Я разрабатываю таблицы Fact и Dimension для хранилища данных, в настоящее время использующего SQL Server, SSIS и SSAS. Получу ли я реальную пользу от программирования взаимосвязей между измерениями и таблицами фактов в SQL? Или мне лучше просто определить отношения вручную, когда придет время создавать кубы?
Кажется, что проще загружать и преобразовывать данные, если у меня нет никаких ограничений на вставку данных в таблицы и, следовательно, не учитывать отношения.
Я интерпретирую «программирование отношений» как означающее наложение ограничений внешнего ключа на таблицы.
Нет, в хранилище данных вы не должны накладывать ограничения первичного или внешнего ключа на таблицы фактов.
Вы упомянули некоторые проблемы, и еще одна проблема заключается в том, что эти ограничения увеличивают производительность при вставке строк, что делает процесс ETL более дорогим.
Для кого-то, кто знаком только с проектированием транзакционных баз данных, это может идти вразрез со всем, что он узнал и испытал. Ограничения внешнего ключа жизненно важны для баз данных, в которых несколько процессов изменяют данные одновременно. Существует определенный риск того, что два процесса каким-то образом испортят данные, несмотря на все усилия разработчиков. Ограничения — это принципиально важная система безопасности.
В многомерной модели база данных заполняется только одним процессом ETL и строго контролируется. Это значительно снижает риск повреждения данных до такой степени, что дополнительные затраты на ограничения просто не стоят того.
Я думаю, нам нужно иметь ограничения FK, поскольку обновления DW «в основном» контролируются, но не всегда. Например, ручное исправление данных происходит в случае каких-либо проблем с данными и тому подобного. [В идеале этого не должно происходить, но.... :)]
Чтобы ключи не влияли на производительность, мы можем отключить их перед загрузкой и снова включить. Это может дать нам уверенность в правильности данных, а также устранить любые проблемы с производительностью во время загрузки. Следует также помнить, что время обработки не является серьезным ограничением для большинства хранилищ данных.
Если учесть время, необходимое для устранения потенциальных проблем с целостностью данных, наличие FK того стоит.
