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

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

МЕХАНИКО-МАТЕМАТИЧЕСКИЙ ФАКУЛЬТЕТ

Базы данных

Подготовил Ковалев А. Д.

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

Оглавление

I. Установочный модуль 11

1. Введение 12

2. Практическое задание 15

2.1. Формулировка задания . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162.2. Пример выполнения задания . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

2.2.1. Описание предметной области . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172.2.2. Шаг 0 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172.2.3. Шаг 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172.2.4. Шаг 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 202.2.5. Шаг 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 212.2.6. Шаг 4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 232.2.7. Шаг 5 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 242.2.8. Шаг 6 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 242.2.9. Шаг 7 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

2

2.2.10. Шаг 8 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 252.2.11. Шаг 9 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 262.2.12. Шаг 10 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 292.2.13. Шаг 11 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 312.2.14. Шаг 12 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

2.3. Варианты контрольных работ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 342.3.1. Страховая компания . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 342.3.2. Гостиница . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 362.3.3. Ломбард . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 372.3.4. Реализация готовой продукции . . . . . . . . . . . . . . . . . . . . . . . . . . . 382.3.5. Ведение заказов . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 392.3.6. Бюро по трудоустройству . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 402.3.7. Нотариальная контора . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 412.3.8. Фирма по продаже запчастей . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 422.3.9. Курсы по повышению квалификации . . . . . . . . . . . . . . . . . . . . . . . . 432.3.10. Определение факультативов для студентов . . . . . . . . . . . . . . . . . . . . . 442.3.11. Распределение учебной нагрузки . . . . . . . . . . . . . . . . . . . . . . . . . . . 452.3.12. Распределение дополнительных обязанностей . . . . . . . . . . . . . . . . . . . 462.3.13. Техническое обслуживание станков . . . . . . . . . . . . . . . . . . . . . . . . . 472.3.14. Туристическая фирма . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 482.3.15. Грузовые перевозки . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 492.3.16. Учет телефонных переговоров . . . . . . . . . . . . . . . . . . . . . . . . . . . . 502.3.17. Учет внутриофисных расходов . . . . . . . . . . . . . . . . . . . . . . . . . . . . 512.3.18. Библиотека . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 522.3.19. Прокат автомобилей . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53

2.3.20. Выдача банком кредитов . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 542.3.21. Инвестирование свободных средств . . . . . . . . . . . . . . . . . . . . . . . . . 552.3.22. Занятость актеров театра . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 562.3.23. Платная поликлиника . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 572.3.24. Анализ динамики показателей финансовой отчетности различных предприятий 582.3.25. Учет телекомпанией стоимости прошедшей в эфире рекламы . . . . . . . . . . 592.3.26. Интернет-магазин . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 602.3.27. Ювелирная мастерская . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 612.3.28. Парикмахерская . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 622.3.29. Химчистка . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 632.3.30. Сдача в аренду торговых площадей . . . . . . . . . . . . . . . . . . . . . . . . . 64

II. Модуль 1 65

3. Реляционная алгебра 66

3.1. Отсутствующие данные . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 663.2. Пустые значения . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 673.3. Неопределенные значения . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68

3.3.1. Интерпретации . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 683.3.2. Правила вычисления выражений . . . . . . . . . . . . . . . . . . . . . . . . . . . 693.3.3. Следствия . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 713.3.4. Проверка условий . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74

3.4. Реляционные объекты данных . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 753.4.1. Формальные определения . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77

3.4.2. Домены и атрибуты . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 773.4.3. Схема отношения . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 793.4.4. Именованное значение атрибута . . . . . . . . . . . . . . . . . . . . . . . . . . . 793.4.5. Кортеж . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 803.4.6. Отношение . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 813.4.7. Схема базы данных . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 823.4.8. База данных . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82

3.5. Операции реляционной алгебры . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 823.5.1. Унарные операции . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 833.5.2. Бинарные операции . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 863.5.3. Варианты операции соединения . . . . . . . . . . . . . . . . . . . . . . . . . . . 913.5.4. Производные операции . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92

3.6. Пример построения выражения реляционной алгебры . . . . . . . . . . . . . . . . . . . 963.7. Понятие базовых и виртуальных отношений . . . . . . . . . . . . . . . . . . . . . . . . 983.8. Понятие полноты реляционной алгебры . . . . . . . . . . . . . . . . . . . . . . . . . . . 993.9. Формирование запросов на языке SQL . . . . . . . . . . . . . . . . . . . . . . . . . . . 100

3.9.1. Реализация операций реляционной алгебры . . . . . . . . . . . . . . . . . . . . 1013.9.2. Пример использования подзапросов . . . . . . . . . . . . . . . . . . . . . . . . . 1093.9.3. Группирующие запросы . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1103.9.4. Упорядочение результатов . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113

3.10. Вопросы для самоконтроля . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114

III. Модуль 2 120

4. Базовые и виртуальные отношения 121

4.1. Типы данных . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1214.1.1. Базовые типы данных . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1214.1.2. Типы данных, определяемые пользователем . . . . . . . . . . . . . . . . . . . . 127

4.2. Первичные и кандидатные ключи . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1284.3. Индексы . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1304.4. Создание базовых отношений . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1324.5. Модификация базовых отношений . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137

4.5.1. Вставка строк . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1374.5.2. Обновление строк . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1384.5.3. Удаление строк . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139

4.6. Целостность . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1404.6.1. Декларативная поддержка . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1404.6.2. Пример декларативной поддержки целостности . . . . . . . . . . . . . . . . . . 1444.6.3. Транзакции и блокировки . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1474.6.4. Триггеры . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 150

4.7. Виртуальные отношения . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1534.8. Вопросы для самоконтроля . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 154

IV. Модуль 3 160

5. Нормальные формы 161

5.1. Функциональные зависимости (ФЗ) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1615.1.1. Правила вывода Армстронга . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 164

5.1.2. Производные правила вывода . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1665.1.3. Независимость правил Армстронга . . . . . . . . . . . . . . . . . . . . . . . . . 1675.1.4. Полнота системы правил Армстронга . . . . . . . . . . . . . . . . . . . . . . . . 169

5.2. Нормальные формы . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1715.2.1. Первая нормальная форма (1NF) . . . . . . . . . . . . . . . . . . . . . . . . . . 1725.2.2. Вторая нормальная форма (2NF) . . . . . . . . . . . . . . . . . . . . . . . . . . . 1765.2.3. Третья нормальная форма (3NF) . . . . . . . . . . . . . . . . . . . . . . . . . . . 1795.2.4. Нормальная форма Бойса-Кодда (Boyce, Codd; NFBC)) . . . . . . . . . . . . . . 1815.2.5. Пример построения нормализованных схем отношений . . . . . . . . . . . . . . 185


V. Модуль 4 190

6. Проектирование схем баз данных 191

6.1. Уровни логической модели . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1936.2. Миграция ключей и виды связей . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1956.3. Классификация кластеров . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2026.4. Иерархическая рекурсия . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 203

6.4.1. Абстрактная схема . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2036.4.2. Обобщения . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2066.4.3. Пример реализации иерархической рекурсии . . . . . . . . . . . . . . . . . . . . 207

6.5. Сетевая рекурсия . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2106.5.1. Абстрактная схема . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2106.5.2. Сетевая реализация иерархической рекурсии . . . . . . . . . . . . . . . . . . . . 213

6.5.3. Обобщения . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2146.5.4. Пример реализации сетевой рекурсии . . . . . . . . . . . . . . . . . . . . . . . . 216

6.6. Ассоциация . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2196.6.1. Детализация связей многие-ко-многим . . . . . . . . . . . . . . . . . . . . . . . 2206.6.2. Обобщения . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2226.6.3. Пример реализации ассоциации . . . . . . . . . . . . . . . . . . . . . . . . . . . 224

