CREATE TABLE software {

Title VARCHAR (32) NOT NULL, Employee INT (11), CheckedOut ENUM(У ,N) , PRIMARY KEY(Title, Employee),

FOREIGN KEY(Employee) REFERENCES employee(ID)

CREATE TABLE employee (

ID INT (11) NOT NULL AUTO INCREMENT, Name VARCHAR(64), Cabinet INT(11) NOT NULL, PRIMARY KEY(ID),

FOREIGN KEY(Cabinet) REFERENCES cabinet(ID)

Четвертая нормальная форма

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

Рассмотрим диаграмму на рис. 8.2. Программа работает с ресурсами двух видов: библиотеками функций и конфигурационными файлами. Это, в частности, справедливо для утилит MySQL. Большинство из них использует клиентскую библиотеку MySQL, а также библиотеку о языка С, храня при этом конфигурационные установки в

Рис. 8.2. Многоцелевая промежуточная таблица В листинге 8.8 описаны таблицы, соответствующие этой диаграмме.

CREATE TABLE program (

ID INT(11) NOT NULL AUTO INCREMENT, Name VARCHAR(32), PRIMARY KEY(ID)

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

CREATE TABLE resource (

ID INT(11) NOT NULL AUTO INCREMENT, Program INT(11) NOT NULL, Library INT (11), ConfigFile INT (11), PRIMARY KEY(ID),

FOREIGN KEY(Program) REFERENCES program{ID),

FOREIGN KEY(Library) REFERENCES library(ID), FOREIGN KEY(ConfigFile) REFERENCES configfile(ID)

AUTO INCREMENT,

CREATE TABLE library ( ID INT (11) NOT NULL Name VARCHAR(32), PRIMARY KEY(ID)

CREATE TABLE configfile (

ID INT (11) NOT NULL AUTO INCREMENT, Name VARCHAR(32), PRIMARY KEY(ID)

Суть проблемы локализована в таблице resource и заключается в том, что в столбцах внешних ключей разрешены значения NULL. Это подразумевает их необязательность. С логической точки зрения необязательная связь между программой и ее ресурсами порождает неопределенность записей в таблице. Предположим, программа работает с одной библиотекой и одним файлом ресурсов. Тогда в таблицу следует добавить строку с соответствующими значениями в столбцах Library и ConfigFile. Но можно поступить иначе: добавить две записи, в которых одно из значений устанавливается явно, а другое равно NULL.

Когда программа перестает работать с библиотекой, возникает неприятная проблема. Внесение изменений в таблицу зависит от того, каким образом в нее добавлялись записи. Потребуется либо инструкция UPDATE, либо DELETE.

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

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

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

значение имеет скорость вычислений.

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

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

вы берете на себя обязанность поддерживать целостность базы данных программным путем. В большинстве случаев на это пойти легко, потому что в приложениях есть определенные средства контроля целостности. Например, таблица адресов может содержать столбец с обозначениями штатов. Ему можно присвоить тип CHAR (2). Приложение будет выдавать пользователям полные названия штатов, но в запросах указывать двухбуквенные коды. В распоряжении приложения будет внутренняя таблица соответствий между полными названиями и кодами. Это хорошее решение, поскольку в обозримом будущем в США не предвидятся внутриполитические реформации.

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

CREATE TABLE contractor (

SSN VARCHAR (16) NOT NULL, Name VARCHAR (64) , WorkType INT(11) PRIMARY KEY (SSN) ,

FOREIGN KEY(WorkType) REFERENCES worktype(ID)

CREATE TABLE worktype (

ID INT (11) NOT NULL AUTO INCREMENT, Name VARCHAR(16) NOT NULL, Rate DECIMAL(6,2) , PRIMARY KEY(ID)

Объединения, включающие более трех таблиц, сложнее выполнять человеку, чем СУБД. Не стоит недооценивать способность MySQL эффективно выполнять объединения при наличии правильного набора индексов. Крупные объединения можно оптимизировать путем добавления индексов или изменения порядка таблиц в инструкции SELECT. Это сложнои утомительно, но зато это можно сделать один раз, после чего программа всегда будет работать оптимальным образом.

Во многих СУБД поддерживаются подчиненные запросы: инструкции SELECT, размещаемые в скобках. В MySQL понятие подчиненного запроса отсутствует, но есть временные таблицы. Можно выполнить часть объединения и поместить его результат во временную таблицу. В главе 13, Инструкции SQL , приводится описание инструкции CREATE TABLE, где рассказывается о том, как создать таблицу по результатам работы инструкции SELECT.