в этой главе:

Денормализация: что, зонем и когда?

Методы реализации с)елор.мал11зацхи1

Д/ЛУ * способы осгрцествлепия депорма.тзацхт

Принятие решения о денормализации

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

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

Денормализация: что, зачем и когда?

Денормализация - это процесс достижения компромиссов в нормализованных таблицах посредством намеренного введения избыточности в целях увеличения производительности.

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

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

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

К сведению

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

Как правило, денормализация уменьшает время запроса за счет DML-операций (вставки, обновления и удаления) (рис. 4.1). Считайте денормализацию расширением нормализованной модели данных, которое повысит производительность запросов. Определите, что является наиболее важным для приложения, и обязательно отразите все решения (с обоснованием) в журнале проектирования. Помните, что, кроме денормализации, существуют и другие пути повышения производительности. Например, можно внести изменения в схемы индексирования и модульную структуру программы.

Рис 4 1 Чувствительные весы денормализации