Глава 4 — Моделирование Data Vault 2.0

Аннотация

В этой главе рассматриваются сущности, используемые в моделировании Data Vault, включая хабы (Hubs), линки/связи (Links) и сателлиты (Satellites). Показано, как идентифицировать бизнес-ключи в исходных данных и связывать их с другими бизнес-ключами в Data Vault с помощью линк-сущностей. Также рассмотрено, как выделять дополнительные атрибуты из исходных данных и моделировать их в виде сателлитных сущностей.

Обсуждение сателлитов затрагивает необходимость их разделения на основе различных аспектов, например, по классификации или типу данных, по скорости изменения или по исходной системе. Для каждой сущности перечислены и подробно объяснены общие атрибуты, которые следует добавлять при моделировании Data Vault. Это включает в себя рекомендации по использованию хеш-ключей, временных меток и идентификаторов источников записей.

Ключевые слова

• Моделирование данных (Data modeling)
• Сателлиты (Satellites)
• Хаб-сущности (Hub Entities)
• Линк-сущности (Link Entities)
• Бизнес-ключ (Business Key)
• Смарт-ключи (Smart Keys)
• Интеллектуальные ключи (Intelligent Keys)
• Бизнес-ключи (Business Keys)
• Суррогатный ключ (Surrogate Key)
• Временные метки (Time Stamps)
• Идентификаторы источников записей (Record Source Identifiers)

В этой главе представлен подход Data Vault, включая основные типы сущностей, используемые при моделировании хранилищ данных на основе Data Vault. Данная модель ориентирована на масштабируемые сети (scale-free networks), которые часто встречаются в природе, поэтому перед определением типов сущностей кратко рассматриваются такие сети. Каждое определение сопровождается примерами рассматриваемого типа сущности.

Обратите внимание, что данная глава частично основана на книге Super Charge Your Data Warehouse Дэна Линстедта.

Также стоит отметить, что в этой главе используется логический язык моделирования, называемый Visual Data Vault. Дополнительную информацию, включая белую книгу и набор шаблонов для Microsoft Visio, можно найти на сайте https://www.visualdatavault.com/.

---

• VisualDataVault.v11.zip

---

Введение в моделирование Data Vault

Модель Data Vault была изобретена Дэном Линстедтом в 1990-х годах и ориентирована на сложные сети, которые часто встречаются в природе. Многие из этих природных систем можно описать с помощью моделей сложных сетей, представляющих собой структуры, состоящие из узлов (вершин), соединенных связями (ребрами).

Примеры таких сетей включают человеческий мозг, который представляет собой сеть нейронов. Другой пример из природы — организация, которая является сетью людей. Еще один пример — глобальная экономика, которая представляет собой сеть национальных экономик, состоящих из сетей рынков. В свою очередь, рынки состоят из сетей производителей и потребителей. Общим для этих сетей является наличие хабов, таких как люди или другие объекты, связей между этими объектами и информации, описывающей контекст объектов.

В прошлом ученые предполагали, что эти сети имеют случайную природу, то есть расположение связей между хабами является случайным, а большинство хабов имеет примерно одинаковое количество связей. Такой тип случайной сети представлен на Рисунке 4.1.

Рисунок 4.1. Дорожная сеть США: случайная сеть

В случайной сети, такой как дорожная сеть США, большинство хабов имеет всего несколько соединений. Эта характеристика является результатом множества исторических решений, обусловленных географическими, политическими и экономическими факторами. Например, стоимость строительства автомагистралей, как правило, ограничивает количество дорог, добавляемых в систему. То же самое относится к авиационной системе США, представленной на Рисунке 4.2.

Однако разница в том, что расширить сеть авиасообщения намного проще за счет добавления новых соединений между аэропортами, которые являются хабами этой сети. Общая структура сети в основном определяется одновременными действиями авиакомпаний, стремящихся максимизировать свою прибыль. Таким образом, сеть авиаперевозок формируется самостоятельно объектами внутри сети.

Рисунок 4.2. Авиационная сеть США: сеть без масштаба

Мы увидим, что хранилище данных, построенное с использованием модели Data Vault, так же легко расширять, как и любую другую сеть без масштаба (scale-free network).

Терминология моделирования Data Vault

Модель Data Vault представляет собой преобразование естественной модели в ориентированную на бизнес модель (business-centric model) для хранилищ данных. Эта модель отражает бизнес-процессы и связана с бизнесом через бизнес-ключи. Это важное свойство модели Data Vault, поскольку бизнес-ключи определяют, как компании интегрируют, связывают и получают доступ к информации в своих системах. Благодаря ориентации модели Data Vault на бизнес-ключи, мы наследуем возможность интеграции, соединения и доступа к информации так же, как это делает бизнес в своей повседневной деятельности.

Цель модели Data Vault — максимально точно представить бизнес. Исходя из этой цели, рассмотрим критически важные характеристики бизнеса:

• Способность реагировать на быстро меняющиеся бизнес-требования, также известная как гибкость.
• Интеграция различных источников информации для создания новых знаний.
• Сложность бизнес-среды и, в некоторых случаях, самой организации.
• Гибкость для использования новых рыночных возможностей.
• Необходимость прозрачности и подотчетности, по крайней мере, перед аудиторами компании.
• Способность отвечать на запросы информации с помощью специализированных и адаптированных отчетов.
• Возможность масштабирования бизнеса после достижения успеха.

Эти ключевые характеристики позволяют компании выживать в современных конкурентных рынках. Модель Data Vault разработана таким образом, чтобы поддерживать все эти ключевые характеристики при построении системы хранилища данных. Используя модель Data Vault, вы сможете максимально точно адаптировать хранилище данных под бизнес и использовать Data Vault в своих интересах.

Для достижения целей модели Data Vault она основана на трех базовых типах сущностей, которые были выделены из естественной модели. Эти типы сущностей включают хабы, линк-и (связи) и сателлиты.

Каждая сущность выполняет определенную функцию:

• Хаб отделяет бизнес-ключи от остальной модели.
• Линк хранит связи между бизнес-ключами (и/или хабами).
• Сателлит хранит контекст (атрибуты бизнес-ключа или отношений).

Хаб-сущности (Hub Entities)

Когда бизнес-пользователи получают доступ к информации в операционной системе, они используют бизнес-ключ для обращения к бизнес-объектам. Это может быть номер клиента, номер счета-фактуры или идентификационный номер транспортного средства. Иногда система требует от пользователя указать комбинацию ключей, например, номер клиента и код региона, такой как код страны. В других случаях для бизнес-объектов не определен бизнес-ключ, но пользователь может найти нужный объект, выполняя поиск по имени или другому идентифицирующему атрибуту.

Из-за центральной роли этих бизнес-ключей в идентификации бизнес-объектов модель Data Vault отделяет их от остальной модели. Назначение хаб-сущности — хранить бизнес-ключи бизнес-объектов вместе с некоторыми другими данными, называемыми метаданными.

В модели Data Vault существуют хабы для каждого типа бизнес-ключа. В авиационном сценарии существуют отдельные хабы для хранения кодов аэропортов, кодов авиаперевозчиков и номеров рейсов, а также других хабов. Поскольку они содержат бизнес-ключи бизнеса, хабы являются основой модели Data Vault.

Сравнивая хаб Data Vault с примером воздушных перевозок, можно заметить, что аэропорты являются хабами. Они являются центральными элементами сети. В Data Vault бизнес-ключи являются центральными и поэтому размещаются в хабах.

Линк-сущности (Link Entities)

Так же, как аэропорты соединены авиарейсами на Рисунке 4.2, бизнес-объекты связаны друг с другом в бизнесе. Ни один бизнес-объект не существует отдельно от других бизнес-объектов. Напротив, они соединены между собой операционными бизнес-процессами, которые используют бизнес-объекты при выполнении своих задач. В Data Vault эти связи моделируются с помощью линков, которые соединяют два или более хаба.

Типичные бизнес-процессы включают закупки, производство, рекламу, маркетинг и продажи. Поскольку эти процессы часто (но не всегда) представляют собой транзакции, линк (Link) часто также представляет собой транзакцию. Таким образом, он часто служит основой для создания фактов в размерной модели (подробнее об этом в главах 7 и 14). Однако это всего лишь эмпирическое правило.