6.7. Обобщение . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2286.7.1. Абстрактная схема . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2286.7.2. Пример реализации обобщения . . . . . . . . . . . . . . . . . . . . . . . . . . . 229

6.8. Композиция . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2336.8.1. Абстрактная схема . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2336.8.2. Пример реализации композиции . . . . . . . . . . . . . . . . . . . . . . . . . . . 239

6.9. Агрегация . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2426.9.1. Абстрактная схема . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2426.9.2. Пример реализации агрегации . . . . . . . . . . . . . . . . . . . . . . . . . . . . 245

6.10. Унификация атрибутов . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2486.11. Вопросы для самоконтроля . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 251

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

7. Технологии баз данных 262

7.1. Информационные системы . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2627.1.1. Жизненный цикл ИС . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2637.1.2. СУБД и БД . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 268

7.1.3. Жизненный цикл БД и средства автоматизированного проектирования . . . . 2697.2. Модели данных . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272

7.2.1. Иерархическая модель данных . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2737.2.2. Сетевая модель данных . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2757.2.3. Реляционная модель данных . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2777.2.4. Постреляционная модель данных . . . . . . . . . . . . . . . . . . . . . . . . . . 2797.2.5. Объектно-ориентированные модели данных . . . . . . . . . . . . . . . . . . . . 2797.2.6. XML как модель данных . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2817.2.7. Многомерная модель данных (OLAP) . . . . . . . . . . . . . . . . . . . . . . . . 282

7.3. Основные функции СУБД . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2867.3.1. Управление данными во внешней памяти . . . . . . . . . . . . . . . . . . . . . . 2877.3.2. Управление буферами оперативной памяти . . . . . . . . . . . . . . . . . . . . . 2877.3.3. Управление транзакциями . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2887.3.4. Журнализация и восстановление БД после сбоев . . . . . . . . . . . . . . . . . 2887.3.5. Поддержка языков баз данных . . . . . . . . . . . . . . . . . . . . . . . . . . . . 291

7.4. Типовая организация СУБД . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2927.5. Модели взаимодействия с БД . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 294

7.5.1. Модель с централизованной архитектурой . . . . . . . . . . . . . . . . . . . . . 2947.5.2. Модель с автономными персональными компьютерами . . . . . . . . . . . . . . 2957.5.3. Архитектура «файл-сервер» . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2967.5.4. Архитектура «клиент-сервер» . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2967.5.5. Архитектура «клиент-сервер» трехзвенная . . . . . . . . . . . . . . . . . . . . . 2987.5.6. Распределенные базы данных . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2997.5.7. Технология тиражирования данных . . . . . . . . . . . . . . . . . . . . . . . . . 300

7.6. Фрактальные методы сжатия BLOB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 301

7.6.1. Понятие «фрактал» . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3027.6.2. Геометрические фракталы . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3037.6.3. Алгебраические фракталы . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3057.6.4. Стохастические фракталы . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3087.6.5. Системы итерируемых функций . . . . . . . . . . . . . . . . . . . . . . . . . . . 308


Литература 314

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

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

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

Часть I.

Установочный модуль

11

1. Введение

Традиционная тема курса – модели данных – рассматривается с той или иной степенью детализациив широком диапазоне: модели иерархическая, сетевая, реляционная, постреляционная, объектно-ориентированая, XML, OLAP.При рассмотрении основных функций СУБД выделяются функции управления данными во внеш-

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

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

гические вопросы разработки РБД.Вводится реляционная алгебра. Анализируется проблема неопределенных значений и ее влияние

на методы обработки данных. Формализуется понятие базы данных на наиболее абстрактном уровне.Вводятся реляционные операции и их варианты, анализируется независимость операций. На алгеб-раическом уровне водятся понятия базовых и виртуальных отношений. Описывается реализацияопераций реляционной алгебры на языке баз данных SQL. Демонстрируется техника использованияSQL-подзапросов.

12

Рассматривается внутреннее устройство базовых и виртуальных отношений. Определяются базо-вые типы данных и типы данных, определяемые пользователем. Описывается техника индексирова-ния. Описываются SQL-конструкции для создания и модификации отношений.Анализируются декларативные и процедурные методы поддержания целостности БД с использо-

вание механизма транзакций и триггеров.Излагается теория нормализации (до NFBC включительно). Вводится понятие функциональных

зависимостей, и обосновываются правила вывода Армстронга. Определяются и анализируются 1NF,2NF, 3NF, NFBC.Описывается методология проектирования схем баз данных в стиле UML. Вводятся понятия диа-

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

тов, что актуально для мультимедийных БД.О контрольных работах (лабораторном практикуме). К пособию прилагается задания на выполне-

ние лабораторных работ с примерами ее выполнения.Цель работы – приобретение практических навыков анализа и моделирования предметной об-

ласти; ознакомление с работой специализированных CASE-средств; изучение подхода к обработкеданных на основе применения языка SQL; при наличии возможностей – ознакомление с архитекту-рой «клиент-сервер».Лабораторный практикум предполагает последовательное выполнение студентами 3-х циклов ла-

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

но) и списки рекомендуемой литературы.

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

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

обучения и преподавателям.

2. Практическое задание

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

предметной области, а также знакомятся с работой в СУБД.Построенная реляционная модель реализуется средствами СУБД. Вводятся тестовые данные.Во втором цикле лабораторных работ изучаются запросы языка SQL и строится простой интер-

фейс пользователя. Студенты самостоятельно формируют различные SQL–запросы, получая навыкирешения конкретных практических задач.В третьем цикле лабораторных работ студенты самостоятельно расширяют предметную область

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

15

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

65

3. Реляционная алгебра

3.1. Отсутствующие данные

Проблема отсутствующих данных довольно часто встречается в реальной жизни. Например, в ис-торических записях встречаются такие записи, как «Дата рождения неизвестна»; в повестке днясобрания часто докладчик «указан» в виде «Будет объявлен»; милицейские доклады могут включатьтакие записи, как «номер автомобиля неизвестен».Для решения проблемы представления отсутствующих данных был предложен подход, основанный

на использовании специального маркера, соответствующего понятию неопределенных значений иназываемого null-значением (будем произносить «нул-значение» вместо «нал-значение»).В различных источниках на неопределенное значение, то есть на null-значение, часто ссылаются

как на «пустое значение» или «нулевое значение». Однако нулевое значение, то есть число 0 –это пустое значение для числовых типов данных, а понятия пустого и неопределенного значенийпринципиально различаются. Поэтому необходимо обращать внимание на контекст употребленияэтих терминов.Вначале рассмотрим понятие пустого значения.

66

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) в условиях действия законов поглощения:

false andx⇒ x and false := false, true orx⇒ x or true := true

Здесь символ подстановки «:=» разделяет список выражений и значение, которым они мо-гут быть заменены. Таким образом, законы поглощения имеют место при любых значенияхоперанда, в том числе и при значении null:

false andnull⇒ null and false := false, true ornull⇒ 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 truefalse false false falsefalse null false nullfalse true false true

null nullnull false false nullnull null null nullnull true null true

true falsetrue false false truetrue null null truetrue true true true

Таблица 3.3.: Операции с null-значением

Тип операции Выражение Значение

арифметич.x × 0

nullx – x

булевый x or not x nullстроковый ’Иванов’ + ’ ’ + x null

сравнения

x < x

nullx = xx 6= xx > 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) trueIsNull(2 × null) true

3.3.4. Проверка условий

Как null-значения влияют на проверку условий в условных операторах и операторах цикла? В кон-тексте возможных логических значений false, null и true null-значение имеет смысл как бы третьегологического значения, и потому на него часто ссылаются как на значение unknown – «неизвестный».Однако в СУБД реализуется двухзначная логика. Поэтому неопределенное условие, то есть усло-

