суррогатные ключи и ссылочная целостность в EDW

Question

обзоре Проблемы
При принятии в стиле Инмона 3NF Enterprise Data Model, что некоторые общие методы для обработки суррогатных ключей и ссылочной целостности? В моем случае я должен заполнить модель данных 3NF, которая предоставляет «корпоративный вид» нескольких транзакционных систем. Кроме того, каждый OLTP распределяется таким образом, что для каждой страны имеется один экземпляр. Таким образом, проблема, с которой я столкнулся сейчас, заключается в объединении каждой исходной системы в единую модель данных.

Актуальна
Поскольку каждая страна имеет свой собственный «местный» PK мне нужна стратегия разрешения конфликтов при консолидации их в EDW. Наиболее распространено ли просто создавать составной ключ в этом случае? например source_id + source_country или лучше было бы сгенерировать здесь суррогатный ключ?

Например:

A.foobar
ID
описание
...

B.foobar
ID
описание
...

бы стать:

EDW.foobar
ID
foobar_id
source_country
описание

Так что в сводных моделях данных мы в конечном итоге с новым суррогатным ключом (ID), который уникально идентифицирует каждую запись источника (foobar_id + source_country). Это кажется логичным, но по какой-то причине кажется неправильным. И, кроме того, отсюда мой вопрос, какое влияние это будет иметь на обработку ссылочной целостности в EDW? т. е. если мы создадим новые суррогатные ключи между источником 3NF & EDW 3NF, тогда добавлена ​​сложность ссылки на эти новые ключи по схеме EDW. Что касается реализации ETL, это означало бы необходимость искать вновь сгенерированный ключ суррогата через существующую FK (исходную систему), а затем заменять его как новый FK. Это означает сохранение нескольких FK (один для поиска нового суррогатного ключа и самого нового суррогатного ключа) в EDW, который кажется очень далеким.

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

N.B.
Большинство исследований, которые я провел, относится конкретно к заполнению витрин данных в стиле Кимбалла, а не к модели данных Enterprise 3NF от Inmon. Более того, я изо всех сил пытался найти что-нибудь полезное в деле консолидации распределенных баз данных, в результате чего базовая схема одинакова.

Answer 1

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

какое влияние это будет иметь на обработку ссылочной целостности в EDW?

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

Вот старая дискуссия на тему суррогата против бизнес-ключей, которые хорошо стоит прочитать: Surrogate vs. natural/business keys

Answer 2

Если у вас есть вполне хороший ПК для вашей таблицы стран и у вас есть еще один объект, который образует 1-1 отношения со странами, то, во что бы то ни стало, использовать PK страны как ПК этого лица. Он также будет служить ссылкой FK на таблицу стран. Это создает отношения идентичности. То есть отношения между страной и этим другим субъектом настолько сильны, что личность страны также формирует личность этой организации.

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