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

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

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

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

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

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

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

ADD AVG ( WEIGHT ) AS AVWT

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

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

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

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

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

12.6. Ортогональное проектирование (небольшое отступление от темы)

в этом разделе мы кратко рассмотрим другой принцип проектирования баз данных, который напрямую не связан с дальнейшей нормализацией, но очень похож на нее тем, что также является научным. Он называется принципом ортогонального проектирования (principle of orthogonal design). Обратимся к рис. 12.7, на котором представлена безусловно плохая, но вполне допустимая структура представления данных о поставщиках. Здесь переменная-отношение SA соответствует поставщикам, которые находятся в Париже, а переменная-отношение SB соответствует поставщикам, которые либо не находятся в Париже, либо имеют статус выше 30 (т.е. предикаты этих переменных-отношений имеют именно такой смысл). Как следует из рисунка, подобная структура характеризуется некоторой избыточностью, точнее говоря, в ней дважды представлен кортеж для поставщика с номером S3 (по одному в каждой переменной-отношении).

Отметим, что данный кортеж должен находиться в обеих переменных-отношениях. Допустим обратное, т.е. что он находится в переменной-отношении SB, но отсутствует в переменной-отношении SA. Применив допущение замкнутости мира к переменной-отношению SA, можно сделать вывод, что поставщик с номером S3 не находится в Париже. Однако данные в переменной-отношении SB свидетельствуют об обратном, т.е. о том, что он находится в Париже. Иначе говоря, мы получили противоречие и, следовательно, база данных находится в противоречивом состоянии.

/* Поставщики в Париже */

???5

/* Поставщики не из Парижа или со статусом, равным 30 */

Рис. 12.7. Плохая, но вполне допустимая структура представления данных о поставщиках

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

Принцип ортогонального проектирования {исходная версия). Никакие две переменные-отношения в базе данных не должны иметь перекрывающихся смысловых значений.

Здесь можно сделать следующие дополнительные замечания.

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

2. Обратите внимание, что две переменные-отношения могут иметь перекрывающееся смысловое значение только в том случае, если они имеют одинаковые типы (т.е. одинаковые заголовки).

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

Однако в настоящее время при вставке кортежа обычно требуется указывать имя той переменной-отнощения R, в которую кортеж вставляется. Но это нисколько не противоречит предыдущему высказыванию, так как, по сути, имя R является всего