После установки на компьютере СУБД у вас может возникнуть сильный соблазн сразу начать создание базы данных, не задумываясь о планировании. Как и в других случаях разработки программного обеспечения, такой подход оправдан лишь при решении простейших задач. Если вы рассчитываете, что ваша база данных должна будет поддерживать хоть какую-то степень сложности, немного планирования и проектирования, в конечном итоге, несомненно сбережет ваше время.

Предположим, у вас есть большая коллекция компакт-дисков, и вы хотите создать базу данных, чтобы отслеживать ее. Прежде всего, нужно определить, какие данные вы собираетесь хранить. Неплохо начать с того, чтобы подумать, а зачем, собственно, вам хранить эти данные. В нашем случае мы, скорее всего, хотим иметь возможность найти диск по исполнителю, названию и песне. Раз мы хотим искать эти пункты, они должны быть включены в базу данных. Помимо того, часто полезно просто перечислить пункты, которые нужно отслеживать. Возможен такой список: название CD, фирма звукозаписи, название ансамбля, название песни. В качестве отправной точки выберем для хранения данных таблицу, представленную как таблица 2-1.

Таблица 2-1. База данных CD, состоящая из одной таблицы


Band Name	CD Title	Record Label	Songs
Stevie Wonder	Talking Book	Motown	You Are the Sunshine of My Life, Maybe Your Baby, Superstition, . . .
Miles Davis Quintet	Miles Smiles	Columbia	Orbits, Circle, . . .
Wayne Shorter	Speak No Evil	Blue Note	Witch Hunt, Fee-Fi-Fo-Fum
Herbie Hancock	Headhunters	Columbia	Chameleon, Watermelon Man, . . .
Herbie Hancock	Maiden Voyage	Blue Note	Maiden Voyage

(Для краткости мы опустили большую часть -песен.) На первый взгляд, эта таблица нам подходит, поскольку в ней есть все необходимые данные. При более близком рассмотрении, однако, мы сталкиваемся с некоторыми проблемами. Возьмем, к примеру, Herbie Hancock. Название ансамбля повторяется дважды - для каждого CD. Это повторение неприятно по нескольким причинам. Во-первых, при вводе данных нам приходится вводить одно и то же несколько раз. Во-вторых, что более важно, при изменении каких-либо данных приходится изменять их в нескольких местах. Что если, к примеру, в Herbie вкралась орфографическая ошибка? Пришлось бы исправлять данные в двух строках. Та же проблема возникнет, если имя Herbie Hancock в будущем изменится (а ля Jefferson Airplane или John Cougar). С добавлением к нашей коллекции новых дисков Herbie Hancock увеличивается объем работы, необходимой для поддержания непротиворечивости данных.

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

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

Сущность - это важная вещь или объект, сведения о котором нужно сохранить. Не все вещи являются сущностями, а только те, данные о которых должны быть сохранены. Сведения о сущностях имеют вид атрибутов и/или связей. Если некий кандидат на то, чтобы быть сущностью, не имеет атрибутов или связей, в действительности он не является сущностью. В модели базы данных сущности представляются в виде прямоугольника с заголовком. Заголовок является именем сущности.

Атрибут описывает данные о сущности, которые нужно сохранить. У каждой сущности ноль или более атрибутов, описывающих ее, и каждый атрибут описывает в точности одну сущность. Каждый экземпляр сущности (строка таблицы) имеет в точности одно значение, возможно, равное NULL, для каждого из своих атрибутов. Значение атрибута может быть числом, строкой символов, датой, временем или другим базовым значением данных. На первом этапе проектирования базы данных, логическом моделировании, нас не заботит то, каким образом будут храниться данные.

NULL лежит в основе проблемы, связанной с отсутствующей информацией. Он специально используется тогда, когда какая-то часть данных отсутствует. Рассмотрим, к примеру, ситуацию, когда на CD нет данных о длительности каждой песни. У каждой песни есть длительность, но, глядя на коробку, вы не можете сказать, какова она. Хранить длительность как О нежелательно, поскольку это было бы неверно. Вместо этого вы записываете длительность как NULL. Если вы считаете, что можно сохранить ее как 0 и использовать 0 для обозначения «неизвестной длины», то можете попасть в одну из тех западней, которые привели к проблеме 2000-го года. В старых системах не только год хранится как две цифры, но и придается особое значение величине 9-9-99.

В нашем примере база данных ссылается на ряд объектов - CD, название CD, название ансамбля, песни и название фирмы звукозаписи. Какие из них являются сущностями, а какие - атрибутами?

