Множества, мультимножества и списки

Для ТОГО чтобы различать множества, мультимножества и списки следует ПОМНИТЬ; что элементы множества не упорядочены и каждый из них входит в данное множество только один раз. Мультимножество допускает более одного вхождения любого элемента, но элементы и их вхождения не упорядочены. В списке может быть несколько вхождений одного и того же элемента, но все вхождения D нем упорядочены. Значит, {I, 2, I) и {2, I, 1) - это одно и то же мультимножество, но {I, 2, 1} и {2. I, 1} - это разные списки.

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

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

Тип связи - это или тип интерфейса, или тип набора, примененный к типу интерфейса.

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

Пример 2.6. Во1к{ожные типы атрибутов:

1. integer.

2. Struct N {string fieldl. integer field2}.

3. Ljsl<real>.

4. Array<Struct N {string fieldl, integer field2}>.

Здесь 1 - атомарный тип, 2 - структура атомарных типов, 3 - множество атомарного типа, а 4 - множество структур, построенных из атомарных типов.

Допустим, что доступными базовыми типами являются имена интерфейса Movie и Star Тогда можно построить типы связи Movie или Bag<Star>. Однако следующие типы связей недопустимы:

1. Struct N {Movie fieldl. Star field2}. Типы связей не могут включать в себя структуры.

2. Set<integer>. Типы связей не могут содержать атомарные типы.

3. Sel<An-ay<Stan . Типы связей не могут содержать два применения типов множества (их не могут содержать и типы атрибутов). □

2.1.8 Упражнения к разделу 2.1

♦ Упражнение 2.1.1. Предположим, что проектируется БД для байка, содержащая информацию о клиентах и их счетах. Информация о клиенте - это его имя,

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

Упрожненис 2.1.2. Модифицируйте описание из предылушего упражнения согласно перечисленным ниже четырем условиям. Причем новую схему строить необя-Зательно - надо просто описать внесенные изменения.

a) Только один клиент может быть указан как владелец счета.

b) В дополнение к предыдущему условию один клиент не может иметь более одного счета.

c) Каждый адрес имеет три компонента: улицу, город и страну. Клиенты могуг иметь любое число адресов и телефонов.

!d) [Слиенты могут иметь любое число адресов, являющихся тройками, как и в пункте (с); с каждым адресом связано множество телефонов. Это означаег, что нужно записать адреса каждого клиента и номера телефонов, соответствующие каждому из его адресов. Примечание: помните об ограничениях на типы атрибутов и/или связей.

Упрожненис 2.1.3. Опишите в ODL БД. содержащую информацию о командах, игроках и их болельщиках, в том числе:

1. Укажите название каждой команды, ее игроков, капитана (одного из игроков) и цвета ее спортивной формы.

2. Укажите имя каждого игрока.

3. Укажите имя каждого болельщика, его любимую команду, любимого игрока и любимый цвет.

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

*1 Цпрожненнс 2.1.5. Предположим, нужно составить генеалогическое дерево. Имеется единственный класс Person. Информация, которую необходимо записать о человеке, состоит из его имени (атрибут) и следующих связей: мать, отец и дети. Опишите в ODL класс Person. Обязательно укажите обращения связей, которые, подобно mother, father и children, служат и связями класса Person с самим собой. Является ли children инверсией связи mother? Почему? Опишите каждую связь и ее обращение как множества пар.

I ипрожненис 2.1.6. Добавим к описанию предыдущего упражнения атрибут education. Предполагается, что его значением является число ученых степеней, полученных каждым человеком, и их названия (например, бакалавр), название учебного заведения и дата его окончания. Набором структур может быть множество, мультимножество, список или массив. Опишите результат применения каждого из этих вариантов. Какую инфор.мацию можно зафиксировать или потерять в каждом случае? Имеет ли утраченная информация практическое значение?

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

Упрожнение 2.1.8. Рассмотрим ODL-определение классов Ship и TG {целевая группа, множество кораблей), приведенное на рис. 2.7.

1) interface Ship {

2) attribute string name;

3) attr bute int yearLaunched;

4) re ationship TG assignedTo inverse TG :; unitsOf; ):

5) interface TG {

6) attribute real number;

7) attribute string commander;

8) relationstiip Set<Stiip> unitsOf;

inverse Ship:: assignedTo;

Рие. 2.7. ODL-олисоние кораблей и цепевьа групп

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

a) Тип атрибута commander становится парой строк, первая из когорых - ранг командира, а вторая - его имя.

b) Корабль может быть придай более чем одной целевой группе.

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

И Упрожнение 2.1.9. При каких условиях связь является своим собственным обращением? Совет предсгавьте связь в виде множества пар, как было показано в разделе 2.1.5.

1 Упрожнение 2.1.10. Допустимо ли, чтобы тип бьш одновременно типом атрибута ODL и типом связи ODL? Объясните, почему.

2.2 Диаграммы сущности-связи

Существует графический метод моделирования БД, называемый диаграммами сущности-связи (entity-relationship, C/R), который весьма соответствует объектно-ориентированному под-ходу. Эти диаграммы имеют тс же три главных компонента, о которых roBopibTOCb при описании ODL (хотя модели E/R и ODL имеют особенности, о которых речь пойдет ниже).

Компоненты E/R:

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

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

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