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

На основе модели «сущность-связь» может быть автоматически синтезирована структура базы данных. Генерация осуществляется в соответствии со следующими правилами:

· каждая сущность преобразуется в таблицу, имя сущности становится именем таблицы;

· атрибуты сущности преобразуются в колонки таблицы, имена атрибутов становятся именами колонок;

· ключевые атрибуты становятся первичными ключами таблицы;

· если для сущности была определена ключевая связь, то первичный ключ таблицы для связанной сущности копируется и объединяется с ключом таблицы для рассматриваемой сущности;

· связи М: 1 и 1: 1 приводят к копированию первичных ключей таблицы для сущности, находящейся на одной стороне связи, в таблицу для сущности, находящейся на другом конце связи, если связь М: 1, то ключи таблицы для сущности, находящейся на конце «один» копируются в таблицу для сущности, находящейся на конце «многие».

Результат генерации таблиц для модели, изображенной на рис. 10, приведен на рис. 11, для сущностей «АВТОР» и «КНИГА» построены таблицы, колонками которых являются атрибуты сущностей, а первичными ключами – ключи сущностей. Для межсекционной сущности получена таблица, состоящая из скопированных ключей, образующих составной ключ таблицы «АВТОР КНИГИ».

	КНИГА
	Название	Место издания	Издательство	Год	Кол-во страниц
	АВТОР			АВТОР	КНИГИ
	ФИО	Тематика		ФИО	Название

Рис. 11. Структура базы данных для модели, приведенной на рис. 10

Правила генерации структуры базы данных иллюстрируются на рис. 12.

Е

А	B	C	D
key

а)

E1

A	B	C
key	key

E2

B	D
key

б)

E1

A	B	C
key

E2

B	D
key

в)

Рис.12. Правила генерации структуры базы данных:
а – создание таблиц для сущностей,
б - обработка ключевых связей, в – обработка связей М:1

Рассмотренные правила генерации структуры базы данных являются достаточно общими, не учитывают обработку случаев конфликта имен и явно не отражают обработку “цепочек” ключевых связей. Кроме того, на практике, как правило, различают логические и физические имена. Первые выступают как имена сущностей и атрибутов, а вторые используются при генерации в качестве имен таблиц и атрибутов. Использование физических имен вызвано тем, что многие СУБД накладывают ограничения на длину имени и набор допустимых символов.

Современные СУБД требуют, чтобы имена колонок в таблицах базы данных были уникальными. Конфликт имен возникает при совпадении имен колонок в результате копирования атрибутов одной сущности в таблицу для другой сущности (при обработке связей).

Типовыми случаями, приводящими к конфликту имен, являются следующие:

· наличие в модели двух связанных сущностей с совпадающими именами атрибутов (рис. 13, а);

· наличие между двумя сущностями более чем одной связи (рис. 13, б);

· рекурсивные связи (сущность связана сама с собой) (рис. 13, в).

Для разрешения конфликта имен используются следующие стандартные приемы:

· добавление в качестве префикса к имени атрибута имени сущности;

· добавление к имени атрибута порядкового номера;

· использование имени (физического имени) связи.

Добавление к имени атрибута имени сущности позволило бы избежать конфликта имен в модели, изображенной на рис. 13, а, соответствующие колонки таблицы получили бы имена «ЭТАП_Номер» и «ДОГОВОР_Номер».

Этот прием не дал бы нужного эффекта для моделей, показанных на рис. 13 б, в. В данном случае потребовалось бы вводить порядковые номера, например «АЭРОПОРТ_Код_1», «АЭРОПОРТ_Код_2».

Использование имен (физических имен) связей позволяет избежать конфликта во всех рассмотренных случаях, например:

· для сущности «ЭТАП» – «Входить_в_Номер»;

· для сущности «АЭРОПОРТ» – «В_Код», «Из_Код»;

· для сущности «ПОДРАЗДЕЛЕНИЕ» – «Входит_в_Название».

В рассматриваемых далее примерах будем придерживаться следующих правил:

· для любого копируемого атрибута (в т. ч. при отсутствии конфликта имен) в качестве префикса добавляется имя сущности, из которой атрибут скопирован;

· при возникновении конфликта имен к именам атрибутов добавляются порядковые номера.

ДОГОВОР

Номер	Название	….
key

ЭТАП

Номер	Номер	Название	…
key	key

а)

АЭРОПОРТ

Код	Название
key

АВИАРЕЙС

Номер	Время	Код	Код
key

б)

ПОДРАЗДЕЛЕНИЕ

Название	Название	Руководитель
key

в)

Рис. 13. Случаи, приводящие к конфликту имен при генерации структуры базы данных

Пример цепочки ключевых связей и результат ее обработки приведен на рис. 14. Предполагается, что экземпляры сущности «СТУДЕНТ» не могут быть однозначно идентифицированы вне связи с экземпляром сущности «ГРУППА», это приводит к тому, что в таблицу «ПРЕДМЕТ» помимо ключа «Студент_ФИО» будет скопирован ключ «ГРУППА_Номер», которые в совокупности с собственным ключевым атрибутом сущности “ОЦЕНКА” образуют составной ключ таблицы.

СТУДЕНТ

Фамилия	Имя	Отчество	Адрес	Номер
key	key	key		key

ПРЕДМЕТ

Предмет	Оценка	Фамилия	Имя	Отчество	Номер
key		key	key	key	key

Рис.14. Пример цепочки ключевых связей

Дата добавления: 2014-01-03