Обратите внимание, что мы определяем несколько видов данных (название CD, название ансамбля и т. д.), относящихся к каждому CD, и без которых описать CD совершенно невозможно. Поэтому CD является одним из тех объектов, которые мы хотим описать, и, похоже, является сущностью. Начнем разработку модели данных с изображения CD как сущности. На рис. 2-1 показана наша единственная сущность в модели данных.

По общепринятому соглашению об именовании сущностей имя сущности должно быть в единственном числе. Поэтому мы называем таблицу, в которой хранятся CD «CD», а не «CDs». Мы используем это соглашение, поскольку каждая сущность дает имя экземпляру. Например, «San Francisco 49ers» является экземпляром сущности «Футбольная команда», а не «Футбольные команды».

На первый взгляд кажется, что оставшаяся часть базы данных описывает CD. Это указывает на то, что она содержит атрибуты CD. На рис. 2-2 они добавлены к сущности CD рис. 2-1. В модели данных атрибуты представлены как имена, перечисленные в прямоугольнике сущности.

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

Е. Ф. Кодд (Е. F. Codd), занимавшийся исследовательской работой в IBM, впервые представил концепцию нормализации в нескольких важных статьях, написанных в 1970-е годы. Задача нормализации остается той же самой и сегодня: устранить из базы данных некоторые нежелательные характеристики. В частности ставится задача устранить некоторые виды избыточности данных и благодаря этому избежать аномалий при изменении данных. Аномалии изменения данных - это сложности при операциях вставки, изменения и удаления данных, возникающие из-за структуры базы данных. Дополнительным результатом нормализации является конструкция, хорошо соответствующая реальному миру. Поэтому в результате нормализации модель данных становится более ясной.

Например, предположим, что мы ошиблись при вводе «Herbie Hancock» в нашу базу данных и хотим исправить ошибку. Нам потребовалось бы рассмотреть все диски этого исполнителя и исправить имя. Если изменения производятся с помощью приложения, позволяющего одновременно редактировать только одну запись, нам придется редактировать много строк. Было бы гораздо лучше запомнить имя «Herbie Hancock» лишь один раз и редактировать его в одном месте.

Общее понятие нормализации подразделяется на несколько «нормальных форм». Говорят, что сущность находится в первой нормальной форме, когда все ее атрибуты имеют единственное значение. Чтобы признать сущность находящейся в первой нормальной форме, нужно удостовериться в том, что каждый атрибут сущности имеет единственное значение для каждого экземпляра сущности. Если в каком-либо атрибуте есть повторяющиеся значения, сущность не находится в 1NF.

Вернувшись к нашей базе данных, мы обнаруживаем, что повторяющиеся значения есть в атрибуте Song (песня), поэтому очевидно, что база не находится в 1NF. Сущность с повторяющимися значениями указывает на то, что мы упустили еще по крайней мере одну сущность. Обнаружить другие сущности можно, взглянув на каждый атрибут и задавшись вопросом «что описывает эта вещь?»

Что описывает атрибут Song? Он перечисляет все песни на CD. Поэтому Song - это еще один объект, о котором мы собираем данные, и, возможно, он является сущностью. Мы добавим его в свою диаграмму и придадим атрибут Song Name (название песни). Чтобы покончить с сущностью Song, спросим себя, чем еще мы хотели бы ее охарактеризовать. Мы отметили ранее, что длительность песни мы также хотели бы сохранить. Новая модель данных показана на рис. 2-3.

Теперь, когда Song Name и Song Length являются атрибутами сущности Song, мы имеем модель данных с двумя сущностями в 1NF. К сожалению, мы не указали никакого способа связать вместе CD и Song.

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

ID очень важен, поскольку позволяет узнать, с каким из экземпляров сущности мы имеем дело. Выбор идентификатора также существенен, потому что он используется для моделирования связей. Если после выбора ID для сущности вы обнаружили, что он не удовлетворяет одному из перечисленных правил, это может повлиять на всю вашу модель данных.

Новички в моделировании данных часто делают ошибку, выбирая в качестве ID неподходящие атрибуты. Если, к примеру, у вас есть сущность Person (человек, лицо), может возникнуть соблазн выбрать в качестве идентификатора Name (фамилию), поскольку она есть у каждого лица и не меняется. Но что если лицо вступает в брак или законным образом хочет изменить фамилию? Или вы допустили ошибку при первоначальном вводе фамилии? При каждом из этих событий нарушается третье правило для идентификаторов. Еще хуже то, что фамилия окажется не уникальной. Если вы не можете стопроцентно гарантировать, что атрибут Name уникален, вы нарушаете первое правило для идентификаторов. Наконец, вы считаете, что у каждого экземпляра Person фамилия отлична от NULL. Но вы уверены, что всякий раз, вводя первоначальные данные в базу, будете знать фамилию? Ваш процесс может быть организован так, что при начальном создании записи фамилия может быть неизвестна. Из этого следует извлечь тот урок, что при выборе неидентифицирующего атрибута в качестве идентификатора возникает много проблем.

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