вие с null-значением, должно быть проинтерпретировано либо как false, либо как true.В условных операторах и операторах цикла неопределенное условие по умолчанию интерпретиру-

ется как false:if P then A else B – при IsNull(P) выполнится Bif not P then B else A – при IsNull(P) выполнится Awhile 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 Bwhile IfNull(P, false) do A; BIfNull(ограничение_целостности, 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) σ〈P 〉r(S) = {t(S) | t ∈ r&σ〈P 〉t}

2) π〈S ′〉r(S) ≡ r[S ′]{t′(S ′) | ∃t ∈ r(t[S ′] = t′)}, S ′ ⊆ S

3) ρ〈ϕ〉r(S) = {t̃(S̃) | ρ〈ϕ−1〉t̃ ∈ r}, ϕ : S → S̃, ϕ−1 : S̃ → S

Примечание. Обозначения унарных операторов σ, π, ρ – от Select, Project, Rename. Параметры этихоператоров записываются в угловых скобках. Схемы отношений для отношений и их кортежей записываютсяв круглых скобках. Указание схемы отношения для отношений и кортежей во многих случаях опускается, таккак отношения и принадлежащие им кортежи имеют одну и ту же схему и в формулах достаточно указатьсхему хотя бы в одном месте – для отношения или принадлежащего ему кортежа. В квадратных скобкахзаписывается схема отношения, которую получает отношение-операнд в результате проекции. Таким образом,и r(S), и r[S′] имеют указанные в скобках схемы S и S′ соответственно, но во втором случае схема самогоотношения S является надсхемой указанной схемы проекции S′ •

Оператор выборки σ〈P 〉 с условием выборки P ≡ P (S) в применении к отношению r(S) даетновое отношение с той же схемой S, состоящее из тех кортежей t(S) исходного отношения, которыеудовлетворяют условию P 〈S〉t. Условие выборки P 〈S〉 записывается как выражение исчисления вы-сказываний (с логическими связками not, and, or), зависящее от имен атрибутов схемы отношения.Применение условия к кортежу P 〈S〉t сводится к подстановке значений атрибутов кортежа вме-сто имен атрибутов. Null-значение условия выборки по умолчанию интерпретируется как false, тоесть условие выборки P 〈S〉 по умолчанию рассматривается как IfNull(P 〈S〉, false). (Напомним, чтоIfNull(•,•) – это функция подмены null-значений.) Если требуется иная интерпретация, то следуетусловие выборки P 〈S〉 в операторе выборки σ〈P 〉 заменить на IfNull(P 〈S〉, true). При такой заменеусловие выборки уже не будет принимать null-значений, и правило интерпретации по умолчанию небудет действовать, так как IfNull(IfNull(P 〈S〉, true), false) = IfNull(P 〈S〉, true).Следующее выражение описывает неименованное отношение, содержащее (в терминах таблиц) те

строки таблицы Сессия, которые удовлетворяют заданному условию выборки:

σ〈Предмет = ’БД’ and Оценка〉Сессия(№ ЗК, Ф, И, О, Предмет, Оценка)

Оператор проекции π〈S ′〉 (в префиксной записи) и [S ′] (в постфиксной записи) на подсхемуS ′ в применении к отношению r(S) дает отношение с новой схемой S ′, состоящее из проекцийt[S ′] кортежей исходного отношения. Проекция кортежа соответствует подстроке строки таблицы иопределяется следующим образом:

t[S ′] ≡ t(S)[S ′] = {x(a) | a ∈ def(t) ∩ S ′}, S ′ ⊆ S

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

Сессия[№ ЗК, Предмет, Оценка]Оператор переименования ρ〈σ〉 с функцией переименования σ : S → S̃, устанавливающей вза-

имно однозначное соответствие между именами атрибутов схем S и S̃, в применении к отношениюr(S) дает отношение со схемой S̃, состоящее из кортежей исходного отношения с переименованнымиатрибутами.Следующее выражение описывает неименованное отношение, полученное (в терминах таблиц) из

таблицы Сессия заменой имен атрибутов (№ ЗК, Оценка) на (№ зачетки, Балл) соответственно:

ρ〈№ ЗК, Оценка→№ зачетки, Балл〉Сессия(№ ЗК, Ф, И, О, Предмет, Оценка)

Из определений операций следуют следующие свойства.Группа 1. Соотношения мощностей:

1) |σ〈P 〉r| 6 |r|

2) |r[S ′]| 6 |r|

3) |ρ〈σ〉r| = |r|

Примечание. Операция выборки связана с вычеркиванием кортежей. Из результата проекции дубликатыкортежей исключаются. Переименование атрибутов не изменяет числа кортежей •Группа 2. Свойства идемпотентности:

1) σ〈P 〉σ〈P 〉r = σ〈P 〉r

2) r[S ′]r[S ′] = r[S ′]

3) ρ〈ϕ2〉ρ〈ϕ1〉r(S) = ρ〈ϕ2 ◦ ϕ1〉r, ϕ1 : S → S1 ϕ2 : S1 → S2, ϕ2 ◦ ϕ1 : S → S2

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

1) r1 ⊆ r2 ⇒ σ〈P 〉r1 ⊆ σ〈P 〉r2

2) r1 ⊆ r2 ⇒ r1[S′] ⊆ r2[S

′]

3) r1 ⊆ r2 ⇒ ρ〈σ〉r1 ⊆ ρ〈σ〉r2

Примечание. Все три унарных оператора монотонны •

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) = σ〈P 〉(r1 × r2), S1 ∩ S2 = ∅, P ≡ P 〈S1 ∪ S2〉

Кортежи операндов, попавшие в результат внутреннего соединения, называются соединимыми.Определим операции левого и правого внешних соединений как результат пополнения внутреннего

соединения несоединимыми кортежами левого и правого операндов соответственно. При пополнениинесоединимый кортеж операнда дополняется на схеме другого операнда 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) = {%〈ϕ1〉r1 ×E %〈ϕ2〉r2}[S1 ∪ S2]

Рис. 3.8.: Круги Эйлера

Рис. 3.9.: Пример. Естественное соединение

Рис. 3.10.: Пример. Декартово произведение

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

3.6. Пример построения выражения реляционной алгебры

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

Поставщики (КодПщ, Имя, Город)Детали (КодД, РодД, ...)Поставки (КодПщ, КодД)

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

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

R1 := Поставщики ./ Поставки ./ Детали[КодД, РодД]

Выборка из отношения R1 по условию РодД = ’Болт’ с последующей проекцией на атрибутыотношения Поставщики позволяет получить список всех Поставщиков, поставляющих хотя бы однудеталь с родовым именем ’Болт’:

R2 := (σ〈РодД = ’Болт’〉R1)[КодПщ, Имя, Город]

Разность отношений Поставщики и R2 дает искомый список Поставщиков. Остается спроектиро-вать результат на заданные атрибуты:

R3:= (Поставщики \ R2)[Имя, Город]

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

(Поставщики \ (σ〈РодД = ’Болт’〉(Поставщики ./ Поставки ./ Детали[КодД, РодД]))[КодПщ,Имя, Город])[Имя, Город]

3.7. Понятие базовых и виртуальных отношений

На наиболее абстрактном уровне база данных – это множество отношений D. Замыкая D (обо-значение D+) относительно введенных ранее операций реляционной алгебры, получим множествовсех отношений (включая сами отношения D), которые можно получить из D, применяя введенныеоперации. Тем самым получаем реляционную алгебру над множеством отношений базы данных, тоесть множество (называемое носителем) с набором операций (называемым сигнатурой):

〈D+;σ, π, ρ,∪,∩, \,×, ./〉

