Таблица 5.5.: Обобщение. Пример в табличной форме (см. 5.7.2, табл. 5.4)

48

5.8.Композиция

5.8.1. Абстрактная схема

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

Обязательными на родительском конце являются связи трех видов – полностью и неполностью идентифицирующие и обязательные неидентифицирующие.

Но полностью идентифицирующие связи используются при обобщении. Почему они возникли при композиции?

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

Примечание. Крыша – это не дом, обладающий дополнительными специфическими свойствами, а часть дома

Различия в идентификации компонентов проявляются и случаях установления неполностью идентифицирующих и обязательных неидентифицирующих связей. Обе связи устанавливают тип связи один-ко-могим (1 : 0 : : : 1) и в этом смысле аналогичны. Но рассмотрим пример композитной иерархии «Дом – Подъезд – Квартира»:

Дома(№ Д) primary key(№ Д)

Подъезды(№ Д, № П) primary key(№ Д, № П)

foreign key(№ Д) references Дома(№ Д)

Квартиры(№ Д, № П, № кв) primary key(№ Д, № кв)

foreign key(№ Д) references Дома(№ Д)

foreign key(№ Д, № П) references Подъезды(№ Д, № П)

В композиции «Дом – Подъезд» устанавливается идентифицирующая связь, а в композиции «Подъезд – Квартира» – неидентифицирующая.

На презентационных диаграммах связь «композит-компонент» удобно изображать в нотации UML (рис. 5.30).

Если требуется подчеркнуть кратность вхождения компонента в композит, то ее можно указать на дочернем конце связи (рис. 5.31).

Рис. 5.30.: Cвязь «композит-компонент» в нотации UML

Рис. 5.31.: Cвязь «композит-компонент» в нотации UML с указанием кратности

Построим абстрактные диаграммы (рис. 5.32, 5.33), реализующие композицию в реляционной модели.

5.8.2. Пример реализации композиции

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

1)Построить презентационную диаграмму.

2)Построить ключевую диаграмму. Привести маркеры атрибутов ключей и указать кратности связей. Какой вид связей используется?

Рис. 5.32.: Композиция. Абстрактная презентационная диаграмма

Примечание. Например, для дома, как композита, видами компонентов могут быть подъезды, квартиры, подвалы, крыша. Стрелки, как и в случае обобщения, можно и не сливать

3)Сформулировать и записать на псевдокоде декларативные правила поддержания ссылочной целостности. Обосновать на содержательном уровне выбор правил.

4)Привести пример в табличной форме.

Решение. Презентационная и ключевая диаграммы представлены на рис. 5.34, 5.35 соответственно. Связь с классом Аудитории является неполностью идентифицирующей, а с классом Буфеты – полностью идентифицирующей.

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

Рис. 5.33.: Композиция. Абстрактная ключевая диаграмма

Примечание. Здесь проиллюстрирована возможность установления трех видов связей «композит-компонент»

понятий композита и его компонента и препятствовало бы дальнейшему развитию всего проекта. Приведем фрагмент оператора создания базового отношения Аудитории (аналогично и для отно-

шения Буфеты) с определением правил поддержания ссылочной целостности:

create table Аудитории primary key(№ К, № А)

foreign key(№ К) references Корпуса(№ К) on update cascade

on delete cascade

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

Пример в табличной форме приведен в табл. 5.6.

Таблица 5.6.: Композиция. Пример в табличной форме (см. 5.8.2)

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