Перевод 6 Главы — Продвинутое моделирование Data Vault 2.0 — Advanced Data Vault Modeling

Предыдущие переводы

Перевод книги «Building a Scalable Data Warehouse with Data Vault 2.0»

• Перевод 1 Главы — Введение в хранилища данных
• Перевод 2 Главы — Масштабируемая архитектура хранилища данных
• Перевод 3 Главы — Методология Data Vault 2.0
• Перевод 4 Главы — Моделирование Data Vault 2.0 — Что такое Hub / Link / Satellite?
• Перевод 5 Главы – Intermediate Моделирование Data Vault

Аннотация к 6 главе

В этой главе рассматриваются два дополнительных аспекта моделирования Data Vault: вспомогательные таблицы для запросов и справочные таблицы. Вспомогательные таблицы для запросов (Query assistant tables) используются для снижения сложности запросов к Data Vault и повышения производительности. Рассматриваются два конкретных типа вспомогательных таблиц для запросов: point-in-time (PIT) таблицы и bridge таблицы. Также подробно рассматриваются справочные таблицы (reference tables), включая справочные таблицы без истории, справочные таблицы с историей и таблицы с кодами и описаниями.

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

• вспомогательные таблицы для запросов (Query assistant tables)
• справочные таблицы (reference tables)
• point-in-time
• bridge таблицы
• таблицы с описаниями (description tables)

Таблицы Point-In-Time и Bridge объединяет то, что их основное назначение — упростить выполнение запросов к данным из Data Vault, а значит, повысить производительность выполнения запросов. Это особенно важно при использовании виртуальных информационных витрин для предоставления данных бизнес-пользователям.

Таблицы Point-in-Time

Проблема, которая может возникнуть при выполнении запросов к данным из Raw Data Vault, возникает, когда у хаба или связи имеется несколько спутников (см. рисунок 6.1).

РИСУНОК 6.1 Хабы с несколькими спутниками и PIT-лента (логическая структура)

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

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

Таблицы 6.1, 6.2, 6.3 и 6.4 показывают представление данных об обновлениях хаба пассажира и связанных с ним спутников.

---

Все представленные таблицы со спутниками (satellites) относятся к типу Slowly Changing Dimension Type 2 (SCD Type 2).

---

Таблица 6.1 Данные хаба пассажиров

Таблица 6.2 Данные спутника с именем пассажира

Таблица 6.3 Спутник с данными о предпочитаемом блюде

Таблица 6.4 Спутник с адресными данными пассажира

Пример показывает двух пассажиров и изменения в их данных с течением времени. Например, Эми Миллер, вероятно, вышла замуж за мистера Фримана и впоследствии сменила имя на Эми Фриман (см. таблицу 6.2). Она также меняла предпочитаемое блюдо со временем — от вегетарианской еды к мясу и обратно к вегетарианской (см. таблицу 6.3). Оба пассажира переезжали (или, по крайней мере, указывали разные адреса) с течением времени (см. таблицу 6.4).

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

Кроме того, спутники не охватывают все изменения, происходящие в исходной системе. Вместо этого изменения или дельты, захватываемые спутниками, поступают с такой частотой, с какой их поставляют источники. Спутники отслеживают только те изменения, которые доставляются в хранилище данных. Если хранилищу данных необходимо сохранять все изменения, происходящие в исходной системе, то исходная система должна предоставлять журнал аудита, например, такой, какой создаётся Microsoft SQL Server 2014 с включённой функцией Change Data Capture (CDC).

Другой вариант — предоставить данные в режиме реального времени с использованием Enterprise Service Bus (ESB) или Message Queue (MQ). Если эти опции не используются, загружаются только те изменения, которые входят в выгрузки из источника. Например, если пакетная загрузка выполняется каждые шесть часов, то дельты в спутниках будут отслеживать запись такой, какой она была каждые шесть часов.

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

Для достижения этой цели требуется использование OUTER JOIN-запросов с обработкой сложных диапазонов времени. При наличии более трёх спутников на хабе или связи это становится сложно и медленно. Лучше использовать equal-join-запросы для извлечения данных из Raw Data Vault. Для этого в моделировании Data Vault используется специальный тип сущности: point-in-time таблицы (PIT) и набор фиктивных записей в спутниковых таблицах, привязанных к фиксированным первичным ключам.

---

Equal-join-запросы — это тип SQL-запросов, при которых объединение таблиц происходит по условию равенства значений в связанных столбцах. Чаще всего используются в операциях INNER JOIN, LEFT JOIN, и других видах JOIN, когда связываются строки из разных таблиц с одинаковыми значениями в указанных столбцах.

