Модель хранилища данных: для чего нужны концентраторы?
Я только что читал о моделировании Data Vault, и, насколько я понимаю, концентратор содержит только ключи (и источник записи). Поэтому мне было интересно, почему я должен создавать эти таблицы-концентраторы только для хранения источника записи? Разве не достаточно иметь только спутники и ссылки?
Кстати: я ищу простые таблицы MySQL в форме хранилища данных, чтобы загрузить и поиграть.
2 ответа
Концентратор - это место, где применяется пассивная интеграция нескольких источников. У вас будет столбец для источника данных и вы будете записывать все экземпляры каждого ключа по мере его поступления в ваш хаб. Например, если у меня есть система CRM и система ERP, и я сначала синхронизирую данные из системы CRM, то данные ERP становятся доступными. Я бы добавил все ключи из системы CRM со значением столбца источника данных "CRM". Затем, когда я ввожу систему ERP, предполагая, что у меня та же структура ключей для таблицы, я бы добавил только новые ключи, которые существуют только в системе ERP с источником данных "ERP". Если ключи разные, вам придется добавить все данные из обеих систем. Дело в том, что вы сохраняете все данные из всех систем в игре. Когда вы переходите на следующий уровень, будь то Business Data Vault или Data Mart, вы применяете бизнес-логику к концентратору и спутникам в соответствии с "Бизнес-правилами", чтобы получить одну результирующую строку для двух систем, где это применимо. Если вы используете преобразование до того, как сохранить его в этом промежуточном состоянии, вы потеряете способность к аудиту и возможность изменять бизнес-правила на более позднем этапе. Есть смысл?
Одной из основных концепций моделирования Data Vault является разделение бизнес-ключей, спутников для подробных данных и ссылок для подключения концентраторов.
пример
Employee
--------
Personnel Number
Name
Surname
Street
City
Department
--------
ID
Shortcode
Name
Employee Number
Представьте, что в одном отделе работает только один сотрудник.
Бизнес Ключи
Теперь необходимо идентифицировать бизнес-идентификаторы для бизнес-объектов Employee и Department. Это будет номер сотрудника для сотрудника и шорткод дляотдела.
Почему не удостоверение личности для отдела? Ну, идентификатор, скорее всего, внутренний идентификатор базы данных. Шорткод в этом примере что-то вродеDEP_A1613, который также внутренне используется для идентификации отдела.
моделирование
Концентратор для сотрудника состоит только из поля " Номер персонала" и концентратора для отдела только сшорткодом.
Это означает, что хаб в моделировании Data Vault предназначен только для хранения бизнес-ключа. Конечно, поля Data Vault, такие как Источник записи, Дата загрузки и другие, также необходимы. Оба концентратора также будут иметь соответствующие спутники для описания данных. Было бы нарушением техники моделирования Data Vault соединять спутники вместе без концентраторов. Это также не имеет смысла: вам нужен какой-то общий идентификатор для ваших спутниковых данных, которого бы не было, если бы вы пропустили концентратор.
Заключение
Итак, чтобы ответить на ваш вопрос: вам следует смоделировать концентраторы для бизнес-ключей. Абсолютно. Концентраторы на самом деле являются важным элементом моделирования Data Vault. Ссылки связаны только с концентраторами, а не со спутниками.
Представьте себе изменение в программном обеспечении Сотрудника. Все остальные поля теперь хранятся в сателлите Сотрудника. При использовании нового программного обеспечения Employee вы можете хранить все данные на новом спутнике , используя тот же концентратор и бизнес-ключ.
Просто чтобы завершить этот пример: ссылка свяжет Сотрудника и Отдел из Отдела с Номером Сотрудника.
РЕДАКТИРОВАТЬ
Так, например, структура будет выглядеть следующим образом. Поля Data Vault помечены [DV]:
Hub Employee
------------
Employee Hash Key [DV]
Load Date [DV]
Record Source [DV]
Personnel Number
Sat Employee
------------
Employee Hash Key [DV]
Load Date [DV]
Load End Date [DV]
Record Source [DV]
Hash Diff [DV]
Name
Surname
Street
City
Link Employee Department
------------------------
Employee Department Hash Key [DV]
Employee Hash Key [DV]
Department Hash Key [DV]
Hub Department
--------------
Department Hash Key [DV]
Load Date [DV]
Record Source [DV]
Shortcode
Sat Department
--------------
Department Hash Key [DV]
Load Date [DV]
Load End Date [DV]
Record Source [DV]
Hash Diff [DV]
ID
Name