переименуем атрибут как Artist Name. На рис. 2-7 показано новое состояние 
модели.
Правда, не показаны связи для новой таблицы исполнителей. Ясно, что у каждого 
Artist может быть один или много CD. У каждого CD может быть один или несколько 
Artist. Это показано на рис. 2-8.

Рис. 2-8. Связи сущности Artist в модели данных
Вначале мы присвоили атрибут Band Name сущности CD. Поэтому было естественным 
установить прямую связь между Artist и CD. Но верно ли это? При ближайшем 
рассмотрении оказывается, что следует установить прямую связь между Artist и 
Song. У каждого Artist есть одна или много Song. Каждая Song исполняется одним 
и только одним Artist. Правильные связи показаны на рис. 2-9.
Это не только более разумно, чем связь между Artist и CD, но и решает проблему 
дисков-сборников.

Рис. 2-9. Подлинная связь между Artist и остальной частью модели данных
Виды связей
При моделировании связей между сущностями важно определить оба направления 
связи. После определения обеих сторон связи мы приходим к трем основным видам 
связей. Если оба конца связи имеют степень «один и только один», то связь 
называется «один-к-одному». Как мы позднее убедимся, связи «один-к-одному» 
встречаются редко. В нашей модели данных их нет.
Если одна сторона имеет степень «один или много», а другая сторона имеет 
степень «один и только один», то это связь «один-ко-многим» или «1-к-М». Все 
связи в нашей модели - это связи «один-ко-многим». Этого можно было ожидать, 
поскольку связи «один-ко-многим» наиболее распространены.
И наконец, последний тип связей - когда обе стороны имеют степень 
«один-ко-многим». Такого типа связи называются «многие-ко-мно-гим», или «М-к-М».
 В предыдущей версии нашей модели данных связь Artist-CD имела тип 
«многие-ко-многим».
Уточнение.связей
Как отмечалось ранее, связи «один-к-одному» очень редки. На практике, если в 
процессе моделирования вы столкнетесь с такой связью, следует внимательнее 
изучить свой проект. Такая связь может означать, что две сущности являются на 
самом деле одной, и если это так, их следует объединить в одну.
Связи «многие-ко-многим» встречаются чаще, чем «один-к-одному». В этих связях 
часто есть некоторые данные, которыми мы хотим охарактеризовать связь. Взглянем,
 например, на предыдущую версию нашей модели данных на рис. 2-8, в которой была 
связь «многие-ко-многим» между Artist и CD. Artist имеет связь с CD, поскольку 
у исполнителя есть одна или несколько Song на этом CD. Модель данных на рис. 
2-9 фактически является другим представлением этой связи «многие-ко-многим».
Все связи «многие-ко-многим» нужно разрешать с помощью следующей технологии:
1. Создайте новую сущность, иногда называемую сущностью-связкой. Назовите ее 
подходящим образом. Если вы не можете придумать подходящее название, образуйте 
его из сочетания имен связываемых сущностей, например ArtistCD. В нашей модели 
Song является сущностью-связкой для связи Artist-CD.
2. Свяжите новую сущность с двумя исходными. Каждая из исходных сущностей 
должна иметь связь «один-ко-многим» с сущностью-связкой.
3. Если в новой сущности нет очевидного уникального идентификатора, введите в 
нее идентифицирующие атрибуты исходных сущностей и сделайте эту пару уникальным 
идентификатором новой сущности.
Почти всегда обнаружатся дополнительные атрибуты, принадлежащие новой сущности. 
Если это не так, то все равно необходимо разрешить связь «многие-ко-многим», 
иначе возникнут проблемы при переводе вашей модели данных в физическую схему.

Рис. 2-10. Наша модель данных во второй нормальной форме
Еще о 2NF
Наша модель все еще не приобрела вторую нормальную форму. Значение атрибута 
Record Label (фирма звукозаписи) имеет только одно значение для каждого CD, но 
одно и то же значение его присутствует в нескольких СD. Ситуация сходна с той, 
которая была с атрибутом Band Name. И точно так же дублирование указывает на то,
 что Record Label должна быть частью отдельной сущности. Каждая Record Label 
выпускает один или много CD. Каждый CD выпускается одной и только одной Record 
Label. Модель этой связи представлена на рис. 2-10.
Третья нормальная форма (3NF)
Сущность находится в третьей нормальной форме, если она уже находится во второй 
нормальной форме и ни один неидентифицирующий атрибут не зависит от каких-либо 
других неидентифицирующих атрибутов. Атрибуты, зависящие от других 
неидентифицирующих атрибутов, нормализуются путем перемещения зависимого 
атрибута и атрибута, от которого он зависит, в новую сущность.
Если бы мы пожелали отслеживать адрес Record Label, то столкнулись бы с 
проблемами для третьей нормальной формы. В сущности Record Label должны быть 
атрибуты State Name (название штата) и State Abbreviation (сокращенное название 
штата). Хотя для учета CD эти данные и не нужны, мы добавим их к нашей модели 
для иллюстрации проблемы. На рис. 2-11 показаны адресные данные в сущности 
Record Label.

Рис. 2-11. Адресная информация о фирме звукозаписи в нашей базе данных
Значения State Name и State Abbreviation удовлетворяют первой нормальной форме, 
поскольку имеют только одно значение в каждой записи сущности Record Label.