SELECT ORDER_NUM, CUST_NUM, PROD_ID, QTY, DATE_ORDER 3 страница

Пример 4.9. Можно определить подкласс жилет класса Изделие:

 

1) interface Жилет: Изделие{

2) attribute string материал_спинки;

};

 

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

Теперь рассмотрим изделие "жилет из меха", являющееся и меховым изделием, и жилетом. Кроме обычных свойств класса Изделие, такие изделия должны иметь связь скорняжный_пошив и атрибут материал_спинки. Эту ситуацию можно описать, определив подкласс, являющийся подклассом обоих классов Меховое_изделие и Жилет:

 

interface Меховой_жилет: Меховое_изделие, Жилет {

};

 

Итак, объект Меховой жилет определяется для выражения всех свойств обоих подклассов Жилет и никаких свойств или связей, принадлежащих только меховым жилетам, не вводится. Объекты класса Меховой_жилет наследуют атрибут материал_спинки класса Жилет и связь скорняжный_пошив класса Меховое_изделие. Поскольку классы Жилет и Меховое_изделие, в свою очередь, наследуют атрибуты и две связи класса Изделие, класс Меховой_жилет наследует также и эти атрибуты и свойства. Однако он не наследует двух копий всех этих свойств, а наследует свойства из класса Изделие через любой из двух его непосредственных подклассов. Рис. 46 иллюстрирует связи подкласс-суперкласс, в которых участвуют четыре названных класса.

 

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

Пример 4.10. Предположим, что класс Изделие имеет подклассы Кожаное_изделие и Меховое_изделие, каждый из которых имеет атрибут стиль. Но в классе Кожаное_изделие этот атрибут получает значения из набора {молодежный, всевозрастной}, а в классе Меховое_изделие – из набора {модный, традиционный}. Если затем вводится новый подкласс Кожано-меховое_изделие, суперклассами которого являются Кожаное_изделие и Меховое_изделие, тип наследуемого атрибута стиль в классе Кожано-меховое_изделие остается неясным.

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

1. Можно указать, какое из двух определений данного свойства относится к подклассу. Так, в примере 4.10 считаем, что для изделия из кожи и меха важен не показатель модности, а целевая возрастная категория. Тогда устанавливается, что класс Кожано-меховое_изделие наследует атрибут стиль из суперкласса Кожаное_изделие, а не Меховое_изделие.

2. Можно присвоить в классе С новое имя одному из двух наследуемых свойств с одним и тем же именем. Если в примере 4.10 Кожано-меховое_изделие наследует атрибут стиль из класса Кожаное_изделие, в этом классе можно определить дополнительный атрибут фасон как результат замены имени атрибута стиль, наследуемого из класса Меховое_изделие.

3. В классе С можно заново определить некоторые свойства, определенные в его суперклассах. В примере 4.10 можно считать, что атрибут стиль не должен наследоваться напрямую из любого суперкласса, а переопределить этот атрибут как числовое значение, которое выражает степень удовлетворенности клиентов, выявленную путем их опроса.

Заметим, что даже в примере 4.9 есть конфликты: Кожано-меховое_изделие наследует из каждого непосредственного суперкласса (Меховое_изделие и Кожаное_изделие) свойства, в том числе назв_изделия и мастера, которые эти классы наследовали из класса Изделие. Но поскольку определения назв_изделия и других свойств идентичны в обоих суперклассах, выбирать используемое определение можно вообще любым способом.

4.1.11. Моделирование ограничений

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

Ключи

В ODL ключ класса – это такое множество атрибутов А, что при наличии в данном классе двух различных объектов 01 и 02 они не могут иметь идентичных значений для любого атрибута в ключе К.

В ODL один или несколько атрибутов описываются как ключи класса с помощью ключевого слова key или keys (любого из них), за которым указываются атрибуты, формирующие ключ. Если в ключе больше одного атрибута, список атрибутов заключается в круглые скобки. Описание ключа должно стоять непосредственно за описанием интерфейса, перед открывающей фигурной скобкой или любыми атрибутами либо связями. Само описание ключа заключается в круглые скобки.

Пример 4.11. Чтобы показать, что множество, состоящее из атрибутов фамилия, имя, отчество является ключом для класса Мастер, строка 7 в примере 4.4 заменяется на:

interface Мастер

(key (фамилия, имя, отчество)) { };

 

Вместо key можно применять keys даже если описывается только один ключ.

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

Пример 4.12. Чтобы проиллюстрировать ситуацию, в которой уместно иметь более одного ключа, рассмотрим класс Сотрудник. He будем описывать здесь все множество его атрибутов и связей, но предположим, что его атрибутами являются empID – идентификатор сотрудника и ssNo – номер страхового полиса. Тогда эти атрибуты можно описать как ключ:

