- •Установочный модуль
- •Введение
- •Модуль 1
- •Реляционная алгебра
- •Отсутствующие данные
- •Пустые значения
- •Неопределенные значения
- •Интерпретации
- •Правила вычисления выражений
- •Следствия
- •Проверка условий
- •Реляционные объекты данных
- •Формальные определения
- •Домены и атрибуты
- •Схема отношения
- •Именованное значение атрибута
- •Кортеж
- •Отношение
- •Схема базы данных
- •База данных
- •Операции реляционной алгебры
- •Унарные операции
- •Бинарные операции
- •Варианты операции соединения
- •Производные операции
- •Пример построения выражения реляционной алгебры
- •Понятие базовых и виртуальных отношений
- •Понятие полноты реляционной алгебры
- •Формирование запросов на языке SQL
- •Металингвистические символы
- •Реализация операций реляционной алгебры
- •Пример использования подзапросов
- •Группирующие запросы
- •Упорядочение результатов
- •Вопросы для самоконтроля
- •Упражнения
- •Построение выражений реляционной алгебры
- •Модуль 2
- •Базовые и виртуальные отношения
- •Типы данных
- •Базовые типы данных
- •Типы данных, определяемые пользователем
- •Первичные и кандидатные ключи
- •Создание базовых отношений
- •Индексы
- •Модификация базовых отношений
- •Вставка строк
- •Обновление строк
- •Удаление строк
- •Целостность
- •Декларативная поддержка
- •Пример декларативной поддержки целостности
- •Транзакции и блокировки
- •Триггеры
- •Виртуальные отношения
- •Вопросы для самоконтроля
- •Упражнения
- •Декларативная поддержка целостности
- •Модуль 3
- •Нормальные формы
- •Функциональные зависимости (ФЗ)
- •Правила вывода Армстронга
- •Производные правила вывода
- •Независимость правил Армстронга
- •Полнота системы правил Армстронга
- •Нормальные формы
- •Первая нормальная форма (1NF)
- •Вторая нормальная форма (2NF)
- •Третья нормальная форма (3NF)
- •Нормальная форма Бойса-Кодда (Boyce, Codd; NFBC)
- •Пример построения нормализованных схем отношений
- •Вопросы для самоконтроля
- •Модуль 4
- •Проектирование схем баз данных
- •Уровни логической модели
- •Миграция ключей и виды связей
- •Классификация кластеров
- •Иерархическая рекурсия
- •Абстрактная схема
- •Обобщения
- •Пример реализации иерархической рекурсии
- •Сетевая рекурсия
- •Абстрактная схема
- •Сетевая реализация иерархической рекурсии
- •Обобщения
- •Пример реализации сетевой рекурсии
- •Ассоциация
- •Детализация связей многие-ко-многим
- •Обобщения
- •Пример реализации ассоциации
- •Обобщение
- •Абстрактная схема
- •Пример реализации обобщения
- •Композиция
- •Абстрактная схема
- •Пример реализации композиции
- •Агрегация
- •Абстрактная схема
- •Пример реализации агрегации
- •Унификация атрибутов
- •Вопросы для самоконтроля
- •Упражнения
- •Иерархическая рекурсия
- •Сетевая рекурсия
- •Ассоциация
- •Обобщение
- •Композиция
- •Агрегация
- •Дополнительные главы
- •Технологии баз данных
- •Информационные системы
- •Жизненный цикл ИС
- •СУБД и БД
- •Жизненный цикл БД и средства проектирования
- •Модели данных
- •Иерархическая модель данных
- •Сетевая модель данных
- •Реляционная модель данных
- •Постреляционная модель данных
- •Объектно-ориентированные модели данных
- •XML как модель данных
- •Многомерная модель данных (OLAP)
- •Основные функции СУБД
- •Управление данными во внешней памяти
- •Управление буферами оперативной памяти
- •Управление транзакциями
- •Журнализация и восстановление БД после сбоев
- •Поддержка языков баз данных
- •Типовая организация СУБД
- •Модели взаимодействия с БД
- •Модель с централизованной архитектурой
- •Модель с автономными персональными компьютерами
- •Архитектура «файл-сервер»
- •Архитектура «клиент-сервер»
- •Архитектура «клиент-сервер» трехзвенная
- •Распределенные базы данных
- •Технология тиражирования данных
- •Понятие «фрактал»
- •Геометрические фракталы
- •Алгебраические фракталы
- •Стохастические фракталы
- •Системы итерируемых функций
- •Вопросы для самоконтроля
- •Литература
- •Список иллюстраций
- •Список таблиц
Таблица 5.5.: Обобщение. Пример в табличной форме (см. 5.7.2, табл. 5.4)
|
Школьники |
|
|
Студенты |
|
|
Аспиранты |
|||||||||
|
КодУ |
Класс |
... |
|
|
КодУ |
Курс |
... |
|
|
КодУ |
Год обучения |
... |
|||
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
1 |
9 |
|
|
2 |
5 |
|
|
3 |
1 |
|
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.: Композиция. Абстрактная ключевая диаграмма
Примечание. Здесь проиллюстрирована возможность установления трех видов связей «композит-компонент»
Рис. 5.34.: Композиция. Презентационная диаграмма (см. 5.8.2)
Рис. 5.35.: Композиция. Ключевая диаграмма (см. 5.8.2)
понятий композита и его компонента и препятствовало бы дальнейшему развитию всего проекта. Приведем фрагмент оператора создания базового отношения Аудитории (аналогично и для отно-
шения Буфеты) с определением правил поддержания ссылочной целостности:
create table Аудитории primary key(№ К, № А)
foreign key(№ К) references Корпуса(№ К) on update cascade
on delete cascade
Здесь можно было бы применить правило ограничения restrict, но это ввиду большого числа аудиторий существенно затруднило бы удаление данных о корпусах.
Пример в табличной форме приведен в табл. 5.6.
Таблица 5.6.: Композиция. Пример в табличной форме (см. 5.8.2)
Корпуса |
|
Аудитории |
|
|
Буфеты |
|||
№ К |
... |
|
№ К |
№ А |
... |
|
№ К |
... |
9 |
|
|
10 |
Нижняя |
|
|
10 |
|
10 |
|
|
9 |
100 |
|
|
9 |
|
1 |
|
|
9 |
100а |
|
|
|
|
|
|
|
|
|
|
|
|
|
Примечание. Заметим, что для атрибута № А и аналогичных атрибутов осмысленными являются операции сравнения, но ни в коем случае не арифметические – вряд ли какой либо смысл можно придать