Ссылочная целостность в реляционном хранилище данных. Стоит ли оно того? и какие есть альтернативы?

Если бы вам пришлось построить реляционное хранилище данных библейских масштабов с помощью SQL Server 2008, вы бы использовали внешние ключи для обеспечения целостности данных или какие-то другие средства?

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

Есть предположения?

Заранее спасибо.


sql-server data-warehouse database-design referential-integrity
person David    schedule 11.10.2010    source источник
comment
Взгляните на похожий вопрос/ответ.   -  person Damir Sudarevic    schedule 11.10.2010
comment
Не уверен, что мне следует добавить сюда или к аналогичному вопросу, но ... Если целостность является проблемой, вы всегда можете исправить функции целостности или хранимые процедуры, которые ищут потерянные факты. (Строки, в которых внешние ключи не имеют смысла). Затем вы можете очистить их после/во время/до следующего цикла загрузки вашей базы данных.   -  person Markus    schedule 12.10.2010

Ответы (3)


arrow_upward
2
arrow_downward

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

person Community    schedule 11.10.2010
comment
Будет нормализованный слой, который фиксирует все детали. После этого будет построен один или несколько слоев, в которые будут загружены сводные данные для аналитики. - person David; 13.10.2010
comment
Из-за потенциального размера хранилища и того факта, что мы не знаем, как эти (медицинские) данные будут использоваться в будущем, нам необходимо хранить детали в первом слое в нормализованной форме. - person David; 13.10.2010
comment
Звездообразные схемы редко бывают значительно больше, чем те же данные, хранящиеся реляционно, потому что денормализация, используемая при построении звездообразной схемы, применима только к измерениям, которые обычно на несколько порядков меньше, чем таблицы фактов. - person ; 13.10.2010
comment
Сказав все это, если вы привержены созданию действительно реляционного хранилища данных, то да, я бы определенно использовал внешние ключи. - person ; 13.10.2010

arrow_upward
1
arrow_downward

О, я бы наверняка! Вы должны помнить, что ваша база данных — это ваше хранилище данных, а не просто хранилище данных для внешнего интерфейса. Это небольшая разница, но она важна, когда вы начинаете думать о будущем. Прямо сейчас вы (предположительно) владеете приложениями для управления, но кто сказал, что в будущем так и будет?

Загружая как можно больше проверок в базу данных, вы в какой-то мере защищаете свое приложение в будущем — по крайней мере, если кто-то другой попытается разработать для вашей базы данных, больше ваших предположений останется в силе.

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

Надеюсь, это поможет!

person ocharles    schedule 11.10.2010
comment
@aCiD2, ОП спрашивает о хранилище данных. - person ; 11.10.2010
comment
@ Марк, я это понимаю, но влияет ли это на мой ответ? - person ocharles; 11.10.2010
comment
@ aCiD2, я не думаю, что ссылки на интерфейс имеют отношение к хранилищам данных - исходные системы были бы более актуальными. Существует также вопрос о том, должен ли процесс ETL обеспечивать ссылочную целостность — обычно я ожидаю этого, поэтому нет необходимости применять его в схеме БД. Но тогда я обычно не ожидаю использования полностью нормализованной схемы в качестве основы для хранилища данных. - person ; 11.10.2010
comment
Я думаю в том же направлении, что и ACiD2. Хотя в настоящее время мы владеем исходными системами и знаем, что в них существует ссылочная целостность, это не всегда так. Мне нравится подход «установить и забыть», который обеспечивают внешние ключи. - person David; 13.10.2010
comment
Кроме того. Влияет ли размер хранилища на дизайн с точки зрения ссылочной целостности и как вы с этим справляетесь? - person David; 13.10.2010

arrow_upward
1
arrow_downward

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

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

person nvogel    schedule 12.10.2010