Модуль2_Проектирование БД

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

Для отображения возможного количества экземпляров сущностей, участвующих в связи, в ER–диаграммах используются следующие типы связей:

−связь «один к одному» (1:1), означающая возможность взаимодействия не более одного экземпляра одной сущности с одним экземпляром другой (связанной) сущности. Например, связь между пассажиром и креслом в салоне самолета;

−связь «один ко многим» (1:М), допускающая возможность взаимодействия одного экземпляра одной сущности с любым числом экземпляров другой сущности. Например, читатель и полученные им на абонемент книги;

−связь «многие ко многим» (М:N), означающая возможность взаимодействия любого числа экземпляров связанных сущностей. Например, подписчики и периодические издания (газеты, журналы)

выписанные ими.

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

110

являются сильными, поскольку их экземпляры могут существовать независимо друг от друга. На рис. 14.5 представлена ER–диаграмма для описания данных по изданиям, книгам и читателям.

ИЗДАНИЕ

1

М КНИГА М

1 ЧИТАТЕЛЬ

Рис. 14.5. Пример ER– диаграммы

На этой схеме отношение между изданиями и книгами (экземплярами изданий) показано связью типа 1:М. Такая связь допускает наличие издания при отсутствии его экземпляров в библиотеке. В диаграмме Чена было определено несколько иное правило: каждому имеющемуся в библиотеке изданию должен соответствовать хотя бы один экземпляр книги. Таким образом, модель Чена позволяет более точно определять связи между сущностями схемы.

Связи, используемые в ER–диаграммах, могут иметь любую природу и описывать любые виды отношений между объектами. Но для структуризации описания предметной области могут быть использованы особые специальные типы связей: родовидовые отношения и отношения агрегации – детализации.

Связь Род – Вид или Класс – Категория образует иерархию наследования и устанавливается между сущностями, имеющими отношение общего и частного. Для создания таких сущностей и связей между ними могут быть применены процедуры конкретизации и обобщения. Конкретизация – образование новой сущности (категории), являющейся частным случаем более общей сущности (класса). Обобщение: обратная процедура образования сущности – класса (супертипа) из сущностей – категорий (типов). Например, сущность компьютер можно конкретизировать сущностями сервер и рабочая станция, а сущность сервер далее конкретизировать сущностями сервер БД, сервер приложений, почтовый сервер. При такой конкретизации создается ER– диаграмма вида, представленного на рис. 14.6. Для обозначения связи класс – категория в ER–диаграмме используется специальный элемент.

111

Компьютер

Сервер		Рабочая станция

Сервер БД Сервер приложений Почтовый сервер

Рис. 14.6. Структуризация описания предметной области посредством конкретизации сущностей

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

Другим типом структурирующей связи является отношение агрегат – деталь. Процедура детализации – создание сущностей, представляющих элементы сущности – агрегата. Например, в иерархии детализации сущность компьютер можно описать схемой, представленной на рис. 14.7, которая может быть далее детализирована для каждого составляющего элемента.

112

Компьютер

Системный блок		Монитор
				Принтер

Рис.14.7. Структуризация описания предметной области посредством детализации сущностей

В иерархии детализации сущность – агрегат объединяет атрибуты детальных сущностей. Поэтому характеристики системного блока, монитора и принтера одновременно являются характеристиками компьютера в целом.

Сущности, построенные процедурами конкретизации и детализации, могут объединяться в общей ER–диаграмме.

ER–диаграммы являются основой для стандарта описания данных IDEF1X. В этом стандарте кроме сущностей, атрибутов и связей определяются способы создания связи и выполнения определяемых ими ограничений в базе данных. Связь типа 1:М поддерживается в БД значениями ключевых атрибутов в экземплярах сущностей. Для этого сущность, многие экземпляры которой (со стороны М) связаны с одним экземпляром другой сущности (1), дополняется атрибутами, значениями которых является первичный ключ связанной сущности. Такие дополнительные атрибуты называют внешним ключом сущности. Т.е. внешний ключ (Foreign Key – FK) это ключ другой сущности. Например, в сущность книга включается атрибут № издания, который в каждом экземпляре книги содержит ссылку (в виде номера издания) на конкретное печатное издание. Для реализации связи книги с читателем в сущности книга следует создать второй внешний ключ – № абонемента читателя, которому выдается книга. Внешние ключи и обеспечиваемые ими связи показаны в виде схемы данных на рис. 14.8.

113

ИЗДАНИЕ1

КНИГА

ЧИТАТЕЛЬ

1

1

№ издания

Инв. номер

№ абонем.

ББК

Место

ФИО

Название

пребывания

. . . . . . .

Год издания

. . . . . . .

М

. . . . . . .

№ издания

М

№ абонем.

Внешние ключи сущности книга

Рис. 14.8. Реализация связи 1:М с помощью внешних ключей С помощью внешних ключей также обеспечивается свойство

