Это - хорошая практика, чтобы иметь внешние ключи в datawarehouse (отношения)?
Я думаю, что вопрос достаточно ясен. Некоторые столбцы в моей datawarehouse таблице могли иметь отношения к первичному ключу. Но это - хорошая практика? Это денормализовывается, таким образом, это никогда не должно удаляться снова (данные в datawarehouse). Вопрос о надежде достаточно несколько ясен.
5 ответов
Понятия не имею. Но никто не отвечает, поэтому я погуглил и нашел документ о передовых методах , который, кажется, говорит очень полезное «это зависит от обстоятельств»: -)
Хотя ограничения внешнего ключа помогают целостности данных, они сопряжены с расходами для всех операторов вставки, обновления и удаления. Уделяйте особое внимание использованию ограничений в вашем хранилище или ODS, если вы хотите обеспечить целостность и проверку данных
Причина использования ограничения внешнего ключа в хранилище данных такая же, как и для любой другой базы данных: для обеспечения целостности данных.
Также возможно, что производительность запросов повысится, поскольку внешние ключи позволяют перезаписывать определенные типы запросов, которые обычно невозможны без них. Однако целостность данных по-прежнему является основной причиной использования внешних ключей.
Ограничения FK хорошо работают в многомерных моделях Кимбалла на SQL Server.
Как правило, ваш ETL должен будет искать в таблице измерений (обычно на бизнес-ключе для обработки медленно меняющихся измерений), чтобы определить суррогатные идентификаторы измерения, и суррогатный идентификатор измерения обычно является идентификатором, а PK для измерения обычно суррогатный идентификатор измерения, который уже является индексом (возможно, сгруппированным).
Наличие RI на этом этапе не вызывает больших накладных расходов при записи, поскольку также может помочь выявить дефекты ETL во время разработки. Кроме того, наличие PK таблицы фактов, представляющей собой комбинацию всех FK, также может помочь отловить потенциальные проблемы моделирования данных и двойной загрузки.
Это может фактически снизить накладные расходы на выборку, если вы хотите сделать общие плоские представления или функции с табличными значениями своих звездообразных моделей. Поскольку дополнительные внутренние соединения с измерениями гарантируют создание одной и только одной строки, оптимизатор может очень эффективно использовать эти ограничения, чтобы исключить необходимость поиска в таблице. Без ограничений FK эти поиски могут потребоваться для исключения фактов, в которых измерение не существует.
Я предполагаю, что вы ссылаетесь на FK в таблицах фактов. Во время загрузки DW индексы и все внешние ключи удаляются для ускорения загрузки - о ключах заботится процесс ETL.
Ограничение внешнего ключа «активируется» во время вставок и обновлений (это когда необходимо проверить, существует ли значение ключа в родительской таблице) и во время удаления первичных ключей в родительских таблицах. Это не играет роли во время чтения. Удаление записей в DW является (должно) управляемым процессом, который сканирует любые существующие отношения перед удалением из таблиц измерений.
Таким образом, большинство DW не имеют внешних ключей, реализованных в качестве ограничений.
Вопрос ясен, но "хорошая практика" кажется неправильным вопросом.
"Может ли иметь FK" ?
Внешние ключи - это механизм сохранения ограничений целостности при модификации базы данных.
Если ваша DW работает только на чтение (накапливая данные источников без записи обратно), то FK не нужны.
Если ваша DW поддерживает запись, константы целостности обычно должны быть скоординированы между участвующими источниками данных с помощью ETL (скорее, это эквивалент Store). Этот процесс может опираться или не опираться на FK в базе данных.
Поэтому правильным вопросом будет: нужны ли они вам или нет.
(Единственная другая причина, о которой я могу думать, это документирование отношений - однако, это можно сделать и на бумаге / в отдельном документе)
.