Физическая таблица Pkey in Fact - PullRequest
0 голосов
/ 14 октября 2018

Я был на собеседовании.Я сделал некоторый код для них, и они были заинтересованы в том, почему в таблице фактов нет PKEY, почему есть дублирующиеся данные.На мой взгляд, FACT хранит внешние ключи от dim, и нет необходимости в физическом PKEY.И на очевидном месте столбец внешнего ключа будет иметь дубликаты.Это его цель.Чтобы показать мне разные факты на разных этапах.Теперь, по логике, какой-то составной ключ может выступать в качестве первичной таблицы фактов, но будет ли хорошим сценарием иметь его как физический в базе данных.

Подводя итог моему вопросу.1. Должен ли FACT иметь первичный ключ физически?2. Можем ли мы иметь физическую PKEY на множестве столбцов fkey (я не думаю, что ms sql позволит это)?3. Должен ли FACT иметь суррогатный ключ только для пки?У нас может быть заказ по другому важному столбцу, например по дате?

Ожидается ответ. Хотите узнать другое мнение по этому вопросу.

1 Ответ

0 голосов
/ 14 октября 2018

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

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

Исключениями из этого обобщения являются:

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

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

...