Таким образом, исходя из отношений 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. [̂символ-символ], либо [̂символ. . . ] – любой одиночный символ, не содержащийсяв указанном диапазоне или последовательности символов. Например, конструкция like ‘[ ̂ 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 список_имен_атрибутов_отношения_1from имя_отношения_1union [all]select список_имен_атрибутов_отношения_2from имя_отношения_2

Списки имен атрибутов объединяемых отношений должны ссылаться на атрибуты совместимыхтипов и быть перечислены в согласованном порядке. Имена атрибутов в отношениях могут бытьразличными. Результирующему отношению приписываются имена атрибутов, указанные в первомоператоре select. Операция объединения может иметь форму union all с опцией all (все). В этомслучае из результирующего отношения дубликаты кортежей не удаляются (, что является болеепредпочтительным с точки зрения производительности).

Операция пересеченияОперация пересечения проще всего реализуется с использованием ключей отношений:

R1(Ключ, A, B, C), R2(Ключ, A, B, C)

select *from R1where Ключ in (select Ключ from R2)

Здесь R1 и R2 – имена отношений. Оператор select в скобках является так называемым подза-просом. Он возвращает список значений ключа отношения R2. Согласно условию выборки в резуль-тирующее отношение выбираются те кортежи отношения R1, ключ которых содержится в спискеключей отношения R2. Имена ключей отношений могли бы быть и различными. Сами отношения

могли бы иметь различные наборы дополнительных атрибутов.

Операция разностиОперация разности реализуется аналогично операции пересечения с заменой ключевого слова inна not in:

R1(Ключ, A, B, C), R2(Ключ, A, B, C)

select *from R1where Ключ 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, Dfrom 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 БаллSumfrom Сессия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

120

4. Базовые и виртуальные отношения

4.1. Типы данных

Тип данных задает множество значений, объединенных определенной совокупностью допустимыхопераций. От типа данных зависит размер выделяемой для значений памяти.

4.1.1. Базовые типы данных

Базовыми типами данных являются следующие.

1. Числовые

• integer – целый,

• перечислимые типы,

• float(n), real – вещественный,

• decimal(n[, d]) – десятичный с фиксированной точкой,

• money, или currency – денежный.

121

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ВесКг).

Ограничение уровня отношения включает ограничения уникальности значений первичного (primarykey) и кандидатных (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 nullprimary key(КодК)candidate key(ИмяК)

Аналогичные ограничения сформулируем и для отношения Организации:

create table ОрганизацииКодО counter,ИмяО char not nullprimary key(КодО)candidate key(ИмяО)

Так как лектор может не числиться в какой-либо организации, то при создании отношения Лекторыдля внешнего ключа КодО null-значения полагаем допустимыми и для операции удаления сведенийоб организации применяем правило присвоения null-значений (on delete set null):

create table ЛекторыКодЛр counter,Ф char not null, И char not null, О char not null,

КодО integer nullprimary 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 nullcheck(ДатаНач < ДатаКон)primary key(КодЛ, КодК, ДатаНач)foreign key(КодЛр) references Лекторы(КодЛр) on delete cascadeforeign key(КодК) references Курсы(КодК) on delete cascade

4.6.3. Транзакции и блокировки

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

перевести деньги на счет другого клиента банка. В базе данных хранится информация о количестведенег у каждого из клиентов. Нужно сделать два изменения в базе данных – уменьшить суммуденег на счете одного из клиентов и, соответственно, увеличить сумму денег на другом счете.Конечно, реальный перевод денег в банке представляет собой гораздо более сложный процесс,

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

счете первого клиента) произошел сбой. Например, могла прерваться связь клиентского компьюте-ра с базой данных, или на клиентском компьютере мог произойти системный сбой, что привело кперезагрузке операционной системы. Что в этом случай стало с базой данных? Команда на умень-шение денег на счете первого клиента была выполнена, а вторая команда – на увеличение денегна другом счете – нет. Без использования транзакций описанная выше ситуация привела бы кпротиворечивому, неактуальному состоянию базы данных.То свойство, что каждая транзакция начинается при целостном состоянии БД и оставляет это

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

торов изменения базы данных, но эти операторы либо выполняются все, либо не выполняется ниодин.Перед выполнением первого действия выдается команда начала транзакции BEGIN TRANSACTION.

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

давая команду отката транзакции ROLLBACK TRANSACTION в случае возникновения ошибочной

ситуации (на счете не хватает денег, счет для операций заблокирован и т.п.):

BEGIN TRANSACTIONUPDATE счет-1 ...IF возникла ошибка THEN GOTO undoUPDATE счет-2 ...IF возникла ошибка THEN GOTO undoCOMMIT TRANSACTIONRETURNundo: 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

160

5. Нормальные формы

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

5.1. Функциональные зависимости (ФЗ)

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

(семестр и учебный год не указаны):

Сессия(№ ЗК, Ф, И, О, МнемоП, Оценка)