Рис. 2-4. Сущности CD и Song со своими уникальными идентификаторами

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

У каждой стороны связи есть имя, описывающее связь. Возьмем две гипотетические сущности — Служащий и Отдел. Один вариант связи между ними состоит в том, что Служащий «приписан» к Отделу. Этот Отдел «отвечает» за Служащего. Таким образом, связь со стороны Служащий называется «приписан», а со стороны Отдел - «отвечает».

Степень, называемая также кардинальным числом, показывает, сколько экземпляров описывающей сущности должны описывать один экземпляр описываемой сущности. Степень выражается с помощью двух разных значений- «один-к-одному» (1) и «один-ко-многим» (М). Служащий приписан одновременно только к одному отделу, поэтому у сущности Служащий связь с сущностью Отдел «один-к-одному». В обратном направлении, отдел отвечает за многих служащих. Поэтому мы говорим, что у сущности Отдел связь с сущностью Служащий «один-ко-многим». В результате в Отделе может быть и только один Служащий.

Иногда полезно выразить связь словами. Один из способов - вставить разные составляющие направления связи в следующую формулу:

сущность1имеет [одну и только одну одну или много] сущностъ2

Согласно этой формуле связь между Служащим и Отделом можно выразить так:

Каждый Служащий должен быть приписан к одному и только одному

Каждый Отдел может отвечать одному или многим Служащим.

Можно использовать эту формулу для описания сущностей в нашей модели данных. В каждом CD содержится много или одна Song, и каждая Song содержится хотя бы в одном CD. В нашей модели данных эту связь можно показать, проведя линию между двумя сущностями. Степень обозначается прямой линией для связи «один и только один» и «птичьей лапой» для связи «один-ко-многим>>. На рис. 2-5 показаны эти обозначения.

Как это применимо к связи между Song и CD? На практике Song может содержаться на многих CD, но для нашего примера мы этим пренебрежем. На рис. 2-6 показана модель данных с обозначенными связями.

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

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

Рис. 2-7. Модель данных с новой сущностью Artist

В нашем примере «Herbie Hancock» является Band Name (названием ансамбля) для двух разных CD. Это показывает, что Band Name не полностью зависит от идентификатора CD ID. Это дублирование представляет собой проблему, поскольку если мы допустили ошибку при вводе «Herbie Hancock», придется исправлять значение в нескольких местах. Это указывает нам, что Band Name должно быть частью новой сущности, связанной с CD. Как и раньше, мы решаем эту задачу, задав вопрос: «Что описывает название ансамбля?» Оно описывает ансамбль, или, вообще говоря, исполнителя. Исполнитель - еще один объект, о котором мы собираем данные, и потому, возможно, является сущностью. Мы добавим его к нашей схеме с атрибутом Band Name. Поскольку исполнитель может не быть ансамблем, мы переименуем атрибут как 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 фактически является другим представлением этой связи «многие-ко-многим».

Все связи «многие-ко-многим» нужно разрешать с помощью следующей технологии:

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

Рис. 2-10. Наша модель данных во второй нормальной форме

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

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

Если бы мы пожелали отслеживать адрес Record Label, то столкнулись бы с проблемами для третьей нормальной формы. В сущности Record Label должны быть атрибуты State Name (название штата) и State Abbreviation (сокращенное название штата). Хотя для учета CD эти данные и не нужны, мы добавим их к нашей модели для иллюстрации проблемы. На рис. 2-11 показаны адресные данные в сущности Record Label.

Рис. 2-11. Адресная информация о фирме звукозаписи в нашей базе данных

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

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

Рис. 2-12. Модель данных в третьей нормальной форме

Методология логического моделирования данных

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

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

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

С какой целью мы создавали логическую модель данных? Вам нужно создать базу данных, чтобы хранить информацию о CD. Модель данных - это только промежуточный шаг. В конечном итоге вы хотели бы получить базу данных MySQL или mSQL, в которой можно хранить данные. Как это сделать? При проектировании физической базы данных логическая модель переводится в набор операторов SQL, которые определяют вашу базу данных MySQL или mSQL.

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

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

Таблица 2-2. Определения физических таблиц для базы, данных CD


