12.5. Денормализация

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

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

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

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

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

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

Что такое денормализация

Кратко говоря, нормализация переменной-отношения R означает ее замену таким множеством проекций R1, Rn для всех возможных значений г переменной-

отношения R, что результатом обратного соединения значений rl, ..., rn проекций Rl, ..., Rn обязательно будет значение г. Конечной целью нормализации является сокраще­ние уровня избыточности данных за счет приведения проекций R1, Rn к макси­мально высокому уровню нормализации (т.е. к 5НФ).

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

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

р#	PNAME	COLOR	WEIGHT	CITY	S#	QTY
PI	Nut	Red	12.0	London	Si	300
PI	Nut	Red	12.0	London	S2	300
P2	Bolt	Green	17.0	Paris	Si	200
|P6	Cog	Red	19.0	London	81	100

Рис. 12.6. Денормалюованные данные о товарах и поставках

Другие проблемы

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

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

SUMMARIZE Р PER Р { COLOR } ADD AVG j WEIGHT ) AS AVWT

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

SUMMARIZE PSQ { Pi, COLOR, WEIGHT } PER PSQ { COLOR }

ADD AVG ( WEIGHT ) AS AVWT

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

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

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

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

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