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

Аннотация

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

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

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

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

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

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

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

РИСУНОК 4.1. Дорожная сеть США: случайная сеть

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

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

РИСУНОК 4.2. Авиационная сеть США: сеть без масштаба

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

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

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

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

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

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

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

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

Мы подробнее рассмотрим типы сущностей в следующих разделах.

Хаб-сущности

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

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

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

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

Линк-сущности

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

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

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

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

РИСУНОК 4.3. Линк, соединяющий три хаба (логический дизайн)

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

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

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

Саттелит-сущности

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

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

РИСУНОК 4.5 Саттелиты на хабах и линках (логический дизайн)

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

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

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

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

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

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

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

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

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

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

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

РИСУНОК 4.7 Хаб Data Vault (логический символ)

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

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

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

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

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

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

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

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

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

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

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

Мы представили идентификационные номера транспортных средств (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-кубы, документация программного обеспечения

Область действия бизнес-ключей

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

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

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

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

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

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

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

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

Разница между бизнес-ключами и суррогатными ключами

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

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

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

Структура хаба

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

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

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

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

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

Хеш-ключ

Запросы к финальной модели 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-базы.
• Они кроссплатформенные и могут быть восстановлены (один и тот же бизнес-ключ всегда генерирует один и тот же хеш-ключ, если расчет выполнен корректно).
• Хотя соединения по хеш-ключам могут быть медленнее, чем по целочисленным порядковым номерам, их преимущества перевешивают недостатки.

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

Бизнес-ключ

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Дата загрузки

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

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

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

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

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

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

Источник записи

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

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

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

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

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

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

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

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

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

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

Такой метод называется полной загрузкой (full load).
Операционным командам и разработчикам приложений часто проще его реализовать.
Определение удаленных данных в полной загрузке
Чтобы определить удаленные данные при полной загрузке, ETL-процесс должен:

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

Зачем нужна дата последнего обнаружения
Если источник данных работает таким образом, дата последнего обнаружения (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 отвечает за моделирование транзакций, ассоциаций, иерархий и переопределений бизнес-терминов. В следующих разделах этой главы Data Vault links будут определены более формально.

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.
Это преимущество рассматривается подробнее в следующем разделе.
Гранулярность выражается количеством связанных хабов (или бизнес-ключей) и четко задокументирована.
Подробное обсуждение гранулярности links приведено в разделе 4.4.3.
Поскольку отношения моделируются в 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

Гранулярность links определяется количеством hubs, которые они соединяют.

Каждый раз, когда в link добавляется новый hub,
→ вводится новый уровень детализации.
Чем больше hubs соединяет link,
→ тем тоньше (детальнее) становится гранулярность.
Если в link добавляется новый hub,

это понижает его гранулярность.
Таким образом, links ведут себя аналогично фактам в размерной модели:

Когда в таблицу фактов добавляется новое измерение,
→ гранулярность также понижается.

Изменение гранулярности в production

Если link уже находится в production, но бизнесу нужна другая гранулярность,
есть два варианта рефакторинга модели Data Vault:

1. Изменение существующего link
Можно изменить текущий link и добавить ссылку на новый hub.
Однако это потребует переработки ETL-процессов.
Также нужно определить, как обрабатывать исторические данные в новом link,
→ так как он имеет другую гранулярность.
Это может поставить под угрозу аудируемость данных,
→ потому что исходная система никогда не передавала NULL-значения (Рисунок 4.19).

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

Важно:

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

2. Создание нового link и “закрытие” старого
Лучший вариант — создать новый link для новых данных и «закрыть» старый link.

Закрытие link означает, что в него больше не загружаются новые данные.
Вместо этого новые данные загружаются в новый link.
Когда бизнес строит витрину данных (Information Mart),

он должен определить, как объединять links с разной гранулярностью.
Это сохраняет аудит данных и соответствует бизнес-требованиям.
Обработка старых данных
SQL-запрос в центре рисунка 4.20
→ представляет собой бизнес-правило, описывающее обработку старых данных.
Например, это правило устанавливает для старых данных аэропорт как “неизвестный”,
→ используя хеш-ключ 0 (упрощенный вариант).
Полученная таблица затем используется:
для создания таблицы Business Vault,
или размерности в информационной витрине (Information Mart).

Рисунок 4.20 Пример обработки старых данных в Data Vault

Более подробно этот процесс рассматривается в Главе 14:
“Загрузка размерной информационной витрины”.

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

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

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

Если просто удалить столбец Airplane из старого link,

данные будут утеряны, так как ссылка на hub также исчезнет.
Это худший сценарий для аудируемого хранилища данных.
Такое уменьшение данных работает аналогично оператору GROUP BY без агрегатных функций.

Рисунок 4.22 Снижение уровня детализации (гранулярности)

Обратите внимание на использование SELECT DISTINCT в SQL-запросе.

Link Unit-of-Work

Похожая проблема, связанная с гранулярностью links,
возникает при нарушении “единицы работы” link (unit-of-work).

Что такое Link Unit-of-Work?

Unit-of-Work — это согласованный набор данных,
который связывает ключевые наборы воедино.
Он обеспечивает целостность данных в links Data Vault,
→ сохраняя соответствие между поступающими и хранимыми данными.
Ошибка при разбиении link на несколько мелких links
Иногда моделировщики хранилищ данных
пытаются разделить один link на несколько меньших links
ради нормализации (например, чтобы избежать дублирования данных).

→ Это может привести к потере связности данных.

Таблица 4.1 Пример таблицы исходной системы, которая станет основой для link в Data Vault.

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

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

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

Чтобы проверить, правильна ли эта нормализация,
→ полезно попробовать восстановить исходные данные
из полученных нормализованных таблиц.

→ Результатом денормализации станет Таблица 4.3.

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

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

Это произошло потому, что “единица работы” (unit-of-work) была нарушена
при нормализации данных на предыдущем шаге.

В реляционном моделировании данных эта проблема
известна как “многозначные зависимости” (multivalued dependencies).

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

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

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

Эти атрибуты аналогичны атрибутам хабов и подробно рассмотрены в разделе 4.3.2 данной главы.

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

• Дата последнего обнаружения
• Дата последнего обнаружения также обсуждалась в разделе 4.3.2.

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

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

Хеш-ключ

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

РИСУНОК 4.23 Примеры ссылок Data Vault (физическая модель)

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

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

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

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

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

РИСУНОК 4.24 Сущность спутника Data Vault (физическая модель)
Помимо стандартных метаданных, спутник хранит атрибуты, которые описывают контекст бизнес-объекта или отношения. Для этого атрибуты фиксируют неидентифицирующие бизнес-элементы объектов или отношений. Эти элементы часто известны в исходной системе как описания, текстовые поля или вычисляемые значения.

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

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

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

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

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

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

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

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

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

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

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

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

Так как история данных должна сохраняться, обновлять или изменять данные в спутнике запрещено. Единственным исключением является атрибут Load End Date (дата завершения загрузки) для предыдущей версии данных. В Главе 12, «Загрузка Data Vault», будет показано, как изменять этот атрибут.

Кроме того, в спутник добавляются только те записи из источника, в которых произошло хотя бы одно изменение. Таким образом, спутник работает по принципу delta-driven, что аналогично измерению Type II в размерном моделировании.

Разделение спутников

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

Рекомендуемый подход к разделению данных:

• Сначала по исходной системе (source system).
• Затем по частоте изменений (rate of change).

Разделение по исходной системе

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

Преимущества такого подхода:

• Добавление новых источников данных без изменения существующих спутников.
• Отсутствие необходимости изменять входящие данные, чтобы они соответствовали уже существующей структуре (например, преобразование типов данных, разбиение, объединение, изменение длины или другие манипуляции).
• Сохранение истории исходной системы, обеспечивая возможность аудита. Если спутник содержит данные из нескольких систем, изменение в одной из них создаст новую запись в спутнике. Однако при анализе количества строк будет неочевидно, какая именно система вызвала изменение.
• Максимизация параллельной загрузки данных, так как нет конкуренции (на уровне ввода-вывода или базы данных) за целевой ресурс (спутник). Данные могут загружаться немедленно, без учета поступления данных из других систем (которые также могут пытаться загрузить данные в тот же момент).
• Интеграция данных в режиме реального времени без необходимости объединять их с данными, загружаемыми пакетно. Отсутствие зависимостей между разными системами позволяет не ждать, пока все источники подготовят свои данные одновременно.

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

Разделение по скорости изменений

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

РИСУНОК 4.26 Спутник до обновления информации о пролетённых милях

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

РИСУНОК 4.27 Спутник после обновления информации о пролетённых милях

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

На протяжении всей книги мы будем использовать обе эти практики при загрузке данных в спутники Data Vault.

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

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

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

Эти атрибуты подробно рассматриваются в разделе 4.3.2 этой главы.

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

Родительский хеш-ключ
Дата окончания загрузки
Следующие атрибуты являются необязательными для спутников Data Vault:

Дата извлечения
Хеш-разница
В следующих разделах подробно рассматриваются все эти атрибуты.

Родительский хеш-ключ

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

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

Как уже упоминалось, каждая спутниковая сущность должна зависеть только от одного концентратора или связи.
Спутник не может зависеть более чем от одного концентратора или связи.

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

Дата загрузки

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

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

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

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

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

Для фиксации таких источников используются последовательные номера, аналогичные многоактивным спутникам, которые рассматриваются в главе 5, «Промежуточное моделирование Data Vault 2.0».

Дата окончания загрузки

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

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

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

Хеш-разница

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

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

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

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

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

Дата извлечения

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

При использовании прямого доступа через 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 Offset) для конкретного места меняется дважды в год (когда в регионе аэропорта действует переход на летнее время).
Если бы атрибут GMTOffset хранился в SatAirport, все описательные атрибуты копировались бы в новую строку, даже если описательные данные не изменялись.

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

Ведущий ключ связи

Пример 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… получает дату окончания, установленную как дата загрузки следующей записи (минус одна секунда или меньше).