(key empID, ssNo).

Поскольку список атрибутов здесь не заключен в скобки, в ODL это означает, что каждый из атрибутов сам является ключом. Если заключить в скобки пару (empID, ssNo), в ODL считается, что эти два атрибута вместе формируют один ключ. Из записи

(key (empID, ssNo))

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

 

Ссылочная целостность

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

Рассмотрим связь выполняется_в между Издел ие и Цех в строке 6 примера 4.4. Разве такое возможно: объект класса Цех является значением выполняется_в, а самого этого объекта не существует? Ответ заключается в том, что в реализации ODL связь выполняется_в представлена указателем или ссылкой на данный объект и в какой-то момент времени этот объект удаляется из класса Цех. Тогда указатель становится висящимибольше не указывает на реальный объект.

Согласно ограничению ссылочной целостности объект, на который есть ссылка, должен существовать. Это ограничение можно ввести по-разному.

1. Можно запретить удаление объекта, на который есть ссылка (в приведенном выше примере – цеха).

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

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

 

Прочиеограничения

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

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

 

4.1.12. Переход от объектно-ориентированной модели

к реляционной

От объектно-ориентированной модели в большинстве случаев достаточно легко перейти к реляционной.

Пусть принимаются следующие ограничения:

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

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

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

В ряде случаев не возникает проблем, даже если некоторые атрибуты не атомарны (такие как дата, перечень). Можно, например, тип "перечень" для дней недели представить целыми числами от 0 до 6.

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

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

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

Ø имеются атрибуты со значением типа множества – нужно представить множество связанных объектов путем создания одного кортежа для каждого значения. При этом появляется избыточность, которая устраняется при переходе к нормальным формам более высокого порядка.

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

4.2. Диаграммы "сущность-связь"

Немаловажную роль в инфологическом проектировании играет наглядность представляемых моделей данных. В этой связи большой популярностью разработчиков пользуются средства, основанные на графических нотациях, самым распространенным средством данного типа являются диаграммы "сущность-связь" (entity-relationship, E/R), которые соответствуют объектно-ориентированному подходу. Эти диаграммы имеют те же три главных компонента, о которых говорилось при описании ODL (хотя модели E/R и ODL имеют особенности, о которых речь пойдет ниже).

 

4.2.1. Компоненты диаграмм "сущность-связь"

1. Множества сущностей, аналогичные классам. Сущности – эточлены множества сущностей, аналогичные объектам ODL.

2. Атрибуты–- это значения, описывающие свойства сущности. Атрибуты в E/R и ODL – это, по сути, одно и то же понятие.

3. Связи – это соединения между двумя или более множествами сущностей. Связи в E/R аналогичны связям в ODL за следующими исключениями:

(a) В модели E/R одно имя приписывается связи в обоих направлениях, а в ODL отдельно определяются связь и ее обращение. Например, обратные связи Изделие:: мастера и Мастер:: от_мастера в примере 4.4 в модели E/R были бы представлены единственной связью.

(b) Связи в E/R могут соединять более двух множеств сущностей, а связи ODL – максимум два класса.

Пример 4.13. На рис. 47 изображена E/R диаграмма, представляющая ту же самую информацию о реальном мире, что и описание ODL в примере 4.5.

Множествами сущностей являются Изделие, Мастер и Цех. Чтобы выразить небольшое различие между множествами сущностей и классами, имена первых пишутся во множественном числе, имена вторых в единственном.

Множество сущностей Изделия имеет те же атрибуты, что и класс Изделие в примере4.5, а именно – название изделия, размер, и тип материала. Аналогично, два других множества имеют атрибуты, которые были описаны для соответствующих классов ODL.

На рис. 47 видны также связи, соответствующие связям из ODL-описания примера 4.5. Одно из них мастером содержит информацию пары обратных связей мастера и от_мастера между ODL-классами Изделие и Мастер. E/R-связь относиться на рис. 44 представляет обратные связи Изделие::выполняется_в и Цех:: обеспечивает. Стрелка, указывающая на множество Цеха, означает, что каждым изделием занимается только один цех.

 

4.2.2. Множественность E/R-связей

 

Для выражения множественности связей в E/R-диаграммах можно применять стрелки. Если между множествами Е и F есть связь типа "многие-к-одному", используется стрелка, указывающая на F. Она означает, что каждая сущность из множества Е связана только с одной сущностью из множества F. Однако сущность из F может быть связана с многими сущностями в Е.

