Измерение сотрудника сокращается каждый день в Datawarehouse

Question

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

Столбцы, которые отслеживают эти изменения, вступают в силу& эффективная последовательность. У нас также есть таблица аудита, которая помогает нам определять, какие записи обновляются, вставляются и удаляются каждый день, сравнивая таблицы за сегодняшний день и за предыдущий день.

Мой вопрос заключается в том, как я могу выполнить добавочную загрузкуна столе в моем промежуточном слое, поэтому суррогатный ключ, который является столбцами идентификаторов, остается неизменным. Если я усекаю окончательное измерение, то каждый раз получаю новый суррогатный ключ и, следовательно, он портит мою таблицу фактов.

Answer 1

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

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

Пример: в вашем dim есть 2 записи, сотрудник A и сотрудник B с ключами 1и 2 соотв.На следующий день сотрудник A обновляется до AA, а сотрудник C добавляется.Вы должны быть в состоянии сравнить этот новый набор данных со старым, так что AA все еще имеет ключ 1, B сохраняется с ключом 2, а C добавляется с ключом 3. Конечно, вы не можете полагаться на ключи автоинкремента,и должен установить их из того, что было ранее

Кроме того, остерегайтесь удалений: только потому, что сотрудник удален, это не означает, что факты, относящиеся к этому сотруднику, также исчезают.Не удаляйте запись из таблицы фактов, вместо этого добавьте «удаленный» флаг и установите для него значение Y для удаленных записей.В ваших отчетах отфильтруйте этих удаленных сотрудников, чтобы вы отчитывались только о не удаленных сотрудниках.

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

Ваша проблема, кажется, очень близка к тому, что Кимбалл описывает как медленно изменяющееся измерение типа II, и ваш ETL должен справиться с этим.