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

С какой целью мы создавали логическую модель данных? Вам нужно создать базу данных, чтобы хранить информацию о 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

	Таблица	Колонка	Тип данных	Примечания
	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.

Домашнее задание.

Провести сравнительный анализ моделей данных