Обработка дубликатов первичного ключа при загрузке хранилища данных

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

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

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

Я рассмотрел альтернативу создания столбца BIT, где 0 — нормальное значение, а 1 — обратное, а затем сделать PK идентификатором транзакции и столбцом BIT.

Мой вопрос: это хорошая практика, и кто-нибудь еще сталкивался с чем-то подобным? Для справки, это система обработки платежей, поэтому значения не будут изменены, поэтому будут только транзакции и отмены.


data-warehouse ssis etl
person Meff    schedule 30.04.2010    source источник

Ответы (2)


arrow_upward
4
arrow_downward

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

dimTransactionType будет выглядеть примерно так:

TransactionTypeKey  integer
TransactionTypeName  varchar(20)

и было бы

0, 'unknown'
1, 'normal'
2, 'reversal'

Не рекомендуется возиться с битами и флагами в DW - как можно больше подробностей.

person Damir Sudarevic    schedule 30.04.2010

arrow_upward
2
arrow_downward

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

person jamz    schedule 01.05.2010