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

Question

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

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

Answer 1

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

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

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

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

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

Answer 2

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

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

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