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

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

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

4. Руководство по нормализации

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

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

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

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

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

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

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

Занимаясь поиском повторяющихся полей, разбейте на компоненты все составные столбцы: например столбец address нужно разбить на два столбца — city и state.

Рис. 8. Разбиение таблицы sales

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

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

В качестве примера рассмотрим столбец contract в таблице titleauthors. Зависит ли он исключительно от комбинации автор-название? Если каждый автор заключает отдельный контракт, тогда — да, но ситуация изменится, если компания подпишет контракт только при достижении согласия со всеми авторами.

Рис. 9. Диаграмма зависимостей между объектами базы данных bookbiz после преобразования данных во вторую нормальную форму

В этом случае контракт определяется книгой, а не отдельными авторами, и вы должны переместить столбец contract в таблицу titles.

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

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

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

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

В таблице authors первичным ключом является au_id. Проверяя каждый столбец, вы обнаружите, что столбец au_ord (позиция автора в списке авторов книги) не зависит от столбца авторов (au_id), так как у каждого автора может быть несколько книг, и в каждой из них он может занимать разные позиции (первую, вторую или третью). На самом деле позиция определяется отношением автор-книга. Так же обстоят дела и со столбцом royaltyper. Оба этих столбца переносятся в таблицу titleauthors.

Столбцы qty_ordered и qty_shipped из таблицы sales также иллюстрируют этот принцип.

Столбец data_shipped более загадочен.

• Если заказ выполняется только при наличии всех книг, столбец data_shipped относится ко всей накладной и поэтому должен быть перемещен в таблицу sales.

• Если же заказ выполняется по мере выполнения отдельных пунктов, этот столбец должен принадлежать таблице salesdetails.

Рис. 10. Диаграмма данных в третьей нормальной форме

ОБЗОР БАЗЫ ДАННЫХ

Давайте вспомним процесс создания базы данных bookbiz. Мы начали с четырех таблиц: authors, titles, publishers и editors. Их создание было интуитивно ясно, к тому же, в соответствии с объектным подходом, независимые объекты должны представляться отдельными базовыми таблицами. Кроме того, в результате моделирования зависимостей между объектами мы построили еще две базовые таблицы —

одну для связи таблиц titles и authors (titleauthors), другую — для связи таблиц titles и editors (tit/editors). Позднее мы добавили таблицы sales и salesdetails.

К этому моменту мы не рассмотрели единственную таблицу — roysched, которая определяет авторские гонорары в виде зависимости от количества проданных книг. Таблица roysched является поисковой таблицей (lookup table), используемой исключительно для справочных целей. Ее данные модифицируются только в случае изменений условий контракта или выхода новой книги.

Таким образом, мы создали девять таблиц.

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

Символы 1 и N на концах линии между таблицами titles и publishers описывают тип отношения между этими таблицами — один-ко-многим. Издатель может выпустить несколько книг, но каждая книга может иметь только одного издателя.