Атрибуты № ЗК (номер зачетной книжки) и МнемоП (мнемоническое обозначение предмета) об-разуют ключ этого отношения (так как в конкретную сессию в одну зачетку по одному предмету

161

Рис. 5.1.: Ненормализованное отношение

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

в базе данных. Термин «зависимость» не означает, что в данном случае по № ЗК (числу) можнобез использования данных, хранимых в отношении, «вычислить» Ф, И, О. Он означает лишь, чтоодному значению № ЗК нельзя в отношении сопоставить два или более значений Ф, И или О.Определение. Пусть X и Y – подсхемы схемы отношения S, определяющие над схемой S схему

функциональной зависимости X → Y (читается «X стрелка Y»). Определим ограничение функци-ональной зависимости inv〈X → Y 〉 как утверждение о том, что в отношении со схемой S любыедва кортежа, совпадающие в проекции на подсхему X, должны совпадать и в проекции на подсхемуY :

inv〈X → Y 〉r(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. inv〈X → X〉r(S)ПВ2. inv〈X → Y 〉r(S)⇒ inv〈X ∪ Z → Y 〉r(S)ПВ3. inv〈X → Y 〉r(S) & inv〈Y ∪W → Z〉r(S)⇒ inv〈X ∪W → Z〉r(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 ПВ12. X ∪ Z → X ПВ2, 1Доказательство правила аддитивности:

1. X → Y посылка 1 ПВА2. X → Z посылка 2 ПВА3. Y ∪ Z → Y ∪ Z ПВ14. X ∪ Z → Y ∪ Z ПВ3, 1, 35. X ∪X → Y ∪ Z ПВ3, 2, 46. X → Y ∪ Z 5Доказательство правила проективности:1. X → Y ∪ Z X → Y ∪ Z посылка ПВП2. Y → Y Z → Z ПВ13. Y ∪ Z → Y Z ∪ Y → Z ПВ2, 24. X → Y X → Z ПВ3◦, 1, 3Конец теоремы.Функциональная зависимость с левой частью, являющейся надмножеством правой части, называ-

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

одинаковыми левыми частями позволяют объединять и расщеплять правые части зависимостей.

5.1.3. Независимость правил Армстронга

Теорема. Правила Армстронга образуют систему независимых правил вывода, то есть ни одноиз правил рефлексивности, пополнения и псевдотранзитивности не является производным от двух

других.Доказательство основано на невозможности построения цепочки вывода, в которой, исходя из

посылок рассматриваемого правила, путем применения других правил выводится его заключение.Случай 1. Для правила рефлексивности цепочка вывода имела бы следующий вид:... ПВ2, ПВ3n. X → X заключение ПВ1Но правила пополнения и псевдотранзитивности требуют посылок. Следовательно, заключение

вывести нельзя.Случай 2. Для правила пополнения цепочка вывода в общем случае имела бы вид:1. X → Y посылка ПВ2... ПВ1, ПВ3n. X ∪ Z → Y заключение ПВ2Для доказательства достаточно рассмотреть частный случай Y = X, поскольку правило рефлек-

сивности все равно породило бы произвольные рефлексивные зависимости:1. X R©X посылка ПВ2 при Y = X... ПВ1, ПВ3n. X ∪ Z → X заключение ПВ2Для применения правила псевдотранзитивности требуется 2 посылки. Поэтому вначале следует

применить один или несколько раз правило рефлексивности. Но применительно к рефлексивным за-висимостям правило псевдотранзитивности также даст рефлексивную зависимость. Таким образом,в цепочке вывода заключению будут предшествовать рефлексивные зависимости. Следовательно,заключение вывести нельзя.Случай 3. Для правила псевдотранзитивности аналогично предыдущему имеем

1. X → Y посылка 1 ПВ32. Y ∪W → Z посылка 2 ПВ3... ПВ1, ПВ2n. X ∪W → Z заключение ПВ3Частный случай выбирается таким образом, чтобы поглотить правило рефлексивности (Z = Y ∪X)

и в противовес правилу пополнения уменьшить левую часть заключения (W = X):1. X → Y посылка 1 ПВ3 при Z = Y ∪X,W = X2. Y ∪X → Y ∪X посылка 2 ПВ3... ПВ1, ПВ2n. X → Y ∪X заключение ПВ3Поэтому в цепочке вывода заключению будут предшествовать тривиальные зависимости и зависи-

мости, полученные пополнением левой части первой посылки. Следовательно, заключение вывестинельзя.Конец теоремы.

5.1.4. Полнота системы правил Армстронга

Пусть F (S) – заданное множество функциональных зависимостей над схемой отношения S. Обо-значим через inv〈F (S)〉 ограничение, накладываемое этим множеством:

inv〈F (S)〉r(S) = ∀X → Y ∈ F (S)[inv〈X → Y 〉r(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){inv〈F (S)〉r(S)⇒ inv〈X ⇒ Y 〉r(S)}

Теорема полноты системы правил вывода Армстронга утверждает, что внешняя импликация заме-няется на эквивалентность (без доказательства).Из теоремы следует практически важные выводы.1. Различные множества функциональных зависимостей будут эквивалентны с точки зрения

накладываемых ограничений тогда и только тогда, когда их замыкания совпадают.2. Достаточно ограничиться рассмотрением полностью нетривиальных зависимостей, в которых

левые и правые части не пересекаются.3. Функциональные зависимости с одинаковыми левыми частями допускают произвольное объ-

единение и разбиение правых частей (согласно правилам аддитивности и проективности).

5.2. Нормальные формы

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

1) декларативно с помощью объявления первичных, кандидатных и внешних ключей,

2) процедурно с помощью написания программного кода триггеров.

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

онной сессии (см. рис. 5.1), и опишем схему базы данных с учетом ограничений функциональныхзависимостей:

Вариант 1 схемы БД

Сессия(№ ЗК, Ф, И, О, МнемоП, Оценка)primary key(№ ЗК, МнемоП){№ ЗК} → {Ф, И, О}

Здесь для поддержания целостности данных, то есть для выполнения ограничения функциональ-ной зависимости {№ ЗК} → {Ф, И, О}, при изменении фамилии необходимо просматривать все

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


Студенты(№ ЗК, Ф, И, О)primary key(№ ЗК)

Сессия(№ ЗК, МнемоП, Оценка)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 Должности(КодД)

Телефоны(№ таб, Телефон)primary key(№ таб, Телефон)foreign key(№ таб) references Сотрудники (№ таб)

Примечание. В отношении Телефоны атрибут № таб является одновременно атрибутом первичного ключаи внешним ключом, ссылающимся на первичный ключ отношения Сотрудники •На отношение, находящееся в первой нормальной форме, в общем случае наложены ограничения

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

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

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

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

ограничения функциональных зависимостей, не навязанные объявлениями ключей:

Отношение1NF(ключевые атрибуты, неключевые атрибуты)primary key(ключ)candidate key(ключ)foreign key(атрибуты) references{не ключ} → {неключевые атрибуты}{не ключ} → {ключевые атрибуты}

5.2.2. Вторая нормальная форма (2NF)

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

{не ключ но подключ} → {неключевые атрибуты}

{не ключ и не подключ} → {неключевые атрибуты}

Цель приведения отношений ко второй нормальной форме – исключить из отношений в пер-вой нормальной форме ограничения функциональных зависимостей вида {не ключ но подключ} →{неключевые атрибуты}.Все атрибуты функционально зависят от (первичного и кандидатных) ключей. Если при этом ат-

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

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

имеет составные ключи •Следующее отношение Аудитории не находится во второй нормальной форме:


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

Аудитории(№ К, № А, ПлощадьКвМ, № таб коменданта)primary key(№ К, № А)foreign key(№ таб коменданта) references Сотрудники(№ таб)

{№ К} → {№ таб коменданта}

Здесь неключевой атрибут № таб коменданта (корпуса) функционально зависит от части ключа.Примечание. Это произошло из-за смешения понятий Корпуса и Аудитории •После приведения ко второй нормальной форме путем декомпозиции отношения Аудитории полу-

чим


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

Корпуса(№ К, № таб коменданта)primary key(№ К)foreign key(№ таб коменданта) references Сотрудники (№ таб)

Аудитории(№ К, № А, ПлощадьКвМ)primary key(№ К, № А)foreign key(№ К) references Корпуса (№ К)

Примечание. Обратим внимание на то, что в отношении Аудитории атрибут первичного ключа № Кявляется одновременно внешним ключом, ссылающимся на первичный ключ отношения Корпуса •В данном примере все требуемые функциональные зависимости навязаны объявлениями первич-

ных и внешних ключей (кандидатных нет). Поэтому дальнейшая нормализация не требуется.

Понятие второй нормальной формы самостоятельного значения не имеет. Оно является ослаблен-ной формой понятия третьей нормальной формы.

5.2.3. Третья нормальная форма (3NF)

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

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

ностью и не зависит ни от чего другого.Конец определения.Следующее отношение Сотрудники не находится в третьей нормальной форме:



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

foreign key(КодД) references Должности(КодД){КодД, Разряд} → {Оклад}

Примечание. Здесь произошло смешение понятий Сотрудники и ДолжностейРазряды •После приведения к третьей нормальной форме путем декомпозиции отношения Сотрудники по-

лучим



ДолжностейРазряды(КодД, Разряд, Оклад)primary key(КодД, Разряд)foreign key(КодД) references Должности(КодД)

Сотрудники(№ таб, Ф, И, О, КодД, Разряд)primary key(№ таб)foreign key(КодД) references Должности(КодД)foreign key(КодД, Разряд) references ДолжностейРазряды(КодД, Разряд)

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

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

Отношение3NF(ключевые атрибуты, неключевые атрибуты)primary key(ключ)candidate key(ключ)foreign key(атрибуты) references{не ключ} → {ключевые атрибуты}

5.2.4. Нормальная форма Бойса-Кодда (Boyce, Codd; NFBC))

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

Примечание. Здесь нет ненавязанных ограничений функциональных зависимостей. Но на отношениемогут быть наложены и другие ограничения, не связанные с понятием функциональных зависимостей •

Всегда ли можно отношение, находящееся в третьей нормальной форме с ненавязанными ограни-чениями {не ключ} → {ключевые атрибуты}, привести к форме Бойса-Кодда?Рассмотрим пример отношения 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.: Диаграмма вложений нормальных форм

primary key(№ таб)foreign key(КодД) references Должности(КодД){КодД, Разряд} → {Оклад}

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

5.2.5. Пример построения нормализованных схем отношений

Практическое задание. Представить в третьей нормальной форме данные об организациях, ихотделах и сотрудниках. Для идентификации организаций используется суррогатный ключ. Отделыуникально нумеруются в пределах организации. Сотрудники идентифицируются табельными номе-

рами, уникальными в пределах организации.

Решение. Заданными являются следующие функциональные зависимости:

• {КодОрг} → данные об организации

• {КодОрг, № отд} → данные об отделе организации

• {КодОрг, № таб} → данные о сотруднике организации

Построение схем начинаем со схем независимых отношений, так что каждое отношение будетссылаться только на предыдущие:

Организации(КодОрг, Наименование)primary key(КодОрг)candidate key(Наименование)

Отделы(КодОрг, № отд, Наименование)primary key(КодОрг, № отд)foreign key(КодОрг) references Организации(КодОрг)

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

Все представленные здесь отношения находятся в третьей нормальной форме, а точнее, в формеБойса-Кодда.Примечание. Часто говорят о третьей нормальной форме даже в случае, когда имеет место форма Бойса-

Кодда. Но если отношение находится в 3NF, но не в NFBC, то это имеет смысл подчеркивать •


Функциональные зависимости

• Понятие нормальных форм относится к OLTP или OLAP-системам?

• Определите понятие ограничения функциональной зависимости.

• К какому уровню относится ограничение функциональной зависимости?

• Приведите пример изображения функциональной зависимости.

• Как понимать фразу «объявления (первичных и кандидатных) ключей навязывают схеме отно-шения соответствующие ограничения функциональных зависимостей»?

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

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

• Сформулируйте правило транзитивности.

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

• Докажите независимость системы правил рефлексивности, пополнения и псевдотранзитивно-сти.

• Сформулируйте понятие полноты системы правил вывода Армстронга.

Нормальные формы

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

• В чем состоит цель нормализации в аспекте функциональных зависимостей?

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

• Сформулируйте понятие отношения, находящегося в 1NF.

• Какими способами отношение может быть приведено к 1NF?

• Какой атрибут называется ключевым?

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

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

• В чем цель приведения отношения к 2NF? Имеет ли 2NF самостоятельное значение?

• Сформулируйте понятие отношения, находящегося в 3NF. Приведите пример.

• Сформулируйте понятие отношения, находящегося в NFBC.

• Всегда ли отношение может быть приведено к 3NF? А к NFBC (если иметь в ввиду декомпо-зицию на независимые отношения)?

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

Часть V.

Модуль 4

190

6. Проектирование схем баз данных

Наиболее распространенным средством абстрактного представления схем баз данных на логическомуровне является модель «сущность-связь» (ER-модель, Entity-Relationship model). Элементами моде-ли являются классы сущностей, их атрибуты и связи.Примечание. Далее диаграммы, составляющие графическую основу модели, изображаются в стиле уни-

фицированного языка моделирования UML •Класс сущностей – это как бы «лишенный методов» класс объектов в смысле объектно-ориентированного

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

ное число связей с другими классами.Связь между двумя классами сущностей может характеризоваться наименованием и кратно-

стью роли класса в связи, а также наименованием связи (безотносительно к роли) Типичнымикратностями являются:

1) 1 – один,

