Нужны ли суррогатные первичные ключи в таблице фактов в хранилище данных?

Question

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

Мне кажется, что каждая таблица в исходной системе должна иметь PK, даже если это столбец идентификаторов. Учитывая, что хранилище данных (DW) является получателем данных из другой системы, - как бы я мог гарантировать, что данные в DW точно отражают то, что находится в исходной системе, если нет способа связать отдельные записи? Если у вас есть прогоненная программа загрузки, которая запутывает данные и работает в течение недели, как бы вы согласовали различия с исходной системой транзакций без каких-либо уникальных ограничений для сравнения?

Answer 1

http://www.ralphkimball.com/html/controversies.html

Fable:

Первичный ключ таблицы фактов состоит из всех ссылочных внешних ключей измерения.

Факт:

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

Answer 2

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

Но производительность тоже намного хуже. Каждый раз, когда вы просите базу данных получить строки для сотрудников с EmployeeType = 'Manager', вы выполняете сравнение строк. Идентификаторы просто быстрее и лучше.

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