---

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

Структура таблицы Point-in-Time

Структура Point-In-Time — это вспомогательная структура для запросов, ориентированная на производительность запросов. Следует рассматривать структуру PIT как часть слоя Business Vault или информационной витрины. Таким образом, структура может быть изменена, чтобы включать вычисляемые столбцы при необходимости для достижения максимальной производительности запросов.

Для достижения этой цели PIT-таблица создаёт снимки данных на даты, заданные потребителями данных выше по потоку. Например, некоторым компаниям требуется текущее состояние данных каждый день, другим — каждую секунду. Для удовлетворения этих требований PIT-таблица включает дату и время снимка в комбинации с PassengerHashKey в качестве уникального ключа сущности. Для каждой такой комбинации PIT-таблица содержит даты загрузки и соответствующие хэш-ключи из каждого спутника, которые наилучшим образом соответствуют дате снимка. Физическое представление PIT-таблицы для примера из предыдущего раздела показано на рисунке 6.2.

РИСУНОК 6.2 Физическая PIT-таблица для пассажира (физическая структура)

Каждая запись в таблице point-in-time идентифицируется хэш-ключом. Это хэш-значение может использоваться далее при загрузке Type 2 измерений информационной витрины. После заполнения PIT-таблицы из предыдущего примера данными она будет выглядеть, как таблица 6.5.

Таблица 6.5 Представление данных PIT-таблицы для пассажира

Как показано на рисунке, должна быть по одному столбцу с датой загрузки для каждого доступного спутника. Для каждой комбинации PassengerHashKey и SnapshotDate приводятся соответствующие даты загрузки по каждому спутнику.

Кроме того, хэш-ключ копируется из спутника. В большинстве случаев это значение будет совпадать со значением хэш-ключа в идентифицирующем ключе (в этом примере — PassengerHashKey). Однако в некоторых случаях соответствующая запись в спутнике для заданной даты снимка отсутствует: либо бизнес-ключ не был известен исходной системе на момент указанной даты снимка, либо он был удалён из исходной системы. В PIT-таблице, показанной в таблице 6.5, это соответствует записи номер 1. В отличие от спутника, хранящего имена пассажиров, спутники Preferred Dish и Passenger Address не содержат записи на дату снимка 1995-01-01. Если исходная система не предоставляет соответствующую запись, PIT-таблица должна ссылаться на неизвестную запись. В моделировании Data Vault 2.0 такая запись называется ghost-записью. Эта запись должна быть добавлена в каждый спутник (таблица 6.6).

Таблица 6.6 Спутник с данными о пассажирах с использованием ghost-записи

Преимущество этой записи заключается в том, что она является допустимой во все моменты времени (то есть содержит самую раннюю дату загрузки и самую позднюю дату окончания загрузки, доступные для выбранного типа данных). Источник записи установлен как SYSTEM, чтобы указать, что запись создана искусственно. PIT-таблица из таблицы 6.5 будет модифицирована путём замены ссылок NULL на ссылки на ghost-запись в спутниковой таблице (таблица 6.7).

Таблица 6.7 Представление данных PIT с ссылками на ghost-записи

NULL-значения из предыдущей версии этой PIT были заменены ссылками на ghost-запись в каждом спутнике. Обеспечив наличие ghost-записи в каждом спутнике, на который ссылается PIT-таблица, становится возможным использовать Equal-join вместо outer join при извлечении данных из неё. Поскольку ссылки на спутники в PIT-таблице больше не содержат значений NULL, их не нужно обрабатывать отдельно.

PIT-таблица не содержит других системно-сгенерированных атрибутов, таких как источник записи. Это связано с тем, что данные создаются системой и не имеют собственного источника записи или даты загрузки. Однако возможно добавление дополнительных вычисляемых атрибутов по необходимости. Например, можно добавить дату окончания загрузки, чтобы поддерживать запросы с использованием оператора BETWEEN. Другие атрибуты могут предоставлять агрегации или вычисления для дальнейшего повышения производительности запросов. Однако следует уделить особое внимание ширине PIT-таблицы. Если она станет слишком широкой, производительность снова снизится, и преимущество PIT-таблицы будет утрачено. Эта рекомендация особенно важна для Microsoft SQL Server 2014, поскольку он поддерживает только страницы базы данных размером 8 КБ. Если серверы баз данных поддерживают страницы размером более 32 КБ и соответствующий размер блока на уровне физического хранилища, это снижает указанную проблему.

Для поддержания высокой производительности PIT-таблиц есть две рекомендации. Первая — включить сжатие на уровне базы данных. Microsoft SQL Server поддерживает сжатие данных в таблицах базы данных.