В авиационном сценарии (Рисунок 4.3), существует линк между хабами авиаперевозчика, аэропорта и номера рейса для представления рейса. Кроме того, этот линк может включать ссылку на бортовой номер самолета. Другие линки могут отслеживать доступные инциденты безопасности, продажи на борту или бронирование мест.

Некоторые возможные линки могут не представлять транзакции (что нарушает эмпирическое правило). Например, может существовать линк, указывающий, что между двумя аэропортами существует соединение (Рисунок 4.4).

Рисунок 4.3. Линк, соединяющий три хаба (логический дизайн)

Рисунок 4.4. Линк, представляющий соединение между двумя хабами (логический дизайн)

Логическая диаграмма показывает линк между хабами Аэропорт и Авиаперевозчик. Обратите внимание на две ссылки на хаб Аэропорт, которые отражают отправную и конечную точку соединения.

Без дополнительной информации мы знаем только то, какое соединение между данными аэропортами существовало в любой момент времени в прошлом. В следующем разделе мы увидим, почему такой нетранзакционный линк полезен.

Саттелит-сущности (Satellite Entities)

Модель Data Vault, состоящая только из хабов и линков, не обеспечила бы нас достаточной информацией. Они предоставляют только информацию о взаимосвязи между бизнес-объектами. Недостающий элемент — это контекст этих бизнес-объектов и контекст этих линков. Для транзакции рейса таким контекстом может быть время в воздухе или задержка рейса по соображениям безопасности.

Саттелиты добавляют эту функциональность в модель Data Vault. Они (Satellites) хранят атрибуты, которые принадлежат либо бизнес-ключу (в хабе), либо связи, либо транзакции (в линке) (Рисунок 4.5).

Рисунок 4.5 Саттелиты на хабах и линках (логический дизайн)

Мы добавили саттелиты к хабам и линкам для хранения информации, необходимой для понимания контекста данных, хранящихся в Data Vault. Обратите внимание на саттелит, связанный с линком соединения между двумя аэропортами. Этот саттелит отслеживает расстояние и количество соединений между аэропортами. Саттелит также хранит историю данных атрибутов — каждое изменение атрибута логируется в саттелит.

Как видно на примере хаба аэропорта, на одном хабе или линке может быть несколько саттелитов. Причины распределения атрибутов между несколькими саттелитами включают наличие нескольких или изменяющихся источников данных, разную частоту изменений или функциональное разделение данных атрибутов.

Определение хаба

Хабы являются основными опорными элементами модели Data Vault. В следующих разделах рассматривается тип сущности хаба и описывается, как определить бизнес-ключ.

Хабы определяются как уникальный список бизнес-ключей и обеспечивают мягкую интеграционную точку для необработанных данных, которые не изменяются по сравнению с исходной системой, но должны иметь одинаковое семантическое значение. Следовательно, бизнес-ключи в одном хабе должны иметь одинаковую семантическую гранулярность. Это означает, что контактное лицо как физическое лицо должно находиться в другом хабе, чем клиент как корпорация (так как в корпорации может быть несколько контактных лиц).

Бизнес-ключ может быть составным ключом. Пример составного ключа — идентификационный номер транспортного средства (VIN), который включает информацию о производителе (первые три символа, называемые WMI-кодом) и информацию, специфичную для поставщика, такую как завод-изготовитель и серийный номер. Эти составные ключи также известны как «умные» (smart) или интеллектуальные (intelligent) ключи, и они рассматриваются подробнее позже в этой главе.

Хаб отслеживает появление нового бизнес-ключа в хранилище данных. Он использует метаданные для отслеживания системы-источника (называемой Record Source) и даты и времени поступления бизнес-ключа в хранилище данных (называемой Load Date). Кроме того, для каждого бизнес-ключа в хабе генерируется хеш-ключ. Хеш-ключ используется для ссылки на бизнес-объект в других сущностях Data Vault, таких как линки и саттелиты. Помимо этого, он повышает производительность загрузки данных в хранилище и объединения бизнес-ключей внутри модели.

Рисунок 4.6 Пример физической структуры сущности хаба в Data Vault (физический дизайн)

Этот хаб использует обязательные метаданные, обсужденные в предыдущем абзаце.

Метаданные хаба (в данном случае атрибуты LoadDate и RecordSource) следует размещать в начале сущности. Это упрощает дизайн (так как все хабы начинаются с одинаковых атрибутов) и облегчает поддержку сущностей Data Vault.

В дальнейшем по книге мы будем использовать символ, показанный на Рисунке 4.7, для обозначения хабов.

Рисунок 4.7 Хаб Data Vault (логический символ)

Определение бизнес-ключа (Business Key)

Прежде чем углубляться в структуру сущности хаба, давайте рассмотрим определение бизнес-ключа и обсудим, как идентифицировать бизнес-ключ в операционных системах.

Бизнес-ключи используются для идентификации, отслеживания и поиска информации. По определению, бизнес-ключ должен иметь очень низкую вероятность изменения и быть уникальным. Это означает, что в одной операционной системе только один бизнес-объект идентифицируется заданным бизнес-ключом, и этот бизнес-ключ не изменяется. Для ясности: в разных операционных системах могут существовать разные бизнес-объекты с одинаковым бизнес-ключом, но в одной и той же операционной системе такого не будет.

Во многих случаях естественные ключи могут использоваться как бизнес-ключи, при условии, что они уникальны и заполнены. Бизнес-ключи должны иметь смысл для бизнеса.

Некоторые примеры бизнес-ключей:

• Номера клиентов
• Номера продуктов (также UPC, EAN или ISBN штрих-коды, в зависимости от случая)
• Номера счетов
• Идентификационные номера транспортных средств (VIN)
• Номера деталей
• Номера счетов-фактур
• Автомобильные номера
• Номера портфелей
• Номера пропусков сотрудников
• Номера заявок в службу поддержки
• Номера водительских удостоверений
• Номера нарядов на работы

Некоторые из этих бизнес-ключей являются умными ключами (или интеллектуальными ключами). Примеры включают идентификационные номера транспортных средств, UPC или EAN штрих-коды. Эти ключи состоят из других ключей, которые идентифицируют другие бизнес-объекты (например, производитель в идентификационном номере транспортного средства).

В некоторых случаях бизнесу не удается обеспечить истинную уникальность бизнес-ключа. Например, один производитель гитар использовал следующую систему для серийных номеров: «первая цифра — это год воспроизводимой модели, вторая цифра — это год производства». Это приводит к дублированию для любых лет с одинаковыми последними цифрами (например, 1996/2006). Для создания действительно уникального бизнес-ключа требуется комбинация серийного номера и года производства.

Другие компании решают ввести суррогатный ключ, чтобы избежать проблемы дублирующихся бизнес-ключей. Они комбинируют серийный номер с искусственно сгенерированным ключом или полностью заменяют серийный номер при ссылке на бизнес-объект. В таком случае суррогатный ключ становится бизнес-ключом.

Однако все эти определения бизнес-ключей являются корректными, поскольку бизнес использует эти ключи для идентификации бизнес-объектов.

Композитные ключи — Composite Keys (также известные как умные ключи — Smart Keys, интеллектуальные ключи — Intelligent Keys)

Мы представили идентификационные номера транспортных средств (VIN) как примеры композитных ключей, также известных как умные ключи или интеллектуальные ключи.

Композитные ключи состоят из нескольких частей. Например, каждый VIN в мире состоит из трех секций:

• Код мирового производителя (WMI)
• Секция описания транспортного средства (VDS)
• Секция идентификатора транспортного средства (VIS)

Коды WMI уникальны и присваиваются только одному автопроизводителю. Однако один производитель может иметь несколько WMI-кодов. Код VDS определяет тип транспортного средства и включает информацию о модели и кузове. Код VIS идентифицирует отдельные автомобили (Рисунок 4.8).

Рисунок 4.8 Индивидуальные секции идентификационного номера транспортного средства

Композитные ключи также известны как умные или интеллектуальные ключи, потому что они содержат бизнес-значение, закодированное в позиционных значениях и форматах. Другие примеры композитных бизнес-ключей:

• Штрих-коды (UPC, EAN и т. д.)
• IMEI-номер, используемый для идентификации мобильных устройств
• MAC-адреса для идентификации сетевого оборудования
• ISBN-коды для книг
• ISSN-коды для периодических изданий
• Номера телефонов
• Адреса электронной почты
• Номера кредитных карт

