Вторая нормальная форма

работниканомер социального страхования (social security number, SSN). И,денти-фикаторы обоих типов являются уникальными и назначаются правительством в целях упрощения налогообложения. Каждый разработчик трудится по фиксированной ставке (число долларов в час). Эта ставка зависит от вида выполняемой работы (столбец orWork). В столбце Quantity указано количество часов, затраченных на выполнение проекта.

CREATE TABLE work {

Project INT(11) NOT NULL, ProjectName VARCHAR(64), ContractorSSN VARCHAR(16) NOT NULL, ContractorName VARCHAR(64), ContractorWork VARCHAR(16), ContractorRate DECIMAL(6, 2) , Quantity DECIMAL(6,2), PRIMARY KEY(Project, ContractorSSN)

Эта таблица находится в первой нормальной форме, но не во второй. Приведем пример. Представьте двух разработчиков, занимающихся одним и тем же проектом. Соответственно, название проекта повторится дважды. Оно зависит только от идентификатора проекта, т.е. от половины первичного ключа. То же самое можно сказать о столбцах ContractorName и ContractorRate.

Чтобы устранить дублирование, необходимо перенести информацию о проектах и разработчиках в отдельные таблицы. В листинге 8.4 исходная таблица разбита на три составляющие. В таблице work содержатся три столбцам ect, ContractorSSN и Quantity. Первичный ключ тот же, что и прежде, но теперь столбцы Project и ContractorSSN являются внешними ключами. Название проекта хранится в таблице proj ect, а имя разработчика и процентная ставка - в таблице contractor.

CREATE TABLE work (

Project INT (11) NOT NULL,

ContractorSSN YARCHAR(16) NOT NULL,

Quantity DECIMAL(6,2),

PRIMARY KEY(Project, ContractorSSN),

EOREIGN KEY(Project) REFERENCES project(ID),

FOREIGN KEY(ContractorSSN) REFERENCES contractor(SSN)

CREATE TABLE project (

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

CREATE TABLE contractor

SSN VARCHAR (16) NOT NULL, Name VARCHAR(64), WorkType VARCHAR(16), Rate DECIMAL (6, 2) , PRIMARY KEY(SSN)

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

На рис. 8.1 изображена схема отношений между тремя таблицами.

Contractor

Рис у. Диаграмма табличных связей

Третья нормальная форма

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

Рассмотрим таблицу contractor в листинге 8.4. Столбец WorkType описывает вид выполняемой работы. Одни разработчики пишут программы на С, другие - готовят иллюстрации. Эти задачи оплачиваются по-разному. По сути, зная вид работы, можно определить процентную ставку. Правда, здесь применяется правило бизнес-логики: работа конкретного вида всегда оплачивается одинаково.

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

CREATE TABLE contractor (

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

FOREIGN KEY(WorkTYpe) REFERENCES WOrktype{ID)

CREATE TABLE worktype ID VARCHAR(16),

Нормальная форма Бойса-Кодда 103

Rate DECIMAL(6,2), PRIMARY KEY(ID)

Нормальная форма Бойса-Кодда

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

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

CREATE TABLE software (

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

FOREIGN KEY(Cabinet) REFERENCES cabinet(ID), 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)

Таблица ware не находится в форме Бойса-Кодда, потому что по идентификатору служащего можн о определить архив. Обратите внимание на то, что столбца title недостаточно для идентификации записей, потому что в двух архивах могут находиться копии одной и той же программы. Точно так же один служащий может одновременно заказать несколько программ.

Решение, переводящее таблицу software в форму Бойса-Кодца, заключается в удалении из нее столбца Cabinet. Столбцов Title и Employee достаточно для однозначной идентификации записей. Новые определения таблиц приведены в листинге 8.7.