3-2 Переход от проектов ODL к реляционным проектам

PaccMOTpirM процесс построения новой БД. Он начинается с фазы проектирования, во время которой мы отвечаем на вопросы о том, какая информация будет храниться, какие ее элементы будут связаны между собой, какие npeflnoj агаются ограничения и т.д. Эта фаза длится до тех пор, пока не оцене1п>1 и не согласованы различные варианты.

За фазой проектирования следует фаза реализации с применением реальной СУБД. Поскольку в подавляющем большинстве коммерческих СУБД используется реляционная модель, люжно предположить, что и на фазе проектирования должна применяться эта модель, а не ODL или E/R модель, рассмотренные в главе 2,

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

В этом разделе рассматривается, как проект ODL преобразуется в реляционный проект. В разделе 3.3 рассматривается конверсия E/R-модели в реляционную модель, а п разделе 3 4-вопросы, связанные с подклассами. Поскольку классы в ODL и в E/R-модели трактуются не совсем одинаково, различаются и их перево ДЫ в отношения.

Часто ограничения считаются частью схемы БД. Ограничения в ODL или E/R-мо.аели типа к.лючей либо ограничения ссылочной целостности можно выразить и в реляционной vio.aejni. В разделе 3.5 рассматривается важный класс 01раниче НИИ, называемый функциональными зависи.мостями, а изучение других ограничений на отношения начнется с раздела 4.5.

3.2.1 Переход от ODL

к реляционным атрибутам

Дли начала предположим, чю наша цель иметь одно отношение для каждого класса и один атрибут для каждого свойства этого отношения. Далее показано много способов, которыми должен быть изменен этот подход; пока же рассмотрим самьм1 простой cjiyMaii, в котором действительно .можно конвергировать классы в отношения, а своПстна в ,ттрн6\ты. Принимаются следующие ограничения:

1. Все свойства класса представляют собой атрибуты (а не отношения или методы).

2. Типы атрибутов атомарны (не являются структурами или множествами).

Пример 3.2. Пример уйовлетаоряюн1его этим ограничениям класса показан на рис. 3.2. здесь четыре атрибута и нет никаких других свойств. Все атрибугы имеют лтомарньиТ тип; title это строка year и lengtti целые числа, а filnrType- перечисление двух знвчеиий.

II Упражнение 3.1,2. Сколько существует различных способов представления

экземпляра отношения (связанных с порядком кортежей и атрибутов), если оно имеет:

*а) Три атрибута и гри кортежа, как отношение Accounts на рис. 3.4

b) Четыре атрибут.) и пять кортежей

c) п атрибутов и т кортежей

Представление перечней и дат

Некоторые атомарные типы ODL - перечни и даты - нельзя представить непосредственно в сташартной реляционной модели. Однако они не вызывают серьезнььч проблем. Например, перечень - это список псевдонимов нескольких первых целых чисел. Поэтому тип перечень ODL для дней недели можно представить атрибутом с типом целого числа, используя только числа от О до б. Атрибут типа строки применяется с днями, предстааленными строками Мои , I Tues и т.д. Аналогичным образом, даты в ODL разрешается представить ( в реляционной модели посредством атрибута типа строки. Обсуждая в главе 5

Lреляционный язык запросов SQL, обнаруживаем, что он, как и ODL, поддерживает типы атрибутов, являющиеся перечнями или датами.

3-2.2 Неатомарные атрибуты в классах

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

Проще всего оперировать со структурами записей, поля которых атомарны: относительно просто расширить определение, создавая один атрибут отношения для каждого поля структуры. Единственная проблема здесь в том, что две структуры могут иметь поля с одинаковым именем. В этом случае при.ходится вводить новые имена атрибутов для различения таких полей в отношении.

Пример 3.3. Рассмотрим определение класса Star из примера 2.3, воспроизведенное на рис. 3.5.

interface Star {

attribute string name, attribute Struct Addr

{string street, string city} address:

Рис. 3.5. Илосс со структурировонным атрибутом

Создадим отношение с тем же именем Movie. Имена реляционных атрибутов могут совпадать с именами соответствующих им атрибутов класса. Схема этого отношения:

Movie{title. year, length, filmType)

как ii в разделе 3.1.1.

Объект данного класса имеет значения дня каждого из четырех атрибутов класса. Кортеж для этого объекта можно образовать, используя каждое значение атрибута в качестве компонента Результат такого преобразования нам уже известен. Пример преобразования некоторых объектов Movie в кортежи показан на рис. 3.1. □

name j street

Carrie Fistier 123 Maple St.

Mark Hamill Harrison Ford

456 Oak Rd. 789 Palm Dr.

City Hollywood Hollywood Beverly Hills

Рис. 3,6. Отношение, предстовлпккцее ниноэяезд

Однако структуры записей еще не самые сложные виды атрибутов, которые пояаляются в определениях классов ODL. Значения можно строить с помошью конструкторов типов Set. Bag, Array и List. Каждый из них вызывает особые проблемы при переходе к реляиионной модели. Здесь мы подробно рассмотрим только наиболее распространенный конструктор - Set

Замечание о качестве данных :-)

I Стремясь сделать при.мер данных максимально точным, мы, тем не ме-

j нее, использовали фиктивные значения для адресов и другой персональной

1 инф01)маиии о кинозвездах, чтобы не нарушать личные интересы актеров,

* многие из которых настолько застенчивы, что избегают публики.

Один из способов представления множества значений для атрибута А - создание одного кортежа для каждого значения. Такой кортеж содержит подходящие значения для всех атрибутов, кроме А. Сначала рассмотрим пример того, когда такой способ хорошо действует, а затем выясним связанные с ним трудности.

Пример 3.4. Предположим, что класс Star определен так, что для каждой кинозвезды можно записать множесгво адресов. Определение класса ODL дано на рис. 3.7.

interface Star {

attribute string name, attnbute Set<

Struct Addr {string street, stnng city} > address;

Рис. 3.7. Кшюэвезды с множеавом ogpecoe

Атрибут name атомарен, но атрибут address -это структура с двумя полями, streel н city. Поэтому ланимЯ класс можно представить в виде отиошения с двумя атрибутами. Первый и1 mi.x. name, соотеетствует атрибуту ODL с таким же именем, а Biopofi и третий, street и city.-двум полям структуры address и вместе составляют адрес. Схема р:ксм;1тривасм010 представления:

Star(name. street, city)

Пример экземпляра этого отношения с некоторыми возможными кортежами показан на рис. 3.fi. □