В Visual Data Vault, языке логического моделирования для Data Vault, различают композитные ключи и умные ключи:

• Композитный ключ состоит из уникальной комбинации нескольких колонок.
• Умный ключ хранится в одном столбце, где отдельные части бизнес-ключа объединены (например, идентификационный номер транспортного средства на Рисунке 4.8).

Процесс идентификации бизнес-ключа

Бизнес-ключ может быть идентифицирован из различных источников. В предыдущей главе мы писали, что «бизнес-ключи используются для идентификации, отслеживания и поиска информации». Исходя из этого, аналитик должен сосредоточиться на приложениях в исходной системе, онлайн-экранах поиска и заголовках отчетов. Везде, где бизнес-пользователь может искать бизнес-объект с помощью референсного кода, есть высокая вероятность, что он использует бизнес-ключи.

Отличным источником информации является интервьюирование бизнес-пользователя. Ключевой вопрос, который аналитик должен задать пользователю:

«Как вы идентифицируете, отслеживаете или находите информацию?»

Эта фраза представляет собой основной принцип определения бизнес-ключей.

Еще одна эффективная стратегия — анализ бизнес-процессов компании (или между компаниями). Бизнес часто идентифицирует и отслеживает свои информационные наборы через бизнес-ключи. Пользователи взаимодействуют друг с другом через бизнес-процессы и передают, прикрепляют или переводят информацию в рамках этих процессов. Поэтому анализ бизнес-процессов помогает выявить ключи, используемые для обработки задач.

Другие источники информации:

• Данные и модели в исходных системах
• XML/XSD-схемы
• Уникальные индексы на бизнес-ключах (это первый индикатор наличия бизнес-ключа)
• Электронные таблицы, OLAP-кубы, документация программного обеспечения

Область действия бизнес-ключей (Scope of Business Keys)

Важно понимать, что у бизнес-ключа есть область действия, в пределах которой он является допустимым.

Например, бизнес-ключи, используемые в операционной системе, могут быть действительны только в этой системе. Они не используются в других системах или бизнес-процессах. Другие бизнес-ключи применяются в локальном контексте, например, в рамках отдельного подразделения (например, отдела продаж). В некоторых случаях бизнес-ключи могут быть уникальны только для одной организации, но не действительны между разными организациями.

Рисунок 4.9 иллюстрирует эту зависимость

Понимание области действия бизнес-ключа важно для выбора наиболее подходящего идентификатора в бизнес-контексте. Чем шире область действия ключа, тем лучше он может представлять бизнес-объект.

Например, автомобиль может иметь суррогатный ключ в операционной системе автопроизводителя. Этот суррогатный ключ действителен только в этой системе. Когда автомобиль производится на заводе, ему присваивается серийный номер, уникальный для всех автомобилей одной марки, модельного года и завода.

Таким образом, этот серийный номер уникален только в данном контексте. Обычно серийный номер используется как часть идентификационного номера автомобиля (VIN), который является глобально уникальным идентификатором для транспортных средств.

Не должно существовать двух автомобилей с одинаковым VIN. Однако автопроизводитель может решить использовать только последние 14 символов VIN, чтобы сэкономить место в операционных системах. Это объясняется тем, что все VIN начинаются с одних и тех же трех символов — WMI-кода производителя.

Однако крупные автопроизводители обычно имеют несколько WMI-кодов. Поэтому не является хорошей бизнес-практикой предполагать, что серийный номер автомобиля является уникальным.

Разница между бизнес-ключами и суррогатными ключами (Business Keys vs Surrogate Keys)

Суррогатные ключи часто используются операционными системами для идентификации бизнес-объекта. Однако они не являются хорошими кандидатами на роль бизнес-ключей, если сам бизнес их не использует. Как только бизнес начинает использовать суррогатный ключ для уникальной идентификации и отслеживания данных в системе-источнике, суррогатный ключ становится бизнес-ключом.

Студентов, изучающих компьютерные науки, учили использовать суррогатные ключи в качестве первичных ключей при разработке баз данных, поскольку это может ускорить соединение (join) таблиц. Вместо использования текстового бизнес-ключа для связи двух записей, они стали применять целочисленные суррогатные ключи, чтобы снизить сложность (например, при использовании составных ключей) и повысить скорость соединений.

Эта практика распространилась больше, чем предполагалось. Разработчики программного обеспечения часто используют суррогатные ключи для идентификации записей в интерфейсах и отчетах. Однако суррогатные ключи не несут никакого смысла. Они служат только для технической идентификации записи в одной системе-источнике.

Структура хаба (Hub Entity Structure)

Каждая сущность Data Vault содержит стандартные атрибуты, которые помогают строить модель, а также отслеживать и запрашивать данные. Тип сущности хаба не является исключением из этого правила.

Для всех хабов Data Vault характерны следующие атрибуты:

• Хеш-ключ (Hash key)
• Бизнес-ключ(и) (Business key(s))
• Дата загрузки (Load date)
• Источник записи (Record source)

Кроме того, существует необязательный атрибут:

• Дата последнего обнаружения (Last seen date)

Хеш-ключ (Hash Key)

Запросы к финальной модели Data Vault требуют намного больше соединений (joins), чем в традиционном хранилище данных. Поэтому при создании модели необходимо подготовить Data Vault так, чтобы увеличить скорость обработки соединений. Здесь на помощь приходит хеш-ключ:

Этот ключ, основанный на бизнес-ключе, становится первичным ключом сущности хаба.
Он используется в качестве внешнего ключа для ссылок на такие сущности, как линки (links) и спутники (satellites).

Хеш-ключ в хабе Data Vault помогает улучшить производительность поиска (lookup) в хранилище данных. Когда ETL-процесс загружает хаб Data Vault данными из промежуточной таблицы (stage table), он проверяет, существуют ли уже бизнес-ключи источника в целевом хабе.

Поскольку поиск по строкам переменной длины обычно медленнее, чем по строкам фиксированной длины, можно вычислить хеш-ключ и добавить его в хаб. Это также повышает производительность, если бизнес-ключи длинные, поскольку символьная последовательность хеш-ключа короче.

Безопасный метод вычисления хеш-ключа для бизнес-ключа хаба рассматривается в главе 11 «Извлечение данных».

Ключевые аспекты хеш-ключей:

• Каждый уникальный бизнес-ключ в хабе Data Vault должен иметь уникальный хеш-ключ.
• Рекомендуется использовать алгоритм MD5 (или другой алгоритм хеширования, например SHA-1).
• Хеш-ключи никогда не должны быть доступны бизнес-пользователям и не должны использоваться за пределами Data Vault.
• Как и суррогатные ключи, хеш-ключи не несут бизнес-смысла – они предназначены только для ускорения и упрощения соединений.
• Важно отметить, что хеш-ключ заменяет порядковый номер (sequence number), который использовался в Data Vault 1.0.

Почему отказались от порядковых номеров в пользу хеш-ключей?

• Хеш-ключи позволяют ссылаться на другие источники данных, например NoSQL-базы.
• Они кроссплатформенные и могут быть восстановлены (один и тот же бизнес-ключ всегда генерирует один и тот же хеш-ключ, если расчет выполнен корректно).
• Хотя соединения по хеш-ключам могут быть медленнее, чем по целочисленным порядковым номерам, их преимущества перевешивают недостатки.

Доказательство этого утверждения рассматривается в следующих главах.

Бизнес-ключ (Business Key)

Атрибут бизнес-ключа в хабе Data Vault хранит бизнес-ключ, который был определен в процессе идентификации бизнес-ключей.

Этот атрибут является основной целью хаба Data Vault. Поэтому он является центральным элементом хаба.

Тип данных бизнес-ключа

• Ориентирован на данные источника.
• В некоторых случаях бизнес-ключи представлены целыми числами.
• Во многих других случаях бизнес-ключ — это строковое значение.
• Поэтому тип данных и длина атрибута должны максимально соответствовать исходной системе.
• На бизнес-ключ должен быть создан уникальный индекс, чтобы обозначить это свойство в модели. Мы будем придерживаться этой практики на протяжении всей книги.

Композитные ключи в хабе

Если бизнес использует композитные ключи, их необходимо хранить в одном хабе Data Vault.
Это соответствует определению и контексту бизнес-процессов, которые используют этот ключ для поиска и индексации с целью получения дополнительного контекста.

