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

 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)
)
  

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

Центр моментальных снимков

 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)
)
  

Это второе решение добавляет дополнительный концентратор, который просто хранит список дат и ссылку для пересечения между date и shop.

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

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

насколько я понимаю подход к моделированию хранилища данных, спутники предназначены для хранения точных временных срезов вашего хранилища данных. Это означает, что если мне задана конкретная дата и я выбираю все узлы, ссылки (без или enddate <= конкретная дата). И затем их соответствующая запись с max (loaddate) amp; 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 продаж.
В вашем первом решении это приводит к обновлению записи satellite с помощью ключа концентратора «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
  

тогда как в вашем втором решении вы просто вставляете новую временную шкалу для хэша моментального снимка хранилища (для бизнес-ключа «Джейнс коутс» с датой «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.

Я думаю, что единственным разрешенным действием обновления в модели хранилища данных является установка конечной даты в таблице ссылок, и что удаления никогда не разрешены. У вас есть доступная и воспроизводимая полная история DWH.