Как отслеживать слияние в «Медленно меняющемся измерении и фактах»

Вам нужно использовать «Тип 6», медленно изменяя размерность. По сути, это комбинация изменений Типа 2 и Типа 1.

Как это работает: чтобы зафиксировать изменение «Типа 2», вам понадобятся «Дата начала» и «Дата окончания» для каждой записи в таблице «Магазин». Для текущих записей конечная дата обычно представляет собой какую-то отдаленную дату в будущем, например 2999-12-31. Когда вы подключаете такую ​​таблицу к таблицам фактов, вам нужно будет соединить измерение и факт по естественному ключу (StoreBusinessID) и по дате факта между датой начала и датой окончания.

Чтобы зафиксировать изменение «Типа 1», вам нужно будет добавить поле в таблицу «Магазин» для отслеживания «Последнего бизнес-идентификатора». Это поле будет содержать последнюю версию бизнес-ключа. Если изменений нет, Store Business ID и Latest Business ID будут содержать один и тот же ключ. Если магазины объединятся, все записи 8897, 8965, 9135 и 9700 будут содержать «Последний идентификатор компании» 9700.

В результате можно как «путешествовать во времени» (воспроизвести точную историю в любой период), так и сгруппировать по последней версии магазина.

Таблицы фактов уже содержат данные, относящиеся к магазинам с SK 1, 2 и 3 (ID 8897, 8965 и 9135), поэтому вы можете оставить таблицы фактов без изменений, и у вас всегда будут данные о прошлой работе этих магазинов. до того момента, когда они были сняты с производства.

Когда появится этот новый магазин (ID 9700), вы можете добавить его как новую строку (SK 4) в измерении Store, установить его как активную строку и установить «прекращенные» строки магазина как неактивные (вы можете использовать логический столбец для это, например, «isActive» или «версия»). С этого момента все данные, загруженные в таблицы фактов, будут указывать на магазин с SK 4 (ID 9700).

До этого момента у него были данные только для SK 1, 2 и 3 (ID 8897, 8965 и 9135). По этой причине вы всегда сможете просматривать данные из прошлых и/или текущих хранилищ, используя поле isActive в измерении Store, когда вы соединяете его с таблицами фактов (используя SK).

Это известно как медленно меняющееся измерение типа 2:

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

Редактировать: относительно второй части вашего вопроса: "требуемая гибкость заключается в том, что я мог бы получить его для 9700 до того, как 9700 существовал в истории, объединив SK 1, 2 и 3"

Одним из простых вариантов было бы ввести иерархию (родительский магазин -> магазин) в измерение «Магазин» и для каждого из других магазинов установить в поле «Идентификатор родительского магазина» значение 9700. Таким образом, вы можете просматривать данные о продажах конкретно для каждого прошлых магазинов, используя их идентификаторы, или просто изучите данные для родительского магазина (родительский ID = 9700), которые предоставят совокупное представление всех данных для всех магазинов под родительским 9700.

Это дает дополнительное преимущество, заключающееся в том, что данные в измерении «Магазин» точно отражают то, что произошло: магазины были объединены в единую сущность, и ни по одному из них не были потеряны исторические данные (что могло произойти, если мы перезапишем их идентификаторы).