Когда мы начинаем моделирование по методологии Data Vault, первой и основной составляющей модели становятся хабы (Hubs). Хаб — это сердце нашей модели, так как он представляет ключевые бизнес-сущности, которые мы хотим зафиксировать в хранилище данных.

Хаб (Hub) — это таблица, которая отвечает за уникальную идентификацию бизнес-сущностей в хранилище данных. Каждая запись в хабе представляет собой уникальный бизнес-ключ, поступивший из одного или нескольких источников.

Основные принципы работы с хабами:

  1. Минимализм данных:
    Хаб содержит только:

    • Уникальный бизнес-ключ (или surrogate key).
    • Метаданные о дате загрузки данных (Load Date).
    • Источник данных (Source System), если это требуется.

    Все остальные данные (например, атрибуты сущности или связи между сущностями) хранятся в сателлитах и линках.

  2. Гибкость и масштабируемость:
    Хабы остаются неизменными, даже если добавляются новые источники или изменяются бизнес-правила.

  3. Фокус на уникальности:
    Один бизнес-ключ всегда соответствует одной записи в хабе, независимо от того, из какого источника пришли данные.

Пример: Хаб "Пассажиры"

Представьте, что мы создаём хранилище данных для авиакомпании. Нам нужно учесть данные о пассажирах из различных систем:

  • Система бронирования билетов (BookingSystem).
  • CRM-система (CRMSystem).
  • Система управления рейсами (FlightSystem).

Каждая из этих систем содержит уникальные бизнес-ключи для одного и того же пассажира:

  • Номер паспорта из BookingSystem.
  • Уникальный клиентский ID из CRMSystem.
  • Номер брони (PNR) из FlightSystem.

Структура Hub_Passengers

Хаб "Пассажиры" хранит только уникальные бизнес-ключи и метаданные:

Surrogate Key Business Key Load Date Source System
1 1234567890 2025-01-03 BookingSystem
1 CUST001 2025-01-03 CRMSystem
1 PNR12345 2025-01-03 FlightSystem
  • Surrogate Key: Единый ключ, который связывает разные бизнес-ключи с одним пассажиром.
  • Business Key: Уникальные идентификаторы пассажира в разных системах.
  • Load Date: Дата, когда информация была загружена в хаб.
  • Source System: Источник данных.

Атрибуты и связи:

Забежим немного вперёд...

Вся дополнительная информация (например, фамилия, дата рождения, контакты) о пассажире хранится в сателлитах, а отношения между пассажирами и их бизнес-ключами — в линках.

Пример таблицы сателлита:

Hub Key Surname Date of Birth Source System Load Date End Date
1 Smith 1990-05-10 CRMSystem 2025-01-03 NULL
  • В сателлите сохраняются все атрибуты сущности.
  • Поддерживается историчность данных (через Load Date и End Date).

Тут может возникнуть вопрос: "почему Date of Birth ты отнёс в сателлит ? этот параметр не может измениться у клиента"

Ты абсолютно прав — Date of Birth (Дата рождения) — это неизменяемый атрибут клиента. На первый взгляд, его действительно можно было бы разместить в хабе, потому что он имеет статический характер. Однако в методологии Data Vault существуют определённые правила, которые объясняют, почему такие атрибуты лучше размещать в сателлитах:

1. Централизация бизнес-ключей в хабе

Хаб должен содержать только:

  • Уникальный бизнес-ключ.
  • Системный surrogate key (если используется).
  • Метаданные для загрузки (Load Date и Source System, если это необходимо).

Все остальные атрибуты, даже неизменяемые, относятся к бизнес-данным, а не к идентификации сущности. По правилам Data Vault, все бизнес-данные (даже неизменяемые) помещаются в сателлиты.

2. Гибкость и масштабируемость

Хранение неизменяемых атрибутов в сателлите даёт возможность:

  • Добавлять или модифицировать структуру данных без изменения хаба.
  • Сохранять оригинальную информацию, даже если она была некорректной при первоначальной загрузке (например, дата рождения могла быть ошибочно введена).

3. Историчность и контроль качества данных

Даже неизменяемые атрибуты могут быть исправлены, если источник допустил ошибку. Например:

  • Клиент мог указать неверную дату рождения.
  • Источник данных мог предоставить некорректную информацию.

4. Разделение ответственности

Data Vault создаёт чёткое разделение между:

  • Идентификацией сущностей (хабы).
  • Хранением атрибутов (сателлиты).

Даже неизменяемые атрибуты лучше держать отдельно, чтобы хаб оставался максимально чистым и стабильным.

Когда дату рождения можно оставить в хабе?

В редких случаях, если:

  1. Вы точно знаете, что дата рождения всегда корректна.
  2. Вся архитектура Data Vault упрощена, и вы готовы принять на себя риск потерять историчность для неизменяемых данных.

Вывод

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

Заключение:

Хабы — это основа Data Vault. Они минималистичны, масштабируемы и сосредоточены на уникальной идентификации сущностей. Вся бизнес-логика, атрибуты и связи выносятся в сателлиты и линки, что позволяет строить гибкие, долговечные хранилища данных.