OLAP: Почему все внешние ключи между таблицами фактов и измерений должны быть суррогатными ключами? - PullRequest
Новая
       7

OLAP: Почему все внешние ключи между таблицами фактов и измерений должны быть суррогатными ключами?

2 голосов
/ 21 декабря 2011

Я читаю статью в Википедии о OLAP и OLAP Facts и в статье говорится

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

Но там не указано, почему. Итак, почему

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

Ответы [ 3 ]

3 голосов
/ 21 декабря 2011

Из подробного объяснения того, что такое Таблица размеров из википедии:

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

  • Производительность - обработка объединения намного эффективнее, если используется суррогатный ключ в одном поле,
  • Буфер из практики управления операционными ключами - предотвращает ситуации форм, когда удаленные строки данных могут появиться снова, когда их естественные ключи могут быть повторно использованы или переназначены после длительного периода бездействия,
  • Отображение для интеграции разнородных источников,
  • Обработка неизвестных или неприменимых соединений,
  • Отслеживание изменений значений атрибутов измерения.
1 голос
/ 21 декабря 2011

С трудом заработанные знания.

Ключи от оперативных данных могут изменить формат в любое время.Просто так проще.

Это все равно что спрашивать: «Должен ли я использовать SSN в качестве первичного ключа для users таблицы?».Хотя вы (теоретически) могли бы, это не очень хорошая идея.

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

0 голосов
/ 29 апреля 2013

Я бы никогда не использовал SSN в качестве первичного ключа для любой таблицы.Эта информация требует большой защиты.Использование его в качестве PK означало бы, что оно появится в других таблицах в качестве соединения внешнего ключа.Даже идентификатор сотрудника, который является уникальным для компании и не является компромиссным, не должен использоваться.Суррогатные ключи работают быстрее.Они позволяют установить размер как SCD типа 2. Даже если вы думаете, что нужен только тип 1, что-то может измениться в будущем.

...