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

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

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

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

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

titleauthors title id -au id contract

titles titlejd у name \ price \ advance, pubdat.V pubJd

publishers , pub id name address

tauthors

au lname

au fname

address

phone

au ord

royaltyper

titles

sonum .....

storjd date

qty ordered qty shipped titlejd date shipper

salesdetails . sonum title id

editors .ed id edjame ed fname address phone

titleditors title id -ed. id

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

В этом случае контракт определяется книгой, а не отдельными авторами, и вы должны переместить столбец contract в таблицу titles (рис. 2.11). Этот пример иллюстрирует сложность процесса проектирования базы данных: ваши решения часто могут зависеть от конкретных принципов организации работы в вашей организации.

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

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

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

titleauthors title id -au id

titles title id у name price advance, pubdateV pubJd \ contract

publishers , pub id name address city state

salesdetails ►sonum - title id

editors -ed id edjame ed fname address city stale zip

phone

titleditors Atitlejd *>ed id

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

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

Столбцы qtyjordered и qty shipped из таблицы sales также иллюстрируют этот принцип. Они относятся к отдельным пунктам, а не ко всей накладной, и, следовательно, должны быть перенесены в таблицу salesdetails.

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

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

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

Так как книги могут быть доступны только после выхода из печати, мы придерживаемся второй модели. Измененная диаграмма представлена на рис. 2.12.

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

titleauthors title id-

au ord royaltyper

titles >-titlejd у name \ price advance, pub dateY pub id ; contract \

publishers , pub id name address city state

salesdetails

-sonum

title id qty ordered qty sliipped date sliipper

editors -edjd edjame ed fname address city state zip

phone

titleditors 4itle id -sdjd

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

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

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

Au lname

Ringer

Ringer

Bennet

Green

Green

Green

1987 Chevy Nova

1994 Volvo Station Wagon

1990 VW Rabbit

1989 Toyota Corolla

pet Rover

Spot Valiant Fluffy Sam

Помещение этой разнородной информации в одну таблицу может привести к появлению в ней пустых мест, так как домашних животных может быть больше, чем машин (как в случае с Green) или наоборот (как в случае с Ringer). Удаление данных о машинах или животных также может привести к появлению пустых мест.

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

1987 1994 1990 1989

au id

998-7F-3567 998-72-3567 409-56-7008 213-46-8915

Chevy Nova

Volvo Station Wagon

VW Rabbit

Toyota Corolla