В схеме "звезда" необходимы ограничения внешнего ключа между фактами и размерами?
Я получаю свое первое воздействие организации хранилищ данных, и я задаюсь вопросом, это необходимый, чтобы иметь ограничения внешнего ключа между фактами и размерами. Есть ли какие-либо главные оборотные стороны для того, чтобы не иметь их? Я в настоящее время работаю с реляционной схемой "звезда". В традиционных приложениях я привык иметь их, но я начал задаваться вопросом, были ли они необходимы в этом случае. Я в настоящее время работаю в среде SQL Server 2005 года.
ОБНОВЛЕНИЕ: Для заинтересованных я столкнулся с опросом, задав тот же вопрос.
5 ответов
В большинстве хранилищ данных (DW) внешние ключи не реализованы как ограничения, потому что:
В общем, ограничение внешнего ключа срабатывает при: вставке в таблицу фактов, любых обновлениях ключа и удалении из таблица размеров.
Во время загрузки индексы и ограничения сбрасываются для ускорения процесса загрузки, целостность данных обеспечивается приложением ETL.
После загрузки таблиц DW, по сути, доступен только для чтения - ограничение не срабатывает при чтении.
Любые обязательные индексы перестраиваются после загрузки.
Удаление в DW - это управляемый процесс. Перед удалением строк из измерений в таблицах фактов запрашиваются ключи удаляемых строк - удаление разрешено только в том случае, если эти ключи не существуют ни в одной из таблиц фактов.
На всякий случай обычно периодически выполняются запросы для обнаружения потерянных записей в таблицах фактов.
Причины использования ограничений целостности в хранилище данных точно такие же, как и в любой другой базе данных: чтобы гарантировать целостность данных. Предполагая, что вы и ваши пользователи заботитесь о том, чтобы данные были точными, вам нужен какой-то способ гарантировать, что они останутся такими и что бизнес-правила применяются правильно.
Я не знаю, что это необходимо, но считаю, что они подходят для обеспечения целостности данных. Вы хотите убедиться, что ваша таблица фактов всегда указывает на действительную запись в таблице измерений. Даже если вы уверены, что это произойдет, почему бы не сделать так, чтобы база данных проверила ваше требование?
Я думаю, что теоретически вам это нужно. Но это зависит от того, как вы разделяете свои данные по базе данных. Если все они в одной базе данных, внешний ключ может помочь вам, потому что настройка внешнего ключа поможет базе данных быстрее выбирать на основе индексирования. Если вы совместно используют таблицы для многих баз данных, вам нужно проверить их на уровне приложения
База данных может проверить их за вас, но это может быть медленно. И, как правило, в хранилище данных нас не волнует избыточность или целостность. У нас уже есть много данных, и некоторые целостность и избыточность не повлияют на общие агрегированные данные
Мы их используем, и нам это нравится.
Является ли хорошей практикой иметь внешние ключи в хранилище данных (отношения)?
Это накладные расходы, но вы всегда можете отключить ограничение во время загрузки, а затем снова включить его.
Наличие ограничения может выявить ошибки ETL и дефекты моделирования.