authors >au id aujname aujname address phone

titles

title id-<

name

price

pubdate

pubJd

titleauthors title id-- au Jd

publishers pub id name address

editors

ed id

edjname

edjname

address

phone

Рис. 2.6. Таблица соединения для отношения многий-ко-многим

Что является первичным ключом в таблице titleauthors? Идентификатор автора и идентификатор книги не идентифицируют однозначно строки в таблице titleauthors. В ее столбцах повторяются идентификаторы книг, имеющих больше одного автора, и идентификаторы авторов, написавших несколько книг. Тем не менее уникальной является комбинация идентификатор автора-идентификатор книги. Как говорит Дейт: Для данного соединения, как правило, комбинация всех внешних ключей его участников имеет свойство уникальности . Таким образом, первичным ключом в таблице titleauthors является комбинация titlejd и auid.

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

Отношение один-к-одному

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

Последние замечания к объектному подходу

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

1. Представить каждый независимый объект (книга, автор, издатель, редактор, наниматель, студент, компания и т.д.) в виде строк базовых таблиц.

2. Представить свойства объектов (адреса авторов, стоимости книг и т.п.) в виде столбцов таблиц.

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

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

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

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

titleauthors title id

-au id contract

- tauthors au id au lname au fname address phone au ord royaltyper

pnce

advance .,-

pubdate

pub id

publishers , pub id name address

titles

80ПШ11

storjd date

qty ordered qty sUpped ►titlejd date.sMpper

titleditors title id edjd-*-

editors ► ed id edjame ed fname address phone

Рис. 2.7. Измененная диаграмма

РУКОВОДСТВО по НОРМАЛИЗАЦИИ

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

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

Выполнение правил нормализации обычно приводит к разделению таблиц на две или больше таблиц с меньшим числом столбцов, выделению отношений пер-

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

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

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

Первая нормальная форма

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

Рассмотрим на примере новой таблицы sales, как составить накладную сразу на несколько книг (рис. 2.8).

Bookbiz Sales Order Рюш Oredr #14 Store 7131 Date:5/29/87

Item. # Title # Ordered # Shipped Ship date

Puc. 2.8. Накладная

Puc. 2.9. Таблица должна быть прямоугольной

Вы не можете записать несколько идентификаторов книг в одном поле, так как это противоречило бы первой нормальной форме. Добавление столбцов типа titlel, title! просто маскирует появление в таблице повторяющихся групп и тоже не решает проблемы. Кроме того, это не лучшее решение и с практической точки зрения, так как при включении в накладную новой книги вам придется переделывать всю таблицу, включая в нее столбец titleS. Так как в первой нормальной форме все данные должны быть представлены в виде прямоугольных таблиц, также не допускается и использование множественных значений (рис. 2.9).

Чтобы избежать повторения столбцов, мы используем главную таблицу (master table) - sales и вспомогатед.ную таблицу (detail table) - salesdetail, которая поддерживает информацию по отдельным позициям накладной (рис. 2.10). Обрати-