🔒Открыть пост
и посмотреть медиа
и посмотреть медиа
Якорная модель (anchor modeling)
Якорное моделирование - это метод моделирования хранилища данных. Считается, что это более усовершенствованная версия Data Vault.
В anchor modeling используются такие элементы, как:
▶️Якоря. Это сами сущности, В этих таблицах хранятся только уникальные идентификаторы и еще, возможно, суррогатные ключи и метаданные загрузки.
▶️Атрибуты. В этих таблицах хранятся описания свойств сущностей, а еще и ссылки на якоря, временные промежутки (дата начала и окончания) и источник самих данных (метаданные).
▶️Связи. В случае, если таблицы-якоря связаны между собой сложнее принципа "один к одному", создаются таблицы-связи, где напротив каждого id записан другой id, который с ним связан. Иными словами, это полный аналог link-таблиц из Data Vault.
▶️Узлы. Можно сказать, это вспомогательные таблицы для атрибутов. Вместо того, чтобы каждый раз записывать в атрибутах значения, эти значения представить в виде id, а сами значения вынести уже в таблицы-узлы. Но можно этого и не делать, это необязательно.
🟠Отличие от Data Vault заключается в том, что Data Vault делит данные на хабы, линки и сателлиты. Якорная модель просто продолжает эти идеи, но с некоторыми отличиями: вместо больших таблиц-сателлитов, которые содержали в себе много атрибутов, создаются отдельные мини-таблицы под каждый атрибут. Также вместо хаба теперь якорь - по сути, то же самое, только чуть более минималистично. Link-таблицы полностью сохранены. И еще дополнительно добавлены узлы.
То есть якорная модель более нормализована, чем Data Vault. И еще одна ключевая особенность - якорная модель хранит историю изменений в DWH. Реализовано это с помощью тех самых дат начала и конца, которые указываются в атрибутах. И каждый атрибут в этой модели должен иметь эти записанные интервалы.
🟠На практике всё может выглядеть следующим образом. Предположим, есть типичная БД с данными о клиентах, товарах и заказах.
Сначала создаются 2 таблицы-якоря: одна с клиентскими данными (client_id, суррогатный ключ и метаданные загрузки), другая - с данными о товарах (prod_id, суррогатный ключ и метаданные).
Затем создаётся таблица связей - она же таблица с заказами. В ней указывается, какие client_id с какими prod_id соотносятся. Но в более сложных моделях можно вынести номер транзакции в отдельный, третий якорь.
Далее создаются таблицы атрибутов. Создается отдельная таблица для имени клиента, которая включает в себя суррогатный ключ, имя, даты начала и конца и источник. Затем создается отдельная таблица для города клиента, которая аналогична предыдущей таблице. И так далее для всех атрибутов, в том числе и товарных. Также в атрибутах указываются еще и данные о заказах: сумма заказа, количество, статус и т.д.
Также для оптимизации могут создаваться и узлы. Например, в таблице с городами скорее всего будет много значений, которые еще и будут дублироваться. И в этом случае названия городов в таблице с атрибутами можно заменить на id, а сами названия городов вынести в отдельную таблицу-справочник (узел). Это не только уменьшит вес таблицы, но еще и защитит данные в случае, если город вдруг сменит своё название.