Разработка Data Mart - Лучшая практика. Почему не используются внешние ключи?

Question

Я работаю над проектом, где меньший datamart (может быть, 30 таблиц) был реализован с нуля.Теперь коллега с глубоким знанием этого рынка собирается сделать еще один проект, оставив меня одного в этом проекте (при некоторой его поддержке).

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

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

Когда я спрашиваю, почему это так (без связей между таблицами)Я получил ответ: «Это из-за производительности».

Обычно это решают так?Если нет, то как решить это с отношениями и все же с хорошими показателями?

Answer 1

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

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

Внешние ключи также имеют ряд недостатков:

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

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

Вас могут заинтересовать следующие вопросы:

• Как документировать базу данных
• Как вы документируете свою структуру базы данных?

Answer 2

Джастин дал хороший ответ на вопрос, почему DWH может быть сконструирован таким образом.

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

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

В настоящей схеме «звезда» таблицы измерений не связаны напрямую друг с другом, а только с таблицами фактов (однако, у вас может быть схема «снежинка»). Обычно вы должны знать, какие измерения ссылаются на какие ключи в таблицах фактов, основываясь на именах полей ключей в таблицах измерений.

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