2) 0 . . . 1 – не-более-один,

3) 0 . . .∞ – много («много» допускает и «ничего»),

191

Рис. 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 – атрибут первичного/внешнего ключа.

Примечание. Для маркировки атрибутов первичного/внешнего ключа часто применяют маркер PFK •

Атрибут первичного/внешнего ключа входит в состав (единственного) первичного ключа и одно-временно в состав (некоторого) внешнего ключа.Таким образом, все атрибуты класса сущностей с маркерами 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, КодУ, Атрибуты)primary key(КодУ)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 соответственно.Между подразделением и вышестоящим подразделением может быть установлена лишь необяза-тельная неидентифицирующая связь.


Рис. 6.10.: Ключевая диаграмма

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

create table ПодразделенияМнемоП_Выше nullprimary key(МнемоП)foreign key(МнемоП_Выше) references Подразделения(МнемоП)

on update cascadeon 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.12, 6.13, реализующие сетевую рекурсию в реляционной

модели, и приведем пример в табличной форме (рис. 6.14).Граф, описываемый приведенной схемой, является ориентированным (упоминание об этом для

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

связывающее узлы, ориентации не имеет •

Рис. 6.13.: Ключевая диаграммаПримечание. При изображении родительских и дочерних классов удобно по возможности придерживатьсяследующего правила: изображать родительский класс слева, а дочерний справа, так как родительский класс

не зависит от дочернего, а дочерний зависит от родительского •


Как прийти к подобным построениям? Пусть, как и в случае иерархической рекурсии, есть неко-торое множество узлов, определяемых кодом узла КодУ и некоторыми атрибутами:

Узлы(КодУ, Атрибуты)primary key(КодУ)

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

Дуги(КодУ_Из, КодУ_На)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 cascadeon delete cascade,

foreign key(МнемоД_На) references Документы(МнемоД)on update cascadeon delete restrict

При обновлении мнемокода документа (МнемоД) здесь применяются правила каскадного обновления(on update cascade), так что все ссылки (МнемоД_Из и МнемоД_На) станут ссылаться на это новоезначение мнемокода. В рассматриваемом ниже примере при изменении значения первичного ключа(МнемоД) 4 на 40 значения внешних ключей (МнемоД_Из и МнемоД_На) также изменятся с 4 на40.При удалении документа (МнемоД) применение правила каскадного удаления (on delete cascade)

для документа, из которого производится ссылка (МнемоД_Из), приведет к тому, что все ссылки изэтого документа также удалятся (если это не будет противоречить описываемому ниже правилу ondelete 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). Здесь атрибут Дата-время

включен в первичный ключ. Если этого не сделать, то для каждой пары врач-пациент можно былобы зарегистрировать не более одной встречи.


Рис. 6.23.: Ключевая диаграммаПримечание. Здесь для краткости указан составной атрибут ФИО, что для ключевых диаграмм допустимо

•

В общем случае граф, моделируемый ассоциацией, может иметь произвольное число долей (k-дольный граф или мультиграф, k ≥ 2).

6.6.3. Пример реализации ассоциации

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

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

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


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

Решение. Презентационная и ключевая диаграммы представлены на рис. 6.24, 6.25 соответствен-но.Связи с классами Заказчики и Исполнители являются неполностью идентифицирующими, связь

с классом Консультанты – необязательной неидентифицирующей.Приведем фрагмент оператора создания базового отношения График с определением правил под-

держания ссылочной целостности:


create table ГрафикМнемоК nullprimary key(МнемоЗ, МнемоИ, Дата-время)foreign key(МнемоЗ) references Заказчики(МнемоЗ)

on update cascadeon delete cascade,

foreign key(МнемоИ) references Исполнители(МнемоИ)on update cascadeon 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.28.: Презентационная диаграммаПримечание. Вид при обобщении – это центральное место триады «род – вид – индивид». Стрелки,

идущие от категорий к обобщению, можно и не сливать •

6.29).Полную или неполную иерархию категорий описывает данная схема реализации обобщения?

Неполную, так как это не противоречит кратностям, устанавливаемым на дочерних концах связей.

6.7.2. Пример реализации обобщения

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

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

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

категориальных сущностей •


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



Решение. Презентационная и ключевая диаграммы представлены на рис. 6.30, 6.31 соответствен-но.

Рис. 6.31.: Ключевая диаграммаПримечание. Здесь для краткости указан составной атрибут ФИО, что для ключевых диаграмм допустимо

•

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

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

create table Школьникиprimary key(КодУ)foreign key(КодУ) references Учащиеся(КодУ)

on delete cascade