Сжатие данных в таблице имеет несколько преимуществ:

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

Однако сжатие данных также требует больше ресурсов CPU для сжатия и распаковки данных.

Второе решение для поддержания высокой производительности PIT-таблиц — удаление неиспользуемых снимков.

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

Управляемое PIT-окно (PIT Window)

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

На рисунке 6.3 PIT-таблица сохраняет историю только за последние три месяца и удаляет все снимки, которые старше этих трёх месяцев. Наличие старых, неиспользуемых данных в PIT-таблицах снижает производительность запросов, если не выполнена дополнительная оптимизация, такая как партиционирование таблицы. Необходимо, чтобы бизнес определил, какую часть старых снимков следует сохранять в PIT-таблицах, и, следовательно, сделать доступными в виртуальных измерениях. Фактически, это «определение старых данных» указывается по-разному для каждой PIT-таблицы.

РИСУНОК 6.3 Управление PIT-окном

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

РИСУНОК 6.4 Снимки логарифмической PIT-таблицы

Все снимки за текущий месяц сохраняются. Кроме того, по одному снимку в неделю хранится за текущий год. После этого PIT-таблица сохраняет только один снимок в месяц, но только за последние пять лет. Более старые данные удаляются. Такая таблица представляет собой компромисс между потреблением хранилища и производительностью запросов. Это позволяет относительно просто выполнять запросы к более старым данным. Если потребуются дополнительные снимки, их можно пересоздать с использованием того же алгоритма, который использовался ранее.

Bridge Tables

Существует ещё один тип вспомогательных таблиц для запросов в стандарте Data Vault 2.0 — bridge-таблица (соединительная таблица). Подобно PIT-таблицам, их цель — повысить производительность запросов к Raw Data Vault за счёт сокращения количества необходимых соединений (joins) в запросе.

Они также являются частью Business Vault, поскольку данные в bridge-таблицах создаются системой и не подлежат аудиту по этой причине. Bridge-таблицы следует создавать только в том случае, если запросы к Raw Data Vault испытывают проблемы с производительностью.

В отличие от PIT-таблиц, которые охватывают несколько спутников хаба или линка, bridge-таблица охватывает несколько хабов и линков. Таким образом, она схожа со специализированной link-таблицей. Она не содержит никакой информации из спутников, в основном потому, что ширина таблицы стала бы слишком большой. На рисунке 6.5 показана логическая модель bridge-таблицы в Data Vault 2.0.

РИСУНОК 6.5 Bridge-таблица для повышения производительности запросов к данным о пассажирах (логический дизайн)

В приведённом выше сценарии имеются данные о пассажирах, связанных с агентом по продажам через Booking-link. Спутники используются для большинства хабов и линков в этом примере. Bridge-таблица Passenger Bridge не охватывает Flight и Airline. Модель не показывает бизнес-ключи или другие атрибуты, являющиеся частью сущностей Data Vault. Bridge-таблица действует как более высокий уровень факт-таблицы без фактов (fact-less fact table) и содержит hash-ключи хабов и линков, которые она охватывает.

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

Bridge-таблицы не обязаны иметь ту же степень детализации (grain), что и link-таблицы, которые они охватывают. В таких случаях bridge-таблица может содержать агрегированные значения, которые добавляются в структуру и загружаются с помощью операторов GROUP BY. В результате bridge-таблица имеет более высокий уровень агрегации (grain), чем линк-таблицы, включённые в неё. Таким образом, bridge-таблица становится очень похожей на exploration link.

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

Структура Bridge-таблицы

Bridge-таблица содержит все hash-ключи из хабов и линков, которые являются частью bridge-таблицы, а также дату снимка и hash-ключ для каждой записи. Бизнес-ключи, вычисляемые или агрегированные поля — опциональны. На рисунке 6.6 показан пример bridge-таблицы.

РИСУНОК 6.6 Физический дизайн bridge-таблицы (физическая структура)

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

Таблица 6.8 Информация из bridge-таблицы

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

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

Сравнение PIT-таблиц и bridge-таблиц

Хотя PIT-таблицы и bridge-таблицы служат одной цели — помогают выполнять запросы к Raw Data Vault, между ними есть различия. PIT-таблицы относятся только к одному хабу или линку. Они используются для создания снимка дат загрузки спутников. Для этого они сохраняют только hash-ключ хаба (или линка) и даты загрузки соответствующих спутников, а также дату снимка самой PIT-таблицы. Можно добавить дополнительные вычисляемые атрибуты, такие как бизнес-ключ хаба, что является распространённой практикой.

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

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

