Проектирование физической базы данных

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

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

Объекты становятся таблицами в физической базе данных.

Атрибуты становятся колонками в физической базе данных. Для каждой колонки нужно выбрать подходящий тип данных.

Уникальные идентификаторы становятся колонками, не допускающими значение NULL. В физической базе данных они называются первичными ключами (primary keys). Вы можете также пожелать создать уникальный индекс по идентификатору, чтобы обеспечивать уникальность. Учтите, что в mSQL нет понятия первичного ключа, есть просто уникальные индексы. К MySQL это не относится.

Отношения моделируются в виде внешних ключей (foreign keys). Мы коснемся их позднее.

Применив эти правила к нашей модели (исключая адресную информацию по фирмам звукозаписи), получим физическую базу данных, представленную в таблице 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», помещенный в таблицу на стороне «многие». В нашем примере это означает, что нужно сделать следующее:

Поместить колонку RecordLabelId в таблицу CD.

Поместить колонку CDId в таблицу Song.

Поместить колонку Artistic! в таблицу Song. Полученная схема показана в таблице 2-3.

Таблица 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

CREATE TABLE CD (CDID INT NOT NULL,

RECORD_LABEL_I INT, CD_TITLE TEXT, PRIMARY KEY (CD_ID))

CREATE TABLE Artist (ARTIST_ID INT NOT NULL, ARTIST_NAMETEXT,

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

CREATE TABLE CD (CD_ID INT NOT NULL,

RECORD_LABEL_IDINT, CD_TITLE TEXT(50))

CREATE UNIQUE INDEX CD_IDX ON 0(DCD.ID)

CREATE TABLE ArtistARTIST_ID INT NO NULL,

ARTIST_NAMETEXT(50))

CREATE UNIQUE INDEX Artist_IDX ON Artist (ARTIST_ID)

CREATE TABLE Song (SONG_ID INT NOT NULL, CD_ID INT,

SONG_NAME TEXT(50))

CREATE UNIQUE INDEX Song_IDX ON Song (SONG_ID)

CREATE TABLE RecordLabel (RECORD_LABEL_IDINT NOT NULL,

RECORD_LABEL_NAMEEXT(50))

CREATE UNIQUE INDEX RecordLabel_IDX

ON RecordLabel(RECORD_LABEL_ID)

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

Содержание раздела