Необходимы ли ограничения внешнего ключа между фактами и измерениями в схеме типа «звезда»?

Question

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

ОБНОВЛЕНИЕ: Для интересующихся я наткнулся на опрос , задающий тот же вопрос.

Answer 1

Большинство хранилищ данных (DW) не имеют внешних ключей, реализованных в качестве ограничений, потому что:

• В общем случае ограничение внешнего ключа срабатывает при: вставке в таблицу фактов,любые обновления ключа и удаление из таблицы измерений.

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

• Один разтаблицы загружаются, DW по существу только для чтения - ограничение не срабатывает при чтениях.

• Любые необходимые индексы восстанавливаются после загрузки.

• Удаление в DW является контролируемым процессом.Перед удалением строк из измерений таблицы фактов запрашивают ключи удаляемых строк - удаление допускается, только если эти ключи не существуют ни в одной из таблиц фактов.

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

Answer 2

Мы используем их, и мы довольны этим.

Является ли хорошей практикой использование внешних ключей в хранилище данных (связи)?

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

Наличие ограничения может отлавливать ошибки ETL и дефекты моделирования.

Answer 3

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

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

Answer 4

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

Answer 5

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

Answer 6

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

Answer 7

Надеюсь, эта тема все еще активна. Я думаю: для больших таблиц фактов со многими измерениями и записями внешние ключи замедляют вставки и обновления, так что таблица фактов становится слишком медленной для загрузки, особенно с увеличением размера. Индексы используются для запроса ПОСЛЕ загрузки таблицы, поэтому их можно отключить во время вставки / обновления, а затем перестроить. Внешний ключ RELATION важен НЕ сам внешний ключ: это действительно подразумевается в процессе ETL. Я обнаружил, что внешние ключи делают вещи слишком медленными в реальном мире Datawarehouse. Вам необходимо использовать ВИРТУАЛЬНЫЙ внешний ключ: отношение является их, но не ограничением. Если вы повредите отношения с внешним ключом в Datawarehouse, вы делаете что-то не так. Если вы отключите их во время вставки, и в случае несоответствия или сироты, вы не сможете снова включить их, так какой смысл. Весь смысл DW - быстрый доступ и запросы. Внешние ключи делают это невозможным. Интересная дискуссия: не легко найти этот вопрос в Сети Кев