обязательности или необязательности участия сущности в связи. Для слабой сущности, экземпляры которой могут появляться только связанными с другой сущностью, атрибуты внешнего ключа должны иметь свойство NOT NULL. Например, чтобы экземпляры сущности книга всегда относились к определенному печатному изданию, внешний ключ № издания должен иметь свойство NOT NULL. Используя данное свойство, СУБД не допустит появления в БД экземпляра книги, не относящейся к определенному изданию. Для внешнего ключа сильной сущности необходимо установить свойство NULL. Благодаря этому появляется возможность создавать в БД новые экземпляры сильной сущности вне зависимости от наличия связанных сущностей. Например, значение NULL внешнего ключа № абонем. делает сущность книга сильной в связи с читателем. Отсутствие значения в атрибуте № абонем. означает, что книга находится в библиотеке, а не выдана читателю.

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

114

−Restrict – попытка удаления экземпляра сильной сущности при наличии связанных с ним экземпляров слабой сущности (удаление первичного ключа при наличии совпадающего с ним внешнего ключа в слабой сущности) прерывается СУБД с сообщением об ошибке. Аналогично добавление экземпляра слабой сущности без связи с сильной (добавление слабой сущности с внешним ключом, которого нет среди первичных ключей в сильной связанной сущности) приводит к ошибке. Также недопустимо изменение внешнего ключа в экземпляре слабой сущности на значение, которого нет среди первичных ключей сильной сущности;

−Cascade – при удалении (или обновлении первичного ключа) экземпляра сильной сущности автоматически удаляются (или обновляются внешние ключи) зависимые экземпляры слабой сущности. Запрещено добавление

экземпляра слабой сущности при отсутствии связанной сильной. Дополнительными способами обработки значений внешнего ключа

для обеспечения ссылочной целостности являются:

−Set NULL – при удалении экземпляра сильной сущности значения внешних ключей связанных сущностей заменяются на отсутствие данного (NULL), но экземпляры этих сущностей сохраняются в базе. Таким способом обеспечивается связь 1:М двух сильных сущностей;

−Set Default – при удалении экземпляра сильной сущности значения внешних ключей связанных слабых сущностей заменяются на заранее определенной умалчиваемый ключ. Таким образом связь автоматически переключается с удаляемой сущности на другую, присутствующую в БД;

−None – СУБД не контролирует выполнение ограничения ссылочной целостности.

Поскольку ER–диаграммы разрешают использование только бинарных

связей, возникает задача представления сложных многоарных связей системой бинарных отношений. Для реализации многоарных связей, а также бинарных связей типа «многие ко многим» (M:N) с помощью пар первичный – внешний

115

ключ, используется общий подход, состоящий в образовании новой связывающей сущности, в которой создаются внешние ключи для каждой связываемой сущности. Кроме внешних ключей, предназначенных для реализации связей, в новой сущности размещаются атрибуты связи. Например, схема данных, представленная на рис. 14.4. диаграммой Чена с тернарной связью Обучение может быть преобразована в ER–диаграмму введением вместо связи новой сущности Обучение. Получающаяся ER–диаграмма представлена на рис. 14.9.

Схемы данных, создаваемые в стандарте IDEF1X, являются средством разработки и документирования структуры БД. Для построения и анализа схем данных в стандарте IDEF1X и последующего преобразования в структуры баз данных конкретных СУБД разработаны средства автоматизации проектирования БД, называемые CASE (Computer Aided Software Engineering)

средства.

											ПРЕПОДАВАТЕЛЬ
						ОБУЧЕНИЕ
	СТУДЕНТ
	N студ.билета					N студ.билета					Табельный N
	ФИО					Табельный N					ФИО
	Группа					N в учебном плане					Кафедра
. . . . . . .						Оценка					. . . . . .
					. . . . . . .
					ПРЕДМЕТ		плане
					N в учебном
					Название предмета
					Семестр
					Число часов
					. . . . . . .

Рис. 14.9. Представление сложной связи дополнительной сущностью с бинарными связями 1:М

Примером таких средств является пакет инструментов AllFusion Modeling Suite, разработанный фирмой Computer Assiciates, включающий систему Erwin Data Modeler для создания схем и генерации структур баз данных. Другое

116

средство для создания и документирования схем данных – Microsoft Office Visio 2003. Большинство конкретных СУБД также располагают средствами графического представления схем баз данных.

Описание данных в стандарте IDEF1X обеспечивает баланс между наглядностью и определенной формализованностью представления данных.

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

Лекция 15. Поэтапная методика проектирования РБД

Общая схема процесса проектирования структуры РБД

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

Главные критерии проектирования - обеспечение полноты описания предметной области и требуемых показателей эффективности выполнения запросов к БД.

В процессе проектирования решаются следующие задачи:

•разработка логической структуры базы данных (схемы),

•выбор системы управления БД (сервера БД)

•выбор физической организации данных на носителях информации,

•ролей, профилей, прав и представлений пользователей,

•создание хранимых процедур и функций, выполняющих транзакции типовой обработки данных Поскольку критерий полноты описания предметной области определяется

логической структурой данных, а эффективность запросов их физической организацией, проектирование любой базы можно выполнить последовательно

117

по шагам (этапам), документируя и согласовывая с будущими пользователями

результаты каждого шага.

Основными шагами процесса проектирования базы являются:

1.формулировка и анализ требований к БД;

2.концептуальное проектирование базы данных;

3.выбор СУБД;

4.логическое проектирование;

5.физическое проектирование базы данных.

Блок-схема процесса проектирования представлена на рис. 15.1.

118

Рис. 15.1. Блок-схема процесса проектирования БД

119