Как хранить композитные ключи в хабе?

• Композитный ключ может храниться в одном поле.
• Если композитный ключ хорошо структурирован, его части могут быть разделены по разным полям хаба.
• В этом случае уникальный ключ должен охватывать все поля, входящие в композитный ключ.
• Можно хранить и композитный ключ в одном поле, и его части в отдельных полях в одном хабе.

В таком случае хаб должен содержать два уникальных ключа:

• Один — для поля, содержащего весь композитный ключ.
• Второй — для группы полей, содержащих отдельные части композитного ключа.

Множественные хабы для частей композитного ключа

Можно создать несколько хабов для каждой отдельной части композитного бизнес-ключа.

Например, для идентификационного номера автомобиля (VIN) можно создать:

• Один хаб для VIN (идентификационного номера автомобиля в целом).
• Отдельный хаб для WMI-кодов (коды производителя в составе VIN).
• Отдельный хаб для VDS (раздел описания автомобиля в VIN).
• Отдельный хаб для VIS (раздел идентификатора автомобиля в VIN).
• Однако так как бизнес использует VIN целиком, должен существовать хаб, содержащий VIN-номер в полном виде.

Дата загрузки (Load Date)

Дата загрузки (Load Date) указывает, когда бизнес-ключ впервые поступил в хранилище данных.

Это поле создается и поддерживается системой автоматически.
Дата загрузки должна быть одинаковой для всех данных, загруженных в одном пакете (см. Глава 11, Извлечение данных, для подробностей).

Использование единой даты загрузки позволяет:

• Отслеживать ошибки
• Находить технические проблемы загрузки, которые повлияли на данные в пакете
• Сделать циклы загрузки повторяемыми, согласованными и перезапускаемыми для любого конкретного цикла загрузки.

Дата загрузки генерируется хранилищем данных (или ETL-процессом, который выполняет загрузку).

• Она фиксирует момент времени, когда данные появились в хранилище.
• После установки дата загрузки никогда не должна изменяться.
• Для всех записей в одном цикле загрузки должна быть установлена одна и та же временная метка.

Источник записи (Record Source)

Помимо присвоения временной метки загрузки, также отслеживается исходный источник данных.

Источник записи (Record Source) — это жестко заданное поле, которое обеспечивает прослеживаемость загружаемого набора данных.
Если у бизнес-ключа есть несколько источников данных, то источник записи должен указывать мастер-источник данных.
Если бизнес-ключ отсутствует в мастер-источнике, но присутствует в других источниках данных, тогда источник записи должен указывать фактический источник данного ключа.

Источник записи — ключевой атрибут для аудита хранилища данных.

Он позволяет идентифицировать исходную систему и обеспечивает прослеживаемость данных от информационных витрин до исходного источника.
Это важно для соответствия нормативным требованиям.
Разработчики, аудиторы и бизнес-пользователи получают пользу от наличия атрибута источника записи в каждой строке данных в модели.

Лучше не использовать обобщенные источники, например:

• «SAP» для всех данных SAP.

Вместо этого используйте наиболее детализированный уровень:

• «SAP.FINANCE.GL» — указывает модуль главной книги в финансовом приложении SAP.

Дата последнего обнаружения (Last Seen Date)

В оптимальном сценарии источник данных указывает записи, которые были вставлены, изменены или удалены перед загрузкой в хранилище данных.

Этот процесс известен как Change Data Capture (CDC).

CDC поддерживается многими реляционными СУБД, включая Microsoft SQL Server.
Однако многие операционные системы не предоставляют такую дельта-загрузку.
Вместо этого источники данных предоставляют полный дамп всей таблицы, содержащей все актуальные записи операционной системы.

Такой метод называется полной загрузкой (full load).

Операционным командам и разработчикам приложений часто проще его реализовать.
Определение удаленных данных в полной загрузке

Чтобы определить удаленные данные при полной загрузке, ETL-процесс должен:

• Просканировать таблицу хранилища данных (например, таблицу хабов).
• Проверить, существует ли каждая запись в новом загруженном наборе данных.
• Если запись больше не существует в источнике, это может означать, что она была удалена.

⚠ Важно: В некоторых системах, например, mainframe, запись может не экспортироваться, если она заблокирована для редактирования.

Зачем нужна дата последнего обнаружения (Last Seen Date)

Если источник данных работает таким образом, дата последнего обнаружения (Last Seen Date) может помочь:

• Решить, когда запись следует считать удаленной.
• Определить временной порог, после которого запись считается удаленной.

Как работает дата последнего обнаружения

• Дата последнего обнаружения фиксирует момент, когда бизнес-ключ последний раз появлялся в источнике.
• Для каждого бизнес-ключа в текущей партии данных обновляется дата последнего обнаружения — ей присваивается дата текущей загрузки.
• Если бизнес-ключ отсутствует в текущей партии данных, его дата последнего обнаружения остается неизменной.
• Все бизнес-ключи, чья дата последнего обнаружения ниже установленного порога, считаются удаленными.
• Порог определяется бизнесом в зависимости от характеристик источника данных и бизнес-кейса.

⚠ Обратите внимание: Дату последнего обнаружения следует использовать только в том случае, если в системе нет журнала аудита или механизма CDC.

В Главе 11 подробно рассматриваются причины этой проблемы и методы заполнения даты последнего обнаружения.

Примеры хабов

Хабы, показанные на Рисунке 4.10, демонстрируют использование различных атрибутов.

Рисунок 4.10 Пример хабов Data Vault (физический дизайн)

HubAirline

Использует идентификационный номер авиакомпании (AirlineID), назначаемый Министерством транспорта США (US DOT), для уникальной идентификации авиакомпании.
Бизнес-ключ представлен в виде хэш-ключа AirlineKey, который создается путем хеширования AirlineID.

HubCarrier

Использует код перевозчика (Carrier Code), присваиваемый IATA.
Этот код шире применяется для идентификации перевозчика, чем AirlineID.
Проблема: код перевозчика не всегда уникален, так как один и тот же код мог быть присвоен разным перевозчикам в разные периоды времени.

HubFlight

Использует составной бизнес-ключ для представления объекта «рейс».

Составной ключ состоит из двух независимых бизнес-ключей:

• Carrier (перевозчик).
• FlightNum (номер рейса).

Отдельный хаб для номера рейса бессмыслен, так как:

• Номер рейса назначается авиакомпанией.
• Один и тот же номер рейса может использоваться разными авиакомпаниями.
• Первичный ключ создается путем хеширования составных бизнес-ключей в один атрибут, что улучшает идентификацию и производительность.
• Дополнительная информация, например, дата рейса, в хабе не хранится — она сохраняется в спутниках (satellites).

HubFlightCode

Альтернативный способ представления составного бизнес-ключа.

В этом случае:

• Составной ключ представлен в одном поле FlightCode.
• Отдельные компоненты ключа также хранятся в Carrier и FlightNum.

HubAirplane

Использует атрибут LastSeenDate.

Это оправдано, так как:

• Источник данных сообщает только об используемых самолетах, но не содержит информации о том, был ли самолет выведен из эксплуатации перевозчиком.
• LastSeenDate позволяет определить, какие самолеты больше не используются авиакомпанией.

Определение Link

Тип сущности Link отвечает за моделирование транзакций, ассоциаций, иерархий и переопределений бизнес-терминов.

• Link соединяет бизнес-ключи; следовательно, связи моделируются между хабами.
• Links фиксируют и записывают прошлые, настоящие и будущие взаимоотношения между элементами данных с максимально возможной детализацией.
• Links не фиксируют временные линии или временные аспекты — такие концепции (включая актуальный статус связи) являются частью контекста, а не задачей links.
• По этой причине в links не должно быть конечных дат (end-dated) или другой временной информации, за исключением атрибута Load Date (по техническим и информационным причинам).
• Links представляют связь, которая существует в настоящее время или существовала в прошлом.
• Добавление временных ограничений в link-структуры (например, Begin Date и End Date) привязывает связь к одной временной шкале и заставляет хранилище данных завершать и запускать эту связь только один раз.

