Правильно ли иметь внешние ключи в хранилище данных (отношения)?

Ответ 1

Я понятия не имею. Но никто не отвечает, поэтому я googled и нашел статью по лучшим практикам, которая, кажется, очень помогает "это зависит": -)

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

Ответ 2

Ограничения FK хорошо работают в размерных моделях Kimball на SQL Server.

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

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

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

Ответ 3

Я предполагаю, что вы ссылаетесь на таблицы FK фактически. Во время загрузки DW индексы и любые внешние ключи отбрасываются для ускорения загрузки - процесс ETL заботится о ключах.

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

Таким образом, большинство DW не имеют внешних ключей, реализованных в качестве ограничений.

Ответ 4

Quesiton ясен, но "хорошая практика" кажется неправильным вопросом.

" Может ли иметь FK"?

Внешние ключи - это механизм для сохранения ограничений целостности при изменении базы данных.

Если ваш DW доступен только для чтения (аккумулируя источники данных без записи), FK не нужно.

Если ваш DW поддерживает записи, целостности целостности, как правило, необходимо координировать через участвующие источники данных с помощью ETL (скорее, это эквивалент Store). Этот процесс может или не может полагаться на FK в базе данных.

Итак, правильный вопрос: нужны ли вам они.

(Единственная причина, по которой я могу думать, это документация о взаимоотношениях, однако это можно сделать и на бумаге/в отдельном документе.)

Ответ 5

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

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

Ответ 6

Использование FK-ограничений в DW похоже на ношение велосипедного шлема. Если ETL спроектирован правильно, вам технически они не нужны. Тем не менее, если бы у меня было миллион долларов за каждый раз, когда я видел безболезненный ETL, у меня были бы нулевые доллары.

Пока вы находитесь в точке, где ограничения FK вызывают проблемы с производительностью, я говорю "leave'em". Очистка проблем ссылочной целостности может быть намного сложнее, чем добавление их из get-go; -)

Ответ 7

Да, как наилучшая практика, реализуйте ограничения FK на ваших таблицах фактов. В SQL Server используйте NOCHECK. В ORACLE всегда используйте RELY DISABLE NOVALIDATE. Это позволяет хранилищу или марку узнать об отношениях, но не проверять его на операции INSERT, UPDATE или DELETE. Преобразования Star, оптимизация и т.д. Не могут полагаться на ограничения FK для улучшения запросов, как они привыкли, но никто не знает, какие инструменты BI или OLAP будут использоваться на лицевой стороне или на вашем складе или в магазине. Некоторые из этих инструментов могут использовать знание отношений. Кроме того, сколько уродливых выглядящих складов вы видели с небольшой или отсутствующей внешней документацией и должны были попытаться перепроектировать их? Определение FK всегда помогает с этим.

Как дизайнеры, мы НИКОГДА не видим, чтобы наши хранилища данных или витрины были самодокументируемыми, как мы должны. Определить FK конечно помогает с этим. Теперь, сказав это, если звездные схемы правильно разработаны без определения FK, их легко прочитать и понять в любом случае.

И для таблиц фактов ORACLE всегда указывайте индекс LOCAL BITMAP на каждом FK для измерения. Просто сделай это. Индексирование на самом деле более важно, чем определено FK.

Ответ 8

Существует очень веская причина для создания ограничений FK даже в DW/DM только для чтения. Да, они действительно не требуются от точки зрения DW только для чтения, если ваш ETL пуленепробиваемый и т.д. И т.д. Но угадайте, что - жизнь не останавливается на данных загрузки в DW. Большинство аналитических/отчетных инструментов BI используют информацию о ваших взаимоотношениях DW для автоматической сборки своей модели (например, табличная модель SSAS). По моему скромному мнению, это одно перевешивает небольшие накладные расходы при снижении и воссоздании ограничений FK во время процесса ETL.