Главная » SQL, Базы данных » ОБЩИЕ СВЕДЕНИЯ О ДЕНОРМАЛИЗАЦИИ

0

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

выполнить денормализацию. При этом используются доводы, подобные перечисленным ниже.

6.           Полная нормализация приводит к появлению большого количества логически не зависимых переменных отношения (и предполагается, что рассматриваемые пере менные отношения являются базовыми).

7.           Большое количество логически независимых переменных отношения приводит к появлению большого количества отдельно хранимых физических файлов.

8.           Большое количество отдельно хранимых физических файлов приводит к появле нию большого количества операций ввода-вывода.

Строго говоря, эти доводы, конечно же, не верны, поскольку (как многократно отмечалось в данной книге) в определении реляционной модели нигде не утверждается, что базовые переменные отношения должны находиться во взаимно однозначном соответствии с хранимыми файлами. Поэтому денормализацию в случае необходимости следует выполнять на уровне хранимых файлов, но не на уровне базовых переменных отношения3. Однако в некотором отношении эти доводы все же верны для современных продуктов SQL, поскольку именно в них эти два уровня не разделены в требуемой степени. В данном разделе понятие "денормализация" будет рассмотрено более подробно.

Примечание. Материал этого раздела в значительной степени основан на [13.6].

Общее определение денормализации

Напомним, что нормализация переменной отношения R означает ее замену множеством таких проекций Rl, R2, …, Rn, что результатом обратного соединения проекций Rl, R2, …, Rn обязательно будет значение R. Конечной целью нормализации является сокращение степени избыточности данных за счет приведения проекций Rl, R2, …, Rn к максимально высокому уровню нормализации.

Теперь можно перейти к определению понятия денормализации. Пусть Rl, R2,  Rn

является множеством переменных отношения. Тогда денормализацией этих переменных отношения называется такая замена переменных отношения их соединением R, что для всех возможных значений i (где i = 1, …, п) выполнение проекции R по атрибутам Ri  обязательно  снова  приводит  к  созданию  значений  Ri.  Конечной  целью  денормализации является увеличение степени избыточности данных за счет приведения переменной отношения R к более низкому уровню нормализации по сравнению с исходными переменными  отношения Rl, R2, …, Rn. Точнее, преследуется цель сократить количество  соединений, которые потребуется выполнять в приложении на этапе прогона, поскольку (в действительности) некоторые из этих соединений уже выполнены заранее в составе работ по проектированию базы данных.

3  Это замечание фактически является не совсем точным; денормализация — это операция с переменными отношения, а не с хранимыми файлами и поэтому не может применяться "на уровне  хранимых файлов". Но предположение о том, что некоторый аналог денормализации может выполняться на уровне хранимых файлов, отнюдь не лишено смысла.

Рис. 13.6. Денормализованные данные о деталях и поставках

В качестве примера рассмотрим денормализацию переменных отношения деталей и поставок для получения переменной отношения4 PSQ, представленной на рис. 13.6. Следует отметить, что переменная отношения PSQ находится в 1НФ, а не в 2НФ.

Некоторые проблемы денормализации

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

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

SUMMARIZE P BY { COLOR } ADD AVG ( WEIGHT ) AS AVWT

Но при использовании денормализованного проекта, показанного на рис.  13.6,  эта формулировка, которая показана ниже, становится несколько сложнее (не говоря уже о том, что в такой ситуации предполагается наличие по крайней  мере  одной поставки для каждой детали, что представляет собой достаточно смелое и в общем неверное допущение).

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

SUMMARIZE PSQ { Р#, COLOR, WEIGHT } BY { COLOR

} ADD AVG ( WEIGHT ) AS AVWT

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

Третья, и самая главная, проблема формулируется следующим образом. (Это  относится к "правильной" денормализации, т.е. к денормализации, которая  выполняется только на физическом уровне, а также к тому типу  денормализации,  которую иногда приходится осуществлять в современных продуктах SQL.) Когда речь идет о том, что денормализация  "способствует  достижению  высокой  производительности",  фактически подразумевается, что она способствует достижению высокой производительности некоторых конкретных  приложений. Любая выбранная физическая структура, которая прекрасно подходит для одних приложений с точки зрения их производительности, может оказаться совершенно непригодной для других. Например, предположим, что  каждая базовая переменная отношения отображается на один физически хранимый файл, а каждый хранимый файл состоит из физически смежного набора хранимых записей, по одной для каждого кортежа соответствующей переменной отношения. Тогда применительно к данной структуре можно сделать приведенные ниже замечания.

■     Допустим, что соединение отношений поставщиков, поставок и деталей представ лено в виде одной переменной отношения, т.е. в виде одного хранимого файла. Тогда запрос "Получить сведения обо всех поставщиках деталей красного цвета" благодаря выбранной физической структуре будет, по-видимому, выполняться достаточно эффективно.

■     Однако запрос "Получить сведения о поставщиках из Лондона" при такой физи ческой структуре будет выполняться менее эффективно по сравнению со струк турой, состоящей из трех отдельных базовых переменных отношения, каждая из которых отображена на физически отдельный хранимый файл. Дело в том, что в последнем случае все записи с данными о поставщиках являются физически смежными, а в первом случае данные будут распределены на большем участке уст ройства хранения и для их выборки потребуется существенно больше операций ввода—вывода. Аналогичные замечания можно высказать по отношению ко всем запросам, в которых доступ осуществляется только к данным о поставщиках, дета лях или поставках по отдельности (без выполнения операции соединения).

Источник: Дейт К. Дж., Введение в системы баз данных, 8-е издание.: Пер. с англ. — М.: Издательский дом «Вильямс», 2005. — 1328 с.: ил. — Парал. тит. англ.

По теме:

  • Комментарии