Определять правило поддержания ссылочной целостности при обновлении родительского ключаКодУ нет необходимости, так как этот ключ – суррогатный и обновлению не подлежит. Вместоправила каскадного удаления могло бы быть сформулировано правило ограничения restrict, но неset null, так КодУ в дочернем отношении является первичным ключом и null-значений не допускает.Пример в табличной форме приведен на рис. 6.32.

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.35.: Презентационная диаграммаПримечание. Например, для дома, как композита, видами компонентов могут быть подъезды, квартиры,

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

Рис. 6.36.: Ключевая диаграммаПримечание. Здесь проиллюстрирована возможность установления трех видов связей

«композит-компонент» •

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

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


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



Решение. Презентационная и ключевая диаграммы представлены на рис. 6.37, 6.38 соответствен-но. Связь с классом Аудитории является неполностью идентифицирующей, а с классом Буфеты –полностью идентифицирующей.Возникает вопрос: поскольку буфетов в корпусе может быть не более одного, то нельзя ли просто

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

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

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

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

(даже если нумерация числовая, а не буквенно-числовая) •

create table Аудиторииprimary key(№ К, № А)foreign key(№ К) references Корпуса(№ К)

on update cascadeon delete cascade

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

Рис. 6.40.: Связь «агрегат-компонент» в нотации UML

6.9. Агрегация


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

неидентифицирующие. Следовательно, компоненты агрегата, ссылающиеся на агрегат посредствомвнешнего ключа, допускающего null-значения, существуют вне агрегата в случае, когда внешнийключ имеет null-значение.На презентационных диаграммах связь «агрегат-компонент» удобно изображать в нотации UML

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

дели.

Рис. 6.41.: Презентационная диаграммаПримечание. Например, для двери, как агрегата, видами компонентов могут быть дверное полотно, ручка,

петли. Стрелки, как и в случаях обобщения и композиции, можно и не сливать •

6.9.2. Пример реализации агрегации

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


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


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

которого указана в секции ограничений.В классе Шасси внешний ключ, ссылающийся на номер автомобиля, объявлен кандидатным клю-

чом. В результате тип устанавливаемой обязательной неидентифицирующей связи изменяется содин-ко-многим (1 : 0 . . .∞) на один-к-не-более-одному (1 : 0 . . . 1). Такой вариант установлениясвязей часто полезен на практике.


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

правил поддержания ссылочной целостности:

create table Двигатели[№ А] nullprimary key(МаркерД)foreign key(№ А) references Автомобили(№ А)

on update cascadeon delete set null

create table Шасси[№ А] not nullprimary key(МаркерШ)candidate key(№ А)foreign key(№ А) references Автомобили(№ А)

on update cascadeon delete cascade

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

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

6.10. Унификация атрибутов

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

отделе, вначале получим ключевую диаграмма до унификации атрибутов (рис. 6.45).В верхней части диаграммы установлена связь один-ко-многим (1 : 0 . . .∞) между Организациями

и их Отделами. Отделы уникально идентифицируются своими кодами в пределах организации.В левой части диаграммы установлена связь один-ко-многим (1 : 0 . . .∞) между Организациями

и их Сотрудниками. Сотрудники уникально идентифицируются своими табельными номерами в

Рис. 6.45.: Ключевая диаграмма до унификации атрибутов

пределах организации.В правой части диаграммы установлена связь не-более-один-ко-многим (0 . . . 1 : 0 . . .∞) между

Отделами и Сотрудниками организации (не все сотрудники организации числятся в отделах).Таким образом, атрибут КодОрг попадает в класс Сотрудники дважды – один раз из класса

Организации с маркером PF, и один раз из класса Отделы с маркером FK. При унификации атрибутКодОрг получает статус атрибута первичного/внешнего ключа PF, поглощающего статус атрибутавнешнего ключа (рис. 6.46).В заключение приведем фрагмент оператора создания базового отношения Сотрудники:

create table СотрудникиКодОтд nullprimary key(КодОрг, № таб)

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

foreign key(КодОрг) references Организации(КодОрг)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.

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

261

7. Технологии баз данных

7.1. Информационные системы

С появлением вычислительной техники сразу образовались два основных направления ее использо-вания:

1) применение для выполнения численных расчетов,

2) применение в информационных системах.

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

ального мира, например, экономики, техники, медицины и т.д. Часть реального мира, отображаемаяв ИС, называется предметной областью.

262

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) и AllFusionProcess 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. Иерархическая модель данных

Наиболее известным и распространенным представителем иерархических СУБД является InformationManagement 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 44 53 5

6=5 44 35 3

Таким образом, в реляционных базах данных (РБД) данные организованы в виде отношенийи представлены в форме таблиц. Однако формы представления или, как еще говорят, изобра-жения, могут быть различными. Так, например, для числа 1 имеем эквивалентные представления1, 0.999 . . . , 0.(9) и т.п.

Применительно к рассматриваемым в примере отношениям эта возможность различного представ-ления проявляется в том, что строки в таблицах переставлять можно, так как отношения – этомножества, а множества не упорядочены. Однако столбцы в таблицах переставлять нельзя, так какэлементы этих множеств являются упорядоченными наборами, в данном случае упорядоченнымипарами. Таким образом, таблицы с произвольным порядком строк, но фиксированным порядкомстолбцов, являются адекватной формой представления отношений в общем математическом смысле.Но с точки зрения информационного содержания рассматриваемые в примере отношения R< и R>

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

Отношение строгого порядка

Оценка Оценкаменьшая бо́льшая

3 44 53 5

=

Оценка Оценкабо́льшая меньшая

