Государственное образовательное учреждение Высшего профессионального образования Санкт-Петербургский государственный политехнический университет Факультет технической кибернетики Кафедра измерительных информационных технологий
		УТВЕРЖДЕНО На заседании кафедры ИИТ Протокол №4 От «__» февраля 2009 г.
Лабораторная работа № 3 по курсам «Базы данных» «Системы управления базами данных» «Управление данными»
Переход от моделей данных к реляционным проектам
Санкт-Петербург 2009

1. Переход от odl проектов к реляционным проектам

Определим правила перехода от ODL-модели к реляционному проекту. Пусть атрибуты в классах представлены простыми типами и связи отсутствуют. Тогда для каждого класса создается отдельное отношение. Если атрибуты в классах представлены сложными типами, структурами, множествами, списками и связи отсутствуют, то требуется представление сложного типа через множество простых типов данных. Например, если актеры имеют несколько домов, то адреса актеров представлены множеством структур:

interface Actors {

attribute string name;

attribute string ampoule;

attribute Set<Struct Address(string Street, string City}> address;}

Каждую структуру представляют множеством простых типов, например, структуру адреса представим атрибутом city для города и street для улицы: Actors(name,ampoule,city,street). Для представления атрибута, заданного в ODL как множество, используется метод расширения множества на несколько кортежей отношения. Например, если для Ольги Бородиной в базе данных указано два адреса, то применив метод, получим для актрисы два кортежа:

name	street	city	Ampoule
Olga Borodina	Nevsky av.148	S-Petersburg	Singer
Olga Borodina	Palm-st.456	S-Francisco	Singer
Irina Bogacheva	GrateSea-st.33	S-Petersburg	Singer

В результате получается избыточное представление данных, в котором специальность артиста повторяется дважды. Имя тоже повторяется дважды, но это не представляет избыточность, поскольку имя является идентификатором кортежа.

Рассмотрим, как представить в реляционном проекте однозначные связи ODL-модели. Например, в классе Performances имеется однозначная связь ownedBy с театром, поставившим спектакль:

intrface Performances(

attribute string title;

attribute integer year;

attribute integer runningTime;

attribute enum Type{concert, perform} type;

relationship set<Actors> Players

inverse Actors::ActorsedIn;

relationship Theatres ownedBy

inverse Theatres::owns;},

а в интерфейсе Theatres имеется обратная связь театра со спектаклем.

В реляционной модели нет указателей. Указатели следует имитировать с помощью связывания объектов. Для этого используют множества ключевых атрибутов двух связываемых объектов. Тогда связь трактуется как включение в схему ключевых атрибутов связанного класса.

Для представления однозначной связи между спектаклем и театром в отношение Performances введем атрибут, который является ключом для отношения Theatres:

Performances(title,year,runningTime,type,TheatresName),

а в отношение Theatres введем атрибуты {title,year}, которые являются ключом для отношении Performances:

Theatres{name,street,city,title,year}

Несколько более сложной задачей является представление в реляционной модели многозначных связей. Для этого используется комбинация двух методов:

• как и в случае однозначных связей следует определить ключи для каждого объекта и добавить ключевые атрибуты в отношение для связываемых объектов;

• многозначные связи следует представить множеством кортежей, по одному кортежу на каждый элемент связываемого множества.

Например, для представления многозначной связи между спектаклем и актерами «relationship set<Actors> Players inverse Actors ::actsIn» сначала введем в соответствующие отношения ключевые атрибуты связываемых объектов: атрибуты {actorsName, actorsAddress) - в отношение Performances, атрибуты {perfTitle,perfYear}- в отношение Actors:

Performances(title,year,runningTime,type,theatresName, actorsName,actorsAddress)

Actors(name,ampoule,street,city,perfTitle,perfYear},

затем вводим множество кортежей, соответствующих множеству актеров, участвующих в спектакле. Тогда отношение для спектаклей имеет вид:

Performances

title	year	Running Time	type	Theatres Name	Actors Name	actorsAddress
Aida	1998	280	perf	Mariinsky	Mlada Khudoley	S. Petersburg Nevsky av.10
Aida	1998	280	perf	Mariinsky	Mariana Tarasova	S. Petersburg Garden st.55
Aida	1998	280	perf	Mariinsky	Edem Umerov	Moscow Garden Ring av.120
Iolanthe	1974	122	conc	Mariinsky	Marina Shaguch	Moscow Kutusov av.120

Такое представление связано с избыточностью. Если изменилась длительность спектакля, то эти изменения необходимо сделать во всех кортежах, введенных для каждого актера, занятого в спектакле. Избыточность увеличивается еще больше, если в реляционной модели требуется отразить связь “многие со многими”. Например, если объект А имеет множественные связи с объектами В_1,В_2,…,В_k, тогда количество кортежей в отношении для объекта А равно n₁n₂…n_k, где n_i – количество связей с объектами типа В(i=1,2…k).Обратные связи теоретически тоже должны быть представлены множеством кортежей, (в отношениях для В). Однако эти связи в реляционной БД являются избыточными.

Таким образом, реляционная модель для связи между таблицами вместо указателей использует ключи. Если база данных существует на устройствах внешней памяти, то такая реализация является скорее достоинством реляционной модели, поскольку реализация указателей была бы даже сложнее, чем реализация реляционной модели. Указатели имеют очевидные преимущества при работе с оперативной памятью.