Справочные таблицы (Reference Tables)

Следующие разделы описывают другой тип сущностей, который не является частью основной архитектуры, но часто используется в Data Vault.

Мы представили хаб в главе 4 как уникальный список бизнес-ключей, идентифицирующих объекты, которые используются в бизнесе. Однако в корпоративных данных существует больше ключей и кодов, которые не обязательно являются бизнес-ключами, поскольку они не ссылаются на бизнес-объекты. Например, ISO-коды стран, такие как USA для Соединённых Штатов или DEU для Германии — это коды, которые используются в бизнесе, но сами страны не рассматриваются как бизнес-объекты внутри организации. Вместо этого они используются как описательные справочные данные, обозначающие определённое состояние информации. В случае кодов стран ISO-код может описывать страну, где была совершена продажа. Это описание обычно включает официальное название страны и другую описательную информацию, такую как континент или столица. Часто эти справочные данные не контролируются организацией, а поддерживаются внешними структурами. С другой стороны, тот же самый код страны может быть бизнес-ключом в другой организации, например, в Организации Объединённых Наций (ООН).

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

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

Справочные таблицы без истории (No-History Reference Tables)

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

Типичные примеры включают:

• Коды и описания медицинских препаратов по рецепту
• Биржевые символы
• Коды медицинских диагнозов
• Коды и описания VIN-номеров (например, коды производителей)
• Календарные даты
• Календарное время
• Международные коды валют
• Сокращения кодов штатов США

Следует отметить, что всё зависит от конкретного проекта: например, в некоторых странах (в отличие от США) могут происходить частые изменения кодов медицинских диагнозов — по разным причинам.

Простая справочная таблица без истории не содержит полей begin-date и end-date, поскольку данные не меняются. Поэтому структура таблицы очень простая, как показано на рисунке 6.7.

РИСУНОК 6.7 Логическая модель справочной таблицы без истории для календаря

Эта логическая модель показывает справочную таблицу для хранения простого календаря в Business Vault. Данные идентифицируются по ключу Date, который представляет собой поле типа Date в базе данных. Другие атрибуты в этом примере — Year, Month и Day, которые хранят соответствующие целые числа. Day of Week — это текстовое представление дня недели, например, «Monday».

Нет необходимости хранить историю изменений, поскольку в большинстве бизнесов отслеживать это не требуется. Это не означает, что данные в этой структуре не могут меняться. Однако большинство изменений — это исправления ошибок или обновления, которые должны быть отражены во всех витринах данных, включая исторические данные. Примеры таких изменений включают переводы значения Day of Week или его сокращения. На рисунке 6.8 представлена ER-модель этой справочной таблицы.

РИСУНОК 6.8 Физическая модель справочной таблицы без истории для календаря

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

Таблица 6.9 «Календарные данные в справочной таблице без истории» показывает пример данных из календарной справочной таблицы:

В этом примере снова используется атрибут RecordSource, поскольку данные поступают из Master Data Services (MDS). Если пользователь изменяет данные в MDS, это перезаписывает содержимое справочной таблицы, так как история изменений не отслеживается. В других случаях данные могут не поступать ниоткуда извне — тогда поля LoadDate и RecordSource не нужны. Тем не менее, хорошей практикой считается брать данные из аналитического мастер-данных источника, так как это позволяет бизнес-пользователям редактировать данные без участия IT. Это является предпосылкой для управляемой самостоятельной аналитики (managed self-service BI).

После создания справочной таблицы в модели, её можно интегрировать в остальную модель, используя первичный ключ справочной таблицы там, где это уместно: чаще всего — в спутниках, но также и в сущностях Business Vault. На рисунке 6.9 показан типичный случай использования, когда спутник на хабе Passenger ссылается на первичный ключ справочной таблицы.

РИСУНОК 6.9 Спутник со справочными данными (логическая модель)

Спутник Address ссылается на справочную таблицу State через почтовые аббревиатуры штатов США (USPS). Таким образом, справочник указывает на наличие более описательной информации о штате в справочной таблице. Благодаря этому не теряется читаемость в спутнике, и при этом сохраняется базовый принцип использования сущностей Data Vault.

Справочные таблицы с историей (History-Based Reference Tables)

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

Подход Data Vault к этой задаче заключается в добавлении стандартных спутников к справочной таблице, представленной в предыдущем разделе. В то время как базовая таблица содержит только неисторизированные атрибуты, спутник хранит справочные данные, требующие истории. Рисунок 6.10 показывает расширенную версию справочной таблицы из предыдущего раздела. Она дополнена спутником Fiscal Calendar, который добавляет два историзируемых атрибута к справочной таблице: Fiscal Year и Fiscal Quarter. Благодаря их историзации бизнес получает возможность изменять эти данные в будущем или учитывать изменения в прошлом. Это может быть необходимо, если, например, две организации с разными фискальными календарями объединились, и бизнесу нужно работать с историческими отчётами.