Этого ограничения следует избегать, так как оно не всегда будет истинным.
Например, даже если такое ограничение сейчас подходит для организации, в будущем бизнес-процессы могут измениться.
Кроме того, взаимоотношение может быть случайно (или временно) удалено в исходной системе и восстановлено при следующем обновлении данных.
Data Vault должен фиксировать такое временное удаление в целях аудита, однако контекстная информация (бизнес-уровень) должна фиксировать процесс восстановления.
Links в Data Vault реализуются с помощью таблиц, которые представляют отношения «многие ко многим».

Links соединяют два или более хабов (или даже тот же самый хаб дважды, используя разные ссылки на хабы).

Link содержит:

• Хэш-ключ каждого связанного хаба.
• Дополнительные метаданные (обсуждаются далее в этой главе).

Типичная сущность Data Vault link представлена на Рисунке 4.11.

Рисунок 4.11 Link сущность в Data Vault (физический дизайн)

Первичный ключ сущности — это хеш-ключ, который идентифицирует link внутри хранилища данных.

Этот ключ используется спутниками (satellites), которые добавляют контекст к link, или другими link, которые ссылаются на данный link.
Хеш-ключ также улучшает поиск записей при загрузке новых данных в таблицу.
Он основан на бизнес-ключах CarrierCode и AirportSeqID, которые хранятся в соответствующих хабах.
Атрибуты Load Date и Record Source предоставляют информацию о времени загрузки записи и ее источнике.

На протяжении всей книги для Data Vault links будет использоваться логический символ, показанный на Рисунке 4.12.

Рисунок 4.12 Логический символ Data Vault link

Форма сущности напоминает звено цепи, что помогает лучше идентифицировать этот базовый элемент.
Кроме того, используется иконка цепи для той же цели.
Data Vault link соединяет два или более хабов (ссылки на хабы), поэтому он всегда изображается вместе с ними (Рисунок 4.13).

Рисунок 4.13 Link, соединяющий два хаба (логическая схема)

Links обеспечивают масштабируемость модели Data Vault.

Можно начать с относительно небольшой модели хранилища данных в Data Vault.
Затем эта модель может расширяться (масштабироваться) путем добавления новых хабов и links для создания более крупной структуры.

Причины использования отношений многие-ко-многим

Отношения многие-ко-многим предоставляют ряду преимуществ для модели.

Они обеспечивают гибкость, поскольку изменения в бизнес-правилах не требуют переработки links.
Гранулярность выражается количеством связанных хабов (или бизнес-ключей) и четко задокументирована.

Поскольку отношения моделируются в link-сущностях, такие сущности:

• помогают физической модели адаптироваться к изменениям данных и бизнес-правил
• минимизируют влияние этих изменений на существующие данные (историю) и процессы загрузки и запросов

Links позволяют снизить количество изменений в Data Vault-модели, которые вызваны изменениями отношений в бизнес-модели.

Пример:

Допустим, сегодня бизнес определяет правило:

«Один авиаперевозчик может обслуживать несколько аэропортов, но каждый аэропорт должен обслуживаться только одним перевозчиком.»

В традиционной третьей нормальной форме (3NF) эта связь моделируется через внешний ключ в дочерней таблице аэропортов, который ссылается на первичный ключ в таблице перевозчиков (Рисунок 4.14).

Рисунок 4.14 Отношение один-ко-многим (физическая модель)

Но если бизнес изменит правило:

«Теперь один аэропорт может обслуживаться несколькими авиаперевозчиками.»

Это потребует изменения структуры данных для поддержки отношения многие-ко-многим (Рисунок 4.15).

Рисунок 4.15 Отношение многие-ко-многим (физическая модель)

Проблема в том, что изменение бизнес-правила приводит к необходимости переработки существующих структур.

Любой редизайн требует реинжиниринга всех зависимых процессов и моделей.
Каждое изменение затрагивает не только новые процессы, но и существующую функциональность, даже если она не должна меняться с точки зрения бизнеса.
Без этих модификаций существующие процессы просто перестанут работать, так как все еще ожидают связи один-ко-многим.
В модели Data Vault существуют только многие-ко-многим отношения, так как используются link-сущности.

Link-сущности могут моделировать любые типы связей:

• 1:m,
• m:n,
• m:1,
• 1:1,
• без изменений в самой структуре link-таблицы.

ETL-процессы загрузки остаются неизменными, чего нельзя сказать о традиционных хранилищах данных, где изменение определения связи требует переработки ETL-процессов.

Таким образом, модель Data Vault стремится свести необходимость реинжиниринга к нулю.

Гибкость Links

Links значительно повышают гибкость модели Data Vault.

Добавлять новые links или изменять тип связи существующих links легко,
→ это позволяет IT-отделу быстрее реагировать на изменения в бизнесе.

Чтобы добавить новую функциональность,
→ IT достаточно добавить новые hubs и связать их links с существующими hubs.
Пример:

На рисунке 4.16 показана начальная модель Data Vault для примера с авиацией (логическая схема).

Рисунок 4.16 Исходная модель до изменений (логический дизайн)

Если бизнес решает добавить информацию о самолете, в Data Vault добавляется новый hub, затем он связывается links с существующей моделью (Рисунок 4.17).

Рисунок 4.17 Модель Data Vault после модификации (логический дизайн)

При этом существующая модель не изменяется.

ETL-процессы, которые зависят от нее, не требуют доработки.
Влияние изменений на существующее хранилище данных равно нулю.
Это и есть ключевое преимущество Data Vault.
Дальнейшие изменения (например, добавление новых данных в хранилище) проводятся аналогичным образом.

Links для объединения распределенных хранилищ данных
Links можно использовать не только внутри одного хранилища данных, но и для связи распределенных хранилищ, где часть модели хранится в одном месте, а другая часть — в другом (Рисунок 4.18).

Рисунок 4.18 Распределенное хранилище данных, соединенное links Data Vault

На схеме:

• Data Vault с информацией о полетах в США
• Data Vault с информацией о полетах в Европе
• Традиционное хранилище данных для Азиатско-Тихоокеанского региона

Как видно, можно даже связать Data Vault-хранилище с традиционными хранилищами, которые изначально не использовали Data Vault.
Кроме того, Data Vault может быть подключен к неструктурированным источникам данных, таким как Hadoop или обычные файлы в файловой системе.

Гранулярность Links

Гранулярность связей определяется количеством хабов, которые они соединяют. Каждый раз, когда в связь добавляется новый хаб, вводится новый уровень гранулярности. Чем больше хабов соединяет связь, тем более тонкой становится гранулярность. Когда добавляется новый хаб, мы уменьшаем гранулярность связи. Таким образом, связи ведут себя как факты в размерной модели. Когда в таблицу фактов добавляется новое измерение, гранулярность также уменьшается.

Если связь в Data Vault уже находится в эксплуатации и бизнес требует изменения гранулярности, есть два варианта для рефакторинга модели Data Vault. Во-первых, мы можем изменить существующую связь и добавить ссылку на другой хаб. Однако это потребует перепроектирования существующих ETL-работ и также необходимо определить, как будет обрабатываться исторические данные в новой связи (которые имеют другую гранулярность). Это также ставит под угрозу возможность аудита данных, поскольку исходная система никогда не поставляла значение NULL (Рисунок 4.19).

Рисунок 4.19 Манипулирование историческими данными в связи Data Vault

По этой причине модификация существующих структур связей больше не является приемлемой практикой в моделировании Data Vault 2.0.

Обратите внимание, что на Рисунке 4.19 каждая ссылка на другие бизнес-объекты (хабы) представлена псевдо-хеш-ключом и бизнес-ключом в фигурных скобках (например, «8fe9… {UA}»).

Лучший вариант — создать новую связь для новых входящих данных и «закрыть» старую связь. Закрытие связи означает, что новые данные не добавляются в таблицу связи. Вместо этого новые данные добавляются в новую связь. Когда новый бизнес строит информационную модель, он должен определить, как связи с разной гранулярностью будут объединяться. Таким образом, можно обеспечить аудитируемость входящих данных и удовлетворить требования бизнеса.

SQL-запрос в центре Рисунка 4.20 представляет собой бизнес-правило, которое описывает, как обрабатывать старые данные. Например, правило указывает, что аэропорт в старых данных должен быть установлен как «неизвестный», что представлено хеш-ключом 0 (упрощено). Полученная таблица используется для создания таблицы Business Vault, как обсуждается в Главе 14, «Загрузка размерной информационной модели», или измерения в информационной модели.

