Переход от 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 как множество, используется метод расширения множества на несколько кортежей отношения. Например, если для Ольги Бородиной в базе данных указано два адреса, то применив метод, получим для актрисы два кортежа:

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

Рассмотрим, как представить в реляционном проекте однозначные связи 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

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

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

Дата добавления: 2015-07-26; просмотров: 252; Нарушение авторских прав

Мы поможем в написании ваших работ!