Когда вы должны денормализовать?

Я думаю, что мы все знакомы с нормализацией базы данных .

Мой вопрос: какие рекомендации вы используете, когда хотите денормализовать таблицы?

Денормализация, когда это операции OLAP, нормализация, когда OLTP (из связанной статьи в разделе Денормализация)

Базы данных, предназначенные для оперативной обработки транзакций (OLTP), обычно более нормализованы, чем базы данных, предназначенные для оперативной аналитической обработки (OLAP). Приложения OLTP характеризуются большим объемом небольших транзакций, таких как обновление записи о продажах в кассе супермаркета. Ожидается, что каждая транзакция оставит базу данных в согласованном состоянии. С другой стороны, базы данных, предназначенные для операций OLAP, в основном представляют собой базы данных «в основном для чтения». Приложения OLAP имеют тенденцию извлекать исторические данные, накопленные за длительный период времени. Для таких баз данных избыточные или «денормализованные» данные могут облегчать приложения бизнес-аналитики. В частности, таблицы измерений в звездообразной схеме часто содержат денормализованные данные. Денормализованные или избыточные данные должны тщательно контролироваться во время обработки извлечения, преобразования, загрузки (ETL), и пользователям не должно быть разрешено просматривать данные, пока они не будут в согласованном состоянии. Нормализованной альтернативой схеме «звезда» является схема «снежинка». Во многих случаях потребность в денормализации уменьшилась, поскольку компьютеры и программное обеспечение СУБД стали более мощными, но, поскольку объемы данных, как правило, увеличивались наряду с аппаратной и программной производительностью, базы данных OLAP часто все еще используют денормализованные схемы.

Денормализация также используется для повышения производительности на небольших компьютерах, таких как компьютеризированные кассовые аппараты и мобильные устройства, поскольку они могут использовать данные только для поиска (например, для поиска цен). Денормализация также может использоваться, когда для платформы (такой как Palm) не существует СУБД или если в данные не вносятся изменения, и быстрый ответ имеет решающее значение.

Нормализуй, пока не болит, денормализуй, пока не заработает (т.е. производительность станет приемлемой)

Одна потенциально разумная причина применить контролируемую денормализацию состоит в том, что она позволяет вам применить некоторые ограничения целостности к данным, которые иначе были бы невозможны. Большинство СУБД SQL имеют крайне ограниченную поддержку ограничений для нескольких таблиц. Иногда в SQL единственным эффективным способом реализации определенных ограничений является обеспечение того, чтобы все атрибуты, включенные в ограничение, присутствовали в одной и той же таблице - даже если нормализация диктует, что они принадлежат отдельным таблицам.

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

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

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

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

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

Вы не можете использовать ограничения CHECK для сравнения столбцов в разных строках или в разных таблицах, если только вы не заключаете такие функции в скалярные пользовательские функции, вызываемые из ограничения CHECK. Что, если вам действительно нужно сравнивать столбцы в разных строках или в разных таблицах, чтобы применить бизнес-правило? Например, предположим, что вы знаете рабочее время врача и хотите убедиться, что все встречи соответствуют рабочим часам? Конечно, вы можете использовать триггер или хранимую процедуру для реализации этого бизнес-правила, но ни триггер, ни хранимая процедура не могут дать вам 100% гарантии того, что все ваши данные чисты - кто-то может отключить или сбросить ваш триггер, введите некоторые грязные данные, и повторно включить или воссоздать ваш триггер. Также кто-то может напрямую изменить вашу таблицу, минуя хранимые процедуры.

Позвольте мне продемонстрировать, как реализовать это бизнес-правило, используя только ограничения FK и CHECK - это гарантирует, что все данные удовлетворяют бизнес-правилу, пока все ограничения являются доверенными.

Еще один пример - способ обеспечить, чтобы периоды времени не имели пропусков и не перекрывались .