Рисунок 4.20 Объединение исторических данных (верхний левый угол) с новыми данными (верхний правый угол) из отдельных связей Data Vault

Второй вариант также работает, когда необходимо удалить уровень гранулярности (ссылку на хаб) (Рисунок 4.21).

Рисунок 4.21 Удаление исторических данных в связи Data Vault

Если мы просто удалим столбец «Самолет» из старой связи, мы потеряем данные из-за удаления ссылки из связи. Это худший случай для аудируемого хранилища данных. Снижение данных работает аналогично оператору GROUP BY без каких-либо мер.

Рисунок 4.22 показывает уменьшение уровня гранулярности. Обратите внимание на SELECT DISTINCT в SQL-запросе.

Рисунок 4.22 Объединение исторических данных (верхний левый угол) с новыми данными (верхний правый угол) из отдельных связей Data Vault

Link Unit-of-Work (Единица работы связи)

Похожая проблема, связанная с гранулярностью связей, возникает при нарушении единицы работы связи. Единица работы — это связанный набор данных, который сохраняет ключевые наборы вместе. Она обеспечивает выполнение запросов по данным связи позднее, устанавливая согласованность между поступающими данными и данными, хранящимися в связях Data Vault. В некоторых случаях моделировщики хранилищ данных пытаются разделить связь на несколько более мелких связей, чтобы нормализовать информацию связи для целей моделирования.

В Таблице 4.1 показан пример упрощенной таблицы исходной системы, которая станет основой для связи Data Vault.

Таблица 4.1 Единица работы в исходной системе

Данные в исходной таблице идентифицируют соединения между аэропортами, обслуживаемыми перевозчиками. Каждый перевозчик (в данном случае два перевозчика), идентифицированный номерами последовательности 222 и 729, обслуживает различные исходные аэропорты и соединяет их с аэропортами назначения. Если данные нормализуются, то следующие две таблицы (Таблица 4.2) будут результатом:

Таблица 4.2 Нормализованная исходная система

Для проверки правильности этой нормализации полезно проверить, можно ли восстановить данные исходной системы из этих данных. Таблица 4.3 будет создана после денормализации данных из предыдущих таблиц.

Таблица 4.3 Денормализованная исходная система

При повторном объединении данных был создана запись, которой не существовало в исходной системе. Это произошло потому, что единица работы была нарушена при нормализации данных на предыдущем шаге, что сделало данные, захваченные двумя нормализованными таблицами, недействительными. В реляционном моделировании данных эта проблема также известна как зависимость от многозначных значений.

Структура сущности Link

Основная структура связи Data Vault состоит из хеш-ключей бизнес-ключей, хранящихся в ссылочных хабах. Кроме того, связь Data Vault имеет следующие обязательные метаданные:

• Хеш-ключ
• Дата загрузки
• Источник записи

Также возможно использовать дополнительный атрибут:

• Дата последнего просмотра

В дополнение к этим обязательным атрибутам, связь Data Vault может иметь следующий дополнительный атрибут:

• Ключ зависимого дочернего элемента

Хеш-ключ (Hash Key)

Подобно хабам в Data Vault, связь (Link) должна иметь хеш-ключ. Когда связь загружается данными из таблицы staging, задача ETL должна проверить, существует ли уже данное отношение или транзакция в таблице связи, поскольку не должно быть дублирующих записей связи, представляющих одно и то же отношение или транзакцию. Для этого задача ETL должна сравнить бизнес-ключи всех связанных бизнес-объектов. Поскольку реляционная база данных медленно сравнивает строки переменной длины (что является обычной характеристикой бизнес-ключей), производительность поиска часто бывает низкой. Проблема становится более серьезной, если бизнес-ключи не хранятся в связи Data Vault и должны быть соединены с ключами из ссылочных хабов, прежде чем их можно будет сравнивать. Хеш-ключ заменяет последующие соединения с ссылочными хабами при загрузке данных из staging-таблиц. Для выполнения соединений вычисляется хеш-код для комбинации всех бизнес-ключей в связи. Поскольку существует большая вероятность ошибок при вычислении хеш-кодов для бизнес-ключей, безопасный метод будет обсуждаться в Главе 11, «Извлечение данных».

Хеш-ключи также могут использоваться для соединения неструктурированных данных из внешних хранилищ данных, таких как распределенная файловая система Hadoop (которая использует хеш-ключи MD5 для идентификации данных).

Ключ зависимого дочернего объекта (Dependent Child Key)

Связь может иметь ключ зависимого дочернего элемента (например, номер строки), который используется в некоторых случаях, например, для представления транзакции счета в связи. Номер строки на счете — это последовательный индекс, который действителен только в пределах счета. Он не является уникальным сам по себе, но уникален только в сочетании с номером счета. Этот тип номера называется «дегенеративным полем» и влияет на гранулярность и уникальность набора данных в связи.

К дегенеративным полям (degenerate fields) применяются следующие правила:

• Они не могут существовать сами по себе (как хабы).
• Они не имеют бизнес-значения.
• Они «зависят» от другого контекста, чтобы быть действительными.
• Они придают смысл и уникальность дополнительной информации об отношении.
• У них нет собственных «описателей».

Примеры дегенеративных полей включают:

• Номера строк в счетах
• Стороны кассетной ленты (сторона A и сторона B)
• Номер страницы в книге
• Последовательный номер в кадре TCP
• Временная метка сообщения электронной почты

Примеры показывают, что де-генеративные поля не обязательно должны быть числовыми значениями. Они могут быть символами (как в случае с кассетной лентой) или датами (как в случае с временной меткой сообщения электронной почты). Однако с датами следует быть осторожным, поскольку не все даты (такие как начала/окончания, начало/конец и другие описательные даты) могут стать частью связи. Чаще всего эти описательные атрибуты бизнес-объектов становятся частью спутников.

Ключ зависимого дочернего элемента также используется как идентифицирующий элемент структуры связи, поэтому хеш-ключ выводится из бизнес-ключей ссылочных хабов и ключа зависимого дочернего элемента.

Примеры ссылок

Рисунок 4.23 представляет несколько примеров таблиц сущностей связи Data Vault.

Рисунок 4.23 Примеры связей Data Vault (физический дизайн)

Первая связь, LinkConnection, соединяет в общей сложности четыре хаба: хабы аэропортов-перевозчиков, исходных аэропортов, аэропортов назначения и номер рейса. Обратите внимание, что хаб аэропорта был упомянут дважды: один раз через SourceAirportHashKey и второй раз через DestinationAirportHashKey. Кроме того, связь включает обязательные метаданные LoadDate и RecordSource.

Вторая связь ссылается только на два других хаба: HubCarrier и HubAirport.

Определение спутника

Спутники хранят все данные, которые описывают бизнес-объект, отношение или транзакцию. Они добавляют контекст на определенный момент времени или на период времени к хабам и связям.

Однако этот контекст часто изменяется в бизнесе, и, следовательно, описательные данные в спутнике также изменяются со временем. Цель спутника — отслеживать эти изменения.

Спутник прикрепляется только к одному хабу или связи. Поэтому он идентифицируется хеш-ключом родительского элемента и временной меткой изменения (Рисунок 4.24):

Рисунок 4.24 Сущность спутника Data Vault (физический дизайн)

В дополнение к стандартным метаданным, спутник хранит атрибуты, которые описывают контекст бизнес-объекта или отношения. Для достижения этой цели атрибуты захватывают неидентифицирующие бизнес-элементы бизнес-объектов или отношений. Эти элементы часто известны в исходной системе как описания, записи в свободной форме или вычисляемые элементы.

Примеры описательных данных включают:

• Внешний цвет автомобиля
• Имя и фамилия человека (например, клиента или сотрудника)
• Адрес доставки заказа
• Количество свободных мест в самолете
• Название бизнеса авиаперевозчика
• Описания продуктов в каталоге товаров
• Дата начала и окончания аренды автомобиля

Последний пример показывает, что дата окончания отношения (в данном случае: дата окончания аренды автомобиля) захватывается спутником. В Data Vault нет другого концепта окончания связи. Как и в других типах сущностей Data Vault, метаданные идут первыми в порядке столбцов. Описательные атрибуты располагаются в конце спутника. Поскольку одной из основных задач Data Vault является захват данных из исходных систем, описательные атрибуты должны использовать типы данных, максимально приближенные к типам данных исходных систем с технической точки зрения. Это включает в себя значения NULL.