5 44 35 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, входящий в комплект поставки MicrosoftSQL 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 DefinitionLanguage) и язык манипулирования данными (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 состоит из аффинныхпреобразований плоскости:{

X ′ = A×X +B × Y + CY ′ = 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.

314

http://olap.ru/

http://www.intuit.ru/

http://www.intuit.ru/

http://www.osp.ru/os/2000/10/062.htm

[9] Нейбург, Э. Дж. Проектирование баз данных с помощью UML / Э. Дж. Нейбург, Р. А. Мак-симчук. Пер. с англ. — М.: Издательский дом “Вильямс”, 2002. — С. 288.

[10] Рамбо, Дж. UML: специальный справочник / Дж. Рамбо, А. Якобсон, Буч Г. Пер. с англ. —СПб.: Питер, 2002. — С. 656.

[11] Шабаршин, А. А. Введение во фракталы. http://members.xoom.com/_XMCM/treestation/fractals.htm.

[12] Швецов, В. И. Базы данных. Учебное пособие / В. И. Швецов, А. Н. Визгунов, И. Б. Мееров. —Нижний Новгород: Изд-во ННГУ, 2004. — С. 217.

http://members.xoom.com/_XMCM/treestation/fractals.htm

http://members.xoom.com/_XMCM/treestation/fractals.htm

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

2.1. Таблица tblОценки . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 202.2. Схема данных . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 232.3. Запрос qryДиаграмма . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272.4. Мастер диаграмм . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 282.5. Запрос qryОтчет . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 292.6. Запрос qryВедомостьСводная . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

3.1. Объединение, пересечение и разность . . . . . . . . . . . . . . . . . . . . . . . . . . . . 873.2. Декартово произведение . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 883.3. Естественное соединение . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 893.4. Свойства бинарных операций . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 903.5. Пример. Операнды соединений . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 933.6. Пример. Внутреннее и левое соединения . . . . . . . . . . . . . . . . . . . . . . . . . . 933.7. Пример. Правое и внешнее соединения . . . . . . . . . . . . . . . . . . . . . . . . . . . 943.8. Круги Эйлера . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 953.9. Пример. Естественное соединение . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 953.10. Пример. Декартово произведение . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96

316

4.1. Модификация таблицы со счетчиком . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1264.2. Индексы . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1314.3. Внешние ключи как механизм ссылок . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1364.4. Декларативная поддержка ссылочной целостности . . . . . . . . . . . . . . . . . . . . 143

5.1. Ненормализованное отношение . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1625.2. Нормализованные отношения . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1735.3. Виды атрибутов . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1735.4. Пример допустимого состояния R . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1835.5. Диаграмма вложений нормальных форм . . . . . . . . . . . . . . . . . . . . . . . . . . . 185

6.1. Диаграмма со связью типа один-ко-многим . . . . . . . . . . . . . . . . . . . . . . . . . 1926.2. Изображение класса сущностей . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1986.3. Типы связей в зависимости от вида связи . . . . . . . . . . . . . . . . . . . . . . . . . . 1996.4. Миграция в PF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2006.5. Миграция в FK . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2016.6. Презентационная диаграмма . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2046.7. Ключевая диаграмма . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2056.8. Пример в табличной форме . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2056.9. Презентационная диаграмма . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2086.10. Ключевая диаграмма . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2086.11. Пример в табличной форме . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2106.12. Презентационная диаграмма . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2116.13. Ключевая диаграмма . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2126.14. Пример в табличной форме . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2126.15. Ключевая диаграмма. Сетевая реализация иерархической рекурсии . . . . . . . . . . . 214

6.16. Презентационная диаграмма . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2176.17. Ключевая диаграмма . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2176.18. Пример в табличной форме . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2196.19. Презентационная диаграмма . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2206.20. Ключевая диаграмма . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2216.21. Пример двудольного графа . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2216.22. Презентационная диаграмма . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2236.23. Ключевая диаграмма . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2236.24. Презентационная диаграмма . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2256.25. Ключевая диаграмма . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2266.26. Пример в табличной форме . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2276.27. Связь «обобщение-категория» в нотации UML . . . . . . . . . . . . . . . . . . . . . . . 2286.28. Презентационная диаграмма . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2296.29. Ключевая диаграмма . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2306.30. Презентационная диаграмма . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2316.31. Ключевая диаграмма . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2326.32. Пример в табличной форме . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2346.33. Cвязь «композит-компонент» в нотации UML . . . . . . . . . . . . . . . . . . . . . . . 2366.34. Cвязь «композит-компонент» в нотации UML с указанием кратности . . . . . . . . . . 2366.35. Презентационная диаграмма . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2376.36. Ключевая диаграмма . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2386.37. Презентационная диаграмма . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2406.38. Ключевая диаграмма . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2406.39. Пример в табличной форме . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2416.40. Связь «агрегат-компонент» в нотации UML . . . . . . . . . . . . . . . . . . . . . . . . 242

6.41. Презентационная диаграмма . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2436.42. Ключевая диаграмма . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2446.43. Презентационная диаграмма . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2466.44. Ключевая диаграмма . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2476.45. Ключевая диаграмма до унификации атрибутов . . . . . . . . . . . . . . . . . . . . . . 2496.46. Ключевая диаграмма после унификации атрибутов . . . . . . . . . . . . . . . . . . . . 250

7.1. Каскадная модель . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2657.2. Итерационная модель . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2667.3. Спиральная модель . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2677.4. Пример одного из деревьев базы медицинских данных . . . . . . . . . . . . . . . . . . 2737.5. Пример структурной диаграммы базы медицинских знаний . . . . . . . . . . . . . . . 2767.6. Логическая схема OLAP-системы . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2857.7. Триадная кривая Кох . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3037.8. «Дракон» Хартера-Хейтуэя . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3047.9. Множество Мандельброта . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3067.10. Участок границы множества Мандельброта, увеличенный в 200 pаз . . . . . . . . . . 307

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

3.1. Интерпретации null-значения . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 693.2. Таблица истинности . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 723.3. Операции с null-значением . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 733.4. Предикат IsNull . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74

320

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

k-дольный граф, 122БД, 12, 76СУБД, 11СУБД с равноправными (однотипными) файла-

ми, 18агрегация, 141агрегация кластеров, 102агрегация общего вида, 102, 144агрегата, 141аппаратный сбой, 31архивная копия, 33ассоциация, 101ассоциативные сущности, 110атрибут, 23, 72аттрактор, 48близнецы, 16декартово произведение, 80

дерево, 16, 105детализация, 29дочерний ключ, 94домен, 24домен атрибута, 71двудольный мультиграф, 121естественное соединение, 80эксплуатация, 7файловый сервер, 39фазовый портрет, 48формы представления, 20фрактал, 45фрактальная геометрия, 45функция переименования, 79генератор, 46глобальные приложения, 42хранилище данных, 26

321

идентифицирующая связь, 95иерархическая БД, 16иерархическая рекурсия, 101иерархическая связь, 102иерархия категорий, 125именующая сущность, 118информационная система, 5итерационная модель, 9измерение, 27изображения, 20каскадная модель, 7категориальная идентифицирующая связь, 95категориальных сущностей, 127класс, 24класс сущностей, 90кластер, 101клиентский компьютер, 39клиентское приложение, 39ключевые диаграммы, 92компилятор языка БД, 37компоненты, 134, 141композиция, 131композиция кластеров, 102композита, 134корень, 16

кортеж, 74лес, 105лист, 16локальные приложения, 42механизм репликации, 38метод фрактального сжатия информации, 51миграция ключей, 94многопользовательский режим, 38множественное наследование, 24множество Мандельброта, 49модель жизненного цикла, 7модернизация, 7мультиграф, 113мягкий сбой, 31надежность хранения, 31наследование, 24настольные СУБД, 39неидентифицирующая связь, 95необязательная неидентифицирующая связь, 95неопределенное значение, 60неполностью идентифицирующая связь, 95нулевое значение, 61объединение, 80объект, 23область притяжения, 48

обобщение, 125обобщение кластеров, 101обобщенные сущности, 127обязательная неидентифицирующая связь, 95однопользовательский режим, 37оператор переименования, 79оператор проекции, 78оператор выборки, 78основная реплика, 38отношение, 75пересечение, 80подкласс, 24подсхема, 78подсистемы поддержки времени выполнения, 37полные атрибутивные диаграммы, 93полностью идентифицирующая связь, 95постреляционная модель, 22потомок, 16поведение объекта, 23предфрактал, 47предок, 16презентационные диаграммы, 92проектируемые связи, 96программный сбой, 31простая сетевая структура, 18

простое наследование, 24пустое значение, 61распределенная БД, 42разность, 80разработка, 6рекурсивная связь, 101, 102реплика, 38репликатор, 43решетка классов, 24родительский ключ, 94сечение, 29секция ограничений, 96сервер приложений, 41сетевая рекурсия, 101схема БД, 76схема миграции, 94схема отношения, 73система управления распределенной БД, 42сложная сетевая структура, 18соединимые кортежи, 81сопровождение, 7состояние объекта, 23спиральная модель, 9спроектированные связи, 96степень отношения, 73

суперкласс, 24свертка, 29связь предок/потомок, 102технология тиражирования данных, 43тип атрибута, 71транзакция, 31три уровня логической модели, 92триадная кривая Кох, 46унификация атрибутов, 147управление буферами оперативной памяти, 30управление данными во внешней памяти, 30управление проектом, 7управление транзакциями, 31условие выборки, 78условная дизъюнкция, 64условная конъюнкция, 64утилиты БД, 37узел, 16верификация, 7вращение, 29взвешенный граф, 113взвешенное деревр, 105ядро СУБД, 36языкы баз данных, 34значение, 27

жесткий сбой, 31жизненный цикл, 6журнал, 32журнализация, 31«дракон» Хартера-Хейтуэя, 47«тонкий клиент», 41

BLOB, 44

n-арной ассоциация, 118null, 60

OLAP, 26OLTP, 26

SQL-сервер, 40

XML-ориентированные БД, 25

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

Documents

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