2-1.6 Множественность связей

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

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

Пример 2.5. На рис. 2.6 приводится описание трех классов: Movie, Star и Studio. Первые два из них уже были введены в примерах 2.1 и 2.2. Объекты студий имеют атрибуты name и address, появляющиеся в строках 13 и 14. Заметим, что здесь типом адресов является строка, а не структура, использованная для атрибута address класса Star в строке 10. В различных классах можно использовать атрибут с одним и тем же именем, но с разными типами.

1) interface Movie {

2) attribute string title;

3) attribute integer year;

4) attribute integer length;

5) attribute enum Film {color, blackAndWhite} filmType;

6) relationship Set<Star> stars

inverse Star:: starredin;

7) relationship Studio ownedBy

inverse Studio:: owns;

8) interface Star {

9) attribute string name;

10) attribute Stnjct Addr

{string street, string city} address;

11) relationship Set<Movla> starredin

inverse Movie:: stars;

12) interface Studio {

13) attribute string name;

14) attribute siring address;

15) relatfonship Set<Movle> owns

inverse Movie.. ownedBy;

Put. 2.6. Нлассы ODL и их сепзи

На строке 7 показана связь ownedBy между фильмами и студиями. Поскольку ее тигюм является Studio, а не Set<Studio>, каждым фильмом владеет только одна студия Обращение данной связи показано в строке 15 - это связь owns между студиями и фильмами. Ее типом является Set<Movie>, поэтому каждая студия владеет множеством фильмов - возможно, ни одним, только одним или большим числом филь.мов. □

Зависимости между типами связей

Следует иметь в виду, что связь типа многие-к-одному - это частный случай связи типа многие-ко-многим , а связь типа один-к-одному - частный случай связи типа многие-к-одному . Любое полезное свойство связей типа многие-ко-многим применимо к связям типа многие-к-одному , а полезные свойства последних верны и для связей типа один-к-одному . Например, структура данных для представления связей типа многке-к-одному подходит I для связей типа один-к-одному . но .может быть непригодна для связи типа j многие-ко-многим .

Если говорится, что связь R относится к типу многие-ко-многим . в дей-

t с гвительиостп это означает, что R люжет быть такой. Со временем при i изменении R, возможно, станет связью типа .многие-к-олному или лаже i один к-одному . Аналогично, связь типа многие-к-сдно.\гу иногда южeт ! быть связью типа один-к-слно.му .

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

Требования уникальности связи и ее обращения называются множеатепиостыо сш13ей. Наиболее распространенные варианты:

1. Свюь типа многие-ко-лтогим класса С с классом /) -это связь, в которой с каждым объектом класса С ассош1ируе1Ся множество объектов класса Д а в се обращении с каждым объектом класса Л ассоциируется множество объектов класса С. В описании, приведенном в примере 2.5, stars - это связь типа многие-ко-многим между классом Movie и классом Star; такой же является связь starredin между классами Star и Movie. В любом направлении связи допускается пустое множество; например, в определенном фильме может вообще не быть звезд.

2. Связь типа многие-к-одному класса С с классом D - это связь, в которой для каждого объекта класса С существует уникальный объект класса О, но в ее обращении с каждым объектом класса D связаны многие С. В примере 2 5 ownedBy - это связь типа многие-к-одному класса Movie с ютас-сом Studio. Обратная ей связь ~ это связь пипа один-ко-многим класса D с классом С. В том ; е примере ow/ns - связь типа олин-ко-многим класса Studio с классом Movie.

3. Связь типа один-к-одному класса С с к.лассом D - это связь, в которой для каждого объекта класса С существует уникальный объект класса D. В обратной связи каждый объект класса D связан с уникальным объектом класса С. В описание из примера 2.5 добавим класс President, представляющий президентов киностДИй. Предполагается, что каждая студия имеет единственного президента и ни один человек не может быть президентом более чем одной студии. Значит, связь между студиями и их президентами имеет тип один-к-одному в обоих направлениях.

Таким образом, обычно допускается, что предполагаемое значение связанного объекта может отсутствовать. Позднее мы увидим, что значение null часто допускается в БД там, где предполагается наличие истинного значения. Например, в терминологии традиционного программирования указатель nil может стоять там. где предполагается указатель на единственный о&ьект. В разделе 2.5 будут рассмотрены ограничения иелостности и механизмы введения условия, согласно которому уникальные объекты должны сушествовать без всяких исключений.

2.1.7 Типы в ODL

ODL предоставляет проектировщику БД систему типов, подобную системам типов языка С или других конвенциональных языков программирования. Система гипов строится из базовых типов, которые определены сами по себе, с помощью конкретных рекурсивных правил (сложные типы строятся из более простых). Базовые типы ODL:

1. Атомарные типы: целое число, плавающая точка, символ, строка символов, булево выражение и перечисление. Последний тип - это список имен, объявленных синонимами целых чисел. Перечисление содержится в строке 5 рис. 2.6, где имена color и blackAndWhite в результате были определены как синонимы чисел О и I.

2. Типы интерфейса, например Movie и Star, являются реальными структурами с компонентами для каждого атрибута и каждой связи данного интерфейса. Эти имена представляют сложные типы, определяемые с помощью перечисленных ниже типов, но их можно считать базовыми.

Базовые типы комбинируются в структурные типы с помощью следующих конструкторов типов:

\. Множество. Если Г-любой тип, то Set<T> обозначает тип, значениями которого являются все конечные множества элементов типа Т. Примеры применения этого конструктора типов содержатся в строках б, 11 и 15 на рис, 2,6,

2. Мультимножество. Если Г- любой тип, то Вад<Т> обозначает тип. значениями которого являются все мультимножества элементов типа Т. Мультимножество позволяет многократное повторение одного и того же элемента. Например, (1, 2, I) -это мультимножество, а не множество, так как 1 повторяется в нем дважды.

3. Список. Если 7-любой тип, то List<T> обозначает тип, значениями которого являются конечные списки, состоящие из нуля или более элементов типа Т. В специальном случае тип string является сокращением типа List<char>,

4. Массив. Если 7- любой тип, то Аггау<Т> обозначает тип, элементами которого являются массив из i элементов типа Т. Например, Array<char.10> обозначает символьную строку длиной 10.

5. Структуры. Если 7, Гз..... Т являются типами, а Fx. Fj, . . F. именами

полей, то

Struct N{T, F,.TjFj.....T FJ

обозначает тип с именем N. элементами которого служат структуры, содержащие я полей; 1-е поле имеет имя F, и тип Г,. Например, строка 10 на рис. 2.6 покозываеттип структуры с именем Addr и двумя полял1И. Оба поля имеют тип string и Имена street и city соответственно.