Не все атрибуты бизнес-объекта, отношения или транзакции хранятся в одном спутнике. Вместо этого атрибуты организуются по бизнес-классификации или типу данных и хранятся в отдельных спутниках по категориям. Распространенной практикой является хранение всех атрибутов из одной исходной системы в одном спутнике, но разделение их по частоте изменений.

Мы будем использовать логический символ, показанный на Рисунке 4.25, для рисования спутников в этой книге.

Рисунок 4.25 Спутник Data Vault (логический символ)

Обратите внимание, что спутники никогда не зависят от более чем одной родительской таблицы (то есть, они никогда не зависят от более чем одного хаба или одного спутника). Они также не могут быть родителями для других таблиц (без снежинки). По этой причине они не вводят собственные хеш-ключи.

Важность сохранения истории

Предоставление исторического представления данных — одна из функций, которые выполняет хранилище данных в бизнесе. Data Vault использует свои спутники для хранения каждого изменения исходных данных. Однако возможно изменить, изменить или переработать структуру спутника. При этом необходимо удостовериться, что 100% исторических данных, хранящихся в изменяемом спутнике, будут сохранены. В противном случае ваше хранилище данных потеряет свою аудируемость и не пройдет аудит.

Из-за архитектуры Data Vault хранилище данных становится единственным местом, где хранятся исторические данные. В области staging хранилища данных нет исторических данных. Данные в информационном марте могут изменяться в зависимости от бизнес-требований. Единственное место, где данные остаются неизменными, — это хранилище данных. Поэтому важно понимать, что хранилище данных является системой учета. Бизнес-пользователи могут иметь другое мнение о системе учета, но: Data Vault становится системой учета, когда операционные системы выводятся из эксплуатации, изменяются или перерабатываются. В таком случае спутники Data Vault могут быть закрыты, но данные все равно остаются в аудируемом формате исходных данных.

Поскольку необходимо сохранять историю данных, обновлять или изменять данные в спутнике запрещается. Единственное исключение из этого правила — атрибут Load End Date предыдущей версии данных. Глава 12, «Загрузка Data Vault», показывает, как изменить этот атрибут. Кроме того, в спутник добавляются только те исходные записи, в которых произошло хотя бы одно изменение. Следовательно, спутник является дельта-ориентированным, что сравнимо с измерением типа II в моделировании размерностей.

Разделение спутников (Splitting Satellites)

Наша цель не заключается в том, чтобы рекомендовать хранить всю описательную информацию о бизнес-объекте в атрибутах одного спутника. Вместо этого рекомендуется распределить данные между различными спутниками. Рекомендуется сначала разделить исходные данные по системе источника, а затем по скорости изменений.

Разделение по исходной системе (Splitting by Source System)

Рекомендуемая практика — разделять входящие данные сначала по системе источника. Это означает, что каждый входящий набор данных сохраняется в отдельных спутниках, которые, в свою очередь, зависят от их родителя (либо хаба, либо ссылки). Таким образом, исходные данные из денормализованного набора данных источника будут распределяться по различным спутникам, чтобы сохраняться в зависимости от соответствующего бизнес-объекта, отношения или транзакции.

Преимущества такой практики следующие:

• Она позволяет дизайнеру добавлять новые источники данных, не изменяя существующие сущности спутников.
• Убирает необходимость изменять входящие данные так, чтобы они соответствовали существующим структурам (например, путем преобразования данных в другой тип данных или разбиения, объединения, изменения длины, сокращения или другого манипулирования входящими данными).
• Она позволяет модели Data Vault сохранять историю системы источника и, следовательно, сохранять аудит для системы. Рассмотрим спутник, который хранит данные из нескольких систем: изменение в одной системе создаст новую запись в спутнике. Из количества строк не будет сразу понятно, какая система вызвала изменение.
• Она максимизирует параллелизм загрузки, поскольку нет конкуренции (на уровне ввода/вывода или базы данных) за целевой ресурс (спутник). Данные могут быть вставлены в спутник немедленно, не учитывая поступление данных из других систем, которые могут также пытаться вставить свои данные сразу.
• Позволяет интегрировать данные в реальном времени без необходимости интегрировать их с исходными данными, загруженными из пакетов. Нет зависимостей между несколькими системами, которые могли бы заставить систему иметь оба типа данных (в реальном времени и из пакетов) готовыми одновременно.

Даже когда спутники разделены по системе источника, атрибут Record Source все равно требуется. Атрибут Record Source может использоваться для идентификации источника данных по географическому положению или приложению. Например, источник может быть системой SAP, которая распределена по более чем одной физической машине. В зависимости от требований хранилища данных мы отслеживаем отдельную физическую машину в атрибуте Record Source.

Разделение по скорости изменений (Splitting by Rate of Change)

После того как данные разделены по системе источника, также является хорошей практикой разделить данные по скорости изменений. Рассмотрим спутник, который хранит информацию о самолете. Некоторые атрибуты меняются не так часто: например, количество доступных мест, оборудование, максимальный возможный груз и т.д. Некоторые атрибуты могут изменяться чаще, например, общее количество пролетенных миль (Рисунок 4.26).

Рисунок 4.26 Спутник до обновления пролетенных миль

Поскольку последний атрибут изменяется каждый раз, когда самолет выполняет полет, это создаст новую запись в спутнике для отслеживания изменения. Для этого необходимо отслеживать текущее состояние других атрибутов. Но поскольку они не изменились, они просто занимают место в новой записи (Рисунок 4.27).

Рисунок 4.27 Спутник после обновления пролетенных миль

Чтобы решить эту проблему, лучшим подходом будет разделение данных. Те атрибуты, которые изменяются часто, хранятся в одном спутнике, а те атрибуты, которые изменяются реже, — в другом. Если существует более двух частот изменений, должно быть больше спутников (например, один спутник для неизменяющихся атрибутов, один спутник для атрибутов, которые изменяются ежемесячно, один спутник для атрибутов, которые изменяются ежедневно и т.д.).
В книге мы будем использовать оба этих подхода при загрузке данных в спутники Data Vault.

Структура сущности спутника

Кроме атрибутов, которые хранят описательные данные в спутнике, требуются следующие метаданные:

• Дата загрузки
• Источник записи

Кроме того, в сущностях спутников Data Vault требуются следующие атрибуты:

• Хеш-ключ родителя
• Дата окончания загрузки

Следующие атрибуты являются необязательными для спутников Data Vault:

• Дата извлечения
• Хеш-дифференциал

Родительский хеш-ключ (Parent Hash Key)

Обязательный хеш-ключ родителя является частью первичного ключа, который идентифицирует строку в спутнике. Другой частью идентификации является дата загрузки; вместе они предоставляют контекст и дату/время изменения. Хеш-ключ родителя ссылается на первичный ключ хаба или ссылки родительского бизнес-объекта (того, к которому хаб или ссылка добавляют контекст).

Как уже упоминалось, каждая сущность спутника должна зависеть только от одного хаба или спутника. Невозможно создать спутник, который зависит от более чем одного хаба или ссылки.
Для каждого хаба или ключа ссылки должно быть как минимум одно соответствующее записанное значение в спутнике. В противном случае вам придется использовать внешние соединения, которых следует избегать по причинам производительности и сложности.

Дата загрузки (Load Date)

Обязательная дата загрузки является второй частью первичного ключа спутника. Она указывает на дату и время изменения, зафиксированного в записи спутника. Обратите внимание, что это время, когда хранилище данных впервые увидело запись. Это не временная метка, предоставляемая системой источника. Такая временная метка будет добавлена как обычный атрибут спутника, описывающий данные. Причина этого заключается в том, что временные метки из систем источников часто ненадежны или поступают из другого (или неопределенного) часового пояса, который не контролируется хранилищем данных. Поэтому эта информация захватывается как описательные данные.

Существует исключение из этого правила: при загрузке исторических данных, например, при первоначальной загрузке хранилища данных, дату загрузки необходимо установить искусственно, чтобы зафиксировать исторические загрузки. Проблема заключается в том, что дата загрузки используется моделью Data Vault для идентификации изменений в системе источника. Если бы исторические данные загружались с датой загрузки, установленной на фактическую дату и время начальной загрузки, все изменения, произошедшие в истории, перекрывали бы друг друга в тот же день (день начальной загрузки) и не могли бы быть зафиксированы в Data Vault. Чтобы зафиксировать изменения, как если бы они происходили в прошлом, мы предполагаем, что данные были загружены в прошлом, и устанавливаем дату загрузки на дату извлечения данных из системы источника.

