Концепції моделювання Data Vault через реальні приклади

Для застосувань існують дві основні техніки моделювання:

(1) повністю нормалізовані моделі (на основі принципів нормалізації, розвинутих в 70-х роках), які зазвичай використовують 2NF для пакетних баз даних і 3NF для DML-інтенсивних баз даних гарячого OLTP;
(2) моделі дата-складу, оптимізовані для читання, відомі як Star Schema або Dimensional model (на основі методології Кімболла).

Всі інші техніки (наприклад, верхньо-донизове проектування дата-складу за методологією Інмона, моделі типу “сніжинка” тощо) є комбінацією або незначним відхиленням від цих двох.

Моделювання Data Vault вирішує проблему, яку ці дві техніки не вирішують. Ця проблема полягає у жорсткості(rigidity). Це краще пояснити на прикладі.

Припустімо, у вас є підприємство із підписним бізнесом (яке продає будь-які продукти). Уявіть дві сутності (таблиці) – Клієнти та Підписка. Кожен клієнт реєструється за допомогою електронної адреси і має рівно одну підписку.

Припустімо, що компанія має 5 типів підписок з різною вартістю та рівнем надання послуг. Кожна підписка містить багатьох клієнтів. Таким чином:

Відношення Клієнт до Підписки є один-до-одного. Відношення Підписка до Клієнта є один-до-багатьох.

Через деякий час бізнес виявив можливість отримання доходу, дозволяючи клієнту придбати кілька підписок. Наприклад, коли клієнт хоче другу підписку для члена своєї родини, але на тому ж обліковому записі (електронна адреса). Тому тепер модель даних повинна змінитися таким чином:

Відношення Клієнт до Підписки є один-до-багатьох. Відношення Підписка до Клієнта залишається один-до-багатьох. Отже, це стало багато-до-багатьох відношенням.

Те, що колись виглядало так:

У підписників багато клієнтів; У клієнтів є одна і тільки одна підписка

Тепер має вигляд:

У підписника є один або декілька клієнтів; У Клієнта є одна або декілька підписок; те і інше дало можливість за допомогою таблиці відношень (Rltp)

Друга модель даних вводить таблицю-міст для нової моделі підписки. Але зміна цього дизайну коштує дорого: коли змінюється модель даних, всі програми, які пишуть і читають з бази даних, повинні бути змінені. ETL-процеси, які завантажують базу даних, повинні бути перероблені. Це може легко стати багатомісячним проектом для складних моделей даних.

Data Vault як рішення

Проблема тут полягає в тому, що модель 3NF (або 2NF, залежно від потенційних атрибутів цих таблиць) жорстко виражена в базовій схемі для конкретних бізнес-правил. Коли ці правила змінюються, модель повинна змінитися. Фактично це означає, що відношення між даними може змінюватися з часом, і модель повинна пристосовуватися до цього, не змушуючи програми переписувати свій код.

А якщо таблиця-міст (або асоціативна таблиця, або таблиця відносин) для розв’язання нового відношення багато-до-багатьох завжди була присутня? Це дійсно додає додатковий обсяг (додаткові з’єднання, наприклад), але це буде працювати для відношень один-до-одного, один-до-багатьох і багато-до-багатьох. В основі цього лежить ідея моделювання Data Vault.

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

Сутності класифікуються на Hubs, Зв’язки(Links) та Супутники (Satellites). Зображення: oceanbi.com.

Основні сутності бізнесу – Клієнт та Підписка, наприклад, – називаються Hub. Huby містять лише бізнес-ключі, без описових атрибутів (наприклад, без імені чи адреси клієнта). Описові атрибути, такі як ім’я та адреса, відображаються у таблицях Satellite. Таблиці Link містять відношення між Hub’ами. Наприклад, таблиця-міст у відношенні багато-до-багатьох є Link. Описові атрибути, що стосуються Link (наприклад, дата початку підписки клієнтом), відображаються у таблицях Satellite Link.

Через наявність таблиць Link, зміни в бізнес-правилах не тільки гнучкі (без змін дизайну, без переписування програм), а також Link відстежує зміни в бізнесі (з використанням, наприклад, дати початку підписки або інших відповідних атрибутів). Це може бути перевірено аудитом як для внутрішнього звітування, так і для юридичних цілей.

Інші використання Data Vaults

Вище наведений приклад показує, як експліцитно відстежуються взаємозв’язки даних через записи даних, а не через зовнішні ключі. Це один варіант використання, але моделі DV можуть бути корисними і в інших сферах, два з яких наведено нижче.

(1) Дата-склади (Data Warehouse DWH)

У дата-складах Link може відображати транзакції, які потрапляють до таблиць фактів у іншому вимірно-модельованому дата-складі. У відміну від таблиць фактів, Link у DV містить лише ключі від Hub’ів (які відповідають таблицям вимірів). Усі показники та описові атрибути запису транзакції відображаються в таблицях Satellite Link. Так само всі описові атрибути Hub’ів відображаються в їх власних таблицях Satellite.

Зазвичай атрибути, які становлять дата-склад (показники та виміри), розміщуються на таблицях Satellite. Зміни типу 2 або типу 4 реалізуються на Satellite.

Складність полягає в тому, що це не в оптимізованому для читання форматі, що вимагає багато з’єднань. Для аналітики дата-склади DV зазвичай мають шар звітів або дата-мартів поверх сирої інформації Hub-Link-Satellite. Це означає, що якщо єдиним призначенням дата-складу є аналіз даних і підтримка прийняття рішень, Data Vault – неправильне рішення.

(2) Проблема декількох джерел істини

Уявіть вищий приклад підприємства, що продає продукти, які можуть мати різні визначення або описи від різних постачальників/реселерів одного й того ж продукту. Ви отримуєте дані від цих постачальників, один з них має ProductA, інший називає це ProdA, ще інший називає це product-A.

Ваше програмне забезпечення повинно взаємодіяти з цими постачальниками на їхньому власному мовленні. Але ваша система звітів повинна розв’язати цю різницю та показувати продажі цих продуктів як продажі одного товару.

Модель у стилі Data Vault може накопичувати дані кожного постачальника в його власному Hub і використовувати Link для розв’язання залежностей. У вищевказаному прикладі таблиця-міст може бути використана для завантаження одного запису для ProductA, ProdA і product-A, і всі вони встановлені на значення product_id = 100, що є неорганічним ключем, який генерує ETL. Очевидно, це залежить від нас (а не від постачальників) вирішити співпадання продуктів в один товар за допомогою методів співставлення (схожих на техніки співставлення записів, що використовуються в системах майстер-даних).

Data Vault не є ні оптимізованим для запису (як у базах даних OLTP 3NF), ні оптимізованим для читання (як у OLAP або вимірних моделях), і це його головний недолік. Якщо у вас немає конкретної потреби в гнучкості та/або аудиті, вартує реалізовувати.

Зазвичай DV реалізується у дата-складах. Це через те, що дата-склади – це великі вертикально масштабовані системи, які можуть дозволити відсутність оптимізації для запису – програми з великою кількістю записів, як правило, мають свою власну невелику базу даних. Щоб вирішити проблему оптимізації для читання, ми вже звикли будувати дата-марти в дата-складах, які також можна побудувати на базі Data Vault.

Оригінал статі
https://rspacesamuel.medium.com/data-vault-modeling-concepts-through-real-world-examples-414fc9a1e906

Автор: Raj Samuel

Leave a Reply

Your email address will not be published. Required fields are marked *