Как получить точный суррогатный ключ для записей поступающих фактов

Question

Я строю хранилище данных для своей компании. Недавно я только что понял, что в моей реализации измерения SCD типа 2 есть некоторые дыры (потенциально очень опасные), так что мне нужно просмотреть их.

Текущее "исходное время" таблицы размеров SCD типа 2это дата, когда оно пришло в хранилище данных, или дата, когда оно заменило более старую запись, и «todate» обычно равно нулю, или дата, когда новая запись с тем же естественным ключом пришла вместо старой записи.

В настоящее время при загрузке факта я получаю суррогатный ключ для этого факта, используя естественный ключ и условие iscurrent = true или todate = null.

Я просто понимаю, что это не гарантирует правильностьсуррогатный ключ для факта, например:

1. Что если изменение произошло в 11:00. Это означает, что половина транзакции, произошедшей в течение этого дня, будет связана со старой записью измерения, но половина из них будет связана с новой записью измерения. Но когда данные поступают в хранилище данных, все транзакции того дня будут обрабатываться как связанные с новым измерением, и это неверно.

2. Если мы используем datetime изтранзакции для более точного получения суррогатного ключа: при загрузке записей фактов в хранилище данных все транзакции, которые произошли до того дня, когда измерение поступило в хранилище данных, не смогут найти суррогатный ключ измерения, связанный с ним. Например: вчера я создал таблицу измерений, поэтому все начальные даты в этой таблице измерений SCD 2 будут иметь минимальное вчерашнее значение, в то время как почти все старые транзакции (которые не были загружены в хранилище данных) произошли раньшеэтот день. Так что у них не будет суррогатного ключа. Такой парадокс.

3. Я даже пытаюсь сделать его более точным, консолидируя дату начала строки, пытаясь передать дату создания этой строки измерения в системе OLTP. Но все же я не могу найти самый правильный способ сделать это. Во-первых, дата и время в хранилище данных и в системе OLTP различаются (поскольку они могут принадлежать разным GMT + X) ...

4. и многим другим проблемам .....

Я понимаю, что если мы хотим отслеживать историю с абсолютно точной точностью, единственный способ - это реализовать ее в системе OLTP, напрямую записав связанный объект в записи транзакций. Хранилище данных не может этого сделать. Но я все еще чувствую, что в концепции SCD 2 слишком много дыр или что я не правильно внедрил систему SCD Typ2 2. Поэтому, пожалуйста, научите меня, если вышеупомянутые проблемы являются нормальными, или укажите ошибку в моем понимании для меня.

Answer 1

1. Если время имеет значение, используйте datetime, а не date. Но сначала подумайте, имеет ли значение время

2. Опять решается с помощью datetime

3. Решите, в каком часовом поясе находится ваше хранилище данных.

   • UTC
   • Исходная система
   • Локальная система
   • Тип данных с учетом часового пояса

Простопримечание: я предлагаю вам использовать 2099-01-01 вместо NULL в качестве конечной даты для текущей записи. Тогда вы легко сможете использовать between при поиске подходящего элемента измерения.

Вам нужно быть более конкретным

Редактировать:

Одно замечание, основанное на комментариях: не используйте Is_Current для поиска суррогатного ключаиспользуйте бизнес-ключ в транзакции и дату транзакции между датой начала и окончания измерения.

Это означает, что вы можете перезагрузить данные за три месяца назад и выбрать правильное измерениеmember (не текущий)

Это подкрепляет мой другой комментарий не использовать NULL в качестве даты окончания активной записи. Вместо этого используйте дату и время в будущее. так что вы всегда можете между этими датами и получить результат