Связь типа "один-к-одному" между множествами Е и F выражается стрелками, указывающими и на Е, и на F. Например, на рис. 48 показаны два множества Цех и Начальник, а также связь между ними Возглавляет (атрибуты не показаны). Предполагается, что начальник может возглавлять только один цех, а у начальника может быть только один цех, что и выражено стрелками, указывающими на оба множества.

Зачастую E/R-связи удобно изображать таблицей, каждая строка которой представляет пару сущностей, вовлеченных в данную связь. Например, связь мастером можно представить так:

 

Изделия	Мастера
Вечернее платье	Иванова
Мужской костюм	Павлов
Дубленка	Семенова

 

Конкретного способа, которым должны реализовываться связи, не существует ни в E/R-моделях, ни в ODL.

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

 

(Вечернее платье, Иванова)

Многосторонние связи

В E/R-моделях, в отличие от ODL, удобно определять связи между несколькими множествами. Однако на практике тернарные (трехсторонние) связи или связи еще более высокого порядка встречаются довольно редко. Многосторонние связи в E/R-моделях изображаются линиями, соединяющими ромб (связь) с каждым из участвующих в

данной связи множеств.

Пример 4.14. На рис. 49 изображена связь Договоры между цехом и мастером на изготовление изделия. Она означает, что цех заключает с мастером контракт на изготовление изделия. В общем случае значением E/R-связи можно считать множество кортежей, компонентами которых являются сущности, вовлеченные в данную связь. Например, связь Договоры можно описать трехмерными кортежами вида:

(цех, мастер, изделие).

В многосторонних связях стрелка, указывающая на множество Е, означает, что из всех других вовлеченных в эту связь множеств выбирается по одной сущности, связанной с единственной сущностью в Е. (Заметим, что такое определение – это обобщение понятия множественности, применявшегося для двухсторонних связей.) На рис. 49 стрелка, указывающая на множество Цеха, означает, что каждый мастер может иметь договор на изготовление конкретного изделия только с одним цехом. Однако здесь нет стрелок, указывающих на Мастера или Изделия. Цех может заключать договор на участие в работе над изделием со многими мастерами, а мастер может заключить контракт с цехом на работу над несколькими изделиями.

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

4.2.3. Роли в связях

 

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

Пример 4.15. На рис. 50 изображена связь Быть_учеником множества Мастера ссамим собой. Каждая связь – это связь между двумя мастерами, один из которых является учеником другого. Для различения этих двух мастеров, в рамках данной связи одна линия отмечена ролью Наставник, а другая ролью Ученик, которые обозначают мастера-наставника и его ученика соответственно. Предполагается, что у наставника может быть много учеников, но у каждого ученика есть только один наставник. Таким образом, стрелка E/R-диаграммы на рис. 50 показывает связь типа "многие-к-одному" множества Ученик с множеством Наставник.

Пример 4.16. В качестве примера, включающего в себя многостороннюю связь и множество сущностей со многими ролями, на рис. 51 дается более сложная версия связи Договоры, введенной в примере 4.5. Здесь показана связь Договоры между двумя цехами, мастером и изделием. Для иллюстрации предполагается, что цех, имеющий договор на пошив изделия с определенным мастером, может заключить со вторым цехом договор, позволяющий привлекать возможности другого цеха, например для получения каких-либо материалов или выполнения тонких работ. Такая связь описывается четверками вида:

(цех_1, цех_2, мастер, изделие),

причем цех_2 заключает с цехом_1 договор на привлечение мастера цеха1 для изделия цеха2.

На рис. 51 есть стрелки, указывающие на Цеха в двух ролях: как "владельца" мастера и как производителя изделия, но нет стрелок, указывающих на Мастера или Изделия. Это значит, что при наличии мастера, изделия и цеха, производящего изделие, только один цех может "владеть" мастером. (Предполагается, что мастер имеет договор только с одним цехом.) Аналогично, данное изделие производится единственным цехом, поэтому при наличии мастера, изделия и цеха, "владеющего" мастером, можно определить единственный производящий изделие цех. Заметим, что обоих случаях для определения уникальной сущности реально нужна только одна из остальных сущностей (например, для определения уникального производящего цеха необходимо знать только изделие), но этот факт не изменяет множественное определение многосторонней связи.

Стрелки не указывают на Мастера или Изделия. При наличии мастера, "владеющего" им цеха и цеха, выпускающего изделия, может быть заключено множество договоров, позволяющих мастеру работать над различными изделиями. Значит, совсем не обязательно, что остальные три компонента в четверке данной связи определяют единственное изделие. Аналогично, производящий цех может заключать контракт с другими цехами об участии нескольких их мастеров при работе над одним своим изделием. Таким образом, мастер не определяется тремя остальными компонентами данной связи.

 

4.2.4. Атрибуты связей

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

