Лекция-6_4

6.4. Переход от ER-модели к реляционной модели данных
Рассмотренный классический механизм проектирования реляционной базы данных очень
сложен и неудобен в практическом применении. В этом проявляется ограниченность
реляционной модели данных:
A. Модель не предоставляет достаточных средств для представления смысла данных (из-за этого
довольно сложно выявить и описать все функциональные и многозначные зависимости, описать
ограничения целостности).
B. Часто трудно представить все свойства объектов предметной области в виде одной плоской
таблицы, которую впоследствии требуется нормализовать.
C. Несмотря на то, что процесс проектирования начинается с выделения некоторых существенных
для приложения объектов предметной области и выявления связей между ними, реляционная модель
данных не предлагает какого-либо аппарата для разделения сущностей и связей.
Поэтому на практике проектирование базы данных начинается с построения концептуальной модели
(ER-модели), которая затем преобразуется в реляционную модель данных с учетом типов данных,
поддерживаемых конкретной СУБД. Процесс преобразования может быть выполнен автоматически с
помощью CASE- средств либо вручную с помощью методик, в которых достаточно четко оговорены все
этапы такого преобразования. В заключение проектировщику остается проверить, отвечает ли схема
полученной базы данных требованиям нормализации (3NF или BCNF) и скорректировать ее в случае
необходимости.
Рассмотрим методику перехода от инфологической модели предметной области “сущность - связь” к
реляционной модели данных. Идея состоит в том, что каждое понятие или связь между ними
отображаются в виде отношений
В первом случае атрибуты отношения соответствуют свойствам понятия, а каждый кортеж
соответствует одной из сущностей.
Во втором случае кортеж соответствует списку связанных понятий, а атрибутами отношения являются
ключевые свойства этих понятий.
Приводимая методика позволяет получить РБД с минимальной избыточностью.
1. Для каждого простого понятия с простыми (не множественными) свойствами строится отношение
R(N,C1,C2...Cn), где N - ключевое свойство, C1..Cn - другие свойства понятия. Пример:
СТУДЕНТ (№ зач книжки, ФИО, АДРЕС, Стипендия).
2. Если понятие имеет множественные свойства, то для каждого такого свойства строится
отдельное отношение. Например, свойство Иностр_языки в понятии СТУДЕНТ может иметь несколько
значений, поэтому кроме отношения СТУДЕНТ строим отношение ИН_ЯЗЫКИ (№ зач книжки, Язык).
3. Если понятие имеет условные свойства, то когда это свойство вероятно для большинства
сущностей, то оно включается в отношение, в противном случае создают дополнительное отношение.
Пример: в ПТИ свойство УЧЕНАЯ СТЕПЕНЬ лучше включить в отношение ЛИЧНОСТЬ, а на
компрессорном заводе лучше выделить в отдельное отношение: УЧЕНЫЕ(Таб_номер,
ученая_степень), так как там немного таких лиц.
4. Если между понятиями R1, R2 существует связь 1 : 1 или 1 : М - то когда связь обязательная, в R2
добавляют ключ R1; в противном случае создают отдельное отношение связи R3(N1,N2).
Пример. Рассмотрим три понятия:
ОБЩЕЖИТИЕ (№_комнаты, Площадь, старший,...) , СТУДЕНТ с теми же свойствами и ГРУППА (№
группы, наставник,...). Связи:
ОБЩЕЖИТИЕ —> СТУДЕНТ < — ГРУППА
Связь 1 не является обязательной, так как не все живут в общежитии, поэтому для нее создадим
отдельное отношение. Вторая связь обязательная, так как любой студент относится к какой-то учебной
группе , поэтому эту связь отобразим в виде дополнительного свойства в отношении СТУДЕНТ:
ОБЩЕЖИТИЕ(№ комнаты, Площадь, Старший, ...)
СТУДЕНТ (№ зач книжки, ФИО, АДРЕС, Стипендия, № Группы).
ГРУППА (№ группы, наставник)
СТУДЕНТЫ_В_ОБЩЕЖИТИИ (№ комнаты, № зач книжки )
5. Если между понятиями связь M : N, то она отображается дополнительным отношением R3(N1,N2,
...), где N1, N2 - ключи связанных понятий.
Пример. Между понятиями КНИГА (Уч номер, название, Автор,...) и СТУДЕНТ(...) связь M : N. Для
отображения этой связи описываем отношение: ВЫДАЧА_КНИГ(Уч номер, № зач книжки,
дата_выдачи, дата_сдачи)
6. Сложное ассоциированное понятие представляют в виде одного отношения, атрибуты которого
соответствуют ключам подчиненных объектов (предыдущий пример).
7. Обобщенное понятие можно представить разными способами, выбор которых зависит от частоты
совместной обработки категорий и от степени различия их свойств. Крайними случаями являются:
a. создание одного отношения, включающего свойства всех частей и ключ обобщенного понятия;
b. представление каждой части отдельным отношением, которое содержит свойства каждой части,
общие свойства и ключ всего понятия.
Пример. Рассмотрим обобщенное понятие УЧАЩИЕСЯ, состоящее из категорий СТУДЕНТ,
АСПИРАНТ, ШКОЛЬНИК.
Вариант a:
УЧАЩИЕСЯ (№ учетный, ФИО, Адрес, место учебы, Группа (класс, кафедра), год_поступл, тема)
Вариант b:
СТУДЕНТ(№ учетный, ФИО, Адрес, Институт, Группа)
АСПИРАНТ (№ учетный, ФИО, Адрес, Институт, кафедра, год_поступл, тема)
ШКОЛЬНИК (№ учетный, ФИО, Адрес, Школа, Класс)
8. В качестве ключей простых и обобщенных понятий выбирают короткий код. Для ассоциированных
понятий и агрегатов ключ будет состоять из кодов подобъектов (составной ключ). Например, ключ
отношения СТУДЕНТ - простой: № зачетки; ключ отношения ВЫДАЧА_КНИГ составной : Уч номер, №
зачетки,
Контрольные вопросы