Проблема в том, что State Name и State Abbreviation взаимозависимы. Иными 
словами, поменяв State Abbreviation для какой-либо Record Label, мы вынуждены 
будем также изменить State Name. Мы произведем нормализацию, создав сущность 
State с атрибутами State Name и State Abbreviation. На рис. 2-12 показано, как 
связать эту новую сущность с сущностью Record Label.
Теперь, получив третью нормальную форму, мы можем сказать, что наша модель 
данных нормализована. Существуют и другие нормальные формы, имеющие значение с 
точки зрения проектирования баз данных, но их рассмотрение находится за 
пределами нашей книги. В большинстве случаев третьей нормальной формы 
достаточно, чтобы гарантировать правильность проекта базы данных.

Рис. 2-12. Модель данных в третьей нормальной форме
Методология логического моделирования данных
Теперь у нас есть завершенная логическая модель данных. Вспомним, какие шаги 
нужно осуществить, чтобы получить ее:
1. Выявить и смоделировать сущности.
2. Выявить и смоделировать связи между сущностями.
3. Выявить и смоделировать атрибуты.
4. Указать уникальный идентификатор для каждой сущности.
5. Провести нормализацию.
На практике процесс редко происходит в такой последовательности. Как показывает 
наш пример, часто возникают желание и необходимость перескакивать между 
сущностями, связями, атрибутами и идентификаторами. Важно не столько строго 
следовать последовательности шагов, сколько выявить и зафиксировать все данные, 
необходимые для правильного моделирования системы.
Модель данных, которую мы создали в этой главе, очень проста. Мы рассказали, 
как создать модель, соответствующую по типу и сложности тем базам данных, с 
которыми вы, скорее всего, столкнетесь, разрабатывая базы данных для MySQL или 
mSQL. Мы не коснулись целой массы приемов проектирования и понятий, которые не 
имеют большого значения при проектировании маленьких баз данных и могут быть 
найдены в любом учебнике, посвященном проектированию баз данных.
Проектирование физической базы данных
С какой целью мы создавали логическую модель данных? Вам нужно создать базу 
данных, чтобы хранить информацию о CD. Модель данных - это только промежуточный 
шаг. В конечном итоге вы хотели бы получить базу данных MySQL или mSQL, в 
которой можно хранить данные. Как это сделать? При проектировании физической 
базы данных логическая модель переводится в набор операторов SQL, которые 
определяют вашу базу данных MySQL или mSQL.
Поскольку MySQL и mSQL являются реляционными базами данных, относительно 
несложно перевести логическую модель, подобную описанной, в физическую базу 
данных MySQL или mSQL. Вот правила перевода:
1. Объекты становятся таблицами в физической базе данных.
2. Атрибуты становятся колонками в физической базе данных. Для каждой колонки 
нужно выбрать подходящий тип данных.
3. Уникальные идентификаторы становятся колонками, не допускающими значение 
NULL. В физической базе данных они называются первичными ключами (primary keys).
 Вы можете также пожелать создать уникальный индекс по идентификатору, чтобы 
обеспечивать уникальность. Учтите, что в mSQL нет понятия первичного ключа, 
есть просто уникальные индексы. К MySQL это не относится.
4. Отношения моделируются в виде внешних ключей (foreign keys). Мы коснемся их 
позднее.
Применив эти правила к нашей модели (исключая адресную информацию по фирмам 
звукозаписи), получим физическую базу данных, представленную в таблице 2-2.
Таблица 2-2. Определения физических таблиц для базы, данных CD
ТаблицаКолонкаТип данныхПримечанияCDCDIdINTprimary keyCDTitleTEXT(50)Artist
ArtistldINTprimary keyArtistNameTEXT(50)SongSongldINTprimary keySongName
TEXT(50)RecordLabelRecordLabelldINTprimary keyRecordLabelNameTEXT(50)primary 
keyПервое, на что вы можете обратить внимание: в нашей физической схеме из всех 
названий объектов удалены пробелы. Это вызвано тем, что названия нужно 
преобразовать в вызовы SQL, создающие таблицы, поэтому названия таблиц должны 
удовлетворять правилам SQL для образования имен. Кроме того, все первичные 
ключи мы сделали типа INT. Поскольку эти атрибуты искусственные, мы можем 
приписать им любой индексируемый тип. То, что они имеют тип INT, почти 
полностью результат нашего произвола. Почти, поскольку на практике поиск по 
числовым полям в большинстве баз данных осуществляется быстрее, и поэтому 
выгодно назначать первичными ключами числовые поля. Однако мы могли бы выбрать 
для ключевых полей тип CHAR, и все работало бы прекрасно. Выбор должен 
основываться на ваших критериях выбора идентификаторов.
Для остальных колонок установлен тип TEXT с длиной 50. Такое определение 
годится и для MySQL, и для mSQL. Для MySQL, впрочем, лучше было бы выбрать 
VARCHAR, но это несущественно для нашего примера. Выбор правильного типа данных 
для колонок очень важен, но мы не будем сейчас на этом останавливаться, 
поскольку не касались еще типов данных, поддерживаемых MySQL и mSQL.
Теперь у нас есть отправная точка для физической схемы. Мы еще не перевели 
отношения в физическую модель данных. Как указывалось ранее, после уточнения 
логической модели у вас должны остаться отношения типа «один-к-одному» и 
«один-ко-многим» - отношения «М-к-М» разрешаются через таблицы-связки. 
Отношения моделируются путем добавления внешних ключей к одной из участвующих в 
них таблиц. Внешний ключ - это уникальный идентификатор или первичный ключ 
таблицы на другом конце отношения.