(мастер, изделие, цех)

во множестве отношений для связи Договоры. На рис. 52 показана схема рис. 49 вместе с атрибутами. Связь имеет атрибут гонорар, а множества сущностей имеют те же атрибуты, которые были показаны на рис. 47.

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

Пример 4.17. Изменим E/R-диаграмму (рис. 52), на которой связь Договоры имеет атрибут гонорар.

Создадим множество Гонорары с атрибутом гонорар (рис. 53).

4.2.5. Конвертирование многосторонних связей в бинарные

 

В ODL допустимы только бинарные связи, в отличие от E/R-модели. Однако любую сложную связь, включающую в себя более двух компонентов, нетрудно конвертировать в множество бинарных связей типа "многие-к-одному" без потери какой-либо информации. В E/R-модели можно ввести новое множество сущностей, элементами которого являются кортежи множества отношений для многосторонней связи. Такое множество называется множеством связующих сущностей. Затем вводится связь типа "многие-к-одному" этого множества связующих сущностей с каждым множеством сущностей, предоставляющим элемент кортежей исходной многосторонней связи. Если какое-то множество сущностей играет несколько ролей, оно является целевым пунктом одной связи для каждой из ролей.

Пример 4.18. Четырехстороннюю связь (рис. 51) можно заменить множеством сущностей под названием Договоры. Как показано на рис. 54, это множество участвует в четырех связях. Если множество отношений для связи Договоры имеет четверку

(цех_1, цех_2, мастер, изделие)

то сущность множества Договоры соединена связью от_мастера с сущностью мастер из множества Мастера, связью изделие_от с сущностью изделие из множества Изделия, а также связями Цех_мастера и Выполняющий_цех соответственно с сущностями цех_1 и цех_2 из множества Цеха.

 

 

 

Предполагается, что у множества Договоры нет атрибутов, хотя другие множества сущностей на рис. 54 имеют невидимые атрибуты. Можно добавить атрибуты и множеству Договоры, например дату подписания договора, сведения о заказчике.

Многосторонняя связь, подобная показанной на рис. 51, в ODL изображалась бы способом, сходным с описанным выше преобразованием для E/R-модели. Однако в ODL нет многосторонних связей, поэтому данное преобразование не выбирается по желанию – оно обязательно.

Пример 4.19. Допустим, есть классы Мастер, Изделие и Цех, соответствующие каждому из трех множеств сущностей, показанных на рис. 52. Для представления четырехсторонней связи Договоры вводится новый класс Договор, не имеющий атрибутов, но имеющий четыре связи, соответствующие четырем компонентам E/R-связи. ODL-описание показано ниже; обратные связи пропущены. Каждая четверка в E/R-связи Договоры соответствует объекту ODL-класса Договор.

 

interface Договор{

relationship Цех владеет_мастером;

relationship Цех выполняющий_цех;

relationship Мастер мастер_;

relationship Изделие изделие_;

};

 

4.2.6. Проектирование E/R моделей

 

Как уже говорилось, проект должен быть правильным относительно описываемой предметной области. Сущности и их атрибуты, должны отражать реальные объекты.

Простота

Не стоит вводить в проект больше элементов, чем это необходимо.

Пример 4.20. Предположим, что вместо связи между Изделием и Мастером было постулировано существование "договора на особых условиях", предполагающего выполнение заказа на изделие только у одного высококвалифицированного мастера и в самый короткий срок. Тогда можно создать еще один класс или множество сущностей Спецзаказ. Между изделием и единственным специальным договором можно ввести связь обслуживает типа "один-к-одному". И связь типа "многие-к-одному" множества Спецзаказ с множеством Мастера завершает схему, показанную на рис. 55.

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

 

Типы элементов проекта

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

Пример 4.21. Рассмотрим пример, иллюстрирующий эффект от применения многосторонней связи, и эквивалентный пример с использованием бинарных связей. Связь Договоры между мастером, изделием и двумя цехами (рис. 51) является четырехсторонней и механически конвертируется в множество сущностей Договоры (рис. 54). Имеет ли значение, какой из этих подходов выбирается?

Решение в ODL однозначно, так как многосторонних связей не существует. В E/R-модели приемлем любой подход. Однако незначительное изменение исходной задачи практически вынуждает нас выбирать подход, при котором используется множество связующих сущностей. Для иллюстрации предположим, что в договоре могут фигурировать один мастер, одно изделие, но любое множество цехов. Эта ситуация сложнее той, что изображена на рис. 51, где было всего два цеха, играющие две роли. Сейчас допускается любое число цехов. Один, возможно, выпускает изделие, в другом делается плиссировка и т.д. Таким образом, приписать роли цехам невозможно.