Есть ли какая-либо польза от включения отношений в дизайн таблицы звездной схемы?

Question

Я разрабатываю таблицы фактов и измерений для хранилища данных, в настоящее время использующего SQL Server, SSIS и SSAS. Получу ли я реальную выгоду от программирования отношений между размерами и таблицами фактов в SQL? Или мне лучше просто определить отношения вручную, когда придет время создавать кубы?

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

Answer 1

Я интерпретирую «программирование отношений» как значение для ограничения внешних ключей на таблицах.

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

Вы упомянули некоторые проблемы, и еще одна проблема заключается в том, что эти ограничения создают служебные издержки при вставке строк, что сделает процесс ETL более дорогостоящим.

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

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

Answer 2

Я думаю, нам нужно иметь ограничения FK, поскольку обновления DW контролируются «главным образом», но не всегда. Например, ручные исправления данных происходят в случае любых проблем с данными и т. Д. [В идеале это не должно происходить, но .... :)]

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

Если вы считаете время, необходимое для устранения проблем с целостностью данных, наличие FK стоит того.