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

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

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

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

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

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

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

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

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

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


data-warehouse star-schema
person Pblade    schedule 31.10.2019    source источник

Ответы (1)


arrow_upward
0
arrow_downward

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

  2. Опять же решено использованием datetime

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

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

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

  1. Вы должны быть более конкретными

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

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

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

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

person Nick.McDermaid    schedule 31.10.2019
comment
Дата или дата и время не имеют значения. Поскольку дата начала новой строки в таблице измерения зависит от хранилища данных, а дата транзакции зависит от системы OLTP. Например: если интервал синхронизации хранилища данных составляет 2 дня, то датой начала новой строки измерения будет день 2, но на самом деле он был фактически создан в день 1, и многие транзакции, связанные с этим, уже произошли. в день 1. Таким образом, если вы используете время транзакции для отслеживания, все транзакции в день 1 потеряют свое измерение. Если вы используете текущий, половина транзакции будет ошибочной. - person Pblade; 01.11.2019
comment
Во-первых: не используйте is_current для поиска суррогатного ключа. Используйте бизнес-ключ в транзакции, которую вы загружаете, и дату и время транзакции между датой начала и окончания SCD. Это означает, что вы можете загружать транзакции в любое время, и он выберет правильный суррогатный ключ. - person Nick.McDermaid; 01.11.2019
comment
Во-вторых: если у вас нет «истинной» даты и времени, с которой член измерения действовал в исходной системе, вы мало что можете сделать. Если вы читаете исходную систему каждые пять дней, а в исходной системе нет индикатора того, когда измерение (скажем, местоположение) стало активным, то вы ничего не можете сделать. Хуже того, если запись менялась дважды за эти пять дней, а первое изменение вы вообще пропустили. - person Nick.McDermaid; 01.11.2019
comment
Вы имеете в виду, что я должен использовать дату создания / дату обновления этой строки в системе OLTP для заполнения столбца начальной даты таблицы SCD типа 2, верно? И если у меня нет этой информации, мне следует отказаться от создания таблицы SCD типа 2, верно? Дело в том, что руководство от группы Kimball, которое я прочитал, предложило мне использовать дату, когда эта строка попала в наш DW. (Совет разработчика 107 - convert (char (10), getdate () - 1, 101), даже функция SSIS SCD типа 2 также использует эту дату для создания таблицы SCD типа 2. Но этот подход никогда не может обеспечить истинную правильность из-за интервал синхронизации хранилища данных. - person Pblade; 01.11.2019
comment
Не сдавайся. Просто осознайте эту проблему и сообщите заинтересованным сторонам как о риске. Я настоятельно рекомендую вам не использовать компонент SSIS SCD. - person Nick.McDermaid; 01.11.2019
comment
Вы должны всегда обновляться из источника как можно чаще. Я никогда не слышал о системе, которая обновлялась бы каждые два дня. Максимум один день. - person Nick.McDermaid; 01.11.2019
comment
Тогда, в конце концов, какую дату и время вы бы посоветовали мне заполнить до начальной даты таблиц dwh scd типа 2? Дата и время создания / обновления OLTP или дата поступления этих строк в хранилище данных? Если вы предлагаете использовать дату из OLTP, тогда, если OLTP не имеет, можно ли использовать дату хранилища данных? Если это действительно так, то я должен увеличить интервал синхронизации, чтобы решить проблему, верно? Я боюсь, что короткий интервал синхронизации может вызвать нагрузку на систему OLTP, поэтому мне нужен более длинный интервал синхронизации. - person Pblade; 01.11.2019
comment
Вы там ответили на свой вопрос. Если возможно, используйте исходную систему. Если этого не существует, используйте дату и время приема. Попробуйте уменьшить задержку исходной системы - person Nick.McDermaid; 01.11.2019
comment
Есть много способов уменьшить нагрузку на исходную систему, т.е. использовать инкрементные нагрузки, использовать реплику только для чтения. На самом деле лучше иметь регулярные управляемые запланированные извлечения из исходных систем, чем иметь неуправляемые дорогостоящие специальные запросы к ним. - person Nick.McDermaid; 01.11.2019