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

Question

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

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

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

Я рассмотрел альтернативу генерации столбца BIT, где 0 - нормальное значение, а 1 - обратный, с последующим назначением PK идентификатора транзакции и столбца BIT.

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

Answer 1

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

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

TransactionTypeKey  integer
TransactionTypeName  varchar(20)

и будет иметь

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

Поворачивать биты и флаги в DW - не рекомендуется, насколько это возможно.

Answer 2

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