Ковалёв А.Д. - Базы данных

САРАТОВСКИЙ ГОСУНИВЕРСИТЕТ
МЕХАНИКО-МАТЕМАТИЧЕСКИЙ ФАКУЛЬТЕТ
Базы данных
Подготовил Ковалев А. Д.
Дата последнего обновления 3 апреля 2009 г.

Оглавление
I. Установочный модуль 11
1. Введение 12
2. Практическое задание 15
2.1. Формулировка задания . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
2.2. Пример выполнения задания . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
2.2.1. Описание предметной области . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
2.2.2. Шаг 0 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
2.2.3. Шаг 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
2.2.4. Шаг 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
2.2.5. Шаг 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
2.2.6. Шаг 4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
2.2.7. Шаг 5 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
2.2.8. Шаг 6 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
2.2.9. Шаг 7 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
2.2.10. Шаг 8 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
2.2.11. Шаг 9 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
2.2.12. Шаг 10 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
2.2.13. Шаг 11 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
2.2.14. Шаг 12 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
2.3. Варианты контрольных работ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
2.3.1. Страховая компания . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
2.3.2. Гостиница . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
2.3.3. Ломбард . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
2.3.4. Реализация готовой продукции . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
2.3.5. Ведение заказов . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
2.3.6. Бюро по трудоустройству . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
2.3.7. Нотариальная контора . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
2.3.8. Фирма по продаже запчастей . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
2.3.9. Курсы по повышению квалификации . . . . . . . . . . . . . . . . . . . . . . . . 43
2.3.10. Определение факультативов для студентов . . . . . . . . . . . . . . . . . . . . . 44
2.3.11. Распределение учебной нагрузки . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
2.3.12. Распределение дополнительных обязанностей . . . . . . . . . . . . . . . . . . . 46
2.3.13. Техническое обслуживание станков . . . . . . . . . . . . . . . . . . . . . . . . . 47
2.3.14. Туристическая фирма . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
2.3.15. Грузовые перевозки . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
2.3.16. Учет телефонных переговоров . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
2.3.17. Учет внутриофисных расходов . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
2.3.18. Библиотека . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
2.3.19. Прокат автомобилей . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
2.3.20. Выдача банком кредитов . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
2.3.21. Инвестирование свободных средств . . . . . . . . . . . . . . . . . . . . . . . . . 55
2.3.22. Занятость актеров театра . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
2.3.23. Платная поликлиника . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
2.3.24. Анализ динамики показателей финансовой отчетности различных предприятий 58
2.3.25. Учет телекомпанией стоимости прошедшей в эфире рекламы . . . . . . . . . . 59
2.3.26. Интернет-магазин . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
2.3.27. Ювелирная мастерская . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
2.3.28. Парикмахерская . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
2.3.29. Химчистка . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
2.3.30. Сдача в аренду торговых площадей . . . . . . . . . . . . . . . . . . . . . . . . . 64
II. Модуль 1 65
3. Реляционная алгебра 66
3.1. Отсутствующие данные . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
3.2. Пустые значения . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
3.3. Неопределенные значения . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
3.3.1. Интерпретации . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
3.3.2. Правила вычисления выражений . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
3.3.3. Следствия . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
3.3.4. Проверка условий . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
3.4. Реляционные объекты данных . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
3.4.1. Формальные определения . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
3.4.2. Домены и атрибуты . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
3.4.3. Схема отношения . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
3.4.4. Именованное значение атрибута . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
3.4.5. Кортеж . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
3.4.6. Отношение . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
3.4.7. Схема базы данных . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
3.4.8. База данных . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
3.5. Операции реляционной алгебры . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
3.5.1. Унарные операции . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
3.5.2. Бинарные операции . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86
3.5.3. Варианты операции соединения . . . . . . . . . . . . . . . . . . . . . . . . . . . 91
3.5.4. Производные операции . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92
3.6. Пример построения выражения реляционной алгебры . . . . . . . . . . . . . . . . . . . 96
3.7. Понятие базовых и виртуальных отношений . . . . . . . . . . . . . . . . . . . . . . . . 98
3.8. Понятие полноты реляционной алгебры . . . . . . . . . . . . . . . . . . . . . . . . . . . 99
3.9. Формирование запросов на языке SQL . . . . . . . . . . . . . . . . . . . . . . . . . . . 100
3.9.1. Реализация операций реляционной алгебры . . . . . . . . . . . . . . . . . . . . 101
3.9.2. Пример использования подзапросов . . . . . . . . . . . . . . . . . . . . . . . . . 109
3.9.3. Группирующие запросы . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110
3.9.4. Упорядочение результатов . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113
3.10. Вопросы для самоконтроля . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114
III. Модуль 2 120

4. Базовые и виртуальные отношения 121
4.1. Типы данных . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121
4.1.1. Базовые типы данных . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121
4.1.2. Типы данных, определяемые пользователем . . . . . . . . . . . . . . . . . . . . 127
4.2. Первичные и кандидатные ключи . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128
4.3. Индексы . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130
4.4. Создание базовых отношений . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132
4.5. Модификация базовых отношений . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137
4.5.1. Вставка строк . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137
4.5.2. Обновление строк . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138
4.5.3. Удаление строк . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139
4.6. Целостность . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140
4.6.1. Декларативная поддержка . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140
4.6.2. Пример декларативной поддержки целостности . . . . . . . . . . . . . . . . . . 144
4.6.3. Транзакции и блокировки . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147
4.6.4. Триггеры . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 150
4.7. Виртуальные отношения . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153
IV. Модуль 3 160

5. Нормальные формы 161
5.1. Функциональные зависимости (ФЗ) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161
5.1.1. Правила вывода Армстронга . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 164
5.1.2. Производные правила вывода . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 166
5.1.3. Независимость правил Армстронга . . . . . . . . . . . . . . . . . . . . . . . . . 167
5.1.4. Полнота системы правил Армстронга . . . . . . . . . . . . . . . . . . . . . . . . 169
5.2. Нормальные формы . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171
5.2.1. Первая нормальная форма (1NF) . . . . . . . . . . . . . . . . . . . . . . . . . . 172
5.2.2. Вторая нормальная форма (2NF) . . . . . . . . . . . . . . . . . . . . . . . . . . . 176
5.2.3. Третья нормальная форма (3NF) . . . . . . . . . . . . . . . . . . . . . . . . . . . 179
5.2.4. Нормальная форма Бойса-Кодда (Boyce, Codd; NFBC)) . . . . . . . . . . . . . . 181
5.2.5. Пример построения нормализованных схем отношений . . . . . . . . . . . . . . 185
V. Модуль 4 190
6. Проектирование схем баз данных 191
6.1. Уровни логической модели . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 193
6.2. Миграция ключей и виды связей . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 195
6.3. Классификация кластеров . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 202
6.4. Иерархическая рекурсия . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 203
6.4.1. Абстрактная схема . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 203
6.4.2. Обобщения . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 206
6.4.3. Пример реализации иерархической рекурсии . . . . . . . . . . . . . . . . . . . . 207
6.5. Сетевая рекурсия . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 210
6.5.2. Сетевая реализация иерархической рекурсии . . . . . . . . . . . . . . . . . . . . 213
6.5.3. Обобщения . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 214
6.5.4. Пример реализации сетевой рекурсии . . . . . . . . . . . . . . . . . . . . . . . . 216
6.6. Ассоциация . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 219
6.6.1. Детализация связей многие-ко-многим . . . . . . . . . . . . . . . . . . . . . . . 220
6.6.2. Обобщения . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 222
6.6.3. Пример реализации ассоциации . . . . . . . . . . . . . . . . . . . . . . . . . . . 224
6.7. Обобщение . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 228
6.7.2. Пример реализации обобщения . . . . . . . . . . . . . . . . . . . . . . . . . . . 229
6.8. Композиция . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 233
6.8.2. Пример реализации композиции . . . . . . . . . . . . . . . . . . . . . . . . . . . 239
6.9. Агрегация . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 242
6.9.2. Пример реализации агрегации . . . . . . . . . . . . . . . . . . . . . . . . . . . . 245
6.10. Унификация атрибутов . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 248
VI. Дополнительные главы 261

7. Технологии баз данных 262
7.1. Информационные системы . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 262
7.1.1. Жизненный цикл ИС . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 263
7.1.2. СУБД и БД . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 268
7.1.3. Жизненный цикл БД и средства автоматизированного проектирования . . . . 269
7.2. Модели данных . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272
7.2.1. Иерархическая модель данных . . . . . . . . . . . . . . . . . . . . . . . . . . . . 273
7.2.2. Сетевая модель данных . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 275
7.2.3. Реляционная модель данных . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 277
7.2.4. Постреляционная модель данных . . . . . . . . . . . . . . . . . . . . . . . . . . 279
7.2.5. Объектно-ориентированные модели данных . . . . . . . . . . . . . . . . . . . . 279
7.2.6. XML как модель данных . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 281
7.2.7. Многомерная модель данных (OLAP) . . . . . . . . . . . . . . . . . . . . . . . . 282
7.3. Основные функции СУБД . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 286
7.3.1. Управление данными во внешней памяти . . . . . . . . . . . . . . . . . . . . . . 287
7.3.2. Управление буферами оперативной памяти . . . . . . . . . . . . . . . . . . . . . 287
7.3.3. Управление транзакциями . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 288
7.3.4. Журнализация и восстановление БД после сбоев . . . . . . . . . . . . . . . . . 288
7.3.5. Поддержка языков баз данных . . . . . . . . . . . . . . . . . . . . . . . . . . . . 291
7.4. Типовая организация СУБД . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 292
7.5. Модели взаимодействия с БД . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 294
7.5.1. Модель с централизованной архитектурой . . . . . . . . . . . . . . . . . . . . . 294
7.5.2. Модель с автономными персональными компьютерами . . . . . . . . . . . . . . 295
7.5.3. Архитектура «файл-сервер» . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 296
7.5.4. Архитектура «клиент-сервер» . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 296
7.5.5. Архитектура «клиент-сервер» трехзвенная . . . . . . . . . . . . . . . . . . . . . 298
7.5.6. Распределенные базы данных . . . . . . . . . . . . . . . . . . . . . . . . . . . . 299
7.5.7. Технология тиражирования данных . . . . . . . . . . . . . . . . . . . . . . . . . 300
7.6. Фрактальные методы сжатия BLOB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 301
7.6.1. Понятие «фрактал» . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 302
7.6.2. Геометрические фракталы . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 303
7.6.3. Алгебраические фракталы . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 305
7.6.4. Стохастические фракталы . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 308
7.6.5. Системы итерируемых функций . . . . . . . . . . . . . . . . . . . . . . . . . . . 308
Литература 314
Список иллюстраций 316
Список таблиц 320
Предметный указатель 321

Часть I.
Установочный модуль
1. Введение
Традиционная тема курса – модели данных – рассматривается с той или иной степенью детализации
в широком диапазоне: модели иерархическая, сетевая, реляционная, постреляционная, объектно-
ориентированая, XML, OLAP.
При рассмотрении основных функций СУБД выделяются функции управления данными во внеш-
ней памяти и буферами оперативной памяти, функция управления транзакциями, функции журна-
лизации и восстановления БД после сбоев, поддержки языков баз данных.
При анализе моделей взаимодействия пользователей с базами данных проводится их сравни-
тельный анализ в исторической цепочке: модели с централизованной архитектурой и автономными
персональными компьютерами, архитектуры «файл-сервер», «клиент-сервер» и ее более развитый
трехзвенный вариант, технологии распределенных баз данных и тиражирования данных.
Далее рассматриваются теоретические вопросы обоснования теории реляционных БД и техноло-
гические вопросы разработки РБД.
Вводится реляционная алгебра. Анализируется проблема неопределенных значений и ее влияние
на методы обработки данных. Формализуется понятие базы данных на наиболее абстрактном уровне.
Вводятся реляционные операции и их варианты, анализируется независимость операций. На алгеб-
раическом уровне водятся понятия базовых и виртуальных отношений. Описывается реализация
операций реляционной алгебры на языке баз данных SQL. Демонстрируется техника использования
SQL-подзапросов.
Рассматривается внутреннее устройство базовых и виртуальных отношений. Определяются базо-
вые типы данных и типы данных, определяемые пользователем. Описывается техника индексирова-
ния. Описываются SQL-конструкции для создания и модификации отношений.
Анализируются декларативные и процедурные методы поддержания целостности БД с использо-
вание механизма транзакций и триггеров.
Излагается теория нормализации (до NFBC включительно). Вводится понятие функциональных
зависимостей, и обосновываются правила вывода Армстронга. Определяются и анализируются 1NF,
2NF, 3NF, NFBC.
Описывается методология проектирования схем баз данных в стиле UML. Вводятся понятия диа-
грамм, связей и их элементов. Методология проектирования демонстрируется на таких кластерах,
как иерархическая и сетевая рекурсии, ассоциация, обобщение, композиция, агрегация. Рассматри-
вается назначение унификации атрибутов.
В заключительной обсуждаются фрактальные методы сжатия BLOB – крупных двоичных объек-
тов, что актуально для мультимедийных БД.
О контрольных работах (лабораторном практикуме). К пособию прилагается задания на выполне-
ние лабораторных работ с примерами ее выполнения.
Цель работы – приобретение практических навыков анализа и моделирования предметной об-
ласти; ознакомление с работой специализированных CASE-средств; изучение подхода к обработке
данных на основе применения языка SQL; при наличии возможностей – ознакомление с архитекту-
рой «клиент-сервер».
Лабораторный практикум предполагает последовательное выполнение студентами 3-х циклов ла-
бораторных работ, моделирующих определенную предметную область, предложенную каждому сту-
денту в рамках конкретного задания.
К разделам пособия прилагаются вопросы для самоконтроля, тестовые задания (где целесообраз-
но) и списки рекомендуемой литературы.
К пособию в целом прилагаются методические указания, тестовые задания и списки рекомендуе-
мой литературы.
Содержание пособия соответствует требованиям ГОС ВПО и, как можно ожидать, пособие не
потеряет актуальности и при переходе на новую систему образования.
Пособие может быть рекомендовано студентам специальности прикладная информатика всех форм
обучения и преподавателям.
2. Практическое задание
Каждая лабораторная работа начинается с объяснения преподавателем задания на конкретном при-
мере. Пример сохраняется неизменным на протяжении всего периода изучении дисциплины. После
объяснения преподавателем задания студенты выполняют свой вариант самостоятельно.
По каждому циклу лабораторных работ должен быть подготовлен отчет.
В первом цикле лабораторных работ студенты приобретают навыки анализа и моделирования
предметной области, а также знакомятся с работой в СУБД.
Построенная реляционная модель реализуется средствами СУБД. Вводятся тестовые данные.
Во втором цикле лабораторных работ изучаются запросы языка SQL и строится простой интер-
фейс пользователя. Студенты самостоятельно формируют различные SQL–запросы, получая навыки
решения конкретных практических задач.
В третьем цикле лабораторных работ студенты самостоятельно расширяют предметную область
(или пользуются предложенным им вариантом расширения) и проектируют схему базы данных для
расширенной предметной области. В рамках новой модели производится модифицирование написан-
ных ранее запросов к базе данных и написание новых. При проведении работ используются CASE-
средства. По окончании производится анализ скрипта для генерирования структуры базы данных,
а также изучение принципов создания хранимых процедур и триггеров, созданных преподавателем
или сгенерированных автоматически с помощью CASE-средства.
2.1. Формулировка задания
Задание на выполнение контрольной работы в минимальной формулировке заключается в следую-
щем.
1) Для варианта контрольной работы, согласованного с преподавателем, требуется по описанию

предметной области спроектировать схему базы данных и разработать офисное приложение
для ее ведения с достаточно простым интерфейсом.
2) Повторить цикл работ с учетом развития постановки задачи. А именно, спроектировать новую
схему базы данных и разработать офисное приложение для ее ведения. В офисном приложе-
нии желательно воспользоваться возможностями используемой СУБД для построения более
дружественного интерфейса.
3) Подготовить отчет в печатной или электронной форме (по согласованию с преподавателем).

Включить в отчет формулировку варианта контрольной работы.
Ниже дается пример выполнения задания с использованием СУБД MS Access (для 1-го цикла ра-
бот; для 2-го –аналогично). Подробное описание способов установки настроек приводится в примере
в учебных целях для первоначального ознакомления с техникой работы с СУБД. В отчете следует
привести укрупненную разбивку по шагам и описание разработок на этих шагах.
Контрольная работа может быть выполнена с использованием любой СУБД. Единственное огра-
ничение – это использование лицензионных программных продуктов.
2.2. Пример выполнения задания
2.2.1. Описание предметной области
Имеются постоянно действующие курсы переподготовки специалистов. Каждый специалист может
многократно (периодически) являться слушателем курсов (курсы отражают последние достижения
в рассматриваемой области и периодически обновляются). Под слушателем понимается специалист,
заявленный на периодическое слушание курсов и однозначно характеризуемый номером удостовере-
ния (УдостНомер).
Разработать приложение для ведения базы.
2.2.2. Шаг 0
Создать новую базу данных dbВедомость.
2.2.3. Шаг 1
Создать (в режиме конструктора) простые (то есть без подстановок) таблицы.
tblСлушатели (keyСлушатель, Фамилия, Имя, Отчество, УдостНомер)
• keyСлушатель: ключевое поле, счетчик;
• Фамилия, Имя, Отчество:
– свойство Обязательное поле – «Да»,

– свойство Пустые строки – «Нет»;
• УдостНомер:
– свойство Значение по умолчанию – отсутствует,

– свойство Условие на значение – «УдостНомер>0»,
– свойство Индексированное поле – «Да (Совпадения не допускаются)».
Ясно, что поле УдостНомер здесь является альтернативным ключевым полем. Причины введения
суррогатного ключа keyСлушатель обусловлены естественным нежеланием использовать семанти-
чески интерпретированные поля в качестве первичных ключей.
Ввести в таблицу (не по алфавиту) несколько записей для тестирования. Задать для таблицы
следующий порядок сортировки: Фамилия, Имя, Отчество, УдостНомер.
Проконтролировать правильность установленного порядка сортировки можно, открыв в режиме
конструктора с помощью контекстного меню окно Свойства таблицы.
tblПредметы (keyПредмет, Наименование).
• keyПредмет: ключевое поле, счетчик;
• Наименование:

– свойство Пустые строки – «Нет».
Наименование, вообще говоря, следовало бы объявить индексированным полем (совпадения не до-

пускаются). Однако ошибки ввода (связанные с дублированием наименований предметов) в данном
случае маловероятны, и в целях экономии ресурсов индексирование поля можно не проводить.
сортировку по полю Наименование. Проконтролировать правильность установленного порядка сор-
тировки можно, открыв в режиме конструктора с помощью контекстного меню окно Свойства таб-
лицы.
tblПреподаватели (keyПреподаватель, Фамилия, Имя, Отчество).
• keyПреподаватель: ключевое поле, счетчик;
• Ф, И, О:

– свойство Пустые строки – «Нет».
Проблема однофамильцев может быть решена путем искусственного добавления некоторой иден-
тифицирующей информации к фамилии (например, «Иванов, ст.», «Иванов, мл.» и т.п.).
следующий порядок сортировки: Фамилия, Имя, Отчество.
tblОценки (Оценка, Наименование).
• Оценка: ключевое поле.
Поскольку для отдельных предметов экзамен может быть не предусмотрен (и требуется лишь
прослушивание курса), в данной таблице следует ввести псевдооценку 0 с пустым наименованием.
Таблицу tblОценки сформировать полностью (рис. 2.1).
Рис. 2.1.: Таблица tblОценки
2.2.4. Шаг 2
Создать (в режиме конструктора) вспомогательные запросы для использования как списков подста-
новки в сложных таблицах.
subСлушатели (keyСлушатель, ФИО_УдостНомер) – сортировка по алфавиту. Здесь ФИО_УдостН
– единое поле в формате «Фамилия И.О. (УдостНомер)». Поле ФИО_УдостНомер определяется в
построителе в виде следующего выражения:
ФИО_УдостНомер: tblСлушатели!Фамилия+’ ’+
Left(tblСлушатели!Имя;1)+’.’+
Left(tblСлушатели!Отчество;1)+’.(’+
LTrim(Str(tblСлушатели!УдостНомер))+’)’
subПредметы (keyПредмет, Наименование) – сортировка по алфавиту;
subПреподаватели (keyПреподаватель, ФИО) – сортировка по алфавиту. Здесь ФИО – еди-
ное поле в формате «Фамилия И.О.». Поле ФИО определяется в построителе в виде следующего
выражения:
ФИО: tblПреподаватели!Фамилия+’ ’+
Left(tblПреподаватели!Имя;1)+’.’+
Left(tblПреподаватели!Отчество;1)+’.’
Это выражение удобно построить из выражения для поля subСлушателиФИО_УдостНомер, ско-

пированного через буфер обмена.
2.2.5. Шаг 3
Создать (в режиме конструктора) сложную (то есть с подстановками) таблицу tblВедомость со
следующими полями:
• keyВедомостиЗапись: ключевое поле, счетчик;
• keyСлушатель:
– с подстановкой subСлушатели,
– свойство Обязательное поле – «Да»;
• keyПредмет:
– с подстановкой subПредметы,
• Оценка:
– с подстановкой tblОценки;
• keyПреподаватель:
– с подстановкой subПреподаватели,
• Дата:

– в маске ввода задать краткий формат даты.
Ввести в таблицу (не по алфавиту) данные для тестирования. Задать для таблицы следующий
порядок сортировки: keyСлушатель, Дата (фактически сортировка будет проводиться по полям
ФИО_УдостНомер, Дата).
2.2.6. Шаг 4
Создать схему данных (установить межтабличные связи и обеспечить целостность данных; для связи
с таблицей tblСлушатели установить флажок каскадного удаления связанных полей; рис. 2.2).
Рис. 2.2.: Схема данных
Протестировать связи:
1) убедиться, что при удалении записи из таблицы tblСлушатели автоматически удаляются
соответствующие записи из таблицы tblВедомость;
2) убедиться, что удаление записей из таблиц tblПредметы и tblПреподаватели невозможно,

если в таблице tblВедомость есть ссылки на эти записи.
2.2.7. Шаг 5
Создать (с помощью мастера) на основе таблицы tblСлушатели форму frmСлушатели (в лен-
точном виде, без показа ключевого поля). Для полей ввода из области данных установить свойство
Оформление как «обычное». В свойствах формы запретить разделительные линии и задать подпись
«Список слушателей». Протестировать ввод данных в форму.
2.2.8. Шаг 6
Создать (с помощью мастера) на основе таблицы tblПредметы форму frmПредметы (в ленточном
виде, без показа ключевого поля). Для поля ввода из области данных установить свойство Оформле-
ние как «обычное». В свойствах формы запретить разделительные линии и задать подпись «Список
предметов». Протестировать ввод данных в форму.
2.2.9. Шаг 7
Создать (с помощью мастера) на основе таблицы tblПреподаватели форму frmПреподаватели
(в ленточном виде, без показа ключевого поля). Для полей ввода из области данных установить
свойство Оформление как «обычное». В свойствах формы запретить разделительные линии и задать
подпись «Список преподавателей». Протестировать ввод данных в форму.
2.2.10. Шаг 8
Создать форму frmВедомость (по предметам). Для этого:
1) создать (с помощью мастера) на основе таблицы tblПредметы форму frmВедомость (в один
столбец, без показа ключевого поля);
2) в режиме конструктора в область данных формы вставить с панели элементов подчиненную
форму на основе таблицы tblВедомость (без показа ключевого поля);
3) отредактировать главную форму:
• задать подпись «Ведомость успеваемости по предметам»;
• запретить удаление и добавление записей;
• сделать поле наименования предмета доступным только для чтения, для чего задать для
его свойства Блокировка значение «Да»;
• изменить подпись для надписи «Наименование» на «Предмет»;
• удалить с формы надпись «подчиненная форма . . . »;
• скрыть столбец keyПредмет в подчиненной форме;
4) отредактировать подчиненную форму:
• задать режим по умолчанию «Режим таблицы»;
• отменить показ кнопок перехода;
• изменить наименования столбцов «keyСлушатель» и «keyПреподаватель» на «Слушатель»
и «Преподаватель»;
• установить тот же порядок сортировки, что и в таблице tblВедомость (можно скопиро-
вать свойство Порядок сортировки через буфер обмена).
Протестировать ввод данных в форму.
2.2.11. Шаг 9
Создать форму frmДиаграмма с диаграммой «Число оценок - Оценка» (по предметам). Предва-
рительно создать (в режиме конструктора) запрос qryДиаграмма (ПредметаНаименование,
ОценкиНаименование, Оценка) (рис. 2.3).
Поле ОценкиНаименование определить в построителе в виде следующего выражения:
ОценкиНаименование: LTrim(Str(tblОценки!Оценка))+
’-’+tblОценки!Наименование
Затем создать с помощью мастера диаграмм на основе запроса qryДиаграмма форму frmДиаграмма
(тип диаграммы – гистограмма, название диаграммы – «Распределение числа оценок по предметам»;
рис. 2.4).
Оптимизировать размеры диаграммы и в свойствах формы задать подпись «Диаграмма», запре-
тить разделительные линии, отменить показ кнопок перехода. Отредактировать диаграмму (переход
в режим редактирования – двойным щелчком; доступ к параметрам форматирования элементов
диаграммы – с помощью контекстного меню):
1) для шкалы вертикальной оси (значений) снять автоматическую установку цены основных де-
лений и установить ее в 1;
2) в параметрах диаграммы на вкладке Линии сетки задать режим вывода основных линий и для
оси категорий.
Рис. 2.3.: Запрос qryДиаграмма
Рис. 2.4.: Мастер диаграмм
Рис. 2.5.: Запрос qryОтчет
2.2.12. Шаг 10
Создать отчет rptОтчет (по предметам). Предварительно создать (в режиме конструктора) запрос
qryОтчет (рис. 2.5).
Поля определить следующим образом:
• Слушатель – subСлушатели!ФИО_УдостНомер;
• Предмет – subПредметы!Наименование;
• Оценка – tblОценки!Оценка;
• Преподаватель –subПреподаватели!ФИО;
• Дата – tblВедомость! Дата.
Затем создать (с помощью мастера) на основе запроса qryОтчет отчет rptОтчет (с группиров-
кой по предметам, с сортировкой по слушателям и дате, в макете «блок», в стиле «Обычный»).
Отредактировать отчет (в режиме конструктора):
• в окне Сортировка и группировка (вызывается через аналогичный пункт контекстного меню)
задать для свойства Примечание группы значение «Да»;
• вставить с панели элементов элемент Поле в область примечания группы (под полем Оценка),
настроить размеры поля и области группы;
• задать для надписи подпись «В среднем:»;
• определить для поля свойство Данные как «=Avg(Оценка)».
Отредактировать разделительные линии, установив для них свойство Тип границы в состояние
«Сплошная».
Установить для заголовка отчета подпись «Ведомость успеваемости по предметам» и выравнивание
по центру.
Отредактировать в области данных поле Слушатель, установив свойство Не выводить повторы в
состояние «Да».
Отредактировать в области данных поле Оценка:
• установить свойство Выравнивание текста в состояние «По центру»;
• установить для свойства Формат поля значение «#» (для подавления нулевых значений);
• задать условное форматирование таким образом, чтобы при неудовлетворительных оценках

поле оценки имело затемненный фон.
2.2.13. Шаг 11
Создать форму frmВедомостьСводная со сводной ведомостью. Предварительно создать (в режиме
конструктора) запрос qryВедомостьСводная (рис. 2.6) с полями
• Слушатель – subСлушатели!ФИО_УдостНомер;
• Предмет – subПредметы!Наименование;
• Оценка – tblВедомость!Оценка, Условие отбора – «< > 0».
Затем создать с помощью мастера перекрестных запросов на основе созданного запроса qryВедомостьС
перекрестный запрос crsВедомостьСводная (заголовки строк – по полю Слушатель, заголовки
столбцов – по полю Предмет, вычисление оценки – по максимуму поля Оценка). На основе запроса
crsВедомостьСводная создать (с помощью мастера) форму frmВедомостьСводная (в ленточ-
ном виде). Отредактировать форму. В частности, задать подпись «Сводная ведомость успеваемости».
2.2.14. Шаг 12
Создать меню для управления формами и отчетами приложения. Установить необходимые параметры
запуска.
Рис. 2.6.: Запрос qryВедомостьСводная
• Создать пустую панель управления Настраиваемая Главная типа «Панель инструментов». Для
этого вызвать окно Настройка (меню Вид Панели инструментов Настройка); на вкладке
Панели инструментов нажать кнопку Создать и задать имя Настраиваемая Главная.
Примечание. Тренинг: варианты закрепления панели (перетаскиванием, двойным щелчком);
закрытие и открытие панели (флажок панели инструментов Настраиваемая Главная окна На-
стройка).
• Изменить тип панели управления Настраиваемая Главная на тип «Строка меню» (окно На-
стройка, Свойства).
• Создать подменю Формы и Отчеты. Для этого в окне Настройка во вкладке Команды выбрать
категорию Новое меню и (дважды) перетащить команду Новое меню на панель. переименовать
подменю (в контекстном меню соответствующего подменю - непосредственно или в свойствах).
• Добавить команды в подменю Формы и Отчеты. Для этого в окне Настройка во вкладке
Команды выбрать категорию Все формы или Все отчеты и перетащить команды в подменю.
Примечание. Тренинг: создание команд меню перетаскиванием объектов непосредственно из
окна базы данных (окно Настройка должно быть закрыто); перестановка команд (перетас-
киванием при открытом окне Настройка); группирование команд, т.е. создание разделителей
между группами (откройте контекстное меню первой команды группы); выбор значков для
команд (откройте контекстное меню команды).
• Установить необходимые параметры запуска (меню Сервис Параметры запуска).
Для отключения параметров запуска при открытии базы данных удерживайте в нажатом положе-
нии клавишу SHIFT.
2.3. Варианты контрольных работ
2.3.1. Страховая компания
Описание предметной области
Вы работаете в страховой компании. Вашей задачей является отслеживание финансовой деятель-
ности компании. Компания имеет различные филиалы по всей стране. Каждый филиал характери-
зуется названием, адресом и телефоном. Деятельность компании организована следующим образом:
к Вам обращаются различные лица с целью заключения договора о страховании. В зависимости
от принимаемых на страхование объектов и страхуемых рисков, договор заключается по определен-
ному виду страхования (например, страхование автотранспорта от угона, страхование домашнего
имущества, добровольное медицинское страхование). При заключении договора Вы фиксируете дату
заключения, страховую сумму, вид страхования, тарифную ставку и филиал, в котором заключался
договор.
Таблицы
Договоры (Номер договора, Дата заключения, Страховая сумма, Тарифная ставка, Код
Вид страхования (Код вида страхования, Наименование).
Филиал (Код филиала, Наименование филиала, Адрес, Телефон).
Развитие постановки задачи

Нужно учесть, что договоры заключают страховые агенты. Помимо информации об агентах (фа-
милия, имя, отчество, адрес, телефон), нужно еще хранить филиал, в котором работают агенты.
Кроме того, исходя из базы данных, нужно иметь возможность рассчитывать заработную плату
агентам. Заработная плата составляет некоторый процент от страхового платежа (страховой платеж
это страховая сумма, умноженная на тарифную ставку). Процент зависит от вида страхования, по
которому заключен договор.
Внести в структуру таблиц изменения, учитывающие эти факты, и изменить существующие за-
просы. Добавить новые запросы.
2.3.2. Гостиница
Вы работаете в гостинице. Вашей задачей является отслеживание финансовой стороны работы
гостиницы.
Ваша деятельность организована следующим образом: гостиница предоставляет номера клиен-
там на определенный срок. Каждый номер характеризуется вместимостью, комфортностью (люкс,
полулюкс, обычный) и ценой. Вашими клиентами являются различные лица, о которых Вы собира-
ете определенную информацию (фамилия, имя, отчество и некоторый комментарий). Сдача номера
клиенту производится при наличии свободных мест в номерах, подходящих клиенту по указан-
ным выше параметрам. При поселении фиксируется дата поселения. При выезде из гостиницы для
каждого места запоминается дата освобождения.
Таблицы
Клиенты (Код клиента, Фамилия, Имя, Отчество, Паспортные данные, Комментарий).

Номера (Код номера, Номер, Количество человек, Комфортность, Цена).
Поселение (Код поселения, Код клиента, Код номера, Дата поселения, Дата освобожд

Необходимо хранить информацию не только по факту сдачи номера клиенту, но и осуществлять
бронирование номеров. Кроме того, для постоянных клиентов, а также для определенных категорий
клиентов, предусмотрена система скидок. Скидки могут суммироваться.
Внести в структуру таблиц изменения, учитывающие этот факт, и изменить существующие за-
2.3.3. Ломбард
Вы работаете в ломбарде. Вашей задачей является отслеживание финансовой стороны работы
ломбарда.
Деятельность Вашей компании организована следующим образом: к Вам обращаются различные
лица с целью получения денежных средств под залог определенных товаров. У каждого из при-
ходящих к Вам клиентов Вы запрашиваете фамилию, имя, отчество и другие паспортные данные.
После оценивания стоимости принесенного в качестве залога товара Вы определяете сумму, которую
готовы выдать на руки клиенту, а также свои комиссионные. Кроме того, определяете срок возврата
денег. Если клиент согласен, то Ваши договоренности фиксируются в виде документа, деньги вы-
даются клиенту, а товар остается у Вас. В случае если в указанный срок не происходит возврата
денег, товар переходит в Вашу собственность.
Таблицы
Клиенты (Код клиента, Фамилия, Имя, Отчество, Номер паспорта, Серия паспорта, Да
Категории товаров (Код категории товаров, Название, Примечание).
Сдача в ломбард (Код, Код категории товаров, Код клиента, Описание товара, Дата
После перехода прав собственности на товар, ломбард может продавать товары по цене, меньшей
или большей, чем была заявлена при сдаче. Цена может меняться несколько раз, в зависимости
от ситуации на рынке. (Например, владелец ломбарда может устроить распродажу зимних вещей
в конце зимы). Помимо текущей цены, нужно хранить все возможные значения цены для данного
товара.
2.3.4. Реализация готовой продукции
Вы работаете в компании, занимающейся оптово-розничной продажей различных товаров. Вашей
задачей является отслеживание финансовой стороны работы компании.
Деятельность Вашей компании организована следующим образом: Ваша компания торгует това-
рами из определенного спектра. Каждый из этих товаров характеризуется наименованием, оптовой
ценой, розничной ценой и справочной информацией. В Вашу компанию обращаются покупатели.
Для каждого из них Вы запоминаете в базе данных стандартные данные (наименование, адрес, те-
лефон, контактное лицо) и составляете по каждой сделке документ, запоминая наряду с покупателем
количество купленного им товара и дату покупки.
Таблицы
Товары (Код товара, Наименование, Оптовая цена, Розничная цена, Описание).

Покупатели (Код покупателя, Телефон, Контактное лицо, Адрес).
Сделки (Код сделки, Дата сделки, Код товара, Количество, Код покупателя, Признак

Теперь ситуация изменилась. Выяснилось, что обычно покупатели в рамках одной сделки покупа-
ют не один товар, а сразу несколько. Также компания решила предоставлять скидки в зависимости
от количества закупленных товаров и их общей стоимости.
2.3.5. Ведение заказов
Вы работаете в компании, занимающейся оптовой продажей различных товаров. Вашей задачей
является отслеживание финансовой стороны работы компании.
Деятельность Вашей компании организована следующим образом: Ваша компания торгует това-
рами из определенного спектра. Каждый из этих товаров характеризуется ценой, справочной инфор-
мацией и признаком наличия или отсутствия доставки. В Вашу компанию обращаются заказчики.
Для каждого из них Вы запоминаете в базе данных стандартные данные (наименование, адрес, те-
лефон, контактное лицо) и составляете по каждой сделке документ, запоминая наряду с заказчиком
количество купленного им товара и дату покупки.
Таблицы
Заказчики (Код заказчика, Наименование, Адрес, Телефон, Контактное лицо).

Товары (Код товара, Цена, Доставка, Описание).
Заказы (Код заказа, Код заказчика, Код товара, Количество, Дата).

Теперь ситуация изменилась. Выяснилось, что доставка разных товаров может производиться
разными способами, различными по цене и скорости. Нужно хранить информацию по тому, какими
способами может осуществляться доставка каждого товара и информацию о том, какой вид доставки
(а, соответственно, и какую стоимость доставки) выбрал клиент при заключении сделки.
2.3.6. Бюро по трудоустройству
Вы работаете в бюро по трудоустройству. Вашей задачей является отслеживание финансовой
стороны работы компании.
Деятельность Вашего бюро организована следующим образом: Ваше бюро готово искать работни-
ков для различных работодателей и вакансии для ищущих работу специалистов различного профи-
ля. При обращении к Вам клиента-работодателя, его стандартные данные (название, вид деятель-
ности, адрес, телефон) фиксируются в базе данных. При обращении к Вам клиента-соискателя, его
стандартные данные (фамилия, имя, отчество, квалификация, профессия, иные данные) также фик-
сируются в базе данных. По каждому факту удовлетворения интересов обеих сторон составляется
документ. В документе указываются соискатель, работодатель, должность и комиссионные (доход
бюро).
Таблицы
Работодатели (Код работодателя, Название, Вид деятельности, Адрес, Телефон).

Сделки (Код соискателя, Код работодателя, Должность, Комиссионные).
Соискатели (Код соискателя, Фамилия, Имя, Отчество, Квалификация, Вид деятельнос

Оказалось, что база данных не совсем точно описывает работу бюро. В базе фиксируется толь-
ко сделка, а информация по открытым вакансиям не храниться. Кроме того, для автоматического
поиска вариантов, необходимо вести справочник «виды деятельности».
2.3.7. Нотариальная контора
Вы работаете в нотариальной конторе. Вашей задачей является отслеживание финансовой стороны
работы компании.
Деятельность Вашей нотариальной конторы организована следующим образом: Ваша фирма готова
предоставить клиенту определенный комплекс услуг. Для наведения порядка Вы формализовали
эти услуги, составив их список с описанием каждой услуги. При обращении к Вам клиента, его
стандартные данные (название, вид деятельности, адрес, телефон) фиксируются в базе данных. По
каждому факту оказания услуги клиенту составляется документ. В документе указываются услуга,
сумма сделки, комиссионные (доход конторы), описание сделки.
Таблицы
Клиенты (Код клиента, Название, Вид деятельности, Адрес, Телефон).

Сделки (Код сделки, Код клиента, Код услуги, Сумма, Комиссионные, Описание).
Услуги (Код услуги, Название, Описание).

Теперь ситуация изменилась. В рамках одной сделки клиенту может быть оказано несколько
услуг. Стоимость каждой услуги фиксирована. Кроме того, компания предоставляет в рамках одной
сделки различные виды скидок. Скидки могут суммироваться.
2.3.8. Фирма по продаже запчастей
Вы работаете в фирме, занимающейся продажей запасных частей для автомобилей. Вашей задачей
является отслеживание финансовой стороны работы компании.
Основная часть деятельности, находящейся в Вашем ведении, связана с работой с поставщика-
ми. Фирма имеет определенный набор поставщиков, по каждому из которых известны название,
адрес и телефон. У этих поставщиков Вы приобретаете детали. Каждая деталь наряду с названием
характеризуется артикулом и ценой (считаем цену постоянной). Некоторые из поставщиков могут
поставлять одинаковые детали (один и тот же артикул). Каждый факт покупки запчастей у постав-
щика фиксируется в базе данных, причем обязательными для запоминания являются дата покупки
и количество приобретенных деталей.
Таблицы
Поставщики (Код поставщика, Название, Адрес, Телефон).

Детали (Код детали, Название, Артикул, Цена, Примечание).
Поставки (Код поставщика, Код детали, Количество, Дата).

Теперь ситуация изменилась. Выяснилось, что цена детали может меняться от поставки к постав-
ке. Поставщики заранее ставят Вас в известность о дате изменения цены и о его новом значении.
Нужно хранить не только текущее значение цены, но и всю историю изменения цен.
2.3.9. Курсы по повышению квалификации
Вы работаете в учебном заведении и занимаетесь организацией курсов повышения квалификации.
В Вашем распоряжении имеются сведения о сформированных группах студентов. Группы фор-
мируются в зависимости от специальности и отделения. В каждой из них включено определенное
количество студентов. Проведение занятий обеспечивает штат преподавателей. Для каждого из них
у Вас в базе данных зарегистрированы стандартные анкетные данные (фамилия, имя, отчество,
телефон) и стаж работы. В результате распределения нагрузки Вы получаете информацию о том,
сколько часов занятий проводит каждый преподаватель с соответствующими группами. Кроме того,
хранятся также сведения о виде проводимых занятий (лекции, практика), предмете и оплате за 1
час.
Таблицы
Группы (Номер группы, Специальность, Отделение, Количество студентов).

Преподаватели (Код преподавателя, Фамилия, Имя, Отчество, Телефон, Стаж).
Нагрузка (Код преподавателя, Номер группы, Количество часов, Предмет, Тип заняти

В результате работы с базой данных выяснилось, что размер почасовой оплаты зависит от пред-
мета и типа занятия. Кроме того, каждый преподаватель может вести не все предметы, а только
некоторые.
2.3.10. Определение факультативов для студентов
Вы работаете в высшем учебном заведении и занимаетесь организацией факультативов.
В Вашем распоряжении имеются сведения о студентах, включающие стандартные анкетные дан-
ные (фамилия, имя, отчество, адрес, телефон). Преподаватели Вашей кафедры должны обеспечить
проведение факультативных занятий по некоторым предметам. По каждому факультативу существу-
ет определенное количество часов и вид проводимых занятий (лекции, практика, лабораторные ра-
боты). В результате работы со студентами у Вас появляется информация о том, кто из них записался
на какие факультативы. Существует некоторый минимальный объем факультативных предметов, ко-
торые должен прослушать каждый студент. По окончанию семестра Вы заносите информацию об
оценках, полученных студентами на экзаменах.
Таблицы
Студенты (Код студента, Фамилия, Имя, Отчество, Адрес, Телефон).

Предметы (Код предмета, Название, Объем лекций, Объем практик, Объем лабораторны
Учебный план (Код студента, Код предмета, Оценка).

Теперь ситуация изменилась. Выяснилось, что некоторые из факультативов могут длиться более
одного семестра. В каждом семестре для предмета устанавливается объем лекций, практик и лабора-
торных работ в часах. В качестве итоговой оценки за предмет берется последняя оценка, полученная
студентом.
2.3.11. Распределение учебной нагрузки
Вы работаете в высшем учебном заведении и занимаетесь распределением нагрузки между препо-
давателями кафедры.
В Вашем распоряжении имеются сведения о преподавателях кафедры, включающие наряду с
анкетными данными сведения об их ученой степени, занимаемой административной должности и
стаже работы. Преподаватели Вашей кафедры должны обеспечить проведение занятий по некоторым
предметам. По каждому из них существует определенное количество часов. В результате распре-
деления нагрузки у Вас должна получится информация следующего рода: «Такой-то преподаватель
проводит занятия по такому-то предмету с такой-то группой».
Таблицы
Преподаватели (Код преподавателя, Фамилия, Имя, Отчество, Ученая степень, Должно

Предметы (Код предмета, Название, Количество часов).
Нагрузка (Код преподавателя, Код предмета, Номер группы).

Теперь ситуация изменилась. Выяснилось, что все проводимые занятия делятся на лекционные
и практические. По каждому виду занятий устанавливается свое количество часов. Кроме того,
данные по нагрузке нужно хранить несколько лет.
2.3.12. Распределение дополнительных обязанностей
Вы работаете в коммерческой компании и занимаетесь распределением дополнительных разовых
работ. Вашей задачей является отслеживание хода выполнения дополнительных работ.
Компания имеет определенный штат сотрудников, каждый из которых получает определенный
оклад. Время от времени, возникает потребность в выполнении некоторой дополнительной работы,
не входящей в круг основных должностных обязанностей сотрудников. Для наведения порядка в
этой сфере деятельности Вы проклассифицировали все виды дополнительных работ, определившись
с суммой оплаты по факту их выполнения. При возникновении дополнительной работы определенно-
го вида Вы назначаете ответственного, фиксируя дату начала. По факту окончания Вы фиксируете
дату и выплачиваете дополнительную сумму к зарплате с учетом Вашей классификации.
Таблицы
Сотрудники (Код сотрудника, Фамилия, Имя, Отчество, Оклад).

Виды работ (Код вида, Описание, Оплата за день).
Работы (Код сотрудника, Код вида, Дата начала, Дата окончания).

Теперь ситуация изменилась. Выяснилось, что некоторые из дополнительных работ являются до-
статочно трудоемкими и, в то же время, срочными, что требует привлечения к их выполнению
нескольких сотрудников. Также оказалось, что длительность работ в каждом конкретном случае
составляет разную величину. Соответственно, нужно заранее планировать длительность работы и
количество сотрудников, занятых для выполнения работы.
2.3.13. Техническое обслуживание станков
Ваше предприятие занимается ремонтом станков и другого промышленного оборудования. Вашей
задачей является отслеживание финансовой стороны деятельности предприятия.
Клиентами Вашей компании являются промышленные предприятия, оснащенные различным слож-
ным оборудованием. В случае поломок оборудования они обращаются к Вам.
Ремонтные работы в Вашей компании организованы следующим образом: все станки прокласси-
фицированы по странам-производителям, годам выпуска и маркам. Все виды ремонта отличаются
названием, продолжительностью в днях, стоимостью. Исходя из этих данных, по каждому факту
ремонта Вы фиксируете вид станка и дату начала ремонта.
Таблицы
Виды станков (Код вида станка, Страна, Год выпуска, Марка).

Виды ремонта (Код ремонта, Название, Продолжительность, Стоимость, Примечания).
Ремонт (Код вида станка, Код ремонта, Дата начала, Примечания).

Теперь ситуация изменилась. Несложный анализ показал, что нужно не просто подразделять
станки по типам, а иметь информацию о том, сколько раз ремонтировался тот или иной конкретный
станок.
2.3.14. Туристическая фирма
Вы работаете в туристической компании. Ваша компания работает с клиентами, продавая им
путевки. Вашей задачей является отслеживание финансовой стороны деятельности фирмы.
Работа с клиентами в Вашей компании организована следующим образом: у каждого клиента,
пришедшего к Вам, собираются некоторые стандартные данные – фамилия, имя, отчество, адрес,
телефон. После этого Ваши сотрудники выясняют у клиента, куда он хотел бы поехать отдыхать.
При этом ему демонстрируются различные варианты, включающие страну проживания, особенно-
сти местного климата, имеющиеся отели разного класса. Наряду с этим, обсуждается возможная
длительность пребывания и стоимость путевки. В случае если удалось договориться, и найти для
клиента приемлемый вариант, Вы регистрируете факт продажи путевки (или путевок, если клиент
покупает сразу несколько путевок), фиксируя дату отправления. Иногда Вы решаете предоставить
клиенту некоторую скидку.
Таблицы
Маршруты (Код маршрута, Страна, Климат, Длительность, Отель, Стоимость).
Путевки (Код маршрута, Код клиента, Дата отправления, Количество, Скидка).
Клиенты (Код клиента, Фамилия, Имя, Отчество, Адрес, Телефон).
Теперь ситуация изменилась. Фирма работает с несколькими отелями в нескольких странах. Пу-
тевки продаются на одну, две или четыре недели. Стоимость путевки зависит от длительности
тура и отеля. Скидки, которые предоставляет фирма, фиксированы. Например, при покупке более 1
путевки, предоставляется скидка 5%. Скидки могут суммироваться.
2.3.15. Грузовые перевозки
Вы работаете в компании, занимающейся перевозками грузов. Вашей задачей является отслежи-
вание стоимости перевозок с учетом заработной платы водителей.
Ваша компания осуществляет перевозки по различным маршрутам. Для каждого маршрута Вы
определили некоторое название, вычислили примерное расстояние и установили некоторую оплату
для водителя. Информация о водителях включает фамилию, имя, отчество и стаж. Для проведе-
ния расчетов Вы храните полную информацию о перевозках (маршрут, водитель, даты отправки и
прибытия). По факту некоторых перевозок водителям выплачивается премия.
Таблицы
Маршруты (Код маршрурта, Название, Дальность, Количество дней в пути, Оплата).

Водители (Код водителя, Фамилия, Имя, Отчество, Стаж).
Проделанная работа (Код маршрута, Код водителя, Дата отправки, Дата возвращения,

Теперь ситуация изменилась. Ваша фирма решила ввести гибкую систему оплаты. Так, оплата
водителям должна теперь зависеть не только от маршрута, но и от стажа водителя. Кроме того,
нужно учесть, что перевозку могут осуществлять два водителя.
2.3.16. Учет телефонных переговоров
Вы работаете в коммерческой службе телефонной компании. Компания предоставляет абонентам
телефонные линии для междугородних переговоров. Вашей задачей является отслеживание стоимо-
сти междугородних телефонных переговоров.
Абонентами компании являются юридические лица, имеющие телефонную точку, ИНН, расчетный
счет в банке. Стоимость переговоров зависит от города, в который осуществляется звонок, и времени
суток (день, ночь). Каждый звонок абонента автоматически фиксируется в базе данных. При этом
запоминаются город, дата, длительность разговора и время суток.
Таблицы
Абоненты (Код абонента, Номер телефона, ИНН, Адрес).

Города (Код города, Название, Тариф дневной, Тариф ночной).
Переговоры (Код переговоров, Код абонента, Код города, Дата, Количество минут, В

Теперь ситуация изменилась. Ваша фирма решила ввести гибкую систему скидок. Так, стоимость
минуты теперь уменьшается в зависимости от длительности разговора. Размер скидки для каждого
города разный.
2.3.17. Учет внутриофисных расходов
Вы работаете в бухгалтерии частной фирмы. Сотрудники фирмы имеют возможность осуществ-
лять мелкие покупки для нужд фирмы, предоставляя в бухгалтерию товарный чек. Вашей задачей
является отслеживание внутриофисных расходов.
Ваша фирма состоит из отделов. Каждый отдел имеет название. В каждом отделе работает опреде-
ленное количество сотрудников. Сотрудники могут осуществлять покупки в соответствии с видами
расходов. Каждый вид расходов имеет название, некоторое описание и предельную сумму средств,
которые могут быть потрачены по данному виду расходов в месяц. При каждой покупке сотрудник
оформляет документ, где указывает вид расхода, дату, сумму и отдел.
Таблицы
Отделы (Код отдела, Название, Количество сотрудников).

Виды расходов (Код вида, Название, Описание, Предельная норма).
Расходы (Код расхода, Код вида, Код отдела, Сумма, Дата).

Теперь ситуация изменилась. Оказалось, что нужно хранить данные о расходах не только в целом
по отделу, но и по отдельным сотрудникам. Нормативы по расходованию средств устанавливаются
не в целом, а по каждому отделу за каждый месяц. Неиспользованные в текущем месяце деньги
могут быть использованы позже.
2.3.18. Библиотека
Вы являетесь руководителем библиотеки. Ваша библиотека решила зарабатывать деньги, выда-
вая напрокат некоторые книги, имеющиеся в небольшом количестве экземпляров. Вашей задачей
является отслеживание финансовых показателей работы библиотеки.
У каждой книги, выдаваемой в прокат, есть название, автор, жанр. В зависимости от ценности
книги Вы определили для каждой из них залоговую стоимость (сумма, вносимая клиентом при
взятии книги напрокат) и стоимость проката (сумма, которую клиент платит при возврате книги,
получая назад залог). В библиотеку обращаются читатели. Все читатели регистрируются в карто-
теке, которая содержит стандартные анкетные данные (фамилия, имя, отчество, адрес, телефон).
Каждый читатель может обращаться в библиотеку несколько раз. Все обращения читателей фик-
сируются, при этом по каждому факту выдачи книги запоминаются дата выдачи и ожидаемая дата
возврата.
Таблицы
Книги (Код книги, Название, Автор, Залоговая стоимость, Стоимость проката, Жанр)
Читатели (Код читателя, Фамилия, Имя, Отчество, Адрес, Телефон).
Выданные книги (Код книги, Код читателя, Дата выдачи, Дата возврата).

Теперь ситуация изменилась. Несложный анализ показал, что стоимость проката книги должна
зависеть не только от самой книги, но и от срока ее проката. Кроме того, необходимо добавить
систему штрафов за вред, нанесенный книге и систему скидок для некоторых категорий читателей.
2.3.19. Прокат автомобилей
Вы являетесь руководителем коммерческой службы в фирме, занимающейся прокатом автомоби-
лей. Вашей задачей является отслеживание финансовых показателей работы пункта проката.
В Ваш автопарк входит некоторое количество автомобилей различных марок, стоимостей и типов.
Каждый автомобиль имеет свою стоимость проката. В пункт проката обращаются клиенты. Все
клиенты проходят обязательную регистрацию, при которой о них собирается стандартная информа-
ция (фамилия, имя, отчество, адрес, телефон). Каждый клиент может обращаться в пункт проката
несколько раз. Все обращения клиентов фиксируются, при этом по каждой сделке запоминаются
дата выдачи и ожидаемая дата возврата.
Таблицы
Автомобили (Код автомобиля, Марка, Стоимость, Стоимость проката, Тип).

Клиенты (Код клиента, Фамилия, Имя, Отчество, Адрес, Телефон).
Выданные автомобили (Код автомобиля, Код клиента, Дата выдачи, Дата возврата).

Теперь ситуация изменилась. Несложный анализ показал, что стоимость проката автомобиля
должна зависеть не только от самого автомобиля, но и от срока его проката, а также от года
выпуска. Также нужно ввести систему штрафов за возвращение автомобиля в ненадлежащем виде
и систему скидок для постоянных клиентов.
2.3.20. Выдача банком кредитов
Вы являетесь руководителем информационно-аналитического центра коммерческого банка. Одним
из существенных видов деятельности Вашего банка является выдача кредитов юридическим лицам.
Вашей задачей является отслеживание динамики работы кредитного отдела.
В зависимости от условий получения кредита, процентной ставки и срока возврата все кредит-
ные операции делятся на несколько основных видов. Каждый из этих видов имеет свое название.
Кредит может получить юридическое лицо (клиент), при регистрации предоставивший следующие
сведения: название, вид собственности, адрес, телефон, контактное лицо. Каждый факт выдачи
кредита регистрируется банком, при этом фиксируются сумма кредита, клиент и дата выдачи.
Таблицы
Виды кредитов (Код вида, Название, Условия получения, Ставка, Срок).

Клиенты (Код клиента, Название, Вид собственности, Адрес, Телефон, Контактное ли
Кредиты (Код вида, Код клиента, Сумма, Дата выдачи).

Теперь ситуация изменилась. После проведения различных исследований выяснилось, что ис-
пользуемая система не позволяет отслеживать динамику возврата кредитов. Для устранения этого
недостатка Вы приняли решение учитывать в системе еще и дату фактического возврата денег. Нуж-
но еще учесть, что кредит может гаситься частями, и за задержку возврата кредита начисляются
штрафы.
2.3.21. Инвестирование свободных средств
Вы являетесь руководителем аналитического центра инвестиционной компании. Ваша компания
занимается вложением денежных средств в ценные бумаги.
Ваши клиенты – предприятия, которые доверяют Вам управлять их свободными денежными сред-
ства на определенный период. Вам необходимо выбрать вид ценных бумаг, которые позволят по-
лучить прибыль и Вам и Вашему клиенту. При работе с клиентом для Вас весьма существенной
является информация о предприятии – название, вид собственности, адрес и телефон.
Таблицы
Ценные бумаги (Код ценной бумаги, Минимальная сумма сделки, Рейтинг, Доходность
Инвестиции (Код инвестиции, Код ценной бумаги, Код клиента, Котировка, Дата поку
Клиенты (Код клиента, Название, Вид собственности, Адрес, Телефон).

При эксплуатации базы данных стало понятно, что необходимо хранить историю котировок каж-
дой ценной бумаги. Кроме того, помимо вложений в ценные бумаги, существует возможность вкла-
дывать деньги в банковские депозиты.
2.3.22. Занятость актеров театра
Вы являетесь коммерческим директором театра, и в Ваши обязанности входит вся организационно-
финансовая работа, связанная с привлечением актеров и заключением контрактов.
Вы поставили дело следующим образом: каждый год театр осуществляет постановку различных
спектаклей. Каждый спектакль имеет определенный бюджет. Для участия в конкретных постановках
в определенных ролях Вы привлекаете актеров. С каждым из актеров Вы заключаете персональный
контракт на определенную сумму. Каждый из актеров имеет некоторый стаж работы, некоторые из
них удостоены различных наград и званий.
Таблицы
Актеры (Код актера, Фамилия, Имя, Отчество, Звание, Стаж).

Спектакли (Код спектакля, Название, Год постановки, Бюджет).
Занятость актеров в спектакле (Код актера, Код спектакля, Роль, Стоимость годово

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

Пациенты (Код пациента, Фамилия, Имя, Отчество, Год рождения).
Обращения (Код обращения, Код врача, Код пациента, Дата обращения, Диагноз, Стои

В результате эксплуатации базы данных выяснилось, что при обращении в поликлинику пациент
обследуется и проходит лечение у разных специалистов. Общая стоимость лечения зависит от сто-
имости тех консультаций и процедур, которые назначены пациенту. Кроме того, для определенных
категорий граждан предусмотрены скидки.
2.3.24. Анализ динамики показателей финансовой отчетности различных
предприятий
Вы являетесь руководителем информационно-аналитического центра крупного холдинга. Вашей
задачей является отслеживание динамики показателей для предприятий Вашего холдинга.
В структуру холдинга входят несколько предприятий. Каждое предприятие имеет стандартные
характеристики (название, реквизиты, телефон, контактное лицо). Работа предприятия может быть
оценена следующим образом: в начале каждого отчетного периода на основе финансовой отчетности
вычисляется по неким формулам определенный набор показателей. Принять, что важность показате-
лей характеризуется некоторыми числовыми константами. Значение каждого показателя измеряется
в некоторой системе единиц.
Таблицы
Показатели (Код показателя, Название, Важность, Единица измерения).

Предприятия (Код предприятия, Название, Банковские реквизиты, Телефон, Контактно
Динамика показателей (Код показателя, Код предприятия, Дата, Значение).

В результате эксплуатации базы данных выяснилось, что некоторые показатели считаются в руб-
лях, некоторые в долларах, некоторые в евро. Для удобства работы с показателями нужно хранить
изменения курсов валют относительно друг друга.
2.3.25. Учет телекомпанией стоимости прошедшей в эфире рекламы
Вы являетесь руководителем коммерческой службы телевизионной компании. Вашей задачей яв-
ляется отслеживание расчетов, связанных с прохождением рекламы в телеэфире.
Работа построена следующим образом: заказчики просят поместить свою рекламу в определенной
передаче в определенный день. Каждый рекламный ролик имеет определенную продолжительность.
Для каждой организации-заказчика известны банковские реквизиты, телефон и контактное лицо
для проведения переговоров. Передачи имеют определенный рейтинг. Стоимость минуты рекламы
в каждой конкретной передаче известна (определяется коммерческой службой, исходя из рейтинга
передачи и прочих соображений).
Таблицы
Передачи (Код передачи, Название, Рейтинг, Стоимость минуты).

Реклама (Код рекламы, Код передачи, Код заказчика, Дата, Длительность в минутах)
Заказчики (Код заказчика, Название, Банковские реквизиты, Телефон, Контактное ли

В результате эксплуатации базы данных выяснилось, что необходимо также хранить информацию
об агентах, заключивших договоры на рекламу. Зарплата рекламных агентов составляет некоторый
процент от общей стоимости рекламы, прошедшей в эфире.
2.3.26. Интернет-магазин
Вы являетесь сотрудником коммерческого отдела компании, продающей различные товары через
Интернет. Вашей задачей является отслеживание финансовой составляющей работы компании.
Работа Вашей компании организована следующим образом: на Интернет-сайте компании представ-
лены (выставлены на продажу) некоторые товары. Каждый из них имеет некоторое название, цену
и единицу измерения (штуки, килограммы, литры). Для проведения исследований и оптимизации
работы магазина Вы пытаетесь собирать данные с Ваших клиентов. При этом для Вас определяю-
щее значение имеют стандартные анкетные данные, а также телефон и адрес электронной почты
для связи. В случае приобретения товаров на сумму свыше 5000р. клиент переходит в категорию
«постоянных клиентов» и получает скидку на каждую покупку в размере 2%. По каждому факту
продажи Вы автоматически фиксируете клиента, товары, количество, дату продажи, дату доставки.
Таблицы
Товары (Код товара, Название, Цена, Единица измерения).

Клиенты (Код клиента, Фамилия, Имя, Отчество, Адрес, Телефон, email, Признак пос
Продажи (Код продажи, Код товара, Код клиента, Дата продажи, Дата доставки, Коли

В результате эксплуатации базы данных выяснилось, что иногда возникают проблемы, связанные
с нехваткой информации о наличии нужных товаров на складе в нужном количестве. Кроме того,
обычно клиенты в рамках одного заказа покупают не один вид товара, а несколько видов. Исходя
из суммарной стоимости заказа, компания предоставляет дополнительные скидки.
2.3.27. Ювелирная мастерская
Вы работаете в ювелирной мастерской. Ваша мастерская осуществляет изготовление ювелирных
изделий для частных лиц на заказ. Вы работаете с определенными материалами (платина, золото,
серебро, различные драгоценные камни и т.д.). При обращении к Вам потенциального клиента Вы
определяетесь с тем, какое именно изделие ему необходимо. Все изготавливаемые Вами изделия
принадлежат к некоторому типу (серьги, кольца, броши, браслеты), бывают выполнены из опреде-
ленного материала, имеют некоторый вес и цену (включающую стоимость материалов и работы).
Таблицы
Изделия (Код изделия, Название, Тип, Код материала, Вес, Цена).

Материалы (Код материала, Название, Цена за грамм).
Продажи (Код изделия, Дата продажи, Фамилия покупателя, Имя покупателя, Отчество

В процессе опытной эксплуатации базы данных выяснилось, что ювелирное изделие может состо-
ять из нескольких материалов. Кроме того, постоянным клиентам мастерская предоставляет скидки.
2.3.28. Парикмахерская
Вы работаете в парикмахерской.
Ваша парикмахерская стрижет клиентов в соответствии с их пожеланиями и некоторым каталогом
различных видов стрижки. Так, для каждой стрижки определены название, принадлежность полу
(мужская, женская), стоимость работы. Для наведения порядка Вы, по мере возможности, состав-
ляете базу данных клиентов, запоминая их анкетные данные (фамилия, имя, отчество). Начиная
с 5-ой стрижки, клиент переходит в категорию постоянных и получает скидку в 3% при каждой
последующей стрижке. После того, как закончена очередная работа, в кассе фиксируются стрижка,
клиент и дата производства работ.
Таблицы
Стрижки (Код стрижки, Название, Пол, Стоимость).

Клиенты (Код клиента, Фамилия, Имя, Отчество, Пол, Признак постоянного клиента).
Работа (Код работы, Код стрижки, Код клиента, Дата).

Теперь ситуация изменилась. У Вашей парикмахерской появился филиал, и Вы хотели бы видеть,
в том числе, и раздельную статистику по филиалам. Кроме того, стоимость стрижки может меняться
с течением времени. Нужно хранить не только последнюю цену, но и все данные по изменению цены
стрижки.
2.3.29. Химчистка
Вы работаете в химчистке.
Ваша химчистка осуществляет прием у населения вещей для выведения пятен. Для наведения по-
рядка Вы, по мере возможности, составляете базу данных клиентов, запоминая их анкетные данные
(фамилия, имя, отчество). Начиная с 3-го обращения, клиент переходит в категорию постоянных
клиентов и получает скидку в 3% при чистке каждой последующей вещи. Все оказываемые Вами
услуги подразделяются на виды, имеющие название, тип и стоимость, зависящую от сложности
работ. Работа с клиентом первоначально состоит в определении объема работ, вида услуги и, соот-
ветственно, ее стоимости. Если клиент согласен, он оставляет вещь (при этом фиксируется услуга,
клиент и дата приема) и забирает ее после обработки (при этом фиксируется дата возврата).
Таблицы
Виды услуг (Код вида услуг, Название, Тип, Стоимость).

Клиенты (Код клиента, Фамилия, Имя, Отчество, Признак постоянного клиента).
Услуги (Код услуги, Код вида услуги, Код клиента, Дата приема, Дата возврата).

Теперь ситуация изменилась. У Вашей химчистки появился филиал, и Вы хотели бы видеть, в том
числе, и раздельную статистику по филиалам. Кроме того, вы решили делать надбавки за срочность
и сложность работ.
2.3.30. Сдача в аренду торговых площадей
Вы работаете в крупном торговом центре, сдающим в аренду коммерсантам свои торговые площа-
ди.
Вашей задачей является наведение порядка в финансовой стороне работы торгового центра.
Работы Вашего торгового центра построена следующим образом: в результате планирования Вы
определили некоторое количество торговых точек в пределах Вашего здания, которые могут сдавать-
ся в аренду. Для каждой из торговых точек важными данными являются этаж, площадь, наличие
кондиционера и стоимость аренды в день. Со всех потенциальных клиентов Вы собираете стандарт-
ные данные (название, адрес, телефон, реквизиты, контактное лицо). При появлении потенциально-
го клиента Вы показываете ему имеющиеся свободные площади. При достижении соглашения Вы
оформляете договор, фиксируя в базе данных торговую точку, клиента, период (срок) аренды.
Таблицы
Торговые точки (Код торговой точки, Этаж, Площадь, Наличие кондиционера, Стоимос
Клиенты (Код клиента, Название, Реквизиты, Адрес, Телефон, Контактное лицо).
Аренда (Код аренды, Код торговой точки, Код клиента, Дата начала, Дата окончания

В результате эксплуатации базы данных выяснилось, что некоторые клиенты арендуют сразу
несколько торговых точек. Помимо этого, Вам необходимо собирать информацию об ежемесячных
платежах, поступающих Вам от арендаторов.
Часть II.
Модуль 1
3. Реляционная алгебра
3.1. Отсутствующие данные
Проблема отсутствующих данных довольно часто встречается в реальной жизни. Например, в ис-
торических записях встречаются такие записи, как «Дата рождения неизвестна»; в повестке дня
собрания часто докладчик «указан» в виде «Будет объявлен»; милицейские доклады могут включать
такие записи, как «номер автомобиля неизвестен».
Для решения проблемы представления отсутствующих данных был предложен подход, основанный
на использовании специального маркера, соответствующего понятию неопределенных значений и
называемого null-значением (будем произносить «нул-значение» вместо «нал-значение»).
В различных источниках на неопределенное значение, то есть на null-значение, часто ссылаются
как на «пустое значение» или «нулевое значение». Однако нулевое значение, то есть число 0 –
это пустое значение для числовых типов данных, а понятия пустого и неопределенного значений
принципиально различаются. Поэтому необходимо обращать внимание на контекст употребления
этих терминов.
Вначале рассмотрим понятие пустого значения.
3.2. Пустые значения
Пустое значение – это просто одно из возможных значений определенного типа данных, названное
пустым. Естественными пустыми значениями, например, являются
• 0 – нулевое значение для числовых типов данных,
• false для логического типа данных,
• ” – пустая строка символов для строк символов переменной длины,
• строка из пробелов, знаков табуляции и других неотображаемых символов для строк символов
постоянной длины.
Не всем типам данных можно естественным образом сопоставить пустое значение. Например, ка-
кое значение можно назвать пустым для данных типа даты, если в СУБД поддерживается диапазон
представления дат от 01.01.0100 до 31.12.9999? В некоторых СУБД в подобных случаях вводится
специальное обозначение для константы пустого значения. Так, например, для пустого значения да-
ты может вводиться специальное обозначение {..}, а непустые константы представляться в формате
{ДД.ММ.ГГГГ}. Если понятие пустого значения введено для всех типов данных, поддерживаемых
СУБД, то тогда появляется возможность использования оператора вставки в таблицу строки пустых
значений:
insert into имя_таблицы blank
Однако в SQL-ориентированных СУБД для подобных целей используется оператор вставки в

таблицу строки значений по умолчанию:
insert into имя_таблицы default values
Значения по умолчанию задаются для каждого столбца при создании таблицы. В частности, в
качестве значения по умолчанию можно задать и пустое значение. Поэтому единственная цель, с
которой выше вводилось понятие пустого значения – это показать отличие понятия пустого значения
от понятия неопределенного значения.
3.3. Неопределенные значения

Для маркировки неопределенных значений используется специальное зарезервированное ключевое
слово null. Null-значение может быть присвоено переменной любого типа (числового, логического,
строкового, даты, даты и времени и т.д.).
3.3.1. Интерпретации
Null-значения допускают следующие интерпретации:
1) значение неизвестно (пока),
2) значение неприменимо.
Рассмотрим пример (табл. 3.3.1).

Null-значение номера паспорта в 1-ом случае интерпретируется как неизвестное, поскольку речь
идет о совершеннолетнем гражданине. Во 2-ом случае значение номера паспорта интерпретируется
как неприменимое (до тех пор, пока текущая дата рассмотрения этих данных не будет соответ-
ствовать совершеннолетнему возрасту). В 3-ем случае неясно, какую можно дать интерпретацию
Таблица 3.1.: Интерпретации null-значения
Паспортные данные
№ пп Фамилия . . . Г.р. № паспорта Интерпретация
1 Иванов 1980 null неизвестно
2 Петров 2000 null неприменимо
3 Сидоров null null ???
null-значению номера паспорта, поскольку год рождения имеет null-значение (интерпретируемое как
неизвестное). Кроме того, с течением времени интерпретация null-значения номера паспорта во 2-ом
случае изменится.
Таким образом, интерпретация null-значений существенно зависит от семантики данных. Правила
вычисления выражений с null-значениями, реализованные в СУБД, следует рассматривать лишь как
правила, действующие в системе по умолчанию.
3.3.2. Правила вычисления выражений

Как формулируются правила вычисления выражений с null-значениями?
1) Как обычно, вычисление выражения заключается в последовательном выполнении отдельных
операций согласно их приоритету и подстановке полученных значений в выражение. Например,
при x, равном 3, имеем последовательно
(1 + 2) × x2 ⇒ (1 + 2) × 32 ⇒ 3 × 32 ⇒ 3 × 9 ⇒ 27
2) Как общее правило, результат выполнения отдельной операции с null-значением в качестве
операнда считается null-значением. Например, при x, имеющим null-значение, имеем
(1 + 2) × x2 ⇒ (1 + 2) × null2 ⇒ 3null2 ⇒ 3 × null ⇒ null
3) Исключением из общего правила являются правила выполнения операций конъюнкции (and) и

дизъюнкции (or) в условиях действия законов поглощения:
f alse and x ⇒ x and f alse := f alse, true or x ⇒ x or true := true
Здесь символ подстановки «:=» разделяет список выражений и значение, которым они мо-
гут быть заменены. Таким образом, законы поглощения имеют место при любых значениях
операнда, в том числе и при значении null:
f alse and null ⇒ null and f alse := f alse, true or null ⇒ null or true := true
Почему правила выполнения операций конъюнкции и дизъюнкции являются исключением из об-

щего правила? Дело в том, что в современных языках программирования вместо обычных операций
конъюнкции и дизъюнкции (обозначаемых как and и or) фактически используются (без изменения
обозначений) операции условной конъюнкции и условной дизъюнкции (их следовало бы обозначать
как cand и cor). В этих условных операциях вычисление операндов проводится слева направо. При
этом если левый операнд оказывается поглощающим элементом для операции, то правый операнд
не вычисляется и результат операции полагается равным поглощающему элементу.
Примечание. Это приводит, например, к корректности следующего оператора, в котором a[1. . . n] – мас-
сив из n элементов: if i < n cand a[i] > a[i + 1] then a[i], a[i + 1] := a[i + 1], a[i] (Здесь во фразе
then использован оператор кратного присваивания, с помощью которого соседние элементы массива меняются
значениями.) •
Следовательно, в операциях условной конъюнкции и дизъюнкции false и true являются левыми
поглощающими элементами соответственно. Но тогда они должны быть и правыми поглощающими
элементами, поскольку иначе не выполнялся бы закон коммутативности в случае определенности
обоих операндов.
Как можно кратко и в общем виде сформулировать правила интерпретации null-значений в кон-
тексте различных операций?
1) В контексте любых операций, за исключением логических операций отрицания, конъюнкции и

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

стве операнда интерпретируется как неизвестное. Тогда, если результат выполнения операции
не зависит от подстановки вместо null-значения значения false или true, то этот независящий
результат и полагается в качестве результата операции. В противном случае результат не опре-
делен, и, следовательно, результатом является null-значение. Таким образом, имеем следующие
правила работы с null-значениями в контексте логических операций («таблицы истинности»).
3.3.3. Следствия
К каким следствиям приводят правила? Следствием является нарушение привычных законов вычис-
лений. В частности, для операций арифметических, логических, строковых и сравнения имеем при
null-значении операнда x. Следовательно, число нуль уже не является поглощающим элементов для
Таблица 3.2.: Таблица истинности
x not x x y x and y x or y
false false false false
false true false null false null
false true false true
null false false null
null null null null null null
null true null true
true false false true
true false true null null true
true true true true
Таблица 3.3.: Операции с null-значением
Тип операции Выражение Значение

x×0
арифметич. null
x–x
булевый x or not x null
строковый ’Иванов’ + ’ ’ + x null
x<x
x=x
сравнения null
x 6= x
x>x
операции умножения, закон исключенного третьего уже не имеет места, отношение равенства не
рефлексивно и нельзя сказать, равно или нет null-значение самому себе.
Таким образом, null-значение не является значением в обычном смысле этого слова и непосред-
ственное сравнение выражения с null-значением невозможно, так как при любых значениях операнда
x в результате сравнения будет получено null-значение.
Как проверить значение переменной или выражения на null-значение? Следует использовать спе-
циальный встроенный предикат IsNull(выражение) – «есть null». Предикат возвращает значение
false или true (но не null) и может применяться к выражению любого типа, например
Ясно, что применительно к пустым значениям предикат IsNull всегда возвращает значение false.
Таблица 3.4.: Предикат IsNull
IsNull(Выражение) Значение
IsNull(0) false
IsNull(x + ’abc’ + null) true
IsNull(2 × null) true
3.3.4. Проверка условий

Как null-значения влияют на проверку условий в условных операторах и операторах цикла? В кон-
тексте возможных логических значений false, null и true null-значение имеет смысл как бы третьего
логического значения, и потому на него часто ссылаются как на значение unknown – «неизвестный».
Однако в СУБД реализуется двухзначная логика. Поэтому неопределенное условие, то есть усло-
вие с null-значением, должно быть проинтерпретировано либо как false, либо как true.
В условных операторах и операторах цикла неопределенное условие по умолчанию интерпретиру-
ется как false:
if P then A else B – при IsNull(P) выполнится B
if not P then B else A – при IsNull(P) выполнится A
while P do A; B – при IsNull(P) выполнится B
Неожиданным следствием является неэквивалентность условных операторов, один из которых
получен из другого отрицанием условия и перестановкой ветвей. Различие в том, что null-значению
условия P в первом случае соответствует оператор B, а во втором – оператор A. Действительно, если
во втором случае условие P имеет null-значение, то его отрицание not P также имеет null-значение,
и согласно общему правилу будет выполняться ветвь else, соответствующая оператору A.
Как null-значения влияют на проверку условий в ограничениях целостности? В ограничениях
целостности, представляющих собой условия корректности вводимых данных, неопределенное усло-
вие интерпретируется как true, поскольку отвергнуть нужно лишь заведомо некорректные данные.
Например, проверочное условие check(x > 0) позволит ввести и положительные значения x, и null-
значение.
Как переопределить правила вычислений с null-значениями, действующими по умолчанию? С по-
мощью встроенной функции подмены null-значения IfNull(выражение1, выражение2). Функция воз-
вращает значение 1-го выражения, если оно не является null-значением, и значение 2-го выражения
в противном случае. На тип возвращаемого значения ограничений не накладывается.
С помощью функции подмены интерпретацию неопределенных условий по умолчанию можно пред-
ставить в явном виде:
if IfNull(P, false) then A else B
while IfNull(P, false) do A; B
IfNull(ограничение_целостности, true)
Как ввести null-значение с клавиатуры? Правила специфичны для каждой СУБД. В некоторых
СУБД для этих целей используется комбинация клавиш Ctrl+0.
3.4. Реляционные объекты данных

В основе реляционной модели лежит иерархия основных объектов: атрибут – кортеж – отношение
– база данных. Центральное место занимает понятие отношения.
К табличной форме представления отношений предъявляются следующие требования, относящие-
ся к заголовку таблицы, ее строкам, столбцам и данным в столбцах.
1) Заголовок таблицы должен состоять из единственной строки заголовков столбцов с уникальны-

ми именами. На практике это означает сведение многоярусного заголовка к одноярусному, что
всегда достижимо выбором подходящих наименований столбцов, так что порядок перечисления
столбцов становится несущественным.
2) Порядок строк в теле таблицы должен быть несущественным. Это требование также не явля-
ется ограничительным, поскольку при необходимости можно ввести дополнительный столбец,
определяющий порядок строк.
3) Среди строк тела таблицы не должно быть дубликатов (в теории). Это требование не являет-
ся ограничительным, поскольку при необходимости можно ввести дополнительный столбец с
данными о числе дубликатов строк.
Примечание. Данное требование приводит к построению реляционной алгебры, в которой отноше-
ния (таблицы) рассматриваются как множества кортежей (строк тела таблицы). Если рассматривать
отношения как мультимножества кортежей (в мультимножествах дубликаты элементов допускаются
и поэтому можно говорить не только о вхождении элемента в мультимножество, но и о числе этих
вхождений), то это привело бы к построению так называемой псевдореляционной алгебры. Даже ес-
ли в исходном состоянии база данных не содержит отношений с дубликатами кортежей, то все равно
дубликаты могут появиться в результирующих запросах. В этом смысле на практике реализуется как
бы псевдореляционная алгебра. Однако операторы языка SQL, реализующие запросы с потенциальной
возможностью появления дубликатов кортежей, имеют специальные опции, позволяющие управлять
исключением дубликатов •
4) Данные в столбце должны быть одного и того же и, что принципиально важно, простого
типа. Это требование лежит в основе всех принципов проектирования и реализации (чисто)
реляционных баз данных.
Примечание. Простой тип данных – это тип, значения данных которого не содержат составных частей.
Таким образом, данные в столбце не должны быть ни списками, ни массивами, ни деревьями, ни тому
подобными составными объектами. Составные объекты в реляционной модели сами представляются в
виде множества взаимосвязанных таблиц. Еще раз подчеркнем, что это требование относится к чисто
реляционной модели данных. СУБД с расширениями это требование могут не выдвигать, но тогда они
должны иметь и соответствующие механизмы доступа к подобъектам таких составных объектов •
3.4.1. Формальные определения

Далее при записи формальных определений знак тождественного равенства связывает сокращен-
ную и расширенную формы обозначения определяемого понятия. Определения отражают наиболее
абстрактный математический взгляд на базу данных как на множество отношений:
dom(a) ⊆ {x | type(x) = type(a)} – домен атрибута
a = (name(a) : dom(a)) – атрибут
S = {a | a ∈ S} – схема отношения
x(a) = (name(a) : x), x ∈ dom(a) – именованное значение атрибута
t ≡ t(S) = {x(a) | a ∈ def (t) ⊆ S} – кортеж
r ≡ r(S) = {t(S) | t ∈ r} – отношение
Σ = {S | S ∈ Σ} – схема базы данных
D ≡ D(Σ) = {r(S) | S ∈ Σ} – база данных
3.4.2. Домены и атрибуты

Домен атрибута dom(a) ⊆ {x | type(x) = type(a)} определяется как множество допустимых значе-
ний одного и того же типа, представляющего тип атрибута type(a) (представляющего тип данных
в столбце). Тип атрибута должен быть простым.
Как и любое множество, домен может быть задан следующими способами:
1) перечислением значений,
2) характеристическим предикатом,
3) порождающей процедурой.
Приведем примеры задания доменов указанными способами:

dom(День) = {пн, вт, ср, чт, пт, сб, вс}
dom(Оценка) = {x | type(x) = integer & 2 6 x 6 5}
dom(Случайно) = {x | x = 0 ∨ x := random(x)}
Домен, определенный с помощью характеристического предиката, соответствует так называемому
подтипу данных, определенному пользователем.
Понятие домена имеет семантическую нагрузку: данные считаются сравнимыми только в том слу-
чае, когда они относятся к одному домену. Например, домены dom(№ паспорта) и dom(№ зачетки)
относятся к типу целых чисел, но сравнение значений из этих доменов смысла не имеет. Кроме того,
домен не всегда может быть практически задан. Домен dom(Имя), скорее всего, будет определен
на типе строк символов, и тогда в число его допустимых значений попадут, в частности, строки,
начинающиеся с мягкого знака.
Примечание. Заметим, что среди значений домена null-значение не появляется. Допустимость или не
допустимость null-значений среди значений атрибута определяется с помощью специального флажка, указы-
ваемого в операторе создания отношения (таблицы) •
Атрибут a = (name(a) : dom(a)) определяется как упорядоченная пара, состоящая из имени
атрибута name(a) (имени столбца) и домена атрибута dom(a). Вместо запятой в обозначении упо-
рядоченной пары используется двоеточие для того, чтобы подчеркнуть близость понятий домена и
типа данных.
3.4.3. Схема отношения

Схема отношения S = {a | a ∈ S} определяется как конечное множество атрибутов с уникальными
именами и изображается как строка заголовков столбцов. Число атрибутов в схеме отношения
называется степенью отношения и обозначается как мощность множества |S|. Схема отношения
может ассоциироваться с именем (схемы) отношения, изображаемым как тематический заголовок
таблицы. В текстовой форме именованные схемы отношений изображаются в виде именованного
списка имен атрибутов, например Студенты(№ ЗК, Ф, И, О). При этом домены атрибутов, как
правило, не указываются, но подразумеваются.
Согласно определению, схема отношения может быть и пустой. Хотя создание пустой схемы СУБД
не допустит, абстракция пустой схемы S = ∅ удобна в теории.
3.4.4. Именованное значение атрибута

Именованное значение атрибута x(a) = (name(a) : x), x ∈ dom(a) определяется как упорядоченная
пара, состоящая из имени атрибута и значения атрибута. Значение атрибута берется из домена
атрибута. Именованное значение атрибута соответствует ячейке тела таблицы, например, (№ ЗК:
100), (Г.р.: 1986).
3.4.5. Кортеж
Кортеж t ≡ t(S) = {x(a) | a ∈ def (t) ⊆ S} (tuple – кортеж) со схемой отношения S определяется как
множество именованных значений атрибутов из области определения кортежа def (t) и изображается
как строка тела таблицы. Одному имени атрибута должно соответствовать не более одного значения
атрибута. В зависимости от области определения кортеж называется
1) def (t) ⊆ S – частичным (общий случай),
2) def (t) = S – полным,
3) def (t) ⊂ S – неполным,
4) def (t) = ∅ – нигде не определенным.
Приведем примеры изображения полного, неполного и нигде не определенного кортежей в тексто-
вой форме:
t(№ЗК, Ф, И, О) = {(№ ЗК: 100), (Ф: Иванов), (И: Иван), (О: Иванович)}
t(№ЗК, Ф, И, О) = {(№ ЗК: 100), (Ф: Иванов)}
t(№ЗК, Ф, И, О) = {} ≡ ∅(№ЗК, Ф, И, О)
Полный кортеж определен на всей схеме отношения. Неполный кортеж не определен хотя бы на
одном атрибуте. Нигде не определенный кортеж со схемой S представляет собой пустое множество,
ассоциированное со схемой, и в расширенной форме обозначается как ∅(S).
В табличной форме неопределенные значения кортежа изображаются как null-значения. В част-
ности, нигде не определенный кортеж изображается как строка таблицы, состоящая из одних null-
значений.
Почему формы изображения неопределенных значений кортежа в текстовой и табличной формах
различаются? Почему бы в текстовой форме не указывать явно null-значения для неопределенных
значений кортежа на атрибутах? Дело в том, что из кортежей необходимо образовывать множества,
представляющие отношения, а для этого необходимо ввести понятие равенства кортежей. Сравни-
мыми считаются кортежи над одной и той же схемой отношения (это понятно). Но как быть с
null-значениями? Если null-значение ввести в определение кортежа, то например, все кортежи вида
{(№ ЗК: 100), (Ф: Иванов), (И: null), (О: null)} считались бы формально различными, так как при
их покомпонентном сравнении было бы получено логическое значение null, интерпретируемое как
false. Таким образом, согласно данному определению кортежи (в теории) равны только тогда, когда
они полностью идентичны, то есть имеют одну и ту же область определения (имеют не null-значения
для одних и тех же атрибутов) и в этой области совпадают.
3.4.6. Отношение
Отношение r ≡ r(S) = {t(S) | t ∈ r} со схемой отношения S определяется как конечное множество
кортежей со схемой S. Количество кортежей в отношении называется мощностью отношения и обо-
значается как мощность множества |r|. В табличной форме представления отношению соответствует
тело таблицы.
Отношение со схемой S может быть пустым, и тогда для него необходимо использовать расши-
ренную форму обозначения ∅(S). Это обозначение совпадает с обозначением нигде не определенного
кортежа и, следовательно, интерпретация обозначения должна определяться по контексту.
Сравнимыми считаются отношения с одной и той же схемой.
В следующих случаях отношение называется
1) ∀t ∈ r(S) [def (t) ⊆ S] – частичным (общий случай),
2) ∀t ∈ r(S) [def (t) = S] – полным,

3) ∃t ∈ r(S) [def (t) ⊂ S] – неполным,
4) ∀t ∈ r(S) [def (t) = ∅] – нигде не определенным.
Полное отношение не содержит null-значений в теле таблицы, а неполное – содержит. Нигде

не определенное отношение либо является пустым ∅(S), либо содержит (единственный, будучи не
мультимножеством) нигде не определенный кортеж {∅(S)}.
3.4.7. Схема базы данных

Схема базы данных Σ = {S | S ∈ Σ} определяется как конечное множество именованных схем
отношений с уникальными именами.
3.4.8. База данных

База данных D ≡ D(Σ) = {r(S) | S ∈ Σ} со схемой базы данных Σ определяется как конечное
множество отношений со схемами из схемы базы данных.
3.5. Операции реляционной алгебры

Реляционная алгебра – это частная разновидность алгебр, в которой операндами являются отноше-
ния (в смысле реляционной модели данных).
В реляционной алгебре выделяются унарные и бинарные операции.
3.5.1. Унарные операции
В терминах таблиц отношение включает строки, столбцы и строку заголовков столбцов. Поэтому
естественными унарными операциями, преобразующим отношение-операнд в отношение-результат,
являются операции
1) выборки (выборки строк),
2) проекции (выборки столбцов),
3) переименования атрибутов (переименования столбцов).
Дадим формальные определения операций выборки, проекции и переименования атрибутов:
1) σhP ir(S) = {t(S) | t ∈ r & σhP it}
2) πhS 0 ir(S) ≡ r[S 0 ]{t0 (S 0 ) | ∃t ∈ r(t[S 0 ] = t0 )}, S 0 ⊆ S
3) ρhϕir(S) = {t̃(S̃) | ρhϕ−1 it̃ ∈ r}, ϕ : S → S̃, ϕ−1 : S̃ → S
Примечание. Обозначения унарных операторов σ, π, ρ – от Select, Project, Rename. Параметры этих

операторов записываются в угловых скобках. Схемы отношений для отношений и их кортежей записываются
в круглых скобках. Указание схемы отношения для отношений и кортежей во многих случаях опускается, так
как отношения и принадлежащие им кортежи имеют одну и ту же схему и в формулах достаточно указать
схему хотя бы в одном месте – для отношения или принадлежащего ему кортежа. В квадратных скобках
записывается схема отношения, которую получает отношение-операнд в результате проекции. Таким образом,
и r(S), и r[S 0 ] имеют указанные в скобках схемы S и S 0 соответственно, но во втором случае схема самого
отношения S является надсхемой указанной схемы проекции S 0 •
Оператор выборки σhP i с условием выборки P ≡ P (S) в применении к отношению r(S) дает
новое отношение с той же схемой S, состоящее из тех кортежей t(S) исходного отношения, которые
удовлетворяют условию P hSit. Условие выборки P hSi записывается как выражение исчисления вы-
сказываний (с логическими связками not, and, or), зависящее от имен атрибутов схемы отношения.
Применение условия к кортежу P hSit сводится к подстановке значений атрибутов кортежа вме-
сто имен атрибутов. Null-значение условия выборки по умолчанию интерпретируется как false, то
есть условие выборки P hSi по умолчанию рассматривается как IfNull(P hSi, false). (Напомним, что
IfNull(•,•) – это функция подмены null-значений.) Если требуется иная интерпретация, то следует
условие выборки P hSi в операторе выборки σhP i заменить на IfNull(P hSi, true). При такой замене
условие выборки уже не будет принимать null-значений, и правило интерпретации по умолчанию не
будет действовать, так как IfNull(IfNull(P hSi, true), false) = IfNull(P hSi, true).
Следующее выражение описывает неименованное отношение, содержащее (в терминах таблиц) те
строки таблицы Сессия, которые удовлетворяют заданному условию выборки:
σhПредмет = ’БД’ and ОценкаiСессия(№ ЗК, Ф, И, О, Предмет, Оценка)
Оператор проекции πhS 0 i (в префиксной записи) и [S 0 ] (в постфиксной записи) на подсхему

S 0 в применении к отношению r(S) дает отношение с новой схемой S 0 , состоящее из проекций
t[S 0 ] кортежей исходного отношения. Проекция кортежа соответствует подстроке строки таблицы и
определяется следующим образом:
t[S 0 ] ≡ t(S)[S 0 ] = {x(a) | a ∈ def (t) ∩ S 0 }, S 0 ⊆ S
Следующее выражение описывает неименованное отношение, содержащее (в терминах таблиц)

указанные столбцы таблицы Сессия (дубликаты строк после вычеркивания столбцов из результата
исключаются):
Сессия[№ ЗК, Предмет, Оценка]
Оператор переименования ρhσi с функцией переименования σ : S → S̃, устанавливающей вза-
имно однозначное соответствие между именами атрибутов схем S и S̃, в применении к отношению
r(S) дает отношение со схемой S̃, состоящее из кортежей исходного отношения с переименованными
атрибутами.
Следующее выражение описывает неименованное отношение, полученное (в терминах таблиц) из
таблицы Сессия заменой имен атрибутов (№ ЗК, Оценка) на (№ зачетки, Балл) соответственно:
ρh№ ЗК, Оценка → № зачетки, БаллiСессия(№ ЗК, Ф, И, О, Предмет, Оценка)

Из определений операций следуют следующие свойства.
Группа 1. Соотношения мощностей:
1) |σhP ir| 6 |r|
2) |r[S 0 ]| 6 |r|
3) |ρhσir| = |r|
Примечание. Операция выборки связана с вычеркиванием кортежей. Из результата проекции дубликаты

кортежей исключаются. Переименование атрибутов не изменяет числа кортежей •
Группа 2. Свойства идемпотентности:
1) σhP iσhP ir = σhP ir
2) r[S 0 ]r[S 0 ] = r[S 0 ]
3) ρhϕ2 iρhϕ1 ir(S) = ρhϕ2 ◦ ϕ1 ir, ϕ1 : S → S1 ϕ2 : S1 → S2 , ϕ2 ◦ ϕ1 : S → S2

Примечание. Все кортежи результата однократной выборки удовлетворяют условию выборки. Повторная
проекция не связана с вычеркиванием столбцов. Двукратное переименование атрибутов сводится к однократ-
ному переименованию с функцией переименования, равной композиции исходных функций переименования
(аналог свойства идемпотентности) •
Группа 3. Свойства монотонности:
1) r1 ⊆ r2 ⇒ σhP ir1 ⊆ σhP ir2
2) r1 ⊆ r2 ⇒ r1 [S 0 ] ⊆ r2 [S 0 ]
3) r1 ⊆ r2 ⇒ ρhσir1 ⊆ ρhσir2
Примечание. Все три унарных оператора монотонны •
3.5.2. Бинарные операции

Бинарные теоретико-множественные операции объединения, пересечения и разности применяются
к двум отношениям с одной и той же схемой. Результатом является отношение с той же схемой, что
и у операндов (рис. 3.1):
1) r1 (S) ∪ r2 (S) = {t(S) | t ∈ r1 ∨ t ∈ r2 } – объединение
2) r1 (S) ∩ r2 (S) = {t(S) | t ∈ r1 & t ∈ r2 } – пересечение
3) r1 (S) \ r2 (S) = {t(S) | t ∈ r1 & t 6∈ r2 } – разность
Бинарными операциями типа произведения являются операции декартова произведения и есте-

ственного соединения:
Рис. 3.1.: Объединение, пересечение и разность
1) r1 (S1 ) × r2 (S2 ) = {t(S1 ∪ S2 ) | t[S1 ] ∈ r1 & t[S2 ] ∈ r2 }, S1 ∩ S2 = ∅

2) r1 (S1 ) ./ r2 (S2 ) = {t(S1 ∪ S2 ) | t[S1 ] ∈ r1 & t[S2 ] ∈ r2 }
Примечание. Операция декартова произведения также относится к теоретико-множественным •
Операции возвращают отношение со схемой, равной объединению схем операндов. В декартово
произведение попадают комбинации всевозможных пар кортежей, так как схемы операндов не пере-
секаются. В естественное соединение попадают лишь те кортежи операндов, которые совпадают на
пересечении схем отношений. Такие кортежи называются соединимыми. Декартово произведение
является частным случаем естественного соединения в случае непересекающихся схем отношений.
Если требуется взять декартово произведение отношений с пересекающимися схемами, то пред-
варительно следует переименовать атрибуты хотя бы одного из отношений так, чтобы схемы не
пересекались. Примеры для операций типа произведения приведены на рис. 3.2, 3.3.
Из определений операций следуют следующие свойства.
Группа 1. Соотношения мощностей:
Рис. 3.2.: Декартово произведение
Рис. 3.3.: Естественное соединение
Рис. 3.4.: Свойства бинарных операций
1) |r1 ∪ r2 | ≤ |r1 | + |r2 |
2) |r1 ∩ r2 | ≤ min(|r1 |, |r2 |)
3) |r1 \ r2 | ≤ |r1 |
4) |r1 × r2 | = |r1 | · |r2 |
5) |r1 ./ r2 | ≤ |r1 | · |r2 |
Примечание. При объединении отношений дубликаты кортежей исключаются •

Группа 2 свойств представлена на рис. 3.4. Знаками + и – обозначены случаи, когда опера-
ция обладает и не обладает соответствующим свойством. Для декартова произведения обладание
свойством идемпотентности не формулируется, так как в этом случае декартово произведение не
определено.
3.5.3. Варианты операции соединения
Введем операцию внутреннего соединения по заданному условию соединения P (обозначение опе-
рации ×P ) как производную от операций декартова произведения и выборки:
r1 (S1 ) ×P r2 (S2 ) = σhP i(r1 × r2 ), S1 ∩ S2 = ∅, P ≡ P hS1 ∪ S2 i
Кортежи операндов, попавшие в результат внутреннего соединения, называются соединимыми.

Определим операции левого и правого внешних соединений как результат пополнения внутреннего
соединения несоединимыми кортежами левого и правого операндов соответственно. При пополнении
несоединимый кортеж операнда дополняется на схеме другого операнда null-значениями. Введенные
таким образом операции являются производными. Например, для левого внешнего соединения име-
ем по шагам
(1) r1 (S1 )
(2) r2 (S2 )
(3) r3 (S1 ∪ S2 ) := r1 (S1 ) ×P r2 (S2 )
(4) r4 (S1 ) := r3 (S1 ∪ S2 )[S1 ]
(5) r5 (S1 ) := r1 (S1 ) \ r4 (S1 )
(6) r6 (S2 ) := {∅(S2 )}
(7) r7 (S1 ∪ S2 ) := r5 (S1 ) × r6 (S2 )
(8) r8 (S1 ∪ S2 ) := r3 (S1 ∪ S2 ) ∪ r7 (S1 ∪ S2 )
Здесь (1) – левый операнд, (2) – правый операнд, (3) – их внутреннее соединение, (4) – соеди-
нимые кортежи левого операнда, (5) – несоединимые кортежи левого операнда, (6) – отношение
со схемой S2 , содержащее один кортеж, состоящий из null-значений, (7) – несоединимые корте-
жи левого операнда, дополненные null-значениями на схеме правого операнда, (8) – левое внешнее
соединение.
Таким образом, операции левого и правого внешних соединений по заданному условию соедине-
ния P (обозначения операций L ×P и R ×P соответственно, мнемоника от Left и Right) определяются
следующим образом:
r1 (S1 )L ×P r2 (S2 ) = (r1 ×P r2 ) ∪ [(r1 \ (r1 ×P r2 )[S1 ]) × {∅(S2 )}] = r2 (S2 )R ×P r1 (S1 )
r1 (S1 )R ×P r2 (S2 ) = (r1 ×P r2 ) ∪ [(r2 \ (r1 ×P r2 )[S2 ]) × {∅(S1 )}] = r2 (S2 )L ×P r1 (S1 )
Основным свойством этих операций является возможность восстановления операнда по результату
соединения:
r1 (S1 ) = (r1 L ×P r2 )[S1 ], r2 (S2 ) = (r1 R ×P r2 )[S2 ]
Операция полного внешнего соединения по заданному условию соединения P (обозначение опе-
рации F ×P , мнемоника от Full) определяется как результат пополнения внутреннего соединения
кортежами и левого, и правого операндов:
r1 (S1 ) F ×P r2 (S2 ) = (r1 L ×P r2 ) ∪ (r1 R ×P r2 ) = r2 (S2 ) F ×P r1 (S1 )
Примеры для операций внутреннего и внешних соединений с условием соединения P = (B1 = B2 )
для исходных отношений (рис. 3.5) приведены на рис 3.6, 3.7. Из примера видно, что по результату
полного внешнего соединения операнды могут быть восстановлены, но с точностью до возможного
появления нигде не определенного кортежа.
3.5.4. Производные операции

Введенные варианты операций соединения являлись производными операциями от 8-ми исходных
операций реляционной алгебры. Но и среди исходных операций имеются производные.
Рис. 3.5.: Пример. Операнды соединений
Рис. 3.6.: Пример. Внутреннее и левое соединения

Рис. 3.7.: Пример. Правое и внешнее соединения
Утверждение 1. Операция пересечения является производной от операции разности. Доказатель-

ство то же, что и теории множеств (рис. 3.8).
r1 (S) ∩ r2 (S) = r1 \ (r1 \ r2 ) = r2 \ (r2 \ r1 )
Утверждение 2. Операция естественного соединения является производной операцией от опера-

ции декартова произведения и унарных операций выборки, проекции и переименования атрибутов.
Действительно, сравним приведенные ранее примеры для операций естественного соединения и
внутреннего соединения с условием соединения P = (B1 = B2 ) (рис. 3.9, 3.10).
Из примеров ясно, что операция естественного соединения выражается через операции переиме-
нования атрибутов, проекции и внутреннего соединения с условием соединения специального вида:
r1 (S1 ) ./ r2 (S2 ) = {%hϕ1 ir1 ×E %hϕ2 ir2 }[S1 ∪ S2 ]

Рис. 3.8.: Круги Эйлера
Рис. 3.9.: Пример. Естественное соединение

Рис. 3.10.: Пример. Декартово произведение
Здесь одна из функций переименования является тождественной, а другая переименовывает атрибу-

ты пересечения схем. Условие соединения E задает условие равенства кортежей с использованием
исходных и переименованных имен атрибутов на пересечении схем операндов. Остается подставить
определение операции внутреннего соединения.
3.6. Пример построения выражения реляционной алгебры

Практическое задание. Имеется следующий фрагмент базы данных:
Поставщики (КодПщ, Имя, Город)

Детали (КодД, РодД, ...)
Поставки (КодПщ, КодД)
Написать выражение реляционной алгебры, позволяющее получить наименования поставщиков
(Имя) и место их расположения (Город) в случае, когда поставщики не поставляют каких-либо
деталей с родовым именем (РодД) ’Болт’. При желании можно применить линейную форму пред-
ставления запроса в виде набора операторов присваивания.
Решение. По условию задания в отношении Детали могут быть детали с различными кодами
КодД, но одним и тем же родовым именем РодД.
Применим линейную форму представления запроса в виде набора операторов присваивания.
Образуем естественное соединение всех отношений:
R1 := Поставщики ./ Поставки ./ Детали[КодД, РодД]
Выборка из отношения R1 по условию РодД = ’Болт’ с последующей проекцией на атрибуты

отношения Поставщики позволяет получить список всех Поставщиков, поставляющих хотя бы одну
деталь с родовым именем ’Болт’:
R2 := (σhРодД = ’Болт’iR1)[КодПщ, Имя, Город]
Разность отношений Поставщики и R2 дает искомый список Поставщиков. Остается спроектиро-

вать результат на заданные атрибуты:
R3:= (Поставщики \ R2)[Имя, Город]
Сворачивая цепочку операторов присваивания, получим окончательно искомое выражение реля-

ционной алгебры, реализующее заданный запрос:
(Поставщики \ (σhРодД = ’Болт’i(Поставщики ./ Поставки ./ Детали[КодД, РодД]))[КодПщ,
Имя, Город])[Имя, Город]
3.7. Понятие базовых и виртуальных отношений

На наиболее абстрактном уровне база данных – это множество отношений D. Замыкая D (обо-
значение D+ ) относительно введенных ранее операций реляционной алгебры, получим множество
всех отношений (включая сами отношения D), которые можно получить из D, применяя введенные
операции. Тем самым получаем реляционную алгебру над множеством отношений базы данных, то
есть множество (называемое носителем) с набором операций (называемым сигнатурой):
hD+ ; σ, π, ρ, ∪, ∩, \, ×, ./i
Таким образом, исходя из отношений D, хранимых в базе данных, можно получить в результате
запроса отношение не только из D, но и из D+ \ D. Но в базе данных хранятся отношения двух
видов – базовые (обозначим D0 ) и виртуальные (обозначим D1 ). (Ясно, что D0 ∩ D1 = ∅, D0 ∪
D1 = D). Базовые отношения содержат независимые данные и не могут быть выражены через
другие отношения базы данных. В СУБД базовые отношения обычно называются таблицами (table).
Виртуальные отношения выражаются в конечном итоге через базовые и (на логическом уровне)
хранятся в базе данных в виде выражений реляционной алгебры. В СУБД виртуальные отношения
обычно называются представлениями (view). Реально они реализуются на языке SQL.
3.8. Понятие полноты реляционной алгебры
Сигнатура реляционной алгебры, так, как она была введена выше, содержала операции, производные
от других операций, и в этом смысле была избыточной. Однако на практике производные операции
полезны, так как позволяют в более компактной форме представлять выражения.
Важен другой вопрос: а достаточно ли этих операций для выражения практически значимых за-
просов? Действительно, если из сигнатуры алгебры исключить операции типа произведения (× и ./),
то в результате запроса, формулируемого в виде выражения реляционной алгебры над отношения-
ми базы данных с оставшимися операциями (σ, π, ρ, ∪, ∩, \) могут быть получены результирующие
отношения со схемами, с точностью до переименования атрибутов являющимися подмножествами
или совпадающими со схемами исходных отношений. Такого ограниченного набора операций для
практики явно не достаточно. Возникает вопрос о полноте набора операций реляционной алгебры.
Если проанализировать определения операций реляционной алгебры, то можно заметить, что все
они с точностью до обозначений определяются в виде выражений вида «множество кортежей над
такой-то схемой, удовлетворяющих такому-то предикату»:
{t(S) | f (t)}
Здесь f – некоторый предикат над переменным кортежем t. Это выражение обозначает отношение
r(S), которое состоит из всех кортежей t(S), для которых f (t) истинно.
Можно задаться вопросом, не будут ли получены новые запросы-отношения из базы данных, если
в качестве предиката f в таких выражениях использовать произвольный предикат, включающий
логические связки ∀ (квантор общности, или всеобщности), ∃ (квантор существования) и ¬, &, ∨
(отрицание, конъюнкция, дизъюнкция)? (Такие выражения с произвольным предикатом f , выра-
женным в элементарных высказываниях, использованных при определении операций реляционной
алгебры, называются выражениями исчисления кортежей.) Можно показать, что нет.
Таким образом, полнота реляционной алгебры понимается в том смысле, что система запросов,
построенная на основе реляционной алгебры (запрос – это выражение реляционной алгебры над
множеством отношений базы данных D), приводит к тому же множеству допустимых запросов D+ ,
что и система запросов, построенная на основе исчисления кортежей (запрос – это выражение
исчисления кортежей над D).
3.9. Формирование запросов на языке SQL

Оператор select – один из наиболее важных и самых распространенных операторов SQL. Он поз-
воляет производить выборки данных из таблиц и преобразовывать к нужному виду полученные
результаты. Будучи очень мощным, он способен выполнять действия, эквивалентные выражениям
реляционной алгебры, причем в пределах единственного выполняемого оператора. При его помощи
можно реализовать сложные и громоздкие условия отбора данных из различных отношений.
Оператор select – средство, которое полностью абстрагировано от вопросов представления дан-
ных, что помогает сконцентрировать внимание на проблемах доступа к данным. Примеры его ис-
пользования наглядно демонстрируют один из основополагающих принципов промышленных СУБД:
средства хранения данных и доступа к ним отделены от средств представления данных. Операции
над данными производятся в масштабе наборов данных, а не отдельных записей.
Оператор select реализует вычисление выражений как реляционной, так и псевдореляционной
алгебры. В последнем случае в результирующем отношении могут появляться дублирующиеся кор-
тежи. Потенциально опасными с точки зрения возникновения дубликатов кортежей являются опера-
ции проекции и объединения. Поэтому в этих операциях вводятся специальные опции, управляющие
режимом исключения дубликатов.
Базовая структура оператора select включает следующие фразы и достаточно проста:
select выбрать такие-то атрибуты
from из таких-то отношений
where с таким-то условием выборки кортежей
Далее рассматривается реализация операций реляционной алгебры с помощью оператора select.
В общем случае в одном операторе select может быть определено целое выражение реляционной
алгебры, а не только одна отдельная операция.
3.9.1. Реализация операций реляционной алгебры

Операция выборки
Операция выборки и реализуется оператором
select *
from имя_отношения
where условие_выборки
Здесь звездочка означает выбор всех атрибутов из схемы отношения. Условие выборки записыва-
ется в виде логического выражения со связками not, and, or. Ссылки на атрибуты производятся по
их именам. Например, в следующем запросе из отношения Успеваемость выбираются те кортежи,
которые относятся к номеру зачетной книжки 100 и семестру 6:
Успеваемость(NЗК, Семестр, Предмет, Оценка, Дата)
select *
from УспеваемостьОперации левого, правого и полного внешних соединений
where NЗК = 100 and Семестр = 6
Условие выборки может содержать предикаты в следующих формах:
1. выражение {< | <= | = | < > | >= | >} выражение;
2. выражение [not] between выражение1 and выражение2;
3. выражение is [not] null;
4. строковое_выражение [not] like шаблон [escape ‘escape_символ’];
5. выражение [not] in (выражение,..);
6. выражение [not] in (подзапрос);
7. выражение {< | <= | = | < > | >= | >} {all | any} (подзапрос);
8. exists (подзапрос).
1-я форма предиката применяется для выражений любого типа, за исключением BLOB – крупных
двоичных объектов.
2-я форма предиката с оператором [not] between (между) является сокращением следующего
условия:
[not] (выражение1 <= выражение and выражение <= выражение2)
3-я форма предиката предназначена для тестирования null-значений.
4-я форма предиката с оператором like (похожий) позволяет отбирать строки по шаблону с ис-
пользованием следующих символов замещения.
Символ 1. % (процент) – любая строка из нуля или более символов. Например, конструкция like
‘%t%’ соответствует любым строкам, содержащим хотя бы один символ ‘t’.
Символ 2. _ (подчеркивание) – любой одиночный символ. Например, конструкция like ‘a_’ соот-
ветствует двухсимвольным строкам, начинающимся с символа ‘a’.
Символ 3. [символ-символ], либо [символ. . . ] – любой одиночный символ, содержащийся в ука-
занном диапазоне или последовательности символов. Например, конструкция like ‘[b-d]at’, как и like
‘[bcd]at’, соответствует строкам ‘bat’, ‘cat’, ‘dat’. Конструкции like ‘[ [ ]’ соответствует символ ‘[’.
Символ 4. [ b символ-символ], либо [ b символ. . . ] – любой одиночный символ, не содержащийся
в указанном диапазоне или последовательности символов. Например, конструкция like ‘[ b 0-9]%’
соответствует любым строкам, первый символ которых не является цифрой.
Если символ замещения ‘%’ или ‘_’ необходимо сам по себе включить в шаблон, то следует или
заключить его в квадратные скобки, или определить escape-символ (то есть символ перехода) и
использовать его перед символом замещения. Например, следующие конструкции соответствуют
двухсимвольным строкам, начинающимся с символа подчеркивания:
like ’[_]_’
like ’/_ _’ escape ’/’
like ’!_ _’ escape ’!’
5-я форма предиката соответствует предикату принадлежности элемента списку.
6-я форма предиката отличается от 5-й тем, что вместо списка задается подзапрос, возвращающий
один столбец (но не одну строку, так как требуется однотипность данных). Например, следующий
запрос выводит список студентов, получивших к моменту запроса хотя бы одну оценку отлично:
Студенты(NЗК, Ф, И, О)
Сессия (NЗК, Предмет, Оценка)
select *
from Студенты
where NЗК in (select NЗК from Сессия where Оценка = 5)
Здесь в результирующем запросе поля из таблицы Сессия не используются и поэтому можно
использовать подзапрос, а не соединение.
7-я форма предиката позволяет сравнивать выражения со всеми (all) или некоторыми (any) значе-
ниями, возвращаемыми в подзапросе. В частности, следующие предикаты эквивалентны:
выражение in (подзапрос)
выражение = any (подзапрос)
8-я форма предиката проверяет подзапрос на пустоту. С помощью этого предиката последний
пример может быть записан в виде
Студенты(NЗК, Ф, И, О)
Сессия (NЗК, Предмет, Оценка)
select *
from Студенты
where exists(select * from Сессия where NЗК = Студенты.NЗК and Оценка = 5)
Здесь подзапрос является примером так называемого коррелированного подзапроса, поскольку
условие выборки в подзапросе зависит от текущей анализируемой записи внешнего запроса.
Указывать конкретные столбцы в подзапросе предиката exists смысла не имеет.
Операция проекции
Операция проекции реализуется оператором
select [distinct] список_имен_атрибутов
from имя_отношения
Здесь необязательная опция distinct задает режим исключения дубликатов кортежей. Если ре-
зультат проекции гарантированно не содержит дубликатов кортежей или дубликаты допустимы, то
из соображений производительности опцию distinct лучше не указывать, например

select NЗК, Семестр, Предмет, Оценка
from Успеваемость
Здесь первые три возвращаемые атрибута образуют ключ отношения. Поэтому опция distinct ста-
новится излишней. Запрос возвращает исходное отношение Успеваемость, в котором опущен атрибут
Дата.
Операция проекции
Операция переименования атрибутов заключается в добавлении ключевого слова as и нового
имени атрибута после исходного имени атрибута в списке имен атрибутов фразы select, например
select NЗК as [№ зачетки],

Семестр,
Предмет as МнемоП,
Оценка,
Дата
from Успеваемость
Имена атрибутов, содержащие не буквенно-цифровые символы, в частности пробелы, заключают-

ся в квадратные скобки (в некоторых СУБД).
Операция объединения
Операция объединения реализуется с помощью операции union, применяемой к базовым операторам
select:
select список_имен_атрибутов_отношения_1
from имя_отношения_1
union [all]
select список_имен_атрибутов_отношения_2
from имя_отношения_2
Списки имен атрибутов объединяемых отношений должны ссылаться на атрибуты совместимых

типов и быть перечислены в согласованном порядке. Имена атрибутов в отношениях могут быть
различными. Результирующему отношению приписываются имена атрибутов, указанные в первом
операторе select. Операция объединения может иметь форму union all с опцией all (все). В этом
случае из результирующего отношения дубликаты кортежей не удаляются (, что является более
предпочтительным с точки зрения производительности).
Операция пересечения
Операция пересечения проще всего реализуется с использованием ключей отношений:
R1(Ключ, A, B, C), R2(Ключ, A, B, C)
select *
from R1
where Ключ in (select Ключ from R2)
Здесь R1 и R2 – имена отношений. Оператор select в скобках является так называемым подза-
просом. Он возвращает список значений ключа отношения R2. Согласно условию выборки в резуль-
тирующее отношение выбираются те кортежи отношения R1, ключ которых содержится в списке
ключей отношения R2. Имена ключей отношений могли бы быть и различными. Сами отношения
могли бы иметь различные наборы дополнительных атрибутов.
Операция разности
Операция разности реализуется аналогично операции пересечения с заменой ключевого слова in
на not in:
R1(Ключ, A, B, C), R2(Ключ, A, B, C)
select *
from R1
where Ключ not in (select Ключ from R2)
В результирующее отношение выбираются те кортежи отношения R1, ключ которых не содержит-

ся в списке ключей отношения R2.
Операция декартова произведения

Операция декартова произведения реализуется с помощью операции перекрестного соединения
cross join:
select *
from R1 cross join R2
Здесь предполагается, что отношения не имеют совпадающих имен атрибутов. В противном случае
потребовалось бы с помощью переименования атрибутов разрешить коллизию имен, например,
R1(A, B), R2(B, C)

select A,
R1.B as B1,
R2.B as B2,
C
from R1 cross join R2
Здесь ссылки на атрибуты B отношений R1 и R2 производятся по их уточненным именам R1.B и

R2.B соответственно.
Операция естественного соединения

Операция естественного соединения является частным случаем операции внутреннего соединения
inner join по условию равенства кортежей на пересечении схем отношений, например,
R1(A, B, C), R2(B, C, D)
select A, R1.B, R1.C, D

from R1 inner join R2 on R1.B = R2.B and R1.C = R2.C
Здесь ссылаться на общие атрибуты B и C просто по именам нельзя, так как будет неясно, к како-
му отношению они относятся. Использованная формулировка условия соединения (после ключевого
слова on) предполагает, что общие атрибуты соединяемых отношений null-значений не допускают.
Операции левого, правого и полного внешних соединений реализуются аналогичным образом с
заменой ключевого слова inner на left outer, right outer и full outer соответственно.
3.9.2. Пример использования подзапросов
Предметы(КодП, ИмяП)
Студенты(NЗК, Ф, И, О, ...)
Сессия (КодП, NЗК, Оценка)
Сформировать SQL-запрос, возвращающий ведомость с указанием номера зачетной книжки (NЗК),

фамилии и инициалов студента (Фамилия И.О.) и оценки для предмета с наименованием (ИмяП)
’БД’. Предполагается, что атрибуты Ф, И, О студента не допускают null-значений, не являются
пустыми и не содержат начальных пробелов. Атрибут ИмяП является кандидатным ключом, то есть
наименования предметов являются уникальными.
Решение. Используем функцию RTrim(строка), которая возвращает строку без концевых пробе-
лов, и функцию Left(строка, число) которая возвращает заданное число символов левой части стро-
ки.
select Студенты.NЗК,
RTrim(Ф) + ’ ’ + Left(И,1) + ’.’ + Left(О,1) + ’.’ as ФИО,
Оценка
from Студенты inner join
(
select NЗК, Оценка
from Сессия
where КодП = (select КодП from Предметы where ИмяП = ’БД’)
) as СессияБД
on Студенты.NЗК = СессияБД.NЗК
Внутренний подзапрос (select КодП from Предметы where ИмяП = ’БД’) может возвра-
щать не более одного значения, так как атрибут ИмяП является кандидатным ключом отношения
Предметы. В запросе, которому присвоен псевдоним СессияБД, этот подзапрос позволяет выделить
из отношения Сессия те кортежи, которые относятся к рассматриваемому предмету. Внутреннее со-
единение отношения Студенты с запросом СессияБД по условию равенства номера зачетной книжки
добавляет к отношению Студенты оценку. Так как атрибуты Ф, И, О студента не допускают null-
значений и не являются пустыми, то формула вычисления возвращаемого атрибута ФИО не требует
соответствующих проверок и упрощается.
3.9.3. Группирующие запросы

В SQL имеется ряд специальных функций, называемых функциями агрегирования и используемых
при формировании списка выбираемых атрибутов в операторе select. Основными из функций явля-
ются
1. count(*)
2. { count | sum | avg | min | max} ([all | distinct] выражение_над_столбцами)
Функции применяются к группам строк и возвращают для каждой из групп единственное значе-
ние.
Функция count(*) возвращает общее количество кортежей в группе. Остальные функции приме-
няются к выражению над столбцами, то есть к столбцу значений, полученных из группы строк
при вычислении выражения для каждой из строк. Null-значения в столбце значений игнорируются.
Опция all действует по умолчанию и означает учет дубликатов строк. Если указана опция distinct,
то дубликаты строк игнорируются. Эти опции значимы для функций подсчета числа строк, сумми-
рования и осреднения, но не для функций экстремальных значений.
Результат осреднения целочисленных значений округляется до целого. Поэтому в этом случае
может потребоваться использование функции явного преобразования типов. Приведем пример вы-
числения средней оценки по всем предметам в целом:
Сессия(NЗК, Ф, И, О, Предмет, Оценка), 3 ≤ Оценка≤ 5

select avg(convert(decimal(5, 2), Оценка)) as ОценкаAvg,
count(*) as Сдач
from Сессия
Для определения средней оценки и числа сдач по конкретному предмету пример можно дополнить
фразой
where Предмет = ’БД’
Вложение функций агрегирования не допускается. Однако из них можно составлять любые выра-
жения.
Фраза group by (группировать по) обычно используется в сочетании с функциями агрегирования.
Она следует за фразой where в операторе select:
select выбрать такие-то атрибуты
from из таких-то отношений
where с таким-то условием выборки кортежей
group by [all] выражение\_группировки,..
having с таким-то условием выборки групп
Выражение группировки может быть именем столбца или в общем случае выражением над столб-
цами, не содержащим функций агрегирования. После того, как список выражений группировки
определен, можно определить столбцы, выбираемые в операторе select. Каждый выбираемый стол-
бец должен быть
1) либо выражением группировки, указанным во фразе group by,
2) либо выражением с некоторой комбинацией функций агрегирования.

Работу оператора select с фразой группировки можно представить следующим образом.
1. Выбираются строки, соответствующие условию поиска во фразе where.
2. Для каждой из строк вычисляются выражения группировки, после чего создается таблица,
состоящая из уникальных сочетаний значений этих выражений. Тем самым создается таблица групп.
3. Затем таблица групп расширяется выбираемыми столбцами, которые не попали в список выра-
жений группировки и для которых, следовательно, должны быть заданы агрегирующие выражения.
4. Если задано ключевое слово all, то шаги 1 и 2 меняются местами. То есть таблица групп
создается для всевозможных групп безотносительно к условию поиска во фразе where. Однако при
расширении таблицы групп при вычислении агрегирующих выражений условие поиска учитывается,
так что дополнительные строки таблицы групп будут дополнены null-значениями.
Приведем пример вычисления средних оценок с группировкой по предметам:

select Предмет,
avg(covert(decimal(5, 2), Оценка)) as ОценкаAvg,
count(*) as Сдач
from Сессия
group by Предмет
Фраза having ограничивает строки, возвращаемые фразой group by, таким же образом, как фраза
where ограничивает строки, возвращаемые фразой select. В один оператор select могут быть вклю-
чены и фраза where, и фраза having. При этом фраза where применяется до операции группировки,
а фраза having после нее.
Синтаксис фразы having идентичен синтаксису фразы where за исключением того, что фраза
having может включать функции агрегирования.
В следующем примере данные о суммарном балле выдаются для тех студентов, которые сдали 3
экзамена:
select NЗК, sum(Оценка) as БаллSum

from Сессия
group by keyСтудент
having count(*) = 3
Для повышения производительности во фразу having имеет смысл включать лишь те условия, ко-
торые действительно требуют предварительные вычисления сгруппированных данных. В противном
случае условия следует размещать во фразе where.
3.9.4. Упорядочение результатов

В общем случае кортежи в результирующем SQL-запросе никак не упорядочены. Однако их можно
требуемым образом отсортировать, для чего в оператор select помещается фраза order by, которая
сортирует данные выходного набора в заданной последовательности. Сортировка может выполняться
по нескольким полям, в этом случае они перечисляются за ключевым словом order by через запятую.
Способ сортировки задается ключевым словом, указываемым в рамках параметра order by следом
за названием поля, по которому выполняется сортировка. По умолчанию реализуется сортировка
по возрастанию. Явно она задается ключевым словом asc. Для выполнения сортировки в обратной
последовательности необходимо после имени поля, по которому она выполняется, указать ключевое
слово desc. Фраза order by позволяет упорядочить выбранные записи в порядке возрастания или
убывания значений любого атрибута или комбинации атрибутов, независимо от того, присутствуют
эти столбцы в таблице результата или нет. Фраза order by всегда должна быть последним элементом
в операторе select.
Общий вид фразы сортировки:
order by {выражение_сортировки [asc | desc]},..
Выражение сортировки – это обычно имя атрибута или выражение над именами. Выражение сор-
тировки может ссылаться на атрибуты, отсутствующие в списке выбираемых атрибутов. Выражение
сортировки не может ссылаться на столбцы, содержащие крупные двоичные объекты BLOB, по-
скольку для них не определены операции сравнения. Null-значение рассматривается как наименьшее
значение. Если задано несколько выражений сортировки, то данные сортируются в лексикографиче-
ском порядке.
3.10. Вопросы для самоконтроля

Отсутствующие данные
• В чем заключается проблема отсутствующих данных? Как она решается в базах данных?
Пустые значения
• Что означает термин «пустое значение»? Укажите пустые значения для числовых типов данных,
логического, строк символов постоянной и переменной длины.
• Могут ли в СУБД вводиться специальные константы пустых значений?
Неопределенные значения
• Какие интерпретации допускают null-значения? Приведите пример.
• Как формулируются правила вычисления выражений с null-значениями?
• Почему правила выполнения операций конъюнкции и дизъюнкции являются исключением из

общего правила?
• Как можно сформулировать правила интерпретации null-значений в контексте различных опе-

раций?
• Как влияют правила вычисления выражений с null-значениями на операции арифметические,

логические, строковые, сравнения?
• Как проверить значение переменной или выражения на null-значение?
• Как интерпретируется по умолчанию неопределенное условие в условных операторах и опера-

торах цикла?
• Как null-значения влияют на проверку условий в ограничениях целостности?

• Как переопределить правила вычислений с null-значениями, действующими по умолчанию?
• Как ввести null-значение с клавиатуры?
Реляционные объекты данных
• Какие требования предъявляются к табличной форме представления отношений?
• В чем различие понятий реляционной и псевдореляционной алгебры?
• Дайте определение домена атрибута и атрибута. Какими способами можно задать домен?
• Дайте определение схемы отношения, кортежа и отношения. Что такое степень отношения?
• Какая терминология используется для кортежей в зависимости от области их определения?
• Почему формы изображения неопределенных значений кортежа в текстовой и табличной фор-

мах различаются?
• Дайте определение понятий отношения, схемы базы данных и базы данных.
Операции реляционной алгебры
• Дайте определения операций выборки, проекции и переименования атрибутов.
• Укажите основные свойства операций выборки, проекции и переименования атрибутов.
• Дайте определения бинарных теоретико-множественных операций объединения, пересечения и

разности.
• Дайте определения бинарных операций декартова произведения и естественного соединения.
Какие кортежи называются соединимыми?
• Какими свойствами обладают бинарные операции?
• Как определяются операции левого, правого и полного внешних соединений?
• Каким образом операция естественного соединения выражается через другие операции реля-
ционной алгебры?
Пример построения выражения реляционной алгебры
• Задание. Имеется следующий фрагмент базы данных:
Поставщики(КодПщ, Имя, Город)

Детали (КодД, РодД, Цвет, ВесКг)
Поставки (КодПщ, КодД, Штук)
Поставщики характеризуются уникальным кодом (КодПщ), уникальным наименованием (Имя)

и городом размещения (Город). Поставляемые детали определяются уникальным кодом (КодД),
родовым наименованием (РодД), которое может и не быть уникальным, а также атрибутами
Цвет (’R’ – красный, ’G’ – зеленый, ’B’ – голубой) и ВесКг. Напишите выражение реляционной
алгебры, реализующее следующий запрос. (При желании можно применить линейную форму
представления запроса в виде набора операторов присваивания.)
Вариант 1. Получить имена поставщиков, которые поставляют хотя бы одну деталь с родовым
наименованием ’Болт’.
Вариант 2. Получить имена поставщиков, которые поставляют хотя бы одну красную деталь.
Вариант 3. Получить имена поставщиков, которые поставляют хотя бы одну зеленую деталь
весом более 1 кг.
Вариант 4. Получить имена поставщиков, которые не поставляют никаких деталей с родовым
наименованием ’Болт’.
Решение: Пример выполнения аналогичного задания приведен в основном тексте.
Понятие базовых и виртуальных отношений
• В чем различие понятий базовых и виртуальных отношений в терминах реляционной алгебры?
Понятие полноты реляционной алгебры
• В чем смысл понятии полноты реляционной алгебры?
Формирование запросов на языке SQL
• Какие операции реляционной алгебры являются потенциально опасными с точки зрения воз-
никновения дубликатов кортежей и почему?
• Как на языке SQL реализуется операция выборки? Предикаты в каких формах может содержать
условие выборки?
• Как на языке SQL реализуется операция проекции? Как задается режим исключения дублика-
тов кортежей?
• Как на языке SQL реализуется операция переименования атрибутов?

• Как на языке SQL реализуется операция объединения? Как задается режим исключения дуб-
ликатов кортежей?
• Как на языке SQL реализуются операции пересечения и разности?
• Как на языке SQL реализуется операция декартова произведения? Как разрешается коллизия
имен?
• Каким образом операция естественного соединения выражается через операцию внутреннего

соединения?
• Что такое подзапрос?
• Для чего предназначены группирующие запросы?
• Как реализуется упорядочивание результатов в SQL-запросах?

Часть III.
Модуль 2
4. Базовые и виртуальные отношения
4.1. Типы данных
Тип данных задает множество значений, объединенных определенной совокупностью допустимых
операций. От типа данных зависит размер выделяемой для значений памяти.
4.1.1. Базовые типы данных

Базовыми типами данных являются следующие.
1. Числовые
• integer – целый,
• перечислимые типы,
• float(n), real – вещественный,
• decimal(n[, d]) – десятичный с фиксированной точкой,
• money, или currency – денежный.
2. Логический
• logical.
3. Строковые
• bit(n), varbit(n) – строки бит фиксированной или переменной длины,
• char(n), varchar(n) – строки символов фиксированной или переменной длины.
4. Даты и времени
• date – дата,
• time – время суток,
• datetime – дата-время.
5. Идентификационные
• counter(x0 , 4x) – счетчик.
6. Крупные двоичные объекты
• BLOB.
Целочисленный тип данных integer может иметь варианты, различающиеся по диапазону представ-
ления данных. Например, вариантами 4-байтового типа integer могут быть 8- и 2-байтовые типы
bigint и smallint соответственно.
Примечание. Аналогичные варианты могут иметь и другие типы данных – денежный, даты и времени,
идентификационный •
Тип, в объявлении которого указывается набор символических имен, называется перечислимым.
В качесве примера перечислимого типа можно назвать множество названий дней недели (пн, вт, ср,
чт, пт, сб, вс). Значения перечислимых типов представляются посредством целочисленных кодов с
использованием требуемого количества байтов.
Тип вещественных чисел float(n), real применяется для описания данных, которые нельзя точ-
но представить в компьютере. Вещественные числа (числа с плавающей точкой) представляются в
научной нотации, при которой число записывается с помощью мантиссы, умноженной на опреде-
ленную степень десяти (порядок), например: 10Е3, +5.2Е6, -0.2Е-4. Параметр n (точность) задает
количество хранимых бит мантиссы. Точность типа real зависит от конкретной реализации.
Тип decimal(n[, d]) – десятичный с фиксированной точкой с точностью в n десятичных цифр, из
которых d (при d > 0) – после десятичной точки, а при d < 0 – до десятичной точки (по умолчанию
d = 0). Например: ± 123.45 (d = 2 > 0, n = 5); ± 1234500. (d = - 2 < 0, n = 5).
Денежный тип money (в некоторых СУБД обозначаемый как currency) представляет числа в
денежном формате в очень широком диапазоне с фиксированной точностью от денежной единицы
(например, .0001).
Логический тип данных logical в некоторых СУБД подменяется типом bit(1).
Битовый тип данных используется для определения строк бит, то есть последовательностей дво-
ичных цифр, каждая из которых может иметь значение либо 0, либо 1. Типы bit(n), varbit(n)
соответствуют строкам бит фиксированной длины n и переменной длины, не превышающей n бит.
Последовательности бит обычно делятся на группы по 8 бит в каждой, которые упаковываются в
байты. Если n не делится на 8 нацело, неиспользуемые биты последнего байта игнорируются.
Строки символов состоят из последовательности символов, входящих в определенный создателя-
ми СУБД набор символов. Поскольку наборы символов являются специфическими для различных
диалектов языка SQL, перечень символов, которые могут входить в состав значений данных сим-
вольного типа, также зависит от конкретной реализации. Чаще всего используются наборы символов
ASCII и EBCDIC. Типы char(n), varchar(n) соответствуют строкам символов фиксированной длины
n и переменной длины, не превышающей n символов.
Поле, соответствующее типу char(n), представляет собой массив из n байтов в случае, если симво-
лы относятся к одному из традиционных 8-битовых наборов данных (скажем, ACSII или EBCDIC).
Символ Unicode представляется 16 битами, или двумя байтами. Если значением атрибута оказы-
вается более короткая строка, в каждую «лишнюю» позицию заносится специальный незначащий
символ, 8-битовый код которого не совпадает с кодом любого другого символа из числа тех, которые
разрешено включать в строки SQL.
SQL-тип varchar(n) на самом деле представляет поле фиксированной длины, хотя размер содер-
жимого может варьироваться. Существуют два общих способа представления строк типа varchar.
Способ 1 : длина плюс содержимое. Система организует массив из n+1 байт. В первом байте в
виде 8-битового целого числа сохраняется количество байтов в строке. Длина строки не может
превысить n, а величина n, в свою очередь, должна быть не больше значения 255 – в противном
случае длину строки нельзя представить с помощью одного байта. Второй и последующие
байты отображают символы содержимого строки. Если строка состоит их меньшего количества
символов, оставшиеся байты массива не могут интерпретироваться как часть содержимого и
игнорируются.
Способ 2 : строки, завершаемые незначащим символом. В этом случае также формируется массив
из n+1 байт. Массив заполняется символами строки, а в элемент, следующий за послед-
ним байтом содержимого строки, заносится незначащий символ. Как и в предыдущем случае,
оставшиеся байты массива игнорируются.
Типы date, time, datetime представляют значения дат и времени. Тип данных date используется
для хранения календарных дат, включающих поля год-месяц-день. Тип данных time – для хранения
отметок времени, включающих поля часы-минуты-секунды. Тип данных datetime – для совместного
хранения даты и времени.
Значения дат обычно представляются в виде символьных строк постоянной длины и принципи-
ально ничем не отличаются от обычных строк символов подобного формата. Временные величины
допускают аналогичное представление. В стандарте SQL, однако, предусмотрен и тип time, позволя-
ющий сохранять значения времени с точностью до дробных долей секунды. Формат значений time
относится к категории строк произвольной длины. Таким образом, имеются два альтернативных
средства описания значений времени. Во-первых, система способна ограничить точность представ-
ления временных величин, как если бы они относились к типу varchar(n), где n – максимально
допустимая длина строки с описанием значения времени. Во-вторых, временные значения могут
сохраняться и использоваться в виде строк действительно переменной длины.
Значения данных типа счетчика counter(x0 , 4x) являются целочисленными, но не задаются, как
для других базовых типов, а генерируются системой. Тип счетчика может быть задан лишь при
определении таблицы, причем лишь для одного столбца. В программном коде тип счетчика исполь-
зовать нельзя. Значения данных типа счетчика генерируются автоматически при вставке строк в
таблицы. Параметры x0 и 4x задают начальное значение и шаг приращения. Генерация проводится
без повторений, так что счетчик всегда будет уникально идентифицировать каждую строку. На-
пример, пусть в таблицу введены 4 строки. Удаление строк 2, 4 и добавление еще одной строки
приведет к следующему преобразованию исходной таблицы (рис. 4.1).
Изменить значение счетчика или объявить несколько счетчиков в одной таблице СУБД не позво-
лит. Уникальных значений 4-байтового счетчика при скорости генерации 1 знач/сек хватит на более
чем 100 лет:
Рис. 4.1.: Модификация таблицы со счетчиком
1 год ≤ 366 * 24 * 60 * 60 сек < 225 сек

1 сек > 2−25 год
24∗8 знач / (1 знач/сек) = 232 сек > 27 год = 128 лет > 100 лет
Счетчик обычно используется как суррогатный, то есть искусственный, первичный ключ табли-
цы.
BLOB – это обобщенное название типов данных, предназначенных для хранения крупных двоич-
ных объектов (Binary Large OBjects). Такими объектами могут быть графические изображения в
различных форматах, видеозаписи, звук, сигналы радаров и т.п. Для данных типа BLOB понятие
сравнения не определено.
4.1.2. Типы данных, определяемые пользователем
Далеко не все современные СУБД в полной мере поддерживают типы данных, определяемые
пользователем. СУБД Ingres включает такой механизм. Эта система предоставляет программи-
сту возможность определять собственные типы данных и операции над ними и использовать их
в операторах SQL. Для определения нового типа данных необходимо написать и откомпилировать
функции на языке СИ, после чего собрать редактором связей некоторые модули Ingres. Введение
новых типов данных является, по сути, изменением ядра СУБД. Важно и то, что в Ingres типы
данных, определяемые пользователем, могут быть параметризованными.
Определение нового типа данных сводится к указанию его имени, размера и идентификатора в
глобальной структуре, описывающей типы данных. Чтобы с новым типом данных можно было ис-
пользовать функции, которые реализуют стандартные операции (сравнение, преобразование в раз-
личные форматы, и т.д.), программист должен разработать их самостоятельно (интерфейс функций
предопределен). Указатели на эти функции являются элементами глобальной структуры. Как только
новый тип данных определен, то все операции выполняются над ним, как над данными стандартно-
го типа. Разрешение пользователю создавать собственные типы данных – один из шагов развития
реляционных СУБД в направлении объектно-реляционных систем.
Многие СУБД позволяют пользователю создавать пользовательские подтипы базовых типов (под-
типы данных, определяемые пользователем). В записи на псевдокоде пользовательский подтип
создается с помощью оператора
create subtype имя_подтипа
type имя_базового_типа
as ограничение
Ограничение подтипа записывается как условие, зависящее от имени определяемого подтипа, на-
пример:
create subtype ПочтовыйИндекс
type decimal(6, 0)
as ПочтовыйИндекс > 0
В общем случае ограничение подтипа может содержать логические связки not, and, or и быть вы-
ражением произвольной сложности. Определенные таким образом подтипы могут использоваться
наряду с другими базовыми типами и в программном коде, и при определении типа данных в столб-
цах таблиц. В визуальной среде разработки базы данных они появляются в списках допустимых
типов вместе с другими базовыми типами.
Пользовательский подтип данных может быть удален с помощью оператора
drop subtype имя_подтипа
Пользовательские подтипы данных рекомендуется вводить для подтипов достаточно общего назна-
чения. В противном случае лучше ограничение ввести при объявлении соответствующего атрибута
таблицы.
4.2. Первичные и кандидатные ключи

При объявлении схемы базового отношения могут быть заданы объявления нескольких ключей.
Ключ схемы базового отношения – это подсхема, состоящая из одного или нескольких атрибутов,
для которых после объявления в схеме базового отношения СУБД будет автоматически поддержи-
вать условие уникальности значений в кортежах отношения. Это означает, что после выполнения
операции вставки, обновления или удаления кортежа (обобщающий термин для этих операций –
«модификация отношения») условие уникальности не нарушится, поскольку СУБД этого не допу-
стит. (Впрочем, при удалении кортежа условие уникальности нарушиться не может.)
Но как выбрать ключ? Например, в списке учебной группы заведомо уникальными должны быть
значения пары атрибутов – номер зачетной книжки и фамилия студента. Однако, если эту пару (№
ЗК, Ф) объявить в качестве ключа, то тогда в список учебной группы окажется возможным ввести
два кортежа с одним и тем же № ЗК и разными Ф. То есть окажется, что в группе появились два
студента с одним и тем же номером зачетной книжки, чего быть не должно. (Заметим, что обратная
ситуация – разные № ЗК и одинаковые Ф – вполне возможна и допустима.) Следовательно, объявляя
ключ, следует позаботиться о его неизбыточности. Это означает, что ни для какого строгого
подмножества ключа требование уникальности не предъявляется и не должно предъявляться. То
есть в рассматриваемом примере ключом следовало бы объявить № ЗК. Требование неизбыточности
является семантическим, и проконтролировать его СУБД, естественно, не в состоянии.
Ключ, состоящий из одного атрибута, называется простым. Простым ключом является № ЗК в
экзаменационной ведомости по конкретному предмету. Ключ, состоящий из двух или более атри-
бутов, называется составным. Составным ключом является № корпуса и № аудитории в списке
учебных аудиторий.
Суперключом называется надмножество ключа. Суперключ может содержать дополнительные ат-
рибуты, которые не обязательны для уникальной идентификации кортежа в отношении. Суперключ
обладает свойством уникальности, но не обязательно обладает свойством неизбыточности. Если
суперключ неизбыточен, то он ключ.
При объявлении схемы базового отношения один из ключей может быть объявлен в качестве пер-
вичного. Другие ключи называются кандидатными. Различие между первичным и кандидатными
ключами заключается в том, что
1) допустимо объявление не более одного первичного ключа, тогда как кандидатных ключей
может быть несколько;
2) атрибуты первичного ключа не могут принимать null-значений, тогда как для кандидатных
ключей это ограничение не обязано накладываться (но может).
При выборе первичного ключа следует отдавать предпочтение простым ключам или ключам, состав-
ленным из минимального числа атрибутов. Нецелесообразно также использовать ключи с длинными
текстовыми значениями, как, например (для блюда) – «Заяц в сметане с картофельными крокетами
и салатом из красной капусты». Но как же сослаться на такое блюдо в базе данных ресторана?
Просто нужно ввести словарь-справочник c двумя атрибутами, первый из которых – суррогатный
ключ типа счетчика, а второй – наименование, объявленное кандидатным ключом.
4.3. Индексы
Создание ключей (в развитых СУБД автоматически) связано с созданием индексов.
Простой или составной индекс для подсхемы из одного или нескольких атрибутов – это систем-
ная структура данных, в которой (по крайней мере, на логическом уровне) размещается упорядо-
ченный перечень значений индекса со ссылками на те кортежи базового отношения, в которых эти
значения встречаются.
Индексы могут быть уникальными и неуникальными, как показано на рис. 4.2 на примере пас-
портных данных (№ П – номер паспорта, Ф – фамилия). Здесь предполагается, что атрибут № П
– первичный ключ. Поэтому индекс для него является уникальным. Индекс атрибута Ф является
неуникальным.
Представим себе, что по заданному номеру паспорта требуется найти соответствующие паспорт-
ные данные (левая таблица, миллион записей). Последовательный просмотр записей этой таблицы
может привести к миллиону сравнений. Но в данном случае имеется структура Индекс № П. В
ней имеется упорядоченный список номеров паспортов с указанием на номера записей, содержащих
соответствующие паспортные данные. Поэтому можно применить алгоритм дихотомического поиска
Рис. 4.2.: Индексы
заданного номера паспорта по упорядоченному списку номеров паспортов структуры Индекс № П, а

затем, если запись найдена, по найденному из структуры номеру записи прямым доступом выбрать
данные из паспортных данных. Такой дихотомический поиск значения индекса в миллионе кортежей
будет реализован в СУБД за двадцать итераций:
106 = (103 )2 ∼ (210 )2 = 220
Индексы могут создаваться безотносительно к ключам для поддержки производительности опе-

раций сортировки и поиска. Создание индексов не предусмотрено стандартом SQL, однако боль-
шинство диалектов языка поддерживают как минимум следующие операторы создания и удаления
индексов:
create [unique] index имя_индекса

on имя_базового_отношения(имя_атрибута,..)
drop index {имя_базового_отношения.имя_индекса},..
Имя индекса должно быть уникально в пределах отношения. Поэтому в операторе удаления индекса
используется его уточненное имя.
После создания индекса он является самостоятельным объектом базы данных. Когда пользователь
выполняет обращающийся к индексированному столбцу запрос, СУБД автоматически анализирует
индекс для поиска требуемых значений.
При последующих модификациях базового отношения СУБД будет автоматически поддерживать
индекс в актуальном состоянии, что, конечно, создает дополнительную нагрузку на систему.
Хотя создание индекса допускается в любой момент, при его построении для уже заполненной
данными таблицы могут возникнуть проблемы, связанные с неуникальностью данных в различных
строках. Следовательно, уникальные индексы имеет смысл создавать непосредственно при создании
таблицы с помощью объявлений первичных и кандидатных ключей. В результате система сразу
возьмет на себя контроль за уникальностью значений данных в соответствующих столбцах.
4.4. Создание базовых отношений

При описании синтаксических конструкций используются следующие металингвистические симво-
лы:
1) { } – синтаксические конструкции в фигурных скобках представляют обязательные синтакси-
ческие единицы;
2) [ ] – синтаксические конструкции в квадратных скобках представляют необязательные синтак-
сические единицы;
3) | – вертикальная черта читается как «либо»;
4) ... – многоточие означает возможность повторения предшествующей синтаксической единицы;
5) ,.. – запятая и две точки означают возможность повторения предшествующей синтаксической

единицы через запятую. Так, например, следующие синтаксические конструкции будут экви-
валентными:
{буква | цифра} [,{буква | цифра}]...
{буква | цифра},..
Обе эти конструкции описывают последовательность из одного или нескольких буквенно-
цифровых символов, разделенных запятыми.
Атрибуты в схеме базового отношения разделяются на базовые (хранимые) и виртуальные (вы-
числяемые).
Оператор создания базового отношения в записи на псевдокоде включает объявления базовых и
виртуальных атрибутов, объявление ограничения кортежа и объявления первичного, кандидатных и
внешних ключей:
create table имя_базового_отношения
{имя_базового_атрибута
тип_значений_атрибута
[check(ограничение_значений_атрибута)]
[null | not null]
[default(значение_по_умолчанию)]
},..
[имя_виртуального_атрибута as(формула_вычисления)
],..
[check(ограничение_кортежа)]
[primary key(имя_атрибута,..)]
[candidate key(имя_атрибута,..)]...
[foreign key(имя_атрибута,..)
references имя_ссылочного_отношения(имя_атрибута,..)
on update {restrict | cascade | set null}
on delete {restrict | cascade | set null}
]...
При объявлении базового атрибута в общем случае задаются его тип, ограничение значений,
флажок допустимости null-значений и значение по умолчанию. Тип и ограничение значений атрибута
определяют его домен. Ограничение значений атрибута записывается как условие (в общем случае
с логическими связками not, and, or), зависящее от имени атрибута, например,
create table ...

Курс integer
check(1 <= Курс and Курс <= 5)
...
Флажок допустимости null-значений разрешает или запрещает появление null-значений в значениях

атрибута. Значение по умолчанию используется при вставке кортежа в отношение, если в операторе
вставки значение атрибута явно не задано. Значение по умолчанию может быть и null-значением,
если только null-значения для атрибута объявлены допустимыми.
Определение виртуального атрибута заключается в задании формулы его вычисления через
другие базовые атрибуты, например:
create table ...
ВесКг ...
[ЦенаРуб/Кг] ...
...
СтоимостьРуб as(ВесКг * [ЦенаРуб/Кг])
...
Ограничение кортежа записывается как условие (в общем случае с логическими связками not, and,
or), зависящее от имен нескольких базовых атрибутов, например:
create table ...
minВесКг ...
maxВесКг ...
...
check(0 < minВесКг and minВесКг < maxВесКг)
...
Применение ограничения к кортежу сводится к подстановке значений атрибутов кортежа вместо
имен атрибутов.
Далее могут быть объявлены первичный, кандидатные и внешние ключи.
Подсхема базового отношения, которой в другом (или том же самом) базовом отношении соответ-
ствует первичный или кандидатный ключ, в контексте указанного отношения называется внешним
ключом. Внешние ключи представляют механизм ссылок кортежей одних отношений на кортежи
других отношений (рис. 4.3). Объявления первичного и кандидатных ключей навязывают схеме ба-
зового отношения соответствующие ограничения уникальности. Объявления внешних ключей свя-
заны с навязыванием так называемых ограничений ссылочной целостности (о них позже).
Базовое отношение может быть удалено с помощью оператора
Рис. 4.3.: Внешние ключи как механизм ссылок
drop table имя_базового_отношения
4.5. Модификация базовых отношений

Термин «модификация» является обобщающим по отношению к операциям вставки, обновления и
удаления кортежей (строк) из базовых отношений (таблиц).
4.5.1. Вставка строк

Для вставки строк в существующую таблицу используется оператор insert в одной из следующих
форм 1-3:
insert into имя_таблицы(имя_столбца,..)
оператор_select
insert into имя_таблицы(имя_столбца,..)

values({default | null | выражение},..)
insert into имя_таблицы

default values
Примечание. В языке SQL список имен столбцов в формах 1, 2 не является обязательным. Если он не ука-
зан, оператор insert должен включать значения для всех не автоматически вычисляемых столбцов в таблице,
а порядок их должен соответствовать порядку столбцов в таблице. Но это очень плохой стиль программирова-
ния, так как оператор вставки становится зависимым от порядка объявления атрибутов в операторе создания
таблицы. Имена столбцов лучше указывать явно •
В форме 1 в таблицу вставляется набор строк, возвращаемый оператором select.
В форме 2 в таблицу вставляется единственная строка. Вместо указания явного значения столбца
для этой строки в виде выражения могут использоваться ключевые слова default или null для вставки
значений по умолчанию или null-значений соответственно. Выражение в качестве значения столбца
не может содержать оператор select.
В форме 3 в таблицу вставляется единственная строка, состоящая из значений по умолчанию.
Вставка значения по умолчанию подменяется на вставку null-значения, если значение по умолча-
нию явно не задано. Вставка строки с null-значениями пройдет успешно, если только null-значения
допустимы для соответствующих столбцов.
Оператор insert применим и к так называемым обновляемым представлениям, допускающим
однозначную интерпретацию операций вставки, обновления или удаления строк. Применительно
к представлениям оператор insert должен сводиться к вставке строки или строк лишь в одну из
таблиц, на которых базируется представление.
4.5.2. Обновление строк

Оператор обновления update позволяет изменять значения в нескольких строках таблицы:
update имя_таблицы
set {имя_столбца = новое_значение},..
[where условие]
Подобно оператору вставки insert, один оператор обновления update может модифицировать только
одну таблицу или одно представление. За ключевым словом set следует перечень имен подлежащих
обновлению столбцов с указанием их новых значений. Новое значение может быть константой или
выражением, которое также может ссылаться на сам столбец. Например, следующий оператор будет
уменьшать значения в столбце Цена на 10%:
update Товары
set Цена = Цена * 0.90
Фраза where не является обязательной. Если она указана, то должна задавать строки, подлежащие
обновлению. Если фраза where отсутствует, то будут обновляться все строки.
4.5.3. Удаление строк

Оператор delete удаляет несколько строк таблицы:
delete from имя_таблицы

[where условие]
Необязательная фраза where дает возможность отбирать удаляемые строки. Если эта фраза опущена,
то будут удалены все строки в указанной таблице.
Все строки таблицы могут быть удалены одновременно с помощью оператора
truncate table имя_таблицы
Это оператор отличается от оператора delete без фразы where тем, что не записывается в журнал
транзакций и, как следствие, выполняется существенно быстрее. Кроме того, оператор truncate table
сбрасывает значение счетчика для идентификационного столбца.
4.6. Целостность
Ограничение целостности (integrity – нетронутость, неприкосновенность, сохранность, целост-
ность) реляционного объекта данных (по состоянию) – это инвариант данных, что означает правиль-
ность данных в любой момент времени. Но эта цель может быть достигнута лишь в определенных
пределах: СУБД не может контролировать правильность каждого отдельного значения, вводимого в
базу данных (хотя каждое значение можно проверить на правдоподобность). Например, нельзя об-
наружить, что вводимое значение 5 (представляющее номер дня недели) в действительности должно
быть равно 3. С другой стороны, значение 9 явно будет ошибочным и СУБД должна его отверг-
нуть. Однако для этого ей следует сообщить, что номера дней недели должны принадлежать набору
(1,2,3,4,5,6,7).
Поддержание целостности базы данных может рассматриваться как защита данных от ошибочных
изменений.
Целостность следует отличать от безопасности, которая подразумевает защиту данных от несанк-
ционированного (незаконного) доступа к ним с целью раскрытия, изменения или разрушения дан-
ных.
Современные СУБД имеют ряд средств для обеспечения поддержания целостности (как, впрочем,
и средств обеспечения поддержания безопасности).
4.6.1. Декларативная поддержка

В общем случае классификация ограничений целостности по уровням иерархии реляционных объ-
ектов данных (атрибут – кортеж – отношение – база данных) означает зависимость ограничений
1) на уровне атрибута – от значения атрибута,

2) на уровне кортежа – от значения кортежа, то есть от значений нескольких атрибутов,
3) на уровне отношения – от отношения, то есть от нескольких кортежей,
4) на уровне базы данных – от нескольких отношений.

Декларативная (то есть путем объявлений, а не процедурная с помощью написания программного
кода) поддержка ограничений целостности реализуется в контексте оператора создания базового
отношения.
Ограничение уровня атрибута включает
1) ограничение типа значений атрибута, например, integer для атрибута Курс;
2) ограничение значений атрибута, записываемое как условие, зависящее от имени атрибута,

например, check(1 <= Курс and Курс <= 5);
3) ограничение null-значений, определяемое флажком допустимости (null) или недопустимости

(not null) null-значений.
Первые два ограничения определяют ограничение домена атрибута.
Ограничение уровня кортежа сводится к ограничению кортежа и записывается как условие,
зависящее от имен нескольких базовых атрибутов схемы отношения, например, check(0 < minВесКг
and minВесКг < maxВесКг).
Ограничение уровня отношения включает ограничения уникальности значений первичного (primary
key) и кандидатных (candidate key) ключей.
Ограничение уровня базы данных включает ограничения ссылочной целостности внешних клю-
чей (foreign key). Внешний ключ объявляемого базового отношения ссылается на первичный или
кандидатный ключ того же или другого базового отношения.
Отношение, на которое ссылается внешний ключ, называется ссылочным, или родительским.
Отношение, содержащее внешний ключ, называется дочерним.
Ограничение ссылочной целостности заключается в том, что каждому значению внешнего клю-
ча дочернего отношения должно соответствовать значение ключа родительского отношения (если
только значение внешнего ключа не содержит null-значений в каких-либо атрибутах). Кортежи до-
чернего отношения, нарушающие это условие, называются висящими. Для исключения возможности
их появления при объявлении внешнего ключа задается одно из следующих правил поддержания
ссылочной целостности, применяемых при обновлении значения ключа в кортеже родительского
отношения или удалении кортежа из родительского отношения (вставка нового кортежа в родитель-
ское отношение не может нарушить ссылочную целостность).
1. restrict – правило ограничения. Обновление ключа в родительском отношении или удаление

кортежа из родительского отношения не выполняется, если на этот кортеж родительского
отношения ссылается хотя бы один кортеж дочернего отношения. В примере на рис. 4.4 лишь
кортежи родительского отношения со значением первичного ключа 1 и 4 допускают обновление
ключа PKey или удаление кортежа.
2. cascade – правило каскадной модификации. Обновление ключа в родительском отношении или

удаление кортежа из родительского отношения вызывает автоматическое обновление или уда-
ление соответствующих кортежей дочернего отношения. Если в выше рассмотренном примере
(рис. 4.4) заменить правило restrict на cascade, то при обновлении PKey с 2 на 20 значение
FKey в двух кортежах также обновится с 2 на 20, а при удалении кортежа со значением
PKey, равным 2, из дочернего отношения автоматически удалятся кортежи со значением FKey,
равным 2.
3. set null – правило присвоения null-значений. Обновление ключа в родительском отношении

Рис. 4.4.: Декларативная поддержка ссылочной целостности
или удаление кортежа из родительского отношения вызывает автоматическое присвоение null-
значений тем атрибутам внешнего ключа, которые null-значения допускают. Правило примени-
мо, если такие атрибуты имеются.
Правила поддержания ссылочной целостности во фразах on update и on delete могут быть различ-
ными.
Вставка кортежа в дочернее отношение или обновление значения ключа в дочернем отношении
не будут выполнены, если это будет приводить к нарушению ссылочной целостности. Удаление
кортежей из дочернего отношения не может привести к появлению висящих кортежей.
Дочернее отношение в одной связи может выступать в качестве родительского в другой связи со
своими правилами поддержания ссылочной целостности.
Процедурная поддержка нестандартных ограничений целостности реализуется с помощью тригге-
ров.
4.6.2. Пример декларативной поддержки целостности

Курсы (КодК, ИмяК)

Организации (КодО, ИмяО)
Лекторы (КодЛр, Ф, И, О, КодО)
Лекции (КодЛр, КодК, ДатаНач, ДатаКон)
Предполагается, что лектор может участвовать в чтении лекций, не числясь в какой-либо органи-
зации из имеющегося списка организаций. Ключи (КодК, КодО и КодЛр) являются суррогатными.
Напишите на псевдокоде операторы создания указанных базовых отношений и обоснуйте на содер-
жательном уровне формулировку правил целостности.
Решение. При создании отношения Курсы требуем, чтобы наименование курса (ИмяК) было уни-
кальным и не могло принимать null-значений (можно было бы запретить и пустые значения):
create table Курсы
КодК counter,
ИмяК char not null
primary key(КодК)
candidate key(ИмяК)
Аналогичные ограничения сформулируем и для отношения Организации:
create table Организации
КодО counter,
ИмяО char not null
primary key(КодО)
candidate key(ИмяО)
Так как лектор может не числиться в какой-либо организации, то при создании отношения Лекторы
для внешнего ключа КодО null-значения полагаем допустимыми и для операции удаления сведений
об организации применяем правило присвоения null-значений (on delete set null):
create table Лекторы
КодЛр counter,
Ф char not null, И char not null, О char not null,
КодО integer null
primary key(КодЛр)
foreign key(КодО) references Организации(КодО) on delete set null
Примечание. Реакцию на обновление значения КодО в родительском отношении определять нет необходи-
мости, так как это значение обновить нельзя •
В отношении Лекции внешние ключи КодЛр и КодК являются атрибутами первичного ключа.
Поэтому для них null-значения объявляются недопустимыми. Реакции на обновление их значений в
родительских отношениях определять нет необходимости, т.к. эти значения обновить нельзя. Приме-
нение правила каскадной модификации (on delete cascade) при удалении данных о Лекторах и Кур-
сах соответствует стратегии хранения оперативных данных. Для атрибута ДатаНач null-значения
объявляются недопустимыми, так как атрибут входит в первичный ключ. Для атрибута ДатаКон
null-значения объявлены допустимыми с тем, чтобы можно было вводить данные о чтении лекций
с пока не определенной датой их окончания. Ограничение кортежа (ДатаНач < ДатаКон) не будет
препятствовать вводу таких данных.
create table Лекции

КодЛр integer not null,
КодК integer not null,
ДатаНач date not null,
ДатаКон date null
check(ДатаНач < ДатаКон)
primary key(КодЛ, КодК, ДатаНач)
foreign key(КодЛр) references Лекторы(КодЛр) on delete cascade
foreign key(КодК) references Курсы(КодК) on delete cascade
4.6.3. Транзакции и блокировки
Рассмотренных выше методов поддержания ссылочной целостности будет недостаточно, если про-
цесс перехода из одного целостного состояния в другое является многоэтапным, так что на проме-
жуточных этапах база данных находится в несогласованном состоянии.
Предположим, что база данных используется в некотором банке и один из клиентов банка желает
перевести деньги на счет другого клиента банка. В базе данных хранится информация о количестве
денег у каждого из клиентов. Нужно сделать два изменения в базе данных – уменьшить сумму
денег на счете одного из клиентов и, соответственно, увеличить сумму денег на другом счете.
Конечно, реальный перевод денег в банке представляет собой гораздо более сложный процесс,
затрагивающий много отношений, а, возможно, и много баз данных. Однако суть та же – нужно
совершить либо все действия (увеличить счет одного клиента и уменьшить счет другого клиента),
либо не выполнить ни одно из этих действий. Нельзя уменьшить сумму денег на одном счете, но не
увеличить сумму денег на другом.
Предположим также, что после выполнения первого из действий (уменьшения суммы денег на
счете первого клиента) произошел сбой. Например, могла прерваться связь клиентского компьюте-
ра с базой данных, или на клиентском компьютере мог произойти системный сбой, что привело к
перезагрузке операционной системы. Что в этом случай стало с базой данных? Команда на умень-
шение денег на счете первого клиента была выполнена, а вторая команда – на увеличение денег
на другом счете – нет. Без использования транзакций описанная выше ситуация привела бы к
противоречивому, неактуальному состоянию базы данных.
То свойство, что каждая транзакция начинается при целостном состоянии БД и оставляет это
состояние целостным после своего завершения, делает очень удобным использование понятия тран-
закции как единицы активности пользователя по отношению к БД. Транзакция – это единица
действий, производимых над базой данных. В состав транзакции может входить несколько опера-
торов изменения базы данных, но эти операторы либо выполняются все, либо не выполняется ни
один.
Перед выполнением первого действия выдается команда начала транзакции BEGIN TRANSACTION.
Поскольку после выполнения первого действия транзакция не была завершена (из-за сбоя), измене-
ния не будут внесены в базу данных. Изменения вносятся (фиксируются) только после завершения
транзакции. Оператор завершения транзакций обычно называется COMMIT TRANSACTION. До
выдачи данного оператора сохранения данных в базе не произойдет. В рассматриваемом примере,
поскольку оператор фиксации транзакции не был выдан, база данных откатится в первоначальное
состояние – иными словами, суммы на счетах клиентов останутся те же, что и были до начала тран-
закции. Администратор базы данных может отслеживать состояние транзакций и в необходимых
случаях вручную откатывать транзакции. Кроме того, в очевидных случаях СУБД самостоятель-
но принимает решение об откате транзакции. Транзакции не обязательно могут быть короткими.
Бывают транзакции, которые длятся несколько часов или даже, несколько дней. Увеличение коли-
чества действий в рамках одной транзакции требует увеличения занимаемых системных ресурсов.
Поэтому, желательно делать транзакции, по возможности, короткими. В журнал транзакций зано-
сятся все транзакции – и зафиксированные и завершившиеся откатом. Ведение журнала транзакций
совместно с созданием резервных копий базы данных позволяет достичь высокой надежности базы
данных. Предположим, что база данных была испорчена в результате аппаратного сбоя компьютера,
на котором был установлен сервер СУБД. В этом случае нужно использовать последнюю сделан-
ную резервную копию базы данных и журнал транзакций. Причем применить к базе данных нужно
только те транзакции, которые были зафиксированы после создания резервной копии. Большинство
современных СУБД позволяют администратору воссоздать базу данных, исходя из резервной копии
и журнала транзакций.
Откатом транзакций можно управлять программно, анализируя промежуточные состояния и вы-
давая команду отката транзакции ROLLBACK TRANSACTION в случае возникновения ошибочной
ситуации (на счете не хватает денег, счет для операций заблокирован и т.п.):
BEGIN TRANSACTION
UPDATE счет-1 ...
IF возникла ошибка THEN GOTO undo
UPDATE счет-2 ...
IF возникла ошибка THEN GOTO undo
COMMIT TRANSACTION
RETURN
undo: ROLLBACK TRANSACTION
С понятием транзакции тесно связано понятие блокировки. Блокировки необходимы для того, чтобы
дать различным пользователям возможность одновременно работать с базой данных. При одновре-
менной работе в некоторый момент времени разные пользователи, могут обратиться к одной и той
же записи. Или один пользователь может использовать данные, которые в данный момент меняет
другой пользователь. СУБД должна запрещать подобные действия, поскольку они могут привести
к ошибкам.
Для реализации этого запрета СУБД устанавливает блокировку на объекты, которые использует
транзакция. Существуют разные типы блокировок – табличные, страничные, строчные и другие, ко-
торые отличаются друг от друга количеством заблокированных записей. Чаще других используется
строчная блокировка – при обращении транзакции к одной строке блокируется только эта строка,
остальные строки остаются доступными для изменения.
Таким образом, процесс внесения изменений в базу данных состоит из следующей последова-
тельности действий: выдается оператор начала транзакции, выдается оператор изменения данных,
СУБД анализирует оператор и пытается установить блокировки, необходимые для его выполнения,
в случае успешной блокировки оператор выполняется, затем процесс повторяется для следующего
оператора транзакции. После успешного выполнения всех операторов внутри транзакции выполняет-
ся оператор фиксации транзакции. СУБД фиксирует изменения, сделанные транзакцией и снимает
блокировки. В случае неуспеха выполнения какого-либо из операторов, транзакция откатывается,
данные получают прежние значения, снимаются блокировки.
4.6.4. Триггеры
Триггеры являются одной из разновидностей хранимых процедур. Хранимые процедуры представ-
ляют собой группу команд SQL, объединенных в один модуль. Такая группа команд компилируется
и выполняется как единое целое. Хранимая процедура является объектом базы данных.
Однако вызов триггеров, в отличие от вызовов хранимых процедур, не производится явно. Триг-
геры вызываются автоматически при выполнении над таблицей какой-либо операции модификации
(вставки, обновления или удаления строки). Триггеры используются для контроля целостности дан-
ных, а также для отката транзакций.
Триггер – это откомпилированная SQL-процедура, исполнение которой обусловлено наступлени-
ем определенных событий внутри реляционной базы данных. Применение триггеров большей частью
весьма удобно для пользователей базы данных. И все же их использование часто связано с дополни-
тельными затратами ресурсов на операции ввода/вывода. В том случае, когда тех же результатов (с
гораздо меньшими непроизводительными затратами ресурсов) можно добиться с помощью хранимых
процедур или прикладных программ, применение триггеров нецелесообразно.
Триггеры – особый инструмент SQL-сервера, используемый для поддержания целостности дан-
ных в базе данных. С помощью ограничений целостности, правил и значений по умолчанию не
всегда можно добиться нужного уровня функциональности. Часто требуется реализовать сложные
алгоритмы проверки данных, гарантирующие их достоверность и реальность. Кроме того, иногда
необходимо отслеживать изменения значений таблицы, чтобы нужным образом изменить связанные
данные.
Триггер представляет собой специальный тип хранимых процедур, запускаемых сервером автома-
тически при попытке изменения данных в таблицах, с которыми триггеры связаны. Каждый триггер
привязывается к конкретной таблице. Все производимые им модификации данных рассматриваются
как одна транзакция. В случае обнаружения ошибки или нарушения целостности данных происхо-
дит откат этой транзакции. Тем самым внесение изменений запрещается. Отменяются также все
изменения, уже сделанные триггером.
Создает триггер только владелец базы данных. Это ограничение позволяет избежать случайного
изменения структуры таблиц, способов связи с ними других объектов и т.п.
Триггер представляет собой весьма полезное и в то же время опасное средство. Так, при непра-
вильной логике его работы можно легко уничтожить целую базу данных, поэтому триггеры необхо-
димо очень тщательно отлаживать.
В отличие от обычной процедуры, триггер выполняется неявно в каждом случае возникновения
триггерного события; к тому же он не имеет аргументов. Приведение его в действие иногда называют
запуском триггера.
С помощью триггеров достигаются следующие цели:
• проверка корректности введенных данных и выполнение сложных ограничений целостности

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

обновлении таблицы;
• накопление аудиторской информации посредством фиксации сведений о внесенных изменениях

и тех лицах, которые их выполнили;
• поддержка репликации.
Основной формат команды CREATE TRIGGER показан ниже:
CREATE TRIGGER имя_триггера
{BEFORE | AFTER} триггерное_событие
ON <имя_таблицы>
[REFERENCING список_старых_или_новых_псевдонимов]
[FOR EACH {ROW | STATEMENT}]
[WHEN(условие_триггера)]
тело_триггера
Триггерные события состоят из вставки, обновления и удаления строк в таблице. В случае обнов-
ления для триггерного события можно указать конкретные имена столбцов таблицы. Время запуска
триггера определяется с помощью ключевых слов BEFORE (триггер запускается до выполнения
связанных с ним событий) или AFTER (после их выполнения).
Выполняемые триггером действия задаются для каждой строки (FOR EACH ROW), охваченной
данным событием, или только один раз для каждого события (FOR EACH STATEMENT).
Обозначение «список_старых_или_новых_псевдонимов» относится к таким компонентам, как ста-
рая или новая строка (OLD / NEW), либо старая или новая таблица (OLD TABLE / NEW TABLE).
Ясно, что старые значения не применимы для событий вставки, а новые – для событий удаления.
При условии правильного использования триггеры могут стать очень мощным механизмом. Ос-
новное их преимущество заключается в том, что стандартные функции сохраняются внутри базы
данных и согласованно активизируются при каждом ее обновлении. Это может существенно упро-
стить приложения. Тем не менее, следует упомянуть и о присущих триггеру недостатках.
1. Сложность: при перемещении некоторых функций в базу данных усложняются задачи ее проек-
тирования, реализации и администрирования.
2. Скрытая функциональность: перенос части функций в базу данных и сохранение их в виде
одного или нескольких триггеров иногда приводит к сокрытию от пользователя некоторых
функциональных возможностей. Хотя это в определенной степени упрощает его работу, но, к
сожалению, может стать причиной незапланированных, потенциально нежелательных и вред-
ных побочных эффектов, поскольку в этом случае пользователь не в состоянии контролировать
все процессы, происходящие в базе данных.
3. Влияние на производительность: перед выполнением каждой команды по изменению состояния

базы данных СУБД должна проверить триггерное условие с целью выяснения необходимости
запуска триггера для этой команды. Выполнение подобных вычислений сказывается на общей
производительности СУБД, а в моменты пиковой нагрузки ее снижение может стать особенно
заметным. Очевидно, что при возрастании количества триггеров увеличиваются и накладные
расходы, связанные с такими операциями.
Неправильно написанные триггеры могут привести к серьезным проблемам, таким, например, как
появление «мертвых» блокировок. Триггеры способны длительное время блокировать множество
ресурсов, поэтому следует обратить особое внимание на сведение к минимуму конфликтов доступа.
4.7. Виртуальные отношения

Виртуальные отношения (view – представления) хранятся в базе данных как именованные операторы
select и создаются с помощью следующего оператора:
\create view имя_виртуального отношения

as оператор_select
Выполнение оператора select происходит в момент обращения к представлению. Представления мож-
но использовать для извлечения данных подобно таблицам, в частности, в операторе select.
Представление может быть обновляемым (термин общепринят, хотя следовало бы говорить «моди-
фицируемым»), если к нему допустимо обращаться с командами модификации (вставки, обновления
и удаления кортежей). Обновляемыми могут быть представления в достаточно простых случаях,
допускающих однозначную реализацию операций модификации на базовых таблицах.
Представление может быть индексированным (в Microsoft SQL Server – начиная с версии 2000).
В этом случае оно материализуется, то есть сохраняется в базе данных как «вычисленный» запрос.
При модификации базовых таблиц, через которые вычисляется представление, СУБД автоматически
модифицирует и материализованное представление. Причина материализации – в необходимости
поддержки индекса.
Удалить представление можно с помощью оператора
drop view имя_виртуального_отношения

Типы данных
• Перечислите базовые типы данных.
• Какие варианты может иметь целочисленный тип данных?
• Что такое перечислимый тип данных?
• Что представляет собой десятичный тип данных с фиксированной точкой?

• Что представляет собой денежный тип данных?
• Чем различаются строки бит фиксированной и переменной длины?
• Чем различаются строки символов фиксированной и переменной длины?
• Какие варианты типа даты и времени существуют?
• Каковы правила работы с данными типа счетчика?
• Для чего предназначены объекты типа BLOB?
• Что представляет собой тип данных, определяемый пользователем?
• Как создаются подтипы базовых типов данных, определяемые пользователем?
Первичные и кандидатные ключи
• Опишите понятие ключа схемы базового отношения. Что понимается под требованием «неиз-
быточности»?
• Чем отличается простой ключ от составного? Приведите примеры.
• Что такое суперключ?
• Чем различаются понятия первичного и кандидатных ключей?
• Из каких соображений должен выбираться первичный ключ?
Индексы
• Для чего предназначены индексы?
• Чем различаются индексы простые и составные?
• Чем различаются индексы уникальные и неуникальные.
• Запишите оператор создания индекса.
• Как следует создавать уникальные индексы?
Создание базовых отношений
• Какие металингвистические символы используются при описании синтаксических конструк-

ций?
• В чем различие понятий базового и виртуального атрибутов?
• Запишите в общей форме оператор создания базового отношения.
• Что задается при объявлении базового атрибута?
• Как определяется виртуальный атрибут?
• Как формулируется ограничение кортежа?
• Как определяется первичный ключ?
• Как определяется кандидатный ключ?
• Что понимается под внешним ключом?

Модификация базовых отношений
• Что понимается под термином «модификация отношения»?
• Приведите три формы оператора вставки строк в существующие таблицы.
• Приведите форму оператора обновления строк.
• Приведите формы оператора удаления строк.
Целостность
• В чем смысл понятия целостность? В чем его отличия от понятия безопасности?
• Укажите уровни декларативной поддержки ограничений целостности.
• Какие ограничения декларативно поддерживаются на уровне атрибута?
• Какие ограничения декларативно поддерживаются на уровне кортежа?
• Какие ограничения декларативно поддерживаются на уровне отношения?
• Какие ограничения декларативно поддерживаются на уровне базы данных?
• Что понимается под ограничением ссылочной целостности? Какие кортежи называются вися-
щими?
• Какие декларативные правила поддержания ссылочной целостности используются?

• Задание 1. Имеется следующий фрагмент базы данных:
Поставщики (КодПщ, Имя, Город)

Детали (КодД, РодД, Цвет, ВесКг)
Поставки (КодПщ, КодД, Штук)
Поставщики характеризуются уникальным кодом (КодПщ), уникальным наименованием (Имя)

и городом размещения (Город). Поставляемые детали определяются уникальным кодом (КодД),
родовым наименованием (РодД), которое может и не быть уникальным, а также атрибутами
Цвет (’R’ – красный, ’G’ – зеленый, ’B’ – голубой) и ВесКг.
Предложите в записи на псевдокоде вариант оператора создания базового отношения Поставки
со следующими правилами поддержания ссылочной целостности.
Вариант 1. Правила ограничения при модификации отношений и Поставщики, и Детали.

Вариант 2. Правило ограничения при модификации отношения Поставщики. Правило каскад-
ной модификации при модификации отношения Детали.
Вариант 3. Правило каскадной модификации при модификации отношения Поставщики. Пра-
вило ограничения при модификации отношения Детали.
Вариант 4. Правила каскадной модификации при модификации отношений и Поставщики, и
Детали.
• Для чего предназначен механизм транзакций?

• Как можно программно управлять откатом транзакций?
• Для чего предназначен механизм блокировок? Какие типы блокировок существуют?
• В чем различие между хранимыми процедурами и триггерами?
• Приведите основной формат команды создания триггера.
Виртуальные отношения
• Как создаются виртуальные отношения (представления)?
• Что понимается под обновляемым представлением?
• Для чего используется материализация представлений?

Часть IV.
Модуль 3
5. Нормальные формы
Все проводимые ниже рассуждения о нормальных формах (как, впрочем, и о проектировании схем
баз данных) относятся к системам оперативной обработки транзакций OLTP и базовым отношениям.
Для OLAP-систем, как и для виртуальных отношений OLTP-систем, характерной является как раз
ненормализованность данных, связанная с избыточной формой их хранения и представления.
5.1. Функциональные зависимости (ФЗ)

Ограничения уникальности, накладываемые объявлениями первичного и кандидатных ключей отно-
шений, являются частным случаем ограничений, связанных с понятием функциональных зависимо-
стей.
Рассмотрим отношение, содержащее данные о результатах конкретной экзаменационной сессии
(семестр и учебный год не указаны):
Сессия(№ ЗК, Ф, И, О, МнемоП, Оценка)
Атрибуты № ЗК (номер зачетной книжки) и МнемоП (мнемоническое обозначение предмета) об-

разуют ключ этого отношения (так как в конкретную сессию в одну зачетку по одному предмету
Рис. 5.1.: Ненормализованное отношение
поставить можно лишь не более одной оценки). Однако помимо ограничения уникальности, свя-
занного с этим ключом, на отношение должно быть наложено то условие, что зачетка выдается
одному конкретному лицу и, следовательно, в этом отношении кортежи с одинаковым номером за-
четки должны содержать одинаковые значения атрибутов Ф, И, О (рис. 5.1). Поэтому, как говорят,
атрибуты Ф, И, О функционально зависят от атрибута № ЗК.
Таким образом, функциональная зависимость – это однозначная зависимость, затабулированная
в базе данных. Термин «зависимость» не означает, что в данном случае по № ЗК (числу) можно
без использования данных, хранимых в отношении, «вычислить» Ф, И, О. Он означает лишь, что
одному значению № ЗК нельзя в отношении сопоставить два или более значений Ф, И или О.
Определение. Пусть X и Y – подсхемы схемы отношения S, определяющие над схемой S схему
функциональной зависимости X → Y (читается «X стрелка Y»). Определим ограничение функци-
ональной зависимости invhX → Y i как утверждение о том, что в отношении со схемой S любые
два кортежа, совпадающие в проекции на подсхему X, должны совпадать и в проекции на подсхему
Y:
invhX → Y ir(S) = ∀t1, t2 ∈ r(t1[X] = t2[X] ⇒ t1[Y ] = t2[Y ]); X, Y ∈ S
В этом случае говорят, также, что X функционально определяет Y или что Y функционально
зависит от X. В схеме функциональной зависимости X → Y подсхема X называется левой частью,
а Y – правой частью. На схему функциональной зависимости для краткости обычно ссылаются как
на функциональную зависимость Конец определения.
Введенное понятие ограничения функциональной зависимости относится к ограничению на уровне
отношения, так как оно накладывает ограничения на возможные значения различных кортежей
одного и того же отношения.
Приведем примеры изображения функциональных зависимостей:
{№ ЗК} → {Ф, И, О}
{№ ЗК, МнемоП} → {Оценка}
При изображении схемы отношения помимо ограничений уникальности, связанных с объявлени-

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

primary key(№ ЗК, МнемоП)
{№ ЗК} → {Ф, И, О}
Здесь важно, что объявление (в данном случае первичного) ключа навязывает схеме отношения
функциональную зависимость, эквивалентную ограничению уникальности. А именно, рассматри-
ваемую схему отношения с ограничениями мы могли бы представить в эквивалентном виде без
объявления (первичного) ключа, заменяя его объявление соответствующим ограничением функцио-
нальной зависимости (вида {ключ} → {остальные атрибуты}):

{№ ЗК, МнемоП} → {Ф, И, О, Оценка}
{№ ЗК} → {Ф, И, О}
Действительно, объявляя атрибуты № ЗК, МнемоП (первичным) ключом, мы гарантируем, что в

отношении Сессия не могут быть два кортежа с одинаковыми значениями этих атрибутов. Следо-
вательно, им просто невозможно сопоставить два различных набора значений остальных атрибутов
Ф, И, О, Оценка.
Таким образом, объявления (первичных и кандидатных) ключей навязывают схеме отношения
ограничения уникальности и, как следствие, соответствующие ограничения функциональных зави-
симостей.
Ограничения функциональных зависимостей могут препятствовать вставке и обновлению корте-
жей в отношении. При удалении кортежей ограничение функциональной зависимости нарушиться
не может.
5.1.1. Правила вывода Армстронга

Если отношение удовлетворяет некоторым определенным функциональным зависимостям, то с по-
мощью формулируемых ниже правил вывода можно получить другие функциональные зависимости,
которым отношение будет автоматически удовлетворять.
Теорема. Справедливы следующие правила, называемые правилами вывода Армстронга (часто
называемые аксиомами):
ПВ1. ` X → X рефлексивность
ПВ2. X → Y ` X ∪ Z → Y пополнение
ПВ3. X → Y, Y ∪ W → Z ` X ∪ W → Z псевдотранзитивность
Здесь X, Y , Z, W – произвольные подсхемы схемы отношения S. Символ метаутверждения о

выводимости «`» разделяет списки посылок и заключений. Посылки и заключения представлены в
сокращенной форме обозначениями схем функциональных зависимостей. В расширенной форме им
соответствуют ограничения функциональных зависимостей:
ПВ1. invhX → Xir(S)

ПВ2. invhX → Y ir(S) ⇒ invhX ∪ Z → Y ir(S)
ПВ3. invhX → Y ir(S) & invhY ∪ W → Zir(S) ⇒ invhX ∪ W → Zir(S)
Доказательство правила рефлексивности следует непосредственно из определения ограничения

функциональной зависимости при подстановке X вместо Y . Это тавтология.
Доказательство правила пополнения. Пусть кортежи равны на X ∪ Z. Тогда они равны на X.
Согласно посылке, они будут равны и на Y .
Доказательство правила псевдотранзитивности. Пусть кортежи равны на X ∪W . Тогда они равны
и на X, и на W . Согласно посылке 1, они будут равны и на Y . Следовательно, они равны и на X, и
на W . Отсюда, согласно посылке 2, они будут равны и на Z.
Конец теоремы.
Функциональная зависимость с совпадающими левой и правой частями называется рефлексив-
ной. Согласно правилу рефлексивности, ограничение рефлексивной зависимости выполняется авто-
матически. Правило пополнения вводит избыточность в левую часть функциональной зависимости.
Правило псевдотранзитивности обобщает правило транзитивности, соответствующее частному
случаю W = ∅:
ПВ3◦ X → Y, Y → Z ` X → Z транзитивность
5.1.2. Производные правила вывода

Если из одних правил вывести другие, то новые правила, называемые производными, можно ис-
пользовать наряду с исходными.
Теорема. Следующие правила являются производными от правил вывода Армстронга:
ПВТ. ` X ∪ Z → X тривиальность
ПВА. X → Y, X → Z ` X → Y ∪ Z аддитивность
ПВП. X → Y ∪ Z ` X → Y, X → Z проективность (обращение аддитивности)
При построении цепочек вывода после формулировки посылок применяется правило рефлексивно-
сти с тем, чтобы ввести функциональную зависимость с правой частью, фигурирующей в заключе-
нии. В правой части цепочки даются ссылки на правила, посылки правил и шаги, обосновывающие
шаг вывода.
Доказательство правила тривиальности
1. X → X ПВ1
2. X ∪ Z → X ПВ2, 1
Доказательство правила аддитивности:
1. X → Y посылка 1 ПВА
2. X → Z посылка 2 ПВА
3. Y ∪ Z → Y ∪ Z ПВ1
4. X ∪ Z → Y ∪ Z ПВ3, 1, 3
5. X ∪ X → Y ∪ Z ПВ3, 2, 4
6. X → Y ∪ Z 5
Доказательство правила проективности:
1. X → Y ∪ Z X → Y ∪ Z посылка ПВП
2. Y → Y Z→Z ПВ1
3. Y ∪ Z → Y Z ∪ Y → Z ПВ2, 2
4. X → Y X→Z ПВ3◦ , 1, 3
Функциональная зависимость с левой частью, являющейся надмножеством правой части, называ-
ется тривиальной. Согласно правилу тривиальной зависимости, ограничение тривиальной зависи-
мости выполняется автоматически. Правило тривиальности является обобщением правила рефлек-
сивности и, как и последнее, могло бы быть получено непосредственно из определения ограничения
функциональной зависимости. Тот факт, что это правило является производным, не случаен и связан
с полнотой системы правил Армстронга (о чем позже).
Правила аддитивности и проективности применительно к функциональным зависимостям с
одинаковыми левыми частями позволяют объединять и расщеплять правые части зависимостей.
5.1.3. Независимость правил Армстронга

Теорема. Правила Армстронга образуют систему независимых правил вывода, то есть ни одно
из правил рефлексивности, пополнения и псевдотранзитивности не является производным от двух
других.
Доказательство основано на невозможности построения цепочки вывода, в которой, исходя из
посылок рассматриваемого правила, путем применения других правил выводится его заключение.
Случай 1. Для правила рефлексивности цепочка вывода имела бы следующий вид:
... ПВ2, ПВ3
n. X → X заключение ПВ1
Но правила пополнения и псевдотранзитивности требуют посылок. Следовательно, заключение
вывести нельзя.
Случай 2. Для правила пополнения цепочка вывода в общем случае имела бы вид:
1. X → Y посылка ПВ2
... ПВ1, ПВ3
n. X ∪ Z → Y заключение ПВ2
Для доказательства достаточно рассмотреть частный случай Y = X, поскольку правило рефлек-
сивности все равно породило бы произвольные рефлексивные зависимости:
1. X X
R посылка ПВ2 при Y = X
... ПВ1, ПВ3
n. X ∪ Z → X заключение ПВ2
Для применения правила псевдотранзитивности требуется 2 посылки. Поэтому вначале следует
применить один или несколько раз правило рефлексивности. Но применительно к рефлексивным за-
висимостям правило псевдотранзитивности также даст рефлексивную зависимость. Таким образом,
в цепочке вывода заключению будут предшествовать рефлексивные зависимости. Следовательно,
заключение вывести нельзя.
Случай 3. Для правила псевдотранзитивности аналогично предыдущему имеем
1. X → Y посылка 1 ПВ3
2. Y ∪ W → Z посылка 2 ПВ3
... ПВ1, ПВ2
n. X ∪ W → Z заключение ПВ3
Частный случай выбирается таким образом, чтобы поглотить правило рефлексивности (Z = Y ∪X)
и в противовес правилу пополнения уменьшить левую часть заключения (W = X):
1. X → Y посылка 1 ПВ3 при Z = Y ∪ X, W = X
2. Y ∪ X → Y ∪ X посылка 2 ПВ3
... ПВ1, ПВ2
n. X → Y ∪ X заключение ПВ3
Поэтому в цепочке вывода заключению будут предшествовать тривиальные зависимости и зависи-
мости, полученные пополнением левой части первой посылки. Следовательно, заключение вывести
нельзя.
5.1.4. Полнота системы правил Армстронга

Пусть F (S) – заданное множество функциональных зависимостей над схемой отношения S. Обо-
значим через invhF (S)i ограничение, накладываемое этим множеством:
invhF (S)ir(S) = ∀X → Y ∈ F (S)[invhX → Y ir(S)]

Пусть отношение r(S) удовлетворяет этому ограничению. Применяя правила вывода Армстронга
к зависимостям из множества F (S), можно получить новые зависимости. Ограничениям этих за-
висимостей отношение r(S) будет автоматически удовлетворять, что видно из расширенной формы
записи правил вывода. Пополним множество F (S) новыми выводимыми из него зависимостями. Бу-
дем применять процедуру пополнения до тех пор, пока не перестанут получаться новые зависимости.
В результате получим множество функциональных зависимостей, называемое замыканием множе-
ства F (S) и обозначаемое как F + (S). Процесс построения замыкания конечен в силу конечности
схемы отношения (и, следовательно, конечности числа функциональных зависимостей). Замыкание
является надмножеством замыкаемого множества и не изменяется при повторном замыкании:
F (S) ⊆ F + (S), [F + (S)]+ = F + (S)

Из истинности правил Армстронга и определения замыкания следует, что любое отношение, удо-
влетворяющее ограничению заданного множества функциональных зависимостей, будет удовлетво-
рять ограничению зависимости, принадлежащей замыканию:
X → Y ∈ F + (S) ⇒ ∀r(S){invhF (S)ir(S) ⇒ invhX ⇒ Y ir(S)}

Теорема полноты системы правил вывода Армстронга утверждает, что внешняя импликация заме-
няется на эквивалентность (без доказательства).
Из теоремы следует практически важные выводы.
1. Различные множества функциональных зависимостей будут эквивалентны с точки зрения
накладываемых ограничений тогда и только тогда, когда их замыкания совпадают.
2. Достаточно ограничиться рассмотрением полностью нетривиальных зависимостей, в которых
левые и правые части не пересекаются.
3. Функциональные зависимости с одинаковыми левыми частями допускают произвольное объ-
единение и разбиение правых частей (согласно правилам аддитивности и проективности).
5.2. Нормальные формы
Понятие рассматриваемых в данном разделе нормальных форм связано с понятием функциональных
зависимостей. Ограничения, накладываемые заданными множествами функциональных зависимо-
стей на схемы базовых отношений, в общем случае реализуются
1) декларативно с помощью объявления первичных, кандидатных и внешних ключей,
2) процедурно с помощью написания программного кода триггеров.
Смысл нормализации схемы базы данных состоит в определении схем базовых отношений, позво-
ляющих максимально уменьшить необходимость в написании программного кода, увеличить произ-
водительность и облегчить поддержку целостности данных.
Вернемся к ранее рассмотренному отношению, содержащему данные о результатах экзаменаци-
онной сессии (см. рис. 5.1), и опишем схему базы данных с учетом ограничений функциональных
зависимостей:
Вариант 1 схемы БД

{№ ЗК} → {Ф, И, О}
Здесь для поддержания целостности данных, то есть для выполнения ограничения функциональ-
ной зависимости {№ ЗК} → {Ф, И, О}, при изменении фамилии необходимо просматривать все
кортежи отношения и вводить необходимые изменения (что чревато ошибками; ситуация усугуб-
ляется, если Ф, И, О имеются и в других отношениях). Однако поддержку этой функциональной
зависимости можно реализовать автоматически с помощью объявлений ключей, если провести де-
композицию этого отношения так, чтобы ненавязанная функциональная зависимость {№ ЗК} → {Ф,
И, О} была навязана объявлением ключа № ЗК в отношении, полученным из исходного проекцией
на объединение атрибутов левой и правой частей функциональной зависимости (рис. 5.2):
Студенты(№ ЗК, Ф, И, О)
primary key(№ ЗК)
Сессия(№ ЗК, МнемоП, Оценка)

foreign key(№ ЗК) references Студенты(№ ЗК)
Цель нормализации в аспекте функциональных зависимостей – навязать базе данных требуемые

функциональные зависимости с помощью объявлений первичных, кандидатных и внешних ключей
базовых отношений.
Принцип проектирования схем баз данных – не смешивать атрибуты различных понятий в одном
базовом отношении.
5.2.1. Первая нормальная форма (1NF)

На ранних стадиях проектирования схем баз данных для краткости используются
Рис. 5.2.: Нормализованные отношения
Рис. 5.3.: Виды атрибутов
1) наряду с простыми, то есть атомарными, и составные атрибуты, составленные из нескольких

разнородных атрибутов;
2) наряду с однозначными и многозначные атрибуты, представляющие множества значений.

Возможны различные комбинации простых или составных и однозначных или многозначных ат-
рибутов (см. пример на рис. 5.3).
Определение. Отношение находится в первой нормальной форме тогда и только тогда, когда его
схема содержит только простые однозначные атрибуты, причем с одной и той же семантикой.
Конец определения.
Рассмотрим пример ненормализованного отношения:
Должности(КодД, Наименование)
primary key(КодД)
candidate key(Наименование)
Сотрудники(№ таб, ФИО, КодД, Телефоны, Дата приема или увольнения)

primary key(№ таб)
foreign key(КодД) references Должности(КодД)
Здесь имеются следующие ошибки нормализации:

1) атрибут ФИО является составным, то есть составленным из разнородных атрибутов;
2) атрибут Телефоны является многозначным, то есть его значением является множество значе-
ний;
3) атрибут Дата приема или увольнения не имеет однозначной семантики.

В последнем случае невозможно понять, какая именно дата внесена для конкретного сотрудника
– приема или увольнения. Если ввести дополнительный атрибут, определяющий смысл даты, то
смысл даты можно будет определить, но останется возможность хранения только одной из этих дат
для каждого сотрудника.
Для приведения отношения к первой нормальной форме следует:
1) провести разбиение атрибутов на простые с тем, чтобы исключить составные атрибуты и
атрибуты с неоднозначной семантикой;
2) провести декомпозицию отношения с тем, чтобы исключить многозначные атрибуты.
После приведения отношения Сотрудники к первой нормальной форме получим:
Сотрудники(№ таб, Ф, И, О, КодД, Дата приема, Дата увольнения: null)

Телефоны(№ таб, Телефон)

primary key(№ таб, Телефон)
foreign key(№ таб) references Сотрудники (№ таб)
Примечание. В отношении Телефоны атрибут № таб является одновременно атрибутом первичного ключа
и внешним ключом, ссылающимся на первичный ключ отношения Сотрудники •
На отношение, находящееся в первой нормальной форме, в общем случае наложены ограничения
уникальности первичного и кандидатных ключей, ограничения внешних ключей, а также ограниче-
ния функциональных зависимостей.
Как провести классификацию ограничений функциональных зависимостей?
Атрибут, содержащийся в каком-либо первичном или кандидатном ключе отношения, называет-
ся ключевым. Все атрибуты отношения, следовательно, разбиваются («разбиваются» – значит без
пересечения) на ключевые и неключевые. Поэтому все ограничения функциональных зависимостей
можно разбить на два класса – с ключевыми и неключевыми атрибутами в правой части.
В левой части функциональной зависимости могут быть представлены атрибуты, не образующие в
совокупности первичный или кандидатный ключ («не ключ»), так как зависимости с левой частью,
образующей ключ, навязываются ограничениями уникальности при объявлении ключей.
Таким образом, схема отношения, находящегося в первой нормальной форме, имеет следующие
ограничения функциональных зависимостей, не навязанные объявлениями ключей:
Отношение1NF(ключевые атрибуты, неключевые атрибуты)

primary key(ключ)
candidate key(ключ)
foreign key(атрибуты) references
{не ключ} → {неключевые атрибуты}
{не ключ} → {ключевые атрибуты}
5.2.2. Вторая нормальная форма (2NF)

Так как «не ключ» может быть или не быть частью некоторого ключа, то класс функциональных
зависимостей {не ключ} → {неключевые атрибуты} разбивается на два подкласса:
{не ключ но подключ} → {неключевые атрибуты}

{не ключ и не подключ} → {неключевые атрибуты}
Цель приведения отношений ко второй нормальной форме – исключить из отношений в пер-

вой нормальной форме ограничения функциональных зависимостей вида {не ключ но подключ} →
{неключевые атрибуты}.
Все атрибуты функционально зависят от (первичного и кандидатных) ключей. Если при этом ат-
рибуты не зависят от части ключа, то функциональная зависимость от ключа называется полной.
Иными словами, цель приведения отношений ко второй нормальной форме заключается в исключе-
нии неполных функциональных зависимостей неключевых атрибутов от ключей.
Определение. Отношение находится во второй нормальной форме относительно заданного множе-
ства функциональных зависимостей тогда и только тогда, когда оно находится в первой нормальной
форме и функциональные зависимости неключевых атрибутов от (первичного и кандидатных) клю-
чей являются полными. Конец определения.
Примечание. Ясно, что отношение может не находиться во второй нормальной форме, если только оно
имеет составные ключи •
Следующее отношение Аудитории не находится во второй нормальной форме:
Сотрудники(№ таб, Ф, И, О)
Аудитории(№ К, № А, ПлощадьКвМ, № таб коменданта)

primary key(№ К, № А)
foreign key(№ таб коменданта) references Сотрудники(№ таб)
{№ К} → {№ таб коменданта}
Здесь неключевой атрибут № таб коменданта (корпуса) функционально зависит от части ключа.
Примечание. Это произошло из-за смешения понятий Корпуса и Аудитории •
После приведения ко второй нормальной форме путем декомпозиции отношения Аудитории полу-
чим
Сотрудники(№ таб, Ф, И, О)
Корпуса(№ К, № таб коменданта)

primary key(№ К)
foreign key(№ таб коменданта) references Сотрудники (№ таб)
Аудитории(№ К, № А, ПлощадьКвМ)
foreign key(№ К) references Корпуса (№ К)
Примечание. Обратим внимание на то, что в отношении Аудитории атрибут первичного ключа № К
является одновременно внешним ключом, ссылающимся на первичный ключ отношения Корпуса •
В данном примере все требуемые функциональные зависимости навязаны объявлениями первич-
ных и внешних ключей (кандидатных нет). Поэтому дальнейшая нормализация не требуется.
Понятие второй нормальной формы самостоятельного значения не имеет. Оно является ослаблен-
ной формой понятия третьей нормальной формы.
5.2.3. Третья нормальная форма (3NF)

Цель приведения отношений к третьей нормальной форме – полностью исключить из отношений
в первой нормальной функциональные зависимости неключевых атрибутов от не ключей, то есть
исключить зависимости вида {не ключ} → {неключевые атрибуты}.
Определение. Отношение находится в третьей нормальной форме относительно заданного множе-
ства функциональных зависимостей тогда и только тогда, когда оно находится в первой нормальной
форме и все функциональные зависимости неключевых атрибутов навязаны объявлениями (первич-
ного и кандидатных) ключей.
Таким образом, в третьей нормальной форме каждый неключевой атрибут зависит от ключа пол-
ностью и не зависит ни от чего другого.
Конец определения.
Следующее отношение Сотрудники не находится в третьей нормальной форме:
Сотрудники(№ таб, Ф, И, О, КодД, Разряд, Оклад)

{КодД, Разряд} → {Оклад}
Примечание. Здесь произошло смешение понятий Сотрудники и ДолжностейРазряды •

После приведения к третьей нормальной форме путем декомпозиции отношения Сотрудники по-
лучим
ДолжностейРазряды(КодД, Разряд, Оклад)

primary key(КодД, Разряд)
Сотрудники(№ таб, Ф, И, О, КодД, Разряд)

foreign key(КодД, Разряд) references ДолжностейРазряды(КодД, Разряд)
Примечание. Обратим внимание на то, что в отношении Сотрудники атрибут КодД является одновремен-
но атрибутом двух различных внешних ключей •
В данном примере все функциональные зависимости оказались навязанными объявлениями клю-
чей, и дальнейшая нормализация не потребовалась. Однако в общем случае схема отношения, на-
ходящегося в третьей нормальной форме, может иметь ограничения функциональных зависимостей
для ключевых атрибутов:
Отношение3NF(ключевые атрибуты, неключевые атрибуты)

{не ключ} → {ключевые атрибуты}
5.2.4. Нормальная форма Бойса-Кодда (Boyce, Codd; NFBC))

Усиленной третьей нормальной формой является форма Бойса-Кодда. В ней требование о навязыва-
нии функциональных зависимостей объявлениями (первичного и кандидатных) ключей распростра-
няется и на ключевые атрибуты. Таким образом, в форме Бойса-Кодда ненавязанных ограничений
функциональных зависимостей нет:
ОтношениеNFBC(ключевые атрибуты, неключевые атрибуты)
Примечание. Здесь нет ненавязанных ограничений функциональных зависимостей. Но на отношение

могут быть наложены и другие ограничения, не связанные с понятием функциональных зависимостей •
Всегда ли можно отношение, находящееся в третьей нормальной форме с ненавязанными ограни-
чениями {не ключ} → {ключевые атрибуты}, привести к форме Бойса-Кодда?
Рассмотрим пример отношения R с атрибутами X, Y, Z, находящего в третьей нормальной форме,
но не находящегося в форме Бойса-Кодда:
R(X, Y, Z)
primary key(X, Y)
{Z} → Y}
Если, как обычно, провести декомпозицию так, чтобы ненавязанная функциональная зависимость
{Z} → {Y} была навязана объявлением ключа Z в выделяемом отношении R1(Z, Y), то получим
R1(Z, Y)
primary key(Z)
R2(X, Z)
foreign key(Z) references R1(Z)
Но что объявить ключом в отношении R2? Построим табличный пример для исходного отношения
R (рис. 5.4). Пример показывает, что в отношении R2(X, Z) ≡ R[X, Z] ни X, ни Z не могут быть
ключами. Следовательно, ключом будет их пара:
Рис. 5.4.: Пример допустимого состояния R
R1(Z, Y)
primary key(Z)
R2(X, Z)
primary key(X, Z)
foreign key(Z) references R1(Z)
{X, Y} → {Z}
Декомпозиция исходного отношения R связана с разрушением его первичного ключа, который
навязывал функциональную зависимость {X, Y} → {Z}. Поэтому в варианте 2 ее следует добавить
в качестве ограничения. Но это ограничение выражено в терминах атрибутов обоих отношений,
что означает невозможность их независимой модификации. Данный пример ограничения является
примером ограничения функциональной зависимости на уровне базы данных, так как здесь огра-
ничение накладывается на два (но в общем случае может накладываться и на более чем два) отно-
шения базы данных. Все ранее рассмотренные примеры функциональных зависимостей относились
к одному отношению, то есть формулировались на уровне отношения.
Как в варианте 1, так и в варианте 2 для контроля ограничения функциональной зависимости
необходимо прибегать к использованию триггеров. Но в варианте 1 (отношение находится в 3NF)
триггер будет оперировать кортежами одного отношения, тогда как в варианте 2 (отношения нахо-
дятся в NFBC, но они не являются независимыми) – двумя. Первый вариант проще.
Таким образом, на практике обычно ограничиваются приведением отношений к третьей нормаль-
ной форме (что всегда возможно). В большинстве случаев при этом оказывается, что отношения
находятся и в форме Бойса-Кодда. Контроль над ограничениями, не связанными с понятием функ-
циональных зависимостей, реализуют с помощью триггеров.
Примечание. Ситуации, когда отношение находится в 3NF, но не находится в NFBC, крайне редки на
практике •
Из определений нормальных форм следует их вложенность, иллюстрируемая диаграммой на рис. 5.5.
По отношению к третьей нормальной форме вторая форма является ослабленной, а форма Бойса-
Кодда – усиленной.
Отметим важность того, что понятия нормальных форм вводятся по отношению к заданному множеству
функциональных зависимостей. Например, следующее отношение Сотрудники не находится в тре-
тьей нормальной форме:
Сотрудники(№ таб, Ф, И, О, КодД, Разряд, Оклад)

Рис. 5.5.: Диаграмма вложений нормальных форм

{КодД, Разряд} → {Оклад}
Но если в организации оклады сотрудникам устанавливаются персонально, безотносительно к

должностям и разрядам, то тогда ограничение функциональной зависимости {КодД, Разряд} →
{Оклад} снимается и отношение Сотрудники становится отношением в третьей нормальной форме,
а точнее, в форме Бойса-Кодда.
5.2.5. Пример построения нормализованных схем отношений

Практическое задание. Представить в третьей нормальной форме данные об организациях, их
отделах и сотрудниках. Для идентификации организаций используется суррогатный ключ. Отделы
уникально нумеруются в пределах организации. Сотрудники идентифицируются табельными номе-
рами, уникальными в пределах организации.
Решение. Заданными являются следующие функциональные зависимости:
• {КодОрг} → данные об организации
• {КодОрг, № отд} → данные об отделе организации
• {КодОрг, № таб} → данные о сотруднике организации
Построение схем начинаем со схем независимых отношений, так что каждое отношение будет
ссылаться только на предыдущие:
Организации(КодОрг, Наименование)
primary key(КодОрг)
Отделы(КодОрг, № отд, Наименование)

primary key(КодОрг, № отд)
foreign key(КодОрг) references Организации(КодОрг)
Сотрудники(КодОрг, № таб, № отд, Ф, И, О)

primary key(КодОрг, № таб)
foreign key(КодОрг, № отд) references Отделы(КодОрг, № отд)
Все представленные здесь отношения находятся в третьей нормальной форме, а точнее, в форме
Бойса-Кодда.
Примечание. Часто говорят о третьей нормальной форме даже в случае, когда имеет место форма Бойса-
Кодда. Но если отношение находится в 3NF, но не в NFBC, то это имеет смысл подчеркивать •

Функциональные зависимости
• Понятие нормальных форм относится к OLTP или OLAP-системам?
• Определите понятие ограничения функциональной зависимости.
• К какому уровню относится ограничение функциональной зависимости?
• Приведите пример изображения функциональной зависимости.
• Как понимать фразу «объявления (первичных и кандидатных) ключей навязывают схеме отно-
шения соответствующие ограничения функциональных зависимостей»?
• Сформулируйте и докажите правила вывода Армстронга (рефлексивность, пополнение, псевдо-

транзитивность).
• Какая функциональная зависимость называется рефлексивной?
• Сформулируйте правило транзитивности.

• Сформулируйте и докажите производные правила от правил вывода Армстронга (тривиаль-
ность, аддитивность, проективность).
• Докажите независимость системы правил рефлексивности, пополнения и псевдотранзитивно-

сти.
• Сформулируйте понятие полноты системы правил вывода Армстронга.
Нормальные формы
• Какими способами могут быть реализованы ограничения, накладываемые заданными множе-

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

их комбинации?
• Сформулируйте понятие отношения, находящегося в 1NF.
• Какими способами отношение может быть приведено к 1NF?
• Какой атрибут называется ключевым?
• Какие ограничения функциональных зависимостей не навязаны объявлениями ключей в схеме

отношения, находящейся в 1NF?
• Какая функциональная зависимость называется полной?

• В чем цель приведения отношения к 2NF? Имеет ли 2NF самостоятельное значение?
• Сформулируйте понятие отношения, находящегося в 3NF. Приведите пример.
• Сформулируйте понятие отношения, находящегося в NFBC.
• Всегда ли отношение может быть приведено к 3NF? А к NFBC (если иметь в ввиду декомпо-
зицию на независимые отношения)?
• Почему понятие нормальных форм вводится по отношению к заданному множеству функцио-

нальных зависимостей?
Часть V.
Модуль 4
6. Проектирование схем баз данных
Наиболее распространенным средством абстрактного представления схем баз данных на логическом
уровне является модель «сущность-связь» (ER-модель, Entity-Relationship model). Элементами моде-
ли являются классы сущностей, их атрибуты и связи.
Примечание. Далее диаграммы, составляющие графическую основу модели, изображаются в стиле уни-
фицированного языка моделирования UML •
Класс сущностей – это как бы «лишенный методов» класс объектов в смысле объектно-ориентированног
программирования. Он представляет собой множество реальных или абстрактных «чего-то», обла-
дающих общими атрибутами. Отдельный элемент этого множества называется экземпляром класса
сущностей.
Каждый класс сущностей может характеризоваться любым числом атрибутов и иметь произволь-
ное число связей с другими классами.
Связь между двумя классами сущностей может характеризоваться наименованием и кратно-
стью роли класса в связи, а также наименованием связи (безотносительно к роли) Типичными
кратностями являются:
1) 1 – один,
2) 0 . . . 1 – не-более-один,
3) 0 . . . ∞ – много («много» допускает и «ничего»),
Рис. 6.1.: Диаграмма со связью типа один-ко-многим
4) 1 . . . ∞ – один-или-более.
Примечание. Символ ∞ по техническим причинам может заменяться, например, на n •

Связь изображается в виде линии, соединяющей классы сущностей. Согласно следующей диа-
грамме каждая касса имеет много билетов, а каждый билет находится в одной кассе рис. 6.1.
Наиболее важными типами связей являются:
1) 1 : 1 – один-к-одному,
2) 1 : 0 . . . ∞ – один-ко-многим (кратко 1:М),
3) 0 . . . ∞ : 1 – многие-к-одному (М:1, обращение 1:М),
4) 0 . . . ∞ : 0 . . . ∞ – многие-ко-многим (М:М).
Другие важные типы связей получаются заменой кратности один на не-более-один.

При переходе к физическому уровню классы сущностей преобразуются в таблицы реляционной
базы данных для конкретной СУБД. Связи реализуются с помощью объявлений внешних ключей
таблиц, ссылающихся на первичные или кандидатные ключи других таблиц.
6.1. Уровни логической модели
Выделяют три уровня логической модели, различающиеся по глубине представления информации
о структуре данных. Этим уровням соответствуют диаграммы
1) презентационные,
2) ключевые,
3) полные атрибутивные.
Презентационные диаграммы описывают основные классы сущностей и их связи. Ключи могут

не описываться и, соответственно, связи не детализироваться, так что допустимыми являются связи
многие-ко-многим, а также составные и многозначные атрибуты. Такие диаграммы используются
для презентаций и консультаций с экспертами предметной области.
Примечание. На презентационных диаграммах классы сущностей удобно именовать в единственном чис-
ле, так как атрибуты классов не указываются или указываются в минимальном объеме, так что такой класс
сущностей воспринимается скорее как экземпляр класса сущностей •
Ключевые диаграммы описывают все классы сущностей и их связи в терминах первичных клю-
чей. Связи многие-ко-многим детализируются. Многозначные атрибуты преобразуются в классы
сущностей. Но однозначные атрибуты все еще могут быть представлены не полностью или описаны
как составные. Таким образом, ключевые диаграммы предполагают в дальнейшем лишь расщепление
составных атрибутов и «навешивание» дополнительных атрибутов на описанные классы сущностей.
На ключевых диаграммах классы сущностей удобно именовать во множественном числе, так как
атрибуты этих классов более или менее представлены на диаграммах.
Примечание. Почему ключевые диаграммы основываются именно на первичных ключах?
Во-первых, все проектирование схемы базы данных можно вести так, как будто каждый выделяемый
класс сущностей обладает единственным ключом. Просто при последующем переходе к полной атрибутивной
диаграмме следует дополнить классы сущностей кандидатными ключами. Например, можно дополнить данные
о сотрудниках (с табельным номером в качестве первичного ключа) паспортными данными и ИНН.
Во-вторых, первичные ключи не допускают null-значений, и это абсолютно гарантируется всеми СУБД.
Идентификация экземпляра класса сущностей с неопределенным идентификатором, понятно, не возможна.
В-третьих, первичные ключи всегда выбираются наиболее лаконичным образом.
В-четвертых, в качестве первичных часто используются суррогатные ключи, полезные тем, что повыша-
ют уровень абстракции рассуждений. Суррогатные ключи осмысленны в пределах одной базы данных. При
экспорте данных в другую базу их следует исключить. В свою очередь при импорте данных им могут быть
назначены суррогатные ключи базы-импортера.
И, наконец, в пятых – обычно СУБД поддерживают наибольшую производительность при выполнении
связанных запросов в случае использования именно первичных ключей. •
Полные атрибутивные диаграммы наиболее детально описывают все классы сущностей, их ат-
рибуты и связи. Как правило, представляют данные в третьей нормальной форме (3NF). Однако
особенности конкретных СУБД при этом все еще не учитываются и, в частности, тип данных
конкретизируется лишь в той мере, в какой это необходимо для логического уровня моделирования.
На полных атрибутивных диаграммах иногда бывает удобно перейти от ссылок внешних ключей
на первичные ключи к ссылкам на кандидатные ключи. Например, в базе данных организации
сотрудник может идентифицироваться табельным номером как первичным ключом, и ИНН как
кандидатным ключом. Но данные для налоговой службы, скорее всего, будут ссылаться по ИНН на
кандидатный ключ данных о сотруднике.
6.2. Миграция ключей и виды связей
Процесс установления связей между классами сущностей, называемый миграцией ключей, связан
с переносом (простого или составного) первичного ключа одного класса сущностей, называемого
родительским, в другой класс, называемый дочерним.
В дочернем классе атрибуты мигрировавшего ключа получают статус атрибутов внешнего ключа
и при этом могут участвовать или не участвовать в формировании его первичного ключа. Таким
образом, при миграции первичного ключа из родительского класса в дочерний в дочернем классе
возникает внешний ключ, ссылающийся на первичный ключ родительского класса.
Введем маркеры атрибутов:
1) PK – атрибут (единственного) первичного ключа (primary key),
2) FK – атрибут (некоторого) внешнего ключа (foreign key),
3) PF – атрибут первичного/внешнего ключа.

Примечание. Для маркировки атрибутов первичного/внешнего ключа часто применяют маркер PF K •
Атрибут первичного/внешнего ключа входит в состав (единственного) первичного ключа и одно-
временно в состав (некоторого) внешнего ключа.
Таким образом, все атрибуты класса сущностей с маркерами PK и PF образуют (в совокупности)
первичный ключ. Атрибут с маркером PF или FK входит хотя бы в один внешний ключ, но может
входить и в несколько внешних ключей одновременно. Конкретные вхождения определяются при
установлении ссылок внешних ключей дочерних классов на первичные ключи родительских классов.
Атрибут PK первичного ключа родительского класса при миграции в дочерний классе может
получить статус PF или FK, что можно символически изобразить в виде двух следующих схем
миграции атрибутов первичного ключа:
1) PK 7→ PF
2) PK 7→ FK
Каждый атрибут первичного ключа может мигрировать по любой из этих схем. Но всевозмож-
ные комбинации таких составных миграций можно разбить на два класса со следующими схемами
миграции первичного ключа:
1) ∀ PK (PK 7→ PF)
2) ∃ PK (PK 7→ FK)
Первая схема миграции означает, что каждый атрибут первичного ключа родительского класса
переносится в состав первичного ключа дочернего класса. Такая связь называется идентифициру-
ющей, так как все атрибуты родительского ключа участвуют в идентификации дочерней сущности.
Вторая схема миграции означает, что некоторые атрибуты первичного ключа родительского класса
переносятся в состав неключевых атрибутов дочернего класса. Такая связь называется неиденти-
фицирующей, так как не все атрибуты родительского ключа участвуют в идентификации дочерней
сущности.
Идентифицирующая связь может быть двух видов в зависимости от того, полностью или непол-
ностью (частично) атрибуты мигрировавшего ключа формируют первичный ключ дочернего класса.
Полностью идентифицирующая связь называется также категориальной.
Неидентифицирующая связь может быть также двух видов, но в зависимости от того, запрещены
ли null-значения для всех атрибутов мигрировавшего ключа, или для некоторых разрешены. Если
запрещены, то неидентифицирующая связь называется обязательной. Если разрешены, то необяза-
тельной.
Этих четырех декларативно поддерживаемых СУБД видов связей, – полностью и неполностью
идентифицирующих, обязательных и необязательных неидентифицирующих, – достаточно для боль-
шинства задач, возникающих на практике. Нестандартные виды связей должны поддерживаться
процедурно с помощью триггеров.
Важно отметить, что на презентационных диаграммах разработчиком устанавливаются проек-
тируемые(требующие последующей реализации) кратности на концах связей. Например, между
сущностями Отдел и Сотрудник при проектировании может быть установлена связь типа не-более-
один-ко-многим (0 . . . 1 : 0 . . . ∞), один-ко-многим (1 : 0 . . . ∞), многие-ко-многим (0 . . . ∞ : 0 . . . ∞)
или, скажем, два-ко-многим (2 : 0 . . . ∞). Во всех случаях здесь каждому отделу разрешается иметь
много сотрудников. Но в первом случае каждый сотрудник может вообще не числиться или чис-
литься только в одном отделе. Во втором – обязан числиться в одном отделе. В третьем – может
числиться во многих отделах, а в последнем случае обязан числиться в двух отделах (совместитель).
Выбор того или иного типа устанавливаемых связей определяется правилами, установленными для
предметной области проектируемой базы данных.
При переходе к ключевым диаграммам ситуация иная. Здесь уже представлены спроектирован-
ные (реализованные) кратности на концах связей. Эти кратности являются следствием вида уста-
новленных связей. Но возможностей, предоставляемых механизмом миграции ключей, может быть
недостаточно для выражения всех требований, представленных на презентационных диаграммах.
Тогда при изображении классов сущностей следует указать необходимость их поддержки, включив
описания или ссылки на описания дополнительных ограничений и используемых триггеров в секцию
ограничений (рис. 6.2).
Между родительским и дочерним классами сущностей устанавливаются различные типы связей
в зависимости от вида связи (рис. 6.3).
Почему возникают такие кратности? Рассмотрим примеры, соответствующие видам связи (рис. 6.4,
6.5).
Рис. 6.2.: Изображение класса сущностей
На родительском конце связи только в последнем случае из-за возможности появления среди
значений внешнего ключа null-значений устанавливается необязательная связь (допускающая крат-
ность 0). В остальных случаях устанавливается кратность 1, так как согласно ограничению ссылоч-
ной целостности значению внешнего ключа должно быть сопоставлено значение первичного ключа
родительской сущности. Но оно может быть лишь одно, так как значения первичного ключа уни-
кальны.
На дочернем конце связи все связи являются необязательными (допускают кратность 0), так как
это не противоречит ограничениям ссылочной целостности – запрещено лишь появление висящих
дочерних сущностей. Значит, значению первичного ключа родительской сущности может быть и не
сопоставлено значение внешнего ключа дочерней сущности, но если оно сопоставлено, то только в
первом случае оно будет единственным, так как тогда значения внешнего ключа будут уникальными.
Рис. 6.3.: Типы связей в зависимости от вида связи
Рис. 6.4.: Миграция в PF
Рис. 6.5.: Миграция в FK
6.3. Классификация кластеров
В процессе моделирования для повышения уровня абстракции рассуждений используются такие
понятия, как ассоциация, обобщение, композиция, агрегация. Все эти понятия представляют со-
бой некоторые группы классов объектов (сущностей), тесно взаимосвязанных между собой. Такие
группы называются кластерами (cluster – гроздь, пучок, группа, скопление).
Но откуда возникли эти кластеры? Нельзя ли придумать еще какие либо кластеры? Как их выде-
лить из всего многообразия возможных взаимосвязей классов?
Проведем классификацию кластеров, исходя из числа родительских и дочерних классов сущно-
стей, представленных в нем. С учетом того, что родительский и дочерний классы могут совпадать,
получим три группы кластеров.
Группа 1. Родительский и дочерний классы сущностей совпадают. Это означает связь класса
сущностей с самим собой. Такая связь называется рекурсивной. Можно выделить два важных вида
рекурсивных связей:
1) иерархическая рекурсия, позволяющая описывать иерархические структуры (деревья),
2) сетевая рекурсия, позволяющая описывать сетевые структуры (графы).
Группа 2. Несколько родительских классов сущностей и один дочерний класс. Связи между клас-
сами могут быть произвольного вида. Такие кластеры приводят в реляционной модели к понятию
ассоциации (дочерний класс ассоциирует, объединяет, родительские классы).
Группа 3. Один родительский и несколько дочерних классов. В зависимости от вида устанавлива-
емых между классами связей получим следующую классификацию кластеров:
1) обобщение – связи категориальные (полностью идентифицирующие);

2) композиция – связи обязательные на родительском конце связи;
3) агрегация – связи необязательные на родительском конце связи.
Примечание. Часто композиция называется композитной агрегацией и рассматривается как усиленная

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

6.4.1. Абстрактная схема
Связь класса сущностей с самим собой называется рекурсивной (иногда такую связь называют «ры-
боловным крючком»). Рекурсивная связь типа не-более-один-ко-многим (0 . . . 1 : 0 . . . ∞) называется
иерархической.
Иерархическая рекурсия определяет связь типа предок/потомок и позволяет хранить древовид-
ную иерархию. В иерархии предок (экземпляр родительского класса сущностей) может иметь много
потомков (экземпляров дочернего класса сущностей), но потомок имеет не более одного предка.
Узел иерархии может выступать в роли и предка, и потомка. Один из узлов в иерархии предка не
имеет (корень).
В иерархической рекурсивной связи один и тот же класс сущностей является и родительским,
и дочерним одновременно. При задании иерархической рекурсивной связи первичный ключ должен
мигрировать в качестве внешнего в состав неключевых атрибутов того же класса сущностей, то есть
Рис. 6.6.: Презентационная диаграмма
такая связь может быть только неидентифицирующей, и, кроме того, необязательной. В противном
случае null-значения для внешнего ключа были бы не допустимы, и рекурсия была бы бесконечной.
Атрибуты не могут появляться дважды в одном классе сущностей под одним и тем же именем.
Поэтому атрибуты мигрировавшего ключа обязательно должны получить имя роли.
Таким образом, в иерархической рекурсии атрибуты узла расширяются атрибутом (внешним клю-
чом), представляющим необязательную ссылку на первичный ключ узла – непосредственного пред-
ка.
Построим абстрактные диаграммы (рис. 6.6, 6.7), реализующие иерархическую рекурсию в реля-
ционной модели, и приведем пример в табличной форме (рис. 6.8).
Как прийти к подобным построениям? Пусть есть некоторое множество узлов, определяемых кодом
узла КодУ и некоторыми атрибутами:
Узлы(КодУ, Атрибуты)
primary key(КодУ)
Подчеркнем, что пока это множество узлов, а не их иерархия. Каждый узел в иерархии имеет не
более одного предка (корень предка не имеет). Поэтому достаточно просто ввести дополнительный
атрибут, допускающий null-значения и ссылающийся на этого предка:
Рис. 6.7.: Ключевая диаграмма
Примечание. Здесь под Атрибутами, понятно, подразумеваются собственные атрибуты класса сущностей,
не имеющие отношения к ключам (ключи – это тоже атрибуты) •
Рис. 6.8.: Пример в табличной форме

УзловИерархия(КодУ_Предок: null, КодУ, Атрибуты)
foreign key(КодУ_Предок) references УзловИерархия(КодУ)
Примечание. Заметим, что в реляционной модели с помощью механизма внешних ключей реализуется
принцип «дочерние сущности знают о родительских, но не наоборот». В объектно-ориентированных моделях
часто применяется обратный принцип, при котором родительские классы объектов содержат в себе данные о
дочерних объектах •
6.4.2. Обобщения
Может ли данная схема иерархической рекурсии описывать не одну иерархию, а несколько однотип-
ных иерархий (то есть не дерево, а лес)? Да, так как число корневых узлов в схеме хранения данных
может быть произвольным. Число хранимых деревьев – это число null-значений, появляющихся в
значениях внешнего ключа КодУ_Предок.
Что делать, если дерево взвешенное, то есть каждой дуге сопоставлены некоторые атрибуты?
Включить их в число атрибутов класса УзловИерархия и разрешить принимать им null-значения,
так как для корневых узлов значения этих атрибутов не определены.
Как описать более сложную иерархию, например, с двумя предками для описания отношений отец-
дитя, мать-дитя? Так как число предков ограничено двумя, то отношение, описывающее множество
людей, расширяется двумя внешними ключами, ссылающимися на предка-отца и предка-мать:
ОтцыМатериДети(КодЧ_Отец: null, КодЧ_Мать: null, КодЧ, Атрибуты)

primary key(КодЧ)
foreign key(КодЧ_Отец) references ОтцыМатериДети(КодЧ)
foreign key(КодЧ_Мать) references ОтцыМатериДети(КодЧ)
Дальнейшие обобщения могут быть связаны с введением нескольких разнотипных иерархий и
установлением перекрестных ссылок между ними.
Как бы то ни было, основная идея реализации иерархии и ее обобщений в реляционной модели
проста: коль скоро предков ограниченное число, то можно расширить классы, описывающие множе-
ства несвязанных сущностей, внешними ключами, ссылающимися на этих предков.
6.4.3. Пример реализации иерархической рекурсии

Практическое задание. Построить реляционную модель, описывающую иерархическую подчинен-
ность подразделений в организации. При этом
1) Построить презентационную диаграмму. Указать кратности и роли в связи.
2) Построить ключевую диаграмму. Привести маркеры атрибутов ключей и указать кратности свя-
зей. Подразделения идентифицировать мнемокодами (обновление мнемокода является осмыс-
ленным). Какой вид связи устанавливается между подразделением и вышестоящим подразде-
лением?
3) Сформулировать и записать на псевдокоде декларативное правило поддержания ссылочной
целостности. Обосновать на содержательном уровне выбор правила.
4) Привести пример в табличной форме для организации, имеющей 6 подразделений со следую-
щей структурой подчиненности: 1(2(3,4),5(6)).
Решение. Презентационная и ключевая диаграммы представлены на рис. 6.9, 6.10 соответственно.

Между подразделением и вышестоящим подразделением может быть установлена лишь необяза-
тельная неидентифицирующая связь.

Приведем фрагмент оператора создания базового отношения Подразделения с определением пра-
вил поддержания ссылочной целостности:
create table Подразделения

МнемоП_Выше null
primary key(МнемоП)
foreign key(МнемоП_Выше) references Подразделения(МнемоП)
on update cascade
on delete set null
При обновлении мнемокода подразделения (МнемоП) здесь применяется правило каскадного об-
новления (on update cascade), так что все непосредственно нижестоящие подразделения (посред-
ством мнемокода МнемоП_Выше) станут ссылаться на это новое значение мнемокода. В рассмат-
риваемом ниже примере при изменении значения первичного ключа (МнемоП) c 2 на 20 значения
внешнего ключа (МнемоП_Выше) также изменятся с 2 на 20.
При удалении подразделения применение правила присвоения null-значений (on delete set null)
приведет к тому, что все непосредственно нижестоящие подразделения приобретут самостоятельный
статус и станут корнями иерархий (например, при расформировании полка составляющие его бата-
льоны станут отдельными). В рассматриваемом ниже примере при удалении данных о подразделении
со значением первичного ключа (МнемоП), равным 2, значения внешнего ключа (МнемоП_Выше)
изменятся с 2 на null-значение.
Пример в табличной форме для организации со структурой 1(2(3,4),5(6)) приведен на рис. 6.11
Построения в данном примере укладываются с точностью до наименований в схему абстрактных
построений в терминах «Узлы – КодУ – КодУ_Предок»: эти термины заменяются на «Подразделения
– МнемоП – МнемоП_Выше».
6.5. Сетевая рекурсия

Напомним, что связь класса сущностей с самим собой называется рекурсивной (иногда такую связь
называют «рыболовным крючком»). Рекурсивная связь типа многие-ко-многим (0 . . . ∞ : 0 . . . ∞)
называется сетевой.
Сетевая рекурсия определяет связь типа предок/потомок между узлами сети. В сети предок может
иметь много потомков и, наоборот, потомок может иметь много предков. Узел сети может выступать
в роли и предка, и потомка.
Для детализации (разрешения) связи многие-ко-многим (0 . . . ∞ : 0 . . . ∞) необходимо создать
новый класс сущностей, содержащий ссылки на предка и потомка в связи предок/потомок. Такой
Примечание. Здесь в силу симметрии связи указывается ее наименование, а не наименования ролей •
класс в общем случае называется классом ассоциативных сущностей. Если класс ассоциативных
сущностей не имеет собственных дополнительных атрибутов, то он называется именующим, так как
каждый экземпляр класса «именует» связь предок/потомок путем ссылок на них.
Таким образом, первичный ключ класса сущностей, представляющих узлы сети, должен дважды
мигрировать в класс ассоциативных сущностей. В этом классе мигрировавшие ключи в совокуп-
ности должны образовывать составной первичный ключ. Поэтому устанавливаемые связи будут
неполностью идентифицирующими.
Атрибуты не могут появляться дважды в одном классе сущностей под одним и тем же именем.
Поэтому атрибуты мигрировавшего ключа обязательно должны получить имя роли.
Построим абстрактные диаграммы рис. 6.12, 6.13, реализующие сетевую рекурсию в реляционной
модели, и приведем пример в табличной форме (рис. 6.14).
Граф, описываемый приведенной схемой, является ориентированным (упоминание об этом для
краткости терминологии мы будем опускать), и потому для обозначения связи между узлами ис-
пользуется термин «дуга».
Примечание. Дуга, связывающая узлы, ориентирована от одного узла к другому, тогда как «ребро»,
связывающее узлы, ориентации не имеет •
Примечание. При изображении родительских и дочерних классов удобно по возможности придерживаться
следующего правила: изображать родительский класс слева, а дочерний справа, так как родительский класс
не зависит от дочернего, а дочерний зависит от родительского •

Как прийти к подобным построениям? Пусть, как и в случае иерархической рекурсии, есть неко-
торое множество узлов, определяемых кодом узла КодУ и некоторыми атрибутами:
Узлы(КодУ, Атрибуты)
Подчеркнем, что пока это множество узлов, а не их сеть. Каждый узел в сети может иметь много
предков и много потомков. Поэтому ясно, что расширение атрибутов узла ссылками на предков и
(или) потомков невозможно. Но как можно образовать связь между узлами, то есть, как можно
описать дугу, идущую из одного узла в другой? Очевидно, парой ссылок (КодУ_Из, КодУ_На). Из
этих элементарных соображений и возникает класс ассоциативных (в данном случае именующих)
сущностей Дуги:
Дуги(КодУ_Из, КодУ_На)
primary key(КодУ_Из, КодУ_На)
foreign key(КодУ_Из) references Узлы(КодУ)
foreign key(КодУ_На) references Узлы(КодУ)
Ключом здесь будет пара ссылок на узлы, так что узлы в одном направлении могут соединяться не
более чем одной дугой.
6.5.2. Сетевая реализация иерархической рекурсии

Сеть (граф) есть обобщение понятия иерархии (дерева). Но как это реализовать? Надо сделать так,
чтобы в сетевой рекурсии из каждого узла могло выходить не более одной дуги. Это означает,
что в классе Дуги значения атрибута КодУ_Из должны быть уникальными. Следовательно, атрибут
Рис. 6.15.: Ключевая диаграмма. Сетевая реализация иерархической рекурсии
Примечание. Здесь тип связи по атрибуту КодУ_Из заменился на один-к-не-более-один (1 : 0 . . . 1) •
КодУ_Из должен быть объявлен ключом. Для этого следует сменить статус атрибута КодУ_На с PF
на FK и при этом наследовать запрет null-значений (рис. 6.15).
Здесь между классами Узлы и Дуги устанавливаются полностью идентифицирующая и обязатель-
ная неидентифицирующая связи.
Данный вариант реализации иерархической рекурсии отличается от ранее рассмотренного вариан-
та «УзловИерархия» тем, что теперь дуги вынесены в отдельный класс сущностей и класс сущностей
Узлы не смешен с понятием их иерархии. Это может быть полезным на практике в случае, когда в
проектируемой схеме базы данных дуги выступают в качестве самостоятельных сущностей.
Что делать, если допускаются кратные дуги, то есть речь идет не о графе, а о мультиграфе?
Достаточно в класс Дуги включить дополнительный атрибут Кратность.
Что делать, если граф взвешенный, то есть каждой дуге сопоставлены некоторые атрибуты?
Включить их в число атрибутов класса Дуги.
Выше даже в случае рассмотрения мультиграфа речь шла, по-существу, о том, что узлы связыва-
ются не более чем одной дугой, на которую «навешиваются» атрибуты, в частности, кратность.
Примечание. В классе Дуги ключом является пара ссылок на узлы, и, следовательно, эта пара (дуга) не
может дублироваться •
Что делать, если каждая из кратных дуг мультиграфа должна характеризоваться своим набором
значений атрибутов? Следует ввести «индивидуальность» дуги, соединяющей узлы. Например, дан-
ные об авиарейсах из пункта A в пункт B могут характеризоваться временем отправления, временем
прибытия, количеством посадочных мест и т.д. В данном случае индивидуальность дуги – это номер
рейса из пункта A в пункт B, и его следует включить в состав атрибутов первичного ключа:
Пункты(КодП, Название)
primary key(КодП)
Рейсы(КодП_Из, КодП_На, № рейса, ВремяОтпр, ВремяПриб, Мест)

primary key(КодП_Из, КодП_На, № рейса)
foreign key(КодП_Из) references Пункты(КодП)
foreign key(КодП_На) references Пункты(КодП)
Если атрибут № рейса не включить в состав первичного ключа, то число возможных рейсов из
одного пункта в другой будет не более одного.
Как и иерархическая, сетевая рекурсия допускает многочисленные обобщения.
Основная идея реализации сети и ее обобщений в реляционной модели проста: создание класса
ассоциативных сущностей, описывающего связи элементов сети.
6.5.4. Пример реализации сетевой рекурсии
Практическое задание. Построить реляционную модель, описывающую сетевую взаимосвязь до-
кументов по ссылкам. При этом
1) Построить презентационную диаграмму. Указать кратности и наименование связи.
2) Построить ключевую диаграмму. Привести маркеры атрибутов ключей и указать кратности

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

целостности. Обосновать на содержательном уровне выбор правил.
4) Привести пример в табличной форме для следующего случая перекрестных ссылок документов
1-4: 1(3,4), 2(1), 4(1,2,3).
Решение. Презентационная и ключевая диаграммы представлены на рис. 6.16, 6.17 соответствен-

но.
Приведем фрагмент оператора создания базового отношения Ссылки с определением правил под-
держания ссылочной целостности:
create table Ссылки

primary key(МнемоД_Из, МнемоД_На)
foreign key(МнемоД_Из) references Документы(МнемоД)
on update cascade
on delete cascade,

foreign key(МнемоД_На) references Документы(МнемоД)
on update cascade
on delete restrict
При обновлении мнемокода документа (МнемоД) здесь применяются правила каскадного обновления
(on update cascade), так что все ссылки (МнемоД_Из и МнемоД_На) станут ссылаться на это новое
значение мнемокода. В рассматриваемом ниже примере при изменении значения первичного ключа
(МнемоД) 4 на 40 значения внешних ключей (МнемоД_Из и МнемоД_На) также изменятся с 4 на
40.
При удалении документа (МнемоД) применение правила каскадного удаления (on delete cascade)
для документа, из которого производится ссылка (МнемоД_Из), приведет к тому, что все ссылки из
этого документа также удалятся (если это не будет противоречить описываемому ниже правилу on
delete restrict).
При удалении документа (МнемоД) применение правила ограничения (on delete restrict) для до-
кумента, на который производится ссылка, приведет к тому, что документ не будет удален, если на
него имеются ссылки из каких-либо документов.
Пример в табличной форме для перекрестных ссылок документов 1-4 (1(3,4), 2(1), 4(1,2,3)) при-
веден на рис. 6.18. В примере на все документы имеются ссылки. Поэтому какой-либо документ
можно будет удалить, если предварительно из отношения Ссылки удалить ссылки на него.
Построения в данном примере укладываются с точностью до наименований в схему абстрактных
построений в терминах «Узлы – КодУ – Дуги – КодУ_Из – КодУ_На» : эти термины заменяются на
«Документы – МнемоД – Ссылки – МнемоД_Из – МнемоД_На».
6.6. Ассоциация
Ассоциация реализуется как взаимосвязь между несколькими родительскими и одним дочерним
классом, описываемая связями различных видов – полностью или неполностью идентифицирующи-
ми, обязательными или необязательными неидентифицирующими. Родительский класс может быть
и один, как, например, в сетевой рекурсии, но число связей, идущих от дочернего класса, должно
быть не менее двух (иначе теряется смысл ассоциации как «объединения»). Дочерний класс в ас-
социации в общем случае называется классом ассоциативных сущностей. В частном случае, когда
класс ассоциативных сущностей не имеет собственных дополнительных атрибутов и содержит толь-
ко атрибуты, мигрировавшие вместе с ключами из родительских классов, такой класс называется
классом именующих сущностей. Ассоциация называется n-арной, если число определяемых в ней
связей равно n (n ≥ 2).
Примечание. При n = 2 ассоциация называется бинарной, при n = 3 – тернарной •

Ассоциации используются, в частности, для детализации (разрешения) связей многие-ко-многим
(0 . . . ∞ : 0 . . . ∞).
6.6.1. Детализация связей многие-ко-многим

Построим абстрактные диаграммы (рис. 6.19, 6.20), детализирующие связь многие-ко-многим (0 . . . ∞ :
0 . . . ∞) в реляционной модели.
Приведенной схемой описывается двудольный граф (рис. 6.21), и потому для обозначения связи
между узлами используется термин «ребро».
Примечание. В двудольном графе множество его узлов разбивается на две такие части (доли), что концы
каждого ребра принадлежат разным частям •
Как прийти к подобным построениям? Пусть есть некоторые множества узлов, соответствующие
долям графа:
Рис. 6.21.: Пример двудольного графа

УзлыA(КодУA, Атрибуты)
primary key(КодУA)
УзлыB(КодУB, Атрибуты)
primary key(КодУB)
Примечание. Здесь, разумеется, собственные атрибуты классов сущностей УзлыA и УзлыB не обязаны
совпадать •
Ребра, связывающие эти узлы, описываются парой ссылок (КодУA, КодУВ). Из этих элементарных
соображений возникает класс ассоциативных (в данном случае именующих) сущностей Ребра:
Ребра(КодУA, КодУB)
primary key(КодУA, КодУB)
foreign key(КодУA) references УзлыA(КодУA)
foreign key(КодУB) references УзлыB(КодУB)
Ключом здесь будет пара ссылок на узлы, так что узлы разных долей могут соединяться не более
чем одним ребром. Естественно, как и в схемах реализации рекурсии, здесь возможны различные
обобщения.
Рассмотрим одно из обобщений, связанное с «индивидуализацией» дуг, в результате чего узлы
разных долей смогут соединяться произвольным числом ребер (двудольный мультиграф).
Пусть требуется описать график приема пациентов (рис. 6.22 и 6.23). Здесь атрибут Дата-время
включен в первичный ключ. Если этого не сделать, то для каждой пары врач-пациент можно было
бы зарегистрировать не более одной встречи.

Примечание. Здесь для краткости указан составной атрибут ФИО, что для ключевых диаграмм допустимо
•
В общем случае граф, моделируемый ассоциацией, может иметь произвольное число долей (k-
дольный граф или мультиграф, k ≥ 2).
6.6.3. Пример реализации ассоциации

Практическое задание. Построить реляционную модель, описывающую график встреч Заказчика
с Исполнителем при необязательном участии Консультанта. При этом
1) Построить презентационную диаграмму. Указать кратности.

связей. Участников встреч идентифицировать мнемокодами (обновление мнемокода является
осмысленным). Какие виды связей используются?

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

но.
Связи с классами Заказчики и Исполнители являются неполностью идентифицирующими, связь
с классом Консультанты – необязательной неидентифицирующей.
Приведем фрагмент оператора создания базового отношения График с определением правил под-
держания ссылочной целостности:
create table График

МнемоК null
primary key(МнемоЗ, МнемоИ, Дата-время)
foreign key(МнемоЗ) references Заказчики(МнемоЗ)
on update cascade
on delete cascade,
foreign key(МнемоИ) references Исполнители(МнемоИ)
on update cascade
on delete cascade,
foreign key(МнемоК) references Консультанты(МнемоК)
on update cascade
on delete set null
При обновлении значения любого мнемокода применяется правило каскадного обновления, так как
это полностью сохраняет содержательную часть хранимых данных. При удалении данных о Заказчи-
ках и Исполнителях помимо принятого правила каскадного удаления можно было бы использовать
правило ограничения restrict. При удалении данных о Консультанте применяется правило присвое-
ния null-значения, позволяющее сохранить данные о встречах Заказчика и Исполнителя.
Пример в табличной форме приведен на рис. 6.26.
Рис. 6.27.: Связь «обобщение-категория» в нотации UML
6.7. Обобщение
Обобщение реализуется как взаимосвязь одного родительского с несколькими дочерними классами,
описываемая категориальными связями, то есть полностью идентифицирующими. При обобщении
реализуется иерархия категорий (иерархия наследования). Родительский класс определяет класс
обобщенных сущностей, характеризуемых атрибутами, общими для сущностей дочерних классов
(категориальных сущностей).
Термин «обобщение» соответствует переходу от детализированных, категориальных сущностей к
обобщенной сущности. Обратный переход называется детализацией.
Иерархии категорий делятся на два типа – полные и неполные. В полной иерархии категорий
одному экземпляру обобщенной сущности обязательно соответствует экземпляр какой-либо катего-
риальной сущности. Если иерархия категорий еще не выстроена полностью и в классе обобщенных
сущностей могут существовать экземпляры, которые не имеют соответствующих экземпляров в
классе категориальных сущностей, то такая иерархия категорий будет неполной.
На презентационных диаграммах связь «обобщение-категория» удобно изображать в нотации
UML (рис. 6.27).
Построим абстрактные диаграммы, реализующие обобщение в реляционной модели (рис. 6.28,
Примечание. Вид при обобщении – это центральное место триады «род – вид – индивид». Стрелки,
идущие от категорий к обобщению, можно и не сливать •
6.29).
Полную или неполную иерархию категорий описывает данная схема реализации обобщения?
Неполную, так как это не противоречит кратностям, устанавливаемым на дочерних концах связей.
6.7.2. Пример реализации обобщения

Практическое задание. Построить реляционную модель, основанную на обобщенном понятии
Учащийся и описывающую категориальные понятия Школьник, Студент и Аспирант. При этом
1) Построить презентационную диаграмму.

Примечание. В родительский класс обобщенных сущностей выносятся АТРИБУТЫ, общие для всех
категориальных сущностей •

связей. Для идентификации учащегося использовать значение суррогатного ключа. Какой вид
связей используется?


но.
Примечание. Здесь для краткости указан составной атрибут ФИО, что для ключевых диаграмм допустимо
•
При обобщении связи могут быть только полностью идентифицирующими, то есть категориаль-
ными.
Приведем фрагмент оператора создания базового отношения Школьники (аналогично и для отно-
шений Студенты и Аспиранты) с определением правил поддержания ссылочной целостности:
create table Школьники

foreign key(КодУ) references Учащиеся(КодУ)
on delete cascade
Определять правило поддержания ссылочной целостности при обновлении родительского ключа

КодУ нет необходимости, так как этот ключ – суррогатный и обновлению не подлежит. Вместо
правила каскадного удаления могло бы быть сформулировано правило ограничения restrict, но не
set null, так КодУ в дочернем отношении является первичным ключом и null-значений не допускает.
6.8. Композиция
Композиция реализуется как взаимосвязь одного родительского с несколькими дочерними классами,
описываемая связями, обязательными на родительском конце. Это означает, что дочерние сущности
(компоненты) не могут существовать вне родительской сущности (композита).
Обязательными на родительском конце являются связи трех видов – полностью и неполностью
идентифицирующие и обязательные неидентифицирующие.
Но полностью идентифицирующие связи используются при обобщении. Почему они возникли при
композиции?
Все дело в идентификации компонента, принадлежащего композиту. Например, дом – это компо-
зит, состоящий из квартир и крыши. Как сослаться на крышу дома? По номеру дома. Следовательно,
класс сущностей Крыши будет связан с классом сущностей Дома с помощью полностью идентифи-
цирующей связи. Но в данном случае эта связь не имеет смысл «обобщение-категория», а имеет
смысл «композит-компонент».
Примечание. Крыша – это не дом, обладающий дополнительными специфическими свойствами, а часть
дома •
Различия в идентификации компонентов проявляются и случаях установления неполностью иден-
тифицирующих и обязательных неидентифицирующих связей. Обе связи устанавливают тип связи
один-ко-могим (1 : 0 . . . ∞) и в этом смысле аналогичны. Но рассмотрим пример композитной иерар-
хии «Дом – Подъезд – Квартира»:
Дома(№ Д)
primary key(№ Д)
Подъезды(№ Д, № П)
primary key(№ Д, № П)
foreign key(№ Д) references Дома(№ Д)
Квартиры(№ Д, № П, № кв)
primary key(№ Д, № кв)
foreign key(№ Д) references Дома(№ Д)
foreign key(№ Д, № П) references Подъезды(№ Д, № П)
Рис. 6.33.: Cвязь «композит-компонент» в нотации UML
Рис. 6.34.: Cвязь «композит-компонент» в нотации UML с указанием кратности
В композиции «Дом – Подъезд» устанавливается идентифицирующая связь, а в композиции

«Подъезд – Квартира» – неидентифицирующая.
На презентационных диаграммах связь «композит-компонент» удобно изображать в нотации UML
(рис. 6.33).
Если требуется подчеркнуть кратность вхождения компонента в композит, то ее можно указать
на дочернем конце связи (рис. 6.34).
Построим абстрактные диаграммы (рис. 6.35, 6.36), реализующие композицию в реляционной
модели.
Примечание. Например, для дома, как композита, видами компонентов могут быть подъезды, квартиры,
подвалы, крыша. Стрелки, как и в случае обобщения, можно и не сливать •
Примечание. Здесь проиллюстрирована возможность установления трех видов связей
«композит-компонент» •
6.8.2. Пример реализации композиции
Практическое задание. Построить реляционную модель, описывающую состав корпусов учебного
городка (корпуса, их аудитории и буфеты). Ввести обобщенное описание буфетов (общее число
посадочных мест и т.п.), так что корпус в этом смысле должен иметь не более одного буфета. При
этом

связей. Какой вид связей используется?


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

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

foreign key(№ К) references Корпуса(№ К)
on update cascade
on delete cascade
Здесь можно было бы применить правило ограничения restrict, но это ввиду большого числа
аудиторий существенно затруднило бы удаление данных о корпусах.
Рис. 6.40.: Связь «агрегат-компонент» в нотации UML
6.9. Агрегация
Агрегация реализуется как взаимосвязь одного родительского с несколькими дочерними классами,
описываемая связями, необязательными на родительском конце. Это означает, что дочерние сущно-
сти (компоненты) могут существовать вне родительской сущности (агрегата).
Необязательными на родительском конце являются связи единственного вида – необязательные
неидентифицирующие. Следовательно, компоненты агрегата, ссылающиеся на агрегат посредством
внешнего ключа, допускающего null-значения, существуют вне агрегата в случае, когда внешний
ключ имеет null-значение.
На презентационных диаграммах связь «агрегат-компонент» удобно изображать в нотации UML
(рис. 6.40).
Построим абстрактные диаграммы (рис. 6.41, 6.42), реализующие агрегацию в реляционной мо-
дели.
Примечание. Например, для двери, как агрегата, видами компонентов могут быть дверное полотно, ручка,
петли. Стрелки, как и в случаях обобщения и композиции, можно и не сливать •
6.9.2. Пример реализации агрегации
Практическое задание. Построить реляционную модель, описывающую маркированные компонен-
ты автомобиля (двигатель, шасси). При этом
связей. Списывание автомобиля предполагает списывание шасси, но не двигателя. Какие виды
связей используются?
Решение. Данный пример представляет агрегацию общего вида, когда часть компонентов мо-
гут, а часть не могут существовать вне агрегата. Согласно презентационной диаграмме (рис. 6.43)
предполагается, что разукомплектованный автомобиль может и не иметь шасси, но если шасси в
комплектацию входит, то оно одно. Число двигателей, приписанных автомобилю (с учетом запас-
ных), не ограничивается. Чтобы подчеркнуть это, на презентационной диаграмме явно указывается
соответствующая кратность.
Ключевая диаграмма представлена на рис. 6.44.
Здесь в секцию атрибутов класса Двигатели введен виртуальный атрибут, формула вычисления
которого указана в секции ограничений.
В классе Шасси внешний ключ, ссылающийся на номер автомобиля, объявлен кандидатным клю-
чом. В результате тип устанавливаемой обязательной неидентифицирующей связи изменяется с
один-ко-многим (1 : 0 . . . ∞) на один-к-не-более-одному (1 : 0 . . . 1). Такой вариант установления
связей часто полезен на практике.
Таким образом, связь с классом Двигатели является необязательной неидентифицирующей, а

с классом Шасси – обязательной неидентифицирующей. Однако в последнем случае вследствие
объявления внешнего ключа и в качестве кандидатного устанавливается требуемая связь типа 1 :
0 . . . 1.
Приведем фрагменты операторов создания базовых отношений Двигатели и Шасси с определением
правил поддержания ссылочной целостности:
create table Двигатели

[№ А] null
primary key(МаркерД)
foreign key(№ А) references Автомобили(№ А)
on update cascade
on delete set null
create table Шасси
[№ А] not null
primary key(МаркерШ)
candidate key(№ А)
foreign key(№ А) references Автомобили(№ А)
on update cascade
on delete cascade
Примечание. Здесь квадратные скобки, в которые должен быть заключен идентификатор № А, опускаются
в случаях, исключающих двусмысленность •
Согласно сформулированным правилам поддержания ссылочной целостности при изменении номе-
ра автомобиля проводится каскадное изменение и ссылок на него. При удалении данных об автомо-
биле разрывается связь с данными о двигателях, и удаляются данные о шасси.
6.10. Унификация атрибутов

Если при миграции ключей в один и тот же дочерний класс попадают совпадающие по смыслу
атрибуты из разных родительских классов, то эти атрибуты необходимо слить, то есть провести так
называемую унификацию атрибутов.
Например, в случае, когда сотрудник может работать в организации, числясь не более чем в одном
отделе, вначале получим ключевую диаграмма до унификации атрибутов (рис. 6.45).
В верхней части диаграммы установлена связь один-ко-многим (1 : 0 . . . ∞) между Организациями
и их Отделами. Отделы уникально идентифицируются своими кодами в пределах организации.
В левой части диаграммы установлена связь один-ко-многим (1 : 0 . . . ∞) между Организациями
и их Сотрудниками. Сотрудники уникально идентифицируются своими табельными номерами в
Рис. 6.45.: Ключевая диаграмма до унификации атрибутов
пределах организации.
В правой части диаграммы установлена связь не-более-один-ко-многим (0 . . . 1 : 0 . . . ∞) между
Отделами и Сотрудниками организации (не все сотрудники организации числятся в отделах).
Таким образом, атрибут КодОрг попадает в класс Сотрудники дважды – один раз из класса
Организации с маркером PF, и один раз из класса Отделы с маркером FK. При унификации атрибут
КодОрг получает статус атрибута первичного/внешнего ключа PF, поглощающего статус атрибута
внешнего ключа (рис. 6.46).
В заключение приведем фрагмент оператора создания базового отношения Сотрудники:
create table Сотрудники
КодОтд null
primary key(КодОрг, № таб)
Рис. 6.46.: Ключевая диаграмма после унификации атрибутов
foreign key(КодОрг, КодОтд) references Отделы(КодОрг, КодОтд)

Уровни логической модели
• Что понимается под классом сущностей и экземпляром класса сущностей?
• Что понимается под наименованием и кратностью роли класса в связи, наименованием связи?
• Укажите типичные кратности и их изображение.
• Приведите наиболее важные типы связей.
• Какому уровню представления информации о структуре данных соответствуют презентацион-

ные диаграммы?
• Какому уровню представления информации о структуре данных соответствуют ключевые диа-

граммы?
• Почему ключевые диаграммы основываются именно на первичных ключах?
• Какому уровню представления информации о структуре данных соответствуют полные атрибу-

тивные диаграммы?
Миграция ключей и виды связей

• Что понимается под миграцией ключей? Какие классы называются родительскими и дочерни-
ми?
• Укажите нотацию для маркеров атрибутов.
• Изобразите схемы миграции первичного ключа.
• Какая связь называется идентифицирующей? Полностью и неполностью идентифицирующей?
• Какая связь называется неидентифицирующей? Обязательной и необязательной неидентифи-

цирующей?
• Какие кратности (проектируемые или спроектированные) устанавливаются на концах связей

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

Классификация кластеров
• Как можно подойти к выделению кластеров сущностей? Укажите основания классификации.
Иерархическая рекурсия
• Какая рекурсивная связь называется иерархической?
• Постройте абстрактную презентационную диаграмму, реализующую иерархическую рекурсию
в реляционной модели.
• Постройте абстрактную ключевую диаграмму, реализующую иерархическую рекурсию в реля-

ционной модели. Приведите пример в табличной форме.
• Какие соображения лежат в основе реализации иерархической рекурсии?
• Может ли схема иерархической рекурсии описывать не одну иерархию, а несколько однотипных

иерархий (то есть не дерево, а лес)?
• Как в схеме иерархической рекурсии моделируется взвешенное дерево?
• Как описать более сложную иерархию, например, с двумя предками для описания отношений
отец-дитя, мать-дитя?
• Задание 1. Реализовать иерархическую рекурсию в реляционной модели данных. Для рассмат-

риваемого варианта

2) Построить ключевую диаграмму. Привести маркеры атрибутов ключей и указать кратно-
сти связей.
Вариант 1. Иерархическая подчиненность подразделений организации. Привести пример
в табличной форме для организации со структурой 1(2(3,4), 5(6)).
Вариант 2. Иерархическая подчиненность сотрудников организации. Привести пример в
табличной форме со структурой подчинения 3(4(5,6), 1(2)).
Вариант 3. Иерархическое вхождение одних агрегатов в другие. Привести пример в таб-
личной форме со структурой вхождения 5(4(6), 1(2,3)).
Вариант 4. Иерархическая система приказов, каждый из которых выполняется «во ис-
полнение» не более чем одного приказа. Привести пример в табличной форме для
системы приказов 6(5(4), 3(2,1)).
Сетевая рекурсия
• Какая рекурсивная связь называется сетевой?
• Когда класс ассоциативных сущностей называется именующим?
• Постройте абстрактную презентационную диаграмму, реализующую сетевую рекурсию в реля-

ционной модели.
• Постройте абстрактную ключевую диаграмму, реализующую сетевую рекурсию в реляционной

модели. Приведите пример в табличной форме.
• Ориентированный или неориентированный граф описывает абстрактная ключевая диаграмма?
• Какие соображения лежат в основе реализации сетевой рекурсии?

• В чем заключается сетевая реализация иерархической рекурсии?
• Как можно описать взвешенный граф?
• Как можно описать взвешенный мультиграф?
• Задание 1. Реализовать сетевую рекурсию в реляционной модели данных. Для рассматривае-

мого варианта

Вариант 1. Каждый документ может ссылаться на много документов. Привести пример в
табличной форме для случая следующих перекрестных ссылок: 1(3,4), 2(1), 4(1,2,3).
Вариант 2. Каждый город может быть связан авиарейсами со многими городами. Приве-
сти пример в табличной форме для случая следующих перекрестных ссылок: 3(1,2),
4(3), 2(3,1,2).
Вариант 3. Каждый документ может ссылаться на много документов. Привести пример в
табличной форме для случая следующих перекрестных ссылок: 3(1,2,3), 2(3,4), 4(1).
Вариант 4. Каждый приказ может выполняться во исполнение многих приказов. Приве-
сти пример в табличной форме для случая следующих перекрестных ссылок: 4(1),
2(1,4), 3(1,2,4).
Ассоциация
• Какой кластер сущностей называется ассоциацией?
• Когда класс ассоциативных сущностей называется именующим?
• Какая ассоциация называется n-арной?
• Постройте абстрактную презентационную диаграмму, детализирующую связь многие-ко-многим

(0 . . . ∞ : 0 . . . ∞) в реляционной модели.
• Постройте абстрактную ключевую диаграмму, детализирующую связь многие-ко-многим (0 . . . ∞ :

0 . . . ∞) в реляционной модели.
• Какой граф описывает абстрактная ключевая диаграмма, детализирующая связь многие-ко-

многим (0 . . . ∞ : 0 . . . ∞)?
• Какие соображения лежат в основе реализации связи многие-ко-многим (0 . . . ∞ : 0 . . . ∞)?
• Поясните принцип «индивидуализации» ребер на примере графика приема пациентов.
• Задание 1. Реализовать ассоциацию в реляционной модели данных. Для рассматриваемого

варианта

3) Сформулировать и записать на псевдокоде декларативные правила поддержания ссылоч-
ной целостности. Обосновать на содержательном уровне выбор правила.
Вариант 1. График встреч Заказчика с Исполнителем при необязательном участии Кон-
сультанта.
Вариант 2. График приема Врачами Пациентов.
Вариант 3. Ассоциация Преподавателей и Студентов в процессе Обучения.
Вариант 4. Участие Сотрудников организации в выполнении НИР (научно-исследовательских
работ).
Решение: Примеры выполнения аналогичных заданий приведены в основном тексте.
Обобщение
• Какой кластер сущностей называется обобщением?
• Как называется переход от обобщенной сущности к категориальным?
• Что понимается под полными и неполными иерархиями категорий?
• Как на презентационных диаграммах связь «обобщение-категория» изображается в нотации

UML?
• Постройте абстрактную презентационную диаграмму, реализующую обобщение в реляционной

модели.
• Постройте абстрактную ключевую диаграмму, реализующую обобщение в реляционной модели.

• Полную или неполную иерархию категорий описывает абстрактная ключевая диаграмма?
• Задание 1. Реализовать обобщение в реляционной модели данных. Для рассматриваемого ва-
рианта
Вариант 1. Учащиеся как обобщение понятий Студенты, Аспиранты.
Вариант 2. Транспорт как обобщение понятий Воздушный, Наземный, Подводный.
Вариант 3. Сотрудники как обобщение понятий Преподаватели и АУП (административно-
управленческий аппарат).
Вариант 4. Аудитория как обобщение понятий Учебная, Административная.
Композиция
• Какой кластер сущностей называется композицией?
• Какие виды связей устанавливаются между компонентами и композитом?
• Почему полностью идентифицирующие связи используются не только при обобщении, но и
при композиции?
• В чем проявляются различия образования композиции с помощью установления неполностью
идентифицирующих и обязательных неидентифицирующих связей?
• Как на презентационных диаграммах связь «композит-компонент» изображается в нотации

UML?
• Постройте абстрактную презентационную диаграмму, реализующую композицию в реляцион-

ной модели.
• Постройте абстрактную ключевую диаграмму, реализующую композицию в реляционной моде-

ли.
• Задание 1. Реализовать композицию в реляционной модели данных. Для рассматриваемого

варианта

Вариант 1. Состав корпусов учебного городка (Корпуса, их Аудитории и Лифты). Лифты
нумеруются в пределах корпуса.
Вариант 2. Университеты и их Факультеты.
Вариант 3. Города и их Районы.
Вариант 4. Улицы и их Дома.
Часть VI.
Дополнительные главы
7. Технологии баз данных
7.1. Информационные системы
С появлением вычислительной техники сразу образовались два основных направления ее использо-
вания:
1) применение для выполнения численных расчетов,
2) применение в информационных системах.
Информационная система (ИС) – это программно-аппаратный комплекс, предназначенный для

автоматизированного сбора, хранения, обработки и выдачи данных, имеющих обычно большой объем
и сложную структуру. Примерами ИС являются банковские системы, системы продажи билетов и
т.п.
Информационная система всегда специализируется на информации из определенной области ре-
ального мира, например, экономики, техники, медицины и т.д. Часть реального мира, отображаемая
в ИС, называется предметной областью.
7.1.1. Жизненный цикл ИС
Как и любая система, информационная система участвует в процессе жизненного цикла. Жизненный
цикл системы – это непрерывный процесс, который начинается с момента принятия решения о
создании системы и заканчивается в момент полного изъятия системы из эксплуатации. Структура
жизненного цикла ИС в соответствии с международным стандартом ISO/IEC 12207 базируется на
трех группах процессов:
1) основные процессы (приобретение, поставка, разработка, эксплуатация, сопровождение);
2) вспомогательные процессы (документирование, верификация, обеспечение качества и др.);
3) организационные процессы (управление проектами, обучение и др.).
Разработка включает все работы по созданию ИС в соответствии с заданными требованиями.

Разработка состоит из 4-х этапов:
1) формирование и анализ требований к системе (в результате составляется спецификация систе-

мы);
2) концептуальное проектирование (создание информационной модели системы без привязки к

типу ЭВМ и системных программных средств);
3) проектирование реализации (выбор вычислительной системы, системных программных средств,

проектирование структуры данных);
4) физическая реализация (разработка прикладных программ, базы данных, их отладка и тести-

рование, написание документации).
Эксплуатация включает все работы по внедрению компонентов ИС, созданию рабочих мест,
обучению персонала, а также собственно эксплуатацию, в том числе поиск и устранение проблем,
подготовку предложений по развитию и улучшению системы.
Модернизация ИС – это процесс замены отдельных компонент системы в связи с изменениями
предметной области, для повышения качества и надежности ИС, для совместимости с другими ИС.
Сопровождение – это поддержание системы в работоспособном состоянии в период эксплуатации.
Управление проектом относится к организационным процессам жизненного цикла и связано с
планированием работ, созданием коллектива разработчиков, контролем над сроками и качеством
работ.
Верификация – это вспомогательный процесс, который состоит в определении того, отвечает ли
промежуточный проект требованиям соответствующего этапа.
Существующие модели жизненного цикла, определяют порядок исполнения этапов в процессе
создания ИС, а также критерии перехода от этапа к этапу. В соответствии с этим наибольшее
распространение получили три модели: каскадная, итерационная, спиральная.
Каскадная модель – предполагает переход на следующий этап в цепочке этапов «Анализ – Про-
ектирование – Реализация – Внедрение – Сопровождение» после полного завершения работ преды-
дущего этапа (характерна для военно-технических проектов).
Каскадный подход хорошо зарекомендовал себя при построении ИС, для которых в самом начале
разработки можно достаточно точно и полно сформулировать все требования и дать свободу разра-
ботчикам реализовать их как можно лучше с технической точки зрения. В эту категорию попадают
сложные расчетные системы, системы реального времени и другие подобные задачи. Однако в про-
цессе использования этого подхода обнаруживается ряд его недостатков, вызванных, прежде всего
тем, что реальный процесс создания программного обеспечения никогда полностью не укладывается
в жесткую схему. Часто возникает потребность в возврате к предыдущим этапам с целью уточнения
или пересмотра ранее принятых решений.
Рис. 7.1.: Каскадная модель
Рис. 7.2.: Итерационная модель
Поэтапная итерационная модель предполагает наличие циклов обратной связи между этапами
«Анализ – Проектирование – Реализация – Внедрение – Сопровождение»:
Преимущество такой модели заключается в том, что межэтапные корректировки обеспечивают
большую гибкость и меньшую трудоемкость по сравнению с каскадной моделью. Однако время
жизни каждого из этапов может растянуться на весь период создания системы.
Спиральная модель опирается на начальные этапы жизненного цикла: анализ, предварительное и
детальное проектирование. Каждый виток спирали соответствует поэтапной модели создания фраг-
мента или версии системы, на нем уточняются цели и характеристики проекта, определяется его
качество, планируются работы следующего витка спирали.
Рис. 7.3.: Спиральная модель
Основная проблема спирального цикла – определение момента перехода на следующий этап. Для
ее решения необходимо ввести временные ограничения на каждый из этапов жизненного цикла.
Переход осуществляется в соответствии с планом, даже если не вся запланированная работа закон-
чена. План составляется на основе статистических данных, полученных в предыдущих проектах, и
личного опыта разработчиков.
Нерешенные вопросы и ошибки, допущенные на этапах анализа и проектирования ИС, порождают
на последующих этапах трудные, часто неразрешимые проблемы и, в конечном счете, приводят к
неуспеху всего проекта.
Главная особенность разработки современных ИС состоит в концентрации усилий на двух на-
чальных этапах ее жизненного цикла - анализе и проектировании, при относительно невысокой
сложности и трудозатратах на последующих этапах.
7.1.2. СУБД и БД
Основные потребности, которые при создании информационных систем не покрываются возможно-
стями обычных систем управления файлами – это
1) поддержка логической согласованности данных,
2) поддержка языка манипулирования данными,
3) восстановление данных после различного рода сбоев,
4) обеспечение параллельной работы пользователей.
Если информационная система опирается на некоторую систему управления данными, обладаю-
щую этими свойствами, то эта система управления данными является системой управления базами
данных (СУБД).
Базы данных (БД) – это наборы данных, находящиеся под контролем СУБД. Они представляют
собой совокупность описаний объектов конкретной предметной области и связей между ними.
СУБД относятся к категории наиболее сложных программных продуктов, имеющихся в настоящее
время. Они
• позволяют пользователям создавать новые базы данных и определять их схемы, то есть опи-
сывать логические структуры данных;
• позволяют модифицировать хранящиеся данные и извлекать данные в том или ином аспекте с
помощью так называемых запросов;
• управляют единовременным доступом к данным со стороны многих пользователей.
7.1.3. Жизненный цикл БД и средства автоматизированного проектирования

Средства автоматизированного проектирования концептуальной модели привлекают к себе в на-
стоящее время большой интерес и используются в процессе создания структуры базы данных и
интерфейса пользователя для доступа к данным.
Причина применения этих средств состоит в использовании в подавляющем большинстве ре-
альных разработок баз данных спиральной модели жизненного цикла программного обеспечения.
Использование спиральной модели предусматривает последовательное создание нескольких версий
программного обеспечения. Каждая следующая версия включает в себя предыдущую (возможно не
полностью) и является ответом на замечания пользователя, полученные в результате тестирования
предыдущей версии.
Альтернативным способом является каскадная схема разработки программного обеспечения. Кас-
кадный подход хорошо подходит для тех задач, для которых в самом начале разработки можно
достаточно полно и точно сформулировать все требования заказчика. В случае построения баз дан-
ных каскадный подход является неприемлемым.
При создании баз данных первая версия программного обеспечения, к сожалению, очень редко
является удачной. Чаще всего, заказчик отвергает первую версию, так как она недостаточно полно
отвечает его требованиям. Причина такой ситуации заключается в том, что заказчик не может сразу,
до создания начальной версии программы, четко и полно сформулировать свои требования. Обычно
после получения первого варианта программного обеспечения, заказчик выдвигает дополнительные
требования, которые нельзя реализовать в рамках созданной базы данных.
Это вынуждает разработчиков вносить изменения в структуру базы данных, а также, соответ-
ственно, в интерфейс пользователя для доступа к базе данных. Таких итераций может быть несколь-
ко до момента получения решения, адекватного запросам заказчика. Но даже после получения удо-
влетворительного решения, процесс разработки базы данных не завершается. Жизнь не стоит на
месте, и запросы заказчика меняются с течением времени. Часть этих изменений можно реализо-
вать без изменения структуры базы данных, изменяя только интерфейс пользователя, другие же
требуют изменения и интерфейса и структуры базы данных. Подобные изменения являются очень
болезненными – работа по внесению изменений может оказаться трудоемкой и, что самое непри-
ятное, может потребовать замены большого количества отлаженного программного кода. Иными
словами, замененный код был написан впустую, на самом деле его не нужно было писать.
Таким образом, создание работоспособной базы данных можно условно разделить на три этапа
– проектирование базы данных, в процессе которого создаются рабочие прототипы, кодирование –
создание структур баз данных и законченного интерфейса пользователя и сопровождение готовой
базы данных.
Основная идея применения средств автоматизированного проектирования баз данных заключается
в том, что процесс ручного кодирования начинается только после окончания процесса проектирова-
ния. На стадии проектирования схема базы данных и интерфейс пользователя для доступа к базе
данных создается автоматически, исходя из описания концептуальной модели, с помощью так на-
зываемых CASE средств (Computer Aided Software/System Engineering). Конечно, созданный таким
образом интерфейс не является законченным программным продуктом, однако он позволяет заказ-
чику оценить возможности, которые будут в конечном продукте и внести свои коррективы. Только
после одобрения заказчиком рабочего прототипа, разработчики приступают к ручному кодированию
– созданию законченного приложения.
При сопровождении все повторяется, за тем исключением, что генерируется не все приложение
целиком, а только часть, которую надо изменять.
На практике, чаще всего, CASE-средства используются для создания схемы базы данных в виде
диаграмм «сущность-связь» и генерации структур баз данных для конкретной СУБД. После по-
лучения от заказчика изменений, разработчики вносят соответствующие исправления в диаграмму
«сущность-связь» и заново генерируют структуры баз данных. Средства автоматической генерации
интерфейсов используются реже.
В настоящее время практически каждый производитель СУБД предлагает собственное программ-
ный продукт автоматизированного проектирования. Это Oracle Designer (Oracle), Power Designer
(Sybase) и другие. Демонстрационные версии данных программных продуктов можно загрузить с
соответствующих сайтов (www.oracle.com, www.sybase.com). Кроме того, на рынке представлены
решения третьих фирм, не производящих СУБД. Одними из самых распространенных являются
программные продукты фирмы AllFusion – AllFusion ERwin Data Modeler (ранее ERwin) и AllFusion
Process Modeler (ранее BPwin) и другие. На российском рынке данные программы предлагает фирма
Interface Ltd. (www.interface.ru). Программа AllFusion Process Modeler предназначена для модели-
рования бизнес-процессов. Результатами ее работы могут быть не только диаграммы, но и сгенери-
рованный для различных сред код для доступа к базам данных. Для этого, однако, необходимо еще
создать диаграммы «сущность-связь» с помощью AllFusion ERwin Data Modeler.
AllFusion ERwin Data Modeler позволяет проектировать, документировать и сопровождать базы
данных, хранилища данных и витрины данных (data marts).
Создав наглядную модель базы данных, можно оптимизировать структуру БД и добиться её
полного соответствия требованиям и задачам организации. Визуальное моделирование повышает
качество создаваемой базы данных, продуктивность и скорость её разработки. На сайте Interface Ltd.
(www.interface.ru) доступна для загрузки демонстрационная версия AllFusion ERwin Data Modeler,
которая представляет собой полнофункциональную версию, ограниченную по времени.
7.2. Модели данных

Ранние СУБД были основаны, в основном, на следующих моделях данных (начиная с 1968 года):
1) иерархические модели (древовидные),
2) сетевые модели (графовые).
Затем возникли СУБД, основанные на реляционной модели данных. Реляционная модель предло-
жена Коддом (Codd) в 1970 году. В настоящее время реляционные СУБД и их модификации состав-
ляют основу рынка. Дальнейшие исследования ведутся в направлении сочетания в той или иной сте-
пени реляционной модели, объектно-ориентированного программирования и интернет-технологий.
Примечание. Строго говоря, понятие модели данных появилось позже разработки ранних СУБД вместе
с развитием реляционного подхода, широко применяемого в настоящее время. Абстрактное представление о
моделях данных ранних систем появилось на основе сравнительного анализа и выявления общих признаков
у различных СУБД, имеющихся к моменту развития реляционного подхода •
Рис. 7.4.: Пример одного из деревьев базы медицинских данных
7.2.1. Иерархическая модель данных

Наиболее известным и распространенным представителем иерархических СУБД является Information
Management System (IMS) фирмы IBM. Первая версия системы появилась в 1968 году. Система до
сих пор эксплуатируется, что создает существенные проблемы с переходом как на новую технологию
БД, так и на новую технику.
Иерархическая БД состоит из упорядоченного набора структур записей. Каждая структура имеет
вид дерева. Вершины дерева называются узлами. Один из узлов, который находится на самом
верху иерархии, называется корнем. Остальные узлы называются потомками и связаны так, что
каждый узел имеет предка. Узлы, не имеющие потомков, называются листьями. Все экземпляры
узла-потомка, имеющие общего предка, называются близнецами.
Больница(Код больницы, Название, Адрес, Телефон, Число коек)
Лаборатория(№ лаборатории, Название, Адрес, Телефон)
Палата(Код палаты, Название, Число коек)
Персонал(№ табельный, ФИО, Должность, Смена, Зарплата)
Пациент(№ регистрационный, № койки, ФИО, Адрес, Дата рождения, Пол)
Врач(№ табельный, ФИО, Специальность)
Примерами типичных операторов манипулирования иерархически организованными данными мо-
гут быть следующие:
• найти указанное дерево БД (например, плановый отдел);
• перейти от одного дерева к другому;
• перейти от одного узла к другому внутри дерева (например, от отдела – к первому сотруднику);
• перейти от одного узла к другому в порядке обхода иерархии;
• вставить новую запись (экземпляр узла) в указанную позицию;
• удалить текущую запись.
Поддерживается ограничение целостности в следующей формулировке: никакой потомок не может

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

• сложность отображения связей многие-ко-многим (когда, например, каждый сотрудник может
работать во многих отделах и в каждом отделе может работать много сотрудников) без увели-
чения избыточности;
• сложность включения информации о новых объектах и удаления устаревших данных;
• доступ к данным возможен только через корень дерева, что может значительно увеличить
время поиска данных для некоторых запросов.
7.2.2. Сетевая модель данных

Отличие сетевой модели от иерархической заключается в том, что в сетевой структуре любой эле-
мент данных может быть связан с любым другим, то есть иерархическая модель является разно-
видностью сетевой.
Различают простую и сложную сетевую структуру. В простой сетевой структуре между ис-
ходным и порожденными узлами реализуется связь один-ко-многим (когда, например, каждый со-
трудник может работать в одном отделе и в каждом отделе может работать много сотрудников).
Сложной сетевой структурой называют такую схему, в которой присутствует хотя бы одна связь
многие-ко-многим.
В настоящее время большинство сетевых СУБД поддерживают только простые сетевые структуры.
Такие системы называют СУБД с равноправными (однотипными) файлами. Типичным представи-
телем является Integrated Database Management System (IDMS) компании Cullinet Software Inc.,
предназначенная для использования на машинах основного класса фирмы IBM под управлением
большинства операционных систем.
Больница(Код больницы, Название, Адрес, Телефон, Число коек)
Лаборатория(№ лаборатории, Название, Адрес, Телефон)
Рис. 7.5.: Пример структурной диаграммы базы медицинских знаний
Палата(Код палаты, Название, Число коек)

Персонал(№ табельный, ФИО, Должность, Смена, Зарплата)
Пациент(№ регистрационный, № койки, ФИО, Адрес, Дата рождения, Пол)
Врач(№ табельный, ФИО, Специальность)
Диагноз(Код диагноза, Тип диагноза, Осложнения, Предупреждающая информация)
Больница-Лаборатория(Код больницы, № лаборатории)
Анализ(Код анализа, Тип, Назначенная дата, Назначенное время, Номер варианта/предписания,
Состояние)
Главным достоинством сетевой и иерархической моделей данных является возможность их эф-
фективной реализации по показателям затрат памяти и оперативности. Недостатком сетевой модели
данных является высокая сложность и жесткость схемы БД, построенной на ее основе.
7.2.3. Реляционная модель данных
Что означает термин «реляционная модель»? Термин происходит от relation (отношение, зависимость,
связь). Отношение в общем математическом смысле – это подмножество декартова произведения
множеств, то есть
R ⊆ A1 × · · · × An = {(x1 , . . . , xn ) | x1 ∈ A1 , . . . , xn ∈ An }
Например, бинарные отношения строгого порядка на множестве положительных оценок A1 = A2 =
{3, 4, 5} являются множествами упорядоченных пар
R< = {(3, 4), (4, 5), (3, 5)} ⊂ A1 × A2
R< = {(5, 4), (4, 3), (5, 3)} ⊂ A1 × A2
A1 × A2 = {(3, 3), (3, 4), (3, 5), (4, 3), (4, 4), . . . (5, 5)}
(x < y) ⇔ (x, y) ∈ R<
(x > y) ⇔ (x, y) ∈ R>
Эти отношения можно представить в форме таблиц с упорядоченными столбцами и произвольным
порядком строк:
Отношение R< Отношение R>

3 4 5 4
4 5 6= 4 3
3 5 5 3
Таким образом, в реляционных базах данных (РБД) данные организованы в виде отношений
и представлены в форме таблиц. Однако формы представления или, как еще говорят, изобра-
жения, могут быть различными. Так, например, для числа 1 имеем эквивалентные представления
1, 0.999 . . . , 0.(9) и т.п.
Применительно к рассматриваемым в примере отношениям эта возможность различного представ-
ления проявляется в том, что строки в таблицах переставлять можно, так как отношения – это
множества, а множества не упорядочены. Однако столбцы в таблицах переставлять нельзя, так как
элементы этих множеств являются упорядоченными наборами, в данном случае упорядоченными
парами. Таким образом, таблицы с произвольным порядком строк, но фиксированным порядком
столбцов, являются адекватной формой представления отношений в общем математическом смысле.
Но с точки зрения информационного содержания рассматриваемые в примере отношения R< и R>
эквивалентны. Поэтому понятие отношения в реляционных базах данных имеет несколько отлича-
ющийся смысл, не связанный с какой-либо упорядоченностью столбцов в табличной форме пред-
ставления. Для этого отношения связываются с так называемыми схемами отношений, имеющими
смысл строки заголовков столбцов:
Отношение строгого порядка
Оценка Оценка Оценка Оценка
меньшая бо́льшая бо́льшая меньшая
3 4 = 5 4
4 5 4 3
3 5 5 3
Таким образом, понятие отношения в смысле реляционных баз данных близко по смыслу, но не
тождественно понятию отношения в общем математическом смысле.
Достоинством реляционной модели данных является ее простота, удобство реализации на ЭВМ,
наличие теоретического обоснования и возможность формирования гибкой схемы БД, допускающей
настройку при формировании запроса. Однако при увеличении числа таблиц в БД заметно падает
скорость работы с ней. Определенные проблемы использования реляционной модели возникают при
создании систем со сложными структурами данных, например, систем автоматизации проектирова-
ния.
7.2.4. Постреляционная модель данных

Классическая реляционная модель предполагает атомарность (неделимость) данных, хранящихся в
полях записей таблицы. Существуют случаи, когда это ограничение мешает эффективной организа-
ции приложений. Постреляционная модель данных представляет собой расширенную реляционную
модель, в которой отменено требование атомарности атрибутов. Эта модель использует трехмерные
структуры, позволяя хранить в полях таблицы другие таблицы и, тем самым, расширить возможно-
сти по описанию сложных объектов реального мира.
В качестве языка запросов в системах, использующих постреляционную модель, используется
несколько расширенный язык реляционных баз данных SQL, позволяющий извлекать сложные объ-
екты из одной таблицы без использования операции соединения.
Достоинство постреляционной модели – это возможность представления совокупности связан-
ных реляционных таблиц одной постреляционной таблицей. Это обеспечивает высокую наглядность
представления информации и повышает эффективность ее обработки. Недостаток постреляционной
модели – это сложное решение проблемы обеспечения целостности и непротиворечивости.
7.2.5. Объектно-ориентированные модели данных

Направление объектно-ориентированных баз данных (ООБД) возникло уже в середине 1980-х го-
дов. Однако наиболее активно это направление развивается в последние годы. Возникновение на-
правления ООБД определяется необходимостью разработки сложных информационных прикладных
систем, для которых технология распространенных систем БД не всегда удовлетворительна.
Базис ООБД обеспечивают как предыдущие работы в области БД, особенно реляционных, так и
давно развивающееся направление объектно-ориентированных языков программирования.
Современная ситуация с ООБД напоминает ситуацию с реляционными системами середины 1970-
х годов. При наличии большого количества экспериментальных проектов (и даже коммерческих
систем) отсутствует общепринятая объектно-ориентированная модель данных, и не потому, что нет
ни одной разработанной полной модели, а по причине отсутствия общего согласия о принятии какой-
либо модели.
В наиболее общей постановке объектно-ориентированный подход базируется на концепциях:
1) объекта и идентификатора объекта;
2) атрибутов и методов;
3) классов;
4) иерархии и наследования классов.
Любая сущность реального мира в объектно-ориентированных языках и системах моделируется

в виде объекта. Любой объект при своем создании получает генерируемый системой уникальный
идентификатор, который связан с объектом во все время его существования и не меняется при
изменении состояния объекта.
Каждый объект имеет состояние и поведение. Состояние объекта – это набор значений его атри-
бутов. Поведение объекта – это набор методов, реализуемых программным кодом, и оперирующих
над состоянием объекта. Значение атрибута объекта – это тоже некоторый объект или множе-
ство объектов. Состояние и поведение объекта инкапсулированы в объекте; взаимодействие между
объектами производится на основе передачи сообщений и выполнении соответствующих методов.
Множество объектов с одним и тем же набором атрибутов и методов образует класс объектов.
Объект должен принадлежать только одному классу (если не учитывать возможности наследова-
ния). Допускается наличие примитивных предопределенных классов, объекты-экземляры которых
не имеют атрибутов (целые, строки и т.д.). Класс, объекты которого могут служить значениями
атрибута объектов другого класса, называется доменом этого атрибута.
Допускается порождение нового класса на основе уже существующего класса, то есть наследо-
вание. В этом случае новый класс, называемый подклассом существующего класса (суперкласса)
наследует все атрибуты и методы суперкласса. В подклассе, кроме того, могут быть определены до-
полнительные атрибуты и методы. Различаются случаи простого и множественного наследования.
В первом случае подкласс может определяться только на основе одного суперкласса, во втором слу-
чае суперклассов может быть несколько. Если в языке или системе поддерживается простое насле-
дование классов, набор классов образует древовидную иерархию. При поддержании множественного
наследования классы связаны в ориентированный граф (с корнем), называемый решеткой классов.
Объект подкласса считается принадлежащим любому суперклассу этого класса.
Наиболее важным новым качеством ООБД является поведенческий аспект объектов. В среде
ООБД проектирование, разработка и сопровождение прикладной системы становится процессом,
в котором интегрируются структурный (статический) и поведенческий (динамический) аспекты.
Для этого нужны специальные языки, позволяющие определять объекты и создавать на их основе
прикладную систему.
7.2.6. XML как модель данных

На исторические причины возникновения XML можно посмотреть с двух различных, но связанных
между собой точек зрения.
Первая состоит в том, что семантическая ограниченность языка разметки гипертекста HTML не
позволяла разработчику Web-приложений описывать специфическую информацию, например, хими-
ческие или математические формулы. Возникла практическая потребность в других языках размет-
ки, структурно аналогичных HTML, но с другой семантикой. В результате был создан метаязык
XML.
Вторая точка зрения состоит в следующем. Информация, заключенная в любом документе, в том
числе и в Web-странице, является в большей или меньшей степени регулярной. Ранние варианты
HTML слабо учитывали эту регулярность, что приводило к громоздкости сообщений на этом языке
и не вполне удовлетворяло разработчиков Web-приложений.
В общем виде XML-документ имеет структуру произвольного дерева, которая описывается набо-
ром вложенных друг в друга тегов.
XML-ориентированные базы данных в качестве модели данных использует модель данных, при-
нятую в самом XML. Следует отличать XML-ориентированные базы данных (например, Tamino) от
реляционных, поддерживающих обмен данными на языке XML (Oracle, Microsoft SQL Server и др.).
В основе последних лежит реляционная модель.
Использовать XML в качестве базы данных в средах, где нет больших объемов данных, большого
количества пользователей, нет высоких требований к производительности, вполне допустимо. Одна-
ко такой подход вряд ли годится для многих реальных задач, предполагающих поддержку большого
числа пользователей, жесткие требования к целостности данных и производительности.
7.2.7. Многомерная модель данных (OLAP)

В развитии концепции информационных систем выделяют два направления:
1) системы оперативной обработки транзакций (OLTP – On-Line Transaction Processing);
2) системы оперативной аналитической обработки (OLAP – On-Line Analytic Processing).

OLTP-системы рассчитаны на быстрое обслуживание относительно простых запросов большого
числа пользователей. Время выполнения типичных запросов в таких системах не должно превышать
нескольких секунд. Например, запрос к OLTP-системе продажи железнодорожных билетов мог бы
выглядеть так (в вербальной формулировке): есть ли свободные купейные места на поезд № 9 на
такое-то число?
Логической единицей функционирования OLTP-систем является транзакция. Применение для ре-
ализации систем такого класса баз данных, основанных на реляционной модели данных, является
эффективным.
OLAP-системы ориентированы на анализ данных и поддержку принятия решений. Включают
сложные запросы, требующие статистическую обработку данных за некоторый прошедший про-
межуток времени, моделирование процессов предметной области, прогнозирование тех или иных
явлений. Например, запрос к OLAP-системе продажи железнодорожных билетов мог бы выглядеть
так (в вербальной формулировке): каким будет объем продаж железнодорожных билетов в денежном
выражении в следующем квартале с учетом сезонных колебаний?
OLAP-системы часто включают средства обработки информации на основе методов искусствен-
ного интеллекта. Имеют развитые средства графического представления данных. Оперируют боль-
шими объемами исторических данных. Реализуют сложные методы анализа, позволяющие выделить
из исторических данных содержательную информацию. Реализуют специальные хранилища данных
для накопления информации из различных источников за большой период времени. Обеспечивают
быстрый доступ к информации.
При реализации OLAP-систем используют организацию данных в виде так называемых хранилищ
данных (ХД), основанных на многомерной модели данных.
Различие в организации данных в OLAP и OLTP-системах связано со следующими обстоятель-
ствами.
• В OLAP-системах данные носят исторический характер, а значит, обладают высоким уровнем
статичности, неизменности. В OLTP-системах ситуация обратная.
• Выполнение многих аналитических запросов в OLAP-системах требует хронологической упо-
рядоченности данных. В OLTP-системах время (изначально) отсутствует.
• В OLAP-системах чаще используются обобщенные (агрегированные), а не детальные данные. В
OLTP-системах ситуация обратная. Например, в OLTP-системе сети магазинов будут хранить-
ся данные о каждой сделанной покупке. Но такие детальные данные излишни в OLAP-системе,
предназначенной для прогноза объема продаж.
Таким образом, концепция хранилищ данных – это концепция подготовки многомерных данных
для последующего анализа.
Можно выделить два основных подхода к построению хранилищ данных:
1) подход, использующий многомерную модель БД (MOLAP – Multidimensional OLAP);
2) подход, использующий реляционную модель БД (ROLAP – Relational OLAP).
Безотносительно к принятому подходу данные в хранилище данных могут на логическом уровне
рассматриваться как точки многомерного пространства (или, как еще говорят, ячейки гиперкуба).
Основные понятия многомерной модели – это измерение и значение (точка, ячейка). Измерение
– это упорядоченный набор значений соответствующий одному из ребер гиперкуба, например Год
(1999, 2000, 2001), Область (Московская, Ленинградская, Саратовская), Возраст (до 20, 20-40, 40-
60, свыше 60). Значения – это подвергаемые анализу количественные или качественные данные,
которые находятся в ячейках гиперкуба, например, (Население, Доход) = function(Год, Область,
Возраст).
Основными операциями над многомерными данными являются сечение, вращение, свертка, дета-
лизация.
Рис. 7.6.: Логическая схема OLAP-системы
Операция сечения формирует подмножество гиперкуба, в котором значение одного или более
измерений фиксировано, например, (Население, Доход) = function(2000, Область, Возраст).
Операция вращения изменяет порядок представления измерений для удобства восприятия. Обыч-
но применяется к двумерным сечениям, например, (Население, Доход) = function(2000, Область,
Возраст → 2000, Возраст, Область).
Для выполнения операций свертки и детализации должна существовать иерархия значений из-
мерения, то есть подчиненность одних значений другим. Например, год состоит из кварталов, квар-
талы из месяцев и т.д. При выполнении операции свертки одно из значений измерения заменяется
значением более высокого уровня иерархии (например, вместо месяца год). Операция детализации
– это операция, обратная свертке. Она обеспечивает переход от обобщенных к детализированным
данным.
Примерами систем, поддерживающих многомерные модели данных, являются Oracle Express Service
и Microsoft Analysis Services (OLAP-сервер фирмы Microsoft, входящий в комплект поставки Microsoft
SQL Server 2000 Enterprise Edition).
Достоинством многомерной модели данных является более быстрый поиск и чтение данных, и
отсутствие необходимости множественного соединения таблиц.
Недостаток многомерной модели заключается в потребности в большом объеме памяти для хра-
нения данных и сложность модификации структуры данных. Например, добавление еще одного
измерения приводит к необходимости полной перестройки гиперкуба.
7.3. Основные функции СУБД

К числу функций СУБД принято относить следующие:
1) управление данными во внешней памяти,

2) управление буферами оперативной памяти,
3) управление транзакциями,
4) журнализация и восстановление БД после сбоев,
5) поддержка языков баз данных.
7.3.1. Управление данными во внешней памяти

Непосредственное управление данными во внешней памяти означает поддержку со стороны СУБД
необходимых структур внешней памяти как для хранения данных, непосредственно входящих в БД,
так и для служебных целей, например, для ускорения доступа к данным. Реализации СУБД могут
активно использовать возможности существующих файловых систем, либо брать на себя эту работу
вплоть до уровня устройств внешней памяти. Но важно, что в развитых СУБД пользователи в любом
случае не обязаны знать, использует ли СУБД файловую систему вообще, и если использует, то
как. В частности, СУБД поддерживают собственную систему именования объектов базы данных.
7.3.2. Управление буферами оперативной памяти

Управление буферами оперативной памяти необходимо в связи с тем, что СУБД обычно работают
с БД значительного размера, существенно превышающего размер доступной оперативной памяти.
Поэтому в развитых СУБД поддерживается собственный набор буферов оперативной памяти с соб-
ственной дисциплиной замены буферов.
7.3.3. Управление транзакциями
Управление транзакциями позволяет СУБД поддерживать логическую целостность базы данных,
то есть непротиворечивость данных, хранимых в БД. Транзакция – это последовательность опе-
раций над БД, рассматриваемых СУБД как единое целое. Либо транзакция успешно выполняется,
и тогда СУБД фиксирует изменения данных во внешней памяти, либо ни одно из этих изменений
никак не отражается на состоянии БД.
7.3.4. Журнализация и восстановление БД после сбоев

Журнализация позволяет обеспечить одно из основных требований к СУБД – надежность хранения
данных во внешней памяти. Под надежностью хранения понимается возможность восстановления
последнего согласованного состояния БД после любого аппаратного или программного сбоя.
Типичные виды аппаратных сбоев:
1) так называемые мягкие сбои, которые можно трактовать как внезапную остановку работы
компьютера, например, из-за аварийного отключения питания;
2) жесткие сбои, характеризуемые потерей информации на носителях внешней памяти.
Примерами программных сбоев могут быть
• аварийное завершение работы СУБД по причине ошибки в программе или в результате неко-
торого аппаратного сбоя,
• аварийное завершение пользовательской программы, в результате чего некоторая транзакция

остается незавершенной.
Первую ситуацию можно рассматривать как особый вид мягкого аппаратного сбоя. При возник-
новении последней требуется ликвидировать последствия только одной транзакции.
Ясно, что для восстановления БД нужно располагать некоторой избыточной информацией. Наи-
более распространенным методом поддержания такой избыточности является ведение журнала из-
менений БД.
Журнал – это особая часть БД, недоступная пользователям СУБД и поддерживаемая с особой
тщательностью (иногда поддерживаются две копии журнала, располагаемые на разных физических
дисках). В журнал поступают записи обо всех изменениях основной части БД. В разных СУБД
изменения БД журнализируются на разных уровнях:
1) иногда запись в журнале соответствует некоторой логической операции изменения БД, напри-
мер, операции удаления строки из таблицы реляционной БД,
2) иногда – минимальной внутренней операции модификации страницы внешней памяти;
3) в некоторых системах одновременно используются оба подхода.

Во всех случаях придерживаются стратегии «упреждающей» записи в журнал (так называемого
протокола Write Ahead Log – WAL). Эта стратегия заключается в том, что запись об изменении
любого объекта БД должна попасть во внешнюю память журнала раньше, чем измененный объект
попадет во внешнюю память основной части БД. Если в СУБД корректно соблюдается протокол
WAL, то с помощью журнала можно решить все проблемы восстановления БД после любого сбоя.
Самая простая ситуация восстановления – индивидуальный откат транзакции. Строго говоря,
для этого не требуется общесистемный журнал изменений БД. Достаточно для каждой транзакции
поддерживать локальный журнал операций модификации БД, выполненных в этой транзакции, и
производить откат транзакции путем выполнения обратных операций, следуя от конца локально-
го журнала. В некоторых СУБД так и делают, но в большинстве систем локальные журналы не
поддерживают, а индивидуальный откат транзакции выполняют по общесистемному журналу. Для
этого все записи от одной транзакции связывают обратным списком (от конца к началу).
При мягком сбое во внешней памяти основной части БД могут находиться объекты, модифициро-
ванные транзакциями, не закончившимися к моменту сбоя, и могут отсутствовать объекты, модифи-
цированные транзакциями, которые к моменту сбоя успешно завершились (содержимое которых, по
причине использования буферов оперативной памяти, при мягком сбое пропадает). При соблюдении
протокола WAL во внешней памяти журнала должны гарантированно находиться записи, относящи-
еся к операциям модификации обоих видов объектов. Целью процесса восстановления после мягкого
сбоя является состояние внешней памяти основной части БД, которое возникло бы при фиксации
во внешней памяти изменений всех завершившихся транзакций и которое не содержало бы ника-
ких следов незаконченных транзакций. Для того, чтобы этого добиться, сначала производят откат
незавершенных транзакций (undo), а потом повторно воспроизводят (redo) те операции завершенных
транзакций, результаты которых не отображены во внешней памяти.
Для восстановления БД после жесткого сбоя используют журнал и архивную копию БД. Грубо
говоря, архивная копия – это полная копия БД к моменту начала заполнения журнала. Конечно,
для нормального восстановления БД после жесткого сбоя необходимо, чтобы журнал не пропал.
Поэтому к сохранности журнала во внешней памяти в СУБД предъявляются особо повышенные
требования. Тогда восстановление БД состоит в том, что, исходя из архивной копии, по журналу
воспроизводится работа всех транзакций, которые закончились к моменту сбоя. В принципе, можно
даже воспроизвести работу незавершенных транзакций и продолжить их работу после завершения
восстановления. Однако в реальных системах это обычно не делается, поскольку процесс восста-
новления после жесткого сбоя является достаточно длительным.
7.3.5. Поддержка языков баз данных
Для работы с базами данных используются специальные языки, в целом называемые языками
баз данных. В ранних СУБД поддерживалось несколько специализированных по своим функциям
языков. Чаще всего выделялись два языка – язык определения схемы БД (SDL – Schema Definition
Language) и язык манипулирования данными (DML - Data Manipulation Language). SDL служил
главным образом для определения логической структуры БД, то есть той структуры БД, какой она
представляется пользователям. DML содержал набор операторов манипулирования данными, то есть
операторов, позволяющих заносить данные в БД, обновлять, удалять или выбирать существующие
данные.
В современных СУБД обычно поддерживается единый интегрированный язык, содержащий все
необходимые средства для работы с БД, начиная от ее создания, и обеспечивающий базовый поль-
зовательский интерфейс с базами данных. Стандартным языком наиболее распространенных в на-
стоящее время реляционных СУБД является язык SQL.
Примечание. Название SQL вначале было аббревиатурой, образованной от Structured Query Language
(язык структурированных запросов), и его было принято произносить «сиквел». Сейчас, когда язык стал
стандартом, SQL – это уже не аббревиатура, а название, которое произносится как «эс-кю-эль» •
Язык SQL сочетает средства SDL и DML, то есть позволяет определять схему реляционной БД
и манипулировать данными. При этом именование объектов БД (для реляционной БД – это име-
нование таблиц и их столбцов) поддерживается на языковом уровне в том смысле, что компилятор
языка SQL производит преобразование имен объектов в их внутренние идентификаторы на осно-
вании специально поддерживаемых служебных таблиц-каталогов. Внутренняя часть СУБД (ядро)
вообще не работает с именами таблиц и их столбцов.
Язык SQL содержит специальные средства определения ограничений целостности БД. Ограниче-
ния целостности хранятся в специальных таблицах-каталогах, и обеспечение контроля целостности
БД производится на языковом уровне, то есть при компиляции операторов модификации БД компи-
лятор SQL на основании имеющихся в БД ограничений целостности генерирует соответствующий
программный код.
Специальные операторы языка SQL позволяют определять так называемые представления БД,
фактически являющиеся хранимыми в БД запросами с именованными столбцами (результатом лю-
бого запроса к реляционной БД является таблица). Для пользователя представление является такой
же таблицей, как любая базовая таблица, хранимая в БД, но с помощью представлений можно
ограничить или наоборот расширить видимость БД для конкретного пользователя. Поддержание
представлений производится также на языковом уровне.
Наконец, авторизация доступа к объектам БД производится также на основе специального набора
операторов SQL. Идея состоит в том, что для выполнения операторов SQL разного вида пользова-
тель должен обладать различными полномочиями. Пользователь, создавший таблицу БД, обладает
полным набором полномочий для работы с этой таблицей. В число этих полномочий входит пол-
номочие на передачу всех или части полномочий другим пользователям, включая полномочие на
передачу полномочий. Полномочия пользователей описываются в специальных таблицах-каталогах,
контроль полномочий поддерживается на языковом уровне.
7.4. Типовая организация СУБД

Организация типичной СУБД и состав ее компонентов соответствует рассмотренному набору основ-
ных функций:
1) управление данными во внешней памяти,
2) управление буферами оперативной памяти,

3) управление транзакциями,
4) журнализация и восстановление БД после сбоев,
5) поддержка языков баз данных.
Логически в современной реляционной СУБД можно выделить
1) наиболее внутреннюю часть – ядро СУБД (часто его называют Data Base Engine),
2) компилятор языка БД (обычно SQL),
3) подсистему поддержки времени выполнения,
4) набор утилит.
В некоторых системах эти части выделяются явно, в других – нет, но логически такое разделение
можно провести во всех СУБД.
Ядро СУБД отвечает за управление данными во внешней памяти, управление буферами опера-
тивной памяти, управление транзакциями и журнализацию. Соответственно, можно выделить такие
компоненты ядра (по крайней мере, логически, хотя в некоторых системах эти компоненты выделя-
ются явно), как менеджер данных, менеджер буферов, менеджер транзакций и менеджер журнала.
Функции этих компонентов взаимосвязаны, и для обеспечения корректной работы СУБД все эти
компоненты должны взаимодействовать по тщательно продуманным и проверенным протоколам.
Ядро СУБД обладает собственным интерфейсом, не доступным пользователям напрямую и исполь-
зуемым в программах, производимых компилятором SQL (или в подсистеме поддержки выполнения
таких программ) и утилитах БД. Ядро СУБД является основной резидентной частью СУБД. При
использовании архитектуры «клиент-сервер» ядро является основной составляющей серверной части
системы.
Основной функцией компилятора языка БД является компиляция операторов языка БД в неко-
торую выполняемую программу. Основной проблемой реляционных СУБД является то, что языки
этих систем (а это, как правило, SQL) являются непроцедурными, то есть в операторе такого язы-
ка специфицируется некоторое действие над БД, но эта спецификация не является процедурой, а
лишь описывает в некоторой форме условия совершения желаемого действия. Поэтому компилятор
должен решить, каким образом выполнять оператор языка прежде, чем произвести программу. При-
меняются достаточно сложные методы оптимизации операторов. Результатом компиляции является
выполняемая программа, представляемая в некоторых системах в машинных кодах, но более часто
в выполняемом внутреннем машинно-независимом коде. В последнем случае реальное выполнение
оператора производится с привлечением подсистемы поддержки времени выполнения, представля-
ющей собой, по сути дела, интерпретатор этого внутреннего языка.
Наконец, в отдельные утилиты БД обычно выделяют такие процедуры, которые слишком наклад-
но выполнять с использованием языка БД, например, загрузка и выгрузка БД, сбор статистики, гло-
бальная проверка целостности БД и т.д. Утилиты программируются с использованием интерфейса
ядра СУБД, а иногда даже с проникновением внутрь ядра.
7.5. Модели взаимодействия с БД

7.5.1. Модель с централизованной архитектурой
СУБД и прикладная программа (приложение) располагаются на одном компьютере (мэйнфрейме
или персональном компьютере). Для такого способа организации не требуется поддержка сети, и
все сводится к автономной работе в однопользовательском режиме. Подобная архитектура исполь-
зовалась в первых версиях СУБД DB2, Oracle, Ingres.
Однако исходная идея создания и использования баз данных предполагала многопользователь-
ское использование данных. С этой целью к мейнфрейму подключалось несколько терминалов. При
этом в рамках ресурсов одного компьютера (мейнфрейма) приходилось обслуживать весь комплекс
возникающих задач, начиная от собственно обработки и хранения данных, до отображения инфор-
мации и приема запросов от пользователей. Модель использовалась в период широкого распростра-
нения больших ЭВМ (IBM-370, ЕС-1045, ЕС-1060). Основным недостатком этой модели являлось
резкое снижение производительности при увеличении числа пользователей.
7.5.2. Модель с автономными персональными компьютерами

Каждый пользователь имеет свой персональный компьютер с установленной СУБД. Компьютеры
в сеть не связаны. На каждом компьютере имеется копия БД, точнее реплика. Механизм репли-
кации, если он реализован в СУБД, позволяет от основной базы данных (преобразованной в так
называемую основную реплику) порождать реплики, переносимые затем на другие компьютеры. В
дальнейшем периодически, например, в конце рабочего дня, можно синхронизировать содержимое
всех реплик и вновь перенести реплики на другие компьютеры. В случае возникновения конфлик-
тов (неоднозначности) при синхронизации реплик может возникнуть необходимость вмешательства
пользователя.
Механизм репликации реализован, в частности, в СУБД MS Access. Основным недостатком мо-
дели является невозможность оперативного обновления данных на всех компьютерах при изменении
их одним из пользователей.
7.5.3. Архитектура «файл-сервер»
Эта архитектура баз данных с сетевым доступом предполагает назначение одного из компьютеров
сети в качестве выделенного сервера (файлового сервера), на котором будут храниться файлы базы
данных. На других компьютерах сети (клиентских компьютерах) установлены СУБД и клиент-
ские приложения для работы с БД.
Файловый сервер выполняет в основном только роль хранилища файлов, не участвуя в обработке
самих данных. В соответствие с запросами клиентских приложений необходимая часть файлов с
файл-сервера копируется на клиентский компьютер, где и осуществляется основная часть обработки
данных. Все обращения к БД от клиентского приложения идут через СУБД, которая инкапсулирует
внутри себя все сведения о физической структуре БД, расположенной на файловом сервере. При
изменении данных на компьютере-клиенте данные отправляются назад на файловый сервер с целью
обновления БД.
В рамках архитектуры «файл-сервер» были выполнены первые версии таких популярных (так
называемых настольных) СУБД, как dBase и MS Access.
Архитектура «файл-сервер» имеет много недостатков, в частности, низкую производительность
при работе многих пользователей.
7.5.4. Архитектура «клиент-сервер»

Использование архитектуры «клиент-сервер» предполагает наличие сети, в которой один из компью-
теров выполняет особые управляющие функции (является сервером сети). На компьютере-сервере
размещаются СУБД и файлы базы данных. На компьютерах-клиентах размещаются клиентские при-
ложения. Клиентское приложение формирует запрос к серверу на языке SQL, являющемся промыш-
ленным стандартом в реляционных БД. Сервер принимает запрос и переадресует его SQL-серверу
БД.
SQL-сервер –это специальная программа, управляющая удаленной базой данных. SQL-сервер
обеспечивает интерпретацию запроса, его выполнение в базе данных, формирование результата
выполнения запроса и выдачу его приложению-клиенту. При этом ресурсы клиентского компьютера
не участвуют в физическом выполнении запроса; клиентский компьютер лишь отсылает запрос к
серверной БД и получает результат, после чего интерпретирует его необходимым образом и пред-
ставляет пользователю. Так как клиентскому приложению посылается результат выполнения запро-
са, по сети передаются только те данные, которые необходимы клиенту. В итоге снижается нагрузка
на сеть. Поскольку выполнение запроса происходит там же, где хранятся данные (на сервере), нет
необходимости в пересылке больших пакетов данных. Кроме того, SQL-сервер, если это возможно,
оптимизирует полученный запрос таким образом, чтобы он был выполнен в минимальное время с
наименьшими накладными расходами. Все это повышает быстродействие системы и снижает время
ожидания результата запроса. При выполнении запросов сервером существенно повышается сте-
пень безопасности данных, поскольку правила целостности данных определяются в базе данных
на сервере и являются едиными для всех приложений, использующих эту БД. Таким образом, ис-
ключается возможность определения противоречивых правил поддержания целостности. Мощный
аппарат транзакций, поддерживаемый SQL-серверами, позволяет исключить одновременное измене-
ние одних и тех же данных различными пользователями и предоставляет возможность откатов к
первоначальным значениям при внесении в БД изменений, закончившихся аварийно.
В архитектуре «клиент-сервер» используются так называемые серверные («удаленные», «промыш-
ленные») СУБД. СУБД этого класса могут обеспечить работу информационных систем масштаба
среднего и крупного предприятия, организации, банка. К таким СУБД принадлежат СУБД Oracle,
MS SQL Server, Informix, Sybase, DB2, InterBase и ряд других.
Основное достоинство данной архитектуры по сравнению с архитектурой «файл-сервер» – это
существенное уменьшение сетевого трафика. Основной недостаток – это высокая стоимость ком-
мерческих SQL-серверов.
7.5.5. Архитектура «клиент-сервер» трехзвенная

Рассмотренная выше архитектура «клиент-сервер» является двухзвенной: первое звено – это кли-
ентское приложение, второе звено – серверная СУБД и сама БД. Здесь вся бизнес-логика (деловая
логика) сосредоточена в клиентских приложениях.
В трехзвенной архитектуре «клиент-сервер» вся бизнес-логика выделяется в отдельное звено,
называемое сервером приложений, на котором располагается программное обеспечение делового
анализа (бизнес-логика). При этом в клиентских приложениях остается лишь пользовательский
интерфейс, реализуемый, например, с помощью Web-браузера. Такие клиентские приложения, ре-
ализующие лишь интерфейс пользователя, но не бизнес-логику, называются «тонким клиентом».
Тонкий клиент инициирует по запросам пользователя обращение к программному обеспечению дело-
вого анализа, расположенному на сервере приложений. Сервер приложений анализирует требования
пользователя и формирует запросы к БД. Для общения используется язык SQL, так что по сети от
сервера приложений к серверной СУБД передается лишь текст запроса. Серверная СУБД, инкапсу-
лируя внутри себя все сведения о физической структуре БД, расположенной на сервере, инициирует
обращения к данным, находящимся на сервере, и возвращает результат выполнения запроса на сер-
вер приложений. Сервер приложений передает результат в клиентское приложение (пользователю).
Клиентское приложение, используя пользовательский интерфейс, отображает результат выполнения
запросов.
Что улучшается при использовании трехзвенной архитектуры? Теперь при изменении бизнес-
логики больше нет необходимости изменять клиентские приложения и обновлять их у всех пользо-
вателей. Кроме того, максимально снижаются требования к клиентской аппаратуре.
7.5.6. Распределенные базы данных
Рассмотренные выше модели взаимодействия с БД предполагали, что база данных размещается на
одном компьютере. Но развитие вычислительных компьютерных сетей обусловило новые возможно-
сти в организации и ведении баз данных, позволяющие, с одной стороны, каждому пользователю
иметь на своем компьютере свои данные и работать с ними, и, с другой стороны, позволяющие
работать всем пользователям со всей совокупностью данных как с единой централизованной ба-
зой данных. Соответствующая совокупность данных называется распределенной базой данных.
Возможны и даже часто встречаются ситуации, когда фрагменты распределенной базы данных на
различных компьютерах в сети пересекаются, дублируются.
Система управления распределенной базой данных – это программная система, обеспечивающая
управление распределенной базой данных и позволяющая пользователю работать как с его локаль-
ными данными, так и со всей базой данных в целом. Система управления распределенной базой
данных является распределенной системой. Каждый фрагмент базы данных работает под управле-
нием отдельной СУБД, которая осуществляет доступ к данным этого фрагмента.
Пользователи взаимодействуют с распределенной базой данных через локальные и глобальные
приложения. Локальные приложения дают пользователю возможность работать со своими локаль-
ными данными и не требуют доступа к другим фрагментам. Глобальные приложения дают поль-
зователю возможность работать с другими фрагментами распределенной базы данных, расположен-
ными на других компьютерах сети. Объединение данных организуется виртуально. Соответствую-
щий подход, по сути, отражает организационную структуру предприятия, состоящего из отдельных
подразделений. Причем, хотя каждое подразделение обрабатывает свой набор данных, существует
необходимость доступа к этим данным, как к единому целому (в частности, для управления всем
предприятием).
Основной принцип технологии распределенных баз данных заключается в том, что доступ к
распределенной базе данных выглядит для клиента точно так же, как и доступ к централизованной
БД. Примером реализации такого принципа может служить Internet (данные вводятся и хранятся на
разных компьютерах по всему миру, но любой пользователь может получить доступ к этим данным,
не задумываясь о том, где они физически расположены).
Достоинством модели распределенной базы данных является приближение данных к месту их
порождения. Недостатком модели является достаточно высокая сложность управления данными как
единым целым.
7.5.7. Технология тиражирования данных

Альтернативой технологии распределенных баз данных является технология тиражирования дан-
ных, не требующая синхронной фиксации изменений. Действительно, далеко не во всех задачах
требуется обеспечение идентичности БД на различных узлах сети в любое время. Достаточно под-
держивать идентичность данных лишь в определенные критичные моменты времени. Следовательно,
можно накапливать изменения в данных в виде транзакций в одном узле сети и периодически фик-
сировать эти изменения в других узлах.
Функции тиражирования данных выполняет специальный модуль СУБД – сервер тиражирования
данных, называемый репликатором. Его задача – поддержка идентичности данных в базах данных
различных узлов сети.
Достоинством технологии тиражирования данных является увеличение производительности, так
как данные всегда расположены там, где они обрабатываются. Недостаток – в возможности возник-
новения конфликтов данных из-за асинхронной фиксации изменений.
7.6. Фрактальные методы сжатия BLOB
BLOB – это обобщенное название типов данных, предназначенных для хранения крупных двоичных
объектов (Binary Large OBjects). Такими объектами могут быть графические изображения в раз-
личных форматах (скажем, .gif или .jpeg), фрагменты видеозаписей (например, в кодировке .mpeg),
звук, сигналы радаров и т.д.
Работа с объектами BLOB в базах данных связана со многими технологическими проблемами.
Объект BLOB должен сохраняться в виде последовательности блоков. В определенных ситуациях
объект BLOB должен считываться настолько быстро, что при размещении его на одном дисковом
устройстве приемлемой скорости достичь не удается. Одним из решений такой проблемы является
попеременное распределение соседних блоков объекта по нескольким дискам. В этом случае группа
блоков может считываться одновременно, и скорость операции возрастает, грубо говоря, пропорци-
онально количеству используемых дисковых устройств.
Естественное требование о том, что блок данных, запрошенный клиентом, должен возвращаться
системой целиком, при возрастании размеров элементов данных подлежит радикальному пересмот-
ру. Можно полагать, что система должна передавать единовременно и полностью только «неболь-
шие» значения полей записей и позволять клиенту запрашивать отдельные блоки объекта BLOB, по
одному в каждый момент времени и независимо от наличия оставшихся блоков. Например, если объ-
ект BLOB представляет двухчасовой кинофильм и клиент выдает запрос на его воспроизведение,
система должна считывать и передавать клиенту последовательные блоки объекта с достаточной
скоростью.
Во многих случаях важно, чтобы клиенту была предоставлена возможность считывания отдель-
ных порций данных (скажем, титров кинофильма или финальной части аудиоклипа) независимо от
порядка их расположения «внутри» объекта и без необходимости загрузки объекта целиком. Если
система поддерживает подобные операции, ей, вероятно, требуются удобные структуры индексных
значений (например, указывающих на начало каждого секундного фрагмента видеофильма).
Для объектов BLOB особо остро стоит проблема сжатия данных. Рассмотрим некоторые подходы,
основанные на фрактальных методах сжатия изображений.
7.6.1. Понятие «фрактал»

Понятия фрактал и фрактальная геометрия, появившиеся в конце 1970-х, с середины 1980-х,
прочно вошли в обиход математиков и программистов. Слово фрактал образовано от латинского
fractus и в переводе означает состоящий из фрагментов. Оно было предложено Бенуа Мандельбро-
том в 1975 году для обозначения нерегулярных, но самоподобных структур, которыми он занимался.
Рождение фрактальной геометрии принято связывать с выходом в 1977 году книги Мандельброта
«The Fractal Geometry of Nature». В его работах использованы научные результаты других уче-
ных, работавших в период 1875-1925 годов в той же области (Пуанкаре, Фату, Жюлиа, Кантор,
Хаусдорф). Но только в настоящее время удалось объединить их работы в единую систему.
Роль фракталов в машинной графике сегодня достаточно велика. Они приходят на помощь, на-
пример, когда требуется с помощью нескольких коэффициентов задать линии и поверхности очень
сложной формы. С точки зрения машинной графики, фрактальная геометрия незаменима при гене-
рации искусственных облаков, гор, поверхности моря. Фактически найден способ легкого представ-
ления сложных неевклидовых объектов, образы которых весьма похожи на природные.
Одним из основных свойств фракталов является самоподобие. В самом простом случае небольшая
часть фрактала содержит информацию обо всем фрактале.
Определение фрактала, данное Мандельбротом, звучит так: «Фракталом называется структура,
состоящая из частей, которые в каком-то смысле подобны целому».
Для того, чтобы представить все многообразие фракталов, удобно прибегнуть к их общепринятой
классификации: фракталы геометрические, алгебраические, стохастические.
Рис. 7.7.: Триадная кривая Кох
7.6.2. Геометрические фракталы

Фракталы этого класса самые наглядные. В двухмерном случае их получают с помощью некоторой
ломаной (или поверхности в трехмерном случае), называемой генератором. За один шаг алгоритма
каждый из отрезков, составляющих ломаную, заменяется на ломаную-генератор в соответствую-
щем масштабе. В результате бесконечного повторения этой процедуры, получается геометрический
фрактал.
Один из таких геометрических фрактальных объектов – триадная кривая Кох.
Рис. 7.8.: «Дракон» Хартера-Хейтуэя
Построение кривой начинается с отрезка единичной длины – это 0-е поколение кривой Кох. Далее
каждое звено (в нулевом поколении один отрезок) заменяется на образующий элемент, соответству-
ющий n = 1. В результате такой замены получается следующее поколение кривой Кох. В 1-ом
поколении – это кривая из четырех прямолинейных звеньев, каждое длиной по 1/3. Для получения
следующего поколения проделываются те же действия – каждое звено заменяется на уменьшенный
образующий элемент. Кривая n-го поколения при любом конечном n называется предфракталом.
При n, стремящемся к бесконечности, кривая Кох становится фрактальным объектом.
Другим примером геометрического фрактального объекта является «дракон» Хартера-Хейтуэя.
Для его получения нужно изменить правила построения. Пусть образующим элементом будут два
равных отрезка, соединенных под прямым углом. В нулевом поколении заменим единичный отрезок
на этот образующий элемент так, чтобы угол был сверху. Можно сказать, что при такой замене
происходит смещение середины звена. При построении следующих поколений выполняется правило:
самое первое слева звено заменяется на образующий элемент так, чтобы середина звена смещалась
влево от направления движения, а при замене следующих звеньев, направления смещения середин
отрезков должны чередоваться. На рисунке представлены несколько первых поколений и 11-е поко-
ление кривой, построенной по вышеописанному принципу. Предельная фрактальная кривая при n,
стремящемся к бесконечности, называется «драконом» Хартера-Хейтуэя.
В машинной графике использование геометрических фракталов необходимо при получении изоб-
ражений деревьев, кустов, береговой линии. Двухмерные геометрические фракталы используются
для создания объемных текстур (рисунка на поверхности объекта).
7.6.3. Алгебраические фракталы

Это самая крупная группа фракталов. Получают их с помощью нелинейных процессов в n-мерных
пространствах. Наиболее изучены двухмерные процессы. Интерпретируя нелинейный итерационный
процесс, как дискретную динамическую систему, можно пользоваться терминологией теории этих
систем: фазовый портрет, установившийся процесс, аттрактор и т.д.
Нелинейные динамические системы обладают несколькими устойчивыми состояниями. То состо-
яние, в котором оказалась динамическая система после некоторого числа итераций, зависит от ее
начального состояния. Поэтому каждое устойчивое состояние (или, как говорят – аттрактор)
обладает некоторой областью начальных состояний, из которых система обязательно попадет в рас-
сматриваемые конечные состояния. Таким образом, фазовое пространство системы разбивается на
области притяжения аттракторов. Если фазовым является двухмерное пространство, то, окраши-
вая области притяжения различными цветами, можно получить цветовой фазовый портрет этой
Рис. 7.9.: Множество Мандельброта
системы (итерационного процесса). Меняя алгоритм выбора цвета, можно получить сложные фрак-
тальные картины с причудливыми многоцветными узорами. Неожиданностью для математиков стала
возможность с помощью примитивных алгоритмов порождать очень сложные нетривиальные струк-
туры.
В качестве примера рассмотрим множество Мандельброта.
Алгоритм его построения достаточно прост и основан на простом итеративном выражении:
Zi+1 = Zi ∗ Zi + C
Здесь Zi и C – комплексные переменные. Итерации выполняются для каждой стартовой точки
C прямоугольной или квадратной области – подмножестве комплексной плоскости. Итерационный
процесс продолжается до тех пор, пока Zi не выйдет за пределы окружности радиуса 2, центр
которой лежит в точке (0, 0), (это означает, что аттрактор динамической системы находится в бес-
конечности), или после достаточно большого числа итераций (например, 200-500) Zi сойдется к
Рис. 7.10.: Участок границы множества Мандельброта, увеличенный в 200 pаз
какой-нибудь точке окружности. В зависимости от количества итераций, в течение которых Zi оста-

валась внутри окружности, можно установить цвет точки C (если Zi остается внутри окружности
в течение достаточно большого количества итераций, итерационный процесс прекращается, и эта
точка растра окрашивается в черный цвет).
Ниже представлен участок границы множества Мандельброта, увеличенный в 200 pаз.
Множеству Мандельброта принадлежат точки, которые в течение бесконечного числа итераций не
уходят в бесконечность (точки, имеющие черный цвет). Точки, принадлежащие границе множества
(именно там возникает сложные структуры) уходят в бесконечность за конечное число итераций, а
точки лежащие за пределами множества, уходят в бесконечность через несколько итераций (белый
фон).
7.6.4. Стохастические фракталы
Еще одним известным классом фракталов являются стохастические фракталы, которые получаются
в том случае, если в итерационном процессе случайным образом менять какие-либо его параметры.
При этом получаются объекты очень похожие на природные – несимметричные деревья, изрезан-
ные береговые линии и т.д. Двумерные стохастические фракталы используются при моделировании
рельефа местности и поверхности моря.
Существуют и другие классификации фракталов, например деление фракталов на детерминиро-
ванные (алгебраические и геометрические) и недетерминированные (стохастические).
7.6.5. Системы итерируемых функций

Метод "Систем Итерируемых Функций"(Iterated Functions System – IFS) появился в середине 1980-х
годов как простое средство получения фрактальных структур.
IFS представляет собой систему функций из некоторого фиксированного класса функций, отоб-
ражающих одно многомерное множество на другое. Наиболее простая IFS состоит из аффинных
преобразований плоскости:
0
X = A × X + B × Y + CY 0 = D × X + E × Y + F
В 1988 году американские специалисты Барнсли и Слоан предложили некоторые идеи, основанные
на соображениях теории динамических систем, для сжатия и хранения графической информации.
Они назвали свой метод методом фрактального сжатия информации. Происхождение названия
связано с тем, что геометрические образы, возникающие в этом методе, обычно имеют фрактальную
природу в смысле Мандельброта.
На основании этих идей Барнсли и Слоан создали алгоритм, который, по их утверждению, поз-
волит сжимать информацию в 500-1000 раз. Вкратце метод можно описать следующим образом.
Изображение кодируется несколькими простыми преобразованиями (в нашем случае аффинными),
то есть коэффициентами этих преобразований (в нашем случае A, B, C, D, E, F ). Например, закоди-
ровав какое-то изображение двумя аффинными преобразованиями, мы однозначно определяем его
с помощью 12-ти коэффициентов. Если теперь задаться какой-либо начальной точкой (например,
X = 0, Y = 0) и запустить итерационный процесс, то мы после первой итерации получим две
точки, после второй – четыре, после третьей – восемь и т.д. Через несколько десятков итераций
совокупность полученных точек будет описывать закодированное изображение.
Для построения IFS применяют, кроме аффинных, и другие классы простых геометрических пре-
образований, которые задаются небольшим числом параметров.
Использование IFS для сжатия обычных изображений (например, фотографий) основано на выяв-
лении локального самоподобия, в отличие от фракталов, где наблюдается глобальное самоподобие
и нахождение IFS не слишком сложно. По алгоритму Барнсли происходит выделение в изображе-
нии пар областей, меньшая из которых подобна большей, и сохранение нескольких коэффициентов,
кодирующих преобразование, переводящее большую область в меньшую. Требуется, чтобы множе-
ство «меньших» областей покрывало все изображение. При этом в файл, кодирующий изображения
будут записаны не только коэффициенты, характеризующие найденные преобразования, но и ме-
стоположение и линейные размеры «больших» областей, которые вместе с коэффициентами будут
описывать локальное самоподобие кодируемого изображения. Восстанавливающий алгоритм, в этом
случае, должен применять каждое преобразование не ко всему множеству точек, получившихся на
предыдущем шаге алгоритма, а к некоторому их подмножеству, принадлежащему области, соответ-
ствующей применяемому преобразованию.
Информационные системы:
• Определите понятие информационной системы (ИС).
• Что понимается под предметной областью ИС?
• Что понимается под каскадной моделью жизненного цикла ИС?
• Что понимается под поэтапной итерационной моделью жизненного цикла ИС?
• Что понимается под спиральной моделью жизненного цикла ИС?
• Что понимается под СУБД? Какими специфическими свойствами должна обладать СУБД по
сравнению с обычными системами управления файлами?
• В чем специфика жизненного цикла баз данных? Какова роль средств автоматизированного
проектирования БД?
Модели данных:
• Что представляет собой иерархическая модель данных?
• Что представляет собой сетевая модель данных? В чем различие понятий простой и сложной
сетевых структур?
• Что означает термин «реляционная модель»?
• Дайте характеристику постреляционных моделей данных.
• Дайте характеристику объектно-ориентированных моделей данных.
• Дайте характеристику XML-ориентированных баз данных.
• В чем различие OLTP и OLAP-систем?
• Приведите логическую схему OLAP-системы.
• Опишите основные операции над многомерными данными.
Основные функции СУБД:
• Что понимается под управлением данными во внешней памяти?
• Что понимается под управлением буферами оперативной памяти?
• Что понимается под управлением транзакциями?
• Что понимается под журнализацией и восстановлением БД после сбоев?
• В чем заключается поддержка языков баз данных?
Типовая организация СУБД:
• Какие функции выполняет ядро СУБД?
• Какую основную функцию выполняет компилятор языка БД?
• Что представляет собой подсистема поддержки времени выполнения?

• Какие процедуры выделяют в утилиты БД?
Модели взаимодействия с БД:
• Что понимается под многопользовательским использованием данных в модели с централизо-
ванной архитектурой?
• В чем заключается работа механизма репликации в модели с автономными персональными

компьютерами?
• Опишите архитектуру «файл-сервер».
• Опишите архитектуру «клиент-сервер».
• Опишите особенности трехзвенной архитектуры «клиент-сервер». Что называется «тонким кли-

ентом»?
• Что понимается под распределенной базой данных?
• В чем заключается технология тиражирования данных?

Фрактальные методы сжатия BLOB:
• Что означает термин BLOB?
• Дайте определение понятия фрактала.
• Приведите примеры геометрических фракталов.
• Приведите пример алгебраического фрактала.

• В чем заключается особенность получения стохастических фракталов?
• В чем заключается метод фрактального сжатия информации на основе систем итерируемых

функций?
Литература
[1] Olap-технологии. http://olap.ru/.
[2] Основы sql // Интернет-Университет Информационных Технологий. http://www.intuit.
ru/.
[3] Буре, Р. Xml и базы данных. http://www.osp.ru/os/2000/10/062.htm.
[4] Буч, Г. Язык UML. Руководство пользователя / Г. Буч, Д. Рамбо, Джекобсон А. Пер. с англ. —
М.: ДМК, 2000. — С. 432.
[5] Гарсиа-Молина, Г. Системы баз данных. Полный курс / Г. Гарсиа-Молина, Дж. Д. Ульман,
Дж. Уидом. Пер. с англ. — М.: Издательский дом “Вильямс”, 2003. — С. 1088.
[6] Дейт, К. Дж. Введение в системы баз данных / К. Дж. Дейт. Пер. с англ. — 6-е изд. — К.:
Диалектика, 1998. — С. 784.
[7] Когаловский, М. Р. Энциклопедия технологий баз данных / М. Р. Когаловский. — М.: Финансы
и статистика, 2002. — С. 800.
[8] Мейер, Д. Теория реляционных баз данных / Д. Мейер. Пер. с англ. — 6-е изд. — М.: Мир,
1987. — С. 608.
[9] Нейбург, Э. Дж. Проектирование баз данных с помощью UML / Э. Дж. Нейбург, Р. А. Мак-
симчук. Пер. с англ. — М.: Издательский дом “Вильямс”, 2002. — С. 288.
[10] Рамбо, Дж. UML: специальный справочник / Дж. Рамбо, А. Якобсон, Буч Г. Пер. с англ. —
СПб.: Питер, 2002. — С. 656.
[11] Шабаршин, А. А. Введение во фракталы. http://members.xoom.com/_XMCM/

treestation/fractals.htm.
[12] Швецов, В. И. Базы данных. Учебное пособие / В. И. Швецов, А. Н. Визгунов, И. Б. Мееров. —

Нижний Новгород: Изд-во ННГУ, 2004. — С. 217.
Список иллюстраций
2.1. Таблица tblОценки . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
2.2. Схема данных . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
2.3. Запрос qryДиаграмма . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
2.4. Мастер диаграмм . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
2.5. Запрос qryОтчет . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
2.6. Запрос qryВедомостьСводная . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
3.1. Объединение, пересечение и разность . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87

3.2. Декартово произведение . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88
3.3. Естественное соединение . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
3.4. Свойства бинарных операций . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90
3.5. Пример. Операнды соединений . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
3.6. Пример. Внутреннее и левое соединения . . . . . . . . . . . . . . . . . . . . . . . . . . 93
3.7. Пример. Правое и внешнее соединения . . . . . . . . . . . . . . . . . . . . . . . . . . . 94
3.8. Круги Эйлера . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
3.9. Пример. Естественное соединение . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
3.10. Пример. Декартово произведение . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96
4.1. Модификация таблицы со счетчиком . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126
4.2. Индексы . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131
4.3. Внешние ключи как механизм ссылок . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136
4.4. Декларативная поддержка ссылочной целостности . . . . . . . . . . . . . . . . . . . . 143
5.1. Ненормализованное отношение . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162

5.2. Нормализованные отношения . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173
5.3. Виды атрибутов . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173
5.4. Пример допустимого состояния R . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183
5.5. Диаграмма вложений нормальных форм . . . . . . . . . . . . . . . . . . . . . . . . . . . 185
6.1. Диаграмма со связью типа один-ко-многим . . . . . . . . . . . . . . . . . . . . . . . . . 192

6.2. Изображение класса сущностей . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 198
6.3. Типы связей в зависимости от вида связи . . . . . . . . . . . . . . . . . . . . . . . . . . 199
6.4. Миграция в PF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 200
6.5. Миграция в FK . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 201
6.6. Презентационная диаграмма . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 204
6.7. Ключевая диаграмма . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 205
6.8. Пример в табличной форме . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 205
6.15. Ключевая диаграмма. Сетевая реализация иерархической рекурсии . . . . . . . . . . . 214
6.21. Пример двудольного графа . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 221
6.27. Связь «обобщение-категория» в нотации UML . . . . . . . . . . . . . . . . . . . . . . . 228
6.33. Cвязь «композит-компонент» в нотации UML . . . . . . . . . . . . . . . . . . . . . . . 236
6.34. Cвязь «композит-компонент» в нотации UML с указанием кратности . . . . . . . . . . 236
6.40. Связь «агрегат-компонент» в нотации UML . . . . . . . . . . . . . . . . . . . . . . . . 242
6.45. Ключевая диаграмма до унификации атрибутов . . . . . . . . . . . . . . . . . . . . . . 249
6.46. Ключевая диаграмма после унификации атрибутов . . . . . . . . . . . . . . . . . . . . 250
7.1. Каскадная модель . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 265

7.2. Итерационная модель . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 266
7.3. Спиральная модель . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 267
7.4. Пример одного из деревьев базы медицинских данных . . . . . . . . . . . . . . . . . . 273
7.5. Пример структурной диаграммы базы медицинских знаний . . . . . . . . . . . . . . . 276
7.6. Логическая схема OLAP-системы . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 285
7.7. Триадная кривая Кох . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 303
7.8. «Дракон» Хартера-Хейтуэя . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 304
7.9. Множество Мандельброта . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 306
7.10. Участок границы множества Мандельброта, увеличенный в 200 pаз . . . . . . . . . . 307
Список таблиц
3.1. Интерпретации null-значения . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
3.2. Таблица истинности . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
3.3. Операции с null-значением . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
3.4. Предикат IsNull . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
Предметный указатель
k-дольный граф, 122 дерево, 16, 105
БД, 12, 76 детализация, 29
СУБД, 11 дочерний ключ, 94
СУБД с равноправными (однотипными) файла- домен, 24
ми, 18 домен атрибута, 71
агрегация, 141 двудольный мультиграф, 121
агрегация кластеров, 102 естественное соединение, 80
агрегация общего вида, 102, 144 эксплуатация, 7
агрегата, 141 файловый сервер, 39
аппаратный сбой, 31 фазовый портрет, 48
архивная копия, 33 формы представления, 20
ассоциация, 101 фрактал, 45
ассоциативные сущности, 110 фрактальная геометрия, 45
атрибут, 23, 72 функция переименования, 79
аттрактор, 48 генератор, 46
близнецы, 16 глобальные приложения, 42
декартово произведение, 80 хранилище данных, 26
идентифицирующая связь, 95 кортеж, 74
иерархическая БД, 16 лес, 105
иерархическая рекурсия, 101 лист, 16
иерархическая связь, 102 локальные приложения, 42
иерархия категорий, 125 механизм репликации, 38
именующая сущность, 118 метод фрактального сжатия информации, 51
информационная система, 5 миграция ключей, 94
итерационная модель, 9 многопользовательский режим, 38
измерение, 27 множественное наследование, 24
изображения, 20 множество Мандельброта, 49
каскадная модель, 7 модель жизненного цикла, 7
категориальная идентифицирующая связь, 95 модернизация, 7
категориальных сущностей, 127 мультиграф, 113
класс, 24 мягкий сбой, 31
класс сущностей, 90 надежность хранения, 31
кластер, 101 наследование, 24
клиентский компьютер, 39 настольные СУБД, 39
клиентское приложение, 39 неидентифицирующая связь, 95
ключевые диаграммы, 92 необязательная неидентифицирующая связь, 95
компилятор языка БД, 37 неопределенное значение, 60
компоненты, 134, 141 неполностью идентифицирующая связь, 95
композиция, 131 нулевое значение, 61
композиция кластеров, 102 объединение, 80
композита, 134 объект, 23
корень, 16 область притяжения, 48
обобщение, 125 простое наследование, 24
обобщение кластеров, 101 пустое значение, 61
обобщенные сущности, 127 распределенная БД, 42
обязательная неидентифицирующая связь, 95 разность, 80
однопользовательский режим, 37 разработка, 6
оператор переименования, 79 рекурсивная связь, 101, 102
оператор проекции, 78 реплика, 38
оператор выборки, 78 репликатор, 43
основная реплика, 38 решетка классов, 24
отношение, 75 родительский ключ, 94
пересечение, 80 сечение, 29
подкласс, 24 секция ограничений, 96
подсхема, 78 сервер приложений, 41
подсистемы поддержки времени выполнения, 37 сетевая рекурсия, 101
полные атрибутивные диаграммы, 93 схема БД, 76
полностью идентифицирующая связь, 95 схема миграции, 94
постреляционная модель, 22 схема отношения, 73
потомок, 16 система управления распределенной БД, 42
поведение объекта, 23 сложная сетевая структура, 18
предфрактал, 47 соединимые кортежи, 81
предок, 16 сопровождение, 7
презентационные диаграммы, 92 состояние объекта, 23
проектируемые связи, 96 спиральная модель, 9
программный сбой, 31 спроектированные связи, 96
простая сетевая структура, 18 степень отношения, 73
суперкласс, 24 жесткий сбой, 31
свертка, 29 жизненный цикл, 6
связь предок/потомок, 102 журнал, 32
технология тиражирования данных, 43 журнализация, 31
тип атрибута, 71 «дракон» Хартера-Хейтуэя, 47
транзакция, 31 «тонкий клиент», 41
три уровня логической модели, 92
триадная кривая Кох, 46 BLOB, 44
унификация атрибутов, 147 n-арной ассоциация, 118
управление буферами оперативной памяти, 30 null, 60
управление данными во внешней памяти, 30
управление проектом, 7 OLAP, 26
управление транзакциями, 31 OLTP, 26
условие выборки, 78
условная дизъюнкция, 64 SQL-сервер, 40
условная конъюнкция, 64
XML-ориентированные БД, 25
утилиты БД, 37
узел, 16
верификация, 7
вращение, 29
взвешенный граф, 113
взвешенное деревр, 105
ядро СУБД, 36
языкы баз данных, 34
значение, 27

Ковалёв А.Д. - Базы данных

Загружено:

Сведения о документе

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

Ковалёв А.Д. - Базы данных

Загружено:

Авторское право:

Доступные форматы

САРАТОВСКИЙ ГОСУНИВЕРСИТЕТ

Дата последнего обновления 3 апреля 2009 г.

III. Модуль 2 120

IV. Модуль 3 160

VI. Дополнительные главы 261

Список иллюстраций 316

Список таблиц 320

Предметный указатель 321

1) Для варианта контрольной работы, согласованного с преподавателем, требуется по описанию

3) Подготовить отчет в печатной или электронной форме (по согласованию с преподавателем).

• keyСлушатель: ключевое поле, счетчик;

• Фамилия, Имя, Отчество:

– свойство Обязательное поле – «Да»,

– свойство Значение по умолчанию – отсутствует,

• keyПредмет: ключевое поле, счетчик;

– свойство Обязательное поле – «Да»,

Наименование, вообще говоря, следовало бы объявить индексированным полем (совпадения не до-

• keyПреподаватель: ключевое поле, счетчик;

– свойство Обязательное поле – «Да»,

• Оценка: ключевое поле.

Это выражение удобно построить из выражения для поля subСлушателиФИО_УдостНомер, ско-

• keyВедомостиЗапись: ключевое поле, счетчик;

– свойство Обязательное поле – «Да»,

Рис. 2.2.: Схема данных

2) убедиться, что удаление записей из таблиц tblПредметы и tblПреподаватели невозможно,

• задать условное форматирование таким образом, чтобы при неудовлетворительных оценках

• Оценка – tblВедомость!Оценка, Условие отбора – «< > 0».

• Установить необходимые параметры запуска (меню Сервис Параметры запуска).

Развитие постановки задачи

Клиенты (Код клиента, Фамилия, Имя, Отчество, Паспортные данные, Комментарий).

Развитие постановки задачи

Товары (Код товара, Наименование, Оптовая цена, Розничная цена, Описание).

Развитие постановки задачи

Заказчики (Код заказчика, Наименование, Адрес, Телефон, Контактное лицо).

Развитие постановки задачи

Работодатели (Код работодателя, Название, Вид деятельности, Адрес, Телефон).

Развитие постановки задачи

Клиенты (Код клиента, Название, Вид деятельности, Адрес, Телефон).

Развитие постановки задачи

Поставщики (Код поставщика, Название, Адрес, Телефон).

Развитие постановки задачи

Группы (Номер группы, Специальность, Отделение, Количество студентов).

Развитие постановки задачи

Студенты (Код студента, Фамилия, Имя, Отчество, Адрес, Телефон).

Развитие постановки задачи

Преподаватели (Код преподавателя, Фамилия, Имя, Отчество, Ученая степень, Должно

Развитие постановки задачи

Сотрудники (Код сотрудника, Фамилия, Имя, Отчество, Оклад).

Развитие постановки задачи

Виды станков (Код вида станка, Страна, Год выпуска, Марка).

Развитие постановки задачи

Маршруты (Код маршрурта, Название, Дальность, Количество дней в пути, Оплата).

Развитие постановки задачи

Абоненты (Код абонента, Номер телефона, ИНН, Адрес).

Развитие постановки задачи

Отделы (Код отдела, Название, Количество сотрудников).

Развитие постановки задачи

Развитие постановки задачи

Автомобили (Код автомобиля, Марка, Стоимость, Стоимость проката, Тип).

Развитие постановки задачи

Виды кредитов (Код вида, Название, Условия получения, Ставка, Срок).

Развитие постановки задачи

Развитие постановки задачи

Актеры (Код актера, Фамилия, Имя, Отчество, Звание, Стаж).