Таблица	Колонка	Тип данных	Примечания
CD	CDId	INT	primary key
	CDTitle	TEXT(50)
Artist	Artistld	INT	primary key
	ArtistName	TEXT(50)
Song	Songld	INT	primary key
	SongName	TEXT(50)
RecordLabel	RecordLabelld	INT	primary key
	RecordLabelName	TEXT(50)	primary key

Первое, на что вы можете обратить внимание: в нашей физической схеме из всех названий объектов удалены пробелы. Это вызвано тем, что названия нужно преобразовать в вызовы SQL, создающие таблицы, поэтому названия таблиц должны удовлетворять правилам SQL для образования имен. Кроме того, все первичные ключи мы сделали типа INT. Поскольку эти атрибуты искусственные, мы можем приписать им любой индексируемый тип. То, что они имеют тип INT, почти полностью результат нашего произвола. Почти, поскольку на практике поиск по числовым полям в большинстве баз данных осуществляется быстрее, и поэтому выгодно назначать первичными ключами числовые поля. Однако мы могли бы выбрать для ключевых полей тип CHAR, и все работало бы прекрасно. Выбор должен основываться на ваших критериях выбора идентификаторов.

Для остальных колонок установлен тип TEXT с длиной 50. Такое определение годится и для MySQL, и для mSQL. Для MySQL, впрочем, лучше было бы выбрать VARCHAR, но это несущественно для нашего примера. Выбор правильного типа данных для колонок очень важен, но мы не будем сейчас на этом останавливаться, поскольку не касались еще типов данных, поддерживаемых MySQL и mSQL.

Теперь у нас есть отправная точка для физической схемы. Мы еще не перевели отношения в физическую модель данных. Как указывалось ранее, после уточнения логической модели у вас должны остаться отношения типа «один-к-одному» и «один-ко-многим» - отношения «М-к-М» разрешаются через таблицы-связки. Отношения моделируются путем добавления внешних ключей к одной из участвующих в них таблиц. Внешний ключ - это уникальный идентификатор или первичный ключ таблицы на другом конце отношения.

Позднее мы коснемся типов данных, поддерживаемых MySQL и mSQL. В каждой из них свои правила относительно того, какие типы данных можно индексировать. Ни в одной из них, например, нельзя индексировать поля типа TEXT. Поэтому недопустимо иметь колонку первичного ключа типа TEXT.

Чаще всего отношение имеет тип «1-к-М». Ему соответствует первичный ключ со стороны «1», помещенный в таблицу на стороне «многие». В нашем примере это означает, что нужно сделать следующее:

Таблица 2-3. Физическая модель данных для базы данных CD


Таблица	Колонка	Тип данных	Примечания
CD	Cdld	INT	primary key
	CDTitle	TEXT(50)
	RecordLabelld	INT	foreign key
Artist	Artistld	INT	primary key
	ArtistName	TEXT(50)
Song	Songld	INT	primary key
	SongName	TEXT(50)
	Cdld	INT	foreign key
	Artistld	INT	foreign key
RecordLabel	RecordLabelld	INT	primary key
	RecordLabelName	TEXT(50)

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

Теперь у нас есть полная физическая схема базы данных. Осталось перевести эту схему на SQL. Для каждой таблицы в схеме вы пишете одну команду CREATE TABLE. Обычно для поддержки уникальности создается уникальный индекс по первичным ключам.

В некотором смысле мы сейчас забегаем вперед. Вы, возможно, не знакомы с SQL, а в задачи данной главы не входит знакомство с версиями SQL, поддерживаемыми MySQL и mSQL. Все же, вот два простых сценария для создания базы данных CD. Первый сценарий, пример 2-1, составлен для MySQL, пример 2-2 — для mSQL.

Пример 2-1. Сценарий создания базы данных CD в MySQL

PRIMARY KEY (ARTIST_ID)) CREATE TABLE Song (SONG_ID INT NOT NULL, CD_ID INT, SONG_NAME TEXT, PRIMARY KEY (SONG_ID))

CREATE TABLE RecorLabel(RECORD LABEL_ID INT NOT NULL, RECORD_LABEL_NAME TEXT, PRIMARY KEY(RECORD_LABEL_ID))

Пример 2-2. Сценарий создания базы данных CD в mSQL

Модели данных разрабатываются так, чтобы не зависеть от базы данных. Поэтому вы можете взять технику и модель данных, созданную в этой главе, и применить ее не только к MySQL и mSQL, но и к Oracle, Sybase, Ingres и любой другой РСУБД. В следующих главах мы подробно обсудим, как соединить ваши новые знания о проектировании баз данных с MySQL и mSQL.

Оглавление