Подобная проблема возникает, когда системы источников предоставляют несколько изменений описательной информации о бизнес-ключе (в хабе), отношении или транзакции (обе эти сущности фиксируются в ссылке): в этом случае предоставляется мини-дельта, которая фиксирует изменения, как они произошли в операционной системе. Для захвата таких источников используются последовательные номера, аналогичные многоактивным спутникам, которые рассматриваются в главе 5, «Моделирование промежуточных данных Data Vault 2.0».

Дата окончания загрузки (Load End Date)

Обязательная дата окончания загрузки указывает на дату и время, когда запись в спутнике становится недействительной. Это единственный атрибут, который обновляется в спутнике. Обновление происходит каждый раз, когда загружается новая запись из системы источника. В то время как новая запись имеет текущую дату загрузки, последняя запись спутника, которая была действительной до загрузки новой записи, обновляется, чтобы отразить новую дату окончания загрузки, которая является датой загрузки новой записи. Дата окончания загрузки требуется для достижения необходимой физической производительности при извлечении данных из Data Vault, как показано в главе 14, «Загрузка информационного хранилища измерений». С точки зрения логического моделирования эта дата не является обязательной.

Хеш-разница (Hash Difference)

Необязательный атрибут хеш-разницы аналогичен хеш-ключу в связи (link) Data Vault. Это хеш-значение всех описательных данных записи спутника.

Наличие этого хеш-значения помогает быстро и эффективно сравнивать значения строк. Хеш-разница позволяет быстро выявлять различия в описательных атрибутах и добавлять новые записи спутника только в случае изменения данных в спутнике.

Некоторые описательные атрибуты можно исключить из вычисления хеш-значения для атрибута хеш-разницы. Это необходимо, если некоторые изменения в исходной системе должны игнорироваться Data Vault.

Примечание: В моделях Data Vault сокращение для хеш-разницы часто обозначается как hdiff или hash diff.

Глава 11, «Извлечение данных», показывает, как вычислять атрибут хеш-разницы при его использовании в загрузках спутников.

Дата извлечения (Extract Date)

Необязательный атрибут даты извлечения фиксирует дату и время, когда данные были извлечены из исходной системы. Он помогает понимать процессы исторической загрузки и наиболее полезен, если данные предоставляются в виде плоских файлов и загружаются из различных источников по всему миру.

При использовании прямого доступа через SQL дата извлечения часто недоступна. Однако ETL-процессы обычно ведут журнал своей активности, включая дату и время извлечения данных из исходных систем. Таким образом, дата извлечения доступна как метаданные в процессных логах ETL-инструмента и не требует включения в Data Vault.

Поскольку дата извлечения зависит от исходной системы, она рассматривается как ненадежная временная метка. Данные могут быть извлечены из исходной системы, в которой часы или часовой пояс системы настроены некорректно. В других случаях данные извлекаются с другого сервера (не из исходной системы) с часовым поясом, отличным от часового пояса исходной системы или хранилища данных, при этом эта информация не добавляется во временную метку. В любом из этих случаев дата извлечения является лишь справочными данными и становится описательным атрибутом в спутнике Data Vault.

Существует множество других «дат» и «времени», присутствующих в исходных данных, например, даты создания, плановые даты, фактические даты и так далее. Все эти даты должны храниться как описательные атрибуты в таблицах спутников. Однако они никогда не должны использоваться для заполнения значений даты загрузки или даты окончания загрузки.

Примеры спутников

Рисунок 4.28 представляет несколько примеров спутников Data Vault.

Рисунок 4.28 Примеры спутников Data Vault (физическое проектирование)

Первый пример, SatAirport, зависит от HubAirport через AirportSeq. Идентифицирующий основной ключ представляет собой комбинацию AirportSeq и LoadDate (дата и время, когда эта запись была впервые увидена хранилищем данных). Кроме того, спутник использует атрибуты метаданных LoadEndDate и RecordSource. Для ускорения поиска изменений в строках спутник также использует необязательный атрибут HashDiff. Остальная часть спутника состоит из описательных атрибутов из системы источника.
SatAirportTZ был выделен из SatAirport, потому что он хранит атрибут, который меняется чаще, чем описательные атрибуты в SatAirport. В то время как эти атрибуты меняются очень редко (менее одного раза за десять лет), GMT-смещение локации меняется дважды в год (когда регион аэропорта переходит на летнее время). Если бы атрибут GMTOffset хранился в SatAirport, все описательные атрибуты были бы скопированы в новую строку, даже если изменения касаются только этого атрибута, а не всей описательной информации.
Последний спутник — это спутник на ссылке Data Vault, LinkConnection. Он хранит все описательные данные о соединении. Поскольку информация предоставляется в виде дельта-загрузок (система источника предоставляет только новую информацию о соединениях), нет необходимости искать, какие данные уже существуют, и, следовательно, нет необходимости в атрибуте HashDiff.

Ведущий ключ связи (Link Driving Key)

Пример SatConnection на рисунке 4.28 зависит от связи (link), как описано ранее. Модель на рисунке 4.29 показывает эту взаимосвязь.

Рисунок 4.29 Связь, привязанная к четырем концентраторам (логический дизайн)

Спутник SatConnection связан с LinkConnection. Сама связь зависит от четырех концентраторов, которые также показаны на рисунке 4.29. Если добавляется новая запись связи, появится одна или несколько записей спутника, описывающих контекст связи.

Таблица 4.4 показывает две записи, описывающие одно и то же соединение. Очевидно, что описательная информация была обновлена в исходной системе и зафиксирована как изменение спутником. Обе записи ссылаются на одно и то же соединение, используя одинаковый Connection Hash Key. Атрибут Load Date указывает, когда данные были загружены из исходной системы.

Однако связь на рисунке 4.29 не полностью отражает реальность данных, представленных в таблице 4.4. На самом деле ключ связи состоит из двух частей. Первая часть идентифицирует перевозчика и обслуживаемое соединение, то есть аэропорт отправления и аэропорт-концентратор. Вторая часть ключа — это номер рейса. В реальности перевозчик может изменить номер рейса, выполняющего соединение, но само соединение остается неизменным.

Соединение идентифицируется тремя ссылками на концентраторы, которые выделены жирными стрелками на рисунке 4.30 (модифицированная версия рисунка 4.29).

Таблица 4.4 Данные спутника в SatConnection

Рисунок 4.30 Связь с ведущим ключом (логический дизайн)

Такой набор ссылок на концентраторы называется ведущим ключом (driving key) в моделировании Data Vault 2.0. Часто его также называют первичным ключом исходной структуры.

Таблица 4.5 показывает данные внутри структуры связи.

Таблица 4.5 LinkConnection с заполненными данными

Заполненные данные в LinkConnection показывают, что United Airlines изменила код рейса с UA4711 на UA123 для соединения Денвер (DEN) – Нью-Йорк (JFK).

Поскольку хеш-ключ вычисляется на основе всех родительских бизнес-ключей, каждая запись связи имеет разный идентифицирующий хеш-ключ.

С точки зрения моделирования ведущий ключ (driving key) не является видимым. Это логическая конструкция, которая должна быть реализована в процедурах загрузки, особенно при загрузке данных спутника. Если в связи изменяется ключ, который не является частью ведущего ключа, это приводит к созданию новой записи спутника, описывающей измененный контекст ведущего ключа (Таблица 4.6).

Таблица 4.6 Данные спутника в SatConnection с ведущим ключом

Ведущий ключ связывает разные хеш-ключи между собой, как показано в связи в Таблице 4.5.

Без концепции ведущего ключа записи концентраторов были бы полностью независимыми друг от друга. Спутниковые записи зависели бы от этих независимых записей связи, не имея между собой никакой связи.

Используя ведущий ключ, спутниковые записи получают взаимосвязь, а записи связи в LinkConnection объединяются. Определение связанных записей связи выполняется с использованием информации о ведущем ключе.

Результатом этой взаимосвязи является то, что первая запись для connection hash key 28db… получает дату окончания, установленную как дата загрузки следующей записи (минус одна секунда или меньше).