РИСУНОК 6.10 Справочная таблица с историей для календаря (логическая модель)

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

Рисунок 6.11 показывает физическую модель, полученную из логической модели на рисунке 6.6.

РИСУНОК 6.11 Физическая модель историзируемого календаря с использованием спутника Data Vault (физическая модель)

Спутник SatFiscalCalendar присоединяется к справочной таблице через её первичный ключ Date. Мы не используем хешированную версию ключа ради читаемости справочной таблицы. Если бы мы предпочли использовать хеш Date, это потребовало бы его использования в качестве первичного ключа, что, в свою очередь, повлияло бы на использование справочной таблицы. В остальном спутник очень похож на стандартные спутники Data Vault 2.0 — особенно это касается использования LoadDate в первичном ключе и LoadEndDate для задания окончания срока действия записей спутника.

Коды и описания (Code and Descriptions)

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

Например, FAA (Федеральное авиационное управление США) использует коды операций, представленные в таблице 6.10, для классификации воздушных судов по предполагаемому назначению:

Таблица 6.10 Список стандартных кодов операций FAA

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

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

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

РИСУНОК 6.12 Таблица справочных кодов и описаний (логическая модель)

Рисунок 6.12 показывает минимальную справочную таблицу для кодов и описаний. Обычно в такой таблице присутствуют дополнительные описательные атрибуты, например:

• Краткое описание (Short description): используется в диаграммах и других графиках, поскольку в столбчатых, круговых и прочих диаграммах имеется ограниченное место для подписей.
• Порядок сортировки (Sort order): большинство справочных данных не сортируются в алфавитном порядке при использовании в отчётах. Вместо этого бизнес хочет самостоятельно определять порядок вывода записей в измерениях.
• Внешняя ссылка (External reference): часто это URL-адрес, где можно найти больше информации о записи справочных данных. Полезно для интеграции справочных данных с Wiki в корпоративной сети.
• Владелец (Owner): указывает функциональное подразделение, ответственное за поддержание записи.
• Комментарий (Comment): произвольный текст, описывающий запись справочных данных для бизнес-пользователя, который её обслуживает.

ER-модель справочной таблицы кодов и описаний представлена на рисунке 6.13.

РИСУНОК 6.13 Справочная таблица кодов и описаний (физическая модель)

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

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

Данные FAA, представленные в таблице 6.10, будут храниться в физической таблице, как показано в таблице 6.11.

Таблица 6.11 Таблица кодов и описаний

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

Существует два варианта использования справочной таблицы кодов и описаний в спутниках. Возможно использовать составной первичный ключ, состоящий из атрибутов Group и Code, как внешний ключ (с обеспечением ссылочной целостности или без неё) в спутнике. Или, если внешние ключи не используются в модели, можно использовать только атрибут Code в спутнике и определять Group неявно через атрибут спутника. Это означает добавление жёстко заданных фильтров в предложения WHERE при получении или объединении данных для их разрешения. Это допустимая практика — модель при этом «типизирует» коды и описания, позволяя всем кодам существовать в обобщённой таблице на уровне подтипа. Однако второй подход требует документации, чтобы понимать, какая Group соответствует какому атрибуту спутника, без необходимости анализа кода из виртуальных фактов и измерений или ETL-кода.

Коды и описания с историей (Code and Descriptions with History)

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

РИСУНОК 6.14 Справочная таблица кодов и описаний со спутником для отслеживания истории (логическая модель)

Как видно на рисунке, эта концепция снова основана на использовании спутника, который хранит атрибуты, требующие отслеживания истории. В этом примере это Short Description и Long Description. Если есть атрибуты, для которых не нужно хранить историю, их можно добавить в саму справочную таблицу. Атрибут Sort Order следует именно такому подходу.

ER-диаграмма таблицы кодов и описаний с историей представлена на рисунке 6.15.

РИСУНОК 6.15 Справочная таблица кодов и описаний со спутником для отслеживания истории (физическая модель)

Наличие составного первичного ключа в справочной таблице требует, чтобы спутник ссылался на оба атрибута первичного ключа. Атрибуты, не требующие отслеживания истории — в данном случае SortOrder — добавляются в родительскую таблицу, а атрибуты, по которым нужна история, — в спутник. Атрибуты ShortDescription и LongDescription являются такими полями.