Вот знакомится специалист с методологией DataVault. Специалист этот – человек ответственный, он со всей рьяностью принимается за нормализацию данных, ведь DataVault про разбиение данных. Но иногда перегибает палку, и разбивает то, что разбиваться не должно.

Вот пример:
Есть адрес у клиента, а также есть адрес у магазина. Ой, как руки чешутся вынести в отдельный хаб и сателлит адрес, ведь он используется в разных сателлитах. Но это лишь приведет к излишней нормализации и увеличению количества join-ов, а никакой выгоды не принесет.

То же касается таких атрибутов, как статус, категория, тип, город и тому подобное.

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

Дополнительный пример:
Мы привыкли выделять категорию продукта в отдельную таблицу и называть это Снежинкой. Но в Снежинке были на то свои причины.

В DataVault не стоит так делать, никаких преимуществ от этого выделения вы не получите.

Есть следующие справочники:

• валюта
• страны
• календарь
• ТНВЭД/ОКВЭД

Создавать для них хабы и сателлиты? Нет!

Для данных, которые не меняются (или практически не меняются) как по своим значениям, так и по структуре в DataVault есть отдельный тип объекта, про который мало кто помнит – Ref. Это обычная таблица-справочник, которая наполняется данными один раз и далее не изменяется.

А вынося, к примеру, валюту в отдельный хаб и сателлит вы попросту усложняете себе жизнь!

Данное правило распространяется не только на DataVault, но и на все методологии проектирования, и всегда является антипаттерном при проектировании Систем и СУБД.

Не храните атрибуты, которые всегда изменяются по прошествии времени.

Если вы будете хранить атрибуты, которые меняются только по прошествии времени, вы просто будете увеличивать количество строк в своих сателлитах. Лучше подобные вещи рассчитывать «на лету», то есть при расчете отчетных витрин или показателей.

Очень хочется хранить дату окончания действия записи (VALID_TO_DTTM или EFFECTIVE_TO_DTTM) в версионных сателлитах или линках. Ведь если ее не хранить, то как потом join-ится на такую таблицу? С использованием подзапроса и оконной функции?? Нет уж, это слишком сложно, да и на больших объемах может долго работать. Лучше просто записывать EFFECTIVE_TO_DTTM в атрибут сателлита.

Нет не лучше! Ведь это может привести к неочевидным последствиям.

Усложняете вы его, потому что добавляете логику расчета даты окончания действия записи. А дольше он становится (в случае с большим объемом данных кратно дольше), потому что вам необходимо делать update записей, у которых появилась новая версия.

Данные задним числом

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

Пример:

Приходит запись задним числом.

Как видно, у первой строки дата окончания действия записи стала некорректной. Придется пересчитывать все записи по ключу 1.

Наш менеджер свяжется с вами для предоставления бесплатного доступа и презентует наш сервис