ГЛАВА 5 – Intermediate Моделирование Data Vault
Вспомним про структуру Data Vault и ключевые термины
Этот раздел не является частью книги, он содержит краткую выдержку по структуре Data Vault (для того, чтобы освежить в памяти структуру DV и основные термины).
Структура Data Vault
- Raw Data Vault — это сырой слой данных, где хранятся исходные данные:
- HUB — таблица, содержащая связку бизнес-ключа сущности и суррогатного ключа хранилища
- LINK — таблица связей сущностей по суррогатным ключам
- SAT — таблица атрибутов сущности
- Business Vault — содержит бизнес-правила и преобразования, применяемые к исходным данным:
- SAL — таблицы унификации ключей сущности
- PIT — таблица расчета полной истории сущности (опционально)
- Bridge/Calculation tables — таблицы с любыми видами расчетов
- Information Mart / Data Mart — это аналитический слой данных. Он предназначен для построения отчётов и визуализации данных для пользователей.
- Генерация ключей
- Sequence — надежно и синхронно
- Hash — коллизии и ассинхрон (шанс коллизии у md5 50% на 2^64 записей). Используем hash, если у вас нет явных требований на 100% точность в DWH. А если они есть, переубеждаем тех, кто их поставил.
Пример связей между таблицами:
Презентация с конференции SmartData 2024 Data Vault.
Переводы 1-4 глав книги по Data Vault 2.0:
- Перевод 1 Главы — Введение в хранилища данных
- Перевод 2 Главы — Масштабируемая архитектура хранилища данных
- Перевод 3 Главы — Методология Data Vault 2.0
- Перевод 4 Главы — Моделирование Data Vault 2.0 — Что такое Hub / Link / Satellite?
Аннотация к главе 5
В этой главе рассматриваются более сложные сущности Data Vault. Они расширяют базовые сущности. Здесь будут затронуты различные специальные типы спутников (Satellite), включая:
- перегруженные спутники (Overloaded Satellites),
- мультиактивные спутники (Multi-Active Satellites),
- спутники отслеживания статуса (Status-Tracking Satellites),
- спутники актуальности (Effectivity Satellites),
- спутники отслеживания записей (Record Tracking Satellites) и
- вычисляемые спутники (Computed Satellites).
Также рассматриваются расширенные сущности связей, включая связи между связями (link-to-link), связи «same-as» (same-as links), иерархические связи, неисторические связи (nonhistorized links), недескриптивные связи, вычисляемые агрегатные связи и исследовательские связи.
Для каждой сущности связи будет объяснена техническая или бизнес-причина её добавления в Data Vault.
Ключевые слова:
- хранилище данных
- data vault
- спутники
- сущности связей
- моделирование данных
Типы сущностей, представленные в предыдущей главе, являются основой для других сущностей Data Vault, представленных в этой главе. Многие из этих примеров — это просто применения существующих сущностей связи или спутников без изменения структуры самой сущности. Они часто используются в Business Vault.
Применение хабов
Глава 4, Моделирование Data Vault 2.0, представила хабы Data Vault как центральные сущности, используемые для хранения бизнес-ключей, идентифицирующих бизнес-объекты. В теории в предприятии должна быть одна ведущая операционная система, отслеживающая конкретный бизнес-объект.
Системы управления взаимоотношениями с клиентами (CRM) являются хорошими примерами таких операционных систем, которые являются основным источником всей информации, связанной с клиентами. Однако на практике бизнес-объекты, такие как клиенты, хранятся в нескольких операционных системах, например, в ритейл-базах данных, e-commerce приложениях, системах управления счетами и так далее. Предприятия пытаются консолидировать эту информацию с помощью концепции, называемой управлением мастер-данными (master data management).
На Рисунке 5.1 показано, что все данные, включая бизнес-ключи, сначала загружаются в слой Data Vault через staging-область. Консолидация происходит при обработке сложных бизнес-правил и построении витрин данных (information marts). Специалисты по хранилищам данных сталкиваются с множественными источниками для одного и того же бизнес-объекта.
Основная проблема при наличии нескольких источников заключается в том, что каждый из них имеет различные возможности по определению бизнес-объекта. Это связано с тем, что в момент создания этих систем в прошлом бизнес выдвигал к ним разные требования. В результате даже типы данных бизнес-ключей могут отличаться: в некоторых случаях буквенно-цифровой номер клиента (например, US4317 для клиента из США), определённый на уровне предприятия, не может быть использован в другой операционной системе, поскольку она не допускает буквенные символы в номере клиента. В таком случае бизнес будет полагаться на какие-либо маппинговые таблицы, которые отображают клиента US4317 из CRM-системы в клиента 132842 в e-commerce приложении.
Рисунок 5.1 Консолидация различных источников в хранилище данных
Поскольку такая ситуация встречается чаще всего, в Data Vault предусмотрено решение. Рекомендуемая практика — загружать все бизнес-ключи, независимо от их конкретного формата, в один общий хаб (в данном случае — хаб клиентов) и создавать специальную связь, называемую same-as link (SAL), чтобы указать бизнес-ключи, которые идентифицируют один и тот же бизнес-объект.
Консолидация бизнес-ключей
Business Vault представляет собой расширение Data Vault RAW и позволяет разработчикам хранилищ данных добавлять вычисляемые данные в слой Data Vault. В этой главе будут представлены вычисляемые агрегатные связи (computed aggregate links), исследовательские связи (exploration links) и вычисляемые спутники (computed satellites) в качестве примеров типов сущностей, входящих в состав Business Vault. Эти типы сущностей моделируются аналогично основным сущностям Data Vault, следуя концепциям моделирования Data Vault, особенно для связей и спутников.
Тем не менее, каждую стандартную сущность Data Vault можно кастомизировать в соответствии с потребностями организации. Эти модификации, которые становятся частью Business Vault, получают данные из стандартных сущностей сырого (RAW) Data Vault (хабы, связи и спутники) и часто оптимизируются для повышения производительности при выполнении запросов к данным в Data Vault.
Распространённый вариант использования — консолидация бизнес-ключей из различных источников, как показано в Таблицах 5.1 и 5.2 и на Рисунке 5.2.
Таблица 5.1 Хаб «Пассажир»
| Passenger HashKey | Load Date | Record Source | Passenger Number |
|---|---|---|---|
| 8473d2a… | 2014-06-26 | DomesticFlight | 1234 |
| 9d8e72a… | 2014-06-26 | DomesticFlight | 1257 |
| 1a4e2c2… | 2014-06-26 | InternationalFlight | C21X9 |
| 238aaff… | 2014-06-26 | InternationalFlight | C43Z8 |
Таблица 5.2 Same-as-Link для пассажира
| SALPassenger HashKey | Load Date | Record Source | Master Passenger HashKey | Duplicate Passenger HashKey |
|---|---|---|---|---|
| 38dfa8… | 2014-06-26 | Dedupe | 238aaff… | 8473d2a… |
| 937aae… | 2014-06-26 | Dedupe | 1a4e2c2… | 9d8e72a… |
Рисунок 5.2 Хаб со структурой Same-as-Link (SAL) для устранения дубликатов бизнес-ключей пассажиров
В данном случае в сыром Data Vault существует хаб (hub) Passenger, получаемый из нескольких исходных таблиц, содержащих номера пассажиров. Во многих организациях используются исходные системы, которые не интегрированы между собой. В результате один и тот же пассажир может присутствовать в нескольких операционных системах с разными идентификаторами (например, номер водительского удостоверения или номер паспорта). Ещё одной причиной данной проблемы является поддержка различными системами разных форматов для одного и того же бизнес-ключа.
В этом примере исходная система Domestic Flight допускает (и использует) только числовые номера водительских удостоверений, в то время как система International Flight допускает буквенно-цифровые бизнес-ключи. Такая ситуация далека от идеальной, но часто возникает, когда две организации объединяются и продолжают использовать свои старые системы без должной интеграции.
Проблема решается путём добавления к хабу структуры Same-as-Link (SAL), которая указывает, какие номера клиентов соответствуют одному и тому же клиенту. Существует несколько способов вычислить записи для Same-as-Link, и они могут быть результатом алгоритмов дедупликации клиентов, как в данном примере. Соответствующая диаграмма «сущность-связь» (ER-диаграмма) представлена на Рисунке 5.3.
Рисунок 5.3 ER-диаграмма структуры Same-as-Link для устранения дубликатов бизнес-ключей пассажиров (физическая модель)
Этот подход, основанный на Same-as-Link и хабе с единственным бизнес-ключом, работает только в том случае, если диапазоны значений ключей в обеих системах не пересекаются. Если же они пересекаются, один и тот же бизнес-ключ может идентифицировать разные бизнес-объекты в разных системах. Вместо того чтобы использовать один хаб для всех бизнес-ключей из всех исходных систем в сыром Data Vault, существует два варианта решения этой ситуации.
Во-первых, можно расширить хаб, добавив ещё один бизнес-ключ, идентифицирующий систему-источник. Этот искусственный ключ становится частью составного бизнес-ключа хаба. Недостатком этого решения является то, что оно не приводит к интеграции исходных систем.
Другой вариант — создать несколько хабов и связать их между собой с помощью таблицы связей (link). Это решение документирует различное использование бизнес-ключей в модели, но требует создания большего числа сущностей в сыром Data Vault.
С точки зрения моделирования оба решения далеки от идеала, но они отражают реальное использование бизнес-ключей в системах-источниках и бизнес-практиках. Однако в обоих случаях это правильный подход, поскольку моделирование в Data Vault 2.0 ориентировано на бизнес. Если организация использует неидеальные методы ведения бизнеса, это также должно быть отражено в модели Data Vault.
Когда данные трансформируются в Business Vault, всё ещё возможно объединить бизнес-ключи в одном бизнес-хабе, включая структуру Same-as-Link, как показано на Рисунке 5.3. На самом деле, Same-as-Link является сущностью Business Vault, при условии, что информация не извлекается напрямую из системы-источника, а поддерживается вручную или с помощью алгоритмов. Однако если бизнес-ключи объединяются в бизнес-хаб, они не должны пересекаться и должны идентифицировать только один бизнес-объект. Это соответствует стандарту Data Vault 2.0 и может быть достигнуто с помощью префиксов или постфиксов (или форматирующих элементов) для бизнес-ключей, которые не поступают из ведущей системы-источника.
Например, если ведущей системой является CRM-приложение и оно не предоставляет бизнес-ключ для конкретного бизнес-объекта, идентифицирующий бизнес-ключ берётся из вторичной системы-источника и загружается в бизнес-хаб. Примером такой вторичной системы может быть система тикетов (ticketing), где клиент был добавлен, но никогда не синхронизировался и не реплицировался в CRM-приложение. Чтобы указать на этот неидеальный случай и избежать путаницы, бизнес-ключ из ticketing-системы заключают в скобки, например, “(4711)”. Этот бизнес-ключ затем используется в аналитических отчётах, и бизнес-пользователю становится очевидно, что ключ не из CRM-системы и его там не найти. Также возможно добавлять к ключу имя системы-источника, например, “(TCK:4711)”, чтобы пользователь знал, откуда поступил данный ключ.
Запросы к таким двум таблицам в некоторых случаях могут быть довольно сложными. Кроме того, в большинстве случаев бизнесу требуется консолидированный вид клиентских номеров, а не сырые данные — за исключением случаев анализа качества данных. Поэтому целесообразно предоставить консолидированный список, получаемый в результате сложного запроса, в виде нового материализованного хаба. Этот хаб имеет ту же структуру, что и хаб в сыром Data Vault, но содержит другие данные. Таким образом, утверждение из начала этого раздела остаётся верным: в Business Vault нет специальной сущности типа «хаб». Однако логично создавать хабы Business Vault, чтобы предоставлять разные наборы бизнес-ключей и улучшать последующую выборку данных. В этом случае атрибут record source изменяется на “SYSTEM” или “SYS”, чтобы указать, что значение было сгенерировано системой хранилища данных.
Этот пример является типичным случаем, когда бизнес-правила применяются в Business Vault. Хотя бизнес-правила обычно реализуются при загрузке витрин данных, хорошей практикой является их реализация в Business Vault, если они используются более чем в 80% отчётов или если их выполнение требует значительных ресурсов. В данном случае «heavy lifting» означает долгие по времени или сложные бизнес-правила. Таким образом можно избежать повторной реализации бизнес-правил для каждой витрины данных. Это становится особенно важным в случае сложных и ресурсоёмких правил, которые используются в нескольких витринах.
Глава 6, Продвинутое моделирование Data Vault, рассматривает ещё две сущности Business Vault (таблицу PIT и таблицу bridge), которые используются для упрощения запросов к данным из сырого Data Vault и повышения производительности запросов. По этой причине они также называются query assistant tables (вспомогательные таблицы для запросов).
Применение связей (Link Applications)
В следующих разделах представлены распространённые структуры связей и сценарии их применения, которые специалисты по Data Vault часто используют в своих проектах.
Link-on-link
Один из часто задаваемых вопросов на этапе проектирования Data Vault — возможно ли создание связей, которые ссылаются на другие связи (так называемые структуры link-on-link).
Рассмотрим пример отклонения рейса в авиационной отрасли. Вместо того чтобы прибыть в исходный аэропорт, рейс перенаправляется из-за неблагоприятных погодных условий или инцидента, связанного с безопасностью. Первая идея по моделированию этой ситуации в Data Vault представлена на логической схеме на рисунке 5.4.
Рисунок 5.4 Логическая модель Data Vault с link-on-link структурой
Связь в центре модели LinkFlight представляет собой исходную информацию о рейсе, запланированную авиаперевозчиком. Каждый рейс имеет исходный и конечный аэропорт (поэтому LinkFlight связан дважды с HubAirport), а также ссылку на номер рейса и номер борта. Обратите внимание, что на схеме не показаны спутники.
Отклонение рейса моделируется как ещё одна связь — LinkDiversionFlight. Она ссылается на исходный рейс в LinkFlight и добавляет ссылку на новый аэропорт прибытия. Хотя эта модель выглядит достаточно эффективной, она вводит нежелательную зависимость между двумя связями. Такая зависимость плохо масштабируется и не обеспечивает должной производительности в условиях высоких объёмов и скоростей обработки данных (big data).
Чем больше подобных link-to-link структур необходимо обработать на уровне СУБД, тем более экспоненциальным становится объём работы для неё. Для обеспечения гибкости и масштабируемости с большими объёмами данных модель необходимо перепроектировать на раннем этапе.
Функциональность, необходимая бизнес-пользователю, поставляется итеративно в рамках отдельных спринтов. Цель — поставлять небольшие инкременты хранилища данных и внедрять эти изменения в продакшн по завершении каждого спринта. Проблема с link-to-link структурами в том, что изменение родительской связи (в данном случае LinkFlight) требует изменения всех зависимых дочерних связей (например, LinkDiversionFlight).
Такие каскадные изменения увеличивают время, необходимое на модификацию компонентов хранилища данных по запросу на изменение, и могут не позволить завершить внедрение запроса в рамках одного спринта. Следовательно, подобные связи следует избегать для сохранения гибкости команды ИТ. Рекомендуемая практика — отказаться от ссылок между связями и реализовать связи независимо (см. рисунок 5.5); в кругах моделирования данных это известно как денормализация.
Рисунок 5.5 Логическая модель с независимыми связями
Теперь каждая связь является независимой и может изменяться отдельно в случае необходимости изменений в её структуре в будущем.
Same-as Links (SAL)
Same-as-Link используются для указания на дублирующиеся бизнес-ключи внутри сущности хаба в Data Vault. Это необходимо в случаях, когда один и тот же бизнес-объект идентифицируется несколькими бизнес-ключами.
Например, в таблице 5.3 представлен фрагмент списка клиентов, загруженного из различных источников.
Таблица 5.3 Хаб клиентов (Customer Hub)
| # | CustomerHashKey | LoadDate | RecordSource | CustomerNo |
|---|---|---|---|---|
| 1 | b7b0a554b9… | 2014-01-17 08:20:15.000 | CRM | DE4711 |
| 2 | dd2c1f2d8d… | 2014-01-17 08:20:15.000 | CRM | US4317 |
| 3 | e138c1d3c9c… | 2014-01-17 08:20:15.000 | CRM | UK8876 |
| 4 | d1360901d7… | 2014-01-17 09:05:43.000 | SHOP | 764912 |
| 5 | 74b3a3c01… | 2014-01-17 09:05:43.000 | SHOP | 124784 |
| 6 | a11593aea… | 2014-01-17 09:05:43.000 | SHOP | 132842 |
Хаб был загружен из нескольких источников, использующих разные форматы хранения номера клиента. В то время как CRM-система хранит клиентские номера как составной ключ (так называемый “smart-key”), интернет-магазин способен хранить только числовые значения для клиентских номеров. Поэтому бизнес предоставляет таблицу сопоставления между номерами клиентов в CRM-системе и системе интернет-магазина (таблица 5.4).
Таблица 5.4 Сопоставление клиентских номеров между системами-источниками
| CRM Customer Number | SHOP Customer Number |
|---|---|
| DE4711 | 124784 |
| US4317 | 132842 |
| UK8876 | 764912 |
Имея таблицу соответствия клиентских номеров, можно создать структуру связи, изображённую на рисунке 5.6.
Рисунок 5.6 Физическая модель Same-as-Link для клиентов
Эта связь заполняется записями, подобными тем, что представлены в таблице 5.5.
Таблица 5.5 Same-as-Link для клиентских номеров
| # | SAICustomerHashKey | LoadDate | RecordSource | CustomerMasterHashKey | CustomerDuplicateHashKey |
|---|---|---|---|---|---|
| 1 | c5cd634e4a… {DE4711;124784} | 2014-01-17 09:08:27.000 | MDM | b7b0a554b9… {DE4711} | 74f33a3c01… {124784} |
| 2 | 69777c1b5b… {US4317;132842} | 2014-01-17 09:08:27.000 | MDM | dd2c1f2d8d… {US4317} | a11593aeaa… {132842} |
| 3 | ae7324fa23… {UK8876;764912} | 2014-01-17 09:08:27.000 | MDM | e138c1d3c9… {UK8876} | d1360901d7… {764912} |
С точки зрения загрузки данных, хэш-ключи в столбце CustomerMasterHashKey должны формироваться на основе ключей из ведущей (master) системы — например, CRM. Это позволяет выполнять поиск клиентского номера из системы интернет-магазина (SHOP) путём выборки записи из таблицы Same-as-Link, где Customer1HashKey соответствует номеру из CRM. Таким образом обеспечивается консолидация клиентских идентификаторов при анализе данных.
Иерархические связи (Hierarchical Links)
Иерархические связи используются для моделирования отношений родитель-дочерний в Data Vault. Один из распространённых примеров — иерархия спецификаций (BOM, bill of materials), описывающая, из каких деталей состоит изделие. Например, самолёт состоит из компонентов, представленных на рисунке 5.7.
Рисунок 5.7 Части самолёта
Каждая часть самолёта состоит из других, более мелких деталей. Компоненты типового турбореактивного двигателя изображены на рисунке 5.8. Все они оформлены в структуре спецификаций (BOM), показанной на рисунке 5.9.
Рисунок 5.8 Сечение турбореактивного двигателя
Рисунок 5.9 Структура спецификации (BOM)
Каждый элемент BOM имеет название, номер детали, количество, необходимое для сборки, и указание источника.
Модель Data Vault для представления такой иерархии приведена на рисунке 5.10.
Рисунок 5.10 Логическая модель иерархической связи
Вместо того чтобы моделировать каждый уровень иерархии отдельным хабом, предпочтительно создать один хаб, поскольку бизнес рассматривает уровни иерархии как однотипные. С технической точки зрения они могут иметь разную степень детализации/гранулярности, но в бизнес-контексте каждый уровень — это просто часть иерархии.
Таким образом, иерархическая связь — это просто применение стандартной связи (link) в Data Vault. Она не нарушает модель и не требует особых правил.
Неисторические связи (Nonhistorized Links)
Все предыдущие примеры связей сохраняют историю отношений между бизнес-объектами. Обычно, если что-то изменилось в источнике, это отражается добавлением новой версии в спутник (satellite). Однако бывают ситуации, когда данные не должны быть изменены вообще — например, транзакционные данные или данные с датчиков. В таких случаях используется неисторическая связь.
Это особый тип связи, также называемый транзакционной (хотя этот термин уже считается устаревшим). Такие связи не обновляются. Если транзакция отменена, в систему загружается обратная транзакция. Исправления задним числом не допускаются.
Примеры:
- Транзакции продаж
- Поток данных с камер видеонаблюдения (CCTV)
- Сенсорные данные от IoT-устройств
Видео или изображения, поступающие в Data Vault, не будут обновляться — они просто фиксируются как есть. Поэтому термин «транзакционная» связь заменён на неисторическая.
Рисунок 5.11 Логическая модель неисторической связи
Символ аналогичен стандартной связи, за исключением индикатора рядом с иконкой, который ясно показывает, что это неисторическая связь. По историческим причинам индикатором служит буква T, как в слове transactional link (транзакционная связь). Обратите внимание, что невозможно добавлять спутники (satellites) к неисторическим связям в логической модели (хотя существуют варианты добавления спутников в физической реализации, как мы узнаем немного позже в этом разделе). Атрибуты, являющиеся частью транзакции, добавляются непосредственно в неисторическую связь.
Существует два варианта физического моделирования неисторических связей в Data Vault. Первый вариант включает стандартную сущность связи и спутник без атрибута LoadEndDate. Таким образом, невозможно вставлять новые версии записей в этот спутник, поскольку нельзя установить дату окончания действия записи и заменить её другой версией. Рисунок 5.12 показывает электронный счёт-фактуру за авиаперелёт — типичную транзакцию в авиационной отрасли.
Рисунок 5.12 Электронный счёт-фактура за авиаперелёт
Транзакция идентифицируется номером счёта-фактуры 0198536 и была выдана 21 января 2014 года. Также указана другая информация, такая как клиент и продавец. Обратите внимание, что невозможно обновить бронирование рейса. Если информация, предоставленная во время бронирования, неверна (например, указан неправильный аэропорт назначения), единственный способ изменить бронирование — заплатить сбор за изменение и приобрести новое бронирование. Старое бронирование будет аннулировано. Поэтому обновление старого счёта-фактуры невозможно без создания нового счёта.
Логическая модель Data Vault на рисунке 5.13 фиксирует транзакцию электронного счёта-фактуры.
Рисунок 5.13 Неисторическая связь (физическая реализация)
Связь LinkInvoice фиксирует основную транзакцию с ссылкой на клиента, ссылкой на продавца и идентификатором транзакции InvoiceNumber. По определению, этот идентификатор транзакции добавляется непосредственно в неисторическую связь. Хэш-ключ неисторической связи создаётся из бизнес-ключей ссылочных хабов и идентификатора транзакции. Спутник SatInvoice содержит все описательные атрибуты, такие как Record Locator и дата выдачи счёта-фактуры (Invoice Issue Date). Обратите внимание, что дата выдачи счёта отличается от даты загрузки записи, и поэтому она должна быть добавлена в модель.
Однако возможно использовать дату транзакции в качестве даты загрузки, если момент загрузки транзакции в Data Vault совпадает с фактической датой транзакции или происходит в пределах нескольких секунд. Обратите внимание, что сущности на рисунке 5.13 не отображают все описательные атрибуты, показанные в счёте-фактуре на рисунке 5.12.
В некоторых случаях можно отказаться от использования атрибута LoadDate в записи спутника, потому что обе записи (запись связи и сопровождающая её запись спутника) будут иметь одинаковую временную метку загрузки. Таким образом, атрибут LoadDate в спутнике хранит дублирующие данные, которые занимают место на диске. Однако бывают случаи, когда данные для обеих сущностей поступают из разных источников и доставляются последовательно, с разницей в миллисекунды. Это часто происходит, например, в сценариях реального времени, которые не рассматриваются в этой книге. В любом случае, в таких случаях атрибут LoadDate должен быть смоделирован в обеих сущностях для фиксации разницы во времени поступления данных. Ещё одной причиной моделирования атрибута в обеих сущностях является стандартизация, которая упрощает понимание сущностей для новых участников проекта.
Второй вариант, которого следует избегать в большинстве случаев, — это добавление атрибутов транзакции непосредственно в структуру связи и отказ от использования структуры спутника вообще. Рисунок 5.14 показывает пример такой неисторической связи.
Рисунок 5.14 Альтернатива неисторической связи без спутника (физическая реализация)
Атрибуты InvoiceIssueDate и RecordLocator были перемещены из спутника в связь LinkInvoice. Спутник SatInvoice с рисунка 5.13 был полностью удалён, так как больше не требуется.
Этот вариант не рекомендуется, поскольку он изменяет архитектурный дизайн модели Data Vault путём внесения решений в процесс проектирования. Тем самым он увеличивает сложность модели и расходы на сопровождение. Кроме того, он усложняет автоматическую загрузку неисторических связей. Тем не менее, бывают случаи, когда второй вариант оправдан: если производительность имеет критическое значение, то есть требуется загрузка данных за миллисекунды или быстрее, может потребоваться смоделировать неисторическую связь, как показано на рисунке 5.14. Однако имейте в виду, что чрезмерная ширина таблицы связи может негативно повлиять на оптимизацию производительности. Если данные в одной строке становятся слишком широкими, это снижает количество записей на одну страницу базы данных (по крайней мере, в СУБД с построчной ориентацией, таких как Microsoft SQL Server). Физическая реализация может варьироваться в зависимости от выбранной платформы, и, как следствие, производительность загрузки и запросов к структуре связи может снижаться. Хотя это также может происходить и при использовании первого варианта, в нём можно распределить данные по нескольким спутникам, чтобы сохранить компактный размер строк.
Рисунок 5.15 показывает, что атрибуты транзакции распределены между спутниками. Оба спутника соответствуют определению неисторических спутников, изложенному в этом разделе. Перенос описательных данных из неисторической связи в зависимый спутник следует рассматривать, если количество фиксируемых атрибутов достаточно велико. Проблема в том, что Microsoft SQL Server хранит данные в файловых страницах размером 8 КБ, без возможности изменить этот параметр. Потенциальная ширина связи ограничена этим ограничением по размеру. По этой причине в структуру неисторической связи следует добавлять лишь ограниченное количество описательных полей для поддержания производительности.
Рисунок 5.15 Неисторическая связь с несколькими спутниками (физическая реализация)
Обратите внимание, что Data Vault 2.0 не зависит от используемой системы баз данных. Примеры в этой книге основаны на Microsoft SQL Server, но могут быть легко перенесены в другие системы баз данных.
Непояснённые связи (Nondescriptive Links)
Во многих случаях связи Data Vault будут иметь один или несколько спутников для предоставления контекста связи. Однако в некоторых случаях связи не будут иметь спутников. Это может происходить, если нужно указать только отношение между двумя бизнес-ключами, например, если клиент авиакомпании выразил интерес к определённому предложению, щёлкнув по рекламе на веб-сайте авиакомпании.
На рисунке 5.16 низкоценная связь Interest соединяет хабы Customer и Offering без предоставления дополнительного контекста.
Рисунок 5.16 Low-value link — Низкоценная связь (логическая модель)
Непояснённые связи также используются для хранения одного состояния в многостадийной (multistate) или ролевой (role-playing) связи. Если мы расширим предыдущий пример, мы можем создать другую связь, чтобы смоделировать другое состояние — например, что клиент был выбран для маркетинговой кампании.
Рисунок 5.17 показывает, что это второе состояние добавлено в модель через другую связь — Mailing. Обратите внимание, что существуют и другие способы моделирования многостадийных связей, например, с использованием комбинации спутника и таблицы кодов.
Рисунок 5.17 Multistate low-value link — Многостадийная низкоценная связь (логическая модель)
Вычисленные агрегатные связи (Computed Aggregate Links)
Этот тип связи Business Vault удаляет один хаб из связи и агрегирует данные по оставшимся отношениям. Например, рассмотрим модель Data Vault, показанную на рисунке 5.18.
Рисунок 5.18 Вычисленная агрегатная связь с вычисленным спутником (логическая модель)
Оригинальная связь LinkFlight соединяет три хаба: HubAirport, HubFlight и HubCarrier. Она обозначает рейс, запланированный авиаперевозчиком между двумя соединяющимися аэропортами с заданным номером рейса. Когда номер рейса удаляется из связи, новая связь LinkService теряет информацию о рейсе, потому что больше не содержит ссылки на HubFlight. Эта связь только указывает, какие перевозчики обслуживают какие аэропортовые соединения. Количество отдельных номеров рейсов агрегируется в атрибут FlightCount в спутнике SatService. И LinkService, и связанный спутник SatService не поступают из исходной системы. Вместо этого данные, хранящиеся в этих сущностях, рассчитываются на основе агрегатных функций.
Поскольку эти данные рассчитаны, а не являются «сырыми», вычисленные агрегатные связи являются частью Business Vault. Сущность не подлежит аудиту, но может быть воссоздана из исходных данных LinkFlight в любой момент времени. В этом смысле вычисленная агрегатная связь является вариантом использования таблицы-моста (bridge table).
Поскольку вычисленная агрегатная связь в этом примере является частью Business Vault, можно также изменить её структуру при необходимости, например, переместив вычисленный атрибут в структуру связи, как показано на рисунке 5.19.
Рисунок 5.19 Вычисленная агрегатная связь с вычисленным атрибутом в связи (логическая модель)
Эта опция доступна только в том случае, если вычисленная агрегатная связь является сущностью Business Vault, то есть сама связь рассчитывается из сырых данных с использованием бизнес-логики, например, оператора GROUP BY. Если данные связи вычисленной агрегатной связи поступают из исходной системы, сущность связи остаётся в Raw Data Vault (рисунок 5.20).
Рисунок 5.20 Агрегация, вычисленная на связи Raw Data Vault (логическая модель)
В этом случае агрегация, которая по-прежнему рассчитывается из других данных в исходной системе, сохраняется в вычисленных спутниках и прикрепляется к сырой связи. Такая ситуация может возникнуть, если сама связь доступна в исходной системе, но агрегация — нет. В этом случае агрегация основана на других сырых данных и прикрепляется к правильному уровню детализации, которым является LinkService в примере на рисунке 5.20. Таким образом, определяющей характеристикой обеих моделей является источник данных связи: поступают ли они из исходной системы или уже являются рассчитанными. В первом случае данные моделируются как сырая связь с прикреплённым вычисленным спутником, как на рисунке 5.20. Если связь уже рассчитана из сырых данных, например с помощью оператора GROUP BY, сущность связи становится частью Business Vault, как на рисунке 5.18.
Исследовательские связи (Exploration Links)
Исследовательские связи — это вычисленные связи, созданные исключительно по бизнес-причинам. Поэтому они являются частью Business Vault. Хотя связь между двумя хабами отсутствует в исходной системе, бизнес может принять решение создать исследовательскую связь для изучения данных (рисунок 5.21).
Рисунок 5.21 Исследовательские связи (логическая модель)
Три хаба (HubAirplane, HubEngine и HubManufacturer) на рисунке 5.21 соединены друг с другом двумя связями (LinkAirplanePart, LinkManufacturer). Бизнес может принять решение проанализировать связь между этими тремя хабами, добавив LinkAirplanePartsWithManufacturer, которая является денормализованной версией обеих связей. В других случаях бизнес может решить проанализировать связь между двумя хабами, которые соединены только косвенно — в данном случае HubAirplane и HubManufacturer. Получившаяся связь LinkAirplaneWithManufacturer предоставляет такую возможность, как показано на рисунке.
Связи, являющиеся стандартными связями Data Vault, создаются и поддерживаются вручную, хотя бизнес может принять решение автоматизировать процесс создания такой связи. Исследовательские связи являются частью Business Vault и, следовательно, не подлежат аудиту.
Причины создания исследовательских связей включают:
- Определение связей и динамических сетей между бизнес-сущностями (хабами), которых нет в исходной системе
- Представление связей, которые в противном случае были бы только косвенными
- Объединение связей между бизнес-объектами, если один из ссылаемых хабов содержит дублирующиеся записи (см. same-as link)
- Идентификация кластеров схожих записей внутри хабов (опять же, с использованием same-as links)
- Автоматическое выявление шаблонов, например при обнаружении мошенничества
Применение спутников (Satellite Applications)
После завершения обсуждения связей специального назначения, следующие разделы рассматривают аналогичные случаи для спутников Data Vault.
Перегруженные спутники (Overloaded Satellites)
Мы рекомендовали в главе 4, «Моделирование Data Vault 2.0», чтобы для каждого источника данных использовался отдельный спутник, отслеживающий атрибуты из этого источника. В некоторых случаях реализационные специалисты Data Vault пытаются объединить данные из нескольких источников в один спутник. Хотя иногда для этого есть веские причины, такой подход также несёт в себе риски.
Первая проблема возникает, если формат данных у каждого отдельного источника отличается, например, длина символов в атрибутах имени или адреса. Если данные различаются — а это весьма вероятно — данные очень быстро становятся «грязными».
Другие проблемы становятся очевидными при анализе таблицы 5.6, которая показывает извлечённые данные из перегруженного спутника.
Таблица 5.6 Перегруженный спутник с данными из нескольких источников
| # | PassengerHashKey | LoadDate | LoadEndDate | Record Source | HashDiff | Name | Addr | Phone |
|---|---|---|---|---|---|---|---|---|
| 1 | 86f8sa7b3c… | 2014-01-17 09:05:43.000 | TICKETING | 10daeb8564… | Dan Linstedt | 26 Prospect St | 802-524-8566 | |
| 2 | 86f8sa7b3c… | 2014-01-17 09:05:43.000 | ONLINE | 00ebf10b9e… | Daniel L | 28 Root Beer | 827-295-1212 | |
| 3 | 86f8sa7b3c… | 2014-01-17 09:05:43.000 | BILLING | ef843ac01e… | Dan Linste | 26 Prospect | 999-111-1111 | |
| 4 | 86f8sa7b3c… | 2014-01-17 09:05:43.000 | SECURITY | a7c8a5e9f1… | Dan Linstedt | 26 Prospect St | 802-555-152 | |
| 5 | 86f8sa7b3c… | 2014-01-17 09:05:43.000 | BAGGAGE | a723eca93f… | Dan Linstedt | 1 Richland | 802-555-1215 |
Согласно атрибуту RecordSource, данные поступают из пяти различных источников. Поскольку каждый источник имел одинаковую структуру и использовал одни и те же типы данных, бизнес решил загружать все данные в один и тот же спутник. При анализе данных возникают следующие вопросы:
- Какую из исходных систем следует считать основной, если данные противоречат друг другу (как в таблице 5.6)?
- Есть ли строки, которые замещают другие строки?
- Какая из строк является самой актуальной?
- Первичным ключом этого спутника должна быть комбинация PassengerHashKey и LoadDate. Однако эта комбинация полей в данном спутнике не уникальна. Следует ли включить атрибут RecordSource в первичный ключ, чтобы сделать его допустимым?
- Если некоторые источники данных предоставляют значения NULL или вовсе не предоставляют значения для некоторых атрибутов, как нам с ними поступать?
- Следует ли объединять или сливать данные из источников при загрузке, или оставить их как есть?
Некоторые из этих вопросов подводят нас к другой проблеме, которая заключается в обнаружении изменений (delta-detection) в спутнике. Напомним, что спутники должны хранить только изменения атрибутов, а не состояние атрибута при каждой загрузке. Однако из-за описанных выше проблем обнаружение изменений становится очень сложным (поскольку мы хотим сохранять каждое изменение из каждой исходной системы, а не только из основной системы).
Мультиактивные спутники (Multi-Active Satellites)
Мультиактивные спутники похожи на перегруженные спутники: они хранят несколько записей на один родительский ключ. Однако эти записи поступают не из разных источников, а из денормализованного источника данных, такого как COBOL copybooks или XML-файлы. Существует множество примеров допустимого использования. Например, у сотрудников может быть неограниченное количество телефонных номеров, как показано на рисунке 5.22.
Рисунок 5.22 Пример мультиактивного спутника
XML-файл слева на рисунке 5.22 представляет сотрудника с рядом телефонных номеров. Структура XML-файла преобразуется в сущность спутника Data Vault справа. Описательный атрибут (телефонный номер) — это атрибут PhoneNumber, который является единственным описательным атрибутом в этом примере. Единственное отличие от предложенной структуры в главе 4 — это PhoneSeq, номер последовательности, который представляет собой индекс, идентифицирующий телефонный номер в левой структуре. Полученные данные спутника представлены в таблице 5.7.
Таблица 5.7 Данные мультиактивного спутника
| # | EmployeeHashKey | PhoneSeq | LoadDate | LoadEndDate | RecordSource | HashDiff | PhoneNumber |
|---|---|---|---|---|---|---|---|
| 1 | 33aa… | 1 | 2013-07-14 03:10:15 | (Null) | Employee.xml | 12fb… | 1-405-1234123 |
| 2 | 33aa… | 2 | 2013-07-14 03:10:15 | (Null) | Employee.xml | 76ca… | 1-213-1561234 |
| 3 | 33aa… | 3 | 2013-07-14 03:10:15 | (Null) | Employee.xml | 8cb1… | 49-511-55349873 |
| 4 | 33aa… | 4 | 2013-07-14 03:10:15 | (Null) | Employee.xml | 9944… | 49-30-12345678 |
Данные показывают, что существует одна запись на каждый номер телефона из XML-источника. Каждая запись идентифицируется по
- EmployeeHashKey — хеш-ключу родительского элемента спутника;
- PhoneSeq — позиции телефонного номера в XML-файле;
- и LoadDate — метке времени первого появления данных в исходном файле.
Тем не менее, с мультиактивными спутниками связаны определённые проблемы, поскольку существует зависимость от порядка детализированных записей. Если порядок номеров телефонов в XML-файле изменится, все данные по сотруднику будут восприниматься как дельта, даже если просто два номера поменялись местами без изменения самих номеров. Таблица 5.8 показывает пример таких данных.
Таблица 5.8 Данные мультиактивного спутника с изменённым порядком в источнике
| # | EmployeeHashKey | PhoneSeq | LoadDate | LoadEndDate | RecordSource | HashDiff | PhoneNumber |
|---|---|---|---|---|---|---|---|
| 1 | 33aa… | 1 | 2013-07-14 03:10:15 | 2013-07-20 02:54:04 | Employee.xml | 12fb… | 1-405-1234123 |
| 2 | 33aa… | 2 | 2013-07-14 03:10:15 | 2013-07-20 02:54:04 | Employee.xml | 76ca… | 1-213-4561234 |
| 3 | 33aa… | 3 | 2013-07-14 03:10:15 | 2013-07-20 02:54:04 | Employee.xml | 8cb1… | 49-511-55349873 |
| 4 | 33aa… | 4 | 2013-07-14 03:10:15 | 2013-07-20 02:54:04 | Employee.xml | 9944… | 49-30-12345678 |
| 5 | 8321… | 1 | 2013-07-14 03:10:15 | (Null) | Employee.xml | 93ca… | 1-205-1234123 |
| 6 | 8321… | 2 | 2013-07-14 03:10:15 | (Null) | Employee.xml | 328a… | 49-40-12345678 |
| 7 | 33aa… | 1 | 2013-07-20 02:54:05 | (Null) | Employee.xml | 12fb… | 1-405-1234123 |
| 8 | 33aa… | 2 | 2013-07-20 02:54:05 | (Null) | Employee.xml | 8cb1… | 49-511-55349873 |
| 9 | 33aa… | 3 | 2013-07-20 02:54:05 | (Null) | Employee.xml | 76ca… | 1-213-4561234 |
| 10 | 33aa… | 4 | 2013-07-20 02:54:05 | (Null) | Employee.xml | 9944… | 49-30-12345678 |
Первые четыре записи (записи №1–4) представляют первый порядок в исходной системе, в то время как последние четыре записи (записи №7–10) представляют порядок тех же, неизменённых записей при второй загрузке пакета. Однако старые записи из первого пакета помечены как удалённые по значению LoadEndDate, которое в этих случаях не равно null (напомним, это означает, что они были заменены).
Для решения этой проблемы можно использовать сам номер телефона в качестве номера последовательности. Субпоследовательность, как в таблице 5.7, должна использоваться только как архитектурный резервный вариант и только с активным сжатием таблицы. Таблица 5.9 приводит пример. Это устраняет зависимость от порядка при проверке дельт, но исключает возможность воссоздать набор данных в правильном порядке поступления. Если это важно, субпоследовательность, как показано в предыдущем примере — единственный способ. Другой вариант — перед вставкой включать существование телефонного номера в спутнике как текущей активной строки. Однако этот вариант не проверяет удалённые номера, которые могли исчезнуть из входящего набора данных.
Таблица 5.9 Данные мультиактивного спутника с альтернативным атрибутом последовательности
| # | EmployeeHashKey | PhoneSeq | LoadDate | LoadEndDate | RecordSource | HashDiff | PhoneNumber |
|---|---|---|---|---|---|---|---|
| 1 | 33aa… | 1-405-1234123 | 2013-07-14 03:10:15 | (Null) | Employee.xml | 12fb… | 1-405-1234123 |
| 2 | 33aa… | 1-213-4561234 | 2013-07-14 03:10:15 | 2013-07-20 02:54:04 | Employee.xml | 76ca… | 1-213-4561234 |
| 3 | 33aa… | 49-511-55349873 | 2013-07-14 03:10:15 | 2013-07-20 02:54:04 | Employee.xml | 8cb1… | 49-511-55349873 |
| 4 | 33aa… | 49-30-12345678 | 2013-07-14 03:10:15 | (Null) | Employee.xml | 9944… | 49-30-12345678 |
| 5 | 33aa… | 1-213-4561235 | 2013-07-20 02:54:05 | (Null) | Employee.xml | 776a… | 1-213-4561235 |
Таблица показывает, что запись №2 была обновлена записью №5 во втором пакете. Запись №3 была удалена и больше не существует. Поэтому она получила конечную дату (end-dated) в спутнике. Обратите внимание, что описательный атрибут PhoneNumber дублируется в первичном ключе спутника (атрибут PhoneSeq), а не просто перемещается. Это упрощает понимание спутника для следующего пользователя, которому необходимо извлекать описательные атрибуты из спутника для бизнеса.
Если используется описанное решение, могут возникнуть две проблемы: во-первых, альтернативный атрибут должен быть NOT NULL и уникальным в контексте родителя, и во-вторых, производительность может значительно пострадать. Проблема с производительностью возникает, если альтернативный столбец последовательности является строкой, а не числом. Однако последовательность, составленная из символов, является лучшим решением из двух плохих (наилучший вариант из худших).
Спутники отслеживания статусов (Status Tracking Satellites)
Спутники отслеживания статусов используются для загрузки журналов аудита или данных из систем фиксации изменений (Change Data Capture, CDC). Эти методы отслеживают информацию об операциях CRUD (также SCRUD) в исходной системе. Информация должна предоставляться исходной системой и включает сведения о создании (C), чтении (R), обновлении (U), удалении (D) и поиске (S) данных в исходной системе. Часто эта информация сохраняется операционной системой каждый раз, когда пользователь выполняет одну из этих операций в приложении. Таблица 5.10 предоставляет пример такой SCRUD-таблицы. Это результат функции CDC и показывает все изменения в исходной таблице.
Таблица 5.10 Таблица фиксации изменений (CDC) для сотрудников
| # | __$start_lsn | __$seqval | __$operation | __$update_mask | Employee ID | First Name | Last Name |
|---|---|---|---|---|---|---|---|
| 1 | 0x0000001C00000610004 | 0x0000001C00000610002 | 1 | 0x07 | 5 | Chris | Miller |
| 2 | 0x0000001C00000620004 | 0x0000001C00000620003 | 2 | 0x07 | 3 | Jane | Brown |
| 3 | 0x0000001C000006D0004 | 0x0000001C000006D0002 | 4 | 0x02 | 1 | Mike | Freeman |
| 4 | 0x0000001C000006E0004 | 0x0000001C000006E0002 | 4 | 0x02 | 1 | Michael | Freeman |
__$operation указывает тип операции над данными. Реализация CDC в Microsoft SQL Server допускает следующие значения:- Удаление
- Вставка
- Обновление (старые значения)
- Обновление (новые значения).
Обратите внимание, что, в зависимости от приложения, журналирование операций чтения (что не поддерживается реализацией CDC в Microsoft SQL Server) может потребовать большого объёма хранения. То же самое может относиться к операциям поиска (снова, не поддерживается). Однако некоторые среды требуют этого по соображениям безопасности, чтобы предоставлять информацию о том, кто получал доступ к каким данным.
Спутник отслеживания статуса определяется, как на рисунке 5.23.
Рисунок 5.23 Спутник отслеживания статуса (логическая модель)
Спутник отслеживания статуса на рисунке 5.23, SatEmployeeStatus, состоит только из одного описательного атрибута — атрибута Status, где хранятся данные из __$operation. Кроме того, имеется только метаданные, которые не отображаются на логических диаграммах Data Vault.
Данные в таблице, полученные из данных таблицы 5.10, представлены в таблице 5.11.
Таблица 5.11 Данные спутника отслеживания статуса
| # | EmployeeHashKey | LoadDate | LoadEndDate | RecordSource | Status |
|---|---|---|---|---|---|
| 1 | 5a5… | 2013-07-14 03:10:15 | (Null) | Employee | D |
| 2 | 389a… | 2013-07-14 03:10:15 | (Null) | Employee | C |
| 3 | 1121… | 2013-07-14 03:10:15 | 2013-07-20 02:54:04 | Employee | U |
| 4 | 1121… | 2013-07-20 02:54:05 | (Null) | Employee | U |
Обратите внимание, что описательные данные (например, бизнес-ключ) не хранятся в спутнике отслеживания статуса. Отслеживаются только статус и метка времени изменения статуса. Кроме того, исходные значения этих записей не отображаются (они устарели). Описательные данные загружаются в соответствующие стандартные спутники, предназначенные для захвата этих данных.
Кроме того, данные в спутниках отслеживания статуса должны быть нормализованы и соответствовать стандартному макету и правилам спутников. В этих таблицах должно быть включено сжатие, чтобы экономить дисковое пространство.
Если несколько исходных систем предоставляют информацию о статусе, следует отслеживать только информацию от основной системы (ведущей системы).
Хорошей практикой также является использование нескольких спутников отслеживания статуса для бизнес-ключа или отношения, тем самым разделяя спутник отслеживания статуса по источникам данных.
Спутники эффективности (Effectivity Satellites)
Спутники эффективности часто прикреплены к сущностям-связям Data Vault и представлены на рисунке 5.24. Они отслеживают эффективность (актуальность) связи между двумя бизнес-объектами среди других применений (например, может быть полезно отслеживать актуальность бизнес-ключа в хабе). Их цель — отслеживать, когда связь активна с точки зрения бизнеса, и предоставлять даты начала и окончания для этой цели. Эти данные часто представляют собой организационно-ориентированную точку зрения, то есть когда связь (или бизнес-ключ) считается удалённой в организации.
Рисунок 5.24 Спутник эффективности (логическая модель)
Связь LinkMembership на рисунке 5.24 соединяет два хаба в модели. Хотя связь состоит только из стандартных атрибутов, которые фиксируют метаданные отношения между авиакомпанией и альянсом, таких как LoadDateTime и RecordSource, сама связь не имеет даты окончания внутри структуры связи.
Начало и окончание членства авиакомпании фиксируются спутником SatMembership, который зависит от связи. Для этой цели добавлены атрибуты MembershipBegin и MembershipEnd.
Даты начала и окончания не генерируются системой. Вместо этого они должны быть предоставлены из источника данных, например из журнала аудита Microsoft Master Data Services, дат актуальности в мастер-данных, CDC или любого другого журнала аудита из операционных систем. Чтобы пройти аудит хранилища данных, должно быть возможно отследить эти даты до исходной системы.
Спутники эффективности имеют смысл только в том случае, если исходная система предоставляет даты эффективности. Избегайте создания искусственных дат эффективности, если только система не предоставляет эти данные. Обычно это касается только подмножества таблиц данных или потоков. Однако чем больше источников предоставляет даты эффективности, тем лучше. Обязательно фиксируйте их в Data Vault, поскольку они часто могут использоваться для целей анализа данных (data mining).
Реляционная структура, показанная на рисунке 5.25, реализует пример с рисунка 5.24 и используется для отслеживания актуальности членства авиакомпаний в авиационных альянсах.
Рисунок 5.25 Спутник эффективности (физическая модель)
Для каждой записи в таблице связей существует одна активная запись в спутнике эффективности. Также возможно вставлять обновлённые записи, например, если членство было продлено.
Обратите внимание, что спутники эффективности не отслеживают доступность данных в исходной системе. Это отслеживается спутниками отслеживания записей (record tracking satellites), которые фиксируют статус данных в исходных системах.
Спутники отслеживания записей (Record Tracking Satellites)
Иногда требуется отслеживать, какие прикладные системы-источники подают какие ключи и связи в какие циклы загрузки. Например, многие системы предоставляют данные в виде полных дампов каждый день. В некоторых случаях не все записи включаются каждый день. Вместо этого они появляются и исчезают изо дня в день без какой-либо фиксированной закономерности. Это особенно верно для устаревших мейнфрейм-систем, поскольку записи в них часто блокируются при редактировании бизнес-пользователем. Если записи выгружаются в экспортный файл одновременно с тем, как бизнес-пользователь блокирует запись для редактирования, то запись пропускается и, соответственно, не экспортируется. В экспортном файле этой записи просто нет вовсе.
Другая проблема заключается в том, что такие системы редко предоставляют информацию о захвате изменённых данных (CDC). Следовательно, невозможно с уверенностью определить удалённые записи. Однако, чтобы загрузить Data Vault, нам нужно выяснить, какие записи были удалены из системы-источника (чтобы задать им дату окончания с помощью атрибута LoadEndDate в спутниках), а какие просто исчезли из экспортного файла, но появятся в одном из следующих экспортов. Последние не должны иметь дату окончания. Это похоже на LastSeenDate хабов и связей, где отмечается последняя временная метка, когда бизнес-ключ или связь в последний раз встречались в системе-источнике — по тем же самым причинам.
Чтобы различать случаи «отсутствует несколько дней» и «удалено», бизнес обычно устанавливает бизнес-правило для различения этих двух классов. Например, бизнес может принять решение, что все записи, которые не появлялись в течение 7 последовательных дней, следует считать удалёнными. Количество дней часто различается для разных типов данных и источников данных. Это также похоже на методы обработки и обновления LastSeenDate хабов и связей. Рисунок 5.26 показывает логическую диаграмму спутника отслеживания записей.
РИСУНОК 5.26 Спутник отслеживания записей (логическая модель)
В этом примере хаб HubPassenger расширяется спутником отслеживания записей SatPassengerTrack. Диаграмма показывает, что отслеживаются следующие источники записей для появления ключа клиента: рейсы, финансы, программа лояльности и бронирования.
Для наличия каждого бизнес-ключа или связи в системе-источнике в определённый момент времени вставляется запись в спутник отслеживания записей (если он существует для хаба или связи). Следовательно, спутник указывает, что данный ключ или связь присутствовали в момент отслеживания (время записи LoadDate). Таблица 5.12 показывает пример данных в спутнике с рисунка 5.26.
Таблица 5.12 Денормализованные данные спутника отслеживания записей
| # | CustomerHashKey | LoadDate | Manufacturing | Finance | Contracts | Sales |
|---|---|---|---|---|---|---|
| 1 | 5af3… | 2013-07-14 03:10:15 | 1 | 1 | 1 | 0 |
| 2 | 5af3… | 2013-07-15 03:10:15 | 1 | 1 | 0 | 0 |
| 3 | 5af3… | 2013-07-16 03:10:15 | 1 | 0 | 0 | 0 |
| 4 | 5af3… | 2013-07-17 03:10:15 | 1 | 1 | 0 | 1 |
В отличие от других спутников, спутник отслеживания записей не имеет атрибутов RecordSource и LoadEndDate. Это связано с тем, что все записи создаются системой (поэтому нет атрибута RecordSource) и записи никогда не обновляются (поэтому нет LoadEndDate). Вместо обновления записей при каждом цикле загрузки, каждый раз вставляется новая запись. Значение 1 в описательных атрибутах указывает, что ключ клиента присутствовал в системе-источнике, а значение 0 — что бизнес-ключ отсутствовал. В результате таких изменений спутники отслеживания записей не подлежат аудиту. Однако это не проблема, поскольку позволяет отклоняться от правил сущностей Data Vault, не нарушая всю модель.
Макет записи оптимизирован для разбиения, фильтрации и запросов. Он обеспечивает быстрый доступ к этим компонентам и определение, какие источники данных «появляются и исчезают». Однако недостатком является то, что для каждого нового источника данных, добавляемого в эту таблицу, происходит вставка, за которой следует обновление.
Обратите внимание, что для предотвращения взрыва объема данных каждый столбец или вся таблица должны быть сжаты. Также рекомендуется суммировать старые данные и удалять их из спутника отслеживания записей, чтобы сэкономить больше дискового пространства. Старые данные определяются бизнесом и должны включать все данные, которые не требуются для основной цели спутника — идентификации удалённых данных в системе-источнике. Альтернатива удалению таких данных — переместить их на более медленные (и потому более дешёвые) носители или на резервные ленты. Разбиение на разделы (partitioning) также может помочь в этом случае.
Структура в таблице 5.12 показывает, что спутник отслеживания записей не управляется данными, как все сущности в Data Vault. Вместо этого он управляется структурой систем-источников: каждый раз, когда система-источник добавляется в хранилище данных и подаёт данные в родительскую таблицу этого спутника, для целей отслеживания должен быть добавлен новый столбец. Это может быть правильным подходом для вашего Data Vault, если вы готовы принимать такие частые структурные изменения. Если это не вариант, также можно нормализовать данные, как показано в таблице 5.13.
Таблица 5.13 Нормализованные данные спутника отслеживания записей
| # | CustomerHashKey | LoadDate | RecordSource | Appearance |
|---|---|---|---|---|
| 1 | 5af3… | 2013-07-14 03:10:15 | Manufacturing | 1 |
| 2 | 5af3… | 2013-07-14 03:10:15 | Finance | 1 |
| 3 | 5af3… | 2013-07-14 03:10:15 | Contracts | 1 |
| 4 | 5af3… | 2013-07-14 03:10:15 | Sales | 0 |
| 5 | 5af3… | 2013-07-15 03:10:15 | Manufacturing | 1 |
В этом случае источник записи указывается в атрибуте RecordSource, а появление отслеживаемого бизнес-ключа или связи фиксируется в Appearance. Такая структура не требует изменений в структуре таблицы для добавления новых источников записей, поскольку новый источник требует только вставки данных в спутник отслеживания записей. Однако анализ данных спутника становится более сложным, но может быть выполнен с помощью оператора PIVOT в SQL, который доступен в Microsoft SQL Server и других СУБД.
Если бизнес предоставляет детализированные источники записей (чего мы стараемся придерживаться в этой книге как можно чаще), также возможно отслеживать перемещения данных внутри системы-источника: где впервые появился бизнес-ключ или связь в системе, куда он переместился и т.д. Детализированный источник записи максимально точно указывает источник. Например, источник записи «CRM/Contact/Lead» указывает на сущность Lead в области Contact в Microsoft CRM. Сравните эту подразумеваемую информацию с недетализированным источником записи «CRM», где не указана никакая конкретная информация о происхождении данных. Чтобы извлечь максимум пользы из источника записи и тем самым предоставить как можно больше ценности для бизнеса, старайтесь использовать максимально детализированные источники записей.
Также рекомендуется использовать иерархическую систему, чтобы агрегировать данные на отдельных уровнях для анализа.
Вычисляемые спутники (Computed Satellites)
Согласно определению Data Vault хранит необработанные (сырые) данные. Однако в некоторых случаях может быть полезно хранить вычисленные данные.
В модели Data Vault для этого предусмотрено место — Business Vault. В разделе 2.2 главы 2 мы представили Business Vault как набор таблиц, следующих модели Data Vault и содержащих данные, изменённые согласно бизнес-правилам. Эти таблицы называются вычисляемыми спутниками и предназначены для хранения вычисленных данных — то есть данных, являющихся результатом агрегации, суммирования, корректировки, оценки и т.п. Это может быть результат процедур проверки качества данных, очистки данных или корректировки адресов.
Обычно бизнес хочет выполнять такие операции только один раз перед распространением в информационные витрины (information marts), чтобы сэкономить вычислительные ресурсы. Вычисляемый спутник предназначен именно для этой цели: он хранит данные до их распространения. При этом структура вычисляемого спутника такая же, как у стандартного спутника. Единственное отличие — источник записи указывает, что данные сгенерированы системой. Также можно указать функцию, операцию или приложение, выполняющее вычисления для спутника, особенно если существует несколько источников данных, загружающих один и тот же вычисляемый спутник.
Поскольку для вычисленных данных нет прямого сырого источника, они по своей природе не подлежат аудиту. Однако возможно, что аудитор захочет изучить логику вычислений или, по крайней мере, увидеть, как, когда и что представляли собой данные до передачи их в информационные витрины. Вычисляемый спутник — это место, где можно это показать.
Логический символ вычисляемых спутников представлен на рисунке 5.27.
Рисунок 5.27 Вычисляемый спутник (логический символ)
Кроме значка на фигуре, отличий от стандартных спутников нет. Как уже упоминалось, структура такая же. Снова, различие заключается в источнике данных, поскольку в этом типе сущности хранятся вычисленные данные.