Моделируете периодический снимок в хранилище данных?

Один из наших источников данных отправляет фид с совокупностью данных за день. Периодический снимок. Например:

shop,       day,        sales
bobs socks, 2019-01-01, 45,
bobs socks, 2019-01-02, 50,
bobs socks, 2019-01-03, 10,
janes coats,2019-01-01, 500,
janes coats,2019-01-02, 55,
janes coats,2019-01-03, 100

Я знаю два способа смоделировать это в необработанном хранилище данных:

Мультиактивный спутник

Здесь мы позволяем каждому спутнику иметь несколько строк на ключ концентратора.

create table dbo.HubShop (
    ShopName nvarchar(50) not null,
    primary key pk_HubShop (ShopName)
)

create table dbo.SatDailyShopSales (
    ShopName nvarchar(50) not null,
    SalesDate date not null,
    SalesAmount money not null,
    LoadTimestamp datetime2(7) not null,

    primary key pk_SatDailyShopSales (ShopName, SalesDate, LoadTimestamp)
)

Это легко реализовать, но теперь у нас есть двухвременной элемент спутника.

Snapshot Hub

create table dbo.HubShop (
    ShopName nvarchar(50) not null,
    primary key pk_HubShop (ShopName)
)

create table dbo.HubSnapshot (
    SalesDate date not null,
    primary key pk_HubSnapshot  (SalesDate)
)

create table dbo.LinkDailyShopSnapshot (
    LinkDailyShopSnapshotHash binary(32) not null,
    ShopName nvarchar(50) not null,
    SalesDate date not null,

    primary key pk_LinkDailyShopSnapshot  (LinkDailyShopSnapshotHash)
)

create table dbo.SatDailyShopSales (
    LinkDailyShopSnapshotHash binary(32) not null,

    SalesAmount money not null,
    LoadTimestamp datetime2(7) not null,

    primary key pk_SatDailyShopSales (LinkDailyShopSnapshotHash, LoadTimestamp)
)

Это второе решение добавляет дополнительный хаб, в котором просто хранится список дат и ссылка на пересечение даты и магазина.

Второе решение кажется более чистым, но требует большего количества стыков.

Какая модель правильная? Есть ли лучшие решения?


data-vault
person James    schedule 25.03.2019    source источник

Ответы (1)


arrow_upward
0
arrow_downward

Насколько я понимаю подход к моделированию Data Vault, спутники предназначены для хранения точных временных интервалов вашего хранилища данных. Это означает, что если мне дается конкретная дата и я выбираю все концентраторы, ссылки (без даты или конечной даты ‹= определенной даты). И затем их соответствующая запись с max (loaddate) & loaddate ‹= конкретная дата, я должен иметь полное представление о текущем состоянии данных в реальном мире.

Применительно к вашему вопросу это означает, что ваше второе решение соответствует этим требованиям. Потому что вы все еще можете импортировать «изменения» в исходную систему как новые временные интервалы, тем самым моделируя правильную временную шкалу информации в DWH.

Чтобы сформулировать это в качестве примера, предположим, что исходная система имеет состояние:

shop,       day,        sales
bobs socks, 2019-01-01, 45,
bobs socks, 2019-01-02, 50,
bobs socks, 2019-01-03, 10,
janes coats,2019-01-01, 500,
janes coats,2019-01-02, 55,
janes coats,2019-01-03, 100

и вы импортируете эти данные 2019-01-03 23:30:00. 4 января в 12:10:00 команда продаж "janes couts" скорректировала цифры до 90 продаж. В первом решении вам остается обновить запись спутника с помощью ключа хаба "janes coats" и loaddate "2019-01-03" до 90, что приведет к потере точной истории DWH.

так что ваш DWH впоследствии сохраняет только следующее:

shop,       day,        sales
bobs socks, 2019-01-01, 45,
bobs socks, 2019-01-02, 50,
bobs socks, 2019-01-03, 10,
janes coats,2019-01-01, 500,
janes coats,2019-01-02, 55,
janes coats,2019-01-03, 90

тогда как во втором решении вы просто вставляете новый временной интервал сателлита для хэша моментального снимка магазина (для бизнес-ключа «janes coats» с датой «2019-01-03») с датой загрузки «2019-01-03 12:10:00» и продажами 90.

LINK
shop,       day,        ID (think of ID as a hash)
bobs socks, 2019-01-01, 1
bobs socks, 2019-01-02, 2
bobs socks, 2019-01-03, 3
janes coats,2019-01-01, 4
janes coats,2019-01-02, 5
janes coats,2019-01-03, 6

SALES Satellite
Link ID, loaddate,            sales
1,       2019-01-03 23:30:00, 45
2,       2019-01-03 23:30:00, 50
3,       2019-01-03 23:30:00, 10
4,       2019-01-03 23:30:00, 500
5,       2019-01-03 23:30:00, 55
6,       2019-01-03 23:30:00, 100   !
6,       2019-01-04 12:10:00, 90    !

Таким образом, вы можете легко увидеть в своей системе, что вы получили корректировку показателей продаж в 2019-01-04 12:10:00 и что до этого они были 100.

На мой взгляд, единственное разрешенное действие обновления в модели Data Vault - это установка EndDate в таблице ссылок, а удаления никогда не допускаются. У вас есть полная история DWH, доступная и воспроизводимая.

person FlorianB    schedule 01.04.2019