Text
                    Г"
\
V-
J
^
;
rJ
-J
&
C7
c1-
с
(i


Системы баз данных Полный курс
Database Systems The Complete Book Hector Garcia-Molina Jeffrey D. Ullman Jennifer Widom Department of Computer Science Stanford University Prentice Hall Prentice Hall Upper Saddle River, New Jersey 07458
Системы баз данных Полный курс Гектор Гарсиа-Молина Джеффри. Д. Ульман Дженнифер Уидом Отделение компьютерных наук Станфордского университета Москва • Санкт-Петербург • Киев 2003
ББК 32.973.26-018.2.75 Г21 УДК 681.3.07 Издательский дом "Вильяме" Зав. редакцией А. В. Слепцов Перевод с английского и редакция канд.техн.наук А. С. Варакина По общим вопросам обращайтесь в Издательский дом "Вильяме" по адресу: info@williamspublishlng.com, http://www.williamspublishing.com Гарсиа-Молина, Гектор, Ульман, Джеффри, Д., Уидом, Дженнифер Г21 Системы баз данных. Полный курс. : Пер. с англ. — М. : Издательский дом "Вильяме", 2003. — 1088 с. : ил. — Парал. тит. англ. ISBN 5-8459-0384-Х (рус.) Книга известного специалиста в области компьютерных наук Дж. Ульмана и его именитых коллег по Станфордскому университету является уникальным учебным и справочным пособием, которое отличается беспрецедентными широтой и глубиной охвата предмета и представляет несомненный интерес для всех, кто по роду своей профессиональной деятельности сталкивается с проблемами проектирования и использования современных систем баз данных. ББК 32.973.26-018.2.75 Все названия программных продуктов являются зарегистрированными торговыми марками соответствующих фирм. Никакая часть настоящего издания ни в каких целях не может быть воспроизведена в какой бы то ни было форме и какими бы то ни было средствами, будь то электронные или механические, включая фотокопирование и запись на магнитный носитель, если на это нет письменного разрешения издательства Prentice Hall, Inc. Authorized translation from the English language edition published by Prentice-Hall, Inc., Copyright © 2002 All rights reserved. No part of this book may be reproduced or transmitted in any form or by any means, electronic or mechanical, including photocopying, recording or by any information storage retrieval system, without permission from the Publisher. Russian language edition published by Williams Publishing House according to the Agreement with R&I Enterprises International, Copyright © 2002 ISBN 5-8459-0384-Х (рус.) © Издательский дом "Вильяме", 2002 ISBN 0-1303-1995-3 (англ.) © Prentice Hall, Inc., 2002
Оглавление Глава 1. Мир баз данных 31 Глава 2. Модель данных "сущность-связь" 51 Глава 3. Реляционная модель 87 Глава 4. Другие модели данных 149 Глава 5. Реляционная алгебра 203 Глава 6. Язык SQL 249 Глава 7. Ограничения и триггеры 317 Глава 8. Системные аспекты SQL 349 Глава 9. Объектная ориентация и языки запросов 419 Глава 10. Логические языки запросов 453 Глава 11. Принципы хранения информации 489 Глава 12. Представление элементов данных 549 Глава 13. Структуры индексов 583 Глава 14. Многомерные и точечные индексы 637 Глава 15. Выполнение запросов 683 Глава 16. Компиляция и оптимизация запросов 753 Глава 17. Профилактика системных отказов и устранение их последствий 837 Глава 18. Управление параллельными заданиями 879 Глава 19. Дополнительные аспекты управления транзакциями 949 Глава 20. Интеграция информации 1003 Послесловие редактора перевода 1049 Именной указатель 1051 Предметный указатель 1055
Содержание Об авторах 27 Предисловие 28 Как работать с книгой 28 Предварительные условия 28 Упражнения 29 Ресурсы в World Wide Web 29 Благодарности 29 Глава 1. Мир баз данных 31 1.1. Эволюция систем баз данных 32 1.1.1. Первые СУБД 32 1.1.2. Системы реляционных баз данных 34 1.1.3. Уменьшение и удешевление систем 35 1.1.4. Тенденции роста систем 36 1.1.5. Системы "клиент/сервер" и многоуровневые архитектуры 37 1.1.6. Данные мультимедиа 38 1.1.7. Интеграция информации 38 1.2. Обзор структуры СУБД 39 1.2.1. Команды языка определения данных 40 1.2.2. Обработка запросов 40 1.2.3. Менеджеры буферов и хранения данных 41 1.2.4. Обработка транзакций 42 1.2.5. Процессор запросов 43 1.3. Обзор технологий СУБД 45 1.3.1. Проектирование баз данных 45 1.3.2. Программирование приложений баз данных 45 1.3.3. Реализация систем баз данных 47 1.3.4. Интеграция информации 48 1.4. Резюме 49 1.5. Литература 50 Глава 2. Модель данных "сущность-связь" 51 2.1. Элементы ER-модели 52 2.1.1. Множества сущностей 52 2.1.2. Атрибуты 53 2.1.3. Связи 53 2.1.4. Диаграммы сущностей и связей 53 2.1.5. Экземпляры ER-диаграммы 54 2.1.6. Множественность бинарных связей 55
2.1.7. Многосторонние связи 56 2.1.8. Связи и роли 57 2.1.9. Связи и атрибуты 59 2.1.10. Преобразование многосторонних связей в бинарные 60 2.1.11. Подклассы в ER-модели 61 2.1.12. Упражнения к разделу 2.1 63 2.2. Принципы проектирования 66 2.2.1. Достоверность 66 2.2.2. Отсутствие избыточности 67 2.2.3. Простота 67 2.2.4. Выбор подходящих связей 67 2.2.5. Использование элементов адекватных типов 69 2.2.6. Упражнения к разделу 2.2 71 2.3. Моделирование ограничений 74 2.3.1. Классификация ограничений 74 2.3.2. Ключи и ER-моделирование 75 2.3.3. Представление ключей в ER-модели 77 2.3.4. Ограничения уникальности 77 2.3.5. Ограничения ссылочной целостности 78 2.3.6. Ссылочная целостность и ER-диаграммы 79 2.3.7. Ограничения других видов 79 2.3.8. Упражнения к разделу 2.3 80 2.4. Слабые множества сущностей 81 2.4.1. Примеры использования слабых множеств сущностей 81 2.4.2. Требования к слабым множествам сущностей 82 2.4.3. Система обозначений слабых множеств сущностей 84 2.4.4. Упражнения к разделу 2.4 85 2.5. Резюме 85 2.6. Литература 86 Глава 3. Реляционная модель 87 3.1. Основы реляционной модели 87 3.1.1. Атрибуты 88 3.1.2. Схемы 88 3.1.3. Кортежи 88 3.1.4. Домены 89 3.1.5. Формы представления отношений 89 3.1.6. Экземпляры отношения 89 3.1.7. Упражнения к разделу 3.1 90 3.2. От ER-диаграмм к реляционным схемам 91 3.2.1. От множеств сущностей к отношениям 91 3.2.2. От ER-связей к отношениям 93 3.2.3. Объединение отношений 95 3.2.4. Преобразование слабых множеств сущностей 96 3.2.5. Упражнения к разделу 3.2 99 3.3. Преобразование структур подклассов в отношения 100 3.3.1. Преобразование в стиле "сущность—связь" 101 3.3.2. Объектно-ориентированный подход 102 3.3.3. Значения "null" и объединение отношений 103 8 СОДЕРЖАНИЕ
3.3.4. Сравнение стратегий 103 3.3.5. Упражнения к разделу 3.3 104 3.4. Функциональные зависимости 106 3.4.1. Определение функциональной зависимости 106 3.4.2. Ключи отношений 108 3.4.3. Суперключи 109 3.4.4. Выбор ключей для отношения 109 3.4.5. Упражнения к разделу 3.4 111 3.5. Правила использования функциональных зависимостей 112 3.5.1. Правила разделения/объединения 113 3.5.2. Тривиальные функциональные зависимости 114 3.5.3. Замыкание множества атрибутов 115 3.5.4. Обоснование алгоритма вычисления замыкания 116 3.5.5. Правило транзитивности 118 3.5.6. Замкнутые множества функциональных зависимостей 119 3.5.7. Проецирование функциональных зависимостей 120 3.5.8. Упражнения к разделу 3.5 121 3.6. Проектирование реляционных схем 123 3.6.1. Аномалии 123 3.6.2. Декомпозиция отношений 124 3.6.3. Нормальная форма Бойса—Кодда 126 3.6.4. Декомпозиция в BCNF 128 3.6.5. Реконструкция данных из отношений декомпозиции 132 3.6.6. Третья нормальная форма 134 3.6.7. Упражнения к разделу 3.6 136 3.7. Многозначные зависимости 137 3.7.1. Независимость атрибутов как причина избыточности 137 3.7.2. Определение многозначной зависимости 138 3.7.3. Правила использования многозначных зависимостей 139 3.7.4. Четвертая нормальная форма 141 3.7.5. Декомпозиция в 4NF 141 3.7.6. Взаимоотношения нормальных форм 143 3.7.7. Упражнения к разделу 3.7 143 3.8. Резюме 145 3.9. Литература 146 Глава 4. Другие модели данных 149 4.1. Обзор понятий объектно-ориентированного проектирования 150 4.1.1. Система поддержки типов 150 4.1.2. Классы и объекты 151 4.1.3. Идентификационный номер объекта 151 4.1.4. Методы 151 4.1.5. Иерархии классов 152 4.2. Введение в язык ODL 152 4.2.1. Объектно-ориентированное проектирование 153 4.2.2. Объявление класса 154 4.2.3. Атрибуты 154 4.2.4. Связи 155 СОДЕРЖАНИЕ 9
4.2.5. Обратные связи 156 4.2.6. Множественность связей 158 4.2.7. Методы 159 4.2.8. Типы в ODL 161 4.2.9. Упражнения к разделу 4.2 163 4.3. Другие понятия ODL 164 4.3.1. Многосторонние связи 164 4.3.2. Подклассы 165 4.3.3. Множественное наследование 166 4.3.4. Экземпляры 167 4.3.5. Ключи 168 4.3.6. Упражнения к разделу 4.3 170 4.4. От ODL-проектов к реляционным схемам 171 4.4.1. От ODL-атрибутов к атрибутам отношений 172 4.4.2. Неатомарные атрибуты классов 172 4.4.3. Представление атрибутов типа множеств 173 4.4.4. Представление атрибутов других составных типов 175 4.4.5. Представление связей 177 4.4.6. А если ключей просто нет? 178 4.4.7. Упражнения к разделу 4.4 179 4.5. Объектно-реляционная модель 180 4.5.1. От отношений к объектам-отношениям 181 4.5.2. Вложенные отношения 182 4.5.3. Ссылки 183 4.5.4. Объектно-ориентированный и объектно-реляционный подходы: за и против 184 4.5.5. От ODL-проектов к объектно-реляционным решениям 185 4.5.6. Упражнения к разделу 4.5 186 4.6. Полуструктурированные данные 187 4.6.1. Обоснование модели полуструктурированных данных 187 4.6.2. Представление полуструктурированных данных 188 4.6.3. Интеграция информации с помощью модели полу структурированных данных 189 4.6.4. Упражнения к разделу 4.6 191 4.7. Язык и модель данных XML 192 4.7.1. Семантические тэги 192 4.7.2. Правильные XML-документы 193 4.7.3. Определения типа документа 194 4.7.4. Использование DTD 195 4.7.5. Списки атрибутов 196 4.7.6. Упражнения к разделу 4.7 199 4.8. Резюме 199 4.9. Литература 200 Глава 5. Реляционная алгебра 203 5.1. Пример схемы базы данных 204 5.2. Алгебра реляционных операций 205 5.2.1. Основы реляционной алгебры 206 5.2.2. Теоретико-множественные операции над отношениями 207 10 СОДЕРЖАНИЕ
5.2.3. Проекция 208 5.2.4. Выбор 209 5.2.5. Декартово произведение 210 5.2.6. Естественное соединение 211 5.2.7. Тета-соединение 212 5.2.8. Наборы операций и формирование запросов 214 5.2.9. Переименование атрибутов 215 5.2.10. Зависимые и независимые операции 216 5.2.11. Алгебраические выражения в линейном представлении 217 5.2.12. Упражнения к разделу 5.2 218 5.3. Реляционные операции над мультимножествами 225 5.3.1. Зачем нужны мультимножества 226 5.3.2. Объединение, пересечение и разность мультимножеств 227 5.3.3. Проекция мультимножеств 228 5.3.4. Выбор из мультимножеств 229 5.3.5. Декартово произведение мультимножеств 230 5.3.6. Операции соединения мультимножеств 230 5.3.7. Упражнения к разделу 5.3 231 5.4. Дополнительные операторы реляционной алгебры 232 5.4.1. Удаление дубликатов 233 5.4.2. Операторы агрегирования 234 5.4.3. Группирование 234 5.4.4. Оператор группирования 235 5.4.5. Оператор расширенной проекции 236 5.4.6. Оператор сортировки 238 5.4.7. Внешние соединения 238 5.4.8. Упражнения к разделу 5.4 241 5.5. Отношения и ограничения 241 5.5.1. Реляционная алгебра как язык описания ограничений 242 5.5.2. Ограничения ссылочной целостности 242 5.5.3. Другие ограничения 243 5.5.4. Упражнения к разделу 5.5 245 5.6. Резюме 246 5.7. Литература 247 Глава 6. Язык SQL 249 6.1. Простые запросы на языке SQL 250 6.1.1. Проекция в SQL 251 6.1.2. Выбор в SQL 253 6.1.3. Сравнение строк 254 6.1.4. Значения даты и времени в SQL 256 6.1.5. Значение null и операции сравнения с null 258 6.1.6. Значение unknown 259 6.1.7. Упорядочение результатов 260 6.1.8. Упражнения к разделу 6.1 261 6.2. Запросы к нескольким отношениям 263 6.2.1. Декартово произведение и соединение в SQL 263 6.2.2. Как различать одноименные атрибуты нескольких отношений 264 6.2.3. Переменные кортежей и псевдонимы отношений 265 6.2.4. Интерпретация запросов к нескольким отношениям 266 СОДЕРЖАНИЕ 77
6.2.5. Объединение, пересечение и разность запросов 6.2.6. Упражнения к разделу 6.2 270 6.3. Подзапросы 271 6.3.1. Подзапросы для вычисления скалярных значений 272 6.3.2. Условия уровня отношения 273 6.3.3. Условия уровня кортежа 273 6.3.4. Коррелированные подзапросы 275 6.3.5. Подзапросы в предложениях FROM 276 6.3.6. Выражения соединения в SQL 277 6.3.7. Естественное соединение 278 6.3.8. Внешние соединения 279 6.3.9. Упражнения к разделу 6.3 280 6.4. Операции над отношениями 283 6.4.1. Удаление кортежей-дубликатов 283 6.4.2. Дубликаты в объединениях, пересечениях и разностях отношений 284 6.4.3. Группирование и агрегирование в SQL 285 6.4.4. Операторы агрегирования 285 6.4.5. Группирование 286 6.4.6. Предложения having 287 6.4.7. Упражнения к разделу 6.4 289 6.5. Модификация базы данных 291 6.5.1. Вставка кортежей 291 6.5.2. Удаление кортежей 293 6.5.3. Обновление данных 294 6.5.4. Упражнения к разделу 6.5 295 6.6. Определение схем отношений в SQL 296 6.6.1. Типы данных 296 6.6.2. Простые объявления схем отношений 297 6.6.3. Модификация реляционных схем 298 6.6.4. Значения по умолчанию 299 6.6.5. Индексы 299 6.6.6. Знакомство с технологиями выбора индексов 301 6.6.7. Упражнения к разделу 6.6 304 6.7. Виртуальные таблицы 305 6.7.1. Объявление виртуальной таблицы 305 6.7.2. Запросы к виртуальным таблицам 306 6.7.3. Переименование атрибутов 307 6.7.4. Модификация виртуальных таблиц 308 6.7.5. Интерпретация запросов к виртуальным таблицам 310 6.7.6. Упражнения к разделу 6.7 312 6.8. Резюме 314 6.9. Литература 315 Глава 7. Ограничения и триггеры 317 7.1. Ключи отношений 318 7.1.1. Объявление первичного ключа 318 7.1.2. Объявление ключа unique 319 7.1.3. Соблюдение ограничений ключей 320 12 СОДЕРЖАНИЕ
7.1.4. Объявление внешнего ключа 7.1.5. Обеспечение ссылочной целостности 7.1.6. Отложенная проверка ограничений 7.1.7. Упражнения к разделу 7.1 7.2. Ограничения уровня атрибутов и кортежей 7.2.1. Ограничения not null 7.2.2. Ограничения check уровня атрибута 7.2.3. Ограничения check уровня кортежа 7.2.4. Упражнения к разделу 7.2 7.3. Модификация ограничений 7.3.1. Именование ограничений 7.3.2. Модификация ограничений и команда alter table 7.3.3. Упражнения к разделу 7.3 7.4. Ограничения уровня схемы и триггеры 7.4.1. Ограничения "общего вида" 7.4.2. Правила "событие—условие—действие" 7.4.3. Триггеры в SQL 7.4.4. Триггеры instead of 7.4.5. Упражнения к разделу 7.4 7.5. Резюме 7.6. Литература Глава 8. Системные аспекты SQL 8.1. SQL в среде программирования 8.1.1. Проблема согласования моделей данных 8.1.2. Интерфейс взаимодействия SQL и базового языка 8.1.3. Секция объявления 8.1.4. Использование общих переменных 8.1.5. Команды выбора единственного кортежа 8.1.6. Курсоры 8.1.7. Модификация данных посредством курсоров 8.1.8. Защита данных курсора от внешних воздействий 8.1.9. Изменение порядка просмотра содержимого курсора 8.1.10. Динамический SQL 8.1.11. Упражнения к разделу 8.1 8.2. Хранимые процедуры и функции 8.2.1. Создание хранимых процедур и функций 8.2.2. Простые формы выражений 8.2.3. Ветвления 8.2.4. Запросы 8.2.5. Циклы LOOP 8.2.6. Циклы for 8.2.7. Исключения 8.2.8. Использование хранимых процедур и функций 8.2.9. Упражнения к разделу 8.2 8.3. Среда SQL 8.3.1. Среды 8.3.2. Схемы 322 324 327 328 328 329 330 332 334 334 334 335 336 336 339 339 343 344 347 348 349 350 350 352 352 353 354 355 358 359 360 361 362 364 364 366 367 368 369 370 372 374 374 376 377 378 СОДЕРЖАНИЕ
8.3.3. Каталоги 8.3.4. Клиенты и серверы в среде SQL 380 8.3.5. Соединения 380 8.3.6. Сеансы 381 8.3.7. Модули 381 8.4. Интерфейс уровня вызовов 382 8.4.1. Введение в SQL/CLI 383 8.4.2. Обработка команд 385 8.4.3. Извлечение данных 386 8.4.4. Передача аргументов в SQL-команды 388 8.4.5. Упражнения к разделу 8.4 389 8.5. Java Database Connectivity 390 8.5.1. Введение в JDBC 390 8.5.2. Создание объектов SQL-команд 390 8.5.3. Операции с курсорами 392 8.5.4. Передача аргументов в SQL-команды 393 8.5.5. Упражнения к разделу 8.5 393 8.6. Транзакции и SQL 393 8.6.1. Последовательное выполнение операций 394 8.6.2. Атомарность 396 8.6.3. Транзакции 398 8.6.4. Транзакции "только для чтения" 399 8.6.5. "Чтение мусора" 400 8.6.6. Другие уровни изоляции 403 8.6.7. Упражнения к разделу 8.6 404 8.7. Безопасность и авторизация пользователей в SQL 405 8.7.1. Привилегии доступа 406 8.7.2. Создание привилегий 407 8.7.3. Контроль привилегий 408 8.7.4. Назначение привилегий 409 8.7.5. Диаграммы назначения привилегий 411 8.7.6. Аннулирование привилегий 411 8.7.7. Упражнения к разделу 8.7 415 8.8. Резюме 416 8.9. Литература 418 Глава 9. Объектная ориентация и языки запросов 419 9.1. Введение в язык OQL 419 9.1.1. Пример объектно-ориентированной базы данных 420 9.1.2. Описание зависимости между объектами и их членами 420 9.1.3. Выражения "select—from—where" 421 9.1.4. Изменение типа результата запроса 423 9.1.5. Сложные типы выходных данных 424 9.1.6. Подзапросы 424 9.1.7. Упражнения к разделу 9.1 425 9.2. Дополнительные формы выражений OQL 429 9.2.1. Логические множественные условия 429 9.2.2. Выражения с операторами агрегирования 430 14 СОДЕРЖАНИЕ
9.2.3. Выражения с оператором группирования 430 9.2.4. Предложения having 432 9.2.5. Операторы объединения, пересечения и разности 433 9.2.6. Упражнения к разделу 9.2 434 9.3. Создание и присваивание объектов в OQL 435 9.3.1. Присваивание значений переменным базового кода 435 9.3.2. Извлечение элементов единичных коллекций 435 9.3.3. Получение элементов произвольных коллекций 436 9.3.4. Константы в OQL 437 9.3.5. Создание объектов 438 9.3.6. Упражнения к разделу 9.3 439 9.4. Типы данных SQL, определяемые пользователем 440 9.4.1. Определение типов в SQL 440 9.4.2. Методы в пользовательских типах 441 9.4.3. Объявление схем отношений с помощью пользовательских типов 442 9.4.4. Ссылочные типы 442 9.4.5. Упражнения к разделу 9.4 444 9.5. Операции над объектно-реляционными данными 445 9.5.1. Обращение по ссылке 445 9.5.2. Доступ к компонентам пользовательских типов 446 9.5.3. Генерирование объектов и модификация компонентов 446 9.5.4. Сопоставление объектов пользовательских типов 448 9.5.5. Упражнения к разделу 9.5 449 9.6. Резюме 451 9.7. Литература 452 Глава 10. Логические языки запросов 453 10.1. Логика отношений 453 10.1.1. Предикаты и атомы 453 10.1.2. Арифметические атомы 454 10.1.3. Правила и запросы Datalog 454 10.1.4. Интерпретация правил Datalog 455 10.1.5. Экстенсиональные и интенсиональные предикаты 458 10.1.6. Правила Datalog для мультимножеств 459 10.1.7. Упражнения к разделу 10.1 460 10.2. От реляционной алгебры к языку Datalog 460 10.2.1. Пересечение 460 10.2.2. Объединение 461 10.2.3. Разность 461 10.2.4. Проекция 462 10.2.5. Выбор 462 10.2.6. Декартово произведение 464 10.2.7. Соединения 464 10.2.8. Представление наборов операций средствами Datalog 466 10.2.9. Упражнения к разделу 10.2 467 10.3. Рекурсивное программирование на языке Datalog 468 10.3.1. Рекурсивные правила Datalog 469 СОДЕРЖАНИЕ 15
10.3.2. Вычисление рекурсивных правил Datalog 469 10.3.3. Отрицание в рекурсивных правилах 474 10.3.4. Упражнения к разделу 10.3 477 10.4. Рекурсия в SQL 478 10.4.1. Определение интенсиональных отношений в SQL 479 10.4.2. Изолированная рекурсия в SQL 480 10.4.3. Проблемы реализации рекурсии в SQL 482 10.4.4. Упражнения к разделу 10.4 485 10.5. Резюме 486 10.6. Литература 487 Глава 11. Принципы хранения информации 489 11.1. Пример системы баз данных 490 11.1.1. Особенности реализации 490 11.1.2. Как СУБД выполняет запросы 491 11.1.3. Что плохого в нашей системе? 492 11.2. Иерархия устройств памяти 492 11.2.1. Кэш-память 493 11.2.2. Оперативная память 494 11.2.3. Виртуальная память 494 11.2.4. Вторичные устройства хранения 495 11.2.5. Третичные устройства хранения 497 11.2.6. Энергозависимые и энергонезависимые устройства памяти 499 11.2.7. Упражнения к разделу 11.2 500 11.3. Диски 500 11.3.1. Внутренние механизмы дисковых накопителей 500 11.3.2. Контроллер дисков 502 11.3.3. Общие параметры дисков 503 11.3.4. Параметры доступа 504 11.3.5. Запись блоков 508 11.3.6. Модификация содержимого блоков 508 11.3.7. Упражнения к разделу 11.3 509 11.4. Использование вторичных устройств хранения 510 11.4.1. Модель вычислений с функциями ввода-вывода 510 11.4.2. Сортировка данных во вторичных хранилищах 511 11.4.3. Сортировка слиянием 512 11.4.4. Сортировка двухфазным многокомпонентным слиянием 513 11.4.5. Многокомпонентное слияние и сверхбольшие отношения 516 11.4.6. Упражнения к разделу 11.4 517 11.5. Повышение эффективности дисковых операций 518 11.5.1. Группирование данных по цилиндрам диска 519 11.5.2. Использование нескольких дисковых устройств 521 11.5.3. Создание зеркальных копий дисков 522 11.5.4. Упорядочение дисковых операций и "алгоритм лифта" 523 11.5.5. Предварительное считывание и крупномасштабная буферизация данных 526 11.5.6. Приемы оптимизации дисковых операций: за и против 527 11.5.7. Упражнения к разделу 11.5 529 16 СОДЕРЖАНИЕ
11.6. Отказы дисковых устройств 530 11.6.1. Перемежающиеся отказы 531 11.6.2. Контрольные суммы 531 11.6.3. "Устойчивые хранилища" 532 11.6.4. Устранение последствий ошибок 533 11.6.5. Упражнения к разделу 11.6 534 11.7. Восстановление данных при полном отказе диска 534 11.7.1. Модель отказов дисковых устройств 534 11.7.2. Зеркальные диски как средство резервирования 535 11.7.3. Блоки четности 536 11.7.4. Массивы RAID уровня 5 539 11.7.5. Восстановление данных после отказа нескольких дисков 540 11.7.6. Упражнения к разделу 11.7 543 11.8. Резюме 546 11.9. Литература 548 Глава 12. Представление элементов данных 549 12.1. Элементы данных и поля 549 12.1.1. Представление элементов реляционных баз данных 550 12.1.2. Представление объектов 550 12.1.3. Представление элементов данных 551 12.2. Записи 554 12.2.1. Конструирование записей постоянной длины 554 12.2.2. Заголовки записей 556 12.2.3. Группирование записей постоянной длины в блоках 557 12.2.4. Упражнения к разделу 12.2 558 12.3. Представление адресов записей и блоков 558 12.3.1. Системы "клиент/сервер" 559 12.3.2. Логические и структурированные адреса 560 12.3.3. "Подмена" указателей 561 12.3.4. Сохранение блоков на диске 565 12.3.5. "Закрепленные" записи и блоки 566 12.3.6. Упражнения к разделу 12.3 567 12.4. Элементы данных и записи переменной длины 569 12.4.1. Записи с полями переменной длины 569 12.4.2. Записи с повторяющимися полями 570 12.4.3. Записи переменного формата 571 12.4.4. Записи крупного объема 573 12.4.5. Объекты BLOB 574 12.4.6. Упражнения к разделу 12.4 575 12.5. Модификация записей 576 12.5.1. Вставка 576 12.5.2. Удаление 577 12.5.3. Обновление 579 12.5.4. Упражнения к разделу 12.5 579 12.6. Резюме 580 12.7. Литература 582 17
Глава 13. Структуры индексов 583 13.1. Индексы для последовательных файлов 584 13.1.1. Последовательные файлы 584 13.1.2. Плотные индексы 585 13.1.3. Разреженные индексы 586 13.1.4. Многоуровневые индексы 588 13.1.5. Дубликаты ключевых значений 589 13.1.6. Управление индексами при модификации данных 592 13.1.7. Упражнения к разделу 13.1 598 13.2. Вторичные индексы 599 13.2.1. Проектирование вторичных индексов 599 13.2.2. Применение вторичных индексов 600 13.2.3. Дополнительные уровни во вторичных индексах 601 13.2.4. Поиск документов и обращенные индексы 603 13.2.5. Упражнения к разделу 13.2 607 13.3. В-деревья 609 13.3.1. Структура В-дерева 609 13.3.2. Применение В-деревьев 612 13.3.3. Поиск в В-деревьях 613 13.3.4. Запросы в диапазонах значений 614 13.3.5. Вставка элементов в В-дерево 615 13.3.6. Удаление элементов из В-дерева 617 13.3.7. Оценки эффективности В-древовидных индексов 620 13.3.8. Упражнения к разделу 13.3 621 13.4. Хеш-таблицы 624 13.4.1. Хеш-таблицы для данных во вторичных хранилищах 624 13.4.2. Вставка записей в хеш-таблицу 625 13.4.3. Удаление записей из хеш-таблицы 626 13.4.4. Оценки эффективности хешированных индексов 626 13.4.5. Расширяемые хеш-таблицы 627 13.4.6. Вставка записей в расширяемую хеш-таблицу 627 13.4.7. Линейные хеш-таблицы 629 13.4.8. Вставка записей в линейную хеш-таблицу 631 13.4.9. Упражнения к разделу 13.4 633 13.5. Резюме 634 13.6. Литература 635 Глава 14. Многомерные и точечные индексы 637 14.1. Приложения модели многомерных данных 638 14.1.1. Географические информационные системы 638 14.1.2. Кубы данных 639 14.1.3. SQL-запросы к многомерным данным 640 14.1.4. Запросы в диапазонах значений с использованием традиционных индексов 641 14.1.5. Поиск ближайших соседних объектов с использованием традиционных индексов 643 14.1.6. Другие офаничения традиционных структур индексов 644 14.1.7. Обзор структур индексов для многомерных данных 645 14.1.8. Упражнения к разделу 14.1 645 18 СОДЕРЖАНИЕ
14.2. Хеш-подобные структуры для многомерных данных 646 14.2.1. Сеточные файлы 647 14.2.2. Поиск записей в сеточном файле 647 14.2.3. Вставка записей в сеточный файл 648 14.2.4. Оценки эффективности структур сеточных файлов 650 14.2.5. Раздельные хеш-функции 652 14.2.6. Сравнение структур сеточных файлов и раздельных хеш-таблиц 654 14.2.7. Упражнения к разделу 14.2 654 14.3. Древовидные структуры для многомерных данных 657 14.3.1. Индексы с несколькими ключами 657 14.3.2. Оценки эффективности структур индексов с несколькими ключами 659 14.3.3. kd-деревья 659 14.3.4. Операции с kd-деревьями 660 14.3.5. kd-деревья и данные во вторичных хранилищах 663 14.3.6. Деревья квадрантов 664 14.3.7. R-деревья 666 14.3.8. Операции с R-деревьями 667 14.3.9. Упражнения к разделу 14.3 669 14.4. Точечные индексы 671 14.4.1. Зачем нужны точечные индексы 672 14.4.2. Сжатые точечные индексы 673 14.4.3. Операции со сжатыми битовыми векторами 675 14.4.4. Управление точечными индексами 676 14.4.5. Упражнения к разделу 14.4 678 14.5. Резюме 679 14.6. Литература 680 Глава 15. Выполнение запросов 683 15.1. Знакомство с операторами физического плана запроса 684 15.1.1. Сканирование таблиц 685 15.1.2. Сортировка в процессе сканирования таблиц 686 15.1.3. Модель вычислений операторов физического плана 686 15.1.4. Критерии эффективности физических операторов 687 15.1.5. Оценки затрат на ввод-вывод для операторов сканирования 688 15.1.6. Реализация физических операторов с помощью итераторов 689 15.2. Однопроходные алгоритмы обработки данных 692 15.2.1. Однопроходные алгоритмы для унарных операций над отдельными кортежами 693 15.2.2. Однопроходные алгоритмы для унарных операций над полными отношениями 694 15.2.3. Однопроходные алгоритмы для бинарных операций над полными отношениями 697 15.2.4. Упражнения к разделу 15.2 700 15.3. Реализация соединений посредством вложенных циклов 702 15.3.1. Соединение посредством вложенных циклов с загрузкой отдельных кортежей 702 15.3.2. Итератор для соединения посредством вложенных циклов с загрузкой отдельных кортежей 702 19
15.3.3. Соединение посредством вложенных циклов с загрузкой блоков данных 702 15.3.4. Анализ алгоритмов соединения посредством вложенных циклов 704 15.3.5. Сводка характеристик однопроходных и циклических алгоритмов 705 15.3.6. Упражнения к разделу 15.3 705 15.4. Двухпроходные алгоритмы, основанные на сортировке 706 15.4.1. Алгоритм удаления кортежей-дубликатов 706 15.4.2. Алгоритм группирования и агрегирования 709 15.4.3. Алгоритм объединения 709 15.4.4. Алгоритмы пересечения и разности 710 15.4.5. Простой алгоритм соединения 712 15.4.6. Анализ простого алгоритма соединения 713 15.4.7. Более эффективный алгоритм соединения 714 15.4.8. Сводка характеристик алгоритмов, основанных на сортировке 715 15.4.9. Упражнения к разделу 15.4 716 15.5. Двухпроходные алгоритмы, основанные на хешировании 717 15.5.1. Распределение содержимого отношений по сегментам хеш- таблицы 718 15.5.2. Алгоритм удаления кортежей-дубликатов 718 15.5.3. Алгоритмы группирования и агрегирования 719 15.5.4. Алгоритмы объединения, пересечения и разности 719 15.5.5. Алгоритм соединения 720 15.5.6. Сокращение затрат на дисковый ввод-вывод 721 15.5.7. Сводка характеристик алгоритмов, основанных на хешировании 723 15.5.8. Упражнения к разделу 15.5 724 15.6. Алгоритмы, основанные на индексировании 725 15.6.1. Группирующие индексы 725 15.6.2. Алгоритм выбора 726 15.6.3. Алгоритм соединения с использованием индекса 728 15.6.4. Алгоритмы соединения посредством сортировки и индексирования 729 15.6.5. Упражнения к разделу 15.6 731 15.7. Управление буферизацией 732 15.7.1. Архитектура менеджера буферов 732 15.7.2. Стратегии управления буферизацией 734 15.7.3. Выбор физических операторов и проблемы управления буферизацией 735 15.7.4. Упражнения к разделу 15.7 737 15.8. Многопроходные алгоритмы 738 15.8.1. Многопроходные алгоритмы, основанные на сортировке 738 15.8.2. Характеристики многопроходных алгоритмов, основанных на сортировке 739 15.8.3. Многопроходные алгоритмы, основанные на хешировании 739 15.8.4. Характеристики многопроходных алгоритмов, основанных на хешировании 740 15.8.5. Упражнения к разделу 15.8 741 20 СОДЕРЖАНИЕ
15.9. Параллельные алгоритмы для реляционных операторов 741 15.9.1. Архитектуры параллельных вычислительных систем 741 15.9.2. Параллельные алгоритмы для операций над отдельными кортежами 744 15.9.3. Параллельные алгоритмы для операций над полными отношениями 745 15.9.4. Характеристики параллельных алгоритмов 746 15.9.5. Упражнения к разделу 15.9 748 15.10. Резюме 749 15.11. Литература 751 Глава 16. Компиляция и оптимизация запросов 753 16.1. Синтаксический анализ 754 16.1.1. Синтаксический анализ и деревья разбора 754 16.1.2. Грамматика простого подмножества языка SQL 755 16.1.3. Препроцессор 759 16.1.4. Упражнения к разделу 16.1 759 16.2. Алгебраические законы и планы запросов 760 16.2.1. Коммутативный и ассоциативный законы 760 16.2.2. Законы выбора 762 16.2.3. Продвижение операторов выбора по дереву выражений 765 16.2.4. Законы проекции 766 16.2.5. Законы соединения и декартова произведения 769 16.2.6. Законы, касающиеся удаления кортежей-дубликатов 769 16.2.7. Законы группирования и агрегирования 770 16.2.8. Упражнения к разделу 16.2 772 16.3. От деревьев разбора к логическим планам запросов 774 16.3.1. От дерева разбора к дереву выражений реляционной алгебры 774 16.3.2. Изъятие подзапросов из условий 775 16.3.3. Улучшение логического плана запроса 780 16.3.4. Группирование ассоциативно-коммутативных операторов 781 16.3.5. Упражнения к разделу 16.3 782 16.4. Анализ стоимости операций 783 16.4.1. Оценка размеров промежуточных отношений 784 16.4.2. Оценка размера результата оператора проекции 785 16.4.3. Оценка размера результата оператора выбора 785 16.4.4. Оценка размера результата оператора соединения 788 16.4.5. Естественное соединение отношений с несколькими общими атрибутами 791 16.4.6. Соединение нескольких отношений 792 16.4.7. Оценка размеров результатов выполнения других операторов 794 16.4.8. Упражнения к разделу 16.4 796 16.5. Выбор планов с учетом их стоимости 797 16.5.1. Статистические характеристики данных 798 16.5.2. Вычисление статистик 801 16.5.3. Эвристические правила сокращения стоимости логических планов 802 СОДЕРЖАНИЕ 21
16.5.4. Способы сопоставительного анализа физических планов 804 16.5.5. Упражнения к разделу 16.5 807 16.6. Выбор порядка соединения 809 16.6.1. Различия между левыми и правыми операндами соединения 809 16.6.2. Деревья соединения 809 16.6.3. Левосторонние деревья соединения 810 16.6.4. Динамическое программирование и выбор порядка соединения 814 16.6.5. Динамическое программирование и уточненные функции стоимости 819 16.6.6. "Жадный" алгоритм выбора порядка соединения 819 16.6.7. Упражнения к разделу 16.6 821 16.7. Завершение формирования физического плана запроса 822 16.7.1. Поиск метода выбора 822 16.7.2. Поиск метода соединения 824 16.7.3. Организация каналов и материализация: за и против 825 16.7.4. Каналы и унарные операции 826 16.7.5. Каналы и бинарные операции 827 16.7.6. Система представления физических планов запросов 830 16.7.7. Упорядочение физических операторов 832 16.7.8. Упражнения к разделу 16.7 833 16.8. Резюме 834 16.9. Литература 836 Глава 17. Профилактика системных отказов и устранение их последствий 837 17.1. Модели живучести систем баз данных 838 17.1.1. Режимы отказов 838 17.1.2. Подробнее о транзакциях 839 17.1.3. Условия выполнения транзакций 841 17.1.4. Базовые операции транзакций 842 17.1.5. Упражнения к разделу 17.1 845 17.2. Протоколирование в режиме "undo" 846 17.2.1. Записи протокола 846 17.2.2. Правила протоколирования в режиме "undo" 847 17.2.3. Восстановление с применением протокола "undo" 850 17.2.4. Введение контрольных точек 852 17.2.5. Динамическое введение контрольных точек 854 17.2.6. Упражнения к разделу 17.2 857 17.3. Протоколирование в режиме "redo" 858 17.3.1. Правило протоколирования в режиме "redo" 859 17.3.2. Восстановление с применением протокола "redo" 860 17.3.3. Введение контрольных точек в режиме "redo" 861 17.3.4. Восстановление на основе протокола "redo" с контрольными точками 863 17.3.5. Упражнения к разделу 17.3 864 17.4. Протоколирование в режиме "undo/redo" 865 17.4.1. Правила протоколирования в режиме "undo/redo" 865 17.4.2. Восстановление с применением протокола "undo/redo" 866 22 СОДЕРЖАНИЕ
17.4.3. Введение контрольных точек в режиме "undo/redo" 867 17.4.4. Упражнения к разделу 17.4 869 17.5. Защита от отказа дискового устройства 870 17.5.1. Архив 871 17.5.2. Динамическое архивирование 872 17.5.3. Восстановление с применением архива и протокола 874 17.5.4. Упражнения к разделу 17.5 875 17.6. Резюме 875 17.7. Литература 876 Глава 18. Управление параллельными заданиями 879 18.1. Последовательные и условно-последовательные расписания 880 18.1.1. Расписания 880 18.1.2. Последовательные расписания 881 18.1.3. Условно-последовательные расписания 882 18.1.4. О важности конкретной семантики транзакций 884 18.1.5. Система обозначений для представления транзакций и расписаний 885 18.1.6. Упражнения к разделу 18.1 886 18.2. Условно-последовательное упорядочение с учетом конфликтов 887 18.2.1. Конфликты 887 18.2.2. Графы предшествования и расписания, условно- последовательные с учетом конфликтов 888 18.2.3. Обоснование корректности процедуры проверки графа предшествования 891 18.2.4. Упражнения к разделу 18.2 892 18.3. Последовательные расписания и механизмы блокирования 894 18.3.1. Блокировки 894 18.3.2. Архитектура простого планировщика с блокированием 897 18.3.3. Двухфазное блокирование 897 18.3.4. Обоснование корректности условия двухфазного блокирования 898 18.3.5. Упражнения к разделу 18.3 900 18.4. Системы с несколькими режимами блокирования 901 18.4.1. Общие и монопольные блокировки 902 18.4.2. Матрицы совместимости 904 18.4.3. Повышение уровня блокирования 905 18.4.4. Обновляемые блокировки 906 18.4.5. Инкрементные блокировки 908 18.4.6. Упражнения к разделу 18.4 910 18.5. Архитектура планировщика с блокированием 912 18.5.1. Планировщик заданий и вставка инструкций блокирования 912 18.5.2. Таблица блокировок 915 18.5.3. Упражнения к разделу 18.5 918 23
18.6. Управление иерархиями элементов базы данных 918 18.6.1. Блокировки с множеством степеней детализации 918 18.6.2. Предупреждающие блокировки 919 18.6.3. Фантомные кортежи и корректная обработка операций вставки 923 18.6.4. Упражнения к разделу 18.6 924 18.7. Протокол блокирования древовидных структур 924 18.7.1. Модель блокирования древовидных структур 924 18.7.2. Правила доступа к элементам древовидных структур 925 18.7.3. Обоснование корректности протокола блокирования древовидных структур 927 18.7.4. Упражнения к разделу 18.7 929 18.8. Хронометраж действий транзакций 930 18.8.1. Хронологические признаки 931 18.8.2. Физически неосуществимые расписания 931 18.8.3. Операции "чтения мусора" 932 18.8.4. Правила упорядочения действий с помощью механизма хронометража 934 18.8.5. Множественные версии элементов и хронологических признаков 936 18.8.6. Хронометраж и блокирование: за и против 938 18.8.7. Упражнения к разделу 18.8 939 18.9. Проверка достоверности действий транзакций 939 18.9.1. Архитектура планировщика с функциями проверки достоверности действий транзакций 939 18.9.2. Правила проверки достоверности действий транзакций 940 18.9.3. Упражнения к разделу 18.9 943 18.10. Сравнение схем управления параллельными заданиями 944 18.11. Резюме 945 18.12. Литература 947 Глава 19. Дополнительные аспекты управления транзакциями 949 19.1. Последовательное упорядочение операций и восстановление данных 949 19.1.1. Проблема "чтения мусора" 950 19.1.2. Каскадный откат 952 19.1.3. Восстановимые расписания 952 19.1.4. Расписания без каскадного отката 953 19.1.5. Управление процедурами отката с помощью схем блокирования 954 19.1.6. Групповая фиксация 956 19.1.7. Логическое протоколирование 957 19.1.8. Восстановление данных с помощью логического протокола 959 19.1.9. Упражнения к разделу 19.1 961 19.2. Условно-последовательное упорядочение с учетом источников данных 962 19.2.1. Эквивалентность расписаний с учетом источников данных 962 19.2.2. Теоретико-графовая модель расписаний, условно- последовательных с учетом источников данных 964 24 СОДЕРЖАНИЕ
19.2.3. Обоснование корректности процедуры проверки графа предшествования 967 19.2.4. Упражнения к разделу 19.2 968 19.3. Разрешение взаимоблокировок 968 19.3.1. Обнаружение взаимоблокировок по истечении лимита времени 968 19.3.2. Графы ожидания 969 19.3.3. Предотвращение взаимоблокировок за счет упорядочения элементов данных 971 19.3.4. Выявление взаимоблокировок с помощью механизма хронометража 972 19.3.5. Сравнение методов обнаружения и предотвращения взаимоблокировок 975 19.3.6. Упражнения к разделу 19.3 976 19.4. Распределенные базы данных 977 19.4.1. Концепция распределенных данных 977 19.4.2. Распределенные транзакции 979 19.4.3. Репликация данных 979 19.4.4. Распределенная оптимизация запросов 980 19.4.5. Упражнения к разделу 19.4 981 19.5. Распределенная фиксация 981 19.5.1. Поддержка распределенной атомарности 982 19.5.2. Двухфазная фиксация 982 19.5.3. Восстановление распределенных транзакций 985 19.5.4. Упражнения к разделу 19.5 986 19.6. Распределенное блокирование 987 19.6.1. Централизованное блокирование 988 19.6.2. Модель трудоемкости алгоритмов распределенного блокирования 988 19.6.3. Блокирование реплицированных элементов 989 19.6.4. Режим блокирования "главной копии" 990 19.6.5. Глобальные блокировки на основе локальных блокировок 991 19.6.6. Упражнения к разделу 19.6 992 19.7. Длинные транзакции 993 19.7.1. Проблемы использования длинных транзакций 993 19.7.2. Хроники 995 19.7.3. Уравновешивающие транзакции 996 19.7.4. Обоснование корректности модели уравновешивающих транзакций 997 19.7.5. Упражнения к разделу 19.7 998 19.8. Резюме 999 19.9. Литература 1001 Глава 20. Интеграция информации 1003 20.1. Обзор технологий интеграции информации 1003 20.1.1. Проблемы интеграции информации 1004 20.1.2. Федеративные базы данных 1005 СОДЕРЖАНИЕ 25
20.1.3. Хранилища данных 1007 20.1.4. Медиаторы 1009 20.1.5. Упражнения к разделу 20.1 1010 20.2. Компоненты-оболочки 1012 20.2.1. Шаблоны запросов 1012 20.2.2. Генераторы оболочек 1013 20.2.3. Фильтры 1014 20.2.4. Другие функции оболочек 1015 20.2.5. Упражнения к разделу 20.2 1017 20.3. Медиаторы и оптимизация с учетом возможностей источников данных 1017 20.3.1. Проблема ограниченных возможностей источника данных 1018 20.3.2. Классификация возможностей источника данных 1019 20.3.3. Выбор плана запроса с учетом возможностей источника данных 1020 20.3.4. Дополнительная оптимизация планов с учетом их стоимости 1022 20.3.5. Упражнения к разделу 20.3 1022 20.4. Оперативная аналитическая обработка данных 1023 20.4.1. Приложения OLAP 1024 20.4.2. Многомерная модель данных OLAP 1025 20.4.3. Схема "звезды" 1026 20.4.4. Рассечение и расслоение куба исходных данных 1028 20.4.5. Упражнения к разделу 20.4 1030 20.5. Кубы данных 1031 20.5.1. Оператор CUBE 1031 20.5.2. Реализация куба на основе материализованных представлений 1033 20.5.3. Сетки представлений 1036 20.5.4. Упражнения к разделу 20.5 1037 20.6. Разработка данных 1039 20.6.1. Приложения разработки данных 1039 20.6.2. Отыскание часто встречающихся наборов объектов 1042 20.6.3. Априорный алгоритм анализа рыночной корзины 1043 20.6.4. Упражнения к разделу 20.6 1045 20.7. Резюме 1046 20.8. Литература 1047 Послесловие редактора перевода 1049 Именной указатель 1053 Предметный указатель 1057 26 СОДЕРЖАНИЕ
Об авторах Джеффри Д. Ульман (Jeffrey D. Ullman), профессор компьютерных наук Станфорд- ского университета. Автор и соавтор 16 книг, включая, например, Elements of ML Programming (Prentice Hall, 1998). Сфера научных интересов — технологии анализа и "разработки" информации, интеграции данных и электронного обучения. Член Национальной академии инженерных наук США, обладатель стипендии Guggenheim Fellowship, лауреат премий Karl V. Karlstrom Outstanding Educator Award, SIGMOD Contributions Award и Knuth Prize. Дженнифер Уидом (Jennifer Widom), адъюнкт-профессор компьютерных наук и электротехники Станфордского университета. Сфера научных интересов — обработка запросов к потокам данных, кэширование и репликация информации, полуструктурированные данных и XML, хранилища данных. Обладатель стипендии Guggenheim Fellowship и член многочисленных комитетов, советов и редакционных коллегий. Гектор Гарсия-Молина (Hector Garcia-Molina), профессор компьютерных наук и электротехники, заведующий отделением компьютерных наук Станфордского университета. Сфера научных интересов — цифровые библиотеки, интеграция данных и приложения баз данных для Internet. Лауреат премии SIGMOD Innovations Award и член Совета по информационным технологиям при Президенте США.
Предисловие В Станфордском университете учебный период делится на четверти. Наше введение в технологии баз данных охватывает два курса. Первый, обозначаемый в соответствии с учебным планом специальности "Компьютерные науки" как CS145, предназначен для тех слушателей, которые в период профессиональной деятельности собираются использовать базы данных, но не обязательно участвовать в реализации СУБД — систем управ- ления базами данных. Этот курс служит основой другого курса, CS245, охватывающего проблематику реализации СУБД. Студенты, желающие углубить знания в области систем баз данных, могут далее перейти к курсам CS345 (теория), CS346 (проект реальной СУБД) и CS347 (обработка транзакций и распределенные базы данных). За четыре последних года мы опубликовали две книги: A First Course in Database Systems содержала сведения, имеющие отношение к курсу CS145, a Database System Implementation была посвящена вопросам, которые обычно находят отражение в курсах CS245 и, частично, CS346. Поскольку многие университеты придерживаются семестровой модели преподавания и сочетают оба вводных курса в одном, мы почувствовали насущную потребность в объединении материала этих книг. В то же время эволюция систем баз данных породила целый ряд новых тем, относящихся к сфере программирования приложений и заслуживающих внимания при написании современного учебного пособия: так, например, мы постарались осветить вопросы обработки объектно- реляционных данных, применения средств SQL/PSM, обеспечивающих возможности создания хранимых программ, а также SQL/CLI и JDBC — стандартов интерфейсов C/SQL и Java/SQL соответственно. Как работать с книгой Мы рекомендуем посвятить изучению книги две учебные четверти. Если следовать подходу, принятому в Станфорде, на протяжении первой четверти целесообразно рассмотреть начальные десять глав, а во второй четверти — заключительные главы. Если же вы предпочтете охватить материал книги в течение одного семестра, вам, вероятно, придется исключить какие-то ее части. По нашему мнению, более пристальное внимание следует уделить главам 2—7, 11—13 и 17—18, хотя и в них имеются отдельные фрагменты, которые при необходимости можно опустить. Если вы захотите предложить студентам подробные сведения по вопросам программирования приложений баз данных и продемонстрировать соответствующий реальный проект (при изложении курса CS145 мы сами поступаем именно так), вам, возможно, потребуется определенным образом переупорядочить материал, чтобы раздел, касающийся инструкций языка SQL, был рассмотрен несколько раньше. Изучение других тем, таких как зависимости данных, напротив, до определенного момента может быть отложено, хотя, разумеется, для реализации проекта студентам потребуются знания о нормализации данных. Предварительные условия Слушателями курса, охватываемого нашей книгой, являются студенты- выпускники. Ниже перечислены дисциплины, без знания которых, формально говоря, ее освоение будет затруднено; 1) структуры данных, алгоритмы и основы дискрет-
ной математики; 2) системы и языки программирования. Важно, чтобы студенты прошли хотя бы элементарную предварительную подготовку в таких областях, как алгебраические законы и выражения, логика высказываний, базовые структуры данных (деревья поиска, графы и т.д.), концепции объектно-ориентированного программирования и среды программирования. Впрочем, мы имеем основания надеяться, что соответствующими знаниями обладают даже те студенты, которые завершили только начальный курс обучения по типовой программе специальности "Компьютерные науки". Упражнения Почти все разделы книги содержат большое количество упражнений. Более трудные задания или их части помечены в тексте одним восклицательным знаком (!), а самые серьезные — двумя. Отдельные упражнения либо их фрагменты снабжены символом звездочки (*), который свидетельствует о том, что решение упражнения приведено (либо будет приведено в ближайшее время) в тексте Web-страницы нашей книги. Подобные решения открыты для широкого доступа и могут быть использованы вами для самоконтроля. Примите к сведению, что в нескольких случаях некоторое упражнение В предусматривает доработку или исправление решения упражнения А. Если для определенных частей упражнения Л предлагаются решения, вы вправе ожидать, что таковые должны существовать и для соответствующих фрагментов упражнения В. Ресурсы в World Wide Web Web-страница книги размещена по следующему адресу: http://www-db.Stanford.edu/~ullman/dscb.html На ней приводятся решения упражнений, текст которых помечен в книге символом звездочки (*), информация об ошибках, включаемая по мере ее поступления, и вспомогательный материал. Мы также предлагаем конспекты курсов CS145 и CS245 в том виде, в каком их преподаем, домашние задания, условия курсовых работ и экзаменационные вопросы. Благодарности В процессе работы над книгой нам помогало множество людей, которые рецензировали отдельные части текста и сообщали об обнаруженных ошибках и недочетах. Мы искренне рады назвать и поблагодарить всех, кто способствовал улучшению ее качеств: Марк Абромовиц (Marc Abromowitz), Джозеф Адамски (Joseph Adamski), Брэд Эделберг (Brad Adelberg), Глеб Ашимов (Gleb Ashimov), Дональд Эйнгуэрт (Donald Aingworth), Джонатан Беккер (Jonathan Becker), Маргарет Бенитез (Margaret Benitez), Ларри Бонем (Larry Bonham), Филип Боннет (Phillip Bonnet), Давид Броко (David Brokaw), Эд Бернз (Ed Burns), Карен Батлер (Karen Butler), Кристофер Чан (Christopher Chan), Сударшан Чават (Sudarshan Chawathe), Пер Кристенсен (Per Christensen), Эд Чанг (Ed Chang), Сураджит Чоудхури (Surajit Chaudhuri), Кен Чен (Ken Chen), Рада Киркова (Rada Chirkova), Нитин Чопра (Nitin Chopra), Бобби Кок- рин (Bobbie Cochrane), Артуро Кресло (Arturo Crespo), Линда де Мишелл (Linda DeMichiel), Том Динстбьер (Tom Dienstbier), Пэл д'Соуза (Pearl D'Souza), Оливер Душка (Oliver Duschka), Ксавье Фаз (Xavier Faz), Грег Фихтенголц (Greg Fichtenholtz), Барт Фишер (Bart Fisher), Джерл Фрайис (Jarl Friis), Джон Фрай (John Fry), Чи-пинь Фу (Chi-Ping Fu), Трейси Фудзиеда (Tracy Fujieda), Маниш Годара (Manish Godara), Мередит Голдсмит (Meredith Goldsmith), Луис Гравано (Luis Gravano), Жерар Гилль- метт (Gerard Guillemette), Рафаэль Эрнандес (Rafael Hernandez), Антти Хьелт (Antti ПРЕДИСЛОВИЕ 29
Hjelt), Бен Голыдман (Ben Holtzman), Стив Хантсбери (Steve Huntsberry), Леонард Джекобсон (Leonard Jacobson), Туласираман Джейяраман (Thulasiraman Jeyaraman), Дуайт Джо (Dwight Joe), Сет Катц (Seth Katz), Ен-пинь Ко (Yeong-Ping Koh), Дьердь Ковач (Gyirrgy Kovacs), Филип Коза (Phillip Koza), Брайан Калман (Brian Kulman), Сань Хо Ли (Sang Ho Lee), Оливье Лобри (Olivier Lobry), Лю Чао-Джун (Lu Chao-Jun), Арун Марат (Arun Marathe), Ли-вей Mo (Le-Wei Mo), Фабьен Модо (Fabian Modoux), Питер Морк (Peter Mork), Марк Мортенсен (Mark Mortensen), Рампракаш Нарайянасвами (Ramprakash Narayanaswami), Нанк-юнь На (Nankyung Na), Мэри Нильссон (Marie Nillson), Торбьерн Норби (Torbjorn Norbye), Чань-мин О (Chang-Min Oh), Мегул Пател (Mehul Patel), Берт Портер (Bert Porter), Лимбек Река (Limbek Reka), Пракаш Раманан (Prahash Ramanan), Кен Росс (Ken Ross), Тим Рафгартен (Tim Roughgarten), Мема Рос- сопулос (Mema Roussopoulos), Ричард Скерл (Richard Scherl), Кэтрин Торнабин (Catherine Tornabene), Андерс Уль (Anders Uhl), Джонатан Ульман (Jonathan Ullman), Майанк Упадхьяй (Mayank Upadhyay), Вассилис Вассалос (VassiHs Vassalos), Кьянь Уанг (Qiang Wang), Кристиан Виджайа (Kristian Widjaja), Дженет By (Janet Wu), Сундар Йа- муначари (Sundar Yamunachari), Такеши Иокукава (Takeshi Yokukawa), Мин-си Юн (Min-Sig Yun), Торбен Заль (Torben Zahle) и Сэнди Занг (Sandy Zhang). Исключительную ответственность за ошибки, оставшиеся в тексте книги, несем мы, ее авторы. 30 ПРЕДИСЛОВИЕ
Глава 1 Мир баз данных Современные технологии баз данных являются одним из определяющих факторов успеха в любой отрасли бизнеса, обеспечивая хранение корпоративной информации, представление данных для пользователей и клиентов в среде World Wide Web и поддержку многих других процессов. Помимо того, базы данных составляют основу разнообразных научных проектов. Они позволяют накапливать информацию, собранную астрономами, исследователями генотипа человека, биохимиками, изучающими свойства протеинов, и специалистами многих других отраслей знания. Мощь баз данных зиждется на результатах исследований и технологических разработок, полученных на протяжении нескольких последних десятилетий, и заключена в специализированных программных продуктах, которые принято называть системами управления базами данных (СУБД) (Database Management Systems — DBMS), или просто системами баз данных (database systems). СУБД — это эффективный инструмент сбора больших порций информации и действенного управления ими, позволяющий сохранять данные в целости и безопасности на протяжении длительного времени. СУБД относятся к категории наиболее сложных программных продуктов, имеющихся на рынке в настоящее время. СУБД предлагают пользователям функциональные возможности, перечисленные ниже. 1. Средства постоянного хранения данных. СУБД, подобно файловым системам, поддерживают возможности хранения чрезвычайно больших фрагментов данных, которые существуют независимо от каких бы то ни было процессов их использования. СУБД, однако, значительно превосходят файловые системы в отношении гибкости представления информации, предлагая структуры, обеспечивающие эффективный доступ к большим порциям данных. 2. Интерфейс программирования. СУБД позволяет пользователю или прикладной программе обращаться к данным и изменять их посредством команд развитого языка запросов. Преимущества СУБД в сравнении с файловыми системами проявляются и в том, что первые дают возможность манипулировать данными самыми разнообразными способами, гораздо более гибкими, нежели обычные операции чтения и записи файлов. 3. Управление транзакциями. СУБД поддерживают параллельный доступ к данным, т.е. возможность единовременного обращения к одной и той же порции данных со стороны нескольких различных процессов, называемых транзакциями (transactions). Чтобы избежать некоторых нежелательных последствий подобного обращения, СУБД реализуют механизмы обеспечения изолированности
(isolation) транзакций (транзакции выполняются независимо одна от другой, как если бы они активизировались строго последовательно), их атомарности (atomicity) (каждая транзакция либо выполняется целиком, либо не выполняется вовсе) и устойчивости (durability) (системы содержат средства надежного сохранения результатов выполнения транзакций и самовосстановления после различного рода ошибок и сбоев) . 1.1. Эволюция систем баз данных Что такое база данных? По существу, это не что иное, как набор порций информации, существующий в течение длительного периода времени (возможно, исчисляемого годами или даже десятилетиями). Термином база данных (database) в соответствии с принятой традицией обозначают набор данных, находящийся под контролем СУБД. Добротная СУБД обязана обеспечить реализацию следующих требований. 1. Позволять пользователям создавать новые базы данных и определять их схемы (schemata) (логические структуры данных) с помощью некоторого специализированного языка, называемого языком определения данных (Data Definition Language — DDL). 2. Предлагать пользователям возможности задания запросов (queries) (слово "запрос", в данном случае обладающее известным жаргонным оттенком, означает вопрос, затрагивающий те или иные аспекты информации, хранящейся в базе данных) и модификации данных средствами соответствующего языка за- просов (query language), или языка управления данными (Data Manipulation Language — DML). 3. Поддерживать способность сохранения больших объемов информации —- до многих гигабайтов и более — на протяжении длительных периодов времени, предотвращая опасность несанкционированного доступа к данным и гарантируя эффективность операций их просмотра и изменения. 4. Управлять единовременным доступом к данным со стороны многих пользователей, исключая возможность влияния действий одного пользователя на результаты, получаемые другим, и запрещая совместное обращение к данным, чреватое их порчей. 1.1.1. Первые СУБД Появление первых коммерческих систем управления базами данных датируется концом 1960-х годов. Непосредственными предшественниками таких систем были файловые системы, удовлетворявшие только некоторым из требований, перечисленных выше (см. п. 3). Файловые системы действительно пригодны для хранения обширных фрагментов данных в течение длительного времени, но они не способны гарантировать, что данные, не подвергшиеся резервному копированию, не будут испорчены или утеряны, и не поддерживают эффективные инструменты доступа к элементам данных, положение которых в определенном файле заранее не известно. Файловые системы не отвечают и условиям п. 2, т.е. не предлагают языка запросов, подходящего для обращения к данным внутри файла. Обеспечиваемая ими реализация требований п. 1, предполагающих наличие возможности создания схем данных, ограничена способностью определения структур каталогов. Наконец, файловые системы совершенно не удовлетворяют условиям п. 4. Даже если система и не препятствует параллельному доступу к файлу со стороны нескольких пользователей или процессов, она не в состоянии предотвратить возникновение ситуаций, когда, например, два пользователя в один и тот же момент времени пытаются внести изменения в один файл: результаты действий одного из них наверняка будут утрачены. 32 ГЛАВА 1. МИР БАЗ ДАННЫХ
К числу первых серьезных программных приложений СУБД относились те, в которых предполагалось, что данные состоят из большого числа элементов малого объема; для обработки таких элементов требовалось выполнять множество элементарных запросов и операций модификации. Ниже кратко рассмотрены некоторые из ранних приложений баз данных. Системы бронирования авиабилетов Система подобного типа имеет дело со следующими элементами данных: 1) сведениями о резервировании конкретным пассажиром места на определенный авиарейс, включая информацию о номере места и обеденном меню; 2) информацией о полетах — аэропортах отправления и назначения для каждого рейса, сроках отправки и прибытия, принадлежности воздушных судов тем или иным компаниям, экипажах и т.п.; 3) данными о ценах на авиабилеты, поступивших заявках и наличии свободных мест. В типичных запросах требуется выяснить, какие рейсы из одного заданного аэропорта в другой близки по времени отправления к указанному календарному периоду, имеются ли свободные места и какова стоимость билетов. К числу характерных операций по изменению данных относятся бронирование места на рейс, определение номера места и выбор обеденного меню. В любой момент к одним и тем же элементам данных могут обращаться несколько операторов-кассиров. СУБД обязана обеспечить подобную возможность, но исключить любые потенциальные проблемы, связанные, например, с продажей нескольких билетов на одно место, а также предотвратить опасность потери записей данных, если система внезапно выйдет из строя. Банковские системы Базы данных банковских систем содержат информацию об именах и адресах клиентов, лицевых счетах, кредитах, остатках и оборотах денежных средств, а также о связях между элементами бухгалтерской и персональной информации, т.е. о том, кто из клиентов владеет теми или иными счетами, кредитами и т.п. Весьма распространенными являются запросы об остатке на счете, а также операции по изменению его состояния, связанные с приходом или расходом средств. Как и в ситуации с системой бронирования авиабилетов, вполне естественной выглядит возможность одновременного доступа к информации со стороны многочисленных клиентов и служащих банка, пользующихся локальными терминалами, банкоматами или средствами Web. В этой связи жизненно важное значение приобретает требование о том, чтобы единовременное обращение к одному и тому же банковскому счету ни при каких условиях не приводило к потере отдельных транзакций. Какие бы то ни было ошибки в данном случае совершенно не допустимы. Как только, например, деньги со счета выданы банкоматом, система должна немедленно сохранить информацию о выполненной расходной операции — даже тогда, когда в тот же момент внезапно отключилось электропитание. Соответствующие решения, обладающие требуемым уровнем надежности, далеко не очевидны и могут быть отнесены к разряду "фигур высшего пилотажа" в сфере технологий СУБД. Корпоративные системы Многие из ранних приложений баз данных были предназначены для хранения корпоративной информации — записей о продажах и закупках, данных об остатках на счетах внутреннего бухгалтерского учета или персональных сведений о служащих компании (их именах, адресах проживания, уровнях фиксированной заработной платы, надбавках, отчислениях и т.д.). Запросы к таким базам данных позволяют полу- 1.1. ЭВОЛЮЦИЯ СИСТЕМ БАЗ ДАННЫХ 33
чать информацию о состоянии счетов, выплатах сотрудникам и т.п. Каждая операция купли/продажи, прихода/расхода, приема сотрудника на работу, его продвижения по службе или увольнения приводит к изменению соответствующих элементов данных. Самые первые СУБД, во многом унаследовавшие свойства файловых систем, оказывались способными представлять результаты запросов практически только в том виде, который соответствовал структуре хранения данных. В подобных системах баз данных находили применение несколько различных моделей описания структуры информации — в основном, "иерархическая" древовидная и "сетевая" графовая. В конце 1960-х годов последняя получила признание и нашла отражение в стандарте CODASYL (Committee on Data Systems and Languages).1 Одной из основных проблем, препятствовавших распространению и использованию таких моделей и систем, было отсутствие поддержки ими высокоуровневых языков запросов. Например, язык запросов CODASYL для перехода от одного элемента данных к другому предусматривал необходимость просмотра вершин графа, представляющего элементы и связи между ними. Совершенно очевидно, что в таких условиях для создания даже самых простых запросов требовались весьма серьезные усилия. 1.1.2. Системы реляционных баз данных После опубликования в 1970 году знаменитой статьи Э.Ф. Кодда (E.F. Codd)2 системы баз данных претерпели существенные изменения. Д-р Кодд предложил схему представления данных в виде таблиц, называемых отношениями (relations). Структуры таблиц могут быть весьма сложными, что не снижает скорости обработки самых различных запросов. В отличие от ранних систем баз данных, рассмотренных выше, пользователю реляционной базы данных вовсе не требуется знать об особенностях организации хранения информации на носителе. Запросы к такой базе данных выражаются средствами высокоуровневого языка, позволяющего значительно повысить эффективность работы программиста. Различным аспектам реляционной модели, положенной в основу многих современных СУБД, посвящен материал большинства глав нашей книги, начиная с главы 3 (см. с. 87), в которой изложены основные концепции модели. В главе 6 (см. с. 249) и нескольких следующих главах мы расскажем о языке SQL (Structured Query Language — язык структурированных запросов) — наиболее важном и мощном представителе семейства языков запросов. Впрочем, дабы продемонстрировать читателю простоту и изящество модели, уже сейчас имеет смысл изложить краткие сведения об отношениях и привести наглядный пример использования SQL, который позволил бы показать, каким образом реляционная модель создает благоприятные условия для применения высокоуровневых запросов и позволяет избежать необходимости "копания" в недрах базы данных. Пример 1.1. Отношения — это таблицы. Каждый столбец таблицы озаглавлен посредством атрибута (attribute), описывающего природу элементов столбца. Например, отношение Accounts, содержащее данные о номерах банковских счетов (accountNo), их типах (type) и величине остатков (balance), могло бы выглядеть следующим образом: accountNo balance type 12345 1000.00 savings 67890 223322.99 checking 1 CODASYL Data Base Task Group April 1971 Report, ACM, New York. 2 Codd E.F. A relational model for large shared data banks, Comm. ACM, 13:6 (1970), p. 377-387. 34 ГЛАВА 1. МИР БАЗ ДАННЫХ
Столбцы таблицы озаглавлены следующими атрибутами: accountNo, type и balance. Под строкой атрибутов расположены строки данных, или кортежи (tuples). Здесь явно показаны два кортежа отношения, а многоточия в последней строке указывают на тот факт, что отношение может включать большее число кортежей, по одному на каждый счет, открытый в банке. Первый кортеж свидетельствует о том, что на счете с номером 12345 содержится остаток, равный 1000 денежных единиц, и счет относится к категории накопительных (savings). Второй кортеж соответствует чековому (checking) счету с номером 67890 и остатком 223322.79. Пусть необходимо узнать величину остатка на счете с номером 67890. Соответствующий запрос, оформленный по правилам языка SQL, может выглядеть так: SELECT balance FROM Accounts WHERE accountNo = 67890; Рассмотрим другой пример. Чтобы получить список номеров накопительных счетов с отрицательным остатком, достаточно выполнить следующий запрос: SELECT accountNo FROM Accounts WHERE type = 'savings' AND balance < 0; Разумеется, мы не вправе ожидать, что двух приведенных примеров будет достаточно, чтобы превратить новичка в эксперта по программированию на языке SQL, но они вполне способны донести до читателя смысл инструкции SQL "select—from—where" ("выбрать—из—при_условии"). Каждое из рассмотренных выражений SQL по существу заставляет СУБД выполнить следующие действия: 1) проверить все кортежи отношения Accounts, упомянутого в предложении from; 2) выбрать те кортежи, которые удовлетворяют некоторому критерию, описанному предложением where; 3) возвратить в качестве результата определенные атрибуты выбранных кортежей, перечисленные в предложении select. В реальной ситуации система бывает способна "оптимизировать" запрос, чтобы отыскать некоторый более эффективный способ выполнения поставленного задания, — даже в том случае, если размеры отношений, участвующих в запросе, чрезвычайно велики. □ До 1990-х годов системы реляционных баз данных занимали главенствующее положение. Однако технологии СУБД продолжают интенсивно развиваться, и на арене с завидной регулярностью появляются новые теоретические и технологические решения проблемы управления данными. Нам хотелось бы быть последовательными, поэтому мы должны уделить внимание некоторым современным тенденциям развития систем баз данных. 1.1.3. Уменьшение и удешевление систем Изначально СУБД представляли собой крупные и дорогие программные комплексы, ориентированные на использование больших компьютеров. Обширные "размеры" компьютера были необходимым условием работоспособности СУБД, имевших дело с гигабайтами информации. Сегодня многие гигабайты данных способны уместиться на единственном маленьком дисковом устройстве, поэтому вполне закономерным итогом развития технологий стала возможность установки СУБД на персональных компьютерах. Системы баз данных, основанные на реляционной модели, теперь доступны для использования на самых малых машинах и становятся обычным компонентом вычислительных систем — во многом подобно тому, как в свое время та же счастливая участь постигла приложения текстовых процессоров и электронных таблиц. 1.1. ЭВОЛЮЦИЯ СИСТЕМ БАЗ ДАННЫХ 35
1.1.4. Тенденции роста систем Гигабайт — это в действительности далеко не самый большой объем информации. Размеры корпоративных баз данных зачастую исчисляются сотнями гигабайтов. Помимо того, с удешевлением носителей информации человек получает в свое распоряжение новые возможности хранения все возрастающих массивов данных. Например, базы данных, обслуживающие пункты розничной продажи, нередко включают терабайты (I терабайт равен 1000 гигабайт, или 1012 байт) информации, фиксирующей каждую операцию продажи на протяжении длительного периода времени, что позволяет более эффективным образом планировать оптовые поставки товаров (подобные вопросы мы осветим в разделе 1.1.7 на с. 38). Помимо того, современные базы данных способны хранить не только простые элементы данных, такие как целые числа и короткие строки символов. Они позволяют накапливать графические изображения, аудио- и видеозаписи и чрезвычайно крупные фрагменты данных других типов. Например, для хранения видеоматериалов часовой продолжительности воспроизведения требуется участок носителя емкостью в один гигабайт. Базы данных, предназначенные для хранения графической информации, полученной со спутников, могут охватывать петабайты (1000 терабайт, или 1015 байт) данных. Задача обслуживания крупных баз данных требует неординарных технологических решений. Базы данных даже относительно скромных размеров сегодня обычно размещают на дисковых массивах, называемых вторичными устройствами хранения (secondary storage devices) — в отличие от оперативной памяти (main memory), которая служит ипервичным " хранилищем информации. Нередко говорят и о том, что наиболее существенной особенностью, отличающей СУБД от других программных продуктов, является их способность к долговременному хранению данных на внешних носителях и загрузке требуемых порций информации в оперативную память по мере необходимости. Технологические решения, кратко рассмотренные ниже, позволяют СУБД эффективно справляться с неуклонно возрастающими потоками данных. Третичные устройства хранения Для нормального функционирования самых крупных баз данных, используемых в настоящее время, возможностей, предлагаемых обычными дисковыми накопителями, уже не достаточно. Поэтому разрабатываются различные типы третичных устройств хранения (tertiary storage devices) данных. Такое устройство, способное к сохранению терабайтов информации, требует гораздо большего времени для доступа к конкретному элементу данных, нежели диск. Если период обращения к данным на диске исчисляется, как правило, 10—20 миллисекундами, на выполнение аналогичной операции третичным устройством хранения может уйти несколько секунд. Третичные устройства хранения предполагают наличие какого-либо роботизированного транспортного средства, способного перемещать носитель, на котором расположен запрошенный элемент данных, к устройству чтения данных. Функции отдельных носителей данных в третичных устройства хранения могут выполнять компакт-диски (CD) либо диски формата DVD (digital versatile disk). Захват робота передвигается к определенному диску, выбирает его, перемещает к устройству чтения и загружает в последний. Параллельные вычисления Способность системы сохранять громадные объемы данных, разумеется, важна, но она вряд ли будет востребована, если производительность такой системы недостаточно высока. Поэтому СУБД, обрабатывающие чрезмерно большие фрагменты информации, нуждаются в реализации решений, позволяющих повысить скорость вычислений. Один из важнейших подходов к проблеме связан с использованием структур индексов (indexes) — мы упомянем их в разделе 1.2.2 на с. 40 и рассмотрим более полно 36 ГЛАВА 1. МИР БАЗ ДАННЫХ
в главе 13 (см. с. 583). Другой способ достижения поставленной цели — обработать больше данных в течение промежутка времени заданной продолжительности — предполагает обращение к средствам распараллеливания вычислений. Параллелизм вычислений реализуется в нескольких направлениях. Поскольку скорость считывания данных, расположенных на определенном диске, заведомо низка и измеряется несколькими мегабайтами в секунду, ее можно увеличить, если использовать множество дисков и выполнять операции чтения данных с них параллельно (такой подход приемлем даже в том случае, если в системе применяется третичное устройство хранения, так как данные, прежде чем поступить в распоряжение СУБД, в любом случае "кэшируются" на дисках). Такие диски могут служить частью специальным образом спроектированной параллельной вычислительной машины либо компонентами распределенной системы, состоящей из нескольких машин, каждая иэ которых ответственна за поддержку определенного звена базы данных и при необходимости допускает обращение при посредничестве высокопроизводительного сетевого соединения. Разумеется, способность системы к быстрому перемещению данных — равно как и возможность хранения больших объемов информации — сама по себе еще не служит гарантией того, что результаты запросов будут получены достаточно быстро. Независимо от применяемых аппаратных средств, безусловно необходимы реализации соответствующих алгоритмов, позволяющих "дробить" множества запросов на части таким образом, чтобы позволить параллельным компьютерам или распределенным сетям компьютеров эффективно использовать все имеющиеся вычислительные ресурсы. Параллельное и распределенное управление сверхбольшими базами данных остается сферой активных исследований и технологических разработок; более серьезное внимание этой теме мы уделим в разделе 15.9 на с. 741. 1.1*5. Системы "клиент/сервер" и многоуровневые архитектуры Огромный пласт современного программного обеспечения поддерживает архитектуру клиент/сервер (client/server), в соответствии с которой запросы, сформированные одним процессом {клиентом), отсылаются для обработки другому процессу {серверу). Системы баз данных в этом смысле -— не исключение: обычной практикой является разделение функций СУБД между процессом сервера и одним или несколькими клиентскими процессами. Простейший вариант архитектуры "клиент/сервер" предполагает, что СУБД целиком представляет собой сервер, за исключением интерфейсов запросов, которые взаимодействуют с пользователем и отсылают запросы и другие команды на сервер с целью их выполнения. Например, в реляционных системах для представления запросов клиентов к серверу используются инструкции языка SQL. Результаты выполнения запросов сервером возвращаются клиентам в форме таблиц, или отношений. Взаимосвязь клиента и сервера может быть гораздо более сложной, особенно в тех случаях, когда результаты выполнения запросов обладают сложной структурой или большим объемом. Более подробно мы рассмотрим этот вопрос в следующем разделе. Существует и тенденция к тому, чтобы изрядную часть функций оставлять за клиентом, если серверное звено в общей структуре системы является "узким местом" ввиду того, что сервер базы данных из-за большого числа единовременных подключений испытывает чрезмерную нагрузку. В последнее время широкое распространение получили многоуровневые архитектуры, в которых СУБД отводится роль поставщика динамически генерируемого содержимого Web-сайтов. СУБД продолжает действовать как сервер базы данных, но его клиентом теперь служит сервер приложений (application server), который управляет подключениями к базе данных, транзакциями, авторизацией и иными процессами. Клиентами серверов приложений в свою очередь могут являться Web-серверы, обслуживающие конечных пользователей, и другие программные приложения. 1.1. ЭВОЛЮЦИЯ СИСТЕМ БАЗ ДАННЫХ 37
1.1.6. Данные мультимедиа Другая важная тенденция развития современных СУБД связана с поддержкой данных мультимедиа. Употребляя термин мультимедиа (multimedia), мы имеем в виду информацию, представляющую сигнал определенного вида. К числу наиболее распространенных разновидностей данных мультимедиа относятся аудио- и видеозаписи, сигналы, полученные от радаров, спутниковые изображения, а также документы и графика различных форматов. Общим свойством элементов данных мультимедиа является большой объем, способный изменяться в широких пределах, что отличает их от традиционных единиц представления информации — целых чисел, строк фиксированной длины и т.п. Потребность в хранении данных мультимедиа способствует развитию технологий СУБД в нескольких направлениях. Например, общепринятые операции, применимые в отношении простых элементов данных, не приемлемы в контексте проблемы обработки информации мультимедиа. Хотя задача поиска в базе данных всех номеров банковских счетов с отрицательным сальдо, предполагающая сравнение значений остатков с вещественным числом 0.0, является вполне правомерной, совершенно не уместной будет выглядеть попытка отыскания в базе данных фотографических изображений лиц, "похожих" на определенную физиономию. Чтобы обеспечить возможность выполнения манипуляций сложной информацией (например, операций по обработке графических изображений), СУБД должны позволять пользователям определять новые функции, которые необходимы в той или иной ситуации. Расширение функционального потенциала систем зачастую осуществляется на основе объектно-ориентированного подхода — даже в контексте сугубо реляционных СУБД, которые после подобной "доработки" становятся "объектно- реляционными" (object-relational). Аспекты объектно-ориентированного программирования приложений баз данных мы будем рассматривать неоднократно — в частности, в главах 4 (см. с. 149) и 9 (см. с. 419). Большие размеры объектов данных мультимедиа вынуждают разработчиков СУБД модифицировать функции менеджеров хранения данных, чтобы обеспечить возможность размещения в базе данных объектов или кортежей объемом в гигабайт и более. Одна из серьезных проблем, возникающих вследствие непомерного роста объема элементов данных, связана с доставкой клиенту результатов отправленного им запроса. В контексте традиционной реляционной базы данных результатом выполнения запроса служит набор кортежей, которые возвращаются клиенту как единое целое. А теперь предположим, что результатом выполнения запроса является видеоклип объемом в один гигабайт. Вполне очевидно, что задача доставки клиенту элемента данных размером в гигабайт в виде единого целого не может считаться безусловно корректной. Во-первых, фрагмент данных настолько велик, что попытка его пересылки воспрепятствует обработке сервером всех других запросов, ожидающих обслуживания. Во-вторых, пользователь может быть заинтересован в получении только небольшой части клипа, но он лишен возможности точно сформулировать цель запроса, не взглянув, например, на начальный фрагмент материала. В-третьих, даже в том случае, если пользователь абсолютно убежден в необходимости получения всего клипа, надеясь просмотреть его целиком, вполне достаточно передавать информацию частями с фиксированной скоростью в течение одного часа (промежутка времени, необходимого для воспроизведения гигабайта сжатых видеоданных). Таким образом, подсистема хранения данных СУБД, поддерживающей форматы мультимедиа, должна предлагать интерактивный режим обслуживания запросов, чтобы пользователь смог указать, желает ли он получать фрагменты данных по дополнительному требованию либо непрерывно с фиксированной частотой. 1.1.7. Интеграция информации По мере повышения роли информации в жизни общества изменяются и развиваются способы использования существующих информационных источников. В качестве примера рассмотрим компанию, желающую обладать электронным каталогом всех собст- 38 ГЛАВА 1. МИР БАЗ ДАННЫХ
венных товаров, чтобы потенциальные клиенты получили возможность просматривать каталог средствами Web-броузера, выбирать нужные товары и оформлять электронные заказы. Крупные компании состоят из многих подразделений. Каждое независимое подразделение вправе создавать собственные базы данных о товарах и применять при этом различные СУБД, различные структуры данных и даже употреблять различные наименования одной и той же вещи либо один термин для обозначения нескольких вещей. Пример 1.2. Рассмотрим компанию, производящую компьютерные диски и состоящую из нескольких филиалов. В каталоге продукции одного филиала скорость вращения дисков представлена, скажем, в виде значения количества оборотов в секунду, а в каталоге другого филиала в качестве единицы измерения того же параметра выбрано количество оборотов в минуту. Третий каталог вовсе не содержит упоминаний о скорости вращения дисков. В каталоге филиала, производящего гибкие диски, для обозначения продукции употребляется термин "диск". То же название товара используется и в подразделении, занимающемся разработкой жестких дисков. В одном случае дорожки диска могут быть названы "треками", а в другом — "цилиндрами". □ Строгую централизацию управления не всегда можно считать приемлемым решением рассмотренной проблемы. Подразделения компании, возможно, инвестировали большие средства в создание собственных баз данных еще до того момента, когда на повестке дня возник вопрос о целесообразности интеграции информации в рамках всей компании. Также вполне допустимо, что какое-либо подразделение, обладающее собственной базой данных, вошло в состав компании совсем недавно. Исходя из подобных и иных причин так называемые унаследованные базы данных (legacy databases) подразделений не могут (и не должны) непосредственно заменяться единой центральной базой данных компании. Более разумно построить "поверх" существующих унаследованных баз новую информационную структуру, способную представить всю продукцию компании в согласованном и последовательном виде. Один из самых популярных подходов к решению такой задачи связан с использованием технологий хранилищ данных (data warehouses), которые предполагают копирование информации из унаследованных баз данных с соответствующей трансляцией и последующим сохранением в центральной базе данных. При изменении состояния унаследованной базы данных необходимые исправления вносятся и в содержимое хранилища, хотя не обязательно автоматически и немедленно. Весьма часто репликацию данных осуществляют ночью, когда вероятность загрузки унаследованных баз данных наиболее низка. Унаследованная база данных, таким образом, продолжает выполнять все обычные функции, предусмотренные в период ее проектирования, а новые, такие как поддержка электронных каталогов в Web, возлагаются на хранилище данных. Содержимое хранилищ данных используется также в целях планирования и анализа: аналитики компании получают возможность обращаться к хранилищу данных с запросами, позволяющими, например, выявить тенденции продаж продукции, чтобы оптимизировать ее ассортимент и спланировать дальнейшее развитие производства. Хранилища данных открывают перспективы применения новейших технологий "разработки " (или "добычи ") данных (data mining) -~ поиска любопытных и необычных образцов информации и использования их для оптимизации бизнес-процессов. Эти и другие вопросы интеграции данных мы обсудим в главе 20 (см. с. 1003). 1.2. Обзор структуры СУБД На рис. 1.1 приведена структурная схема типичной системы управления базами данных. Прямоугольниками из одинарных линий обозначены компоненты системы, а фигурами из двойных линий — структуры данных, организованные в памяти. Непрерывные отрезки со стрелками указывают направление потоков управляющих инструкций и данных, а пунктирными линиями отмечены только потоки данных. По- 1.2. ОБЗОР СТРУКТУРЫ СУБД 39
скольку схема достаточно сложна, мы будем рассматривать ее поэтапно. Начнем с того, что в верхней части рисунка изображены два различных источника управляющих инструкций, направляемых системе: 1) рядовые пользователи и прикладные программы, запрашивающие или изменяющие данные; 2) администратор базы данных (database administrator — DBA) — лицо или группа лиц, ответственных за поддержку и развитие структуры, или схемы, базы данных. 1.2.1. Команды языка определения данных Относительно более простым является множество команд, поступающих от администратора базы данных (их поток изображен в правой верхней части рис. 1.1). В качестве примера рассмотрим базу данных факультета университета. Администратор может включить в ее состав таблицу (отношение), строки (кортежи) которой представляют информацию о студентах — их имена и фамилии, номера курсов и курсовые отметки. Администратор вправе ограничить множество допустимых отметок, выставляемых студентам по окончании курса, скажем, значениями А, В, С, D и F. Структура создаваемой таблицы и вводимая информация об ограничениях становятся частью схемы базы данных. Чтобы выполнить задуманное, администратор должен обладать специальными полномочиями по выполнению команд, затрагивающих схему базы данных, поскольку таковые оказывают самое серьезное влияние на структуру хранения информации. Подобные команды определения данных — их называют командами языка DDL (Data Definition Language — язык определения данных) — подвергаются лексической обработке с помощью компилятора DDL (DDL compiler) и передаются для выполнения исполняющей машине (execution engine), которая при посредничестве менеджера ресурсов (resource manager) изменяет метаданные (metadata — "данные о данных"), т.е. информацию, описывающую схему базы данных. 1.2.2. Обработка запросов Большая часть обращений к базе данных инициируется пользователями и приложениями (соответствующие потоки команд и данных изображены в левой части рис. 1.1). Подобные действия не оказывают влияния на схему базы данных, но затрагивают содержимое последней (если команда предусматривает внесение изменений) либо предполагают чтение данных (если команда содержит запрос). В разделе 1.1 на с. 32 мы уже писали о том, что такие команды оформляются с помощью языка управления данными (Data Manipulation Language — DML), или, проще говоря, языка запросов (query language). Существует множество различных языков управления данными, но самым распространенным и мощным из них является SQL, упоминавшийся нами в примере 1.1 (см. с. 34). Инструкции языка DML обрабатываются двумя отдельными подсистемами СУБД, описанными ниже. Получение ответа на запрос Запрос анализируется и оптимизируется компилятором запросов (query compiler). Сформированный компилятором план запроса (query plan), или последовательность действий, подлежащих выполнению системой с целью получения ответа на запрос, передается исполняющей машине. Исполняющая машина направляет группу запросов на получение небольших порций данных -— как правило, строк (кортежей) таблицы (отношения) — менеджеру ресурсов, который "осведомлен" об особенностях размещения информации в файлах данных (data files), содержащих таблицы, о форматах и размерах записей в этих файлах и о структурах индексных файлов (index files), обеспечивающих существенное ускорение процессов поиска запрошенных данных. 40 ГЛАВА 1. МИР БАЗ ДАННЫХ
Запросы на получение данных транслируются в адреса страниц и пересылаются менеджеру буферов (buffer manager). О роли менеджера буферов мы поговорим ниже, но здесь уместно кратко отметить, что его задачей является обращение к соответствующим порциям данных на носителях вторичных устройств хранения (обычно, дисках), где они располагаются постоянно, с последующим переносом данных в буферы, размещаемые в оперативной памяти, и наоборот. Единицами потоков обмена данными между буферами в памяти и диском являются страница или "дисковый блок". Чтобы получить информацию с диска, менеджеру буферов приходится обращаться к услугам менеджера хранения данных (storage manager), который, решая возложенные на него задачи, может вызывать команды операционной системы, но чаще всего непосредственно инициирует инструкции дискового контроллера. Обработка транзакций Запросы и другие команды языка управления данными группируются в транзакции (transactions) — процессы, которые должны выполняться атомарным образом (atomically) и изолированно (in isolation) друг от друга. Зачастую каждый отдельный запрос или операция по изменению данных является самостоятельной транзакцией. Транзакция обязана обладать свойством устойчивости (durability). Это значит, что результат каждой завершенной транзакции должен быть зафиксирован в базе данных даже в тех ситуациях, когда после окончания транзакции система по той или иной причине выходит из строя. На рис. 1.1 процессор транзакций (transaction processor) представлен в виде двух основных компонентов: 1) планировщика заданий (scheduler), или менеджера параллельных заданий (concurrency-control manager), ответственного за обеспечение атомарности и изолированности транзакций; 2) менеджера протоколирования и восстановления (logging and recovery manager), гарантирующего выполнение требования устойчивости транзакций. Указанные компоненты будут подробно рассмотрены в разделе 1.2.4 на с. 42. 1.2.3. Менеджеры буферов и хранения данных Информация, хранимая в базе данных, обычно располагается на носителях вторичных устройств хранения. Термин вторичное устройство хранения (secondary storage device), употребляемый применительно к современной компьютерной системе, обычно означает магнитный диск. Однако, чтобы выполнить любую сколько-нибудь полезную операцию над данными, необходимо перенести их в оперативную память. Задача управления размещением информации на диске и обмена ею между диском и оперативной памятью возлагается на менеджер хранения данных (storage manager). В простой системе баз данных роль менеджера хранения может быть поручена непосредственно файловой системе, обслуживаемой соответствующей операционной системой. Впрочем, из соображений обеспечения эффективности вычислений СУБД обычно (по меньшей мере, при определенных обстоятельствах) самостоятельно управляет размещением данных на дисках. В ответ на запрос со стороны менеджера буферов менеджер хранения данных определяет положение файлов на диске и получает набор блоков диска, содержащих требуемый файл или его часть. Отметим, что поверхность диска обычно разделена на дисковые блоки (disk blocks) — непрерывные участки, способные сохранять большое число байтов информации, до 212 или 214 (4096 или 16384). Менеджер буферов (buffer manager) ответствен за разбиение доступной оперативной памяти на буферы (buffers) — участки-страницы (pages), куда может быть помещено содержимое дисковых блоков. Все компоненты СУБД, обращающиеся к дисковой информации, взаимодействуют с буферами и менеджером буферов — либо непосредственно, либо при помощи исполняющей машины. Данные, требуемые компонентами системы, могут относиться к одной из следующих категорий: 1.2. ОБЗОР СТРУКТУРЫ СУБД 41
Пользователь/приложение Запросы, команды изменения4 Команды транзакций Администратор базы данных Команды DDL Компилятор запросов План запроса Менеджер транзакций ^ ^Метаданные, ^\статистика Исполняющая машина Запросы к индексам, файлам и записям Менеджер протоколирования и восстановления Менеджер ресурсов 1Данные,\ индексы,^ метаданные^ Менеджер буферов Чтение/записц страниц Менеджер хранения данных Носитель данных Компилятор DDL \ Метаданные Планировщик заданий Таблица i блокировок Рис. 1.1. Компоненты системы управления базами данных 1) собственно данные — содержимое базы данных как таковой; 2) метаданные — описание схемы, или логической структуры, базы данных, введенных ограничений и т.д.; 3) статистика — информация о свойствах данных, таких как размеры различных отношений, о вероятностных распределениях хранящихся значений и т.п., собранная СУБД; 4) индексы — структуры данных, обеспечивающие эффективный доступ к информации в базе данных. За подробными сведениями о функциональных особенностях менеджера буферов и его значении в общей структуре СУБД обращайтесь к разделу 15.7 на с. 732. 1.2.4. Обработка транзакций Обычной практикой является оформление одной или нескольких операций над базой данных в виде транзакции (transaction) — единицы работы, которая должна быть 42 ГЛАВА 1. МИР БАЗ ДАННЫХ
выполнена атомарным образом и изолированно от других транзакций. Кроме того, СУБД обязана удовлетворять требованию устойчивости транзакций: результат выполнения завершенной транзакции не должен быть утрачен ни при каких условиях. Менеджер транзакций (transaction manager) воспринимает от приложения команды транзакций (transaction commands), которые свидетельствуют о начале и завершении транзакции, а также передают информацию о предпочтениях приложения в отношении параметров транзакции (приложение, например, может отказаться от свойства атомарности транзакции). Процессор транзакций (transaction processor) выполняет функции, рассмотренные ниже. 1. Протоколирование (logging). С целью удовлетворения требования устойчивости (durability) транзакций каждое изменение в базе данных фиксируется в специальных дисковых файлах. Менеджер протоколирования (logging manager) в своей работе руководствуется одной из нескольких стратегий, призванных исключить вредные последствия системных сбоев во время выполнения транзакции, а менеджер восстановления (recovery manager) в случае возникновения подобных ситуаций способен считать протокол изменений и привести базу данных в некоторое сообразное состояние. Информация протокола изначально сохраняется в буферах; затем менеджер протоколирования в определенные моменты времени взаимодействует с менеджером буферов, дабы убедиться, что содержимое буферов действительно сохранено на диске (где данные находятся под надежной защитой в момент возможного краха системы). 2. Управление параллельными заданиями (concurrency control). Транзакции обязаны выполняться в полной изоляции друг от друга. Горькая истина, однако, заключается в том, что в реальных системах одновременно могут действовать несколько процессов-транзакций. Планировщик заданий (scheduler), или менеджер параллельных заданий (concurrency-control manager), должен обеспечить такой режим работы системы, чтобы результат выполнения отдельных перемежающихся во времени операций многочисленных транзакций оказался таким, как если бы транзакции в действительности инициировались, протекали и полностью завершались в строгой очередности, не "пересекаясь" одна с другой. Типичный планировщик заданий добивается поставленной перед ним цели, устанавливая признаки блокировки (lock) на соответствующие фрагменты содержимого базы данных. Блокировки препятствуют возможности единовременного обращения нескольких транзакций к порции данных такими способами, которые плохо согласуются друг с другом. Признаки блокировки обычно хранятся в таблице блокировок (lock table), размещаемой в оперативной памяти, как показано на рис. 1.1 (см. с. 42). Планировщик заданий воздействует на процесс выполнения запросов и других операций, запрещая исполняющей машине обращаться к блокированным порциям данных. 3. Разрешение взаимоблокировок (deadlock resolution). Поскольку транзакции состязаются за ресурсы, которые могут быть блокированы планировщиком заданий, возможно возникновение таких обстоятельств, когда ни одна из транзакций не в состоянии продолжить работу ввиду того, что ей необходим ресурс, находящийся в ведении другой транзакции. Менеджер транзакций обладает прерогативой вмешиваться в ситуацию и прерывать (откатывать — "rollback") одну или несколько транзакций, чтобы позволить остальным продолжить работу. 1.2.5. Процессор запросов Подсистема, в наибольшей степени определяющая показатели производительности СУБД, видимые, что называется невооруженным глазом, носит название процессора запросов (query processor). На рис. 1.1 (см. с. 42) процессор запросов представлен двумя компонентами, рассмотренными ниже. 1.2. ОБЗОР СТРУКТУРЫ СУБД 43
ACID: свойства транзакций Принято говорить, что правильным образом реализованные транзакции удовлетворяют "условиям ACID": • А представляет свойство "atomicity" (атомарность) — транзакция осуществляется в соответствии с принципом "все или ничего", т.е. должна быть выполнена либо вся целиком, либо не выполнена вовсе; • /служит сокращением термина "isolation" (изолированность) — процесс протекает таким образом, словно в тот же период времени других транзакций не существует; • D определяет требование под названием "durability" (устойчивость) — результат выполнения завершенной транзакции не должен быть утрачен ни при каких условиях. Оставшаяся буква аббревиатуры, С, обозначает свойство "consistency" (согласованность). Все базы данных вводят те или иные ограничения (constraints), обусловливающие особенности различных элементов данных и их взаимную согласованность (так, например, сумма бухгалтерской проводки не может быть отрицательной). Транзакции обязаны сохранять согласованность данных. О том, каким образом ограничения определяются в схеме базы данных, мы расскажем в главе 7 (см. с. 317), а вопросы, касающиеся поддержки системой требования согласованности данных, будут освещены в разделе 18.1 на с. 880. 1. Компилятор запросов (query compiler) транслирует запрос во внутренний формат системы — 1ыан запроса (query plan). Последний описывает последовательность инструкций, подлежащих выполнению. Часто инструкции плана запроса представляют собой реализации операций "реляционной алгебры" (мы расскажем о ней в разделе 5.2 на с. 205). Компилятор запросов состоит из трех основных частей: a) синтаксического анализатора запросов (query parser), создающего на основе текста запроса древовидную структуру данных; b) препроцессора запросов (query preprocessor), выполняющего семантический анализ запроса (проверку того, все ли отношения и их атрибуты, упомянутые в тексте запроса, действительно существуют) и функции преобразования дерева, построенного анализатором, в дерево алгебраических операторов, отвечающих исходному плану запроса; c) оптимизатора запросов (query optimizer), осуществляющего трансформацию плана запроса в наиболее эффективную последовательность фактических операций над данными. Компилятор запросов, принимая решение о том, какая из последовательностей операций с большей вероятностью окажется самой оптимальной по быстродействию, пользуется метаданными и статистической информацией, накопленной СУБД. Например, наличие индекса (index) — специальной структуры данных, обслуживающей процессы доступа к информации отношений посредством хранения определенных значений, которые соответствуют порциям содержимого отношения, — способно существенным образом повлиять на выбор наиболее эффективного плана. 2. Исполняющая машина (execution engine) несет ответственность за осуществление каждой из операций, предусмотренных выбранным планом запроса. В процессе своей работы она взаимодействует с большинством других компонентов СУБД — либо напрямую, либо при посредничестве буферов данных. Чтобы получить возможность обрабатывать данные, исполняющая машина обязана считать их с носителя и перенести в буферы. При этом ей необходимо "общаться" с планировщиком заданий, чтобы избежать опасности обращения к блокиро- 44 ГЛАВА 1. МИР БАЗ ДАННЫХ
ванным порциям информации, а также с менеджером протоколирования, обеспечивающим гарантии того, что все изменения, внесенные в базу данных, должным образом зафиксированы в протоколе. 1.3. Обзор технологий СУБД Вопросы, имеющие отношение к проблематике создания систем баз данных, можно поделить на три категории, описанные ниже. 1. Проектирование баз данных. Как разрабатывать полезные базы данных? Информация каких разновидностей должна быть включена в базу данных? Как надлежит структурировать данные? Какие предположения следует выдвигать относительно типов и значений элементов данных? Как обеспечить взаимосвязь этих элементов? 2. Программирование приложений баз данных. Каковы средства представления запросов и других операций над содержимым базы данных? Каким образом следует использовать другие возможности СУБД, такие как транзакции или ограничения, в конкретном программном приложении? Как соотносится и сочетается программирование баз данных с программированием обычных приложений? 3. Реализация систем баз данных. Что необходимо сделать, чтобы реализовать конкретную СУБД, включая и такие ее функции, как обработка запросов, управление транзакциями и эффективная организация хранения данных? 1.3.1. Проектирование баз данных В главе 2 на с. 51 мы рассмотрим абстракцию процесса проектирования базы данных, называемую ER-моделью, или моделью "сущность—связь" (entity-relationship model). Глава 3 на с. 87 познакомит вас с реляционной моделью (relational model), лежащей в основе большинства наиболее распространенных коммерческих СУБД (некоторые особенности реляционной модели мы кратко освещали в разделе 1.1.2 на с. 34). Мы покажем, как конкретный образец ER-модели транслируется в соответствующую реляционную схему базы данных. Позже, в разделе 6.6 на с. 296, будут изложены сведения о том, как реляционная схема базы данных может быть описана средствами подмножества языка SQL, которое имеет отношение к определению данных. В главе 3 рассматривается и понятие зависимостей (dependencies), формально выражающее предположения о взаимоотношениях кортежей отношения. Использование аппарата определения зависимостей позволяет улучшить качество проекта реляционной базы данных в ходе процесса, известного как нормализация (normalization) отношений. В главе 4 на с. 149 мы изложим сведения об объектно-ориентированных подходах к проектированию баз данных. Здесь рассмотрены особенности языка ODL (Object Definition Language — язык определения объектов), позволяющего описывать базы данных высокоуровневыми объектно-ориентированными средствами. Мы расскажем также о способах сочетания инструментов объектно-ориентированного проектирования с реляционным моделированием, что подведет вас к пониманию "объектно-реляционной" (object-relational) парадигмы. В главе 4 затрагиваются и вопросы использования "полуструктурированных" данных (semistructured data) — особенно гибкой модели представления информации — и современной реализации этой модели в виде языка описания документов XML. 1.3.2. Программирование приложений баз данных В главах 5—10 на с. 203—487 излагаются основы программирования приложений, ориентированных на использование баз данных. Главу 5 мы начнем с рассмотрения абстрактной трактовки запросов в рамках реляционной модели, введя семейство операторов, применяемых в контексте отношения, которые составляют существо реляционной алгебры (relational algebra). 1.3. ОБЗОР ТЕХНОЛОГИЙ СУБД 45
Как создаются индексы Вы, читатель, возможно, уже изучали курс структур данных и осведомлены о том, что хеш-таблицы (hash tables) — это весьма многообещающее средство создания индексов. В ранних СУБД хеш-таблицы использовались особенно интенсивно. Но сегодня наиболее распространенной структурой данных, применяемой для создания индексов, является В-дерево (B-tree; буква В служит сокращением термина "balanced" — сбалансированное). Структура В-дерева представляет собой обобщение так называемого сбалансированного бинарного дерева поиска (balanced binary search tree): если вершина бинарного дерева обладает, самое большее, двумя дочерними вершинами, вершина В-дерева может иметь произвольное число дочерних вершин. Если принять во внимание, что данные В-дерева обычно размещаются на диске, а не в оперативной памяти, структура проектируется таким образом, чтобы информация о каждой ее вершине занимала отдельный блок диска. Поскольку обычный размер блока достигает 212 (4096) байт, в одном блоке вполне возможно хранить данные о сотнях дочерних вершин дерева. Таким образом, при поиске данных по В-дереву необходимость обращения к более чем нескольким блокам возникает сравнительно редко. Трудоемкость дисковых операций пропорциональна количеству запрашиваемых блоков диска. Поэтому поиск по В-дереву, затрагивающий, как правило, всего несколько блоков диска, существенно более эффективен, нежели бинарный поиск, в процессе выполнения которого приходится посещать вершины дерева, относящиеся к многим различным блокам. Указанное различие между деревьями бинарного поиска и В-деревьями — это один из характерных примеров того, что структуры данных, наиболее подходящие для хранения данных в оперативной памяти, не обязательно столь же эффективны, если данные располагаются на диске. Главы 6—8 на с. 249—418 посвящены технологиям программирования на языке SQL. Как мы говорили прежде, SQL преобладает на современном рынке языков запросов. Глава 6 познакомит вас с базовыми понятиями, касающимися представления запросов и схем баз данных на языке SQL. Глава 7 на с. 317 охватывает аспекты SQL, связанные с заданием ограничений (constraints) и построением триггеров (triggers). Глава 8 на с. 349 дает ответы на некоторые более сложные вопросы применения SQL. Простейшая модель программирования на SQL предусматривает обособленное употребление элементов "чистого" интерфейса языка, но в большинстве реальных ситуаций фрагменты SQL-кода используются в контексте крупных программных проектов, написанных на традиционных языках, таких как С. В главе 8 мы расскажем о том, как правильно применять выражения SQL внутри кода других программ, а также переносить информацию из базы данных в переменные программы и наоборот. В той же главе приводятся сведения об использовании в прикладных программах механизмов поддержки транзакций, подключения клиентов к серверам и авторизации доступа к информации со стороны пользователей, не являющихся владельцами объектов базы данных. В главе 9 на с. 419 мы сосредоточим внимание на двух направлениях объектно- ориентированного программирования приложений баз данных. Первое из них связано с применением языка OQL (Object Query Language — язык объектных запросов), появление которого можно рассматривать как тенденцию к пополнению СН-4- и других объектно-ориентированных языков общего назначения инструментами, удовлетворяющими требованиям концепции высокоуровневого программирования с ориентацией на использование баз данных. Второе направление, имеющее отношение к недавно принятым нововведениям, которые касаются объектно-ориентированных "расширений" стандарта SQL, выглядит, с другой стороны, как попытка обеспечения совместимости реляционной парадигмы и языка SQL с моделью объектно- ориентированного программирования. 46 ГЛАВА 1. МИР БАЗ ДАННЫХ
Наконец, в главе 10 на с. 453 мы вновь вернемся к теме абстрактных языков запросов, рассмотрение которой начато в главе 5 (см. с. 203). Мы расскажем о логических языках запросов (logical query languages) и об использовании их с целью расширения возможностей современных диалектов SQL. 1.3.3. Реализация систем баз данных Третья часть книги посвящена технологиям реализации СУБД, которые можно условно поделить на три категории, перечисленные ниже. 1. Управление процессами хранения данных— использование вторичных устройств хранения для обеспечения эффективного доступа к информации. 2. Обработка запросов — оптимальное обслуживание запросов, оформленных средствами высокоуровневых языков, подобных SQL. 3. Управление транзакциями — поддержка транзакций, обеспечивающая выполнение условий ACID (см. раздел 1.2.4 на с. 42). Каждой из названных тем отведено несколько глав книги. Управление процессами хранения данных В главе 11 на с. 489 рассматривается иерархия устройств памяти. Поскольку вторичные устройства хранения данных, в частности диски, являются наиболее важным средством сбережения информации в рамках СУБД, мы уделим повышенное внимание способам хранения данных на диске и доступа к ним. Вашему вниманию будет предложена "блоковая модель" размещения данных на диске, оказывающая влияние почти на все стороны "деятельности" СУБД. В главе 12 на с. 549 обсуждаются вопросы хранения отдельных элементов данных — отношений, кортежей, значений атрибутов и равнозначных им сущностей, принятых в других моделях представления информации, —- в соответствии с требованиями блоковой модели дисковых данных. Далее мы уделим внимание основным структурам данных, находящим применение при конструировании индексов. Уместно напомнить, что индекс — это структура данных, обеспечивающая эффективный доступ к информации на диске. Глава 13 на с. 583 содержит сведения о важных одномерных (one-dimensional) индексных структурах данных — последовательных файлах (sequential files), В-деревьях (B-trees) и хеш-таблицах (hash tables). Подобные индексы широко используются в СУБД для оптимизации запросов, предполагающих поиск группы кортежей, которые удовлетворяют заданному значению некоторого атрибута. В-деревья применяются также для доступа к содержимому отношения, отсортированного в порядке убывания или возрастания определенного атрибута. В главе 14 на с. 637 рассматриваются многомерные (multidimensional) индексы, представляющие собой структуры данных, используемые при создании специализированных разновидностей баз данных (например, предназначенных для хранения географической информации), запросы к которым обычно предполагают поиск элементов данных, отвечающих нескольким критериям. Подобные индексные структуры хорошо приспособлены для удовлетворения сложных SQL- запросов, в которых ограничения накладываются1 на целую группу атрибутов, и некоторые из таких структур уже обрели поддержку со стороны ряда коммерческих СУБД. Обработка запросов В главе 15 на с. 683 излагаются сведения о процессах выполнения запросов. Мы представим вашему вниманию большое количество алгоритмов, позволяющих эффективно реализовать множество операций реляционной алгебры. Алгоритмы спроектированы таким образом, чтобы оптимизировать действия с дисковыми данными, и в некоторых случаях довольно существенно отличаются от аналогов, предназначенных для обработки информации, размещенной в оперативной памяти. 1.3. ОБЗОР ТЕХНОЛОГИЙ СУБД 47
Глава 16 на с. 753 содержит сведения об архитектуре компилятора запросов (query compiler) и оптимизатора запросов (query optimizer). Сначала мы рассмотрим процессы лексического анализа запросов и их семантической проверки. Затем будет рассказано о преобразовании запросов SQL в наборы инструкций реляционной алгебры и критериях выбора логического плана запроса (logical query plan), т.е. алгебраического выражения, которое представляет определенные операции, подлежащие выполнению, и необходимые ограничения, затрагивающие порядок следования операций. Наконец, мы обсудим вопросы конструирования физического плана запроса (physical query plan), который, учитывая конкретный порядок выполнения операций, задает алгоритм реализации каждой операции. Управление транзакциями В главе 17 на с. 837 мы ответим на вопросы, каким образом СУБД обеспечивает устойчивость (durability) транзакций. Основной подход к решению проблемы связан с ведением протокола, регистрирующего все изменения в базе данных. При сбое системы (возникающем, например, из-за отключения электропитания) информация, расположенная в оперативной памяти, но не зафиксированная на диске, будет утрачена. Поэтому весьма важно, чтобы операции по перемещению данных из буферов памяти на диск выполнялись своевременно и в соответствующем порядке и чтобы изменения, затрагивающие непосредственно базу данных и протокол, вносились синхронно. Существует несколько стратегий ведения протоколов, но каждый из них каким-либо образом ограничивает свободу действий над данными. В главе 18 на с. 879 мы затронем тему управления параллельным доступом к данным, способного обеспечить поддержку свойств атомарности (atomicity) и изолированности (isolation) транзакций. Транзакции представляются в виде последовательностей операций чтения и записи элементов содержимого базы данных. Основное внимание в главе уделено тому, как следует обращаться с блокировками (locks) элементов данных. Здесь рассмотрены различные типы блокировок и допустимые методы установки блокировок параллельными транзакциями и освобождения их. Помимо того, мы предоставим сведения о способах обеспечения свойств атомарности и изолированности транзакций без использования механизмов блокирования. Глава 19 на с. 949 завершает обсуждение проблем обработки транзакций. Мы расскажем о взаимном соотношении требований протоколирования, рассмотренных в главе 17 на с. 837, и условий, обеспечивающих параллельное выполнение транзакций (этой теме посвящена глава 18 на с. 879). Особое внимание мы уделим технологии разрешения взаимоблокировок (deadlock resolution) — одной из важнейших функций менеджера транзакций. В главе 19 также изложены сведения об управлении параллельными транзакциями в условиях распределенной вычислительной среды (distributed environment) и инструментах обслуживания длинных ("long") транзакций, продолжительность выполнения которых измеряется часами или даже сутками вместо привычных секунд или долей секунды. Длинная транзакция не в состоянии блокировать элементы данных, не причиняя ущерба интересам других потенциальных пользователей тех же данных, что приводит к необходимости переосмысления подходов к проектированию приложений, предусматривающих применение транзакций. 1.3.4. Интеграция информации Немалая часть современных исследований в сфере технологий баз данных направлена на обеспечение возможностей сочетания в единое целое различных источников данных (data sources), среди которых могут быть как привычные базы данных, так и информационные ресурсы, не относящиеся к ведению СУБД. Подобные проблемы кратко освещались в разделе 1.1.7 на с. 38. Заключительная, 20-я, глава (см. с. 1003) содержит сведения о важнейших аспектах интеграции данных. Здесь мы расскажем об основных режимах интеграции, включая использование транслированных и объединенных копий источников информации в рамках хранилищ данных (data warehouses) 48 ГЛАВА 1. МИР БАЗ ДАННЫХ
и создание виртуальных баз данных (virtual databases) на основе фупп источников информации, которое выполняется средствами профаммных компонентов, называемых медиаторами (mediators). 1.4. Резюме ♦ Системы управления базами данных. СУБД отличаются способностью к эффективному выполнению операций обработки больших массивов информации, хранимых на протяжении длительных периодов времени. В СУБД реализована поддержка мощных языков запросов и устойчивых транзакций, которые могут выполняться атомарным образом и независимо от других параллельных транзакций. ♦ СУБД и файловые системы. Традиционные файловые системы не являются полноценной альтернативой СУБД, поскольку они не в состоянии обеспечить реализацию высокопроизводительных функций поиска, возможность эффективной модификации небольших элементов информации, поддержку сложных запросов, гибкую буферизацию требуемых данных в оперативной памяти и атомарное и изолированное выполнение транзакций. ♦ Системы реляционных баз данных. Большинство современных СУБД основано на реляционной модели представления данных, в соответствии с которой информация организуется в виде таблиц. В подобных системах в качестве языка запросов наиболее часто применяется SQL. ♦ Вторичные и третичные устройства хранения данных. Крупные базы данных размещают на вторичных устройствах хранения (как правило, дисках). Наиболее обширные базы данных требуют использования третичных устройств хранения, которые на несколько порядков более емки, но во много раз менее производительны. ♦ Системы "клиент/сервер". СУБД обычно поддерживают архитектуру "клиент/сервер", предусматривающую размещение основных компонентов системы на сервере и предоставляющую пользователю необходимый клиентский интерфейс. ♦ Языки баз данных. Существует ряд языков или языковых компонентов для определения структур данных (языки определения данных) и описания запросов и инструкций по изменению элементов информации (языки управления данными). ♦ Компоненты СУБД. К числу наиболее важных компонентов системы управления базами данных относятся менеджер хранения данных, процессор запросов и менеджер транзакций. ♦ Менеджер хранения данных — компонент СУБД, ответственный за размещение и хранение на диске основной информации базы данных, метаданных (сведений о схеме, или логической структуре, данных), индексов (структур, ускоряющих доступ к информации) и протоколов (записей, фиксирующих изменения в базе данных). Важнейшей частью подсистемы хранения данных является менеджер буферов, обеспечивающий перенос порций дисковой информации в буферы оперативной памяти и обратно. ♦ Процессор запросов — элемент СУБД, осуществляющий лексический и семантический разбор запроса, его оптимизацию, выбор соответствующего плана запроса и последующее выполнение плана применительно к реальным данным. ♦ Менеджер транзакций — часть СУБД, реализующая функции ведения протокола изменений с целью обеспечения возможности восстановления данных после сбоев системы, а также управляющая процессами протекания параллельных транзакций и гарантирующая их атомарность (транзакция выполняется либо целиком и до конца, либо не выполняется вовсе) и изолированность (каждая транзакция обслуживается таким образом, словно других конкурирующих транзакций не существует). 1.4. РЕЗЮМЕ 49
♦ Будущее систем баз данных. Основные тенденции в развитии СУБД связаны с поддержкой сверхбольших объектов мультимедиа-данных (таких как видео- или аудиозаписи) и интеграцией информации из многих разнородных источников в единую базу данных. 1.5. Литература Сегодня, в эпоху существования электронных библиографических каталогов, открытых для доступа с помощью средств Internet и содержащих, в частности, ссылки на все свежие информационные источники, относящиеся к сфере технологий баз данных, совершенно нецелесообразно пытаться привести на страницах книги исчерпывающий список литературы, достойной цитирования. Здесь уместно упомянуть только те печатные работы, которые важны с точки зрения исторической перспективы, указать основные гиперссылки на соответствующие ресурсы Web и отметить некоторые полезные обзоры. Один из каталогов, охватывающих библиографию результатов исследований по проблемам управления базами данных, в свое время был создан и содержится в актуальном состоянии Михелем Леем (Michael Ley) [5]. Альф- Кристиан Ахилл (Alf-Christian Achilles) поддерживает каталог каталогов информации, относящихся к предметной области систем баз данных [1]. Хотя существенные успехи были достигнуты при реализации многих проектов СУБД, наибольшую известность получили два из них — System R, осуществленный в исследовательском центре IBM Almaden Research Center [3], и INGRES, выполненный в Калифорнийском университете в Беркли [7]. Каждый из проектов предусматривал создание систем реляционных баз данных и способствовал становлению этой разновидности систем в качестве главного участника рынка технологий баз данных. Большое количество результатов исследований нашло отражение в обзоре [6]. Одним из самых свежих в серии отчетов по результатам научных изысканий и технологических разработок в области СУБД является отчет [4], который содержит ссылки на многие более ранние информационные источники подобного рода. За дополнительными сведениями по теории систем баз данных, не нашедшими отражения в литературе, названной выше, обращайтесь к работам [2], [8] и [9]. 1. http://liinwww.ira.uka.de/bibliography/Database. 2. Abiteboul S., Hull R., and Vianu V. Foundations of Databases, Addison-Wesley, Reading, MA, 1995. 3. Astrahan M.M. et al. System R: a relational approach to database management, ACM Trans, on Database Systems, 1:2 (1976), p. 97-137. 4. Bernstein P.A. et al. The Asilomar report on database research (http://www.acm.org/sigmod/record/issues/9812/asilomar.html). 5. http://www.informatik.uni-trier.de/-ley/db/index.html. Адрес зеркального сайта: http://www.acm.org/sigmod/dblp/db/index.html. 6. Stonebraker M., Hellerstein J.M. (eds.) Readings in Database Systems, Morgan-Kaufmann, San Francisco, 1998. 7. Stonebraker M., Wong E., Kreps P., and Held G. The design and implementation of INGRES, ACM Trans, on Database Systems, 1:3 (1976), p. 189-222. 8. Ullman J.D. Principles of Database and Knowledge-Base Systems, Volume I, Computer Science Press, New York, 1988. 9. Ullman J.D. Principles of Database and Knowledge-Base Systems, Volume II, Computer Science Press, New York, 1989. 50 ГЛАВА 1. МИР БАЗ ДАННЫХ
Глава 2 Модель данных "сущность-связь" Процесс проектирования базы данных начинается с анализа того, какого рода информация должна быть в ней представлена и каковы взаимосвязи между элементами этой информации. Структура, или схема (schema), базы данных определяется средствами различных языков или систем обозначений, пригодных для описания проектов. По завершении этапа уточнений и согласований проект преобразуется в форму, которая может быть воспринята СУБД, и база данных начинает собственную жизнь. В книге рассматривается несколько систем описания проектов баз данных. Эта глава посвящена изучению ER-модели, или модели "сущность—связь" (entity-relationship model), ставшей традиционной и наиболее популярной. По своей природе модель является графической: прямоугольники отображают элементы данных, а линии (возможно, со стрелками) указывают на связи между ними. В главе 3 на с. 87 мы сосредоточим внимание на реляционной модели (relational model), представляющей данные об окружающем мире в виде набора таблиц. Множество структур, которые могут быть описаны средствами реляционной модели, разумеется, ограниченно, но этот факт не способен преуменьшить ее значение: модель чрезвычайно проста и плодотворна и является основой большинства современных коммерческих СУБД. Процесс проектирования базы данных обычно начинается с разработки ее схемы посредством инструментов, предлагаемых ER-моделью либо некоторой объектной моделью, с последующей трансляцией схемы в реляционную модель, подлежащую физической реализации. Альтернативные модели описания данных рассмотрены в главе 4 на с. 149. Раздел 4.2 на с. 152 предлагает введение в язык ODL (Object Definition Language — язык определения объектов) — стандарт средств описания объектно-ориентированных баз данных. Затем мы проследим, как идеи объектно-ориентированного проектирования, сочетаясь с реляционной моделью представления данных, трансформируются в модель, называемую объектно-реляционной (object-relational model). В разделе 4.6 на с. 187 описан другой подход к моделированию, основанный на концепции "полуструктурированных" данных (semistructured data). Последняя предоставляет неограниченную свободу выбора структурных форм, в которые может быть облечена информация. В разделе 4.7 на с. 192 мы обсудим стандарт XML, позволяющий моделировать данные в виде иерархически структурированных документов, используя "тэги" (подобные тэгам HTML), которые определяют роль и функции тексто-
вых элементов. XML представляет собой блестящее практическое воплощение модели "полуструктурированных" данных. Рис. 2.1 иллюстрирует, каким образом ER-модели используются при проектировании баз данных. Обычно принято начинать с изучения понятий и описаний информации, подлежащей моделированию, а затем пытаться отобразить их в рамках ER-модели. Затем ЕЯ- проект преобразуется в реляционную схему, выраженную средствами языка определения данных для конкретной СУБД. В большинстве случаев СУБД основываются на реляционной модели. Если дело обстоит именно так, в ходе довольно прямолинейного процесса, детали которого мы обсудим в разделе 3.2 на с. 91, абстракция обретает конкретную осязаемую форму, называемую реляционной схемой базы данных (relational database schema). Понятия и ER- Реляционная Реляционная описания проект схема СУБД Рис. 2.1. Процесс моделирования и реализации базы данных Важно отметить, что в то время как в СУБД подчас находят применение модели, отличные от реляционных или объектно-реляционных, систем баз данных, способных реализовать ER-модель непосредственно, попросту не существует. Причина заключается в том, что эта модель недостаточно удовлетворительно согласовывается с эффективными структурами данных, на основе которых должна создаваться "реальная" база данных. 2.1. Элементы ER-модели Наиболее распространенным средством абстрактного представления структур баз данных является ER-модель, или модель "сущность—связь" (entity-relationship model). В ER-модели структура данных отображается графически, в виде диаграммы сущностей и связей (entity-relationship diagram), состоящей из элементов трех основных типов: a) множеств сущностей; b) атрибутов; c) связей. Ниже подробно рассмотрен каждый из типов элементов диаграммы сущностей и связей. 2.1.1. Множества сущностей Сущность (entity) — это абстрактный объект определенного вида. Набор однородных сущностей образует множество сущностей (entity set). Понятие сущности обладает определенным сходством с понятием объекта (object) (если трактовать последнее так, как это принято делать в объектно-ориентированном проектировании). Примерно таким же образом соотносятся множество сущностей и класс объектов. ER-модель, однако, отображает статические объекты — она имеет дело со структурами данных, но не с операциями над данными. Поэтому предполагать, что в ней могут содержаться описания неких "методов", соответствующих множествам сущностей и аналогичных методам класса, нет никаких оснований. Пример 2.1. На протяжении многих глав книги мы будем рассматривать и развивать пример, касающийся базы данных о кинофильмах, участвующих в них актерах, студиях, осуществивших съемку, и т.п. Каждый из фильмов представляет собой сущность, а коллекция всех фильмов образует множество сущностей. Актеры, снимающиеся в фильмах, также являются сущностями, но другого вида, и их множество — это множество сущностей. Киностудия — это сущность еще одного вида, а перечень киностудий формирует третье множество сущностей, которое будет использоваться в дальнейших примерах. □ 52 ГЛАВА 2. МОДЕЛЬ ДАННЫХ "СУЩНОСТЬ-СВЯЗЬ"
Разновидности ER-модели В некоторых версиях ER-модели атрибуты могут относиться к следующим типам: 1) атомарный, как в версии, рассматриваемой нами; 2) "struct", как в языке С, или кортеж с фиксированным числом атомарных компонентов; 3) множество значений одного типа — атомарного либо "struct". Например, в качестве типа атрибута в подобной модели может быть задано множество пар, каждая из которых состоит из целого числа и строки. 2.1.2. Атрибуты Множеству сущностей отвечает набор атрибутов (attributes), являющихся свойствами сущностей множества. Например, множеству сущностей Movies ("кинофильмы") могут быть поставлены в соответствие такие атрибуты, как title ("название") и length ("продолжительность" — значение периода времени воспроизведения, выраженное в минутах). В версии ER-модели, рассматриваемой в этой книге, мы предполагаем, что атрибуты представляют собой атомарные значения (например, строки, целые или вещественные числа и т.д.). Существуют и такие варианты модели, в которых понятие типа атрибута трактуется иным образом (см. врезку "Разновидности ER- модели", приведенную выше). 2.1.3. Связи Связи (relationships) — это соединения между двумя или большим числом множеств сущностей. Если, например, Movies ("кинофильмы") и Stars ("актеры") — это два множества сущностей, вполне закономерно наличие связи Stars-in ("актеры- участники", снявшиеся в фильме), которая соединяет множества сущностей Movies и Stars: сущность т множества Movies соединена с сущностью s множества Stars посредством связи Stars-in, если актер s снялся в фильме т. Хотя наиболее распространена разновидность бинарных связей (binary relationships), соединяющих два множества сущностей, ER-модель допускает наличие связей, охватывающих произвольное количество множеств сущностей. Обсуждение вопросов, касающихся многосторонних связей (multiway relationships), мы отложим до раздела 2.1.7 на с. 56. 2.1.4. Диаграммы сущностей и связей Диаграмма сущностей и связей (entity—relationship diagram), или ER-диаграмма (ER-diagram), — это графическое представление множеств сущностей, их атрибутов и связей. Элементы названных видов описываются вершинами графа, и для задания принадлежности элемента к определенному виду используется специальная геометрическая фигура: • прямоугольник — для множеств сущностей; • овал — для атрибутов; • ромб — для связей. Ребра графа соединяют множества сущностей с атрибутами и служат для представления связей между множествами сущностей. Пример 2.2. На рис. 2.2 приведена ER-диаграмма, представляющая структуру простой базы данных, содержащей информацию о кинофильмах. В составе диафаммы имеется три множества сущностей: Movies ("кинофильмы"), Stars ("актеры") и Studios ("киностудии"). 2.1. ЭЛЕМЕНТЫ ER-МОДЕЛИ 53
Множество сущностей Movies обладает четырьмя атрибутами: title ("название"), year ("год производства"), length ("продолжительность") и film Type ("тип пленки") — "color" ("цветная") или "blackAndWhite" ("черно-белая"). Два других множества сущностей, Stars и Studios, содержат по паре однотипных атрибутов, пате ("имя" или "название") и address ("адрес"), смысл которых вполне очевиден без дополнительных разъяснений. На диаграмме представлены две связи, описанные ниже. 1. Stars-in ("актеры-участники", снявшиеся в фильме) — это связь, соединяющая каждую сущность-"кинофильм" с сущностями-"актерами", принимавшими участие в съемках фильма. Связь Stars-in, рассматриваемая в противоположном направлении, в свою очередь соединяет актеров с кинофильмами. 2. Связь Owns ("владеет") соединяет каждую сущность-"кинофильм" с сущностью-"студией", выпустившей фильм и владеющей правами на него. Стрелка, задающая направление от связи Owns к множеству сущностей Studios, свидетельствует о том, чго каждый фильм является собственностью одной и только одной киностудии. Подобные ограничения уникальности (uniqueness constraints) будут рассмотрены в разделе 2.1.6 на с. 55. Рис. 2.2. Диаграмма сущностей и связей для базы данных о кинофильмах 2.1.5. Экземпляры ER-диаграммы ER-диаграммы представляют собой инструмент описания схем (schemata), или структур, баз данных. Базу данных, соответствующую определенной ER-диаграмме и содержащую конкретный набор данных, принято называть экземпляром базы данных (database instance). Каждому множеству сущностей в экземпляре базы данных отвечает некоторый частный конечный набор сущностей, а каждая из таких сущностей обладает определенными значениями каждого из атрибутов. Уместно отметить, что информация о сущностях, атрибутах и связях носит строго абстрактный характер: содержимое ER-модели не может быть сохранено в базе данных непосредственно. Однако представление о том, что такие данные будто бы реально существуют, помогает на начальной стадии проекта — пока мы не перейдем к отношениям и структуры данных не приобретут физическую форму. 54 ГЛАВА 2. МОДЕЛЬ ДАННЫХ "СУЩНОСТЬ-СВЯЗЬ1
Экземпляр базы данных включает также определенные экземпляры связей, описываемых диаграммой. Связи R, которая соединяет п множеств сущностей Еь Е2,..., Еп, соответствует экземпляр, состоящий из конечного множества списков (еи еъ ..., еп), где каждый элемент <?, выбран из числа сущностей, присутствующих в текущем экземпляре множества сущностей £,. Мы говорим, что элементы каждого из таких списков, охватывающих п сущностей, "соединены" посредством связи R. Указанное множество списков называют множеством данных связи (relationship set) для текущего экземпляра связи R. Зачастую оказывается полезным представлять множество данных связи в виде таблицы. Столбцы этой таблицы озаглавлены наименованиями множеств сущностей, охватываемых связью, а каждому списку соединенных сущностей отводится одна строка таблицы. Пример 2.3. Экземпляр связи Stars-in ("актеры-участники") легко описать таблицей пар данных, которая может иметь следующий вид: Movies Stars Basic Instinct Sharon Stone Total Recall Arnold Schwarzenegger Total Recall Sharon Stone Члены множества данных связи — это строки таблицы. Например, ("Basic Instinct", "Sharon Stone") представляет собой кортеж множества данных для текущего экземпляра связи Stars-in. □ 2.1.6. Множественность бинарных связей Бинарная связь (binary relationship) в общем случае способна соединять любой член одного множества сущностей с любым членом другого множества сущностей. Однако весьма распространены ситуации, в которых свойство "множественности" связи некоторым образом ограничивается. Предположим, что R — связь, соединяющая множества сущностей Е и F. Тогда возможно выполнение одного из нескольких условий, перечисленных ниже. • Если каждый член множества Е посредством связи R может быть соединен не более чем с одним членом F, принято говорить, что R представляет связь типа "многие к одному" (many-one relationship), направленную от Е к F. В этом случае каждая сущность множества /'допускает соединение с многими членами Е. Если же член F посредством связи R может быть соединен не более чем с одним членом Е, мы говорим, что R — это связь "многие к одному", направленная от F к Е (или, что то же самое, связь типа "один ка многим"(one-many relationship), направленная от Е к F). • Если связь R в обоих направлениях, от Е к F и от F к Е, относится к типу "многие к одному", говорят, что R — это связь типа "один к одному'' (one-one relationship). В этом случае каждый элемент одного множества сущностей допускает соединение не более чем с одним элементом другого множества сущностей. • Если связь R ни в одном из направлений — ни от Е к F и ни от F к Е — не относится к типу "многие к одному", имеет место связь типа "многие ко многим " (many-many relationship). Как мы уже отмечали в примере 2.2 (см. с. 53), стрелки в ER-диаграмме используются для отображения факта множественности связей. Если связь относится к типу "многие к одному" и соединяет множество сущностей Е с множеством сущностей F, она отображается в виде стрелки, направленной к F. Стрелка указывает, что каждая из 2.1. ЭЛЕМЕНТЫ ER-МОДЕЛИ 55
сущностей множества Е связана не более чем с одной сущностью множества F. Если при этом линия не снабжена противоположной стрелкой, обращенной к Е, сущность множества F допускает связь со многими сущностями множества Е. Пример 2.4. Если следовать рассмотренной логике, связь типа "один к одному" между множествами сущностей Е и F должна представляться на диаграмме двунаправленной стрелкой, один конец которой обращен в сторону множества Е, а другой — в сторону F. На рис. 2.3 показаны два множества сущностей, Studios ("киностудии") и Presidents ("президенты"), соединенные связью Runs ("возглавляет") (атрибуты сущностей для краткости опущены). Уместно предположить, что каждый президент вправе руководить только одной студией, а каждая студия может возглавляться только одним президентом. Поэтому связь Runs следует отнести к типу "один к одному" и соединить на диаграмме с множествами сущностей Studios и Presidents посредством двух стрелок, по одной на каждое множество (так, как показано на рис. 2.3). Studios Runs Presidents Рис. 2.3. Связь типа "один к одному" Следует помнить: стрелка означает, что в связи участвует "не более чем один" элемент множества сущностей, на которое она указывает. При этом обязательное наличие такого элемента в составе множества не гарантируется. Рассматривая диафамму рис. 2.3, мы вправе полагать, что некий "президент" обязательно связан с определенной студией — иначе на каком основании он мог бы величать себя президентом? Однако студия в какой-то период времени может обходиться без руководителя, так что стрелка, направленная от Runs к Presidents, на самом деле означает именно "не более чем один", но не "в точности один". Указанное различие мы проясним позже, в разделе 2.3.6 на с. 79. □ 2.1.7. Многосторонние связи ER-модели вполне по силам отображать связи, охватывающие более двух множеств сущностей. В реальных ситуациях тернарные связи (ternary relationships), соединяющие три множества, или связи, представляющие взаимоотношения еще большего числа множеств сущностей, сравнительно редки, но иногда они все-таки находят применение, помогая воссоздать в модели истинное положение вещей. Многосторонние связи (multiway relationships) отображаются на ER-диафамме линиями, соединяющими ромб связи с каждым из соответствующих прямоугольников множеств сущностей. Пример 2.5. На рис. 2.4 изображена связь Contracts ("контракты"), которая соединяет между собой множества сущностей Studios ("киностудии"), Stars ("актеры") и Movies ("кинофильмы"). Связь отображает факт заключения контракта между киностудией и определенным актером, обязующимся принять участие в съемках конкретного кинофильма. Значение некоторой связи в ER-модели, вообще говоря, можно воспринимать в виде соответствующего множества кортежей, компонентами которых являются Рис. 2.4. Тернарная связь 56 ГЛАВА 2. МОДЕЛЬ ДАННЫХ "СУЩНОСТЬ-СВЯЗЬ"
Взаимоотношения типов связей Следует отметить, что связь типа "многие к одному" является частным случаем связи типа "многие ко многим", а связь "один к одному" — это частный случай связи "многие к одному". Другими словами, любое свойство связей "многие ко многим" характерно и для связей "многие к одному", а некоторое свойство связей "многие к одному" сохраняется в силе для связей "один к одному". Например, структура данных, представляющая связь "многие к одному", способна адекватно отображать связи "один к одному", хотя в общем случае она непригодна для поддержки связей типа "многие ко многим". сущности из множеств, соединяемых этой связью (мы говорили об этом в разделе 2.1.5 на с. 54). Таким образом, связь Contracts может быть описана набором кортежей вида (studio, star, movie). В многосторонних связях стрелка, обращенная к некоему множеству сущностей Е, означает следующее: если мы выберем по одной сущности из всех остальных множеств сущностей, охватываемых связью, эти сущности могут быть связаны не более чем с одним элементом множества Е. (Обратите внимание, что это правило является обобщением того, которое относится к бинарным связям типа "многие к одному".) На рис. 2.4 стрелка направлена к множеству сущностей Studios, свидетельствуя о том, что для каждой пары актеров и кинофильмов существует только одна студия, с которой этот актер заключил контракт на участие в съемках определенного кинофильма. Однако стрелки, которые были бы обращены к множествам сущностей Stars и Movies, не заданы: любая студия вправе пригласить для участия в фильме несколько актеров, а любой актер может быть связан со студией контрактом, предусматривающим участие в съемках нескольких кинофильмов. □ 2.1.8. Связи и роли Вполне вероятна ситуация, когда одно и то же множество сущностей упоминается в контексте единственной связи многократно. Если дело обстоит именно так, в ER- диаграмме задается столько линий, соединяющих связь с множеством сущностей, сколько требуется. Каждая линия, направленная к множеству сущностей, представляет отдельную роль (role), в которой множество выступает в конкретном случае. Линии, соединяющие связь и множество сущностей, принято обозначать текстовыми метками, описывающими определенные роли. Пример 2.6. На рис. 2.5 изображена связь Sequel-of ("продолжение кинофильма"), соединяющая множество сущностей Movies Orw'nal ("кинофильмы") само с собой. Каждый конкретный экземпляр связи соединяет два кинофильма, один из которых служит продолжением другого. Чтобы различить два фильма, участвующих в связи, одна из ее линий помечена ролью Original ("исходный"), а другая — Sequel ("продолжение"). Мы подразумеваем, что некий фильм может иметь несколько продолжений, но для каждого продолжения существует только один "исходный" фильм. Таким образом, Рис. 2.5. Связь и ее роли связь Sequel-of, соединяющая фильмы Sequel с фильмами Original, относится к типу "многие к одному" (этот факт на диаграмме рис. 2.5 отмечен стрелкой). □ 2.1. ЭЛЕМЕНТЫ ER-МОДЕЛИ 57
Стрелки в многосторонних связях Если связь охватывает три или более множеств сущностей, для адекватного описания каждой возможной ситуации средствами ER-диаграмм уже не достаточно ответить на вопрос, снабжать стрелкой соответствующую линию или нет. Для примера вновь обратимся к диаграмме рис. 2.4. Некоторая студия напрямую связана с определенным кинофильмом, а не с актером и кинофильмом, рассматриваемыми совместно, поскольку производством фильмов занимается именно студия. Однако используемая нами система обозначений не позволяет отличить эту ситуацию от случая, когда в тернарной связи одно множество сущностей в действительности является функцией двух других множеств. В разделе 3.4 на с. 106 мы рассмотрим строгую систему, основанную на задании функциональных зависимостей и позволяющую описать все мыслимые ситуации, в которых связи одного множества сущностей с другими обособлены друг от друга. Пример 2.7. В качестве завершающего примера, иллюстрирующего как многосторонние связи, так и связи с несколькими ролями, на рис. 2.6 приведен более сложный вариант связи Contracts ("контракты"), рассмотренной выше, в примере 2.5 (см. с. 56). Теперь связь Contracts затрагивает уже две киностудии, актера и кинофильм. Смысл состоит в том, что одна студия, заключившая контракт с актером (вообще говоря, не обязательно связанный со съемками конкретного фильма), может подписать контракт с другой студией, который позволил бы актеру участвовать в работе над новым фильмом. Таким образом, связь теперь описывается набором кортежей следующего вида: (studio 1, studio2, star, movie). Имеется в виду, что студия "studio2" заключает контракт со студией "studiol", оговаривающий условия привлечения актера студии "studiol" на съемки фильма "movie", который выпускается студией "studio2". Стрелки, изображенные на рис. 2.6, характеризуют две роли киностудии, относящейся к множеству сущностей Studios: "студия-владелец актера" (Studio-of-Star) и "студия-продюсер кинофильма" (Producing-Studio). Доводы таковы. Для каждого определенного актера, фильма и студии, которая занимается съемкой этого фильма, существует только одна студия, "владеющая" актером. (Предполагается, что актер заключил долговременный контракт только с одной студией.) Аналогично, конкретный фильм снимается только одной студией, так что обладая информацией об актере, фильме и студии, к которой относится этот актер, мы сможем определить уникальную сущность, соответствующую студии, осуществляющей съемку. Обратите внимание, что в обоих случаях для определения уникальной сущности нам необходимо только одно из остальных множеств сущностей — например, для отыскания конкретной студии-продюсера достаточно определить кинофильм, снимаемый ею, — но этот факт не меняет общей картины множественности соединений в многосторонней связи. Стрелок, которые были бы обращены к множествам Movies ("кинофильмы") и Stars ("актеры"), однако, не существует. Заданной тройке значений — имени актера и названиям студии-владельца и студии-продюсера — может соответство- Stars 0 ^tudio - [ f-Star \ Contracts Studios Movies \ Producing- 1 Studio Рис. 2.6. Четырехсторонняя связь 58 ГЛАВА 2. МОДЕЛЬ ДАННЫХ "СУЩНОСТЬ-СВЯЗЬ
вать несколько контрактов, позволяющих актеру сниматься в различных фильмах. Поэтому такой набор данных кортежа не обязательно соответствует уникальному кинофильму. Аналогично, студия-продюсер вправе заключить контракт с другой студией на привлечение к съемкам фильма сразу нескольких актеров, так что имя актера в общем случае не может быть определено на основании данных трех других компонентов связи. □ 2.1.9. Связи и атрибуты Подчас бывает удобно или даже, как кажется, настоятельно необходимо ассоциировать атрибут со связью, а не с некоторым множеством сущностей, охватываемых этой связью. Вновь вернемся к примеру связи, показанной на рис. 2.4 (см. с. 56), которая представляет множество контрактов между актерами и студиями.3 Пусть нам необходимо зафиксировать на диаграмме атрибут "размер заработной платы" (salary) актера (Stars), установленный в соответствии с контрактом (Contracts). Мы не вправе связывать подобный атрибут непосредственно с актером: последний за участие в съемках различных фильмов может получать различные суммы вознаграждения. Исходя из подобных соображений, не имеет смысла ассоциировать атрибут "размер заработной платы" и с множествами сущностей "киностудии" (Studios) (студии по-разному оплачивают работу различных актеров) и "кинофильмы" (Movies) (различные актеры за участие в съемках одного и того же фильма могут получать различную зарплату). Однако уместно ассоциировать атрибут salary с кортежем (star, movie, studio) из множества данных, соответствующего связи Contracts. На рис. 2.7 приведена диаграмма рис. 2.4 (см. с. 56), дополненная атрибутами множеств сущностей Movies, Stars и Studios (эти атрибуты приводились на рис. 2.2 — см. с. 54), а также атрибутом salary, соединенным со связью Contracts. Рис. 2.7. Связь с атрибутом Впрочем, злоупотреблять возможностью размещения атрибутов на связях не следует. В ка-честве альтернативы можно предложить следующее: ввести в диаграмму новое множество сущностей с тем же атрибутом, соединить это множество со связью и уда- 3 Здесь мы рассматриваем исходную, тернарную, редакцию связи Contracts, соответствующую примеру 2.5 на с. 56, а не ее четырехстороннюю версию, упоминавшуюся в примере 2.7 на с. 58. 2.1. ЭЛЕМЕНТЫ ER-МОДЕЛИ 59
лить атрибут связи. Но иногда мы все-таки будем использовать атрибуты, ассоциированные со связями напрямую, если такое решение в конкретной ситуации окажется более целесообразным и наглядным. Пример 2.8. Давайте исправим ER-диаграмму рис. 2.7, на которой атрибутом salary ("размер заработной платы") снабжена связь Contracts ("контракты"). Создадим множество сущностей Salaries ("заработная плата") с одноименным атрибутом salary. Salaries станет четвертым множеством сущностей, соединенным со связью Contracts. Результат показан на рис. 2.8. □ 2.1.10. Преобразование многосторонних связей в бинарные Существуют некоторые модели представления данных, такие как язык ODL (Object Definition Language — язык определения объектов), рассматриваемый в разделе 4.2 на с. 152, которые ограничивают число "сторон", охватываемых связью, до двух, т.е. предполагают использование только бинарных связей (binary relationships). Поскольку ER-модели подобные ограничения не присущи, полезно знать о том, что любая связь, соединяющая более двух множеств сущностей, может быть преобразована в набор бинарных связей типа "многие к одному" (many-one relationships). С этой целью вводится новое множество сущностей, элементы которого являются кортежами множества данных для рассматриваемой многосторонней связи. Множество сущностей, подобное вводимому, называют соединяющим множеством сущностей (connecting entity set). Затем в диаграмму включаются связи типа "многие к одному", "сплачивающие" соединяющее множество сущностей с каждым из множеств сущностей, элементы которых служат компонентами кортежей множества данных для исходной многосторонней связи. (Читатель, если вы это поняли, вы поймете и все остальное. — Прим. перев.) Если некоторое множество сущностей в контексте связи обладает несколькими ролями, каждая роль преобразуется отдельно. Рис. 2.8. Передача атрибута связи множеству сущностей Пример 2.9. Четырехсторонняя связь Contracts ("контракты"), изображенная на рис. 2.6 (см. с. 58), может быть заменена соединяющим множеством сущностей, которое уместно назвать тем же именем, Contracts. Результат показан на рис. 2.9. Множе- 60 ГЛАВА 2. МОДЕЛЬ ДАННЫХ "СУЩНОСТЬ-СВЯЗЬ
ство сущностей Contracts принимает участие в четырех связях. Если в составе множества данных, соответствующего связи Contracts, имеется кортеж (studio 1, studio2, star, movie), можно считать, что множество сущностей Contracts содержит некоторую сущность е, соединенную связью Star-of с сущностью star множества сущностей Stars ("актеры"), связью Movie-of— с сущностью movie множества сущностей Movies ("кинофильмы"), а также с сущностями studio 1 и studio2 множества сущностей Studios ("киностудии") посредством связей Studio-of-Star и Producing-Studio соответственно. Здесь мы подразумеваем, что соединяющее множество сущностей Contracts не содержит атрибутов, а все другие множества таковыми обладают, хотя на рис. 2.9 они не показаны. Однако ничто не мешает снабдить подходящими атрибутами — например, таким как date-of-signing ("дата подписания") — и множество Contracts. □ 2.1.11. Подклассы в ER-модели Нередки ситуации, когда множество сущностей содержит определенные сущности, которые обладают специальными свойствами, не присущими остальным членам множества. В подобных случаях подчас оказывается полезным создавать специальные множества сущностей — или подклассы (subclasses) — каждое из которых обладает собственными набором атрибутов и/или связями. Для соединения "полного" множества сущностей — базового класса (superclass) — с его подклассами используются связи, называемые isa (от "is а" — есть) (например, утверждение "А есть Я" выражает наличие связи isa, направленной от множества сущностей А к множеству сущностей В). Связь isa имеет особый смысл, и чтобы отличить ее от других, мы применяем специальное обозначение: каждая связь isa на ER-диаграмме представляется треугольником. Одна из сторон треугольника соединяется с подклассом, а противоположная вершина — с базовым классом. Каждая связь isa относится к типу "один к одному", но, в отличие от других связей типа "один к одному", стрелки на ее линиях не проставляются. Рис. 2.9. Замена многосторонней связи соединяющим множеством сущностей и набором бинарных связей 2.1. ЭЛЕМЕНТЫ ER-МОДЕЛИ 61
Пример 2.10. В "кинематографической" базе данных, рассматриваемой нами, может храниться информация о фильмах, относящихся к различным жанрам: мультипликация, "боевик", приключения, комедия и т.д. Для каждого из жанров вполне правомерно определить соответствующий подкласс множества сущностей Movies ("кинофильмы"). Рассмотрим для примера два подкласса — Cartoons ("мультипликация") и Murder-Mysteries ("боевики"). Множество сущностей "мультипликация", помимо атрибутов и связей, унаследованных от базового класса "кинофильмы", участвует в дополнительной связи Voices ("голоса"), которая определяет подмножество актеров, участвовавших в озвучивании фильма, но не появлявшихся на экране непосредственно. Фильмы, не относящиеся к жанру мультипликации, не обладают подобной связью. Для кинофильмов-"боевиков" характерно наличие атрибута weapon ("оружие"). Взаимоотношения множеств сущностей Movies, Cartoons и Murder-Mysteries иллюстрируются диаграммой рис. 2.10. G К множеству сущностей Stars [length) С title J Г year filmType Movies weapon Cartoons Murder- Mysteries Рис. 2.10. Связи isa на ER-диаграмме Хотя, вообще говоря, набор множеств сущностей, соединенных связями isa, может обладать структурой любой топологии, мы сосредоточим внимание на гораздо более распространенных древовидных (tree-like) /^-структурах, обладающих одним корневым (root) множеством сущностей (таким как Movies на рис. 2.10), из которого "произрастают" и "ветвятся" множества более частного характера. Рассмотрим дерево множеств сущностей, соединенных связями isa. Некоторая сущность состоит из компонентов (components), относящихся к одному или нескольким указанным множествам сущностей, если эти компоненты принадлежат поддереву (subtree) исходного дерева, включающему корневую вершину. Другими словами, если некоторая сущность е обладает компонентом с из множества сущностей Е и родительским по отношению к Е в дереве является множество F, то е обладает также некоторым компонентом d из F. Кроме того, end должны быть представлены в виде пары во множестве данных для связи isa, направленной от Е к F. Сущность е имеет те же атрибуты, которыми обладает любой из ее компонентов, и участвует в тех же связях, к которым имеет отношение любой из этих компонентов. Пример 2.11. Обратимся к рис. 2.10. Сущность-"кинофильм", которая не относится ни к жанру мультипликации (Cartoons), ни к числу "боевиков" (Murder-Mysteries), будет обладать только таким компонентом, который принадлежит корневому множеству сущностей Movies ("кинофильмы"). Всем сущностям Movies поставлены в соответствие четыре атрибута (length ("продолжительность"), title ("название"), year ("год производства") и filmType ("тип пленки")) и две связи (Stars-in ("актеры-участники") и Owns ("владеет") — последние на рис. 2.10 не показаны). 62 ГЛАВА 2. МОДЕЛЬ ДАННЫХ "СУЩНОСТЬ-СВЯЗЬ"
Различия параллельных связей На рис. 2.10 иллюстрируется одна тонкая особенность ER-связей, требующая дополнительного разъяснения. Диаграмма содержит две различные связи, Studio-of- Star ("студия-владелец актера") и Producing-Studio ("студия-продюсер кинофильма"), и каждая из них соединяет одни и те же множества сущностей — Contracts ("контракты") и Studios ("киностудии"). Мы, однако, не вправе ожидать, что из факта "параллель-ности" связей следует идентичность множеств данных, соответствующих этим связям. Действительно, в рассматриваемом здесь случае совершенно неправомочно полагать, что обе связи представляют один и тот же "контракт", относящийся к некоторой сущности-"киностудии", поскольку иначе студия должна заключать контракт сама с собой. В более общем плане можно утверждать, что в ER-диаграмме, содержащей связи, которые соединяют одинаковые множества сущностей, нет ничего противоестественного. В базе данных конкретные экземпляры этих связей при нормальных условиях всегда окажутся различными, подтверждая особый смысл каждой из связей. Если же множества данных для двух или более связей, как предусматривается, должны совпадать, такие связи по существу сводятся к единственной связи, и нет никаких причин отображать их отдельно под разными именами. Сущность-"мультфильм", не являющаяся "боевиком", обладает двумя компонентами, один из которых относится к множеству Movies, а другой — к Cartoons. Поэтому она получит не только четыре упомянутых выше атрибута множества Movies, но и связь Voices ("голоса"). Аналогичным образом, сущность-"боевик", не являющаяся "мультфильмом", также обладает двумя компонентами, один из которых относится к множеству Movies, а другой — к Murder-Mysteries, и поэтому характеризуется пятью атрибутами, включая weapon ("оружие"). Наконец, сущности-"кинофильмы" (подобные "Roger Rabbit"), которые относятся к жанрам мультипликации и "боевика" одновременно, обладают компонентами всех трех множеств — Movies, Cartoons и Murder-Mysteries. Компоненты соединяются в целостную сущность благодаря связям isa. Рассматриваемые совместно, эти компоненты поставят в соответствие тому же "Roger Rabbit" все четыре атрибута множества сущностей Movies плюс атрибут weapon множества Murder-Mysteries плюс связь Voices множества Cartoons. □ 2.1.12. Упражнения к разделу 2.1 * Упражнение 2.1.1. Рассмотрим проект базы данных банка, содержащей информацию о клиентах (назовем это множество сущностей Customers) и состоянии их счетов {Accounts). Данные о клиенте включают его имя {пате), адрес {address), номер телефона {phone) и код полиса социального страхования {ssnumber). Счет описывается атрибутами номера {number), типа (например, "накопительный", "чековый" и т.п.) {type) и остатка {balance). Необходимо также отразить в базе данных факт принадлежности счета определенному клиенту. Начертите ER-диаграмму, соответствующую такой базе данных. Не забудьте там, где необходимо, использовать стрелки, чтобы однозначно описать тип той или иной связи. Упражнение 2.1.2. Исправьте решение упражнения 2.1.1 следующим образом: a) измените диаграмму в предположении, что счет может принадлежать только одному клиенту; b) измените диаграмму, предусматривая, что клиент может открыть в банке только один счет; 2.1. ЭЛЕМЕНТЫ ER-МОДЕЛИ 63
Подклассы в объектно-ориентированных системах Имеется значительное сходство между связью isa, соединяющей множества сущностей в ER-модели, и отношением подкласса (subclass) к базовому классу в объект- но-ориентиро-ванном языке. Впрочем, между двумя подходами существует и фундаментальное различие: сущности в ER-модели могут обладать компонентами, представляющими другие вершины дерева множеств сущностей, в то время как объекты относятся к конкретному классу. Чтобы прояснить указанное различие, рассмотрим сущность-"кинофильм" "Roger Rabbit", которую мы упоминали в примере 2.11. Если применить объектно- ориентированный подход, для описания этой сущности нам пришлось бы образовать новое множество сущностей, что-то вроде Cartoons-Murder-Mysteries (" мультипликационные боевики"), и придать ему все атрибуты и связи множеств Movies ("кинофильмы"), Cartoons ("мультипликация") и Murder-Mysteries ("боевики"). В ER- модели, однако, тот же эффект достигается "распределением" компонентов сущности "Roger Rabbit" по множествам сущностей Cartoons и Murder-Mysteries. ! с) измените исходную диаграмму, полученную в результате решения упражнения 2.1.1, в предположении, что клиент может иметь несколько адресов, описываемых кортежами вида "улица—город—страна", и множество номеров телефонов. Имейте в виду, что в рамках ER-модели вы не вправе использовать атрибуты типов, таких как множества, не являющихся атомарными; ! d) выполните дальнейшую модификацию диаграммы, предусматривая, что клиент может иметь несколько адресов, а за каждым адресом закреплено множество номеров телефонов. Упражнение 2.1.3. Представьте в виде ER-диаграммы структуру "футбольной" базы данных, охватывающей информацию о командах, об игроках и о болельщиках, включая следующие атрибуты: 1) для каждой команды — название, перечень имен игроков, имя капитана (из числа игроков), цвета формы; 2) для каждого игрока — имя; 3) для каждого болельщика — имя, название команды, имя любимого игрока и предпочитаемый цвет. Не забывайте, что множество не является допустимым типом атрибута. Как обойти это ограничение при описании цветов формы команды? Упражнение 2.1.4. Предположим, что в диаграмме решения упражнения 2.1.3 следует предусмотреть связь Led-by ("играл под руководством"), соединяющую двух игроков и команду. Множество данных для связи Led-by состоит из кортежей вида (playerl, player2, team), свидетельствующих о том, что игрок "playerl" играл в команде "team" в тот период, когда игрок "player2" был ее капитаном. a) Внесите в ER-диаграмму необходимые изменения. b) Замените тернарную связь Led-by новым множеством сущностей и набором бинарных связей. ! с) Совпадают ли новые бинарные связи с какими-либо из ранее существовавших связей? Мы полагаем, что две сущности вида "игрок", соединяемые 64 ГЛАВА 2. МОДЕЛЬ ДАННЫХ "СУЩНОСТЬ-СВЯЗЬ
связью Led-by, различны, т.е. капитан команды не может играть под своим собственным руководством. Упражнение 2.1.5. Дополните диаграмму решения упражнения 2.1.3 информацией о том, в каких командах игрок выступал прежде, включая даты зачисления в состав каждой команды и увольнения из нее. ! Упражнение 2.1.6. Рассмотрим задачу описания генеалогического дерева семьи. Нам понадобится одно множество сущностей, People ("люди"). Информация, которую необходимо отобразить в модели, включает атрибут пате ("имя") и следующие связи: MotherOf ("является матерью"), FatherOf ("является отцом") и ChildOf ("является ребенком"). Постройте ER-диаграмму, состоящую из множества сущностей People и при-соединенных к нему связей MotherOf, FatherOf и ChildOf He забудьте воспользоваться ролями, если множество сущностей в контексте связи участвует многократно. ! Упражнение 2.1.7. Измените проект базы данных, созданный вами при решении упражнения 2.1.6, включив в него описание следующих специальных множеств сущностей "человек": 1) Females ("женщины"); 2) Males ("мужчины"); 3) Parents ("родители"). Можете усложнить задание и создать другие частные подклассы множества People, воспользовавшись требуемыми связями. Упражнение 2.1.8. Альтернативный способ решения задания упражнения 2.1.6 состоит в применении тернарной связи Family ("семья") в предположении, что кортеж множества данных для Family выглядит как (person, mother, father), где сущности "mother" и "father" представляют данные о матери и отце человека "person" соответственно. * а) Начертите диаграмму, пометив стрелками необходимые связи. Ь) Замените тернарную связь Family множеством сущностей и набором бинарных связей. Вновь разместите стрелки соответствующим образом, отмечая типы связей. Упражнение 2.1.9. Спроектируйте структуру, адекватно описывающую университетскую базу данных, которая должна включать информацию о студентах, факультетах, профессорах, курсах, а также о том, какие студенты слушают какие курсы и какие профессора преподают эти курсы, какие курсы читаются на том или ином факультете, об отметках студентов и лучших достижениях студентов по каждому курсу. Вы вправе представить на диаграмме и другие данные, которые покажутся вам уместными и значимыми. Это задание предусматривает большую свободу действий, нежели предыдущие, и при его выполнении вам придется принимать самостоятельные решения, касающиеся свойств множественности связей, выбора их типов и даже того, какого рода информация достойна представления в базе данных. ! Упражнение 2.1.10. Мы вправе неформально утверждать, что две ER-диаграммы "равнозначны по смыслу", если в контексте реальной ситуации экземпляры этих диаграмм могут быть "приведены" одна к другой путем вычислений. Вновь для примера обратимся к диаграмме рис. 2.6 (см. с. 58). Четырехсторонняя связь Contracts ("контракты") может быть заменена тернарной и бинарной связями на основании того факта, что для каждого фильма из множества сущностей Movies 2.1. ЭЛЕМЕНТЫ ER-МОДЕЛИ 65
имеется в точности одна киностудия (Studios), которая снимает этот фильм. Начертите ER-диаграмму, равнозначную представленной на рис. 2.6, не используя четырехстороннюю связь. 2.2. Принципы проектирования Нам с вами предстоит рассмотреть еще немало аспектов модели "сущность- связь", но уже сейчас уместно обсудить ряд принципиальных вопросов, касающихся того, что представляет собой хороший проект базы данных и чего в процессе дизайна желательно избегать. В этом разделе мы предложим вашему вниманию сведения об основных принципах проектирования. 2.2.1. Достоверность Прежде всего, проект обязан достоверно представлять спецификацию базы данных. Другими словами, множества сущностей и их атрибуты должны соответствовать реальным требованиям. Вы не вправе, например, ассоциировать с множеством сущностей Stars ("актеры") атрибут number-of-cylinders ("количество цилиндров"), хотя последний вполне применим по отношению к множеству Automobiles ("автомобили"). Прежде чем вводить в модель новое множество сущностей, атрибут или связь, надлежит задаться вопросом, а все ли доподлинно известно о той части реального мира, которая должна быть смоделирована. Пример 2.12. Если вновь присмотреться к связи Stars-in ("актеры-участники"), соединяющей множества сущностей Stars ("актеры") и Movies ("кинофильмы"), станет очевидным, что она должна относиться к типу "многие ко многим". Причины бесспорны: здравый смысл, основанный на элементарном понимании моделируемых сущностей, подсказывает, что актеры вправе участвовать в съемках нескольких фильмов, а в каждом фильме могут быть заняты одновременно несколько актеров. Совершенно неправомерно считать, что связь Stars-in в любом направлении может представлять отношение "многие к одному" или, более того, "один к одному". □ Пример 2.13. Подчас, однако, далеко не очевидно, как именно те или иные объекты реального мира должны соотноситься в рамках ER-модели. Рассмотрим для примера множества сущностей Courses ("учебные курсы") и Instructors ("преподаватели"), соединенные связью Teaches ("обучает"). Действительно ли Teaches представляет связь типа "многие к одному" в направлении от Courses к Instructors? Ответ зависит от корпоративной политики и традиций конкретного учебного заведения. Вполне возможно, что за каждым курсом закреплен в точности один преподаватель. Даже в том случае, если несколько преподавателей ведут курс совместно, не исключено, что в соответствии с внутренними требованиями организации в базе данных должен быть указан только один из преподавателей, "ответственный" за курс. В любом из подобных случаев мы имеем право утверждать, что связь Teaches, соединяющая множества сущностей Courses и Instructors, должна относиться к типу "многие к одному" (если рассматривать ее в указанном направлении). С другой стороны, в учебном заведении может быть принят такой порядок, когда несколько преподавателей способны заменять друг друга при чтении определенного курса без каких бы то ни было ограничений. Либо изначальный смысл связи Teaches заключается не в том, чтобы отобразить зависимость между курсом и преподавателем, ведущим его в данный момент, а зафиксировать хронологию ведения курса различными преподавателями или просто описать множество преподавателей, готовых к чтению этого курса (наименование связи Teaches само по себе не раскрывает ее истинного смысла). В любом из названных случаев уместно считать, что связь Teaches должна относиться к типу "многие ко многим". □ 66 ГЛАВА 2. МОДЕЛЬ ДАННЫХ "СУЩНОСТЬ-СВЯЗЬ
2.2.2. Отсутствие избыточности Мы обязаны тщательно следить за тем, чтобы объекты структуры не повторяли друг друга. Пусть, например, сущности Movies ("кинофильмы") и Studios ("киностудии") соединены связью Owns ("владеет"). Мы можем также снабдить множество сущностей Movies атрибутом studioName ("название студии"). Хотя такое решение на первый взгляд вполне приемлемо, оно таит в себе ряд опасностей. 1. Повторение описания студии-владельца кинофильма приводит к дополнительному расходу памяти при хранении атрибута в базе данных. 2. При продаже кинофильма мы можем изменить название студии, которая им владела, на новое, определяемое связью Owns, но забыть исправить содержимое атрибута studioName — или умудриться сделать наоборот. Конечно, можно утверждать, что подобные ошибки вряд ли вероятны, но на практике они, к несчастью, случаются, и, пытаясь описать некий объект несколькими различными способами, мы заранее ставим себя, мягко говоря, в невыгодное положение. Подобные ситуации мы опишем более подробно в разделе 3.6 на с. 123, где расскажем и о некоторых конкретных инструментах устранения избыточности в схемах баз данных. 2.2.3. Простота Включайте в проект только те структурные элементы, без которых совершенно нельзя обойтись. Пример 2.14. Предположим, что вместо непосредственной связи между множествами сущностей Movies ("кинофильмы") и Studios ("киностудии") мы считаем целесообразным использовать новое "промежуточное" множество сущностей Holdings ("права владения"), описывающее факт принадлежности конкретного фильма определенной студии. Между каждым фильмом и сущностью "права владения" может быть установлена связь Represents ("представляет") типа "один к одному". Общую картину, иллюстрируемую рис. 2.11, завершает связь типа "многие к одному", соединяющая множества сущностей Holdings и Studios. Movies Studios Рис. 2.11. Неудачный пример: в диаграмму включено избыточное множество сущностей Если говорить формально, структура, приведенная на рис. 2.11, совершенно верно отображает реальные зависимости, поскольку она позволяет "проследовать" от конкретного кинофильма к студии, которая им владеет, при посредничестве множества сущностей Holdings. Последнее, однако, не выполняет никаких уникальных функций, и его вполне можно исключить. Не сделав этого, при создании базы данных и соответствующих программных приложений мы затратим усилия и время на реализацию более сложных зависимостей и поиск дополнительных вероятных ошибок, а также израсходуем лишнее дисковое пространство. □ 2.2.4. Выбор подходящих связей Множества сущностей могут быть соединены посредством связей разными способами. Однако включение в проект первых попавшихся связей — это не самое хорошее решение. Во-первых, оно способно привести к избыточности схемы, когда одни и те же соотношения множеств сущностей выражаются несколькими цепочками соединений. 2.2. ПРИНЦИПЫ ПРОЕКТИРОВАНИЯ 67
Во-вторых, реализация подобной модели потребует дополнительного расхода дискового пространства, а задача внесения изменений в схему базы данных существенно усложнится, поскольку исправление одной связи повлечет необходимость модификации многих других. Указанные проблемы по существу схожи с теми, о которых мы говорили в разделе 2.2.2 на с. 67, хотя причины возникновения тех и других различаются. Чтобы проиллюстрировать проблемы и описать средства их разрешения, мы воспользуемся двумя примерами: в первом несколько связей представляют одну и ту же информацию, а во втором одна связь может быть получена на основании нескольких других. Пример 2.15. Вернемся к диаграмме рис. 2.7 (см. с. 59), на которой множества сущностей Movies ("кинофильмы"), Stars ("актеры") и Studios ("киностудии") соединены с помощью тернарной связи Contracts ("контракты"). Здесь опущены две бинарные связи, Stars-in ("актеры-участники") и Owns ("владеет"), введенные в диаграмму ранее, на рис. 2.2 (см. с. 54). Возникает закономерный вопрос, действительно ли связи Stars-in (между Movies и Stars) и Owns (между Movies и Studios) все еще необходимы при наличии связи Contracts! Ответ таков: "не известно; решение зависит от того, какой смысл мы вкладываем в каждую из трех рассматриваемых связей". Вполне возможно получить связь, аналогичную Stars-in, на основании связи Contracts. Если актер появляется в фильме только при наличии соответствующего контракта, в котором упоминаются сам актер, студия и производимый ею фильм, тогда действительно необходимость в использовании связи Stars-in отпадает: для определения всех пар вида "актер—кинофильм" для заданных сущностей "актер" и "кинофильм" достаточно просмотреть кортежи "актер—кинофильм—киностудия" множества данных, отвечающего связи Contracts, и выбрать нужные, ограничившись компонентами "актер" и "кинофильм". Если, однако, актер может сниматься в фильме, не подписав контракт — или, что более вероятно с практической точки зрения, не имея контракта, который был бы зафиксирован в нашей базе данных, — тогда во множестве данных связи Stars-in могут существовать такие пары вида "актер—кинофильм", которые не являются частью кортежей "актер—кинофильм—киностудия" множества данных связи Contracts. В этой ситуации связь Stars-in обладает самостоятельным значением и должна быть сохранена. Подобные соображения применимы и по отношению к связи Owns. Если для каждой сущности "кинофильм" имеется по меньшей мере один "контракт", в который вовлечены как она сама, так и соответствующие сущности "киностудия"-владелец кинофильма и некоторый "актер", связью Owns без какого-либо ущерба можно пренебречь. Если же, напротив, существует вероятность того, что студия владеет кинофильмом и при этом актеры не связаны контрактом на участие в этом фильме либо такой контракт не зарегистрирован в базе данных, связь Owns следует оставить в неприкосновенности. Если подытожить сказанное, мы не можем дать пригодного на все случаи жизни совета по поводу того, как определить, является конкретная связь избыточной или нет. Вы должны получить нужные сведения от тех, для кого предназначена проектируемая база данных, и на этом основании самостоятельно принять единственно правильное решение. □ Пример 2.16. Давайте вновь обратимся к диаграмме рис. 2.2 (см. с. 54). На ней нет каких-либо прямых связей между множествами сущностей Stars ("актеры") и Studios ("киностудии"). Но мы можем получить необходимую соединяющую цепочку, используя свойства связей Stars-in ("актеры-участники") и Owns ("владеет"), поскольку некоторый "актер" связан посредством Stars-in с определенными "кинофильмами", а те, в свою очередь, благодаря связи Owns соединены с соответствующими сущностями-"киностудиями". Таким образом, можно говорить, что актер связан со студией, владеющей фильмом, в котором этот актер снимался. Имеет ли смысл включать в диаграмму дополнительную связь — что-то вроде Works-for ("работает" на киностудию) — между множествами сущностей Stars и Studios, как показано на рис. 2.12? И вновь, как и прежде, мы не можем ответить на 68 ГЛАВА 2. МОДЕЛЬ ДАННЫХ "СУЩНОСТЬ-СВЯЗЬ"
Рис. 2.12. Включение в диаграмму дополнительной связи этот вопрос однозначно, не обладая нужными сведениями. Самое главное, каково истинное назначение этой связи? Если ее смысл таков, что "актер снялся, по меньшей мере, в одном фильме, выпущенном студией", тогда, вероятно, веских причин для использования подобной связи нет, так как аналогичная информация может быть получена на основе существующих связей, Stars-in и Owns. Однако вполне вероятна ситуация, что имеется некая иная информация (возможно, совершенно уникальная) об особенностях работы актеров со студиями, которая не отражена в цепочке связей Stars-in и Owns. В этом случае связь, соединяющая множества сущностей Stars и Studios напрямую, может оказаться полезной и не восприниматься как избыточная. Например, такая связь должна представить тот факт, что актер связан со студией неким общим контрактом, который не имеет отношения к конкретному кинофильму. Кроме того, как мы упоминали в примере 2.7 (см. с. 58), отнюдь не невероятно, что актер, заключивший контракт с одной студией, принимает участие в фильме, выпускаемом другой студией. В подобных ситуациях новая связь Works-for никак не зависит от связей Stars-in и Owns и определенно не будет считаться излишней. □ 2.2.5. Использование элементов адекватных типов Иногда при выборе типа элемента модели, используемого для отображения реального объекта, возможно наличие нескольких альтернатив дальнейших действий. Во многих случаях приходится поразмышлять, чему отдать предпочтение — атрибутам или сочетаниям множеств сущностей и связей. Вообще говоря, атрибут реализовать гораздо проще, нежели множество сущностей или связь. Однако крайности всегда вредны — необоснованное повсеместное применение атрибутов способно привести к неприятностям. Пример 2.17. Обратимся к рис. 2.2 (см. с. 54) и рассмотрим одну частную проблему. Насколько здравым было наше решение о представлении объектов "киностудия" отдельным множеством сущностей Studios? Может быть, следовало передать атрибуты "название студии" и "адрес студии" множеству сущностей Movies ("кинофильмы") и исключить Studios вовсе? Если поступить так, как мы сказали, придется повторять адрес студии в наборе данных о каждом кинофильме. Это еще один пример избыточности, подобный тем, которые упоминались в двух предыдущих разделах. Помимо издержек, связанных с избыточностью данных, мы столкнемся со следующей опасностью: если в базе данных будут отсутствовать сведения о каких бы то ни было фильмах, снятых определенной студией, информация об этой студии как таковой окажется утраченной. С другой стороны, если потребность в хранении адреса студии не возникает, никакого вреда не принесет то, что наименование студии в качестве атрибута будет поставлено в соответствие каждому фильму. Теперь об избыточности из-за многократного повторения адреса студии речь не идет, а то, что наименование студии, такое как, скажем, "Disney", указывается для каждого фильма, снятого этой студией, не может рассматриваться как излишняя информация, поскольку авторские права студии должны быть отражены так или иначе. □ Теперь попробуем абстрагировать выводы, к которым мы пришли, рассматривая пример 2.17, чтобы более строго описать обстоятельства, позволяющие предпочесть атрибут множеству сущностей. Пусть Е — это некоторое множество сущ- 2.2. ПРИНЦИПЫ ПРОЕКТИРОВАНИЯ 69
ностей. Ниже перечислены условия, которым должно удовлетворять множество Е, чтобы его было целесообразно заменить атрибутом или набором атрибутов нескольких других множеств сущностей. 1. Все связи, в которые вовлечено множество Е, обладают стрелками, указывающими на Е. Другими словами, множеству Е должна отводиться роль компонента "один" во всех связях типа "многие к одному" или их обобщениях для случаев многосторонних связей. 2. Атрибуты множества Е в совокупности обязаны однозначно определять любую сущность множества. Чаще всего имеется только один такой атрибут, и в этом случае условие определенно удовлетворяется. Если же множество обладает несколькими атрибутами, ни один из них не должен зависеть от остальных (таким образом, как, например, атрибут address ("адрес") множества сущностей Studios ("киностудии") зависит от атрибута пате ("название") того же множества). 3. Ни в одной из связей множество Е не должно участвовать многократно. Если все указанные условия удовлетворены, множество сущностей Е может быть заменено другими элементами одним из следующих способов: a) если существует связь R типа "многие к одному", направленная от некоторого множества сущностей F к множеству Е, следует удалить R и передать атрибуты Е множеству F, выполнив при необходимости их переименование, если F уже содержит атрибуты с теми же именами; в результате каждая сущность множества F получит в качестве атрибута наименование уникальной связанной с ней сущности множества Е 4 (как, например, в случае, когда сущностям "кинофильм" передается атрибут "название студии", а атрибут "адрес студии" исключается). b) если существует многосторонняя связь R, содержащая стрелку, направленную к Е, целесообразно передать атрибуты Е связи R и удалить стрелку, соединяющую R с Е\ примером может служить возврат от диаграммы рис. 2.8 (см. с. 60), где было введено новое множество сущностей Salaries, к исходной версии диаграммы с аналогичным атрибутом salary, относящимся к элементу связи Contracts (см. рис. 2.7 на с. 59). Пример 2.18. Проанализируем ситуацию, предполагающую выбор компромиссного решения — использовать многостороннюю связь или предпочесть соединяющее множество сущностей и набор из нескольких бинарных связей. В разделе 2.1.8 на с. 57 мы рассматривали четырехстороннюю связь Contracts ("контракты"), соединяющую сущности "актер" (из множества Stars), "кинофильм" (Movies) и две сущности "киностудия" (Studios) (см. рис. 2.6 на с. 58). На диаграмме рис. 2.9 (см. с. 61) в предыдущем разделе эта структура была "механически" преобразована в одноименное соединяющее множество сущностей Contracts с несколькими дополнительными бинарными связями. Возникает вопрос, насколько принципиален подобный выбор. Если говорить о задаче в том виде, как мы ее представили, можно считать приемлемым любое из двух решений. Если, однако, изменить постановку задачи хотя бы незначительно, мы почти во всех случаях будем вынуждены отдать предпочтение варианту, предполагающему применение соединяющего множества сущностей. Допустим, например, что в контракте упоминаются один актер, некоторый фильм, но любое подмножество студий. (Подобная ситуация более сложна по сравнению с той, ко- 4 В ситуации, где F-сущность не связана ни с какой £-сущностью, новым атрибутам множества F будут присвоены специальные значения пи/1, свидетельствующие об отсутствии подходящей Е-сущности. Подобное замечание применимо и к случаю передачи атрибутов множества Е связи R, который рассматривается в п. (Ь). 70 ГЛАВА 2. МОДЕЛЬ ДАННЫХ "СУЩНОСТЬ-СВЯЗЬ"
торая отображена на диаграмме рис. 2.6 (см. с. 58), где контракт охватывает две студии, "играющие" определенные роли.) Теперь мы имеем дело с произвольным числом студий, одна из которых, например, занимается собственно производством фильма, другая осуществляет монтаж спецэффектов, третья несет ответственность за маркетинг и рекламу и т.д., и роли студиям присвоить уже нельзя. Чтобы модель адекватно описывала условия поставленной задачи, множество данных связи Contracts должно состоять из кортежей вида (star, movie, set-of-studios), и связь Contracts как таковая будет охватывать не только привычные множества сущностей Stars и Movies, но и новое множество сущностей, элементами которого являются множества студий ("set-of-studios"). Хотя в рассматриваемой ситуации такого результата, как кажется, избежать нельзя, похоже, не совсем естественно воспринимать множества студий в виде элементарных сущностей, и поэтому мы не рекомендуем применять указанный подход. Более предпочтительным представляется решение, в котором контракты описываются множеством сущностей. На диаграмме рис. 2.9 (см. с. 61) сущность "контракт" соединяется с сущностями "актер", "кинофильм" и двумя сущностями "киностудия", но сейчас ограничение на количество киностудий, подписывающих контракт, должно быть снято. Связь между множествами Contracts и Studios приобретает свойство "многие ко многим", а не относится к типу "многие к одному", как в том случае, когда Contracts является "подлинным" соединяющим множеством сущностей. Новая версия диаграммы приведена на рис. 2.13. Еще раз подчеркнем, что теперь контракт соединяет по одной сущности вида "актер" и "кинофильм" с произвольным числом сущностей "киностудия". □ Рис. 2.13. Контракт соединяет актера и кинофильм с произвольным множеством киностудий 2.2.6. Упражнения к разделу 2.2 * Упражнение 2.2.1. На рис. 2.14 представлена диаграмма, описывающая структуру базы данных банка, в которой предусматривается хранение информации о клиентах {Customers) и их счетах {Accounts). Поскольку в общем случае клиент вправе открыть в банке несколько счетов, а счетом могут совместно распоряжаться несколько клиентов, клиентам ставятся в соответствие "наборы счетов" {AcctSets), и каждый счет может быть членом {Member-of) одного или нескольких "наборов счетов". Мы полагаем, что смысл всех остальных связей и атрибутов, приведенных на диаграмме, внятно определяется их названиями {owner-address — "адрес владельца", Has— "обладает", пате— "имя", number— "номер счета", balance— "размер остатка на счете", Lives-at — "проживает", Addresses — "адреса", address — "адрес"). Изучите схему и попытайтесь выдвинуть собственные критические замечания. Ка- 2.2. ПРИНЦИПЫ ПРОЕКТИРОВАНИЯ 71
кие правила проектирования, по вашему мнению, нарушены? Почему? Какие изменения вы предложили бы внести? * Упражнение 2.2.2. При каких условиях два множества сущностей — Studios ("киностудии") и Presidents ("президенты") — и связь Runs ("возглавляет"), образующие диаграмму рис. 2.3 (см. с. 56) (с учетом атрибутов, которые для краткости опущены), могут быть заменены единственным множеством сущностей с соответствующими атрибутами? Упражнение 2.2.3. Предположим, что атрибут address ("адрес") множества сущностей Studios ("киностудии") на диаграмме рис. 2.7 (см. с. 59) удален. Покажите, каким образом множество Studios теперь может быть заменено некоторым атрибутом. Как именно следовало бы расположить этот атрибут? Рис. 2.14. Неудачный пример: ЕЯ- диаграмма банковской базы данных Упражнение 2.2.4. Выберите атрибуты для перечисленных ниже множеств сущностей диаграммы рис. 2.13, что позволит заменить каждое из этих множеств некоторым атрибутом: a) Stars ("актеры"); b) Movies ("кинофильмы"); ! с) Studios ("киностудии"). !! Упражнение 2.2.5. В этом и следующих примерах мы рассмотрим два альтернативных проектных решения, касающихся возможности описания события рождения человека. С фактом рождения связана одна сущность "младенец" (событие рождения близнецов может быть отображено набором отдельных кортежей данных), сущность "мать" и произвольные наборы сущностей "медсестра" и "врач". Предположим далее, что имеются множества сущностей Babies ("младенцы"), Mothers ("матери"), Nurses ("медсестры") и Doctors ("врачи"), а также связь Births ("роды"), соединяющая названные множества сущностей так, как показано на диаграмме рис. 2.15. Примите к сведению, что кортеж множества данных связи Births имеет следующий вид: (baby, mother, nurse, doctor). Если родовспоможением занимается более одной медсестры и/или врача, будут существовать несколько кортежей для одних и тех же компонентов данных "младенец" 72 ГЛАВА 2. МОДЕЛЬ ДАННЫХ "СУЩНОСТЬ-СВЯЗЬ
("baby") и "мать" ("mother") — по одному на каждую комбинацию компонентов "медсестра" ("nurse") и "врач" ("doctor"). Существует несколько дополнительных предположений, перечисленных ниже, которые могут быть учтены при построении модели. Рассмотрев каждое из них, ответьте, следует ли для его реализации добавить в диаграмму какие-либо стрелки связей или другие элементы, и если да, то какие именно. a) Каждой сущности "младенец" соответствует уникальная сущность "мать". b) Каждому сочетанию сущностей "младенец ветствует уникальная сущность "мать". Рис. 2.15. Представление события "роды " с помощью многосторонней связи 'медсестра" и "доктор" соот- Births Babies Mothers Doctors Nurses Рис. 2.16. Представление события "роды" посредством множества сущностей с) Каждой комбинации сущностей "младенец" и кальная сущность "доктор". мать соответствует уни- ! Упражнение 2.2.6. Другой подход к решению проблемы, описанной в упражнении 2.2.5, состоит в соединении множеств сущностей Babies ("младенцы"), Mothers ("матери"), Nurses ("медсестры") и Doctors ("врачи") с множеством сущностей Births ("роды") посредством четырех отдельных связей, как показано на рис. 2.16. Используя стрелки (с целью констатации, что соответствующая связь относится к типу "многие к одному"), обеспечьте реализацию следующих условий: d) каждая сущность "младенец" связана с уникальной сущностью "роды" и каждая сущность "роды" связана с уникальной сущностью "младенец"; e) в дополнение к условию (а), каждой сущности "младенец" соответствует уникальная сущность "мать"; f) в дополнение к условиям (а) и (Ь), каждой сущности "роды" соответствует уникальная сущность "врач". Какие ошибки дизайна вы можете назвать в каждом из случаев? !! Упражнение 2.2.7. Изменим постановку задачи, добавив требование о том, что модель должна отображать факт рождения близнецов непосредственно, а не в виде набора кортежей, по одному на каждую сущность "младенец". Каким образом представить условие, что каждой сущности "младенец" соответствует уникальная сущность "мать", используя подходы, рассмотренные в упражнениях 2.2.5 и 2.2.6? 2.2. ПРИНЦИПЫ ПРОЕКТИРОВАНИЯ 73
2.3. Моделирование ограничений До сих пор мы говорили о том, как моделировать "срез" реального мира средствами множеств сущностей, атрибутов и связей. Однако существуют некоторые другие аспекты действительности, для адекватного представления которых возможностей инструментов моделирования, изученных нами, уже не достаточно. Дополнительная информация об объектах окружающего мира зачастую бывает облечена в форму определенных ограничений (constraints), которые никак не связаны со структурными и "типовыми" ограничениями, сопутствующими описанию конкретных множеств сущностей, атрибутов и связей. 2.3.1. Классификация ограничений Следующий перечень представляет некую грубую классификацию наиболее распространенных ограничений. В этом разделе мы не намереваемся давать их исчерпывающее описание. Дополнительный материал, касающийся ограничений, изложен в разделе 5.5 на с. 241 в терминах реляционной алгебры, а в главе 7 на с. 317 — в контексте модели программирования на языке SQL. 1. Ключ (key) — атрибут или подмножество атрибутов, уникальным образом определяющие некоторую сущность в составе множества сущностей. Никакие две сущности в пределах множества сущностей не могут обладать одинаковыми комбинациями значений атрибутов, составляющих ключ. Впрочем, совпадение отдельных, но не всех одновременно, значений ключевых атрибутов любых двух сущностей вполне допустимо. 2. Ограничение уникальности (single-value constraint): определенное значение в некотором контексте должно быть уникальным. Ключи — это основной "поставщик" ограничений уникальности, поскольку наличие ключа предполагает, что каждая сущность во множестве сущностей обладает уникальными значениями атрибутов, в совокупности образующих ключ. Есть и другие источники, "порождающие" ограничения уникальности, — например, связи типа "многие к одному". 3. Ограничение ссылочной целостности (referential integrity constraint): некоторое значение, на которое ссылается другой объект, должно существовать в базе данных. Ограничение ссылочной целостности аналогично запрету на использование в обычных программах "висящих" указателей или иных элементов, ссылающихся на нечто отсутствующее. 4. Ограничение домена (domain constraint): значение атрибута должно выбираться из некоего конечного множества значений или принадлежать определенному диапазону изменения. 5. Ограничение общего вида (general constraint): произвольное требование, которое должно быть зафиксировано в базе данных, — например, такое как "каждой сущности кинофильм должно быть поставлено в соответствие не более десяти сущностей актер". За сведениями об инструментах описания ограничений общего вида обращайтесь к разделам 5.5 на с. 241 и 7.4 на с. 336. Назовем несколько причин, обусловливающих важность механизма задания ограничений в рамках модели базы данных. Ограничения дают возможность выразить некоторые особые свойства моделируемых сущностей реального мира. Так, например, ключи позволяют однозначно распознавать элементы множества однородных сущностей. Если, скажем, мы знаем, что атрибут пате ("название") служит ключом для множества сущностей Studios ("киностудии"), тогда при обращении к сущности "киностудия" по ее названию обеспечиваются гарантии выбора уникального элемента множества. Помимо того, при сохранении уникального значения экономятся время и дисковое пространство; отдельное значение занести в базу данных проще, нежели множество значений — даже в том случае, если множество состоит из единственного 74 ГЛАВА 2. МОДЕЛЬ ДАННЫХ "СУЩНОСТЬ-СВЯЗЬ
члена.5 Применение ключей и ограничений ссылочной целостности также способствует оптимизации структур данных, что приводит к увеличению скорости доступа к информации (об этом мы расскажем в главе 13 на с. 583). 2.3.2. Ключи и ER-моделирование Говоря более строго, ключ (key) для множества сущностей Е — это множество К, состоящее из одного или более атрибутов множества Е, такое, что при выборе из Е любых двух различных сущностей е{ и е2 последние не могут обладать одинаковыми значениями атрибутов, относящихся к множеству К. Если К состоит из нескольких элементов, допустимо равенство отдельных, но не всех, атрибутов сущностей ех и е2. Надлежит запомнить важные положения, перечисленные ниже. • Каждое множество сущностей должно обладать определенным ключом. • Ключ может состоять более чем из одного атрибута (соответствующая иллюстрация приведена в примере 2.19). • Для каждого множества сущностей допускается наличие нескольких ключей (мы обсудим подобную ситуацию в примере 2.20). Целесообразно, однако, выбрать один их них в качестве "первичного ключа" (primary key) и далее обращаться с множеством таким образом, словно оно обладает единственным ключом. • Если некоторое множество сущностей вовлечено в иерархию связей isa, следует обеспечить, чтобы корневое множество сущностей обладало всеми атрибутами, необходимыми для формирования ключа, и ключ для каждой сущности мог быть найден на основе ее компонентов, относящихся к корневому множеству сущностей, — независимо от того, какое число множеств, участвующих в иерархии, располагает соответствующими компонентами. Пример 2.19. Рассмотрим множество сущностей Movies ("кинофильмы"). На первый взгляд, на роль ключа подходит атрибут title ("название"). Однако нетрудно привести целый ряд примеров названий, которые употреблялись для обозначения двух и более различных кинофильмов (скажем, "King Kong"). Поэтому выбор атрибута title в качестве самодостаточного ключа — это, очевидно, не самое дальновидное решение. Если все же поступить именно так, в дальнейшем мы не сможем различить в базе данных те кинофильмы, которые волею случая получили одно и то же название. Более уместно создать ключ на основе двух атрибутов — title и year ("год производства"). Разумеется, вероятность выхода в одном и том же году двух кинофильмов с одинаковым названием (в базе данных нельзя будет представить сведения об одном и другом одновременно) все еще существует, но она, надо признать, довольно мала. Решение о выборе ключей для двух других основных множеств сущностей, представляющих рассматриваемую нами "кинематографическую" базу данных, должно быть не менее взвешенным. Функции ключа для множества сущностей Studios ("киностудии") имеет смысл возложить на атрибут пате ("название"), поскольку двух студий с одинаковым названием определенно быть не может. Однако столь же категорично утверждать, что сущность "актер" однозначно определяется атрибутом "имя", мы бы не стали, поскольку различить людей только по имени-фамилии в общем случае нельзя. Впрочем, актеры довольно часто выбирают для себя броские "сценические" псевдонимы, поэтому атрибут пате ("имя") может рассматриваться как претендент на роль ключа множества сущностей Stars ("актеры"). Более универсальным, однако, могло бы оказаться решение, предполагающее создание ключа на основе пары атрибутов, пате и address ("адрес"), — если, конечно, вы не столкнетесь с тем редким случаем, когда два актера с одинаковым именем проживают по одному и тому же адресу. □ 5 Аналогично, в программе на языке С, например, гораздо проще представить отдельное целочисленное значение, чем связанный список таких значений, пусть даже этот список состоит из единственного элемента. 2.3. МОДЕЛИРОВАНИЕ ОГРАНИЧЕНИЙ 75
Ограничения как часть схемы базы данных При изучении содержимого некоторой базы данных легко впасть в заблуждение и принять решение о выборе ключевых атрибутов лишь на том, довольно зыбком, основании, что в данный момент времени никакие из сущностей рассматриваемого множества не обладают одинаковыми значениями этих атрибутов (скажем, в базу данных до сих пор не заносились сведения о кинофильмах с одинаковыми названиями). Таким образом, для множества сущностей Movies ("кинофильмы") ключ может быть ошибочно сформирован, например, из единственного атрибута title ("название"). К чему это способно привести, подробно пояснять, вероятно, не нужно: если база данных проектируется с учетом того, что title является уникальным ключом множества сущностей Movies, в дальнейшем в нее нельзя будет внести информацию о нескольких одноименных кинофильмах (таких как "King Kong"). Таким образом, ограничения, касающиеся ключей, — впрочем, и ограничения всех других категорий — в процессе реализации базы данных становятся частью ее схемы, наряду со всеми остальными структурными элементами, такими как множества сущностей и связи. После того как ограничение объявлено, любые операции по пополнению или изменению содержимого базы данных, нарушающие условие этого ограничения, будут запрещены. Хотя частный экземпляр базы данных может заведомо удовлетворять некоторым ограничениям, "подлинными" следует считать только те из них, которые определены проектировщиком базы данных и справедливы для всех ее экземпляров, верно отображающих особенности моделируемых сущностей. Пример 2.20. Предыдущий пример мог утвердить вас во мнении, что, дескать, задача выбора подходящих ключей, гарантирующих уникальность представляемых данных, всегда и заведомо сложна. В действительности обычно все гораздо проще. В реальных ситуациях, подлежащих моделированию, при выборе ключевых атрибутов множеств сущностей зачастую применяются непрямолинейные подходы. Например, во многих компаниях принято присваивать всем служащим уникальный идентификационный код, и одна из целей подобных мер состоит в том, чтобы облегчить введение информации о служащих в корпоративные базы данных и гарантировать возможность различения записей даже в тех случаях, когда несколько служащих имеют одинаковые имена и фамилии. Таким образом, в качестве ключа множества сущностей, описывающего служащих, используется атрибут идентификационного кода. В США является нормой, когда каждый сотрудник компании обладает также собственным номером полиса социального страхования (Social Security number). Если в базе данных предусмотрен соответствующий атрибут для отображения номера полиса социального страхования служащих, он также вполне пригоден для использования в качестве ключевого. Заметим, что в наличии нескольких альтернативных вариантов ключей для одного и того же множества сущностей — например, самостоятельных ключевых атрибутов идентификационного кода и номера полиса социального страхования служащих — нет ничего предосудительного. Практика создания специальных атрибутов, единственным назначением которых является поддержка ключевых признаков сущности во множестве однородных сущностей, достаточно распространена. Аналогично идентификаторам служащих, во многих университетах каждому студенту также присваивают уникальный идентификационный код. В базах данных Государственной автомобильной инспекции в качестве ключевых атрибутов множеств сущностей, представляющих сведения о водителях и транспортных средствах, используются, соответственно, номера водительских удостоверений и регистрационные номера транспортных средств. Любой читатель при желании сможет привести и другие примеры определения специальных атрибутов, предназначенных для использования в качестве ключевых. □ 76 ГЛАВА 2. МОДЕЛЬ ДАННЫХ "СУЩНОСТЬ-СВЯЗЬ!
2.3.3. Представление ключей в ER-модели Используемая нами система обозначений предусматривает, что атрибуты множеств сущностей, объявленные как ключевые, на ER-диаграмме выделяются подчеркиванием. На рис. 2.17 воспроизведена диаграмма рис. 2.2 (см. с. 54), которая отображает структуру базы данных, содержащей сведения о кинофильмах {Movies), киностудиях (Studios) и актерах (Stars). Ключевые атрибуты названных множеств сущностей подчеркнуты. В качестве ключевых атрибутов для множеств Stars и Studios выбраны атрибуты пате ("имя" или "название") — это решение мы обсуждали в примере 2.19 на с. 75. Рис. 2.17. На ER-диаграмме атрибуты-ключи отмечаются подчеркиванием Ключ для множества сущностей Movies сформирован на основе совокупности атрибутов title ("название") и year ("год производства"). Атрибуты, наименования которых подчеркнуты, являются членами ключа. Для описания ситуации, когда множество сущностей снабжено несколькими альтернативными ключами, специальных обозначений, однако, не существует; мы подчеркиваем только первичные ключи (primary keys). Следует упомянуть и тот довольно необычный случай, когда атрибуты, образующие ключ для некоторого множества сущностей, не обязательно принадлежат этому множеству (подобные вопросы, имеющие отношение к так называемым слабым множествам сущностей (weak entity sets), мы обсудим в разделе 2.4 на с. 81). 2.3.4. Ограничения уникальности Важным свойством некоторого объекта базы данных зачастую является то, что он может описываться не более чем одним значением. Так, например, конкретной сущности "кинофильм" соответствуют строго определенные значения атрибутов "название", "год производства", "продолжительность" и "тип", а "владеет" кинофильмом только одна "киностудия". Существует несколько ситуаций, в которых ограничения уникальности (single-value constraints) проявляют себя в рамках ER-модели. 1. Некоторый атрибут множества сущностей обладает единственным значением. Иногда допускается отсутствие значения атрибута для отдельных сущностей множества, и в подобных случаях приходится "изобретать" какое-то "нулевое" значение, используемое по умолчанию. Для примера можно представить ситуацию, 2.3. МОДЕЛИРОВАНИЕ ОГРАНИЧЕНИЙ 77
когда для некоторых кинофильмов, сведения о которых занесены в базу данных, информация о продолжительности их воспроизведения неизвестна. Значением атрибута length в таком случае могло бы быть, скажем, —1. С другой стороны, допускать отсутствие значений ключевых атрибутов, таких как title ("название") и year ("год производства"), нельзя. Требование о том, что некоторый атрибут не может иметь неопределенных значений вида null, в ER-модели не имеет специальных средств представления. Если необходимо описать подобное ограничение, можно снабдить атрибут дополнительным текстовым пояснением. 2. Связь R типа "многие к одному", соединяющая множества сущностей Е и F в направлении от Е к F, подразумевает наличие ограничения уникальности. Другими словами, для каждой сущности е множества Е имеется не более одной связанной с ней сущности / множества F. Или, в общем случае, если R представляет собой многостороннюю связь, тогда каждая из стрелок, "выходящая" из R, выражает ограничение уникальности. В частности, если существует стрелка, соединяющая связь R с множеством сущностей Е, в составе Е имеется не более одной сущности, ассоциированной с определенным набором сущностей из всех остальных множеств, охватываемых связью R. 2.3.5. Ограничения ссылочной целостности Если ограничения уникальности (single-value constraints) декларируют возможность существования не более одного значения, выступающего в определенной роли, ограничения ссылочной целостности (referential integrity constraints) подразумевают наличие в точности одного такого значения. Требование о том, чтобы атрибут обладал единственным возможным значением, отличным от null, можно рассматривать как разновидность ограничений ссылочной целостности, но чаще последние используются для описания свойств связей между множествами сущностей. Рассмотрим связь Owns ("владеет"), соединяющую множества сущностей Movies ("кинофильмы") и Studios ("киностудии") так, как показано на рис. 2.2 (см. с. 54). Связь Owns относится к типу "многие к одному" и предполагает только то, что ни один из кинофильмов не может принадлежать нескольким студиям одновременно. Связь — в том виде, как она задана — отнюдь не подразумевает, что кинофильмом определенно должна владеть какая-либо студия, а если это даже и так, студия вовсе не обязана быть представлена во множестве сущностей Studios. Ограничение ссылочной целостности в контексте связи Owns предусматривает, что для каждой сущности "кинофильм" в базе данных должна присутствовать соответствующая сущность "киностудия", на которую "кинофильм" ссылается. Существует несколько способов поддержки условий ссылочной целостности. Мы рассмотрим их ниже на примере связи Owns. 1. Если база данных пополняется новой сущностью "кинофильм", обязана существовать (или должна быть добавлена) и соответствующая сущность "киностудия". Помимо того, если значение экземпляра связи Owns (ссылка на множество сущностей Studios) для конкретного "кинофильма" изменяется, необходимо гарантировать, что новое значение ссылки также является сущностью множества Studios. 2. Следует запретить удаление сущностей множества Studios, адресуемых сущностями множества Movies. Другими словами, некоторая сущность "киностудия" не может быть удалена до тех пор, пока имеются сущности "кинофильм", которые на нее ссылаются. 3. Если сущность множества Studios подлежит принудительному удалению, должны быть удалены также все сущности множества Movies, ссылающиеся на нее. 78 ГЛАВА 2. МОДЕЛЬ ДАННЫХ "СУЩНОСТЬ-СВЯЗЬ"
Аспекты практической реализации ограничений ссылочной целостности относятся к компетенции определенной СУБД или конкретного проекта базы данных, поэтому здесь мы не будем останавливаться на них подробно. 2.3.6. Ссылочная целостность и ER-диаграммы Правила применения стрелок в ER-диаграммах могут быть расширены с целью обеспечения возможности отображения ограничений ссылочной целостности связей в одном или нескольких направлениях. Предположим, что R — это связь, соединяющая множества сущностей Е и F в направлении от Е к F. Тогда полукруглая стрелка, указывающая на F, не только свидетельствует о том, что связь, соединяющая множества Е и F, относится к типу "многие к одному" или "один к одному", но и отображает требование обязательного наличия в F сущности, на которую ссылается определенная сущность из Е. Те же соображения применимы и к случаю, когда R соединяет между собой более двух множеств сущностей. Пример 2.21. На рис. 2.18 обозначены несколько ограничений ссылочной целостности, заданных для связей Owns ("владеет") и Runs ("возглавляет"), которые соединяют множества сущностей Movies ("кинофильмы"), Studios ("киностудии") и Presidents ("президенты"). Названные связи и множества сущностей были впервые введены на диаграммах рис. 2.2 (см. с. 54) и 2.3 (см. с. 56). Полукруглая стрелка, соединяющая связь Owns с множеством сущностей Studios, выражает ограничение ссылочной целостности, которое подразумевает, что каждым кинофильмом должна владеть одна определенная студия и соответствующая сущность "киностудия" обязана присутствовать в составе множества Studios. Presidents Рис. 2.18. ER-диаграмма с обозначениями ограничений ссылочной целостности Аналогично, полукруглая стрелка, указывающая на множество Studios со стороны связи Runs, обозначает ограничение ссылочной целостности, которое заключается в том, что каждый президент возглавляет одну студию и соответствующая сущность "киностудия" должна наличествовать во множестве Studios. Обратите внимание, связь Runs по-прежнему соединена с множеством сущностей Presidents обычной (а не полукруглой) стрелкой, поскольку она отображает вполне естественную закономерность взаимоотношений сущностей "президент" и "киностудия". Если студия прекращает свое существование, ее президент более не может занимать свой пост, и поэтому резонно ожидать, что соответствующая сущность "президент" должна быть удалена из множества Presidents', здесь проявляет себя ограничение ссылочной целостности. С другой стороны, удаление сущности "президент", как подсказывает здравый смысл, не должно оказывать влияния на содержимое множества Studios, поскольку в какие-то периоды времени студия может обходиться без руководителя. Поэтому связь Runs и множество сущностей Presidents соединены обычной стрелкой: каждая студия может возглавляться не более чем одним президентом, а в каких-то случаях президента может не быть вовсе. □ 2.3.7. Ограничения других видов В начале раздела 2.3, помимо ключей, ограничений уникальности и ссылочной целостности, мы упоминали и другие ограничения, которые могут быть предусмотрены в схеме базы данных. Здесь мы только вкратце остановимся на вопросах задания произвольных ограничений и более подробно осветим их в главе 7 на с. 317. 2.3. МОДЕЛИРОВАНИЕ ОГРАНИЧЕНИЙ 79
Ограничения домена (domain constraints) предполагают, что значения атрибута должны выбираться из определенного конечного множества или принадлежать ограниченному диапазону изменения. Простой пример использования ограничений домена связан с объявлением типа атрибута. Более строгое ограничение предусматривает определение некоторого перечислимого типа атрибута либо диапазона значений. Так, например, значение атрибута length ("продолжительность") множества сущностей Movies было бы уместно задавать в виде целого числа, выраженного в минутах и принадлежащего интервалу от 0 до 240. ER-модель не содержит специальных выразительных средств, позволяющих описать ограничения домена, но не запрещает размещать на диаграмме вместе с атрибутом необходимые текстовые примечания. Существуют и иные разновидности ограничений, которые нельзя отнести ни к одной из категорий, рассмотренных выше. Вполне вероятна, например, такая ситуация, когда следует ограничить количество возможных сочетаний сущностей множеств, охватываемых определенной связью (скажем, одна сущность "кинофильм" должна быть соединена не более чем с десятью сущностями "актер"). ER-модель позволяет включить в диаграмму соответствующее ограничивающее значение, поместив его в непосредственной близости от линии, соединяющей связь и множество сущностей, как на рис. 2.19. Movies <=10 Stars Рис. 2.19. Так обозначается ограничение на количество сущностей- "актеров", сея- занных с определенной сущностью-"кинофильмом " Пример 2.22. На рис. 2.19 показан пример ограничения на число сущностей множества Stars ("актеры"), связанных с определенной сущностью множества Movies ("кинофильмы"). Развивая мысль, мы могли бы сказать, что обычная стрелка между связью типа "... к одному" и множеством сущностей равнозначна ограничению вида "<= 1", а полукруглая стрелка (см. рис. 2.18), применяемая для обозначения условий ссылочной целостности, —- ограничению "= 1". □ 2.3.8. Упражнения к разделу 2.3 Упражнение 2.3.1. Обратившись к ER-диаграммам, построенным вами при решении заданий из упражнений *а) 2.1.1 (см. с. 63); b) 2.1.3 (см. с. 64); c) 2.1.6 (см. с. 65), выполните следующее: i) выберите и обозначьте ключевые атрибуты для каждого множества сущностей; и) отметьте ограничения ссылочной целостности, если таковые необходимы. ! Упражнение 2.3.2. Вполне допустимо представить, что связи в ER-модели способны обладать ключами точно так же, как и множества сущностей. Пусть R является связью, соединяющей множества сущностей Еь Ег,..., Еп. Тогда ключ для R — это множество К атрибутов, выбранных из наборов атрибутов множеств Е[у £2,..., Еп таким образом, что если (eh еь ..., еп) и (/i,/2, ...,/л) представляют собой два различных кортежа множества данных связи R, то совпадение этих кортежей во всех атрибутах К невозможно. Пусть также для каждого i tf, представляет множество атрибутов, служащих ключами множества сущностей £,. Теперь предположим, что п = 2, т.е. R является бинарной связью. Создайте наименьший возможный ключ для R при условии, что 80 ГЛАВА 2. МОДЕЛЬ ДАННЫХ "СУЩНОСТЬ-СВЯЗЬ
a) R относится к типу "многие ко многим"; * b) R представляет связь типа "многие к одному" от Ех к Е2\ c) R представляет связь типа "многие к одному" от Е2 к Е{; d) R относится к типу "один к одному". !! Упражнение 2.3.3. Вновь рассмотрим задание упражнения 2.3.2, но теперь позволим параметру п принимать произвольные значения, а не только значение 2. Обладая информацией о том, какие линии от R к Е{ снабжены стрелками, покажите, каким образом найти наименьший возможный ключ К для R в терминах К,. ! Упражнение 2.3.4. Приведите реальные образцы атрибутов (отличные от упомянутых в примере 2.20 на с. 76), которые созданы преимущественно для использования в роли ключей множеств сущностей. 2.4. Слабые множества сущностей Изредка обстоятельства складываются так, что ключ для некоторого множества сущностей (его называют слабым — weak entity set) приходится формировать на основе атрибутов, которые полностью или частично принадлежат другому множеству сущностей. 2.4.1. Примеры использования слабых множеств сущностей Существуют два основных источника, порождающих необходимость использования слабых множеств сущностей. Во-первых, иногда множества сущностей участвуют в иерархии, построенной на принципах, не имеющих отношения к связям isa (см. раздел 2.1.11 на с. 61). Если сущности множества Е представляют собой единицы более "крупных" сущностей множества F, вполне вероятна ситуация, когда атрибуты сущностей Е, претендующие на роль ключевых, не будут обладать свойством уникальности до тех пор, пока во внимание не приняты атрибуты сущностей F, которым "подчиняются" сущности Е. Проблема иллюстрируется несколькими примерами. Пример 2.23. Киностудия может состоять из нескольких творческих объединений. Пусть объединениям (назовем их Crews) в рамках киностудии даны условные названия, такие как, скажем, "crew 1", "crew 2" и т.д. Но в другой киностудии для нумерации объединений может быть принята совершенно такая же схема, так что атрибут number ("номер") уже нельзя считать ключевым. Чтобы обеспечить уникальность названия объединения среди подразделений всех киностудий, необходимо, наряду с его номером, учесть и наименование (пате) студии, которой это объединение принадлежит. Ситуация смоделирована на рис. 2.20. Ключом для слабого множества сущностей Crews служит совокупность двух атрибутов — собственного атрибута number множества Crews и атрибута пате уникальной сущности-"киностудии", с которой сущность- "объединение" соотносится посредством связи Unit-of ("подразделение").6 □ Рис. 2.20. Так отображаются слабые множества сущностей и соответствующие связи 6 Правила употребления в ER-диаграммах двойных прямоугольников и ромбов разъяснены в разделе 2.4.3 на с. 84. 2.4. СЛАБЫЕ МНОЖЕСТВА СУЩНОСТЕЙ 81
Пример 2.24. Биологический вид принято обозначать совокупностью имен рода, к которому принадлежит этот вид, и собственного имени вида. Например, человек как биологическое существо относится к виду Homo sapiens, где Homo ("человек") — название рода, a sapiens ("разумный") — название вида. Род в общем случае состоит из нескольких видов, и полное наименование каждого из них включает название рода и уточняется названием вида. Названия видов, рассматриваемые отдельно, к сожалению, не уникальны. В составе двух или нескольких родов могут встретиться виды с одинаковыми собственными названиями. Поэтому для обеспечения уникальности сущности "вид" во множестве сущностей Species ("биологические виды") необходимо пользоваться полными именами видов, состоящими из собственного имени вида и названия соответствующей сущности "род" из множества сущностей Genera ("биологические роды"), с которой "вид" соединен связью Belongs-to ("принадлежит") (см. рис. 2.21). Таким образом, Species — это слабое множество сущностей, в состав ключа которого введен атрибут множества Genera, находящегося на более "высокой" ступени иерархии. □ > Genera Рис. 2.21. Еще одна ER-диаграмма, представляющая слабое множество сущностей Другая причина применения слабых множеств сущностей связана с механизмом соединяющих множеств сущностей (connecting entity sets) (см. раздел 2.1.10 на с. 60), который позволяет преобразовать ER-диаграмму, устраняя многосторонние связи.7 Соединяющие множества сущностей зачастую не содержат собственных атрибутов, поэтому ключи для таких множеств формируются на основе ключевых атрибутов других, связанных с ними множеств. Пример 2.25. На рис. 2.22 изображено соединяющее множество сущностей Contracts ("контракты"),, заменяющее собой одноименную тернарную связь, которая была рассмотрена в примере 2.5 на с. 56. Множество Contracts обладает собственным атрибутом salary ("размер заработной платы"), который, однако, не участвует в формировании ключа. Уникальная сущность "контракт" определяется совокупностью значений ключевых атрибутов пате ("имя" или "название") множеств Stars ("актеры") и Studios ("киностудии"), а также title ("название") и year ("год производства") множества Movies ("кинофильмы"). □ 2.4.2. Требования к слабым множествам сущностей К проблеме выбора ключевых атрибутов для слабых множеств сущностей надлежит подходить аккуратно и взыскательно. Если Е представляет собой слабое множество сущностей, его ключ может быть образован из 1) подмножества (возможно, пустого) собственных атрибутов; 2) ключевых атрибутов множеств сущностей, которые могут быть достигнуты посредством цепочки связей типа "многие к одному", соединяющих множество Е с другими множествами; подобные связи принято называть поддерживающими связями (supporting relationships) для множества Е. 7 ER-модель не содержит жестких требований относительно того, что многосторонние связи непременно должны быть преобразованы, хотя подобные условия предусмотрены в некоторых других моделях, применяемых для проектирования баз данных. 82 ГЛАВА 2. МОДЕЛЬ ДАННЫХ "СУЩНОСТЬ-СВЯЗЬ"
Рис. 2.22. Соединяющие множества сущностей "слабы" Чтобы некоторую связь R типа "многие к одному", соединяющую множества сущностей Е и F в направлении от Е к F, можно было отнести к числу поддерживающих связей для множества £", должны выполняться условия, перечисленные ниже. 1. Связь R должна быть бинарной связью типа "многие к одному"8, направленной от Е к F. 2. Связь R обязана предусматривать реализацию ограничения ссылочной целостности в направлении от Е к F. Другими словами, для каждой Е-сущности следует обеспечить наличие в базе данных соответствующей F-сущности, с которой Е-сущность соотносится посредством связи R, т.е. присутствие на диаграмме полукруглой стрелки, соединяющей R с F, должно быть подтверждено фактически. 3. Атрибуты, предоставляемые множеством F для образования ключа множества Е, должны быть ключевыми для F. 4. Если F, в свою очередь, также является слабым множеством сущностей, тогда некоторые или все ключевые атрибуты, поставляемые множеству Е, должны быть ключевыми атрибутами одного или нескольких множеств сущностей G, с которыми множество F соединено посредством поддерживающих связей. Если и G относится к числу слабых множеств, ключевые атрибуты по цепочке связей заимствуются у других множеств и т.д. 5. Если существует несколько различных поддерживающих связей, направленных со стороны Е к F, каждая связь для формирования ключа множества Е поставляет собственную копию ключевых атрибутов множества F. Заметим, что некоторая сущность е множества Е может быть связана с несколькими различными сущностями множества F посредством различных поддерживающих связей, направленных otEkF. Таким образом, сущность е множества Е может определяться ключевыми значениями, полученными от нескольких различных сущностей множества F. 8 Заметим, что связь "один к одному" является частным случаем связи типа "многие к одному". Когда мы говорим о том, что некоторая связь должна относиться к типу "многие к одному", мы подразумеваем и равную возможность существования связи "один к одному". 2.4. СЛАБЫЕ МНОЖЕСТВА СУЩНОСТЕЙ 83
Интуитивные доводы в пользу необходимости принятия названных условий таковы. Рассмотрим некоторую сущность, принадлежащую слабому множеству сущностей, такому как, скажем, Crews ("объединения") (см. пример 2.23 на с. 81). Каждая сущность "объединение" должна быть уникальной, чтобы ее можно было отличить от другой даже в том случае, если "объединения" обладают одним порядковым номером, но относятся к разным "киностудиям". Одного номера для решения задачи, однако, не достаточно. Следует провести поиск дополнительных значений, способных обеспечить уникальность сущностей множества Crews. К числу уникальных значений, тем или иным образом связанных с сущностями "объединение", относятся: 1) значения атрибутов самого множества Crews] 2) значения, которые можно получить на основе связей множества Crews с другими множествами; каждая подобная связь должна относиться к типу "многие к одному" (или, в частном случае, "один к одному") и соединять множество Crews с некоторым множеством F, а заимствованные множеством Crews атрибуты обязаны участвовать в образовании ключа множества F. 2.4.3. Система обозначений слабых множеств сущностей При обозначении на ER-диаграмме слабых множеств сущностей, их ключевых атрибутов и поддерживающих связей мы действуем в соответствии со следующими правилами. 1. Если множество сущностей является слабым, его принято изображать в виде двойного прямоугольника. Примерами могут служить множества сущностей Crews ("объединения") (см. рис. 2.20 на с. 81) и Contracts ("контракты") (см. рис. 2.22 на с. 83). 2. Поддерживающие связи типа "многие к одному" для слабых множеств сущностей обозначают двойными ромбами. В качестве примеров можно упомянуть связь Unit-of ("подразделение") (см. рис. 2.20) и все три связи диаграммы рис. 2.22. 3. Если в формировании ключа слабого множества сущностей участвуют его собственные атрибуты, их наименования подчеркиваются. На диаграмме рис. 2.20 атрибут number ("номер") является частью ключа множества сущностей Crews, хотя этим состав ключа не исчерпывается. Те же правила, но в лаконичной форме, могут быть представлены так. • "Если множество Е на диаграмме обозначено двойным прямоугольником, оно является слабым. Атрибуты множества £, отмеченные подчеркиванием (если таковые есть), в совокупности с ключевыми атрибутами тех множеств сущностей, с которыми Е соединено посредством связей типа "многие к одному", обозначенных двойными ромбами, образуют ключ множества Е\ Следует напомнить, что двойные ромбы применяются только для обозначения поддерживающих связей. Вполне возможно наличие в диаграмме связей типа "многие к одному", охватывающих слабые множества сущностей, но не относящихся к категории поддерживающих связей; такие связи отмечаются обычными (не двойными) ромбами. Пример 2.26. Изображенную на ER-диаграмме рис. 2.22 (см. с. 83) связь Studio-of не обязательно следует считать поддерживающей связью для множества сущностей Contracts ("контракты"), поскольку каждой сущности "кинофильм" соответствует строго определенная сущность "киностудия", определяемая не показанной здесь связью Owns ("владеет"), которая соединяет множества сущностей Movies ("кинофильмы") и Studios ("киностудии"). Поэтому для каждой конкретной пары сущностей 84 ГЛАВА 2. МОДЕЛЬ ДАННЫХ "СУЩНОСТЬ-СВЯЗЬ"
"актер—кинофильм" существует не более одного контракта с любой студией, оговаривающего условия участия актера в съемках фильма, и для обозначения связи Studio-of более уместно было бы вместо двойного ромба использовать обычный, одинарный. □ 2.4.4. Упражнения к разделу 2.4 * Упражнение 2.4.1. Один из способов представления сведений о студентах и оценках, полученных ими по завершении изучения тех или иных курсов, связан с созданием множеств сущностей "студенты", "курсы" и "регистрационные записи". Сущности "регистрационные записи" формируют множество, "соединяющее" множества "студенты" и "курсы", которое может быть использовано не только для регистрации того факта, что определенный студент сдал экзамен по конкретному курсу, но и для хранения данных о полученных студентами оценках. Начертите ER-диаграмму, представляющую описанную ситуацию, и отметьте на ней слабые множества сущностей и ключи для всех множеств. Является ли атрибут "оценка" частью ключа для множества сущностей "регистрационные записи"? Упражнение 2.4.2. Дополните решение упражнения 2.4.1 таким образом, чтобы обеспечить хранение промежуточных оценок, получаемых студентом в процессе изучения курса. Вновь отметьте на диаграмме слабые множества сущностей и ключи для всех множеств. Упражнение 2.4.3. Обратившись к ER-диаграммам, представляющим решения заданий упражнения 2.2.6 (а)—(с) (см. с. 73), отметьте слабые множества сущностей, поддерживающие связи и ключи. Упражнение 2.4.4. Постройте ER-диаграммы, описывающие ситуации с участием слабых множеств сущностей, перечисленные ниже. Отметьте на каждой диаграмме ключи для всех множеств сущностей. а) Даны множества сущностей Courses ("курсы") и Departments ("факультеты"). Каждый курс читается на строго определенном факультете, но обладает единственным атрибутом number ("номер"). Различные факультеты вправе предлагать курсы с одинаковыми номерами. Каждому факультету соответствует уникальное значение атрибута пате ("название"). *! Ь) Даны множества сущностей Leagues ("лиги"), Teams ("команды") и Players ("игроки"). Лиги обладают уникальными названиями. В составе лиги нет двух команд с одинаковыми наименованиями, а в команде — игроков с одним и тем же номером. Однако в пределах нескольких команд могут совпадать номера игроков, а в нескольких лигах допускается наличие команд с одинаковыми наименованиями. 2.5. Резюме ♦ Модель "сущность—связь", или ER-модель, используется для представления множеств сущностей, связей между ними, а также атрибутов множеств и связей. ♦ Диаграмма сущностей и связей. При построении диаграммы сущностей и связей, или ER-диаграммы, для описания множеств сущностей, связей и атрибутов применяются соответственно прямоугольники, ромбы и овалы. ♦ Множественность связей. Бинарные связи могут относиться к типам "один к одному", "многие к одному" или "многие ко многим". Связь "один к одному" соединяет некоторую сущность множества не более чем с одной сущностью другого множества. Связь "многие к одному" соединяет любую сущность множества, указанного на стороне "многие", не более чем с одной сущностью множества, заданного на противоположной стороне соединения. Связи типа 2.5. РЕЗЮМЕ 85
"многие ко многим' не ограничивают свойство множественности взаимоотношений соединяемых множеств сущностей. ♦ Ключи. Ключом для множества сущностей называется набор атрибутов, значения которых уникальным образом определяют сущность во множестве однородных сущностей. ♦ Принципы проектирования. Чтобы достичь успеха при проектировании базы данных, следует обеспечить достоверность представления сведений об объектах реального мира, выбрать подходящие инструменты моделирования (т.е. верно использовать элементы множеств сущностей, связей и атрибутов) и избежать избыточности (представления некоторых сущностей дважды либо описания их неоднозначными и сложными средствами). ♦ Ссылочная целостность. Ограничение ссылочной целостности подразумевает, что сущность, на которую ссылается некоторая другая сущность, обязана присутствовать в базе данных. ♦ Подклассы. ER-модель предлагает возможность использования связей специальной разновидности, isa, для представления того факта, что одно множество сущностей является некоторым подмножеством другого. Множества сущностей, соединенные связями isa, могут образовывать древовидную иерархию, а их элементы — обладать компонентами, принадлежащими любому поддереву дерева иерархии, включающему корневую вершину. ♦ Слабые множества сущностей. ER-модель позволяет представлять такие множества сущностей, ключи которых полностью или частично основаны на ключевых атрибутах других, связанных, множеств. Для описания слабых множеств сущностей в ER- диаграммах применяются специальные обозначения — двойные прямоугольники. 2.6. Литература Самое первое описание модели "сущность—связь" приведено в работе [2]. Современные достижения в области ER-моделирования отражены в книгах [1] и [3]. 1. Batini Carlo, Ceri S., Navathe S.B., and Batini Carol. Conceptual Database Design: an Entity/Relationship Approach, Addison-Wesley, Reading, MA, 1991. 2. Chen P.P. The entity-relationship model: toward a unified view of data, ACM Trans, on Database Systems, 1:1 (1976), p. 9-36. 3. Thalheim B. Fundamentals of Entity-Relationship Modeling, Springer- Verlag, Berlin, 2000. 86 ГЛАВА 2. МОДЕЛЬ ДАННЫХ "СУЩНОСТЬ-СВЯЗЬ1
Глава 3 Реляционная модель Хотя подход к проектированию баз данных, который связан с моделью "сущность- связь" (ее называют также ER-моделью), рассмотренной в главе 2 на с. 51, предлагает простые и адекватные средства описания структур данных, современные образцы баз данных почти всецело основываются на иных принципах, в совокупности называемых реляционной моделью (relational model). Реляционная модель крайне проста и плодотворна, поскольку основана чуть ли не на единственном основном понятии отношения (relation). Отношение — это двумерная таблица, предназначенная для упорядоченного хранения данных. В главе 6 на с. 249 будет рассказано о том, как в рамках реляционной модели поддерживается весьма высокоуровневый язык программирования, сокращенно называемый SQL (от Structured Query Language — язык структурированных запросов). Благодаря языку SQL можно создавать простые, но чрезвычайно мощные программы, позволяющие манипулировать данными, хранящимися в отношениях, самыми различными способами. ER-модель, напротив, нельзя считать пригодной для использования в качестве основы какого-либо языка управления данными. С другой стороны, проектировать базы данных зачастую легче именно в терминах ER-модели. Таким образом, наша первая задача состоит в том, чтобы рассказать, как проект базы данных, оформленный по правилам ER-моделирования, может быть преобразован в набор отношений. Затем вы узнаете, что реляционная модель реализует собственную теорию проектирования. Эта теория, обычно сводимая к правилам нормализации (normalization) отношений, основывается преимущественно на концепции функциональных зависимостей (functional dependencies), которая включает и расширяет понятие ключа (key), рассмотренное нами неформально в разделе 2.3.2 на с. 75. Практическое применение правил нормализации позволяет существенно улучшить структуру отношений, представляющих конкретную предметную область, подлежащую моделированию. 3.1. Основы реляционной модели Реляционная модель предусматривает единственный способ представления данных — в виде набора двумерных таблиц, называемых отношениями (relations). На рис. 3.1 приведен пример отношения. Наименование отношения — Movies, и предназначено оно для хранения информации об элементах множества сущностей Movies ("кинофильмы"), рассматриваемого в контексте знакомого вам по главе 2 (см. с. 51) проекта "кинематографической" базы данных, который мы будем развивать и далее. Каждая строка отношения Movies отвечает одной сущности "кинофильм", а каждый
столбец — одному из атрибутов множества сущностей Movies. Впрочем, отношения позволяют отображать не только множества сущностей, и об этом мы расскажем ниже. title Star Wars Mighty Ducks Wayne's World year 1977 1991 1992 length 124 104 95 filmType color color color Рис. 3.1. Отношение Movies 3.1.1. Атрибуты В верхней части таблицы-отношения задается перечень наименований атрибутов (attributes): так, на рис. 3.1 атрибутами являются title, year, length и filmType. Атрибуты отношения выполняют функцию наименований его столбцов и содержательно описывают смысл и назначение элементов данных, располагаемых в соответствующих ячейках. Например, в столбце с атрибутом length хранятся целочисленные данные о продолжительности воспроизведения каждого кинофильма, выраженной в минутах. Обратите внимание, что атрибуты отношения Movies, представленного на рис. 3.1, — это те же атрибуты, которыми обладает множество сущностей Movies. Позже мы покажем, что преобразование некоторого множества сущностей в отношение с тем же набором атрибутов — это весьма распространенная операция. В общем случае, однако, требований о том, чтобы атрибуты некоторого отношения обязательно соответствовали определенным компонентам ER-модели, не существует. 3.1.2. Схемы Наименования отношения и атрибутов этого отношения в совокупности называют схемой (schema) отношения. Схема отношения представляется в виде имени отношения, за которым следует список имен атрибутов, заключенный в круглые скобки. Например, схема отношения Movies, изображенного на рис. 3.1, может выглядеть так: Movies(title, year, length, filmType). Атрибуты схемы отношения образуют на самом деле множество, а не упорядоченный список. Однако, чтобы облегчить работу с отношениями, часто бывает полезно принять некий "стандартный" порядок следования их атрибутов. Поэтому всякий раз, когда приводится схема отношения со списком атрибутов (как в примере выше), мы подразумеваем определенный "стандартный" порядок перечисления атрибутов, позволяющий однозначно задавать любые кортежи данных этого отношения. Проект базы данных, выполненный в рамках реляционной модели, включает одну или несколько схем отношений. Набор схем отношений называют реляционной схемой базы данных (relational database schema), или просто схемой базы данных (database schema). 3.1.3. Кортежи Строки отношения, отличные от той, которая представляет наименования атрибутов, называют кортежами (tuples). Кортеж содержит по одному компоненту (component) для каждого атрибута отношения. Например, первый из трех кортежей отношения Movies, изображенных на рис. 3.1, включает четыре компонента, star Wars, 1977, 124 и color, которые соответствуют атрибутам title, year, length и filmType. Если необходимо описать кортеж отдельно, вне контекста отношения, принято заключать его в круглые скобки и разделять компоненты символом запятой. Первый кортеж отношения Movies можно задать следующим образом: (Star Wars, 1977, 124, color). 88 ГЛАВА 3. РЕЛЯЦИОННАЯ МОДЕЛЬ
Если кортеж представляется так, как показано выше, видимая связь компонентов с атрибутами утрачивается, поэтому следует непременно указывать, к какому отношению принадлежит данный кортеж, и перечислять его компоненты в том "стандартном" порядке, который зафиксирован в схеме отношения. 3.1.4. Домены Одно из требований, выдвигаемых реляционной моделью, гласит, что каждый компонент кортежа должен быть атомарным, т.е. относиться к некоторому базовому типу, такому как целочисленный или строковый. В качестве значений компонентов кортежа не разрешается использовать записи, множества, списки, массивы или иные составные объекты, которые допускают естественное разбиение на более мелкие элементы. Помимо того, предполагается, что с каждым атрибутом отношения ассоциирован определенный домен (domain), т.е. некоторый базовый тип. Значения компонентов всех кортежей должны принадлежать соответствующим доменам, определяемым каждым из атрибутов отношения. Вновь для примера обратимся к отношению Movies, показанному на рис. 3.1. Первые компоненты всех кортежей отношения Movies должны быть строками, вторые и третьи — целыми числами, а четвертые обязаны содержать одну из двух допустимых строковых констант, color или blackAndWhite. Домены являются частью схемы отношения (мы отложим обсуждение вопросов, касающихся средств описания доменов в схемах отношений, до раздела 6.6.2 на с. 297). 3.1.5. Формы представления отношений Отношения — это множества (но не упорядоченные списки!) кортежей. Порядок, в котором кортежи перечисляются в пределах отношения, не существен. Вполне возможно, например, переставить кортежи отношения Movies, показанного на рис. 3.1, любым из шести различных способов, но это никоим образом не повлияет на его содержимое. Более того, допускается без каких-либо последствий изменять и порядок задания атрибутов отношения. Если, однако, реляционная схема отношения подвергается упорядочению, необходимо помнить, что наименования атрибутов являются заголовками столбцов отношения. Поэтому, изменяя порядок перечисления атрибутов, мы должны позаботиться и о соответствующем упорядочении столбцов отношения. При перемещении столбцов изменится и взаимное положение компонентов кортежей. В результате каждый компонент кортежа займет то же место, что и соответствующий ему атрибут. На рис. 3.2 показан один из многочисленных вариантов представления отношения Movies, получаемых при перемещении его строк и столбцов. Все возможные версии таблицы рис. 3.1 (включая и ту, которая изображена на рис. 3.2) по существу являются различными формами, в которых допустимо изображать отношение Movies. year 1991 1992 1977 title Mighty Ducks Wayne's World Star Wars film Type color color color length 104 95 124 Рис. 3.2. Другая форма представления отношения Movies 3.1.6. Экземпляры отношения Отношение, содержащее информацию о кинофильмах, по своей природе не является статичным; этому и большинству других отношений со временем свойственно меняться. Изменения обычно затрагивают содержимое отношения: в базу данных помещаются новые кортежи (например, представляющие сведения о новинках кинема- 3.1. ОСНОВЫ РЕЛЯЦИОННОЙ МОДЕЛИ 89
тографии), а также модифицируются (при поступлении дополнительной уточняющей информации) или удаляются (по самым разным причинам) существующие. Гораздо менее вероятны такие изменения, которые затрагивают схему отношения. Однако ситуации, связанные с необходимостью добавления, изменения или удаления атрибутов отношения, иногда все же возникают. Операции по изменению схемы реальных баз данных обычно весьма дорогостоящи, поскольку подразумевают просмотр и модификацию миллионов кортежей. Например, при добавлении нового атрибута задача отыскания подходящих значений для новых компонентов существующих кортежей может оказаться весьма трудоемкой или даже вовсе неразрешимой. Конкретное множество кортежей отношения называют экземпляром (instance) отношения. Например, набор из трех кортежей, показанный на рис. 3.1 (см. с. 88), образует некоторый экземпляр отношения Movies. Ясно, что отношение, подобное Movies, могло претерпевать изменения раньше и будет подвержено изменениям впредь. Скажем, в 1980 году отношение Movies не могло содержать кортежей для таких кинофильмов, как Mighty Ducks или Wayne ' s World (их просто еще не было). Традиционные системы баз данных обычно поддерживают только одну версию любого отношения: набор кортежей, которые содержатся в отношении "в данный момент". Такой экземпляр отношения принято называть текущим экземпляром (current instance). 3.1.7. Упражнения к разделу 3.1 Упражнение 3.1.1. На рис. 3.3 показаны два отношения — Accounts ("счета") и Customers ("клиенты"), — которые могут служить частью базы данных банка. Назовите или изобразите следующее: a) атрибуты каждого отношения; b) кортежи каждого отношения; c) компоненты одного кортежа из каждого отношения; d) реляционную схему каждого отношения; e) схему базы данных; f) домен, соответствующий каждому атрибуту; g) альтернативный способ представления каждого отношения. acctNo 12345 23456 34567 type savings checking savings balance 12000 1000 25 Отношение Accounts firstName Robbie Lena Lena lastName Banks Hand Hand idNo 901-222 805-333 805-333 account 12345 12345 23456 Отношение Customers Рис. 3.3. Два отношения банковской базы данных !! Упражнение 3.1.2. Каким числом способов (зависящих от порядка следования атрибутов и кортежей) может быть представлен экземпляр отношения, если он включает: 90 ГЛАВА 3. РЕЛЯЦИОННАЯ МОДЕЛЬ
* а) три атрибута и три кортежа (подобно отношению Accounts, изображенному на рис. 3.3)? b) четыре атрибута и пять кортежей? c) п атрибутов и т кортежей? 3.2. От ER-диаграмм к реляционным схемам Рассмотрим процесс создания новой базы данных, подобной рассматриваемой нами базе данных о кинофильмах. На первой стадии процесса, связанной с проектированием, необходимо сформулировать следующие вопросы и найти ответы на них: какая информация должна быть представлена в базе данных; каким образом элементы данных соотносятся друг с другом; какие ограничения (например, ключи и условия ссылочной целостности) должны быть введены и т.д. Эта стадия может протекать в течение длительного времени, пока все альтернативные варианты не будут рассмотрены и сопоставлены, а все мнения — учтены и согласованы. За стадией проектирования следует стадия реализации, предусматривающая использование инструментов конкретной системы управления базами данных. Поскольку подавляющее большинство коммерческих систем баз данных основано на реляционной модели, уместно предположить, что в ходе проектирования было бы целесообразно применять ту же модель, а не модель "сущность—связь" или любые другие средства проектирования. На практике, однако, зачастую проще приступить к проектированию, пользуясь ER- или другой аналогичной моделью, осуществить задуманное, а затем преобразовать результат в реляционную модель. Основной довод в пользу такого подхода связан с тем, что реляционная модель, основанная на единственном понятии "отношения", а не на совокупности различных взаимодополняющих понятий (таких как "множество сущностей" и "связь" в ER-модели), обладает определенными ограничениями в смысле гибкости, которые проще "обойти" уже по завершении начальной стадии проектирования. В первом приближении процесс "превращения" ER-диаграммы в реляционную схему довольно прямолинеен: • преобразовать каждое множество сущностей в отношение с тем же набором атрибутов; • заменить каждую связь отношением, атрибуты которого являются ключами множеств сущностей, соединяемых этой связью. Хотя названные правила охватывают изрядную часть предмета, существует несколько особых ситуаций, с которыми приходится считаться. 1. Слабые множества сущностей (weak entity sets) не могут быть преобразованы в отношения непосредственно. 2. Связи isa и подклассы (subclasses) требуют специального подхода. 3. Иногда целесообразно объединить в составе одного отношения два других — например, отношение для множества сущностей Е с отношением для связи типа "многие к одному", которая соединяет Е с другими множествами. 3.2.1. От множеств сущностей к отношениям Вначале рассмотрим множества сущностей, не относящиеся к категории слабых. (О том, как справляться со слабыми множествами сущностей, мы расскажем в разделе 3.2.4 на с. 96.) Для каждого множества сущностей, не являющегося слабым, можно создать отношение с теми же именем и набором атрибутов. Такое отношение не будет содержать каких бы то ни было сведений о связях, в которых участвует исходное множество сущностей; информация о связях отображается в отдельных отношениях (этот вопрос освещен в разделе 3.2.2 на с. 93). 3.2. ОТ ER-ДИАГРАММ К РЕЛЯЦИОННЫМ СХЕМАМ 91
Схемы и экземпляры Давайте не будем забывать об основном различии между схемой отношения и экземпляром отношения. Схема включает наименование и перечень атрибутов и считается относительно более устойчивым объектом. Экземпляр состоит из набора кортежей отношения и, как правило, подвержен частым изменениям. В процессе моделирования данных различия между схемой и экземпляром отношения отчетливо себя проявляют. Описания множеств сущностей и связей — это средства представления схемы в ER-модели, а множества сущностей и данных связей как таковые — это экземпляры схемы. Экземпляр базы данных не является частью ее дизайна: в процессе проектирования мы можем только предполагать, какие конкретные образцы данных будут в ней храниться. Пример 3.1. Рассмотрим три множества сущностей — Movies ("кинофильмы"), Stars ("актеры") и Studios ("киностудии") — ER-диаграммы рис. 2.17 (см. с. 77), которая в том же виде воспроизведена на рис. 3.4. Атрибутами множества Movies, например, являются title ("название"), year ("год производства"), length ("продолжительность") и film Type ("тип пленки"). Отношение Movies может выглядеть так, как оно представлено на рис. 3.1 (см. с. 88). Рис. 3.4. ER-диаграмма базы данных о кинофильмах Теперь обратимся к другому множеству сущностей, Stars. Оно обладает двумя атрибутами, пате ("имя") и address ("адрес"). Схема соответствующего отношения Stars может быть представлена как Stars (name, address), а его типичный экземпляр — как пате Carrie Fisher Mark Hamill Harrison Ford address 123 Maple St., Hollywood 456 Oak Rd., Brentwood 789 Palm Dr., Beverly Hills □ 92 ГЛАВА З. РЕЛЯЦИОННАЯ МОДЕЛЬ
Замечание по поводу качества примеров данных :—) Пытаясь представить примеры реальных данных в настолько точном виде, насколько это возможно, мы, тем не менее, вынуждены покривить душой, когда речь идет об адресах и другой информации личного характера, касающейся упоминаемых нами актеров. Не судите строго — мы не можем и не должны разглашать конфиденциальные сведения о людях, которые и без того у всех на виду. 3.2.2. От ER-связей к отношениям Связи ER-модели также представляются отношениями. Отношение для заданной связи R должно охватывать атрибуты, перечисленные ниже. 1. В схему отношения для связи R заносятся ключевые атрибуты каждого из множеств сущностей, соединяемых связью R. 2. Если связь обладает собственными атрибутами, они также вводятся в набор атрибутов отношения для этой связи. Если одно и то же множество сущностей в контексте связи упоминается многократно, в различных "ролях", каждый из его ключевых атрибутов вводится в отношение столько раз, в скольких ролях он участвует. При этом во избежание конфликтов имена атрибутов должны быть изменены. Переименование атрибутов выполняется, вообще говоря, в тех случаях, когда атрибуты с одинаковым именем встречаются в наборе атрибутов самой связи или среди атрибутов тех множеств сущностей, которые охватываются этой связью. Пример 3.2. Рассмотрим связь Owns ("владеет") ER-диаграммы рис. 3.4 (см. с. 92), соединяющую множества сущностей Movies ("кинофильмы") и Studios ("киностудии"). В схему отношения Owns для связи Owns мы введем ключевые атрибуты множеств сущностей, соединяемых связью Owns: title ("название") и year ("год производства") множества Movies и пате ("название") — множества Studios (наименование атрибута пате для ясности уместно изменить, скажем, на studioName). Схема отношения Owns примет следующий вид: Owns(title, year, studioName). А так может выглядеть типичный экземпляр отношения Owns: title Star Wars Mighty Ducks Wayne's World year 1977 1991 1992 studioName Fox Disney Paramount □ Пример 3.3. Связь Stars-in ("актеры-участники") ER-диаграммы рис. 3.4 подобным образом может быть преобразована в отношение с атрибутами title и year (служащими ключом для множества сущностей Movies) и атрибутом starName (аналогичным ключевому атрибуту пате множества Stars). На рис. 3.5 показан простой экземпляр отношения Stars-in. Поскольку названия кинофильмов в столбце title на рис. 3.5 выглядят как уникальный ключ, может показаться, что атрибут year избыточен. Однако, если в базу данных попадет информация о нескольких фильмах с одним и тем же названием (таким, например, как "King Kong"), атрибут year приобретет существенное значение, поскольку позволит определить, в каких именно версиях фильма снимался тот или иной актер. □ 3.2. ОТ ER-ДИАГРАММ К РЕЛЯЦИОННЫМ СХЕМАМ 93
title Star Wars Star Wars Star Wars Mighty Ducks Wayne's World Wayne's World year 1977 1977 1977 1991 1992 1992 starName Carrie Fisher Mark Hamill Harrison Ford Emilio Estevez Dana Carvey Mike Meyers Рис. 3.5. Экземпляр отношения Stars-in Stars Studio- 1 of-Star \ Contracts Studios Movies \ Producing- 1 Studio Рис. З.6. Связь Contracts Пример 3.4. Многосторонние связи также могут быть легко преобразованы в отношения. Рассмотрим четырехстороннюю связь Contracts ("контракты") диаграммы рис. 2.6 (см. с. 58), вновь воспроизведенной на рис. 3.6. Связь охватывает сущности "актер" (Stars), "кинофильм" (Movies) и две сущности "киностудия" (Studios). Роль Studio-of- Star отображает долговременный контракт актера с некоторой студией, a Producing- Studio — контракт, оговаривающий условия участия актера в съемках фильма, выпускаемого какой-либо другой студией. Связь Contracts представляется в виде отношения Contracts, схема которого состоит из следующих ключевых атрибутов: 1) атрибута starName, соответствующего ключу пате множества Stars; 2) атрибутов title и year ключа множества Movies; 3) атрибута studioofstar, содержащего название студии-"владельца" актера; напомним, что атрибут "название" мы выбрали в качестве ключа множества сущностей Studios; 4) атрибута producingStudio, содержащего название студии, которая выпускает фильм с участием приглашенного актера. Схема отношения Contracts, таким образом, примет вид Contracts(starName, title, year, studioOfStar, producingStudio). Обратите внимание — мы совершенно свободны в выборе имен атрибутов отношения: так, мы постарались избежать использования имени name, поскольку в противном случае было бы далеко не очевидно, на какой объект оно указывает — на имя актера или на название киностудии (тем более, что схема предусматривает задание двух атрибутов-названий киностудии). Кроме того, если рассматривать вариант многосторонней связи Contracts с собственными атрибутами — такой, например, как изображенный на диаграмме рис. 2.7 (см. с. 59), — эти атрибуты (в данном случае, salary) пришлось бы ввести и в схему отношения Contracts. □ 94 ГЛАВА 3. РЕЛЯЦИОННАЯ МОДЕЛЬ
3.2.3. Объединение отношений Иногда отношения, получаемые в результате прямых преобразований из множеств сущностей или связей, нельзя считать наилучшей формой представления определенных элементов данных. Один из распространенных вариантов подобных ситуаций таков. Имеется множество сущностей Е, соединенное посредством связи R типа "многие к одному" с множеством F в направлении от Е к F. Реляционные схемы каждого из отношений, полученных на основе множества Е и связи R, будут содержать ключ множества Е. Кроме того, в схему отношения для множества Е будут введены также атрибуты £, не относящиеся к ключевым, а в схему отношения для связи R — собственные атрибуты R и ключевые атрибуты множества F. Поскольку связь R относится к типу "многие к одному", все указанные атрибуты обладают значениями, которые однозначным образом определяются на основе ключа множества Е, и их можно объединить в одной схеме отношения, состоящей из: 1) всех атрибутов множества Е; 2) ключевых атрибутов множества F; 3) собственных атрибутов связи R. В кортеже для сущности е множества Е, которая не связана ни с одной сущностью множества F, компоненты, отвечающие атрибутам, названным в пп. 2, 3, получат некоторые "нулевые" (null) значения. О значениях null как о средстве представления ситуации, когда содержательное значение компонента кортежа неизвестно или утрачено, мы неформально уже говорили (см. раздел 2.3.4 на с. 77). Понятие "значение пи1Г не является частью реляционной модели, но в языке SQL для его обозначения применяется специальное служебное слово, null, и мы будем пользоваться им по мере необходимости,, если в ходе изложения нам потребуется сослаться на "неопределенное" значение. Пример 3.5. Возвращаясь к примеру "кинематографической" базы данных, отметим, что Owns — это связь типа "многие к одному", соединяющая множества сущностей Movies ("кинофильмы") и Studios ("киностудии") в направлении от Movies к Studios. Процесс "превращения" связи Owns в отношение рассматривался в примере 3.2 на с. 93, а преобразование множества сущностей Movies мы иллюстрировали в примере 3.1 на с. 92. Теперь мы вправе объединить полученные решения в общую реляционную схему отношения. Пример экземпляра такого отношения приведен на рис. 3.7. title Star Wars Mighty Ducks Wayne's World year 1977 1991 1992 length 124 104 95 frim Type color color color studioName Fox Disney Paramount Рис. 3.7. Объединение отношений Movies и Owns □ Стоит объединять отношения таким образом или нет — это вопрос, заслуживающий обсуждения. Сочетание всех атрибутов, зависящих от ключа множества сущностей Е, в едином отношении, в определенных случаях сулит дополнительные преимущества — даже тогда, когда существует сразу несколько связей типа "многие к одному", направленных от Е к другим множествам. Зачастую, например, гораздо проще получить ответ на запрос, касающийся данных, которые размещены в одном отношении, нежели обращаться за теми же данными одновременно к нескольким отношениям. Действительно, некоторые системы проектирования баз данных, основанные на ER-модели, выполняют подобное объединение автоматически. 3.2. ОТ ER-ДИАГРАММ К РЕЛЯЦИОННЫМ СХЕМАМ 95
С другой стороны, вероятно, не следует серьезно рассматривать возможность объединения отношения для множества Е с отношением для связи R, которая охватывает Е, но не является связью типа "многие к одному", направленной от Е к каким-либо другим множествам. Подобная операция довольно рискованна, поскольку нередко приводит к избыточности данных (эту тему мы обсудим в разделе 3.6 на с. 123). Пример 3.6. Чтобы продемонстрировать, чем отличается плохое решение от хорошего, рассмотрим объединение отношения, представленного на рис. 3.7, с отношением, полученным для связи Stars-in типа "многие ко многим" (см. рис. 3.5 на с. 94). Результат может выглядеть так, как показано на рис. 3.8. title Star Wars Star Wars Star Wars Mighty Ducks Wayne's World Wayne's World year 1911 1977 1977 1991 1992 1992 length 124 124 124 104 95 95 film Type color color color color color color studio Name Fox Fox Fox Disney Paramount Paramount starName Carrie Fisher Mark Hamill Harrison Ford Emilio Estevez Dana Carvey Mike Meyers Рис. 3.8. Отношение Movies, включающее сведения об актерах Поскольку в кинофильме могут сниматься несколько актеров, в кортежи для каждого из них приходится вводить одну и ту же информацию о кинофильме. Нетрудно заметить, например, что значение атрибута length ("продолжительность") — равно как и содержимое всех остальных атрибутов сущности-"кинофильма" "Star Wars" — повторяются три раза, по числу актеров, принимавших участие в съемках фильма. Подобные излишества явно нежелательны, и одна из целей, которые ставились при разработке теории проектирования реляционных баз данных, как раз и состоит в устранении информационной избыточности (за подробностями обращайтесь к разделу 3.6 на с. 123). □ 3.2.4. Преобразование слабых множеств сущностей Для преобразования слабого множества сущностей в отношение необходимо принять во внимание следующее. 1. Отношение для слабого множества сущностей W как такового должно включать не только собственные атрибуты W, но и ключевые атрибуты всех других множеств, содействующих в формировании ключа множества W. Подобные "вспомогательные" множества на ER-диаграмме легко различимы, поскольку они соединяются с W посредством поддерживающих связей, которые обозначаются двойными ромбами. 2. В отношении для любой связи, с которой соединено слабое множество сущностей W, должны быть отражены все ключевые атрибуты множества W, в том числе и те, которые "получены" им от других множеств. 3. Поддерживающая связь R, соединяющая слабое множество сущностей W с другим множеством, помогающим в образовании ключа для W, однако, вовсе не нуждается в преобразовании. Причина заключается в том, что (как упоминалось в предыдущем разделе ) атрибуты отношения для связи R типа "многие к одному" либо уже присутствуют в отношении для множества W, либо (если речь идет о собственных атрибутах R) могут быть объединены со схемой отношения для множества W. Разумеется, при формировании ключа слабого множества сущностей на основе дополнительных атрибутов надлежит позаботиться о том, чтобы не использовать одно 96 ГЛАВА 3. РЕЛЯЦИОННАЯ МОДЕЛЬ
и то же имя атрибута дважды. При необходимости некоторые или все подобные атрибуты следует переименовать. Пример 3.7. Рассмотрим слабое множество сущностей Crews ("объединения") ER- диаграммы рис. 2.20 (см. с. 81), которая воспроизведена на рис. 3.9. На основе диаграммы мы можем получить три отношения, схемы которых выглядят так: Studios(name, addr) Crews(number, studioName) Unit-of(number, studioName, name) Первое отношение, studios, создано непосредственно на основе одноименного множества сущностей, предназначенного для хранения информации о киностудиях. Второе отношение, Crews, соответствует слабому множеству сущностей Crews, представляющему творческие подразделения киностудий. Атрибутами Crews служат ключевые атрибуты множества Crews; если бы Crews обладало собственными неключевыми атрибутами, их также пришлось бы ввести в схему отношения Crews. Атрибут studioName отношения Crews суть атрибут пате множества сущностей Studios. Рис. 3.9. Пример ER-диаграммы со слабым множеством сущностей Третье отношение, Unit-of, соответствует связи Unit-of. Связь в реляционной модели, как мы говорили выше, представляется отношением, в схему которого вводятся ключевые атрибуты множеств, соединяемых этой связью. В нашем случае схема отношения Unit-of включает атрибуты number й studioName, образующие ключ слабого множества сущностей Crews, и атрибут name — аналог атрибута пате множества Studios. Однако, поскольку связь Unit-of относится к типу "многие к одному", атрибуты studioName и name фактически совпадают. Предположим для примера, что "Disney-crew-#3" — это одно из творческих подразделений студии "Disney". Тогда во множестве данных для связи Unit-of должен существовать кортеж ("Disney-crew-#3", "Disney"), которому соответствует кортеж (3, Disney, Disney) отношения Unit-of. Обратите внимание, что компоненты этого кортежа, соответствующие атрибутам studioName и name, одинаковы, поэтому вполне допустимо осуществить их "слияние", что позволит получить более простую схему: Unit-of(number, name). Впрочем, теперь необходимость в использовании отношения Unit-of вовсе исключается, поскольку его схема полностью совпадает со схемой отношения Crews. □ Пример 3.8. Обратимся к слабому множеству сущностей Contracts ("контракты"), которое рассматривалось в примере 2.25 и было представлено на ER-диаграмме рис. 2.22 (см. с. 83). Та же диаграмма приведена и на рис. 3.10. Схема соответствующего отношения Contracts выглядит так: Contracts(starName, studioName, title, year, salary). 3.2. ОТ ER-ДИАГРАММ К РЕЛЯЦИОННЫМ СХЕМАМ 97
Подмножества схем отношений Изучая пример 3.7, вы могли бы сделать вывод о том, что коль скоро одно отношение (назовем его R) обладает набором атрибутов, являющимся подмножеством множества атрибутов другого отношения, 5, отношение R может быть исключено из рассмотрения. В общем случае такое утверждение неверно. Отношение R способно содержать информацию, которой нет в S, поскольку дополнительные атрибуты S не позволяют перейти от кортежа R непосредственно к кортежу S. Пусть, например, налоговая служба пытается (:-). — Прим. перев.) создать отношение People (name, ss#) ("люди"), которое содержит информацию об именах потенциальных налогоплательщиков и их кодах полисов социального страхования (или каких-либо иных идентификационных кодах) и охватывает даже такую ситуацию, когда человек не имеет доходов и его налоги прежде еще не фиксировались. Службе, вероятно, потребуется и отношение Taxpayers (name, ss#, amount ("налогоплательщики"), в котором отражаются суммы налогов, выплаченные каждым человеком в текущем году. Как нетрудно убедиться, схема отношения People является подмножеством схемы отношения Taxpayers, но смысл в хранении идентификационных номеров лиц, не "замеченных" в уплате налогов, т.е. упомянутых в People, но отсутствующих в Taxpayers, для вас, тем не менее, должен быть очевиден. На самом деле даже совершенно одинаковые наборы атрибутов отношений могут обладать различной семантикой, так что говорить о возможности замены одного отношения другим в общем случае нельзя. Примером могут служить отношения Stars (name, address) и Studios (name, address), представляющие объекты знакомой вам "кинематографической" базы данных. Хотя схемы выглядят одинаково, мы не имеем права превращать кортежи, описывающие информацию об актерах, в кортежи, содержащие данные о киностудиях, и наоборот. С другой стороны, если два отношения создаются на основе одной и той же конструкции с участием слабого множества сущностей, то из них, в котором меньше атрибутов, не будет иметь самостоятельного значения. Причина заключается в том, что кортежи отношения, соответствующего поддерживающей связи множества, однозначно совпадают с кортежами отношения, отображающего слабое множество сущностей как таковое. Таким образом, отношение для поддерживающей связи может быть безболезненно отброшено. Атрибуты starName и studioName — это переименованные ключевые атрибуты пате ("имя" или "название") множеств сущностей Stars ("актеры") и Studios ("киностудии") соответственно, title ("название") и year ("год производства") — ключевые атрибуты множества Movies ("кинофильмы"), a salary ("размер заработной платы") — собственный атрибут слабого множества сущностей Contracts. Создание отношений для поддерживающих связей Star-of, Studio-ofw Movie-of лишено смысла, поскольку их схемы представляют собой соответствующие подмножества схемы Contracts. Между прочим, обратите внимание, что построенное отношение совершенно совпадает с тем, какое мы могли бы получить, если бы взяли за основу ER-диаграмму рис. 2.7 (см. с. 59). Напомним, что последняя трактует контракты как трехсторонние связи между "актерами", "кинофильмами" и "киностудиями", а атрибут salary относится непосредственно к связи Contracts. □ Явление, проиллюстрированное в примерах 3.7 и 3.8 — связи, "поддерживающие" слабые множества сущностей, не нуждаются в создании соответствующих отношений, — носит универсальный характер. Ниже приведена новая версия правила преобразования в отношения тех множеств сущностей, которые относятся к категории слабых. 98 ГЛАВА 3. РЕЛЯЦИОННАЯ МОДЕЛЬ
Рис. 3.10. Слабое множество сущностей Contracts 1. Если W является слабым множеством сущностей, построить отношение для W, схема которого включает следующее: a) все атрибуты множества W; b) все атрибуты поддерживающих связей для множества W; c) все ключевые атрибуты каждого из множеств сущностей Е, соединенных с множеством W посредством поддерживающих связей типа "многие к одному" в направлении от W к Е\ 2. Не создавать отношения, соответствующие любым поддерживающим связям для слабого множества W. 3.2.5. Упражнения к разделу 3.2 * Упражнение 3.2.1. Преобразуйте ER-диаграмму рис. 3.11 в реляционную схему базы данных, имея в виду следующую семантику наименований множеств сущностей и атрибутов: Bookings— "заказы на билеты", row— "ряд", seat— "место", Customers — "пассажиры", SSNo — "код полиса социального страхования", phone — "номер телефона", addr — "адрес", пате — "имя", Flights — "рейсы", number — "номер", aircraft — "самолет", day— "дата вылета". ! Упражнение 3.2.2. Возможен иной вариант представления ER-диаграммы рис. 3.11 в части, касающейся слабого множества сущностей Bookings ("заказы на билеты"). Заметим, что сущность-"заказ" однозначно задается номером рейса, датой вылета и номерами ряда и места; для идентификации заказа информация о пассажире не нужна. a) Исправьте диаграмму рис. 3.11, чтобы отразить в ней указанные условия. b) Преобразуйте диаграмму, полученную при выполнении задания п. (а), в набор отношений и проверьте, совпадает ли он с тем, который вы построили, решая упражнение 3.2.1. 3.2. ОТ ER-ДИАГРАММ К РЕЛЯЦИОННЫМ СХЕМАМ 99
Рис. 3.11. ER-диаграмма базы данных системы бронирования авиабилетов Упражнение 3.2.3. ER-диаграмма рис. 3.12 представляет базу данных о кораблях (Ships). Корабли называют однотипными (sister), если они строятся по одним чертежам. Преобразуйте диаграмму в реляционную схему. Упражнение 3.2.4. Преобразуйте в реляционные схемы баз данных следующие ER-диаграммы: a) диаграмму рис. 2.22 (см. с. 83); b) результат решения упражнения 2.4.1 (см. с. 85); c) результат решения упражнения 2.4.4 (а) (см. с. 85); d) результат решения упражнения 2.4.4 (Ь). Рис. 3.12. ER-диаграмма, представляющая данные об однотипных кораблях 3.3. Преобразование структур подклассов в отношения Имея дело с иерархией множеств сущностей, соединенных связями isa, мы вправе выбрать одну из нескольких возможных стратегий преобразования ER-диаграмм в реляционные схемы. Напомним ряд положений. • Существует корневое множество сущностей иерархии. • Корневое множество сущностей обладает ключом, который используется для идентификации любой сущности из множеств, входящих в иерархию. • Сущность может содержать компоненты, принадлежащие множествам сущностей любого поддерева иерархии, если только это поддерево включает корневое множество. Основные стратегии преобразования таковы. 1. Применить подход "сущность—связь ". Для каждого множества сущностей Е иерархии создать отношение, содержащее ключевые атрибуты корневого множества сущностей и все атрибуты, принадлежащие Е. 2. Трактовать сущности как объекты одного класса. Для каждого возможного поддерева, включающего корневое множество сущностей, создать одно отношение, схема которого содержит все атрибуты всех множеств сущностей, принадлежащих поддереву. 100 ГЛАВА 3. РЕЛЯЦИОННАЯ МОДЕЛЬ
3. Использовать значения null. Создать одно отношение, включающее все атрибуты всех множеств сущностей, входящих в иерархию. Каждая сущность представляется одним кортежем, и компоненты кортежа, соответствующие тем атрибутам, которых сущность не имеет, принимают значения null. Указанные стратегии рассмотрены в следующих разделах. 3.3.1. Преобразование в стиле "сущность—связь" Первый из подходов к проблеме преобразования иерархии множеств сущностей, соединенных связями isa, в реляционную схему состоит в создании отношений для каждого множества сущностей (до сих пор мы так и поступали). Если множество сущностей Е не является корневым, отношение для Е должно содержать ключевые атрибуты корневого множества и все собственные атрибуты Е. Если, помимо того, множество Е соединено связью с другими множествами, ключевые атрибуты используются для идентификации сущностей из Е в отношении, представляющем эту связь. Заметим, однако, что, называя связь isa именно связью, мы, тем не менее, подразумеваем ее принципиальное отличие от других связей, поскольку связь isa соединяет компоненты единой сущности, а не различные сущности. Поэтому отдельные отношения для связей isa не создаются. К множеству сущностей Stars Рис. 3.13. Иерархия множеств сущностей, основанная на связях isa Пример 3.9. Рассмотрим ER-диаграмму рис. 2.10 (см. с. 62), заново воспроизведенную на рис. 3.13. Схемы отношений, необходимых для представления множеств сущностей, входящих в иерархию — Movies ("кинофильмы"), Cartoons ("мультипликация") и Murder-Mysteries ("боевики"), — указаны ниже. 1. Movies (title, year, length, filmType). Экземпляр этого отношения мы приводили на рис. 3.1 (см. с. 88). Каждый фильм может быть однозначно представлен кортежем отношения Movies. 2. MurderMysteries (title, year, weapon). Два первых атрибута— title и year — это ключ множества сущностей Movies, а последний, weapon, — собственный атрибут множества Murder-Mysteries. Сущности-"боевики" описываются кортежами отношений MurderMysteries и Movies. 3. Cartoons (title, year). Отношение описывает множество сущностей- "мультфильмов" и не содержит, помимо title и year, никаких других атрибутов; дополнительная информация о мультфильмах может быть получена на ос- 3.3. ПРЕОБРАЗОВАНИЕ СТРУКТУР ПОДКЛАССОВ В ОТНОШЕНИЯ 101
нове связи Voices ("голоса"), соединяющей множества сущностей Cartoons и Stars ("актеры"). Сущности-"мультфильмы" описываются кортежами отношений Cartoons и Movies. Сущности-"кинофильмы", относящиеся к жанру "мультипликационного боевика", описываются кортежами всех трех названных отношений одновременно. Нам необходимо, помимо перечисленных выше, и отношение Voices (title, year, starNarne), соответствующее связи Voices, которая соединяет множества сущностей Cartoons и Stars (последнее на диаграмме не показано). Первые два атрибута, title и year, являются ключом множества Cartoons, а последний, starNarne ("имя актера"), — это переименованный ключ множества Stars. Например, кинофильм "Roger Rabbit", который относится к жанру "мультипликационного боевика", будет представлен кортежами во всех четырех отношениях. Основные сведения о нем должны храниться в отношении Movies, информация об оружии (weapon) -~ в MurderMysteries, а данные об актерах, принимавших участие в озвучивании, — в Voices. Обратите внимание, что схема отношения Cartoons является подмножеством схемы отношения Voices. Во многих ситуациях было бы уместно отбрасывать отношения, подобные Cartoons, поскольку в них нет такой информации, которая отсутствует в более "полном" отношении (в данном случае — Voices). Однако вполне резонно предположить существование "немых" мультфильмов, сведения о которых необходимо сохранить. Удаляя из схемы базы данных отношение Cartoons, мы рискуем утратить информацию о том, что подобные фильмы относятся к жанру мультипликации, если не предусмотрим возможность присваивания атрибуту starNarne отношения Voices значения null. □ 3.3.2. Объектно-ориентированный подход Другая стратегия преобразования шг-иерархии в отношения предполагает перечисление всех возможных поддеревьев ER-диаграммы, включающих корневое множество сущностей, с последующим созданием отношений, представляющих сущности, которые обладают всеми компонентами каждого поддерева. Схема отношения должна включать все атрибуты любого множества сущностей, принадлежащего поддереву. Мы называем подобный подход "объектно-ориентированным", поскольку трактуем сущности как "объекты" одного и только одного "класса". Пример 3.10. Вновь рассмотрим иерархическую диаграмму рис. 3.13. В ней можно различить четыре поддерева, включающих корневую вершину и содержащих следующие множества сущностей: 1) Movies; 2) Movies и Cartoons; 3) Movies и Murder-Mysteries; 4) Movies, Cartoons и Murder-Mysteries. Нам предстоит создать отношения для всех четырех перечисленных "классов". Поскольку только множество Murder-Mysteries обладает собственным особым атрибутом, выделяющим сущности "боевик" среди других, схемы отношений будут содержать преимущественно повторяющиеся атрибуты: Movies (title, year, length, filrnType) MoviesC (title, year, length, filrnType) MoviesMM(title, year, length, filrnType, weapon) MoviesCMM(title, year, length, filrnType, weapon) Теперь, вероятно, без серьезного ущерба мы можем объединить отношения Movies и MoviesC (т.е. создать одно отношение, представляющее все "кинофильмы", не отно- 102 ГЛАВА 3. РЕЛЯЦИОННАЯ МОДЕЛЬ
сящиеся к жанру "боевика"), а также MoviesMM и MoviesCMM (создать отношение для хранения данных обо всех кинофильмах-"боевиках"), хотя в последнем случае информация о том, какие фильмы относятся к жанру "мультипликации", будет утрачена. Помимо того, следует подумать, как быть со связью Voices, соединяющей множества сущностей Cartoons и Stars в направлении от первого ко второму. Если бы Voices относилась к типу "многие к одному", мы могли бы добавить атрибут voice в схемы отношений MoviesC и MoviesCMM, чтобы как-то отобразить информацию связи Voices (это действие привело бы и к побочному эффекту — все четыре отношения стали бы различными). Voices, однако, принадлежит к категории связей "многие ко многим", поэтому для нее надлежит создать отдельное отношение. Схема отношения Voices — это очевидно — должна содержать ключевые атрибуты множеств сущностей, соединяемых связью Voices: Voices(title, year, starName). Вполне правомерен вопрос, не следовало ли вместо одного создать два таких отношения: одно, отображающее связь "мульфильмов", не являющихся "боевиками", с множеством "актеров", и второе, содержащее информацию об актерах, озвучивавших "мультипликационные боевики". В нашем случае, однако, подобное решение не способно обеспечить получение каких бы то ни было дополнительных преимуществ. □ 3.3.3. Значения "null" и объединение отношений Существует еще один подход к описанию иерархии множеств сущностей, соединенных связями isa. Если допустить возможность использования неопределенных значений вида null (так обозначаются значения null в языке SQL), можно "уместить" все множества в единственном отношении, которое охватывает все атрибуты всех множеств сущностей иерархии. Произвольная сущность любого множества в этом случае представляется одним кортежем, компонентам которого присваиваются значения nu£l, если соответствующий атрибут не определен для рассматриваемой сущности. Пример 3.11. Применяя указанный подход к иерархии множеств сущностей, показанной на рис. 3.13 (см. с. 101), мы получим отношение, схема которого такова: Movie(title, year, length, filmType, weapon). Компоненты weapon кортежей для тех сущностей-"кинофильмов", которые не являются "боевиками", получат значения mull. Как и в примере ЗЛО, следует создать также дополнительное отношение voices, представляющее информацию об актерах, озвучивавших "мультфильмы". 3.3.4. Сравнение стратегий Каждый из трех рассмотренных выше подходов к проблеме преобразования иерархических структур подклассов в отношения — "ER-подобный", "объектно- ориентированный" и "нулевой" — обладает как несомненными преимуществами, так и очевидными недостатками, рассмотренными ниже. 1. Обработка запросов, охватывающих информацию из нескольких отношений, значительно упрощается, если та же информация размещена в пределах единственного отношения. Подход с использованием значений null предполагает создание только одного отношения, так что в этом контексте он обладает безусловными преимуществами. Два других подхода сулят выгоды при выполнении запросов иных видов. а) Для удовлетворения запроса, подобного такому как "Какие фильмы продолжительностью свыше 150 минут были выпущены в 1999 году?", вполне достаточно информации отношения Movies, созданного в соответствии со стратегией "сущность—связь" (см. пример 3.9 на с. 101). Однако при использовании "объектно-ориентированного" подхода для ответа на тот же вопрос нам при- 3.3. ПРЕОБРАЗОВАНИЕ СТРУКТУР ПОДКЛАССОВ В ОТНОШЕНИЯ 103
шлось бы проверить содержимое всех четырех отношений — Movies, MoviesC, MoviesMM и MoviesCMM, — поскольку киноленты продолжительностью свыше 150 минут, выпущенные в 1999 году, могут относиться к любому из жанров.9 Ь) С другой стороны, применив подход "сущность—связь", мы столкнемся с неприятностями при получении запроса, подобного следующему: "Какое оружие применялось персонажами мультфильмов продолжительностью свыше 150 минут?" Для отыскания ответа нам придется выполнить такие действия: обратиться к отношению Movies и найти все кинофильмы указанной продолжительности; просмотреть кортежи отношения Cartoons, чтобы выбрать из числа найденных кинофильмов только те, которые относятся к жанру мультипликации; обратившись к отношению MurderMysteries, определить типы оружия, применявшегося персонажами каждого из фильмов, удовлетворяющих двум предыдущим требованиям. Если же применить "объектно-ориентированный" подход, мы сможем свести задачу к просмотру единственного отношения, MoviesCMM, в котором содержится вся необходимая информация. 2. Разумеется, нам не хотелось бы иметь слишком много отношений. Подход, предусматривающий использование значений null, выглядит в этом смысле наиболее многообещающим, поскольку предполагает создание единственного отношения. Два других подхода принципиально отличны. Прямолинейная стратегия "сущность—связь" требует создания отношений для каждого множества иерархии. Применяя "объектно-ориентированный" подход, мы вынуждены рассматривать Т различных классов сущностей и создавать столько же отношений для иерархии, состоящей из корневого и п "дочерних" множеств сущностей. 3. При проектировании базы данных необходимо минимизировать расход дискового пространства и избежать повторения одних и тех же порций информации. Поскольку при использовании "объектно-ориентированного" подхода каждой сущности соответствует единственный кортеж и последний содержит компоненты только для тех атрибутов, которые имеют смысл для рассматриваемой сущности, этот подход позволяет расходовать дисковое пространство наиболее экономно. Стратегия, допускающая применение значений null, также предполагает создание одного кортежа для каждой из сущностей, но кортежи в этом случае становятся слишком "длинными", т.е. содержат компоненты для всех атрибутов — независимо от того, требуются они для описания конкретной сущности или нет. Если иерархия охватывает много множеств сущностей, а каждое из них содержит изрядное количество атрибутов, при использовании "нулевого" подхода немалая часть дискового пространства будет истрачена, что называется, впустую. Подход "сущность—связь" допускает создание нескольких кортежей для каждой сущности, но повторяться в них будут только ключевые атрибуты. Поэтому в каких-то ситуациях он может оказаться более предпочтительным в сравнении с "нулевым" подходом, а в других — проигрышным. 3.3.5. Упражнения к разделу 3.3 * Упражнение 3.3.1. Преобразуйте ER-диаграмму рис. 3.14 в реляционную схему базы данных, используя следующие стратегии: a) "сущность—связь"; b) "объектно-ориентированную"; c) допускающую использование значений null. 9 Даже если четыре названных отношения будут "слиты" в два (так, как показано в примере 3.10), все равно для ответа на запрос мы все еще будем вынуждены обращаться к двум отношениям, а не к одному равноценному отношению. 104 ГЛАВА 3. РЕЛЯЦИОННАЯ МОДЕЛЬ
Семантика наименований множеств сущностей и атрибутов диафаммы рис. 3.14 такова: Courses— "учебные курсы", number— "номер", тот — "аудитория", Lab-Courses — "лабораторные работы", computer-allocation — "компьютерный класс", GivenBy — "кем читается", Depts — "факультеты", пате — "название", chair — "декан". number Croomj- С chair ) Courses А* Lab- Courses rcomputer\ , allocation j Рис. 3.14. ER-диаграмма к упражнению 3.3.1 address^ People Рис. 3.15. ER-диаграмма к упражнению 3.3.2 Упражнение 3.3.2. Преобразуйте ER-диафамму рис. 3.15 в реляционную схему базы данных, используя следующие стратегии: a) "сущность-связь"; b) "объектно-ориентированную"; c) допускающую использование значений null. 3.3. ПРЕОБРАЗОВАНИЕ СТРУКТУР ПОДКЛАССОВ В ОТНОШЕНИЯ 105
Семантика наименований множеств сущностей и атрибутов диаграммы рис. 3.15 такова: People — "люди", пате — "имя", address — "адрес", Children — "дети", Child Of — "является ребенком", Fathers— "отцы", FatherOf — "является отцом", Mothers — "матери", MotherOf— "является матерью", Married— "женаты". Упражнение 3.3.3. Преобразуйте ER-диаграмму, полученную вами при решении задания упражнения 2.1.7 (см. с. 65), в реляционную схему базы данных, используя следующие стратегии: a) "сущность—связь"; b) "объектно-ориентированную"; c) допускающую использование значений null. ! Упражнение 3.3.4. Пусть задана /ш-иерархия, охватывающая е множеств сущностей. Каждое множество обладает а атрибутами, к из которых относятся к корневому множеству и образуют ключ для всех множеств сущностей. Предложите формулы вычисления i) минимального и максимального количества используемых отношений; и) минимального и максимального количества компонентов, включаемых в кортеж(и) для одной сущности, если используется одна из следующих стратегий преобразования ER-диаграммы в реляционную схему базы данных: * а) "сущность—связь"; b) "объектно-ориентированная"; c) допускающая использование значений null 3.4. Функциональные зависимости В разделах 3.2 (см. с. 91) и 3.3 (см. с. 100) мы показали, как выполнять преобразование ER-диаграмм в реляционные схемы. Вполне возможно также создать реляционную схему непосредственно на основе спецификации базы данных, минуя стадию ER-моделирования, хотя такой подход может оказаться довольно трудоемким. Независимо от того, каким образом создается реляционная схема, зачастую представляется возможным повысить качество проекта, реализуя определенные типы ограничений. К наиболее важным типам ограничений, применяемых в контексте проекта реляционной базы данных, относится ограничение уникальности, называемое функциональной зависимостью (functional dependency ~- FD). Реализация ограничений этого типа жизненно важна для обеспечения возможности внесения изменений в схему базы данных с целью устранения информационной избыточности (этот вопрос будет освещен в разделе 3.6 на с. 123). Существуют и иные разновидности ограничений, способных улучшить реляционную схему базы данных: здесь достаточно упомянуть многозначные зависимости (multivalued dependencies), рассмотренные в разделе 3.7 на с. 137, и ограничения ссьшочной целостности (referential integrity constraints), о которых мы подробно расскажем в разделе 5.5 на с. 241. 3.4.1. Определение функциональной зависимости Функциональная зависимость (functional dependency — FD) для отношения R — это утверждение следующего вида: "Если два кортежа отношения R совпадают в атрибутах Al9A2,...,An (т.е. кортежи обладают одинаковыми значениями компонентов для каждого из названных атрибутов), то они должны совпадать и в другом атрибуте, /?". 106 ГЛАВА 3. РЕЛЯЦИОННАЯ МОДЕЛЬ
Формально такая FD записывается как А{А2 ■ •Л„-~> В и свидетельствует, что "Аг,А2, -., Ап функционально обусловливают В". Если несколько атрибутов, АьА2,...,Ап, функционально обусловливают более одного атрибута, т.е. А1А2-Ап-*В1 А, А2 •• Ап -» В2 А1А2-Ап->Вт, позволяется использовать следующее сокращенное представление набора таких FD: А1А2-Ая->В1В2-Вт. На рис. 3.16 представлена диаграмма, изображающая функциональную зависимость на примере двух кортежей t и и отношения R. -*- Атрибуты А +~ : -*- Атрибуты В -*** Если f и и они должны совпадают здесь, совпадать и здесь Рис. 3.16. Эффект функциональной зависимости двух кортежей Пример 3.12. Рассмотрим отношение Movies(title, year, length, filmType, studioName, starNarne), экземпляр которого изображен на рис. 3.8 (см. с. 96) и воспроизведен на рис. 3.17. Нетрудно указать несколько функциональных зависимостей, которым подчиняется отношение Movies ("кинофильмы"). Например, мы имеем основания утверждать, что title year —> length title year —> filmType title year —> studioName title Star Wars Star Wars Star Wars Mighty Ducks Wayne's World Wayne's World year 1977 1977 1977 1991 1992 1992 length 124 124 124 104 95 95 film Type color color color color color color studioName Fox Fox Fox Disney Paramount Paramount starNarne Carrie Fisher Mark Hamill Harrison Ford Emilio Estevez Dana Carvey Mike Meyers Рис. 3.17. Экземпляр отношения Movies (title, year, length, filmType, studioName, starNarne) Поскольку левая часть всех трех FD одинакова, title year, их можно кратко представить так: title year —> length filmType studioName. 3.4. ФУНКЦИОНАЛЬНЫЕ ЗАВИСИМОСТИ 107
Если говорить неформально, рассматриваемый набор функциональных зависимостей свидетельствует, что если два отношения обладают попарно одинаковыми значениями компонентов title и year, они должны содержать одни и те же значения в компонентах length, f ilrnType и studioName. Это утверждение справедливо, если принять во внимание изначальный смысл реальных объектов, которые моделируются отношением Movies. Атрибуты title ("название") и year ("год производства") образуют ключ множества сущностей Movies. Таким образом, подразумевается, что конкретные значения атрибутов title и year однозначно определяют сущность-"кинофильм", которой соответствуют строго определенные значения атрибутов length ("продолжительность") и f ilmType ("тип пленки"). Кроме того, существует связь типа "многие к одному", соединяющая множества сущностей Movies и Studios ("киностудии"). Следовательно, каждой сущности-"кинофильму" соответствует только одна сущность "киностудия". С другой стороны, выражение title year —> starName неверно, поскольку не является функциональной зависимостью для отношения Movies. Каждой сущности-"кинофильму" в базе данных, вообще говоря, может соответствовать сразу несколько сущностей-"актеров". □ 3.4.2. Ключи отношений Говорят, что множество вида [AhA2,...,An], состоящее из одного или нескольких атрибутов, является ключом отношения R, если выполняются следующие условия: 1) атрибуты АиАъ..., Л„ функционально обусловливают все остальные атрибуты отношения; ситуация, когда два различных кортежа R совпадают во всех атрибутах Аь Аъ..., Ап, невозможна; 2) ни одно из допустимых подмножеств множества {АьА2,...,Ап} атрибутов не является функциональным обоснованием всех остальных атрибутов отношения R, т.е. ключ минимален (minimal). Если ключ состоит из одного атрибута А, вместо громоздкого обозначения {А} мы будем пользоваться кратким — А. Пример 3.13. Атрибуты {title, year, starName} образуют ключ для отношения Movies в той его редакции, которая приведена на рис. 3.17. Первым делом мы обязаны показать, что эти атрибуты функционально обусловливают все остальные атрибуты. Предположим, что существуют два кортежа, которые совпадают во всех трех атрибутах — title ("название"), year ("год производства") и starName ("имя актера"). Как мы упоминали в примере 3.12, поскольку эти кортежи обладают, в частности, одинаковыми значениями атрибутов title и year, должны попарно совпадать значения и всех остальных атрибутов — length ("продолжительность"), filmType ("тип пленки"), studioName ("название киностудии") и starName ("имя актера"). Вывод справедлив только в отношении первых трех атрибутов — length, filmType и studioName. Двух кортежей, у которых одновременно равны значения атрибутов title, year и starName, быть не может, т.е. исходное предположение неверно, и атрибуты {title, year, starName} действительно формируют ключ отношения Movies. Теперь надлежит доказать, что ни одно из подмножеств множества {title, year, starName} атрибутов не в состоянии функционально обусловить все остальные атрибуты. Начнем с того, что на основании {title, year} нельзя однозначно определить значение starName, так как в одном кинофильме могут участвовать несколько актеров. Поэтому {title, year} нельзя считать ключом. Подмножество {year, starName} также не является ключом, поскольку актер может сняться в нескольких фильмах, выпущенных в течение одного года. Поэтому выражение year starName —> title 108 ГЛАВА 3. РЕЛЯЦИОННАЯ МОДЕЛЬ
Функциональные зависимости как свойства схемы Напомним, что функциональная зависимость, как и любое другое ограничение, — это некоторое предположение относительно структуры схемы отношения, не связанное с конкретными экземплярами этого отношения. Экземпляр отношения сам по себе не дает оснований делать какие-либо выводы, касающиеся взаимозависимостей данных. Например, глядя на частный экземпляр отношения, приведенный на рис. 3.17, можно подумать, будто отношение само по себе поддерживает такую FD, как, скажем, title —> filrnType, поскольку два любых его кортежа, совпадающих в значениях атрибута title, как кажется, всегда совпадают и в значениях f ilrnType. Мы, однако, не вправе декларировать справедливость этой FD. Случись так, что в базу данных попадет информация о двух версиях кинофильма (скажем, какого- нибудь "King Kong"), одна из которых снята на цветной пленке (color), а другая — на черно-белой (blackAnaWhite), и все наши умозаключения просто рухнут. не относится к числу функциональных зависимостей для рассматриваемого отношения Movies. Наконец, мы можем утверждать, что и подмножество {title, starNarne} не может быть ключом, так как вероятны случаи, когда один и тот же актер в разные годы участвует в съемках фильмов с одинаковыми названиями.10 □ Подчас для отношения может быть создано несколько ключей. В такой ситуации, как правило, одному из них отводится роль первичного ключа (primary key). В коммерческих системах баз данных выбор первичного ключа способен воздействовать на определенные свойства реализации (например, на то, каким образом отношение хранится на диске). Вот одно полезное правило, которому следуем мы сами. • "В тексте схемы отношения атрибуты первичного ключа надлежит подчеркивать". 3.4.3. Суперключи Множество атрибутов, содержащее ключ в качестве подмножества, называют суперключом (superkey). Каждый ключ, очевидно, является и суперключом. Некоторые суперключи, однако, не обладают свойством минимальности, хотя каждый суперключ удовлетворяет первому требованию, предъявляемому к ключам: он функционально обусловливает все остальные атрибуты отношения. Пример 3.14. Для отношения Movies, рассмотренного в примере 3.13, можно указать несколько суперключей. Суперключом является не только ключ {title, year, starNarne}, но и любое его надмножество, такое, как, скажем, {title, year, starNarne, length, studioNarne}. □ 3.4.4. Выбор ключей для отношения Когда реляционная схема создается путем преобразования ER-диаграммы в набор отношений, зачастую структуру ключа определенного отношения можно предсказать заранее. Первое правило, касающееся выбора ключей отношения, звучит так. • "Если отношение получено на основе множества сущностей, ключ отношения формируется из ключевых атрибутов множества сущностей". 10 Приводя этот пример в предыдущих книгах, мы не могли найти подлинные образцы подобных совпадений, но получили их от нескольких коллег и читателей. Вообще говоря, это забавно — отыскать реальных актеров, которые умудрились сняться в нескольких версиях одного и того же кинофильма. 3.4. ФУНКЦИОНАЛЬНЫЕ ЗАВИСИМОСТИ 109
Минимальность ключей Требование, касающееся минимальности ключей, в ER-модели не выдвигается, но, имея дело с реляционной моделью, мы вынуждены ему подчиняться. Опытный дизайнер, работая с ER-моделью, вряд ли станет добавлять в ключи избыточные атрибуты, но модель сама по себе не дает возможности проверить, действительно ли каждый из ключей минимален. Только используя некий формализм, подобный функциональным зависимостям, мы можем, по меньшей мере, грамотно поставить вопрос, является ли определенное множество атрибутов "минимальным" множеством, пригодным для применения в качестве ключа. Позвольте напомнить о смысловом различии между минимальным ключом (из него нельзя удалить какой бы то ни было атрибут) и ключом, наименьшим среди всех возможных. Минимальный ключ, вообще говоря, не обязательно обладает наименьшим количеством атрибутов в сравнении с другими, альтернативными, ключами для того же отношения. Может случиться, например, что А В С и D Е одновременно являются ключами некоторого отношения (разумеется, минимальными), но только D Е обладает наименьшей "размерностью" среди всех остальных. Пример 3.15. В примере 3.1 на с. 92 мы рассказывали о том, как преобразовать множества сущностей Movies ("кинофильмы") и Stars ("актеры") в отношения. Ключами указанных множеств сущностей являются, соответственно, множества [title, year) и [пате]. Они будут и ключами отношений Movies и stars, схемы которых можно представить следующим образом: Movies (title, year, length, filrnType) Stars(name, address) где ключевые атрибуты выделены подчеркиванием. □ Второе правило выбора ключей отношения касается бинарных связей. Если отношение R создается на основе связи, на состав множества ключей отношения оказывает влияние свойство множественности связи. Существуют три варианта правила, перечисленных ниже. • "Если связь относится к типу "многие ко многим", ключами отношения R становятся ключевые атрибуты обоих множеств сущностей, соединяемых связью". • "Если связь относится к типу "многие к одному" и соединяет множества сущностей Е{ и Е2 в направлении от Ех к Еъ ключами отношения R должны быть ключевые атрибуты множества Е{ (но не Е2у\ • "Если связь относится к типу "один к одному", ключевыми атрибутами отношения R могут быть ключи любого из соединяемых множеств". Пример 3.16. В примере 3.2 на с. 93 мы обсуждали свойства связи Owns ("владеет"), соединяющей множества сущностей Movies ("кинофильмы") и Studios ("киностудии") и относящейся к типу "многие к одному". Ключ отношения Owns в соответствии с рассмотренным выше правилом должен состоять из атрибутов title и year, которые являются ключом множества сущностей Movies. Схема отношения Owns с подчеркнутыми ключевыми атрибутами выглядит так: Owns (title, year, studioNarne). В примере 3.3 на с. 93 речь шла о связи Stars-in типа "многие ко многим", соединяющей множества сущностей Movies и Stars ("актеры"). Все атрибуты отношения Stars-in(title, year, starName) no ГЛАВА 3. РЕЛЯЦИОННАЯ МОДЕЛЬ
Что есть "функционального" в функциональных зависимостях? Выражение АХА2~-Ап —>В называют "функциональной" зависимостью благодаря тому, что по существу оно определяет "функцию", которая в качестве "параметров" принимает список значений, по одному на каждый из атрибутов АЪА2, ...,Ап, и возвращает строго определенное значение (либо не возвращает никакого значения вовсе) для атрибута В. Изучая, например, отношение Movies, мы можем предположить существование функции, которая воспринимает строку (скажем, "Star Wars") и целочисленное значение (такое как 1977), а затем возвращает в виде результата определенное значение атрибута length (а именно, 124) из содержимого отношения Movies. Рассматриваемая функция, однако, не относится к категории обычных математических функций, поскольку не предполагает каких-либо "вычислений" в привычном смысле этого слова: мы не можем выполнить некие "операции" над строкой "Star Wars" и числом 1977, чтобы получить на их основе число 124. Процесс "вычислений" заключается в просмотре отношения и поиске в нем необходимых данных: отыскивается кортеж, содержащий для атрибутов title и year заданные значения "Star Wars" и 1977 соответственно, а затем из него извлекается содержимое атрибута length. должны быть ключевыми. Единственный способ предотвратить введение всех атрибутов отношения связи в состав ключевых состоит в том, чтобы снабдить связь собственным атрибутом. Тогда атрибуты множеств сущностей, охватываемых связью, можно будет изъять из набора ключевых атрибутов отношения связи. □ В завершение вкратце упомянем многосторонние связи. Поскольку в подобных случаях, вообще говоря, с помощью одних только стрелок нельзя описать все допустимые взаимозависимости соединяемых множеств сущностей, возможны ситуации, когда состав ключа или ключей отношения связи трудно определить, если тщательно не поразмыслить о том, каким именно образом те или иные сущности функционально обусловливают содержимое других сущностей. Впрочем, справедливость одного утверждения мы все-таки можем гарантировать. • "Если многосторонняя связь R содержит стрелку, направленную к множеству сущностей £, существует по меньшей мере один ключ для соответствующего отношения, который противоречит ключу £". 3.4.5. Упражнения к разделу 3.4 Упражнение 3.4.1. Рассмотрим отношение, которое представляет сведения о гражданах США, включая их имена, номера полисов социального страхования, почтовые адреса, названия городов и штатов проживания, почтовые коды, телефонные коды и номера. Какие функциональные зависимости следовало бы учесть? Каковы ключевые атрибуты такого отношения? Чтобы ответить на эти вопросы, необходимо знать о том, каким образом указанные параметры соотносятся друг с другом и как их значения присваиваются объектам (людям, городам и т.д.). Например, может ли один телефонный код охватывать два штата или один почтовый код соответствовать нескольким телефонным кодам? Могут ли два человека обладать полисами социального страхования с одним номером? Могут ли люди иметь один почтовый адрес или номер телефона? * Упражнение 3.4.2. Рассмотрим отношение, представляющее текущие позиции молекул вещества, размещенного в ограниченном сосуде. Пусть в число атрибутов входят идентификатор id молекулы, ее координаты х, у и z, а также значения скоростей vx, vy и vz в направлении осей х, у и г. Какие функциональные зависимости необходимо предусмотреть? Как может выглядеть ключ отношения? 3.4. ФУНКЦИОНАЛЬНЫЕ ЗАВИСИМОСТИ 111
К вопросу о терминах В отдельных книгах и статьях при обозначении ключей отношения употребляется особая терминология. В одних ситуациях "ключом" называют то, что мы трактуем как "суперключ", т.е. множество атрибутов, функционально обусловливающих значе-ния всех других атрибутов отношения (при этом требование минимальности ключа не выдвигается). В других источниках для ссылки на минимальный ключ используется выражение "candidate key" — мы же в подобном случае применяем термин "ключ" ("key"). ! Упражнение 3.4.3. В упражнении 2.2.5 на с. 72 мы выдвигали три различных предположения относительно свойств связи Births ("роды"). Постройте для каждого из них схему соответствующего отношения и укажите ключевые атрибуты. * Упражнение 3.4.4. Обратитесь к реляционной схеме базы данных, построенной вами при решении задания упражнения 3.2.1 (см. с. 99), и определите наборы ключевых атрибутов для каждого отношения. Упражнение 3.4.5. Укажите множества ключевых атрибутов для отношений, созданных вами при решении каждого из четырех вариантов задания упражнения 3.2.4 (см. с. 100). !! Упражнение 3.4.6. Предположим, что R — это отношение с атрибутами Ль Аъ..., Ап. Ответьте, каким количеством суперключей, выраженным в виде функции от л, обладает отношение R, если отдельными ключами являются: * а) атрибут А\\ b) атрибуты Ах и А2\ c) множества атрибутов {Аь А2} и {A3>Ai}; d) множества атрибутов {АиА2} и {ЛьЛз}- 3.5. Правила использования функциональных зависимостей В этом разделе мы постараемся рассказать, как следует воспринимать функциональные зависимости (functional dependencies — FD) — например, тогда, когда нам говорят, что некоторый набор FD удовлетворяет определенному отношению. Зачастую в процессе анализа можно прийти к выводу, что тому же отношению должны удовлетворять и некоторые другие FD. Способность к выявлению дополнительных функциональных зависимостей особенно важна, если мы стремимся отыскать самые удачные схемы отношений (эта тема освещена в разделе 3.6 на с. 123). Пример 3.17. Если известно, что отношение R с атрибутами А, В и С удовлетворяет функциональным зависимостям А —> В и В —> С, можно утверждать, что R также удовлетворяет FD A —> С. Как мы пришли к такому выводу? Чтобы доказать справедливость выражения А —> С, мы должны рассмотреть два кортежа отношения R, которые совпадают в атрибуте А, и доказать, что они совпадают также в атрибуте С. Пусть (а, Ьи с{) и (д, Ъъ с2) — два кортежа, в которых значения атрибута А совпадают. Мы подразумеваем, что порядок следования атрибутов в кортежах таков: А, В, С. Так как R удовлетворяет FD А —> В и кортежи совпадают в атрибуте А, они должны совпадать и в атрибуте В. Другими словами, Ъх - Ь2 и поэтому кортежи фактически выглядят как {a, b, ci) и (а, Ь, с2), где Ъ — это одновременно и Ьи и Ь2. Аналогично, поскольку R удовлетворяет В —> С и кортежи совпадают в атрибуте В, они должны совпадать и в атрибуте С. Таким образом, сх - с2, т.е. кортежи совпадают в значениях атрибута С. Мы доказали, что любые два кортежа отношения R, совпадающие в атрибуте А, также совпадают и в атрибуте С, так что А —> С — это верная функциональная зависимость для R. □ 112 ГЛАВА 3. РЕЛЯЦИОННАЯ МОДЕЛЬ
Функциональные зависимости нередко могут быть представлены несколькими различными способами при условии, что набор существующих экземпляров отношения остается неизменным. Говорят, что: • два множества FD S и Т являются эквивалентными (equivalent), если множество экземпляров отношения, удовлетворяющих S, в точности совпадает с множеством экземпляров отношения, удовлетворяющих Г; • множество FD S следует из множества FD Г, если каждый экземпляр отношения, удовлетворяющий всем FD множества Г, также удовлетворяет всем FD множества S. Заметим, что два множества FD S и Т являются эквивалентными, если и только если S следует из Г и Г следует из S. Ниже мы приведем несколько полезных правил использования функциональных зависимостей. Правила дают возможность, например, заменять одно множество FD другим, эквивалентным, множеством или добавлять в множество другие FD, которые следуют из существующих FD. Пример 3.17, рассмотренный выше, иллюстрирует правило транзитивности (transitive rule), которое позволяет следовать по цепочке взаимосвязанных FD. Кроме того, мы предложим алгоритм, способный дать ответ на общий вопрос, следует ли заданная FD из одной или нескольких других FD. 3.5.1. Правила разделения/объединения В разделе 3.4.1 на с. 106 мы упоминали о том, что функциональная зависимость вида А1А2-Ая->В1В2...Вт представляет собой сокращенное представление множества FD: АХА2-Ап->ВХ А1А2~Ап->В2 AiA2-An-^Bm. Другими словами, мы имеем право разделить множество атрибутов, перечисленных в правой части сокращенного выражения FD, на элементы и поместить каждый из них в правую часть новой отдельной FD. И наоборот, допустимо заменить набор FD, обладающих одинаковой левой частью, единственной FD с той же левой частью, а в правой части этой FD указать все "правосторонние" атрибуты исходных FD, объединенные в множество. В любом из двух случаев новые функциональные зависимости полностью равноценны исходным. Изложим каждое из правил формально. • Преобра