Введение в системы баз данных - Ульман Дж.Д., Уидом Дж.

Автор: Ульман Дж.Д. Уидом Дж.

Теги: программирование базы данных информационные технологии информационные системы

Похожие

Системы баз данных

Основы систем баз данных

Введение в системы баз данных

Базы данных на Паскале

Текст

F ШФФ1>11 t ШН4
ДИ1ШН<Ш УНДОК
Содержание
1 Миры систем баз данных 1
1.1 Эволюция систем БД 1
1.2 Архитектура СУБД б
1.3 Будущее систем БД 12
1.4 Краткий обзор книги 17
1.5 Итоги 18
1.6 Литература к главе 1 19
2 Моделирование базы данных 20
2.1 Введение в ODL 21
2 2 Диаграммы сущности-связи 32
2.3 Принципы проектирования 40
2.4 Подклассы 45
2.5 Моделирование ограничений 50
2.6 Слабые множества сущностей 57
2.7 Модели, представляющие исторический интерес 61
2.8 Итоги 65
29 Л итератора к главе 2 66
3 Реляционные модели данных 67
3.1 Основы реляционной модели 67
3.2 Переход от проектов ODL к реляционным проектам 72
3.3 Переход от E/R-диаграмм к реляционным проектам 83
3.4 Преобразование структур подклассов в отношения 89
3 5 Функциональные зависимости 94
3.6 Правила функциональной зависимости 102
3.7 Разработка схем реляционных БД 111
3 8 Многозначные зависимости 125
3.9 Пример схемы БД 134
3.10 Итоги 136
3. II Литература к главе 3 138
4 Операции в реляционной модели 139
4.1 Алгебра реляционных операций 139
4.2 Логика отношений 156
4.3 Переход от реляционной алгебры к Datalog 16?
4.4 Рекурсивное программирование в Datalog 169
4.5 Ограничения на отношения 181
4 6 Реляционные операции на мультимножествах 186
4.7 Другие расширения реляционной модели 194
4 8 Итоги 195
4.9 Литература к главе 4 196
vii Содержание
5 Язык баз данных SQL 198
5.1 Простые запросы в SQL 198
5.2 Запросы, содержащие более одного отношения 207
5.3 Подзапросы 215
5.4 Дубликаты 220
5.5 Агрегация 223
5.6 Изменения базы данных 228
5.7 Определение схемы отношения в SQL 233
5.8 Определения пользовательских представлении 739
5.9 Пустые значения и шешние соединения 249
5.10 Рекурсия в SQL 256
5.11 Итоги 265
5 12 Литература к главе 5 267
6 Ограничения и триггеры в SQL 2б8
6.1 Ключи в SQL 268
6.2 Ссылочная целостность и внешние ключи 271
6 3 Ограничения на значения атрибутов 276
6 4 Глобальные ограничения 279
6.5 Изменение ограничений 285
6.6 Триггеры в SQL3 288
6.7 Итоги 294
6 8 Литература к главе 6 295
7 Системные аспекты SQL 296
7.1 SQL в среде программирования 296
7 2 Транзакции в SQL 309
7 3 Среда SQL 318
7 4 Зашита и авторизация пользователя в SQL2 324
7.5 Итоги 334
7.6 Литература к главе 7 335
8 Объектно ориентированные языки
запросов 336
8 I Свойства ODL, связанные с запросами 336
8.2 Введение в OQL 341
8.3 Дополнительные формы выражений OQL 348
8.4 Создание и назначение объектов в OQL 353
8.5 Объекты кортежей в SQL3 357
8 6 Абстрактные типы данных в SQL3 365
8.7 Сравнение подходов ODL/OQL и SQL3 371
8.8 Ито и 373
8.9 Литература к главе 8 374
VI
Предисловие
Некоторые упражнения выделяются звездочкой — для них мь предлагаем
решения, доступные на Web-стра чине данной книги. Их следует использовать
JU я самопроверки. Заметим, что в некоторых случаях упражнение £ требует моди-
фикации или адапташн вашего решения для упражнения Л. Если определенные
части А имеют решения, мож! о считать, что соответствующие части В тоже
имеют решения.
Поддержка на World Wide Web
Домашняя Web-странина этой книги:
http.//www-db.stanford.edu/~ullman/fcdb.html
На ней содержатся решения отмеченных звездочкой упражнений, обнаруженные
ошибки и дополнительные материалы Мы надеемся сделать доступными также
лекции по курсу CSI45 в том виде, в каком он преподается, включая домашние
задания, решения и оценки проекта.
Бл а годарности
Наша особая благодарность Бобби Кочрейну и Линде Демичел за их помощь
по вопросам стандарта SQL3 Мы признательны и многим другим людям, помогав-
шим нам в подготовке рукописи, среди них Дональд Эйнсворт, Джонатану Беккер,
Ларри Бонем, Кристофер Чен. Оливер Дучка, Грег Фихтенгольц, Барт Фишер,
Мередит Голдсмит, Стив Хантсберри Леонард Джекобсон, Таласирман Джейара-
ман, Дуайт Джой, Сет Катц, Брайан Кулмен, Ли Вей Мо, Марк Мортенсен,
Рампракаш Нарайянасвамн, Торбьорн Норби, Михал Пател, Катерина Торнбин,
Джонатан Ульман, Мейанк Ападхай. Василис Вассалос, Кьянг Ванг, Сандар
Ямунахари и Такеши Йокукава Оставшиеся в книге ошибки, конечно же, ошибки
авторов
Дж. ДУ.
Дж. У.
Глава 1
Миры систем баз данных
С помощью этой книги читатель научится эффективно использовать системы
управления БД, в том числе осуществлять разработку БД и программирование
операций на БД. В данной главе вводится ряд важных понятий БД, представлена
краткая история развития БД, показаны отличия систем БД от других типов ПО,
а также изложены основы реализации систем управления и поддержки БД. Мате-
риал раздела помогает понять, почему БД проектируются так, а не иначе или чем
ограничено число способов проведения операций на БД. В заключение главы дан
обзор некоторых понятий, относящихся, например, к объектно-ориентированному
программирования и, возможно, уже знакомых читателю. Они сыграют важную
роль в следующих главах.
1.1 Эволюция систем БД
По сути дела БД — это просто множество информации, существующее долгое
время, часто в течение многих лет Обычно термином "база данных" обозначается
множество данных управляемое системой управления базой данных, называемой
также СУБД (DBMS), или просто системой базы данных. Предполагается, что СУБД:
1. Обеспечивает пользователю возможность создавать новые БД и определять
их схему (логическую структуру данных) с помощью специального языка,
получившего название языка определения данных.
2. Позволяет "запрашивать" данные ("запрос" в терминологии БД означает
вопрос по поводу данных) и изменять их с помощью подходящего языка,
называемого языком запросов, или языком манипулирования данными.
3. Поддерживает хранение очень больших массивов данных, измеряемых
гигабайтами и более, в течение долгого времени, защищая их от слу гай-
ной порчи или неавторпзованного ^пользования и обеспе* ивая модифи-
кацию БД п доступ к данным пугем запросов.
4 Контролирует посту л к данным сразу множества пользователей, не позво-
ляя запросу одного из них влиять на запрос другого и не допуская одно-
временного доступа, который может случайно испортить данные.
1.1.1 Первые системы управления БД
Первые коммерческие системы управления БД появились в конце шестидеся-
тых годов. Они возникли из систем, выполнявших пункт 3 из предыдущего раздела:
файловые системы позволяют хранить большое количество данных долгое время.
Однако в общем случае они нс гарантируют, что данные не будут потеряны, если
2
Г лава 1 Мири систем баз данных
они не скопированы, и не поддерживают эффективного доступа к данным, распо-
ложенным в неизвестном файле.
Кроме того, файловые системы непосредственно не выполняют пункт 2 — не
поддерживают язык запросов на данные в файлах. Поддержка пункта I. те. схемы
данных, ограничена созданием структуры каталогов для файлов 1-1 наконец, файло-
вые структуру не удовлетворяют пункту 4. Допуская параллельный доступ к файлам
множества пользователей или процессов, они не предотвращают ситуации, в кото-
рой два пользователя изменяют один и тот же файл почти одновременно, поэтому
изменения одного из них в файле вообще не появляются.
Первыми важными приложениями СУБД были те, в которых данные разбива-
лись на множество небольших элементов, вводилось множество запросов гели изме-
нений Рассмотрим несколько таких приложений.
Система резервирования авиабилетов
Элементы данных этой системы:
I . Бронирование единственным клиентом билета на единственный рейс,
включающее в себя информацию о номере места и пище, которую пред-
почитает клиент.
2 Информация об авиарейсах: аэропортах, из которых осуществляются
рейсы, времени вылета и прибытия или самолетах, находящихся в пути.
3 Информация о ценах на билеты, требованиях и наличии свободных мест.
Типичные запросы касаются авиарейсов в определенное время из одного
конкретного города в другой, наличия свободных мест и цен на билеты. Типичные
изменения данных — это бронирование для клиента определенного рейса и места
или указание, какую пищу предпочитает клиент. В любой момент множество
агентов получают доступ к частям упомянутых данных. СУБД должна разрешить
такой параллельный доступ и предотвратить проблему (например, два разных аген-
та одновременно бронируют одно и то же место на один и тот же рейс), а также
потерю записей в случае выхода системы из строя.
Банковская система
В этой системе элементами данных являются адреса клиентов, счета, займы
и их балансы, а также связи между клиентами, их счетами и займами, например
информация о том, кто какие счета имеет право подписывать. Широко распростра-
нены запросы на балансы счетов, но еше чаще встречаются единичные выплаты
со счета или внесение вкладов.
Как и в случае с резервированием авиабилетов, можно ожидать, что множество
клиентов будут одновременно (используя банкоматы) делать запросы и изменять
банковские данные. Жизненно важно, чтобы одновременный доступ к счету не
привел к потере транзакций на банкомате. Ошибки здесь недопустимы. Например,
после изъятия денег из банкомата банк должен записать этот дебет, даже если при
этом немедленно отключится электроэнергия. С другой стороны, банк не имеет
права сначала записать дебет, а затем не выдавать деньги потому, что отключилась
электроэнергия Правильное проведение этой операции далеко не очевидно и его
можно рассматривать как одно из важных достижений в архитектуре DBMS
Корпоративные записи
Многие первые приложения были связаны с корпоративными записями типа
записи каждой продажи, информации о подлежащих оплате и оплаченных счетах
или данных о служащих, таких как имена, адреса, зарплата, надбавки, налоги и т.п.
1 1 Эволюция систем БД
3
Запросы здесь относятся к распечатке записей, например полученных счетов или
недельных расчетных чеков служащих. Каждая продажа, покупка, иск, получение
денег, прием на работу, увольнение или повышение служащего и т.д. приводят
к изменениям базы да! ных.
Первые СУБД возникли из систем обеспечивающих пользователю возможность
визуально воспринимать данные во многом так же, как они хранились. В этих
системах БД применялись различные модели данных для описания структуры
хран нзшейся в БД информации. Главными из них были иерархическая, или осно-
ванная на деревьях, и сетевая, основанная на графах, модели. Последняя была
стандартизована в шестидесятых годах в документе Комитета по системам данньх
и языкам CODASYL’.
Обе эти модели будут описаны в разделе 2.7 данной книги, хотя сегодня они
представляют только исторический интерес.
Недостаток этих первых моделей и систем заключался в том, что они не под-
держивали языки запросов высокого уровня. Например, в языке запросов
CODASYL есть операторы, позволяющие пользователю перескакивать от одного
элемента данных к другому по графу указателей, расположенному среди этих
элементов. Для написания подобных программ даже для простых запросов требо-
вались большие усилия.
1.1.2 Реляционные базы данных
После выхода в свет знаменитой статьи Тэда Кодда в 1970 г.1 2 системы БД
значительно изменились. Кода предложил, чтобы системы БД обеспечивали
пользователя представлением данных, организованных в виде таблиц, называемых
отношениями. На заднем плане могут находиться сложные структуры данных, допу-
скающие быстрые ответы на множество запросов. Однако в отличие от пользователя
прежних систем БД пользователь реляционной системы не связан со структурой
памяти. Запросы можно выражать на языке очень высокого уровня, что значительно
повышает эффективность усилий программистов БД.
Реляционной модели системы БД посвящена основная часть этой книги (базовые
реляционные понятия вводятся в главе 3). SQL (язык структурированных запросов)
будет рассматриваться, начиная с главы 5. Здесь мы дадим лишь краткое введение
в отношения, чтобы читатель мог почувствовать простоту модели, и приведем при-
мер SQL, показывающий, как реляционная модель поддерживает запросы очень
высокого уровня, позволяя избегать деталей “навигации" в БД.
Пример 1.1. Отношения — это таблицы. Заголовками их столбцов являются
атрибуты, описывающие вхождения данных в эти столбцы Например, отношение
с именем Accounis, описывающее банковские счета, их балансы и типы, может
иметь вид:
accountNc balance type
12345 1000.00 savings
67890 ... 2846.92 checking
1 CODASYL Data Rase Task Group April /97/ Report. ACM, New York.
2 Codd E.F., “A relatonal model for large shared daia banks". Comm. ACM 13.6. pp 377-387.
4
Глава 1 Миры систем баз данных
Заголовками столбцов являются три атрибута: accountNo, balance и type. Под
атрибутами рпсположены строки, или кортежи. Здесь явно показаны два кортежа
данного отношения, а точки под ними означают, что может быть множество кор
гежей — по одному для каждого банковского счета. Первый кортеж показывает,
что баланс счета пол номером 12345 равен SI000 и этот счет является сберега-
тельным, а второй кортеж означает, что счет 67890 является чековым счетом на
сумму S2S46.92
Предположим, нужно узнать баланс счета 67890. Можно сформулировать запрос
в SQL:
SELECT balance
FROM Accounts
WHERE accountNo = 67890.
С помощь о другого запроса можно потребовать сберегательные счета с отри-
цательным балансом:
SELECT accountNo
FROM Accounts
WHERE type = 'savings' AND balance < 0;
Мы понимаем, что двух приведенных примеров недостаточно для того, чтобы
читатель стал экспертом по программированию в SQL, но они тем не менее демон-
стрируют высокий уровень операторов SQL типа select from-where. В принципе они
просят систему БД
I. Проверить все кортежи отношения Accounts, упомянутые в пункте FROM.
2. Выбрать кортежи, удовлетворяющие определенному критерию, указанно-
му в пункте WHERE.
3. Выдать в качестве ответа определенные атрибуты этих кортежей, указан-
ные в пункте SELECT.
I la практике система должна "оптимизировать" запрос и найти эффективный
способ ответа на него, даже если отношения, включенные в запрос, очень велики. □
Первым поставщиком реляционных и репрезентаиионных СУБД была фирма
IBM Затем реляционные СУБД стали реализовывать и продавать другие компании.
Сейчас некоторые из них являются крупнейшими в мире поставщиками ПО.
1.1.3 Уменьшение размеров систем
Сначала СУБД были очень большими и дорогими системами ПО, работающи-
ми на мощных компьютерах Это было необходимо, так как для хранения гигабайт
данных нужны были большие компьютерные системы. Сегодня гигабайт умещается
на одном диске, и этого достаточно для работы с СУБД на персональном компью-
тере Таким образом системы БД, основанные на реляционной модели, стали до-
ступны даже на небольших компьютерах и становятся общераспространенным
средством компьютерных приложений, подобно электронных, таблицам и тек
стовым процессорам.
1.1.4 Увеличение размеров систем
Однако в гигабайте умещается не тпк уж много информации. Корпоративные
БД иногда занимают сотни гигабайт. Поскольку память становится все дешевле,
находятся все новые основания для хранения больших массивопланных. Например
сеш розничном торговли часто хранят терабайт (1000 Гбайт, или 105 120 байт)
1 1 Эволюция систем БД
5
и даже больше информации отражающей историю каждой продажи за длительный
период времени (для планирования инвентаризации, более подробно об этом будет
сказано в разделе 1.3.4). БД больше не концентрируются на хранении простых эле-
ментов данных типа целых чисел или коротких строк символов, а могут хранить
образы, аудио- и видеоинформацию, а также другие типы информации, требующие
огромного пространства памяти Например, один час видео требует гигабайта памя-
ти. Ожидается, что к 2000 году БД, хранящие информацию со спутников, будут
достигать нескольких петабайт (1000 терабайт, или 105 150 байт).
Поддержка таких больших БД требует технических усовершенствований. На-
пример БД среднего размера сегодня хранятся на наборах дисков, называемых
вторичными устройствами памяти (по аналогии с основной памятью, которая явля-
ется "первичной"). Более того системы БД отличаются от другого ПО прежде всего
тем, что заведомо предполагают: данных слишком много для того, чтобы хранить
их в основной памяти, поэтому они в первую очередь должны размещаться на
дисках. Следующие две тенденции позволяют системам БД быстрее обрабатывать
большие массивы данных.
Дополнительные носители памяти
Самым большим на сегодняшний день БД требуется нечто большее, чем диски.
Поэтому были созданы различные дополнительные носители памяти, каждое из
которых может хранить терабайт. Для доступа к нему нужно больше времени, чем
для доступа к диску. Для доступа к любому элементу данных на типичном диске
достаточно 10 — 20 мс. а для доступа к дополнительному носителю памяти может
понадобиться несколько секунд Такое устройство включает в себя транспортировку
объекта, на котором хранится нужный элемент данных, на считывающее устройство.
Это перемещение выполняется роботом передатчиком определенного типа
Например, дополнительными носителями памяти могут быть компакт-диски.
Указанный на дорожке автомат перемешается к конкретному CD. выбирает его
и загружает в считывающее устройство.
Параллельные вычисления
Способность хранить огромные объемы данных важна, но от нее было бы мало
пользы, не будь быстрого доступа к данным Поэтому очень большие БД требуют
средств ускорения доступа. Одно из них — индексные структуры, о которых пойдет
речь в разделах 1.2.1 и 5.7,7. Другой способ обработки большего количества данных
за фиксированное время — использование параллелизма в различных его вариантах.
Поскольку скорость считывания данных с конкретного диска достаточно
мала — несколько мегабайт в секунду, можно ускорить обработку данных исполь-
зуя параллельное чтение нескольких дисков (даже если данные находятся в допол-
нительном носителе памяти, перед обработкой с помощью СУБД они кэшируются
на диске). Эти диски могут быть частями структурированной параллельной маши
ны или компонентами распределенной системы, в которой несколько компьютеров
отвечают за отдельные части БД и при необходимости взаимодействуют через
высокоскоростную сеть.
Разумеется, способность к быстрому перемещению данных, как и возможность
хранить большое количество данных, сама по себе не гарантирует быстрых ответов
на запросы Нужны еще алгоритмы, разбивающие запросы так, чтобы параллель-
ные компьютеры или сети распределенных компьютеров могли эффективно
использовать псс ресурсы. Таким образом, параллельное и распределенное управле-
ние очень большими БД остается сферой перспективных научных исследований
и разработок.
6
Глава 1 Миры систем баз данных
1.2 Архитектура СУБД
В этом разделе кратко описываются структуры типично!’! системы управления
БД. рассматриваются обработка запросов пользователя с помощью СУБД и другие
операции БД. а также проблемы, связанные с проектированием СУБД, способных
управлять большими массивами данных и поддерживать высокую скорость обра-
ботки запросов. Технология реализации СУБД не является темой данной книги;
мы сосредоточимся на проектировании и эффективном использовании БД.
1.2.1 Обзор компонентов СУБД
На рис. 1.1 показаны основные части СУБД. В нижней части схемы — место
хранения данных. Принято, что компоненты схем, имеющие форму дисков, обо-
значают именно места хранения данных. Заметим, что в данном случае этот компо-
нент содержит не только данные, но и метаданные — информацию о структуре
данных. В частности, если это реляционная СУБД, метаданные включают в себя
имена отношений, имена атрибутов этих отношений и типы данных для этих
атрибутов (например, число или строку длиной в 20 символов).
Часто СУБД поддерживает индексы данных. Индекс — это структура данных,
помогающая быстро найти элементы данных при наличии части их значения.
Наиболее распространенный пример — индекс, который находит кортежи конкрет-
ного отношения, имеющие заданное значение одного из атрибутов. Например,
отношение, хранящее номера счетов и балансы, может иметь индекс счета-номера
что позволяет быстро найти баланс при наличии номера счета. Индексы — часть
хранимых данных, а описание, указывающее, какие атрибуты имеют индексы,
часть метаданных.
Реализация индексов
t
а
Вероятно, из курса по структуре данных вы уже знаете, что хеш-таблица i
является очень эффективным средством построения индексов. В первых
СУБД хеш-таблицы действительно применялись очень широко В настоящее
время наиболее распространенная структура данных называется В-деревом,
где “В" обозначает "balanced" (балансированные). В-дерево — это обобщение
балансированного бииарното дерева поиска. Однако каждый узел бинарного
• дерева имеет не более двух потомков, а узлы В-дерева имеют множество
i потомков. Поскольку обычно В-дерево появляется на диске, а не в основной
1 памяти, оно проектируется так, чтобы каждый его блок полностью занимал
г блок диска. Поскольку типичные системы используют дисковые блоки поряд-
I ка 25 120 байт (4096 бит), в одном блоке В-дерева могут быть сотни указателей
i на потомка. Поэтому поиск в В-дереве обычно состоит более чем из трех
уровней. i
Стоимость дисковых операций в общем случае пропорциональна числу I
доступных дисковых блоков. Поэтому поиск в В-дереве, при котором обычно
проверяется только три дисковых блока, намного эффективнее поиска в би- I
нарном дереве, когда обычно просматривается множество различных диско- j
вых блоков. Различие способов поиска в В-дереве и бинарном дереве является |
одним из многочисленных примеров того, чем наиболее удобные структуры I
f данных, хранящихся на диске, отличаются от структур данных, используемых i
I алгоритмами основной памяти. !
1.2 Архитектура СУБД
7
Рис. 1.1. Главные компоненты СУБД
На рис. 1.1 показан также менеджер памяти, задача которого получать требуе-
мую информацию из хранилища данных и изменять в нем информацию по требо-
ванию расположенных выше уровней системы. Следующий компонент называется
процессором запроса. Название не совсем точное, поскольку этот элемент не только
обрабатывает запросы, но и запрашивает изменения данных или метаданных. Его
задача — найти лучший способ выполнения требуемой операции и дать соответст-
вующие команды менеджеру памяти
Компонент менеджер транзакции отвечает за целостность системы. Он доджей
обеспечить одновременную обработку множества запросов, отсутствие интерференции
запросов и защиту данных на случай выхода системы из строя. Он взаимодействует
с менеджером запросов, так как должен знать, на какие данные воздействуют
текущие запросы (чтобы избежать конфликтных ситуаций), и может отложить
определенные запросы или операции, чтобь избежать конфликтов Он взаимо-
действует также с менеджером памяти, так как схемы защить данных обычно
включают в себя хранение файла регистрации изменений данных. При правильном
порядке выполнения операций файл регистрации будет содержать запись измене-
ний, поэтому можно заново выполнить даже те изменения, которые не достигли
диска из-за сбоя в системе.
В верхней части рис. 1.1 находятся три типа обращения СУБД:
1 Запросы — вопросы по поводу'данных, которые генерируются двумя спо-
собами
а) с помощью общего интерфейса запросов; например, реляционная СУБД
позволяет печатать запросы SQL, передаваемые процессору запросов,
и получать на них ответы;
Ь) с помощью интерфейсов прикладных программ Типичная СУБД по-
зволяет писать прикладные программы, которые через вызовы СУБД
запрашивают БД. Например, агент, применяющий систему резер-
вирования авиабилетов, запускает программу запрашивающую БД
о наличии свободных мест иа рейсы Запросы передаются через спе-
циальный интерфейс, который может содержать боксы, заполняемые
названиями городов, указаниями времени и т.д. Через этот интер-
фейс нельзя посылать произвольные запросы, ио все же проще
отправить подходящий запрос через такой интерфейс, чем писать его
непосредственно в SQL.
2. Модификации — это операции по изменению данных Подобно запросам
они могут выполняться с помощью общего интерфейса или интерфейса
прикладной программы.
8
Глава I Миры систем баз данных
3. Модификации схемы — это команды, которые обычно лаются авторизован-
ным персоналом, администраторами БД, имеющими право изменять схе-
му БД или создавать новую БД Например, если IRS требует от банков
отчета о выплатах процентов с номерами страховых полисов всех клиен-
тов, банку может потребоваться новый атрибут socialSecuntyNo для отно-
шения, хранящего информацию о клиентах
1.2.2 Менеджер памяти
В простых системах БД менеджером памяти может быть просто система фай-
лов базовой операционной системы. Однако для повышения эффективности СУБД
обычно осуществляет прямой контроль памяти, по крайней мере в определенных
условиях, Менеджер памяти состоит из двух компонентов: менеджера буфера
и менеджера файлов.
I. Менеджер файлов контролирует расположение файлов на диске и получает
блок или блоки, содержащие файлы, по запросу менеджера буфера Напо-
минаем, чго диск в общем случае делится на дисковые блоки — смежные
области памяти, содержащие большое число байтов возможно 502 512
пли 25 140 (от 4000 до 16 000 байт)
2. Менеджер буфера управляет основной памятью. Он получает блоки данных
с диска через менеджер файлов и выбирает страницу основной памяти
для хранения конкретного блока Он может временно сохранять диско-
вый блок в основной памяти, но возвращает его на диск, когда страница
основной памяти нужна для другого блока. Страницы тоже возвращаются
на диск но требованию менеджера транзакций см. раздел 1 2.4
1.2.3 Менеджер запросов
Задача менеджера запросов — превращать запрос или действие с БД которые
могут быть выражены на очень высоком уровне (например, в виде запроса SQL),
в последовательность запросов на хранимые данные типа отдельных кортежей
отношения или частей индекса на отношении. Иногда самой трудной частью обра-
ботки запроса является его организация — выбор хорошего плана запроса или после-
довательности запросов к системе памяти, отвечающей на запрос.
Пример 1.2. Предположим, что банк имеет БД с двумя отношениями:
I. Customers — таблица, приписывающая каждому клиенту имя номер стра-
хового полиса и адрес
2. Accounts таблица, приписывающая каждому счету номер, баланс и номер
страхового полиса владельца. Заметим, что каждый счет имеет главною
владельца, чей номер страхового полиса используется при налогообложе-
нии могут бызъ и другие владельцы счета, но о них нельзя узнать из двух
упомянутых отношений
Предположим, что есть запрос: ‘Найти балансы всех счетов, главным владель-
цем которых является Салли Джонс" Для работы с ними отношениями менеджер
запросов должен составить такой план запроса, который позволил бы получить
на него ответ Чем меньше шагов требуется для ответа, тем лучше план запроса
В общем случае дорого обходятся шаги, па которых дисконын блок копируется
менеджером памяти с диска на страницу пула буфера или страница записывается
обратно на диск Поэтому при оценке плана запроса разумно учитывать только эти
операции с дисковым блоком
1.2 Архитектура СУБД 9
Для ответа на запрос нужно проверить отношение Customers, чтобы найти но-
мер страхового полиса Салли Джонс (предполагается, что существует единственный
клиент с таким именем, хотя на практике их может оказаться несколько). Затем
следует проверить отношение Accounts, чтобы найти каждый счет с данным номе-
ром страхового полиса и напечатать балансы этих счетов.
Простой, но дорогостоящий план — проверять все кортежи (строки) отноше-
ния Customers до тех пор, пока не найдется имя клиента Салли Джонс В среднем
придется проверить половину кортежей чтобы найти это имя. Поскольку банк
может иметь множество клиентов, отношение Customers займет много дисковых
блоков, так что этот шаг окажется очень дорогим. Недостаточно получить номер
страхового полиса Салли Джонс. Нужно еще просмотреть кортежи отношения
Accounts и найти счета с этим номером Поскольку таких счетов может быть мною,
придется просматривать все кортежи Как правило, в банке много счетов, поэтому
отношение Accounts гоже займет много дисковых блоков и их просмотр обойдется
весьма дорого.
Более подходящий вариант решения, если имя клиента для отношения
Customers имеет индекс, вместо просмотра всего отношения Customers использо-
вать индекс для поиска только того дискового блока, который содержит кортеж
для Салли Джонс. Как упоминалось в тексте раздела 1.2.1, заключенном в рамку,
типичный индекс В-дерева требует просмотреть три дисковых блока этого индекса,
чтобы найти то, что нужно3. Доступ еще к одному дисковому блоку дает кортеж
для Салли Джонс.
Разумеется, нужно сделать и второй шаг: найти кортеж с заданным номером
страхового полиса в отношении Accounts Для этого обычно требуется многократ-
ный доступ к диску. Однако при наличии индекса на номере страхового полиса
для отношения Accounts можно найти каждый блок, содержащий один из счетов
с данным номером, просматривая указанный индекс. Для этого необходимы два
или три доступа к диску, как и в случае с индексным доступом к отношению
Customers. Если все требуемые кортежи находятся в различных дисковых блоках,
нужен доступ к каждому из этих блоков. Но один человек может и не иметь мно-
жества счетов, так что на этом шаге, возможно потребуется небольшое количество
доступов к диску.
Итак, если оба упомянутых выше индекса существуют, на запрос, вероятно,
можно ответить с помощью шести — десяти доступов к диску. Если же нет одного
из них или обоих, придется использовать менее эффективные планы запросов.
Тогда число требуемых доступов может возрасти до сотен и тысяч, так как придет-
ся сканировать все большое отношение. □
Из приведенного примера может создаться впечатление, что оптимизация за-
просов исчерпывается применением индексов если таковые существуют. На самом
деле это не так. Сложные запросы часто позволяют изменять порядок операций,
и может существовать очень большое число возможных планов, часто растущее по
экспоненте в рамках одного запроса. Иногда невозможно использовать оба индекса
и приходится выбирать один из двух. Анализ этой важной части реализации СУБД
выходит за рамки данной книги.
1.2.4 Менеджер транзакций
Как говорилось в разделе 1.1, СУБД должна гарантировать выполнение опре-
деленных операций на БД Например, важно, чтобы результат выполнения опера-
ции никогда не был утрачен, даже о случае серьезной поломки системы Типичная
з Поскольку корневой узел В-дерева используется при каждом поиске, включающем
индекс его блок чисто обнаруживается в основной памяти и занимает одну страницу
буфера. поэтому на практике достаточно доступа к двум дисковым блокам
10
Глава 1 Миры систем баз данных
СУБД позволяет пользователю сгруппировать несколько запросов и/или изменений
н одной транзакции. Неформально говоря, транзакция - это группа операций, ко-
торые необходимо выполнить последовательно как единое целое
Часто система ЬД допускает параллельную поддержку .множества транзакций
(например, что-то может происходить на нескольких банкоматах одновременно).
Гарантировать правильное выполнение всех таких транзакций — задача компонента
СУБД, называемы о менеджером транзакций. Говоря точнее, '’правильное" выполне-
ние транзакций требует того, что часто называется АС//)-свойствами (atomicity,
consistency, isolation, durability — четырех основных требования к выполнению
транзакций).
• Атомарность Требуется, чтобы были выполнены все транзакции или не
была выполнена ни одна из них. Например, изъятие денег из банкомата и
внесение соответствующего дебета в счет клиента должны быть единствен-
ной атомарной транзакцией. Отдельное выполнение одной из этих операций
не допускается
• Непротиворечивость. Обычно БД характеризуется закнм понятием, как непро-
тиворечивое состояние, при котором данные соответствуют всем возможным
ожиданиям. Например, условие непротиворечивости для БД авиационных
линий состоит в том, что ни одно из мест в самолете не бронируется для
двух клиентов. Хотя это условие может ненадолго нарушаться в процессе
транзакции, когда люди размешаются по местам, менеджер транзакций
должен гарантировать, что после завершения транзакции БД будет удовлет-
ворять всем предполагаемым требованиям непротиворечивости
• Изоляция При параллельном выполнении двух или более транзакций их
результаты должны быть изолированы друг от друга. То есть, одновременное
выполнение двух транзакций одновременно не должно привести к резуль-
тату. которого не было бы, если бы они выполнялись последовательно.
Например, когда агенты продают билеты на один и тот же рейс и остается
единственное свободное место, запрос одного из них должен быть удовлетво-
рен. а запрос другого отвергнут Недопустимо, чтобы по причине парал-
лельных операций одно место было продано дважды.
• Долговременность. Если транзакция завершена, ее результат не должен быть
утрачен в результате сбоя системы, даже если этот сбой происходит немед-
ленно после завершения транзакции.
Реализация транзакций с ACID-свойствами может быть темой отдельной
книги, и мы не будем пытаться осветить эту тему полностью Однако в разделе 7.2
будет показано, как в языке SQL определить операции, относящиеся к транзакци-
ям. и что может извлечь программист SQL из объединения операций в транзакции
В этом разделе очень кратко описаны общие методы обеспечения свойств ACID
Размеры блокируемых элементов
СУБД могут различаться в соответствии с тем. какие виды элементов
{ данных имеют блокировки Например, можно блокировать отдельные корте
’ жн отношения, отдельные дисковые блоки или целые отношения. Чем больше
элемент, имеющий блокировку, тем больше вероятность, что одна транзакция
: должна ждать завершения другой, даже если они не имеют реального доступа
к одним п тем же данным. Однако чем меньше блокируемый элемент, тем
' больше и сложнее механизм блокировки.
1.2 Архитектура СУБД
11
Блокировка
Главной причиной отсутствия изоляции транзакций является то, что транзак-
ции считывают или записывают в БД один и тот же экземпляр данных. Напри
мер, если две транзакции пытаются одновременно записать новый баланс одного
и того же счета, одна из записей будет внесена поверх другой, п результате чего
первая запись будет утрачена. В большинстве СУБД менеджер транзакций может
блокировать элементы, к которым транзакция осуществляет доступ. Пока одна
транзакция блокирует элемент данных, другая транзакция не имеет к нему
доступа Например, блокировав счет 12345, первая транзакция может читать его
и вносить новое значение до того, как другая транзакция получит к нему доступ.
Вторая транзакция прочтет уже новый, а не старый баланс, и обе транзакции мо-
гут вполне успешно взаимодействовать.
Регистрация
Регистрация всех начатых транзакций, изменения в БД, вызванные каждой
транзакцией, и завершение каждой из них осуществляются менеджером транзак-
ций Регистрация всегда записывается в постоянной памяти, на носитель типа
диска где данные могут пережить сбой питания, В то время как сама транзакция
в отдельных операциях может использовать изменяющуюся основную память,
регистрация всегда немедленно вносится на диск. Регистрация всех операций —
важный фактор обеспечения свойства долговременности.
Завершение транзакции
Для обеспечения долговременности и атомарности транзакции обычно выпол
няются "пробным" способом, при котором изменения БД подсчитываются, но не
вносятся в саму БД. Когда транзакция готова к окончанию работы, или к заверше-
нию, изменения копируются в протокол, который в первую очередь копируется на
диск, и только после этого изменения вносятся в саму БД.
Даже если сбой системы происходит между этими шагами, после ее восстанов
ления можно прочесть протокол и узнать, какие еще изменения нужно внести в БД.
Если сбой системы происходит до того, как изменения были внесены в протокол,
можно повторить транзакцию, не опасаясь, например, что дважды забронировано
одно и то же место в самолете или дважды внесен один и тот же дебет в банковский
счет.
1.2.5 Архитектура клиент/сервер
Во многих вариантах современного ПО реализуется архитектура, в которой один
процесс (клиент) посылает запрос для выполнения другому процессу (серверу). БД
не исключение, и работа компонентов, показанных на рис. 1.1, часто разделяется
иа процесс сервера и несколько процессов клиентов.
В простейшей архитектуре клиент/сервер вся СУБД является сервером за
исключением интерфейсов запроса, которые взаимодействуют с пользователем
и посылают запросы или другие команды на сервер. Например, реляционные сис
темы широко используют язык SQL для представления запросов от клиента серве
ру. Затем сервер БД возвращает клиенту ответ в виде таблицы или отношения.
Отношение клиента с сервером может быть более сложным, особенно когда ответы
являются слишком большими (см. раздел 1.3.3). Имеет место тенденция увеличения
нагрузки на клиента, так как при наличии множества одновременно работающих
пользователей БД с сервером могут возникнуть проблемы.
12
лава 1 Миры систем баз данных
1.3 Будущее систем БД
В настоящее время БД развиваются в различных направлениях. Некоторые из
них — новые технологии, объектно-ориентированное программирование, ограниче-
ния и триггеры, мультимедийные данные или WWW — изменяют саму природу
конвенциональных СУБД. Другие включают в себя новые приложения типа храни-
лища или интеграции данных Ниже дается краткий анализ основных направлений
развития систем БД.
1.3.1 Типы, классы л объекты
Объектно-ориентированное программирование часто рассматривается как
средство улучшения организации программ и в конечном счете как более надежное
средство реализации ПО. Впервые популяризованное в языке Smalltalk объектно-
ориентированное программирование получило серьезный стимул развития с появле-
нием C++ и переходом на него большинства разработок ПО. выполнявшихся
ранее иа С. Чуть позже интерес к объектно-ориентированному программированию
возрос благодаря языку Java, подходящему для распространения программ no WWW.
Мир БД тоже стал привлекателен для объектно-ориентированной парадигмы, и
многие компании продают ''объектно-ориентированные' СУБД. Напомним читателю
идеи, положенные в основу объектной ориеншиии.
Система типов
Объектно-ориентированное программирование предлагает пользователю бога-
тый набор типов. Начиная с базовых типов, простых чисел, действительных чисел,
булевых выражений и строк символов, можно создать новые типы с помощью
конструкторов типов. Обычно они позволяют построить:
I. Структуры записей. При наличии списка типов 7,, Т2. Т„ и соответст-
вующего списка имен полей (называемого в языке Smalltalk переменными
экземпляров) ft, fi, , f„ можно построить тип записей, состоящих из
л компонентов Компонент i имеет тип Т„ и ссылка на него делается по
имени его поля f. Структуры записей совпадают с тем, что в языке С или
C++ называется "страктами" (structs).
2. Типы множеств При наличии типа Т можно построить новые типы, при-
меняя оператор множества к типу Г В разных языках используются
различные операторы множества, ио есть общие операторы, такие как
массивы, списки и множества. Значит, если Т — число базового типа,
можно построить типы "м юсив чисел', "список чисел" или множество чисел".
3. Типы ссылок. Ссылка на тип Т — это тип, значения которого подходят
для локализации значения типа Г. В С и C++ ссылка — это "указатель"
значения, те. место, и котором находится внесенный в виртуальную
память адрес указанного значения. Часто для понимания ссылок исполь-
зуется модель указателей однако в системах БД. где данные хранятся на
многих ансках, возможно, распределенных на множестве узлов, ссылка по
необходимости сложнее указателя. Например, она может включать в себя
имя узла номер диска, блок данного диска и позицию в блоке занимае
мую значением, на которое делается ссылка
Разумеется, структуру отчетов и операторы множества можно применять по-
вторно для построения еще более сложных типов. Можно определить тип, являю
щпйся структурой отчета, первый компонент которой пол именем customer
относится к тину строк а второй под именем accounts относится к типу множества
всея Такой тип подходит для установления соответствия между ю центами банка
и их счетами
1.3 Будущее систем БД
13
Классы и объекты
Класс состоит из типов и. возможно, из нескольких функций или процедур
(называемых методами, см. ниже), которые можно выполнить на объектах этого
класса. Объекты класса — это или значения данного типа (называемые неизменяе
мыми объектами), или переменные, значения которых относя гея к этому же типу
(изменяемые объекты). Например, если по определению класс С относится к типу
'множество чисел", {2,5,7} — это неизменяемый объект класса С, тогда как пере-
менную г можно отнести к классу С и приписать ей значение {2,5,7}.
Идентичность объектов
Предполагается, что все обтлкты имеют значение, называемое идентичностью
объекта (OID). Никакие два объекта не могут иметь одно и тоже OID, и ни один
объект не может иметь два различных OID. OID —это значение, которое имеет
ссылка на конкретный объект. 01D часто рассматривают как ссылку на объект в
виртуальной памяти, но, как было сказано при обсуждении типов ссылок, в системе
БД OID может быть более сложной конструкцией — последовательностью битов,
достаточной для размещения объекта во вторичной памяти или на дополнительных
носителях памяти неограниченного числа различных компьютеров. Поскольку
данные сохраняются долго, OID должен быть корректным на протяжении всего
времени существования данных.
Основания для использования объектов
Объектно-ориентированное программирование обеспечивает для систем БД
ряд важных средств.
• С помощью богатой системы типов можно оперировать данными
в формах более естественных, нежели отношения в прежних моделях
данных. Заметим, что реляционная модель имеет достаточно ограничен-
ную систему типов. Отношения — это множества записей, имеющих
структуру, в которой поля (называемые "атрибутами" в реляционной
модели) имеют базовые типы.
• Совместное или повторное использование ПО и схем с помощью классов
и их иерархии Проше, чем в конвенциональных системах.
I • Абстрактные типы данных помогают предотвратить неправильное
использование данных, если разрешить доступ к ним только посред-
। ством точно спроектированных функций, которые используют данные
I правильно.
Методы
Обычно с классом ассоциируются определенные функции, которые часто на
зывают методами. Метод для класса С имеет по крайней мере один аргумент, явля-
ющийся объектом класса С, и может иметь другие аргументы любого класса,
включающего в себя С Например, для класса типа "множество целых чисел" мож-
но иметь метод вычисления мощности данного класса, объединения двух множеств
или возвращения булева значения, показывающего, является ли данное множество
пустым.
14
Глава 1 Миры систем баз данных
Абстрактные типы данных
Во многих случаях классы являются "абстрактными типами данных": они
инкапсулируют ши ограничивают доступ к объектам данного класса так, что только
методы, определенные для этого класса, могут прямым образом изменять его
объекты. Такое О1раничспие гарантирует, что объекты класса нельзя изменить
способам । неприемлемыми для того, кто данный класс реализовал. Это одно из
ключевых средств разработки надежного ПО.
Иерархии классов
Можно один класс С объявить подклассом другого класса D. Тогда класс С на-
следует все свойства класса £>, включая тип D и все функции, определенные дня D.
Однако С может иметь и дополнительные свойства. Например, для объектов класса С
можно определить новые методы либо взамен методов класса D, либо в дополнение
к ним. Можно даже расширить тип D различными способами. В частности, если
типом D является структура записей, к этому типу можно добавить новые поля,
представляющие только объекты типа С.
Пример 1.3. Рассмотрим класс, объектами которого являются банковские счета.
Неформальное описание тина этого класса:
CLASS Ассо int = {accountNo: integer;
balance: real;
owner: REF Customer,
}
В этом примере тип класса Account —это структура записи с тремя полями:
номером счета, выраженным целым числом, балансом, выраженным действитель-
ным числом, и владельцем, являющимся ссылкой на объект класса Customer (этот
класс необходим для банковской БД. но его тип здесь не вводится).
Для этого класса можно определить методы, например, метод
deposit(a: Account, m: real)
увеличивающий balance для объекта а класса Account на величину т.
И наконец, класс Account может иметь множество подклассов. Например, у
счета временного вклада может быть дополнительное поле dueDate обозначающее
дату, когда владелец может снять баланс со счета. Можно определить также допол-
нительный метод для подкласса TimeDeposit
penalty(a: TimeDeposit)
приписывающий счет а подклассу TimeDeposit и начисляющий штраф за прежде-
временное снятие денег со счета как функцию от поля dueDate объекта а и теку-
щей даты, полученной из системы в которой действует данный метод □
Объектно-ориентированные методы систем БД будут рассматриваться во мно-
гих частях этой книги. В разделе 2.1 вводится объектно-ориентированный язык
проектирования БД ODL, а глава 8 посвящена объектно-ориентированному языку
запросов. Мы рассмотрим и язык запросов OQL, ставший стандартным для объект-
но-ориентированных СУБД, и объектно-ориентированные свойства SQL, стандарт-
ного языка запросов для реляционных СУБД.
1.3 Будущее систем БД 15
1.3.2 Ограничения и триггеры
Другим новым направлением развития БД является широкое применение актив-
ных элементе! в коммерческих системах. "Активность" компонента БД означает, что
он доступен в любое время, готов к выполнению действий в подходящие для них
моменты В системах БД существует два общих вида активных элементов.
I. Ограничения — это булевы функции, значения которых должны быть ис-
тинными. Например, в банковскую БД можно ввести ограничение, со-
гласно которому баланс не может быть меньше нуля. Изменение БД,
нарушающее это ограничение, например изъятие денег, делающее счет
отрицательной величиной, отвергается СУБД
2. Триггеры — это части программы, ожидающие какого-то события. Собы
тиями могут быть введение или удаление элементов данных определенно-
го типа Когда событие происходит, выполняется (или инициируется)
определенная последовательность действий. Например, система резерви-
рования авиабилетов может иметь правило, условие которого иницииру-
ется, когда какой-то рейс приобретает статус cancelled. Действующей
частью правила может быть запрос номеров телефонов всех клиентов, за-
бронировавших билеты на этот рейс, для их оповещения об отмене рейса.
Более сложное действие — автоматическое бронирование мест для этих
клиентов на другие альтернативные рейсы.
Активные элементы не являются чем-то принципиально новым. Они возникли
как "ON-условия" в языке программирования PL/I. В течение многих лет они
появлялись также в системах искусственного интеллекта и родственны демонам,
применяемым в операционных системах. Однако, когда объем данных, на которых
действуют активные элементы очень велик, число их интенсивно возрастает
и возникают технические трудности их эффективной реализации. Поэтому актив-
ные элементы не применялись в стандартных компонентах СУБД до начала 1990 х.
В этой книге они рассматриваются в главе б.
1.3-3 Данные мультимедиа
Еще одно важное направление развития систем БД — введение данных мульти-
медиа. Мультимедиа — это информация, представляющая сигнал определенного
вида. Общие формы данных мультимедиа: видео, аудио, сигналы радара, спутнико-
вые образы, а также документы и графические изображения в различных кодиров-
ках. Общее во всех этих формах то, что их размеры значительно превышают
размеры прежних форм данных — целые числа, строки символов фиксированной
длины и т.д.— и очень сильно варьируются.
Для хранения данных мультимедиа пришлось создавать различные средства
расширения СУБД. Операции, выполняемье сданными мультимедиа, не являются
простыми и не подходят для традиционных форм данных. Например, можно искать
в банковской БД счета с негативными балансами, сравнивая каждый баланс с чис-
лом 0 0, но невозможно найти в БД фотографии, ''похожие" на конкретный образ.
Поэтому СУБД должно включать в себя возможности пользователей вводить по
собственному выбору функции, применимые к данным мультимедиа. Часто объек -
но-ориентированные методы используются для таких расширений даже в реляиион
ных системах.
Размеры объектов мультимедиа также вынуждают СУБД модифицировать
менеджер памяти для работы с объектами или кортежами размером гигабайт или
более. К проблемам, связанным с такими большими элементами, относится и
проблема ответов на запросы, В конвенциональной, реляционной БД ответы — это
множества кортежей, которые сервер БД поставляет клиенту как единое целое.
16
Глава! Миры систем Еаз данных
Предположим, однако, что ответ на запрос — это видеоклип длиной в гига-
байт. Сервер не может предоставить клиенту гигабайт в виде единого целого.
Во-первых, это займет слишком много времени и не позволит серверу обрабаты-
вать другие запросы Во-вторых, может оказаться, что клиенту нужна только не-
большая часть клипа, но запросить именно то, что ему нужно, не просмотрев
начало клипа, он не мог. В- ретьих, даже если клиенту нужен весь клип, например,
для просмотра его на экране, достаточно передавать клип с фиксированной
скоростью в течение часа (столько времени уходит на просмотр гигабайта уплотнен-
ного видео). Итак, система памяти мультимедийной СУБД должна выдавать ответы
в интерактивном режиме, передавая клиенту части ответа по его требованию или
с фиксированной скоростью.
1.3-4 Интеграция данных
По мере тою как информация становится все более существенной для нашей
работы и игры, появляются и новые способы использования существующих инфор-
мационных ресурсов. Например, рассмотрим компанию распространяющую элект-
ронный каталог всех своих продуктов, с помощью которого посредством WWW
можно было бы найти нужный продукт и заказать его. В большой компании много
отделов, и каждый из них мог независимо от других создать собственную БД по
продуктам Они могли использовать различные СУБД, различные структуры ин-
формации и даже называть один и тот же продукт по-разному.
Пример 1.4. Представьте себе компанию по производству дисков, имеющую
множество отделов. В каталоге одного отдела скорость вращения диска может быть
представлена в оборотах в секунду, в каталоге другого — в оборотах в минуту,
а третий эту скорость вообще игнорирует И отдел, производящий дискеты,
и отдел, выпускающий жесткие диски, могут называть свои продукты дисками.
В одном отделе число дорожек на диске может называться дорожками, а в другом
цилиндрами □
Контроль со стороны центра не всегда лучшее решение. Отделы могли вло-
жить в свои БД огромные инвестиции задолго до того, как интеграция отделов
стала очевидной проблемой. Отдел мог ранее быть независимой компанией,
недавно присоединившейся к корпорации. По самым разным причинам так
называемые наследственные БД не так легко заменить. Значит, компания должна
надстроить над такими БД структуру, дающую пользователю единое представление
о всех своих продуктах.
Чаше всего проблема решается путем сознания хранилищ данных, в которых
копируется информация множества наследственных БД и соответствующим обра-
зом переводится в центральную БД При изменении наследственных БД хранилище
обновляется, но необязательно в тот же момент Согласно общей схеме хранилище
реконструируется каждую ючь, когда наследственные БД, вероятнее всего, менее
загружены работой.
Таким образом, наследственные БД могут продолжать выполнять задачи, ради
которых они были созданы. Новые функции типа распространения электронного
каталога через Web выполняются в хранилище данных. Оно может применяться
также для планирования и анализа Например, аналитики компании могут посы-
лать в хранилище запросы о направлениях продаж для более эффективного плани-
рования оборудования и производства Создание хранилищ данных обеспечило
также разработку данных — поиск интересных, необычных образцов данных, поззо-
ляюшпх улучшить процесс продаж.
1.4 Краткий обзор книги
17
1.4 Краткий обзор книги
Вопросы, связанные с системами БД, можно разделить на три крупные категории:
I Проектирование БД. Как построить действительно полезную БД? Какие
виды информации поступают в БД? Как структурируется информация9
Какие допущения принимаются относительно типов или значений эле-
ментов данных9 Как связаны элементы данных?
2. Программирование БД Как выражаются в БД запросы и другие операции?
Как применяются другие средства СУБД типа триггеров или транзакций9
3. Реализация БД. Как строится СУБД, осуществляющая обработку процессов
и транзакций, а также организацию памяти для эффективного доступа?
Хотя реализация БД является главной частью индустрии ПО, число людей,
проектирующих или использующих БД, намного превосходит число тех, кто строит
БД. Эта книга — вводный курс по системам БД, поэтому уместно сосредоточиться
на первых двух аспектах: проектировании и программировании. В данной главе
мы попытались кратко познакомить читателя и с реализацией но в дальнейшем
мы больше не будем к ней возвращаться. В остальных главах рассматривается
проектирование и программирование в следующей последовательности
1.4.1 Проектирование
Проектированию посвящены главы 2 и 3 В главе 2 рассмотрены две нотации
высокого уровня для выражения проектов БД: язык определения объектов ODL —
объектно-ориентированный язык декларирования классов; модель E/R (или модель
сущности-связи) — графическая система обозначений для описания организации БД.
Ни ODL, ни модель E/R не предназначены для прямого применения в качест-
ве определения структуры БД, хотя ODL очень близок к языку определения данных
при наличии объектно-ориентированной СУБД. Вместо этого предполагается, что
проект, представленный в одной из этих моделей, будет переводиться в любую
формальную нотацию, используемую языком определения данных, связанным с
применяемой СУБД. Поскольку большинство СУБД являются реляционными, со-
средоточимся на переводе ODL или E/R в реляционную модель. Поэтому глава 3
посвящена реляционной модели и процессу перевода. Далее, в разделе 5.7 будет
показано, как формально представить схемы реляционной БД в части языка SQL,
связанной с определением данных.
1.4.2 Программирование
Главы с 4 по 8 посвящены программированию БД В главе 4 дана абстрактная
трактовка запросов в реляционной модели, введено семейство операторов на отно-
шениях, образующее реляционную алгебру, а также рассмотрен альтернативный
способ описания запросов, основанный на логических выражениях, под названием
Datalog.
Главы с 5 по 7 посвящены программированию па SQL— доминирующем
языке запросов. В главе 5 вводятся базовые понятия, относящиеся к запросам
в SQL. и выражение схем БД в SQL. Почти все в этой и последующих двух главах
основано на стандартной версии SQL, называемой SQL2. Однако определенные
аспекты программирования SQL, которые можно найти в некоторых коммерческих
системах, не относятся к SQL2 В таких случаях используется более поздний, еще
не принятый формально стандарт SQL3.
Глава 6 посвящена аспектам SQL, связанным с триггерами и ограничениями
на данные. Поскольку в этих областях возможности SQL2 ограничены, мы уделим
внимание и трактовке ограничений и триггеров в языке SQL3.
18
Глава! Миры систем баз данных
В главе 7 рассматриваются более сложные аспекты программирования SQL.
Хотя простейшей моделью программирования SQL является автономный интер-
фейс порождения запросов, на практике большинство SQL-программ погружается
п более сложную программу, написанную на конвенциональном языке типа С.
В главе 7 показано, как соединять операторы SQL с окружающей их программой,
как передавать данные из БД переменным программы и обратно и как средства
SQL применяются для определения транзакций, подключения клиентов к серверу
и авторизации доступа к БД теми, кто не является ее пользователем.
В главе 8 новые стандарты программирования объектно-ориентированных БД
рассматриваются в двух направлениях. Язык объектных запросов OQL можно счи-
тать попыткой совместить C++ с требованиями программирования БД высокого
уровня, а объектно-ориентированные свойства SQL3 — попыткой совмещения ре-
ляционных БД и SQL с объектно-ориентированным программированием. В опреде-
ленной степени эти два подхода имеют общую основу, хотя во многом отличаются
друг от друга
1.5 Итоги
♦ Системы управления БД СУБД позволяют проектировщикам структурировать
информацию, пользователям — запрашивать и изменять ее, а также обеспе-
чивает управление большими массивами данных и множеством параллель
ных операций с данными.
+ Языки БД. Существуют языки или компоненты языков для определения
структуры данных (языки определения данных), а также для запросов и изме-
нения данных (языки манипулирования данными).
+ Системы реляционных БД Сегодня большинство систем БД основано на ре
ляционной модели данных, организующей информацию в таблицы. Чаще
всего в этих системах применяется язык SQL.
♦ Объектно-ориентированные системы БД. В некоторых современных системах
БД используются идеи объектно-ориентированного моделирования данных,
в том числе классы, мощные системы типов, идентификация объектов и на-
следование свойств подклассами. По видимому, когда-нибудь большинство
систем управления БД, включая реляционные, будут поддерживать вес эти
свойства или некоторые из них.
+ Вторичная память и дополнительные носители памяти Большие БД хранятся
на устройствах вторичной памяти обычно на дисках Очень большие БД тре-
буют дополнительных носителей памяти, которые не только во много раз
вместительнее дисков, но и работают во много раз медленнее.
♦ Компоненты СУБД. Главными компонентами системы управления БД явля
ются процессор запросов, менеджер транзакций и менеджер памяти.
♦ Менеджер памяти Устройство управления пах ятью оперирует файлами
данных вторичной памяти и буферами основной памяти, содержащими части
этих файлов Система управления БД обычно оперирует индексами — струк-
турами данных, обеспечивающими эффективный доступ к данным.
+ Менеджер запросов Важная задача менеджера запросов — "оптимизация
запросе! ' те. нахождение хорошего алгоритма ответа на данный запрос.
4- Менеджер транзакций. Транзакции — это элементарные единицы работы в БД.
Менеджер транзакций позволяет выполнять транзакции параллельно, в то же
время гарантируя их свойства ACID: атомарность, непротиворечивость,
изолированность и долговременность.
1.6 Литература к главе 1 19
♦ Системы клиент/сераер. Системы управления БД обычно поддерживают
архитектуру клиент/сервер. в которой главные компоненты БД находятся на
сервере, клиент применяется для интерфейса с пользователем.
*• Активные элементы БД. Современные системы БД поддерживают некоторую
форму активных элементов, обычно триггеры и/или ограничения целостности.
+ Будущие системы. Большинство направлений развития систем БД включают
в себя поддержку очень больших мультимедийных объектов типа видео или
изображений и интеграцию информации из множества разных источников
в единой БД.
1.6 Литература к главе 1
Ниже приведен ряд книг, посвяшенных важным аспектам реализации систем БД.
[3] и [5] посвящены реализации менеджера транзакций. В этих же работах, а также
в |7 рассматривается реализация распределенной БД. Реализация менеджера файлов
описана в [II].
Системы объектно-ориентированных БД рассматриваются в (2J, [4] и [6], теория
систем БД — в ]1], [9] и [10] В [8] включено множество научных статей по БД
1. Abiteboul, S., R. Hull and V. Vianu, Foundations of Databases Addison-Wesley,
Reading, MA, 1995.
2 Bancilhon, F., C. Delobel, and P Kanellakis, Budding an Object Oriented
Database System, Morgan-Kaufmann, San Francisco, 1992.
3. Bernstein, P. A.. V. Hadzilacos, and N Goodman, Concurrency Control and-
Recovery in Database Systems, Addison-Wesley. Reading, MA, 1987
4. Gattell. R G G Object Data Management, Addison-Wesley. Reading, MA, 994
5. Gray, G. N. and A Reuter, Transaction Processing. Concepts and Techniques,
Morgan-Kaufmann, San Francisco, 1993
6 Kim, W (ed.). Modern Database Systems- The Object Model Interoperability,
and Beyond, ACM Press, New York, 1994.
7. Oszu, M T. and P. Valduriez, Principles of Distributed Database Systems,
Prentice Hall, Englewood Cliffs, NJ, 1991.
8. Stonebraker, M (ed ), Readings in Database Systems Morgan-Kaufmann, San
Francisco, 1994
9. Ullman, J. D.. Principles of Database and Knowledge-Bat>e Systems. Volume I,
Computer Science Press, New York, 1988.
10. Ullman, J. D., Principles of Database and Knowledge-Base Systems, Volume II,
Computer Science Press, New York. 1989.
II. Wiederhold, G., Database Design, McGraw-Hill. New York, 1983
Глава 2
Моделирование базы данных
Процесс проектирования БД начинается с анализа того, какую информацию
должна содержать БД и определения отношений между компонентами этой
информации Часто структура БД, называемая схемой БД, определяется в одном
из нескольких языков, или нотаций, которые подходят для выражения проектов.
После соответствующего рассмотрения проекту придается форма, позволяющая
ввести его в систему управления БД, и БД начинает свое физическое существование.
В этой книге используются две нотации проектирования Более традиционная
из них, называемая моделью сущности-связи (L/R), имеет графическую природу,
с прямоугольниками и стрелками, представляющими главные элементы данных
и их связи Параллельно введем ODL — объектно-ориентированный подход к про-
ектированию БД. Этот стандарт для объектно-ориентированных БД только форми-
руется. В данной главе упоминаются еще две модели — сетевая и иерархическая,
представляющие в основном исторический интерес. В каком-то смысле это ограни-
ченные версии ODL, применявшиеся в коммерческих системах БД в 70-х годах
В главе 3 мы рассмотрим реляционную модель, в которой мир представлен
множеством таблиц. Реляционная модель имеет несколько ограниченные структуры
представления данных однако она исключительно проста и полезна. В настоящее
время именно на ней базируется большинство коммерческих систем управления
БД. Часто проектировщики начинают построение схемы с помощью E/R-модели
или основанной на объектах модели, а затем преобразуют эту схему в реляционную
модель для реализации
На рис. 2.1 изображен процесс проектирования
Идеи
Рис. 2.1. Процесс моделирооония и реализации БД
Начнем с того, какую информацию моделировать. Эти идеи должны быть
выражены । каком то языке проектирования В качестве альтернативы здесь исполь-
зуютоя F/R и ODL хотя существуют, конечно к другие языки. Затем в большинстве
с.чунев проекгы будут реализованы с помощью системы управления реляш онной
БД Поэтому с помощью чисто механического процесса, рассмотренного в 1лаве 3.
2.1 Введение в ODL
21
абстрактный проект конвертируется п конкретную реализацию реляционной БД.
Мы рассмотрим и альтернативный путь: когда проект ODL становится вводом
в систему управления объектно-ориентированной БД. В этом случае перевод явля-
ется автоматическим и может состоять из простой трансляции выражений ODL
в соответствующее выражение объек1но-ориентировапного языка программирова-
ния типа C++ или Smalltalk.
2.1 Введение в ODL
ODL — стандартный язык для определения структуры БД в объектно-ориен-
тированных терминах таких языков, как C++ и Smalltalk. Это расширение языка
описания интерфейса IDL, являющегося компонентом CORBA — формирующегося
стандарта распределенных объектно-ориентированных вычислений.
Абстрактный
ODL
Погружение ODL
в C++
OODBMS,
основанная на C++
Погружение ODL
в Smalltalk
OODBMS,
основанная на Smalltalk
Рис. 2.2. Нонаертироеоние проектов ODL в вырожения для OODBMS
Главное назначение ODL — обеспечить запись объектно-ориентированных про-
ектов и ее последующий прямой перевод в выражения объектно-ориентированной
СУБД (OODBMS). Поскольку основным языком таких систем является C++ или
Smalltalk, ODL необходимо переводить в выражения этих языков. ODL соответст-
вует им обоим (но больше C++), поэтому предложенный на рис. 2.2 перевод
достаточно прост. Гораздо сложнее перевод из ODL или проектов, реализованных
в терминах модели сущности-связи, в выражения, подходящие для более общих
систем управления реляционными базами данных (RDBMS).
Схемы и данные
ODL — язык для определения схемы или структуры данных, не имеющий i
средств для определения реального содержания БД, запросов или операций |
с данными.' Как упоминалось в разделе 1.1. языки определения схемы типа |
ODL часто называются языками определения данных, в то время как языки, !
позволяющие определять содержание БД или запрашивать и изменять данные, |
языками манипулирования дачными. Мы не будем обсуждать последние, пока |
в главе 4 не рассмотрим БД с точки зрения пользователя. Основу изучения БД j
с точки зрения проектировщика составляю языки определении даш ых.
L=._____ ._______,__~____ ________ - —— — —= =—1
2.1.1 Объектно-ориентированное
проектирование
Как считается в объектно-ориентированном проектировании, мир состоит из
оаьек нчв — определенных наблюдаемых сущностей. Например, люди, бажовские
счета, авиарейсы, курсы в колледже, здания и т.д. могут мыслиться как объекты
Как было сказано в разделе 1.3.1, предполагается, что каждый объект можно уникаль-
ным образом идентифицировать, чтобы отличить его от любого другого объекта.
22
Глава 2 Моделирование базы данных
Природа OID
1 Как говорилось в разделе I 3 1 объектно-ориентированные БД бывают '
настолько большими, что число необходимых OID намного превосходит число i
адресов п адресном пространстве Поэтому системы объектно ориентированных
БД обычно имеют схему создания уникальных строк связанных с каждым
5 объектом: часто это довольно длинные строки—до 16 байт Например, j
объект может получить в качестве 01D время своего создания (измеряемое I
J в достаточно малых единицах чтобы один компьютер не мог создать два :
•; обт>ект,1 в одно и то же время) вместе с идентификатором хост-компьютера,
! создавшего его (если БД распределена на множестве хост-узлов).
> I
= м -X. —ч--— —а-е T.i—льш— тг ей чшишм-ттп - и и » г — л--*sw.*—г-дг— -*п-=»•«*=—»
Для организации информации обычно нужно сгруппировать объекты в классы
объектов, обладающих сходными свойствами. Понятия "объект” и "класс” в БД по
сути дела совпадают с этими понятиями в языках C++ и Smalltalk (вспомните
обсуждение объектно-орнентнрованных понятий в разделе 1.3.1). Однако, говоря
об объектно-ориентированных проектах в языке ODL, следует учитывать два пони-
мания "сходных свойств” объектов в классе.
• Понятия реального мира, представляемые объектами класса, должны быть
сходными. Например можно сгруппировать всех клиентов банка в один
класс, а все банковские счета в другой. Нет смысла объединять клиентов
и счета в одном классе, так как между ними практически нет ничего общего
и они играют очень разные роли в банковском мире.
• Свойства объектов в классе должны быть одними и теми же. Программируя
на объектно-ориентированном языке, мы часто представляем себе объекты
в виде .записей, как показано на рис. 2.3. Объекты имеют поля, или слоты,
и которых размешены значения. Такими значениями могут быть целые числа,
строки или массивы, ссылки на другие объекты, а также методы, т.е. функции
применяемые к объектам. Однако при изучении ODL мы не будем углубляться
в применение методов оно одинаково во всех объектно-ориентированных
языках программирования (о методах ODL см. раздел 8.1).
acctNo
balance
1-oOwner
Объект
Account
к объекту
Customer
Рис. 2 3 Объект представляющий счет
Иногда бывает удобно считать, что объекты имеют структуру записи, тем не
менее данная глава посвящена проектированию па абстрактном уровне Мы со-
средоточимся н i более абстрактных понятиях класса и его свойств, не вдаваясь
в детали реализации типа упорядочивания полей записи и даже и реальное пред-
ставление объекта с помошью структуры записи.
2.1 Введение в ODL 23
Определяя проект классов ODL, будем описывать свойства следующих видов.
I. Атрибуты — свойства, типы которых строятся из исходных типов, напри-
мер целых чисел или строк. Характерно то. что атрибут имеет тип, не
включающий в себя ни одного класса. В ODL типы атрибутов ограничены.
Более подробно этот вопрос будет рассмотрен в разделе 2.1.7.
2. Связи — свойства, типом которых являются ссылка на объект некоторого
класса или набор (например множество) таких ссылок.
3. Методы — функции которые можно применить к объектам класса. Как
уже было сказано, здесь применение методов не рассматривается,
2.1.2 Описания интерфейса
Описания класса в ODL в их простейшей форме состоят из следующих элементов:
I Ключевого слова interface
2 Имени интерфейса (т.е. класса).
3 Списка свойств класса, заключенного в скобки. Напоминаем, что свойства —
это атрибуты, связи и методы.
Простая форма описания интерфейса:
interface <имя>{
<список свойств*
}
2.1.3 Атрибуты в ODL
Свойства в их простейшем виде называются атрибутами. Эти свойства описы-
вают определенные аспекты объекта, связывая с ним значение некоторого простого
типа Например, все объекты person могут иметь атрибут name, типом которого
является строка, а значением — имя данного человека. Эти объекты могут иметь
также атрибут birthdate, являющийся тройкой целых чисел (те. структурой записи),
выражающей год, месяц и лень рождения человека.
Пример 2.1. На рис. 2.4. приведено ODL-описание класса фильмов. Здесь оно
относительно простое; позже мы расширим его.
1) interface Movie {
2) attnbute string title;
3) attribute integer year;
4) attribute integer length
5) attribute enum Film {color, blackAndWhite} filmType
);
Рис. 2 4. ODL-описание класса Movie
Строка I описывает Movie как класс. Ключевое слово interface используется
в ODL для выражения класса1. За строкой i следуют описания четырех атрибу
тов, которые имеют объекты класса Movie Первый из них на строке 2 называется
1 Технически n ODL класс — это интерфейс плюс реализация структур данных
и методов, связанных с интерфейсом. В этом разделе реализация интерфейсов ODL
нс рассматривается но в дальнейшем будем считать, что описания интерфейса
определяют класс я".
24
Глава 2 Моделирование базы данных
title. Его типом является string — строка символов неизвестной длины. Предполага-
ется, что значением атрибута title в любом объекте Movie будет название фильма.
Два следующих атрибута (year и length), описанные на строках 3 и 4 имеют тип
целых чисел и представляют год создания фильма и его длину в минутах На строке 5
описан атрибут Mm Гуре, иоказываюиипТ, фильм цветной или черно белый Его тип —
перечень с именем Film. Значения шрпбуга перечня кыбираются из списка .««перо
поп, в данном примере — color и blackAndWhite.
Определенный таким образом объект Movie можно считать записью, или
кортежем, состоящим из четырех компонентов, по одному для каждого атрибута.
Например:
("Унесенные ветром", 1939 231, цветной)
является обьектом Movie. □
Пример 2.2. В примере 2.I атрибуты имеют атомарные типы Могут быть атри-
буты. типами которых являются струк1уры, множества или множества структур.
Они будут рассмотрены в разделе 2.I.7. Здесь приводится пример с неатомарным
типом.
Определим класс Star.
1) interface Star {
2) attribute string name:
3) attribute Struct Addr;
{string street, string city] address,
}.
Строчка 2 определяет атрибут name (имя кинозвезды), являющийся строкой.
Строчка 3 определяет атрибут address, имеющий тип структуры записи Имя этого
атрибута Addr, а его тип состоит из двух полей: street и city. Оба поля являются
строками. В общем случае в ODL можно определить типы структуры записи
с помощью ключевого слова Struct и фигурных скобок, выделяющих список имен
полей и их типы □
2.1.4 Связи в ODL
Изучение атрибутов объекта играет большую роль, однако иногда важнее знать
то, как он связан с объектами того же самого или другого класса.
Пример 2.3. Предположим, что к описанию класса Movie из примера 2.1 до-
бавляется свойство, представляющее множество кинозвезд. Поскольку сами кино-
звезды являются классом, описанным в примере 2 2, информацию о них нельзя
сделать атрибутом Movie, так как типы атрибутов не должны быть классами иди
строиться из классов Множество кинозвезд, занять* в фильме,—это связь между
классами Movie и Star, которая выражается строкой
relationship Set<Star> stars,
в описании класса Movie. Эта строка может появиться на рис. 2 4 после любой из
строк — с I по 5. Он) означает, что в каждом объекте класса Movie есть множество
ссылок на объекты класса Star. Множество ссылок называется stars. Ключевое сло-
во relationship определяет, что stars содержит ссылки на другие объекты, а ключевое
слово Set. предшествующее <Stars>, показывает, что stars ссылается на множество
объектов Stars, а не на единственный объект В общем случае в ODL тип, яв1яю-
шийси множеством элементов другого типа 7’, определяется ключевым словом Set
। угловыми скобками, выделяющими тип Т
2.1 Введение в ODL 25
В физических терминах множество stars можно было бы представить списком
указателей на объекты Star; сами объекты Star физически не появлялись бы в объек-
те Movie. Однако на фазе проектирования БД физическое представление неизвестно
и важным аспектом связи является то, что из объекта Movie легко найти кинозвезд,
играющих в данном фильме. □
В примере 2.3 показана связь множества объектов (кинозвезд) с единственным
объектом (фильмом). Можно установить и связь единственного объекта с объектом
описываемого класса. Предположим, например, что в примере 2.3 был задан тип
связи Star, а не Set<Star>, с помощью строки
relationship Star starOf;
Это значит, что с каждым фильмом связан единственный объект Star. Такой способ
здесь не очень подходит, так как в фильме обычно играют несколько кинозвезд.
Однако во многих других примерах связь с единственным значением вполне
приемлема.
2.1.5 Обратные связи
Можно определять не только кинозвезд, занятых в данном фильме, но и фильмы,
в которых играл данный актер. Для получения такой информации в объектах Star
можно добавить строку
relationship Set<Movie> starredln,
к описанию класса Star из примера 2.2. Однако в такой строке и сходном описании
Movie не учитывается очень важный аспект связи между фильмами и кинозвездами,
а именно: если кинозвезда 5 находится в множестве stars для фильма М, то Л/ на-
ходится в множестве starredln для кинозвезды 5. Это соотношение связей между
множествами stars и starredln выражается тем, что в описании каждой связи указы-
вается ключевое слово inverse и имя другой связи. Если одна из связей находится
в другом классе, как это обычно и бывает, ссылка на нее делается с помощью
имени этого класса, за которым следуют двойное двоеточие (::) и 1мя связи.
Пример 2.4. Чтобы определить связь starredln класса Star как обращение связи
stars в классе Movie, изменим описание класса Star следующим образом (рис. 2 5):
1) interface Star {
2) attribute string name;
3) attribute Struct Addr
{string street, string city} address;
4) elationship Set<Movie> starredln
inverse Movie :: stars;
}
Put. 2.5. Клосс Star показывающий сепзь и ее обращение
В строке 4 выражено не только описание связи starredln, но и то, что данная связь
имеет инверсию Movie .sta s. Поскольку связь stars определена в другом классе,
ее имени предшествуют двойное двоеточие и имя этого класса (Movie) Такая нота-
ция широко применяется при ссылках на свойства различных классов. □
26 Глава 2 Моделирование базы данных
В примере 2.4 две обратные связи, каждая из которых соединяет объект
(фильм или кинозвезду) с множеством объектов. Как упоминалось ранее, есть связи
и другого типа, соединяющие объект с единственным объектом другого класса.
Понятие обращения связи при этом не изменяется. Общее правило: если связь Я
дня класса С соединяет с объектом v класса С множество объектов у2, .... у„. то
обратная к ней связь соединяет с каждым у, объект х (возможно, наряду с другими
объектами)
Иногда это помогает показать связь Я класса С с классом О и виде списка пар,
или кортежей, отношения Каждая пара сосгопт из объекта х из класса С и связан-
ного с ним объекта >• из класса £>
С 'О
*2 | У2
i
... I ...
Если Я имеет тип Set<D>, существует несколько пар с одним и тем же С-значением
Если Я имеет тип D, существует только одна пара с заданным С-значением.
Тогда обращение Я есть множество пар с обращенными компонентами:
D , С
У< Xi
Уг х2
Заметим, что это правило действует даже если Си/) являются одним и тем же
классом Существуют связи класса с самим собой, например связь "быть ребенком"
класса "люди” с самим собой.
О требовании к обращениям связей
{Абстрактный язык проектирования ODL требует чтобы связи были обра- |
тимы. Суть этого требования: если есть путь от объекта (например, фильма) [
i к связанному с ним объекту (в частности, к кинозвезде), то существует »
In обратный путь —от кинозвезды к фильмам, в которых она играла. Напри- |
мер, имея кинозвезду Чарльтона Хэстона можно проверить объекты фильмов !
и определить кинозвезд, которые в них играли, а затем перечислить фильмы, (
в которых играл Хэстон. ODL требует, чтобы такому процессу обращения !
присваивалось имя связи.
| Известно, что при преобразовании ODL в реальный язык программирова- ;
। ния, например C++, имеется возможность размещать ссылки только в объектах >
I "фильм", и не допускаются ссылки на фильмы в объектах "кинозвезда". Поэ- !
| тому погружение ODL в C++ допускает существование однонаправленных *
L связей. Поскольку же мы рассматриваем проектирование, а не реализацию, I
предполагается, что связи обратимы. I
.11 I Ж II .1 I —II м — ! — I ' ' ' ~ I - ।
2.1 Введение в ODL
27
2.1.6 Множественность связей
Важное значение имеет то, что данный объект связан с единственным объек-
том или он может быть связан с множеством других объектов. В ODL эти воз-
можности определяются тем, применяется или нет в описании связи оператор
множества типа Set При наличии обратимой пары связей существует четыре
возможности: связь может быть уникальной в одном из направлений, в обоих
направлениях или не быть уникальной ни в одном направлении
Рассмотренная выше связь между кинозвездами и фильмами не является
уникальной ни в одном направлении' обычно в фильме играет несколько кинозвезд
и одна кинозвезда появляется в множестве фильмов Следующий пример является
развитием предыдущих. В нем вводится класс Studio, представляющий студии,
выпускающие фильмы.
Пример 2.5. На рис. 2.6 приводится описание трех классов: Movie, Star и Studio.
Первые два из них уже были введены в примерах 2.1 и 2.2. Объекты студий имеют
атрибуты name и address, появляющиеся в строках 13 и 4 Заметим, что здесь типом
адресов является строка, а не структура, использованная для атрибута address класса
Star в строке 10. В различных классах можно использовать атрибут с одним и тем же
именем, но с разными типами.
1) interface Movie {
2) attribute string title;
3) attribute integer year;
4) attribute integer length;
5) attribute enum Film {color, blackAndWhite} filmType;
6) relationship Set<Star> stars
inverse Star.: starred n
7) relationsh p Studio ownedBy
inverse Studio:; owns;
}
8) interface Star {
9) attribute string name;
10) attribute Struct Addr
{string street, string city} address;
11) relationship Set<Movia> starredln
inverse Movie: stars:
};
12) interface Studio {
13) attribute string name;
14) attribute string address;
15) relationship Set<Movie> owns
inverse Movie.. ownedBy;
};
Рис. 2.6. Классы ODL и их связи
На строке 7 показана связь ownedBy между фильмами и студиями Поскольку
ее типом является Studio, а не Set<Studio>, каждым фильмом владеет только одна
студия Обращение данной связи показано в строке 15 — это связь owns между сту-
диями и фильмами. Ее типом является Set<Movie> поэтому каждая студия владеет
множеством фильмов — возможно, ни одним, только одним или большим числом
фильмов □
28
Глааа 2 Моделирование базы данных
Требования уникальности связи и ее обращения называются множественностью
связей. Наиболее распространенные варианты
I. Снизь типа "многие-ко-многим" класса С с классом D — это связь, в кото-
рой с каждым объектом класса С ассоциируется множество объектов
класса D, а в ее обращении с каждым объектом класса Л ассоциируется
множество объектов класса С. В описании, приведенном в примере 2.5,
stars — это связь типа "многие ко-многим“ между классом Movie и клас-
сом Star; такой же является связь starredln между классами Star и Movie.
В любом направлении связи допускается пустое множество; например,
в определенном фильме может вообще не быть звезд.
2. Снизь типа "многие-к-одному" класса С с классом D — это связь, в которой
для каждого объекта класса С существует уникальный объект класса D но
в ее обращении с каждым объектом класса D связаны многие С. В приме-
ре 2 5 ownedBy — это связь типа "многие-к-одному” класса Movie с клас-
сом Studio. Обратная ен связь - это связь типа "один-ко-многим" класса D
с классом С. В том же примере owns — связь типа "один-ко-многим”
класса Studio с классом Movie.
3. Связь типа "один-к одному" класса С с классом D — это связь, в которой
для каждого объекта класса С существует уникальный объект класса D.
В обратной связи каждый объект класса D связан с уникальным объектом
класса С. В описание из примера 2.5 добавим класс President, представля-
ющий президентов киностудий Предполагается, что каждая студии имеет
единственного президента и ни один человек не может быть президентом
более чем одной студии Значит, связь между студиями и их президентами
имеет тип “один-к-одному" в обоих направлениях.
Зависимости между типами связей
t
i
i
t
i
Следует иметь в виду, что связь типа "многие-к-одному" — это частный
случай связи типа "многие-ко-многим”, а связь типа "один-к-одному” — частный
случай связи типа "многис-к-одному". Любое полезное свойство связей типа
"многие-ко-многим" применимо к связям типа "многие-к-одному", а полезные
свойства последних верны и для связей типа "один-к-одному". Например
структура данных для представления связей типа "многие-к-одному” подходит ?
для связей типа “один-к-одному". но может быть непригодна для связи типа s
“многие-ко-многим".
Если говорится, что связь R относится к типу "многие-ко-многим”. в дей- 8
с гвительности это означает что Л может быть такой Со временем при j
изменении R, возможно, станет связью типа "многие-к-одному" или лаже -
"один к-одному". Аналогично, связь типа "многие-к-одному" иногда может |
быть связью типа "один-к-одно.му". =
В применении терминов типа "уникальный" или "один" при определении свя-
зей типа "миогие-к-одпому" или "один-к-одному" есть одно слабое место Важно
считать, что "уникальный” или "один" элемент реально существует Например, для
каждого фильма реально существует владеющая им студия, а студию возглавляет
реальный президент. Однако есть все основания считать что в реальности уникаль-
ного объекта не существует. Например, студия может временно работа! ь без прези-
дента или же мы можем не знать, какой студии принадлежит конкретный фильм
2.1 Введение в ODL
29
Таким образом, обычно допускается, что предполагаемое значение связанного
объекта может отсутствовать. Позднее мы увидим, что значение "null” часто
допускается в БД там, где предполагается наличие истинного значения Например,
в терминологии традиционного программирования указатель nil может стоять там,
где предполагается указатель на единственный объект В разделе 2.5 будут рассмот-
рены ограничения целостности и механизмы введения условия, согласно которому
уникальные объекты должны существовать без всяких исключений
2.1.7 Типы в ODL
ODL предоставляет проектировщику БД систему типов, подобную системам
типов языка С или других конвенциональных языков программирования Система
типов строится из базовых типов, которь е определены сами по себе, с помощью
конкретных рекурсивных правил (сложные типы строятся из более простых).
Базовые типы ODL:
I. Атомарные типы, целое число плавающая точка, символ, строка символов,
булево выражение и перечисление. Последний тип — это список имен,
объявленных синонимами целых чисел. Перечисление содержится в стро-
ке 5 рис. 2.6, где имена color и blackAndWhite в результате были определены
как синонимы чисел 0 и I.
2. Типы интерфейса, например Movie и Star, являются реальными структура-
ми с компонентами для каждого атрибута и каждой связи данного интер-
фейса. Эти имена представляют сложные типы, определяемые с помощью
перечисленных ниже типов, но их можно считать базовыми
Базовые типы комбинируются в структурные типы с помощью следующих кон-
структоров типов'.
I. Множество. Если Г—любой тип, то Set<T> обозначает тип значениями
которого являются все конечные множества элементов типа Т. Примеры
применения этого конструктора типов содержатся в строках 6, 11 и 15 на
рис. 2.6.
2. Мультимножество. Если Т — любой тип, то Еад<Т> обозначает тип, зна-
чениями которого являются все мультимножества элементов типа Т.
Мультимножество позволяет многократное повторение одного и того же
элемента. Например, <1, 2, 1) —это мультимножество, а не множество,
так как I повторяется в нем важды
3 Список. Если 7’—любой тип, то List<T> обозначает тип, значениями
которого являются конечные списки, состоящие из нуля или более эле-
ментов типа Т В специальном случае тип string является сокращением
тина List<char>.
4. Массив. Если Т — любой тип, то Аггау<Т> обозначает тип, элементами ко-
торого являются массив из i элементов типа Т Например, Array<char,1O>
обозначает символьную строку длиной I0.
5. Структуры. Если 7\. Ti, .... Т„ являются типами, а F,. Fi. . , F. именами
полей, то
Struct N (Г, F,. Т2 F2.Т„ FJ
обозначает тип с именем N. элементами которого служат структуры, содер-
жащие л полей, i-е поле имеет имя F, и тип Т,. Например, строка 10 на
рис. 2.6 показывает тип структуры с именем Addr и двумя полями. Оба поля
имеют тип string и имена street и city соответственно.
30
Глава 2 Моделирование базы данных
I Множества, мультимножества и списки
Для того чтобы различать множества, мультимножества и списки следует
помнить, что элементы множества не упорядочены и каждым из них входит
' в данное множество только один раз Мультимножество допускает более одного
I вхождения любого элемента, но элементы и их вхождения не упорядочены.
I В списке может быть несколько вхождений одного и того же элемента, но все
| вхождения в нем упорядочены. Значит, {1, 2, I) и {2, I, 1} — это одно и то же
J мультимножество, но {I, 2, I) и (2. 1, I}—это разные списки.
Первые четыре типа — множество, мультимножество, список и массив — назы-
ваются типами множеств. Существуют правила, определяющие какие типы можно
ассоциировать с атрибутами, а какие со связями.
• Построение типа атрибута начинается с атомарного типа или со структуры,
полями которой являются атомарные типы. Затем по выбору можно приме-
нить тип множества к исходному атомарному типу структуры.
• Тип связи — это или тип интерфейса, или тип набора, примененный к типу
интерфейса.
Важно помнить, что типы интерфейса могут не появляться в типе атрибута,
а атомарные типы — в типе связи. В этом отличие атрибутов и связей друг от друга.
Разница между ними еше и в том, как строятся для них сложные типы: и атрибут,
и связь допускают произвольный тип множества в качестве последнего оператора,
но тип структуры допустим только в атрибутах.
Пример 2.6. Возможные типы атрибутов:
I. integer.
2. Struct N {string fieldl, integer feld2}.
3. List<rea!>.
4 Array<Struct N {string fieldl, integer field2}>.
Здесь I — атомарный тип, 2 — структура атомарных типов, 3 — множество ато-
марного типа, а 4 — множество структур, построенных из атомарных типов.
Допустим, что доступными базовыми типами являются имена интерфейса
Movie и Star. Тогда можно построить типы связи Movie или Bag<Star> Однако
следующие типы связей недопустимы:
1. Struct N {Movie fieldl, Star field2}. Типы связей не могут включать в себя
структуры.
2. Set<integer>. Тилы связей не могут содержать атомарные типы
3. Set<Array<Star>>. Типы связей нс могут содержать два применения типов
множества (их не могут содержать и типы атрибутов) □
2.1.8 Упражнения к разделу 2.1
* Упражнение 2.1,1. Предположим, что проектируется БД для байка, содержа-
щая информацию о клиентах и их счетах. Информация о клиенте — это его имя
адрес телефон и номер страхового полиса. Счета имеют номера, типы (например,
сберегательный, чековый) и балансы. Нужно также записывать клиентов, являю-
щихся владельцами счетов. Опишите в ODL такую базу данных.
2.1 Введение в ODL
31
Упражнение 2.1.2. Модифицируйте описание из предыдущего упражнения
согласно перечисленным ниже четырем условиям. Причем новую схему строить
необязательно — надо просто описать внесенные изменения.
а) Только один клиент может быть указан как владелец счета.
Ь) В дополнение к предыдущему условию один клиент не может иметь более
одного счета.
с) Каждый адрес имеет три компонента: улицу, город и страну. Клиенты
могут иметь любое число адресов и телефонов.
! d) Клиенты могут иметь любое число адресов, являющихся тройками, как
и в пункте (с); с каждым адресом связано множество телефонов. Это
означает, что нужно записать адреса каждого клиента и номера телефо-
нов. соответствующие каждому из его адресов. Примечание: помните об
ограничениях на типы атрибутов и/или связей.
Упражнение 2.1.3. Опишите в ODL БД, содержащую информацию о командах,
игроках и их болельщиках, в том числе:
1. Укажите название каждой команды, ее игроков, капитана
(одного из игроков) и цвета ее спортивной формы.
2. Укажите имя каждого игрока.
3. Укажите имя каждого болельщика, его любимую команду,
любимого игрока и любимый цвет.
Упражнение 2.1.4. Измените предыдущее упражнение, указав, за какие
команды выступал каждый из игроков, включая начальную и конечную даты его
выступления за каждую из команд.
Упражнение 2.1.5. Предположим, нужно составить генеалогическое дерево.
Имеется единственный класс Person. Информация, которую необходимо записать о
человеке, состоит из его имени (атрибут) и следующих связей: мать, отец и дети.
Опишите в ODL класс Person. Обязательно укажите обращения связей, которые,
подобно mother, father и children, служат и связями класса Person с самим собой.
Является ли children инверсией связи mother’ Почему? Опишите каждую связь и ее
обращение как множества пар.
Упражнение 2.1.6. Добавим к описанию предыдущего упражнения атрибут
education Предполагается, что его значением является число ученых степеней,
полученных каждым человеком, и их названия (например, бакалавр), название
учебного заведения и дата его окончания. Набором структур может быть множество,
мультимножество, список или массив. Опишите результат применения каждого из
этих вариантов. Какую информацию можно зафиксировать или потерять в каждом
случае? Имеет ли утраченная информация практическое значение?
Упражнение 2.1.7. Опишите БД для администрации университета. Она должна
включать в себя информацию о студентах, факультетах, профессорах, учебных
курсах, какие студенты на каких курсах заняты и какие профессора какие курсы
читают, оценки, получаемые студентами, и любые другие данные, которые вы
сочтете уместными Это задание более свободной формы, чем предыдущее, и вам
придется самостоятельно принимать решения о множестве связей подходящих
типах и даже о том, какая информация должна быть представлена в БД.
32 Глава 2 Моделирование базы данных
Упражнение 2.1.8. Рассмотрим ODL-определение классов Ship и TG (целевая
группа, множество кораблей), приведенное на рис. 2.7.
1) interface Ship {
2) attribute string name,
3) attribute int year aunched;
4) re ationship TG assignedTo inverse TG :: unitsOf;
>:
5) interface TG {
6) attnbute real number;
7) attribute string commander;
8) relationship Set<Ship> unitsOf;
inverse Ship assignedTo;
};
Рис. 2.7. ODL-описоние кораблей и целевых групп
В это определение надо внести изменения. Каждое из таких изменений можно
описать. Для этого следует указать строку или строки подлежащие изменению, а
также что именно в них заменяется, или же вводя новые строки. Опишите следую-
щие изменения.
а) Тип атрибута commander становится парой строк, первая из которых —
ранг командира, а вторая — его имя.
Ь) Корабль может быть придан более чем одной целевой группе
с) Корабли-близнецы — идентичные корабли, построенные по одному и тому
же проекту. Для каждого корабля нужно представить множество
кораблей-близнецов (отличных от него). Корабли-близнецы для каждого
корабля можно считать объектами Ship.
! Упражнение 2.1.9. При каких условиях связь является своим собственным
обращением? Совет-, представьте связь в виде множества пар, как было показано
в разделе 2.1.5.
! Упражнение 2.1.10. Допустимо ли, чтобы тип был одновременно типом атри-
бута ODL и типом связи ODL? Объясните, почему.
2.2 Диаграммы сущности-связи
Существует графический метод моделирования БД, называемый диаграммами
сущности-связи (entity-relationship, Е/R), который весьма соответствует объектно-
ориентированному подходу. Эти диаграммы имеют те же три главных компонента,
о которых говорилось при описании ODL (хотя модели Е/R и ODL имеют особен-
ности, о которых речь пойдет ниже)
Компоненты E/R:
I. Множества сущностей, аналогичные классам. Сущности — это члены
множества сущностей, аналогичные объектам ODL
2. Атрибуты — это значения описывающие свойства сущности. Атрибуты
в Е/R и ODL — это. по сути, одно и то же понятие.
3. Связи — это соединения между двумя или более множествами сущностей.
Связи в Е/R аналогичны связям в ODL за следующими исключениями’
2.2 Диа раммы сущности-связи
33
(а) В модели Е/R одно имя приписывается связи в обоих направлениях,
а в ODL отдельно определяются связь и ее обращение. Например,
обратные связи Movie :: Stars и Star : starredln на рис. 2.6 в модели E/R
были бы представлены единственной связью
(Ь) Связи в Е/R могут соединять более двух множеств сущностей, а связи
ODL — максимум два класса.
Пример 2.7. На рис. 2.8 изображена диаграмма Е/R, представляющая ту же
самую информацию о реальном мире, что и описание ODL на рис. 2.6. Множества-
ми сущностей являются Movies, Stars и Studios. Чтобы выразить небольшое различие
между множествами сущностей и классами, имена первых пишутся во множествен-
ном числе, имена вторых в единственном.
Рис. 2.8. Диогроммо сущности связи для БД фильмов
Множество сущностей Movies имеет те же четыре атрибута, что и класс Movie на
рис. 2.6: название, год, длину и тип фильма. Аналогично, два других множества имеют
атрибуты имени и адреса, которые были описаны для соответствующих классов ODL.
На рис. 2.8 видны также связи, соответствующие связям из ODL-описания на
рис. 2.6. Одно из них Stars-in содержит информацию пары обратных связей stars
и sta redln между ODL-классами Movie и Star. E/R-связь Owns на рис. 2.8 представ-
ляет обратные связи Movie:: ownedBy и Studio : Owns. Стрелка, указывающая на
множество Studios, означает, что каждым фильмом владеет единственная студия. □
2.2.1 Множественность Е/К-связей
Как было показано в примере 2.7, для выражения множественности связей
в Е/R диаграммах можно применять стрелки. Если между множествами Е и Л" есть
связь типа “многие к одному”, используется стрелка, указывающая на F. Она озна-
чает, что каждая сущность из множества Е связана только с одной сущностью из
ьножества F Однако сущность из F может быть связана с многими сущностями в £.
Согласно такому принципу, связь типа "один к одному" между множествами Е
и F выражается стрелками, указывающими и на Е, и на F Например, на рис. 2.9
показаны два множества Studios и Presidents, а также связь между ними Runs
(атрибуты не показаны) Предполагается, что президент может возглавлять только
одну студию, а у студии может быть только один президент, что н выражено стрел-
ками, указывающими на оба множества.
Рис. 2.9. Связь типе "один-к-одному"
34
Глава 2 Моделирование базы данных
Визуализация E/R-связей
Зачастую E/R-связп удобно изображать таблицей, каждая строка которой
представляет пару сущностей, вовлеченных в данную связь Например, связь
[ Siars-in можно представить так:
Movies
Stars
Основной инстинкт
Вспомнить все
Шерон Стоун
Арнольд Шварценеггер
Вспомнить все
j Шерон Стоун
| Конкретного способа, которым должны реализовываться связи, не суше- t
1 ствует ни в E/R-моделях, ни в ODL. I
Такая таблица иногда называется множеством отношений для конкретной !
• связи. Элементы этого множества — строки таблицы. Их можно представить в
| виде кортежей с компонентами для каждого множества сущностей Например,
I кортежем во множестве отношений для связи Stars-in является пара
(Основной инстинкт, Шерон Стоун)
2.2.2 Многосторонние связи
В отличие от ODL в E/R-моделях удобно определять связи между несколькими
множествами. Однако на практике тернарные (трехсторонние) связи или связи еще
более высокого порядка встречаются довольно редко. Многосторонние связи в
E/R-моделях изображаются линиями, соединяющими ромб (связь) с каждьм из
участвующих в данной связи множеств.
Stars
Contracts
Movies
Studios
Рис. 2.10. Трехсторонняя связь
Пример 2.8. На рис. 2.10 изображена связь Contracts между студией, кинозвез
дой и фильмом Она означает, что студия заключает с кинозвездой контракт на
участие в фильме. В общем случае значением E/R связи можно считать множество
кортежей, компонентами которых являются сущности, вовлеченные в данную
связь, как было показано выше в тексте "Визуализация E/R-связей', выделенном
рамкой. Например, связь Contracts можно описать трехмерными кортежами вида
(сгудия. кинозвезда, фильм)
2.2 Диаграммы сущности-связи
35
В многосторонних связях стрелка, указывающая на множество Е, означает, что
из всех других вовлеченных в эту связь множеств выбирается по одной сущности,
связанной с единственной сущностью в Е. (Заметим, что такое определение — это
обобщение понятия множественности, применявшегося для двухсторонних связей.)
На рис. 2.16 стрелка, указывающая на множество Studios, означает, что каждая ки
нозвезда может иметь контракт на участие в конкретном фильме только с одной
студией Однако здесь нет стрелок, указывающих на Stars или Movies. Студия может
закл очать контракт на участие в фильме со многими звездами, а кинозвезда может
заключить со студией контракт на участие в нескольких фильмах. □
ь Ограниченные возможности применения стрелок |
для выражения многосторонних связей
Для выражения связи между тремя или более участниками недостаточно |
6 ставить или не ставить стрелки на линиях, идущих к ромбу связи. Вполне ?
| реальную ситуацию с помощью стрелок описать Невозможно. Например, I
I согласно рис. 2.К), студия является функцией только фильма, а не кинозвезды |j
и фильма, вместе взятых, так как фильм производится единственной студией, j
В принятой нотации такую ситуацию невозможно отличить от случая трех- !
сторонней связи, когда множество, на ко орое указывает стрелка, является 1
| функцией двух других множеств. В разделе 3.5 будут введены формальные г
Lобозначения — функциональные зависимости, позволяющие описать все I
возможные альтернативы. I
___________________:______________________J
2.2.3 Роли в связях
Одно множество сущностей может многократно фигурировать в одной и той же
связи. Поэтому от символа связи к множеству проводится столько линий, сколько
раз это множество участвует в данной связи. Каждая из таких линий обозначает роль,
которую множество играет в связи.
Пример 2.9. На рис. 2.11 изображена связь Sequel-of множества Movies с самим
собой. Каждая связь — это связь между двумя фильмами, один из которых является
продолжением другого. Для различения этих двух фильмов в рамках данной связи
одна линия отмечена ролью Original, а другая ролью Sequel, которые обозначают
исходный фильм и его продолжение соответственно. Предполагается, что у фильма
может быть много продолжений, но для каждого продолжения есть только один
(сходный фильм. Таким образом, стрелка Е/R диаграммы на рис. 2.11 показывает
связь типа "многие-к-одному1 множества Sequel с множеством Original. □
Original
Sequel
Рис. 2.11. Связь с ролями
36
Глава 2 Моделирование базы данных
Пример 2.10. В качестве последнего примера, включающего в себя многосто-
роннюю связь и множество сущностей со многими ролями, на рис. 2.12 дается
более сложная версия связи Contracts, введенной в примере 2 8. Здесь показана
связь Contracts между двумя студиями, кинозвездой и фильмом. Предполагается,
что студия, имеющая контракт с кинозвездой, может заключить со второй студией
контракт, позволяющий ей снимать кинозвезду в своем фильме. Такая связь опи-
сывается четверками вида
(студияI, студия’,кинозвезда, фильм),
причем студия’ заключает со студией! контракт на съемки кинозвезды студии! в
фильме студии’.
Рис 2.12. Четырехсторонняя связь
На рис. 2.12 есть стрелки, указывающие на Studios в двух ролях, как "владельца"
кинозвезды и как производителя фильма, но нет стрелок, указывающих на Stars
или Movies. Это значит, что при наличии кинозвезды, фильма и студии, производя-
щей фильм только одна студия может “владеть" кинозвездой. (Предполагается, что
кинозвезда имеет контракт в точности с одной студией.) Аналогично, данный
фильм производится единственной студией, поэтому при наличии кинозвезды,
фильма и студии, “владеющей" кинозвездой, можно определить единственную про-
изводящую фильм студию. Заметим, что обоих случаях для определения уникаль-
ной сущности реально нужна только одна из остальных сущностей (например, для
определения уникальной производящей студии необходимо знать только фильм),
но этот факт не изменяет множественное определение многосторонней связи
Стрелки не указывают на Лога или Movies. При наличии кинозвезды, владеющей
ею студии и студни, выпускающей фильм, может быть множество контрактов, по-
зволяющих кинозвезде играть в различных фильмах Значит, совсем не обязательно,
что остальные три компонента в четверке данной связи определяют единственный
фильм Аналогично, производящая студия может заключать контракт с другими
студнями об участии нескольких нх звезд в одном своем фильме. Таким образом,
кинозвезда не определяется тремя остальными компонентами данной связи □
2.2.4 Атрибуты связей
Иногда полезно приписывать атрибуты к связи, а не к одному из множеств
сущностей, находящихся в данной связи Рассмотрим связь, представляющую конт-
ракт кинозвезды со студней на участие в фильме (см рис. 2.10). Допустим, надо
записать гонорар, указанный в этом контракте. Однако гонорар нельзя связать
с кинозвездой, так как она может получать разные гонорары за участие в разных
2.2 Диаграммы сущности-связи 37
фильмах. Не имеет смысла связывать контракт и со студией (различным звездам
она может выплачивать разные гонорары) или с фильмом (разные кинозвезды
получают за один фильм разные гонорары).
Удобно связать гонорар с тройкой
(кинозвезда, фильм студия)
во множестве отношений для связи Contracts. На рис. 2.13 показана схема рис. 2.10
вместе с атрибутами. Связь имеет атрибут salary, а множества сущностей имеют те
же атрибуты, которые были показаны на рис. 2.8.
Рис. 2.13. Связь с атрибутами
Размешать атрибуты на самих связях нет необходимости. Вместо этого можно
ввести новое множество сущностей с атрибутами, приписанными данной связи, и
включить такое множество в связь.
Пример 2.11. Изменим E/R-диаграмму (рис. 2.13), на которой связь Contracts
имеет атрибут salary. Создадим множество Salaries с атрибутом salary, которое
станет четвертым членом связи Contracts. Результат такого изменения показан на
рис. 2.14. □
( year Л Movies Q length у"”/' {ffilmTypeJ ( name }— Salaries (^salary^) -<^ContractsJ^> Stars address _) — Studios (^address^)
Рис. 2.14 Перемещение атрибута в множество сущностей
38
Глава 2 Моделирование базы данных
2.2 5 Конвертирование многосторонних связей
в бинарные
Напомним, что. в отличие от E/R-модели, в ODL допустимы только бинарные
связи. Однако любую связь, включающую в себя более двух компонентов нетрудно
конвертировать в множество бинарных связей типа "многие-к-одному" без потерн
какой-либо информации. В E/R-модели можно ввести новое множество сущно-
стей. элементами которого являются кортежи множества отношений для многосто-
ронней связи Такое множество называется множеством связующих сущностей.
Затем вводится связь типа "многие-к-одному" этого множества связующих сущно
стей с каждым множеством сущностей, предоставляющим элемент кортежей исход-
ной многосторонней связи Если какое то множество сущностей играет несколько
ролей оно является целевым пунктом одной связи для каждой из ролей.
Пример 2.12. Четырехстороннюю связь (см. рис. 2.12) можно заменить множе-
ством сущностей под названием Contracis. Как показано на рис. 2 15, это множест-
во участвует в четырех связях. Если множество отношений для связи Contracis
имеет четверку
(студия 1, студия?, кинозвезда, фильм)
то сущность е множества Contracts соединена связью Star-of с сущностью star из
множества Stars, связью Movie-of с сущностью movie из множества Movies, а также
связями Studio of-star и Producing-studio соответственно с сущностями studio] и studio2
из множества Siudios
Рис. 2 15. Зомено многосторонней связи множеством сущностей и бинарными связями
Предполагается, что у множества Contracts мет атрибутов, хотя другие множест-
ва сущностей на рис. 2.15 имеют невидимые атрибуты. Можно добавить атрибуты
и множеству Contracts, например дату подписания контракта. □
Многостороння связь, подобная показанной на рис. 2.12, в ODL изображалась
бы способом, сходным с описанным выше преобразованием для E/R-модели.
Однако в ODL нет многосторонних связей, поэтому данное преобразование не
выбирается по желанию — оно обязательно.
Пример 2.13. Допустим, есть классы Star, Movie и Studio, соответствующие
каждому из трех множеств сущностей, показанных на рис. 2.12 Для представления
четырехсторонней связи Contracts вводится новый класс Contract, не имеющий
атрибутов но имеющий четыре связи, соответствующие четырем компонентам
E/R-связи. ODL-описание дано на рис. 2.16; обратные связи пропущены. Каждая
четверка в E/R-связи Contracts соответствует объекту ODL-класеа Contract. □
2.2 Диаграммы сущности-связи
39
interface Contract {
relationship Studio ownerOfStar;
relationship Studio producingStudio;
relat onship Star star:
relatonship Movie movie;
}.
Рис. 2.16. Представление контроктов в ODL
2.2.6 Упражнения к разделу 2.2
* Упражнение 2.2.1. Представьте банковскую БД из упражнения 2.1.1 в виде
E/R-модели. Обязательно введите стрелки (там, где они необходимы) для выраже
ния множественности связи.
Упражнение 2.2.2. Измените результат выполнения упражнения 2.2.1 для от-
ражения изменений, указанных в упражнении 2.1.2:
а) Измените диаграмму так, чтобы счет мог принадлежать только одному'
клиенту.
Ь) Далее измените диаграмму так, чтобы клиент мог иметь только один счет
!с) Измените исходную диаграмму упражнения 2.2.1 так, чтобы клиент мог
иметь множество адресов (являющихся тройками улиыа-город-страна) и
множество телефонов. Помните, что в E/R-модели атрибуты не могут
иметь тип множеств, но при определенных условиях это допустимо в ODL.
1 d) Далее измените диаграмму так, чтобы клиент мог иметь множество
адресов и множество телефонов по каждому адресу.
Упражнение 2.2.3. Представьте БД команды/игроки /болельщики из упражне-
ния 2.1.3 в виде E/R-модели. Помните, что множество цветов — неподходящий тип
атрибута для команд. Как можно обойти это ограничение?
! Упражнение 2.2.4. Предположим, что к схеме упражнения 2.2.3 нужно доба-
вить связи Led-by между двумя игроками и командой. Оно состоит из таких троек
(игрок!, игрок2, команда)
в которых игрок! выступал за данную команду, когда ее капитаном был игрок2.
а) Введите изменения в E/R-диаграмму.
Ь) Замените тернарную связь новым множеством сущностей и бинарными
связями.
!с) Являются ли новые бинарные связи такими же, как любая из прежде
существовавших связей? Учтите, что речь идет о разных игроках: ни один
капитан команды не может возглавлять самого себя.
Упражнение 2.2.5. Измените E/R-диаграмму упражнения 2.2.3, включив в нее
истории игроков, как в упражнении 2.1.4.
! Упражнение 2.2.6. Представьте БД из упражнений 2.1.5 и 2.1.6 в виде
Е/R модели Включите в нее связи для матери, отца и детей; не забудьте указать
роли, когда множество сущностей используется в связи более одного раза. Включи
те в модель информацию об ученых степенях, полученных каждым человеком, как
было указано в упражнении 2.1.6. Укажите сложность каждой связи. Нужны ли
отдельные связи для матери, отца и детей? Почему?
40
Г лава 2 Моделирование базы данных
Упражнение 2.2.7. Альтернативный способ представления информации упраж-
нении 2.1.5—ввести тернарную связь Family, полагая, что тройкой в множестве
отношений для Family является
(человек, отец, мать)
и псе ее члены, разумеется, входят во .множество People.
*а) Составьте диаграмму с указанной связью (не включая в нее информацию
об образовании). Используйте стрелки там, где они нужны.
Ь) Замените тернарную связь Family множеством сущностей и бинарными
связями; иля отражения множественности связей используйте стрелки.
Упражнение 2.2.8. Представьте унивсрситетскро БД из упражнения 2.1.7 в виде
Е, R-модели.
2.3 Принципы проектирования
Более подробное знакомство с моделями ODL и E/R у вас еще впереди, но
уже сейчас вы знаете достаточно, чтобы разобраться в том, из чего состоит хоро
шнй проект и чего нужно избегать при его построении. В этом разделе рассматри-
ваются некоторые полезные принципы проектирования.
2.3.1 Правильность
Первое и самое главное: проект должен быть правильным относительно конк-
ретной области. Классы, или множества сущностей и их атрибуты, должны отра-
жать реальность. Нельзя приписывать кинозвезде атрибут "число цилиндров", хотя
это имеет смысл для класса автомобилей Любые установленные связи должны
соотноситься с нашими знаниями о моделируемой части реального мира.
Пример 2.74. Если определяется связь Stars-in между Star и Movie, она должна
быть типа "многие-ко-многим", так как наблюдения за реальным миром показыва-
ют, что кинозвезды могут играть во многих фильмах, а несколько кинозвезд может
участвовать в одном фильме. Неверно определять эту связь как многие-к-одному”
в любом направлении или как связь типа 'однн-к-одному". □
2.3.2 Ликвидация избыточности
Необходимо следить за тем, чтобы каждый факт упоминался не более одного
раза. Например, мы использовали связь Owns между фильмами и студнями Можно
было бы еще ввести атрибут studioName или множество сущностей Movies, в чем нет
ничего незаконного. Однако это опасно по многим причинам.
1. Два представления одного и того же факта владения фильмом занимают
больше места, чем любое единственное представление
2. Если фильм был продан, мы можем изменить студию-владельца с помощью
Owns, забыв при этом изменить значение атрибута stttdioName. или наобо-
рот. Конечно, такая небрежность недопустима, гем не менее на практике
ошибки случаются часто: стараясь сказать одно и то же двумя разными
способами легко накликать проблемы.
В разделе 3.7 дано более формальное описание таких проблем и некоторых
средств пересмотра схем БД, позволяющих избежать избыточности.
2.3 Принципы проектирования
41
Избыточность и обратные связи
J
Можно подумать, что использование связи и ее обращения в ODL —это
’ пример излишеств в модели Однако не следует полагать, что связь и ее обра-
| щение будут представлены двумя различными структурами данных, например !
‘ указателями в различных направлениях. Вспомните, что определение связи и |
I ее обращения лишь отражают тот факт, что связи в принципе можно придать |
1 любое направление. ►
Если же связь действительно реализуется двумя отдельными структурами 5
данных, возникает риск, связанный с избыточностью. Поскольку предполага- J
ется, что базовые указатели постоянно используются при изменении данньх,
при реализации СУБД, основанных на ODL, нужно внимательно относиться
к способам изменений БД. Но эта проблема относится к уровню системы,
причем предполагается, что разработчики системы успешно (в конечном счете)
с ней справятся. На уровне реализации с избыточностью связан меньший
риск, и существование указателей в обоих направлениях может привести
к существенному повышению скорости, с которой связи придается то или
иное направление.
2-3-3 Простота
Нельзя вводить в проект больше элементов, чем это необходимо.
Пример 2.15. Предположим, что вместо связи между Monies и Studios было по-
стулировано существование 'фильм-холдинга", владения единственным фильмом.
Тогда можно создать еще один класс или множество сущностей Holdings. Между
каждым фильмом и единственным представляющим его холдингом можно ввести
связь Represents типа "один-к-одному" И связь типа "многие-к-одному" множества
Holdings с множеством Studios завершает схему, показанную на рис. 2.17.
Рис. 2 17. Слобый проект с ненужным множеством сущностей
Технически такая структура правильно представляет реальный мир, так как
единственную студию, владеющую фильмом можно определять через холдинги
Однако множество Holdings при этом бесполезно, и лучше обойтись без него. О ю
порождает программы, использующие более сложные связи между фгльмом и сту
дней, занимает излишнее пространство памяти и порождает ошибки. □
2.3.4 Выбор элементов правильного вида
Иногда приходится выбирать тип элементов проекта, применяемых для пред-
ставления объектов реального мира При этом часто выбор заключается в том, что
использовать: атрибуты и ш же классы, множества сущностей. В общем случае
атрибут проше реализовать, чем любой класс/мпожество сущностей или связь
Впрочем, если все делать только с помощью атрибутов, возникнут осложнения.
42
Глава 2 Моделированг е базы данньх
Пример 2.16 Рассмотрим конкретную проблему Правильно ли мы поступили,
сделав ст):п ю классом на рис 2.6 или множеством сущностей на рис. 2.8‘? Может
быть вместо этого надо было сделать атрибутами студии ее название и адрес,
устранив соответствующий класс или множество сущностей? С одной стороны,
тогда пришлось бы адрес студии повторять для каждого фильма, что ведет к избы
точности. Кроме неудобств с излишествами, упомянутых в разделе 2.3.2, возникает
риск потерять адрес студии, не владеющей ни одним фильмом
С другой стороны, если адреса студий не записывались, то нет ничего страш-
ного в том. чтобы сделать название студии атрибутом фильмов Избыточности,
связанной с повторением адресов, не возникает. Ведь нельзя считать избыточным
упоминание студни Disney в связи с каждым фильмом, которым она владеет,
поскольку нужно как-то определять владельца каждого фильма, а назвать при этом
его имя вполне разумно. □
В общем случае предполагается, что если о чем-то известно больше, чем
просто имя. то это "что-то" по видимому, должно быть множеством сущностей,
пли классом, однако, если в модели можно использовать только имя, лучше
создать атрибут. Здесь мы сталкиваемся с вопросом “нормализации" схем в реляци-
онной модели который будет рассматриваться в разделе 3.7.
Пример 2.17, Рассмотрим ситуацию, предполагающую определенный баланс
между результатом применения многосторонней связи и множества связующих
сущностей с бинарными связями. Например, четырехсторонняя связь Contracts
между кинозвездой, фильмом и двумя студиями (см. рис. 2 12) механически кон-
вертируется в множество сущностей Contracts (см. рис 2.15). Имеет ли значение,
какой из этих подходов выбирается-’
В проектировании ODL фактически, выбора нет, так как многосторонних
связей не существует. В E/R-модели приемлем любой подход. Однако незначитель-
ное изменение исходной задачи практически вынуждает нас выбирать подход,
при котором используется множество связующих сущностей. Предположим, что
в контракте могут фигурировать одна кинозвезда, один фильм, но любое множест-
во студий. Эга ситуация сложнее той, что изображена на рис. 2.12, где было всего
две студии, играющие две роли Сейчас допускается любое число студий. Одна,
возможно, выпускает фильм другая организует спецэффекты, третья продает фильм
кинотеатрам и т.д. Таким образом, приписать роли студиям невозможно.
В данном случае оказывается, что множество отношений для связи Contracts
должно содержать тройки вида
(кинозвезда, фильм, множество студий),
а сама связь Contracts — не только обычные множества сущностей Stars и Maries, но
и новое множество сущностей, элементами которого являются множества студий.
Если такой подход допустим, считать множества студий базовыми сущностями
неприемлемо, мы не рекомендуем это делать.
Рис. 2 18 Контронты, связывающие кинозвезду, фильм и множество студий
2.3 Принципы проектирования
43
Лучше считать множеством сущностей контракты. Как и на рис. 2.15, контракт
связывает кинозвезду, фильм и множество студий, но теперь число студий не
ограничено. Поэтому между контрактами и студиями имеется связь типа
"многие-ко-многим", а не "многие-к-одному", как это было бы, если бы контракты
были настоящим множеством “связующих сущностей. Набросок E/R-диаграммы
показан на рис 2.18. Заметим, что здесь контракт связан с единственной кинозвез-
дой и единственным фильмом, но с произвольным множеством студий.
Такая же стратегия проектирования подходит и для ODL. Например вполне
приемлемо следующее описание интерфейса ODL:
interface Contract {
relationship Star theStar
relationship Movie theMovie;
relationship Set<Studio> studios,
);
Здесь объекты контрактов имеют три связи: с единственной кинозвездой с единст-
венным фильмом и с множеством студий Обратные связи опушены. □
2-3-5 Упражнения к раздел}' 2.3
Упражнение 2.3.1 На рис 2.19 дана ODL-разработка банковской БД содер-
жащей клиентов и счета Предполагается, что смысл различных связей и атрибутов
выражен их именами. Сделайте критический разбор этой разработки. Какие правила
здесь нарушены9 Предложите ваши изменения
interface Address {
attribute string addr;
relationship Set<Customer> residents
inverse Customer::livesAt,
}.
interface Customer {
attribute string name;
relationship Address livesAt
inverse Address:.residents;
relationship AcctSet accounts
inverse AcctSet::owner;
};
interface Account {
attribute real balance,
relationship Set<AcctSet> memberOf
inverse AcctSet. :members;
}.
interface AcctSet {
attribute string ownerAddress;
relationship Customer owner
inverse Customer::accounts;
relationship Set<Accounts> members
inverse Account memberOf;
};
Рис. 2.19. Неудачноя разработка банковской 6Д
44
Глава 2 Моделирование базы данных
Рис. 2.20. Представление рождения с помощью многосторонней связи
I! Упражнение 2.3.2. В этом и следующем упражнениях рассматриваются два
варианта разработки E/R-мояелн, описывающей рождение детей. В рождении уча-
ствует один ребенок (близнецы ассоциируются с двумя актами рождения), одна
мать, любое число медсестер н любое число врачей. Поэтому предполагается, что
есть множества сущностей Babies, Mothers, Nuises и Doctors, а также связь Births
между этими множествами, как показано на рис. 2.20. Заметим, что кортеж множе-
ства отношений для Births имеет вид
(ребенок, мать, медсестра, врач)
Если в родах участвуют несколько медсестер и/или врачей, будет множество корте-
жей с одними и теми же ребенком и матерью — по одному кортежу для каждой
комбинации медсестры и врача.
Существуют определенные предпосылки, которые вполне уместно включить
в эту разработку. Покажите, как добавить в E/R-диаграмму стрелки или другие
элементы, чтобы выразить каждую предпосылку.
а) У каждого ребенка есть единственная мать.
Ь) Для каждой комбинации ребенка, медсестры и доктора существует един-
ственная мать.
с) Для каждой комбинации ребенка и магери существует единственный врач
1 Упражнение 2.3.3. Другой подход решения проблемы из упражнения 2.3.2
состоит в том. чтобы связать четыре множества сущностей Babies, Mothers, Nurses
н Doctors с помощью одного множества сущностей Births с четырьмя связями между
Births п каждым из остальных множеств, как показано на рис. 2.21.
Рис. 2 21 Представление рождения с помощью множества сущностей
2.4 Подклассы
45
Используйте стрелки (показывающие, что конкретная связь имеет тип
многие-к-одному") для выражения следующих условий:
а) Любой ребенок появляется в результате единственного акта рождения,
н любое рождение — это рождение единственного ребенка.
Ь) В дополнение к (а), любой ребенок имеет единственную мать.
с) В дополнение к (а) и (Ь), для любого рождения существует единственный
доктор
!! Упражнение 2 3.4. Предположим, что одна мать может родить несколько де
тей. Как отразить факт, что у каждого ребенка все же только одна мать, с помощью
подходов, описанных в упражнениях 2.3.2 и 2.3.3?
! Упражнение 2.3.5. Перепишите E/R-схемы упражнений 2.3.2 и 2.3.3 в ODL.
Какие из условий этих упражнений отразить в ODL легко, а какие вообще невоз-
можно? Можно ли изменить разработку, чтобы допускалось рождение одной
матерью нескольких детей, как в упражнении 2.3.4?
2.4 Подклассы
Часто класс содержит объекты с особыми свойствами, не связанными со всеми
членами этого класса. В таком случае полезно разделить класс на подклассы, каж-
дый из которых имеет собственные специальные атрибуты и/или связи в дополне-
ние к тем, что присущи классу как единому целому Сначала мы рассмотрим
простой способ описания подклассов в ODL, а затем покажем, как иерархии
класс-подкласс представляются в E/R-модели с помощью специальных связей под
названием "isa” ("Л есть В выражает связь "isa" подкласса А с подклассом В).
2.4.1 Подклассы в ODL
В рассматриваемой нами в качестве примера БД могут находиться нуль филь
мы, детективы, приключенческие фильмы, комедии и множество других типов
фильмов. Для каждого из этих типов можно определить подкласс класса Movie, вве-
денного в примере 2.1. По определению, класс С является подклассом другого
класса D, если в описании за именем С следуют двоеточие и имя класса D.
Пример 2.18. То, что Cartoon — это подкласс класса Movie и, следовательно,
Movie — это суперкласс класса Cartoon, можно выразить простым ODL-описанием:
1) interface Cartoon: Movie {
2) relationship Set<Star> voices,
};
Строка (I) показывает, что Cartoon подкласс класса Move. Строка (?) означает,
что все объекты класса Cartoon имеют связь voices— людей, озвучивающих персона-
жей мультфильма. В описании не указано имя обращения этой связи, хотя технически
это следовало бы сделать. Заметим что связь voices имеет смысл не для всех фильмов,
а только для мультфильмов, поэтому нс вводится для класса Movie. □
Подкласс наследует все свойства своего суперкласса (называемого также классом,
из которого еыводится подкласс) Другими словами, любые атрибут и связь суперклас
са автоматически являются атрибутом и связью его подкласса. В примере 2.I8 каждый
объект класса мульгфильмов имеет атрибуты title, year, length и fi mType. наследован-
ные от Movie (вспомните рис. 2.6), и в дополнение к собственной связи voices
наследует от Movie связи stars и ownedBy.
46
Глава 2 Моделирование базы данных
2.4.2 Множественное наследование в ODL
Класс может иметь несколько подклассов. к< ка.ый из которых наследует
свойства своего суперкласса, как было показано в предыдущем разделе. Более того,
подклассы сами мот иметь подклассы, образуя иерархию классов, в которой
каждый класс наследует свойства своих предшественников Класс может также
иметь несколько суперклассов. Следующий пример иллюстрирует потенциальные
возможности н проблемы, связанные с такой ситуацией.
Пример 2.19. Можно определить подкласс детективов класса Movie:
1) interface MurderMystery: Movie {
2) attribute string weapon;
}.
Все детективы имеют атрибут, выражающий орудие убийства, а также четыре
атрибута и дне связи, которыми обладают все фильмы.
Теперь рассмотрим фильм типа "Кто ложно обвинил кролики Роджера?", являю-
щийся п мультфильмом, и детективом. Кроме обычных свойств класса Movie такие
фильмы должны иметь связь voices и атрибут weapon. Эту ситуацию можно
описать, определ! и подкласс Cartoon MurderMystery, s вляющийся подклассом обоих
классов Cartoon и MurderMystery.
interface Cartoon MurderMystery: Cartoon MurderMystery {};
Итак объект мультипликационного детектива определяется для выражения всех
свойств обоих подклассов Cartoon и MurderMystery. Никаких свойств или связей,
принадлежащих только мультипликационным детективам, не вводится. Объекты
класса Cartoon-MurderMystery наследуют атрибут weapon класса MurderMystery и связь
voices класса Cartoon. Поскольку классы MurderMystery и Cartoon, в свою очередь,
наследуют четыре атрибута и две связи класса Movie, класс Cartoon-MurderMystery
наследует также и эти шесть свойств Однако он нс наследует двух копий всех этих
шести свойств, а наследует свойства из класса Movie через любой из двух его
непосредственных подклассов. Рис 2.22 иллюстрирует связи подкласс-суперкласс,
в которых участвуют четыре названных класса. □
Movies
Cartoon MurderMystery
Cartoon-MurderMystery
Рис. 2.22. Диограммо множественного носледованиА
В общем случае можно определить класс С как подкласс любого числа других
классов, поставив двоеточие и перечислив имена всех этих классов после описания
имени и ггерфейса С. Пример 2.19 иллюстрирует именно такую форму связей.
Когда класс С наследует свойства нескольких классов, потенциально возможен
конфликт имен свойств Два или более суперкласса класса С могут иметь атрибут
или свойство с одним и тем же именем, притом что типы этих свойств различны.
2.4 Подклассы
47
Пример 2.20. Предположим, что класс Movie имеет подклассы Romance и
Courtroom , каждый пт которых имеет атрибут ending. Но в классе Romance этот
атрибут получает значения из набора {happy sad}, а в классе Courtroom — из набора
{guilty, notGuilty}. Если затем вводится новый подкласс Courtroom Romance
суперклассами которого являются и Romance, и Courtroom, тип наследуемого
атрибута в классе Courtroom-Romance остается неясным. □
Хотя в ODL и не определен особый синтаксис, реализации ODL предлагают по
крайней мере один из следующих механизмов, подсказывающих пользователю, как
действовать в случае конфликта, возникающего из множественного наследования
I Можно указать, какое из двух определений данного свойства относится к
подклассу. Так. в примере 2 20 считаем, что для мелодрамы, замешенной
на детективе, важен не вердикт, вынесенный судом, а как кончается фильм:
хорошо или плохо. Тогда устанавливается, что класс Courtroom-Romance
наследует атрибут ending из суперкласса Romance, а не из Courtroom.
2. Можно присвоить в классе С новое имя одному из двух наследуемых
свойств с одним и тем же именем. Если в примере 2.20 Courtroom-Romance
наследует атрибут ending из класса Romance, в этом классе можно опреде-
лить дополнительный атрибут verdict как результат замены имени атрибу-
та ending, наследуемого из класса Courtroom
3. В классе С можно заново определить некоторые свойства, определенные
в его суперклассах. В примере 2.20 можно считать, что атрибут ending не
должен наследоваться напрямую из любого суперкласса, а переопределить
этот атрибут как числовое значение, которое выражает степень удовлетво
рснности зрителей концом фильма, выявленную путем их опроса.
Заметим, что даже в примере 2.19 есть конфликты Cartoon MurderMystery на-
следует из каждого непосредственного суперкласса (Cartoon и MurderMystery) все
шесть свойств, в том числе title и stars, которые эти классы наследовали из класса
Movie. Но поскольку определения title и других свойств идентичны в обоих супер-
классах Cartoon и MurderMystery, выбирать используемое определение можно вооб-
ще любым способом
2.43 Подклассы в диаграммах сущности-связи
Напомним, что классы в ODL аналогичны множествам сущностей в E/R-модели.
Пусть класс С —это подкласс класса D. Для выражения этого понятия в E/R-модели
мы соединяем множества сущностей, соответствующие классам С и D, специальной
связью isa Множества сущностей Си D обозначаются обычными прямоугольника-
ми Атрибуты, или связи, относящиеся только к сущностям С, присоединяются к
прямоугольнику С, а атрибуты, применимые к С и £>, размещаются у D.
Связь /го обозначается линиями с треугольниками в середине Вершина каждо-
го треугольника указывает на суперкласс. В треугольнике можно при желании
написать слово "isa".
Пример 2.21. На рис. 2 23 показаны множество сущностей Movies и два его
подкласса; Cartoons и MurderMysteries. Эта структура подклассов аналогична
структуре для ODL показанной в примере 2.19. Треугольники, помеченные isa, ука
зывают от Cartoons и MurderMysteries на суперкласс Movies. Связи Stars in и Owns,
48
Глава 2 Моделирование базы данных
связывающие Movies со Slurs и Studios, не показаны, но предполагается, что есть
связь Voices между Cartoons и Stars. □
2.4- 4 Наследование в E/R-модели
Между наследованием в ODL или других объектно-ориентированных моделях
и в Е/R модели есть небольшая разнипа. В ODL объект должен быть членом только
одного класса. Так, в примере 2.19 для объектов, являющихся одновременно мульт-
фильмами п детективами, необходимо было определить класс Cartoon-MurderMystery
и нельзя было, например, поместить объект Roger Rabbit в классы Cartoon и
MurderMystery.
В E/R-модели считается, что сущность имеет компоненты, принадлежащие
нескольким множествам сущностей, которые являются частью isa-иерархии. Эти
компоненты объединены в единую сущность связями isa, и такая сущность имеет
все атрибуты своих компонентов, а также участвует По всех связях, в которых они
участвуют.
В общем случае при таком подходе получается тот же эффект, что и в ODL,
так как иаследопание свойств дает объекту те же атрибуты и связи, которые соот-
ветствующая ему сущность могла бы собрать из своих компонентов. Однако иногда
результаты различны, что будет показано при рассмотрении примера 2.22, а затем
в разделе 3.4 при конвертировании разработок ODL и Е/R в реляционную модель.
Пример 2.22. Заметим, что в схеме на рис. 2.23 не требуется множество сущ-
ностей, соответствующее мультипликационным детективам, так как сущность ипа
Roger Rabbit имеет компоненты, принадлежащие всем трем множествам: Movies,
Cartoons и MurderMysteries. Эти компоненты соединены связями isa в единую сущ-
ность и дают Roger Rabbit все четыре атрибута Movies (и две связи Movies, не пока-
занные на рисунке), а также атрибут weapon множества Murder Mysteries и связь
Voices множества Cartoons. Именно все перечисленные свойства объект Roger Rabbit
в классе Cartoon-MurderMystery наследовал из своих суперклассов Movie, Cartoon
п MurderMystery в примере 2.19. □
Однако если бы у мультипликационных детект! вов были свойства, которых
нет ни у мультфильмов, ни у детективов, в схему рис. 2.23 нужно было бы ввести
четвертое м тожество сущностей Cartoon-Martlet-Mysteries и отнести к нему эти
свойства (атрибуть 1 связи). Тогда сущность Roger Rabbit имела бы четвертый
компонент, принадлежащий Cartoon-MurderMysteries и обеспечивающий упомяну ые
новы : свойства для Roger Rabbit.
2.4 Подклассы
49
2.4.5 Упражнения к разделу 2.4
* Упражнение 2.4.1. Рассмотрим БД военных кораблей и ее выражение в ODL.
С каждым кораблем связана следующая информация.
I. Имя корабля.
2. Водоизмещение корабля (вес) в тоннах
3. Тип корабля, например линкор, эскадренный миноносец.
Есть также информация о специальных видах кораблей:
1. Gunships— пушечные корабли, оснащенные большими орудиями, напри-
мер линкоры или крейсера. Для них нужно записывать число и калибр их
главных орудий.
2. Cai tiers— авианосцы, на которых размещены самолеты. Для них нужно
записывать длину взлетной палубы и множество приданных им воздуш-
ных групп.
3. Submarines — подводные лодки, для которых нужно записывать максималь-
ную глубину погружения. Можете предполагать, что ни один пушечный
корабль или авианосец не является подводкой лодкой.
4. Battlecartiers -линкоры-авианосцы являются одновременно пушечными
кораблями и авианосцами; к ним относится вся информация, связанная
как с линкором, так и с авианосцем2
Выполните следующие задания:
а) Сделайте ODL-разработку указанной иерархии классов.
Ь) Покажите, как можно представить линкор-авианосец Ise, который имел
водоизмещение 36 тыс. тонн, восемь 14-дюймовых орудий, взлетную па-
лубу длиной в 200 футов и нес авиационные группы "1 и 2".
!! Упражнение 2.4.2. Для определенных подклассов, например для Battlecarrier
в упражнении 2.4.1, возможен только один тип, а для других, таких как Gunship,
возможны несколько типов, например линкор и крейсер. Создает ли такая ситуа-
ция определенную форму избыточности? Если да, то как от нее избавиться?
* Упражнение 2.4.3. Повторите упражнение 2.4.1 для E/R-модели.
! Упражнение 2.4.4. Измените разработку БД "людей* из упражнения 2.1 5,
включив в нее следующие типы людей-
I. Женщины
2. Мужчины
3. Родители
Можно выделять также другие типы людей,, чтобы связи соединяли подходящие
подклассы людей Выразите разработку в:
a) ODL,
Ь) E/R-модели
2 Не сомневайтесь, что такие корабли существовали в действительности. Два японских
линкора he и Hyuga сшс в 1943 г. были перестроены так. что имели взлетные палубы
и ангары для самолетов.
50
Глава 2 Моделирование базы данных
2.5 Моделирование ограничений
Мы рассмотрели, как моделировать фрагмент реального мира с помощью клас-
сов ODL и их свойств — атрибутов и связей — или посредством множеств сущно-
стей и связей Е/К-модели Большую часть моделируемой структуры можно
выразить в любой из этих нотаций. Однако есть важные аспекты реального мира
моделировать которые, используя рассмотренные выше средства, невозможно Та-
кая дополнительная информация часто принимает форму ограничений на данные,
выходящих за рамки структурных и типовых ограничений, вводимых определения-
ми классов, атрибутов и связей.
Далее приводится простая классификация ограничений, которые обычно
применяются. Она охватывает не все типы ограничений Дополнительный материал
по ограничениям содержится в разделе 4.5 в контексте реляционной алгебры
и в главе 6 в связи с программированием SQL.
I. Ключи — атрибуты пли множества атрибутов, уникальным образом иден-
тифицирующие объект в его классе или сущность в ее множестве сущно
стен. Никакие два объекта класса не могут совпадать по своим значениям
для каждого множества атрибутов, формирующих ключ.
2. Ограничения по единственному значению — требования того, чтобы зна-
чение в определенной роли было уникальным. Главным источником
таких ограничений являются ключи, так как они требуют, чтобы со
значением(ями) атрибута(ов) ключа были связаны уникальные значения
других атрибутов класса или множества сущностей. Но имеются и иные
источники ограничений по единственному значению.
3. Ограничения ссылочной целостности — требования того, чтобы значение,
на которое ссылается объект реально существовало в БД Ссылочная
целостность аналогична запрел' на висящие указатели в обычных про-
граммах.
4. Ограничения области значений требуют, чтобы значение атрибута выбира-
лось из особого множества значений или находилось в определенных
границах. Ограничения области значений для SQL будут рассмотрены
в разделе 6.3.
5- Общие ограничения — произвольные утверждения, которые должны выпол-
няться в БД. Например, можно потребовать, чтобы для любого фильма
перечислялось не более десяти кинозвезд. Языки для записи общих огра-
ничений анализируются в разделах 4.5 и 6 4.
Эти ограничения важны по многим причинам. Они содержат информацию о
структуре моделируемых фрагментов реального мира. Например, ключи позволяют
пользователю безошибочно идентифицировать объекты или сущности. Если извест-
но, что атрибут пате — это ключ для объектов класса Studio, тогда, ссылаясь на
обьект "студия" по имени, мы знаем, что ссылаемся на уникальный объект. Знание
того, что существует уникальное значение, экономит пространство и время, так как
хранить единственное значение легче, чем множество, даже если это множество
имеет только один элемент3. Ссылочная целостность и ключи поддерживают также
определенные структуры памяти, обеспечивающие быстрый доступ к объектам
з По аналогии заметим, что в программе С проще представить целое число, чем
связанный список целых чисел, даже если он содержит только одно число.
2 5 Моделирование ограничений
51
Г~~ ——— — ————]
Ограничения — это часть схемы
Можно подумать, что БД существует только определенное время, и оши
‘ бочно решить, что атрибут является ключом, так как никакие два объекта не ;
имеют идентичных значений этого атрибута Например создавая БД фильмов, [
мы могли некоторое время не вводить в нее фильмы с одинаковыми названи- |
ями, и ситуация выглядела бы так, что title — это ключ для класса Movie s
Однако, положившись на очевидность того, title является ключом, и спроекти !
ровав для БД структуру памяти, которая предполагает, что title — ключ, мы
' лишились бы возможности ввести в БД второй фильм “Кинг Конг".
Таким образом, ограничения ключа и ограничения вообще — это часть
схемы БД. Они описываются проектировщиком вместе со структурной схемой
(например, атрибутами и связями). Если ограничение определено, нарушаю-
щие его вводы в БД или ее изменения запрещены.
Следовательно, даже если отдельный пример БД удовлетворяет опреде
ленным ограничениям, единственно "истинными” являются ограничения,
I определенные проектировщиком для всех примеров БД и корректно модели-
; руюшие реальный мир. Такие ограничения могут предполагаться пользовате-
Е лем и структурами, которые используются для хранения БД.
2.5.1 Ключи
В ODL клюй класса — это такое множество атрибутов К, что при наличии в
данном классе двух различных объектов О, и О2 они не могут иметь идентичных
значений для любого атрибута в ключе К. В E/R-модели ключ определяется так же,
только слово “класс" заменяется на "множество сущностей”, а ’объекты" — на "сущ
ности'.
Пример 2,23. Рассмотрим класс Movie из примера 2.1. Сразу можно предполо-
жить, что сам атрибут t tle является ключом. Однако есть названия, которые можно
использовать для двух и даже более различных фильмов, например Кинг Конг". По-
этому неразумно объявлять ключом атрибут title: тогда невозможно будет включить
в БД информацию об обоих фильмах с названием Кинг Конг".
Лучше принять в качестве ключа множество, состоящее из двух атрибутов: title
и year. Правда, остается риск, что существует два фильма, выпущенных в одном
и том же году с одинаковым названием, однако это маловероятно.
Ключи для двух других классов, Star и Studo, введенных в примере 2.1, тоже
нужно подбирать внимательно. Разумно предположить, что нет двух студий с од
ним и тем же названием, поэтому name принимается в качестве ключа для класса
Studio. Кинозвезды же совсем не обязательно идентифицируются своими именами:
у многих людей могут быть одинаковые имена Однако кинозвезды обычно выби
рают себе "сценические имена", поэтому пате может служить ключом для класса
Star Если же нет, то в качестве ключа вполне подойдет лара атрибутов name
и address, если только нет двух кинозвезд с одинаковыми именами, живущих по
одному и тому же адресу. □
Пример 2.24. Из примера 2.23 может создаться впечатление, как это пробле-
матично — найти ключи или быть уверенным в том, что множество атрибутов
формирует ключ. Однако на практике все гораздо проще. В реальных ситуациях
обычно моделируемых с помощью БД, для важных классов часто специально
создаются эффективные ключи. Например компании обычно- присваивают всем
своим сотрудникам идентификаторы 1D, которые тщательно отбираются в виде
52
Глава 2 Моделирование базы данных
уникальных номеров. Одно из назначений ID —служить гарантией, что в БД
компании каждого сотрудника можно отличить от всех остальных, даже если одно
и то же имя носят несколько сотрудников Поэтому атрибут "1D сотрудника" может
служить ключом для сотрудников в БД
В корпорациях США принято также, что у каждого сотрудника есть номер
страхового полиса. Если в БД есть такой атрибут, как номер страхового полиса, он
тоже может быть ключом для сотрудников. Заметим, что нет ничего плохого, если
существует несколько вариантов ключа для класса, как, например, для класса
сотрудников, имеющих и ID, и номер страхового полиса.
Идея создания атрибута, служащего ключом, достаточно широко распростра-
нена. Кроме ID сотрудников, для различения студентов университетов применя-
ются также специальные ID студентов. Номера водительских удое оверений
(регистрационные номера автомобилей) применяются Департаментом автотранс-
порта для различения водителей (автомобилей). Впрочем читатель и сам найдет
примеры атрибутов, изначально созданных в качестве ключей □
2,5 2 Описание ключей в ODL
13 ODL один или несколько атрибутов описываются как ключи класса с по-
мощью ключевого слова key или keys (любого из них), за которым указываются
атрибуты, формирующие ключ. Если в ключе больше одного атрибута, список
атрибутов заключается в круглые скобки. Описание ключа должно стоять непосред-
ственно за описанием интерфейса, перед открывающей фигурной скобкой или
любыми атрибутами либо связями Само описание ключа заключается в круглые
скобки.
Пример 2.25. Чтобы показать, что множество, состоящее из атрибутов title и
year является ключом для класса Movie, строка I на рис. 2.6 заменяется на:
interface Movie
(key (title, year))
{
Вместо key можно применять keys, даже если описывается только один ключ.
Аналогично, если пате —ключ для класса Star.
(key name)
добавляется перед фигурной скобкой в строку 8 на рис. 2.6. □
Возможно, что ключами являются несколько множеств атрибутов. Тогда за
словом key(s) можно поместить несколько ключей, разделенных запятыми. Обычно
в ключах, имеющих множество атрибутов, список атрибутов должен быть заключен
в круглые скобки, поэтому один ключ с несколькими атрибу ахи можно отличить
от нескольких ключей содержащих по одному атрибуту.
Пример 2.26 Чтобы проиллюстрировать ситуацию, в которой уместно иметь
более одного ключа, рассмотрим класс Employee. Не будем описывать здесь все
множество ею атрибутов и связей, но предположим что его атрибутами являются
empID — идентификатор сотрудника и ssNo — номер страхового полиса Тогда эти
атрибуты можно описать как ключ:
(key empID, ssNo)
2.5 Моделирование ограничений
53
Поскольку список атрибутов здесь не заключен в скобки, a ODL это означает, что
каждый из атрибутов сам является ключом. Если заключить и скобки пару (empID,
ssNo), в ODL считается, что эти два атрибута вместе формируют один ключ. Из
записи
(key (empID, ssNo))
следует именно то, что никакие два сотрудника не могут иметь один и тот же ID
и один и тот же номер страхового полиса, хотя два сотрудника могут совпадать
по одному из этих атрибутов. □
2.5.3 Представление ключей в E/R-модели
Множество сущностей может иметь ключи точно в том же смысле, в каком их
имеют классы ODL. Если множество атрибутов формирует ключ для множества
сущностей, в нем не может быть двух сущностей, чьи значения совпадают для
каждого атрибута ключа В нотации F/R-диаграммы подчеркиваются атрибуты,
принадлежащие ключу для любого множества сущностей. Например, на рис. 2.24
показано множество сущностей Movies из рис. 2.8 с атрибутами Ш!е и year, которые
вместе служат ключом.
Рис. 2.24. Множество сущностей Movies с отмеченным ключом
При наличии нескольких ключей в E/R-модели нет формальных обозначений
для указания всех ключей. Принято выделять один ключ в качестве первичного
и рассматривать множество его атрибутов как единственный ключ для множества
сущностей. В E/R-модели первичный ключ выделяется подчеркиванием, а другие
ключи, называемые вторичными, либо не отмечаются, либо перечисляются в ком-
ментарии на краю диаграммы.
Возможна необычная ситуация, когда ключ для множества сущностей не при-
надлежит самому этому множеству. Такой случай называется “слабыми множества-
ми сущностей" и рассматривается в разделе 2.6.
2.5.4 Ограничения по единственному значению
Часто основной особенностью проекта БД является то, что отдельную роль
в нем играет только одно значение. Например, предполагается, что объект "фильм"
имеет уникальные название, год, длину, тип и фильмом владеет единственная
студня. В ODL легко описать эти допущения, поскольку каждый атрибут имеет
тип. Если он не является множеством, то для атрибута может быть золько одно
значение или только один связанный объект для каждой связи Если же определе
но, что атрибут или связь имеет тип множества, например тип Set<Star> для связи
stars в строке 6 рис. 2.6, тогда с данным фильмом может быть связано несколько
звезд. Данная связь называется многозначной
Следует различать также ситуацию, когда имеется не более чем одно значение
для атрибута или связи, и сшуацию, когда должно быть в точности одно значение.
Если объекты одного класса связаны с единственным объектом другого класса
и требуется, чтобы этот объект существовал, получается ограничение 'ссылочной
54
Глава 2 Моделирование базы данных
целостности", о котором речь пойдет в разделе 2.5.5. Если есть атрибут с единст-
венным значением, возможны два варианта действий.
) Можно потребовать, чтобы значение данного атрибута существовало.
2 Можно считать данное значение произвольным.
Если атрибут является частью ключа для класса. в общем случае требуется, чтобы
значение существовало в каждом объекте. Для других атрибутов можно ввести
пустое значение, которое заменяет реальное значение, когда не существует никакого
значения. Тогда непустое значение для данного атрибута будет необязательным.
Пример 2.27. Для класса Movie, ключом которого в примере 2 23 были опреде-
лены lite и year, потребуем, чтобы эта два атрибута существовали во всех объектах
класса фильмов. Атрибут же length может отсутствовать. Можно использовать,
например, -1 в качестве пустого значения для lengtl , так как ни один фильм не
может иметь отрицательной длины. Если длина фильма не известна, значение
атрибута length устанавливается в - I. Аналогично, можно добавить третье значение
к нумерации, определяющей возможные значения атрибута filmType. В дополнение
к значениям color и blackAndWhite можно выбрать значения типа NULL или
Unknown, показывающие, что о типе фильма нет никакой информации, □
В модели сущности-связи тоже есть способы выражения ограничения по един-
ственному значению. Подразумевается, что каждый атрибут множества сущностей
имеет единственное значение. В обшем случае предполагается, что значение может
быть пустым. Атрибут, который не может иметь пустого значения, указывается
в примечании на полях.
Стрелки, обозначающие связи типа “многие-к-одному" и “один-к-одному1'
тоже выражают ограничения по единственному значению. Если связь имеет стрел-
ку, указывающую на множество сущностей Е\ то только одна сущность из £
ассоциируется с выбором сущностей из каждого из остальных связанных мно-
жеств сущностей.
2.5-5 Ссылочная целостность
Если ограничения по единственному значению устанавливают, что в данной
роли существует только одно значение, ограничение ссылочной целостности означа
ет, что в этой роли существует в точности одно значение. Вариантом ограничения
ссылочной целостности является ограничение, согласно которому атрибут имеет
единственное непустое значение, но “ссылочная целостность чаше применяется
к связям между классами.
Рассмотрим связь ownedBy между Movie и Studio в строке 7 рис. 2.6. Разве
такое возможно: объект класса Studio является значением ownedBy, а самого этого
объекта не существует"5 Ответ заключается в том, что в реализации ODL связь
ownedBy представлена указателем или ссылкой на даннь и объект и в какой-то
момент времени этот объект удаляется из класса Studio. Тогда указатель становится
висящим и больше не указывает на реальный объект.
Согласно ограничению ссылочной целостности объект, на который есть ссыл-
ка, до1жен существовать. Это ограничение можно ввести по-разному.
1. Можно запретить удаление объекта на который есть ссылка (в приведен-
ном выше примере студии).
Можно потребовать, чтобы при удалении объекта, на который есть ссылка,
удалялся п объект, который на него ссылается. В приведенном примере
это значит, что при удалении студим из базы данных нужно удалить также
все фильмы, которыми эта студия владеет.
В дополнение к упомянутым условиям удаления требуется, чтобы при созда-
нии объекта "фильм" существующий объект “студия" был задан в качестве значения
связи ownedBy. При изменении этого значения новое значение также должно быть
2 5 Моделирование ограничений
55
существующим объектом. Использование таких методов обеспечения ссылоч-
ной целостности связи — вопрос реализации БД. и здесь мы не будем его обсуж-
дать.
2.5-6 Ссылочная целостность в E/R-диаграммах
Функции стрелок в E/R-диаграммах можно расширить таким образом, чтобы
они показывали, ожидается ли ссылочная целостность данной связи в одном или
нескольких направлениях. Пусть Л —это связь множества сущностей £ с множеством
сущностей £. Стрелка с закругленным “острием", указывающая на /’, означает не
только то, что £ и £ находятся в связи типа "многие-к-одному" или “один-к-однсму”,
но и то, что должно существовать множество £. То же самое относится к случаю,
когда Л — связь между более чем двумя атрибутами.
Пример 2.28. На рис. 2.25 показано ограничение ссылочной целостности для
множеств Movies, Studios и Presidents. Эти множества и связи впервые были введены
на рис. 2.8 и 2.9. Закругленная стрелка, указывающая от связи Owns на множество
Studios, выражает ограничение ссылочной целостности, состоящее в том, что сту-
дия, владеющая фильмом, должна всегда присутствовать в множестве Studios.
Рис. 2.25. б/В-диогроммо. показывоющоя ограничения ссылочной целостности
Аналогично, вторая закругленная стрелка от Puns к Studios означает, если
президент возглавляет студию, то эта студия обязательно существует в множестве
Studios.
Заметим, что от Puns на Presidents по-прежнему указывает обычная стрелка,
выражая разумное допущение о связи между студиями и их президентами. Если
студия прекращает свое существование, ее президент больше не может называться
президентом (студии) и должен быть удален из множества Presidents. Поэтому
закругленная стрелка указывает на Studios. Если же из базы данных удален прези-
дент, студия может продолжать существовать. Поэтому на Presidents указывает
обычная стрелка, обозначающая, что у каждой студии есть только один президент,
но иногда она может быть и без президента □
2.5-7 Другие виды ограничений
К БД можно применять и другие виды ограничений. Подробно эта тема
рассматривается в главе 6; здесь же приводится лишь краткий анализ.
Согласно ограничениям области значения атрибут должен принимать значения
из ограниченного множества. В ODL каждый атрибут должен иметь определенный
тип. являющийся элементарной формой ограничения области. Например, если
атрибут length имеет тип integer, значением length не может быть 101,5 или любое
другое не целое число. Однако в ODL не действуют более строгие ограничения
типа требования, что длина не должна превышать от 60 до 240. Как будет показано
в разделе 6.3, такие ограничения поддерживаются в SQL.
Существуют и более общие виды ограничений, не попадающие ни в одну
из перечисленных ранее категорий. Например, согласно ограничению на степень
связи, объект/сущность "фильм" не может находиться в связи stars более чем
56
Глава 2 Моделирование базы данных
с 10 объектами/сущностях и “кинозвезда". В E/R-x-юдели линии между символами
связи и множества сущностей можно помечать цифрой, показывающей максималь-
ное число сущностей одного множества, с которыми может быть связана сущность
другого множества. В ODL это же ограничение можно выразить, задав тип атрибута
stars класса Movie списком длины 10. Однако здесь невозможно задать условие,
согласно которому множество может иметь не более 10 элементов.
Пример 2.29. На рис. 2.26 показано, как в E/R-модели выражается ограниче-
ние, согласно которому в фильме может быть не более 10 кинозвезд.
Рис. 2.26. Схеме ограничения число кинозвезд для одного фильма
Другой пример: стрелку можно рассматривать как синоним ограничения <1
п считать закругленную стрелку на рис. 2.25 выражением ограничения '=1'. □
2.5.8 Упражнения к разделу 2.5
Упражнение 2.5.1. Выберите и определите ключи для ОDL-разработок из.
Упражнения 2.1.1
Ь) Упражнения 2.1.3
*с1 Упражнения 2.1.5
d) Упражнения 2.4.1
Упражнение 2.5.2. Выберите и определите ключи для E/R-диаграмм из'
*а) Упражнения 2.2 I
Ь) Упражнения 2.2.3
с) Упражнения 2.2.6
d) Упражнения 2.4.3
(/) выберите и определите ключи и (н) укажите подходящие ограничения ссылоч-
ной целостности.
Упражнение 2.5.3. Можно считать, что связи в E/R-модели имеют ключи, так
же как и множества сущностей. Пусть R есть связь между множествами сущностей
£,. £,, ... Е„. Тогда ключ для А —это такое множество атрибутов К, выбранное из
атрибутов множеств £,, £,. ..., £,, что если (еь в,, .... <?„) н </,/2, --/,) суть два раз-
। ичных кортежа в множестве отношений для А, то невозможно, чтобы эти кортежи
соответствовали друг другу во всех атрибутах К. Теперь предположим, что п= э.те
чю А—бинарная связь. Пусть также дня всякого / Kt это множество атрибутов,
являющееся ключом для множества £}. В терминах £, и £, определите наименьший
возможный кл оч для А при условии, что:
) R — связь типа “многие ко-многим”,
•Ь) R связь £, с £т типа "многие к одному".
с) R связь £> с Е| типа "многие-к-одномч".
di R — связь типа “одии-к-одиому".
2.6 Слабые множества сущностей
57
II Упражнение 2.5.4. Выполните упражнение 2.5.3 при условии, что л —любое
число, кроме 2. Используя только информацию о том, какие линии от R к Ej
имеют стрелки, покажите, как найти наименьший возможный ключ А” для Я
в терминах К;.
I Упражнение 2 5 5. Приведите примеры таких атрибутов, которые созданы в
качестве ключей, из реальной жизни (помимо примера 2.24).
2.6 Слабые множества сущностей
В некоторых случаях ключ множества сущностей формируется из атрибутов,
которые частично пли полностью принадлежат другому множеству сущностей.
Множество с таким ключом называется слабым множеством сущностей.
2.6.1 Причины возникновения
слабых множеств сущностей
Существует два главных источника слабых множеств сущностей. Во-первых,
иногда множества сущностей выстраиваются в иерархию. Когда сущности множе-
ства £ являются составными частями сущностей множества F, возможно, что имена
сущностей Е не уникальны до тех пор, пока не будет учитываться имя той сущно-
сти из F, которой подчинена сущность из £.
Пример 2.30. Приведем примеры иерархий, ведущих к слабым множествам
сущностей.
I. В киностудию может входить несколько съемочных групп, которые обо-
значаются "группа I”, 'группа 2" и т.д. Но так же могут обозначить свои
съемочные группы и другие студии, поэтому атрибут number не является
ключом для съемочных групп. Для определения уникального имени груп-
пы необходимы имя студии, которой она принадлежит, и номер. Такая
ситуация изображена на рис. 2 27. Ключ для слабого множества сущно-
стей Crew состоит из его собственного атрибута number и атрибута пате
единственной студии, с которой кинокомпания находится в связи Unit-of
типа многие к-одному".4
Рис. 2.27. Слобое множество сущностей и его связи
2. Вилы конструируются с помощью рода и имен видов. Например, люди —
это виды Ното sapiens; Ното — имя рода, a sapiens — имя вила В обшем
случае род состоит из множества видов, каждый из которых имеет имя,
начинающееся с имени рода, за ним следует имя вида. К сожалению,
имена видов не уникальны. Несколько ролов могут иметь виды с одним
и тем же именем. Значит, для уникального обозначения необходимы име-
на видов н имя рода, с которым они находятся в связи Member-of. Вилы —
это слабое множество сущностей, ключ которого частично происходит от
содержащего их рода. □
4 Значение двойного ромба и двойного прямоугольника объясняется в разделе 2.6.3.
58
Глава 2 Моделирование базы данных
Другим источником слабых множеств сущностей могут быть множества связу-
ющих сущностей, введенные в разделе 2.2.5 в качестве способа устранения много-
сторонних связей5. Эти множества сущностей часто не имеют собственных
атрибутов, их ключи формируются из атрибутов, являющихся ключевыми для мно-
жеств, с которыми они связаны.
Пример 2,31. На рис. 2 28 показано множество связующих сущностей Contracts,
заменяющее тернарную связь Contracts нз примера 2.8. Contracts имеет атрибут salary,
но он не относится к ключу. Ключ для данного множества состоит нз имени
студии, имени кинозвезды, а также названия и года выпуска фильма. □
2.6.2 Требования
к слабым множествам сущностей
Ключевые атрибуты для слабого множества сущностей нельзя получить произ-
вольным образом. Если Г — слабое множество сущностей, то каждое из мно-
жеств F, поставляющих один ключевой атрибут для £ или более, должно быть
соединено с Е связью Л, Кроме того, необходимо выполнить следующие условия:
I. Л должно быть бинарной связью типа ''многис-к-одному''6 между Е и F.
s Заметим, что в E/R-модслн не требуется заменять многосторонние связи,
а в ODL и в некоторых старых моделях, например, сетевых и иерархических,
рассмотренных к разделе 2 7, это делать необходимо.
а Помните, что связь типа "один-к-одному” — это специальный случай связи типа
“многие-к-одному'1. Требование, чтобы связь была типа "многие-к-одному1, всегда
включает в себя и связь типа "один к-одному".
2.6 Слабые множества сущностей
59
2. Атрибуты F, используемые в ключе для £, должны быть ключевыми атри-
бутами множества F.
3. Если Г само является слабым, атрибуты £, используемые в ключе для Е,
могут быть атрибутами множества сущностей, с которым F соединено
связью типа "многие-к одному”.
4 Если есть несколько связей типа 'многие-к одному” между Е и £ эти
связи можно использовать для получения копий ключевых атрибутов F,
позволяющих сформировать ключ для £ Заметим, что сущность е из Е
может быть связана с многими сущностями в F посредством различных
связей из £ Поэтому ключи многих различных сущностей из F могут
появляться в ключевых значениях, идентифицирующих отдельную сущ-
ность е из £
Эти условия можно объяснить на интуитивном уровне. Рассмотрим сущность
из слабого множества, например съемочную группу из примера 2.30. С абстрактной
точки зрения каждая съемочная группа уникальна. В принципе можно отличить
одну из них от другой, даже если они имеют один и тот же номер, но принадлежат
различным студиям. По данным, относящимся только к съемочным группам, их
трудно различать, поскольку номера здесь недостаточно Единственный способ
связать со съемочной группой дополнительную информацию — это детерминиро-
ванный процесс порождения дополнительных значений, делающих обозначение
съемочной группы уникальным. Найти уникальное значение, связанное с множест-
вом съемочных групп, можно только при выполнении хотя бы одного из следую-
щих условий:
1. Искомым значением является атрибут множества Crew.
2. Можно проследить связь сущности "съемочная группа" с уникальной сущ-
ностью другого множества £, имеющей некоторое уникальное связанное
значение. Такая связь должна иметь тип "многие к одному" (в частном
случае "один-к одному"), а упомянутое связанное значение должно быть
ключом для F.
2.6-3 Обозначение
слабого множества сущностей
Для обозначения слабого множества сущностей и описания его ключевых
атрибутов принимаются следующие соглашения.
I Слабое множество обозначается двойным прямоугольником. Примерами
таких множеств являются Сгеня на рис. 2.27 и Contracis на рис. 2.28.
2 Связи типа "многие к одному" слабого множества с другими множества-
ми сущностей, поставляющими для него ключевые атрибуты, обознача-
ются двойными ромбами. Примерами таких связей являются (Jmt-of на
рис. 2.27 и все три связи на рис. 2 28
3 Если множество сущностей поставляет атрибуты для собственного ключа,
эти атрибуты подчеркиваются Например, на рис. 2 27 number участвует
в собственном ключе, хотя и не является полным ключом для Crews.
Эти соглашения суммируются в виде правила
• Множество сущностей с двойной границей является слабым Его ключ
состоит из его собственных подчеркнутых атрибутов (если таковые имеются)
и ключевых атрибутов тех множеств, с которыми данное слабое множество
соединено связями типа "многие к одному", имеющими двойную границу.
60
Глава 2 Моделирование базы данных
Г-------- --------------------—----------.----.--------_----q
Причина отсутствия "слабых классов" в ODL
Вопрос о поиске ключа никогда не возникает в ODL или любой другой j
( объектно-ориентированной модели. Как было показано в разделе 2.5.2, можно 1
j построить ключ путем описания атрибута или атрибутов, хотя это и нсобяза-
f тельно. Объект обладает свойством "целостности объекта" и в результате имеет
| адрес, по которому его можно найти, a ID объекта уникальным образом отли-
чает один объект от другого даже тогда, когда их невозможно различить по
значениям их атрибутов или связям. А E/R-модель “ориентирована на значе-
1 ние”, и сущности различимы только по связанным значениям их атрибутов.
' Поэтому нужно всегда учитывать, что в E/R-моделях сущности любого мно- !
(жества можно различать только по значениям, не обращаясь ни к какой :
"идентичности объектов". !
_ ___________ ________________________________ t
2.6.4 Упражнения к разделу 2.6
Упражнение 2.6.1. Один из способов представления студентов и оценок,
полученных ими на учебных курсах,- использование множеств сущностей, соот-
ветствующих студентам, курсам и "зачислениям". Зачисления образуют множество
"связующих" сущностей между студентами и курсами. Их можно использовать не
только для представления того факта, что студент проходит определенный курс, но
для выражения отметок, полученных студентом по данному курсу. Предсгавьте эту
ситуацию в E/R-диаграмме. указав слабые множества сущностей и их ключи.
Является ли отметка частью ключа для зачислений?
Упражнение 2.6.2. Измените упражнение 2.6.1 так, чтобы можно было запи-
сывать отметки студентов в каждом случае выдачи заданий по данному курсу.
Укажите слабые множества сущностей и ключи.
Упражнение 2.6.3. На E/R-диаграмме упражнения 2.3.3 укажите слабые мно-
жества сущностей и ключи.
Упражнение 2.6.4. Создайте E/R-днаграммы следующих ситуаций, включаю-
щих в себя слабые множества сущностей, указывая каждый раз ключи для этих
множеств.
a) Comses и Departments — множества сущностей. Курс преподается на един-
ственном факультете, но единственным атрибутом курса является его но-
мер. На разных факультетах мо1ут преподаваться курсы с одним и тем же
номером. У каждою факультета уникальное имя.
*! b) Leagues, Teams и Players — множества сущностей. Имена лиг уникальны.
Ни в одной лиге пет двух команд с одним и тем же названием. Ни в од-
ной команде нет двух игроков с одним и тем же номером, но в разных
командах могут бы ть и роки с од| им и тем же номером и в разных J игах
могут быть команды с одним и тем же названием.
2.7 Модели, представляющие исторический интерес
61
2.7 Модели, представляющие
исторический интерес
В этом разделе рассматриваются еще две модели и часть относящейся к ним
терминологии. Первыми попытками обоснования БД были "сетевые" и "иерархиче-
ские" модели, применявшиеся в коммерческих БД в шестидесятых и семидесятых
годах. Они были вытеснены системами, основанными на реляционных моделях,
которые рассматриваются в главе 3. Однако многие идеи старых моделей сохрани-
лись и в новых объектно-ориентированных подходах к проектированию БД.
2.7.1 Сетевая модель
Сетевую модель можно считать E/R-моделью. ограниченной бинарными связя-
ми типа "многие-к-олному". Ее основные элементы:
I . Типы логических записей. Они аналогичны множествам сущностей н состоят
из имени типа и списка атрибутов. Элементы типа логических записей
называются записями, они аналогичны сущностям в E/R-модели
2 Соединения — это бинарные связи типа "многие-к одному". Они связывают
два множества сущностей, одно из которых имеет тип владельца, а другое
тип члена. Связь направлена от типа члена к типу владельца: каждая за-
пись типа члена приписывается в точности одной записи типа владельца,
а каждая запись типа владельца "владеет" mi ожеством, состоящим из нуля
или более записей типа члена.
Пример 2.32. Рассмотрим пример с фильмами и кинозвездами, которые в них
играют, в сетевой модели. Кинозвезды и фильмы образуют типы логических запи-
сей. Однако связь “stars-in" между фильмами и кинозвездами — это связь типа
"многие-ко-многим", поэтому для ее представления в сетевой модели невозможно
использовать единственную связь. Необходимо создать новый тип логических запи-
сей, называемый Starsln, который является "связующим" подобно связующему мно-
жеству сущностей, введенному в разделе 2.2.5. Каждая запись Starsln представляет
пару кинозвезда-фильм, т.е. кинозвезду и фильм, в котором она играет. Получаем
три типа логических записей для сетевой модели:
Stars(name, address)
Movies(title, year, length, filmType)
Starsln()
Первый из них имеет два атрибута: имя и адрес кинозвезды, а второй — четыре
атрибута: название, год выпуска, длину и тип фильма. Студия, связанная с фильмом,
здесь не рассматривается, хотя в полном проекте эта связь была бы представлена
с помощью соединения. В данной модели связующий тип Starsln не имеет атрибу-
тов, но их можно приписать Например, если записывается гонорар, полученный
кинозвездой за отдельный фильм, он будет функцией пары кинозвезда-фильм
и атрибутом Starsln. Однако в данном примере результат действия Starsln проявля-
ется только в связях, в которых этот тип участвует.
В .модели две связи. Первая из них направлена от Stars к Starsln, т.е. Stars —
это тип владельца, a Starsln — тип члена. Эта связь, называемая TheStar, соединяет
кинозвезду с каждой парой кинозвезда-фильм, в которой она участвует. Вторая
связь — TTieMovie с типом владельца Movies и типом члена Starsln Каждая запись
о фильме владеет парами фильм-кинозвезда, в которую этот фильм входит. Обе
связи — это связи типа ‘многие-к-одному". Парой Starsln {in, s') владеют запись
Movies для фильма т и запись Slars для кинозвезды з. На рис. 2.29 показано, как
соединяются связями все три типа логических записей.
62
Глава 2 Моделирование базы данных
Movies
TheMovie
Starsin
TheStar
Stars
Рис. 2.29. Записи и их свези
Эта диаграмма не является схемой, а показывает сами отдельные записи и спо-
собы их соединения с другими записями с помощью связей. На ней три записи
Starsin Номер I показывает, что Шерон Стоун — кинозвезда в фильме “Основной
инстинкт". Номер 2 представляет пару Шерон Стоун/"бсло.«нигиь все", а номер 3 —
пару Арнольд Швариснеггер/"йсяолшк/пь все". Номера не являются реальными
частями записей, а используются для ссылки на записи Starsin. Записи Starsin
выступают членами обеих связей, а другие записи — владельцами. □
2.7.2 Представление сетевых схем
В диаграммах, представляющих типы логических записей и связи, первые
изображаются овалами, а вторые — именованными стрелками, указывающими от
типа члена на тип владельца.
Пример 2.33. Схематическая диаграмма для трех логических типов записей
и двух связей из примера 2.32 изображена на рис. 2.30. □
Рис. 2.30. Сетовав схема для примера с фильмами
2.7.3 Иерархические модели
Иерархическую модель можно считать ограничением сетевой модели при ко
тором логические типы записей и связи обра уют ес (множество деревьев). Если
каждая из связей показывает, что тип владельца является предком типа члена, типы
логических записей образуют лес деревьев. Проблема с данным ограничением
в том, что оно не выполнимо для некоторых сетей. Например, из рис. 2.30 ясно,
что для логического типа записи Starsin в иерархии нужны были бы два предка:
Stars и Movies, поэтому схема на данном рисунке не является лесом.
2 7 Модели представляющие исторический интерес
63
Вспомните, что тип логических записей Starsln на самом деле служит связую-
щим типом для связи ’многие-ко-многим" между кинозвездами и фильмами.
В иерархической модели такие связи представляются путем создания виртуальной
копии каждого из связанных типов Виртуальные типы можно считать указателями
на записи реальных типов, позволяющими показать любую сеть в виде иерархии.
Пример 2.34. На рис. 2.31 показана иерархическая схема для примера с филь-
мами и кинозвездами. В данном лесу только два дерева. Первое имеет корень Stars
и потомка virtual-Movies. второе имеет корень Movies и потомка virtual-Stars.
Рис. 2 31. Иерархическая сеемо для примера с фильмами
Реальные данные, представленные в схеме на рис. 2.31, можно явно показать
так, как это сделано на рис. 2.32.
Тип Stars имеет потомка virtual-Movies, поэтому каждая запись типа Stars имеет
потомков типа virtual-Movies; виртуальные записи обозначены прямоугольниками,
в которых есть слово "to”.
Рис 2.32. Иерархическое представление фактов о фильмв^нинозвезде
64
Глава 2 Моделирование база данных
Например, запись Шерон Стоун из Stars имеет двух потомков, каждый из
которых является указателем на запись Movies, в данном случае для "Основного
инстинкта" и “Вспомнить все". Чтобы проследить связь типа "многие- о-многим”
между кинозвездами и фильмами, можно начать с записи Stars типа Шерон Стоун
и перейти к ее дочерним записям virttal-Movies а затем от каждой из них к реаль-
ной записи Movies. □
Значение иерархий
Можно задаться вопросом почему странные требования иерархической
модели некогда имели сильное влияние в индустрии БД. Простейший ответ
на него в том, что организуя данные в иерархию с виртуальными т <пами
записей только тогда, когда это необходимо, можно хранить данные, объединяя
записи с их предками в последующем файле. Например, можно хранить
данные, представленные на рис. 2.32, с помощью записи Шерон Стоун, за ко-
торой следуют все "принадлежащие" ей записи, а под ней находятся указатели
virtual-Movies. При попытке получить доступ к данным двигаясь вниз по
дереву, можно поискать их в ближайшем файле и перейти от родительских
записей к дочерним. Таким образом уменьшается количество времени, необ-
ходимого для получения нужной информации с диска.
В данном примере от такого метода мало пользы, поскольку следование
указателю, представленному виртуальными типами, приводит в случайным
образом расположенные места на диске, в которых хранится информация о
фильмах. Однако, за исключением случая со связями типа "многие-ко-многим",
выполнение запросов в иерархической структуре значительно повышает
пром зводительность
2.7.4 Упражнения к разделу 2.7
Упражнение 2.7.1. Выразите в сетевой модели проекты, описанные в
*а) упражнении 2.1.1;
Ь) упражнении 2.1.3
с) упражнении 2.1.5;
d) упражнении 2.3.2.
Упражнение 2.7.2. Повторите упражнение 2.7 1 в иерархической х одели
*5 Упражнение 2.7.3. Предположим, что имеется диаграмма сущности-связи с
п множествами сущностей и т бинарными связями. Каково максимальное и мини-
мальное число связей, необходимых при конвертировании этой диаграммы в сете-
вую модель? Помните, что каждая связь может быть типа "многие-ко-многим",
"viHorne к одному" пли "один к одному’
Упражнение 2.7.4. Предположим, что имеется диаграмма сушности-связи с
л множествами сущностей и т бинарными связями. Назовите максимальное
и минимальное >исло виртуальных типов, необходимых для представления этой
диа рам 1ы в иерархической модели.
! Упражнение 2.7.5. Как изменятся результаты выполнения упражнений 2 7.3
и 2.7 4, если связи А.-арны для к > 2?
2.8 Итоги
65
2.8 Итоги
♦ Обозначения проектов. Проектирование БД часто проводится с помощью
E/R-модели или объек1но-ориентированной модели типа ODL. Предполага-
ется, что E/R-модель переводится в модель реальной системы БД, часто
в реляционную модель. Проекты ODL либо трактуются точно так же, либо
служат (почти) прямым вводом в объектно-ориентированную систему БД,
+ Язык описании объектов (ODL). В этом языке классы объектов описываются
с пом шью атрибутов, связей и методов. Атрибуты представлены их типами
данных. Система типов ODL включает в себя обычные базовые типы,
например целые числа, и конструкции типов, сформированные из структур
записей, множеств, мультимножеств списков и наборов. Связи описываются
с помощью класса, с которым они связаны, и могут быть односторонними
или многосторонними.
> Диаграммы сущности-связи (Е/R). В Е/R модели описываются множества
сущностей и связи между ними. Члены этих множеств называются сущно-
стями. Множества сущностей, связи и атрибуты обозначаются соответствен-
но прямоу!ельниками, ромбами и овалами.
к Множественность связей. Связи в ODL или Е/R обычно различают по их
множественности. Бинарные связи могут быть типа "один-к одному",
"многие-к-одному" или "многие-ко-многим". Связи между более чем двумя
множествами сущностей (классами) допустимы в Е/R, но не в ODL.
+ Слабые множества сущностей. E/R-модель иногда осложняется тем, что
в ней возникает слабое множество сущностей, требующее атрибутов другого
связанного с ним множества или множеств для определения собственных
сущностей. Для обозначения слабых множеств сущностей применяется спе-
циальная нотация, включающая в себя двойные прямоугольники и двойные
ромбы
+ Хороший проект. Эффективное проектирование БД требует, чтобы выбранная
нотация (например, ODL или Е/R) правильно отражала реальный мир
с помощью подходящих элементов (связей и атрибутов) и была свободна от
избыточности: повторений одного и того же факта или выражений в косвен-
ной или слишком сложной форме.
+ Подклассы. ODL и Е/R поддерживает специальные классы или множества
сущностей. ODL имеет классы и наследование, а Е/R использует специаль-
ную связь isa для выражения того факта, что одно множество сущностей
является специальным случаем другого.
♦ Ключи. В ODL и F/R множества атрибутов можно объявлять ключами, имея
в виду, что их значения уникальным образом определяют объект или
сущность. ODL имеет также обозначения идентификаторов объектов — зна-
чений, которые уникальным образом определяют объек ы, но недоступны
для пользователя.
* Сетевая модель. Эта модель в настоящее время используется редко. Она
аналогична E/R-диаграммам, ограниченным бинарными связями типа
“многие-к-одному“
* Иерархическая модель. Эта модель сейчас тоже используется не часто Она со
ответствует E/R-модели с м гожествами сущностей, упорядоченными в виде
леса, и связями типа "многие-к-одному' только между предком и потомком.
66 Глава 2 Моделирование базы данных
2.9 Литература к главе 2
Основополагающей работой по E/’R моделям является [3]. В книгах [4] и [1]
содержится обширный материал по проектированию в модели сущности-связи
и в других полезных моделях.
Учебник [2] по ODL подготовила группа Object Data Management Group
(ODMG). Доступ к новейшим материалам по ODL этой организации можно полу-
чить по адресу info@odmg.org и на Web-странице http://www.odmg.org.
I. Batini, С., S. Ceri, and S. В. Navathe, Conceptual Database Design,
Benjamin/Cumnnngs Redwood City, CA, 1992.
2. Canell, R. G. G. (ed ), The Object Database Standard: ODMG-93 Release / 2,
Morgan-Kaufmann, San Francisco, 1996
3. Chen, P. P, "The entity-relationship model: toward a unified view of data",
ACM Trans, on Database Systems 1 1, pp. 9-36, 1966.
4 El Masri, R. and S. B. Navathe, Fundamentals of Database Systems, Benjamin
Cummings, Menlo Park, 1994
Глава 3
Реляционные
модели данных
Методы моделирования данных ODL и Е/R, рассмотренные в главе 2, вполне
подходят для описания структуры данных, однако современные реализации БД
почти всегда базируются на другой модели — реляционной. Ее ценность заключается
в том, что она основана на единственном понятии моделирования данных — "отно-
шении", двумерной таблице, в которой собраны данные. В главе 5 будет показано,
как реляционная модель поддерживает язык программирования очень высокого
уровня — SQL, позволяющий писать простые и мощные программы, которые
манипулируют данными, хранящимися в отношениях.
Тем не менее иногда бывает легче проектировать БД с помощью моделей, изу-
ченных в глвве 2. Поэтому необходимо знать, как перевести проекты из ODL или
Е/R в отношения. Реляционная модель имеет собственную теорию, которая часто
называется нормализацией отношений и основана на "функциональных зависимо-
стях", расширяющих понятие "ключ", неформально рассмотренное в разделе 2.5.1.
Теория нормализации часто облегчает выбор отношений, представляющих конк-
ретный проект БД.
3.1 Основы реляционной модели
Реляционная модель обеспечивает единственный способ представления данных
в виде двумерной таблицы, называемой отношением. Пример отношения приведен
на рис. 3.1.
title year length filmType
Star Wars 1977 124 color
Mighty Ducks 1991 104 color
Wayne's World 1992 95 color
Рис. 3.1. Отношение Movie
Это отношение имеет имя Movie и предназначено для хранения такой же
информации, которая содержалась в простом определении ODL класса Movie на
рис. 2.4 из примера 2.1 и воспроизводится здесь как рис. 3.2. Заметим, что данное
определение не является окончательным определением класса Movie и имеет только
атрибуты title, year, length и filmType.
Глава 3 Реляционные модели данных
1) interface Movie {
2) attribute string title;
3) attribute integer year;
41 attribute integer length,
5) attribute enumeration (color, blackAndWhite} filmType;
};
Рис. 3.2 ODl-описоние классе Movie
3.1.1 Атрибуты
В верхней части рис. 3.1 расположены атрибуты title, year, length и filmType.
Атрибуты отношения служат именами ею столбцов. Обычно атрибут отражает
смысл того, что записано в лежащем иод ним столбце. Например, в столбце с атри-
бутом length указана длительность различных фильмов в минутах.
Заметим, что атрибуты отношения Movie на рис 3.1 соответствуют элементам
структуры, называемым “атрибутами" в определении ODL на рис. 2.4. Такой подход
к выбору атрибутов для отношения встречается довольно часто. Однако не сущест-
вует общего требования, чтобы атрибуты отношения соответствовали всем отдель-
ным компонентам ODI. или F/R-опнсания данных.
3.1-2 Схемы
Имя отношения н .множество его атрибутов образуют схему этого отношения.
Схема обозначается именем отношения, за которым следует заключенный в Kpyi-
лые скобки список его атрибутов. Схема отношения Movie на рис. 3.1:
Movie(title year, legth, filmType)
Атрибуты в схеме отношения являются множеством, а не списком, тем не
менее, говоря об отношениях, часто приходится определять "стандартный’ порядок
атрибутов. Поэтому, вводя схему отношения со списком атрибутов, будем считать
принятое упорядочение стандартным порядком при просмотре отношения или
любой из его строк.
В реляционной модели проект состоит из одной или нескольких схем отноше
пий. Множество схем отношения в проекте называется схемой реляционной БД или
просто схемой БД.
3.1.3 Кортежи
Строки отношения, отличные от заглавной строки, состоящей из атрибутов,
называются кортежами. Кортеж содержит один компонент для каждого атрибута
отношения. Например, первый из трех кортежей на рис. 3.1 имеет четыре компо-
нента Star Wars. 1977, 124 и color для атрибутов title, year, legth и filmType coo вет-
libchho. При записи кортежа отдельно от отношения он обычно заключается в
круглые скобки и его компоненты разделяются запятыми. Например.
(Star Wars, 1977, 124, color)
является кортежем рис. 3.I. При появлении кортежа отдельно от отношения
атрибуты отсутствуют, поэтому необходимо каким-то образом указать отношение,
к которому он принадлежит. Во всех случаях мы будем придерживаться порядка,
при котором атрибуты были перечислены в схеме отношения
Можно по мать, что кортежи представляют объекты, а отношения, которым
1^ р^^щ^жат^^^цсс. 1’^^що rui^gjjpHT дело в привеченном примере отно-
3.1 Основы реляционной модели
69
тения; каждый кортеж представляет объект "фильм" Компоненты трех кортежей
отношения идентичны свойствам этого объекта, описанным на рис. 3.2. Однако
объектам присуща идентичность, а кортежам нет. В принципе при объектно-ориен-
тированном представлении фильмов может оказаться два разных объекта с одними
и теми же значениями всех атрибутов, хотя в примере 2.23 и утверждалось, что
с фильмами такое вряд ли случится.
Однако отношения — это множества кортежей, причем один кортеж НС МОЖСТ
дважды входить в данное отношение. Поэтому, если отношение представляет класс
объектов, нужна гарантия, что у отношения достаточно атрибутов для того, чтобы
два каких-либо объекта нс имели одинаковых значений всех атрибутов данного
отношения. В примере 2.23 говорилось, что два разных фильма не могут быть
выпушены с одним и тем же названием в одном и том же году. Однако в худшем
случае может понадобиться атрибут, являющийся искусственным представлением
самого объекта. Например, можно присвоить фильму уникальное целое число
"ID фильма" и добавить movielD к множеству атрибутов приведенного в данном
примере отношения.
3-1-4 Области
Как того требует реляционная модель, каждый компонент каждого кортежа
должен быть атомарным, те. компонентом элементарного типа, например целым
числом или строкой. Недопустимо, чтобы значение было структурой записи, мно-
жеством, списком, набором или имело любой иной тип, который можно разбить
на более мелкие компоненты Это ограничение служит одним из препятствий для
прямого перевода атрибутов ODL в единственные атрибуты отношения Так, если
атрибут ODL пате имеет тип
Struct Name {string first, string last}
в соответствующем отношении должно быть два атрибута — first и last (см раз-
дел 3.2.2).
Кроме того, предполагается, что с каждым атрибутом отношения связана
какая-то область значений, т.е. отдельный элементарный тип Каждый компонент
любого кортежа отношения должен иметь значение, принадлежащее области
соответствующего столбца. Например, первым компонентом каждого из кортежей
отношения Movie на рис. 3.1 должна быть строка, вторым и третьим — целое число,
а значением четвертого компонента — одна из констант color или blackAndWhite.
3-1.5 Эквивалентное представление отношения
Схема и кортежи отношения - это множества, а не списки, поэтому порядок
их представления не имеет значения. Если, например, перечислить три кортежа из
рис. 3.1 шестью различными способами, отношение останется "одним и тем же".
Более того, можно произвольно изменять порядок атрибутов отношения,
причем само отношение не изменится. Однако, перестраивая схему отношения,
следует помнить, что атрибуты являются заголовками столбцов. Поэтому при
изменении порядка атрибутов меняется порядок их столбцов При перемещении
столбца изменяется и порядок компонентов кортежей. В результате компоненты
каждого кортежа переставляются так же, как переставляются столбцы
В частности, на рис. 3 3 показано одно из многих отношений, которые могут
быт получены на рис. 3.1 путем перестановки строк н столбцов. Исходное и полу-
ченное из него отношения считаются "одним и тем же". Точнее говоря, эти две
таблицы являются различными представлениями одного и того же отношения.
Заметим, «по перестановка атрибутов и столбцов влияет на отдельное пред-
ставление кортежей
70
Глава 3 Реляционные модели данных
year title filmType length
1991 Mighty Ducks color 104
1992 Wayne’s World color 95
1977 Star Wars color 124
Рис. 3.3. Другое предстоеление отношения Movie
Пример 3.1 Кортежи (Star Wars. 1977, 124, color)
из рис. 3.1 и (1977, Star Wars, color, 124)
из рис 3 3 представляют один и тот же объект. Тем не менее в их эквивалентности
можно быть уверенным, только если известен порядок атрибутов соответствующих
им отношений. Поэтому в обшем случае следует выбирать порядок для атрибутов
отношения и сохранять его на все время использования данного отношения. □
| Формальное понятие кортежа
В данной книге кортежи выражаются как списки с понятным порядком
! атрибутов каждого отношения. В то же время существует и формальное
| понятие кортежа, позволяющее избежать фиксированного порядка атрибутов
| Кортежем можно считать функцию из множества атрибутов схемы их от-
I ношения в множество значений — компонентов кортежа для этих атрибутов,
i Например, кортеж, представленный двумя способами в примере 3.1. можно
! определить как функцию
title -* Star Wars
| year-» 1977
J length -» 124
! ЧтТуре -> color
3-1.6 Экземпляры отношения
Отношение, касающееся фильмов, нс статично, со временем оно изменяется
Предполагается, что изменяются и кортежи отношения в БД вводятся новые
кортежи фильмов, существующие кортежи изменяются при получении новой
информации о фильме и, бывает, удаляются кортежи для тех фильмов, которые по
какой-то причине исключаются из БД
Схема отношения изменяется реже. Однако в некоторых ситуациях необходи-
мо добавлять или удалять атрибуты. Схема при этом изменяется, а это в некоторых
коммерческих системах БД может стоить очень дорого, так как для добавления или
удаления компонента приходится переписывать иногда миллионы кортежей При
добавлении атрибута иногда трудно, а подчас даже невозможно найти правильные
значения новых компонентов кортежей
3. t Основы реляционной модели
Множество кортежей для заданного отношения будем называть экземпляром
этого отношения. Например три кортежа на рис 3.1 составляют экземпляр
отношения Movie. Допустим, отношение Movie со временем изменилось и будет из-
меняться далее Так, в 1980 г. в Movie нет кортежей для M'ghty Ducks или Wayne’s
World. Однако обычная система БД работает только с одной версией любого
отношения — множеством кортежей, находящихся в отношении "сейчас". Такой
экземпляр отношения называется текущим экземпляром.
Схемы и экземпляры
Не забывайте о важных различиях между схемой отношения и его экземп-
ляром Схема — это имя и атрибуты отношения, она относительно неизменна.
Экземпляр — это множество кортежей для данного отношения, он может
часто изменяться.
Различие схема/экземпляр широко распространено в моделировании
данных Например, в главе 2 подчеркивалось различие между определениями
интерфейса ODL, задающими структуру класса объектов, и множеством
объектов этого класса. Определение интерфейса подобно схеме, а множество
объектов определяемого класса является экземпляром Аналогично, множест-
во сущностей и описания связей — это способ описания схемы в E/R-модели,
а конкретный набор сущностей и множества связей образуют экземпляр
E/R-схемы Следует, однако, помнить, что при проектировании БД ее экземп-
ляр не является частью проекта При развитии проекта мы только представля-
ем себе, как выглядят типичные экземпляры.
3-1.7 Упражнения к разделу 3-1
Упражнение 3.1.1. На рис 3.4 показаны экземпляры двух отношений, которые
могут быть частью банковской БД. Покажите
а) Атрибуты каждого отношения
Ь) Кортежи каждого отношения
с) Компоненты одного из кортежей в каждом из отношений
d) Схему каждого из отношений
е) Схему БД
f) Подходящую область для каждого атрибута
g) Другой эквивалентный способ представления каждого отношения
acctNo type balance firstName lastName idNo account
12345 savings 12000 Robbie Banks 901-222 12345
23456 checking 1000 Lena Hand 805-333 12345
34567 savings 25 Lena Hand 805-333 23456
Отношение Accounts
Отношение Customers
Рис. 3.4 Два отношения для банковской БД
72
Глава 3 Реляционные модели данных
Упражнение 3.1.2. Сколько существует различных способов представления
экземпляра отношения (связанных с порядком кортежей и атрибутов), если оно
имеет:
*а) Три атрибута и гри кортежа, как отношение Accounts на рис. 3.4
Ь) Четыре атрибута и пять кортежей
с) я атрибутов и т кортежей
3.2 Переход от проектов ODL
к реляционным проектам
Рассмотрим процесс построения новой БД Он начинается с фазы проектиро-
вания, во время которой мы отвечаем на вопросы о том, какая информация будет
храниться, какие ее элементы будут связаны между собой, какие предполагаются
ограничения и т.д Эта фаза длится до тех пор, пока не оценены и не согласованы
различные варианты.
За фазой проектирования следует фаза реализации с применением реальной
СУБД. Поскольку в подавляющем большинстве коммерческих СУБД используется
реляционная модель, можно предположить, что и на фазе проектирования должна
применяться эта модель а не ODL или Е/R модель рассмотренные в главе 2.
На практике, однако, подчас бывает легче начать именно с этих моделей,
чтобы завершить проектирование, а затем конвертировать результат в реляционную
модель. Основная причина применения такого подхода в том, что реляционной
модели, имеющей единственное понятие отношения, присуща определенная жест
кость, с которой лучше иметь дело после принятия проекта.
В этом разделе рассматривается, как проект ODL преобразуется в реляционный
проект. В разделе 3 3 рассматривается конверсия E/R-модели в реляционную
модель, а в разделе 3 4- вопросы, связанные с подклассами. Поскольку классы
в ODL и в E/R-модели трактуются не совсем одинаково, различаются и их передо
ды в отношения
Часто ограничения считаются частью схемы БД. Ограничения в ODL или
E/R-модели типа ключей либо ограничения ссылочной целостности можно выразить
и в реляционной модели. В разделе 3.5 рассматривается важный класс ограниче
ний, называемый функциональными зависимостями, а изучение других ограниче-
ний на отношения начнется с раздела 4.5.
3-2.1 Переход от ODL
к реляционным атрибутам
Для начала предположим, что наша цель иметь одно отношение для каждого
класса один атрибут для каждого свойства этого отношения Далее показано
много способов, которыми должен быть изменен этот подход, пока же рассмотрим
самый простой случай, в котором действительно можно конвертировать классы
в отношения, а свойства в атрибуты. Принимаются следующие ограничения:
I Все свойства класса представляют собой атрибуты
(а не отношения или методы).
2. Типы а рибутов атомарны (не являются структурами или множествами).
Пример 3.2. Пример удовлетворяющего этим ограничениям класса показа а на
рпс. 3.2. здесь четыре атрибута и нет никаких других свойств Все атрибуты имеют
атомарный тип; title это строка year и length петые числа, a filmType— пере-
числение двух значений
3.2 Переход от проектов ODL к реляционным проектам
73
Создадим отношение с тем же именем Movie. Имена реляционных атрибутов
могут совпадать с именами соответствующих им атрибутов класса Схема этого
отношения:
Movieftitle, year, ength, filmType)
как и в разделе 3.1.1.
Объект данного класса имеет значения для каждого из четырех атрибутов класса
Кортеж для этого объекта можно образовать, используя каждое значение атрибута
н качестве компонента Результат такого преобразования нам уже известен. Пример
преобразования некоторых объектов Movie в кортежи показан на рис. 3.1. □
Представление перечней и дат
Некоторые атомарные типы ODL — перечни и латы — нельзя представить
I непосредственно в стандартной реляционной модели. Однако они не вызывают
серьезных проблем. Например, перечень — это список псевдонимов нескольких
первых целых чисел. Поэтому тип "перечень" ODL для дней недели можно
! представить атрибутом с типом целого числа, используя только числа от 0 до 6.
Атрибут типа строки применяется с днями, представленными строками "Моп",
( ’’Tues’ и т.д. Аналогичным образом, даты в ODL разрешается представить
в реляционной модели посредством атрибута типа строки. Обсуждая в главе 5
реляционный язык запросов SQL, обнаруживаем, что он, как и ODL, поддер-
[ живает типы атрибутов, являющиеся перечнями или датами.
3-2.2 Неатомарные атрибуты в классах
К сожалению, при конверсии классов в отношения возможны трудности, даже
если все свойства класса являются атрибутами Причина в том, что атрибуты
в ODL могут иметь сложные типы, например, структуры, множества, мультимно-
жества или списки. С другой стороны, согласно фундаментальному принципу реля-
ционной модели атрибуты отношения имеют только атомарный тип, такой как
простое число или строку. Поэтому нужно найти способ представления неатомар-
ных типов в виде отношений.
Проще всего оперировать со структурами записей, поля которых атомарны:
относительно просто расширить определение, создавая один атрибут отношения
для каждого поля структуры. Единственная проблема здесь в том, что две структу-
ры могут иметь поля с одинаковым именем. В этом случае приходится вводить
новые имена атрибутов для различения таких полей в отношении
Пример 3 3. Рассмотрим определение класса Star из примера 2.3, воспроизве-
денное на рис. 3.5.
interface Star {
attribute string name,
attribute Struct Addr
{string street, string city} address;
};
Рис. 3.5. Клосс co структурированным атрибутом
74
Г лава 3 Реляционные модели данных
Атрибут name атомарен, но атрибут address — это структура с двумя полями,
street и city Поэтому данный класс можно представить в виде отношения с двумя
атрибутами. Первый из них. name, соответствует атрибуту ODL с таким же именем,
а второй и третий, street и city.—двум полям структуры address и вместе составляют
адрес Схема рассматриваемого представления:
' Starfname. street, city)
Пример экземпляра этого отношения с некоторыми возможными кортежами пока-
зан на рис. 3.6. □
пате street city
Carrie Fisher 123 Maple St Hollywood
Mark Hamill 456 Oak Rd. Hollywood
Harrison Ford 789 Pam Dr Beverly Hills
Рис. 3.6. Отношение, представляющее кинозвезд
Однако структуры записей еще не самые сложные виды атрибутов, которые
появляются в определениях классов ODL. Значения можно строить с помощью
конструкторов типов Set, Bag, Array и List. Каждый из них вызывает особые проб
лсмы при переходе к реляционной модели. Здесь мы подробно рассмотрим только
наиболее распространенный конструктор — Set
| -lllll Л---И--Г _ I. -IK- I TUMI r II -41- — Г IM T --П-М- ---—
Замечание о качестве данных :-)
Стремясь сделать пример данных максимально точным, мы, тем не ме-
нее, использовали фиктивные значения для адресов и другой персональной
1 информации о кинозвездах, чтобы не нарушать личные интересы актеров, ।
‘ многие из которых настолько застенчивы, что избегают публики. |
-- --- . —s г. — — ... . I I
Один из способов представления множества значений для атрибута Я — созда-
ние одного кортежа для каждого значения. Такой кортеж содержит подходящие
значения для всех атрибутов, кроме Я. Сначала рассмотрим пример того, когда
такой способ хорошо действует, а затем выясним связанные с ним трудности.
Пример 3.4. Предположим, что класс Star определен так, что для каждой
кинозвезды можно записать множество адресов Определение класса ODL дано на
рис. 3 7.
interface Star {
attribute siring name,
attribute Set<
Struct Addr {string street, string city}
> address,
}
Рис. 3.7. Кинозвезды с множеством адресов
3.2 Переход от проектов ODL к реляционным проектам
Допустим также, что у Кэрри Фишер есть еше дом на побережье, а две другие
кинозвезды, названные на рис. 3.6, имеют только по одному дому. Тогда можно со-
здать два кортежа с атрибутом name, совпадающим с "Carrie Fisher", как показано
на рис. 3.8. Другие кортежи остаются такими же, как на рис. 3.6. □
лете ; street _______ city
Carrie Fisher 123 Maple St. Hollywood
Came Fisher 5 Locust Ln. Malibu
Mark Hamill 456 Oak Rd. Brentwood
Harrison Ford 789 Palm Dr. Beverly Hills
Рис. 3.8. Допущение множество адресов
Следует учесть, что такая техника расширения множества на несколько корте-
жей иногда дает плохо спроектированное отношение. В разделе 3.7 исследуются
некоторые возникающие при этом проблемы и методы перестройки схемы БД
Здесь же мы просто рассмотрим примеры проблем, которые могут возникнуть.
Атомарные значения:
технический дефект
или характерное свойство?
Кажется, что реляционная модель создает проблемы, a ODL является
более гибкой, допуская структурированные значения в качестве свойств.
Конечно, можно вообще игнорировать реляционную модель или считать ее
примитивным понятием, которое вытесняется более элегантными объектно-
ориентированными подходами типа ODL. Однако реальность такова, что на
рынке доминируют СУБД, основанные именно на реляционной модели. Одна
из причин в том, что простота модели позволяет применять для запросов к БД
элегантные и мощные языки’ программирования. В разделах 4.1 и 4.2 будут
I введены абстрактные языки программирования реляционная алгебра и Datalog.
I Возможно, самое важное значение имеет их внедрение в SQL, стандартный
язык, применяемый в большинстве современных СУБД.
Пример 3.5. Допустим, что в определение класса Star добавляется атрибут
birthdate и используется определение, описанное на рис. 3.9.
Interface Star {
attribute string name;
attribute Set<
Struct Addr [string street, string city}
> address;
attribute Date birthdate,
};
Рис. 3.9 Кинозвезды с множеством одресов и дотами рождения
76
Глава 3 Реляционные модели данных
Мы просто добавили в рис. 3.7 атрибут birthdate типа Date —один из атомарных
шпон н ODL. Этот атрибут может принадлежать отношению Star, схема которого
теперь выглядит так:
Starfname, street, city, birthdate)
Внесем erne одно изменение в данные на рис. 3.8. Поскольку множество
адресов .может быть пустым, предположим, что в БД нет адреса Харрисона Форда
(Harrison Ford). Результат такого изменения показан на рис 3.10.
пате I street
Carrie Fisher : 123 Maple St.
Carrie Fisher । 5 Locust Ln.
Mark Hamill 456 Oak Rd.
city ! birthdate
Holywood 1 9/9/99
I Malibu 9/9/99
[ Brentwood I 8/8/88
Рис. 3.10. Добавление дот рождения
У этого отношения два недостатка Во-первых, дата рождения Кэрри Фишер
повторяется дважды, следовательно, в отношении присутствует избыточная инфор-
мация. Заметим, что ее имя тоже повторяется, но это повторение не является
настоящей избыточностью, так как без повторения имени в каждом кортеже невоз-
можно определить, что оба адреса принадлежат Кэрри Фишер. Разница в том, что
имя кинозвезды — это ключ для объекта, который представляется отношением
н должен появляться в каждом кортеже, представляющем кинозвезду. Дата рожде-
ния — это даннью о кинозвезде, не входящие в ключ для представляемого объекта,
поэтому их повторение избыточно.
Во-вторых, множество адресов Харррисона Форда пусто, информация о нем
утрачена. В частности, дата его рождения не является частью отношения, даже если
она появляется в объекте Star.
Читатель должен помнить, что методология конвертирования схем ODL
в реляционные схемы позволяет исправить оба недостатка, но о подобных проб-
лемах следует знать и исправить реляционную схему методами ‘‘нормализации",
описанными в разделе 3.7. □
Когда у класса несколько атрибутов, имеющих тип множества (будем называть
их многозначными атрибутами), число кортежей, необходимых для представления
единственного объекта, может увеличиваться, так как нужно создавать кортеж для
каждой комбинации значений многозначного атрибута. К этой проблеь е мы
вернемся в разделе 3.2.5 в контексте отношений с типом множества.
3.2.3 Представление других
конструкторов типов
Для конструирования значений в определении класса ODL, кроме структур
.laniiCeii и множеств, можно использовать мультимножества, массивы и списки. Для
предегзнлеиия мультимножества, в котором единственный объект может встречать-
ся л раз. невозможно просто ввести в отношение п идентичных кортежей1. Вместо
1 ючнее говоря истьтя ввозить iischtu'ihmc кортежи в отношения абстрактной
реляционной мотели описанной и этой главе. Однако основанные на SQL
реляционные СУБД »»3«<i.imom дублирован. кортежи ге. в SQL отношения являются
му Тьтпмножсетпачп. а не множествами (см разаслы 4.6 и 5.4). Когда важно чисто
кортежей советуем использовать схемы подобные описанным в этой главе если лаже
.. ш.| С У.ьД io-.iWbci туб1провзт1. кортежи
3 2 Переход от проек ов ODL к реляционным лроехтам
77
этого можно добавить к реляционной схеме еще один атрибут count показы-
вающий, сколько раз каждый элемент входит в мультимножество. Например,
пусть address на рис. 3.7 — это мультимножество, а не множество. Можно указать,
что "123 Maple St Hollywood” является адресом Кэрри Фишер дважды, а "5 Locust
Ln., Malibu” трижды:
пате street I city count
Carrie Fisher 123 Mapla St I Hollywood 2
Carrie Fisher 5 Locust Ln. | Malibu 3
Список адресов можно представить с помощью нового атрибута postion, обо-
значающего позицию в списке. Например, покажем адреса Кэрри Фишер, начиная
с Голливуда, в виде списка:
name street city position
Carrie Fisher 123 Maple St. Hollywood 1
Carrie Fisher 5 Locust Ln. Malibu 2
И наконец массив адресов фиксированной длины можно представить с по-
мощью атрибутов для каждой позиции в наборе. Например, если address — набор,
состоящий из двух структур улица-город, объекты Star представляются следующим
образом:
name streetl cityl street? I city2
Carrie Fisher 123 Maple St. Hollywood 5 Locust Ln. | Malibu
3.2.4 Представление однозначных связей
Нередки случаи, когда одно определение класса ODL содержит связи с другими
классами ODL. В качестве примера рассмотрим полное определение класса Move,
приведенное на рис. 2.6 и воспроизведенное здесь на рис, 3.11.
interface Movie {
attribute string title;
attribute integer year;
attribute integer length;
attribute enumerat on{color, blckAndWhite} filmType;
relationship Set<Star> stars
inverse Star:: starredln;
relationship Studio ownedBy -
inverse Studio :. owns.
}:
Рис. 3.11. Полное определение класса Movie
Рассмотрим сначала связь ownedBy между каждым фильмом и создавшей его
студией. На первый взгляд она похожа на атрибут. Можно создать реляционный
атрибут или несколько таких атрибутов для представления объектов связанного
класса по аналогии с тем, как мы представляем атрибут ODL. значением которого
является структура или множество структур. В случае со связью ownedBy можно
было бы внести в схему отношения Movie по одному атрибуту1 для каждого свойства
класса Studio.
78
Глава 3 Реляционные модели данных
Такой подход вызывает следующую проблему: объест Studio имеет свойство
owns являющееся обратной связью с классом Movie. Для представления этой связи
каждый кортеж фильма должен содержать информацию о всех других фильмах,
сделанных на данной студни. В принципе, информация о каждом из этих фильмов
включает в себя и данные о студни, что вынуждает нас снова учитывать информа-
цию о всех фильмах этой студни. Ясно, что такое решение слишком сложно, если
только вообще возможно.2
Более подходящее решение можно найти, обратившись к тому, как на самом
леле объекты хранятся в компьютерной памяти. Если объект О, содержит ссылку
на другой объект О2, это не означает, что О2 копируется в просто в О, есть
"указатель", указывающий на О2.
По в реляционной модели нет понятия указателя или чего-то близко соответ-
ствующего указателям. Эффект указателей приходится имитировать с помощью
значений представляющих связанные объекты. Что в данном случае необходимо,
так это множество атрибутов связанного класса, образующее ключ. При наличии
такого множества связь трактуется как ключеиой(ыс) атрибут(ы) связанного класса.
Проиллюстрируем этот метод на примере.
Пример 3 6. Допустим, что name — ключ для класса Studio, определение кото-
рого было дано на рис. 2.6:
interface Studio {
attribute string name,
attribute string address;
relationship Set<Movie> owns
inverse Movie : ownedBy;
};
Изменим схему для отношения Movie, показанную на рис. 3.1, включив в нее
атрибут, представляющий студию, владеющую фильмом. В качестве такого атрибута
произвольно выбирается studioName Результат изменения схемы и некоторые
простые кортежи показаны на рис. 3.12. □
title year length I filmType studioName
Star Wars 1977 124 | color Fox
Mighty Ducks 1991 104 I . : color Disney
Wayne's World 1992 95 color Paramount
Рис. 5.12 Отношение Movie с нопьтл отрибутом, представляющим студию,
впадающую фильмом
3-2.5 Представление многозначных связей
К связи stars на рис. 3 11 относился проблема, которой не возникало при
рассмотрении связи ownedBy Если типом связи является класс, она называется
однозначной связью Пример такой связи — ownedBy с типом Studio. Если же связь
2 В то время как иепь фильмов в студий никогда не выходит за пределы множества
фильмов, выпушенных одной студней, аналогичный подход к связи siers
п ее обращению starredln гораздо сложнее. Он ведст от фильма к занятым в нем
кинозвездам. от них ко всем фильмам, в которых они играли, затем ко всем
кинозвездам, участвующим в этих фильмах . И так до тех пор, пока нс перебираются
почти вес кинозвезды и фильмы, внесенные в БД
3.2 Переход or проектов ODL к реляционным проектам
79
имеет тип множества, примененный к классу, она считается многозначной. Например,
stars — многозначная связь, так как имеет тип Set<star>. Другими словами, любая
связь класса А с классом В типа "однн-ко-многим" или "многие ко-многим" — это
многозначная связь А с В
Для представления многозначной связи нужна комбинация двух методов:
I. Однозначные связи — нужно найти ключ для представления каждого из
связанных объектов.
3. Атрибуты со значением типа множества — нужно представить множество
связанных объектов путем создания одного кортежа для каждого значе-
ния. При этом сохраняется избыточность, так как значения других атри-
бутов отношения будут повторяться по одному разу для каждого элемента
множества Проблема избыточности рассматривается в разделе 3.7, а пока
что мы допускаем наличие этого дефекта.
Пример 3.7. Пусть пате — ключ для класса star. Тогда отношение, построенное
для класса movie, можно расширить, добавив к нему атрибут, например starName,
в который входит имя одной из кинозвезд, занятой в каждом фильме. В результате
фильм будет представлен столькими кортежами, сколько в нем занято кинозвезд,
внесенных в БД Пример такого отношения показан на рис. 3.13. Заметим, что ему
присуща избыточность: вся прочая информация о каждом фильме повторяется по
одному разу для каждой занятой в нем кинозвезды. □
.дае .. year length filmType studioName starName
Star Wars 1977 124 color Fox Carrie Fisher
Star Wars 1977 124 color Fox Mark Hamill
Star Wars 1977 124 color Fox Harrison Ford
Mighty Ducks 1991 104 color Disney Emlio Estevez
Wayne's World 1992 95 color Paramount Dana Carvey
Wayne’s World 1992 95 color Paramount Mike Meyers
Рис. 3.13. Отношение Movie, содержащее информацию о кинозвездах
Иногда класс имеет несколько многозначных связей с другими классами. В та
ком случае число кортежей, необходимых для представления единственного объекта
класса, резко возрастает. Пусть Л,, /?2,. .. — многозначные связи класса С. Тогда
отношение для С имеет атрибуты, соответствующие всем атрибутам С, атрибуты,
соответствующие ключам всех однозначных связей класса С, И атрибуты, представ-
ляющие ключи целевых классов для Я,, Я2, ..., Яц..
Пусть отдельный объект о класса С соединен с и, объектами связью /?,, с
п} объектами связью R2, и т.д. Тогда для каждого выбора объекта для Я(, объекта
для Я2 итд строится кортеж, соответствующи! объекту о. В результате получается
л, х п2 х... х кортежей для объекта в отношении, построенном для класса С.
Пример 3 8. Допустим, что класс С имеет множество однозначных атрибутов X
и две многозначные связи Л, и Я2 с классами, ключевыми атрибутами которых
являются множества У и 2 соответственно. Рассмотрим объект с класса С, соеди-
ненный связью с объектами обладающими ключами у( и у2, и связью Я2
с объектами, обладающими ключами Z|, ’2 и z3. Пусть также х представляет значе-
ния объекта с в множестве атрибутов л.
SO Глава 3 Реляционные модели данных
Тогда в отношени i, построенном из класса С, объект с представляется шестью
кортежами
(л, I’r-z,) Ст.у,,;,) Ct,у„ ",)
(-V. V,. Z, J (X.l'j, Z,) (х.у2. ?3)
Другими словами, ключи из ¥ комбинируются с ключами из Z всеми возможными
способами □
3.2.6 Отсутствие ключей
В объектно-ориентированной модели ODL значения всех атрибутов двух
объектов одного класса могут полностью совпадать. Поэтому нужно быть готовым
к такой проблеме, как, например, наличие двух кинозвезд с одинаковыми именами.
В таком случае имя не является ключом для класса Star и его нельзя использовать
дня представления кинозвезд в кортежах отношения Movie. Для получения ключа
можно попытаться добавить новые атрибуты кинозвезды, но, сколько бы новых
атрибутов кинозвезды ни вносилось в БД, нет никакой гарантии, что когда-нибудь
не появятся две кинозвезды с одним м тем же именем, одной и той же датой
рождения, одним и тем же адресом и т,д.
Единственное решение проблемы — ввести новый атрибут, представляющий
идентификатор объекта для отдельного объекта класса, соответствующего конкрет-
ному отношению Например, если нет уверенности в том, что пате —ключ для
кинозвезд, можно ввести номер сертификата для каждой кинозвезды, обозначаю-
щий ее членство в гильдии актеров Такие номера уникальны - за этим следит
центральное руководство гильдии.
Пример 3.9. Если каждой звезде присваивается номер сертификата, который
используется как ключ для представления кинозвезды в отношениях, тогда отноше-
ние Movie выглядит следующим образом:
title year length » | filmType studioName I cert#
Star Wars I 1977 124 [ color Fox 12345
В нем только один кортеж, а 12345 — номер сертификата Кэрри Фишер. Отношение
Star в этом случае содержит такой атрибут, как номер сертификата, и всю осталь-
ную информацию, включенную в определение ODL класса Star. Например:
cert# , name | street 1 city j starredln
12345 i Ca ie Fisher i 123 Maple St. Hollywood j Star Wars
Это схема отношения и один из множества кортежей для Кэрри Фишер. □
3.2- 7 Представление связи и ее обращения
В принципе, при прямом переводе из ODL в реляционную модель каждая
связь переводится дважды, по одному разу в обоих направлениях. Так в примере 3.7
каждая кинозвезда фильма включена и кортеж, сопержаший название этого фильма.
При проектировании отношения для класса Star связь starredln была бы представ-
лено путем создания для каждой кинозвезды стольких кортежей, в скольких филь-
мах она играла с названием и голом выпуска каждого фильма в одном из этих
кортежей (всп»мн-гге. что вместе title п year составляют ключ для фильмов).
3.2 Переход от проектов ODL к реляционным проектам
81
Однако представления связи stars и ее обращения вместе избыточны, так как
каждое из них выражает одну и ту же информацию. Поэтому можно, например,
вообще убрать информацию starredln из отношения Star или же оставить ее но
удалить атрибут starName из отношения Movie. В разделе 3.3.2 будет изложен
третий возможный подход, при котором связь и ее обращение выделяются в виде
новых отношений. Иногда, хотя и не всегда, именно такой подход предпочтитель-
нее. Впрочем, при выборе такого подхода процесс "нормализации", обсуждаемый
в разделе 3.7, иногда вынуждает разделять связь на два новых отношения, даже
если такого разделения не было в исходном реляционном проекте
Заметим, что в модели ODL необходимы и связь, и ее обращение, так как они
содержат указатели от фильмов на занятых в них кинозвездах и от кинозвезд на
фильмы, в которых они играют. Невозможно следовать указателю "обратно", поэто
му нужны указатели в обоих направлениях3. Но в реляционной модели типа
E/R-модели связи представляются с помощью соединения значений (ключей). Для
отслеживания связей в обоих направлениях можно использовать кортежи с парами
связанных ключей, например с названием и годом выпуска фильма и именем
кинозвезды.
Представление связей в одном направлении
Наличие бинарной связи между двумя множествами сущностей предпола-
гает возможность выбирать отношение, в котором эта связь может появиться,
т.е. отношение, построенное для любого из этих множеств. Важно ли, какое
именно из них выбирается? По-видимому, нет, если связь имеет тип "многие-
ко-многим” или один-к-одному". Но в случае связи типа “многие-к-одному"
мы рекомендуем выбирать то, к чему относится слово "многие", т.е. множество
сущностей, многие элементы которого могут быть связаны с единственной
сущностью другого множества. В результате исключается избыточность.
Например, связь Owns между Movies и Studios лучше поместить в Movies.
Таким образом отношение для Movies получает атрибут для имени владеющей I
фильмом студии и каждый кортеж расширяется именем такой студии. Напро- ]
тив, если связь добавляется в Studios, кортеж для каждой студии необходимо I
расширять до множества кортежей, по одному для каждого фильма, которым |
владеет студия. В результате вся остальная информация о каждой студии будет !
дублироваться для каждого фильма, которым эта студия владеет.
3-2.8 Упражнения к разделу 3-2
Упражнение 3.2.1. Преобразуйте в схемы реляционных БД проекты ODL сле-
дующих упражнений:
*а) упражнения 2.1 !
Ь) упражнения 2.1.2 (включая все четыре модификации,
указанные в этом упражнении),
с) упражнения 2.1.3;
d) упражнения 2.1 4-
*е) упражнения 2.1 5:
О упражнения 2.1.6.
з Конечно нельзя гарантировать, что в конкретной ODL реализации эти указатели будут
представлены именно так, как ожидается; фактически реализация может иметь
единственное представление для пары взаимно обратных связей
82
Глава 3 Реляционные модели данных
Указатели:
полезное средство
или технический недостаток?
< Связи ODL реализуются преимущественно с помощью указателей и ссылок
i от каждого объекта на связанные с ним объекты или объект. Такая реализа-
j ния очень удобна, так как позволяет быстро перейти от объекта к связанным
j с ним объектам. По сравнению с этим способом реляционная модель, пред-
} ставляюшая объекты значением их ключа, а не указателем, требует более
j медленного перехода между связанными объектами.
а Так. в примере 3.7 объект Movie представлен одним кортежем для каждой
1 кинозвезды, играющей в фильме. В таком кортеже отсутствует какая-либо
* информация о кинозвезде, кроме имени. Чтобы найти адреса кинозвезд,
| занятых в фильме Wayne's World, нужно взять имя каждой кинозвезды и найти
1 в отношении Star кортеж или кортежи для искомой кинозвезды — только
I тогда получим адрес.
I Таким образом, возникает впечатление, что отсутствие указателей — это
I технический недостаток реляционной модели На практике же можно создать
J индексы на отношениях, которые позволяют вести эффективный поиск кор-
i тежей, имеющих заданное значение в заданном компоненте (см. разделы 1.2.1
] и 5.7.7). Значит, при отсутствии указателей практические потери невелики.
| Более того, указатели очень полезны в программах, которые действуют
{ в главной памяти и выполняются за считанные секунды, а БД значительно
; отличаются от таких программ. Реализация указателей среди объектов, суще-
ствующих гадами и распределенных по многим устройствам вторичной
памяти, подключенным к широко распределенным компьютерным системам,
1 намного сложнее метода реляционных моделей, не содержащих указателей.
Упражнение 3.2.2. Преобразуйте описание ODL на рис. 2.7 в схему реляци-
онной БД Как повлияет на эту схему каждое из трех изменений из упражне-
ния 2.1.8?
Упражнение 3.2.3. На рис. 3.14 дано определение ODL класса клиентов.
В объектах этого класса хранится множество типов телефонов (домашних, служебных,
факсов) и множество "ссылок", где отмечены заслуги клиента в Пеле вовлечения
в бизнес других клиентов. Преобразуйте это определение в схему реляционной БД.
interface Customer {
attribute Struct Name
{string first, string last) name;
attribute Set <
Struct Phone {stnng type, int number)
> phones;
relat onship Customer referredBy inverse referrals,
relationship Set<Customer> referrals
inverse referredBy;
}.
Рис. 3.14. Записи о клиентах
3 3 Переход от E/R-диаграмм к реляционным проектам 83
3.3 Переход от E/R-диаграмм
к реляционным проектам
Переход от диаграммы сущности-связи к схеме БД аналогичен переходу к ней
от проекта ODL. В принципе, Е/R модель — это переходная форма между объектно-
ориентированным и реляционным проектами. Поэтому, начав с E/R-Диаграммы,
мы имеем проект, в котором уже проделана большая часть работы Между ODL
и E/R-моделями есть три важных различия:
1. В E/R-модели связь является отдельным понятием, а не свойством класса,
что помогает избежать избыточности (см. раздел 3.2 2). которая возникает
при погружении многозначной связи типа stars в кортежи, представляю-
щие объекты Movie.
2. В ODL атрибуты могут иметь любой тип множества, например <Set>.
В E/R-моделн точно не определено, какие именно типы разрешены, но
обычно считается, что допустимы структурированные значения, но не
множества или другие конструкторы типа множества.4 В результате атри-
буты типа множества адресов кинозвезды из примера 3.4 вынуждают рас-
сматривать адрес в E/R-модели как множество сущностей и определять
связь Lives-at между кинозвездами и их адресами.
3. В E/R-модели связи могут иметь атрибуты. В ODL соответствующего
понятия нет.
3.3.1 Переход от множества сущностей
к отношениям
Рассмотрим множество сущностей, не являющееся слабым (модификации, свя-
занные со слабыми множествами сущностей, оставим до раздела 3 3.3) Для каждо
го не слабого множества создадим отношение с таким же именем и с тем же самым
множеством атрибутов. В этом отношении не будет никаких указаний на связи,
в которых участвует данное множество сущностей; мы будем работать со связями
с помощью отдельных отношений, как было показано в разделе 3 3.2.
Пример 3.10. Рассмотрим множества Movies, Stars и Studios, изображенные на
рис. 2 8, который здесь воспроизведен как рис. 3.15. Атрибутами множества Movies
являются title, year, length и filmType, Поэтому отношение Movie имеет точно такой
же вид, как на рис. 3.1, с которого начинается раздел 3.1. □
Рис. 3.15 Е/R диаграмма для БД фильмоо
4 Все же существуют формулировки Е/R модели, использующие в точности те же
ограничения на типы атрибуты, что и ODL. типом может быть множество структур
. или что то более простое.
84
Г лава 3 Реляционные модели данных
Пример 3.11. Теперь рассмотрим множество сущностей Stars на рис. 3.15. В нем
два атрибута, name u address
пате address
Carrie Fisher 123 Maple St., Hollywood
Mark Hamill 456 Oak Rd. Brentwood
Harrison Ford 789 Palm Dr., Beverly Hills
Отношение для данного множества соответствует отношению Star на рис. 3 6 из
примера 3.3, но в последнем три атрибута, два из которых — street и city —пред-
ставляют структурированный адрес. Разница между ними небольшая. Можно было
бы так сконструировать E/R-диаграмму. изображенную на рис. 2.8, чтобы в ней
были атрибуты street и city для множества Stars, и получить точно такое же отноше-
ние Star, как на рис. 3.6. □
3.3-2 Переход от E/R-связей к отношениям
Связи в E/R-модели также можно представить посредством отношений. Отно
шение для конкретной связи Л имеет следующие атрибуты:
J Ключевой атрибут или атрибуты каждого множества сущностей включен
ных в связь /?, являются частью схемы отношения, построенного для Я.
2. Если связь имеет атрибуты, они становятся и атрибутами отношения Л
Если одно множество сущностей вовлечено в связь несколько раз, атрибуты необ-
ходимо переименовать, чтобы избежать дублирования имен. Аналогичным образом
если имя одного и тою же атрибута неоднократно встречается средн атрибутов Л
и вовлеченных в него множеств, имена нужно изменить.
Пример 3.12. Рассмотрим связь Owns на рис. 3.15. Она соединяет множества
сущностей Movies и Studios. Поэтому в схеме отношения Owns используются ключ
для множества Movies т.е. title и year, а также ключ множества Studios — name
Образец этого отношения:
title year studioName
Star Wars 1977 Fox
Mighty Ducks 1991 Disney
Wayne's World 1992 Paramount
Атрибут studioName выбран для ясности, он соответствует атрибуту' name множест-
ва Studios
Заметим, что это отношение, как и отношение из примера 3 10. построенного
для множества сущностей Movies (см. рис. 3.1), содержит точно такую же информа-
цию. что и отношение на рис. 3.12, построенное в примере 3.6 для класса Movie, за
исключением свойства stars. □
Пример 3.13. Связь Stars-ln. показанная на рис. 3.15, тоже можно преобразо-
вать в отношение с атрибутами title, year (ключ множества Movie) и starName (ключ
множества Stars). Па рис. 3.16 показан пример отношения Stars-tn. Заметим, что
это отношение, как и отношение, показанное на рис. 3.1, содержит информацию,
представленную на рис 3.13, но уже без повторов неключевых атрибутов класса
^jar |цщб^гон «jngt^u filmType), ослабляющих схему рис. 3.13.
3.3 Переход от E/R-диаграмм к реляционным проектам
85
title year starName
Star Wars 1977 Carrie Fisher
Star Wars ' 1977 Mark Hamill
Star Wars 1977 Harrison Ford
Mighty Ducks 1991 ! Emilio Estevez
Wayne's World 1992 Dana Carvey
Wayne’s World 1992 Mike Meyers
Рио. 3.16. Отношение для связи Stars-ln
Кажется, что в отношении на рис. 3.16 год является излишним. Однако такое
ппечаттение создается лишь потому, что названия фильмов уникальны. Для
нескольких фильмов с одинаковым названием, например Кинг Конг", год,
несомненно, необходим, чтобы выяснить, какие кинозвезды участвуют и каждой
версии фильма. О
Преимущества перехода к схеме БД от Е/R моделей по сравнению с ODL-про-
ектом заключаются в следующем.
• Отношения часто можно "нормализовать", избегая избыточности, присутст-
вующей в проекте, полученном непосредственно из описания ODL.
• Двухсторонние связи ODL заменяются единственным отношением, пред-
ставляющим связи в обоих направлениях.
Пример 3.14. Многосторонние связи тоже легко конвертируются в отношение
Рассмотрим введенную на рис. 2.12 и воспроизведенную здесь на рис. 3.17 четырех-
стороннюю связь Contracts между кинозвездой, фильмом и двумя студиями. Одна
студия имеет контракт с кинозвездой, а другая нанимает эту кинозвезду для
участия в своем фильме Такую связь легко представить с помощью отношения
Contracts, схема которого состоит из атрибутов, входящих в ключи четырех
множеств сущностей:
I Ключ starName для кинозвезды.
2. Ключ для фильма, состоящий из атрибутов title и year
3 Ключ studioOfStar обозначающий название первой студии (предполагается,
что название студии — это ключ множества сущностей Studio).
4. Ключ producingStudio, обозначающий название второй студии выпускаю-
щей фильм с участием кинозвезды.
Рис. 3.17. Четырехсторонняя связь Contracts
86
Глава 3 Реляционные модели денных
Кстати, при выборе имен атрибутов для схемы отношения мы проявили изоб-
ретательность. избегая "имени'' для любою атрибута, так как в противном случае
было бы неясно, относится это имя к кинозвезде или к студии, а если к студии, то
к какой именно. □
Еще раз о переходе от ODL к отношениям
»
Перевод связей E/R-модели в отношения иногда дает более подходящую j
схему реляционной БД, чем перевод связей CDL. Но ведь ничто не мешает .
применить E/R-методы представления связи типа "многие-к-од| ому' или ।
"многие-ко-многим" в качестве отдельного отношения Это позволяет избе |
' жать избыточности и резкого увеличения числа кортежей, с которыми прнхо j
। днтся иногда сталкиваться при попытке реализации многосторонней связи
• ODL с классом, для которого она определена Однако еще раз напоминаем j
I читателю, что в разделе 3.7 показан механический способ исправления реля- i
• ционных схем, полученных прямо из ODL. I
З-З-З Работа со слабыми множествами
сущностей
При наличии в Е/R диаграмме слабого множества сущностей необходимы
следующие условия.
I. Отношение для слабого множества сущностей И-7 должно включать в себя
не только атрибуты И7, но и ключевые атрибуты других множеств, участ-
вующих в формировании ключа для И7. Такие вспомогательные множест-
ва легко распознать, так как они достижимы из И7 с помощью связи типа
"многие-к-одному', обозначаемой двойным ромбом
2. Связи, в которых появляется слабое множество сущностей И7 должны
использовать в ключе для И7 все ключевые атрибуты W и ключевые
атрибуты других множеств, участвующих в формировании ключа для И7.
3. Однако обозначенные двойным ромбом связи слабого множества W с
другими множествами, участвуют imh в создании ключа для И7 вообще
нс нужно конвертировать в отношение. Дело в том, что атрибуты этих
связей всегда будут подмножествами атрибутов самого множества И7;
значит, такие связи не несут никакой дополнительной информации,
кроме факта, что они помогают найти ключ для Н7
Разумеется, вводя дополнительные атрибуты при построении ключа для слабою
множества сущностей, нельзя допускать повторного применения одного и того же
имени При необходимости следует переименовать некоторые или все используемые
атрибуты
Пример 3.15. Рассмотрим слабое множество сущностей Crews, изображенное
на рис. 2.27, а здесь показанное на рис. 3.18.
Рис. 3.18. Пример съемочных групп кок слобого множества сущностей
3.3 Переход от E/R-диаграмм к реляционным проектам
87
Из этой диаграммы получаются три отношения со схемами:
Studios(name, addr)
Crews(number studioName)
Unit-of(number, studioName, name)
Первое отношение, Studios, строится прямо из множества сущностей с тем же
именем второе. Crews, получается из слабого множества сущностей Crews. Атрибуты
этого отношения — это ключевые атрибуты множества Crew.v; если бы у Crews были
неключевые атрибуты они тоже были бы введены в схему отношения. Здесь
studioName указывается в качестве атрибута отношения Crews, сооггетствуюшего
атрибуту' name в множестве сущностей Studios.
Третье отношение. Unit of, получается из связи с тем же именем. Как всегда,
E/R-связи представляются в реляционной модели с помощью отношения, схема
которого содержит ключевые атрибуты связанных множеств сущностей В данном
случае Unt-of имеет атрибуты number, studioName (ключ для слабого множества
сущностей СУени) и name (ключ для множества Studios). Поскольку Utut-o — это
связь типа "многие-к-одному1, studioName для любой студии совпадает со значением
ее атрибута name.
Пусть, например, Disney crew #3 — одна из съемочных групп студии Disney.
Тогда множество связей для Unit-o включает в себя пару
(Disney crew#3, Disney),
из которой получается кортеж
(3, Disney, Disney).
В результате, смешав" атрибуты studioName и name для Unit-of, получим более
простую схему:
Umt-of(number, name).
Но тогда можно обойтись вообще без отношения Unit-of, так как его атрибуты
являются подмножеством атрибутов отношения Crews □
Пример 3.16. Рассмотрим слабое множество сущностей Contracts из примера 2.31
и рис. 2.28 в разделе 2.6.1. Диаграмма из этого примера воспроизведена на рис. 3.19.
88
Глава 3 Реляционные модели данных
Схема отношения для множества Contracts
Contracts(starName, studioName. title, year, salary)
Атрибутами мссь являются соответствующим образом переименованные ключи для
множеств Start н Studios, два атрибута из ключа для Movies и атрибут salary, лринад
лежаший множеству Contracts. Отношения для связей Star of, Siudio-of и Movie ofне
построены. Каждое из этих отношений имело бы схему, являющуюся собственным
подмножеством приведенной выше схемы для Contracts
Заметим, что полученное отношение является точно таким же, какое можно
было бы получить из E/R-диаграммы. показанной на рис. 2 13. На ней контракт
трактуется как трехместная связь между кинозвездами, фильмами и студиями
с атрибутом гонорара, приписанного множеству Contracts. □
То что мы наблюдали на примерах 3.15 и 3.16 (для связи в двойном ромбе
отношение не требуется), универсально для слабых множеств сущностей. Схема
отношения для слабого множества сущностей Е включает в себя схему отношения,
построенного из любой заключенной в двойной ромб связи Л типа "многие-к-
одному", соединяющей Ес одним из множеств, помогающих составить ключ для Е.
Дело в том что отношение для Е содержит ключевые атрибуты для Е, которые
объединяют все ключевые атрибуты двух множеств, связанных посредством /?.
Поэтому для слабых множеств сущностей верны следующие правила:
• Если £— слабое множество сущностей, для него нужно строить отношение,
схема которого состоит нз всех ключевых атрибутов для Е, в том числе атри-
бутов являющихся ключами "вспомогательных'' множеств, соединенных с £
связью типа "многие-к-одному"
• Не нужно строить 01ношение для тюбой связи типа "многие-к-одному"
между слабым множеством сущностей и другим множеством сущностей при
условии, что данная связь заключена в двойной ромб и помогает сформиро-
вать ключ для слабого множества сущностей.
3-3-4 Упражнения к разделу 3-3
Упражнение 3.3.1. Преобразуйте E/R-диаграмму, представленную на рис. 3.20,
в реляиконную БД
3 дис^^^^О О ?-Л
3.4 Преобразование структур подклассов в отношения
89
Рис. 3 21. б/П-диагромлло, относящаяся к кораблям-близнецам
Упражнение 3 3.2. E/R-диаграмма на рис. 3.21 относится к кораблям. Если
корабли построены по одному проекту, они называются "близнецами". Преобразуйте
эту диаграмму в схему реляционной БД.
Упражнение 3 3.3. Преобразуйте в схемы реляционной БД следующие
E/R-диаграммы:
а) диаграмму на рис. 2.28’
Ь) результат выполнения упражнения 2.6.1;
с) результат выполнения упражнения 2.6.4(a);
d) результат выполнения упражнения 2.6.4(b).
3-4 Преобразование структур подклассов
в отношения
Понятие подкласса в объектно-ориентированных и E/R-моделях трактуется не
одинаково. Напомним, в чем разница.
• В ODL объект принадлежит только одному классу и наследует свойства всех
своих надклассов, но технически не является их членом.
• В Е/R модели "объект" может быть представлен сущностями принадлежаши
ми нескольким множествам, находящимся в связи isa. Таким образом, связан-
ные сущности формируют объект и придают ему свойства: атрибуты и связи.
Именно поэтому применяются различные методы построения отношений, пред-
ставляющих иерархию классов. Рассмотрим две различные точки зрения, определя-
ющие разные стратегии разработки схемы реляционной БД. Следует учесть, что ни
ODL. ни E/R-модели сами по себе не вынуждают применять тот или иной подход;
по желанию можно выбрать методику, предназначенную для другой модели.
3-4-1 Реляционное представление
подклассов ODL
Рассмотрим сначала технику перевода иерархии подклассов ODL в реляцион-
ные схемы в соответствии со следующими принципами
• Каждый подкласс имеет собственное отношение.
• В этом отношении представлены все свойства данного подкласса, включая
все свойства, которые он наследует.
90
Глава 3 Реляционные модели данных
Пример 3.17. Рассмотрим иерархию (см. рис. 2.22), содержащую четыре класса:
I. Movie —самый широкий класс, фигурирующий во многих примерах этой
главы.
2. Cartoon — подкласс класса Movie с дополнительным свойством. а именно
СВЯЗЬЮ, являющейся множеством кинозвезд под названием voices.
3. MurderMystery — второй подкласс класса Movie с дополнительным атрибу-
том weapon.
4. Cartoon-MurderMystery — подкласс классов Cartoon и MurderMystery, не
имеющий дополнительных подклассов, но (естественно) обладающий
всеми свойствами трех своих надклассов.
Схема для Movie прежняя:
Movie(title, year, length filmType studioName starName).
Некоторые типичные кортежи уже были показаны нв рис. 3 13. Для Cartoon к шести
атрибутам схемы Movie добавляется voice. В результате получается схема с семью
атрибутами:
Cartoonftitle, year, length, filmType, studioName, starName. voice).
Для MurderMystery получается другое отношение — с шестью атрибутами Movie плюс
weapon Схема этого отношения:
MurderMystery(title, year, length filmType, studioName, starName, weapon)
И наконец, схема отношения Cartoon-MurderMystery содержит шесть атрибутов Movie
и атрибуты voice и weapon из других надклассов:
Cartoon-MurderMystery(title, year, length, filmType, studioName,
starName, voice, weapon). □
3.4-2 Представление isa в реляционной модели
Философия иерархий isa в E/R-модели заключается в том, что эти иерархии
наполнены сущностями, находящимися в связи isa. Значит, вполне естественно
создавать отношение для каждого множества сущностей и придавать ему атрибуты
только этого множества. Но для идентификации сущностей, связанных с каждым
кортежем, необходимо ввести в отношение и ключевые атрибуты каждого множества
сущностей. В результате информация для члена некоторого подкласса рассеивается
по множеству отношений, что по-видимому, неизбежно, так как преобразование
E/R-модели в реляционную расщепляет информацию о E/R-атрибутах и связях на
отдельные отношения.
Отношение для связи isa не создается, скорее, сама эта связь заключается в том
что связанные сущности имеют одни и те же ключевые значения.
Пример 3.18. Выразим иерархию, показанную на рис. 2.22, в E/R-модели. На
поминаем, что релевантная часть E/R-диаграммы была показана на рис. 2.23, кото-
рый воспроизводится здесь как 3.22.
Реляционные схемы, необходимые для представления этой части диаграммы.
I Отношение Movies(title. year length filmType). Оно рассматривалось в при-
мере 3 10
2 Отношение MurderMystenes(title, year, weapon). Первые два атрибута —
ключи для всего множества фильмов а третий атрибут относится к соот
петствующем) множеству сущностей
3.4 Преобразование структур подклассов в отношения
91
3. Отношение Cartoons(titie, year) — множество мультфильмов, у которого
нет других атрибутов, кроме ключа для множества фильмов, так как
дополнительная информация о фильмах содержится в связи Voices.
4. Отношение Vo’ces(title, year, name) соответствует связи Voices между Stars
и Cartoons. Последний атрибут данного отношения — это ключ для Stars,
а первые два — клю1 для Cartoons.
Заметим, что на рис. 3.22 нет множества сущностей, соответствующего классу
Cartoons-MurderMystery. Поэтому, в отличие от реляционной модели из приме-
ра 3.17, здесь нет и специального отношения для фильмов, которые являются одно-
временно мультфильмами и детективами. Голоса для них берутся из отношения
Voices, оружие — из отношения MurderMysteries, а вся другая информация — из
отношения Movies или из отношения, построенного для одной из связей между
множествами Movies, Cartoons и MurderMysteries.
Схема отношения Cartoons является подмножеством схемы отношения Voices.
Во многих ситуациях отношение Cartoons можно ликвидировать, так как оказыва-
ется, что оно содержит только ту информацию, которая уже есть в Voices. Однако
в базе данных могут быть “немые" мультфильмы. В них нет голосов, поэтому утра-
чивается информация о том, что они являются мультфильмами. Фактически та же
проблема возникает в отношении Cartoons из примера 3.17, где при отсутствии
голосов нет и упоминания о мультфильме. Она решается с помощью нормализации
(см. раздел 3.7). □
3-4-3 Сравнение различных подходов
С каждым из подходов рассмотренных в двух предыдущих разделах, связаны
свои специфические проблемы. При переводе ODL в реляционные модели все
свойства объекта сохраняются в одном отношении, но при этом поиск объекта
|риходится вести в множестве отношений. Например, для определения длины
фильма с помощью схемы БД из примера 3.17. пришлось проверить четыре разных
отношения, пока не нашлось отношение для класса, в который этот фильм входит.
При переводе E/R-диаграмм в реляционные модели ключ объекта повторяется
по одному разу для каждого множества сущностей или связи, к которым этот
объект (сущность) принадлежит. Такие повторы требуют дополнительного про-
странства. Кроме того, для получения информации об одном объекте может потре
боваться просмотр множества отношений. Такая ситуация возникает, например,
при определении длины детектива и применяемого в нем оружия с помощью схе-
мы БД из примера 3.18.
92
Глава 3 Реляционные модели данных
3.4.4 Применение пустых значений
для комбинирования отношений
Есть еще один метод представления информации об иерархии классов. Можно
использовать особое пустое значение, обозначаемое NULL. Неформально говоря,
если NULL — это компонент кортежа для какого-то атрибута, значит, дня этого
атрибута в данном кортеже нет подходящего значения. Хотя пустые значения и не
являются частью традиционной реляционной модели, фактически они очень полез
ны и играют важную роль в языке запросов SQL (см. раздел 5.9).
Используя NULL в качестве значения в кортежах, с иерархией классов можно
работать, лишь применяя единственное отношение, имеющее атрибуты для всех
свойств, которыми обладают объекты любого класса данной иерархии. Объект
представляется с помощью единственного кортежа, имеющего NULL в каждом
атрибуте, соответствующем свойству, которое не принадлежит классу этого объекта.
Пример 3.19. Применяя такой метод при решении проблемы из примера 3.17,
можно построить единственное отношение по схеме.
Movie(title, year, length, filmType, studioName. starName voice, weapon)
В такой модели фильм "Кто ложно обвинил кролика Роджера?", являющийся
мультипликационным детективом, представлен несколькими кортежами без NULL;
каждому "голосу” соответствует один кортеж.5 "Русалочка мультфильм, но не
детектив — имеет значение NULL в компоненте weapon, детектив "Убийство
в восточном экспрессе" — в атрибуте voice, а мелодрама "Унесенные ветром"— в ат-
рибутах voice и weapon □
Заметим, что такой подход, как и метод из раздела 3 4 2, позволяет найти
п одном отношении кортежи из всех классов данной иерархии Кроме того, он,
как и метод из раздела 3.4.1, позволяет получить всю информацию об объекте из
одного отношения.
3 4-5 Упражнения к разделу 3-4
Упражнение 3.4.1. Конвертируйте представленную на рис. 3.23 E/R-диаграмму
в схему реляционной БД
Рис 3 23 С/В-диогроммо
5 Фильм "Кролик Роджер‘\ в котором участвуют и кинозвезды, и озвученные
мультипликационные персонажи имел бы кортежи для каждой пары кинозвезда —
голос. В обычном мультфильме NULL требуется в атрибуте starName для того, чтобы
записать информацию о звучащих в нем голосах и другие данные.
3.4 Преобразование структур подклассов в отношения 93
Упражнение 3.4.2. На рис. 3.24 дано ODL-описание схемы, аналогичной
E/R-диаграмме из упражнения 3 4.1 Конвертируйте его в схему реляционной БД.
Помните, что объекты Course могут быть однозначно идентифицированы и допус-
кается ввести атрибут, представляющий это свойство, например CourseiD В этом
упражнении не рекомендуется имитировать стратегию, в упражнении 3.4.1 примени
емую для конвертирования слабого множества сущностей (хотя, в принципе это
можно сделать).
interface Course {
attribute mt number;
attribute stnng room'
relationship DeptdeptOf inverse Dept::coursesOf;
};
’nterface LabCourse: Course {
attribute int computerAlloc;
};
interface Dept {
unique attribute stnng name;
attribute string chair;
relationship Set<Course> coursesOf
inverse Course: deptOf;
}:
Рис. 3.24. ODl-описание теоретических и лабораторных курсов
Рис. 3.25. Cfi-диаграмма к упражнению 3.4.5
94
Глява 3 Реляционные модели данных
Упражнение 3.4.3 Конвертируйте в схемы реляционных БД ODL проекты:
”а) из упражнения 2.4.1:
Ь) нз упражнения 2.4 4.
Упражнение 3 4 4 Конвертируйте в схемы реляционных БД Е/R проекты;
“‘а) из упражнения 2.4.3
Ь) из упражнения 2.4.4.
! Упражнение 3.4.5 Конвертируйте показанную на рис. 3 25 E/R-диаграмму в
схему реляционной БД
! Упражнение 3.4 6. Как будет выглядеть схема реляционной БД из упражне-
ния 3.4.5, если начать ес построение с соответствующего определения ODL’
3.5 Функциональные зависимости
Самый важный вид ограничений, применяемых в реляционной модели, огра-
ничение по уникальности значений, называемое функциональной зависимостью.
Знать такое ограничение просто необходимо для того, чтобы перерабатывать схемы
БД с целью устранения избыточности (см. раздел 3.7). Существуют и другие огра-
ничения, позволяющие создавать хорошие схемы БД: многозначные зависимости
(см. раздел 3.8), ограничения существования и ограничения независимости (см раз-
дел 4.5).
3.5.1 Определение
функциональной зависимости
Функциональная зависимость на отношении Л —это утверждение вида "Если
два кортежа R совпадают по атрибутам Л„ А,, ...,А„ (т.е эти кортежи имеют в соот-
ветствующих друг другу компонентах одни и тс же значения для каждого из пере-
численных атрибутов), то они должны совпадать и по другому атрибуту Д'
Формально эта зависимость записывается выражением Л, А2.. А„ -> В, причем го-
ворится, что "4|, Аг,....А„ функционально определяют В'.
Рис. 3 26. Эффек функциональной зависимости на двух кор ежах
совпадают здесь совпадают и здесь
3.5 Функциональные зависимости
95
Если множество атрибутов Л,. Л2>Л„ функционально определяют более
одного атрибута, например,
Л, А... 4,-^й,
А А - А„^Вг
Я|Л2.. А„ -> В„,
то данное множество зависимостей можно записать сокращенно-
A А-,... А„ -» £| В2 ... Вт
На рис. 3.26 показана функциональная зависимость между любыми двумя кортежа-
ми г и и отношения В.
Пример 3.20. Рассмотрим отношение Movie из рис. 3 13, экземпляр которого
воспроизведен на рис. 3.27.
title 1 year length filmType studioName starName
Star Wars ! 1977 124 color Fox Carrie Fisher
Star Wars ] 1977 124 color Fox Mark Hamil
Star Wars I 1977 124 color Fox Harrison Ford
Mighty Ducks : 1991 104 color Disney Emilio Estevez
Wayne's World 1992 95 color Paramount Dana Carvey
Wayne's World | 1992 95 color Paramount Mike Meyers
Рис. 3.27. Отношение Movie
В этом отношении можно установить множество функциональных зависимостей,
например:
title year -+ length
title year -> filmType
title year -> studioName
Поскольку левые части этих зависимостей совпадают, их можно записать одной
строкой:
title year -> length filmType studioName
Неформально это множество зависимостей означает: если два кортежа имеют
одно и то же значение в своих компонентах title и одно и то же значение в компо-
нентах year, то они должны иметь одинаковые значения в компонентах length, оди-
наковые значения в компонентах filmType и одинаковые значения в компонентах
studioName. Такое утверждение имеет смысл, если вспомнить исходный проект, из
которого была построена реляционная схема Movie Атрибуты title и year образуют
ключ для объектов из множества фильмов. Поэтому при наличии названия и года
выпуска фильма, существуют также его уникальная длина, уникальный тип и един-
ственная владеющая им студия.
В то же время утверждение
title year -> starName
96
Глава 3 Реляционные модели данных
ложно. Оно не является функциональной зависимостью, так как, согласно опреде-
лению класса Movie, верно только то, что для каждого фильма уникальным образом
определено множество кинозвезд. При конвертировании ODL в реляционную
модель необходимо было создать кортеж для каждого фильма и в каждый кортеж
ВХОДИЛИ разные кинозвезды. Поэтому кортежи не совпадают по имени кинозвезды,
даже если все они совпадают по другим свойствам класса Movie □
И J
Функциональные зависимости
относятся к схемам
i s
Помните, что функциональная зависимость подобно любому ограииче
г нию, является утверждением о схеме отношения а не об отдельном ее экзем- ;
плнре По отдельному экземпляру нельзя определить, верна ли для него 5
5 функциональная зависимость Например, глядя на рис 3 27. можно предполо-
< жить, что есть зависимость типа title -> filmType, так как для каждого кортежа ;
i п этом экземпляре отношения верно, что любые два кортежа, совпадающие по {
< title, совпадают и ио filmType j
г Однако нельзя утверждать, что эта функциональная зависимость верна ’
• для отношения Movie. Например, если его экземпляр содержит кортежи для j
двух версий "Кинг Кинга — цветной и черно белой, данной функциональной ;
5 зависимости нет.
. ____ г- — - - -- — ——
3.5-2 Ключи для отношений
Множество атрибутов А.....А„} является ключом для отношения К, если:
1. Эти атрибуты функционально определяют все остальные атрибуты данного
отношения, т.е зва различных кортежа R не могут совпадать по всем
атрибутам А. А.....>1,,.
2. Ни одно собственное подмножество множества (At Аг.А„\ функцио-
нально не определяет все остальные атрибуты Л, т.е. ключ должен быть
минимальным.
Если ключ состоит из единственного атрибута А, часто говорят, что А (а ие {А)
есть ключ.
Пример 3.21 Атрибуты {title, year starName} формируют ключ для отношения
Movie на рис. 3.27 Во первых, нужно показать что они функционально определяют
все остальные атрибуты. Допустим, два кортежа совпадают по этим трем атрибутам.
Поскольку они совпадают по title и year, они должны совпадать и по остальным ат-
рибутам: length, filmType и studioName (что было показано в примере 3 20) Значит
два разных кортежа не могут совпадать по title, year и starName, так как в случае
такого совпадения онн фактически были бы одним и тем же кортежем
Теперь нужно доказать, что ни одно собственное подмножество множества
{title, year, starName} функционально не определяет все остальные атрибуты. Дейст-
вительно title и year не определяют starName поскольку во многих фг дымах участ-
вуют несколько кинозвезд. Значит, {title, year} не является ключом.
{year, starName} не является ключом потому, что одна кинозвезда может участ-
вовать в двух фильмах, снятых в одном и том же юлу. Следовательно
year starName -> title
не является функциональной зависимостью Можно также сказать, что {title,
starName} не является ключом потому, что в разные годы могут бьть сняты два
3.5 Функциональные зависимости
97
ф тьма с одних и тем же названием. Возможно даже, что в этих фильмах участво-
вала одна и та же кинозвезда.6 □
Иногда отношение имеет несколько ключей. В таком случае один из них
считается первичным ключом. В коммерческих системах БД выбор первичного клю-
ча может повлиять на вопросы реализации, например на способ хранения данного
отношения на диске.
> "Функциональное"
в функциональных зависимостях
Л| А... /1„ —> В называется функциональной" зависимостью, потому что, !
в принципе, ото функция, которая из списка значений, содержащего по одно- j
’ му значению для каждого из атрибутов Лг, Л2,.... А„, порождает уникальное j
значение для В (или не порождает никакого) Например, можно представить i
; себе |>у книге в отношении Movie, которая из строки "Star Wars” и числа 1977 •
• порождает уникальное значение для length, а именно, число 124, появляющее- ;
ся в этом же отношении Movie. Но такая зависимость не является обычной j
1 математи зеской функцией, так как ее невозможно вычислить из исходных
|! данных. Другими словами, нельзя получить правильную длину фильма, I
1 вь полнив какие то операции на строках типа “Star Wars' и числах типа 1977. t
? Эта функция вычисляется путем просмотра отношения: мы смотрим на кортеж j
. с заданными ttle и year и видим, какое значение он имеет для length.
3-5-3 Над ключ и
Множество атрибутов, содержащее ключ, называется надкиючам (сокращение
выражения “надмножество ключа"). Значит, каждый ключ — это иадключ, но
некоторые надключи не являются (минимальными) ключами. Заметим, что любой
надключ удовлетворяет первому условию ключа: функционально определяет все
осзальные атрибуты отношения, но не должен удовлетворять второму условию —
минимальности.
Пример 3,22. В отношении из примера 3.21 много надключей. Ими являются
не только ключ
{title, year, starName},
но и любое надмножество этого множества атрибутов, например
{title, year, starName, length} □
3-5-4 Обнаружение ключей для отношений
Когда при конвергировании DDL и ш E/R-проекта в отношение строится ре-
визионная схема, обычно можно заранее сказать, каким будет ключ этого отноше-
ния. В данном разделе рассматриваются отношения, полученные из E/R-диаграмм,
а в следующем — из ODL-проектов.
6 Помните, что функциональные заш с i.mocth — это допущения или утверждения,
ка аюшиеея данных. Не существует внешнего авторитета, способного выносить
окот । 1 .ное решение по поводу наличия или отсутствия функциональной
зав ют ноет Поэтому в нашей поле при шмать любые разумные решения о том,
какая функциональная заинсчмость верна
98
Глава 3 Реляционные модели данных
Когда отношения строятся из ODL или E/R-проекта, в большинстве случаев
(хотя и нс всегда) для каждого отношения существует единственный ключ. Если
отношение имеет единствен! ый ключ, при составлении его схемы полезно подчер-
кивать атрибуты, которые этот ключ формируют
.. — -= |
Другая терминология, относящаяся к ключам j
’ В некоторых книгах и статьях ключи описываются в другой термнноло- [
} гии. Иногда термином "ключ" обозначается то, что мы называем "надключом". (
й т.е множество атрибутов, функционально определяющее все атрибуты без j
ч учета требования минимальности. В этих работах для минимального ключа i
; (который мы обозначаем термином "ключ"} обычно используется термин 5
j “потенциальный ключ" ("candidate key"). ’
Первое правило введения ключей:
• Если отношение происходит из множества сущностей, ключом этого отно-
шения являются ключевые атрибуты данного множества или класса.
Пример 3.23 В примерах 3.10 и 3 11 показано, как множества сущностей
Movies и Stars конвертируются в отношения Ключами этих множеств являются
{title, year] и {пате} соответственно. Значит, они являются также ключами соот-
ветствующих отношений, имеющих следующие схемы:
Movies(title, year, length, filmType)
Starsfname, eddress)
в которых ключи подчеркнуты. □
Второе правило относится к бинарным связям Если отношение Л стооится из
связи, ее сложность влияет на ключ для R. Имеется три случая:
• При связи типа "многие ко-многим‘ ключи обоих связанных множеств явля-
ются ключевыми атрибутами для R.
• Если есть связь типа "многие к-одному" множества £, с множеством £>,
ключевыми атрибутами R являются ключевые атрибуты £,. но не £2.
• При связи типа "один-к-одному" ключи любого из связанных множеств
являются ключевыми атрибутами для R. Поэтому для R не существует
уникального ключи.
Пример 3 24 В примере 3.12 обсуждалась связь Owns типа "многие-к-одному"
между множествами Movies и Studios. Из него ясно, что ключ для отношения Owns —
это ключевые атрибуты title и уеег, взятые из ключа для Movies. Схема для Owns
с подчеркнутыми атрибутами имеет вид-
Owns(title, year, studioname)
В примере 3 13 рассматривалась связь Stors-in типа "многие-ко-многим" между
множествами Movies и Stars В этом случае все атрибуты результирующего отношения
Stars-m(title, year gtarName)
3.5 Функциональные зависимости 99
являются ключевыми. Фактически, все атрибуты отношения, полученного из связи
типа "многие-ко-многим", могут не быть частью ключа только тогда, когда сама
сходная связь имеет атрибут В таком случае атрибуты отношения удаляются из
ключа. □
И наконец, рассмотрим многосторонние связи. Поскольку стрелками, выходя-
щими из связи, все возможные зависимости показать не удается, возникают ситуа-
ции, в которых ключи не очевидны и приходится детально анализировать, какие
именно множества сущностей функционально определяют другие множества
Однако одно правило все же есть:
• Если многосторонняя связь Л содержит стрелку, направленную на множество
сущностей Е, для соответствующего этой связи отношения имеется по край-
ней мере один ключ, который не содержит Е.
Другие понятия функциональной зависимости
' 5
! Мы считаем, что в левой части функциональной зависимости может быть !
, множество атрибутов, а в правой только один. Более того, атрибут, стоящий
ij справа, не может появиться в левой части. Однако для краткости допускается ’
комбинировать несколько зависимостей с одинаковыми левыми частями, что-
". бы получить множество атрибутов справа. Иногда полезна также ''тривиальная1' I
' зависимость, в правой части которой стоит один из атрибутов, находящихся J
слева. ‘
В других работах на э-rv тему часто принимается точка зрения, согласно
! которой левая и правая части зависимости являются произвольными множе-
ствами атрибутов и атрибуты могут находиться одновременно слева и справа
Между этими двумя подходами нет существенных различий, но мы будем
исходить из того что ни один атрибут не входит одновременно в правую
и левую части функциональной зависимости, если явно не оговорено проти-
воположное.
3.5-5 Ключи для отношений,
выведенных из ODL
Преобразовывать ODL-проекты в отношения несколько сложнее. Для класса
ODL может быть декларировано несколько ключей, но среди атрибутов может не
быть ни одного ключа. В таком случае в отношение необходимо ввести атрибут,
являющийся суррогатом объектного идентификатора для объектов данного класса
(см. раздел 3.2.6)
Однако независимо от того, имеет ли класс ODL ключ, сформированный из
его собственных атрибутов, или приходится использовать суррогатный идентифика-
тор объектов, существ}ют обстоятельства, при которых ключевые атрибуты класса
не являются ключом для отношения Такая Проблема возникает, когда отношения
являются частью определения класса.
Пусть класс С имеет однозначную связь R с некоторым классом £>. Тогда, как
предлагалось в разделе 3.2.4, ключ для D вводится в отношение для С. При этом
ключ для С остается ключом для соответствующего отношения.
100
Глава 3 Реляционные модели данных
Проблема возникает, когда С имеет многозначную связь R с классом D. Если обра-
щение Л однозначно в обратном направлении (т.е. Л—связь типа "один-ко-многим ),
тогда, как говорилось в выделенном рамкой тексте “Представление связей в одном
направлении" раздела 3.2.7, (обращение) R можно представить только в отношении
для D. Обращение R не представляет для Z) никакой проблемы, ТЭК как в D оно
однозначно.
Предположим, однако, что Л —связь типа "многие-ко-многим”, т.е. она сама
и ее обращение многозначны в С и D. Тогда построенное для С отношение может
иметь множество кортежей, описывающих один объект класса С В результате ключ
для С не будет ключом для соответствующего отношения; для создания такого
ключа придется добавлять ключ для D к ключу для С.
Пример 3.25. В примере 3.7 при построении отношения для ODL-класса Movie
к атрибутам Movie были добавлены:
1 Ключ studioName для класса Studio, с которым класс Movie соединен
однозначной связью ownedBy.
2 . Ключ starName для класса Star (с которым класс Movie соединен
многозначной связью stars).
Первый из них образуется из однозначной связи и не влияет на ключ для Movie,
а второй — из многозначной связи и должен быть добавлен к ключу для Movie.
В результате получается
(title, year, starName}
Анализ экземпляра отношения Movie на рис. 3.13 показывает, что title и year не явля-
ются ключами, но для получения ключа к ним достаточно добавить starName. □
В обшем случае, если отношение, построенное для С, представляет многознач-
ные связи С. то ключи для всех классов, с которыми С соединено этими связями,
необходимо добавить к ключу для С. В результате получается ключ для отношения,
представляющего С. Разумеется, если множество связей соединяет С с классом D,
то для каждой такой связи С имеет различные атрибуты, выражающие ключ для D
11 ара доке заключается в том, что ключ для ODL-класса может не подходить
в качестве ключа для соответствующего отношения. Если следовать инструкции
построения отношения, данной в разделе 3 2, часто приходится исправлять отно-
шения, построенные этим простым методом. Исправление таких oti ошений анали-
зируется в разделе 3 7. Здесь же мы рассмотрим, как можно расщепить связи типа
“многие-ко-многим" из отношения, построенного для любого из связанных классов.
Результирующее множество схем отношений больше похоже на то, что получается
прямо из множества E/R-дпа грамм7
? Конечно можно сначала преобразовать ODL-проекты п E/R-диаграммы. а затем
а реляционные модели. Хотя такой подход позволяет обойти некоторые проблемы,
снизанные с прямым методом, рассмотренным а разделе 3.2. существа дела
это_не меняет. Техника реляционных моделей из раздела 3.7, которую нее равно
гВМВ]Н ие^ц^|. не _
3.6 Правила функциональной зависимости
101
3.5.6 Упражнения к разделу 3-5
Упрожнение 3 5.1. Рассмотрим отношение, касающееся жителей США и
включающее в себя их имена, номера страховых полисов, адресные данные (улицу
город, штат, почтовый код, код региона) и семизначные номера телефонов. Какие
функциональные зависимости здесь верны? Что является ключами для этого
отношения? Для ответа на этот вопрос нужно знать, как приписываются номера.
Например, может ли код региона относиться к двум штатам? Может ли почтовый
код относиться к двум кодам региона? Могут ли два человека иметь один и тот же
номер страхового полиса или один и тот же адрес либо номер телефона?
* 9пражнение 3 5 2. Рассмотрим отношение, представляющее положение
молекул в закрытом контейнере в определенный момент. Атрибуты: ID молекулы,
координаты молекулы х, у и г, скорость молекулы в измерениях х, у и г. Какие
функциональные зависимости здесь верны? Что является ключами?
! Упражнение 3 5 3. В упражнении 2.3.2 рассматривались четыре различных
допущения о связи Births. Для каждого случая укажите ключи отношения, постро-
енного из этой связи.
!? Упражнение 3.5.4. Пусть /( — отношение с атрибутами Л|.Л2.А„. В виде
функции от и покажите, сколько надключей имеет Л, если:
*а) единственным ключом является Л,;
Ь) единственными ключами являются Л, и Аг,
с) единственными ключами являются {Л, Л2} и {Л], AJ;
d) единственными ключами являются {Л], Л2} и (Л(, Лз).
3-6 Правила
функциональной зависимости
В этом разделе показано, как логически рассуждать о функциональной за
виснмости. Допустим, нам предъявили множество зависимостей, которым удовлетво
ряет некоторое отношение. Часто из этого делается вывод о том, что данное отно-
шение должно удовлетворять и другим конкретным зависимостям, при этом
неизвестно даже, какие именно кортежи входят в это отношение. Такая способ
ность открывать дополнительные зависимости играет существенную роль при рас-
смотрении проектов хороших схем в разделе 3 7,
Пример 3 26 Если отношение R с атрибутами Л, В и С удовлетворяет функцио-
нальным зависимостям А -> В и В -> С, можно сделать вывод, что R удовлетворяет
также зависимости Л -> С. Как же получается такой вывод? Чтобы доказать А С,
рассмотрим два кортежа из /?, совпадающих по Л. и покажем, что они совпадают
и по С.
Пусть кортежи («, />,, q) и (а Ь2, с>) совпадают по атрибуту Л, а порядок атри-
бутов в кортежах — А, В, С Поскольку R удовлетворяет Л -» В и кортежи совпадают
по Л, они совпадают и по В. Значит Ь} = Ь2 и кортежами действительно являются
(а Ь, с,) и (о, В, <?2) где b есть и bt, и /ь. Поскольку R удовлетворяет В-> С и кортежи
совпадают по В, они совпадают и по С Значит, с, = с2, т.е. кортежи действительно
совпадают по С. Итак, мы доказали, что любые два кортежа В, совпадающие по А,
совпадают и по С. а это и есть функциональная зависимость Л -> С. О
102
Глава 3 Реляционные модели данных
Функциональную зависимость часто можно выразить различными способами
не изменяя множества допустимых экземпляров отношения; в таком см чае гово-
рят, что множества зависимостей эквивалентны. Считается, что множество функци-
ональных зависимостей S следует из х ножества функциональных зависимостей 7’,
если каждый экземпляр отношения, удовлетворяющий всем зависимостям в Г,
удовлетворяет и всем зависимостям в 5. Заметим, что множества зависимостей 5
и Т эквивалентны, если S следует из Г, а Т— из S.
В этом разделе рассмотрим множество полезных правил, касающихся функци-
ональных зависимостей. Эти правила позволяют заменять множество зависимостей
эквивалентным ему множеством или добавлять к множеству зависимостей другие
множества, которые следуют из исходного множества Примером таких правил
является правило транзитивности, позволяющее следовать по цепи функциональ-
ных зависимостей, как в примере 3.26. Введем также алгоритм ответа на общий
вопрос: следует ли функциональная зависимость из одной или нескольких других
зависимостей.
3.6.1 Правило расщепления/соединения
В разделе 3.5.1 функциональная зависимость
Л,А.. А„^В,В2.. В„
был! определена как сокращение множества зависимостей
А । А2 ... Alt —> В [
/1| А2 .. А„ -» В
А А2 ... Аи —> Ви1
Следовательно, можно расщепить атрибуты, стоящие в правой части, так, чтобы
только один атрибут появлялся в правой части каждой функциональной зависимости
Можно также заменить множество зависимостей с общей левой частью единствен
ной зависимостью с той же левой частью и всеми правыми частями, соединенными
в одно множество атрибутов. В любом случае новое множество зависимостей экви-
валентно исходному. Такую эквивалентность можно реализовать двумя способами.
• Функциональную зависимость Л, Аг ...А„-> В{ В2... В„, можно заменить мно-
жеством функциональных зависимостей А,А2.. А„-э В< для /=1.2, .../л.
Такое преобразование называется правилом расщепления.
• Множество функциональных зависимостей А, А}... А„ -» Bi для /= 1, 2,.... т
можно заменить единственной функциональной зависимостью
А А2... А„ -» В} В2... Вт. Такое г рсобразование называется правилом соединения.
Например, в примере 3.20 было показано что множество зависимостей
title year -+ length
title year —> filmType
title year -> studioName
эквивалентно единственной зависимости
title year -> length filmType studioName
3.6 Правила функциональной зависимости
103
Может показаться, что расщепление применимо и к левым частям функцио-
нальных зависимостей. Но следующий пример показывает, что правила расшепле-
иия левых частей не существует.
Пример 3.27. Рассмотрим зависимость
title year -» length
для отношения Movie из примера 3.20. Расщепив его левую часть, получим две
ложные зависимости
title -> length
year -i- length
Другими словами, title функционально не определяет length, так как могут
существовать два фильма различной длины, но с одним и тем же названием
(например, "Кинг Конг'}. Аналогично, year функционально не определяет length, так
как в один год может быть выпушено множество фильмов различной длины □
3-6.2 Тривиальные зависимости
Функциональная зависимость At Л,... А„ -> В называется тривиальной, если В
совпадает с одним из А Например, зависимость
title year -> tit е
тривиальна.
Любая тривиальная зависимость верна на любом отношении, так как она
означает, что "два кортежа, совпадающие по всем атрибутам AltA2, . .,Ап, совпала
ют по одному из них'. Значит, можно допускать любую тривиальную зависимость,
не под!Верждая ее знаниями о данных.
В исходном определении функциональных зависимостей их тривиальность не
допускалась. Однако ничто не мешает использовать тривиальные зависимости, по-
скольку они всегда истинны и иногда упрощают формулировки правил.
Допуская тривиальные зависимости, мы допускаем и зависимости, в которых
отдельные атрибуты находятся и справа, и слева. Зависимость At А2.. Ап -+ В. В2... Д„:
• тривиальна, если {5,, В2.Д„,} является подмножеством множества {Л,, Аг,.... А„};
• нетривиальна, если по крайней мере одно В не входит в множество {Л,, Л2,.... А,,}:
• полностью нетривиальна, если ни одно В, не совпадает ни с одним А,.
Значит,
title year -> year length
нетривиальна, но не является полностью нетривиальной. Удалив year из правой
части, получим полностью нетривиальную зависимость.
Всегда можно удалить из правой части функциональной зависимости атрибуты,
входящие в ее левую часть
• Функциональная зависимость At А-,.. А„ -> В,. В„, эквивалентна
At Аг... А„ -> Q G... Ск, где все С — это такие В, которые не совпадают с А
104
Глава 3 Реляционные модели данных
Это правило, представленное на рис. 3.28. назь вается правшам трнвшиьнай
зависимости.
Если t ин Они должны
совпадают совпадать в В'а
в A s Значит,
они обязательно
совпадают и в C's
Рис. 3 28. Пролило тривиальной зависимости
3.6.3 Вычисление замыкания атрибутов
Прежде чем перейти к другим правилам, рассмотрим общий принцип, из кото-
рого следуют все правила. Пусть (/lt, А2,.А„} есть множество атрибутов, а 5—
множество функциональных зависимостей Замыкание (At, Аг,.... A,,} по зависимо-
стям в 5 есть такое множество атрибутов В, что любое отношение, удовлетворяю-
щее всем зависимостям в 5, удовлетворяет также зависимости Л| /12... А„ -> В.
Значит, At А2 . А„-> В следует из зависимостей 5. Замыкание множества атрибутов
{Л,, А2, -.А,,} обозначается (Л,, А,.., Л„}+ Для того чтобы упростить ход рассуж-
дений о вычислении замыканий, допускаются тривиальные зависимости, поэтому
Л|.Л2...А„ всегда входят в {Л,, А2,А„}+.
На рис. 3.29 изображен процесс вычисления замыкания.
Начиная с заданного множества атрибутов, будем последовательно расширять
его. добавляя правые части функциональных зависимостей тогда, когда вводятся
их левые части. Множество, которое больше расширить уже нельзя, является замы-
канием Следующие шаги описывают алгоритм вычисления замыкания множества
атрибутов {.4|. А->,... А,,} по отношению к множеству функциональных зависимо-
стей.
1 Пусть X — множество атрибутов, которое в конечном счете станет замы
капнем Начнем с того, что X есть {Л|. А2,.... А„)
2. Осуществляем поиск такой функциональной зависимости В\ В2... В,„ -> С,
в которой псе Я,. В2...В,п входят в множество атрибутов X, а С нет.
Затем добавляем С к множеству X
3. Повторяем ша 2 необходимое число раз, пока к множеству X уже невоз-
можно будет добавить атрибуты. Поскольку X может только расги, а мно-
жество атрибутов любого отношения должно быть конечным, процесс
завершается
3 6 Правила функциональной зависимости
105
4. Множество X, к которому невозможно добавить атрибуты, и будет кор-
ректным значением замыкания (Ль Л2,..., Л,,}1-.
Рис. 3 29 Вычисление зомыкония множество атрибутов
Пример 3.28. Рассмотрим отношение с атрибутами А, В, С, О, Е и F. Пусть
оно имеет функциональные зависимости АВ-> С, ВС > AD, D-> Е и CF-> В. Вы-
числим замыкание {А, В}, т.е. {А, В}+.
Начнем с X = [А, В}. Заметим сначала, что все атрибуты левой части функцио-
нальной зависимости АВ-> С находятся в X, значит, можно добавить атрибут С,
расположенный в правой части этой зависимости. Таким образом, после повторе-
ния шага 2 X становится множеством {Л, В, С}.
Теперь ясно, что левая часть зависимости BC->AD входит в X, поэтому к X
можно добавить атрибуты А и А.8 А уже входит в X, но D не входит, значит, после
.добавления X становится множеством (Л, В, С, D}. Теперь можно использовать
зависимость Z) -» Е, чтобы добавить Е к X. после чего X становится множеством
{Л, В С, D, £}. Дальнейшие изменения X невозможны В частности, нельзя исполь
зовать функциональную зависимость CF-* В, так как ее левая часть никогда не
пойдет в X. Следовательно, {Л, В}+ = {Л, В, С, D, £}. С
Зная, как вычислять замыкание любого множества атрибутов, можем прове-
рить, следует ли функциональная зависимость А, А2... Л„-э В из множества зави-
симостей S. Сначала вычисляем (Л(, Л2,.... Л,,)* с помощью множества зависимо-
стей S. Если В входит в {AhA2.Л„}+, тогда
Л1 Л2.. А„ -» В
действительно следует из 5. Если же В не входит в (Л„ Л2,. , Л„}+, данная зависи-
мость не следует из .5" В общем случае можно проверить и зависимость с множест
вом атрибутов в правой части, так как она является сокращенной записью для
множества зависимостей. А, А2 ... А„ -> В, В-,. . В„, следует из множества зависимо-
стей S' тогда и только тогда, когда Bt, Вг.. Вт входят в {Л(, Л>,.., Л„}+.
s ВС-ь AD — это сокращенная запись пары ВС -» А и ВСО При желании
эти зависимости можно рассматривать отдельно
106
Глава 3 Реляционные модели данных
Обоснование действия алгоритма замыкания
Обосновать алгоритм вычисления замыкания достаточно просто. Ннзук- •
uiieii по числу применений операции наращивания шага 2 можно доказать, что {
для к» ждого атрибута D в Л' верна функциональная зависимость At А . Л„-> D j
(если D входит также н п левую часть, зависимость тривиальна). Другими i
словим i каждое отношение Л, удовлетворяющее всем зависимостям в 5,
I удовлетворяет и ,-1| /Г. ... /1„ -> D.
Базис индукции — (I шагов. Тогда D должно совпадать с одним из
j л,. А,..А„ и зависимость ,4( А,... А„ -> D верна на любом отношении, так как
? она тривиальная.
По ннзукипн допустим, что D было добавлено, когда использовалась
i зависимость В В->... Я„,-» D. В силу индуктивного предположения R удов-
, летворяет Л|А --А,,-* В, лля всех i= 1,2.т. Другими словами, любые
t два кортежа из Я. совпадающие по всем Л,, Аг,... А„, совпадают и по всем
В . Вг..... Я,„. Но поскольку Я удовлетворяет Я, Вг... Вт-> D, эти два кортежа
совпадают и ио D. Следовательно, Я удовлетворяет зависимости А, А,... А„ -> D.
Из этого доказательства следует, что алгоритм замыкания является
правильным: если он помешает D в {Л|, Л,./1,,}*, значит, At А2... А„ -э D -
i истинная зависимость. Нужно еще доказать и его паяноту. а именно:
J если At А,... А„~* D верно, то Сбудет помещено в М,, А2. ...,А„}*. Однако
такое доказательство выходит за рамки данной книги.
Пример 3.29. Рассмотрим отношение и функциональные зависимости из
примера 3.2S. Допустим, что нужно проверить, следует ли из этих зависимостей
АВ-> D. Вычисляем, как показано выше, {А, В}+, получаем {А. В, С, D, £} и, посколь-
ку в это множество входит D делаем вывод, что АВ D действительно следует из
указанных зависимостей.
Обратимся теперь к зависимости D -» А. Чтобы проверить, следует ли она из
данных зависимостей, сначала вычислим |О}+. Начнем с X- {£>}. Далее можно ис-
пользовать /)-» Е, чтобы добавить Е к множеству X. Однако на этом все заканчива-
ется. Другую зависимость, левая часть которой входила бы в X, найти невозможно,
поэтому {Д)+ = {£>,£}. Но Я не входит в множество {/), £}, значит, D-+A не следует
из данных зависимостей. □
3-6.4 Правило транзитивности
Правило транзитивности позволяет строить новую функциональную зависи-
мость из двух заданных.
• Если А, Л,... А„ -> Я, Я,... В,п и Я, Я,... В„. -к С, С2 ... Q верны в отношении Я,
то Л, /17... Аа -» С, С:... Сд тоже верна в Я.
Если некоторые из С находятся среди А. их можно удалить из правой части по пра-
вилу тривиальной зависимости.
Для обоснования правила транзитивности можно применить способ проверки
из раздела 3.6.3. Чтобы проверить, верна ли А, А... А„~* С, С,... Ct, нужно вычис-
лить замыкание {.41% Л,,.... Л„}+.
Функциональная зпшсимость Л, Л,... А„ -> Bt В-,... Вт означает, что все
Я|. Я2..В„ входят в (.di./b.А.,}'*. Тогда можно использовать зависимость
3.6 Правила функциональной зависимости
107
Bt В,... В^-ь С( С ... Q для добавления Ch С2, .. С* в {/1(, А,.... Л„}+. Но по-
скольку все С входят в {Л(, А,.., А„}\ можно сделать вывод, что зависимость
Л, А ... .4„-> С, С2 ... Ct верна для любого отношения, удовлетворяющего
А) А ... А„ —» Bt В} ... Вт и В, By... В„ —» С| С2... Cf:.
Замыкания и ключи
Заметим, что {Л,, Л2..АГ является множеством всех атрибутов тогда
* и только тогда, когда /1(, А,.... А, — надключ рассматриваемого отношения.
Только в этом случае At, Аг.....А„ функционально определяет все остальные
! атрибуты. Чтобы проверить, является ли А,,..., А„ ключом отношения,
j достаточно сначала убедиться, что (Я,, А,..., Л„}+ — это все атрибуты, а затем
f установить, что ни для какого множества 5, полученного удалением одного
| из атрибутов из {Л|, А.....AJ, замыкание 5^ не является множеством всех
| атрибутов.
Пример 3.30. Начнем с отношения Movie (см. рис. 3.12), построенного в раз-
деле 3.2.4 для представления четырех атрибутов класса Movie и его связи с классом
Studio.
title year length filmType studioName
Star Wars 1977 124 color Fox
Mighty Ducks 1991 104 color Disney
Wayne’s World 1992 95 color Paramount
Допустим, мы решили представить в этом же отношении данные о студии,
владеющей фильмом. Для простоты в качестве адреса студии введем только город
В результате получим следующее отношение:
title year length filmType studioName studioAddr
Star Wars 1977 124 color Fox Hollywood
Mighty Ducks 1991 104 color Disney Buena Vista
Wayne's World 1992 95 color Paramount Hollywood
Можно утверждать. Ito здесь верны две зависимости:
title year -> studioName
studio Name -> studioAddr
Первая обосновывается тем, что связь ownedBy класса Movie однозначна (фильмом
владеет только одна студия), а вторая тем, что атрибут address класса Studio одно-
значен, он имеет тип string (см. рис. 2 6).
Правило транзитивности позволяет соединить эти две зависимости в одну:
title year -> studioAddr
Она означает, что название и год выпуска (фильма) определяет адрес студии, вла-
деющей этим фильмом □
108
Глава 3 Реляционные модели данных
Полное множество правил вывода
| С помошью вычисления замыкания, описанного п разделе 3.6.3, всегда |
можно установить следует ли одна функциональная зависимость из других, а
Однако интересно то, что существует множестю правил, называемых аксиома-
ми Армстронга. позволяющих вывести любую функциональную зависимость.
i которая следует из заданного множества зависимостей.
I. Рефлексивность. Если (Дь В2,.... В,,,} с {/1(,/Б, 4J.
то 4i Jj ,4,,-т й| Я.... В„,. Это то. что мы называли тривиальными
• зависимостями
2. Пополнение. Если Л, /Б ... А„ -ж Bt Bi.. й„„ |
то Я| А;... А„ С С>... Ct -> Bt Bi... В„ C| Ci... С, для любого множества |
j атрибутов C|. Ci,.... Ct. I
3. Транзитивность Если ,4( А?... А„ -» В, В,... В„, ]
и В\ Bi.. В,—» С| Ст... С*, то Ai Al... А„ —» С| C2... Cj. 5
I 1
3.6-5 Замыкающие множества
функциональных зависимостей
При наличии множества зависимостей часто можно вывести другие зависимо-
сти. в том числе тривиальные и нетривиальные. В следующих разделах необходимо
будет различать заданные зависимости, которые первоначально устанавливаются
для отношения, и производные зависимости, выведенные по правилам, описанным
в этом разделе, или по алгоритму замыкания множества атрибутов.
Более того, иногда можно выбирать, какие зависимости использовать для
представ мния полного множества зависимостей для отношения. Любое множество
заданных зависимостей, из которого можно вывести все зависимости для отноше-
ния называется базисом для этого отношения. Если полное множество зависимо-
стей нельзя вывести ни из одною собственного подмножества зависимостей,
входящих в базис, базис считается минимальным.
Пример 3.31. Рассмотрим отношение Я(Л, В, С), в котором каждый атрибут
функционально определяет все остальные атрибуты. Здесь полное множество выво-
димых зависимостей состоит из шести зависимостей, содержащих по одному атри-
буту справа и слева: АВ, А^С, В^А. В-ьС, С-+А и С-+В. Оно содержит
также три нетривиальные зависимости с двумя атрибутами слепа каждая- АВ-^> С.
АС-л В ч ВС-> А. В нем есть сокращения для пар зависимостей типа А -> ВС.
к тому же можно еще добавить тривиальные зависимости типа ,4->Л или зависи-
мости типа Л/?-> ВС. не являющиеся полностью тривиальными (хотя строгое опре-
деление функциональной зависимости и не требует перечисления тривиальных
зависимостей, частично тривиальных зависимостей или зависимостей с множест-
вом атрибутов в правых частях).
Такое отношение и его зависимости имеют множество минимальных базисов,
например:
{/!-> В. ВА. И^С. С^В}
<Л!1
(Я -» В, fl-+ С, С ж /4]
Предлагаем читателю в качестве упражнения найти другие базисы и минимальные
базисы О
3.6 Правила функциональной зависимости
109
3.6.6 Упражнения к разделу 3.6
* Упражнение 3.6.1. Рассмотрим отношение со схемой Я(Л, В, С, D) и с функ-
циональными зависимостями АВ-+ С, С-» D и О-г Л
а) Какие нетривиальные зависимости следуют из этих зависимостей?
Ь) Укажите все ключи для Я.
с) Какие надключи для Я не являются ключами?
Упражнение 3.6.2. Выполните упражнение 3.6.1 для следующих схем и зави-
симостей:
7) 5(А Я, С, D) с функциональными зависимостями А-> В, В~> С и Я-> D,
м) ДА В, С, П) с функциональными зависимостями AB-t С, ВС-+ D, CD-+A
и AD -» В.
Hi) U(A, В С, D) с функциональными зависимостями А В, В-^С, С-> D
и D -> А.
Упражнение 3.6.3. Обоснуйте следующие правила с помощью теста на замы-
кание, описанного в разделе 3.6.3.
*а) Пополнение левых частей. Если At А2... А„ -> Я—функциональная зависи-
мость, а С — другой атрибут, то At А2 А„ С -> В.
Ь) Завершенное пополнение. Если At А2... А„ -* В — функциональная зависи
мость, а С— другой атрибут, то А{ А2... А„ С-» ЯС. Заметим, что из этого
правила легко вывести правило "пополнения'', упомянутое в разделе 3 6.5
среди аксиом Армстронга.
с) Псевдотранзитивность Пусть верны зависимости At А2 ... А,-> Я| В2... Вт
и С, Сг... Ск -> D, а все В находятся среди С. Тогда верна зависимость
A, Аг... А„ Et £>... Ej-> D, где все Е совпадают с теми С, которых нет
среди В.
d) Дополнение. Если верны функциональные зависимости
Ai А2... А„ -> Bi В2... В„, и С, С2... С* -> О, D2 ... Dj, то верна и зависимость
А[ А2... А„ С| С2 ... С/. -» В/ Вг... В,„ Dt D}... D-
Из нее нужно удалить один экземпляр каждого атрибута, который появ-
ляется одновременно среди А и среди С или же среди В и среди D.
1 Упражнение 3.6.4. Покажите, что перечисленные ниже правила функцио-
нальных зависимостей неверны, для чего приведите пример отношений, которые
удовлетворяют исходным зависимостям, но не удовлетворяют тем, которые якобы
из них следуют.
*а) ’Если А-» В, то Я-> А
Ь) Если АВ -> С и А -> С, то Я -> С.
с) Если АВ С. то А -> С или Я-> С.
! Упражнение 3.6.5. Покажите, что если отношение не имеет атрибута, функ-
ционально определяемого всеми другими атрибутами, то оно вообще не имеет
нетривиальных функциональных зависимостей.
ПО Глава 3 Реляционные модели данных
! Упражнение 3 В.Ь. Пусть X и У — множества атрибутов. Покажите, что если
Л ,- ). то .V* с >•'. где замыкания берутся ио отношению к одному и тому же
множеству функциональных зависимостей.
! Упражнение 3 6.7. Докажите, что t.V+r = Л'+.
?! Упражнение 3.6.8. Множество атрибутов А замкнуто (по отношению к данному
множеству функциональных зависимостей), если А* = X. Рассмотрим отношение
со схем >й /?(.'!. В С. L)} и неизвестным множеством функциональных зависимостей.
Их можно обнаружить, если известно, какие множества атрибутов замкнуты. Каки-
ми будут зависимости если:
*а) все множества четырех атрибутов замкнуты;
Ь) замкнуты только множества 0 и (А. В. С, D}:
с) замкнуты только множества 0, (А В] и (А, В С, £•).
I Упражнение 3.6.9. Найдите все минимальные базисы дтя зависимостей н от-
ношений из примера 3.3!.
!! Упражнение 3.6.10. Покажите, что если функциональная зависимость /"следует
из некоторых заданных зависимостей, то можно вывести F из этих зависимостей
с помощью аксиом Армстронга (определенных в разделе 3.6.5). Подсказка', проверьте
алгоритм вычисления замыкания множества атрибутов и покажите, как можно
имитировать любой шаг этого алгоритма, выводя функциональные зависимости
с помощью аксиом Армстронга.
3.7 Разработка схем реляционных БД
Как уже неоднократно отмечалось, при прямом преобразовании объектно-
ориентированных ODL-проектов (а также E/R-проектов) в схемы реляционной БД
возникают некоторые проблемы. Главная из них избыточность- повторение одного
факта в нескольких кортежах. Наиболее распространенная причина избыточности —
соединение однозначных и многозначных свойств объекта в одном отношении. На-
пример. в разделе 3.2.2 была показана избыточность, возникающая при попытке
сохранить однозначную информацию о фильме, например о его длине, вместе
с многозначными свойствами типа множества кинозвезд занятых в этом фильме.
Такне проблемы просматриваются на рис 3 27. который воспроизведен здесь как
рис. 3.30. Аналогичная избыточность возникала и тогда, когда мы пытались сохра-
нить однозначную информацию о дате рождения кинозвезды вместе с се адресами
title , year length i filmType studioName starName
Star Wars 1 1977 j 124 j color Fox j Carrie Fisher
Star Wars , 1977 I j 124 ! COlor 1 Fox Mark Hamill
Star Wars 1977 ! 124 1 color । Fox Harrison Ford
Mighty Ducks ! 1991 i 104 I color 1 Disney , Emilio Estevez
Wayne's World 1 1992 I 95 color i Paramount Dana Garvey
Wayne’s Worlc i 1992 | 95 color Paramount ! Mike Meyers
Рис. 3.30. Отношение Movie с ономалиями
3.7 Разработка схем реляционных БД 111
В этом разделе более подробно и последовательно рассматривается задача раз-
работки хороших реляционных схем.
I. Сначала детально анализируются проблемы, возникающие при перепол-
нении схемы.
2. Затем вводится понятие декомпозиции — разбиения схемы отношения
(множества атрибутов) иа более мелкие схемы.
3. Далее вводится нормальная форма Бойса-Кодда (ECNF) — условие для
реляционной схемы, позволяющее решить упомянутые проблемы.
4 Два предыдущих пункта объединяются при объяснении того, как обеспе-
чивается BCNF с помощью декомпозиции реляционных схем.
3-7.1 Аномалии
Проблемы типа избыточности, возникающей при попытке внести слишком
большой объем информации в единственное отношение, называются аномалиями
Основные виды аномалий:
I. Избыточность. Информация может без всякой необходимости повторяться
в множестве кортежей. Примеры—длина и тип фильма на рис. 3.30.
2. Аномалии обновления. Информацию можно изменить в одном кортеже и
оставить ее же без изменений в другом. Например, обнаружив, что фильм
Star Wars на самом деле длится 125 мин, можно по рассеянности изме-
нить цифру в первом кортеже на рис. 3.30 а во втором и третьем — нет.
Конечно, можно заявить, что необходимо всегда быть внимательным. Од-
нако далее мы увидим, что нетрудно перестроить отношение Movie так,
чтобы исключить риск подобной ошибки.
3. 4номалии удаления. Если множество значений становится пустым, побоч-
ным эффектом может быть утрата и другой информации. Например, при
удалении Эмилио Эстевез из числа кинозвезд фильма Mighty Duck в базе
данных не останется больше кинозвезд для этого фильма. Последний
кортеж для Mighty Duck в отношении Movie исчезнет вместе с информа-
цией о том, что данный фильм цветной и длится 95 мин.
3-7.2 Декомпозиция отношений
Для устранения аномалий применяется метод декомпозиции отношений.
Декомпозиция Л—это расщепление атрибутов У? для построения схем двух новых
отношений. Правило декомпозиции включает в себя и способ заполнения новых
отношении путем "проекции" кортежей отношения Л. После описания процесса
декомпозиции мы покажем, как выбирать декомпозицию, устраняющую аномалии.
Отношение Л со схемой {А,, Л,.... А„} можно расчленить на два таких отноше-
ния 5 и Т со схемами {ft, ft,.., В„,) и {С,. С2,..., С.} соответственно, что
1. {Л,, л,..., л,,} = {ft. В2.Вт} и (G, Сз,.... С*|.
2 Кортежи в отношении 5 являются .проекциями на {Bt, В2,.... Вт} всех кор-
тежей в R. Другими словами, для каждого кортежа / в текущем экземпля-
ре Я берутся компоненты 1 в атрибутах ft, ft,..., Вт. Эти компоненты
формируют кортеж, который и принадлежит текущему экземпляру отно-
шения 5 Однако отношения являются множествами и один и тот же
кортеж 5 может получиться из проекции двух различных кортежей Я.
В таком случае в текущий экземпляр 5 помещается только один экземп-
ляр кортежа
3. Кортежи в отношении Т—тоже проекции кортежей в текущем экземпля-
ре Я на множество атрибутов (G, С2...G).
112
Глава 3 Реляционные модели денных
Пример 3.32. Выполним декомпозицию отношения Movie, показанного на
рис. 3 3 . Сначала расчленим схему. Наш выбор (цель которого будет ясна из
раздела 3.7.3) состоит в том, чтобы использовать:
I. Отношение Moviel, в схему которого входят все атрибуты, кроме starName.
2. Отношение Movie2, схема которого состоит из атрибутов title, year
и starName.
Затем рассмотрим процесс декомпозиции экземпляров отношений путем
декомпозиции данных, приведенных на рис. 3.30. Сначала построим проекцию на
схему Moviel:
{tit е, year, length, filmType, studioName)
Первые три кортежа иа рис. 3.30 имеют в этих пяти атрибутах одни и те же компо-
ненты:
(Star Wars, 1977, 124, color, Fox)
Четвертый кортеж порождает для первых пяти компонентов совсем другой кортеж,
а пятый и шестой кортежи порождают один и тот же пятикомпонентный кортеж
В результате получается отношение для Moviel, изображенное на рис. 3.31.
title year length filmType studioName
Star Wars 1977 124 color Fox
Mighty Ducks 1991 104 color Disney
Wayne's World 1992 95 color Paramount
Рис. 3.31. Отношение для Moviel
title year starNeme
Star Wars 1977 Carrie Fisher
Star Wars 1977 Mark Hamill
Star Wars 1977 Harrison Ford
Mighty Ducks 1991 Emilio Estevez
Wayne's World 1992 Dana Carvey
Wayne's World 1992 Mike Meyers
Рис. 3.32. Отношение Movie2
Теперь раеск отрим проекцию с рис. 3.30 на схему Movle2. Все шесть кортежей
этой схемы отличаются друг от друга по крайней мере в одном из атрибутов title,
name или siarName. поэтому в результате получается отношение, показанное на
рис. 3.32. □
Заметим, что такая декомпозиция устраняет аномалии, упомянутые в разде-
ле 3 7.1. Исчезнет избыточность. В частности, длина фильма входит в отношение
Moviel только один раз. Риск аномалии обновления тоже исчезает. Например,
поскольку нужно изменить длину фильма Star Wars только в одном кортеже отно-
шения Moviel, можно не опасаться, что появятся две различные длины этого фильма.
1-1 наконец мы избавляемся от риска аномалии удаления. Так, при удалении
всех кипозвец для фильма Mighiy Duck этот фильм исчезает из отношения Movie2,
но всю остальную информацию о нем можно найти в отношении Moviel.
3.7 Разработка схем реляционных БД
113
Может создаться впечатление что отношению Movie2 нее еше присуща из-
быточность поскольку название фильма и год выпуска появляются в нем много-
кратно. Но эти два атрибута составляют ключ для множества фильмов, и более
короткого способа представления фильма не существует Более того, Movie2 исклю-
чает возможность аномалии обновления. Может показаться, что, если изменить год
в кортеже с Кэрри Фишер, не изменяя два других кортежа для Star Won возникнет
аномалия обновления. Однако в предполагаемых функциональных зависимостях
нет ничего такого, что предотвращало бы появление в 1997 г. дру ого фильма
с названием Star Wars, и Кэрри Фишер вполне могла бы в нем играть Поэтому
изменение года в кортеже для Star Wars не запрещается и совсем необязательно,
что такое изменение является неправильным.
3.73 Нормальная форма Бойса Кодда
Декомпозиция предназначена для замены отношения несколькими другими
отношениями, свободными от аномалий. Оказывается, есть простое условие, при
котором аномалии изначально не могут существовать. Оно называется нормальной
формой Ьойса-Кодда, или BCNF.
• Отношение Я есть BCNF. eoni и только если пр наличии в Я нетри-
виальной зависимости у1, А ...Л„-х В множество {/1t. А./1,,} является над-
ключом для R
Это значит, что левая часть любой нетривиальной зависимости должна быть
надкзючом. Напоминаем, что надключ не всегда минимален. Поэтому BCNF
эквивалентна условию согласно которому левая часть любой нетривиальной
функциональной последовательности должна содержать ключ.
Если обнаружена зависимость, нарушающая BCNF, полезно найти все другие
зависимости с такими же левыми частями, независимо от того, нарушают они
BCNF или нет. Приведем альтернативное определение BCNF. отражающее поиск
таких зависимостей с одинаковыми левыми частями, по крайней мере одна из
которых нарушает BCNF.
• Отношение Л находится в BCNF, если и только если для В выполняется не-
тривиальная зависимость Л, А .. Л„->В Bt. В„, и множество (А. Л},.... Л„|
является надключом для Л.
Это требование эквивалентно исходному условию BCNF. Напоминаем, что
зависимость А х1>... А„ -> В, В2 В,„ — это сокращенная запись множества зависи-
мостей At А — Л дл!| '=1.2, ., т Поскольку должно быть хотя бы одно 2?,-,
не встречающееся в левой части (в противном случае зависимость будет тривиаль-
ной). то А А... А„ -х В, является нарушением BCNF согласно первоначальному
определению.
Пример 3.33 Отношение Move на рис.-3 30 не находится в BCNF Чтобы
убедиться в этом, нужно сначала определить, какие множества атрибутов служат
ключами В примере 3 71 показано, что ключом является {tile. year. starName} Зна-
чит, любое множество, содержащее эти три атрибута, представляет собо 1 надключ
Аналогичную аргументацию из примера 3.21 можно использовать для объяснения
того, почему ни одно множество, не содержащее все эти три атрибута, не может
быть надключом. Следовательно, можно утверждать, что {title year, starName) — это
единственный ключ для Movie
114
Глава 3 Реляционные модели данньх
Теперь рассмотрим функциональную зависимость
title year -> length filmType studioName
которая верна для Move. Напоминаем, почему она верна исходный ODL-проект
имеет ключ {title, year), однозначные атрибуты length и filmType. а также однознач-
ную связь ownedBy, ведущую к студни, владеющей фильмом.
К сожалению, левая часть этой зависимости не является надключом В частности,
известно, что title и year функционально не определяют шестой атрибут — starName.
Значит, существование такой зависимости нарушает условие BCNF и свидетельст-
вует о том, что отношение Movie не находится в BCNF. Более того, согласно исход-
ному определению BCNF по которому в правой части должен быть единственный
атрибут, нарушать BCNF может любая из трех функциональных зависимостей,
например title year -гlength. □
Пример 3.34. Отношение Moviel на рис. 3.31 находится в BCNF Поскольку
зависимость
title year -» length filmType studioName
верна и ни title, ни уест сами по себе не определяют никакие другие атрибуты,
единственный ключ для Moviel — {title, year) Более того, нетривиальные функцио-
нальные зависимости в своих левых частях должны иметь по крайней мере title
и year, поэтому их левые части должны быть надключами Таким образом, Moviel
находится в BCNF. □
Пример 3.35. Любое отношение с двумя атрибутами находится a BCNF Для
доказательства этого утверждения нужно проверить возможные нетривиальные
зависимости с единственным атрибутом справа. При этом необходимо рассмотреть
всего четыре случая. Пусть имеются два атрибута А и В
I . Нетривиальных функциональных зависимостей нет. Тогда условие BCNF
должно выполняться, так как нарушить его может только нетривиальная
зависимость. Кстати, в данном случае единственный ключ — это {Л, В}
2 . Верно А В. но не верно В -ь А В этом случае А — единственный ключ
и каждая нетривиальная зависимость содержит А слева (фактически, сле-
ва может стоять только А). Значит, условие BCNF не нарушается
3 Верно В-*А, но не верно А -» В Случай симметричен предыдущему
4 Верно А -> В и В-* А. Тогда А и В ключи. Ясно, что любая зависимость
имеет в левой части А или В, поэтому нарушений BCNF не может быть.
Из пункта 4 следует, что для отношения может быть несколько ключей. Однако,
согласно условию BCNF, в леиой части нетривиальной зависимости достаточно
иметь некоторый ключ, а не все Заметим также, что отношение с двумя атрибута-
ми, функционально определяющими друг друга, не является абсолютно неправдо-
подобным. Например, компания может приписать своим сотрудникам уникальные
ID (empID) и одновременно записывать номера их страховых полисов (ssNo). В от-
ношении с атрибутами empID и ssNo оба атрибута функционально определяют друг
Друга Другими словами, каждый атрибут является ключом, поэтому не существует
двчх кортежей, совпадающих по одному из этих атрибутов. □
3.7 Разработка схем реляционных БД
115
3.7.4 Декомпозиция в BCNF
Повторно применяя подходящие декомпозиции, можно разбить любую схему
отношения на множество подмножеств его атрибутов со следующими важными
свойствами
I Эти подмножества являются схемами отношений в BCNF
2 . Данные исходного отношения правильно представлены данными в отно-
шениях, полученных в результате декомпозиции, в смысле, который будет
уточнен в разделе 3.7.6. Строго говоря, нужно иметь возможность восста-
новить исходное отношение точно из отношений полученных в результате
его декомпозиции
Судя по примеру 3.35, достаточно разбить схему отношения на двухатрибутив-
ные подмножества, чтобы результат наверняка был в BCNF. Однако, как будет
показано в разделе 3.6 7, такая произвольная декомпозиция не удовлетворяет усло-
вию 2. Просто нужно быть более внимательным и при декомпозиции руководство-
ваться функциональными зависимостями, нарушающими BCNF
В процессе декомпозиции будем следовать стратегии поиска нетривиальной
функциональной зависимости А А ... А„ -> Bt В-,.. Вт, которая нарушает BCNF;
т.е. {A- А* —> А) не является надключом. В качестве эвристическою приема добавим
в правую часть зависимости атрибута, функционально определенные множеством
{А, А,..., Ah
На рис. 3.33 показано разбиение атрибутов на две пересекающиеся схемы
отношений. Первая — это все атрибуты, входящие в нарушающую зависимость,
вторая — левая часть зависимости плюс все атрибута, не входящие в эту зависи-
мость, т.е. все атрибуты, за исключением тех В, которые не совпадают с /1,.
Рис. 3.33, Декомпозиция схемы отношения, основанная на нарушении BCNF
Пример 3 36. Рассмотрим снова отношение Movie на рис 3.30. В примере 3.33
было показано, что
title year -> length filmType studioName
нарушает BCNF. В данном случае правая часть уже содержит все атрибуты, функ-
ционально определяемые атрибутами title и year Поэтому мы используем данное
нарушение BCNF для декомпозиции Movie на:
1) схему со всеми атрибутами этой зависимости-
{title, year, length, filmType studioName)
2) схему co всеми атрибутами Movie, за исключением трех, входящих в
правую часть зависимости Таким образом, удаляются length, filmType
и studioName и остается схема
{title year, starName}
116
Глава 3 Реляционные модели данных
Заметим, что именно эти схемы выбирались для отношений Moviel и Movie2
в примере 3 32 В примере 3 34 было показано, что обе они находятся в BCNF. □
Пример 3.37. Рассмотрим отношение MovieStudio, введенное в примере 3.30.
В нем хранится информация о фильмах, владеющих ими студиях н адресах этих
студий Схема и некоторые типичные кортежи этого отношения показаны на
рис. 3.34.
title year length filmType studioName studioAddr
Star Wars 1977 124 color Fox Hollywood
Mighty Ducks 1991 104 color Disney Buena Vista
Wayne’s Wo Id 1992 95 co or Paramount Hollywood
Addams Family 1991 102 color Paramount Hollywood
Рис. 3.34. Отношение MovieStudio
Это отношение содержит избыточную информацию. Поскольку к обычным
данным здесь добавлена запись о фильме, которым владеет Paramount, адрес этой
студии повторяется дважды Однако источник этой проблемы иной, нежели в при-
мере 3.36. В предыдущем примере проблема заключалась в том, что многозначная
связь (кинозвезды данного фильма) хранилась вместе с другой информацией
о фильме. Здесь же псе однозначно: атрибут фильма length связь ownedBy фильма
с единственной владеющей им студией и атрибут студий address.
В данном случае проблема в транзитивной зависимости. Как показано в при-
мере 3.30, отношение movieStudio имеет две зависимости:
title year -+ studioName
studioName -» studioAddr
По правилу транзитивности можно получить
title year-> studioAddr
Значит, название и год выпуска фильма (т.е. ключ для фильмов) функционально
определяют адрес студии, владеющей фильмом. Но
title year -> length filmType
является очевидной зависимостью, следовательно, (title,year) — ключ для MovieStudio,
фактически, единственным.
С другой стороны, зависимость
studioName -> studioAddr
которая использовалась при применении правила транзитивности, нетривиальна
но ее левая часть не является надключом. Значит, отношение MovieStudio не нахо-
дится в BCNF. Используя эту зависимость, можно решить рассматриваемую проб-
лему согласно правилу декомпозиции. Первая схема декомпозиции — атрибуты
самой данной зависимости:
(studioName, studioAddr)
Вторая схема — все атрибуты MovieStudio, за исключением studioAddr, так как
последний находится в правой части зависимости, используемой в декомпозиции.
Значит, второй схемой является
(title, year, length, filmType, studioName)
3.7 Разработка схем реляционных БД
f 17
Проекция с рис. 3 34 на две последние схемы дает два отношения - MoveStudio 1
и MovieStud о2 (рис. 3.35 и 3.36) Оба они находятся в BCNF. Единственный ключ
для Mov eStudio 1 {title year}, а единственный ключ для MovieStud'o2 — {studioName}.
В обоих случаях нс существует нетривиальных зависимостей не содержащих эти
ключи в левой части. □
title year length filmType ’ studioName
Star Wa s 1977 124 color ‘ Fox
Mighty Ducks 1991 104 color • Disney
Wayne's World 1992 • 95 color Paramount
Addams Family 1901 102 color Paramount
Рис. 3.35. Отношение MovieStudio!
studioName | I studioAddr
Fox ! Hollywood
Disney i i Buena Vista
Paramount | | Hollywood
Рис. 3.36. Отношение MovieStudio2
Во всех предыдущих примерах достаточно одного применения декомпозиции
для получения множества отношений, находящихся в BCNF. В обшем случае это
не так.
Пример 3.38. Обобщая пример 3.37, можно получить цепь функциональных
зависимостей. Рассмотрим отношение со схемой
{title, year, stud oName, president, presAddr}
Каждый кортеж этого отношения содержит информацию о фильме, выпустившей
его студии, президенте этой студии и его адресе. Предполагается, что в данном
отношении есть зависимости
title year studioName
studioName -> president
president -+ presAddr
Для этого отношения существует единственный ключ {title, year} Поэтому
последние две зависимости нарушают BCNF Декомпозицию можно начать, напри-
мер, с зависимости
studioName -> president
В первую очередь в правую часть этой зависимости нужно добавить псе осталь-
ные атрибуты из замыкания stu< ioName. Применяя правило транзитивности
к studioName -> president и presiden -> tpresAddr, получаем зависимость
studioName -> presAddr
Затем, соединяя две зависимости с одинаковыми левыми частями, получаем
studioName —> president presAddr
11Б
Глава 3 Реляционные модели данных
Эта функциональная зависимость имеет максимально развернутую правую часть,
поэтому произведем декомпозицию в результате чего получаются две схемы
{title, yeer, studioName}
{studioName. president, presAddr}
Первая из них находится в BCNF. Единственным ключом второй является
(studioName), но при этом в ней есть зависимость
president -> presAddr
нарушающая BCNF Значит, необходимо продолжить декомпозицию, используя
расширенную зависимость, в правой части которой находится president. В результате
получаются три схемы в BCNF:
{title, year. studioName)
{studioName president)
{president, presAddr) □
R общем случае можно применять правило декомпозиции столько раз, сколько
необходимо для получения отношений в BCNF. Конечный успех обеспечен, по-
скольку при каждом применении этого правила к отношению Я получаются схемы,
содержащие меньше атрибутов, чем Я. Как показано в примере 3.35, когда остается
только два атрибута, отношение обязательно будет в BCNF.
Декомпозиция действительно всегда приводит к более мелким схемам. Допус-
тим. что зависимость At А ... А„ -> В, В... Вт нарушает BCNF. Можно предполо-
жить, что она уже расширена так, что среди Я,,.., Вт находятся все другие
атрибуты, функционально определяемые атрибутами А,, и все В}, находящиеся сре-
ди И,,.... А„ уже удалены из правой части зависимости.
Одна из схем, получающихся в результате декомпозиции, это все атрибуты R.
за исключением атрибутов В,.. , Вт Но по крайней мере один атрибут В/ должен
существовать, значит, эта схема не включает в себя все атрибуты.
Другая схема содержит все А,,..., и Вь .... Вт. Это множество не может быть
всеми атрибутами Я. иначе множество {А,, А,.. , А,,} было бы надключом для R
(т.е. атрибуты А},А„ функционально определяли бы все остальные атрибуты Я).
Тем не менее ни одна зависимость с надключом в левой части не нарушает BCNF.
Таким образом, обе схемы, полученные при декомпозиции, меньше R. Значит,
ряд повторных декомпозиций в конечном счете должен привести к множеству
отношений, находящихся в BCNI-.
3.7.5 Проекция фтнкциональных зависимостей
При декомпозиции схемы отношения необходимо следить, чтобы результирую-
щие схемы были в BCNF. Из примера 3.38 ясно, что одна из них или даже обе но-
вые схемы могут нарушать BCNF. Но как узнать, находится ли данное отношение в
BCNF, если для этого отношения не определены зависимости'3 В примере 3 38 мы
рассуждали о зависимостях, которые истинны для новых отношений ad hoc. К сча-
стью, существует регулярный метод нахождения функциональных зависимостей для
результатов декомпозиции.
Пусть имеется отношение Я разложенное на отношение 5 и какое-то другое
отношение. Пусть Я—множество функциональных зависимостей, истинных на Я.
Дпя вычисления функциональных зависимостей, истинных на 5. сделайте следующее.
3 7 Разработка схем реляционных БД
19
Рассмотрите каждое множество атрибутов А', содержащееся в множестве атри-
бутов отношения S. Вычислите А'’. Тогда для каждого атрибута Л, такого как
1) В есть атрибут А:
2) В входит в А";
3) В не входит в А,
в А выполняется функциональная зависимость X -> В.
Упрощение поиска зависимостей
а .
При выведении функциональных зависимостей для отношения 5 из зави- i
! симостей для В с помощью алгоритма раздела 3.7.5 иногда можно ограничить s
j область поиска, не вычисляя замыкания всех подмножеств атрибутов А. Сле- ;
дующие правила облегчают поиск.
1. Необязательно рассматривать замыкание множества всех атрибутов А. I
2. Необязательно рассматривать множество атрибутов, не содержащее
левой части какой-либо зависимости.
j •
3. Необязательно рассматривать множество, содержащее атрибут,
не входящий в левую часть какой-либо зависимости.
Пример 3.39. Пусть В имеет схему К(А, В, С, D) и для R заданы завис шости /I -> В
и В->С. Пусть А(А, 0 — одно из отношений, полученных в результате декомпози-
ции R. Вычислим зависимости, которые верны для А.
В принципе, нужно вычислить замыкание каждого подмножества множества
{Л. Cj Последнее является множеством атрибутов отношения А. Начнем с {А}’1'.
Очевидно, что это множество {Л, В, Q. Поскольку В не входит в схему' А, нельзя
утверждать, что А -> В является зависимостью для А. Но С входит в А, поэтому
для А устанавливается зависимость А С.
Теперь рассмотрим {0+. Поскольку Сне входит в левую часть заданной зави-
симости, в замыкании не появляется ничего нового, т е. {0* = (0. В общем случае
множество, не содержащее по крайней мере одной левой части заданной зависимо-
сти, не может порождать никаких зависимостей в А.
И наконец, нужно рассмотреть {А, 0+. Это замыкание равно {А, В, С]. Значит,
мы не нашли никакой новой зависимости, кроме той, что была обнаружена при
рассмотрении {А}+. Следовательно, А -> С— единственная зависимость, которую
надо установить для А. Конечно, из нее можно вывести другие зависимости для А,
например AD -> С или тривиальную зависимость А -х А. Однако их можно получить
по правилам, приведенным в разделе 3 6, и не требуется устанавливать специально
при определении зависимостей для А □
Пример 3.40. Рассмотрим отношение Я(А, В, С, D, Е), расчлененное на А(А, В. С)
и какое то другое отношение. Пусть для В установлены функциональные зависи-
мости А -ь D, В -> Е н DE -> С.
Сначала рассмотрим {А]+ = {A, D} Поскольку D не входит в схему А, мы не по
лучаем новых зависимостей. Точно так же (В}+ ~ {В, Е) и {С}+ — {0 не дают новых
зависимостей для А.
Теперь рассмотрим пары. {А, В}+ = {Я, 5, С, D, £}, поэтому для А получается
зависимость АВ-± С. Ни одна из остальных возможных лар новых зависимостей
для А не дает. Разумеется, множество всех атрибутов А, т.е. (А, В. С}, тоже не может
дать нетривиальную зависимость для А. Следовательно, единственной зависимо-
стью, которую нужно установить для А, является АВ~> С. □
120
Глава 3 Реляционные модели данных
3.7.6 Восстановление информации
из декомпозиции
Обратимся к вопросу о том, почему алгоритм декомпозиции, введенный в раз-
деле 3.7.4, сохраняет информацию, содержащуюся в исходного отношении. Дело в
том. что. следуя данному алгоритму, можно снова ’соединить" проекции исходных
кортежей, чтобы получить исходные кортежи и только их
Упростим ситуацию: рассмотрим отношение Л со схемой (Л, В, С} и функцио-
нальной зависимостью В-» С, нарушающей BCNF. Здесь, как и в примере 3.37,
может существовать транзитивная цепь зависимостей содержащая другую фуикци
ональную зависимость А -> В. В таком случае (Л) — единственный ключ, и левая
часть зависимости /?-> С не является надключом. Другая возможность состоит
в том что В-> С— единственная нетривиальная зависимость и ключом служит
{Л, 2?|. Но и в этом случае левая часть С не является надключом. В любом
случае требуемая декомпозиция, основанная на зависимости В -> С, делит атрибуты
на (Л, В и (й. С}.
Рис. 3.37. Соединение деух кортежей из проецироеонных отношений
Пусть / — кортеж в R и / (<?, Ь, с), где а, Ь и с — компоненты t для атрибутов
А. В и С соответственно. Кортеж / проецируе ся как (а, Ь} для отношения со схе-
мой И, В} и как (6. с) для отношения со схемой (/?, Cl-
Кортеж из {/1, В) можно соединить с кортежем из |ft Q при условии, что они
совпадают по ком юнснту В Так, соединение (а, Л) с (Ь. с) дает исходный кортеж
г=(а. Ь. с) Независимо от того, с какого кортежа I мы начинали, можно всегда
соединить его проекции и снова получить г.
Однако восстановление исходных кортежей не гарантирует, что исходное отно-
шение Л правильно представлено декомпозицией. Что произойдет, если было два
кортежа Л, например t = (я. Ь. с) и v = (J, b, е)9 Проекция г на (И. В} дает и = (я, Л).
1 проекция г на {Л’. С} дает w=(h, е). как показано на рис. 3 37.
Кортежи и и iv соединяются, так как они совпадают по В, и получается кортеж
.\-= (я. Z>, е). Может ли х быть фиктивным кортежем, т.е. допустимо ли. что (д, Л, е)
нс является кортежем R?
3.7 Разработка схем реляционных БД
121
Ответ отрицательный, так как для R установлена функциональная зависимость
В-> С. Вспомните, ведь она означает, что любые два кортежа R, совпадающие по
компонентам 5, должны совпадать и по компонентам С. Поскольку t и я совпадают
по компонентам В (в них входит Ь}, они совпадают и по компонентам С, Это зна-
чит. что с=е, т.е. два значения, которые мы считали различными, на самом деле
совпадают. Значит, (а, Ь, е) совпадает с (д, Л, с), т.е. х= t.
Поскольку / входит в R, хтоже должен быть в R Другими словами, пока функ-
циональная зависимость В~> С истинна, соединение двух проецированных корте-
жей не может породить фиктивный кортеж. Более того, каждый подученный в
результате соединения кортеж обязательно будет кортежем R.
Приведенный выше аргумент действует и в общем случае. Предполагалось, что
А, В и С — единичные атрибуты, но такое же обоснование применимо к множест-
вам атрибутов. Возьмем любую зависимость, нарушающую BCNF, и пусть В— ат-
ргбуты левой части. С — атрибуты, которые находятся в правой части, но не входят
в левую, и А — атрибуты, не входящие ни в одну из частей этой зависимости. Тогда
можно сделать следующее заключение
• Если отношение разложено по методу раздела 3 7.4, оно может быть точно
восстановлено путем соединения кортежей новых отношений всеми возмож-
ными способами.
Если при декомпозиции отношений применяется метод, не основанный на
функциональной зависимости, восстановить исходное отношение не всегда воз-
можно. Приведем пример.
Пример 3,41. Рассмотрим отношение R с прежней схемой {А, В, С], но без за-
висимости В -> С. Оно может состоять из двух кортежей:
Проекциями R на отношения со схемами {А, В] и {В, С) будут
А В
1 2
4 2
2 5
соответственно. Поскольку значение ”2“ атрибута В встречается во всех четырех
кортежах, каждый кортеж одного отношения соединяется с обоими кортежами
другого. Поэтому при попытке восстановить R получаем
А | В С
112 3
1 I 2 5
4 2 3
4 2 5
Мы получаем "слишком много” —два фиктивных кортежа (1,2,5) н (4,2,3),
которых не было в К. □
1?2
Глава 3 Реляционные модели данных
3.7.7 Третья нормальная форма
Иногда трудности вызваны тем. что схема отношения и ее зависимости не
удовлетворяют BCNF. но эту схему нежелательно разлагать далее. Приведем типич-
ный пример.
Пример 3.42. Рассмотрим отношение Bookings с атрибутами:
I) title — название фильма.
2) theater — название кинотеатра, где демонстрируется фильм;
3) city — город, в котором находится кинотеатр.
Кортеж (от. г. с) означает, что фильм т сейчас демонстрируется в кинотеатре t
города с.
Можно установить следующие зависимости:
theater -> city
title city theater
Первая из них означает, что кинотеатр находится в одном городе. Вторая не оче-
видна но основана на том. что обычно один и тот же фильм не показывают одно-
временно в двух кинотеатрах одного города. Эта зависимость приведена только для
примера.
Сначала найдем ключи. Ни один атрибут сам по себе не является ключом.
Например, title не ключ, так как фильм может демонстрироваться одновременно
в нескольких кинотеатрах и нескольких городах.’ Атрибут theater тоже не является
ключом. Несмотря на то что theater функционально определяет city, есть кинотеат-
ры, в нескольких залах которых демонстрируются разные фильмы одновременно.
Поэтому theater не определяет title И наконец, city не является ключом, так как
в городах обычно несколько кинотеатров, в которых идет множество фильмов.
Ключами могут быть два или три атрибута вместе. Ясно, что {title, city} — ключ,
поскольку в силу заданной зависимости эти атрибуты определяют theater
Ключом является и [theater, title}. Чтобы убедиться в этом, начнем с зависимо-
сти theater -> city. Из нее по правилу пополнения (см. упражнение З.б.З.а) получается
theater, title —> city. Интуитивно ясно, что если один атрибут theater функционально
определяет city, то уж theater и title тем более.
Оставшаяся пара атрибутов, city и theater, функционально не определяет title,
поэтому не является ключом. Итак, существует только два ключа:
{title, city}
{theater title}
Нарушение BCNF очевидно. Была задана функциональная зависимость
theater -> city, но ее левая часть не является надключом Значит, мы пытались
применить разбиение на два отношения
{theater city}
[theater, title}
используя нарушающую BCNF зависимость.
Проблема здесь связана с функциональной зависимостью title city -> theater.
Для полученных при декомпозиции схем могут существовать текущие отношения.
9 В этом примере предполагается, что не существует двух идущих в прокате фильмов
с одним названием, хотя ранее предполагалось, что могут быть фильмы с одним
и тем же названием, сделанные в разные голы.
3.7 Разработка схем реляционных БД
123
удовлетворяющие зависимости theater -> city (что можно проверить в отношении
{theater, city}), но при их соединении получается отношение, не удовлетворяющее
зависимости title city -> theater. Например, два отношения
theater
Guild
Park
I city
j Menlo Park
: Menlo Park
theater | title
Guild | The Net
Park | The Net
допустимы, согласно функциональным
соединение дает два кортежа
зависимостям, к каждому из них, но их
theater city title
Guild Menlo Park The Net
Park Menlo Park The Net
нарушающих зависимость title city -»theater. □
Решение этой проблемы состоит в ослаблении требования BCNF, допускаю
щем реляционные схемы (как в примере 3.42), которые невозможно расчленить
на BCNF, не утратив возможности проверять каждую функциональную зависимость
в одном отношении. Такое ослабленное условие называется третьей нормальной
формой.
• Отношение R находится в третьей нормальной форме (3NF), если для любой
нетривиальной зависимости А А2... А„ -> В, либо {А, А2.А,.} — надключ
либо В — член некоторого ключа.
Заметим, что условия 3NF и BCNF различаются словами "В — член некоторого
ключа", которые "оправдывают" зависимость типа theater -> city из примера 3 42, так
как ее правая часть, city, является членом ключа.
Доказательство того, что 3NF соответствует своим целям, выходит за рамки
этой книги. Тем не менее всегда можно без потери информации разложить схему
отношения на схемы в 3NF и контролировать все функциональные зависимости.
Однако, если новые отношения не находятся в BCNF, в схеме остается некоторая
избыточность.
Интересно заметить, что последний пример схемы отношения, находящейся
в 3NF, но не в BCNF, отличается от рассмотренных ранее примеров нарушения
BCNF. Одна из релевантных функциональных зависимостей, theater-> city, типична
по форме и основана на том что кинотеатр — это уникальный объект, расположен-
ный в городе. Другая же —
title city —> theater
основана на наблюдении за практикой проката фильмов студиями. В общем случае
функциональные зависимости распадаются на две категории. Одни из иих основаны
на факте представления уникальных объектов типа фильмов или студий, другие —
на реальной практике типа проката фильма не более чем в одном кинотеатре
каждого города.
124
Глава 3 Реляционные модели данных
Другие нормальные формы
Если речь идет сразу о третьей нормальной форме, чго же случилось
с первыми двумя нормальными формами" Разумеется, они были определены,
но в настоящее время применяются очень редко. Первая нормальная форма —
это условие, согласно которому каждый компонент каждого кортежа является !
атомарным значением. Вторая нормальная форма слабее 3NF. Она допускает [
транзитивные зависимости в отношении, но запрещает нетривиальную запи j
спмость. левая часть которой является собственным подмножеством ключа. ।
Есть и четвертая нормальная форма, которая будет рассмотрена в разделе 3.S. s
3-7-8 Упражнения к разделу 3-7
Упражнение 3.7.1. Для каждой из реляционных схем:
•а) В С, D) с функциональными зависимостями АВ~> С, C~t D
и D -> А,
*Ь) R(A, В. С, D) с функциональными зависимостями В-+ С, В-у [У,
с) Л(Л, В, С, D) с функциональными зависимостями АВ-> С. ВС-у D
CD -> А и AD~> В;
d) Д(Д, В, С, D) с функциональными зависимостями Л-r В, В-+ С, С-> D
и D -> А ;
е) В(А, В, С D. Е> с функциональными зависимостями ЛВ-> С, DE-ь С
и £-> D;
f) R(A, В, С, D, Е) с функциональными зависимостями АВ~> С, С~> D,
D-> В и D Е
выполните следующее:
О Укажите все нарушения BCNF, Не забудьте рассмотреть зависимости, ко-
торые не входят в заданное множество зависимостей, но следуют из него.
Указывать нарушения в виде зависимостей, имеющих в правой части
более одного атрибута, необязательно.
0) Проведите декомпозицию отношений па множество новых отношений,
находящихся в BCNF.
НП Укажите все нарушения 3NF
п’) Разложите отношения на множество новых отношений, находящихся
в 3NF.
Упражнение 3 7.2. В разделе 3.7 4 было сказано, что по возможности следует
расширять правую часть функциональной зависимости, нарушающей BCNF, но это
считалось произвольным шагом, который можно не делать. Рассмотрите отношение R
со схемой (Л, В С, и функциональными зависимостями А В и А -> С. Любая
нз них нарушает BCNF, так как ключом для R является {Л, D}. Допустим, что де-
композиция начинается с А -> В. Получится ли в конечном счете тот же результат,
какой получился бы, если нарушающая BCNF зависимость предварительно была
бы расширена до /1-> ВС? Почему да или почему нет?
3.8 Многозначные зависимости
125
Упражнение 3.7.3. R остается таким же, как в упражнении 3.7.2 но имеет за-
висимости Л-» В и В-> С. Сравните декомпозиции, начатые с А -> В и с Л-> ВС.
Подсказка- важно учитывать, какие зависимости истинны для полученных в резуль-
тате декомпозиции отношений Достаточно ли только тех зависимостей, которые
содержат атрибуты лишь одной из схем, полученных в результате декомпозиции?
Как быть с зависимостями, которые следуют из заданных зависимостей?
Упражнение 3.7.4. Допустим, что реляционная схема Я(Л, В, С) с функцио-
нальной зависимостью А-> В разложена на S(A, S) и Т(В, С). Приведите пример
отношения R, проекция которого на 5 и Т и последующее восстановление по
методу раздела 3.7.6 не приводят к тому же экземпляру отношения.
Упражнение 3.7.5. Пусть отношение Я(Л, В, С, D, Е) разложено на В, С)
и другие отношения Укажите функциональные зависимости для 5, если зависимо-
стями для R являются:
*а) AB^DE, С-^Е, D->Cm Е->А;
b) А -> D, BD^> Е, АС-> Е и DE-> В;
с) АВ-> D, АС~> Е, ВС-у D, D^A и Е-> В,
d) А -> В, В -> С, С-» D, IUE и £-> А.
В каждом случае достаточно обеспечить минимальный базис для полного множест-
ва зависимостей 5.
3.8 Многозначные зависимости
"Многозначная зависимость" означает, что два атрибута или два множества
атрибутов не зависят друг от друга. Это условие предполагает обобщение понятия
функциональной зависимости в том смысле, что любая функциональная зависи-
мость влечет соответствующую многозначную зависимость. Однако в некоторых
ситуациях независимость множества атрибутов невозможно объяснить через функ-
циональные зависимости. В этом разделе показано, как возникают многозначные
зависимости и как их можно применить в разработке схемы БД.
3.8.1 Независимость атрибута ~ причина
его избыточности
В некоторых случаях находящееся в BCNF отношение сохраняет избыточ-
ность, не связанную с функциональными зависимостями. Наиболее распространен-
ный источник избыточности в BCNF — независимость одного или нескольких
многозначных атрибутов какого-то класса при прямом преобразовании из ODL
в отношения, описанные в разделе 3 2.
Пример 3.43, Пусть класс Star по определению приведенному на рис. 3 38,
имеет имя, множество адресов и множество кинозвезд Определение этого класса
аналогично приведенному на рис. 2.5, за исключением типа атрибута address.
interface Star (
attribute string name;
attribute Set<
Struct Addr {string street, string city}
> address;
r lationship Set<Movie> starredln inverse Movie”stars,
}:
Рис. 3.38. Кинозвезды, no определению имеющие одресо и фильмы
126
Глава 3 Реляционные модели данных
На рис. 3.39 показаны некоторые кортежи отношения, которое получается не-
посредственно из этого определения.
пате street city I title year
Carrie Fisher 123 Maple St. Hollywood [ Star Wars 1977
Carrie Fisher 5 Locust Ln. Malibu I Star Wars 1977
Carrie Fisher 123 Maple St Hollywood Empire Strikes Back 1980
Carre Fisher 5 Locust Ln. Malibu | Empire Strikes Back 1980
Carrie Fisher 123 Maple St. Hollywood ! Return of the Jedi ! 1983
Carrie Fisher 5 Locust Ln Malibu । Return of the Jedi ; 1983
Рис. 3 39. Множество адресов. незовисимьа от фильмов
Множество адресов представлено здесь точно так же, как на рис. 3.8. Кортежи
того отношения были расширены компонентами, соответствующими атрибутам title
и year, ключу для класса Movie. Эти атрибуты представляют фильмы, соединенные
с кинозвездой связью starredln.
В отношение на рис 3.39 входят два гипотетических адреса Кэрри Фишер
(Carrie Fisher) н три наиболее известных фильма. Связывать адрес только с одним
фильмом, а не с другим, нет никаких оснований. Поэтому единственный способ
выразить то, что адреса и фильмы являются независимыми свойствами кинозвезд,
это повторить адрес с каждым фильмом. Очевидно, что при этом возникает избы-
точность. Например, на рис. 3.39 каждый из адресов Кэрри Фишер повторяется три
раза (по разу для каждого фильма, в котором она играла), а каждый из фильмов
повторяется два раза (по разу для каждого адреса).
Тем не менее здесь нет нарушения BCNF Фактически, в этом примере вообще
нет нетривиальных функциональных зависимостей. Например, атрибут city функци-
онально не определяется четырьмя другими атрибутами. У кинозвезды может быть
два дома, находящихся в разных городах на улицах с одинаковым названием. Тогда
было бы два кортежа, совпадающих по всем атрибутам, кроме city. Значит
name street title year -ж city
не является функциональной зависимостью для отношения Star. Предоставляем
читателю возможность самому' проверить, что пи один нз пяти атрибутов функцио-
нально не определяется четырьмя остальными Этого достаточно для того, чтобы
сделать вывод, что здесь вообще нет нетривиальных функциональных зависимостей
(надеемся, читатель сам разберется, почему такой вывод является правильным).
Поскольку нетривиальных функциональных зависимостей нет, все пять атрибутов
формируют единственный ключ и BCNF не нарушается □
3-8.2 Определение многозначных зависимостей
Многозначная зависимость — это утверждение об отношении R, согласно кото-
рому при фиксированных значениях одного множества атрибутов значения некото-
рых других атрибутов независимы от значений всех остальных атрибутов данного
отношения. Точнее говоря, многозначная зависимость
/1|А.. A,,-** Bt Bi . li,„
верна для отношения Л при наличии следующей ситуации. Если мы ограничимся
кортежами Я, имеющим» конкретное значение для каждого атрибута А„.., А„, то
множество значений атрибутов В.. В„ не зависит от множества значений атрибу-
тов /?. которые нс совпадают ни с А, ни с В Можно дать еще более точное опреде-
ление
3 В Многозначные зависимости
127
Многозначная зависимость верна, если для каждой пары кортежей t и и отно-
шения R, совпадающих по всем атрибутам Л,,.... А„, в Я можно найти кортеж v,
который совпадает:
а) с I и и по атрибутам Л; ... А„,
b) с I по атрибутам Вь ... В„„
с) с и по всем атрибутам Я, не совпадающим ни с Ль ..., Л,„ ни с Bt, В„.
Заметим, что, поменяв местами t и и, с помощью этого правила можно вывести
существование четвертого кортежа гг, который совпадает с и по атрибутам Bt,В„.,
а с t по всем другим атрибутам. В результате для любых фиксированных значений
атрибутов Ль .... Л„, связанные с ними значения атрибутов В„, и других атри-
бутов появляются во всех возможных комбинациях в разных кортежах. На рис. 3.40
показано, как г связано с Г и и при наличии многозначной зависимости
Рис. 3.40 Многозначной зависимость гарантирует существование v
В общем случае можно считать, что множества {/4|;..., А„} и {Я|, ..., В,„} (левая и
правая части) многозначной зависимости не имеют общих элементов. Однако, как
и в случае с функциональными зависимостями, допустимо добавлять некоторые А,
в правую часть Заметим также, что в отличие от функциональных зависимостей,
в которых мы начинали с единственного атрибута в правой части и допускали
множество атрибутов справа только в качестве сокращения, при многозначной
зависимости необходимо сразу рассматривать множества атрибутов в правой части.
Как показывает пример 3.45, иногда невозможно расчленить правые части много-
значных зависимостей на единичные атрибуты.
Пример 3 44 В примере 3.43 была введена многозначная зависимость, которая
в новом обозначении имеет вид
name -» street city
Здесь для каждого имени кинозвезды множество адресов появляется вместе с каж-
дым фильмом, в котором кинозвезда играла. В качестве примера применения мно-
гозначной зависимости рассмотрим первый и четвертый кортежи из рис 3.39.
пате street city | title year
Carrie Fisher 123 Maple St. Hollywood Star Wars 1S77
Carrie Fisher 5 Locust Ln Malibu Empire Strikes Back 1S80
128
Главе 3 Реляционные модели данных
Обозначим первый кортеж /. а второй и. Тогда из многозначной зависимости
следует, что в Л должен быть кортеж, который по имени Carrie Fisher, улице и городу
совпадает с первым кортежем, а по другим атрибутам (title и year) совпадает со вторым
кортежем. Такой кортеж действительно есть —это третий кортеж на рис 3 39.
Если обозначить первый кортеж и, а второй г, многозначная зависимость
определяет, что в Л должен быть кортеж, который совпадает со вторым кортежем
по атрибутам name, street и city, а с первым по атрибутам name, title и year Такой
кортеж тоже существует — это агорой кортеж па рис 3.39. □
3-8.3 Логические рассуждения
о многозначных зависимостях
Для многозначных зависимостей существуют правила, аналогичные правилам
для функциональных зависимостей из раздела 3.6
• Правим тривиальных зависимостей гласит, что если многозначная зависи-
мость Л, А.. А„-+* Вг Вг.. В„ истинна для некоторого отношения, то для
пего истинна и
Л| А2 ... А„ —» <?[ Сг ... Ск
где атрибуты С — это атрибуты .. , вместе с некоторыми атрибутами
Л|..А„ В обратном порядке можно также удалить атрибуты В.Вю, встре-
чающиеся среди атрибутов /lt,..., А„, и вывести многозначную зависимость
Af А>... Ал —кэ £)[ Dj... Dr
если £»|,.., Dr— это атрибуты, не встречающиеся среди атрибутов А.Ап.
• Правим транзитивности 1Ласит. что если истинны At А, Bt В2 — Вт
и S, В2 . Вп—>+ С( С2... Сь то истинна и
Л, А2 ... Л,,-» С[ С,... Ск
Однако для многозначных зависимостей нет правила расщепления/соедииения.
Пример 3.45. Рассмотрим отношение на рис. 3.39 с многозначной зависимостью
name -» street city
Если бы действовало правило растепления, зависимость
name -» street
гоже была бы истинной. Она означает, что улица из адреса каждой кинозвезды нс
зависит от других атрибутов, в том числе city. Но это угверждение ложно Рассмот-
рим, например, первые два кортежа на рис. 3.39. Гипотетическая .многозначная за-
висимость позволяет заключить, что в отношение входят кортежи, в которых улицы
взаимно заменены:
name street city i title year
Came Fisher 5 Locust Ln Hollywood ; Star Wars 1977
Came Fisher 123 Maple St. Malibu Star Wars 1977
Но это ложные кортежи, так как на самом деле дом 5 по Locust Ln. относится к
Malibu, а нс к Hollywood. □
3,8 Многозначные зависимости
129
Однако для многозначных зависимостей действует множество новых правил.
• Каждая функциональная зависимость является многозначной зависимостью,
если Л, Л2 А В Вг... В,„, то /1, Л2.. А„ —м- flt В.... В„.
Покажем, почему это верно. Пусть В — отношение, для которого истинна
функциональная зависимость Л, Л2 ... Л„-> Вх Вг... Вт, а / и и — кортежи R, совпада-
ющие по атрибутам /!,...Д,. Чтобы доказать, что истинна многозначная зависи-
мость
Л2, А„ й| В2 В„
нужно показать, что R содержит кортеж v, совпадающий с t и и по атрибутам
Д,.... Д,, с ! по атрибутам Вх,.... Вя и с и по всем остальным атрибутам. Кортеж v
вполне может быть кортежем и. Несомненно, что и совпадает с t и и по атрибутам
А..... А„. Согласно функциональной зависимости АХА2 .. А,,-+> В, Вг... В„,, кортеж и
совпадает с ! по атрибутам В,, .... В„, и, конечно же, и совпадает с самим собой по
всем остальным атрибутам. Следовательно, если истинна функциональная зависи-
мость, истинна и соответствующая многозначная зависимость.
Следующее правило дополнительности не имеет аналога в мире функциональ-
ных зависимостей.
• Если /1, А2 ... В1 В,.. В„, - многозначная зависимость для отношения R.
то R удовлетворяет зависимости Ах А,... С, С2... Ск, где все С, являются
атрибутами В, которые не встречаются ни среди Ах,..., А„, ни среди В,,..., Вт.
Пример 3.46. Рассмотрим отношение на рис. 3 39 с многозначной зависимостью
name -» street city
Согласно правилу дополнительности, для этого отношения должна быть истинной
и зависимость
name title year
так как атрибуты title и year не упоминаются в первой зависимости. С интуитивной
точки зрения вторая зависимость означает, что каждая кинозвезда снималась во
множестве фильмов, которое не зависит от ее адресов. □
3-8-4 Четвертая нормальная форма
Избыточность, показанную в разделе 3 8.1 и вызванную многозначными зави-
симостями, можно устранить, если применить эти зависимости в новом алгоритме
декомпозиции отношений В этом разделе вводится еше одна нормальная форма —
четвершя нормальная форма, в которой устраняются псе "нетривиальные" (смысл
этого определения раскрывается ниже) многозначные зависимости, как удалялись
все функциональные зависимости, нарушающие BCNF. В результате разложенные
О' ношения (см раздел 3.7 1) освобождаются от избыточности, вызванной и функ-
циональными, и многозначными зависимостями (см. раздел 3.8 1).
Многозначная зависимость Ах А... Л,,-» Вх Вг... В,„ для отношения R нетриви-
альна, если:
1. Ни один атрибут В, не входит в атрибуты Ах, .., А„
2 Л|. .... А„ и В], .... В„, не исчерпывают всего множества атрибутов
отношения R.
130
Глава 3 Реляционные модели данных
Условие "четвертой нормальной формы", по существу, является условием
BCNF. относящимся не к функциональным, а к многозначным зависимостям
Формально:
• Отношение Л находится в четвертой нормальной форме (4NF), если всегда,
когда многозначная зависимость
А,А,...Ап-^ В,В2.. В„
нетривиальна, И,, /13, .... А,,) — надключ.
Другими словами, если отношение находится в 4NT, любая нетривиальная
многозначная зависимость — это функциональная зависимость с надключом в левой
части Заметим, что понятия ключей и надключей связаны только функциональны-
ми зависимостями: многозначные зависимости не изменяют определение ключа.
Пример 3.47. Отношение на рис. 3 39 нарушает условие 4NF. Например, мно-
гозначная зависимость
пате ->-> street city
нетривиальна, но name нс является надключом. Фактически единственный ключ
для этого отношения — все его атрибуты. □
Четвертая нормальная форма — это обобщение BCNF. Любая функциональная
зависимость является многозначной зависимостью Значит, каждое нарушение
BCNF —это нарушение 4NF. Другими словами, всякое отношение в 4NF находится
в BCNF
Однако есть отношения, которые находятся в BCNF, но не в 4NF. Хороший
пример такого отношения приведен на рис. 3.39. Единственным ключом этого
отношения являются все атрибуты, и здесь нет нетривиальных функциональных
зависимостей. Таким образом, очевидно, что это BCNF, но не 4NF, о чем свиде-
тельствует пример 3.47.
3-8.5 Декомпозиция
в четвертую нормальную форму
Алгоритм декомпозиции 4NF примерно такой же, как алгоритм декомпозиции
BCNF. Мы находим нарушение 4NF, например А\ Л3... А„ Я, В2 . В„,
где {4 , А2,..., Л„) не является надключом. Заметим, что эта многозначная зависи-
мость может быть истинной многозначной зависимостью, а может быть выведена
из соответствующей функциональной зависимости Л]Л2..Л„-> В В2... В,„, так как
любая функциональная зависимость является многозначной Затем схему отноше-
ния Л, имеющую Нарушение 4NF, разбиваем на две схемы:
I. Атрибуты А,.Ап и атрибуты 51. В»,.
2 Атрибуты А,, .. А„ и все атрибуты Л, не совпадающие ни с Д, .. А„
ни с й|, В,„.
Пример 3.48. Продолжим пример 3.47 Установлено, что
name —» street city
нарушает 4NF. По правилу декомпозиции схему с пятью атрибутами нужно заме-
нить схемой с тремя атрибутами из указанной многозначной зависимости и схемой,
состоящей из ее левой части name и атрибутов, не входящих в данную зависимость
Такими атрибутами являются title и year В результате декомпозиции получаем схемы
3 8 Многозначные зависимости
131
{name, street city}
{name title, year}
Ни в одной из них нет нетривиальных многозначных (или функциональных) зави-
симостей. поэтому они находятся в 4NF. Заметим, что в отношении со схемой
{name, street, city} многозначная зависимость
name -» street city
тривиальна, так как она содержит все атрибуты. Аналогично в отношении со схе-
мой {name, t tie, year} многозначная зависимость
name title year
тривиальна. Если бы одна из схем или обе не были в 4NF, их пришлось бы разла-
гать дальше. □
t=i.к^-,— Л-.ТЛ — III I 4 111 I 1ИТП I I . I .....
I S
Построение проекций
многозначных отношений
Проводя декомпозицию в четвертую нормальную форму, нужно найти 1
| многозначные зависимости, которые истинны лля результата декомпозиции. |
! Такой поиск желательно упростить. Однако простого теста, аналогичного вы- I
числению замыкания множества атрибутов (см раздел 3 6.3), не существует
; Даже полное множество пранил логических рассуждений о множествах функ-
J циональных и многозначных зависимостей является очень сложным и выхо- |
> дит за рамки этой книги В списке литературы в конце главы указаны
5 некоторые источники, где обсуждается эта тема.
I К счастью, релевантные многозначные зависимости для одного из про-
дуктов декомпозиции часто можно найти с помощью правил транзитивности,
дополнительности и пересечения (упражнение 3.8.7(b)! Рекомендуем читателю
поработать с ними, анализируя примеры и выполняя упражнения.
Каждый шаг декомпозиции BCNF приводит к схемам, имеющим строго меньше
атрибутов, чем исходные, поэтому в конечном счете получаются схемы, которые
не нужно разлагать дальше, т.е. они находятся в 4NF. Более того, обоснование
декомпозиции, приведенное в разделе 3.7.6, подходит и для многозначных зависи-
мостей. Если декомпозиция отношения проводится согласно многозначной зависи-
мости
Л| ... -4„~» Bt В2... Вт
ег достаточно для обоснования того, что из результатов декомпозиции можно
восстановить исходное отношение.
3.8 6 Связи между нормальными формами
Как уже было сказано, 4NF влечет BCNF, а та, в свою очередь, 3NF. Значит,
для любой схемы отношений множества ее экземпляров, удовлетворяющие этим
трем отношениям, связаны так, как показано на рис. 3 41 Если множество корте
Жей удовлетворяет условию 4NF, оно обязательно удовлетворяет и двум другим
условиям нормальной формы, а если оно удовлетворяет BCNF, то обязательно на-
ходится в 3NF Однако при определенных функциональных зависимостях, установ
ленных для схемы, множества кортежей могут находиться в 3NF, но не в BCNF.
132
Глава 3 Реляционные модели данных
Другие множества кортежей при других функциональных зависимостях могут быть
в BCNF, но не в 4NF.
Рис. 3.41. 4NF влечет BCNF, которой влечет 3NF
Нормальные формы можно сравнивать также по гарантиям, которые они обес
печивают дця множеств отношений в нормальной форме, получающихся в резуль-
тате декомпозиции (рис. 3.42). BCNF (а значит, и 4NF) устраняет избыточность
и другие аномалии, вызванные функциональными зависимостями, тогда как 4NF
устраняет дополнительную избыточность, вызванную нетривиальными многознач-
ными зависимостями, не являющимися функциональными зависимостями. Часто,
но не всегда, для устранения такой избыточности достаточно 3NF Декомпозицию
в 3NF всегда можно выбрать для того, чтобы сохранить функциональные зависи-
мости: они внедряются в результирующие отношения (хотя такой алгоритм не об-
суждается в данной книге). BCNF не гарантирует сохранения функциональных
зависимостей, и ни одна из нормальных форм не гарантирует сохранения много-
значных зависимостей, хотя в типичных случаях они сохраняются
Свойство 3NF BCNF 4NF
Устраняет избыточность вследствие функциональной зависимости Большинство Да Да
Устраняет избыточность вследствие многозначной зависимости Нет Нет Да
Сохраняет функциональные зависимости Да Возможно Возможно
Сохраняет многозначные зависимости Возможно Возможно Возможно
Рис. 3.42. Свойство нормальных форм и их декомпозиции
3.8.7 Упражнения к разделу 3.8
* Впражнение 3.8-1. Пусть имеется отношение Я(/|, В, О с многозначной зави-
симостью Л-» В. Известно, что в текущий экземпляр R входят кортежи [а, />,, с(),
(о, /ъ. с:) и (л. b:„ с3). Какие еще кортежи должны входить в Я?
3 8 Многозначные зависимости
133
* Упражнение 3 8.2. Предположим, что есть отношение, в котором нужно запи-
сать имя человека, номер его страхового полиса и дату рождения имя, номер стра-
хового полиса и дату рождения его ребенка, а также серийный номер и марку его
машины. Точнее говоря это отношение имеет кортежи
(п, s, b, сп, cs, cb, as, ат)
1 л — имя человека с номером страхового полиса s.
2. Ь— дата рождения человека л.
3. сп — имя одного из детей л.
4. с.$ — помер страхового полиса сп.
5 ch — дата рождения сп.
6. ат—серийный номер автомобиля, принадлежащего л.
7 а/л — марка автомобиля с серийным номером аг.
Для этого отношения:
а) укажите функциональные и многозначные зависимости, которые можно
считать истинными;
Ь) проведите декомпозицию в 4NF.
Упражнение 3 8.3. Для каждой из следующих схем и зависимостей:
*а) /?(/, Д, С, D) с многозначными зависимостями А В и А -» С;
Ь) Я(Л, В, С, D) с многозначными зависимостями А ->> В и В -» CD;
с) R{A, В, С, D) с многозначными зависимостями АВ -г* С
и функциональной зависимостью D,
d) R(A, В, С, D, Е) с многозначными зависимостями А -н В, АВ -» С
и функциональными зависимостями А-э D и АВ~> Е
выполните следующее:
О найдите все нарушения 4NF;
ti) разложите отношения на множества отношений, находящихся в 4NF
I Упражнение 3.8.4. В упражнении 2.3.2 обсуждались четыре различных допуще-
ния об отношении Births. Для каждого из них укажите многозначные зависимости
(отличающиеся от функциональных), которые могут быть истинными в результиру-
ющем отношении.
Упражнение 3 8 5. Обоснуйте неформально, почему ни один из пяти атрибу-
тов в примере 3.43 функционально не определяется четырьмя остальными
1 Упражнение 3.8.6. С помощью определения многозначной зависимости пока-
жите. почему верно правило дополнительности.
1 Упражнение 3.8.7. Докажите следующие правила для многозначных зависи-
мостей:
*а) Правило объединения. Если X, ¥ и Z— множества атрибутов, Л-» Y
и X -» Z то X -» (У щ 2).
Ь) Правило пересечения. Если X, У и Z— множества атрибутов, Д'-» Y
и X -ь» Z. то X (У n Z).
134
Глава 3 Реляционные модели данных
с) Правило разности. Если X. Ун 7 — множества атрибутов X-э-> Y
и Л-н 7. то Л'-н (У— 2).
d) Тривиальные многозначные последовательности. Если Ус Л', то X->> У
истинно для любого отношения.
е) Другой источник тривиальных многозначных последовательностей.
Если Л'*.- У—это все атрибуты отношения Л, то А'-» У верно в R.
О Удаление атрибутов, входящих <? левую и правую часть. Если верно А'-» У,
то верно н А'-» (У- Д').
! Упражнение 3.8.8. Приведите примеры противоположных отношений, пока-
зывающие. что следующие правила для многозначных зависимостей не верны
♦а) Если А -н ВС, то А •» В
Ь) Если А -н- В, то А —> В.
с) Если АВ~+ь С, то Л-*» С.
1 Упражнение 3.8.9. При преобразовании из ODL в отношения часто возникают
многозначные зависимости. Сформулируйте принципы извлечения многозначных
зависимостей из многозначных атрибутов и связей при применении стратегии
построения схем отношений, описанной в разделах 3.2.2 и 3 2.5
3.9 Пример схемы БД
Рассмотрев проблемы, которые могут возникнуть при построении отношений
непосредственно из ODL или Е/R проектов, и методы устранения аномалий, при-
мем единственную схему реляционной БД, которую будем использовать в примерах
следующей части книги, посвященной программированию БД пользователем.
Схема БД составлена из примеров о фильмах, кинозвездах и студиях. В ней
используются нормализованные отношения, аналогичные тем, которые были
построены в предыдущих разделах Однако здесь есть также атрибуты и одно отно-
шение, MovieExec, которые не встречались в предыдущих примерах. Цель таких
изменений — обеспечить возможность изучения различных типов данных и разных
способов представления информации в примерах 4 — 8 глав. Схема БД приведена
на рис. 3.43.
В схеме пять отношений. Атрибуты каждого отношения приведены вместе
с предполагаемой областью каждого атрибута. Ключевые атрибуты отношения здесь
написаны прописными буквами, при ссылках на них в тексте они будут набраны
строчными буквами, как и прежде. Например, все три атрибута составляют ключ
отношения Starsin. Отношение Movie имеет шесть атрибутов; title и year, как и
прежде, составляют ключ для Movie. Атрибут title — строка, a year — целое число
В схему внесены следующие новшества:
• Введено понятие номера сертификата для производителей фильмов — пре-
зидентов студий и продюсеров Сертификат — это уникальное целое число,
которое находится во внешнем ведении, например регистратуры или проф-
союза
• Номера сертификатов используются в качестве ключа для производителей
фильмов, хотя кинозвезды не всегда имеют сертификаты и в качестве ключа
для них по-прежнему используется name. Такое решение вряд ли возможно
в действительности, поскольку иногда у двух звезд бывает одно и то же имя,
но мы избрали такой путь, чтобы показать различные варианты выбора
3.9 Пример схемы БД
135
Movie(
TITLE, string.
YEAR integer,
length integer,
inColor- boolean,
stud oName: string,
producers#: integer)
Starsln(
MOVIETITLE: string,
MOVIEYEAR Integer,
STARNAME- string)
MovieStarf
NAME: string,
address: string,
gender, char,
birthdate date)
MovieExec(
name string,
address: string,
CERT#, integer,
netWorth: integer)
Stud o(
NAME: string,
address: string,
presC#: integer)
Рис. 3.43 Пример схемы БД о фильмах
• Продюсер введен в качестве одного из свойств фильма Эта информация
представлена новым атрибутом producerC# отношения Movie. Предполагается,
что этим атрибутом является номер сертификата продюсера. Продюсеры - это
производители фильмов, как и президенты студий. В отношении MovieExec
могут быть и другие производители.
• Атрибут filmType отношения Movie, имеющий тип "перечисление', заменен
на булев атрибут InColor. Он истинен, если фильм цветной, и ложен, если
фильм черно-белый. Причина изменения в том, что не все языки БД под-
держивают перечисляющие типы.
• Для кинозвезд, играющих в фильме, добавлен атрибут gender Его типом
является 'буква”: М для мужчин и F для женшин. Добавлен также атрибут
birthdate типа "дата' (специальный тип, поддерживаемый большинством
коммерческих систем БД. или, если угодно, строка символов).
• Все адреса сделаны не парами, а строками, состоящими из улицы и города.
Цель изменения — упростить сравнение адресов разных отношений и вы
полнение операций с ними.
136
Гпава 3 Реляционные модели данных
В заключение краткий комментарий этих пяти отношений, их атрибутов и их
выводов из ODL или E/R-проектов.
1. Movie — одно из отношений, полученных в результате декомпозиции от-
ношения Movie в примере 3.36, к которому добавлен атрибут producerC#,
представляющий производителя фильма.
2. Starsln — второе отношение, полученное при декомпозиции в примере 3.36.
Это же отношение необходимо, если отношение Star строится непосред
ственно из класса ODL с таким же именем, а затем переводится в BCNF
Начиная с определения ODL. приведенного на рис. 2.5. мы получаем
отношение Star с атрибутами name, address, title и year. Последние два из
них представляют связь starredln. Множество {name, title, year) является
ключом, a name -к address функциональной зависимостью. Поэтому
данное отношение разлагается на схемы {name, address) (расширенную до
отношения Moviestar) и {name, title, year) (являющуюся по существу отно-
шением Starsln). Отношение Starsln представляет также связь Stars-in из
E/R-диаграммы, изображенной на рис. 2.8.
ЗЛО Итоги
+ Реляционная модель. Отношения — это таблицы, содержащие информацию.
Столбцы таблицы озаглавлены атрибутами; с каждым из них связана область
значений, иди тип. Строки таблиц называются кортежами. Кортеж имеет
один компонент для каждого атрибута отношения.
+ Схемы. Имя отношения и его атрибуты составляют схему отношения. Мно-
жество схем отношений образует схему БД. Отдельные данные для отноше-
ния, или множества отношений, называются экземпляром реляционной
схемы или схемы БД.
+ Преобразование множества сущностей в отношения. Отношение для множества
сущностей содержит один атрибут для каждого атрибута множества сущно-
стей. Исключением является слабое множество сущностей £. Его отношение
должно содержать также атрибуты для ключевых атрибутов тех множеств
сущностей, которые позволяют идентифицировать сущности множества Е.
+ Преобразование связей в отношения. Отношение для E/R-связи имеет атрибу-
ты, соответствующие ключевым атрибутам каждого множества сущностей,
участвующего в этой связи.
> Преобразование классов ODL в отношения. Отношения для ODL-класса С со-
держит один атрибут для каждого атрибута этого класса. Оно может иметь
также атрибуты для ключа класса D, с которым связан класс С Поскольку
связи ODL имеют обращения, рекомендуется хранить связи С с D типа
""многие-к-одному' вместе с множеством С. а не D.
♦ Преобразование ODL-связей типа "многие-ко-многим". Связи типа "многие
ко-многнм" можно хранись вместе с любым классом, но они ведут к резкому
увеличению числа кортежей в отношении Этот недостаток реляционного
проекта можно устранить в процессе нормализации ODL связи типа
"многие-ко-многим" можно, кроме того, представить отдельным отношением
так, как будто они находятся в E/R-модели.
3.10 Итоги
37
+ Преобразование подклассов в отношения. Один из подходов состоит в распре-
делении сущностей или объектов на множестве подклассов и создании отно-
шения со всеми атрибутами, необходимыми для каждого подкласса. Другой
подход — представить все сущности или объекты в главном отношении,
которое содержит лишь атрибуты наиболее общего класса. Сущности или
объекты из подклассов также содержатся в специальных отношениях для
этих подклассов. Эти отношения содержат только ключевые атрибуты для
общего класса и особые атрибуты конкретного подкласса.
+ Функциональные зависимости Представляют собой утверждение о том, что
два кортежа, совпадающие по конкретному множеству атрибутов должны
совпадать и по другому отдельному атрибуту.
♦ Ключи. Надключ для отношения — это множество атрибутов, функционально
определяющее все остальные атрибуты отношения. Ключ —это такой над-
ключ, при котором ни одно собственное подмножество ключа функциональ-
но не определяет все атр1 буты.
♦ Логические рассуждения о функциональных зависимостях. Существует множе-
ство правил, позволяющих заключить, что одна функциональная зависи-
мость X —> А содержит в любом экземпляре отношения, удовлетворяющие
другому заданному множеству функциональных зависимостей. Самый про-
стой метол подтверждения истинности Х^А обычно заключается в том,
чтобы вычислить замыкание X. применяя заданные зависимости для расши-
рения X до тех пор. пока в него не войдет А.
♦ Декомпозиция отношений. Можно разлагать одну схему отношения на две без
потери информации до тех пор пока атрибуты в обеих новых схемах состав
ляют надключ по крайней мере для одного из разлагаемых отношений.
♦ Нормальная форма Бойса-Кодда (BCNF). Отношение находится в BCNF, если
единственно возможные нетривиальные зависимое™ гласят, что некоторый
надключ функционально определяет один из остальных атрибутов. Любое
отношение можно разложить на множество отношений в BCNF без потери
информации. Основное достоинство BCNF в том, что она устраняет избы-
точность, вызванную существованием функциональных зависимостей
+ Третья нормальная форма Иногда декомпозиция в BCNF может предотвра-
тить проверку определенных функциональных зависимостей. Ослабленная
форма BCNF, называемая 3NF, допускает функциональную зависимость
.¥-> А. даже если X нс 51вляется надключом, при условии что А — шен неко-
торого ключа. 3NF не всегда, но довольно часто устраняет все избыточности,
связанные с функциональными зависимостями.
+ Многозначные зависимости. Представляют собой утверждение о том, что два
множества атрибутов в отношении имеют множество значений, появляю-
щихся во всех возможных комбинациях Общая причина возникновения
многозначных зависимостей — построение отношения для представления
ODL-класса с двумя ил! более многозначными атрибутами или связями.
+ Четвертая нормальная форма. Многозначные зависимости могут вызывать
избыточность в отношении. 4NF похожа на BCNF, но, кроме того, запрета
ет нетривиальные многозначные зависимости (если только они нс являются
реальными функциональными зависимостями, допускаемыми BCNF). Мож-
но разложить отношение на 4NF без потери информации.
138
Глава 3 Реляционные модели данных
3-11 Литература к главе 3
Классической статьей Коша (Codd) по реляционным моделям является [4].
посвященная и-тсс функциональных зависимостей и основным реляционным поня-
тиям. Здесь же рассматривается третья нормальная форма, а нормальная форма
Бойса-Кодла описана Кодлом в более поздней статье |5|.
Многозначные зависимости и четвертая нормальная форма были определены
Фэджннем (Fagin) в |7|. Однако совершенно сан остоятельный подход к теме
многозначных зависимостей прослеживается в (б| и |9].
Армстронг (Ariiistrong) первым исследовал правила выведения функциональ-
ных зависимостей в |1]. Рассмотренные в данной книге правила (включая аксиомы
Армстронга) и правила выведения многозначных зависимостей взягы из |2]. Техно
ка тесл ровання функциональной зависимости путем вычисления замыкания мно-
жества атрибутов заимствована из (3]
Существует ряд алгоритмов н/нли доказательств того, что алгоритм работает,
которые нс приведены а этой книге. К ним относятся объяснения того почему
действует алгоритм замыкания для выведения функциональных завис! мостей, как
выводится многозначные зависимости как онн проецируются на разлагаемые отно-
шения и как провести декомпозицию в 3NF, не утратив возможности проверять
функциональные зависимости Эти и другие вопросы, касающиеся зависимостей,
анализируются в [8].
1 . Armstrong W W “Dependency stmetures of da abase relationships'. Proceedings
of the 1974 /HP Congress, pp. 580-583
2 Been. C., R Fagin and J. H Howard, "A complete axiomatization for functional
and multivalued dependencies”, ACM S/GMOD International Conference on
Management of Data, pp 47-61, 1977.
3 . Bcrnsiein. P A, "Synthesizing third normal form relations from functional
dependences", ACM /ransacnons on Database Systems 1 4, pp 277 298 1976.
4 Codd. E. F, "A relational model for large shared data banks". Comm ACM 13 6.
pp. 377-387, 1970.
5 Codd E F, "Funher normalization of the data base relational model", in
Database Systems (R. Rustin. ed.), Prentice-Hall, Eng ewood Cliffs, NJ, 1972.
6 Delobel C "Normalization and h erarchical dependencies in the relational data
model". ACM Transactions on Database Systems 3:3, pp 201-222. 1978
7 Fagin, R “Mulmalued dependencies and a new normal form for relational
databases', ACM Transactions on Database Systems 2.3 pp 262-278, 1977.
8 . Ullntnti. J. D., Principles of Database and Knowledge-Rase Systems, lokime I,
Computer Science Press Neu York. 1988
9 . Zamolo, C and M A Melkanoff. "On the design of relational database
schemata". ACM Transactions on Database Systems 61, pp 1-47, 1981.
Глава 4
Операции
в реляционной модели
В этой главе мы приступаем к изучению БД с точки зрения пользователя
Обычно главное для пользовате я — запросы к БД, т.е. написание программ, отвеча-
ющих на вопросы о текущем состоянии БД. В этой главе проблема запросов к БД
рассматривается абстрактно; здесь определяются основные операторы запросов.
В то время как ODL применяет методы, которые в принципе позволяют
выполнить любую операцию над данными, а E/R-модель не заключает в себе спе-
цифического способа манипулирования данными, реляционная модель содержит
конкретное множество стандартных операций над данными. Поэтому при анализе
работы с БД мы сосредоточимся на реляционной модели и ее операциях, которье
можно выразить в алгебре назь ваемой реляционной алгеброй, или в виде логики
обозначенной Datlog. В данной главе рассматриваются обе эти нотации
В последующих главах мы обратимся к языкам и средствам, которые в настоя-
щее время предлагают пользователю коммерческие системы БД Абстрактные опе-
раторы запросов впервые появятся в виде операций языка запросов SQL, о котором
речь пойдет в главах 5 - 7, а затем в языке OQL в главе 8.
4.1 Алгебра реляционных операций
Приступая к изучению операций на отношениях, нужно познакомиться со
специальной алгеброй - реляционной. Она состон из простых, но мощных методов
конструирования новых отношений из уже имеющихся Выражения реляционной
алгебры начинаются < отношений в качестве операндов Отношения представляются
их именами (например, Л или Movie) или явно, в виде списка их кортежей. Затем
можно последовательно сгроить сложные выражения, применяя любые описанные
ниже операторы к отношениям или к более простым выражениям реляционной
алгебрь Запрос- это выражение реляционной алгебры. Таким образом реляшюн
ная алгебра - первый конкретный пример языка запросов.
Операции реляционной алгебры делятся на че ыре распространенных класса.
I. Обычные теоретике множественные операции объединение, пересечение
и разность, примененные к отношениям.
2. Операции удаления частей отношения- "отбор”, удаляющий некоторые
строки (кортежи), и "проекция”, удаляющая некоторые столбцы.
3. Операции комбинирования кортежей двух отношений включая "декарто-
во произведение” (образование пар кортежей двух отношений всеми воз-
можными способами) и множество видов "ссели! ения" - выборочного
образования пар кортежей двух отношений
МО
Глава 4 Операции в реляционной модели
4. Операция "переименования", которая не влияет на кортежи отношения,
но изменяет реляционную схему, т.е. имена атрибутов и/или имя самого
отношения.
Для выполнения всех возможных вычислений на отношениях этих операций
недостаточно: их действие весьма ограничено. Однако они позволяют сделать
многое из того, чю необходимо делать с БД и, как будет показано в главе 5,
составляют боль пую часть с андартного реляционного языка запросов SQL.
В разделах 4 6 н 4.7 мы рассмотрим также средства вычисления, которые имеются
в 1>еальных языках запросов типа SQL, но при этом не являются частью реляцион-
ной алгебры
4-1.1 Теоретико-множественные операции
на отношениях
Наиболее распространенные операции множеств — объединение, пересечение
и разность. Для произвольных множеств Я и S' они определяются следующим
образом.
• Яи 5, объединение Я н S— это множество элементов, входящих или в Я, или
в S, «ли в оба множества. Элемент входит в объединение только один раз,
таже если он входит и в Я, и в S
• RmS, пересечение Я п S— это множество элементов, входящих и в Я, и в S’.
« Я - 5, разность Я и S’— это множество элементов, которые входят в Я, но
не входят в S'. Заметим, что R - S отличается от S - Я; второе выражение
обозначает множество элементов, входящих в S', но не входящих в Я.
При применении этих операций к отношениям необходимо соблюдать ряд
условий.
I. Я и S'должны иметь схемы с идентичными множествами атрибутов.
2. Перед вычислением теоретико-множественного объединения, пересечения
или разности множеств кортежей столбцы Я и S должны быть расположе-
ны так, чтобы порядок атрибутов был одинаков в обоих отношениях.
Иногда нужно вычислить объединение, пересечение или разность отношений,
имеющих одинаковое число атрибутов с различными именами. В таком случае при-
меняется оператор переименования (см. раздел 4.1.8) дгя изменения схемы одного
или обоих отношений.
пате : address . gender ! birthdate
Carrie Fisher i 123 Maple St., Hollywood j Ff I 9/9/99
Mark Hamill 456 Oak Rd., Brentwood M 1 8/8/88
Отношение Я
name address I 1 gender j birthdate
Carrie Fisher i 123 Maple St. Hollywood . F • 9/9/99
Harrison Ford | i 789 Palm Dr. Beverly Hills 1 ' M | 7/7/77
Отношение S
4.1 Алгебра реляционных операций
141
Пример 4.1. Рассмотрим два отношения Л и 5, экземпляры отношения
Moviestar из раздела 3.9 Текущие экземпляры /? и 5 показаны на рис 4.1 Объели
пение Я и 5'
пате address gender birthdate
Came Fisher 123 Maple St., Hollywood F 9/9/99
Mark Hamill 456 Oak Rd., Brentwood M 8/8/88
Harrison Ford 789 Palm Dr Beverly Hills M 7/7/77
В результате кортеж для Кэрри Фишер, входящий в оба отношения, появляется
всего один раз.
Пересечение ЙГ15:
name address gender birthdate
Came Fisher 123 Maple St., Hollywood F 9/9/99
Здесь появляется только кортеж для Кэрри Фишер, поскольку только он входит
в оба отношения.
Разность R - S:
name I | address gender birthdate
Mark Hamill | 456 Oak Rd., Brentwood M 8/8/88
Кортежи для Фишер и Хэмилла входят в Л, поэтому являются кандидатами
для Л - 5 Но кортеж для Фишер входит и в 5, поэтому его нет в R - S.
4.1-2 Проекция
Оператор проекции применяется к отношению R для получения нового отношения,
содержащего только некоторые столбцы R. Значение выражения пл А.л. (Я) это
отношение, содержащее только столбцы Л,, Л,..., А„ отношения Я. Схема результи-
рующего значения — это множество атрибутов {/!,, Аг,А,,}, которое обычно пока-
зывается в порядке перечисленных атрибутов.
title year length inColor studioName producerC#
Star Wars 1977 124 true Fox 12345
Mighty Ducks 1991 104 true Disney 67890
Wayne’s World 1992 95 true Paramount 99999
Рис. 4.2. Отноше1 ие Movie
Пример 4.2. Рассмотрим отношение Movie со схемой, приведенной в разделе 3.9
Экземпляр этого отношения показан на рис. 4.2. Его можно проецировать на три
первых атрибута с помощью выражения
year, leiiglh (Mo е
142
Глава 4 Операции в реляционной модели
В результате получается отношение
title year ; length
Star Wars ' 1977 124
M ghty Ducks 1991 ( 104
Waynes World , 1992 j 95
В качестве другого примера можно взять проекцию на атрибут inCoor с помощью
выражения nmfWir(Movie). В результате получается отношение с единственным
столбцом:
mColor
true
Заметим, что в нем только один кортеж, так как все три кортежа на рис. 4.2 имеют
одно и то же значение своих компонентов для атрибута inColor □
4.1.3 Отбор
Оператор отбора, примененный к отношению R, даст новое отношение с под-
множеством кортежей R. Кортежи нового отношения удовлетворяют некоторому
условию С, включающему в себя атрибуты R. Операция отбора обозначается ос(Я).
Схема результирующего отношения совпадает со схемой R, и атрибуты в пей обыч-
но показаны в том же порядке, в каком они входят в R.
С- выражение условного типа Такие выражения применяются в обычных
языках программирования. Например, в языках С или Pascal условное выражение
следует за ключевым словом if Единственное различие состоит в том, что операнды
в С— это константы или атрибуты Я. Оператор С применяется к каждому кортежу г
отношения Я: при этом каждый атрибут Л, входящий в условие С, заменяется ком-
понентом кортежа t для атрибута Л. Если после таких подстановок вместо каждого
атрибута С это условие истинно, то кортеж t включается в результат ос(Я); в про-
тивном случае он в результат не входит.
Пример 4.3. Рассмотрим отношение Movie, показанное на рис. 4.2. Значением
выражения a/ras</, . юо (Movie) является отношение
title year length inColor studioName producerC#
Star Wars i 1977 124 true Fox 12345
Mighty Ducks 1991 104 true Disney i 67890
Первый кортеж удовлетворяет условию length's так как при подстановке
вместо length значения 124 найденного в компоненте первого кортежа для атрибута
ength, условием станет выражением 124 > 100 Оно истинно, поэтому первый
кортеж принимается Точно гак же можно объяснить, почему входит в результат
второй кортеж из рис. 4 2.
Компонент length третьего кортежа - 9э. Поэтому после подстановки получает-
ся ложное условие 95 > 100 и этот кортеж не включается в результат- □
Пример 4.4. Допустим, что в отношении
Movie(title, year, length. inColor studioName. producers#)
4.1 Алгебра реляционных операций 143
нужно выбрать множество кортежей, представляющих фильмы студии Fox, которые
длятся не менее 100 мин. Для того чтобы получить это более сложное условие,
применим связку AND к двум подусловиям:
100 ANDjwrteA'F«W*’FoX (Mo te
и отноше не с единственным кортежем
title _______i year I length inColor | studioName i producerC#
Star Wars : 1977 I 124 j true Fox i 12345 □
4.1.4 Декартово произведение
Декартово произведение (или просто произведение) двух множеств R и 5—это
множество пар причем первым элементом каждой пары является элемент множе-
ства R, а вторым — элемент множества 5. Произведение обозначается Ry. S. Если R
и 5 — отношения, их произведение, по существу, остается таким же. Но поскольку
членами R н 5 являются кортежи, состоящие обычно из нескольких компонентов,
в результате соединения кортежа из Л с кортежем из S получается более длинный
кортеж, содержащий по одному компоненту для каждого компонента кортежей,
составляющих данную пару. При этом компоненте, из Я предшествуют компонен-
там из S’,
Реляционная схема для результирующего отношения — это объединение схем
для R и S'. Если же R и S’ имеют какие-то общие атрибуты, необходимо ввести
новое имя по крайней мере для одного атрибута из каждой пары идентичных
атрибутов. Чтобы уточнить, откуда взят атрибут /, входящий в схемы Л и 5, мы
пишем R.A для атрибута из R и 5.Z для атрибута из S’.
А В
1 2
3 4
Отношение R
В С О
2 5 6
4 7 8
9 10 11
А RB S.B С D
1 2 2 5 6
1 2 4 7 8
1 2 9 10 11
3 4 2 5 6
3 4 4 7 8
3 4 9 10 11
Рис. 4 3 Два отношений и иг денар ово произведение
Отношение 5
Произведение R> S
144
Глава 4 Операции в реляционной модели
Пример 4.5. Рассмотрим абстрактный пример операции декартова произведе-
ния. Пусть R и 5 имеют схемы и кортежи, показанные на рис. 4 3, Тогда произве-
дение Ях 5 состоит из шести кортежей. Обратите внимание на то, как соединяются
в пары каждый нз двух кортежей Л с каждым из трех кортежей 5. Поскольку В вхо-
дит в обе схемы, в схеме Rx S используются R.B и S.B. Другие атрибуты безопасны,
и их имена входят в результирующую схему без изменений □
4.1.5 Натуральное соединение
Произведение двух отношений требуется далеко не всегда. Чаще нужно соеди-
нить их, создавая пары только из тех кортежей, которые по каким-то параметрам
соответствуют друг другу. Простейшим видом соответствия является натуральное
соединение двух кортежей Л и 5, обозначаемое RtxiS, в котором соединяются
кортежи R и S, совпадающие по любым атрибутам, входящим и в Я, и в S. Пусть
А,. Л../1„— атрибуты, входящие и в схему Я, и в схему 5. Тогда кортеж г из Я и
кортеж з из 5 соединяются в пару, если и только если г и s совпадают по каждому
из атрибутов Л,, Л2,А„.
Если кортежи г и з успешно соединены в объединении Ям5, результатом
является кортеж, называемый соединенным кортежем^ с компонентами для каждого
из атрибутов в объединении схем Я и 5. Соединенный кортеж совпадает с корте-
жем г по каждому атрибуту из схемы Я и совпадает с s по каждому атрибуту, входя-
щему в схему 5. Поскольку г и s успешно соединены, они совпадают по атрибутам,
входящим и в схему Я, и в схему 5. Значит, соединенный кортеж может совпадать
с г и .V по атрибутам, входящим в обе схемы. Конструкция соединенного кортежа
показана на рис. 4.4.
R
---------------- s
Рис. 4.4. Соединение кортежей
Заметим, что эта операция соединения совпадает с той, которая применялась
в разделе 3.7.6 для воссоединения отношений, проецированных на два подмножест
ва атрибутов. Гам соединение использовалось для объяснения смысла декомпози-
ции BCNF. 13 разделе 4.L7 будет показано другое применение натурального
соединения — комбинирование двух отношений, позволяющее написать запрос,
относящийся к атрибутам каждого из них
Пример 4.6. Натуральное соединение отношений Я и 5 из рис. 4.3.
XI | б ' С I jD
1 ! 2 i 5 "7 6
3 4 | 7 | 8
4.1 Алгебра реляционных операций
145
Здесь В — единственный общий для R и 5 атрибут. Поэтому для успешного соедине
ния кортежи должны совпадать только по компонентам В. В этом случае результиру-
ющий кортеж имеет компоненты для атрибутов А (из Я), В (из R или 5) и D (из 5).
В этом примере первый кортеж В успешно соединяется только с первым
кортежем S; их общий атрибут В имеет значение 2. Так получается первый кортеж
результата (1,2, 5, 6). Второй кортеж Rуспешно соединяется только со вторым кор-
тежем 5. В результате получается кортеж (3,4,7, 8). Заметим, что третий кортеж 5
не соединяется ни с одним кортежем Я и не оказывает никакого влияния на резуль-
тат Кортеж, который невозможно соединить ни с каким кортежем другого
отношения, иногда называется висящим кортежем. □
Пример 4.7. Предыдущий пример не иллюстрирует всех возможностей натураль-
ного объединения. В нем каждый кортеж успешно соединяется только с одним
кортежем и две схемы отношений имеют только один общий атрибут. На рис 4.5
показаны отношения (/икс двумя общими атрибутами В и С. В этом случае один
кортеж соединяется с несколькими кортежами.
Для успешного соединения кортежи должны совпадать по компонентам В и С.
Значит, первый кортеж U успешно соединяется с двумя первыми кортежами К
а второй и третий кортежи I/-с третьим кортежем К Результат этих операций
тоже показан на рис 4 5. □
Отношение U
Рис. 4.5. Нотурольное соединение отношений
Отношение У
Результат (/tx V
4.1.6 Тета-соединения
Натуральное соединение вынуждает соединять кортежи только при одном
специфическом условии Хотя совпадение атрибутов — это наиболее общий базис
объединения отношений, иногда желательно соединять кортежи двух отношений на
другом основании. Для этой цели и служит понятие тета соединение. Тета озна-
чает произвольное условие, которое мы будем обозначать буквой С, а не 0.
146
Глава 4 Операции в реляционной модели
Тета-соедпнение отношений Л и 5’, основанное на условии С, обозначается
как S. Результат этой операции получается следующим образом.
I Берется произведение Л и S’.
э. Нз полученного произведения выбираются только те кортежи, которые
удовлетворяют условию С.
Как н при операции произведения, схема результата - это объединение схем А
п 5, в котором префиксы "R." и "S'." используются, чтобы указать, нз какой схемы
взят данный атрибут.
Пример 4.8. Рассмотрим операцию Ut*>A<D И где U и И- отношения из рис. 4.5.
Необходимо рассмотреть нее девять пар кортежей и проверить, действительно ли
компонент А кортежа из U меньше компонента D кортежа из И Компонент А
первого кортежа из U равен 1 н успешно соединяется с каждым кортежем из И
Однако второй и третий кортежи из U с компонентами А, равными 6 и 9, успешно
соединяются только с последним кортежем V Значит, результат содержит только
пять кортежей, построенных с помощью пяти успешных соединений в пары. Это
отношение показано па рис. 4.6. □
А U.B U.C V В V.C D
1 2 3 2 3 4
1 2 3 2 3 5
1 2 3 7 6 10
6 7 8 7 8 10
9 7 8 7 8 10
Рис. 4.6. Результат 6'txl, р К
Заметим что схема результата содержит все шесть атрибутов. Префиксы Uh V
позволяют различить соответствующие им вхождения атрибутов В и С. Таким обра-
зом, тета соединение отличается от натурального соединения, так как в последнем
общие атрибуты смешаны в одной копии. Конечно в натуральном соединении это
уместно, поскольку кортежи нс соединяются, если они не совпадают по общим
атрибутам. В случае тета-соединения нет гарантии, что сравниваемые атрибуты
в результате совпадут, так как оператором сравнения необязательно является =.
Пример 4.9. Рассмотрим тета-соединение отношений U и И с более сложным
условием:
U^A<I> ANO U.B-I.В
Для успешного соединения в пары требуется не только, чтобы компонент А
из кортежа U был меньше компонента D из кортежа У, но и чтобы два кортежа
различались по своим компонентам, соответствующим В. Обоим этим условиям
удовлетворяет только один кортеж, поэтому результатом такого тета-соединения
будет отношение
А i и.в I и.с ! VB V.C i 1 D
1 " Г 2 ! 3 | 7 8 1 10
4.1 Алгебра реляционных операций
147
4-1.7 Комбинирование операций
для построения запросов
Если бы в качестве запроса разрешалось писать только единичные операции
на одном или двух отношениях, от реляционной алгебры было бы мало пользы.
Однако она, как и все алгебры, позволяет строить выражения произвольной слож-
ности путем применения операторов к заданным отношениям или к отношениям,
уже полученным в результате применения операторов.
Выражения реляционной алгебры можно строить, применяя операции к под-
выражениям и при необходимости выделяя скобками группы операнд. Выражения
представляются в виде дерева, чтобы их легче было прочесть, хотя они меньше
подходят в качестве нотации для машинного чтения.
Пример 4.10. Рассмотрим декомпозированное отношение Movie из примера 3.32
Допустим, нужно узнать названия и годы выпуска фильмов студии Fox, которые
длятся более 100 мин Это можно вычислить следующим образом.
1. Выбрать кортежи Movie, имеющие length >100.
2. Выбрать кортежи Movie, имеющие nludioName = 'Fox'
3 Вычислить пересечение (1) и (2),
4. Построить проекцию отношения из пункта (3.) на атрибуты title и year.
На рис. 4 7 эти четыре шага изображены в виде дерева выражений. Два узла
отбора соответствуют шагам (1) и (2) Узел пересечения соответствует шагу (3), а
узел проекции шагу (4).
title, year
СУlength к 100 <5studioName —'Fox'
Movie Movie
Рис. 4.7. Дерево выражений для выражений реляционной алгебры
Это же выражение можно представить в обычной линейной нотации со скоб-
ками, а именно, в виде формулы
ttfiite.reor ^tengiht (оо (Movie) гт ст5йи^вуят,е.ром. (Movie))
Часто одно и то же вычисление можно представить несколькими выражениями
реляционной алгебры. Например, вышеприведенный запрос можно написать, заме-
нив пересечение логической связкой AND с единственной операцией выбора:
‘^mte.yva - 100 AND ‘Fcx* (MOVI©) )
В результате получается запрос, эквивалентный исходному □
148
Глава 4 Операции в реляционной модели
Пример 4.11. Оператор натурального соединения применяется для восстановле-
ния отношений, которые были декомпозированы для приведения в BCNF. Напом-
ним декомпозированное отношение из примера 3.32:1
Moviel со схемой {title, year, length, filmType, studioName}
Movie2 co схемой {title, year, starName)
Запишем выражение для ответа на запрос: найти кинозвезд, играющих в филь-
мах, которые длятся больше 100 мин. Этот запрос связывает атрибут starName
отношения Moviel с атрибутом length отношения Movie2. Атрибуты можно связать,
соединив два данных отношения. Натуральное соединение успешно соединяет
в пары только кортежи, совпадающие по атрибутам title и year, т.е. относящиеся
к одному и тому же фильму. Значит, Moviel X Movie2 — выражение реляционной
алгебры, порождающее отношение, названное Movie в примере 3.32. Оно не нахо-
дится в BCNF, а его схема состоит из шести атрибутов и содержит несколько кор-
тежей для одного и того же фильма, когда в нем играет несколько кинозвезд.
К соединению Moviel и Movie2 необходимо применить оператор отбора с усло-
вием, согласно которому длина фильма не превышает 100 мин. Затем строится
проекция на требуемые множества атрибутов title и year. Рассматриваемый запрос
принимает вид выражения реляционной алгебры
loo (Moviel м Movie2}) □
Эквивалентные выражения
и оптимизация запросов
Все системы БД включают в себя системы ответов на запросы, многие из
которых основаны на языках, по своей выразительности равных реляционной
алгебре. Поэтому запрос пользователя может иметь множество эквивалентных
выражений (выражений, дающих один и тот же ответ, когда в них в качестве
операнд используются одни и те же отношения). Некоторые из них можно
оценить намного быстрее, чем другие. Важной задачей оптимизатора запросов,
кратко рассмотренного в разделе 1.2.3, является замена выражения реляцион-
ной алгебры эквивалентным выражением, которое оценивается более эффек-
тивно.
4.1.8 Переименование
Контроль за именами атрибутов, используемых в отношениях, которые
построены с помощью одной или нескольких операций реляционной алгебры, по-
1езно осуществлять с помощью оператора, явным образом переименовывающего
отношения. Для переименования отношения R будем использовать оператор
Рти j. _« ,(Л)- Результирующее отношение имеет в точности те же кортежи, чго
л «с именем отношения 5. Его атрибуты получают имена /t, 4г, ....Л„ в порядке
слева направо Если нужно изменить только имя отношения, но не его атрибутов,
можно писать просто р.г(Л)
1 Учтите, что схема отношения Move того примера отличалась от реляционной схемы
Movie^ введенной^! разделе 3.9 и использованной в примерах 4.2, 4.3 и 4.4.
4.1 Алгебра реляционных операций
149
Пример 4.12. В примере 4.3 мы брали произведение отношений Л и 5 из рис 4.3
и следовали соглашению, что при появлении атрибута сразу в обеих операндах он
переименовывается префиксированием ему имени отношения. Эти отношения Я и 5
повторяются далее на рис. 4 8
Предположим, однако, что мы не хотим называть аве версии В именами R.B
и S.B, а хотим использовать имя В для атрибута, происходящего из /?, и имя X
для атрибута, происходяшего из £ Тогда можно переименовать атрибуты 5 так,
чтобы первый из них имел имя X. Результат выражения рЙЛ с D)(S) -это таблица
с именем S, которая выглядит точно так же, как и таблица S из рис. 4.3 но в ее
первом столбце вместо атрибута 5 находится атрибут X.
Когда берется произведение Л с этой новой таблицей, конфликта имен атрибу-
тов не возникает, поэтому дальнейшее переименование не производится Таким
образом результат выражения R х р.ад с. D) (5) - это отношение Ях 5 из рис. 4.3, за
исключением того, что пя!Ь его столбцов отмечены буквами А В, X С и D слева
направо. Это отношение изображено на рис. 4.8.
Отношение R
Рис. 4.8. Две отношении и их произведение
Отношение S
Результат R х рЛГ c.a(S)
Можно также взять продукт без переименования, как в примере 4 5, а затем
переименовать результат. Выражение Рядд й с. д (Л х .$) дает то же самое отношение,
которое изображено на рис 4.8 с тем же самым множеством атрибутов, но теперь у
него нмя RS, которого не имеет результирующее отношение на рис. 4.8. □
150
Глава 4 Операции в реляционной модели
4.1.9 Зависимые и независимые операции
Некоторые операции, описанные в разделе 4 I. можно выразить в терминах
других операций реляционной алгебры, например, пересечение в терминах разно-
сти множеств имеет biu:
Л.->5= Л-(/?-5)
Значит, если Л и S— отношения с одной н той же схемой, их пересечение можно
вычислить следующим образом. Сначала выделяем 5 из Л, чтобы получить отноше-
ние Т. состоящее из кортежей, входящих в Я. но не в 5, а затем выделяем Т из Я,
оставляя только тс кортежи Я, которые входят в 5.
Два вила соединения тоже можно выразить в терминах других операций. Тета-
соедппение записываем с помощью произведения и выбора:
Я txc 5 = cc(Rx S)
Натуральное объединение можно выразить, начиная с произведения /?х5, к кото-
рому затем применяется оператор отбора с условием С вида
ЛЛ| = AND Л.Л, = SA, AND . AND R.A„ = SA„
где Ир A2 .... A„- все атрибуты, появляющиеся в схемах R и 5. И наконец, нужно
построить проекцию одной копии каждого из приравненных друг другу атрибутов
Пусть I. — список жрнбугов в схеме R. за которым следуют те атрибуты из схемы 5,
которые не входят в схему R. Тогда
/? гх.У = л, (о,-(Л*5))
Пример 4.13. Натуральное соединение отношений U и К из рис. 4.5 можно за-
писать в терминах произведения, отбора и проекции.
”л св, ас. о t'.B AND и.с- v.c
Берется произведение t/x И, затем выбирается равенство между каждыми двумя
атрибутами с одинаковыми именами (в данном примере В и С) и, наконец, проек-
ция на все атрибуты, за исключением одного атрибута из В и одного из С; в дан-
ном случае устраняются атрибуты К имена которых встречаются и в схеме U.
Тета соединение из примера 4 9 можно записать как
; о АНО г в - ид(^х
То есть, берется произведение отношений U и И а затем применяется условие из
тета-соединения □
Сводимости, упомянутые в данном разделе это единственные сводимости
между введенными операциями. Остальные шесть операций — объединение, раз-
ность, выбор, проекция произведение и переименование — образуют независимое
множество, каждый член которого не может быть выражен через пять остальных
4-1.10 Упражнения к разделу 4.1
Упражнение 4.1.1. Здесь вводится один из примеров схемы реляционной БД
и некоторые образцы данных. Схема БД состоит из четырех отношений:
Productfmaker, model, type)
PC(model, speed, ram hd. cd, price)
Laptop(model, speed, ram, hd, screen, price)
Printerfmodel, color, type, price)
4.1 Алгебра реляционных операций 15
Отношение Product представляет производителя, номер модели и тип (ПК,
ПК блокнот или принтер) продукта. Для удобства предполагается, что номера мо-
делей уникальны для всех производителей и типов продуктов. Такое допущение не
соответствует действительности. В реальной БД код производителя является частью
номера модели В отношении PC для каждого номера модели, обозначающего ПК,
указаны скорость (процессора в мегагерцах), общий объем RAM (в мегабайтах),
размер диска (в гигабайтах), скорость считывающего устройства CD (например, 4х)
и иена. Отношение Laptop аналогично отношению PC за исключением того, что
вместо скорости CD содержит размер экрана (в дюймах). В отношении Printer для
каждой модели принтера указывается, является ли он цветным (true, если принтер
цветной), тип принтера (лазерный, струйный или ленточный) и цена.
maker model type
А 1001 PC
А 1002 PC
А 1003 pc
В 1004 PC
В 1006 pc
В 3002 printer
в 3004 printe
с 1005 PC
с 1007 pc
D 1008 PC
D 1009 pc
D 1010 pc
D 2001 laptop
D 2002 laptop
D 2003 laptop
D 3001 printer
D 3003 printer
Е 2004 laptop
Е 2008 laptop
F 2005 laptop
G 2006 laptop
G 2007 laptop
н 3005 pr nter
1 3006 pr nter
Рис. 4.9. Пример данных для Product
Данные для отношения Product показаны на рис. 4.9, а образны данных для
остальных трех отношений — на рис 4.10. Производители и номера моделей были
"вычищены”, тем не менее эти данные типичны для продуктов при продажах
в конце 1996 г.
152
Глава 4 Операции в реляционной модели
а) Пример данных для отношения PC model speed ram hd cd price
1001 133 16 1.6 6x 1595
1002 120 16 1.6 6x 1399
1003 166 24 2.5 6x 1899
1004 166 32 2.5 8x 1999
1005 166 16 2.0 8x 1999
1006 200 32 3.1 8x 2099
1007 200 32 3.2 8x 2349
1008 180 32 2.0 8x 3699
1009 200 32 2.5 8x 2599
1010 160 16 1.2 8x 1495
I
b) Пример данных для отношения Laptop model speed ram hd screen price
2001 100 20 1 10 9.5 1999
2002 117 12 0.75 11.3 2499
2003 117 32 1.00 10.4 3599
2004 133 16 1.10 11.2 3499
2005 133 16 1.00 11.3 2599
2006 120 8 0.81 12.1 1999
2007 150 16 1 1.35 12.1 4799
2008 120 16 1 10 12.1 2099
с) Пример данных для отношения Printer model color fype price
3001 true ink-jet 275
3002 true Ink-jet 269
3003 false laser 829
3004 false laser 879
3005 false ink jet 180
3006 true dry 470
Рис. 4.10. Пример донных для отношения из упрожнения 4.1.1
Напншиге выражения реляционной алгебры для ответов на перечисленные
ниже запросы Для данных, приведенных на рис. 4.9 и 4.10. покажите резутьтать
запроса При этом ваши ответы должны работать для произвольных данных, а не
4 1 Алгебра реляционных операций
153
только для тех, что приведены на рис. 4.9 и 4,10. Подсказка: для сложных выраже-
ний полезно определить одно промежуточное выражение или более в терминах
заданных отношений, а затем использовать их в окончательном выражении Потом
в нем можно заменять промежуточные выражения, чтобы получить выражения
в терминах заданных отношений.
*а) Какие модели PC имеют скорость не менее 150?
Ь) Какие производители выпускают ПК-блокноты с жестким диском не ме-
нее одного гигабайта?
с) Найдите номера моделей и цену всех продуктов (любого типа), изготов-
ленных производителем В.
d) Найдите номера моделей всех цветных лазерных принтеров.
е) Найдите производителей, продающих ПК-блокноты, но не ПК.
*! О Найдите размеры жестких дисков, принадлежащих двум или более ПК.
! g) Найдите пары моделей ПК, имеющих одинаковые скорости и объемы
RAM. Пара должна быть упомянута только один раз; например, перечне
ляется (/,_/), но не (/, 0-
*!! h) Найдите производителей по крайней мере двух компьютеров (ПК или
ПК-блокнотов) со скоростью не менее 133.
!! i) Найдите производителя(ей) компьютера (ПК или ПК-блокнота) с макси-
мальной доступной скоростью.
!! j) Найдите производителей, выпускающих ПК по крайней мере с тремя раз-
личными скоростями.
!! к) Найдите производителей, продающих в точности три разные модели ПК.
Упражнение 4 12, Покажите деревья выражений.из упражнения 4.1.1.
Упражнение 4.1.3. Данные выражения - еще один пример, касающийся кораб-
лей, участвующих во второй мировой войне. Он содержит следующие отношения:
Classes(class, type, country, numGuns, bore, displacement)
Ships(name, class, launched)
Battlesfname, date)
Outcomes(ship, battle, result)
Корабли в "классах" построены по одному и тому же проекту, и классу обычно
присваивается название первого корабля этою класса. Отношение Classes содер-
жит имя класса, тип (ЬЬ для боевого корабля или Ьс для боевого крейсера), страну,
в которой построен корабль, число главных орудий, калибр орудий (диаметр ствола
орудия в дюймах) и водоизмещение (вес в тоннах). В отношении Ships записаны
название корабля, имя его класса и год спуска на воду. В отношение Battles
включены название и лата битвы, в которой участвовали корабли, а в отношение
Outcomes — результат участия данного корабля в битве (потоплен, поврежден или
остался невредимым).
На рис. 4.11 и 4 12 приведены примеры данных для этих четырех отношений.2
Заметим, что, в отличие от данных в примере упражнения 4.1 I, здесь есть
"висящие" кортежи, т.е. корабли, входящие в Outcomes и не входящие в Ships.
2 Источники. J N Westwood, Fighting Ships of World War II, Follett Publishing, Chicago. 1975
и R C. Stern. US Battleships in Action, Squadron/Signal Publications. Carrollioit. TX, 1980.
154
Глава 4 Операции в реляционной модели
class а) Пример данных для отношения Classes
type country numQuns bore displacement
Bismarck bb Germany 8 15 42000
Iowa bb USA 9 16 46000
Kongo be Japan 8 14 32000
North Carolina bb USA 9 16 37000
Renown be Gt. Britain 6 15 32000
Revenge bb Gt. Britain 8 15 29000
Tennessee bb USA 12 14 32000
Yamato bb Japan 9 18 65000
b) Пример данных date
для отношения Battles name
North Atlantic 5/24 27/41
Guadalcanal 11/15/42
North Cape 12/26/43
Surigao Strait 10/25/44
с) Пример данных
для отношения Outcomes
ship battle result
Bismarck North Atlantic sunk
California Surigao Strait ok
Duke of York North Cape ok
Fuse Surigao Strait sunk
Hood North Atlantic sunk
King George V North Atlantic ok
Kirishima Guadalcanal sunk
Prince of Wales North Atlantic damaged
Rodney North Atlantic ok
Schamho st North Cape sunk
South Dakota Guadalcanal damaged
Tennessee Surigao Strait ok
Washington Guadalcanal ok
West Virginis Surigao Strait ok
Yamashiro Surigao Strait sunk
Рис. 4.11. Донные для упражнения 4.1.3
4.1 Алгебра реляционных операций
155
пате class launched
California Tennessee 1921
Haruna Kongo 1915
Hiei Kongo 1914
Iowa Iowa 1943
Kirishima Kongo 1915
Kongo Kongo 1913
Missouri Iowa 1944
Musashi Yamato 1942
New Jersey Iowa 1943
North Carolina North Carolina 1941
Ramillies Revenge 1917
Renown Renown 1916
Repulse Renown 1916
Resolution Revenge 1916
Revenge Revenge 1916
Royal Oak Revenge 1916
Royal Sovereign Revenge 1916
Tennessee Tennessee 1920
Washington North Carolina 1941
Wisconsin Iowa 1944
Yamato Yamato 1941
Рис. 4.12. Пример донных для отношения Ships
Напишите выражения реляционной алгебры для ответов на перечисленные
ниже запросы. Для данных, приведенных на рис. 4.11 и 4.12, покажите результаты
запроса. При этом написанные вами выражения должны работать для произволь-
ных данных, а не только для тех, что приведены на указанных рисунках.
а) Укажите имена и страны для классов кораблей, калибр орудий которых
не менее 16 дюймов.
Ь) Найдите корабли, спущенные на воду до 1921 г.
с) Укажите корабли, потопленные в сражениях в Северной Атлантике.
d) По Вашингтонскому международному договору 1921 г. запрещалось
строить корабли водоизмещением более 35 тыс. тонн. Укажите корабли,
нар)тпившие этот договор.
е) Укажите названия, водоизмещение и число орудий кораблей, участвовав-
ших в сражении при Гвадалканале.
f) Перечислите названия головных кораблей внесенных в БД (Помните,
что в отношении Ships всех этих кораблей может и не быть)
1 g) Найдите классы, в которые входит только один корабль.
156
Глава 4 Операции в реляционной модели
! h) Найдите страны, владеющие и обычными кораблями, и крейсерами.
! i) Найдите корабли, "сохранившиеся для будущих сражений"; выведенные
из строя и одной битве, они участвовали в другой.
Упражнение 4.1.4. Покажите деревья выражений из упражнения 4 !.з.
’ Упражнение 4.1.5. Чем отличается натуральное соединение RcxiS от тета-
соединения Rtx>cS с условием С, согласно которому R.A = S./I для каждого атри-
бута А. появляющегося в обеих схемах Л и S?
I Упражнение 4.1.6. Оператор на отношениях называется монотонным, если при
добавлении кортежа к одному из его аргументов результат содержит все кортежи,
которые были до добавления и, возможно, некоторые другие кортежи. Какие из
описанных в этом разделе операций монотонны? Для каждой операции объясните,
почему она монотонна, или же приведите пример, показывающий, что она не
монотонна.
I Упражнение 4.1.7. Пусть отношения 7? и S’ имеют соответственно и и т кор-
тежей. Укажите минимальное и максимальное количество кортежей, получающееся
в выражениях
*а) RuS
b) RtxiS
с) oc(R)xS для некоторого условия С
d) яд (Л) - S для некоторого списка атрибутов L
I Упражнение 4.1.8. Полусоединение отношений Ли S, обозначаемое Ль<5—это
множество кортежей Л, согласующихся по крайней мере с одним кортежем 5 по
всем атрибутам, которые являются общими для Л и S. Приведите три эквивалент-
ных Л 1x5 выражения реляционной алгебры.
!! Упражнение 4.1.9. Пусть Л-отношение со схемой
(Л,, Л2, ..., А„, Bt, В,, .... Вт)
aS- отношение со схемой (Bt, Л2, ., й,„); т.е. атрибуты S являются подмножеством
атрибутов Л. Частное отношений Л и 5, обозначенное Лч- 5,— это такое множество
кортежей г на атрибутах ,4(. А, .., А„ (т.е. атрибутах, принадлежащих R. но не при-
надлежащих 5), что для любого кортежа з из S кортеж к. состоящий из компонен-
тов t для Л(. А-,.А„ и компонентов s для Л,, Й2,.... Вт, входит в Л. С помощью
операторов, введенных в данном разделе, напишите выражение реляционной алгеб-
ры, эквивалентное Л+S.
4.2 Логика отношений
Существует другой способ выражения запросов, основанный на логике, отли
чающейся от алгебры Интересно то, что два подхода (алгебраический и логиче-
ский) ведут к одному и тому же классу выразимых запросов. Логический язык
запросов, вводимый в этом разделе, называется Datalog ("логика БД") и состоит из
правил типа "если , то ". В одном нз этих правил выражается такая идея из
определенной комбинации кортежей в определенном отношении можно вывести,
что некоторый другой кортеж входит в другое отношение, или же ответить на
запрос
4-2 Логика отношений
157
4-2.1 Предикаты и атомы
В Catalog отношения представлены символами — предикатами. Каждый преди-
кат имеет фиксированное число аргументов. Предикат, за которым следуют его
аргументы, называется атомом. Синтаксис атомов похож на синтаксис вызова
функций в обычных языках программирования. Например: Жх„х2, ...д;,) —это
атом, состоящий из предиката Р с аргументами х„ х2, .... х„.
По сути, предикат — это имя функции, возвращающей булево значение. Если
Я — отношение с п атрибутами, расположенными в фиксированном порядке, то Я
будет применяться в качестве имени предиката, соответствующего данному отно-
шению. Атом Я(й|, о2.а„) имеет значение TRUE (истинно), если at, а2, ..., а„~
кортеж Я; в противном случае он имеет значение FALSE (ложно).
Пример 4.14. Пусть Я-это отношение
А В
1 2
3 4
из рис. 4.3. Тогда предикаты Я(1, 2) и Я(2,3) истинны, а для любых других х и у
предикат Я(х, у) ложен. □
Аргументами предиката могут быть переменные и константы. Атом, имеющий
в качестве своих аргументов более одной переменной, это булева функция, областью
определения которой являются переменные, а значениями TRUE или FALSE.
Пример 4.15. Если Я - предикат из примера 4 14, то Я(х,у) — функция, опре-
деляющая для любых х и у, входит ли кортеж (х, у) в отношение Я. Для конкретно-
го экземпляра Я, показанного в примере 4.14, Я(х, у) возвращает значение TRUE,
если
I. л = 1 и у = 2
или
2. х = 3 и у = 4
и FALSE во всех других случаях. При 2=2 атом Я(1, г) имеет значение TRUE, в
противном случае FALSE. □
4-2.2 Арифметические атомы
Существует другой вид атомов, имеющих важное значение в Datalog — арифме-
тические атомы. Они выражают сравнение двух арифметических выражений,
например: х<у или z+l£y + 4xj. Атомы, введенные в разделе 4.2.1, будем
называть реляционными атомами, чтобы отличать их от арифметических; те и другие
являются ’атомами'.
Аргументы арифметических и реляционных атомов — это любые переменные,
а IX значения — TRUE и FALSE. Арифметические сравнения типа < или > похожи
на имена отношений, содержащих все истинные пары. Поэтому можно представить
отношение “<" как отношение, содержащее все кортежи типа (I 2) или ( 1,5, 65,4),
первые компоненты которых меньше вторых. Однако следует помнить, что отно-
шения БД всегда конечны и обычно время от времени изменяются, а отношения
арифметических сравнений типа < бесконечны и неизменны.
158
Глава 4 Операции в реляционной модели
4-2.3 Правила и запросы в Datalog
Операции, сходные с операциями реляционной алгебры, в Datalog описывают-
ся с помощью правил включающих в себя:
I. Реляционный атом, называемым головой. За ним следует
2. Символ который часто читается как "если". За ним следует
3. Тем. состоящее из одного или более реляционных или арифметических
атомов, называемых подцелями. Подцели соединяются связкой AND, каж-
дой нз которых может предшествовать логический оператор NOT
Анонимные переменные
' Часто правила Datalog имеют переменные, входящие в них только один
раз. Имена таких переменных не имеют никакого значения. Только когда
переменная входит в правила более одного раза, нужно заботиться о ее имени,
чтобы знать, являются ли различные вхождения вхождениями одной и той же
* переменной. Поэтому принимается общее соглашение о том, что знак
< в качестве аргумента атома обозначает переменную, которая появляется только
! в данном месте. Множество вхождений знака " " относятся к различным
| переменным и никогда к одной и той же переменной. Например, правило из
,1 примеря 4.16 можно записать в следующем виде:
ILongMovie(t.y)«- Movieft,у,AND I > 100
Переменные с, s и р, входящие в правило только по одному разу, замене-
^ны знаком подчеркивания. Другие переменные нельзя заменять этим знаком,
так как каждая из них входит в правило дважды.
I___, — _____________ __________________.
Пример 4.16. Правило Datalog
LongMovie(t.y) «- Movie(t,y,l,c,s,p) AND I г 100
можно применить для вычислений "длинных фильмов", которые длятся не менее
100 мин Оно указывает на стандартное отношение Movie, определенное в разде-
ле 3.9 со схемой
Movie(tille, year length, inColor, StudioName, producerC#)
Голова данного правила — атом LongMovie(t, у), а тело состоит из двух подцелей:
1 В первую подцель входит предикат Movie с шестью аргументами соответ
ствующими шести атрибутам отношения Movie. Все аргументы имеют раз-
личные переменные: / для компонента title, у для year, / для length и т.д.
Эта подцель означает; "Пусть (/, у, I, c,s р) — кортеж текущего экземпляра
отношения Movie Более точно: Movie'r, у, I, с, j, р) истинно, если значе-
ниями шести переменных являются шесть компонентов одного из корте-
жей Movie.
2 , Вторая подцель, /> 100, истинна, если значение компонента length отно-
шения Movie не менее J00.
4 2 Логика отношений
159
Правило в целом гласит. LongMovieii. у) истинно, если в Movie найдется кор-
теж, содержащий
a) t и у в качестве первых двух компонентов (для title и year)-
b) третий компонент / (для length) со значением не менее 100.
с) любые значения компонентов ОТ 4 до 6
Это правило эквивалентно следующему "оператору оценки" н реляционной алгебре-
LongMovie = nMt )гвг (ст,гчей. |00 (Movie)) ,
правая часть которого есть выражение реляционной алгебры. □
Запрос в Datalog - это непустое множество правил. Если головой правил явля-
ется одно и то же отношение, его значение считается ответом на запрос Значит,
в примере 4 16 LongMovie - это ответ на запрос. Если головой правил являются
несколько отношений, одно из них считается ответом, а другие участвуют в опреде-
лении ответа. Отношение, предназначенное для выражения ответа, нужно отме-
тить, например, словом Answer.
4.2.4 Смысл правил Datalog
Пример 4.16 помогает уяснить смысл правила Datalog. Представьте себе, что
переменные правила пробегают по всем возможным значениям. Когда эти пере-
менные имеют значения, при которых все подцели истинны, мы видим значения
этих переменных в головных элементах. К отношению, предикат которого является
головным элементом, добавляется результирующий кортеж.
Пусть, например, шесть переменных из примера 4.16 пробегают по всем воз-
можным значениям. Единственная комбинация значений, делающая все подцели
истинными, это значения (г, у, / с, s, р), стоящие в том порядке, в котором они рас-
положены в кортеже из Movie. Более того, поскольку подцель /> 100 тоже должна
быть истинной, этот кортеж должен быть таким кортежем, в котором /, т е. значе-
ние компонента length, не менее 100. Определив такую комбинацию значений,
берем кортеж (/, у) в качестве головы отношения LongMovie
Следует учитывать следующие ограничения на применение переменных в пра-
вилах: результат правила есть конечное отношение, а правила с арифметическими
подцелями или отрицательными подцелями (которым предшествует NOT) имеют
содержательный смысл. Запомните условие безопасности:
• Каждая включенная в правило переменная должна входить
и в неотрицательную реляционную подцель этого правила.
В частности, переменная, включенная в голову правила, в отрицательную реляци-
онную подцель или в любую арифметическую подцель должна входить и в неотри-
цательную реляционную подцель.
Пример 4Л7. Рассмотрим правило
LongMovie(t, у) ♦ - Movie(t, у, I, _, _) AND 1 г 100
из примера 4 I6. Первая подцель положительна и содержит все переменные, входя-
щие в это правило. В частности, переменные г и у, включенные в голову, входят
и в подцель тела. Переменная / входит в арифметическую подцель и в первую
подцель. □
160
Глава 4 Операции в реляционной модели
Пример 4.18. В следующем правиле требование безопасности нарушено трижды:
Р(х, у) Q(x, z) AND NOT R(w, x, z) AND x < у
l. Переменная у входит в голову, но не входит ни в одну неотрицательную
подцель. Заметим, что факт вхождения у в арифметическую подцель х < у
не помогает ограничить возможные значения у до конечного множества.
Когда мы находим для ж, х и z соответственно значения а, b и с, удовлет-
воряющие первым двум подцелям, в отношение Р головы правила при-
вносится бесконечное число кортежей (a, d), где rf> а.
2. Переменная iv входит в отрицательную, но не в неотрицательную реля-
ционную подцель.
3. Переменная у входит в арифметическую подцель, но не в неотрицатель-
ную реляционную подцель.
Значит, это правило нс безопасно и не может применяться в Catalog. □
Смысл безопасности правил можно объяснить по-другому. Вместо того, чтобы
рассматривать все возможные приписывания значений переменным, анализируется
множество кортежей в отношениях, соответствующих каждой неотрицательной
реляционной подцели. Если некоторое приписывание кортежей каждой такой под-
цели непротиворечиво в том смысле, что каждому вхождению одной переменной
приписывается одно и то же значение рассматривается результирующее приписы-
вание значений всем атрибутам данного правила. Заметим, значение приписывает-
ся каждой переменной, потому что правило безопасно.
Для каждого непротипоречивого приписывания рассматриваются отрицатель-
ные реляционные и арифметические подцели. Это необходимо для того, чтобы
убедиться, что приписывание сделало все эти подцели истинными. Напоминаем,
что отрицательная подцель истинна, если ее атом ложен. Если все подцели истин-
ны, видно, каким кортежем становится голова правила при данном приписывании
значений переменным. Этот кортеж добавляется к отношению, предикат которого
является головой.
Пример 4.19. Рассмотрим правило из Datalog:
Р(х, у) <- Q(x, z) AND R(z у) AND NOT Q(x y)
Пусть отношение Q содержит два кортежа (1,2) и (1, 3), а отношение R корте-
жи (2.3) и (3. 1). Здесь две положительные подцели Q(x, z) и Л(е, у), поэтому
нужно рассмотреть вес комбинации приписываний этим подцелям кортежей из
отношений Q и Л соответственно. Эти комбинации показаны в таблице на рис. 4 13.
i Tuple for ( Tuple for Consistent | NOT O(x, y) Resulting
i Q(x z) i R(z, у) I Assignment? i True? Head
1) (1.2) ! (2, 3) Yes No —
2) (1.2) j (3.1) No; z = 2.3 Irrelevant —
3) (1.3) (2. 3) No; z = 3,2 Irrelevant
4) (1.3) (3, 1) Yes Yes p(1.1)
Рис. 4.13. Все (зозможные приписывания кортежей £)(х, -) и /?(>, 1)
4.2 Логика отношений
161
Второй и третий варианты на рис. 4 13 противоречивы В каждом из них
переменной » приписываются два разных значения, поэтому они далее не рассмат-
риваются.
Первый вариант, в котором подцели Q(x, z) приписан кортеж (1,2), а подцели
R(z, J) кортеж (2,3) —это непротиворечивое приписывание переменным х, у и г
значений 1, 3 и 2 соответственно. Значит, нужно проверить другие отрицательные
реляционные подцели. Такая подцель здесь одна: NOT Q(x, у). При данном припи-
сывании значений переменным она имеет вид МОТ 0(1,3) и является ложной, так
как (I, 3) —это кортеж из Q. Поэтому при варианте приписывания кортежей (I)
никакой головной кортеж не порождается.
Последнее приписывание (4) непротиворечиво; переменным х, у и г приписы-
ваются значения 1, I и 3 соответственно. Подцель NOT Q(x, у) принимает истинное
значение NOT 0(1,1). Так как (1,1) не является кортежем из Q, эта подцель истин-
на. Таким образом, мы оцениваем голову Р{х, у) для этого приписывания значений
переменным и определяем, что ее оценкой является Г(1,1). Значит, кортеж (1,1)
входит в отношение Р Поскольку были исчерпаны все приписывания значений
кортежам, этот кортеж является единственным кортежем отношения Р. □
4.2.5 Экстенсиональные и интенциональные
предикаты
«, Следует различать:
• Экстенсиональные предикаты, отношения которых хранятся в БД,
и
Интенциональные предикаты, отношения которых вычисляются по одному
или нескольким правилам Datalog.
Разница между ними такая же, как между операндами выражений реляцион-
ной алгебры, которые "экстенсиональны" (т.е. определяются их объемом, обознача-
ющим "текущий экземпляр отношения”) и отношениями, вычисляемыми с помощью
этих выражений, которые "интенциональны" (т.е. определяются "интенцией" про-
граммиста).
Говоря о правилах Datalog, мы будем называть отношение, соответствующее
предикату, "экстенсиональным" или "интенциональным", если предикат соответст-
венно экстенсионален или интенционален. Ссылаясь на интенциональный преди-
кат или соответствующее ему отношение, будем обозначать интенциональную БД
аббревиатурой IDB, а аббревиатурой EDB— "экстенсиональную БД" для экстенсио-
нальных предикатов или соответствующих им отношений.
Значит, в примере 4.16 Move —это отношение EDB, определяемое его объемом,
a Movie — предикат EDB Отношение и предикат LongMovie интенциональны
Предикат EDB никогда не может входить в голову правила, хотя может
входить в его тело. Предикаты IDB могут входить в любую часть правила или
по все части сразу. Единственное отношение обычно строится путем применения
множества правил с одним предикатом в голове правила. Такой подход иллюстри-
руется в примере 4.21, касающемся объединения двух отношений
Применяя серию интенциональных предикатов, можно последовательно строить
все более сложные функции отношений EDB. Этот процесс аналогичен построе-
нию выражений реляционной алгебры с помощью множества операторов. Примеры
использования множества интенциональных операторов приведены также в следу
Юнн lx разделах.
162
Глава 4 Операции в реляционной модели
4-2.6 Упражнения к разделу 4-2
Упражнение 4 2 1 Запишите каждый запрос из упражнения л 1 на языке
Datalog При этом применяйте только безопасные правила: впрочем, можно ис-
пользовать множество предикатов IDB, соответствующих подвыражениям сложных
выражений реляционной алгебры.
Упражнение 4.2.2. Запишите каждый запрос из упражнения 4.1.3 на языке
Datalog. Применяйте только безопасные правила, но при желании можно использо-
вать множество предикатов IDB.
I! Упражнение 4.2.3 Условия безопасности правил Datalog достаточны для га-
рантии того, чтобы головной предикат имел конечное отношение, если предикаты
реляционных подцелей имеют конечные отношения Но это слишком жесткое
ограничение Приведите пример правила Datalog, которое нарушает данное ограни
чение, но тем не менее при приписывании конечных отношений реляционным
предикатам головное отношение будет конечным
4-3 Переход от реляционной алгебры
к Datalog
Любой оператор реляционной алгебры можно изобразить с помощью одного
или нескольких правил Datalog. В этом разделе мы снова рассмотрим все эти
операторы и покажем, как комбинировать правила Datalog для имитации сложных
алгебраических выражений.
4.3-1 Пересечение
Пересечение двух отношений выражается правилом, имеющим подцели для
обоих данных отношений с теми же самыми переменными в соответствующих
аргументах.
Пример 4.20. Рассмотрим отношения Л и 5, изображенные на рис. 4.1 Каждое
из них имеет схему с атрибутами name, address, gender и birthdate. Результат вычис-
ления пересечения этих отношений по правилам Datalog:
l(n,a,g,b) <- R (n,a,g,b) AND S(n a,g b)
Здесь /—предикат IDB, отношением которого при применении данного пра-
вила становится Rr\S Таким образом, чтобы обе подцели были истинными для
кортежа (п,а, g, b), он должен находился в обоих отношениях — R и 5. □
4-3.2 Объединение
Объединение двух отношений строится с помощью двух правил. Каждое из
них в качестве своей единственной подцели имеет атом, соответствующий одному
из отношений, а головы обоих правил содержат один и тот же предикат. Аргументы
головы каждого правила в точности совпадают с аргументами его подцели.
Пример 4.21. Для получения объединения отношений R и 5 из примера 4.20
применяются два правила:
1. U (n,a,g,b) «- R (п,а g,b)
2 U (n,a,g,b) <- S (n,a,g,b)
4 3 Переход от реляционной алгебры к Datalog
163
Правило (1) гласит, что каждый кортеж из Л является кортежем (DB-отношения U,
а согласно правилу (2), каждый кортеж из S входит в U Значит, из двух этих
правил следует, что каждый кортеж из R\jS входит в U. Если не писать больше
правил с U в головных элементах, никакие другие кортежи не смогут попасть в U,
и тогда можно сделать вывод, что И совпадает с Яс’5.3 Поскольку отношения
являются множествами, каждый кортеж входит в (J только один раз, даже если он
входит и в R и в 5. □
Переменные локальны
по отношению к правилам
Отметим, что имена переменных в правиле выбираются произвольно и не
имеют никакого отношения к переменным используемым в любом другом
правиле. Причина такой независимости заключается в том, что каждое прави-
ло оценивается отдельно и кортежи отношения в его голове не связаны
с другими правилами. Например, второе правило из примера 4.21 можно
заменить правилом
U(w, х, у, z) <- S(w, х, у, z)
i оставив при этом первое правило без изменений. В результате два правила
по-прежнему будут вычислять объединение R и 5. Однако при замене в пра-
виле переменной а на другую переменную b вместо каждого вхождения а в
рассматриваемое правило необходимо подставлять Ь. Более того, при этой
подстановке b должно быть переменной, которая не входит в данное правило
4.3.3 Разность
Разность отношений R и S строится с помощью единственного правила с отри-
цательной подцелью. Это означает, что положительная подцель имеет предикат Я
а отрицательная — предикат 5. В соответствующие друг другу аргументы головы
и подцелей входят одни и те же переменные.
Пример 4.22. Если Я и 5- отношения из примера 4.20, то правило
D(n,a,g,b) <- R (n,a,g,b) AND NOT S(n,a,g,b)
определяет D как отношение Я - 5. □
4.3.4 Проекция
Для вычисления проекции отношения Я применяется правило с единственной
подцелью с предикатом Я. Аргументы данной подцели — это различные перемен-
ные, по одной для каждого атрибута отношения Я. Головной элемент содержит
атом с аргументами в виде переменных, соответствующих атрибутам в списке про-
екции, расположенным в нужном порядке.
з В каждом примере этого раздела предполагается “то нет других правил для предиката
1DB, кроме тех, которые явно указаны. Если они есть, невозможно установить
существование других кортежей в отношении для данного предиката.
64 Глава 4 Операции в реляционной модели
Пример 4.23. Построим проекцию отношения
Mov'e(title, year, length, inColor, studioName, producerC#)
на его первые три атрибута, как в примере 4.2. Отношение Р, являющееся результа-
том такой проекции, определяется по правилу
P(t,y,1) <- Movie(t,y,,c,s,р) □
43-5 Отбор
Выразить отбор в Datalog немного труднее. Простым является случай, в котором
условием отбора является AND или арифметические сравнения При этом строится
правило, содержащее:
I. Одну реляционную подцель для отношения, на котором проводится от-
бор. Этот атом содержит различные переменные для каждого компонента,
по одной для каждого атрибута отношения.
2. Арифметическую подцель для каждого сравнения в условии отбора, иден-
тичную этому сравнению. Но так же, как при условии отбора используется
имя атрибута, в арифметической подцели применяется соответствующая
ему переменная в соответствии с установленной реляционной подцелью
Пример 4.24. Отбор
S 00 ANO sntdioNoHie ~ Ток’ (Movie)
из примера 4 4 можно записать в виде следующего правила Datalog:
S(t,y, ,c,s,p,) <- Move(t,y,l,c,s p) AND I >100 AND s = 'Fox'
В результате получается отношение 5 Заметим, что переменные I и s соответствуют
атрибутам length н studioName в стандартном порядке, примененном для атрибутов
Movie. □
Теперь рассмотрим отбор, в котором условия соединены связкой OR, Его не
всегда можно заменить единственным правилом Datalog. Однако отбор, содержа-
щий два условия, соединенных OR, эквивалентен отбору по каждому из условий
в отдельности с последующим объединением результатов. Значит, и условий, сое-
диненных связкой OR можно выразить с помощью и правил, каждое из которых
определяет один и тот же головной предикат. <-е правило выполняет выбор для А го
условия из числа
пример 4.25. Изменим выбор из примера 4 34, заменив AND на OR. и получим
t« OR даЛпЛтате =-Foi- (MOVle)
То есть, нужно найти все длинные фильмы или принадлежащие студии Fox
Можно написать два правила для этих условий-
1 S(t.y,l,c s,p) t - Movie(t,y l,c,s,p) AND I >100
2 S(t,y,l,c,s,p)Movie(t,y l,c,s,p) AND s ='Fox'
Первое порождает фильмы, длящиеся более 100 мин, а второе фильмы, принадле-
жав не студни Fox. О
4.3 Переход от реляционной алгебры к Data од
165
Многократно применяя логические операторы AND, OR или NOT, можно полу-
чать еще более сложные условия отбора. Однако широко известен меток приведе-
ния любого логического выражения в “конъюнктивную нормальную форму",
состоящую из "конъюнктов" связанных между собой OR. Конъюнкты - это литералы,
а литерал — это условие или отрицательное сравнение.4
Любой литерал можно представить с помощью подпели, которой иногда пред-
шествует NOT. В арифметической подцели NOT можно ввести в оператор сравне-
ния. Например NOT х>100 можно записать как х<100 Тогда любой конъюнкт
представим единственным правилом Datalog, содержащим по одной подцели для
каждого сравнения И наконец, каждое выражение в конъюнктивной нормальной
форме можно записать с помощью множества правил, содержащего по одному
правилу для каждого конъюнкта. Эти правила выражают объединение результатов,
полученных из каждого конъюнкта.
Пример 4.26. Простой образец такого алгоритма приведен в примере 4.25.
Более сложный пример можно построить, отрицая условие этого примера. В ре-
зультате получается выражение
aNOT iteislhz 100 OR яиЛюЫот“’Fox') (Movie) ,
означающее, что нужно найти фильмы, которые не являются длинными и не при-
надлежат студии Fox
Здесь NOT применяется к выражению, не являющемуся простым сравнением.
Значит, следует переместить отрицание вовнутрь по закону Де Моргана, согласно
которому отрицание выражения с OR эквивалентно соединению AND отрицаний
его частей. Таким образом, выбор можно записать как
СДЮТ </wrEA г. 00)) AND (NOT (xMfoAtoir “ 'Fox п (Movie)
Теперь можно ввести отрицание в сравнения и получить
< (00 ANO siudioHame * ‘Fox' (MOVie)
Это выражение конвертируется в следующее правило Datalog’
S(t,y l,c,s,p,) ч— Movieft.yJ.c.s.p) AND I <100 AND s *'Fox' □
Пример 4.27. Рассмотрим похожий пример, в котором есть отрицание условий,
связанных посредством AND. Теперь мы используем вторую форму закона Де
Моргана, согласно которой отрицание AND эквивалентно отрицаниям, связанным
посредством OR. Начнем с алгебраического выражения
aNOT(ftnsAi 100 ANO яиОоНате-'ГтП (M°Vle)
т.е, найдем фильмы не длинные и не принадлежащие студии Fox.
По закону Дс Моргана проносим NOT внутрь AND и получаем
°(NOT i 100)1 OR (NOT ImtmKmne = ’Fox’)) (Movie)
Затем вносим отрицание в компоненты, чтобы получить
< (00 or stttdioNaitu * тох' (Movie
И наконец, записываем два правила, по одному для каждой части этого выражения:
1. S(t,y,!,c,s,p) <- Movie(t,y,l,c,s,p) AND I <100
2. S(t,y,l,c s.p) <- Movie(t,y l.c.s.p) AND s * 'Fox' □
а См., например, A. V. Aho and J. D. Ullman, Founifaiions of Computer Science, Computer
Science Press, New York, 1992
166
Глава 4 Операции в реляционной модели
4-3.6 Произведение
Произведение двух отношений R* S можно представить единственным прави-
лом Datalog, имеющим две подцели, по одной для R и S. Каждая из них содержит
различные переменные, по одной для каждого атрноута из Л или 5 Аргументы пре-
диката IDB н голове это переменные, входящие в каждую из подцелей, и перемен-
ные. входящие в подцель Я, предшествующие переменным, входящим в подцель 5.
Пример 4.28. Рассмотрим четырехатрцбугивные отношения R и 5 из примера 4.20.
Правило
P(a,b c,d w,x,y,z) <- R(a b,c,d) AND S(w x.y z)
определяет P как R x 5. Для аргументов R произвольно использовались переменные
из начала латинского алфавита, а для 5 — из конца. Все они входят в голову пра-
вила. □
4-3.7 Соединения
Натуральное соединение двух отношений можно провести по правилу Datalog,
очень похожему на правило произведения. Отличие состоит в том, что при получе-
нии RtxS нужно следить за чем чтобы одна и та же переменная применялась для
а рибутов Я и 5с одним и тем же именем или же указывать для них разные пере-
менные. Например, в качестве переменных можно применять имена самих атрибу-
тов. Голова правила — предикат IDB, в который каждая переменная входит только
один раз.
Пример 4.29. Рассмотрим отношения со схемами R(A, В) и S(В С, D) Их на-
туральное соединение можно определить с помощью правила
J(a,b,c.d) <-R(a,b) AND S(b c,d)
Переменные, используемые в подцелях, очевидным образом соответствуют атрибу-
там отношений Я и 5. □
Тета-сосдинения также конвертируются в Datalog довольно простым способом.
В разделе 4 I.9 было показано, как выразить тета-соединение в виде произведения
с последующим отбором. Если условие отбора конъюнктивно, т.е. представляет
собой сравнения связанные с помощью AND, можно просто начать с правила
Datalog для произведения, а затем добавить арифметические подцели, по одной для
каждого сравнения
Пример 4.30. Рассмотрим отношения (/(И, В, С) и ¥(В, С, D) из примера 4.9,
где применялось тета соединение:

Эту же операцию можно выполнить с помощью правила
J(a, ub ис, vb, vc, d)«- U(a, ub uc) AND V(vb, vc d) AND a < d AND ub s» vb
Мы указываем uh как переменную, соответствующую атрибуту В из У (аналогично
используются vb, нс и vc), хотя было бы лучше применить шесть любых перемен-
ных для шести атрибутов обоих отношений. Первые две подцели вводят два отно-
шения, а две последние определяют два сравнения, появляющихся в условии
тета-соединения □
4 3 Переход от реляционной алгебры к Datalog 167
Если условие тета-соединения не является конъюнкцией, оно переводится в
конъюнктивную нормальную форму, как показано в разделе 4 3.5, а затем строится
отдельное правило для каждого конъюнкта. Головные части всех правил идентичны,
и для каждого атрибута участвующих в тета-соединении отношений имеется один
аргумент.
Пример 4.31. Изменим алгебраическое выражение из примера 4.30, заменив
AND на OR. В выражении нет отрицаний, поэтому оно уже находится в конъюнк-
тивной нормальной форме В нем два конъюнкта, каждый из которых имеет един-
ственный литерал:
О OR Кв» Кв
Применив такую же схему именования переменных, как и в примере 4.30, по-
лучаем два правила:
1. J(a, ub, uc, vb, vc, d) <- Ufa, ub, uc) AND V(vb, vc, d) AND a < d
2. J(a, ub, uc, vb, vc, d) Ufa, ub, uc) AND Vfvb, vc, d) AND ub * vb
Каждое из них имеет подцели для двух отношений и одно из двух условий: А < D
или U.B* V В. □
43-8 Моделирование сложных операций
в Datalog
С помощью правил Datalog можно имитировать не только простые операции
реляционной алгебры, но, фактически, любые алгебраические выражения. Для этого
нужно представить выражение реляционной алгебры в виде дерева и построить по
одному предикату IDB для каждого его внутреннего узла. Правило или правила для
каждого предиката IDB — вот все, что необходимо для применения оператора в со-
ответствующем узле дерева. Экстенсиональные операнды дерева (т.е. отношения из
БД) можно представить соответствующими предикатами Операнды, являющиеся
внутренними узлами, выражаются предикатами IDB.
Пример 4.32. Рассмотрим алгебраическое выражение
^titlr.year (Movie) П (MOV 6 )
из примера 4.10, представленное в виде дерева на рис. 4.7 и воспроизведенное здесь
на рис. 4.14.
ft title .year
(3 length > WO
O' studioName — ’Fox’
Movie Movie
Рис 4.14. Дерево вырожений
168
Глава 4 Операции в реляционной модели
В этом дереве четыре внутренних узла, поэтому нужно построить четыре предиката
IDB, к каждому из которых относится единственное правило IDB Все эти правила
перечислены на рис. 4.15.
1. W(t, у I, с, S, р) «- Movie(t у, I, с, s, р) AND I > 100
2. X(t, у, I, с, S, р) «- Movie(t, у. I, с, s, р) AND s = ’Fox’
3. Y(t, у, 1, c, s, р)«- W(t, у, I, с, s р) AND X(t, у. I, с, s, р)
4. Z(t, у) <- Y(t, у I с s, р)
Рис 4.15. Провило Catalog для выполнения множества алгебраических операций
Два нижних внутренних узла дерева на рис. 4.14 выполняют две простые
операции отбора на EDB-отношении Movie, поэтому для их представления можно
построить IDB-предикаты W и X. Эти операции описаны правилами I и 2 из
рис. 4 15. Например, правило I определяет И' как кортежи отношения Movie, в ко-
торых атрибут length имеет значение не менее 100.
Правило 3 определяет предикат Y как пересечение Wи X. причем применяется
форма правила пересечения, описанная в разделе 4.3 I. И наконец, правило 4 опре-
деляет Z как проекцию Y на атрибуты title и year. Здесь применяется метод пред
ставления проекции, описанный в разделе 4.3.4. Z—это предикат "ответа’’, т.е.
независимо от значения отношения Movie отношение, определяемое Z, совладает
с результатом алгебраического выражения, с которого начинался данный пример
В этом примере подцель Y из правила 4 можно заменить на тело из правила 3.
Затем вместо подцелей W и X можно подставить тела из правил I и 2 соответствен-
но Поскольку подцель Movie входит в оба тела, одну ее копию можно удалить
В результате Z определяется единственным правилом:
Z(t, у) <- Movie(t, у, I, с, s, р) AND 1 > 100 AND s = 'Fox’
Однако это не значит, что сложное выражение реляционной алгебры всегда экви-
валентно единственному правилу Datalog. □
43.9 Упражнения к разделу 43
Упражнение 4 3.1. Пусть Я(а, Ь, с), 5(о, Ь, с) и Да, Ь, с) - три отношения На-
пишите правила Datalog определяющие результат каждого из перечисленных выра-
жений реляционной алгебры:
а) Я о Я
Ь) ЯсхЯ
с) Я - Я
*<1) (ЯсэЯ)-Г
! е) (Я-Я)п(Я- Г)
0 в„.,.(Я)
' ь ( Я) П р(Д„1И f (Я 1)
Упражнение 4.3.2. Пусть Я(х. у, $ - отношение. Напишите правила Datalog.
определяющие (Я), tae С-одно из следующих условий
а) л =у
4.4 Рекурсивное программирование в Datalog
169
с) х < у. OR у < z
d) NOT(jc<y OR х> у)
*1 е) NOT ((х < у OR х > у) AND у < г)
! О NOT ((х < у OR jc < z) AND у < z)
Упражнение 4.3.3. Пусть R(a, Ь, с). S(£, с, d) и T(d, ё) — три отношения. Напи-
шите единственное правило Datalog для каждого из следующих натуральных соеди-
нений:
a) R txi 5’
Ь) 51x1 Т
1 с) (Atxi 5) txi Т(Примечание. Поскольку натуральное соединение ассоциативно
и коммутативно, порядок соединения этих трех отношений не имеет
значения.)
Упражнение 4.3.4. Пусть Дх, у, г) и S(x, у, z) - отношения. Напишите прави-
ла Datalog, определяющие результат каждого тета-соединеиия Rtx^S, где С—одно
из условий из упражнения 4.3 2. Для каждого условия интерпретируйте любое
арифметическое сравнение как сравнение, в левой части которого стоит атрибут
из R, а в правой - атрибут из 5. Например, х < у означает R.x < Sy.
Упражнение 4.3.5. Правила Datalog тоже можно конвертировать в эквивалент-
ные им выражения реляционной алгебры. Хотя мы и не рассматривали общий
метод такого перевода, можно привести множество простых примеров. Для каждого
из перечисленных ниже правил Datalog запишите выражение реляционной алгеб-
ры, определяющее отношение, которое является головой этого правила.
*а) Р(х, у) <- Q(x, z) AND R(z, у)
b) P(x, у) Q(x, z) AND Q(z, y)
c) P(x, y) «- Q(x, z) AND R(z, y) AND x < у
4-4 Рекурсивное программирование
в Datalog
Несмотря на то что средствами реляционной алгебры можно выразить многие
полезные операции, есть вычисления, представить которые в виде выражений этой
апгебры, нельзя. Распространенный вид операции на данных, которую нельзя вы
разить в реляционной алгебре, включает в себя бесконечную последовательность
сходных, но при этом возрастающих алгебраических выражений, которая называет-
ся рекурсией.
Пример 4.33. Пример рекурсивной операции, взятый из области киноиндуст-
рии, касается продолжений фильма. Часто за удачным фильмом следует его продол-
жение, за ним другое и т.д. Итак, фильм может стать предшественником длинной
последовательности фильмов. Рассмотрим отношение SequelOffmovie, sequel), содер-
жащее пару, состоящую из фильма и его непосредственного продолжения. Примеры
кортежей этого отношения:
movie
Naked Gun
Naked Gun 2 72
| sequel
Naked Gun 21/2
Naked Gun 331/3
170
Глава 4 Операции в реляционной модели
Можно применить еще Более общее понятие "Следует за..." к фильму, который
является продолжением, продолжением продолжения и тл. В приведенном выше
отношении Naked Gun 33'/-, следует за Naked Gun но не является его продолжением
в строгом смысле используемого здесь термина "продолжение''. Пространство памяти
можно сэкономить, сохраняя в отношениях только непосредственные продолжения
и создавая последующие только в случае необходимости. В данном примере фикси-
руется всего лишь одна наименьшая пара, но для пяти фильмов с участием Рокки
уже нужно запоминать шесть пар. а для фильмов "Пятница, 13-е" число минималь-
ных пар возрастает до 136.
Совсем не очевидно, как построить отношение "следования за...” из отноше-
ния SequelOf. Продолжение продолжений можно построить путем однократного
соединения SequelOf с самим собой. В результате получается выражение, в котором
применяется переименование и соединение становится натуральным:
(SequelOf) txi (SequelOf))
В этом выражении SequelOf встречается дважды. В первом случае его атрибуты на-
зываются first и second, а во втором second и third. Значит, натуральное соединение
требует, чтобы в SequelOf были кортежи (т,, тг) и (т3, /щ), где т2 = лщ Затем вво-
дится пара (/»,, тА). Заметим, что — продолжение mf.
Аналогичным образом можно соединить три копни SequelOf и получить про-
должения продолжений продолжений (например, "Рокки" и “Рокки /К'). Фактиче-
ски, можно построить f-е продолжения для любого фиксированного значения /,
соединяя SequelOf с самим собой г-1 раз. Тогда, объединяя SequelOf с конечным
множеством таких соединений, можно получить все продолжения вплоть до неко-
торого фиксированного предела.
В реляционной алгебре невозможно получить "бесконечное объединение" бес-
конечной последовательности выражений, порождающих r-е продолжения для каж-
дого /. Объединение в реляционной алгебре — это объединение только двух, а не
бесконечного числа отношений. Применяя в алгебраическом выражении оператор
объединения конечное число раз, можно получить объединение любого конечного
числа отношений, а объединение бесконечного числа отношений — нет. □
4-4.1 Оператор фиксированной точки
В реляционную алгебру не требуется вводить никакого искусственного согла-
шения, позволяющего выразить бесконечные объединения "одинаковых" выраже-
ний Есть общий способ выражения отношений типа FollowOn(x, у) (т.е. фильм у
следует за фильмом х, как показано в примере 4.33), которые строятся в бесконеч-
ном, но все же регулярном процессе из других отношений типа SequelOf. Записы-
вается уравнение, в котором FollowOn выражается в своих собственных терминах
и в терминах SequelOf, а затем говорится, что значение FollowOn — это наименьшее
отношение (наименьшая фиксированная точка}, удовлетворяющее этоь у уравнению.
Оператор наименьшей фиксированной точки, применяемый к уравнению, мы
будем обозначать символом ф.
Пример 4.34. Рассмотрим применение оператора наименьшей фиксированной
точки к уравнению, выражающему отношение FollowOn(x, у):
ф (FollowOn = (SequelOf) рЛ(ч. г)(лт№А. ,, (SequelOf txi , FollowOn)))
Это уравнение означает "Фильм у следует за фильмом х, если у является продолже-
нием х или следует за продолжением х".
Здесь отношение FollowOn с атрибутами х и у приравнивается к объединению
двух термов. Первый терм (SequelOf) - это копия отношения SequelOf,
4.4 Рекурсивное программирование в Datalog
171
переименованная так, чтобы ее атрибуты соответствовали атрибутам отношения
FollowOn. Второй терм - это тета-соединение SequelOfixi Jr?w,= r FollowOn всех пар
(й, Ь) из SequelOf с парами (Ь, с) из FollowOn, в результате которого получаются
кортежи (й. i, b, с), атрибутами которых являются movie, sequel, х и у соответствен-
но. Этот терм проецируется на первый и четвертый компоненты, movie и у, после
чего производится переименование атрибутов х и у
Итак, в уравнении с фиксированной точкой FollowOn приравнивается к объели
нению отношения SequeOf с результатом второго терма, который вычисляет следую-
щие продолжения Таким образом, FollowOn состоит из всех таких пар (х, у), что (х, у)
входит в SequelOf или у следует за продолжением х. Другими словами, у — это про-
должение продолжения продолжения ... продолжения хдля некоторого числа приме-
нений термина "продолжение". □
4.4.2 Вычисление наименьшей фиксированной
точки
Из уравнения, приведенного в примере 4.34, не совсем ясно, почему наимень-
ший результат для FollowOn является множеством следующих одна за другой пар
фильмов. Чтобы понять смысл оператора фиксированной точки, нужно усвоить,
как вычисляется наименьшая фиксированная точка. В разделе 4.4.4 будет рассмсп-
рена проблема, возникающая при наличии в уравнении оператора разности, а для
уравнения без этого оператора действует следующий метод.
I. Принимается допущение о том, что отношение R в левой части уравне-
ния пусто
2. Заново вычисляется значение отношения Р. путем вычисления правой
части с помощью старого значения R.
3. Действия прекращаются, если после одного повторен 1я старое и новое
значения оказываются одинаковыми.
Пример 4.35. Проведем вычисление отношения FollowOn для случая, в котором
SequelOf состоит из следующих трех кортежей:
movie
Rocky
Rocky II
Rocky 111
sequel
Rocky II
Rocky III
Rocky IV
В качестве первого шага предполагаем, что FollowOn пусто. Тогда объединение
SequelOf и FolowOn в уравнении с фиксированной точкой тоже пусто и кортежи
берутся только из первого терма объединения, т.е. из SequelOf. Поэтому значение
FolljwOn совпадает со значением SequelOf, т.е. получается отношение, показанное
на рис. 4 16.
X У
Rocky Rocky II
Rocky II Rocky III
Rocky III Rocky IV
Рис. 4.16. Отношение Fol owOn после первого того вычисления
172
Глава 4 Операции в реляционной модели
Далее с помощью этого отношения вычисляем правую часть уравнения
с фиксированной точкой. Из первого терма объединения, SequeiOf, получаются три
уже имеющихся кортежа. Для второго терма нужно получить соединение отношения
SequeiOf, содержащего три кортежа, показанных на рис. 4.16, с текущим отноше-
нием FollowOn причем эти отношения совпадают. Для этого мы ищем такие пары
кортежей, чтобы второй компонент кортежа из SequeiOf совпадал с первым компо-
нентом кортежа из FollowOn
Итак, можно взять кортеж (Rocky, Rocky II) из SequeiOf и соединить его
с кортежем (Rocky II. Rocky II) из FollowOn, чтобы получить новый кортеж (Rocky,
Rocky III) для отношения FollowOn. Аналогично, можно взять кортеж
(Rocky II Rocky III)
из отношения SequeiOf, чтобы получить новый кортеж (Rocky III Rocky IV) для
отношения FollowOn. Никакие другие пары кортежей, один из которых взят из
SequeiOf, а другой нз FollowOn со старым значением, не объединяются. Значит,
после второго шага отношение FollowO содержит пять кортежей, изображенных на
рис. 4.17. Отношение, изображенное на рис. 4.16, содержало только последователей
одного продолжения, а отношение, представленное на рис. 4.17, включает в себя
одно или два продолжения.
X У
Rocky Rocky II
Rocky П Rocky III
Rocky III Rocky IV
Rocky Rocky III
Rocky II Rocky IV
Рис. 4.17. Отношение FollowOn после второго шага вычисления
И наконец, используется отношение FollowOn, изображенное на рис. 4.17, и
заново вычисляется правая часть уравнения с фиксированной точкой. В результате
получаются уже имевшиеся кортежи и один новый. Объединяя кортеж (Rocky,
Rocky 1Г 13 SequeiOf с кортежем (Rocky II, Rocky IV) из текущего значения отноше-
ния FollowOn, получаем новый кортеж (Rocky, Rocky IV). После этого шага отноше-
ние становится таким, как оно изображено на рис. 4 18.
X У
Rocky Rocky II
Rocky II Rocky III
Rocky III Rocky IV
Rocky Rocky III
Rocky II Rocky IV
Rocky Rocky IV
Рис. 4.78. Отношение FollowOn после третьего июга вычисления
Делая следующий шаг. мы не получаем новых кортежей, поэтому процедура
вычисления заканчивается. Истинное отношение FollowOn, определяемое таким
у^^^'ир щщоГ точки, показано на рис. 4.18. □
4.4 Рекурсивное программирование в Catalog
173
4.4.3 Уравнения с фиксированной точкой
в Catalog
Для построения достаточно сложных выражений реляционной алгебры необхо-
димы уравнения с фиксированной точкой. Часто их можно выразить с помощью
множества правил Datalog Именно такой способ будет применяться в данном раз-
деле. В разделе 5.I0 будет показано, что при реализации такого подхода в SQL3
применяется нотация, имеющая скорее алгебраический, нежели логический харак-
тер, так как она больше соответствует стилю SQL.
Общая идея, лежащая в основе логических уравнений с фиксированной
точкой, заключается в том, чтобы начинать вычисления с отношений EDB. Другие
отношения, определяемые путем их введения в головы правил, являются отноше-
ниями IDB. Тела этих правил могут содержать подцели, предикатами которых
являются отношения EDB или 1DB, а также арифметические атомы. Если одно
отношение IDB (или более) определяется по правилам, имеющим одни и те же от-
ношения в своих телах, такие правила эффективно определяют данные отношения
IDB с поь ощыо уравнений с фиксированной точкой, как это делают в уравнении
реляционной алгебры из примера 4.34.
Другие формы рекурсии
В примерах 4.34 и 4.36 реализована правосторонняя рекурсия. При этом
рекурсивное отношение FolowOn применяется после EDB-отношения Seq elOf.
Можно записать и аналогичные правила левосторонней рекурсии, в которых
первым стоит рекурсивное отношение
.
1. Fol owOnfx, у) «- SequelOf(x, у)
2. Fol owOn(x у) «- Fol owOn(x, z) AND SequelOf(z, y)
li
Неформально: у — последователь x, если у - продолжение .х или продолжение §
последователя х.
Можно даже использовать рекурсивное отношение дважды, как это дела-
ется при нелинейной рекурсии:
1. Fo lowOn(x, у) <- SequelOffx, у)
2. FollowOnfx, у)«- FolIowOnfx, z) AND Fo lowOn(z, y)
Неформально: у- последователь x, если у — продолжение л или последова ель
последователя х. Все три формы рекурсии дают одно и то же значение отно-
шения FolowOn множество таких пар (х, у), что у - продолжение продолже
ния продолжения ... х
j i
Пример 4.36. IDB-отношение FollowOn можно определить с помощью следую-
щих правил Datalog:
1. Fo lowOn(x, у) -е- SequelOf(x, у)
2. Fo lowOn(x, у) ч- SequelOf(x, z) AND FollowOn(z, у)
Первое из них формирует базис и означает, что всякое продолжение является
последователем Оно соответствует первому терму объединен! я в уравнении 1 з
примера 4 34.
13торое правило означает, что каждый последователь продолжения фильма х
является последователем х. Более точно: если г — продолжение х, а у — последова-
тель г, то у — последователь х □
174
Глава 4 Операции е реляционной модели
Правила примера 4.36 — это абсолютно то же самое, что уравнения с фиксиро-
ванной точкой из примера 4.35, поэтому вычисление значения FollowOn для этих
правил идентично вычислению из примера 4.35 В обшем случае при вычислении
значений отношений IDE. определяемых множеством правил Daialog без отрицатель-
ных подцелей, можно начинать с пустого множества отношений !DB и итеративно
вычислять новые значения отношений IDB. применяя правила к отношениям EDB
и к предыдущим значениям до тех пор, пока отношения IDE не перестанут изме-
няться
Пример 4.37. Более сложные примеры применения рекурсии можно найти при
анализе путей в графах На рис. 4 19 показан граф представляющий рейсы двух
гипотетических авиалиний — Untried Airtines (UA) и Arcane^ Airlines (AA) — между
городами Сан-Франциско, Денвер, Даллас, Чикаго и Нью-Йорк.
Рис. 4.19. Корта авиареисое
Авиарейсы можно представить отношением EDB-
Flightsfairiine, from, to, departs, arrives)
Кортежи этого отношения для данных из рис. 4.19 показаны на рис. 4.20.
airline from to departs arrives
UA SF DEN 930 1230
AA SF DAL 900 1430
UA DEN CHI 1500 1800
UA DEN DAL 1400 1700
AA DAL CHI 1530 1730
AA DAL NY 1500 1930
AA CHI NY 1900 2200
UA CHI NY 1830 2130
Рис. 4 20. Кортежи отношений Flights
4 4 Рекурсивное программирование в Data од
175
Самый простой рекурсивный запрос: указать такие пары городов, чтобы из
города х можно было попасть в город у одним авиарейсом или более Отношение
Reachesfx, у), содержащее именно такие пары городов, описывается двумя правилами:
1. Reachesfx. у) -г— Flightsfa, х, у d, г)
2. Reachesfx у) <- Reachesfx, z) AND Reachesfz, у)
Согласно первому правилу, Reaches содержит такие пары городов что гз
первого из них можно попасть прямым авиарейсом. В этом правиле рейс а, время
вылета d и время прилета г произвольны. Согласно второму правилу, если из
города х можно попасть в город z, а из z в у, то из х можно попасть в у. Здесь
применяется нелинейная рекурсия, которая описывается в выделенном текс е,
озаглавленном “Другие формы рекурсии". Такая рекурсия в данном слу гае более
уместна, так как второе применение Flights в рекурсивном правиле содержит еще
три переменные для неиспользованных компонентов Flights.
Вычисление отношения Reaches проводится с помощью рекурсивного процесса,
описанного в разделе 4.4.2. С помощью первого правила получаются пары (SF, DEN).
(SF, DAL), (DEN, CHI), (DAL, CHI), (DAL, NY) и (CHI, NY), представленные ориенти-
рованными ребрами графа на рис. 4.19.
Затем по второму рекурсивному правилу получаются еще три пары: (CF, CHI),
(DEN, NY) и fSF, NY). На следующем шаге эти пары, представленные двумя ребрами,
комбинируются с парами, каждая из которых представлена только одним ориенти-
рованным ребром, и получаются пути в графе длиной до четырех ориентированных
ребер. Для данной диаграммы уже невозможно сформировать новую пару. Значит,
отношение Reaches состоит из десяти таких пар (х,у), что на рис. 4.19 у находится
справа от х. □
Пример 4.38. Еще более сложное определение, в котором два авиарейса можно
комбинировать в более длиннье последовательности, состоит в требовании, чтобы
самолет второго рейса покидал аэропорт не раньше чем через час после прибытия
в этот аэропорт самолета первого рейса. При этом применяется IDB-предикат
Connects(x, у, d, г), означающий, что можно вылететь из города х во время d и не
сколькими рейсами добраться до города у во время г. Если между рейсами имеется
связь, то есть по крайней мере не меньше часа на то, чтобы ее использовать.
Правила для Connect:6
1. Connectsfx, у, d, г) <- Flightsfa, х у, d, г)
2. Connectsfx, у, d г) -с— Connectsfx, z, d, t1) AND
Connectsfz, y, 12, r) AND t1 <= t2 + 100
На первом шаге вычисления правило 1 дает восемь кортежей отношения
Connects, показанных на рис. 4 21, каждый из которых соответствует одному из
авиарейсов, представленных на диаграмме рис. 4.19 Заметим, что одно из семи
ориентированных ребер этой диаграммы представляет два рейса в различное время.
Теперь попытаемся комбинировать эти кортежи по правилу 2. Например,
соединение второго кортежа с пятым дает (CF, CHI, 900, 1730), но второй кортеж не
комбинируется с шестым, так как самолет прибывает в Даллас в 14.30, а вылетает из
Далласа в 15.00, т.е. через полчаса. На рис. 4.22 показаны кортежи Connects,
полученнь е после второго шага. Результат второго шага отделен от результата
первого горизонтальной чертой, которая не является частью отношения.
s Зги правила работают только при допущении, что самолеты не вылетают
и не прилетают точно в полночь
176
Глава 4 Операции в реляционной модели
X У d Г
SF DEN 930 1230
SF DAL 900 1430
DEN CHI 1500 1800
DEN DAL 1400 1700
DAL CHI 1530 1730
DAL NY 1500 1930
CHI NY 1900 2200
CHI NY 1830 2130
Рис. 4.21. Бозоеые кортежи отношения Connects
На третьем шаге все пары кортежей, показанных на рис. 4.22, нужно рассмат-
ривать. в принципе в качестве кандидатов для двух кортежей Connects входящих
в тело правила 2. Однако, если оба кортежа находятся над горизонтальной линией,
значит, они уже анализировались на предыдущем шаге и не могут породить нового
кортежа. Получить новый кортеж можно только тогда, когда по крайней мере один
из двух кортежей отношения Connects, используемого в теле правила 2, был полу-
чен на втором шаге; т.е. нужно использовать кортежи, находящиеся на рис. 4.42
под горизонтальной линией.
X У d Г
SF DEN 930 1230
SF DAL 900 1430
DEN CHI 1500 1800
DEN DAL '400 1700
DAL CHI 1530 1730
DAL NY 1500 1930
CHI NY 1900 2200
CHI NY 1830 2130
SF CHI 900 1730
SF CHI 930 1800
SF DAL 930 1700
DEN NY 1500 2200
DAL NY 1530 2130
DAL NY 1530 2200
Рис, 4 22. Отношение Connects после второго цюго вычисления
На третьем шаге получаются три новых кортежа, находящихся в нижней части
Д^^щ : лщш^нуто^габлииы разделяют группы кортежей
4.4 Рекурсивное программирование в Datalog
177
полученных на первом, втором и третьем шагах вычисления. Новые кортежи полу-
чить невозможно, поэтому вычисление закончено и на рис. 4.23 изображено все
отношение Connects. □
X У d r
SF DEN 930 1230
SF DAL 900 1430
DEN CHI 1500 1800
DEN DAL 1400 1700
DAL CHI 1530 1730
DAL NY 1500 1930
CHI NY 1900 2200
CHI NY 1830 2130
SF CHI 900 1730
SF CHI 930 1800
SF DAL 930 1700
DEN NY 1500 2200
DAL NY 1530 2130
DAL NY 1530 2200
SF NY 900 2130
SF NY 900 2200
SF NY 930 2200
Рис. 4.23. Отношение Connects после третьего шага вычисления
4.4.4 Отрицание в рекурсивных правилах
Иногда в правилах, содержащих рекурсию, необходимо использовать отрицание
Есть опасный и безопасный способ соединения рекурсии с отрицанием. В общем
случае считается приемлемым применять отрицание только тогда, когда оно не
возникает внутри операции с фиксированной точкой. Рассмотрев приемлемый
и парадоксальный примеры соединения рекурсии с отрицанием, мы увидим, что
при наличии рекурсии полезно только ’стратифицированное" отрицание. Опреде-
ление термина стратифицированное” дается после примеров.
Пример 4.39. Предположим, что нужно найти на схеме рис. 4.19 такие пары
городов (х, у), чтобы самолет авиакомпании UA летел бы из х в у (возможно, через
несколько других городов), а самолет авиакомпании АА нет. Можно рекурсивно
определить предикат UAreaches так же, как определялся предикат Reaches в приме-
ре 4 37, но ограничиться при этом рейсами UA:
1. UAreaches(x, у) <- Flights(UA, х, у, d, г)
2 UAreaches(x, у) «- UAreaches(x, z) AND UAreaches(z у)
178
Глава 4 Операции в реляционной модели
Аналогично можно определить предикат AAreaches как такие пары городов (.г, у),
что из .г можно попасть в г только самолетами АА:
1. AAreaches(x, у) < - Flighls(AA. х. у, d, г)
2 AAreachesix. у) < - AAreaches(x. z) AND AAreaches(z. у)
Теперь с помошыо нерекурсивного правила легко вычислить предикат UAonly. состо-
яшни нз таких пар городов (х. у). что из х можно попасть в у только рейсами UA,
но не рейсами .АА:
UAonly(x, у) <- UAreac ies(x, у) AND NOT AAreaches(x, у)
По этому правилу вычисляется теоретико-множественная разность между UAreaches
и AAreaches.
В соответствии с данными, представленными на рис. 4.19, UAreaches состоит
ИЗ пар: (SF, DEN), (SF, DAL), (SF, CHI), (SF, NY), (DEN, DAL), (DEN. CHI), (DEN, NY)
и (CHI, NY). Это множество пар вычисляется итерированием операции фиксирован-
ной точки, описанной в разделе 4.4.2. Аналогично получается из этих же данных и
значение предиката AAreaches: (SF, DAL), (SF, CHI), (SF, NY), (DAL, CHI), (DAL, NY)
и (CHI. NY). Значением предиката UAonly является разность между четырьмя этими
множествами пар. т.е. (SF, DEN), (DEN, DAL). (DEN, CHI) и (DEN, NY). □
Пример 4.40. Приведем абстрактный пример, который будет посложнее преды-
дущих. Пусть Л - единственный унарный (одноместный) предикат EDB с единствен-
ным кортежем (0), а Р и Q— одноместные унарные предикаты IDB, определяемые
двумя правилами:
1. Р(х) <- R(x) AND NOT Q(x)
2. Q(x) <- R(x) AND NOT P(x)
Неформально говоря, эти правила означают, что элемент х из Л входит либо в Р,
либо в Q. При этом Р и Q определяются рекурсивно в терминах друг друга.
При выяснении смысла рекурсивных правил в разделе 4.4.1 говорилось, что
нужна наименьшая фиксированная точка — наименьшие отношения, делающие
данные правила истинными алгебраическими выражениями. Согласно правилу I,
Р= R-Q. а по правилу 2, Q = R-Р. Поскольку R содержит только кортеж (0),
он находится либо в Р. либо в Q. Где же именно находится данный кортеж?
Оказывается, он не может входить ни в Р. нн в Q. Например, из Р= R- Q следует
0 = (<0)} ~ 0> что явно ложно.
Если Р={(0)}. а 0=0. оба уравнения имеют решения. Р= Я-Сдает
{(0)} = ((0)) • 0, что истинно, и Q = R- Р дает 0= ((0)) - {(0)), что тоже истинно.
Значения Р = & и <2= НО)} тоже удовлетворяют обоим правилам. Значит, есть
два варианта значений:
а) Р={(0)}. 0=0
b) Р=0, G=((0)}
Они оба минимальны в том смысле, что при удалении любого кортежа из любого
отношения, рассматриваемые отношения уже нс удовлетворяют правилам. Следова-
тел! но, невозможно различить две минимальные фиксированные точки (а) и (Ь)
и ответить на простой вопрос: является ли Р(0) истинным? □
4.4 Рекурсивное программирование в Data од
179
Данный пример показывает, что метод определения смысла рекурсивных
правил или уравнений с фиксированной точкой не действует, когда рекурсия слиш-
ком тесно связана с отрицанием. Допустим, существует несколько минимальных
фиксированных точек, между которыми может возникнуть противоречие. Было бы
желательно иметь более эффективный метод определения смысла рекурсивного
отрицания, но, к сожалению, общего соглашения о том. что должны означать такие
правила или уравнения, нет.
Поэтому принято ограничиваться рекурсиями со стратифицированным (рас-
слоенным) отрицанием. Такое ограничение вводится, например, стандартом рекур-
сии SQL3, о котором пойдет речь в разделе 5.I0. Позже будет показано, что при
стратифицированном отрицании существует алгоритм вычисления определенной
минимальной фиксированной точки (возможно, из множества фиксированных
точек), соответствующий интуитивному пониманию смысла правил Свойство
стратифицированности определяется следующим образом.
1. Строится граф, соответствующий предикатам 1DB.
2. Если в правило, содержащее предикат Л в своей голове, входит отрица-
тельная подцель В, от узла А к узлу В проводится ориентированное ребро,
которое помечается знаком как отрицательное ребро.
3. Если в правило, содержащее предикат А в своей голове, входит неотрица-
тельная подцель В, от узла А к узлу В проводится обычное ориентирован-
ное ребро, не отмеченное знаком отрицания " ”.
Если в этом графе есть цикл, содержащий одно или несколько отрицательных
ребер, рекурсия не стратифицирована, в противном случае граф стратифицирован.
Предикаты 1DB можно сгруппировать в слои. Слой предиката А — это наибольшее
число отрицательных ребер на пути, начинающемся с А.
При стратифицированной рекурсии предикаты IDB можно оценивать в порядке
их слоев, начиная с первого. Такая стратегия дает одну из минимальных фиксиро-
ванных точек используемых правил. Еще важнее то, что она всегда оказывается
эффективной и позволяет получить "правильную" фиксированную точку, А нестра-
тифицированная рекурсия, как показывает пример 4.40, может вообще не привести
ни к какой "правильной" фиксированной точке, даже если есть широкий выбор
фиксированных точек.
Пример 4.41. На рис, 4.24 изображен граф для предикатов из примера 4,39,
AAreaches и UAreaches находятся в слое 0, так как ни один из путей, начинающихся
в их узлах, не содержит негативного ребра. UAonly относится к слою 1, потому что
из этого узла выходят пути с одним негативным ребром, но нет путей, содержащих
более одного негативного ребра. Значит, прежде чем вычислять UAonly, нужно пол-
ностью вычислить AAreaches и UAreaches,
UAonly
AAreaches
Рис 4.24. Граф, построенный по стратифицированной рекурсии
180
Глава 4 Операции в реляционной модели
Рис 4.25. Гроф, построенный по нестротифицироаонной рекурсии
Для сравнения построим 1тэаф для предикатов из примера 4.40 (рис 4 25). По-
скольку правило I имеет голову Р с отрицательной подцелью Q, существует
отрицательно направленное ребро от Р к Q, а поскольку правило 2 имеет голову Q
с отрицательной подцелью Р. существует отрицательное ребро и в обратном направлении.
Значит, получается негативный цикл и правила не стратифицированы. □
4.4.5 Упражнения к разделу 4.4
Упражнение 4.4.1. Добавляя или удаляя направленные ребра в диаграмме,
изображенной на рис. 4.19, можно изменить значения отношения Reaches из
примера 4.37, отношения Connects из примера 4.38 или отношений AAreaches и
UAreaches из примера 4.39. Найдите новые значения этих отношений, если:
"а) добавлено новое ребро АА, 1900-2100, направленное от CHI к SF;
Ь) добавлено новое ребро UA, 900-1100, направленное от NY к DEN,
с) добавлены два ребра, указанные в пунктах (а) и (Ь);
d) удалено ребро, направленное от DEN к DAL.
Упражнение 4.4.2. Сформулируйте правила Datalog (используя при необходи-
мости стратифицированное отрицание) для описания указанных ниже изменений
понятия "последователя” из примера 4 33. При этом можно использовать EDB-
отношение SequelOf и IDB-отношение FollowOn, определенные в примере 4.36.
*а) Р(х, у) означает, что фильм у следует за фильмом х, но не является про-
должением фильма X (как определено EDB-отношением SequelOf).
b) О(х, у) означает, что фильм у следует за х, но не является ни продолжени-
ем, ни продолжением продолжения х.
1 с) R(x) означает, что за фильмом х следуют по крайней мере два фильма.
Учтите, что они оба могут быть независимыми друг от друга продолжени-
ями х. т.е. необязательно, чтобы один был продолжением, а второй про-
должением продолжения.
Id) S(x.у) означает, что у следует за х и при этом имеет не более одного
последователя.
Упражнение 4.4.3. ODL-классы и их связи можно описать с помощью отно-
шения Rel(dass, rclass, mult), где mult обозначает множественность связей: multi —
многозначная, single - однозначная связь. Первые два атрибута — связанные классы;
связь направлена от class к rclass (связанный класс). Например, на рис. 4.26
пока кию отношение Rel, представляющее три ODL-класса из примера текущего
фильма, показанною на рис. 2.6.
Эти данные тоже можно представить в виде графа, узлами которого являются
классы, а ребра направлены от класса к связанному с ним классу и помечены как
multi или single. На рис. 4.27 изображен граф для данных из рис. 4.26.
4.5 Ограничения на отношения
181
class rclass mult
Star Movie multi
Movie Star multi
Movie Studio single
Studio Movie multi
Рис. 4.26. Представление ODL-связей с помощью реляционных донных
Выразите все описанные ниже предикаты с помощью правил Datalog, приме-
няя при необходимости стратифицированное отрицание Rel можно использовать
как отношение EDB Покажите шаги и результат вычислений по вашим правилам
на данных из рис. 4.26.
а) Предикат ₽(class, eclass) означает, что в графе классов есть путь6 от class
к eclass. Можно считать второй из этих классов погруженным в первый,
так как в некотором смысле он является частью объекта первого класса.
*! Ь) Даны предикаты: S(class, eclass) и M(class. eclass) Первый означает что
существует "однозначное погружение" eclass в class, т.е. путь от class
к eclass, на котором каждое из направленных ребер имеет отметку single.
Предикат М означает, что существует "многозначное погружение" edass
в class, т е. путь от class к eclass, содержащий по крайней мере одно
ориентированное ребро с отметкой multi.
с) Предикат Q(class, eclass) означает, что в графе классов есть путь от class
к eclass, но он в любом случае не является однозначным путем. Здесь
можно использовать предикаты, определенные ранее при выполнении
этого упражнения.
Рис. 4.27. Представление связей в виде грофо
4-5 Ограничения на отношения
Реляционная модель предоставляет средства выражения общих ограничений
типа ограничений ссылочной целостности, введенных в разделе 2.5. Фактически,
реляционная алгебра открывает широкие возможности и для выражения огромного
множества других ограничений. Как слсдуег из примера 4.44, в ретяционной
алгебре можно выразить даже функциональные зависимости. Ограничения имеют
важное значение в программировании БД. В главе 6 будет показано, как системы
БД SQL вводят в действие ограничения, которые можно выразить в реляционной
алгебре.
« В этом упражнении пустые пути нс считаются путями"
182
Глава 4 Операции в реляционной модели
4.5.1 Реляционная алгебра
как язык ограничений
Есть два способа применения выражений реляционной алгебры для формули-
ровки ограничений.
I. Если Л- выражение реляционной алгебры, то R = 0- ограничение, кото-
рое гласит: “Значение выражения Я должно быть пустым" (другими слова-
ми: "Результат выражения Я не содержит кортежей").
2. Если Я и 5- выражения реляционной алгебры, то Л с 5-ограничение,
которое гласит: "Каждый кортеж нз результата Я должен входить и в ре-
зультат 5". Разумеется, результат S может содержать дополнительные
кортежи, не порождаемые Я.
Эти способы эквивалентны по своим результатам, но иногда один из них ока-
зывается яснее и удобнее в применении, чем другой. С одной стороны, ограниче-
ние Яе 5 можно записать как Я-5=0. Действительно, если каждый кортеж из Я
входит и в 5, то Я - 5 пусто. И наоборот, если в Я - S нет кортежей, то каждый
кортеж из Я должен входить и в 5 (в противном случае он входил бы в R-S).
С другой стороны, ограничение R = 0 можно записать как R g 0. Технически 0
не является выражением реляционной алгебры, но, поскольку для его оценки
можно применить другие выражения, например Я-Я, вполне допускается исполь-
зовать 0 в качестве выражения реляционной алгебры
В следующих разделах будет показано, как выразить важные ограничения
одним из этих способов. Из главы б вы узнаете, что в программировании SQL
наиболее широко применяется первый из них — равенство с пустым множеством
Однако, как было сказано выше, при желании можно рассуждать в терминах вклю-
чения одного множества в другое, а затем преобразовать ограничение в стиле
равенства пустому множеству.
4-5.2 Ограничения ссылочной целостности
Согласно общему ограничению, названному в разделе 2.5 "ссылочной целост-
ностью", значение, возникающее в одном контексте, входит также и в другой, свя-
занный с ним контекст. Ссылочная целостность — это вопрос "придания смысла”
связям. То есть, если объект или сущность Л связаны с объектом или сущностью В,
то В должно реально существовать. Например, в терминологии ODL, если связь
в объекте А физически представлена указателем, он не может быть пустым
и должен указывать на подлинный объект.
В реляционной модели ограничения целостности выглядят несколько иначе.
Если в кортеже отношения Я есть значение я, то, исходя из целей проекта, можно
предполагать, что v будет отдельным компонентом кортежа другого отношения S.
Следующий пример показывает, как выразить ссылочную целостность реляцион-
ной модели в реляционной алгебре.
Пример 4.42 Рассмотрим два отношения из схемы БД идущих в прокате
фильмов:
Movie(title, year, length, inColor, studioName, producerC#)
MovieExec(name, address, cert#, netWorth)
Вполне разумно предположить, что производитель каждого фильма входит
в отношение MovieExec В противном случае что-то не так, и желательно, чтобы
система, реализующая реляционную БД, сообщала хотя бы о наличии фильма,
о производителе которого в системе нет никакой информации.
4.5 Ограничения на отношения
163
Точнее говори, компонент producerC# каждого из кортежей отношения Movie
должен входить и в компонент cert# некоторого кортежа отношения MovieExec.
Поскольку администраторы однозначно идентифицируются номерами сертифика-
тов, есть гарантия, что производитель фильма входит в число администраторов
этого фильма. Такое ограничение можно выразить с помощью включения одного
множества в другое
Яцихшию» (Movie) £tcer,„ (MovieExec)
Значение левой части данного выражения — это множество всех номеров
сертификатов, входящих в компоненты producerC# кортежей отношения Movie,
а значение правой части — множество всех номеров сертификатов, входящих
в компоненты cert# кортежей отношения MovieExec. Ограничение означает, что
каждый сертификат из первого множества должен входить и во второе.
Такое же ограничение можно выразить в виде равенства с пустым множеством.
ЛргоОиеис» (Movie) - лии# (MovieExec) = 0 □
Пример 4.43. Аналогично предыдущему примеру, можно выразить ограниче-
ние ссылочной целостности, в котором содержится "значение" представленное не-
сколькими атрибутами. Например, может понадобиться, чтобы фильм, упомянутый
в отношении
Starsln(movieTiUe, movieYear, starName)
появлялся и в отношении
Movle(titfe, year length, inColor, studioName, producerC#)
В обоих этих отношениях фильмы представлены парами название-год, так как по
соглашению ни один из этих атрибутов в отдельности не может идентифицировать
фильм. Ограничение
moveVear (StSCSln) О уваг (Movie)
выражает ограничение референциальной целостности путем сравнения пар назва-
ние-год, порожденных проекцией обоих отношений на соответствующие списки
компонентов. □
4-5.3 Дополнительные примеры ограничений
Рассматриваемая нотация позволяет выразить не только ссылочную целост-
ность. Например, любую функциональную зависимость можно выразить в виде
алгебраического ограничения, хотя его запись сложнее записи функциональной
зависимости, которую мы применяли ранее.
Пример 4.44. Представим в виде алгебраического выражения функциональную
зависимость
name -> address
для отношения
MovieStar(name, address, gender birthdate)
Идея ограничения в том, что среди всех сконструированных пар кортежей (г(, /2)
отношения MovieStar не должно быть пары, кортежи которой совпадают по компо
ненту пате, но не совпадают по компоненту address Для создания пар применяется
декартово произведение, а для поиска пар, нарушающих функциональную зависи
мость, выбор Ограничение устанавливается путем приравнивания полученного
результата к 0.
184
Глава 4 Операции в реляционной модели
Поскольку берется произведение отношения с самим собой, для получения
имен атрибутов такого произведения сначала нужно переименовать по крайней
мере одну копию исходного отношения Для краткости при ссылке на отношение
Moviestar мы используем два новых имени MS1 и MS2. Тогда функциональная
зависимость представима в виде алгебраического выражения:
ns.rc MS3 ram- АНО MSI address -MS2 address (M S1 X MS2) = 0
В этом выражении MS1 п произведении MSI х MS2 — сокращение результата пере-
именования:
РЮТ(«аг«с', nddrtst.gender. binhdatri (MovieS ЯГ
a MS2 — аналогичное переименование отношения MovieStar. □
Другой вид ограничения — ограничение области значений Часто оно просто
требует, чтобы значения атрибутов относились к определенному типу данных, на-
пример к целым числам или строкам длиной в 30 символов. Такие ограничения не
выразимы и реляционной алгебре, так как типы, подобные целым числам, нс явля-
ются ее ч-зстыо. Однако нередко ограничения области содержат особые значения
атрибутов. Если множество допустимых значений можно выразить в виде условий
выбора, ограничение области выразимо в языке алгебраических ограничений.
Пример 4.45. Допустим, нужно зафиксировать, что единственными допусти-
мыми значениями атрибута gender отношения MovieStar являются "F" и "М". Это
ограничение можно выразить алгебраически:
^gender-'Г' AND gander-ТЫ' (MoV eStar — 0
те. множество кортежей в MovieStar, компонент которых gender не равен ни F
ни М, пусто. □
И наконец, есть ограничения, не попадающие ни в одну из категорий, описанных
в разделе 2.5. Язык алгебраических ограничений позволяет выразить множество
новых видов ограничений Приведем один пример.
Пример 4,46. Предположим, нужно потребовать, чтобы президентом студии мог
быть только тот, кто имеет чистый доход не менее $ 10 000 000. Такое ограничение
не относится нн к ограничениям области, ни к ограничениям по единичному
значению, ни к ссылочной целостности. Тем не менее его можно выразить алгебра-
ически. Построим тета соединение двух отношений:
MovieExecfname. address, cert#, netWorth)
Studio(name address presC#)
используя условие, согласно которому атрибуты presC# из Studio и cert# из MovieExec
равны между собой. Такое соединение создает пары кортежей, состоящие из студии
н руководителя, являющегося ее президентом. Из этого отношения выберите
кортежи, в которых чистый доход менее десяти миллионов. Получится множество,
которое, согласно данному ограничению, должно быть пустым. Итак, записываем
алгебраическое ограничение:
°п*лгопп « кхюоооо (Studio txtp,eiCi,. cen, MovieExec) = 0
Это же ограничение можно выразить и путем сравнения сертификатов, пред-
ставляющих президентов студий, с множеством сертификатов, представляющих
администраторов, чей чистый доход составляет не менее S10 000 000. причем
первое множество должно быть подмножеством второго. В результате получаем
выражение:
яргепс» (Studio) с nMrW (Onaway юооосоо (MovieExec)) □
a 5 Ограничения на отношения 165
4-5.4 Упражнения к разделу 4.5
Упражнение 4.5.1. Выразите перечисленные ниже ограничения на следующие
отношения из упражнения 4 4.1:
Product(maker, model, type)
PC(model speed ram, hd, cd, price)
Laptop(model speed, ram, hd, screen, price)
Printerfmodel, color, type, price)
Ограничения можно выражать любым из рассмотренных выше способов.
Укажите нарушения этих ограничений для данных из упражнения 4.1.1.
®а) ПК со скоростью процессора менее 150 не должны продаваться более чем
за $1500.
Ь) ПК-блокнот с размером экрана менее II дюймов должен иметь жесткий
диск не менее I Гбайт или должен продаваться дешевле $2000.
!с) Пи один производитель ПК не производит ПК-блокноты.
4 ! d) Производитель ПК должен производить и ПК-блокноты, имеющие такую
же или большую скорость процессора.
!с) Если основная память ПК-блокнота превышает основную память ПК, его
цена тоже должна превышать цену ПК.
Ипрагинение 4 5 2. Выразите в реляционной алгебре следующие ограничения,
основанные на отношениях упражнения 4.1.3:
Classes(class, type, country, numGuns, bore)
Ships(name, class, launched)
Battlesfname, date)
Outcomes(ship, battle, result)
Ограничения можно выражать любым из рассмотренных выше способов.
Укажите нарушения этих ограничений для данных из упражнения 4.1.3.
а) Ни один класс кораблей не может иметь орудия калибра более 16 дюймов.
Ь) Если класс кораблей имеет более девяти орудий, то их калибр должен
превышать 14 дюймов.
!с) Ни один класс не может содержать более двух кораблей.
!d) Ни одна страна не может владе ь одновременно линкорами и крейсерами.
!! е) Ни один корабль, имеющий более девяти орудий, не может участвовать
в бою прошв корабля, который имел меньше девяти орудий и был
потоплен.
Упражнение 4.5.3. Ограничения можно выразить не только в реляционной
алгебре, но и в Datalog. Запишите правило или правила Datalog, определяющие
предикат IDE, значение которого должно быть пустым. Выразите в Datalog-
’а) ограничения из примера 4.42;
Ь) ограничения нз примера 4.43:
с) ограничения из примера 4.44;
<1) ограничения нз примера 4 45;
е) ограничения из примера 4.46.
186
Глава 4 Операции в реляционной модели
! Упражнение 4.5.4. Пусть Л и 5-отношения, а С—ограничение ссылочной
целостности, согласно которому, если Л содержит кортеж, со значениями v,, v2,.... v„
в отдельных атрибутах /1„ Л2, ..., А„ то в Одолжен быть кортеж, имеющий те же
значения ц, is, .... v„ в отдельных атрибутах Bh Вь ..., В„. Выразите ограничение С
в реляционной алгебре.
18 Упражнение 4.5.5. Пусть В - отношение, и функциональная зависимость
Л, Л... /!„ -> В включает в себя атрибуты Л. Выразите в реляционной алгебре огра-
ничение, согласно которому эта функциональная зависимость должна быть истин-
ной в R.
4 6 Реляционные операции
на мультимножествах
Несмотря на то что множество кортежей (т.е. отношение) является простой
моделью данных в том их виде, в каком они могут входить в БД, коммерческие
системы БД редко (и вряд ли когда-либо вообще) строятся исключительно на основе
множеств. В некоторых ситуациях допускается, что отношения, входящие в систему
БД, содержат дублирующиеся кортежи. Напоминаем, что "множество", содержащее
несколько вхождений какого-либо своего элемента, называется мультимножеством.
В этом разделе рассматриваются отношения, являющиеся мультимножествами, а не
множествами, т.е. один и тот же кортеж может входить в одно и то же отношение
несколько раз. Термином "множество" обозначается отношение без повторяющихся
кортежей, а термином "мультимножество' — отношение, содержащее (или не содер-
жащее) повторяющиеся кортежи.
Пример 4.47. Отношение на рис. 4.28 — это мультимножество кортежей,
в которое кортеж (1,2) входит трижды, а кортеж (3, 4) один раз. Если бы оно было
основано на множестве, нужно было бы удалить из него два вхождения кортежа (), 2).
В отношении, основанном на мультимножестве, действительно допустимо повторе
ние вхождений некоторого кортежа, но. как и во множествах, порядок кортежей не
имеет значения. □
А В
1 2
3 4
1 2
1 2
Рис. 4 28. Мультимножество
4.6 1 Причины использования мультимножеств
Анализ вопросов эффективной реализации отношений показывает, что ис-
пользование мультимножеств может увеличить скорость операций на отношениях.
Например если мультимножество допускается в качестве результата проекции
с каждым кортежем можно работать независимо. Если же результатом является
множество, необходимо сравнивать результат проекции из нежелательных компо
нентов каждого кортежа с результатом проецирования всех остальных кортежей,
чтобы убедиться в том, что такая проекция ранее не встречалась. Если же резуль-
татом является мультимножество, мы просто проецируем каждый кортеж
и добавляем его к результату; при этом не требуется никакого сравнения прое
цированных кортежей.
4.6 Реляционные операции на мультимножествах
187
А
1
3
1
ig i.c
2 5
4 6
2 7
1 2 8
I
Рис. 4.29. Мультимножество для примера 4 48
Пример 4.48 Мультимножество, изображенное на рис. 4.28, может быть ре-
зультатом проекции отношения из рис. 4.29 на атрибуты А и В при условии, что
результат —это мультимножество. Если же применить обычный оператор проекции
реляционной алгебры, а значит, удалить дубликаты кортежей, получается только
отношение
А В
1 2
3 4
Результат в виде мультимножества по размеру больше этого отношения, хотя
вычисляется быстрее, так как необязательно сравнивать каждый кортеж (1,2) или
(1,3) с построенными ранее кортежами
Более того, если проекция отношения применяется для получения статистиче-
ского значения (как было показано в разделе 5.5) типа среднего значения А в отно-
шении, показанном на рис. 4.29, для анализа проецированного отношения нельзя
применять модель множества. Для множества среднее значение А равно 2, так как А
имеет только два различных значения: 1 и 3, средним значением которых является 2.
Если же этот столбец на рис. 4.29 считается мультимножеством {1,3, 1, 1}, получа-
ется правильное среднее значение А для четырех кортежей — 1,5. □
Когда результатом является мультимножество, можно сэкономить время и при
вычислении объединения отношений. Если в результате вычисления R и 5 должно
получиться множество, необходимо проверять, является ли каждый кортеж из 5
членом R. Если он входит в R, то он не вносится в объединение, если не входит
в R, вносится в объединение. А при допущении мультимножества в качестве
результата его можно получить, просто колируя все кортежи из R и 5 независимо
от того, входят ли они одновременно в оба отношения.
4.6.2 Объединение, пересечение и разность
мультимножеств
При объединении двух мультимножеств берется сумма вхождений каждого из
кортежей. То есть, если R — мультимножество, в которое кортеж t входит п раз,
a S мультимножество, в которое кортеж t входит т раз, в мультимножество R о S
кортеж t входит п + т раз При этом и и т порознь или одновременно могут рав-
няться 0.
При пересечении мультимножеств R и 5, в которые кортеж I входит п и т раз
соответственно, в Rr\ S кортеж t входит min(n, т) раз. При вычислении разности
Я - 5 мультимножеств R и 5 кортеж t входит в R S тах(0, п - т} раз То есть, если
в R вхождений t больше, чем в 5, то число вхождений t в R- S равно числу вхожде-
ний t в R минус число вхождений 7 в 5. Если же число вхождений I в 5 не меньше
числа вхождений t в R, то t вообще не входит в Я J. С интуитивной точки зрения
каждое вхождение t в S "аннулирует" одно вхождение в R.
188
Глава 4 Операции в реляционной модели
Мультимножественные операции
на множествах
Представьте себе два множества — R и S. Любое множество может мыслить-
ся как мультимножество, в котором случайно оказалось только по одному
вхождению каждого элемента. Пусть выполняется пересечение Rr,S, но R н 5
считаются мультимножествами и применяется правило пересечения мульти-
множеств. Результат получается такой же, как и тогда, когда R и 5 являются
множествами. То есть, если R и 5 мыслятся как мультимножества, число
вхождение кортежа г в Rc-S равно минимальному из чисел его вхождений
в R и 5. Поскольку R и 5 на самом деле множества, t может входить в каждое
из них только 0 или 1 раз. Независимо от того, применяются лн правила
пересечения множеств или мультимножеств, оказывается, что t может входить
в Rr\ S не более одного раза и ходит в пересечение именно один раз, когда он
входит и в Я, и в 5. Применение правила разности мультимножеств R - S или
5- Л тоже дает точно такой же результат, как и применение правила разности
множеств.
Однако объединение ведет себя ио-разному в зависимости от того, счита-
ются ли R и S множествами или мультимножествами. Если для вычисления
объединения RuS применяется правило для мультимножеств, результат
может не быть множеством, даже если R и 5— множества. В частности, если
[ кортеж t входит в R и 5, то он входит в R\.j S дважды, когда R и 5 мульти
। множества. Если же применяется операция над множествами, / входит в Я и 5
' только один раз Отсюда следует вывод: производя объединение, внимательно
, следите за тем, что именно объединяется — множества или мультимножества.
Пример 4.49. Пусть Я —отношение, изображенное на рис 4.28, т.е. мульти-
множество, в которое кортеж (1,2) входит трижды, а кортеж (3,4) один раз.
Пусть 5 — мультимножество:
А В
1 2
3 4
3 4
5 6
Тогда Rv S'- это мультимножество, в которое (1, 2) входит четыре раза (три вхож-
дения из Я и одно вхождение из S), (3. 4) входит зри раза и (5, б) один раз
Пересечение Я ,-~i 5— это мультимножество:
A i В
1 , 2
3 И
в которое (I, ?) и (3, 4) входят по одному разу. То есть. (1.2) входит трижды в Я
и один раз в 5, a min(3, 1) = 1, значит, (1,2) входит в Яп5 только один раз.
Аналогично. (3.4) входит в RrtS (1,2)= 1 раз. Кортеж (5,6) входящий один раз
в 5 и не входящий в Я, входит min(0, 1) = 0 раз в Rr S.
4,6 Реляционные операции на мультимножествах
169
Разность мультимножеств Я- S' -это мультимножество:
А [ В
1 2
1 I 2
Действительно, (I 2) входит трижды в Я и один раз в 5, значит, в Я - S'он входит
тах(0 3 - 1) = 2 раза Кортеж (3, 4) входит один раз в Я и дважды в S, поэтому
в Я — S' он входит тах(0,1 -2) =0 раз. В Я нет других кортежей, поэтому их не
может быть и в Я - Я.
Еще один пример мультимножества — разность 5-Я:
А В
3 4
5 6
Кортеж (3,4) входит в него один раз, поскольку такова разность между числом его
вхождений в 5 и Я. Кортеж (5, 6) входит в 5- Я по той же самой причине. В дан-
ном случае результирующее мультимножество оказалось множеством. □
4-6.3 Проекция мультимножеств
Проекция мультимножеств уже рассматривалась в примере 4 48, где каждый
кортеж обрабатывался независимо от других. Если Я - мультимножество, изобра-
женное на рис. 4.29, и вычисляется мультимножественная проекция В(Я), полу-
чается мультимножество, показанное на рис. 4.28.
Если устранение одного или более атрибутов в процессе проекции вынуждает
строить один и тот же кортеж из нескольких кортежей, повторяющиеся кортежи не
удаляются из результата мультимножественной проекции. Значит, проекция каждого
из кортежей (1,2, 5), (1, 2,7) и (1,2, 8) отношения Я из рис. 4.29 на атрибуты А и В
порождает один и тот же кортеж (1,2). В результате-мультимножестве есть три
вхождения этого кортежа, в то время как в результате-множестве только одно
Алгебраические законы мультимножеств
Алгебраический закон — это эквивалентность двух выражений реляцион-
ной алгебры, аргументами которых являются переменные, обозначающие
отношения Суть эквивалентности в том, что два выражения определяют одно
и то же отношение независимо от того, какие отношения подставлены вместо
переменных. Пример широкоизвестного закона - закон коммутативности
обт единения: fixj S= Su Я. Он верен независимо от того, считаются ли реля-
ционные переменные Я и 5 множествами или мультимножествами. Однако I
есть ряд других законов, которые действуют, когда реляционная алгебра «
интерпретируется в обычном стиле с отношениями в виде множеств, но не г
действуют, когда отношения интерпретируются как мультимножества. Простой |
пример такого закона — закон дистрибутивности теоретико-множественной раз 1
ности относительно объединения (ЯоА) Г). Он верен для |
множеств, но не для мультимножеств. Действительно, пусть Я, 3 и Т- муль- I
тимножесгва, содержащие по одной копии Тогда в левой части эквивалентно- f
сти есть одно вхождение г, а в правой нет ни одного. В случае с множествами 1
ни в одной части эквивалентности нет вхождений Г. Анализ алгебраических 1
законов для мультимножеств включен в упражнения 4.6.4 и 4.6.5.
190
Глава 4 Операции в реляционной модели
4.6.4 Операция выбора на мультимножествах
Для выполнения выбора на мультимножестве условие выбора применяется не
зависимо к каждому кортежу и, как всегда с мультимножествами, повторяющиеся
кортежи не удаляются из результата.
Пример 4.50. Есл1 Я—мультимножество
А В С
1 2 5
3 4 6
1 2 7
1 2 7
результатом мультимножественного
выбора аСг6(Я) является
А
3
1
1
В
4
2
2
С
6
7
7
То есть условию выбора удовлетворяют все кортежи, кроме первого. В результат
включаются оба последних идентичных кортежа Я. □
А В
(а) Отношение R 1 2
1 2
е С
(Ь) Отношение 5 2 3
4 5
4 5
А R.B S.B С
1 2 2 3
(с) Произведение Ry. S 1 2 2 3
1 2 4 5
1 2 4 5
1 2 4 5
1 2 4 5
Рис. 4.30. Вычисление произведения мультимножеств
4.6 Реляционные операции на мультимножествах 1Э1
4-6.5 Произведение мультимножеств
Согласно правилу для декартова произведения мультимножеств, каждый кортеж
одного отношения спаривается с каждым кортежем другою, независимо от того,
дублируется он или нет. В результате, если кортеж г входи! в R т раз, а кортеж л
дайлит в 5 п раз. кортеж rs войдет в Л х 5 тп раз
Пример 4.51- Пусть Я и 5— мультимножества, показанные на рис. 4.30. Тогда
произведение R*S состоит из шести кор1ежей, показанных на рис 4.30(c)
Заметим, что обычное соглашение относительно имен атрибутов, введенное для
отношений-множеств, действует и для мультимножеств. Поэтому атрибут В,
принадлежащий отношениям R и 5, дважды входит в произведение, и каждому
его вхождению предшествует имя одного из отношений □
4-6.6 Соединения мультимножеств
Процедура соединения мультимножеств тоже не содержит сюрпризов. Каждый
кортеж одного отношения сравниваем с каждым кортежем другого и решаем,
успешно ли они соединяются. Если да, полученный при их объединении кортеж
вносится в результат, причем повторяющиеся кортежи из результата не устраняются.
Пример 4.52. Натуральным соединением ЛмЗ1 отношений R и 5, показанных
на рис. 4.30, является отношение
Д J В j С
1 2 । 3
1 2 I 3
Здесь кортеж (1,2) из R соединяется с кортежем (2, 3) из 5. Поскольку в Л две
копии (1,2) и в 5 одна копия (2.3), существуют две пары кортежей, которые при
объединении дают (1,2, 3). Больше никакие другие кортежи из R и S успешно не
соединяются
Тета-соединение тех же отношений R и 5

порождает мультимножество
А R.B S.B С
1 2 4 5
1 2 4 5
1 2 4 5
1 2 4 5
Это объединение вычисляется следующим образом. Кортежи (1,2) из R и (4, 5) из 5
удовлетворяют условию объединения. Поскольку каждый из них появляется
в эти хотношениях дважды, числом вхождений объединенного кортежа в результат
будет 2x2 = 4. Другое возможное объединение кортежей (1,2) из Л с (2,3)
из 5— не удовлетворяет условию объединения, поэтому их комбинация не входит
в результат □
192
Глава 4 Операции в реляционной модели
4.6.7 Применение правил Datalog
к мультимножествам
Методы вычисления выборов, проекций и объединений мультимножеств
можно применить и к правилам Datalog при условии, ЧТО В НИХ нет отрицательных
реляционных подцелей. Строго говоря, берется соединение отношений, представ-
ленных в виде различных подцелей, к результату применяется любой выбор, вклю-
ченный в арифметические подцели, и результат выбора проецируется на голову
правила. На каждом нз этих шагов применяется алгоритм подходящий для мульти-
множеств.
С концептуальной точки зрения проще применить второй подход к опенке
правил Datalog (см. раздел 4.2.4). При таком подходе просматривается каждая неот-
рицательная реляционная подцель и вместо нее подставляются все кортежи отно-
шения для предиката этой подцели. Если выбор кортежей для каждой подцели дает
непротиворечивое значение для каждой переменной и все арифметические подцели
становятся истинными,7 сразу ясно, какой становится голова правила при данном
приписывании значений переменным.
Так как мы имеем дело с мультимножествами, дубликаты не устраняются из
головы правила. Более того, поскольку рассматриваются все комбинации кортежей
для подцелей, кортеж, входящий п раз в отношение для подцели, рассматривается
п раз как кортеж для этой подцели в конъюнкции с со всеми комбинациями
кортежей для других подцелей.
Пример 4,53. Рассмотрим правило
Н(х, z) ♦- R(x, у) AND S(y, z)
Пусть Л и 5—отношения, изображенные на рис. 4.30. Единственное непротиворе-
чивое приписывание кортежей подцелям (т.е. приписывание, при котором значения
переменной у из каждой подцели совпадают) получается, когда первой подцели
приписывается кортеж (I, 2) из Я, а второй подцели приписывается кортеж (2, 3)
из 5. Поскольку (1,2) входит в R дважды, а (2, 3) входит в 5 один раз, есть два
приписывания кортежей, порождающих приписывания переменных х = I, у=2 и
г = 3. Кортеж головы правила (х, г) при каждом из этих приписываний равен (1,3).
Значит, в отношении Н головы правила нет никаких кортежей, кроме двух вхожде-
ний кортежа (I, 3). Огсюда
Н1 Н2
1 3
1 3
является головным отношением, определяемым этим правилом, где атрибутам
произвольно присвоены имена и /12. В обшем случае, если бы кортеж (1,2)
входил п раз в Я. а кортеж (2. 3) входил т раз в 5, кортеж (1.3) входил бы пт раз
в Н. □
Если отношение определяется несколькими правилами, результат является
мульгимножественным объединением всех кортежей, порожденных каждым из
правил.
? В правиле не должно быть ни одной отрицательной ретяционной подцели. Ясного
определения смысла произвольных правил Daialog с отрицательными реляционными
подцелями для муяьтимиожествешюй модели не сушестоуе
4.6 Реляционные операции на мультимножествах
193
Пример 4.54. Рассмотрим отношение Н. определяемое двумя правилами
Н(х, у) <- S(x, у) AND х > 1
Н(Х, у) «- S(x, у) AND у < 5
и отношение S, имеющее значения, показанные на рис. 4.30(b). Согласно первому
правилу, все три кортежа из 5 вводятся в //, так как в каждом из этих кортежей
первый компонент больше 1. По второму правилу в Н попадает только кортеж (2, 3),
так как (4, 5) нс удовлетворяет условию у< 5. Поэтому в результирующее отноше-
ние Н входят две копии кортежа (2 3) и две копии кортежа (4, 5). □
4.6.8 Упражнения к разделу 4.6
* Упражнение 4.6.1. Пусть PC - отношение, изображенное на рис 4.10(a)
Нужно вычислить проекцию л¥т/(РС). Каковы значения этого выражения как
множества и как мультимножества? Каковы средние значения кортежей этой
проекции, когда отношение считается множеством или мультимножеством?
Упражнение 4.6.2. Выполните упражнение 4.6.1 для проекции it^fPC).
Упражнение 4 6 3. Это упражнение относится к отношениям линкоров из
упражнения 4 13
а) Выражение (Classes) влечет отношение с единственным столбцом,
содержащим калибры орудий различных классов. Для данных из упраж
нения 4 1 3 покажите, как выглядит это отношение в виде множества и
мультимножества.
! Ь) Запишите выражение реляционной алгебры, содержащее калибры орудий
кораблей (но не классов) Это вьражение должно иметь смысл для муль-
тимножеств, т.е число вхождений значения Ь должно совпадать с числом
кораблей, имеющих калибр орудий Ь.
Упражнение 4 6.4. Определенные алгебраические законы для отношений,
интерпретируемых как множества, верны и для отношений, которые считаются
мультимножествами. Объясните, почему каждый из следующих законов действует
и для множеств, и для мультимножеств.
*а) Закон ассоциативности объединения: (Rv S) u Т~ Ru (Su Т).
Ь) Закон ассоциативности пересечения’ (Ял 6) л Т= Ял (5л Т).
с) Закон ассоциативности натурального объединения:
(Rixi5)ixi7,eA><i(Sixi7)
d) Закон коммутативности объединения (Ли 5) = (SR)
е) Закон коммутативности пересечения: (Ял 5) =(5л Я).
f) Закон коммутативности натурального объединения: (Ах 3") ~ (,5 tx /?).
g) зЛ (R-~j S) = nf. (R) j-t (5), где L - произвольный список атрибутов
*11) Закон дистрибутивности объединения относительно пересечения:
Ли(.Г.о7) = (ЯиАп(Яо 7)
О Ос and с (Я) -=gc (Я) л °о (Я). где Си £>- произвольные условия
относительно кортежей Я
194
Глава 4 Операции в реляционной модели
!! Упражнение 4.6.5. Следующие алгебраические законы действуют для множеств,
но не для мультимножеств. Объясните, почему они верны для множеств, и приве
дите противоположные примеры, доказывающие, что они не верны для мультимно-
жеств.
*а) Т).
Ь) Закон дистрибутивности пересечения относительно объединения:
Лп(5и7)в(Лп5)и(йл Г).
с) ос or где Си D - произвольные условия
относительно кортежей R.
4.7 Другие расширения
реляционной модели
Существует ряд понятий и операций, которые не являются частью формальной
реляционной модели, но входят в реальные языки запросов В этом разделе упоми-
наются операции, которые изменяют отношения, вычисляют ’'агрегаты" типа суммы
столбцов отношения и определяют "представления", или именованные функции
отношений. Каждая из них входит в язык баз данных SQL и будет рассмотрена
в главе 5. Некоторые из них упоминаются и при анализе языка запросов OQL
в главе 8.
4.7 -1 Модификации
Реляционная алгебра и Datalog — это языки запросов в том смысле, что каж-
дый из них позволяет вычислять отношение или ответ, являющиеся функцией от
некоторых заданных отношений. Несмотря на всю важность запросов, БД, которую
нельзя изменить, не представляет особого интереса. Поэтому все реальные языки
БД содержат и средства для формулировки запросов к БД, и средства ее измене-
ния. Необходимы команды, обеспечивающие как минимум
1. Введение кортежей в отношение.
2. Удаление кортежей из отношения
3. Обновление существующих кортежей путем изменения их компонентов.
4.7.2 Агрегаты
Операции реляционной алгебры воздействуют на определенные кортежи неза-
висимо от других кортежей этого же отношения Часто требуется скомбинировать
кортежи единственного отношения и получить агрегированное значение, т.е. функ-
цию от всех кортежей, смешанных каким-нибудь способом Например, в примере
с фильмами может понадобиться:
• подсчитать число различных фильмов, упомянутых в отношении Movie;
• составить таблицу показывающую сумму длин фильмов, вылущенных
каждой студией;
• найти администратора фильма с наибольшим чистым доходом.
Реальные языки запросов к БД позволяют применять операторы агрегации к столб-
цам отношения, подсчитывать и суммировать их, вычислять минимальные и мак-
симальные значения.
4.8 Итоги
195
4.7.3 Представления
Выражение реляционной алгебры можно интерпретировать как ''программу",
которая вычисляет отношение А и печатает или как-то иначе воспроизводит его в виде
результата. Однако возможна и другая интерпретация реляционного выражения.
Его допустимо рассматривать как формулу, определяющую отношение, которое не
строится до тех пор пока эта формула не применяется к реальным отношениям
В терминологии БД такие формулы называются представлениями. Им обычно
присваиваются имена, которые используются в других реляционных выражениях
так словно представления являются реальными отношениями.
Правила Datalog тоже иллюстрируют различие между запросом и представле-
нием. Напомним, что предикаты или отношения, определяемые этими правилами,
считаются интенциональными, т.е. выражают определения отношения, которые не
должны существовать в экстенсиональной, или хранимой в памяти, форме. Пред-
ставление эквивалентно интенциональному предикату. Точно так же, как интенци-
ональные предикаты используются в телах правил, представление реализуется
в качестве аргумента алгебраического выражения Точно так же, как набор правил
Datalog применяется к БД, состоящей из хранимых в ней отношений, представле-
ние вычисляется в случае необходимости.
4-7.4 Пустые значения
Часто возникает необходимость приписать значение компоненту кортежа, но
при этом оно нам неизвестно. Например, можно знать, что Кевин Кестнер — кино-
звезда, но при этом не знать даты его рождения. В то же время каждый кортеж
отношения MovieStar имеет компонент birthdate. Как же зафиксировать его значе-
ние9 Именно в таком случае применяется специальное значение NULL, называемое
пустым значением. В некотором смысле NULL ничем не отличается от других
значений, но, в то же время, оно не является реальным значением. В частности,
при соединении отношений два компонента NULL не считаются равными друг
другу. Например, если кортежи, представляющие двух кинозвезд одного фильма,
имеют в своих компонентах birthday значение NULL, это не значит, что даты рожде
ния этих кинозвезд должны совпадать.
Существует множество интерпретаций нулевых значений. Приведем наиболее
распространенные из них.
1. Значение неизвестно-, известно, что здесь есть какое-то значение, но неиз-
вестно, какое именно Примером такой интерпретации является неизвест-
ная дата рождения, о чем только что шла речь.
2. Значение не применимо; нет значения, которое в данном случае имело бы
смысл. Например, если отношение MovieStar имеет атрибут spouse (супруг,
супруга), кортеж, представляющий кинозвезду, обязательно имеет в этом
атрибуте нулевое значение, и не потому, что неизвестно имя супруга или
супруги, а потому, что их просто не существует.
3. Значение скрыто; у нас нет полномочий знать используемое здесь значе-
ние Например, засекреченный номер телефона может быть представлен
в компоненте phone значением NULL
4.8 Итоги
+ Реляционная алгебра. Эта алгебра — важная форма языка запросов для реля-
ционной модели. Главными ее операторами являются объединение, пере-
сечение. разность, выбор, проекция, декартово произведение, натуральное
соединение, тета-соединение и переименование
196
Глава 4 Операции в реляционной модели
+ Catalog. Эта форма логики - важный тип языка запросов для релящ онной
модели. В Datalog записываются правила, в которых предикат или отноше-
ние определяется в терминах тела, состоящего из подцелей. Голова и подце-
ли правила являются атомами, а атом состоит из (возможно, отрицательного)
предиката, применяемого к некоторому числу аргументов. Все запросы,
представимые в реляционной алгебре, можно записать и в Datalog.
+ Рекурсивный Catalog. Правила Datalog могут быть рекурсивными, что позво-
ляет определять отношение в его собственных терминах. Смысл рекурсивных
правил Datalog определяется наименьшей фиксированной точкой — наимень-
шим множеством кортежей для определяемого отношения, делающим голову
правила в точности равной тому, что следует из его тела.
Стратифицированное отрицание. Когда рекурсия включает в себя отрицание,
наименьшая фиксированная точка может не быть уникальной, а правилам
Datalog в отдельных случаях невозможно придать приемлемый смысл. Требо-
вание стратифицированного отрицания запрещает применение отрицания
внутри рекурсии. Для каждого правила Datalog такого типа существует одна
наименьшая фиксированная точка (возможно, несколько таких точек). Эти
точки определяют общепринятый смысл данных правил.
* Отношения как мультимножества. В коммерческих системах БД отношения
действительно являются мультимножествами, в которые один и тот же
кортеж может входить много раз. Операции реляционной алгебры на мно
жествах можно распространить и на мультимножества, однако некоторые
алгебраические законы для мультимножеств не действуют.
ь Отношения в коммерческих системах. Помимо мультимножесгвенной модели
отношений, коммерческие системы используют операции, отсутствующие в
реляционной алгебре или Datalog: введение, удаление и изменение кортежей
в отношениях, агрегацию отношений и пустые значения в кортеждх.
4-9 Литература к главе 4
Реляционная алгебра составляет предмет исследований ставшей уже классиче-
ской статьи [4], посвященной реляционной модели. Но у языков запросов такого
единого источника нет. В одной из своих ранних статей по реляционной модели [5]
Кодд ввел форму первопорядковой логики - реляционное исчисление. Это исчисле-
ние - язык выражений, во многом сходный с реляционной алгеброй и фактически
равный ей по своей выразительной силе, что и доказывается в [5]
Появление Datalog, который выглядит скорее как набор правил, было навеяно
языком программирования Prolog. Однако Datalog выразительнее реляционного
исчисления, поскольку содержит рекурсии Книга [6] в основном посвящена разви-
тию логики как языка запросов, а в [?] эти же идеи рассматриваются в контексте
систем БД. Оригинальная статья [8] посвящена применению запросов для выраже-
ния ограничений.
Мысль о том что стратифицированный подход позволяет сделать правильный
выбор фиксированной точки, сформулирована в [3], а идея применения такого
подхода к оценке правил Datalog реализована в [1, 7 и 10]. Дополнительную
информацию о стратифицированном отрицании, о связи между реляционной
алгеброй, Dalal g и реляционным исчислением, а также вычислений правил
Datalog с отрицанием и без отрицания можно найти в |9].
1. Apt, К. R., Н. Bit г and A. Walker, Towards a theory of declarative knowledge",
in Foundations of Deductive Databases and Logic Programming (J Minker, ed )
pp. 89-148, Morgan-Kaufmann, Sait Fiancisco, 1988.
4.9 Литература к лаве 4
2. Bancilhon, F. and R. Ramakrishnan, "An amateur's introduction to recursive
query-processing strategies", ACM SIGMOD Inti. Conf, on Management of Data,
pp. i6-a2, 1986.
3. Chandra, A. K. and D. Harel, ’’Structure and complexity of relational queries",
J. Computer and System Sciences 25:1, pp. 99-128.
4. Codd, E. F., ‘A relational model for large shared data banks". Comm. ACM 13:6,
pp. 377-387, 1970.
5. Codd, E F., Relational completeness of database sublanguages", in Database
Systems (R. Rustin, ed.) Prentice Hall, Engelwood Cliffs, NJ, 1972.
6. Callaire, H. and J. Minker, Logic and Databases, Plenum Press, New York,
1978.
7. Naqvi, S., "Negation as failure for first-order queries", Proc. Fifth ACM Symp.
on Principles of Database Systems, pp. 114-122, 1986.
8. Nicolas, J.-M., "Logic for improving integrity checking in relational databases",
Acta Informatica 18:3, pp. 227-253, 1982.
9 Ullman, J D., Principles af Database and Knowledge-Base Systems, Volume I,
Computer Science Press, New York 1988.
10. Van Gelder, A., Negation as failure using tight derivation for general logic
programs", in Foundations of Deductive Databases and Logic Programming
(J. Minker, ed.) pp 149-176, Morgan-Kaufmann, San Francisco, 1988.
Глава 5
Язык баз данных SQL
Наиболее широко применяемые системы реляционных БД запрашивают и из-
меняют БД с помощью языка SQL (Structured Query Language — структурированный
язык запросов) Основная часть SQL эквивалентна реляционной алгебре, но неко-
торые его важные свойства, например агрегация и изменения БД, выхолят за ее
пределы.
В SQL множество различных диалектов Во-первых, есть два главных стандарта
ANSI (American National Standards Institute) SQL и обновленный стандарт SQL-92,
или SQL2, принятый в 1992 г. Существует также формирующийся стандарт SQL3,
дополняющий SQL2 новыми средствами, такими как рекурсия, триггеры н объекты.
Во-вторых, существуют версии SQL, созданные главными поставщиками систем
управления БД. Все они включают в себя исходный стандарт ANSI н в значитель-
ной степени согласуются с новейшей версией SQL2, но каждый из них отличается
от SQL2 своими вариантами и расширениями включая некоторые средства предла-
гаемого стандарта SQL3.
В этой и в следующих двух главах описывается применение SQL в качестве
языка запросов. В данной главе основное внимание уделено базовому интерфейсу
для SQL, т.е, SQL рассматривается как автономный язык запросов, при помощи
которого с терминала в БД посылаются запросы или требования о внесении изме-
нений Ответь на запросы выводятся на экран терминала. При обсуждении SQL
мы в основном придерживаемся стандарта SQL2. выделяя средства имеющиеся
почти во всех коммерческих системах и в более раннем стандарте ANSI В некото-
рых случаях, когда SQL2 неадекватен рассматриваемому вопросу, мы будем следо-
вать новейшей из доступных версий — стандарту SQL3.
В этих главах поставлена задача познакомить читателя с SQL скорее на дидак-
тическом, чем на рабочем, уровне. Поэтому наше внимание будет сосредоточено
только на его наиболее широко применяемых средствах. В списке литературы
помещенном в когте главы, указаны источники, содержащие более подробную
информацию об этом языке и его диалектах.
5-1 Простые запросы в SQL
Возможно, наиболее простая форма запроса в SQL — это запрос об удовлетво-
ряющих некоторому условию кортежах одного отношения. Такой простой запрос
аналогичен выбору в реляционной алгебре. В нем, как почти во всех запросах SQL,
применяются ключевые слова SELECT, FROM и WHERE, характеризующие язык
SQL.
5.1 Простые запросы в SOL
199
Пример 5.1. В этом и в последующих примерах используется схема БД. введен-
ная в разделе 3 9. Соответствующие схемы отношений воспроизведены на рис. 5.1.
В разделе 5.7 будет показано, как выразить информацию схемы в SQL, а пока
предполагается, что каждое отношение и области упомянутые в разделе 3.9, имеют
соответствие в SQL.
Movie(trtJe, year, length, inColor. studioName, producerC#)
Starsln(movieTitJe movieYear, starName)
MovieStar(name, address, gender, birthdate)
MovieExec(name, address cert#, netWorth)
Studio(name address. presC#)
Рис. 5.1. Пример аемы БД
Сформулируем запрос к отношению
Movieftitla, year, length, inColor studioName producerC#
обо всех фильмах, выпушенных студией Disney Studios в 1990 г В SQL он записы
вается следующим образом:
SELECT *
FROM Movie
WHERE studioName ='Disney' AND year = 1990,
Форма этого запроса "выбрать из .. где...” характерна для большинства запро-
сов SQL.
• Пункт FROM указывает на отношение, к которому принадлежит запрос.
В данном примере запрос касается отношения Movie.
• Пункт WHERE — условие, которое во многом похоже на условие выбора в
реляционной алгебре н которому должны удовлетворять кортежи для соот-
ветствия запросу. Здесь условие заключается в том, чтобы атрибут кортежа
studioName имел значение 'Dsney1, а атрибут кортежа уааг — значение "1990“
Все кортежи, имеющие указанные значения атрибутов, удовлетворяют усло-
вию, остальные — не удовлетворяют.
• Пункт SELECT показывает, какие атрибуты кортежей, удовлетворяющих
условию, становятся частью ответа Знак * в данном примере указывает на
то. что порождается полный кортеж. Результат запроса - это отношение
состоящее из всех кортежей, созданных при построении ответа
Один нз способов интерпретации этого запроса заключается в том, чтобы
рассмотреть каждый кортеж отношения, упомянутого в пункте FROM, и применить
к нему условие, указанное в пункте WHERE. Точнее говоря, любой атрибут, упомя-
нутый в пункте WHERE, заменяется значением компонента кортежа для данного
атрибута Затем оценивается условие, и если оно выполняется, то компоненты, воз-
никающие в пункте SELECT, становятся одним из кортежей ответа Таким образом
результат рассматриваемого запроса это кортежи для фильмов, выпущенных
студией Disney в 1990 г., например для фильма "Pretty Woman".
Когда процессор запросов встречает в отношении Movie кортеж
title year length in Color | studioName | producerC#
Pretty Woman 1990 119 true | Disney • 999
200
Глава 5 Язык баз данных SQL
Здесь 999 — вымышленный номер сертификата продюсера этого фильма В условии
пункта WHERE значение “Disney" подставляется вместо атрибута studioName, а зна-
чение "I9901 — вместо атрибута year, так как в рассматриваемом кортеже они явля-
ются значениями этих атрибутов В результате пункт WHERE приобретает вид:
WHERE 'Disney'='Disney' AND 1990 = 1990
Поскольку оно япно истинно кортеж для "Pretty Woman" выдержал проверку и стал
частью результата запроса. □
5-1.1 Проекция в SQL
Некоторые компоненты выбранных кортежей при желании можно устранить,
т.е. проецировать порожденное запросом SQL отношение на некоторые из его
атрибутов. Вместо * в пункте SELECT разрешается перечислить любые атрибуты
отношения, упомянутого в пункте FROM. Тогда результат проецируется именно на
них.1
Пример 5.2. Допустим, нужно изменить запрос из примера 5.1. чтобы полу-
чить только название фильма и его продолжительность. Тогда следует написать'
SELECT title, length
FROM Move
WHERE studioName = 'Disney' AND year =1990
В результате получилась таблица с двумя столбцами, озаглавленными title и
length. Кортежами этой таблицы являются пары, каждая из которых состоит из на-
звания и длительности фильма, выпушенного студией Disney в 1990 г. Например
title | length
Pretty Woman -119 □
Иногда бывает нужно построить отношение, заголовки столбцов которого от-
личаются от атрибутов отношения, упомянутого в пункте FROM. Тогда за именем
атрибута ставится ключевое слово AS и псевдоним, представляющий имя, которое
появится в результирующем отношении. AS применяется по выбору. В старых
системах SQL оно всегда пропускается, т е. псевдоним может непосредственно, без
запятой, следовать за атрибутом, который он заменяет.
Пример 5.3. Изменив пример 5.2, можно получить отношение с атрибутами
name и duration «место title и length.
SELECT title AS name, length AS duration
FROM Movie
WHERE studioName ='Disney' AND year = 1990;
В результате получается такое же множество кортежей, как и в примере 5.2. но
столбцы в нем озаглавлены атрибутами name п duraton Например
name duration
Pretty Woman ; 119 □
В предложении SELECT вместо атрибутов можно испочьзовать формулу.
1 Таким образом, ключевое слово SELECT языка SQL действительно соответствует
оператору проекции в реляционной алгебре, а ее оператор выбора соответствует пункту
WHERE шпроса SQL
5.1 Простые запросы в SQL
201
Пример 5.4. Допустим, нужно получить такой же вывод, как и в примере 5.3,
но с продолжительностью фильма в часах. Тогда предложение SELEC предыдуще-
го примера заменяется на
SELECT title AS name, length*0 016667 AS lengthlnHours
В результате получаются те же самые пары 'название — продолжительность", но
продолжительность фильма исчисляется уже в часах и второй столбец озаглавлен
атрибутом lengthlnHours. □
Пример 5.5. В качестве элемента предложения SELECT допускается использо-
вать константу. Это может показаться бессмысленным, но по крайней мере одно из
применений константы состоит в том, чтобы вносить полезные слова в вывод SQL,
появляющийся на экране. Запрос
SELECT ttie, length*0.016667 AS length, 'hrs' AS inHours
FROM Movie
WHERE studioName _'Disney' AND year “ 1990;
порождает кортежи типа
title length | tnHours
Pretty Woman 1.96334 [hrs.
Мы сделали так, что третий столбец называется inHours, а это название соответст-
вует заголовку length второго столбца. Теперь каждый кортеж ответа будет иметь в
своем третьем столбце константу hrs., которая оказывается элементом, связанным
со значением во втором столбце. □
Нечувствительность к регистру
SQL нечувствителен к регистру, т.е. буква, набранная в верхнем и в нижнем
регистре, считается одной и той же буквой. Например, мы пишем ключевое
слово типа FROM заглавными буквами, с равным успехом ею можно писать
как From, from и даже как FrOm. Имена атрибутов, отношений, псевдонимов !
и т.д. тоже нечувствительны к регистру. SQL различает регистр только внутри i
кавычек, т.е. 'FROM' отличается от 'from' и, разумеется, от ключевого слова I
FROM.
5.1.2 Выбор в SQL
С помощью пункта WHERE запроса SQL можно выразить оператор выбора
реляционной алгебры, а также многое другое. Выражение, которое следует за
WHERE, содержит условные выражения, похожие на те, что встречаются в извест
ных языках С или Pascal.
Выражения можно строить, сравнивая значения с помощью шести операторов-
= О, <, >, <= и >=. Они совпадают с операторами языка Pascal и имеют очевид-
ный смысл.
Сравниваемые значения могут содержать константы и атрибуты отношения
или отношений, упомянутых после слова FROM. Перед сравнением числовых зн1-
чений к ним можно применять арифметические операции +, “ и т.д. Например,
выражение (jeor— 1930) * (year — 1930) < 100 истинно для годов от 1930 до 1939
К строкам можно также применять оператор конкатенации |; например, 'too' | 'bar'
имеет значение 'foobar'.
202
Глава 5 Язык баз данных SQL
В примере 5.1 используется сравнение
studioName = 'Disney'
Атрибут studioName отношения Movie проверяется па предмет равенства
с константой 'Disney'. Значением этой константы является строка. Строки в SQL
обозначаются заключением их в одинарные кавычки. Допустимы также цифровые
константы, целые и реальные числа, для которых в SQL применяется обычная
форма записи типа -12.34 или 1.23Е45.
Результатом сравнения является булево значение TRUE или FALSE. Эти значе-
ния можно комбинировать с логическими операторами AND, OR и NOT, имеющими
обычные значения, как и языке Pascal. В примере 5.1 было показано, как условия
комбинируются с оператором AND. Пункт WHERE из этого примера является
истинным, если и только если удовлетворяются оба сравнения, т.е. имя студии
'Disney' и год 1990. Приведем другие примеры запросов со сложными пунктами
WHERE.
Пример 5.6. Следующий запрос касается черно-белых фильмов, снятых после
1970 г.
SELECT title
FROM Movie
WHERE year > 1970 AND NOT inColor;
В этом условии два булевых выражения соединены связкой AND Первое из
них — простое сравнение, второе — атрибут inColor с отрицанием Такое применение
атрибута вполне уместно, так как inColor относится к булеву типу.
Теперь рассмозрим запрос
SELECT title
FROM Movie
WHERE (year > 1970 OR length < 90) AND studioName ='MGM‘;
Он касается названий фильмов студии MGM, снятых после 1970 г, или длящихся
менее 90 мин. Заметим, что сравнения можно группировать с помощью скобок,
которые здесь необходимы, поскольку приоритет логических операторов в SQL
определяется так же, как и в большинстве других языков AND сильнее OR, a NOT
сильнее их обоих. □
5-1.3 Сравнение строк
Дне строки равны, если они состоят из одной и той же последовательности
символов. В SQL допустимы различные типы строк, например массивы символов
фиксированной длины и списки символов переменной длины.2 Hanpi мер, строка
типа too может храниться в виде строки фиксированной длины 10 с семью допол-
няющими символами или в виде строки переменной длины. Предполагается что
в обоих случаях ее значения равны друг другу и исходной строке 'too'.
При сравнении строк с помощью одного нз операторов "меньше чем”, напри-
мер < или >=. проверяется, предшествует ли одна из них другой в лексикографиче-
ском (т.е. в словарном или алфавитном) порядке. Если а,. а2. .... а„ и bt, А,.Ь,„ —
две строки, то первая "меньше” второй если at < b, или = Z>, и а2 < или а-, — Ь2
н а~ < Ь3 и т.д. Считается также, что о„ а2. ..., а„ < 6t, f>2, .. , b„„ если п < т
и а,, а2,.... а„ = bf, Ъъ .... Ьт. т.е. если первая строка является префиксом второй
2 В обшем-то принято с 1Ита ъ, что строки хранятся в памяти в виде массивов а списков
символов Как они хранятся на самом деле — вопрос реализации, нс определенный
ни в одном стандарте SQL
5 1 Простые запросы в SQL
203
Например, 'fodder' < Too’, так как первые две буквы этик строк совпадают, а третья
буква строки fodder предшествует третьей букве строки foo. Верно также, что
'bar' < bargain, поскольку первая строка является префиксом второй.
SQL позволяет сравнивать строки на основании их совпадения с простым
образном. Формой сравнения может быть выражение
s LIKE р
где s — строка, ар — образец, т.е. строка, в которой произвольно применяются спе-
циальные символы % и _. Обычные символы в р соответствуют только самим себе
в я, но % в р может соответствовать любой последовательности в з, состоящей из 0
и более символов, а _ в р соответствует любому символу из з. Такое выражение
истинно, если и только если строка з соответствует образцу р. В силу аналогичных
рассуждений выражение з NOT LIKE р истинно, если и только если строка з не со-
ответствует образцу р
Представление булеаков и битовых строк
В SQL булевы значения можно представить битовыми строками особого
вида. Битовая строка в двоичной системе счисления представляется буквой В,
за которой следует ряд нулей и единиц, заключенных в кавычки. Например,
В'011' — строка из трех битов, первый из которых содержит 0, а два других — I.
Для записи битовых строк можно использовать также шестнадцатеричную
систему счисления. В таком случае битовая строка будет представлена как
буква X, за которой следует заключенная в кавычки строка, состоящая из
шестнадцатеричных цифр от 0 до /(где буквы от с до/являются шестнадцате-
ричными цифрами со значением от 10 до 15 соответственно). Например,
учитывая, что каждая шестнадцатеричная цифра занимает четыре бита,
X7ff —это строка из двенадцати битов, первый из которых содержит 0,
а одиннадцать следующих — 1.
Булево значение TRUE можно представить одним битом, т.е. В'Т. Анало-
гичным образом, FALSE можно представить с помощью В‘0'.
Пример 5.7. Допустим, мы помним, что название фильма начинается со слова
"Star’ и второго слова, состоящего из четырех букв. Названия с такими параметрами
можно узнать с помощью запроса
SELECT title
FROM Movie
WHERE title LIKE 'Star____'
Этот запрос выявляет атрибут названия фильма, имеющий значение длиной
в девять символов. Первые пять символов — Star и пробел, а последние четыре
могут быть любыми, так как любая последовательность из четырех символов соот-
ветствует_____Результат запроса — множество полностью совпадающих по числу
символов названий типа Star Wars и Star Trek. □
Пример 5.8. Допустим, нужно найти фильмы, в названиях которых есть апост-
роф. Это можно сделать с помощью запроса
SELECT title
FROM Movie
WHERE title LIKE '%’s%'
204
Глава 5 Язык баз данных SQL
Для понимания такого образца в первую очередь нужно знать, что апостроф,
будучи символом выделяющим строки SQL, не может представлять самого себя.
В SQL действует соглашение, согласно которому два связующих апострофа в строке
представляют единственный апостроф и не завершают эту строку, т.е. "s в образце
соответствует единственному апострофу и s является названием фильма.
Два символа % с обеих сторон 's соответствуют вообще любым строкам.
Поэтому любое название с "s и качестве подстроки соответствует образцу и ответ
на рассматриваемый запрос будет содержать фильмы типа "Logan's Лип" или
"Alice's Restaurant". □
— - г.
Символ выхода в выражениях LIKE
Как быть, если в выражениях LIKE встречается символ % или _? Вместо
| особого символа выхода (например, обратного слеша в большинстве команд
; UNIX) SQL позволяет определить любой символ в качестве символа выхода
| в единственном образце команды. Для этого в конце команды ставится
ключевое слово, ESCAPE и выбранный символ выхода, заключенный в кавычки,
г Символ % или , которому в команде предшествует символ выхода, интерпре-
« тируется буквально, а не как символ, обозначающий последовательность
S других символов или любой другой символ. Например:
| S LIKE х%%х%' ESCAPE V
§ делает х символом выхода в шаблоне х%%х%. Последовательность х% считается
i единственным %. Значит, такой шаблон совпадает с любой строкой, которая
“ начинается и заканчивается символом %.
5-1.4 Сравнение дат и времени
Реализация SQL обычно поддерживает даты и время в виде особых типов
данных. Эти значения представимы в различных форматах, например 5/14/1948 или
14 Мау 1948. Здесь мы описываем только нотацию стандарта SQL2, в котором
к формату предъявляются особые требования
Дата представляется ключевым словом DATE, за которым следует заключенная
в кавычки строка особого вида, например DATE '1948 05-14. Первые четыре симво-
ла — это цифры, представляющие год За ними следуют дефис и две цифры, обо-
значающие месяц. Заметим, что номеру месяца, выраженному одной цифрой,
предшествует 0. Далее следуют еще один дефис н две цифры обозначающие день
месяца. Как и в случае с месяцем перед номером дня, выраженным одной цифрой,
ставится О
Время представляется аналогично — ключевым словом TIME и заключенной
в кавычки строкой, которая начинается двумя цифрами, обозначающими час
(по 24-часовому циферблату): далее следуют двоеточие, две цифры, обозначающие
минуты, и две цифры, обозначающие секунды. Если нужно фиксировать доли
секунды, ставится десятичная точка и за ней произвольное количество цифр.
Например TIME '15:00.02.5'— это время, в которое после закончившейся в 15:00
лекции в аудитории уже нет ни одного студента.
Даты п время можно сравнивать с помощью тех же операторов, которые
применялись к числам пли строкам. Например, < означает, что дата или время,
стоящие слева, были или будут раньше даты или времени, указанных справа
5.1 Простые запросы в SQL
205
5.1.5 Упорядочение вывода
Порождаемые запросом кортежи можно упорядочить на основе значения лю-
бого атрибута Для получения упорядоченного вывода в запрос добавляется пункт
ORDER BY <1 st of attributes»
По умолчанию принимается восходящий порядок, но его можно изменить на
нисходящий с помощью ключевого слова DESC. Восходящий порядок тоже можно
задать ключевым словом ASC, но указывать его нет необходимости.
Пример 5.9. Рассмотрим запрос из примера 5.1, касающийся отношения
Movieftitle, year, length, inColor, studioName, producerC#)
Для получения списка фильмов, в котором они упорядочены по длительности,
начиная с самого короткого, а рапные по длительности фильмы упорядочены по
алфавиту, запрос записывается в следующей форме:
SELECT *
FROM Movie
WHERE studioName = Disney AND year =1990
ORDER BY length, title;
Если порядок атрибутов известен (а так и должно быть, поскольку отношения SQL
выражаются списками атрибутов, что будет показано в разделе 5.7.2), то при желании
вместо имен атрибутов можно использовать их номера. Поэтому пункт ORDER BY
рассматриваемого запроса можно записать как
ORDER BY 3. 1;
в соответствии со стандартным порядком, в котором перечислены атрибуты отно
шения Movie. □
5.1.6 Упражнения к разделу 5.1
Упражнение 5.1.1. Если пункт запроса SELECT записан в виде
SELECT А В
как узнать, являются ли А и В различными атрибутами или В — это псевдоним
Упражнение 5.1.2. Запишите на SQL перечисленные ниже запросы, основы-
ваясь на примере БД о фильмах:
Movie(title, year, length, inColor, studioName, producerC#)
Sta sln(movieTitle, moveYear, starName)
MovieStar(name, address, gender, birthdate)
MovieExec(name, address, cert# netWorth)
Studio(name, address. presC#)
*a) Найдите адреса студий MGM.
b] Найдите дату рождения Sandra Bullock.
*c) Найдите всех кинозвезд, игравших в фильмах, снятых до 1980 г.,
или в фильмах, в названиях которых есть слово "любовь". _____________
206
Глава 5 Язык баз данных SQL
d) Найдите администраторов с чистым доходом не менее 10 млн. дол.
е) Найдите все.х кинозвезд-мужчин и и тех, которые живут в Malibu
(Malibu часть адреса)
Упражнение 5.1.3, Запнш ггс перечисленные ниже запросы на SQL, относя-
щиеся к схеме БД из упражнения 4.1.1:
Product(maker, model, type)
PC(model, speed ram, hd, cd, price)
Laptop(model, speed, ram, hd, screen, price)
Printer(mode , color, type, price)
Покажите результаты этих запросов, используя данные из упражнения 4.1.1.
*а) Найдите номер модели, скорость и размер жесткого диска для всех ПК
стоимостью менее 1600 дол.
*Ь) Выполните запрос (а), но при этом переименуйте столбец speed
в megahertz, а столбец hd в gigabytes.
с) Найдите производителей принтеров.
d) Найдите помер модели, объем памяти и размеры экранов ПК блокнотов,
иена которых превышает 2000 дол.
*е) Найдите все кортежи отношения Printer для цветных принтеров.
Не забывайте, что color —булевозначный атрибут.
Г) Найдите номер модели, скорость и размер жесткого диска ПК,
имеющих 6х или 8х CD и цену менее 2000 дол. При этом можно считать,
что атрибут cd относится к типу строки.
Упражнение 5.1.4. Запишите перечисленные ниже запросы, основанные на
схеме БД упражнении 4.1.3
Classes(class type, country, numGuns, bore displacement)
Ships(name, class, launched)
Battles(name, date)
Outcomes(ship, battle, result)
и покажите результаты этик запросов, используя данные из упражнения 4.1.3.
а) Найдите класс, имя и страну для всех классов кораблей, имеющих
не менее 10 орудий
Ь) Найдите названия всех кораблей, спущенных на воду до 1918 г.;
при этом результирующий столбец должен быть озаглавлен shipName
с) Найдите названия кораблей, потопленных в сражениях,
и название сражения, в котором они были потоплены.
d) Найдите все корабли, названия которых совпадают с именем их класса.
е) Найдите все названия кораблей, начинающиеся с буквы R
I f) Найдите все i азван гя кораблей, состоящие из трех и более слов
(например. King George V).
5.2 Запросы, содержащие более одного отношения
207
5.2 Запросы, содержащие
более одного отношения
Эффективность реляционной алгебры во многом определяется возможностью
комбинирования отношений с помощью объединений, произведений, пересечений
и разностей. В SQL применяется любая из этих операций. Как будет показано
в разделе 5.2.5. теоретико-множественные операции объединения, пересечения и
разности непосредственно включены в SQL, а сейчас мы рассмотрим, как приме-
няются в запросах SQL произведения и объединения
5.2.1 Произведения и объединения в SQL
В SQL есть простой способ соединения отношений в одном запросе — их нужно
перечислить в пункте FROM. Тогда пункты SELECT и WHERE смогут ссылаться на
любой атрибут этих отношений.
Пример 5.10. Допустим, нужно узнать имя продюсера фильма "Star Wars" Для
этого нужны два отношения:
Movie(title, year, length, inColor, studioName, producerC#)
MovieExec(name, address, cert#, netWorth)
Номер сертификата продюсера содержится в отношении Movie, значит, его
можно узнать с помощью простого запроса на этом отношении. Затем можно
выполнить запрос на отношении MovieExec и получить имя человека, имеющего
данный номер сертификата.
Однако оба этих шага можно объединить в одном запросе на отношениях
Movie и MovieExec:
SELECT name
FROM Movie, MovieExec
WHERE title = Star Wars AND producerC# = cert#
Этот запрос требует рассмотреть все пары кортежей, один из которых принад-
лежит Movie, а другой — MovieExec. Условие, которому они должны удовлетворять
формулируется в пункте WHERE:
1. Атрибут title кортежа из Movie должен иметь значение 'Star Wars'.
2. Атрибут producerC# кортежа из Movie должен быть тем же номером
сертификата, что и атрибут cert# кортежа из MovieExec т е два кортежа
должны ссылаться на одного и того же продюсера.
Когда найдена пара кортежей, удовлетворяющих обоим условиям, в качестве
части ответа создается атрибут name кортежа из MovieExec. При подходящих
данных оба условия выполняются только однажды — для кортежа "Star Wars" из
Movie и кортежа George Lucas нз MovieExec Только в этом случае название фильма
будет правильным и номера сертификатов совпадут В результате получается един-
ственное значение — George Lucas. □
5.5.2 Уточнение атрибутов
Иногда в запрос включается несколько отношений, и некоторые нз них имеют
атрибуты с одинаковыми именами В этом случае приходится уточнять, какой
именно атрибут используется. В SQL эта проблема решается указанием перед атри-
бутом имени отношения, за которым следует точка. Таким образом, Л.Л обозначает
атрибут Л отношения R
208
Глава 5 Язык баз данных SQL
Пример 5.11. Два отношения
MovieStar(name, address, gender, birthdate)
MovieExecfname. address, cert#, netWorth)
имеют атрибуты nama и address. Предположим, нужно найти пары, состоящие ИЗ
кинозвезды и продюсера, имеющих один и тот же адрес. Это можно сделать
с помощью следующего запроса:
SELECT MovieStar.name, MovieExec.name
FROM Movie.Star, MovieExec
WHERE Movie Star, address = MovieExec.address
В этом запросе мы ищем пары кортежей, один из которых находится в MoveStar,
а другой в MovieExec и при этом их компоненты, содержащие адреса, совпадают.
По условию пункта WHERE атрибуты address каждой пары кортежей должны сов-
падать. Затем нз каждой пары кортежей выбирается два атрибута лете — сначала
из кортежа, принадлежащего отношению Moviestar, а потом из другого кортежа.
В результате получается множество пар типа
MovieStar.name i MovieExec пате
Jane Fonda I Ted Turner □
Отношение co следующей за ним точкой допустимо даже тогда, когда нет
никакой двусмысленности. Так, запрос из примера 5.10 можно записать в следую-
щем виде:
SELECT MovieExec.name
FROM Movie, MovieExec
WHERE Movie.titie = 'Star Wars"
AMD Movle.producerC# = MovieExec.cert#
В этом запросе имена отношений с точками можно указывать перед каждым
подмножеством атрибутов.
Переменные кортежей и имена отношений
Технически ссылки на атрибуты в предложениях SELECT и WHERE всегда
являются ссылками на переменную кортежа. Однако, если отношение входит
J в предложение FROM всего один раз, его имя можно использовать в качестве
переменной его собственного кортежа Поэтому имя отношения Л в пункте
j FROM может быть сокращением записи Л AS Я.
г
5-2.3 Переменные кортежей
Уточнение атрибутов путем префикспрования отношения эффективно, когда
запрос содержит комбинацию различных отношений. Однако иногда требуется
запрос, содержащий несколько кортежей из одного и того же отношения. Можно
повторить отношение Л необходимое число раз в пункте FROM, но при этом нужно
обеспечить ссылки на каждое его вхождение. В SQL дня каждого вхождения Я
в пункт запроса FROM можно определить “псевдоним”, который мы будем называть
переиеинач кчрте.чса. За каждым применением Л в пуикге FROM следует (по выбору)
ключевое слово AS и пмч или переменная кортежа.
5.2 Запросы, содержащие более одного отношения
209
Атрибуты R в пунктах SELECT и WHERE можно уточнить, указывая передними
подходящую переменную кортежа и точку. Таким образом, переменная кортежа
выполняет функцию другого имени отношения Л и при желании может быть исполь-
зована вместо него
Пример 5.12. Запрос из примера 5.11 касается кинозвезды и администратора,
имеющих один и тот же адрес. Аналогично можно искать двух кинозвезд с одним и
тем же адресом. Запрос, по существу, остается прежним, но теперь нужно выбирать
кортежи только из отношения MovieStar Используя переменные кортежей и псев-
донимы для двух применений отношения MovieStar, можно сформулировать следу-
ющий запрос
SELECT Starl name, Star2.name
FROM MovieStar AS Start, MovieStar AS Star2
WHERE Start.address = Star2.address AND Start .name < Star2.name
В предложении FROM переменные кортежей Start и Star2 являются псевдонимами
отношения MovieStar В предложении SELECT они применяются для ссылки на
компоненты пате двух кортежей, а в предложении WHERE означают, что представ-
ленные ими кортежи из MovieStar имеют одно и то же значение в своих компонен
тах address.
Согласно второму условию предложения WHERE, т.е. Start.name<Star2.name,
имя первой кинозвезды предшествует имени второй по алфавиту. В отсутствие
этого условия переменные Start и Star2 относились бы к одному и тому же кортежу.
Адреса при этом тоже совпали бы, и в результате получились бы пары идентичных
имен кинозвезд 3 Второе условие требует также формировать каждую пару кино-
звезд только один раз в алфавитном порядке. При использовании оператора <> (не
равно) можно получить пары кинозвезд состоящих в браке, например:
Staff.пате Star2.name
Alec Baldwin Kim Basinger
Kim Basinger Alec Badwm □
5.2.4 Интерпретация запросов
с несколькими отношениями
Существует множество способов интерпретации запросов типа select-from-where.
Все они эквивалентны в том смысле, что при любой интерпретации запрос к одному
и тому же экземпляру отношения дает один и тот же ответ.
Вложенные циклы
В предыдущих примерах неявно использовалась семантика переменных корте
жен Напомним, что псевдоним имени отношения — это переменная кортежа, про-
бегающая по всем кортежам определенного отношения. Имя отношения без
псевдонима — это тоже переменная кортежа, пробегающая по самому этому отно
шению. При наличии нескольких переменных кортежей для каждой из них можно
представить вложенный цикл, в котором каждая переменная пробегает по кортежам
соответствующего ей отношения Для каждого приписывания кортежей перемен-
ным кортежей определяется, истинен ли пункт WHERE. Если истинен, порождается
з Такая же проблема возникает в примере 5.П, когда один и тот же человек является
и кинозвездой, и администратором. Она решается с помошью требования, согласно
которому два имени не должны совпадать.
гю
Глава 5 Язык баз данных SOL
кортеж, состояшпг из значений термон, которые следуют за словом SELECT. Заме-
тим. что значение каждого терма определяется текущим приписыванием кортежей
переменным кортежей Алгоритм ответов на запросы представлен на рис. 5.2.
LET переменные кор ежей в пункте from пробегают по
отношениям R1, R2, .., Rn;
FOR каждого кортежа t в отношении R1 DO
FOR каждого кортежа t2 в отношении R2 DO
FOR каждого кортежа tn в отношении Rn DO
IF пункт where выполняется при подстановке
переменных из tl, t2.tn вместо всех
ссылок на атрибуты THEN
оценить атрибуты пункта select согласно
t1r t2,.... tn и построить кортеж
из результатов этой оценки.
Рис. 5.2 Алгоритм ответа на простой запрос SQI
Параллельное приписывание
Существует эквивалентное определение семантики запроса, при котором
вложенные циклы, пробегающие по переменным кортежей, не строятся явным
образом. Вместо этого применяются произвольные или параллельные возможные
приписывания кортежей из отношений переменным кортежей. Для каждого припи-
сывания определяется истинность пункта WHERE. Каждое приписывание, при
котором этот пункт истинен, составляет кортеж ответа, который строится из атри-
бутов пункта SELECT, вычисляемых согласно данному приписыванию.
Интерпретации Datalog и SQL
Между вторым способом интерпретации правил Datalog, описанным в
разделе 4.2.4, и только что рассмотренной интерпретацией простых запросов
SQL есть определенное сходство. В Datalog рассматриваются все возможные
приписывания кортежей из подходящего отношения подцелям в теле правила.
I В SQL тоже рассматриваются все возможные приписывания кортежей пере-
I менным кортежей. В обоих случаях эти приписывания кортежей ограничива-
ются арифметическими подцелями (частями предложений WHERE в SQL) и
кортежи результата получаются путем вычисления головного элемента правила
(пункта SELECT в SQL).
Преобразование в реляционную алгебру
Третий способ интерпретации — это преобразование запроса SQL в выражение
реляционной алгебры Сначала берется декартово произведение переменных корте-
жей из пункта FROM. Если две переменные кортежей ссылаются на одно и то же
отношение, оно появляется в произведении дважды и его атрибуты переименовы-
на отся так, чтобы псе их имена были уникальны. Во избежание двусмысленностей
жалогичным образом переименовываются атрибуты из разных отношений, имею
шие одно и то же имя.
5.2 Запросы, содержащие более одного отношения
211
К полученному произведению применяется оператор выбора путем простого
преобразования предложения WHERE в условия выбора. При этом каждая ссылка
на атрибут в предложении WHERE заменяется соответствующим ей атрибутом из
произведения. И наконец, из предложения SELECT строится список атрибутов для
финальной операции проекции. Атрибуты для этой операции определяются так же
как и дм операции выбора: каждая ссылка на атрибут предложения SELECT заме-
няется соответствующим ей атрибутом из произведения 4
Интуитивно неочевидные следствия
из семантики SQL
Пусть Я, 5 и Т— унарные (однокомпонеитные) отношения, в каждое из
которых входит единственный атрибут /1, и нужно найти такие элементы Л
которые входят также в S или Т, т.е. вычислить Лгт(5и 7). Предположим,
что для этого нужен запрос:
SELECT R.A
FROM R, S.T
WHERE RA = S.A OR RA-T.A
Рассмотрим случай, когда T пусто. Тогда условие R.A = Т.А никогда не
выполняется, и на основе интуитивного понимания связки OR мы считаем,
что запрос даст результат Яг>5. И все же, применяя любое из приведенных
выше эквивалентных определений запроса, мы обнаруживаем, что результат
пуст независимо от того, сколько общих элементов имеют R и 5" Применение
семантики вложенных циклов (рис. 5.2) показывает, что цикл для переменной
кортежа Т повторяется 0 раз, так как в этом отношении нет кортежей, по
которым данная переменная могла бы пробегать Поэтому IF-предложение
никогда не выполняется и ничего нового не возникает. Если же рассматривать
приписывания кортежей переменным, тоже оказывается, что невозможно
приписать кортеж отношению Т, поэтому никаких приписываний не сущест-
вует. И наконец, применяя декартово произведение, мы начинаем с выраже-
ния R х S х Т, которое является пустым, поскольку Т пусто.
Пример 5.13. Преобразуем в выражение реляционной алгебры запрос из при-
мера 5.12 В предложении FROM две переменные кортежей ссылаются на отноше-
ние Moviestar, поэтому начнем с выражения
Moviestar х MovieStar
В результирующем отношении восемь атрибутов. Первые четыре — name, address,
gender и birthdate - берутся из первой копии отношения MovieStar, а последние
соответствуют тем же атрибутам из второй копии MovieStar Можно было бы со-
здать имена этих атрибутов с помощью точки и псевдонима переменной кортежа,
например Starl .gender, но для краткости введем новые символы и назовем атрибуты
Ль Л,...At Итак, Л, соответствует Starl name, А? соответствует Star2 name и т.д.
4 Технически реляционная алгебра не допускает арифметических вычислений
в предложении SELECT, а в SQL они допустимы (см. пример 5.4). Однако можно
применить очевидное расширение оператора проекции реляционной алгебры, и более
ограниченное определение проекции — просто дань традиции
212
Глава 5 Язык баз данных SQL
При таком методе фисвосния имен атрибутам из пункта WHERE получается
условие отбора .-L =Л6 и Л| < Я5. Список проекции — И|. Л5. Таким образом выра-
жение
П.>,. I, (° I. Н. AND 4, «Л. (р„(I,. з„ ^<WovieS,ar) * РЛ(.4, л,. „^MovieStar»)
представляет весь запрос в реляционной алгебре □
5.2.5 Объединение, пересечение и разность
запросов
Иногда отношения комбинируются с помощью теоретико-множественных
операций объединения, пересечения и разности. В SQL соответствующие операто-
ры применяются к результатам запросов при условии, что запросы порождают
отношения с одним и тем же множеством атрибутов. Ключевые слова UN ON,
INTERSECT и EXCEPT обозначают соответственно ш, г> и Слова типа UNION
ставятся между двумя запросами, заключенными в скобки.
Пример 5.14. Допустим, нужно найти имена и адреса всех женщин-кинозвезд,
которые являются администраторами и имеют чистый доход не менее 10 млн. дол
Используя отношения
MovieStar(name, address, gender, birthdate)
MovieExec(name, address, cert# networth)
можно сформулировать запрос, показанный на рис. 5.3.
1) (SELECT name, address
2) FROM MovieStar
3) WHERE gender = F)
4) INTERSECT
5) (SELECT name, address
6) FROM MovieExec
7) WHERE netWorth > 10000000)
Рис. 5.3 Пересечение женщин-кинозвезд с богатыми администраторами
Строки (1) •— (3) порождают множество женщип-кинозвезд в отношении, схема
которого содержит атрибуты name и address.
Строки (5) — (71 порождают множество администраторов с чистым доходом не
менее 10 млн. дол Этот запрос тоже дает отношение, схема которою содержит
только атрибуты пате и address. Поскольку обе полученные схемы совпадают,
пересечения можно вычислить с помощью оператора, указанного в строке (4) □
Стили записи запросов SQL
; В общем l'i\ tae запросы SQL записываются так, что каждое важное клю-
чевое слово начинает новую строку. Такой стиль записи дает читающему
визхдльное представление о структуре запроса. Однако, когда запрос или г од-
запрос короток, он записывается в одной строке (.как в примере 5.15). Такой
сгпль 3I HICJI делает запрос компактным и удобным для чтения
5.2 Запросы, содержащие более одного отношения 213
Пример 5.15. Можно найти также разность между множествами людей, вы-
бранными из двух отношений. Запрос
SELECT name, address FROM Moviestar)
EXCEPT
(SELECT name, address, FROM MovieExec)
дает имена и адреса кинозвезд, не являющихся администраторами, независимо от
их дохода. □
В двух предыдущих примерах отношения, на которых выполняются операции
пересечения и разности, по соглашению имеют одни и те же атрибуты. Но при
необходимости создания общего множества атрибутов можно применить и пере-
именовать атрибуты, как было показано в примере 5.3.
Пример 5.16. Предположим, нужно найти все названия и годы выпуска филь-
мов, входящих в отношение Movie или Starsln:
Movie(title, year, length, inColor, studioName, producerC#)
Starsln(movieTitle, movieYear, starName)
В идеальном случае эти множества фильмов совпадают, но на практике они
обычно различаются. Например, могут быть фильмы без кинозвезд или кортеж
Starsln, в котором упоминается фильм, отсутствующий в отношении Movie 5
Итак, можно сформулировать следующий запрос:
(SELECT title, year FROM Movie)
UNION
(SELECT movieTitle AS title movieYear AS year FROM Starsln);
Результатом будут все фильмы, упомянутые в любом из этих отношений
с атрибутами результирующего отношения title и year. □
5.2.6 Упражнения к разделу 5-2
Упражнение 5.2.1. Используя схему БД фильмов
Movie(title, year length nColor, studioName, producerC#)
Starsln(movleTltle, movieYear, starName)
MovieStar(name, address, gender, birthdate)
MovieExec(name, address, cert#, netWorth)
Studlo(name, address, presC#)
запишите следующие запросы:
*a) Какие женщины-кинозвезды играют в фильме "Terms of Endearment'?
b) Какие кинозвезды играют в фильмах, снятых на студии MGM в 1995 г.?
с) Кто является президентом студии MGM?
*! d) Какие фильмы длиннее фильма "Gone With the Wind"1
! e> Какие администраторы богаче, чем Merv Griffin1’
s Такое различие можно предотвратить двумя способами рассмотренными в папе 6
214 Глава 5 Язык баз данных SQL
Упражнение 5.2.2. Запишите перечисленные ниже запросы, основанные на
схеме БД
Product(maker, model, type)
PC(model, speed, ram, hd cd, price)
Laptop(model speed, ram, hd. screen, price)
Printer(model. color, type, price)
из примера 4.1.1 и оцените их с помощью данных этого упражнения.
*а) Укажите производителя и скорость ПК-блокнотов с жестким диском
объемом не менее I Гбайт.
®Ь) Найдите номера моделей и цены всех продуктов (любого типа),
выпушенных производителем В.
с) Найдите производителя, продающего ПК-блокноты, но не ПК.
id) Найдите размеры жестких дисков, совпадающие у двух или более ПК.
!е) Найдите пары моделей ПК, имеющих одинаковые скорость и RAM.
В результате каждая пара указывается только один раз,
т.е. указывается (/.У), но не (/, Г)
!! f) Найдите производителей по меньшей мере двух различных компьютеров
(ПК или ПК-блокнотов), имеющих скорость не менее 133 МГц.
Упражнение 5.2.3. Запишите перечисленные ниже запросы, основанные на
схеме БД:
Classes(class, type, country, numGuns. bore, displacement)
Ships(name, class, launched)
Batt)es(name, date)
Outcomes(shlp, battle result)
из примера 4.1.3 и оцените их с помощью данных этого упражнения.
а) Найдите корабли водоизмещением более 35 тыс. тонн.
Ь) Перечислите названия, водоизмещение и число орудий кораблей,
участвовавших в сражении при Гвадаканале (Guadacanal).
с) Перечислите все корабли, упомянутые в этой БД. (Помните, что некото-
рые корабли могут не входить в отношение Ships.)
id) Укажите страны, имеющие линкоры и крейсеры.
!е) Укажите корабли, которые были повреждены в одном сражении,
но позднее участвовали в другом.
10 Укажите сражения, в которых участвовало по меньшей мере три корабля
одной и той же страны.
! Упражнение 5.2.4. Общая форма запроса в нотации реляционной алгебры-
Лг(ас(Л| х Л2х... х А„))
Здесь А — произвольный список атрибутов, а С — произвольное отношение. Список
/?|. А:. .., В„ может содержать одно и то же многократно повторяющееся отноше
нне. При этом предполагается, что этот список можно переименовать подходящим
образом Покажите, как выразить в SQL любой запрос такой формы.
! Упражнение 5.2.5. Другой формой запроса в нотации реляционной алгебры
является выражение
л/ (<тс (A, tx Ajtxi ... ixi А,,))
5.3 Подзапросы
215
При этом принимаются такие же допущения, как и в упражнении 5.2.4. Единст-
венное отличие состоит в том, что здесь вместо произведения применяется натураль-
ное объединение Покажите, как выразить в SQL любой запрос такой формы
5-3 Подзапросы
В этом разделе рассматривается более широкая область выражений, соторые
могут появляться в предложениях WHERE. Раисе в условии сравнивались скалярные
значения (простые значения типа целых или реальных чисел, строк и дат или же
выражения, представляющие значения). Теперь мы будем сравнивать целые кортежи
и даже отношения Сначала рассмотрим, как в условиях применяются подзапросы.
Подзапрос — это выражение приписывающее значение отношению. Например,
подзапросом может быть вь ражение типа select-from-wliere. Рассмотрев, как созда-
ются значения, являющиеся отношениями, мы опишем операторы SQL, позволяю-
щие сравнивать кортежи и отношения в предложении WHERE.
5-3-1 Подзапросы, порождающие
скалярные значения
Выражения типа select-from-where могут порождать отношения с любым чис-
лом атрибутов в схеме, и в этих отношениях может быть любое число кортежей.
Однако часто нужно знать значения единственного атрибута Более того, иногда из
информации о ключах можно сделать вывод, что для данного атрибута порождается
единственное значение.
В таком случае допускается использовать заключенный в скобки простой
запрос как константу В частности, он может стоять в пункте WHERE на любом
месте, на котором предполагается вхождение константы или атрибута, представля-
ющего компонент кортежа. Например, результат такого подзапроса можно срав-
нить с константой или атрибутом.
Пример 5.17. Рассмотрим пример 5.10, в котором запрос относился к продюсеру
фильма "Star Wars”. Для него нужны были два отношения:
Move(title, year, length, inColor, stud oName, producerC#}
MovieExec(name, address, cert#, netWorth)
поскольку только в первом из них есть информация о названии фильма, а имена
продюсеров только во втором Эта информация связана "номерами сертификатов ',
которые уникальным образом идентифицируют продюсеров. В результате был по-
строен запрос:
SELECT name
FROM Movie MovieExec
WHERE title 'Star Wars' AND producerC# = cert#
На этот запрос можно посмотреть иначе. Для получения номера сертификата
продюсера фильма "Star Wars" необходимо только отношение Movie. Зная этот
номер можно адресовать отношению MovieExec запрос о человеке с этим сертифи-
катом Первую проблему можно решить с помощью подзапроса, а его результат,
являющийся, по нашему предположению, единственным значением, использовать
в “главном" запросе для получения того-же эффекта, что и в случае с предыдущим
запросом Такая форма запроса показана на рис. 5.4.
216
Глава 5 Язык баз данных SQL
1
2)
3)
4)
5)
6)
7)
SELECT name
FROM MovieExec
WHERE certC# ~
(SELECT producerC#
FROM Movie
WHERE t tie = 'Star Wars
);
Рис. 5.4. Пойен продюсере фильме "Star Wars" с помощью вложенного подзапросе
Подзапрос выражен строками (4) — (6) Уже один он показь вает, что результа-
том будет унарное отношение с атрибутом producers# и единственным кортежем.
Кортеж будет выглядеть примерно как (12345), т.е. как единственный компонент
с целым числом, совпадающим с номером сертификата продюсера George Lucas.
Если этот подзапрос не порождает ни одного кортежа или порождает более одного
кортежа, это ошибка этапа выполнения запроса.
Выпол, ив подзапрос, можно выполнять строки (I) —(3) так, словно I2345
заменяет целый подзапрос, т.е. “главный" запрос выполняется так как запрос вида
1) SELECT name
2) FROM MovieExec
3) WHERE certC# = 12345
Его результат — George Lucas. □
5.3.2 Условия, содержащие отношения
Есть ряд операторов SQL, которые можно применять к отношению Л и полу-
чать булевы значения. Обычно R — результат запроса select from where Некоторые
из этих операторов, например IN, ALL и ANY, содержат скалярное значение s,
и в этом случае R должно быть отноше гнем с одним столбцом.
1 EX STS R — это условие, которое истинно, если и только если R не пусто.
2. Условие з IN R истинно если и только если г эквивалентно одному из
значений R Выражение s NOT IN R истинно, если и только если s не
эквивалентно ни одному из значений R. При этом предполагается, что
R—унарное отношение. Расширение операторов IN и NOT IN, при кото-
ром схема Л имеет более одного атрибута, as — кортеж будет рассмотрено
в разделе 5 3.3
3. Условие s > ALL R истинно, если и только если s больше любого значе-
ния унарного отношения Л. Здесь оператор > можно заменить любым
оператором сравнения с аналогичным значением. Например, выражение
г <> ALL Л эквивалентно выражению г NOT IN R.
4. Условие s > ANY R истинно, если и только если s больше по крайней
мере одного из значений унарного отношения R Здесь оператор > можно
заменить любым из пяти других опера оров сравнения. Например,
s = ANY R эквивалентно s IN R.
Можно строить отрицания операторов EXIST, ALL и ANY точно так же. как
. юбых булевозначных выражений — ставить перед всем выражением слово NOT.
Значит. NOT EXIST R истинно, если н только если R пусто. NOT s > ALL Л истинно,
если и только если s не является максимальным значением Я. a NOT s > ANY R
hctui но если и только если s—минимальное значение R.
5 3 Подзапросы 217
5-3.3 Условия, содержащие кортежи
В SQL кортеж представляется заключенным в скобки списком скалярных зна-
чений, например (123. Too') и (name, address, networth). Первый из них в качестве
своих компонентов содержит константы, а второй — атрибуты Допустимо также
смешение констант и атрибутов в одном кортеже.
Если в кортеже г столько же компонентов, как и в отношении R, имеет смысл
сравнивать z и Л в выражениях типа / IN Л или / <> ANY Л. Последнее означает, что
в R есть кортеж, отличающийся от /. При сравнении кортежа с членами отношения R
необходимо использовать установленный стандартный порядок атрибутов Л.
Пример 5.18. На рис. 5.5 сформулирован запрос SQL на трех отношениях:
Movie(title, yeer length, inColor, studioName. producerC#)
Starsln(movieTitle, movieYear starNeme)
MovieExecfname, address, cert#, netWprth)
касающийся продюсеров фильмов, в которых играет Harrison Ford. Он состоит из
"главного" запроса, вложенного в него запроса и третьего запроса, вложенного во
второй.
1) SELECT name
2) FROM MovieExec
3) WHERE cert# IN
4) (SELECT producerC#
5) FROM Movie
6) WHERE (title, year) IN
7) (SELECT movieTitle movieYear
8) FROM Stars n
9) WHERE starName = 'HarrisonFord'
Ю) )
11) ):
Рис. 5.5. Поиск продюсеров фильмов с Харрисоном Фордом (Harrison Ford)
Нужно проанализировать каждый вложенный подзапрос, начиная изнутри.
Поэтому мы начнем со строк (7) — (9). Этот подзапрос проверяет кортежи от-
ношения Starsln, находит в них кортежи, компонентом starName которых явля-
ется ’Herrison Ford', и возвращает названия и годы выпуска фильмов. Напоминаем,
что ключом фильмов является не один атрибут year, а оба атрибута title и year,
поэтому для идентификации фильма нужно строить кортежи, содержащие оба эти
атрибута. Значит можно ожидать, что строки (7) — (9) порождают значение, похо-
жее на то которое изображено на рис. 5.6.
title ; year
Star Wars i 1977
Raiders of the Lost Ark j 1981
The Fugitive 1993
Рис 5.6 Поры "название — год", возвращаемые внутренним запросом
218
Глава 5 Язык баз данньх SOL
Теперь рассмотрим средний подзапрос, т.е. строки (4) - (6). Здесь ведется поиск
кортежей отношения Movie, в которых есть годы и названия фильмов, указанные
в отношении на рис. 5.6 Для каждого такого кортежа возвращается номер серти-
фиката продюсера, поэтому результат данного подзапроса — множество номеров
сертификатов продюсеров фильмов, в которых играет Харрисон Форд.
И наконец рассмотрим "главный” запрос на строках (I) — (3). Здесь проверя-
ется отношение MovieExec и ведется поиск кортежей, компонент cert# которых
является одним из сертификатов множества, возвращенного средним подзапросом.
Для каждого такого кортежа возвращается имя продюсера н порождается требуемое
множество продюсеров фильмов, в которых играл Харрисон Форд. □
Вложенный запрос, сформулированный на рис. 5.5, как и множество других
вложенных запросов, можно записать в виде выражения типа se ect-from-wliere
с указанием в пункте FROM всех отношений, упомянутых в главном запросе или
в подзапросе Связки IN заменяются равенствами в пункте WHERE. Например на
рис. 5.7 выражен, в сущности, тот же запрос, что и на рис. 5.5
SELECT name
FROM MovieExec, Movie, Starsln
WHERE cert# = producerC# AND
title = movieTitle AND
year = movieYear AND
starName = 'Harrison Ford’;
Рис. 5.7. Поиск продю еров фильмов без помощи вложенных подвопросов
Разница между ними связана со способом дублирования имен продюсеров и будет
рассмотрена в разделе 5.4.
5.3-4 Коррелирующие подзапросы
Простейшие подзапросы можно оценить раз и навсегда, а затем использовать
результаты в запросе более высокого уровня. При более сложном применении под-
запросов проводится многократное вычисление подзапроса, по одному разу для
каждого приписывания значения терму этого подзапроса, происходящему от пере-
менной. находящейся вне его. Подзапрос такого типа называется коррелирующим.
Рассмотрим пример.
Пример 5.19. Найдем названия, использованные для двух или более фильмов.
Внешний запрос касается поиска кортежей в отношении
Mov e(t tie, year, length, inColor, studioName, producerC#)
В подзапросе спрашивается, есть ли в каждом кортеже фильм с тем же названием
и более позднего года выпуска. Весь запрос показан на рис. 5.8
1) SELECT ttle
2) FROM Movie AS Old
3) WHERE year < ANY
4) (SELECT year
5) FROM Movie
6) WHERE title = Old.title
7) )
Рис. 5.8. Поиск названий фильмов встречающихся более одного раза
5.3 Подзапросы
219
Как и и случаях с другими вложенными запросами, мы начинаем с обработки
внутреннего подзапроса, т.е. со строк (4) — (6). Если Old.title на строке (6) заменен
постоянной строкой типа 'King Kong', легко понять, что запрос касается года или
годов, когда был снят фильм с названием "King Kong". Данный подзапрос определяет
название. Единственная проблема состоит в том, что значение Old.title неизвестно.
Однако внешний запрос, находящийся на строках (1) —(3), обеспечивает такое
значение, что позволяет выполнить внутренний подзапрос на строках (4) — (6) и
определить истинность пункта WHERE, расположенного на строках (3) — (6)
Условие в строке (3) выполняется, если любой фильм с тем же названием, что
и Old.title. снят позже, чем фильм кортежа, являющегося значением переменной
кортежа Old. Условие истинно, если год в кортеже Old не является последним го-
дом, когда был снят фильм с тем же названием. Значит, запрос на строках (I) — (3)
порождает на один фильм меньше, чем все множество фильмов с одинаковым
названием: фильм снятый дважды, указывается один раз, фильм, снятый трижды,
указывается дважды и т.д.4 □
При записи коррелирующего запроса важно знать правила определения области
действия имен В общем случае атрибут подзапроса принадлежит одной из перемен-
ных кортежа в пункте FROM, если этот атрибут входит в схему отношения для
данной переменной. В противном случае рассматривается запрос, в который непо-
средственно входит данный подзапрос, затем следующий, "окружающий', запрос
и т.д. Например, year на строке (4) и title на строке (6) рис 5.8 указывают на атри
буты переменной кортежа, пробегающей по всем атрибутам экземпляра отношения
Movie, введенного на строке (5), к которому адресован подзапрос, расположенный
на строках (4) — (6).
Однако, ставя перед атрибутом переменную кортежа и точку, можно указать,
что атрибут принадлежит именно этой переменной. Именно поэтому вводится
псевдоним Old для отношения Movie внешнего запроса и в строке (6) делается
ссылка на Old title. Если бы два отношения из пунктов FROM в строках (2) и (5)
различались, псевдоним не был бы нужен и запрос относился бы непосредственно
к атрибутам отношения, указанного в строке (2).
5-3-5 Упражнения к разделу 5.3
Упражнение 5.3.1. Запишите перечисленные ниже запросы, основанные на
схеме БД упражнения 4 1.1:
Product(maker, model, type)
PC(model speed ram hd, cd, price)
Laptopfmodel, spaed, ram, hd, screen price)
Printer(model, color, type, price)
В каждом ответе нужно использовать по крайней мере один подзапрос и записать
каждый запрос в различных формах (т.е. с помощью различных множеств операто-
ров EXISTS, IN, ALL и ANY)
*а) Найдите производителей ПК со скоростью не менее 160.
Ь) Найдите принтеры, имеющие самую высокую цену.
’с) Найдите ПК-блокноты, скорость которых меньше скорости любого ПК.
6 В этом примере мы впервые столкнулись с существенной разницей между отношениями
в реляционной алгебре и в SQL. Все отношении SQL могут иметь дубликаты кортежей,
тс они являются мультимножествами а не множествами Дубликаты могут возникай,
в отношениях SQL разными путями. Этот вопрос подробно обсуждается в разделе 5.4.
220
Глава 5 Язык баз данных SQL
!d) Найдите помер модели продукта (ПК, ПК-блокнота или принтера)
имеющего самую высокую иену.
!е) Найдите производителей самых дешевых цветных принтеров.
!! П Найдите производителей принтеров с самым быстрь м процессором среди
всех ПК, имеющих наименьший объем RAM.
Упражнение 5.3.2. Запишите перечисленные ниже запросы, основанные на
схеме БД упражнения 4.1.3:
Classes(class, type, country, numGuns, bore, displacement)
Shtps(name, class, launched)
Battles(name, date)
Outcomesfship, battle, result)
В каждом ответе нужно использовать по крайней мере один подзапрос и записать
каждый запрос в различных формах (т.е. с помощью различных множеств операто-
ров EXISTS, IN. ALL и ANY).
а) Найдите страны, корабли которых имеют наибольшее число орудий.
*! Ь) Найдите классы кораблей, в которых хотя бы один корабль был потоплен
в сражении.
с) Найдите названия кораблей с орудиям! калибра 16 дюймов.
d) Найдите сражения, в которых участвовали корабли класса Kongo.
!! е) Найдите названия кораблей, имеющих наибольшее число орудий среди
всех кораблей такого же водоизмещения.
t Упражнение 5.3.3. Запишите без подзапросов запрос на рис. 5.8.
I Упражнение 5.3.4. Рассмотрим выражение реляционной алгебры
к, (Л, м Л,м . м R„), в котором /. — список атрибутов, принадлежащих отноше-
нию Л|. Покажите, что его можно записать в SQL, используя одни подзапросы.
Точнее говоря, запишите эквивалентное выражение SQL, в котором пункт FROM
содержит более одной переменной кортежей.
! Упражнение 5.3.5. Запишите следующие подзапросы, не применяя операторы
пересечения или разности:
*а) запрос с пересечением из рис. 5.3;
Ь) запрос с разностью нз примера 5.15.
II Упражнение 5.3.6. Некоторые операторы SQL производны в том смысле, что
их всегда можно заменить другими операторами Например, з IN R можно заме-
нить на s = ANY R Покажите, что EXISTS и NOT EXISTS производны, объяснив,
как записать выражения вида EXISTS R или NOT EXISTS R, не применяя EXISTS
(нигде, кроме выражения, обозначенного Л). Подсказка- и пункте SELECT можно
использовать кочетанту, хотя это делается редко.
5-4 Дубликаты
Рассматриваемые до сих пор операции объединения, пересечения и разности
на отношениях применялись к кортежам. В этом и в следующем разделах рассмат-
риваются операции, действующие на отношениях в целом. При этом отношения
5.4 Дубликаты 221
являются мультимножествами, а не множествами и один кортеж может входить
в отношение Многократно. В разделе 5.4.1 показано, как получить результат в виде
множества, а в разделе 5.4.2 рассказывается, как предотвратить удаление дубликатов.
5.4.1 Удаление дубликатов
Понятие отношения в SQL отличается от абстрактного понятия отношения,
введенного в главе 3. Отношение в форме множества не может содержать более
одной копии одного и того же кортежа. При создании нового отношения с помощью
запроса SQL система SQL обычно не удаляет дубликаты кортежей и в ответе на
запрос один и тот же кортеж может встречаться несколько раз.
В разделе 5.2.4 было показано, что одно из многих эквивалентных определений
смысла запроса SQL типа select-from-where начинается с декартова произведения
отношений, указанных в пункте запроса FROM. Каждый кортеж проверяется на
соответствие условию из пункта WHERE, все кортежи, удовлетворяющие данному
условию, используются для проекции согласно пункту SELECT. Эта проекция из
различных кортежей произведения может порождать один и тот же кортеж,
и все его экземпляры входят в результат. Поскольку в отношениях SQL дубликаты
кортежей допустимы, отношения, из которых строится декартово произведение,
тоже могут иметь дубликаты и каждая из идентичных копий кортежа спаривается
с кортежами из других отношений, что приводит к резкому увеличению числа
дубликатов в произведении.
Чтобы исключить порождение дубликатов, за ключевым словом SELECT ста-
вится ключевое слово D ST1NCT, которое заставляет строить только одну копию
любого кортежа. В результате получается свободный от дубликатов ответ на запрос.
Пример 5.20. Рассмотрим не содержащий подзапросов запрос на рис. 5.7.
В ответе на такой запрос будет несколько вхождении имени продюсера George
Lucas. Во избежание таких повторов заменим строку (1) запроса на
1) SELECT DISTINCT name
Тогда перед печатанием ответа все дубликаты из него будут устранены.
Оказывается, для запроса из рис. 5.5, в котором применяются подзапросы,
проблема дубликатов в ответе не возникает. Действительно, подзапрос строки (4)
порождает номер сертификата продюсера George Lucas несколько раз. Однако в
"главном" запросе строки (1) каждый кортеж отношения MovieExec рассматривается
только один раз. Предполагается, что в этом отношении есть только один кортеж
для George Lucas, поэтому только он и удовлетворяет условию пункта WHERE на
строке (3). Следовательно, George Lucas войдет в ответ только один раз. □
Последствия устранения дубликатов
Теоретически DISTINCT можно ставить после каждого слова SELECT.
Фактически удаление дубликатов из отношения может дорого обойтись.
В общем случае отношение должно быть упорядочено так, чтобы идентичные
кортежи следовали один за другим. Только при такой группировке кортежей
можно определить, следует ли удалять данный кортеж. Время, необходимое
для упорядочения отношения и удаления дубликатов, зачастую превышает
время выполнения самого запроса Поэтому, если мы хотим, чтобы запросы
выполнялись быстро, к устранению дубликатов следует прибегать выборочно
222
Глава 5 Язык баз данных SQ
5-4.2 Дубликаты е объединениях, пересечениях
и разностях
В отличие от оператора SELECT сохраняющего дубликаты по умолчанию и уда-
ляющего их только при наличии ключевого слова DISTINCT, операции объединения,
пересечения и разности, введенные в разделе 5.2.5, обычно удаляют дубликаты
кортежей. Для предотвращения удаления дубликатов за операторами UNION,
INTERSECT или EXCEPT ставится ключевое слово ALL. В результате применяется
семантика мультимножеств, описанная в разделе 4 6.2
Пример 5.21. Добавим к выражению с объединением из примера 5.16 ключевое
слово ALL:
(SELECT title, year FROM Movie)
UNION ALL
(SELECT movieTtle AS title, movieYear AS year FROM Starsin);
Теперь название и год выпуска фильма появятся в результате столько раз,
сколько их вхождений содержится в отношениях Movie и Starsin, вместе взятых
Например, если фильм входит в отношение Movie один раз, а и отношении Starsin
перечислены три кинозвезды, участвующие в этом фильме (фильм входит в три
различных кортежа из Starsin), его название и год выпуска войдут в результат
объединения четыре раза. □
Операторы NTERSECT ALL и EXCEPT ALL обозначают пересечение и разность
мультимножеств. Если Л и 5—отношения, результатом выражения
A INTERSECT ALL 5
будет отношение, в котором число вхождений кортежа t равно минимальному
числу его вхождений в А и в S’.
Число вхождений кортедса г в результат выражения
A EXCEPT ALL S
равно разности между числом вхождений t в Л и числом его вхождений в S при
условии, что эта разность положительна. Именно такие определения рассматрива-
лись для мультимножеств в разделе 4.6.2.
5.4.3 Упражнения к разделу 5.4
Упражнение 5.4.1. Запишите в SQL все запросы упражнения 4.1.1, обеспечив
устранение дубликатов
Упражнение 5.4.2. Запишите в SQL все запросы упражнения 4.1.3, обеспечив
устранение дубликатов
! Упражнение 5.4.3. Для каждого ответа из упражнения 5.3.1 определите, может
ли результат запроса содержать дубликаты кортежей. Если да, то перепишите
запрос так, чтобы дубликаты были исключены. Если нет, запишите запрос без
помощи подзапросов, что в итоге тоже дает свободный от дубликатов ответ
! Упражнение 5.4.4. Повторите упражнение 5.4.3 шля ваших ответов к упражне-
нию 5.3.2.
5.5 А;регация
223
5.5 Агрегация
Другим классом операций над отношениями и целом являются операции агре-
гации значении в столбце. Агрегация — это формирование единственного значения
нз списка значений, содержащихся в столбце Примерами агрегации являются сум-
ма значений и среднее значение в столбце. SQL позволяет не только агрегировать
столбцы, но и группировать кортежи отношения по какому-либо критерию, напри
мер по конкретному значению из другого столбца, а затем проводить агрегацию
в полученных группах.
5.5.1 Операторы агрегации
В SQL есть операторы, которые применяются к столбцу отношения и порож-
дают на нем некоторый итог, или агрегацию.
I. SUM — сумма значений в столбце.
2. AVG — среднее из всех значений в столбце.
3. MIN — минимальное из всех значений в столбце.
4 МАХ — максимальное из всех значений в столбце.
5. COUNT — число значений (включая дубликаты, если только они явным
образом не удаляются с помощью DISTINCT).
Эти операторы применяются к выражению со скалярным значением, обычно
к имени столбца, в пункте SELECT.
Пример 5.22. Следующий запрос находит среднюю величину чистого дохода
всех продюсеров фильмов:
SELECT AVG(netWorth)
FROM MovieExec
Заметим, что в этом запросе вообще нет пункта WHERE. Запрос проверяет столбец
отношения
MovieExec(name. address, cert#, netWorth)
суммирует найденные в нем значения, извлекая по одному значению из каждого
кортежа (включая дубликаты), н делит полученную сумму на число кортежей. Если
дубликатов нет, запрос дает ожидаемую среднюю величину чистого дохода. При
наличии дубликатов чистый доход продюсера фильмов, чей кортеж входит в отно
шение п раз, используется при подсчете средней величины тоже п раз □
Пример 5.23. Запрос
SELECT COUNTC)
FROM MovieExec;
подсчитывает число кортежей в отношении MovieExec. При условии, что паше — ключ
для MovieExec и в этом отношении нет дубликатов кортежей, результат совпадет
с числом продюсеров, внесенных в БД.
Применение оператора агрегации со знаком *, т.е. к кортежу в целом, имеет
смысл только для COUNT. Бесполезно применять любой другой оператор агрегации
более чем к одному столбцу.
224
Глава 5 Язык баз данных SQL
Для получения гарантии, что дублирующиеся кортежи учитываются лишь один
раз, можно вычислять только атрибут name и использовать в запросе ключевое
слово DISTINCT:
SELECT COUNT(DISTINCT name)
FROM Mov’eExec;
Если даже name не является ключом (т.е. существуют различные кортежи, относя-
щиеся к одному и тому же продюсеру фильмов или продюсеры с одним и тем же
именем), этот запрос учитывает каждое имя только один раз. □
5-5-2 Группирование
Иногда необходимо рассматривать кортежи отношения в виде групп, соответ-
ствующих значению одного из столбцов. Допустим, нужно вычислить общее коли-
чество времени (в минутах), в течение которого длятся фильмы, снятые на каждой
студии. Тогда кортежи отношения Move нужно сгруппировать в соответствии со
студнями и вычислить сумму в столбце length каждой полученной группы. Результат
может потребоваться в виде таблицы, связывающей студии с суммами продолжи-
тельности их фильмов, например:
studio SUM(tength)
Disney 12345
MGM 54321
Для получения такой таблицы применяется предложение GROUP BY, стоящее
в запросе непосредственно за предложением WHERE. За ключевыми словами
GROUP BY указывается список группируемых атрибутов. В простейшей ситуации
в предложении FROM указано только одно отношение и его кортежи группируются
согласно и.х значениям в группируемых атрибутах. Любой оператор агрегации, ис-
пользуемый в пункте SELECT, применяется только внутри групп.
Пример 5.24. Задача нахождения суммы продолжительности всех фильмов
каждой студии в отношении
Movie(ti le, year, length, inColor, studioName, producerC#)
решается с помощью запроса
SELECT studioName, SUM(length)
FROM Movie
GROUP BY studioName;
Можно допустить, что кортежи отношения Mov е распознаются и группируются
так. как показано на рис. 5.9. Затем подсчитывается сумма компонентов продолжи-
тельности в каждой группе и для каждой группы название студни печатается вместе
с такой суммой. □
Заметим, что предложение SELECT в примере 5.24 содержит термы двух типов
I Агрегаты, в которых оператор агрегации применяется к атрибуту или
к выражению, содержащему атрибут. Как уже было сказано, эти термы
оцениваются отдельно в каждой группе.
2. Атрибуты iiina studoName в данном примере, входящие в пункт GROUP
BY. В предложении SELECT, содержащем агрегаты, неагрегированными
могут быть только атрибуты, упомянутые в предложении GROUP BY.
5.5 Агрегация
225
studioName
Dsney Disney Disney
MGM MGM
ООО
Рис. 5.9. Отношение с всюброжоемым разделением но группы
Хотя запросы с GROUP BY в обшем случае могут содержать в предложении
SELECT и группируемые атрибуты, и агрегаты, с технической точки зрения это
совсем не обязательно. Например, можно написать:
SELECT studioName
FROM Movie
GROUP BY studioName
Этот запрос группирует кортежи отношения Movie согласно названиям их студий и
выдает название студии для каждой группы независимо от того, сколько кортежей
содержит данное название студии. Значит, этот запрос дает такой же результат, как
и запрос
SELECT DISTINCT studoName
FROM Movie
Предложение GROUP BY можно применять и в запросе, адресованном несколь-
ким отношениям. Такой запрос интерпретируется согласно следующим шагам.
1. Вычисляется отношение Л, которое получается из предложений FROM
и WHERE, т.е. Л—это декартово произведение отношений, указанных
в предложении FROM, к которому применен выбор указанный в предло-
жении WHERE.
2. Кортежи отношения /? группируются согласно атрибутам из предложения
GROUP BY.
3. Результат выдается в виде атрибутов и агрегатов пункта SELECT так,
словно запрос касался отношения R.
Пример 5.25. Допустим, нужно вывести на печать таблицу, перечисляющую
сумму продолжительности фильмов, выпущенных каждым продюсером Нужна
информация из двух отношений:
Movieftitle year, ength, inColor, studioName, producerC#)
MovieExecfname. address, cert#, netWorth)
поэтому мы начинаем с тэта-соединения, сравнивая входящие в них номера
сертификатов. В результате получается отношение, в котором каждый кортеж из
MovieExec спарен с кортежами из Movie, содержащими все фильмы конкретного
продюсера. И наконец, подсчитывается сумма продолжительности фильмов в каж-
дой группе. Такой запрос показан на рис. 5.10. □
226
Глава 5 Язык баз данных SOL
1) SELECT name. SUM(length)
2) FROM MovieExec. Movie
3) WHERE producerC# = cert#
4) GROUP BY name;
Рис. 5 10. Вычисление продолжительности фильмов, выпущенных каждым продюсером
5-5-3 Предложение HAVING
Предположим, что мы не хотим включать в таблицу примера 5.25 всех продю-
серов фильмов. Тогда перед группированием можно ограничить кортежи так, чтобы
нежелательные группы оказались пустыми. Например, если нужна общая продол-
жительность фильмов, выпущенных только продюсерами, чистый доход которых
превышает I0 млн. дол , строку (3) рис. 5.10 можно заменить следующей строкой:
3) WHERE producerC# = cert# AND networth >= 10000000
Однако иногда нужно выбрать группы, основанные на некотором общем свой-
стве самой данной группы. Тогда за предложением GROUP BY указывается предло-
жение HAVING, состоящее из ключевого слова HAVING, за ним следует условие,
касающееся группы.
Пример 5.26. Допустим, нужно определить общую продолжительность фильмов
только для продюсеров, выпустивших хотя бы один свой фильм до 1930 г. В конец
рис. 5 10 добавляется предложение
HAVING MIN(year) < 1930
В результате получается запрос (рис. 5 11), удаляющий нз отношения такие группы
кортежей, в которых каждый кортеж имеет в компоненте year значение 1930
и более. □
SELECT name. SUM (length)
FROM MovieExec Movie
WHERE producerC# = cert#
GROUP BY name
HAVING M N(year) < 1930,
Рис. 5.11. Вычисление продолжительности фильмов, оыпущенных старыми продюсерами
Порядок пунктов б запросах SQL
’ Мы рассмотрели шесть предложений, которые могут входить в запрос SQL
i типа selcct-from where: SELECT, FROM WHERE, GROUP BY, HAVING n ORDER BY
f Обязательны только первые три. Остальные предложения яачяются дополн! -
' тельными- они должны появляться в запросе в том порядке, в каком здесь
перечислены
5.5 Агрегация
227
5.5Л 5пражнения к разделу 5-5
Упражнение 5,5.1. Запишите перечисленные ниже запросы, основанные на
БД из упражнения 4.1.1:
Product(maker, model, type)
PCfmodel speed ram, hd, cd, price)
Laptop(model, speed, ram, hd, screen, price)
Pnnter(mode, color, type, price)
и оцените их, используя данные этого упражнения.
*а) Найдите среднюю скорость ПК.
Ь) Найдите среднюю скорость ПК-блокнотов, цена которых превышает
2500 дол.
с) Найдите среднюю цену ПК, выпущенных производителем А
Id) Найдите среднюю цену ПК и ПК-блокнотов, выпущенных
производителем D.
е) Для каждого значения скорости найдите среднюю стоимость ПК
с такой же скоростью процессора.
*1 0 Для каждого производителя найдите средний размер экрана выпускаемых
им ПК-блокнотов.
!g) Найдите производителей, выпускающих по меньшей мере три различные
модели ПК.
!h) Найдите максимальную цену ПК, выпускаемых каждым производителем.
*! i) Для каждого значения скоросги ПК, превышающего 150 МГц, определите
среднюю цену компьютера с такой же скоростью,
11 j) Найдите средний размер диска ПК тех производителей, которые
выпускают и принтеры.
Упражнение 5.5.2. Запишите перечисленные ниже запросы, основанные на БД
из упражнения 4 1.3:
Classes{clsss, type country, numGuns, bore, displacement)
Ships(name, class, launched)
Battlesfneme, date)
Outcomes(ship, battle, result)
и вычислите их. используя данные этого упражнения.
а) Определите число классов линейных кораблей.
Ь) Определите среднее число орудий для классов линейных кораблей.
'с) Определите среднее число орудии линейных кораблей Учтите разницу
между этим п предыдущим заданием. Определяется ли класс числом
входящих в него кораблей?
!d) Для каждого класса определите год, когда был спущен на воду первый
корабль этого класса
1 е) Для каждого класса определите число кораблей этого класса потоплен
ных в сражении.
228
Глава 5 Язык баз данных SQL
!! О Для каждого класса, содержащего не менее трех кораблей, определите
число кораблей этого класса, потопленных в сражении
!! g) Вес снаряда (в фунтах), выпускаемого орудием, примерно равен половине
куба его калибра (в дюймах). Определите средний вес снарядов для
кораблей каждой страны.
5.6 Изменения базы данных
До сих пор мы рассматривали нормальную форму запросов SQL — выражения
типа select-from-where. Существуют и другие формы SQL-предложений, которые не
возвращают ответы, а изменяют состояние БД В этом разделе мы сосредоточимся
на выражениях трех типов, позволяющих:
I. Вставлять кортежи в отношения
2. Удалять кортежи из отношений
3 Изменять значения определенных компонентов существующих кортежей
Все эти типы операций мы будем называть изменениями
5-6.1 Операция вставки
Основная форма предложения вставки состоит из следующих частей
1 Ключевого слова INSERT INTO
2. Имени отношения Я
3. Заключенного в скобки списка атрибутов отношения /?
4. Ключевого слова VALUES
5. Выражения кортежа, т.е. заключенного в скобки списка конкретных
значений, содержащего по одному значению для каждого атрибута из
списка, упомянутого в пункте (3).
Запись основной формы вставки:
INSERT INTO R(At,Д) VALUES (»>(,. , v„);
Кортеж строится применением значения v, для атрибута Л,- при / — 1,2,..., л.
Если в список входят не все атрибуты отношения R, для недостающих атрибутов
в создаваемом кортеже используются значения, принятые по умолчанию. Они
обсуждаются в разделе 5 7.5. Самым распространенным из них является значение
NULL, которое рассматривается в контексте SQL в разделе 5.9. Здесь же мы будем
считать NULL меткой-заполнителем, применяемой тогда, когда правильное значение
компонента неизвестно.
Пример 5.27. Предположим, нужно добавить Sydney Greenstreet к списку кино-
звезд. занятых в фильме “The Maltese Falcon". Для этого формулируется предложение:
1) INSERT INTO Starsln(movieTit1e. movieYear, starName)
2) VALUESfThe Maltase Falcon', 1942, 'Sydney Greenstreef);
В результате его выполнения кортеж с тремя компонентами, указанный на строке (2),
вставляется в отношение Starsln. Поскольку на строке (I) перечислены осе атрибуты
Starsln. компоненты, принимаемые по умолчанию, нс нужны. Значения на строке (2)
соответствуют атрибутам на строке (I) в заданном порядке, поэтому "The Maltese
, Falcon” становится значением компонента для атрибута movieTitle и т.л. □
5.6 Изменения базы данных
229
Если все атрибуты отношения обеспечены значениями, как в примере 5.27,
список атрибутов, следующий за именем отношения, можно пропустить и писать
просто:
INSERT NTO Starsin
VALUESfThe Maltese Falcon, 1942, 'Sydney Greenstreet');
Однако в этом случае мы должны быть уверены, что порядок значений совпадает
со стандартным порядком расположения атрибутов отношения. В разделе 5.7 будет
показано, как строятся схемы отношений и как при этом задается порядок атрибу-
тов. Такой порядок предполагается при установлении соответствия между значени-
ями и атрибутами, когда список атрибутов явно не указан в предложении INSERT.
Если стандартный порядок атрибутов не гарантирован, лучше явно перечислить их
в произвольно выбранном порядке.
Приведенное выше простое предложение INSERT вставляет в отношение только
один кортеж. Вместо применения явно указанных значений для одного кортежа с
помощью подзапроса можно вычислить множество кортежей, которое необходимо
ввести в отношение. Подзапрос заменяет ключевое слово VALUES и выражение
кортежа в предложении INSERT описанной выше формы.
Пример 5.28. Предположим, нужно вставить в отношение
Studi(name address presC#)
все студии, которые упомянуты в отношении
Mov e(title, year, length inColor. studioName producerC#)
но не входят в Studio. Поскольку адреса или имена президентов таких студий опре-
делить невозможно, для атрибутов address и presC# вставляемых кортежей Studio
приходится применять значение NULL. Такой способ вставки представлен на рис. 5.12.
1) INSERT INTO Studio(name)
2) SELECT DISTINCT studioName
3) FROM Movie
4) WHERE studioName NOT IN
5) (SELECT name
6) FROM Studio);
Рис. 5.12. Добавление новых студий
Выполнение этого предложения, как и большинства вложенных запросов SQL,
проще всего начинать изнутри. Строки (5) и (6) порождают все названия студий в
отношении Studio. Строка (4) устанавливает, что в число этих студий не входит ни
одной студии из отношения Movie.
Итак, строки (2) — (6) порождают множество названий студий, входящих в Mov е,
но не в Studio. Применение DISTINCT в строке (2) гарантирует, что каждая студия
входит в это множество только один раз, независимо от того, с каким числом
фильмов она связана. И наконец, трокг I) вставляет каждую из этих студий со
значением NULL для атрибутов address и presC# в отношение Studios. □
5.6.2 Операция удаления
Предложение удаления состоит из следующих компонентов:
I. Ключевого слова DELETE FROM
2. Имени отношения, например Л
230
Глава 5 Язык баз данных SQL
3. Ключевого слева WHERE
4. Условия
Форма записи операции удаления
DELETE FROM Л WHERE <условие>;
В результате ее выполнения каждый удовлетворяют ift условию (4) кортеж удаляется
из отношения Л.
Пример 5,29. Из отношения
Starsln(movieTitle, movieYear, starName)
можно удалить информацию о том, что Sydney Greenstreet играл в фильме "The
Maltese Falcon", используя следующий запрос SQL:
DELETE FROM Starsln
WHERE movieTitle = The Maltese Falcon' AND
movieYear = 1S42 AND
sta Name = Sydney Greenstreet';
Заметим, что здесь, в отличие от запроса из примера 5.27, нельзя просто задать уда-
ление кортежа, а нужно точно описать этот кортеж в пункте WHERE □
Синхронизация вставок
Рис. 5 12 иллюстрирует определенный недостаток семантики предложе-
ний SQL. В принципе оценка строк запроса (2) —(6) должна проводиться до
выполнения вставки согласно строке (1). Поэтому новые кортежи, добавляемые
в отношение Studio согласно строке (I), не могут повлиять на условие строки (4).
Однако в целях повышения эффективное и запроса при определенной реали-
зации его можно выполнять так, что в процессе обработки строк (2) — (6)
изменения в Studio выполняются сразу, как только найдена очередная новая
студия.
В данном частном примере неважно, откладываются ли вставки до завер-
шения оценки всего запроса Но в других запросах результат можно изменить
варьируя синхронизацию вставок. Допустим, DISTINCT удаляется из строки (2)
запроса 5.12. Тогда, если строки (2) —(6) оцениваются до любой вставки
новое название студии, входящее в несколько кортежей отношения Movie
несколько раз войдет в результат запроса, а следовательно, и в отношение
Studio, Если же новые студии вводятся в отношение Studio сразу при обнаруже-
нии их в процессе запроса на строках (2) — (6), одна и та же студия не будет
введена дважды. Действительно, как только новая студия вводится в отноше-
ние, ее название перестает удовлетворять условию строк (4) — (6) и уже не
появится вторично в результате запроса, указанного на строках (2) — (6)
Пример 5.30. В качестве еще одного примера удалим из отношения
Mov eExec(name, address, cert# netWorth)
сразу несколько кортежей с помощью специального условия, которому может удов-
летворять множество кортежей Предложение
DELETE FROM MovieExec
WHERE netWorth < 10000000
удаляет всех продюсеров фильмов чистый доход которых меньше 10 млн. дол. □
5.6 Изменения базы данных
231
Вставка, удаление и дубликаты
I , '
। Рассмотрим, как вставки и удаления взаимосвязаны с дубликатами, допу- ;
! стимыми в отношениях SQL. Прежде всего вставка добавляет в отношение
i определенные кортежи независимо от того, содержались ли они в данном
отношении до вставки. Значит, если в Starsln уже есть кортеж для "The Maltese
Falcon" и Sydney Greensireet, в результате вставки, рассмотренной в примере 5.27,
в данное отношение добавляется еще один экземпляр этого же кортежа Если
вслед за вставкой применить удаление, рассмотренное в примере 5.29, оба
кортежа будут удовлетворять условию пункта WHERE и поэтому оба будут
удалены. Неожиданным следствием последовательного применения вставки
и удаления является то, что полученное отношение Starsln отличается от
исходного отношения, к которому эти операции применялись. Кроме того,
предложение удаления, казалось бы, описывающее удаление единственного
кортежа, на самом деле удаляет несколько кортежей Фактически в SQL вооб
ще невозможно удалить только один из двух идентичных кортежей.
5.6.3 Операции обновления
Хотя вставки и удаления кортежей можно в каком-то смысле считать обнов-
лениями БД, обновление в SQL — это особый вид изменений БД изменяются
компоненты одного или более кортежей, существующих в БД, Общая форма пред-
ложения обновления:
1. Ключевое слово UPDATE
2. Имя отношения, например R
3. Ключевое слово SET
4 Список формул, каждая из которых устанавливает равенство атрибута
отношения Я со значением выражения или константой
5. Ключевое слово WHERE
б. Условие
Форма записи операции обновления.
UPDATE R SET Сприписывание новых значений> WHERE <условие>
Каждое приписывание нового значения (пункт 4) состоит из атрибута, знака равенства
и формулы При наличии нескольких приписываний они разделяются запятыми.
Данное предложение находит все кортежи отношения Я, удовлетворяющие
условию (6). Затем каждый из них изменяется путем оценки формул пункта 4 и
приписывания полученных значений компонентов кортежа для соответствующих
атрибутов Я.
Пример 5.31. Изменим отношение
MovieExec(name, address, cert#, netWorth)
ставя префикс Pres, перед именем каждого продюсера, являющегося президентом
студии. Условие, предъявляемое к нужным кортежам, состоит в том, что номера
сертификатов таких продюсеров должны входить в компонент presC# некоторого
кортежа из отношения Studio. Это обновление представляется выражением:
1) UPDATE MovieExec
2) SET name = Pres ' || name
3) WHERE cert# IN (SELECT presC# FROM Studio);
232
Глава 5 Язык баз данных SQL
Строка (3) проверяет, является ли номер сертификата из кортежа отношения
MovieExec одним из номеров сертификатов президентов в отношении Studio.
Строка (2) выполняет обновление выбранных кортежей. Напомним, что опера-
тор || означает конкатенацию строк, поэтому выражение, следующее за знаком =
в строке (2), помещает строку Pres, и пробел перед старым значением компонента
name данного кортежа. Новая строка становится значением этого компонента — 'Pres. '
стоит перед старым значением name. □
5.6.4 Упражнения к разделу 5-6
Упражнение 5.6.1. Запишите перечисленные ниже обновления БД, основан-
ные на схеме БД из упражнения 4.1.1
Productfmaker, model, type)
PCfmodel, speed, ram, hd, cd. price)
Laptop(modei speed, ram hd, screen, price)
Printerfmode, color, type, price)
и опишите их результаты, используя данные этого упражнения.
а) С помощью предложений INSERT введите в БД информацию о том, что
ЛК модели 1100 сделан производителем С, имеет скорость 240, RAM 32,
жесткий диск 2,5, диск I2x CD и цену 2499 дол.
!Ь) Вставьте в БД информацию о том, что для каждого ПК есть ПК-блокнот,
имеющий такую же скорость и RAM, диск 8х CD, при этом номер его
модели превышает номер ПК на 1100, а цена превышает цену ПК на 500 дол.
с) Удалите ПК с жесткими дисками объемом менее 2 Гбайт.
d) Удалите все ПК-блокноты, выпускаемые производителями, которые не
выпускают принтеры.
е) Производитель А купил предприятие производителя В Измените продукты,
выпущенные В, так, чтобы они стали продуктами А.
0 Измените объем RAM каждого ПК и добавьте к его жесткому диску
объемом 1 Гбайт.
!g) Добавьте один дюйм к размеру экрана каждого ПК блокнота, выпущен-
ного производителем Е, и уменьшите его иену на 100 дол.
Упражнение 5.6.2. Запишите перечисленные ниже обновления БД, основан-
ные на схеме БД из упражнения 4.1.3
CIasses(class, type, country, numGuns, bore,'displacement)
Shipsfname, class, launched)
Battlesfname, date)
Outcomesfship, battle, result)
и опишите их результаты, используя данные этого упражнения.
*а) Два британских линкора класса Melson — "Nelson" и "Rodney", имевшие
16-дюймовые орудия и водоизмещение в 34 тыс тонн, были потоплены
в 1927 г. Введите эту информацию в БД.
Ь) Два из трех итальянских линкоров класса Vittorio Vento — "Vittorio Vento"
и 'Italia" — были потоплены в 1940 г; третий корабль этого класса
"Roma —был потоплен в 1942 г. Каждый из них имел 15-люймовые
орудия и водоизмещение в 41 тыс. тонн. Введите эту информацию в БД
5 7 Определение схемы отношения в SQL
233
*с) Удалите из отношения Ships все корабли, потопленные в сражении.
*d) Измените отношение Classes так, чтобы калибры их орудий измерялись
в сантиметрах (I дюйм = 2,5 см), а водоизмещение в метрических тоннах
(I метрическая тонна =1,1 тонны).
е) Удалите классы, содержащие менее трех кораблей.
5-7 Определение схемы отношения в SQL
Рассмотренные ранее аспекты SQL—запросы и изменения — часто называют
манипулированием данными. В этом разделе мы начнем рассматривать определения
данных, т.е. фрагменты SQL, описывающие структуру информации в БД.
Тема данного раздела — описание реляционных схем. Мы рассмотрим, как
описывается новое отношение, называемое в SQL таблицей, а именно: имена атри
бутов, типы данных для атрибутов и некоторые фиксированные типы ограничений,
относящиеся к ключам В разделе 5.8 будут рассмотрены пользовательские "пред-
ставления" — виртуальные отношения, реально не хранящиеся в БД Некоторые
более сложные вопросы, касающиеся ограничений на отношения, будут рассмотре-
ны в главе б.
5.7.1 Типы данных
Для начала введем основные типы данных, используемые в системах SQL. Тип
данных должен иметь каждый атрибут.
1. Строка символов фиксированной или переменной длины. Тип CHAR(n)
обозначает строку фиксированной длины с п символами. Если атрибут
имеет тип CHAR(n), то в любом кортеже компонентом для этого атрибута
должна быть строка длиной в л символов. VARCHAR(n) обозначает строку
длиной до п символов включительно. Компонентами для атрибута этого
типа являются строки длиной от 0 до п символов. В SQL допустима
корректировка значений типов символьной строки. Обычно строка запол-
няется пробелами, если она становится значением компонента, являюще-
гося строкой большей фиксированной длины Например, если строка 'foo’
становится значением компонента для атрибута типа CHAR(5), она запи-
сывается как ’foo 1 (за последней буквой следуют два пробела При срав-
нении этого компонента с другой строкой пробелы можно не учитывать
(см. раздел 5.1.3).
2. Битовые строки фиксированной или переменной длины. Они аналогичны
строкам символов фиксированной и переменной длины, но их значениями
являются строки битов, а не символов. Тип В1Т(п) означает битовые строки
длины п, а тип BIT VARYlNG(n) — битовые строки длиной до п символов
включительно.
3. Тип INT или INTEGER (это синонимы) обозначает обычные значения,
выраженные целыми числами Тип SHORTINT тоже обозначает числа
целые числа, количество допустимых битов при этом может быть меньше
и зависит от конкретной реализации (аналогично случаю с типами Int
и short int в языке С).
4. Числа с плавающей точкой могут быть представлены различными сп -
собами. Для обычных таких чисел можно использовать типы FLOAT или
REAL, а более высокой точности представления можно достичь с помощью
типа DOUBLE PRECISION; разница между ними такая же, как в языке С.
В SQL есть также тип реальных чисел с фиксированной десятичной точкой.
234
Глава 5 Язык баз данных SOL
Например. DECIMAL(n.d) допускает значения, состоящие из «десятичных
цифр с десятичной точкой, стоящей после d-if иифрь при отсчете справа.
Так, 0123.45 —это возможное значение типа DECIMAL(6,2).
5. Даты и время представимы типами данных DATE и TIME соответственно.
Вспомните обсуждение дат и времени в разделе 5.1.4. Эти значения, по
существу, являются строками особой формы Фактически даты и время
можно сделать типами строки и наоборот, если строка "имеет смысл"
в качестве даты или времени
5-7.2 Простые описания таблиц
Простейшая форма описания реляционной схемы состоит из ключевых слов
CREATE TABLE, за которыми следуют имя отношения и заключенный в скобки
список имен атрибутов и их типов.
Пример 5.32. Реляционную схему для примера отношения MovieStar, нефор-
мально описанную в разделе 3.9, можно построить в виде таблицы SQL с помощью
предложения it рис. 5 13 Первые два атрибута — паше и address — объявляются
строками символов. Для представления имени используется строка фиксированной
длины в 30 символов, при необходимости в конце ее применяются пробелы
и сокращается имя, если длина его превышает 30 символов. Адреса описываются
строкой переменной длины до 255 символов.’ Неясно, чем такие способы пред-
ставления имен и адресов лучше других, но мы выбрали их, чтобы показать два
различных типа строковых данных.
1) CREATE TABLE MovieStar (
2) name CHAR(30)
3) address VARCHAR(255),
4) gender CHAR(1)
5) birthdate DATE
);
Put 5.13. Описание реляционной схемы для отношения MovieStar
Значениями атрибута gender являются единичные буквы М или F поэтому в
качестве его типа можно использовать единственный символ. И наконец, атрибуту'
birthdate вполне естественно приписать тип данных DATE. Если он недоступен
в системе, не удовлетворяющей стандарту' SQL2, можно использовать CHAR(1O),
поскольку все значения DATE—это строки, состоящие из 10 символов: восьми
цифр и двух дефисов. □
5.7.3 Удаление таблиц
Отношение, созданное как часть существующей долгое время БД, обычно
строится один раз, а затем пополняется кортежами в течение ряда лет. Его можно
загрузить из внешней памяти путем перевода данных, существующих в форме,
отличающейся от таблицы SQL, в последовательность команд ввода; такую
возможность обеспечивает, в частности, DBMS. Отношение может расширяться
г Число 255 не основано ни на каком таинственном понятии типичного адреса
Единственный байт может содержать числа от 0 до 255, поэтому строку переменной
длины до 255 символов можно представить с помошью единственного байта для
подсчета символов н байтов дчя хранения самой строки. В коммерческих системах
допустимы строки большей переменной длины.
5 7 Определение схеме отношения в SQL
235
с течением времени, накапливая кортежи. Например отношение Movie может
быть загружено из какой-то ранее существовавшей БД, а затем оно обновляется
с помошыо операций INSERT при выпуске каждого нового фильма
В некоторых случаях отношение нужно уладить из схемы БД. При изменении
обстоятельств информация, хранящаяся в таблице, может стать ненужной. Отноше
ние может также быть временным и существовать, например, в виде промежуточ-
ного результата какого то сложного запроса, который невозможно выразить одним
предложением SQL. В таких случаях отношение Л можно удалить с помощью
предложения
DROP R;
5.7.4 Изменение реляционных схем
Изменять схему существующего отношения приходится гораздо чаще, чем
удалять его из долговременной БД. Такие изменения производятся с помощью
предложения, которое начинается с ключевых слов ALTER TABLE и имени отноше-
ния, а в остальной части можно использовать различные варианты. Самыми важ-
ными из них являются следующие:
1. ADD и далее следует имя столбца и его тип.
2. DROP и далее следует имя столбца.
Пример 5.33. Отношение MovieStar можно изменить, добавив в него атрибут
phone с помощью предложения
ALTER TABLE MovieStar ADD phone CHAR(16);
В результате в схеме MovieStar становится пять атрибутов: четыре из них перечисле-
ны на рис. 5.13, а пятый, phone, является строкой фиксированной длины в 1б байт
В реальном отношении все кортежи имеют компоненты для phone, но неизвестны
номера телефонов, которые нужно в них вносить Поэтому каждый такой компо-
нент имеет значение NULL. В разделе 5.7.5 будет показано, как вместо NULL приме-
няется другое значение "по умолчанию".
В качестве примера другого изменения из MovieStar можно удалить атрибут
birthdate с помощью предложения
ALTER TABLE MovieStar DROP birthdate; □
5.7.5 Значения ио умолчанию
Создавая или изменяя кортежи, мы иногда не знаем значений всех их компо-
нентов. Например, выше было сказано, что при добавлении столбца к реляционной
схеме значения существующих кортежей неизвестны и вместо “реального" значения
применяется NULL, В примере 5.28 мы вводили новые кортежи в отношение Studio
зная при этом только название студии, но не ее адрес или номер сертификата ее
президента. В этом случае вместо значений последних двух атрибутов тоже исполь-
зуется значение типа "я не знаю".
В SQL есть значение NULL. Оно применяется в любом компоненте, которому
не приписано конкретное значение, за исключением случаев, в которых его исполь-
зование запрещено (см раздел 6.2) Однако иногда предпочтительнее применять
другое значение по умоччанию. которое вносится в компонент, если все другие
значения неизвестны.
236
Глава 5 Язык баз данных SQL
В общем случае в любое место описания атрибута и его типа данных можно
добавить к; ючевое слово DEFAULT и подходящее значение. Обычно Это NULL или
константа, но допустимы и другие значения, имеющиеся в системе, например
текущее время.
Пример 5 34. Рассмотрим пример 5 32. Допустим, мы хотим использовать
символ ? в качестве значения по умолчанию для неизвестного атрибута gender
и самую раннюю из возможных дат, DATE '0000-00-00', вместо неизвестного
атрибута birthdate Тогда строки (4) и (5) рис 5.13 заменяются на
4) gender CHAR(1) DEFAULT'?',
5) birthdate DATE DEFAULT DATE '0000-00-00'
В качестве другого примера при добавлении атрибута phone (см. пример 5 33)
можно установить для него значение по умолчанию 'unlisted'. В результате г случа-
ется следующее предложение изменения:
ALTER TABLE MovieStar ADD phone CHAR(16) DEFAULT 'unlisted'; □
5.7 6 Области значений
До сих пор для каждого атрибута мы определяли тип данных. Вместо этого
можно определять область значения. Для нее можно также описать различную ин-
формацию типа значений по умолчанию или ограничений на значения, о когорьх
пойдет речь в разделе б 3.3. Тогда при описании атрибута за его именем ставится не
тип данных, а имя области. Множество атрибутов может использовать одну и ту же
область, связывающую эти атрибуты каким-нибудь полезным образом. Например,
если два атрибута имеют одну и ту же область, значение одного из них всегда
может быть значением другого.
Определение области значений состоит из ключевых слов CREATE DOMAIN,
имени области, ключевого слова AS и типа данных:
CREATE DOMAIN <имя> AS <описание типа>;
Далее могут следовать значения по умолчанию и другие ограничения области,
которые будут рассмотрены в разделе 6.3.3.
Пример 5.35. Определим область MovieDomain для названий фильмов. Ее можно
использовать для атрибутов tide из отношения Movie и movieTtle из отношения Starsln.
Определение области:
CREATE DOMAIN MovieDomain AS VARCHAR(50) DEFAULT 'unknown':
Здесь значениями области являются строка переменной длины до 50 символов
и неизвестное название unknown’.
При описании схемы отношения Movie атрибут title можно записать как
title MovieDomain
вместо
title VARCHAR(50) DEFAULT'unknown'
Аналогичным способом можно описать и атрибут movieTitle из отношения Starsln.
movieTitle MovieDomain □
5 7 Определение схемы отношения в SQL
237
Изменить значение области по умолчанию можно с помощью предложения:
ALTER DOMAIN Mov eDomain SET DEFAULT 'no such title’;
В результате значение по умолчанию ’unknown’, введенное для MovieDomain в при-
мере 5 35, заменяется строкой 'no such title'. Можно внести и другие изменения,
например касающиеся ограничений области, которые рассматриваются в главе 6.
Определение области удаляется с помощью предложения-
DROP DOMAIN MovieDomain;
В результате эта область становится недоступной для описаний атрибутов, по атри-
буты, уже определенные с ее помощью, сохранят типы и значения по умолчанию,
которые им были приписаны до удаления области.
5.7.7 Индексы
Индекс атрибута А это структура данных, обеспечивающая эффективный
поиск кортежей, имеющих фиксированное значение для атрибута А. Индексы, как
правило, полезны в запросах, в которых атрибут А сравнивается с константой
например /1-3 или даже А £ 3. При очень большом отношении накладно сканиро-
вать все его кортежи в поиске (возможно, очень малого числа) кортежей, удовлет-
воряющих заданному условию.
Рассмотрим первый запрос из примера 5.1:
SELECT *
FROM Movie
WHERE studioName = ’Disney' AND year” 1990
Здесь может быть iO тыс. кортежей Movie, из которых только 200 фильмов выпуще-
но в 1990 г.
Примитивный способ обработки этого запроса состоит в проверке условия
пункта WHERE на каждом из 10 тыс. кортежей. Гораздо эффективнее как-нибудь
найти 700 кортежей, относящихся к 1990 г., а затем проверить есть ли в них студия
Disney. Еще лучше — сразу найти только десяток кортежей, удовлетворяющих обоим
условиям пункта WHERE но это уже превышает возможности обычных структур
данных.
Хотя создание индексов не предусмотрено ни одним стандартом SQL, включая
SQL2, в большинстве коммерческих систем разработчики БД имеют возможность
задать системе операцию создания индекса для конкретного атрибута из определенно-
го отношения. Обычно для этого применяется следующий синтаксис. Предложение-
CREATE INDEX Yearlndex ON Movie(yaar),
создает индекс с именем Yearindex на атрибуте year из отношения Movie. В даль-
нейшем процессор запросов SQL может обрабатывать запросы относите ьно года
так, что будут проверяться только те кортежи отношения Movie, в которых есть
указанный год. В результате сокращается время, необходимое для получения ответа
на запрос.
В SQL часто допустимы многоатрибутные индексы с несколькими переменны-
ми, позволяющие эффективно находить кортежи с заданными значениями этих
переменных. Может показаться, что многоатрибутный индекс менее полезен чем
индекс единственного атрибута, так как последний можно применять тогда, когда
первый не имеет значений для каждого из своих И все же тогда, когда многоатри-
бутные индексы можно применять, этим надо пользоваться, поскольку они повы-
шают эффективность поиска кортежей.
23В
Глава 5 Язык баз данных SQL
Пример 5.36. Если title и year образуют ключ для Movie, значит, либо опреде-
лены значения обоих этих атрибутов, либо не определено ни одно из них. Типич-
ное описание индекса этих атрибутов:
CREATE INDEX Keyindex ON Movieftitle. year)'
Поскольку (title year) — ключ, при задан ьх названии и годе выпуска фильма
индекс укажет единственный требуемый кортеж. Напротив, если запрос определяет
и год, и название, ио при этом доступен лишь индекс Yearindex, система может
найти только все ф| льмы заданного года выпуска, а затем искать среди них нужное
название.
Лучше иметь индекс на одном атрибуте title, чем на одном атрибуте уеег, так
как обычно в один год выпускается множество фильмов, а фильмы с одинаковым
названием встречаются крайне редко. В данном примере поиск всех заданных
названий фильмов с последующей их проверкой по заданному году требует не
намного больше времени, чем применение многоатрибутного индекса для Йен
year. □
Для улалелия индекса достаточно полстааить его имя в предложение
DROP INDEX Yearndex
При выборе индексов нужно соблюдать определенный баланс.
• С одной стороны, существование индекса на атрибуте обычно увеличивает
скорость выполнения запросов, определяющих значение этого атрибута.
* С другой стороны, каждый индекс, построенный на атрибуте отношения,
усложняет операции вставки, удаления и изменения, а также увеличивает
время их выполнения.
Выбор индексов — один из самых трудных элементов проектирования БД так
как при этом требуется определить, какими будут типичные множества запросов
и другие операции на БД. Как правило, имеет смысл строить индексы тогда, когда
к отношению чаще применяются запросы, чем изменения. Если же доминируют
изменения, к созданию индексов следует подходить осторожно. Однако даже
индекс часто изменяющегося атрибута может быть эффективным. Поскольку
некоторые команды изменения включают в себя запросы (например, INSERT
с подзапросом типа select-from-where или DELETE с условием), нужно внимательно
следить за относительной частотой изменений и запросов
5-7 8 Упражнения к разделу 5-7
* Упражнение 5.7 1. В этом разделе дано формальное описание только отноше-
ния MovieStar. Дайте подходящие описаг ня остальных четырех отношений
Movieftitle, year, length, inColor, studioNeme, producerC#)
Starsln(movieTitle, movieYear, starName)
MovieExec(name, address, cert#, netWorth)
Studio(name, address, presC#)
Ипрожнение 5 7.2. Используя неформальные схемы БД из упражнения 4.1.1
Product(maker. model, type)
PC(model, speed, ram, hd cd, price)
Laptop(model, speed, ram. hd, screen price)
Printer(model, color, type, price)
5.8 Определения пользовательских представлений
239
дайте описания:
а) схемы отношения Product:
b) схемы отношения PC:
гс) схемы отношения Laptop;
d) схемы отношения Printer;
е) определения области ModelType, значениями которой являются номера
моделей: покажите, как применить эту область в схемах fa) — (d);
*f) изменения схемы (с), состоящего в добавлении атрибута cd; если
ПК-блокнот не имеет считывающего устройства CD, используйте для
этого атрибута значение по умолчанию 'попе';
g) изменения схемы (d), состоящего в удалении атрибута color.
Упражнение 5,7.3. Используя неформальные схемы БД из упражнения 4.1.3
Classesfclass, type, country, numGuns, bore, displacement)
Shipsfname, class, launched)
Battlesfname, date)
Outcomesfship, battle, result)
дайте описания:
а) схемы отношения Classes;
b) схемы отношения Ships;
с) схемы отношения Battles:
d) схемы отношения Outcomes;
е) определения области ShlpNames, применимой и к кораблям, и к именам
классов; покажите, как применить эту область в схемах (а), (Ь) и (с);
О изменения схемы (Ь), состоящего в добавлении атрибута yard, обозначаю-
щего док, в котором был построен корабль;
g) изменения схемы (а), состоящего в удалении атрибута bore
I Упражнение 5.7.4. Объясните разницу между предложениями
DROP R
и
DELETE FROM R.
5.8 Определения
пользовательских представлений
Отношения, определяемые с помощью предложения CREATE TABLE, реально
существуют в БД, т е система SQL размещает таблицы в некоторой типичной
структуре. Они постоянны в том смысле, что могут неограниченно долго сохранять-
ся в неизменном виде, если только не изменяются с помощью INSERT или любых
других операторов изменения, рассмотренных в разделе 5.6.
В SQL есть другой класс отношений, называемых пользовательскими или про
сто представлениями, Физически они не существуют, а определяются выражениям)
во многом похожими на запросы. К представлениям можно адресо) ать запросы
так, словно они существуют физически, а в некоторых случаях допускается даже
изменять их.
240
Глава 5 Язык баз данных SOL
5.8 1 Описание представлений
Простейшая форма определения представления.
I. Ключевое слово CREATE VIEW.
2. Имя представления
3. Ключевое слово AS.
4 Запрос Q, являющийся определением представления. При наличии запро-
са к самому представлению SQL действует так, словно к этому моменту
запрос Q уже выполнен и к его результату применен запрос, адресован-
ный представлению.
Простая форма описания представления
CREATE VIEW <имя_представления> AS <определение_представления>;
Пример 5 .37. Допустим нужно создать представление, являющееся частью от-
ношения
Movie(title, year, length inColor, studioName, producerC#)
состоящей из названий и годов выпуска фильмов, созданных студиями Paramount.
Определение этого представления:
1) CREATE VIEW ParamountMovie AS
2) SELECT title, year
3) FROM Movie
4) WHERE studioName = ’Paramount’;
Имя представления ParamountMovie указано на строке (I), а его атрибуты title
и year перечислены на строке (2) Определением представления являются строки
(2) - (4). □
Отношения таблицы и представления
Программисты SQL чаще употребляют термин "таблица", а не ’’отношение".
Дело в том, что различие между хранимыми в БД отношениями ("таблицами")
и виртуальными отношениями ("представлениями") имеет важное значение
Зная теперь разницу между таблицей и представлением, мы можем применять
термин "отношение" только тогда, когда речь идет о таблиие или о представ-
лении Чтобы подчеркнуть, что отношение хранится в памяти, а не является
представлением, мы иногда будем употреблять термин "отношение базы’ или
"таблица базы"
Есть и третий вид отношений, которые не относятся к представлениям
и не хранятся постоянно, а являются временными результатами подзапросов
В дальнейшем они тоже будут называться ’отношениями*
J
5-8 2 Запросы к представлениям
Отношение ParamountMovie не имеет кортежей в обычном смысле, но при
наличии запроса к этому отношению в ответ на него извлекаются кортежи из
таблицы базы Movie. В результате можно дважды адресовать ParamountMovie один
и тот же запрос и получить на него разные ответы, даже если ParamountMov е не
5.8 Определения пользовательских представлений 241
изменялось — ведь таблица базы могла измениться за время, прошедшее между
этими запросами.
Пример 5.38. Представление ParamountMovie можно запрашивать так же, как
и хранимую таблицу:
SELECT title
FROM ParamountMovie
WHERE year = 1979;
Определение представления ParamountMovie используется для преобразования
этого запроса в другой запрос, адресованный только к таблице базы Movie. В разде
ле 5.8.5 будет показано, как запросы к представлениям преобразуются в запросы
к таблицам базы. В данном простом примере легко установить что означает запрос
к представлению. ParamountMovie отличается от Movie по двум параметрам:
1. ParamountMovie порождает только атрибуты title и year.
2. Условие studioName = ‘Paramount1 — это часть любого пункта WHERE,
касающегося ParamountMov е.
Поскольку запрос относится только к атрибуту title, с пунктом (I) проблем не воз-
никает Для пункта (2) достаточно ввести условие studioName = Paramount1 в пункт
запроса WHERE. Затем Movie можно использовать вместо ParamountMovie в пункте
FROM, сохранив прежний смысл запроса. Итак, запрос
SELECT title
FROM Movie
WHERE studioName = 'Paramount1 AND year = 1979
относится к таблице базы Movie и дает тот же результат, что и исходный запрос
к ParamountMovie Заметим, что такой перевод выполняется системой SQL Мы
привели здесь процесс рассуждений только для того, чтобы показать смысл запроса
к представлению □
Пример 5.39. Можно также писать запросы, содержащие представление и таб-
лицы базы. Например:
SELECT DISTINCT starName
FROM ParamountMovie Starsln
WHERE title = movieTitie AND year = movieYear;
Это запрос об именах всех кинозвезд, снимающихся в фильмах, выпущенных сту
днями Paramount. Применение DISTINCT гарантирует, что имя каждой кинозвезды
будет упомянуто только один раз, даже если она снималась во многих фильмах. □
Пример 5.40. Рассмотрим более сложный запрос, применяемый для определе-
ния представления Наша цель — построить отношение MovieProd содержащее
названия фильмов и имена их продюсеров. Запрос, определяющий представление,
включает в себя отношение
Movieftitle, year length, inColor studioName, producerC#)
из которого мы получаем номер сертификата продюсера, и отношение
MovieExec(name, address, cert#, netWorth)
24:
Глава 5 Язык баз данных SO
п котором сертификат связывается с именем продюсера. Можно создать следующее
представление:
1) CREATE VIEW MovieProd AS
2) SELECT title, name
3) FROM Movie, MovieExec
4) WHERE producerC# = cert#,
К нему можно адресовать запрос как к хранимому в БД отношению. Напри-
мер. для поиска продюсера фильма "Gone Wi(h (he H ind" формулируется запрос.
SELECT name
FROM MovieProd
WHERE title = 'Gone With the W nd';
Как и использование любого представления, этот запрос считается экв патент-
ным запросу, адресованному исключительно таблицам базы например-
SELECT name
FROM Movie, MovieExec
WHERE producerC# = cert# AND title - 'Gone With the Wind'; □
5.8.3 Переименование атрибутов
Иногда удобнее давать имена атрибутам представления по собственному
усмотрению а не использовать имена из запроса, определяющего представление.
Атр| буты представления можно определить, перечислив их в скобках вслед за
именем представления в предложении CREATE VIEW Например, определение
представления из примера 5.40 можно записать следующим образом:
CREATE VIEW MovieProd(movleTitle, prodName) AS
SELECT title, name
FROM Movie MovieExec
WHERE producerC# - cert#,
Представление остается прежним, но его столбцы теперь озаглавлены movieTitle и
prodName вместо ti le и name.
5 8 4 Изменение представлений
При некоторых обстоятельствах к представлениям можно применять операции
вставки, удаления и изменения Поначалу может показаться что такая идея вообще
бессмысленна, поскольку представление не существует так. как существует таблица
базы (хранимое отношение). Что означает вставка нового кортежа в представление?
Куда попадает этот кортеж и как система БД может помнить о том, что он дозжен
быть в представлении9
Для многих представлений ответ: "Этого делать нельзя . Однако изменения
достаточно простых представлений называемых обновляемыми представлениями,
можно перевести в эквивалентные изменения таблицы базы и выполнить их на
»тон таблице. В SQL2 есть формальные определения случаев в которых изменения
представления, говоря упрощенно, допустимы Правила SQL2 достаточно сложны,
но они позволяют модифицировать представления, определяемые путем выбора
(с помощью SELECT но не SELECT DISTINCT) некоторых атрибутов из одного
отношения Л (которое само может быть обновляемым представлением). При этом
должны выполняться два важных технических условия:
• Предложение подзапроса WHERE не должно содержать Л.
5.8 Определения пользовательских представлений
243
• Предложение SELECT должно содержать достаточное число атрибутов для
каждого вставляемого в представление кортежа так, чтобы недостающие
атрибуты можно было заполнить значениями NULL или собственными
значениями по умолчанию и получить кортеж отношения базы, который
дает вставляемый в представление кортеж.
Пример 5.41 Допустим, нужно вставить кортеж в представление ParamountMovie
из примера 5.37.
INSERT INTO ParamountMovie
VALUESfStar Trek' 1979)
Представление ParamountMovie почти удовлетворяет условиям обновляемости
представлений в SQL2, поскольку представление запрашивает только некоторые
компоненты отдельных кортежей таблицы базы
Movie(title, year, length inColor, studioName, producerC#)
Единственная проблема в том, что атрибут studioName из Movie не является
атрибутом представления и поэтому кортеж, вводимый в Movie, имеет для атрибута
stud oName значение NULL вместо 'Paramount.
Значит, чтобы сделать представление ParamountMovie обновляемым, нужно ввес-
ти атрибут studioName в предложение SELECT, даже если очевидно, что названием
студии будет Paramount. Измененное определение представления ParamountMovie
выглядит следующим образом:
1) CREATE VIEW ParamountMovie AS
2) SELECT studioName, title, year
3) FROM Movie
4) WHERE studioName ~'Paramount';
Теперь можно записать вставку в обновляемое представление ParamountMovie-
INSERT INTO ParamountMovie
VALUESfParamount' 'StarTrek' 1979);
В результате образуется кортеж из Movie, который дает вставляемый в пред-
ставление кортеж, когда определение представления применяется к отношению
Movie. Здесь компонентом studioName является 'Paramount', компонентом title —
'Star Trek', а компонентом year — 1979.
Остальные не входящие в представление атрибуты — length, InColor и producerC# —
должны присутствовать во вставляемом кортеже Movie. Однако их значения вывес
ти невозможно. Поэтому новый кортеж Movie должен иметь в компонентах для
каждого из этих атрибутов подходящее значение по умолчанию: NULL или другое
подобное значение, установленное для атрибута или его области. Например, если
для атрибута length установлено значение по умолчанию 0, а для двух других —
NULL, вставляемым кортежем Movie будет
title I year I length inCotor | studioName producerC#
'Star Trek' 1979 i 0 I NULL 'Paramount NULL
К обновляемому представлению можно применять также операцию удаления.
Удаление, как и ввод, проходит через базовое отношение /?, из которого удаляется
каждый кортеж, порождающий удаляемый из представления кортеж.
244
Глава 5 Язык баз данных SQL
i“— - • - —____=—_— ........ ......................
Почему некоторые представления
необновляемы
Рассмотрим представление MovieProd из примера 5.40, связывающее с на-
। званиями фильмов и имена продюсеров. Согласно определению SQL2 оно не
• является обновляемым, так как в предложение FROM входят два отношения —
| Movie и MovieExec. Допустим, мы пытаемся вставить кортеж
('Greatest Show on Earth', 'Cecil В. DeMil e')
Его нужно вставить в оба отношения — Movie и MovieExec. Для атрибутов
типа length или address можно использовать значение по умолчан по NULL, но
что делать с двумя равными атрибутами — producerC# и cert#? Для них тоже
можно было бы использовать NULL, но при объединении отношений SQL не
считает два значения NULL равными (см. раздел 5.9.1). Поэтому 'Greatest
Show on Earth" не связывается с "Cecil В DeMille” в отношении MovieProd
j и ввод оказы зается некорректным.
Пример 5.42. Допустим, из обновляемого представления ParamountMovie нужно
удалить все фильмы, в названиях которых есть слово Trek. Используем следующее
предложение удаления:
DELETE FROM ParamountMovie
WHERE tite LIKE '%Trek%';
Это удаление переводится в эквивалентное удаление на таблице базы Move с той
лишь разницей, что условие, определяющее представление ParamountMovie, добав-
ляется к условию пункта WHERE. В результате получается предложение удаления.
DELETE FROM Move
WHERE title LIKE %Trek%' AND studioName = 'Paramount;
□
Обновление представления тоже проходит через базовое отношение. При этом
обновляются все кортежи отношения, порождающие обновляемые кортежи пред-
ставления.
Пример 5.43. Обновление представления:
UPDATE ParamountMovie
SET year - 1979
WHERE title = 'Star Trek the Movie';
это преобразова! не например в такой вид
UPDATE Movie
SET year = 1979
WHERE tite ‘Sta Trek the Movie' AND
stud oN ame =' Paramount', □
5 8 Определения пользовательских представлений
245
Последний вид изменения представления — это удаление его целиком Это из-
менение можно выполнять независимо от того, обновляемо удаляемое представле-
ние или нет. Типичное предложение удаления DROP:
DROP VIEW ParamountMovie;
Оно удаляет определение представлении, и после этого уже нельзя формулировать
запросы или команды изменений, содержащие это представление Однако такое
удаление не влияет иа кортежи базового отношения Movie. Напротив, предложение
DROP TABLE Movie
удаляет таблицу Movie и делает представление ParamountMovie недоступным, так
как адресованный этому представлению запрос относится уже к несуществующему
отношению Movie.
5-8-5 Интерпретация запросов,
содержащих представления
В этой книге мы не будем детально рассматривать, как система SQL реализует
запросы к представлениям, а объясним их смысл с помощью интерпретации При
этом мы ограничимся запросами и представлениями, выражаемыми в реляционной
алгебре, хотя в полном SQL допустимы и операторы, соответствующие группирова-
нию и агрегации.
Основная идея интерпретации проиллюстрирована на рис. 5.14 Запрос Q
представлен здесь в виде дерева выражения реляционной алгебры. В качестве
листьев этого дерева используются отношения, являющиеся представлениями И и Ж
Их определения тоже имеют форму деревьев выражений реляционной алгебры.
Рис. 5.14. Подстановка определений представлении вместо ссылок на представления
При создании запроса к таблицам базы вместо каждого листа в дереве Q, я вл я
юшегося представлением, подставляется корень экземпляра дерева, определяющего
это представление. На рис. 5.14 показано, что листья Г и ГК заменены определени-
ями представлений. Результирующее дерево — это запрос к таблицам базы, эквива
лентный исходному запросу к представлениям
Пример 5.44. Рассмотрим определение представления и запрос из примера 5.38.
Определение представления выглядит следующим образом
1) CREATE VIEW ParamountMovie AS
2) SELECT title, year
3) FROM Movie
4) WHERE studioName = 'Paramount';
246
Глава 5 Язык баз данных SQL
Дерево выражения мв этого представления показано на рис 5 15.
tide, year
СУ stucicb'axe “ 1 Paiamour.t'
Movie
Рис. 5.15, Дерево выражения для представления ParamountMov е
Запрос из примера 5.38:
SELECT title
FROM ParamountMov е
WHERE year =1979;
относится к фильмам, выпущенным студией Paramount в I979 г. Дерево выражения
этого запроса показано на рис. 5.16. Заметим, что один лист в этом дереве обознача-
ет представление ParamountMovie. Данный запрос интерпретируется путем подста-
новки дерева, изображенного на рис. 5.15, вместо листа ParamountMovie на рис. 5.16
Я title
СУ year - 1979
ParamountMovie
Рис. 5.16. Дерево вырожения cyin запроса
Результат подстановки показан на рис. 5.17
Дерево, изображенное иа рис. 5.17,— приемлемый, но излишне сложный спо-
соб интерпретации запроса. Система SQL вынуждена трансформировать это дерево,
чтобы оно выглядело так, как дерево выражения для запроса из примера 5.38:
SELECT title
FROM Movie
WHERE studioName -'Paramount' AND year = 1979;
Например, проекцию n„,t можно поставить над выбором иу,„ ,e7e, так как
перепое проекции на более позднее время не может изменить смысл выражения.
Тогда получатся дне последовательные проекции, сначала на title и year а затем
только на title. Ясно, что первая из них является избыточной и ее можно устранить.
Таким образом две проекции можно заменить одной проекцией — на title.
5 8 Определения пользовательских представлений
247
title
С year - 197S
title, year
СУ studioName * 'Paramount’
Movie
Рис. 5.17. Вьражение запросе в терминах таблиц базы
Две операции выбора тоже можно скомбинировать. В общем случае два после-
довательных выбора заменяются одним выбором для связки AND в их условиях.
Результирующее дерево выражения показано на рис. 5.18. Именно такое дерево
получается непосредственно из запроса:
SELECT title
FROM Movie
WHERE studioName ='Paramount' AND year = 1979;
title
СУ year ~ 1979 AND studioName = ‘ Peraroour.t'
Movie
Рис. 5.18. Упрощение запросе к таблицам базы
5.8.6 Упражнения к разделу 5-8
Упражнение 5.8.1. Из таблиц базы
MovieStar(name, address, gender, birthdate)
MovieExec(name, address, cert#, netWorth)
Studio(name. address, presC#)
248
Глава 5 Язык баз данных SQL
постройте следующие представления:
•а) Представление RichExec, содержащее имена, адреса и номера сертифика-
тов администраторов с чистым доходом не менее 10 млн. дол.
Ь) Представление StudioPres, содержащее имена, адреса И номера сертифи-
катов всех администраторов, являющихся президентами студий
с) Представление Executivestar, содержащее имена, адреса пол, даты рожде-
ния, номера сертификатов и размеры чистого дохода людей, являющихся
администраторами и кинозвездами одновременно.
Упражнение 5.8.2. Какие представления из упражнения 5.8.1 являются обнов-
ляемыми?
Упражнение 5 8.3. Запишите перечисленные ниже запросы с помощью одного
или нескольких представлений из упражнения 5.8.1, не используя при этом ника-
ких таблиц базы
а) Найдите имена женщин, являющихся одновременно кинозвездами
и администраторами.
*'Ь) Найдите имена администраторов, являющихся президентами студий
и имеющих чистый доход не менее 10 млн. дол.
!с) Найдите имена президентов студий, являющихся кинозвездами
и имеющих чистый доход не менее 50 млн. дол.
*! Упражнение 5.8.4, Для представления и запроса из примера 5.40:
а) Постройте дерево выражения для представления MovieProd.
б) Постройте дерево выражения для запроса нз данного примера.
с) Постройте из ваших ответов на пункты (а) и (Ь) выражение для запроса
в терминах таблиц базы
d) Объясните, как изменить выражение из пункта (с), чтобы получить
эквивалентное ему выражение, соответствующее решению,
предложенному в примере 5.40.
! Упражнение 5.8.5. Запишите все запросы и представления из упражнения 5.8 3
в виде выражений реляционной алгебры, замените применения представлений
в выражении запроса и упростите, насколько это возможно, результирующие выра-
жения. Запишите соответствующие им запросы SQL на таблицах базы.
Упражнение 5.8.6. Используя таблицы базы
Classesfclass, type, country, numGunu, bore, displacement)
Ships(name, class, launched)
из примера 4.1.3. сделайте следующее:
а) Постройте представление BrltishShips, определяющее для каждого
принадлежащего Великобритании корабля его класс, тип, количество
и калибр орудий водоизмещение и год спуска на воду
Ь) Используя представление из пункта (а) постройте запрос о количестве орудий
и водоизмещении всех британских линкоров, спущенных на воду до 1919 г.
'с) Запишите запрос из пункта (а) и представление из пункта (Ь) в виде
выражений реляционной алгебры, замените применения представлений
з выражении запроса и упростите, насколько это возможно,
результирующие выражения
!d) Постройте соответствующий выражению из пункта (с) запрос SQL
на таблицах базы Classes и Ships.
5 9 Пусзые значения и внешние соединения
249
5.9 Пустые значения
и внешние соединения
В этом разделе мы более подробно рассмотрим применение NULL В качестве
значения в кортежах SQL. Особенно важную роль значения NULL играют в опреде-
лении варианта операции соединения, позволяющего сохранять информацию в си-
туациях, когда кортеж отношения невозможно соединить ни с одним кортежем
другою отношения. Такая версия соединения называется внешним соединением.
В данном разделе рассматриваются различные варианты оператора внешнего
соединения Он используется только в системах, поддерживающих SQL2, хотя
значения NULL присутствуют и в более ранних стандартах SQL.
5.9.1 Операции на значениях NULL
В разделе 4 7.4 было показано, как специальное значение NULL применяется
для обозначения неизвестного или несуществующего значения NULL используется
например, тогда, когда кортеж вставляется в отношение с помощью команды,
определяющей некоторые, хотя и не все компоненты кортежа. NULL появляется
в компонентах, значения которых не определены, если для них не установлено
другое значение по умолчанию. Другим источником NULL является внешнее соеди-
нение.
Прн действиях со значением NULL нужно соблюдать два важных правила
I. Результатом применения арифметических операторов типа х или + к NULL
и другому значению, содержащему NULL, должно быть значение NULL
2. Результатом сравнения NULL с любым другим значением, содержащим
NULL, с помощью операторов типа = или > должно быть значение
UNKNOWN Оно является третьим истинностным значением наряду с TRUE
и FALSE
Хотя значение NULL и может появляться в кортежах, оно не является константой.
Поэтому сформулированные выше правила можно применять для операций на
выраже пнях содержащих NULL, но само это значение нельзя использовать явным
образом в виде операнда
Специфика значений NULL
Предполагается, что NULL в SQL2 всегда можно считать “значением,
которое не известно, но обязательно существует". Однако во многих случаях
такое интуитивное понимание NULL оказывается неверным Допустим, напри-
мер, что х - компонент кортежа, областью значения которого являются целые
числа. Можно утверждать, что 0 * х имеет значение 0, так как умножение
любого числа на 0 дает 0. Но если х содержит значение NULL, по правилу (1)
нз раздела 5.9 1 произведение 0 и NULL дает NULL Аналогично, х-х = 0, так
как разность любого целого числа с самим собой всегда равна 0, а примене-
ние правила (1) и в этом случае дает NULL
Пример 5.45. Пусть х имеет значение NULL. Тогда х + 3 тоже равно NULL
Однако NULL + 3 не является правильным выражением SQL Значением выражения
х= 3 являегся UNKNOWN, так как значение х — это NULL и мы не знаем, равно ли
оно 3. Сравнение NULL также не является корректным выражением SQL □
250
Глава 5 Язык баз данных SQL
Правильным способом определения, имеет ли х значение NULL, является
выражение х IS NULL. Оно истинно, если х имеет значение NULL, и ложно в про-
тивном случае. Выражение х IS NOT NULL истинно, если значением х не является
NULL.
5-9-2 Истинностное значение UNKNOWN
В разделе 5.1.2 говорилось, что результатами сравнения являю ся TRUE или
FALSE, и эти истинностные значения стандартным образом комбинируются с по
мошыо связок AND, OR и NOT. При наличии значения NULL сравнение может дать
и значение UNKNOWN. Рассмотрим, как ведут себя операторы при комбинировании
всех трех истинностных значений.
Следующие правила легче запомнить, обозначив TRUE как 1 (полностью
истинно), FALSE как 0 (полностью ложно) и UNKNOWN как 1/2 (где-то между
истинным и ложным).
I. AND с двумя истинностными значениями дает минимум от этих значе-
ний: х AND у принимает значение FALSE, если х или у есть FALSE; значе-
ние UNKNOWN, если ни х, ни у не имеют значения FALSE, но по крайней
мере один из них имеет значение UNKNOWN, и значение TRUE, если и х,
и у имеют значение TRUE.
2. OR с двумя истинностными значениями дает максимум от этих значений:
х OR у принимает значение TRUE, если х или у есть TRUE; значение
FALSE, если х млн у имеет значение FALSE, и значение UNKNOWN, если
ни х, ни у не имеют значения TRUE, но по крайней мере один из них
имеет значение UNKNOWN.
3. Отрицание истинностного значения равно 1 минус данное истинностное
значение: NOT х принимает значение TRUE при значении х—FALSE;
значение FALSE при значении х—TRUE и значение UNKNOWN при зна-
чении х - UNKNOWN.
На рис. 5 19 представлены результаты применения трех логических операторов
к девяти различным комбинациям истинностных значений операндов х и у. Значе-
ние последнего оператора NOT зависит только от х.
X xANDy xORy NOTx
TRUE TRUE TRUE TRUE FALSE
TRUE UNKNOWN UNKNOWN TRUE FALSE
TRUE FALSE FALSE TRUE FALSE
UNKNOWN TRUE UNKNOWN TRUE UNKNOWN
UNKNOWN UNKNOWN UNKNOWN UNKNOWN UNKNOWN
UNKNOWN FALSE FALSE UNKNOWN UNKNOWN
FALSE TRUE FALSE TRUE TRUE
FALSE UNKNOWN FALSE UNKNOWN TRUE
FALSE FALSE FALSE FALSE TRUE
Рис. 5.19. стинносгноя таблице для трехзначной логики
SQL-условия стоящие в предложениях WHERE запросов типа select-from-wl ere
или в операциях DELETE, применяются к каждому кортежу некоторого отношения,
и для каждого кортежа порождается одно из значений: TRUE, FALSE или UNKNOWN.
5.9 Пустые значения и внешние соединения
251
Однако в ответ входят только те кортежи, для которых заданное условие имеет
значение TRUE, а кортежи с UNKNOWN или FALSE из ответа исключаются В такой
ситуации могут возникнуть неожиданности, подобные тем, которые упоминались
в заключенном в рамку тексте “Специфика значений NULL".
Пример S.46. Рассмотрим отношение
Movieftitle, year, length, inColor, studioName, producerC#)
и запрос
SELECT *
FROM Movie
WHERE length <=120 OR length >120
Можно предположить, что в результате такого запроса получится копия отношения
Movie, так как каждый фильм имеет либо меньшую продолжительность, либо
равную, либо превышающую 120.
Но предположим, что в Movie есть кортежи со значением NULL в компоненте
length. Тогда оба сравнения — length <= 120 и length > 120 — принимают значение
UNKNOWN. Согласно рис. 5.19 два значения UNKNOWN со связкой OR дают
UNKNOWN Поэтому для любого кортежа с NULL в компоненте length пункт
WHERE принимает значение UNKNOWN и этот кортеж не включается в ответ на
запрос. Значит, смысл данного запроса — найти кортежи без значений NULL
в компоненте length □
5-9.3 Выражение соединений в SQL2
Прежде чем ввести операцию внешнего соединения SQL2, рассмотрим про-
стейший случай обычного соединения. В SQL2 доступно множество видов операто-
ров соединения. В более ранних стандартах SQL их в явном виде нет, но равный их
применению эффект можно получить с помощью запросов типа select-from-where.
В SQL2 соединения являются альтернативой запросам типа select-from-where и их
можно использовать всегда, когда допустимо применение запросов такого типа.
Поскольку соединения порождают отношения, их можно применять и в пунктах
FROM этих запросов.
Простейшая форма соединения — перекрестное соединение Этот термин — сино-
ним декартова произведения или просто 'произведения” из раздела 4.1 4 Например,
для получения произведения двух отношений
Movie(title year length, InColor studioName. producerC#)
Starsln(mavieTltle, movieYear, starName)
можно записать выражение
Movie CROSS JOIN Starsln
и в результате получить отношение с девятью столбцами и всеми атрибутами отно-
шений Movie и Starsln Кортежем результирующего отношения будет каждая пара,
состоящая из одного кортежа из Movie и одного кортежа нз Starsln.
Атрибуты результирующего отношения можно обозначить R.A, где R — одно из
соединяемых отношений, а Л — один из его атрибутов. Обычно R и точку можно
пропустить, если только одно из отношений имеет атрибут А В данном примере
У отношений Movie и Starsln нет общих атрибутов и для произведения достаточно
Девяти имен атрибутов
252
Глава 5 Язык баз да ных SQL
Само по себе произведение редко бывает полезным. Более стандартное тэта-
соединение получае ся с помощью ключевого слова ON и какого-то условия. Между
отношен 1Ями Я и 5 ставится JOIN, а далее следует ON и заданное условие. Тогда за
операцией произведения следует выбор для любого условия, указанного после ON.
Пример 5.47. Предположим, нужно объединить отношения
Movieftitle. year, length, inColor, studioName, producerC#)
Sta sln(mov eTi ie, movieYear, starName)
при условии, что будут объединяться только кортежи, относящиеся к одному и тому
же фильму, т.е. названия фильмов и годы их выпуска в обоих отношениях должны
совпадать Тогда в результате запроса
Movie JOIN Starsin ON
ti le = movie itle AND year = movieYear,
ci ова получится отношение с девятью столбцами и очевидными именами атрибутов. Но
теперь кортежи из отношений Movie и Starsin составляют кортеж ответа, если только
они совпадают по году выпуска и названию фильма Б итоге два столбца оказываются
излишними, так как каждый кортеж результата имеет одно и то же значение в компо-
нентах tite и movieTWe и одно и то же значение в year и movieYear. □
Соедг нения могут входить в предложения FROM запросов типа select from where.
При этом отношение, обозначенное таким выражением, интерпретируется точно
гак же, как таблицы базы или представления в предложении FROM.
Пример 5.48. Если имеет значение то, что в отношении из примера 5.47 есть
избыточные кортежи, все выражение из этого примера можно поместить в предло-
жение FROM и применить SELECT для удаления ненужных атрибутов. Итак, мы
можем записать запрос:
SELECT title year, length, inColor, studioName,
producerC#, starName
FROM Movie JOIN Starsin ON
title = movieTite AND year = movieYear;
чтобы получить отношение с семью столбцами, состоящее из кортежей отношения
Movie, расширенных всеми возможными способами за счет имен кинозвезд, сняв-
шихся в конкретном фильме □
5-9.4 Натуральные соединения
Натуральные объединения отличаются от тэта-соединений двумя параметрами
I Единственное условие натурального соединения заключается в том, что все
пары атрибутов из двух отношений, имеющих общее имя, приравниваются.
2. Одна из пар равных атрибутов удаляется путем проекции.
Натуральное объединение SQL2 деиствует точно так же, только оператор соедине-
ния lx захеняе ся ключевыми словами NATURAL JOIN
Пример 5.49. Вычислим натуральное соединение отношений
MovieStar(name, address, gender, birthdate)
Mov’eExec(name, address, cert#, networth)
5.9 Пустые значения и внешние соединения
253
В результате получится отношение, схема которого содержит атрибуты пате
и address плюс атрибуты, входящие в одно или другое из этих двух отношений.
Кортеж результата будет обозначать человека, являющегося одновременно кино-
звездой и админисгратором, и содержать всю информацию о нем: имя, адрес, пол,
дата рождения, номер сертификата и размер чистого дохода. Такое отношение
кратко описывается выражением
MovieStar NATURAL JOIN MovieExec; □
5.9-5 Внешние соединения
Внешнее соединение — это один из вариантов соединения, предусмотренный
стандартом SQL2 для решения проблемы, связанной с определенными соединениями.
Допустим нужно вычислить соединение R И 5. Если кортеж г из А не соответствует
ни одному кортежу из S, он полностью исчезает из отношения Rtxi S. Такая ситуа-
ция вызывает немало проблем. Например, если данное соединение является пред-
ставлением и запрос относится к представлению об атрибутах, принадлежащих
только схеме отношения R, мы интуитивно предполагаем, что t войдет в результат
этого запроса. Но фактически t невозможно увидеть в представлении Rx 5, поэто-
му запрос к R может дать результат, отличающийся от результата такого же самого
запроса к
Внешнее соединение отличается от обычного ("внутреннего") тем, что оно
добавляет к результату любой кортеж любого из соединяемых отношений, который
не соединяется по крайней мере с одним кортежем другого отношения. Напомним
(см пример 4.6), что кортежи, которые не соединяются ни с одним кортежем дру-
гого отношения, называются висящими. Поскольку кортежи одного из соединяемых
отношений должны иметь все атрибуты обоих отношений, каждый висящий кор-
теж сначала пополняется значениями NULL для атрибутов, принадлежащих только
другому отношению, а затем вносится в результат.
Пример 5.50. Допустим, нужно выполнить соединение двух отношений:
MovieStar(name address, gender, birthdate)
MovieExec(name, address, cert#, netWorth)
и при этом сохранить информацию о людях, являющихся либо кинозвездами, либо
администраторами. В данном случае можно выполнить операцию SQL2 под назва-
нием "полное натуральное внешнее соединение", применив следующий синтаксис:
MovieStar NATURAL FULL OUTER JOIN MovieExec;
Результат такой операции — отношение с такой же шестиатрибутной схемой, как и
в примере 5.49. В него входят кортежи трех видов Люди, являющиеся одновремен-
но кинозвездами и администраторами, представлены кортежами со всеми шестью
атрибутами без значений NULL. Эти же кортежи входят в результат примера 5.49.
Второй вид кортежей представляет людей, являющихся кинозвездами, но не
администраторами. Значения атрибутов name, address, gender и birthdate этих
кортежей взяты из кортежа отношения MovieStar, а их атрибуты cert# и netWorth,
принадлежащие только отношению MovieExec, имеют значения NULL.
Третий вид кортежей представляет людей, являющихся администраторами, но
не кинозвездами. Для этих кортежей значения атрибутов MovieExec берутся из
кортежа отношения MovieExec, а их атрибуты gender и birthdate, принадлежащие
только отношению MovieStar, имеют значения NULL.
Три кортежа результирующего отношения, показанные на рис. 5.20, соответст
вуют перечисленным трем типам людей. □
254
П ава 5 Язык баз данных SQL
name address gender birthdate 1 cert# netWcrth
Mary Tyler Moore i Maple St Г 9/9/99 ; 12345 $100
Tom Hanks ' Cherry Ln. 8/8/88 I NULL NULL
George Lucas Oak Rd NULL NULL ! 23456 $200...
Рис, 5.20. Три кортежа внешнего соединения отношений MovieStar и MovieExec
В SQL2 доступно множество вариантов внешнего соединения. Кроме полного
внешнего соединения, при котором висяшие кортежи обоих отношений попол-
няются значениями NULL, применяется левое внешнее соединение, при котором
пополняются значениями NULL и вносятся в результат только кортежи левого
(первого) отношения. Например, выражение
MovieStar NATURAL LEFT OUTER JOIN MovieExec
дает только два первых кортежа отношения, изображенного на рис. 5.20.
Аналогично правое внешнее соединение пополняет значениями NULL и вклю-
чает в результат только кортежи правого (второго) отношения. Выражение
MovieStar NATURAL RIGHT OUTER JOIN MovieExec
дает только первый и третий кортежи отношения, изображенного на рис. 5 20.
Внешнее соединение варьируется и в зависимости от определения условия,
которому должны удовлетворять соответствующие друг другу кортежи. Вместо
ключевого слова NATURAL за соединением могут следовать слово ON и условие
для кортежей. Если задано также FULL OUTER JOIN, то после установления соот-
ветствия между кортежами соединяемых отношений висящие кортежи обоих отно
шений пополняются значениями NULL и включаются в результат.
Пример 5.51. Рассмотрим снова пример 5.47, в котором отношения Move
и StarsIN соединялись при условии, что атрибуты этих отношений title и moveTitle,
а также year и movieYear совпадают. Если изменить этот пример, введя в него
полное внешнее соединение
Movie FULL OUTER JOIN Starsln ON
title = movieTitle AND yaer = movieYear;
получатся кортежи только для фильмов, в которых снялась по крайней мере одна
из кинозвезд, упомянутых в Starsln, а кортежи для фильмов, для которых кинозвезды
не указаны, будут иметь значения NULL в атрибутах movieTitle, movieYear и starName.
Аналогично для кинозвезд, не участвующих ни в одном из фильмов, перечислен-
ных в отношении Movie, получится кортеж со значениями NULL в шести атрибутах
из Movie. □
В объединении из примера 5.51 ключевое слово FULL можно заменить на LEFT
или RIGHT. Например:
Movie LEFT OUTER JOIN Starsln ON
title = movieTitle AND year = movieYear.
позволяет получить кортежи отношения Movie, в которых указана хотя бы одна
кинозвезда, и кортежи Movie без кинозвезд, пополненные значениями NULL, но не
кортежи, в которых для кинозвезд не указаны фильмы
Напротив, соединение
Mov е RIGHT OUTER JOIN Starsln ON
title = movieTitie AND year = movieYear;
5.9 Пустые значения и внешние соединения
255
дает пополненные значениями NULL кортежи для кинозвезд, для которых не указа-
ны фильмы, и исключает кортежи для фильмов, для которых не указаны играющие
в них кинозвезды.
5-9-6 Упражнения к разделу 5-9
Упражнение 5.9.1. Для отношений из схемы БД фильмов
Starsln(movieTitle, movieYear, starName)
MovieStar(name, address, gender, birthdate)
MovieExec(name, address, cert#, netWorth)
Studio(name, address, presC#)
опишите кортежи, появляющиеся в следующих выражениях:
a) Studio CROSS JOIN MovieExec;
b) Starsin FULL NATURAL JOIN MovieStar;
c) Starsin FULL OUTER JOIN MovieStar ON name = starName;
! Упражнение 5.9.2. Используя схему БД
Product(maker, model, type)
PC(modei, speed, ram, hd, cd, price)
Laptop(model, speed, ram, hd, screen, price)
Pnnterfmodel, color, type, price)
напишите SQL-запрос, дающий информацию обо всех продуктах — ПК, ПК-блокно-
тах и принтерах,— включая их производителей, если они доступны, а также любую
информацию, относящуюся к конкретному продукту (т.е. содержащуюся в отноше-
нии, представляющем каждый продукт).
Упражнение 5.9.3. Используя отношения
Classes(class, type, country, numGuns, bore, displacement)
Ships(name, ciass, launched)
напишите SQL-запрос, дающий всю доступную информацию о кораблях, включая
информацию из отношения Classes Информация о классе не нужна, если в отно-
шении Ships нет кораблей этого класса.
Упражнение 5.9.4. Повторите упражнение 5.9.3, но теперь включите в резуль-
тат для любого класса С, не упомянутого в Ships, информацию о корабле, название
которого совпадает с именем класса С.
! Упражнение 5.9.5. В примере 5.46 рассматривался запрос
SELECT *
FROM Movie
WHERE length <= 120 OR length > 120
который дает интуитивно неожидаемый результат, когда продолжительность фильма
равна NULL. Найдите более простой запрос эквивалентный данному, с единствен-
ным условием в пункте WHERE (без AND или OR)
256
Глава 5 Язык баз данных SOL
! Упражнение 5.9.6. Рассмотренные в данном разделе операторы соединения
производны в том смысле, что их всегда можно заменить выражениями формы
select-from-where. Объясните, как записать в такой форме следующие выражения:
*а) R CROSS JOIN S;
b) R NATURAL JOIN S;
c) R JOIN S ON С, где С —условие SQL.
!! Упражнение 5.9.7. Операторы внешнего соединения тоже можно заменить
SQL-запросами, содержащими другие SQL-операторы. Покажите, как переписать
приведенные ниже вьражения с помощью явного применения операторов соедине-
ния и внешнего соединения.
a) R NATURAL LEFT OUTER JOIN S;
b) R NATURAL FULL OUTER JOIN S;
c) R FULL OUTER JOIN S ON С, где С — условие SQL;
5.10 Рекурсия в SQL
В этом разделе мы сосредоточимся на средстве SQL3 — рекурсивных запросах,
которые сейчас начинают появляться в коммерческих системах. В предыдущих
разделах этой главы рассматривались средства SQL2, имеющиеся почти во всех
коммерческих системах или аналогичные применяемым в них средствам. В то время
как стандарт SQL2 формально принят, описание рекурсивных запросов базируется
только на предвари 1ельном варианте стандарта SQL3.
Подход SQL3 к рекурсии основан на рекурсивных правилах Datalog, рассмот-
ренных в разделе 4.4, но предполагает их различные модификации. Во-первых,
стандарт SQL3 допускает только линейную рекурсию, т.е. правила не более чем
с одной рекурсивной подцелью. Во-вторых, требование стратификации для опера-
тора отрицания, рассмотренное в разделе 4.4.4, относится и к другим SQL-операто-
рам, способным вызвать аналогичные проблемы, например к оператору агрегации.
5-10.1 Определение отношений IDB в SQL
В разделе 4.4 была объяснена разница между отношениями EDB, валяющимися
хранимыми таблицами, и отношениями IDB, которые определяются правилами
Datalog. В SQL3 есть оператор, вводимый ключевым словом WITH и позволяющий
определять эквиваленты отношений IDB. Такие определения затем можно приме-
нять внутри самого выражения с WITH. Простая форма выражения с WITH:
WITH Я AS ^определение Я> <запрос, содержащий Я>
Оно определяет временное отношение Я, а затем использует его в запросе.
В общем случае после WITH можно определить несколько отношений, разделив их
определения запятыми, и любое из этих определений может быть рекурсивным.
Определяемые отношения могут быть взаимно рекурсивными, т.е. каждое из них
может определяться в терминах других отношений, возможно, включая и себя
самого. Каждому включенному в рекурсию отношению должно предшествовать
ключевое слово RECURSIVE. Итак, выражение с WITH включает в себя следующие
компоненты:
I. Ключевое слово WITH.
2. Одно или несколько определений, разделенных запятыми.
Каждое определение состоит из следующих частей:
(а) ключевого слова RECURSIVE, которое необходимо только тогда, когда
отношение определяется рекурсивно;
5.10 Рекурсия в SQL
257
(b) имени определяемого отношения,
(с) ключевого слова AS;
(d) запроса, определяющего отношение.
з. Запрос, относящийся к любому из предшествующих определений
и формирующий результат выражения WITH.
Важно учесть, что, в отличие от других определений отношений, определения,
стоящие внутри предложения с WITH, доступны только в этом предложении и не
применяются больше нигде. Если необходимо постоянное отношение, его нужно
определить в схеме БД вне предложения WITH.
Пример 5.52. Обратимся к информации об авиарейсах, приведенной в примере
раздела 4.4. Данные о полетах самолетов содержатся в отношении8
Flights(airllne, frm, to, departs, arrives)
Реальные данные этого примера воспроизведены на рис. 5.21.
Рис. 5.21. Рейсы самолетов (копия рис. 4.19)
В примере 4.37 вычислялось множество пар городов; из одного из них можно
попасть во второй с помощью рейсов, представленных на рис. 5.21. Там IDB отно-
шение Flights, содержащее нужную информацию, вычислялось с использованием
правил
1. Reaches(x у) <- Flights(a, х, у, d, г)
2. Reaches(x, у)«- Reaches(x, z) AND Reaches(z, у)
Из этих правил можно построить SQL-определение отношения Reaches. SQL-
запрос становится определением этого отношения в предложении WITH, которое
завершается искомым запросом В примере 4.37 результатом было все отношение
Reaches, но и к нему может быть адресован запрос, например о городах, в которые
можно попасть из Денвера.
На рис. 5.22 показано, как отношение Reaches вычисляется в виде запроса SQL3.’
в Имя второго атрибута заменено на frm. так как from — ключевое слово SQL.
» По некоторым техническим причинам стандарт SQL3 требует, чтобы СУБД поддерживала
только линейную рекурсию, при которой пункт FROM определяющего рекурсивное
отношение запроса содержит только одно рекурсивное отношение. В строке (5)
на рис. 5.22 содержатся два применения рекурсивного отношения Raaches. Однако
этот запрос больше всего похож на пример 4.37 и, по-видимому, является наиболее
естественным В такой форме он может поддерживаться или не поддерживаться СУБД,
реализующей SOL3.________________________ - ------
258
Глава 5 Язык баз данных SQL
1) WITH RECURSIVE Reaches(frm to) AS
2) (SELECT frm, to FROM Flights)
3) UNION
4) (SELECT R1.frm_.R2.to
5) FROM Reaches AS R1, Reaches AS R2
6) WHERE R1 .to = R2.frm)
7) SELECT ‘ FROM Raaches.
Рис. 5.22. Вопрос яэыно SQL3 о порох городов, связанных авиалиниями
Строка (1) лишь вводит определение Reaches а реальное определение этого
отношения находится на строках (2) — (6) Оно состоит из объединения двух
запросов, соответствующих двум правилам, с помощью которых Reaches было
определено в примере 4.37. Строка (2) соответствует первому (базисному) правилу
и означает, что второй и третий компоненты (frm и to) каждого кортежа отношения
Fights являются кортежем отношения Reaches.
Строки (4) — (6) соответствуют второму (индуктивному) правилу в определении
Reaches. Две подцели Reaches представлены в пункте FROM двумя псевдонимами
отношения Reaches — R1 и R2. Первый компонент R1 соответствует х, а второй
компонент R2 соответствует у в правиле (2). Переменная z представлена и вторым
компонентом R1, и первым компонентом R2: на строке (6) эти компоненты при-
равниваются.
И наконец, строка (7) описывает отношение, которое порождается запросом
в целом и является копией отношения Reaches. Эту строку можно заменить более
сложным запросом, например:
7) SELECT to
FROM Reaches
WHERE frm ='DEN';
Этот запрос определяет все города, достижимые из Денвера. □
Взаимная рекурсия
Проверить, являются ли два отношения или предиката взаимно рекурсив-
ными можно с помощью теории графов. Построим граф зависимостей, узлы
| которого соответствуют отношениям (или предикатам в правилах Datalog).
( Проведем ориентированное ребро от отношения А к отношению В, если опре-
t деление В непосредственно зависит от определения А, т.е. при применении
I Datalog предикат В входит в голову правила, в теле которого содержится А
! В SQL А входит в определение В, обычно в предложение FROM или же
в качестве терма объединения, пересечения или разности.
Если есть цикл, содержащий узлы А и 5, значит, Л и S’ взаимно рекурсивны.
Наиболее распространенный случай — это петля из А в А, означающая, что А
f рекурсивно зависит от самого себя.
Заметим что граф зависимостей похож на граф, введенный в разделе 4.4.4
для определения стратифицированного отрицания Однако там проводилось
|! различие между позитивной и негативной зависимостями, которое здесь не
t требуется.
5.10 Рекурсия в SQL
259
5.10.2 Линейная рекурсия
В примере 5.22 упоминался технический изъян, связанный с тем, что по стан-
дарту SQL3 поддерживается только линейная рекурсия Формально рекурсия линей-
на, если предложение FROM для любого определяемого отношения содержит не
более одного вхождения отношения, которое взаимно рекурсивно с определяемым
отношением. Чаше всего определяемое отношение само появляется в предложении
FROM, но возможно также, что там появится и другое отношение, взаимно рекур-
сивное с определяемым.
Пример 5.53. Интересно, что программу, представленную на рис. 5.22, можно
выразить простой заменой любого из применений Reaches в строке (5) на Fi ghts.
При этом рекурсия примет форму одного из правил правой или левой рекурсии,
введенных в заключенном в рамку тексте раздела 4 4.3. Другой способ состоит
в определении дополнительного отношения Pairs в предложении WITH Это отно-
шение представляет проекцию Flights на компоненты frm и to, используется в обеих
частях объединения.
Рис. 5.23 — новый вариант рис. 5.22. Здесь выбрано определение с правой ре-
курсией, но, поменяв местами Pairs и Reaches, можно выполнить и левую рекурсию.
1) WITH
2) Pairs AS SELECT frm, to FROM Flights,
3) RECURSIVE Reachesffrm, to) AS
4) Pairs
5) UNION
6) (SELECT Pairs.frm, Reaches.to
7) FROM' Pairs, Reaches
8) WHERE Pairs.to = Reaches.frm)
9) SELECT * FROM Reaches;
Рис. 5.23. Запрос с линейной рекурсией о парах городов, связанных авиалиниями
Заметим, что для SQL-запросов, подобных этому, можно применять описанное
в разделе 4 4.2 итеративное вычисление фиксированной точки точно так же, как
для правил Datalog. Поскольку рекурсия линейна, факты, содержащиеся в Reaches,
можно искать в каком-то другом порядке, но в конечном счете будут найдены все
пары городов (х, у), когда из х можно долететь до у.
Рассмотрим первый шаг вычислений на нашем примере данных. Поскольку
Reaches изначально пусто, только первый терм объединения — Pairs на строке (4) —
составляет основу пар городов согласно схеме 5.21. На втором шаге из Ра rs
и Reaches берется по одному транзитному участку и получаются пары транзитных
участков, такие как (SF, CHI). На следующем этапе из Reaches получаются также
двойные транзитные участки и больше нельзя добавить никаких пар. В общем
случае на /-м шаге получаются все такие пары (х, у), что наикратчайший маршрут
от х к у состоит из / ориентированных ребер. □
5.10.3 Применение представлений
в выражениях с WITH
Представления, как и таблицы, можно применять в выражениях с WITH. Един-
ственное синтаксическое различие — применение ключевого слова VIEW в опреде-
лении отношения.
260
Глава 5 Язык баз данных SQL
Пример 5,54. Отношение Pairs на строке (2) рис. 5.23 можно определить как
представление Для этого строка (2) записывается в следующем виде
2)
VIEW Pairs AS SELECT frm, to FROM Flights
В данном случае есть определенные причины для того, чтобы сделать Pairs именно
представлением. Если Pairs — настоящее отношение, оно будет впервые построено
полностью при выполнении предложения WITH, независимо от его применения
в начале построения отношения Reaches на строке (4). Если же Pairs — представ-
ление, его использование в построении Reaches можно заменить применением
компонентов кортежей из Flights. □
5-10 4 Стратифицированное отрицание
Запросы, которые могут быть определениями рекурсивного отношения, не
могут быгь SQL-запросами произвольной формы. Они должны удовлетворять
различным ограничениям. Одно из наиболее важных таких ограничений заключается
в том, что отрицание взаимно рекурсивных отношений должно быть стратифици-
ровано в смысле, определенном в разделе 4.4.4. В разделе 5.10.5 будет показано, как
принцип стратификации распространяется на другие когструкнии SQL, но не на
конструкции Datalog или реляционной алгебры.
Пример 5.55. Вернемся к примеру 4.39, в котором мы искали такие пары
городов (х, у), чтобы из .V в у можно было перелететь рейсом UA. но не АА. Для
выражения перелета через неопределенное число транзитных участков необходима
рекурсия, а отрицание принимает стратифицированную форму: после применения
рекурсии для вычисления отношений UAreaches и AAreaches из примера 4,39
вычисляется их разность.
Такой же ме од применим и для записи запроса в SQL3 но тогда нелинейную
рекурсию нужно заменить правой или левой линейной рекурсией как показано
в примере 5 53. Для иллюстрации другого способа действий в данном примере
рекурсивно определим единственное отношение Reaches(airline, frm, to), кортежи
которого (а,у; /) означают, что из города f можно перелететь в город Г, возможно,
через несколько транзитных участков но только рейсами авиалинии а. Мы исполь-
зуем также отношение Triples(airiine, frm, to), являющееся проекцией Flights на три
релевантных компонента. Составленный таким способом запрос показан на рис. 5.24.
1) WITH
2) Тriples AS SELECT airline, frm, to FROM F ights.
3) RECURSIVE Reaches(airline, frm, to) AS
4) Triples
5) UNION
6) (SELECT Triples airline, Triples.frm, Reaches.to
7) FROM Triples, Reaches
8) WHERE Triples.to = Reaches.frm AND
9) Triples airline - Reaches.airline
)
10) (SELECT frm to FROM Reaches WHERE airline = UA')
11) EXCEPT
12) (SELECT frm, to FROM Reaches WHERE airline = 'AA');
Put. 5.24. Стратифицированный запрос с городах, достижимых с помощью одной из двух
авиалинии
5,10 Рекурсия в SQL 261
Определение отношения Reaches на строках (3) — (9) — это объединение двух
термов. Базовый терм — это отношение Tripes на строке (4), а индуктивный
терм —запрос на строках (6)- (9), порождающий объединение отношений Tripes
и Reaches В результате объединения этих термов в Reaches попадают все такие
кортежи (а,/, /), что из города J можно перелететь в город /; может быть, даже через
несколько транзитных участков, но только рейсами авиалинии а.
Основной запрос сформулирован на строках (10) — (12). Строка (10) дает пары
городов, достижимых с помощью UA, а строка (12) —пары городов, достижимых
с помощью АА Общий результат запроса — разность между двумя этими отноше-
ниями. □
Пример 5.56. На рис. 5.24 отрицание, выраженное словом EXCEPT на строке (11),
явно стратифицировано, так как применяется только после завершения рекурсии
на строках (3) — (9). Нестратифииированное применение отрицания из примера 4.40
тоже можно перевести в применение EXCEPT в определении рекурсивного отноше-
ния. Результат такого прямого перевода в запрос языка SQL3 показан на рис. 5.25
Этот запрос касается значения Р, но можно запросить и значение Q или некоторой
функции от Р и Q.
1) WTH
2) RECURSIVE Р(х) AS
3) (SELECT * FROM R)
4) EXCEPT
5) (SELECT * FROM Q)
6) RECURSIVE Q(x) AS
7) (SELECT * FROM R)
8) EXCEPT
9) (SELECT * FROM P)
10) SELECT * FROM P,
Рис. 5.25. Недопустимый e SQL3 ^стратифицированный запрос
Два применения EXCEPT на строках (4) и (8) рис. 5.25 недопустимы в SQL3,
так как в каждом случае второй аргумент —это отношение, которое взаимно
рекурсивно с определяемым отношением. Оба эти применения отрицания не стра-
тифицированы и потому запрещены Фактически здесь не может быть верного
решения вопроса с помощью SQL3, так как показанная на рис. 5.25 рекурсия на
самом деле не определяет значений отношений Р и Q. □
5.10.5 Выражения рекурсивного SQL3,
вызывающие проблемы
В примере 5 56 было показано, что применение EXCEPT в рекурсивном опреде-
лении нарушает требование SQL3 о стратификации отрицания. Существуют и другие
неприемлемые формы запросов, в которых EXCEPT не применяется.10 Например,
•^Технически нелинейная рекурсия даже без отрицания недопустима в SQL3, хотя
в документации по этому языку предло агается, что такая рекурсия появится в SQL4.
Однако здесь мы рассматриваем бессмысленные или парадоксальные формы рекурсии,
кот^^^^рос
262
Глава 5 Язык баз данных SQL
отрицание отношения можно выразить с помощью оператора NOT IN Тогда стро-
ки (2) — (5) рис. 5 25 можно записать в следующей форме:
RECURSIVE Р(х) AS
SELECT х FROM R WHERE x NOT IN Q
При гаком преобразовании рекурсии остается нестратпфицированной и, следо-
вательно, недопустимой. Но если просто применить NOT в пункте WHERE, внеся
в мето, например, выражение NOT х = у (эквивалентное х<>у), автоматического
нарушения условия о стратификации отрицания не произойдет. Существует ли
общее правило отбора видов SQL-запросов, которые можно применять для опреде-
ления рекурсивных отношений в SQL3?
Для того чтобы быть рекурсией, допустимой в SQL3, определение рекурсивного
отношения R должно содержать применение взаимно рекурсивного отношения S
(S может совпадать с А), если такое применение является монотонным. Применение S
монотонно, если добавление произвольного кортежа к S способно привести
к добавлению одного или нескольких кортежей к R или оставить R неизменным,
но никогда не приводит к удалению кортежа из R.
Это правило применимо при вычислении наименьшей фиксированной точки,
о которой шла речь в разделе 4.4.2. Вычисление начинается с пустых, рекурсивно
определяемых отношений IDB, к которым на последующих этапах последовательно
добавляются кортежи. Если добавление кортежа на одном этапе может вызвать
удаление кортежа на следующем, возникает риск колебаний и вычисление может
никогда не закончиться. В приведенных ниже примерах представлены немонотон-
ные конструкции, не допустимые в рекурсии SQL3.
Пример 5.57. Рис. 5.25 — это реализация правил Datalog из примера 4.40
иллюстрирующая нестратифицированное отрицание. Эти правила допускают две
различные фиксированные точки. Определения Р и Q немонотонны. В определе-
нии Р на строках (2) — (5) Р зависит от С, с которым оно взаимно рекурсивно, но
добавление кортежа к Q может привести к удалению кортежа из Р. Чтобы показать
это, предположим, что R состоит из кортежей (а) и (b), a Q— из кортежей (а) и (с).
Тогда Р={(Ь)}. Однако при добавлении (Ь) к Q отношение Р становится пустым.
Добавление кортежа привело к удалению кортежа, значит, данная конструкция
немонотонна и некорректна.
Утрата монотонности ведет к возникновению колебаний при оценке отноше-
ний Р и Q путем вычисления минимальной фиксированной точки.11 Пусть, напри-
мер, R имеет кортежи {(а), (А)}. Отношения Рн Q первоначально пусты. Значит, на
первом шаге строки (3) — (5) рис. 5.25 дают значение Р, равное {(а), (Ь)}. Согласно
строкам (7) — (9), Q имеет точно такое же значение, поскольку на строке (9) ис-
пользуется старое пустое значение Р
Теперь R, Р и Q имеют значение {(о), (6)}. Поэтому на втором шаге в строках
под номерами (3) — (5) и (7) — (9) будут вычислены пустые значения Р и Q
соответственно, а это значит, что на третьем шаге оба они снова получат значение
{(д). (/>)} Этот процесс длится бесконечно, и на каждом его четном шаге отношения
пусты, а на каждом нечетном имеют значение {(а), (£)} Следовательно, из "определе-
ний" рис. 5.25 невозможно получить ясные значения отношений Р и Q. □
11 При немонотонной рекурсии порядок оценки отношений в пункте WITH влияет
на конечный результат, а при монотонной рекурсии он не зависит от порядка
В этом и с следующем примерах предполагается, что на Каждом этапе Р и Q
оцениваются "параллельно": старое значение каждого отношения используется
для вычисления другого значения на каждом этапе.
5,10 Рекурсия в SQL
263
Пример 5 58 Агрегация тоже иногда приводит к немонотонности, хотя связь
между ними может быть неочевидной. Предположим, унарные (одноатрибутные)
отношения Р и Q определяются следующими условиями
1. Р есть объединение Q с EDB-отношением R
2. Q имеет один кортеж, являющийся суммой членов Р
Эти условия можно выразить с помощью оператора WTH, но при этом будет нару-
шено требование монотонности SQL3. Запрос на рис. 5.26 относится к значению Р.
1) WITH
2) RECURSIVE Р(х) AS
3) (SELECT ‘ FROM R)
4) UNION
5) (SELECT * FROM Q)
6) RECURSIVE Q(x) AS
7) SELECT SUM(x) FROM P
8) SELECT * FROM P;
Рис- 5.26 Нвдопустимьй в SQL3 нестротифицироеанный запрос с агрегацией
Пусть R состоит из кортежей (12) и (34), a Р и Q пусты, как и должно быть
в начале вычисления фиксированной точки. На рис. 5.27 показан результат вычис-
ления значений на первых шести шагах.
Round Р Q
D {(12), (34)} 0
2) {(12), (34)} «46)}
3) {(12), (34). (46)} {(46)}
4) {(12), (34). (46)} {(92)}
5) {(12), (34). (92)} «92)}
6) {(12), (34). (92)} {(148)}
Рис 5 27. Итеративное вычисление фиксированной точки для немонотонной агрегации
Напомним, что значения всех отношений на каждом шаге вычисляются из
значений, полученных на предыдущем шаге. Значит, на первом шаге значения Р и R
совпадают, a Q пусто, поскольку старое пустое значение Р используется на строке (7).
На втором шаге новым значением Р становится объединение строк (3) — (5).
т.е. R = {(12), (34)}. Старое значение А было таким же, как и новое, значит, на этом
шаге Q= {(46)} — это сумма 12 и 34.
На третьем шаге из строк (2) (5) получается Р— {(12), (34), (46)}. На основе
старого значения Р, {(12), (34)}, на строках (6) — (7) значение Q снова определяется
как {(46)}.
На четвертом шаге Р имеет прежнее значение {(12), (34), (46)}, a Q получает
значение {(92)}, поскольку 12 + 34 + 46 92. Заметим, что из Q исчез кортеж (46),
хотя и появился кортеж (92) Иными словами, добавление к Р кортежа (46) привело
к удалению (случайно того же самого) кортежа из Q. Такая немонотонность, запре-
щенная в рекурсивных определениях SQL3, означает что запрос рис 5.26 не
допустим. В общем случае на 2/-м шаге Р будет состоять из кортежей (12), (34) и
(46/ — 46), а Столько из кортежа (46/). □
264
Глава 5 Язык баз данных SQL
Применение новых значений
в вычислениях фиксированной точки
В примерах 5.57 и 5.58 при вычислении значения Q применялись старые,
а не новые значения Р. Результат вычисления зависел от порядка определений
рекурсивных предикатов в предложении WITH. В примере 5.57 Р и Q сходились
к одной из двух возможных фиксированных точек в зависимости от порядка
оценки. В примере 5.58 они не сходились и фактически изменялись на каждом
шаге вычислений.
5.10.6 Упражнения к разделу 5.Ю
Упражнение 5.10.1. В примере 4.36 рассматривалось отношение
SequelOffmovie, sequel)
дающее непосредственное продолжение фильма, и было определено JDB-отношение
FollowOn; его парами (х. у) были такие фильмы, у которых у являлся продолжением х
или продолжением его продолжения и т.д.
а) Запишите определение отношения FollowOn в форме рекурсии SQL3.
Ь) Запишите рекурсивный запрос на SQL3, возвращающий множество пар (х, у),
в которых у являлся бы последователем фильма х, но не его непосредст-
венным продолжением.
с) Запишите рекурсивный запрос на SQL3, возвращающий множество пар (х,у),
в которых у являлся бы последователем фильма х, но при этом не был ни
его продолжением, ни продолжением его продолжения.
! d) Запишите рекурсивный запрос на SQL3, возвращающий множество филь-
мов х, имеющих по крайней мере двух последователей Оба они могут
быть самостоятельными продолжениями х и необязательно, чтобы один
был продолжением х, а другой продолжением продолжения.
!е) Запишите рекурсивный запрос на SQL3 возвращающий множество пар (х, у),
в которых у — последователь фильма х, имеющий не более одного после-
дователя.
Упражнение 5.10.2. В упражнении 4.4.3 введено отношение
Rel(class,eclass, multi)
описывающее взаимосвязи классов ODL. Оно содержит кортеж (с, d, ns) если класс с
связан с классом <1. Такая связь многозначна, если т = 'multi', и однозначна, если
т = 'single'. В упражнении 4.4.3 было сказано, что отношение Rel можно опреде-
лить с помощью графа, узлами которого являются классы и в котором есть ребро
направленное от с к d и помеченное буквой т, если и только если (с, d. т) — кор-
теж Rel.
а) Запишите рекурсивный запрос на SQL3. порождающий такое множество
пар (с, d), чтобы в описанном выше графе был путь от класса с к классу d.
•b) Запишите рекурсивный запрос на SQL3, порождающий такое множество
пар (с, г/), чтобы в описанном выше графе был путь от класса с к классу d,
на котором каждое ребро помечено как single
5.11 Итоги
265
•• с) Запишите рекурсивный запрос на SQL3, порождающий такое множество
пар (с, d), чтобы в описанном выше графе был путь от класса с к классу d,
на котором по меньшей мере одно ребро помечено как multi.
d) Запишите рекурсивный запрос на SQL3, порождающий такое множество
пар (с, d), чтобы в описанном выше графе был путь от класса с к классу d.
но не было пути, на котором все ребра помечены как singe
!е) Запишите рекурсивный запрос на SQL3, порождающий такое множество
пар (с, d), чтобы в описанном выше графе был путь от класса с к классу d,
на котором ребра single чередуются с ребрами multi.
f) Запишите рекурсивный запрос на SQL3, порождающий такое множество
пар (с, d), чтобы в описанном выше графе были пути от класса с к классу d
и от класса d к классу с, на которых каждое ребро помечено как single
Упражнение 5.10.3. Допустим, мы изменили вычисление Reaches на рис. 5.23,
чтобы применить нелинейную рекурсию. А именно: строки (6) — (8) заменены
строками
6) (SELECT First.frm, Second.to
7) FROM Reaches AS First, Reaches AS Second
8) WHERE First to = Second.frm)
в которых два экземпляра отношения Reaches, представленные переменными
кортежей First и Second, объединяются для получения новых пар. Какую длину
имеют новые пути, добавляемые к Reaches на r-м шаге вычисления фиксированной
точки?
5.11 Итоги
+ SQL — главный язык запросов систем реляционных БД. Его стандарт, оказы-
вающий наиболее сильное влияние на коммерческие системы, называется
SQL2. Предполагается, что в ближайшее время будет завершен его новый
стандарт — SQL3.
> Запросы типа select from-where — наиболее распространенная форма SQL
запросов, позволяющая получать произведение нескольких отношений
(предложение FROM), применять к кортежам результата заданное условие
(пункт WHERE) и создавать нужные компоненты (предложение SELECT)
+ Подзапросы. Запросы типа select-from-where можно применять в качестве
подзапросов в предложении WHERE другого запроса Для выражения буле-
возначных условий для отношений, являющихся результатом запроса, при-
меняются операторы EXISTS, IN, ALL и ANY.
+ Теоретико-множественные операции на отношениях. Объединение, пересече-
ние и разность отношений или запросов, определяющих отношения, прово
дится с помощью ключевых слов UNION INTERSECT и EXCEPT.
4- Мультимножественная модель отношений. Реальные отношения в SQL счита-
ются мультимножествами, а не множествами Удаление дублирующихся
кортежей проводится с помощью ключевого слова DISTINCT, а ключевое
слово ALL позволяет получить результат в виде мультимножества там, где
мультимножества не приняты по умолчанию.
266
Глава 5 Язык баз данных SQL
♦ Агрегация. Значения столбцов отношения можно объединять (агрегировать)
с помощью ключевых слов SUM, AVG (среднее значение) MIN, МАХ или
COUNT. Перед агрегацией кортежи разбиваются на группы посредством клю-
чевого слова GROUP BY. Определенные группы можно удалить с помощью
предложения начинающегося ключевым словом HAVING.
+ Операции изменения. SQL позволяет изменять кортежи отношения с помощью
предложений начинающихся одним из ключевых слов: INSERT (добавить
новые кортежи), DELETE (удалить кортежи) или UPDATE (изменить некото-
рые существующие кортежи).
♦ Определение данных. В SQL есть операторы для описания элементов схемы
БД. CREATE TABLE позволяет описать схему хранимых отношений (таблиц)
путем определения атрибутов и их типов. CREATE DOMAIN используется для
определения имени типа данных, которое затем можно применять в описа-
ниях реляционных схем. Эти два оператора CREATE позволяют также зада-
вать значения по умолчанию для атрибутов и областей.
♦ Изменении схем. Различные аспекты схемы БД можно изменять с помощью
оператора ALTER. Эти изменения включают в себя удаление атрибутов из
реляционных схем и изменение значения по умолчанию, связанного с атри-
бутом илн областью. Для полного удаления отношений, областей или других
элементов схемы применяется оператор DROP.
♦ Индексы. Хотя это и не предусмотрено стандартом SQL, коммерческие систе-
мы SQL позволяют задавать на атрибутах индексы, ускоряющие выполнение
определенных запросов, или выполнять изменения, включающие в себя
определение значения индексированного атрибута.
♦ Представления — определения, показывающие, как из таблиц, хранимых в БД.
построить отношение (представление). К представлениям можно адресовать
запросы, как к таблицам, и система SQL изменяет запрос к представлению
так, что он действительно относится к таблицам, использованным для опре-
деления этого представления.
♦ Значение NULL — особое значение в SQL, появляющееся в компонентах кор-
тежей, для которых недоступно никакое конкретное значение. Арифметика
и логика NULL необычны. Сравнение с NULL любого значения даже другого
NULL, дает значение UNKNOWN, которое применяется в булевозначных вы-
ражениях как нечто среднее между TRUE и FALSE.
♦ Выражения соединения В SQL есть операторы типа NATURAL JOIN, примени-
мые к отношениям либо в качестве запросов, либо для определения отноше-
ний в предложении FROM.
♦ Внешнее соединение. В SQL есть оператор OUTER JOIN, который соединяет
отношения, но при этом вносит в результат висящие кортежи из одного
или обоих этих отношений. В результирующем отношении висящие кортежи
пополняются значениями NULL.
+ Рекурсия в SQL3. По стандарту SQL3 предполагается рекурсивный способ
определения временных отношений и их использования в запросах. Соглас-
но этому стандарту включенные в рекурсию отрицание и агрегация должны
быть стратифицированы, т.е. рекурсивно определяемое отношение не должно
определяться в терминах своих собственных отрицания или агрегации.
5.12 Литература к главе 5
267
5.12 Литература к главе 5
Электронные версии стандартов SQL2 и SQL3 можно получить через Нацио-
нальный институт науки и техники (NIST, бывшее Национальное бюро стандартов)
по анонимному FTP или по HTTP. Имя хост-узла: speckle.ncsl nist.gov. Стандарт
SQL2 и текущие версии SQL3 находятся в каталоге
isowg3/dbl/BAS Edocs
Особый интерес представляет формальный синтаксис SQL2, представленный в файле
isowg3/dbI/BASEdocs/sql-92.bnf
Каталог isowg3/x3h2 содержит множество работ и исторических документов
по стандартам SQL2 и SQL3. Все они имеют номера, начинающиеся с ХЗН2, Для
доступа к документам SQL с помощью HTTP используйте URL:
http://speckle.ncsl.nist gov/~ftp/
за которым следует путь одного из указанных выше каталогов.
Деталям программирования SQL посвяшено множество книг. Мы предпочитаем,
например, работы [2], [3] и [6].
Первое or ределение SQL дано в книге [4]. В работе [1] он был реализован
как часть системы R — одного из прототипов реляционной БД первого поколения.
Материал по рекурсии SQL3 можно найти в источнике [5].
1. Astrahan, М. М. et al., "System R: a relational approach to data management,"
ACM Transactions on Database Systems 1'2, pp. 97 — 137, 1976.
2. Celko, J., SQL for Smarties, Morgan Kaufmann, San Francisco, 1995.
3. Date, C. J and H. Darwen, A Guide to the SQL Standard, Addison-Wesley,
Reading, MA, 1993.
4. Chamberlin, D. D., et al., “SEQUEL 2: a unified approach to data definition,
manipulation and control", IBM Journal of Research and Development 20:6,
pp. 560 - 575, 1976.
5. Finkelstein, S. J., N. Mattos, I. S. Mumick, and H. Pirahesh, "Expressing
recursive queries in SQL," ISO WG3 report X3H2-96-075, March, 1996
6. Melton, J. and A. R. Simon, Understanding the New SQL: A Complete Guide,
Morgan Kaufmann, San Francisco, 1993.
Глава 6
Ограничения и триггеры
в SQL
Эта глава посвящена аспектам SQL, позволяющим создавать "активные"
элементы. Активный элемент—это выражение или оператор, которые создаются,
хранятся в БД и выполняются в нужные моменты, например при вставке данных
в определенные таблицы или при изменении БД так, что становится истинным
какое-то булевозначное условие.
Одной из серьезных проблем, с которыми сталкиваются создатели приложений
по обновлению БД. является то, что новая информация может быть неправильной
по многим параметром. Самый простой способ предотвратить появление в отноше-
ниях неприемлемых кортежей в результате изменений БД — создание программ
приложений, в которых команды вставки, удаления и обновления связаны с про-
верками, обеспечивающими корректность Однако это не лучший путь, поскольку
требования корректности зачастую очень сложны и всегда повторяемы; после каж-
дого изменения программа вынуждена проводить одни и те же тесты.
В SQL2 существуют различные способы выражения ограничений целостности
в качестве части схемы БД. В этой главе рассматриваются основные из них, и в пер-
вую очередь ограничение по ключу, при котором атрибут или множество атрибутов
объявляются ключом отношения. Затем мы перейдем к требованию ссылочной цело-
стности, согласно которому значение атрибута илн атрибутов одного отношения
(например, presC# в Studio) должно быть также значением атрибута или атрибутов
другого отношения (например, cert# в MovieExec) После этого будут рассмотрены
ограничения на области, включая уникальность ("возможность ключа ), ограничение
по конкретным значениям и запрещение NULL, а также ограничения на кортежи
и отношения в целом и ограничения на взаимосвязи, называемые утверждениями.
Эти ограничения проверяются при каждом изменении отношения или отношений.
И наконец, будут рассмотрены триггеры, которые тоже являются активными
элементами и вводятся в действие при определенных событиях. Их нет в стандарте
SQL2. ио они включены в SQL3, и хотя на момент написания этой книги SQL3 не
является завершенным стандартом, многие коммерческие системы БД предлагают
пользователям какую-нибудь форму триггера.
6.1 Ключи в SQL
Возможно, самым важным видом ограничений в БД является объявление атри-
бута или атрибутов ключом отношения. Другими словами, два кортежа отношений
не могут совпадать по атрибуту, объявленному ключом, или по всему множеству
атрибутов формирующих ключ Ограничение по ключу, подобно многим другим
6.1 Ключи в SQL
269
ограничениям .SQL, определяется в команде CREATE TABLE. Есть два сходных спо-
соба определения ключей: с помощью ключевых слов PR MARY KEY и с помощью
UNIQUE. Таблица может иметь любое число ключей типа unique, но первичньй
ключ только один.
6.1.1 Определение ключей
Первичный ключ состоит из одного и более атрибутов отношения. Существует
два способа объявления первичного ключа в команде CREATE TABLE, определяю-
щей хранимую таблицу.
1. Атрибут объявляется первичным ключом при его перечислении в реляци-
онной схеме.
2. К списку элементов схемы (которые до этого были только атрибутами)
добавляется предложение, означающее, что отдельный атрибут или мно-
жество атрибутов являются первичным ключом.
В первом случае после атрибута и его типа ставятся ключевые слова PRIMARY
KEY. Во втором случае в список атрибутов вводится новый элемент, состоящий из
ключевых слов PRIMARY KEY и заключенного в скобки списка атрибутов, форми-
рующих ключ. Если ключ состоит более чем из одного атрибута, применяется толь-
ко второй способ.
Пример 6.1. Обратимся снова к схеме отношения MovieStar из примера 5.32.
Первичный ключ этого отношения — name. Значит, указание на этот факт нужно
внести в строку, в которой находится name. Такое изменение рис. 5.13 показано на
рис. 6.1.
1) CREATE TABLE MovieStar (
2) name CHAR(30) PRIMARY KEY,
3) address VARCHAR(255),
4) gender CHAR(1),
5) birthdate DATE
);
Рис. 6.1. Превращение name в первичньй ключ
Псрви'ный ключ можно определить по-другому. После строки (5) на рис. 5.13
отдельно указывается первичный ключ и строку (2) изменять не нужно. Результат
показан на рис. 6.2. □
1) CREATE TABLE MovieStar (
2) name CHAR(30),
3) address VARCHAR(255),
4) gender CHAR(1),
5) birthdate DATE,
6) PRIMARY KEY (name)
):
Pnc. 6.2. Отдельное указание первичного ключа
270
Глава 6 Ограничения и триггеры в SQL
Заметим, что и примере 6.1 допустим любой из этих способов, так как первичный
ключ — единственный атрибут. Но когда первичный ключ содержит бо iec одного
атрибута, необходимо применять способ, показанный на рис. 6.2. Например, ключом
отношения Movie является пара атрибутов title и year и при определении схемы
этого отношения после списка атрибутов нужно ввести отдельную строку:
PRIMARY KEY (title, year)
Ключ определяется и с помощью ключевого слова UNIQUE, которое может
стоять там же, где и слова PRIMARY KEY: либо за атрибутом и его типом, либо
в отдельной строке команды CREATE TABLE Оно имеет такое же значение, как
и определение первичного ключа, но определений UNIQUE может быть сколько
угодно, а первичный ключ только один.
Пример 6.2. Строку (2) рис. 6.1 можно заменить строкой
2) name CHAR(30) UNIQUE.
а строку (3) строкой
3) address VARCHAR(255) UNIQUE,
если считать, что две кинозвезды не могут иметь один и тот же адрес (сомнитель-
ное допущение). Аналогичным образом строку (6) рис. 6.2 при желании можно
заменить на
6) UNIQUE (name) □
Ограничение по ключу — это ограничение, введенное с помощью PRIMARY KEY
или UNIQUE.
Первичные ключи и уникальные атрибуты
Описания с помощью PRIMARY KEY и UNIQUE — почти синонимы Раз
ница между ними в том, что таблица может иметь единственный первичный
|ключ и произвольное множество атрибутов или множеств атрибутов типа
UNIQUE. Однако есть между ними и более мелкие различия.
I. Внешний ключ может ссылаться только на первичный ключ отношения.
2. Реализация системы управления БД может приписывать "первичному
ключу" особый смысл, не предусмотренный стандартом SQL2. Напри-
1мер. СУБД всегда может помешать индекс (как было показано в раз-
деле 6.1.2) на первичном ключе (даже если он состоит из нескольких
| атрибутов), но при этом требовать, чтобы пользователь явно вызывал
индекс совсем на других атрибутах. Альтернативным образом таблица
может быть всегда отсортирована по своему первичному ключу, если
I он есть.
I_______ .- - . _ . _ -
6.1.2 Применение ограничений по ключу
В разделе 5.7.7 было сказано, что индексы не входят в стандарт SQL, но в каж-
дой реализации SQL есть способ построения индексов в качестве части определе-
ния схемы БД. Обычно индекс строится на первичном ключе для поддержки
запроса общего типа, определяющего значение этого первичного ключа. Можно
также построить индексы на других атрибутах, определенных с помощью UN QUE.
6.2 Ссылочная целостность и внешние ключи
271
Когда пункт запроса WHERE содержит условие, приравнивающее ключ
к отдельному значению, например name ='Audrey Hepburn’ в случае отношения
MovieStar из примера 6.1, соответствующий кортеж будет найден очень быстро, без
просмотра всех кортежей отношения.
Во многих реализациях SQL при создании индексов применяется команда
с ключевым словом UNIQUE, которая делает атрибут ключом и одновременно
создает на нем индекс. Например, команда
CREATE UNIQUE INDEX Yearlndex ON Movie(year);
дает тот же результат, что и команда создания индекса из раздела 5.7.7, но при
этом еще вводит ограничение уникальности на атрибуте year отношения Movie.
Рассмотрим, как система SQL применяет ограничение по ключу. В принципе
ограничение нужно проверять при каждом изменении БД. Однако совершенно
ясно, что ограничение по ключу для отношения R можег быть нарушено только
при изменении этого отношения. Фактически удаление кортежей из Л не может
нарушить ограничение, нарушение могут вызвать только вставка или изменение.
Поэтому обычно система SQL проверяет ограничение по ключу только при введе-
нии кортежей в отношение или при его изменении.
Индексы на атрибутах, объявленных ключом, имеют исключительно важное
значение, когда система SQL должна эффективно применить ограничение. Если
индекс доступен, при вставке кортежа в отношение или при изменении ключевого
атрибута в кортеже он применяется для того, чтобы установить, существует ли уже
кортеж с таким же значением в атрибуте или атрибутах, формирующих ключ. Если
такой кортеж есть система должна не допустить изменения таблицы.
Ограничение по ключу применяется и в отсутствие индекса на ключевых атрибу-
тах, но тогда при поиске кортежа с таким же ключевым значением система должна
просматривать все отношение. Такой процесс требует очень много времени и может
сделать практически невозможной модификацию БД с большими отношениями.
6.1.3 Упражнения к разделу 6.1
Упражнение 6.1.1. В примере БД из раздела 3.9 ключи определены для всех
отношений. Измените описания SQL-схемы из упражнения 5.7.1, включив в них
определения ключей для каждого из этих отношений. Учтите, что ключом для
Starsln являются все три атрибута.
Упражнение 6.1.2. Предложите подходящие ключи для отношений БД персо-
нальных компьютеров из упражнения 4.1.1. Измените схему из упражнения 5.7.2,
включив в нее определения этих ключей.
Упражнение 6.1.3. Предложите подходящие ключи для отношений БД боевых
кораблей из упражнения 4.1.3. Измените схему из упражнения 5.7.3, включив в нее
определения этих ключей.
6.2 Ссылочная целостность
и внешние ключи
Второй важный вид ограничений на БД состоит в том, что значения опреде-
ленных атрибутов должны иметь смысл. Например, считается, что атрибут presC#
отношения Studio должен относиться к конкретному администратору фильмов.
Согласно такому ограничению ссылочной целостности, если кортеж какого-то
фильма имеет в своем компоненте presC# конкретное значение с, то оно не фикция,
272
Глава 6 Ограничения и триггеры в SQL
а сертификат реального администратора фильмов. В терминах БД "реальный”
администратор — это администратор, упомянутый в отношении MovieExec. Значит,
в MovieExec должен быть кортеж со значением с атрибута cert#.
6.2.1 Описание ограничений
по внешнему ключу
В SQL атрибут или атрибуты одного отношения можно объявить внешним ключам,
относящимся к атрибуту или атрибутам другого отношения (возможно, того же
самого). При этом могут быть два следствия:
I. Атрибуты второго отношения, на которые делается ссылка, должны стать
в нем первичным ключом.
2. Любое значение атрибута внешнего ключа в первом отношении должно
появиться и в соответствующем атрибуте второго отношения. Иными
словами, вводится ограничение референциальной целостности, связываю-
щее два атрибута или два множества атрибутов.
Внешний ключ можно внести двумя способами.
а) Если внешний ключ — единственный атрибут, за его именем и типом
вводится описание того, что он "ссылается” на другой атрибут (который
должен быть первичным ключом) какой-то таблицы. Форма такого опи-
сания:
REFERENCES <таблица> (<атрибут>)
Ь) При наличии в команде CREATE TABLE списка атрибутов за ним вводят-
ся описания, означающие, что множество атрибутов является внешним
ключом. Затем указывается таблица и ее атрибуты (которые должны быть
первичным ключом), к которым относится этот внешний ключ. Форма
такого описания:
FOREIGN KEY <атрибуты> REFERENCES <таблица> (<атрибуты>)
Пример 6.3. Допустим, нужно описать отношение
Studiofname, address, presC#)
имеющее первичный ключ пате и внешний ключ presC#, ссылающийся на cert#
отношения
MovleExec(name, address, cert#, netWorth)
Ссылку presC# на cert# можно задать непосредственно:
CREATE TABLE Studio (
name CHAR(30) PRIMARY KEY,
address VARCHAR(255),
presC# INT REFERENCES MovieExec(cert#)
);
Но можно ввести внешний ключ и отдельно:
CREATE TABLE Studio (
name CHAR(30) PRIMARY KEY,
address VARCHAR(255),
presC# INT,
FOREIGN KEY presC# REFERENCES MovieExec(cert#)
6.2 Ссылочная целостность и внешние ключи
273
Заметим, что атрибут cert# в MovieExec, на который ссылается внешний ключ, фак-
тически является первичным ключом этого отношения. Для того чтобы в отноше-
нии Studio корректно объявить атрибут presC# внешним ключом, ссылающимся на
cert# из MovieExec, атрибут cert# обязательно должен быть объявлен первичным
ключом своего отношения.
Смысл любого из приведенных описаний внешнего ключа заключается в следу-
ющем. Если какое-то значение появляется в компоненте presC# кортежа из Studio,
оно должно появиться и в компоненте cert# одного из кортежей MovieExec. Единст-
венным исключением является то, что при наличии значения NULL в компоненте
presC# кортежа из Studio не требуется, чтобы оно было значением и в компоненте
cert# (фактически разумно вообще не допускать NULL в качестве атрибута, являю-
щегося первичным ключом; см. раздел 6.3.1). □
6.2.2 Применение ссылочной целостности
Мы рассмотрели, как вводятся внешние ключи. При этом не совпадающее с
NULL значение внешнего ключа должно появляться в соответствующих атрибутах
того отношения, на которое он ссылается. Но как применять такое ограничение
при изменениях БД? В конкретных СУБД могут использоваться три варианта
действий.
Правило по умолчанию:
отвергать изменения, нарушающие ограничения
В SQL по умолчанию принимается правило, согласно которому система отвергает
любое изменение, нарушающее ссылочную целостность. Обратимся к примеру 6.3,
в котором требовалось, чтобы значение presC# отношения Studio было также зна-
чением cert# отношения MovieExec. В данном случае следующие действия будут
отвергнуты системой (и вызовут ошибку выполнения операций):
Попытка ввести в Studio новый кортеж, в котором значение компонента
presC# не совпадает ни с NULL, ни со значением компонента cert# любого
кортежа из MovieExec. Действие отвергается, и такой кортеж никогда не
вводится в Studio.
2. Попытка обновить кортеж из Studio, изменив presC# на отличное от NULL
значение, которого нет в компоненте cert# любого кортежа из MovieExec
Изменение отвергается, и кортеж остается в прежнем виде.
3. Попытка удаления кортежа из MovieExec, компонент которого cert#
входит как компонент presC# в один или несколько кортежей из Studio.
Удаление отвергается, и кортеж остается в MovieExec.
4. Попытка изменения кортежа в MovieExec, при котором меняется значе-
ние cert#, но при этом старое значение cert# остается значением presC#
в Studio. Изменение отвергается, и кортеж остается в прежнем виде.
Правило каскада
Существует и другой подход к выполнению удалений и изменений в отноше-
нии, на которое делается ссылка, и называется он правилам каскада. Согласно
этому правилу для соблюдения ссылочной целостности при удалении из MovieExec
кортежа, обозначающего президента студии, система удаляет соответствующие ему
кортежи из отношения Studio. Изменения выполняются аналогично Если cert#
администратора фильма изменяется с с, на с2 и в Studio есть кортеж со значением с,
в компоненте presC#, система изменит это значение на сг.
274
Глава 6 Ограничения и триггеры в SQL
Правило установки значения NULL
Третий подход к рассматриваемой проблеме заключается в том, чтобы заме-
нить значение presC#. обозначающее удаленного или замененного президента
студии, на NULL. Такой подход получил название установки NULL
Последние два правила применяются для удалений н изменений независимо
друг оз друга и фиксируются в описании внешнего ключа с помошыо ключевых
слон ON DELETE пли ON UPDATE, за которыми следуют SET NULL или CASCADE.
Висящие кортежи и правила изменении
Кортеж со значением внешнего ключа, не появляющимся в отношении,
на которое делается ссылка, называется висящим кортежем. Кортеж, не участ-
। вуюший в соединении, тоже называется висящим. Такое совпадение терминов
I неслучайно. Если значения внешнего ключа кортежа пет в отношении, на
I которое делается ссылка, то он не участвует в соединении этого отношения
* с отношением, в которое он входит.
j Именно висящие кортежи нарушают ссылочную целостность для ограни-
I чення по внешнему ключу.
1 • Правило по умолчанию для удалений и изменений в отношении, на ко-
s. торос делается ссылка, заключается в том, что действие запрещается,
[ если и только если оно создает висящие кортежи в отношении, из кото-
!рого сделана ссылка.
• Правило каскада состоит в удалении или изменении всех созданных
висящих кортежей (в зависимости от удалений или изменений в отноше-
| нии, на которое делается ссылка).
> Правило установки в NULL заключается в установке значения внешнего
ключа в NULL в каждом висящем кортеже
Пример 6.4. Рассмотрим, как можно изменить описание отношения
Studio(name, address, presC#)
приведенное в примере 6.3. чтобы можно было проводить удаления и изменения
в отношении
MovieExecfname, address, cert#, netWorth)
На рис 6.3 показано расширение первой из приведенных в примере 6.3 формули-
ровок CREATE TABLE с помощью дополнительных предложений ON DELETE и ON
UPDATE.
1) CREATE TABLE Studio (
2) name CHAR(30) PRIMARY KEY,
3) address VARCHAR(255),
4) presC# INT REFERENCES MovieExec(cert#)
5) ON DELETE SET NULL
6) ON UPDATE CASCADE
);
Рис. 6.3 Выбор стратегии сохранения референциальной целостности
6.2 Ссылочная целостность и внешние ключи 275
Строка (5) означает, что при удалении кортежа из MovieExec компонент presC#,
относящийся к президенту любой студии, устанавливается в значение NULL Со-
гласно строке (6), при изменении значения компонента cert# кортежа из MovieExec
таким же образом изменяются все кортежи из Studio, имеющие такое же значение
вкомпоненте presC#
Заметим, что в данном примере при удалении лучше применять правило уста-
новки в NULL, а прн изменениях — правило каскада. Можно предположить, напри-
мер, что после ухода президента студия некоторое время будет существовать
вообще без президента. Изменение же номера сертификата президента студии,
скорее всего, лишь формальное изменение. Человек продолжает существовать и
быть президентом студии, поэтому желательно, чтобы такое же изменение было
внесено и в атрибут presC# из Studio. □
6.2.3 Упражнения к разделу 6.2
Упражнение 6.2.1. Опишите перечисленные ниже ограничения ссылочной
целостности для БД фильмов
Movie(frtle, year, length, inColor, studioName, producerC#)
Starsln(movieTitle, movieYear, starName)
MovieStar(name, address, gender, birthdate)
MovieExecfname, address, cert#, netWorth)
Studo(name, address, presC#)
а) Продюсером фильма должен быть человек, упомянутый в MovieExec.
Изменения отношения MovieExec, нарушающие это ограничение, отвер-
гаются.
Ь) Ограничение то же, что и в пункте (а), но в результате его нарушения
значение producerC# в отношении Movie устанавливается в NULL.
с) Ограничение то же, что и в пункте (а), но в результате его нарушения из
отношения Movie удаляется кортеж, который вызывает нарушение.
d) Фильм, появляющийся в Starsln, должен появиться и в Movie. При нару-
шении этого ограничения изменения отвергаются.
е) Кинозвезда, появляющаяся в Starsln, должна появиться и в MovieStar.
При нарушении этого ограничения удаляются кортежи, вызывающие
нарушение.
1 Упражнение 6.2.2. Введите ограничение, согласно которому каждый фильм
из отношения Movie должен появиться по крайней мере с одной кинозвездой
в отношении Starsln. Можно ли это сделать путем ограничения внешним ключом?
Обоснуйте спой ответ.
Упражнение 6.2.3. Опишите перечисленные ниже ограничения ссылочной
целостности на основе схемы БД из упражнения 4.1.3
Classes(class, type, country, numGuns, bore, displacement)
Ships(name, class, launched)
Battles(name, date)
Outcomes{ship, battle, result)
276
Г лава 6 Ограничения и триггеры в SQL
Сформулируйте приемлемые допущения относительно ключей и пресекайте все
нарушения ограничений установкой значения соответствующего Э1рибута в NULL,
*а) Каждый класс, упомянутый в Ships, должен быть упомянут и в Classes.
b) Каждое сражение, упомянутое в Outcomes, должно быть упомянуто
и в Battles.
с) Каждый корабль, упомянутый в Outcomes, должен быть упомянут
и в Ships.
6.3 Ограничения на значения атрибутов
Мы рассмотрели ограничения, согласно которым определенные атрибуты
должны иметь значения, отличающиеся от значений во всех кортежах отношения,
а также ограничения внешним ключом, требующие ссылочной целостности между
атрибутами двух отношений. Существует третий важный вид ограничений на значе-
ния атрибута, выражаемых в двух формах
1. Ограничение на атрибут в определении схемы отношения, в которое он
входит
2. Ограничение на область, которая объявляется областью значений данного
атрибута.
В разделе 6 3.1 будет введен простой тип ограничений на значение атрибута,
согласно которому' атрибут не имеет значения NULL. В разделе 6.3.2 рассматриваются
главная форма ограничений типа (1) — основанные на атрибуте ограничения CHECK.
Раздел 6.3.3 посвяшен второму типу ограничений — ограничениям на области,
а раздел 6.4 — более общим видам ограничений. Последние применяются как для
ограничения изменений целых кортежей и даже целых отношений или множества
отношений, так и для ограничения значения единственного атрибута.
6.3.1 Ограничения,
запрещающие значение NULL
Простым ограничением, связанным с атрибутом, является NOT NULL. Оно
запрещает кортежи, п которых данный атрибут имеет значение NULL, и задается
ключевыми словами NOT NULL, стоящими за описанием атрибута в определении
CREATE TABLE.
Пример 6.5. Требование, чтобы атрибут presC# отношения Stud о не имел зна
чепия NULL, можно выразить заменой строки (4) рис. 6.3 на строку
4) pesC# INT REFERENCES MovieExec(cert#) NOT NULL
Это изменение имеет несколько следствий:
» Значение компонента presC# кортежа невозможно заменить значением
NULL.
» Невозможно ввести кортеж в отношение Studio, определив только имя
п адрес, так как при этом он имеет значение NULL в компоненте presC#
• Невозможно применить правило установки в NULL в случаях, подобных тому,
что отражен н строке (5) рис. 6 3, т.е. фиксировать нарушения внешнего
ключа установкой значения presC#. □
6.3 Ограничения на значения атрибутов
277
6.3-2 Основанные на атрибуте
ограничения CHECK
Более сложные ограничения можно ввести в описание атрибута с помощью
ключевого слова CHECK, за которым следует заключенное в скобки условие, кото-
рому должны удовлетворять все значения этого атрибута. На практике основанное
на атрибуте ограничение CHECK — это, как правило, просто ограничение значений
типа перечисления допустимых значений или арифметического неравенства. Но в
принципе условием может быть все, что следует за словом WHERE в запросе SQL.
Это условие может относиться к ограничиваемому атрибуту. Однако, если условие
касается других отношений или атрибутов отношений, они должны быть введены
в пункт FROM подзапроса (даже если это отношения, содержащие проверяемые на
выполнение условия атрибуты)
Проверка основанного на атрибуте ограничения CHECK проводится всегда,
когда любой кортеж получает новое значение данного атрибута. Новое значение
может быть введено при изменении кортежа или являться частью введенного
кортежа. Если новое значение нарушает ограничение, изменение не выполняется.
В примере 6.7 будет показано, что основанное на атрибуте ограничение CHECK
не всегда проверяется, когда изменение БД не затрагивает значение атрибута,
к которому ограничение относится, и это может привести к его нарушению.
Рассмотрим простой пример этого ограничения.
Пример 6.6. Допустим, требуется, чтобы иомер сертификата состоял по мень-
шей мере из шести цифр. Для этого строку (4) описания схемы отношения
Studio(name, address, presC#)
из рис. 6.3 можно заменить строкой
4) presC# INT REFERENCES MovieExec(cert#)
CHECK (presC# >= 100000)
Или, например, атрибут gender отношения
MovieStar(name, address, gender, birthdate)
описанного на рис. 5.13, имеет тип данных CHAR(1), т.е. единственный символ.
В действительности же здесь могут появиться только буквы F или М. Поэтому
строку (4) рис 5.I3 можно заменить строкой
4) gender CHAR(1) CHECK (gender N fF'_ 'M')},
В этом условии используется явное отношение с двумя значениями. Условие озна-
чает, что значение любого компонента gender должно входить в это отношение. □
В проверяемом условии можно упоминать другие атрибуты данного отношения
и даже другие отношения, но при этом нужно формулировать подзапрос. Условием
может быть все, что следует за словом WHERE в SQL-предложении. Однако провер-
ка ограничения связана только с рассматриваемым атрибутом, а не с каждым отно-
шением или атрибутом, упомянутым в ограничении. Поэтому условие может стать
ложным, если изменяется элемент не проверяемого, а какого-то другого атрибута.
Пример 6.7. Попробуем выразить ограничение ссылочной целостности с помощью
основанного на атрибуте ограничения CHECK, требующего наличия значения, на
которое делается ссылка. Далее показана ошибочная попытка выразить требование
согласно которому значение presC# в кортеже отношения
Studio(name address presC#)
278
Глава 6 Ограничения и триггеры в SOL
должно появиться в компоненте сеп# кортежа отношения
MovieExecfname, address, cert#, netWorth)
Допустим, что строка (4) рис. 6.3 заменена строкой
4) presC# INT CHECK
(presC# IN (SELECT cert# FROM MovieExec))
Это иполне корректное, основанное на атрибуте ограничение CHECK, но резуль-
таты его негативны.
• Невозможно ввести в отношение Studio новый кортеж, имеющий значение
компонента presC#. не являющееся номером сертификата администратора
фильма.
• Значение компонента presC# кортежа нз Studio невозможно заменить новым
значением, не являющимся номером сертификата администратора фильма.
• Если из отношения MovieExec удалить, например, кортеж для президента
студии, такое изменение останется "невидимым" для данного ограничения.
Значит, удаление разрешено, даже если нарушается ограничение CHECK на
атрибут presC#.
В разделе 6.4.2 будут введены более жесткие ограничения, позволяющие кор-
ректно выразить рассмотренное в этом примере условие. □
f
Когда нужно проверять
выполнение ограничения
| В нормальных условиях система SQL не допускает изменений БД. вызы-
| вающих нарушения ограничения. Но иногда приходится выполнить несколько
« изменений, одно из которых вызывает нарушение, а другие устраняют воз-
| никшие противоречия. В примере 6.3 presC# — это внешний ключ отношения
Studio, ссылающийся на cert# в отношении MovieExec. Если нужно добавить
I новую студию и ее президента, то попытка сначала добавить студию нарушает
j ограничение по внешнему ключу.
5 Кажется, что проблему можно решить, добавляя сначала президента.
5 а затем студию. Однако допустим, что имеется еще и ограничение, согласно
s которому кортежи отношения MovieExec должны содержать сертификаты,
| принадлежащие президентам студий или продюсерам (из отношения Movie).
I Тогда порядок добавления студии и ее президента ничего не изменит.
В SQL"5 проблема решается добавлением к ограничению слова DEFERRED,
s Тогда данное ограничение проверяется до тех пор, пока не завершится тран-
• закния (базовый модуль операции на БД; см. раздел 7.2). В единственной
транзакции можно ввести и студию, и президента, избежав таким образом
| нарушения ограничения.
6.3-3 Ограничения области
Ограничить значения атрибута можно, описав область (см. раздел 5.7.6) с ана-
логичным ограничением, а затем определив ес как тип данных этого атрибута.
Единственное важное различие состоит в том, что, ограничивая значение в области,
мы не можем потом сослаться на него, а ограничивая атрибут, имеем возможность
сослаться на значение этого атрибута по его имени. В SQL2 данная проблема реша-
ется с помощью специального ключевого слова VALUE для ссылки на значение
в области.
6.4 Глобальные ограничения
279
Пример 6.8. Описать область GenderDomain с двумя значениями F и М можно
с помошью предложения;
CREATE DOMAIN GenderDomain CHAR(1)
CHECK (VALUE IN CF1. '№'));
Тогда строку (4) рис. 5.13 нужно заменить на
4) gender GenderDomain,
Точно так же можно потребовать, чтобы номера сертификатов для атрибута
presC# состояли не менее чем из шести цифр (см. пример 6.6). Для этого задается
область:
CREATE DOMAIN CertDomain INT
CHECK (VALUE >= 100000);
а затем дается следующее описание атрибута presC#:
4) presC# CertDomain REFERENCES MovieExec(cert#) □
6.3-4 Упражнения к разделу 6.3
Упражнение 6.3.1. Запишите перечисленные ниже ограничения на атрибуты
отношения
Movieftitle, year, length, InColor, studioName, producerC#)
*a) Год не может быть до 1895
Ь) Продолжительность не может быть меньше 60 и больше 250 минут
’с) Именем студии может быть только Disney, Fox, MGM или Paramount
Упражнение 6.3.2. Запишите перечисленные ниже ограничения на атрибуты
из схемы упражнения 4.1.1
Product(maker model, typa)
PC(model speed, ram, hd, cd, price)
Laptop(model, speed, ram, hd screen price)
Printer(model, color, type, price)
а) Скорость ПК-блокнота должна быть не менее 100 МГц
Ь) Скорость CD может быть только 4х, бх, 8х или 12х
с) Типами принтеров могут быть только лазерный, струйный и матричный
d) Типами продукта могут быть только ПК ПК-блокноты и принтеры
е) Объем RAM каждого ПК должен составлять не менее 1% объема
его жесткого диска
6.4 Глобальные ограничения
Рассмотрим описания более сложных ограничений, включающих в себя связи межпу
атрибутами и даже между различными отношениями. Тема состоит из двух частей:
I Основанные на кортежах ограничения CHECK, касающиеся любого аспекта
кортежей единственного отношения.
2. Операторы контроля (assertions) — ограничения, которые могут включать
в себя целые отношения или множество переменных кортежей над одним
и тем же отношением.
280
Глава 6 Ограничения и триггеры в SQL
6.4.1 Основанные на кортежах
ограничения CHECK
Для описания ограничения на кортежи единственного отношения Л при опре-
делении Л с помощью CREATE TABLE к списку атрибутов и описанию ключа или
внешнего ключа добавляется слово CHECK, за которым следует заключенное в скоб-
ки условие. Условием может быть все, что появляется в пункте WHERE. Этому
условию должен удовлетворять некоторый кортеж R. Как и при основанном на
атрибуте ограничении CHECK, условие может упоминать в подзапросах другие
отношения или другие кортежи отношения R.
Условие основанного на кортеже ограничения CHECK проверяется при каждой
вставке в R нового кортежа и при изменении существующего. Если условие не
выполняется для нового или измененного кортежа, вставка или изменение этого
кортежа отвергается. Однако, если условие упоминает некоторое отношение (даже
само R) в подзапросе и изменение этого отношения приводит к нарушению данного
условия для кортежа R, такое изменение не отвергается. Иными словами, подобно
основанному на атрибуте ограничению CHECK, основанное на кортеже ограниче-
ние CHECK остается "невидимым" для других отношений.
Хотя основанные на кортежах проверки могут включать в себя очень сложные
условия, такие условия лучше оставить для "операторов контроля" SQL, о которых
пойдет речь в разделе 6.4.2. Причина в том, что при определенных условиях
основанные на кортежах проверки могут нарушаться. Если же такая проверка
затрагивает только атрибуты проверяемого кортежа и не содержит подзапросов,
ограничение всегда соблюдается. Приведем пример простого, основанного на кор-
теже ограничения, включающего в себя различные атрибуты одного кортежа.
Правильная запись ограничений
Многие ограничения похожи на ограничение из примера 6 9 — в них
запрещаются кортежи, удовлетворяющие двум и более условиям. Выражение,
следующее за ключевым словом CHECK,— это отрицания данных условий,
связанные OR. В примере 6.9 первое условие состоит в том, чтобы кинозвездой
был мужчина, поэтому отрицание записано как gender = ’F' (хотя, возможно,
более естественно было бы записать его как gender <> ’М'). Согласно второму
условию, name должно начинаться с "Ms.", и для отрицания используется
сравнение NOT LIKE. Это сравнение отрицает само условие, которое в SQL
выглядело бы как name LIKE 'Ms.%'.
Пример 6.9. Вспомним пример 5.32, в котором была описана схема таблицы
MovieStar. На рис. 6.4 команда CREATE TABLE дополнена описанием ключа со
словом UNIQUE и другим ограничением — одним из многих возможных "условий
непротиворечивости", которые может понадобиться проверить. Согласно этому
ограничению, если кинозвезда — мужчина, его имя не должно начинаться с "Ms.’.
1) CREATE TABLE MovieStar (
2) name CHAR(30) UNIQUE,
3) address VARCHAR(255),
4) gender CHAR(1),
5) birthdate DATE,
6) CHECK (gender = "F" OR name NOT LIKE "Ms %")
);
Рис. 6.4. Ограничение на таблицу MovieStar
6.4 Глобальные ограничения
281
В строке (2) атрибут name объявлен ключом отношения, а в строке (6) введено
ограничение. Условие ограничения выполняется для каждой кинозвезды женского
пола и каждой кинозвезды, имя которой не начинается с 'Ms.'. Оно не выполняется
только для кортежей, и которых пол обозначен как мужской и имя действительно
начинается с ‘Ms.'. Именно такие кортежи нужно исключить из отношения. □
6.4.2 Операторы контроля
Итак, мы перешли от ограничений на атрибуты к ограничениям на кортежи.
Однако иногда даже этих форм ограничений недостаточно. Нужны ограничения,
включающие а себя отношение в целом, например ограничение суммы или другого
объединения значений в одном столбце. Применяются также ограничения, затраги-
вающие несколько отношений. Фактически к ним относится ограничение по внеш
нему ключу, соединяющее два отношения.
Утверждения в SQL2 (называемые также общими ограничениями) позволяют
ввести любое условие (выражение, следующее за WHERE). В то время как другие
типы ограничений только связаны с элементами схемы, обы шо с таблицами или
областями, утверждения сами являются элементами схемы.
Подобно другим элементам схемы, утверждение описывается с помощью пред-
ложения CREATE. В описание входят следующие элементы:
1. Ключевые слова CREATE ASSERTION
2. Имя утверждения
3. Ключевое слово CHECK
4. Заключенное в скобки условие
Таким образом, предложение имеет вид-
CREATE ASSERTION <имя> CHECK (<условие>)
Условие должно всегда выполняться, и нарушающие его изменения БД отвер-
гаются. Напомним, что другие рассмотренные ранее ограничения типа CHECK при
определенных условиях могут нарушаться, если они содержат подзапросы,
Основанные на кортеже ограничения CHECK и утверждения записываются
по-разному. Первые могут относиться к атрибутам отношения, в описание которого
они входят Например, в строке (6) на рис. 6.4 не указано, откуда берутся атрибуты
gender и пате. Они относятся к компонентам кортежа таблицы MovieStar, так как
только она вводится оператором CREATE.
У условия утверждения контроля нет такого преимущества. Любой упомянутый
в условии атрибут должен быть введен в описание, как правило, путем указания
отношения, к которому он принадлежит, в выражении типа select-from-whcrc.
Поскольку условие должно иметь булево значение, естественно как-нибудь
агрегировать результаты проверки, чтобы остался только выбор истинно/ложно
Например, можно записать условие в виде выражения, порождающего отношение,
к которому применяется оператор NOT EXISTS, т.е, ограничение заключается в том,
что это отношение всегда пусто. Возможно также применить оператор агрегации
типа SUM к столбцу отношения и сравнить результат с константой. Например,
можно потребовать, чтобы сумма всегда была меньше установленной величины.
Пример 6.10. Предположим, требуется, чтобы президентом студии мог стать
только человек, имеющий чистый доход не менее 10 млн. дол. Вводится утвержде-
ние, требу ощее, чтобы множество студий. президенты которых имеют чистый
доход менее 10 млн. дол., было пустым. В него входят дна отношения:
MovieExecfname, address, cert#. netWorth)
Studio(name, address presC#)
282
Глава 6 Ограничения и триггеры в SQL
Описание такого оператора контроля дано на рис. 6.5.
CREATE ASSERTION RichPres CHECK
(NOT EXISTS
(SELECT ‘
FROM Stud o, MovieExec
WHERE presC# = cert# AND netWorth < 10000000
)
):
Рис. 6.5. Утверждение, гарантирующее богатых президентов студий
Заметим, что это ограничение можно записать не в виде единственного утверж-
дения а в виде основанных на кортеже ограничений CHECK на двух отношениях
Например, к рис. 6.3 можно добавить ограничение на отношение Studio, как это
показано на рис. 6.6.
1) CREATE TABLE Studio (
2) name CHAR(30) PRIMARY KEY,
3) address VARCHAR(255).
4) presC# INT REFERENCES MovieExec(cerW),
5) CHECK (presC# NOT IN
6) (SELECT cert# FROM MovieExec
7) WHERE netWorth < 10000000)
)
);
Рис. 6.6. Ограничение на Studio, отражающее утверждение
Однако это ограничение будет проверяться только при изменении отношения
Studio. Оно не касается, например, случая, когда чистый доход президента какой
нибудь студии, упомянутого в MovieExec, упадет ниже 10 млн. дол. Для достижения
полного эффекта утверждения к описанию отношения MovieExec тоже нужно до-
бавить ограничение согласно которому администратор, являющийся президентом
студни, должен иметь чистый доход не менее 10 млн. дол. □
Преимущества и недостатки
лимитированной проверки ограничений
Может показаться странным, что допускаются нарушения основанных на
атрибуте и на кортеже ограничений CHECK, если они ссылаются на другие
S кортежи одного и того же отношения или на другие отношения в целом Дело
( в том, что такие ограничения реализуются эффективнее, чем утверждения.
. Первые относятся только к кортежу или кортежам, которые вставляются
в отношение или изменяются, а вторые должны проверяться при каждом
изменении упомянутых в них отношений. Вопр’ с о необходимости дополни-
t тельных проверок во время изменений БД реши-1 проектировщик БД. Однако
I для обеспечения долговременной надежности программы рекомендуется не
। применять основанные на атрибуте или на кортеже ограничения CHECK,
| которые могут нарушаться.
I
Ч U I n~WWH4 -1 LWn-*L . r— — — in — —- j »! I I .._,,,,,, , , , - • • • I ij_l—T'" "
6 4 Глобальные ограничения 283
Пример 6.11. Построим утверждение, которое действует на отношение
Movie(title, year length, inColor, studioName, producerC#)
и означает, что общая продолжительность фильмов выпущенных студией, не должна
превышать 10 000 мин.
CREATE ASSERTION SumLength CHECK (10000 >= ALL
(SELECT SUM(length) FROM Movie GROUP BY studioName),
)
Это ограничение содержит только отношение Movie, и его можно выразить не
в форме утверждения, а в виде основанного на кортеже ограничения в схеме отно-
шения Movie Последнее добавляется к определению таблицы Movie'
CHECK (10000 >= ALL
(SELECT SUM(length) FROM Movie GROUP BY studoName)),
В принципе это условие касается любого кортежа таблицы Movie. Однако в нем явно
не указывается ни один атрибут кортежа и вся работа выполняется в подзапросе.
Заметим также, что проверка этого ограничения не проводится при удалении
кортежа из Movie В данном примере это не опасно, так как, если ограничение вы-
полнялось до удаления, оно заведомо будет выполняться и после удаления. Но если
бы ограничивался нижний, а не верхний предел обшей длины, то при такой форме
записи ограничение было бы нарушено □
Сравнение ограничений
В таблице отражены главные различия между ограничениями трех типов
Тип ограничения Где описывается Когда действует Обязательно ли выполняется
Основанное на атрибуте CHECK Вместе с атрибутом При изменении атрибута или его введении в отношение Нет, если имеются подзапросы
Основанное на кортеже CHECK Как элемент реляционной схемы При изменении кортежа или его введении в отношение Нет, если имеются ; подзапросы ।
Утверждение Как элемент схемы БД При изменении любого из упомянутых отношений Да
284
Глава 6 Ограничения и триггеры в SOL
6.4.3 Упражнения к разделу 6.4
Упражнение 6.4.1. В примере 6.10 говорилось, что основанное на кортеже
ограничение CHECK выполняет только часть функций утверждения, представлен-
ного на рис. 6.5. Запишите ограничение CHECK на отношение MovieExec, которое
обязательно завершит выполнение этих функций.
Упражнение 6.4.2. Запишите перечисленные ниже ограничения в виде осно-
ванных на кортеже ограничений CHECK на отношения БД фильмов:
Movieftitle year, length, inColor. studioName, producerC#)
Starsln(movieTitie, movieYear, starName)
MovieStarfname, address, gender, birthdate)
MovieExecfname, address, cert#, netWorth)
Studiofname, address, presC#)
Если ограничение содержит два отношения, его нужно накладывать на каждое из них,
чтобы при любом их изменении ограничение проверялось относительно введений
и изменений. Предполагается, что удалений нет; к удалениям нельзя применить
ограничения, основанные на кортеже.
*а) Фильм не может быть цветным, если он снят до 1939 г.
Ь) Кинозвезда не может играть в фильме, выпущенном до ее рождения.
! с) Две студии не могут иметь один и тот же адрес.
*! d) Имя, вхоляшее в MovieStar, не может входить в MovieExec.
! е) Название студии, входящее в Studio, должно входить по крайней мере
в один кортеж отношения Movie.
!! О Если продюсер фильма является президентом студии, он должен быть
президентом студии, выпустившей этот фильм.
Упражнение 6.4.3. Запишите в виде SQL-выражений перечисленные ниже
ограничения, основанные на отношениях примера 4.1.1
Productfmaker, model, type)
PCfmodel, speed, ram, hd, cd, price) •
Laptopfmodel, speed, ram, hd, screen, price)
Pnnterfmodel, color, type, price)
*a) Ни один производитель ПК не может производить ПК-блокноты.
*! Ь) Производитель ПК должен производить ПК-блокноты по меньшей мере
с такой же скоростью процессора.
!с) Если объем главной памяти ПК блокнота превышает объем главной
памяти ПК, его иена должна быть выше цены ПК.
!! d) Ни один номер модели не может появиться дважды в отношениях PC,
Laptop и Printer
!! е) Если модель к ее тип упоминаются в отношении Product, эта модель
должна появиться в отношении, подходящем для данного типа.
6.5 Изменение ограничений
285
Упражнение 6.4.4. Запишите следующие основанные на кортеже ограничения
CHECK на схему "PC"
а) Цена ПК со скоростью процессора менее 150 МГц не должна превышать
1500 дол.
Ь) П К-блокнот с размером экрана менее 11 дюймов должен иметь жесткий
диск не менее I Гбайт или продаваться по цене ниже 2000 дол
Упражнение 6.4.5. Запишите в виде SQL-выражений перечисленные ниже
ограничения, основанные на отношениях примера 4.1.3
C!asses(class, type, country, numGuns. bore, displacement)
Sh ps(name, class, launched)
Batt es(name, date)
Outcomesjship, battle result)
а) Ни один класс не может иметь более двух кораблей.
!Ь) Ни одна из стран не может иметь и линкоры, и крейсеры.
!с) Ни один корабль, имеющий более девяти орудий, не мог участвовать в
одном сражении с кораблем, у которого меньше девяти орудий и который
был потоплен в этом сражении.
!d) Ни один корабль не мог быть спущен на воду раньше корабля того же
класса, носящего то же самое имя.
!е) Для каждого класса существует корабль с именем этого класса.
Упражнение 6.4.6. Запишите следующие основанные на кортежах ограниче-
ния CHECK, касающиеся схемы "линкоров'':
а) Ни один класс кораблей не может иметь орудий калибра более 16 дюймов.
Ь) Если класс кораблей имеет более девяти орудий, их калибр не должен
превышать 14 дюймов.
1 с) Ни один корабль не может участвовать в сражении до его спуска на воду.
6.5 Изменение ограничений
Ограничения можно изменить или отменить в любое время Способ выраже-
ния изменений зависит от того, с чем связано ограничение с областью, атрибутом,
таблицей или со схемой БД.
6.5.1 Присваивание имен ограничениям
Для изменения или отмены существующего ограничения необходимо, чтобы
оно имело имя. Утверждениям, являющимся частью схемы БД, всегда присвоены
имена в выражении CREATE ASSERTION. Чтобы присвоить имя любому другому
ограничению, нужно поставить впереди ключевое слово CONSTRAINT и выбранное
имя.
Пример 6.J2. Имя можно присвоить даже ограничению по первичному или
внешнему ключу. Например, переписать строку (2) рис. 6.1 и присвоить имя огра-
ничению, согласно которому name является первичным ключом:
2)
name CHAR(30) CONSTRAINT NamelsKey PRIMARY KEY,
2В6
Глава 6 О раничения и триггерь в SQL
Аналогичным способом присваивается имя основанному на атрибуте ограничению
CHECK из примера 6.6
4) gender CHAR(1) CONSTRA NT NoAndro
CHECK (gender IN ('F M1))
ограничению области из примера 6.S:
CREATE DOMAIN CertDomain INT
CONSTRAINT SixDigtS CHECK (VALUE >= 100000)
И наконец, основанному на кортеже ограничению CHECK имя присваивается
заменой строки (6) рис. 6.4 строкой
6) CONSTRAINT RightTitle
CHECK (gender = F OR name NOT LIKE ,Ms.\%’) □
6.5.2 Изменение ограничений на таблицы
Изменить множество ограничений, связанных с областью, атрибутом или
таблицей, можно с помошыо оператора ALTER. Оператор ALTER TABLE применял-
ся в разделе 5.7.4 для добавления и удаления атрибутов. Оператор ALTER DOMAIN
применялся в разделе 5 7.6 для изменения значения по умолчанию
Эти операторы можно применять и для изменения ограничений. ALTER TABLE
используется для изменения основанных на атрибуте и на кортеже ограничений
CHECK. Ограничение можно отменить с помощью ключевого слова DROP и имени
уда1яемого ограничения или же добавить с помощью ключевого слова ADD, за
которым следует добавляемое ограничение
Пример 6.13. Рассмотрим, как отменить и добавить ограничения из примера 6.12.
Ограничение. согласно которому name является первичным ключом отношения
MovieStar, отменяется предложением
ALTER TABLE MovieStar DROP CONSTRAINT NamelsKey;
Основанное на атрибуте ограничение CHECK на значения атрибута gender
отменяется предложением
ALTER TABLE MovieStar DROP CONSTRAINT NoAndro;
Ограничение на отношение MovieStar, согласно которому 'Ms.' относится
только к кинозвездам женского пола, отменяется предложением
ALTER TABLE MovieStar DROP CONSTRAINT RightTitle;
Для восстановления этих ограничений нужно изменить схему отношения
MovieStar. добавив к ней эти же ограничения. Например
ALTER TABLE MovieStar ADD CONSTRAINT NamelsKey
PRIMARY KEY (name).
ALTER TABLE MovieStar ADD CONSTRAINT NoAndro
CHECK (gender IN (F, 'M')),
ALTER TABLE MovieStar ADD CONSTRAINT RightTitle
CHECK (gender = F OR name NOT LIKE Ms.\%')
Теперь они стали ограничениями CHECK, основанными на кортеже, а не на
атрибуте. Их нельзя вновь превратить в ограничения атрибутов, но если бы типами
атрибутов были области можно было бы отнести ограничения к этим областям, не
изменяя таблицы MovieStar.
6.5 Изменение ограничений
287
Имя вводимого заново ограничения выбирается произвольно, однако SQL не
запоминает ограничений, связанных с их именами. Поэтому при добавлении преж-
него ограничения его нужно писать заново и нельзя ссылаться на него только по
имени. □
Присваивайте ограничениям имена
Желательно присвоить ограничению имя, даже если вы полагаете, что |
никогда не будете на него ссылаться. Если ограничение создано без имени, i
= а вам понадобилось его изменить, присваивать имя уже поздно.
6-5-3 Изменения ограничений области
Удален е и добавление ограничений области проводится, по существу, так же,
как удаление или добавлений основанных на кортеже ограничений CHECK. Для
удаления применяется оператор ALTER, в котором за ключевым словом DROP
следует имя ограничения. Для добавления ограничения области в оператор ALTER
вносятся ключевое слово ADD, имя ограничения и условие CHECK, определяющее
данное ограничение.
Пример 6.14. Ограничение, согласно которому номер сертификата должен со-
держать не менее шести цифр, удаляется предложением
ALTER DOMAIN CertDomain DROP CONSTRAINT SixDigits;
Восстановить это же ограничение можно с помощью предложения
ALTER DOMAIN CertDomain ADD CONSTRAINT SixDigits
CHECK (VALUE >= 100000); □
6.5.4 Изменение утверждений
Утверждение можно удалить с помощью предложения, состоящего из ключе-
вых слов DROP ASSERTION за которыми следует имя утверждения.
Пример 6.15. Утверждение из примера 6.10 удаляется предложением
DROP ASSERT ON Rich Pres,
Для восстановления ограничения нужно описать его снова, как в примере 6.10. □
6.5.5 Упражнения к разделу 6.5
Упражнение 6.5.1. Покажите, как изменить реляционные схемы
Movie(ttle, year, length, inColor, studioName, producerC#)
Starsln(movieTitle movieYear, starName)
Mov eSta (name, address, gender, birthdate)
Mov eExecfname, address, cert#, netWorth)
Studio(nama, address, presC#)
288
Глава 6 Ограничения и три серы в SQL
следующими способами:
*а) сделайте title и year ключом отношения Movie;
b) введите ограничение ссылочной целостности, согласно которому
продюсер каждого фильма входит в отношение MovieExec;
с) потребуйте, чтобы продолжительность фильма была не менее 60
и не более 250 минут;
*! d) потребуйте, чтобы ни одно имя не было именем и кинозвезды,
и администратора (это ограничение не нужно применять при удалениях);
! е) потребуйте, чтобы никакие две студии не имели одного и того же адреса.
Упражнение 6.5.2. Покажите, как изменить схемы БД
Classes(class, type, country, numGuns, bore, displacement)
Ships(name, class, launched)
Battles(name, date)
Outcomes(ship. battle, result)
чтобы получ 1ть следующие основанные на кортеже ограничения:
a) Class и country образуют ключ отношения Classes.
b) Ограничение ссылочной целостности, согласно которому корабль,
появляющийся в Battles, появляется н в Ships.
с) Ограничение ссылочной целостности, согласно которому корабль,
появляющийся в Outcomes, появляется и в Ships.
d) Ни один корабль не имеет более )4 орудий.
! е) Корабль не должен участвовать в битве до его спуска на поду
6.6 Триггеры в SQL3
Рассмотренные в этой главе различные формы ограничений удовлетворяют
стандарту SQL2. Согласно модели нх выполнения, они применяются при измене-
нии элемента к которому относятся. Например, основанное на атрибуте ограниче-
ние CHECK используется при изменении этого атрибута в некотором кортеже
(включая случай вставки кортежа).
Поскольку реализация ограничений предполагает "инициирование" проверки
при определенных событиях, кажется естественным поручить отбор таких событий
программисту БД а не системе. Такой подход дал бы пользователю дополнительные
возможности запускать операции БД нс только для предотвращения нарушений
ограничений Поэтому предлагаемый стандарт SQL3 содержит триггеры которые
напоминают ограничения, но включают в себя явно определенные события и дей-
ствия, предпринимаемые при определенных условиях Интересно, что современные
коммерческие системы зачастую ближе к SQL3. чем к SQL2, в плане трактовки
активных элементов. Это можно объяснить тем, что коммерческим поставщикам
легче реализовать триггеры, чем утверждения.
6.6 Триггеры в SQL3
289
6.6.1 Триггеры и ограничения
Триггеры, иногда называемые правилами типа событие-условие-действие или
правилами ЕСА, отличаются от рассмотренных выше ограничений в трех аспектах:
1. Триггеры применяются только при наступлении конкретных событий,
определенных программистом БД, обычно при вставке удалении или
изменении отдельного отношения. Во многих системах SQL таким собы-
тием считается также конец транзакции (атомарные единицы работы,
называемые транзакциями, рассматриваются в разделе 7.2),
2. Вместо немедленного предотвращения вызвавшего его события триггер
проверяет заданное условие. Если оно не выполняется, в ответ на событие
не выполняется никаких действий, связанных с триггером.
3. Если условие триггера выполняется, связанное с ним действие выполня-
ется DBMS. Это действие состоит либо в предотвращении события, либо
в отмене его результата (например, в удалении вставленного кортежа).
Фактически таким действием может быть любая последовательность опе-
раций БД, возможно, даже операций, никак не связанных с событием,
вызвавшим срабатывание триггера.
Далее мы рассмотрим триггеры в SQL3, а затем БОЕЗ-расширения ограниче-
ний SQL2, называемых утверждениями и включающих в себя некоторые аспекты
триггеров.
6.6.2 Триггеры SQL3
Триггеры SQL3 предоставляют пользователю ряд различных опций, касающихся
события, условия и действия.
1. Действие можно выполнить до события, после или вместо события,
вызвавшего срабатывание триггера.
2. Действие может относиться как к старым, так и к новым значениям
кортежей, которые были введены, удалены или изменены событием,
вызвавшим срабатывание триггера.
3 События обновления могут определять отдельный столбец или множество
столбцов.
4. Условие можно задать в пункте WHEN, и действие выполняется, если
только при наступлении события, вызвавшего срабатывание триггера,
срабатывает правило и выполняется данное условие.
5. Программист может установить режим выполнения действия:
(а) один раз для каждого изменяемого кортежа;
(Ь) один раз для всех кортежей, изменяемых операцией на БД.
Прежде чем рассматривать детали синтаксиса триггеров, приведем пример,
иллюстрирующий наиболее важные синтаксические и семантические аспекты.
В этом примере триггер выполняется один раз для каждого изменяемого кортежа.
Пример 6.16. Запишем триггер SQL3 для таблицы
MovieExec(name, address, cert#, netWorth)
относящийся к изменениям атрибута netWorth Он предназначен для возобновления
любой попытки снизить чистый доход президента студии Описание триггера дано
на рис. 6.7.
290
Глава 6 Ограничения и триггеры в SQ .
1) CREATE TRIGGER NetWorthTrigger
2) AFTER UPDATE OF netWorth ON MovieExec
3) REFERENCING
4) OLD AS OldTuple,
5) NEW AS NewTuple
6) WHEN(OldTuple.networth > NewTuple.netWorth)
7) UPDATE MovieExec
8) SET networth = О dTuple netWorth
9) WHERE cert# ~ NewTuple.cert#
10) FOR EACH ROW
Рис 6.7. Триггер SQL3
В строке (I) описание начинается ключевыми словами CREATE TR GGER и
именем триггера. В строке (2) указано событие, вызывающее срабатывание тргггера,
а менно обновление атрибута networth отношения MovieExec. В строках (3) — (5)
показано, как при условии и действии триггера производятся ссылки на старый
кортеж (кортеж до обновления) и новый кортеж (кортеж после обновления) На
строках (4) и (5) они описаны как OldTuple и NewTuple соответственно В условии
к действии эти имена можно применять как переменные кортежей указанные
в пункте FROM обычного запроса SQL.
Строка (6) — это условие триггера, означающее, что действие выполняется,
если только новый чистый доход администратора ниже старого.
В строках (7) — (9) описано действие в виде обычного оператора изменения
SQL. В принципе при этом рассматривается каждый кортеж, но пункт WHERE
на строке (9) гарантирует, что опер;п-ор действует только на измененный кортеж
(кортеж с подходящим атрибутом cert#).
И наконец, строка (I0) выражает требование, согласно которому триггер сра-
батывает один раз для каждого измененного кортежа. Если такого кортежа нет. он
срабатывает один раз для каждого оператора SQL, независимо от количества ини-
циирующих триггер изменений кортежа. □
Конечно, пример 6.16 иллюстрирует только некоторые особенности триггеров
SQL3 Далее кратко перечислены обеспечиваемые триггерами режимы н способы
их выражения
• Согласно строке (2) рис. 6.7, действие выполняется после события, вызыва- '
ющего срабатывание триггера, что выражено ключевым словом AFTER. Воз-
можны другие варианта:
I. BEFORE означает, что условие пункта WHEN проверяется перед
наступлением события, вызывающего срабатывание триггера. Если
условие истинно, выполняется действие триггера. Тогда событие,
вызвавшее изменение, выполняется независимо от того, было ли
истинным условие.
2. INSTEAD OF—действие выполняется (при выполнении условия WHEN),
а инициирующее триггер событие не выполняется вообще.
" Помимо UPDATE, инициировать триггер могут события INSERT и DELETE.
Предложение OF netWorth в строке (2) рис. 6.7 применяется для событий
UPDAiE и означает, что событием является только изменение атрибутов,
перечисленных после ключевого слова OF. Применять OF с событиями
INSERT или DELETE запрещено: эти события имеют смысл только для целых
кортежей.
6.6 Триггеры в SQL3
291
* > В предыдущем примере действие показано как единственный оператор SQL,
но там могло быть любое число таких операторов, разделенных точкой
с запятой.
• Когда вызывающим срабатывание триггера событием является изменение
имеются старый и новый кортежи, т.е. кортеж перед изменением и кортеж
после изменения. В строках (4) и (5) им присваиваются имена с помощью
ключевых слов OLD AS и NEW AS. Если вызывающим срабатывание тригге-
ра событием является вставка, слова NEW AS используются для именования
вводимого кортежа, a OLD AS запрещены. И наоборот, при удалении слова
OLD AS применяются для именования удаляемого кортежа, а слова NEW AS
запрещены.
• При удалении ключевых слов FOR EACH ROW из строки (10) триггер уровня
строки, описанный на рис. 6.7, становится триггером уровня предложения.
Последний выполняется один раз для каждого предложения, генерирующего
одно и более событий, вызывающих срабатывание триггера. Например, если
вся таблица изменяется с помощью SQL-предложения, триггер уровня
предложения выполняется только один раз, а триггер уровня кортежа
выполняется по одному разу для каждого кортежа. В триггере уровня пред-
ложения невозможно прямо ссылаться на старые и новые кортежи, как это
делалось в строках (4) и (5), а можно ссылаться только на множество старых
кортежей (удаленных кортежей или старых версий измененных кортежей)
и на множество новых кортежей (вставленных кортежей или новых версий
измененных кортежей) как на два отношения. Значит, вместо строк (4) и (5)
на рис. 6 7 мы пишем соответственно OLD TAELE AS OidStuff и NEW_TABLE
AS NewStuff, где OidStuff — имя отношения, содержащего все старые кортежи,
a NewStuff—имя отношения, содержащего новые кортежи.
Пример 6.17. Допустим, нужно предотвратить падение среднего чистого дохода
администраторов ниже 500 тыс. дол. Такое ограничение может быть нарушено
вставкой, удалением или изменением в столбце netWorth таблицы
MovieExec(name, address, cert#, netWorth)
Необходимо ввести по одному триггеру для каждого из этих событий. На рис. 6.8
показан триггер для изменения Триггеры для вставки и удаления похожи на него
хотя и более просты.
1) CREATE TRIGGER AvgNetWorthTrigger
2) INSTEAD OF UPDATE OF netWorth ON MovieExec
3) REFERENCING
4) OLD TABLE AS OidStuff
5) NEW_TABLE AS NewStuff
6) WHEN(500000 <=
7) (SELECT AVG(NetWorth)
8) FROM ((MovieExec EXCEPT OidStuff) UNION NewStuff)
)
9) DELETE FROM MovieExec
10) WHERE (name, address, cert#, netWorth) IN OidStuff;
11) INSERT INTO MovieExec
12) (SELECT * FROM NewStuff),
Рис. 6 В Огроничение среднего чистого доходо
292
Глава 6 Ограничения и триггеры в SQL
Строки (3) -(5) означают, что NewStuff и OldStuff — это имена отношений,
содержащих соответственно новые и старые кортежи, включенные в операцию БД,
вызывающую срабатывание триггера. Заметим, что один оператор БД может изме-
нять множество кортежей отношения и при его выполнении в NewStuff it OldStuff
может входить множество кортежей.
Если операцией является изменение, NewStuff и OldStuff — соответственно
новые и старые версии измененных кортежей. В аналогичном триггере для удаления
в OldSluff входили бы удаляемые кортежи и не было бы описания имени отноше-
ния NewStuff для NEWTABLE. В триггере для вставки новые кортежи входили бы
в NewStuff и не было бы описания отношения OldStuff.
Строки (6) — (S) — это условие, которое выполняется, если средний чистый
доход nocie изменения составляет не менее 500 тыс. дол. Заметим, что выражение
в строке (8) вычисляет, каким должно быть отношение MovieExec, когда выполнено
изменение.
Но в строке (2) указано INSTEAD OF и поэтому пресекается любая попытка
изменения столбца netWorth из отношения MovieExec. Изменение не выполняется
никогда. Вместо этого триггер проверяет условие, чтобы решить, что предпринять
дальше. В данном примере, если изменение не делает средний доход администрато-
ров фильмов менее 500 тыс. дол., действие приводит к результату, который был
целью изменения. А именно: строки (9) и (10) удаляют кортежи, предназначенные
для изменения, а строки (II) и (12) вводят новые версии этих кортежей. □
6.6.3 Утверждения в SQL3
Утверждения SQL.2 в SQL3 расширяются в двух важных направлениях:
I. Утверждения вводятся в действие событиями, определенными програм-
мистом, а не событиями, которые, согласно решению системы, могут
нарушить ограничение.
2. По выбору утверждения могут относиться к каждому кортежу таблицы,
а не к таблице или к таблицам в целом.
Пример 6.18. Утверждение RichPres из примера 6 10 показано на рис. 6.9 в но-
тации SQL3.
1) CREATE ASSERTION RichPres
2) AFTER
3) INSERT ON Studio.
4) UPDATE OF presC# ON Studio,
5) UPDATE OF netWorth ON MovieExec,
6) DELETE ON MovieExec
7) CHECK (NOT EXISTS
8) (SELECT * FROM Studio. MovieExec
9) WHERE presC# = cert# AND netWorth < 10000000
)
)
Рис. 6.9. Утверждение SQL3
Строка (I) — обычное начало описания. В строках (2) —(6) перечислены события,
при которых утверждение вводится в действие
Напомним, что для пресечения всех возможных изменений БД, нарушающих
ограничение, введенное в строках (7) — (9), нужно проверить каждого нового
президента студии или изменение дохода некоторого администратора. Значит,
6.6 Триггеры a S0L3
293
строки (3) и (4) инициируют выполнение утверждения при введении кортежа
в Studio или при изменении номера сертификата президента студии (т.е при смене
президента). Строки (5) и (6) инициируют проверку при изменении чистого дохода
любого администратора или при удалении администратора, так как при этом может
нарушиться ограничение. Оно описано в строках (7) — (9), по существу, так же,
как и в примере 6.10 □
Главное различие между подходами SQL2 и SQL3 к утверждениям состоит в
том, что на рис. 6.9 явно показано, когда нужно производить проверку Поэтому
утверждения SQI.3 более удобны для разработчика СУБД системы и менее удобны
для пользователя по следующим причинам:
1 Пользователь должен обнаружить все события инициирующие проверку
заданного ограничения.
2 . Пользователь рискует привести БД в противоречивое состояние, если
события выбраны неправильно
6.6.4 Упражнения к разделу 6.6
Упражнение 6.6.1. Запишите триггеры, аналогичные представленным на рис. 6.8,
для событий вставки и удаления для MovieExec.
Упражнение 6.6.2. Запишите следующие три геры, или утверждения, SQL3,
основанные иа примере ”РС” из упражнения 4.1.1:
Product(maker, model, type)
PC(model, speed, ram hd, cd, pnee)
Laptop(model, speed, ram hd, screen, pree)
Prlnter(model, color, type, price)
*a) При изменении цены ПК не должно быть ПК с более низкой ценой
и такой же скоростью процессора.
Ь) При введении нового принтера установить, что номер его модели
существует в отношении Product.
!с) При любом изменении отношения Laptop средняя цена ПК-блокнотов
любого производителя должна быть не меньше 2 тыс. дол
! d) При изменении RAM или жесткого диска любого ПК объем жесткого
диска нового ПК должен превосходить объем его RAM минимум в 100 раз.
!е) При введении нового ПК, ПК-блокнота или принтера номер его модели
не должен входить в отношение PC, Laptop или Printer.
Упражнение 6,6.3. Для схемы БД упражнения 4.1.3
Classes(class, type country numGuns bore, displecement)
Shipsfname, class, launched)
Battlesfname, date)
Outcomes(ship, battle result)
запишите триггеры, или утверждения, SQL3. позволяющие выполнять следующие
условия:
*а) При добавлении нового класса в отношение Classes в него вводится так-
же корабль с именем этого класса и значением NULL вместо даты спуска
на воду.
294
Глава 6 Ограничения и триггеры в SQL
b) При вставке нового класса корабля водоизмещением более 35 тыс тонн
водоизмещение заменяется на значение 35 000.
!с) При вставке кортежа в отношение Outcomes корабль и сражение из этого
кортежа должны входить в отношения Ships н Battles соответственно:
в противном случае в оба эти отношения вставляются кортежи со значе-
ниями NULL в тех компонентах, в которых они необходимы.
' d) Вставка в отношение Ships или изменение его атрибута class разрешается
только в том случае, если ни одна из стран не имеет более 20 кораблей.
!! е) При любых обстоятельствах ни один корабль не может участвовать
в сражении, состоявшемся позже сражения, в котором он был потоплен.
Любое изменение, нарушающее это ограничение, отвергается.
! Упражнение 6.6.4 Запишите перечисленные ниже триггеры, или утверждения,
SQL3 для примера БД фильмов:
Movie(litle, year, length, inColor, studioName, producerC#)
StarsJnfmovieTitle. movieYear, starName)
MoveStarfoame address gender, birthdate)
MovieExec(name address, cert#, netWorth)
Studiofname, address, presC#)
Можете предположить, что условие должно выполняться перед попыткой
любого изменения БД и что лучше изменить БД (даже если изменение означает
вставку кортежей со значениями по умолчанию NULL), чем отвергать изменение.
а) При любом появлении кинозвезды в отношении Starsln она должна
появляться и в отношении MovieStar
b) Каждый администратор должен быть президентом киностудии или
продюсером фильма, или тем и другим одновременно.
с) В каждом фильме должно участвовать по крайней мере по одной
кинозвезде мужского и женского пола.
d) Любая студия должна выпускать не более 100 фильмов год.
е) Средняя продолжительность фильмов, выпушенных за год, не должна
превышать 120 минут.
5 Упражнение 6.6.5. В примере 6.17 мы действовали не лучшим образом, вы-
полняя сначала проверку, а затем изменения, если они не нарушают условия.
Можно допустить изменение, а затем отменить, если оно нарушает условие. Запи
шнте этот триггер.
6.7 Итоги
* Ограничения по ключу. Атрибут пли множество атрибутов можно объявить
ключом введя в описание реляционной схемы объявления UNIQUE или
PRIMARY KEY
+ Ограничение ссылочной целостности. Вводя в реляционную схему ключевые
слова REFERENCES или FOREIGN KEY, можно потребовать, чтобы значение
атрибута или множества атрибутов одного отношения было также значением
атрибутов первичною ключа в некотором кортеже другого отношения.
6.8 Литература к главе 6
295
* Основанные на значении ограничения CHECK. Можно проверять ограничение
на значение некоторого атрибута, добавляя в реляционную схему после
описания этого атрибута ключевое слово CHECK и условие, которое нужно
проверять. Можно также задать область в качестве типа атрибута и в описа-
нии этой области задать условие, которое нужно проверять.
+ Основанные на кортеже ограничения CHECK. Можно проверять условие,
относящееся к любому компоненту илг ко всем компонентам кортежей
отношения, добавив ключевое слово CHECK и данное условие описание
самого отношения.
♦ Утверждения Утверждения можно описать как элемент схемы БД с ключе-
вым словом CHECK и условием, которое необходимо проверять. Это условие
может содержать одно или более отношений схемы БД а также отношение
в целом, например с агрегацией, и условия, касающиеся отдельных кортежей.
♦ Активизация проверок. Утверждения активизируются, когда изменение одного
из включенных в них отношений делает возможным нарушение ограничения
Основанные на значении и на кортеже проверки активизируются, когда ат
рибут или отношение, к которому они относятся, изменяется путем введения
или модификации кортежей. Поэтому такие ограничения могут нарушаться,
когда в них есть подзапросы, содержащие другие отношения или кортежи
одного и того же отношения.
+ Триггеры SQL3. Предполагаемый стандарт SQL3 включает в себя триггеры,
определяющие конкретные события (например, вставку, удаление или
изменение отдельного отношения), которые вводят эти триггеры в действие.
Введенное в действие условие можно проверять, и, если оно истинно, выпол-
няется определенная последовательность действий (SQL-предложений я виде
запросов и изменений БД).
+ Утверждения SQL3. В стандарте SQL3 есть понятие утверждения, отличаю
щееся от аналогичного понятия в SQL2. Подобно триггерам SQL3, эти утверж-
дения вводятся в действие одним или несколькими событиями, такими как
введение в отношение. При введении в действие утверждение SQL3 проверяет
условие, касающееся отношений или кортежей, и отвергает изменения, если
это условие не выполняется
6.8 Литература к главе 6
Информация о получении документов по стандартам SQL2 и SQL3 дана перед
списком литературы к главе 5. Книга [4] — источник информации по всем аспек-
там активных элементов систем БД. В книге [1] рассматриваются современные
идеи об активных элементах SQL3 и будущих стандартах. В работах [2] и [3] обсуж-
дается HiPAC, ранний прототип системы, содержащей активные элементы БД.
1. Cochrane, R. J., Н. Pirahesh, and N. Mattos, "Integrating triggers and declarative
constraints in SQL database systems," Inti. Conf, on Very Large Database Systems,
pp. 567-579, 1996.
2. Dayal, LL, et al., "The HiPAC project: combining active databases and timing
constraints'1, SIGMOD Record 17:1 pp. 51-70, 1988.
3. McCarthy, D. R., and U. Dayal, "The architecture of an active database
management system," Proc. ACM SIGMOD Inti. Conf, on Management of Data,
pp. 215-224, 1989.
4. Widom, J. and S. Ceri, Active Database Systems, Morgan Kaufmann. San Francisco,
1996.
Глава 7
Системные аспекты SQL
Рассмотрим, как SQL вписывается а полную среду программирования. По
всем затронутым далее вопросам мы будем следовать стандарту SQL2. В разделе 7.1
показано, как SQL обычно применяется в программах, написанных на стандартном
языке программирования (типа С). SQL имеет ряд средств перемещения данных
между собственными отношениями и переменными окружающего, или "главного",
языка.
В разделе 7.2 содержится введение в транзакции — атомарные единицы работы.
Многие приложения БД, например банковские, требуют, чтобы операции с данны-
ми выглядели атомарными и неразделимыми, даже если при этом параллельно
выполняется множество операций. В SQL есть средства определения транзакций
и механизмы, обеспечивающие автоматическое их выполнение.
В разделе 7.3 рассматриваются дополнительные вопросы такие как поддержка
модели вычисления клиент/сервер. В разделе 7.4 показано, как SQL контролирует
неавторизованный доступ к данным и как определить в системе SQL авторизован-
ный доступ.
7.1 SQL в среде программирования
До сих пор в примерах использовался непосредственный язык SQL, т.е. предпо-
лагалось, что имеется интерпретатор SQL. принимающий и выполняющий запросы
и команды SQL. Такой способ действия применяется редко. На практике большин-
ство операторов SQL являются частью более крупной программы или множества
функций. Правильнее считать, что существует программа в обычном главном языке
типа С, но некоторые функции в этой программе или некоторые операторы внутри
программ С в действительности являются операторами SQL, В этом разделе пока-
зано, как SQL может работать с обычной программой.
Краткая схема типичной системы программирования, содержащей операторы
SQL, изображена на рис. 7.1.
Программист пишет программы на главном языке, но в них встраиваются спе-
циальные операторы SQL, не являющиеся частью главного языка. Вся программа
посылается на препроцессор, заменяющий встроенные операторы SQL на осмыслен-
ные выражения главного языка. Представление SQL может быть таким же простым,
как вызов функции которая получает SQL-предложение как аргумент, состоящий
из строки символов, и выполняет это SQL предложение. На рис. 7.1 показано, что
программист может писать программу на главном языке, применяя такие вызовы
функций по мере необходимости.
Затем программа главного языка после препроцессора компилируется обычным
способом. Поставщик СУБД обычно предоставляет библиотеку с определениями
необходимых функций. Таким образом, можно выполнить функции, реализующие
SQL, и вся программа будет работать как единое целое.
7.1 SQL в среде программирования
297
Встроенный SQL
I
Препроцессор
т
Ч Главный язык
► +
Вызовы функций
I
Компилятор главного языка ч-
Программа главного языка
Библиотека SQL
Рис. 7.1. Выполнение программ с операторами SQL
Языки стандарта SQL2
Реализации SQL2 должны поддерживать по меньшей мере семь главных
языков: ADA, С, Cobol, Fortran, М (прежнее название — Mumps), Pascal и PL/I.
Студенты, изучающие компьютерную науку, должны знать все эти языки,
исключая, может быть, М, который ранее применялся медицинским сообще-
ством. В наших примерах используется С.
7.1.1 Проблема несогласованности моделей
Основная проблема связи операторов SQL с обычным языком программирова-
ния состоит в полной несогласованности моделей. Так называется слишком большая
разница между моделями данных SQL и моделями других языков. Ядром SQL явля-
ется реляционная модель данных, а С и другие обычные языки программирования
используют модели данных с целыми и реальными числами, арифметическими
выражениями, символами, структурами записей, наборами и т.д. В С или в других
подобных языках невозможно прямо выразить множества, а в SQL прямо не ис-
пользуются указатели, наборы и другие обычные конструкции языка программиро-
вания. В результате переход между SQL и другими языками оказывается непростым
и необходим специальный механизм разработки программ, сочетающих в себе эти
языки.
Может показаться, что лучше использовать один язык —либо выполнять все
вычисления на SQL, либо забыть о нем и вообще выполнять все вычисления на
обычном языке. Но полезность SQL становится очевидной, когда речь заходит об
операциях на БД. Системы SQL существенно помогают программисту при написа-
нии операций БД, которые можно эффективно выполнять и в то же время выра
жать на очень высоком уровне. SQL освобождает программиста от необходимости
разбираться в том, как организованы данные в памяти или как использовать струк
туру памяти для эффективной работы с БД.
2S8
Глава 7 Системные аспекты SOL
Оды. ко множество важных вещей SQL вообще неспособен делать. Например,
невозможно записать запрос SQL о вычислении факториала числа по формуле
п |»! = и > (п - I) >... '2 11. а это всего лишь простое упражнение в С пли в сход-
ных с ним языках. SQL не может прямо форм.тировать своп вывод в удобном
виде, в частности графически. Таким образом, в реальном программировании БД
нужны и SQL. । обычный язык, часто называемый главным.
7.1.2 Интерфейс SQL/главный язык
Передача информации между БД. которая достижима только с помощью опе-
раторов SQL и программой главного языка выполняется через переменные главно-
го языка которые можно прочитать или записать с гюмошыо запросов SQL. Перед
такими разде шемыми переменными ставится двоеточие, когда они используются
в SQL-предложениях. В операторах главного языка они появляются без двоеточия.
Пр । необходимости использовать SQL-предложение в программе главного
языка перед ним ставятся ключевые слова EXEC SQL. Обычная система обрабаты-
вает их н заменяет подходящими вызовами функции в главном языке, используя
при этом связанную с SQL библиотеку функций.
Для связи программы главного языка с системой выполнения SQL предложе-
нии применяется переменная, носящая в стандарте SQL2 название SQLSTATE.* 1
Тип SQLSTATE —эго массив нз пяти символов. При каждом вызове функции из
библиотеки SQL и переменную SQLSTATE помещается код, обозначающий любую
проблему, обнаруженную во время этого вызова. Например. *00000 (пять нулей)
означает, что не возникло никаких ошибок; *02000' означает что кортеж, который
должен быть частью ответа на запрос SQL. не обнаружен. Программа главного языка
может прочесть значение SQLSTATE и на его основе принять решение
7.1.3 Раздел DECLARE
Для объявления разделяемых переменных их определения помещаются между
двумя встроенными операторами SQL;
EXEC SQL BEGIN DECLARE SECTION;
EXEC SQL END DECLARE SECTION;
Все, что находится между ними, называется разделом объявлений. Форма опи-
сания переменной в этом разделе должна соответствовать требованиям главного
языка. Более того, разумно приписывать переменным типы, приемлемые и для
главного языка, и для SQL например целые и действительные числа, строки
символов пли наборы.
Пример 7.1. Следующие операторы миут входить и функцию языка С, изменя-
ющую отношение Studio:
EXEC SQL BEGIN DECLARE SECTION,
char studioName[15j, studioAddr[50];
char SQLSTATE[6];
EXEC SQL END DECLARE SECTON,
Первая и последняя строки — обязательные начало и конец раздела объявлений.
Между hiimi находится оператор, описывающий переменные studoName и studioAddr.
1 В системах. нс реализующих стандарт SQL2, может применяться другая переменная.
i ы пол ник пая ту же ро. ь
7.1 SOL в среде программирования
299
Обе они являются массивами символов и могут быть использованы для хранения
имени и адреса студии, из которых строится кортеж, вставляемый в отношение
Studio. На третьей строке SQLSTATE определяется как набор в шесть символов? □
7.1- 4 Применение разделяемых переменных
Разделяемую переменную можно использовать в SQL предложениях вместо
конкретного значения. Напомним, что при этом перед ней должно стоять двоето
Чпе. Приведем пример, где переменные из примера 7 1 используются в качестве
компонентов кортежа, который нужно вставить в отношение Studio.
Пример 7.2 На рис. 7.2 приведена краткая запись функции getStudio языка С,
которая запрашивает у пользователя название и адрес студии, читает ответы и
вставляет подходящий кортеж в отношение Studio.
void getStudioQ {
1) EXEC SQL BEGIN DECLARE SECTION;
2) char studioName[15), stud©Addr[50].
3) char SQLSTATE[6),
4) EXEC SQL END DECLARE SECTION;
/• напечатать запрос о введении названия и адреса
студии и прочитать ответ в переменных
studioName и studioAddr*/
5) EXEC SQL INSERT INTO Studiofname, address)
6) VALUES (rstudioName, studioAddr);
Рис. 7 2. Применение розделяемых переменных для вставки новой студии
Строки (I) — (4) — это описание из примера 7 I. Часть программы, печатающая
запросы и сканирующая текст для заполнения наборов studioName и studioAddr,
пропущена.
Строки (5) и (6) содержат встроенное SQL-предложение — обычное предложе-
ние вставки INSERT Ему предшествуют ключевые слова EXEC SQL, означающие,
что это действительно встроенное SQL предложение, а не грамматически неправиль-
ная программа С. Препроцессор, изображенный на рис. 7 I, будет искать EXEC SQL
дпя обнаружения предложений, которые необходимо предварительно обработать.
Значения, введенные на строках (5) и (6),— это не явные константы, как
в примере 5 77 Значения на строке (6) — разделяемые переменные, текущие значс
ния которых становятся компонентами вставляемого кортежа. □
Кроме INSERT, есть множество видов SQL-предложений, которые можно
встраивать в главный язык, используя разделяемые переменные в качестве интер-
фейса. Каждому такому предложению в программе главного языка предшествуют
ключевые слова EXEC SQL, и в нем вместо констант можно применять разделяемые
переменные В главный язык может быть встроено любое SQL-предложение, не
г Для 5-симпольного значения SQLSTATE мы будем применять шесть символов. так как
в дальнейших программах для проверки, имеет ли SQLSTATE определенное значение
будет использована функция stremp языка С. Поскольку stremp предполагает,
что строки завершаются символом 30’, для этой отметки конца строки нужен
шестой символ Шестой символ должен быть первоначально установлен в W.
но в дальнейших программах мы не будем явно показывать эту установку
300
Глава 7 Системные аспекты SQL
возвращающее результата (т.е. нс являющееся запросом). Примерами таких пред-
ложений служат стандартные операторы вставки, удаления и изменения, а также
операторы создания, изменения или удаления элементов схемы типа таблиц или
представлений.
Запросы типа select-froin-where невозможно встроить в главный язык по при-
чине несогласованности моделей В качестве результата запросы порождают мно-
жества кортежей, в то время как ни один нз главных языков непосредственно не
тоздерживает множественный тип данных. Поэтому встроенный SQL должен
использовать один из двух механизмов связи результата запроса с программой
главного языка
I Запрос, порождающий единственный кортеж, может хранить его в разде-
ляемых переменных, используя по одной такой переменной для каждого
компонента кортежа. Для этого применяется модифицированная форма
sclecr-from-wliere, называемая оператором выбора единственной строки
(single-row select).
2. Запросы, порождающие более одного кортежа, можно выполнять, опреде-
лив курсор запроса. Курсор пробегает по всем кортежам результирующего
отношения и при этом каждый кортеж может быть считан в разделяемые
переменные и обработан программой главного языка.
7.1.5 Операторы выбора единственной строки
Оператор выбора единственной строки отличается от select from-where только
тем, что в нем за пунктом SELECT следует ключевое слово INTO и список разде-
ляемых переменных. Этим переменным как и всем разделяемым переменным
в операторе SQL, префиксируются столбцы. Если результатом запроса является
единственный кортеж, его компоненты становятся значениями этих переменных.
Если же в результате отсутствует кортеж или имеется несколько кортежей, разде-
ляемым переменным не приписывается никаких значений и в переменную
SQLSTATE записывается подходящий код.
Пример 7.3. Запишем функцию С для чтения названия студии и печати чистого
дохода ее президента Краткая запись такой функции приведена на рис. 7.3.
void printNetWorthQ {
1) EXEC SQL BEGIN DECLARE SECTION;
2) char studicName[15];
3) int presNetWorth;
4) char SQLSTATE[61;
5) EXEC SQL END DECLARE SECTION;
/* напечата ь запрос о введении названия
студии и прочитать ответ е переменной
studioName */
6) EXEC SQL SELECT netWorth
7) INTO presNetWorth
8) FROM Studio, MovieExec
9) WHERE presC# = cert# AND Studio name - studioName;
I* проверить, содержит пи SQLSTATE одни нули, и если
это так, напечатать значение presNetWorth*/
}
Рис. 7.3. Выбор единственной стропи, встроенный в функцию С
7.1 SQL s среде программирования
301
Строки (.1) — (5) — это раздел описания необходимых разделяемых переменных.
Далее следуют не показанные явно операторы С, извлекающие название студии из
стандартного ввода. Строки (6) — (9) — оператор выбора единственной строки,
отличающий от стандартного запроса SQL по двум параметрам. В условии WHERE
вместо константы используется значение переменной studioName, а в строке (7)
введен пункт INTO, указывающий, куда помещать результат запроса. В данном
случае предполагается, что п результате получается единственный кортеж и что
кортежи имеют только один компонент для атрибута netWorth. Значение этого
компонента хранится в разделяемой переменной presNetWorth типа "натуральное
число”. □
7.1- 6 Курсоры
Наиболее гибким методом связи SQL с главным языком являются курсоры,
пробегающие по кортежам отношения. Это отношение может быть хранимой
таблицей или генерироваться запросом. Для создания и применения курсора
необходимо следующее:
I. Описание курсора. Наиболее простая форма описания курсора включает
в себя:
а) вводные ключевые слова EXEC SQL, как и во всех встроенных опера-
торах SQL;
b) ключевое слово DECLARE;
с) имя курсора;
d) ключевые слова CURSOR FOR;
е) выражение типа имени отношения или выражение select-from-where,
значением которого является отношение. Курсор пробегает по корте-
жам отношения, т.е. при его "вызове” относится к каждому кортежу
данного отношения.
Форма описания курсора:
EXEC SQL DECLARE <курсор> CURSOR FOR <запрос>
2. Оператор EXEC SQL OPEN, за которым следует имя курсора. Этот оператор
инициирует курсор в позиции, откуда он готов извлечь первый кортеж
отношения, по которому пробегает курсор.
3. Одно или несколько применений предложения FETCH< предназначенного
для получения следующего кортежа отношения, по которому пробегает
курсор. Если перебор кортежей закончен, никакой кортеж не возвращает-
ся и значение SQLSTATE устанавливается в ‘02000’ — это означает, что
ни один кортеж не найден. В предложение FETCH входят следующие
компоненты:
(а) ключевые слова EXEC SQL FETCH FROM;
(b) имя курсора:
(с) ключевое слово INTO;
(d) список переменных, разделенных запятыми При наличии кортежа,
который нужно выбрать, его компоненты размещаются в этих пере-
менных по порядку.
Форма предложения FETCH:
EXEC SQL FETCH FROM <курсор> INTO <список псременных>
302
Глава 7 Системные аспекты SOL
4. One] атор EXEC SQL CLOSE, за которым следует имя курсора. Этот
one, пор закрывает курсор, который больше те пробегает по кортежам
отношения. Однако его можно снова ввести в действие другим оперзто
ром OPEN и он в юнь будет пробегать кортеж! этого же отношения.
Пример 7.4. Требуется определить число администраторов фильмов, чьи * ис-
-ые доходы выетраи киоте} в последовательность экспоненциально возрастающих
диапа нон. каждый из которых соответствует количеству цифр, выражающих
доход администратора Сформулируем запрос, извлекают! fl поле networth из всех
кортежей отношения MovieExec в разделяемую переменную worth. Курсор с зменем
execCursor будет пробегать по всем этим однокомпонентным кортежам. При каж-
дом вь боре кортежа подсчитывается количество цифр в натуральном числе worth
и увеличивается подходя и и и элемент набора counts.
1) void worthRangesQ {
2) int i digits, counts 15];
3) EXEC SQL BEGIN DECLARE SECTION;
4) int worth;
5) char SQLSTATE[6];
6) EXEC SQL END DECLARE SECTION;
7) EXEC SQL DECLARE execCursor CURSOR FOR
8) SELET netWorth FROM MovieExec;
9) EXEC SQL OPEN execCursor,
10) for(i=0; i<15; i++) counts[i] = 0;
11) while(1){
12) EXEC SQL FETCH FROM execCursor INTO :worth;
13) if(NO MORE TUPLES) break
14) digits =1;
15) while((worth /= 10) > 0) d gits++;
16) ii (d igits <= 141 counts[d g its]++,
)
17) EXEC SQL CLOSE execCursor,
18) for(i=0 <15, ++)
19) printffr igits = %d‘ number of execs = %d\n"
i, counts]]);
)
Рис. 7.4. Сведение доходов администроторов в экспоненциальные диапазоны
Описи! к функции worthRanges начинается на строке (1) рис 7.4. Строка (2)
описывает переменные, используемые только функцией С, но не встроенных SQL
Набор count содержг т счета администраторов в разтичных диапазонах dgits
перешиты: ет количество цифр в чистом доходе, a i--индекс. пробегающий по
элементам набора counts.
Строки (3 —(6) —это раздел описания SQL, в котором заданы разделяемая
переменная worth и обычная SQLSTATE. Строки (7) и (8) означают, что курсор
execCursor пробегает по значениям порождаемым запросом строки (8) Запрос
относится к компонентам networth всех кортежей отно :ения Mov Exec. Курсор
открывает я на строке (9) Строка (10) завершает инициализацию превращая в ну i
эдеме» ы паб pa counts.
7.1 SOL в среде программирования
303
Основная, работа выполняется циклом на строках (III —(I6) На строке (I2)
выбранный кортеж вносится в переменную worth. Поскольку кортежи, порождае-
мые запросом строки (S). имеют только один компонент, нужна всего одна разде-
ляемая переменная, хотя в общем случае требуется столько переменных, сколько
компонентов входит в извлекаемые кортежи Строка (I3) контролирует успешность
выбора кортежей. Здесь применяется макрокоманде NO_MORE_TUPLES. которая
может быть определена как
#define NO_MORE_TUPLES ! (strcmp(SQLSTATE."02000' j)
Напомним, что ’02000" —это содержание SQLSTATE означающее, что не найдено ни
одного кортежа. В таком случае цикл прерывается, н выполняется переход к строке (17).
Если кортеж был выбран, на строке (14) число цифр в чистом доходе устанав-
ливается в I. Строка (15) — это цикл, который повторно делит чистый доход на 10
н увеличивает digits на I. Когда чистый доход после деления на 10 превращается
в 0. digits содержит верное количество цифр в значении переменной worth, которое
было первоначально извлечено. И наконец, строка (16) увеличивает подходящий
элемент набора counts на I. Предполагается, чго количество цифр не превышает 14.
При наличии же чистого дохода с 15 цифрами и более, строка (16) не увеличивает
ни один элемент counts, так как не существует подходящего ранга, т.е. 1 истьй
доход ненормальной величины отбрасывается и не влияет на статистику.
Строка (17) завершает действие функции Курсор закрывается, и строки (18)
и (19) печатают значения в наборе counts. □
7.1.7 Изменения с использованием курсора
Когда курсор пробегает по кортежам таблицы базы (т.е. отношения, которое
хранится в БД, а не представления или отношения, порождаемого запросом), можно
не только считывать и обрабатывать значения каждого кортежа, но также изменять
пли удалять этот кортеж. Синтаксис операторов UPDATE и DELETE отличается от
синтаксиса, введенного в разделе 5.6 только пунктом WHERE. Здесь он должен
содержать ключевые слова WHERE CURRENT OF, за которыми следует имя курсо-
ра. Разумеется, программа главного языка, читающая кортеж, может применять
любое условие его изменения или удаления.
Пример 7.5. На рис. 7.5 описана функция С, аналогичная функции, представ-
ленной на рис. 7.4. Обе они вводят курсор execCursor, пробегающий по кортежам
отношения MovieExec Однако первая из них просматривает каждый кортеж и ре-
шает. удалить его или удвоить чистый доход.
Здесь снова применяется макрокоманда NO_MORE_TUPLES для условия, со-
гласно которому переменная SQLSTATE с кодом "02000" означает "кортежей
больше нет". На строке (12) проверяется величина чистого дохода, и если они
меньше 1000 дол., кортеж удаляется оператором DELETE на строке (13). Если
чистый доход составляет минимум 1000 дол., он удваивается на строке (15). □
7.1.8 Опции курсора
SQL.2 обеспечивает различные опции курсора.
I. Можно определить порядок, в котором кортежи выбираются
НЗ ОТНОШС1 ИЯ.
2. Можно ограничить результат изменений отношения, по которому
пробегает курсор.
3. Можно варьировать движение курсора по списку кортежей.
Подробности этих режимов рассматриваются в разделах 7.1.9—7.1.11.
304
Глава 7 Системные аспекты SQL
1) void changeWorth() {
2) EXEC SQL BEGIN DECLARE SECTION'
3) int worth;
4) char SQLSTATE[6];
5) EXEC SQL END DECLARE SECTION;
6) EXEC SQL DECLARE execCursor CURSOR FOR
7) SELECT netWorth FROM MovieExec;
8) EXEC SQL OPEN execCursor;
9) while(1) {
10) EXEC SQL FETCH FROM execCursor INTO worth;
11) if(NO_MORE_TUPLES) break;
12) if (worth < 1000)
13) EXEC SQL DELETE FROM MovieExec
WHERE CURRENT OF execCursor;
14) else
15) EXEC SQL UPDATE MovieExec
SET netWorth = 2 * netWorth
WHERE CURRENT OF execCursor;
}
16) EXEC SQL CLOSE execCursor;
}
Рис. 7.5. Изменение чистых доходов одминистроторое
7.1.9 Упорядочение выбираемых кортежей
Рассмотрим сначала порядок кортежей. Их можно выбирать по порядку, соглас-
но значению каждого компонента. Порядок вводится в соответствии с определением
отношения, которое пробегает курсор, с помощью ключевых слов ORDER BY и спис-
ка используемых при сортировке компонентов, точно так же как и в запросах из
раздела 5.1.5 Компоненты определяются атрибутом или числом. Во втором случае
число — это номер позиции атрибута среди других атрибутов отношения
Пример 7.6. Предположим, нужно проверить кортежи отношения, введенного
путем объедг нения отношений Movie и Starsln, и последующей проекции, резуль-
татом которой являются только название фильма, год, кинозвезда и студия. Нуж-
но также упорядочить кортежи по году выпуска фильма, а кортежи с одним
и тем же годом сгруппировать по названию фильма в алфавитном порядке.
Курсор moveStarCursor пробегающий по такому отношению, описан на рис. 7 6. 1 2 3 4 5
1) EXEC SQL DECLARE moveStarCursor CURSOR FOR
2) SELECT title, year, studio, starName
3) FROM Mov e, Starsln
4) WHERE title ~ movieTitle AND year = movieYear
5) ORDER BY year tite;
Рис. 7.6. Применение ORDER BY для контроля за порядком выбираемых кортежей
Строки (1) (4) эта обычный оператор SELECT, а в строке (1) задан Kvpcop.
пробегающий по кортежам этого отношения Согласно строке (э) при выборе
7 1 SOL в среде программирования 305
кортежей через курсор movieStarCursor первыми будут выбраны кортежи с более
ранними голами. Названия фильмов одного и того же года будут упорядочены по
алфавиту, поскольку именно так упорядочены значения, представленные строками
символов. Никакой порядок для кортежей, представляющих кинозвезд одного и
того же фильма здесь не установлен. □
7.1.10 Предотвращение
одновременных изменений
Рассмотрим случай, когда одна функция читает кортежи посредством курсора
movieStarCursor из примера 7.6. а другая одновременно выполняемая функция (или
даже та же самая функция) изменяет базовое отношение Movie или Starsln. Более
подробно об одновременном протекании нескольких процессов в единственной БД
будет сказано в разделе 7.2. Здесь мы просто допустим, что при использовании
отношения другой процесс может изменять его.
Что же делать в подобной ситуации? Возможно вообще ничего Предположим,
нужно найти кортежи для конкретных кинозвезд. Тогда неважно увидим ли мы
кинозвезд, кортежи для которых вводятся или удаляются; просто принимаются
кортежи, полученные с помощью курсора.
Однако иногда необходимо запретить одновременные изменения кортежей
которые получаются с помощью курсора. Например, если кортежи просматривав •
мые функцией, вынуждают ее добавлять новые кортежи в Starsln, может возник
нуть бесконечный цикл, в котором новые кортежи генерируют через курсор
дополнительные кортежи, а последние, в свою очередь, создают новые кортежи.
Если есть риск такого или какого-либо другого нежелательного явления, курсор
нужно объявить нечувствительным к одновременным изменениям
Пример 7.7. Строку (1) на рис. 7 6 можно заменить строкой
1) EXEC SQL DECLARE movieStarCursor INSENSITIVE CURSOR FOR
При таком описании курсора movieStarCursor система SQL гарантирует, что
изменения отиошег ий Movie и Starsln, сделанные между открытием и закрытием
курсора не повлияют нв множество выбра! ных кортежей □
Нечувствительный курсор может дорого обойтись в том смысле, что системой
SQL будет затрачено много времени на управление доступом к данным, гарантиру
юшим нечувствительность курсора. Управление параллельными операциями на БД
обсуждается в разделе 7.2. Здесь же упомянем лишь один способ поддержки нечув
ствительного курсора. Система SQL должна останавливать любой процесс, способ-
ный затронуть базовые отношения Movie и Starsln
Есть пробегающие отношение Л курсоры о которых можно определенно
сказать, что они не изменяют R. Такой курсор может пробегать R параллельно
с нечувствительным курсором, без риска изменить отношение Л, которое видит
последний. При задании курсора FOR READ ONLY СУБД получает гарантию, что
базовое отношение не будет изменено из-за доступа к отношению через этот
курсор.
Пример 7.8. К рис. 7.6 можно добавить строку
6) FOR READ ONLY
В результате любая попытка выполнить UPDATE или DELETE с помощью курсора
movieStarCursor приведет к ошибке. □
306
Глава? Системные аспекты SQL
7.1.11 Курсоры прокрутки
Последний нт режима курсора — выбор способа перемещения по кортежам
отношения. Принятый no умолчанию и наиболее распространенный способ—на-
чать с начала if выбирать кортежи по порядку до конца. Но существуют и другие
порядки выбора кортежей it кортежи можно сканировать несколько раз до закры-
тия курсора. Для НСПОЛ1-ЮВ.1ННЯ таких режимов необходимо выполнить следующее:
I. При ОШ1С11НИ1 курсора перед ключевым словом CURSOR ставится ключе-
ное слово SCROLL. Оно означает, что система SQL может использовать
курсор иначе, чем просто двигать его вперед по порядку кортежей.
2. В предложении FETCH за ключевым словом FETCH стоит одно из следую-
щих ключевых слов, указывающих. где именно искать нужный кортеж;
(at NEXT пли PRIOR применяется для получения следующего или преды-
дущего по порядку кортежа относительно текущей позиции курсора:
NEXT принимается по умолчанию, если не задан никакой другой
режим;
(b) FIRST или LAST используется для получения первого или последнего
по порядку кортежа;
(с) RELATIVE, за которым следует положительное или отрицательное на-
туральное число, указывает на сколько кортежей продвинуться вперед
(при положительном числе) или назад (при отрицательном), например-
RELATIVE 1 — это синоним NEXT, a RELATIVE-1 — синоним PRIOR;
(d) ABSOLUTE, за которым следует положительное пли отрицательное
натуральное число, указывает позицию нужного кортежа, считая
с начала (при полож цельном числе) или с конца (при отрицательном):
например: ABSOLUTE 1 — это синоним FIRST, a ABSOLUTE-1 — си-
ноним LAST.
Пример 7.9. Перепишем функцию на рис. 7 5 так, чтобы начать с последнего
кортежа и двигаться по списку кортежей. Сначала нужно объявить курсор execCursor
перемещаемым, добавив в строку (6) ключевое слово SCROLL:
6) EXEC SQL DECLARE execCursor SCROLL CURSOR FOR
7) SELECT netWorth FROM MovieExec;
Необходимо также ипицпировать выбор кортежей с помощью предложения
FETCH LAST и применить п цикле FETCH PRIOR. Цикл на строках (9) —(15) изме-
няется следующим образом:
EXEC SQL FETCH LAST FROM execCursor INTO worth;
while(1) {
/* то же самое, что и в строках (11) — (15) */
EXEC SQL FETCH PRIOR FROM execCursor INTO worth
}
He следует думать, что лучше читать кортеж и порядке, обратном тому, в котором
их генерирует зап|Х>с
SELECT netWorth FROM MovieExec
Фактически это может обойтись системе дороже, поскольку все кортежи могут
быть построены и упорядочены перед первым выбором из execCursor. □
7.1 SOL в среде программирования
307
7-1.12 Динамический SQL
Рассмотренная выше модель SQL, встроенного в главный язык, состояла из
особых запросов и команд SQL внутри написанной на главном языке программы.
Однако есть более обший способ погружения SQL в другой язык. Сами SQL-опера-
торы могут вычисляться главным языком. Они неизвестны во время компиляции,
и поэтому их не может обрабатывать препроцессор SQL или компилятор главного
языка.
Такую ситуацию иллюстрирует программа, которая требует от пользователя
запрос, читает его и выполняет. Пример подобной программы — интерпретатор
ad hoc запросов SQL, предполагавшийся в главе 5. Интерпретаторы этого типа
есть во всех коммерческих системах SQL. Если запросы читаются и выполняются
в реальном времени, компиляции не происходит Запрос должен быть выделен
синтаксически, и система SQL должна найти способ его выполнения немедленно
после его прочтения.
Программа главного языка должна указывать системе SQL, какую строку
читать в данный момент, переводить ее в выполнимый оператор SQL и выполнять
этот оператор. Эти шаги выполняются двумя операторами динамического SQL:
I. EXEC SQL PREPARE, за которым следуют SQL-переменная К ключевое
слово FROM и переменная главного языка или выражение типа символьной
строки. Этот оператор превращает строку в SQL-предложение, которое
становится значением переменной V. Предполагается, что SQL предложе-
ние синтаксически проанализировано и системой SQL найден хороший
путь его выполнения, но предложение не выполнено.
2. EXEC SQL EXECUTE, за которым следует SQL-переменная типа V из
пункта (1). Этот оператор реализует выполнение SQL-предложения, обо-
значенного переменной И
Оба шага можно соединить в один с помошью оператора
EXEC SQL EXECUTE IMMEDIATE
за которым следует разделяемая переменная или выражение со значением в виде
строки. Недостаток такого объединения проявляется тогда, когда предложение
формулируется один раз а выполняется многократно. При применении EXECUTE
IMMEDIATE приходится подготавливать предложение при каждом его выполнении,
вместо того чтобы сделать это один раз.
Пример 7.10. На рис. 7.7 дано краткое описание программы С, которая считы-
вает текст нз стандартного ввода в переменную query, готовит и выполняет его.
1) void readQueryO {
2) EXEC SQL BEGIN DECLARE SECTION,
3) char ‘query,
4) EXEC SQL END DECLARE SECTION
5) /* потребовать у пользователя запрос, выделить пространство и
установить разделяемую переменную query на первый
символ запроса */
6) EXEC SQL PREPARE SQLquery FROM query,
7) EXEC SQL EXECUTE SQLquery,
}
Рис, 7.7. Подготовке и выполнение эопросо динамического SQL
зев
Глава 1 Системные аспекты SQL
Переменная SQLquery языка SQL содержит подготовленный запрос. Поскольку
запрос выполняется только один раз строки (6) и (7) рис. 7.7 можно заменить
единствеин ы м оп ератором
EXEC SQL EXECUTE IMMEDIATE query, □
7.1.13 Упражнения к разделу 7.1
Упражнение 7.1.1. Запишите перечисленные ниже встроенные запросы SQL,
основанные на схеме БД упражнения 4.1.1:
Product!maker, model, type)
PC(model, speed, ram, hd, cd, price)
Laptop(model, speed ram. hd screen, price)
Pnnter(model color, type, pnee)
Можно использовать любой известный вам главный язык, а детали программирова
ння на нем заменить ясными комментариями.
*а) Запросите у пользователя цену и найдите ПК, цена которого наиболее
близка к цене названной пользователем. Напечатайте производителя, но-
мер модели и скорость этого компьютера.
Ь) Запросите у пользователя минимальные приемлемые для него значения
скорости, RAM, размера жесткого диска и размера экрана Найдите
ПК-блокноты, удовлетворяющие этим требованиям Напечатайте их спе-
цификацию (все атрибуты laptop) и производителя.
!с) Запросите у пользователя имя производителя. Напечатайте специфика
цию всех его продуктов, т.е. номер модели, тип и все атрибуты любого
отношения, подходящего для данного типа.
!! d) Запросите у пользователя бюджет" (общую иену ПК и принтера). Найдите
самую дешевую систему (ПК с принтером), которая находится в рамках
этого бюджета, обладает минимальной скоростью, но желательно с цвет-
ным принтером. Напечатайте номера моделей выбранной системы.
е) Запросите у пользователя имя производителя, номер модели, скорость,
RAM, размер жесткого диска, скорость CD и цену нового ПК Убедитесь,
нс существует ли уже ПК с таким номером модели. Если существует,
напечатайте предупреждение: в противном случае введите I нформацию
в отношения Product и PC
*! f) Уменьшите иену всех старых" ПК на 100 дол Убедитесь, что во время
выполнения вашей программы не понизилась цена ни одного "нового”
компьютера
Упражнение 7.1 2. Запишите перечисленные ниже встроенные запросы SQL,
основанные на схеме БД упражнения 4.1.3
Classes(clsss, type, country, numGuns, bore, displacement)
Ships(name, class, launched)
Battles(name, date)
Outcomes(ship battle, result)
а) Огне гая мощь корабля прямо пропорциональна числу орудий, умноженно-
му на куб калибра орудий. Найдите класс с наибольшей огневой мошью.
! Ь) Запросите у пользователя название сражения. Найдите страны, владею-
щие кораблями, участвовавшими в этом сражении Напечатайте название
страны, наибольшее число кораблей которой было потопленс и название
7 2 Транзакции в SQL
309
страны, наибольшее число кораблей которой было повреждено
сражении. Этом
С) Запросите у пользователя имя класса и другую информацию, необхсив
мую для кортежа таблицы Classes, а также список названий корабле "
этою класса и даты их спуска на воду. При этом пользователь не обязан
сообщать первое слово названия корабля, являющееся именем класса
d) Проверьте, есть ли в отношениях Battles, Outcomes и Ships корабли уча-
ствовавшие в сражении до спуска их на воду При наличии ошибки пред-
ложите пользователю режим изменения даты спуски на воду или даты
сражения. Выполните любое из запрошенных изменений.
*1 Упражнение 7.1.3. В отношении
PC(model, speed, ram, hd, cd, price)
нужно найти все П К, для которых есть по крайней мере два более дорогих компью-
тера с такой же скоростью. Существует множество способов решения этой задачи,
но вы должны применить перемещаемый курсор. Прочтите кортежи, упорядоченные
сначала по speed, а затем по price. Подсказка. После прочтения каждого кортежа
пропускайте два кортежа, чтобы проверить, не изменяется ли значение speed.
!! Упражнение 7.1.4. В разделе 7 1.1 было сказано, что в SQL невозможно напи-
сать факториальную программу. Это верно для SQL2, но рекурсия SQL3, описан-
ная в разделе 5.10, позволяет сделать нечто подобное. Запишите запрос SQL3,
применимый к отношению М, содержащему единственный кортеж (дт), где т — на-
туральное число. Результатом запроса должно быть множество кортежей (л, п!),
где I s п < т.
7.2 Транзакции в SQL
В рассматриваемой модели операций на БД единственный пользователь за-
прашивает или изменяет БД. При этом операции на БД выполняются по одной
в каждый момент времени, и каждая следующая операция выполняется над БД, на-
ходящейся в том состоянии, в какое она была приведена предыдущей операцией.
Более того, предполагается, что каждая операция выполняется полностью, т.е в
процессе выполнения операции не может быть сбоя в программном или аппарат-
ном обеспечении и БД не может остаться в состоянии, которое нельзя представить
как результат выполнения операции
В действительности ситуация зачастую бывает намного сложнее Рассмотрим
сначала, как БД может прийти в состояние не отражающее выполняемую на ней
операцию, а затем перейдем к средствам SQL. дающим пользователю гарантию, что
этого не случится.
7.2.1 Преобразование
в последовательную форму
В приложениях типа банковских или систем бронирования авиабилетов на БД
выполняются согни операций в секунду на сотнях и тысячах узлов типа автоответ-
чиков, настольных компьютеров агентов по путешествиям, служащих авиалиний
пли самих клиентов. Вполне возможно, что две операции относятся к одному и
тому же счету или авиаренсу и перекрываются по времени. При этом они могут
взаимодействовать весьма странными способами. Приведем пример ошибок, кото-
рые могут возникнуть, если система управления БД абсолютно не ограничена
в плайе порядка воздействия иа БД Подчеркнем что обычно Б^та^не дейстцщют
310
Глава 7 Системные аспекты SOL
1 нужно выбрать какой-то искусственный путь, чтобы вызвать такие ошибки при
использовании коммерческой системы управления БД.
Пример 7.11 Предположим. записывается функция chooseSeat() для чтения
thouici ня. содержащего репсы и свободные места, для нахождения свободных
мсс и превращения их и запятые. Отношение называется Flights и содержит атри-
буты fltNum. fit Date. fitseat и occupied, смысл которых очевиден. Программа выбора
мест кратко записана на р ic. 7.8.
1) EXEC SQL BEGIN DECLARE SECTION;
2) int flight. I* номер рейса 7
3) char date[1O); Г дата рейса в формате SQL 7
4) char seat[3] /* место представлено двумя цифрами и буквой 7
5) int осс; Г булева переменная, означающая, занято место
или нет7
6) EXEC SQL END DECLARE SECTION;
7) void chooseSeatf) {
8) /* программа С, предлагающая пользователю ввести рейс,
дату и место и размещающая эти данные в трех
переменных с их именами 7
9) EXEC SQL SELECT occupied INTO .осс
10) FROM Flights
11) WHERE fltNum - Tight
AND fltDate = date
AND ftSeat_:seat
121 if (locc) {
13) EXEC SQL UPDATE Flights
14) SET occupied = 'BT
15) WHERE fltNum = flight
AND fltDate = date
AND fitSeat = seat,
16) I* операторы С и SQL для записи номера места
и сообщения пользователю этого номера 7
}
17) else Г операторы С для передачи пользователю сообщения
о недоступности места и просьбы выбрать
другое место 7
)
Рис. 7.8. Выбор мест
Строки (9) — (I I) — это выбор единственной строки, устанавливающий разде-
ляемую переменную осс в истинное или ложное значение (I или 0) в зависимости
от того, свободно или занято указанное место. Строка (12) проверяет занято пи
место, и если оно свободно, кортеж для этого места изменяется так что место
становится занятым. Это изменение выполняется на строках (13) —(15), а на
строке (16) место приписывается заказавшему его пользователю Практически
информацию о местах можно хранить в другом отношении. И наконец, если место
занято строка (17) сообщает об этом пользователю.
Функция chooseSeatf) может выполняться одновременно несколькими пользо-
вателями. Для простоты предположим, что два агента пытаются забронировать
одно в то же место на один и тот же рейс и дату приме) но в одно и то же время,
как показано на рис. 7 9
7.2 Транзакции в SQL
311
Время
Пользователь I
обнаруживает,
что место свободно
Пользователь 2
обнаруживает,
что место свободно
Пользователь 1
занимает место
Пользователь 2
занимает место
Рис, 7.9. Два пользователя одновременно пытаются забронировать одно и то же место
Оба пользователя одновременно достигают строки (9), и их копии локальной
переменной осс получают значение 0, т.е. в данный момент место свободно. На
строке (12) каждое выполнение chooseSeatQ заменяет данный бит на I. т.е. делает
данное место занятым. Возможно, эти изменения выполняются одно за другим и
строка (16) сообщает каждому пользователю о том, что место принадлежит ему. □
Пример 7.11 показывает, что обе операции можно выполнить правильно, а ре-
зультат при этом получится некорректным: оба пользователя верят, что получили
запрошенное место. Проблему можно решить с помошыо различных механизмов
SQL. которые служат для приведения двух функций в последовательную форму Вы-
полнение функций на одной и той же БД называется последовательным, если одна
из них выполняется полностью до начала выполнения другой. Выполнение функ-
ций приводится в последовательную форму, если они действуют последовательно,
даже если их выполнение частично совпадает по времени.
Если два вызова chooseSeatQ выполняются последовательно (приводимы
в последовательную форму), ошибки не произойдет. Один из пользователей делает
вызов первым, обнаруживает, что место свободно, и бронирует его. Затем следует
вызов второго пользователя, который обнаруживает, что место занято. Это может
обеспокоить пользователя, которому нужно место, но для БД важно только то,
чтобы место приписывалось лишь один раз.
Обеспечение последовательности действий.
Зачастую практически невозможно требовать, чтобы операции выполни- •
! лись серийно: их слишком много, и поэтому требуется их параллельное вы- j
полненне. Таким образом, системы управления базами данных используют 1
! механизмы обеспечения серийности действий; даже если выполнение опера- J
' ций не является серийным, результат выглядит для пользователя так. словно '
они выполнялись серийно
Как было показано в разделе 1.2.4. одним из обших методов обеспечения (
серийности для системы управления базой данных является блокировка ,
элементов базы данных таким образом, чтобы две функции не могли получить ;
! к ним доступ одновременно Например, если функцию chooseSeatQ из при- г
। мера 7.11 написать для блокировки других операций вне таблицы Flights, то I
; операции, не имеющие доступа к Flights, смогут выполняться параллельно i
* с вызовом функции chooseSeatQ. но не сможет выполняться никакой другой •
। вызов chooseSeatQ. Фактически, как было сказано в разделе 1.2.4, блокировка j
более мелких чем таблицы элементов, например отдельного диска или
। кортежа обеспечивает еше более сильный параллелизм, включая возможность j
одновременно выполнять различные вызовы функции chooseSeatQ.
312
Глава 7 Системные аспекты SQL
7-2.2 Атомарность
Несмотря на то что две и более операций на БД могут выполняться почти
одновременно, единственная операция способна привести БД в неприемлемое
состояние при сбое программного или аппаратного обеспечения во время
выполнения операции. Приведем пример того, что может при этом произойти
Следует помнить, что такого рода ошибки не случаются в правильно построенных
прикладных программах.
Пример 7.12. Рассмотрим широко распространенный тип БД записи банков-
ских счетов. Эти записи представлены отношением Accounts с атрибутами acctNo
и balance. Пары этого отношения состоят из номера счета и баланса данного счета.
Запишем функцию transfer(), которая читает два счета и количество денег и,
если на первом счету находится по меньшей мере такое количество, переводит день-
ги с первого счета на второй. Краткая запись этой функции приведена на рис 7.10.
D
2)
3)
4)
5)
EXEC SQL BEGIN DECLARE SECTION,
int acctl, acct2;
int balance 1;
int amount;
EXEC SQL END
/* два счета *!
Г сумма денег на первом счету */
Г переводимая сумма денег */
DECLARE SECTION;
6)
7)
8)
9)
10)
11)
12)
13)
14)
15)
16)
17)
18)
void transfer}) {
l* операторы С. предлагающие пользователю ввести счета 1 и 2
и сумму переводимых денег в переменные
acctl acct2 и amount*/
EXEC SQL SELECT balance INTO .balancel
FROM Accounts
WHERE acctNo - :acct1,
f (balancel >= amount) {
EXEC SQL UPDATE Accounts
SET balance = balance + .amount
WHERE acctNo = :acct2,
EXEC SQL UPDATE Accounts
SET balance = balance - .amount
WHERE acctNo = :acct1;
)
else /* программа С для вьвода сообщения о том,
что денежных средств для перевода недостаточно*/
)
Рис. 7.10. Перевод денег е одного счета но другой
Эта функция действует просто. Строки (8) — (10) определяют баланс первого
счета. Строка (II) определяет достаточен ли этот баланс, чтобы снять со счета
нужную сумму Если это так, то строки (12) — (14) добавляют ату сумму ко второму
счету', а строки (15) — (17) вычитают ее из первого счета. Если баланс первого счета
недостаточен, перевод не выполняется и на строке (18) печатается соо!ветствуюшее
п реду прсжден ие.
Рассмотрим, что происходит в случае сбоя после строки (14): возможно, выхо-
дит из строя компьютер или прерывается по сети связь БД с процессором, выпол-
няющим операцию. БД остается в состоянии, когда деньги переведены на второй
счет, но не сняты с первого. В результате банк лишается суммы которую нужно
было перевести □
7.2 Транзакции в SQL
313
Проблема, показанная а примере 7.12. заключается в том. что определенные
комбинации операций на БД типа изменений согласно рис 7.10 должны выполнять-
ся атомарно, т.е. либо выполняются обе. либо не выполняется ни одна из них.
Например, общее решение состоит и том, чтобы все изменения БД производить
п локальном рабочем пространстве и фиксировать изменения БД только после
завершения работы; лишь после этого псе изменения становятся частью БД и могут
быть использованы в других операциях.
7.2.3 Транзакции
Решение показанных в разделах 7.2.1 и 7.2.2 проблем преобразовании и после-
довательную форму и атомарности состоит в снедении операций на БД и транзак-
ции. Транзакция — это непустое множество операций на БД, которое должно
выполняться атомарно, т.е. либо выполняются все операции, либо не выполняется
ни одна из них. Ранние стандарты SQL требуют также, чтобы транзакции можно
было преобразовать а последовательную форму. В SQL2 используется более гибкий
метод. Преобразование в последовательную форму принято в нем по умолчанию,3
но пользователь может применять более мягкое ограничение относительно взаимо-
связи операций из различных транзакций. Эти варианты приведения в последова-
тельную форму будут рассмотрены позже.
Транзакция начинается с началом работы SQL предложения, которое либо
запрашивает БД или схему, либо манипулирует ими. В SQL нет специального опе-
ратора начала транзакции, но можно явно определить ее конец двумя способами.
I. Оператор COMMIT завершает транзакцию успешно. Любые изменения,
вызванные оператором или операторами SQL с момента начала транзак
иии, постоянно вводятся в БД (т.е. принимаются) До выполнения COMMIT
они остаются предполагаемыми и невидимыми для других транзакций.
2 Оператор ROLLBACK вызывает прекращение транзакции, или неуспешное
ее завершение. Любые изменения, выполняемые операторами SQL
в рамках данной транзакции, отменяются (т.е. производится их откат),
и они больше не возникают в БД.
i г
Изменения БД в процессе транзакций
; В различных системах транзакции реализуются по-разному. Выполнение ,
. транзакции может изменять БД. После прекращения такой транзакции изме- «
1 нения могут быть видимыми для другой транзакции. Обычное решение такой
проблемы — блокировка изменяемых элементов до выполнения COMMIT пли [
f ROLLBACK. В результате другая транзакция не может увидеть предполагаемых i
изменений. Блокировки или их эквиваленты обязательно применяются тогда. ‘
> когда пользователю нужно выполнять транзакции в последовательной форме. I
Как будет показано в начале раздела 7.2.4, в SQL2 существуют различные
' варианты работы предполагаемыми изменениями БД. Измененные данные
могут не блокироваться п быть видимыми, даже если последующий откат I
’ уничтожает изменение. Разработчик транзакций сам решает, нужно ли делать -
i невидимыми предполагаемые изменения. Во всех реализациях SQL есть по-
- добный блокировке метод сделать изменения невидимыми до их завершения.
з D некоторых реализациях применяются менее жесткие установки по умолчанию
314
Глава 7 Системные аспекты SQL
Пример 7.13. Допустим, нужно сделать ы олнение функции transferf) из при-
мера 7.10 ед н oil транзакцией. Она начинается на строке (8) при чтении баланса
первого счета. Если тест строки (II) дает положительный результат i вь нолняется
перевод денег, такое изменение желательно зафиксировать. Для это о в конце
if-блока строк (12) —( 7) вводится дополнительный оператор SQL:
EXEC SQL COMMIT;
Если тест строки (II) дает от; ицательный результат, т.е. средств для перевода незо-
т; очно, транзакцию нужно аннулировать, введя оператор
EXEC SQL ROLLBACK;
в конце else-блока на строке (18). Поскольку в этом случае не выполняется ника
кой оператор изменен! я БД, фиксация и удаление не играют роли, поскольку нет
изменений, которые нужно npi нять. □
7.2.4 Транзакции, предназначенные
только для чтения
В примерах 7.11 и 7.12 приведены транзакции, которые считывают, а затем
(возможно) записывают данные в БД. Такой тип транзакций связан с проблемой
преобразования в последовательную форму. В примере 7 II показано, что происходит
когда два выполнения функции направлены на резервирование одного и того же
места в одно и то же время. В примере 7.12 показано, что случается при сбое
в процессе выполнения функции. Если же транзакция только считывает данные
и не записывает их, существуют более широкие возможности для ее выполнения
параллельно с другими транзакциями4
Пример 7.14. Допустим, написана функция, считывающая данные и определяющая
свободно ли конкретное место авиарейса. Она действует согласно строкам (I) —(II)
на рис. 7.8. Можно выполнить одновременно несколько вызовов такой функции без вся-
кого риска повредить БД. Наихудшее, что может случиться,— это то. что во время
определения доступности конкретного места оно резервируется или освобождается в
результате выполнения другой функции. Значит, ответ "свободно' или "занято' может
зависеть от микроскопической разницы во времени выполнения запроса, в определен-
ный момент ответ все равно будет иметь смысл. □
Если сообщить исполнительной системе SQL о том что текущая транзакция
предназначена только для чтения, т.е. никогда не изменяет БД, вполне возможно,
что система извлечет пользу из этого знания. Не вдаваясь в подробности, отметим,
1то многие предназначенные только для чтения транзакции, использующие одни
и те же данные, могут выполняться параллельно, что невозможно для транзакций,
записывающих данные.
Сообщить системе SQL о том. что следующая транзакция предназначена
только для чтения, можно с помощью оператора
SET TRANSACTION READ ONLY,
который должен выполняться до начала транзакции. Например, функцию, выра-
женную строками (I) —(II) на рис. 7.8, можно объявить предназначенной только
для чтения, поместив
EXEC SQL SET TRANSACTION READ ONLY-
л Транзакции можно сравнить с управлением курсорами. Например, в разделе 7.1.10
говорилось, что курсорам. предназначенным только для чтения доступен
более глубокий параллелизм, чем общим курсорам То же самое относите!
I к пред или 1енным только для чтенля транзакциям
7.2 Транзакции в SQL
315
непосредственно перед строкой (9). которая начинает транзакцию. Делать это
после строки (9) бессмысленно.
Сообщить системе SQL о том, что транзакция записывает или способна запи-
сывать данные, можно с помощью оператора
SET TRANSACTION READ WRITE;
Однако этот режим обычно принят по умолчанию и явно определять его необяза-
тельно.
7.2.5 "Грязное" чтение
"Грязные" данные — это данные, записанные транзакцией, которая еще не за-
фиксирована. "Грязное" чтение— это чтение "грязных” данных. Риск считывания
"грязных" данных в том, что записавшая их транзакция может быть прервана Тогда
"грязные” данные удаляются из ЕД навсегда и все идет так, словно их никогда нс
существовало. Если транзакция прочла "грязные" данные, она затем может быть за-
фиксирована или выполнять другое действие, отражающее знание об этих данных.
В одних случаях “грязное" чтение имеет значение, в других нет. Иногда оно
не стоит поглощающей время работы, которую система управления БД должна
провести для предотвращения "грязных" чтений. Рассмотрим, что может произой-
ти, когда "грязное” чтение допускается.
Пример 7.15. Рассмотрим еще раз перевод счета в примере 7.12, предположив,
что теперь переводы реализуются программой Р, которая выполняет следующие шаги:
I. Добавляет деньги к счету 2.
2. Проверяет, достаточно ли денег на счете I.
(а) Если денег недостаточно, удаляет деньги со счета 2 и прекращает
работу.
(Ь) Если денег достаточно, снимает деньги со счета I и принимает
результат.
Если Р выполняется в последовательной форме, то временное помещение денег на
счет 2 не имеет значения. Никто их не увидит, и они будут удалены, если перевод
невозможен.
Но предположим, что допустимо "грязное" чтение. Пусть имеется три счета —/II,
А2 и ЛЗ со 100, 200 и 300 дол. соответственно. Транзакция 7\ выполняет программу Р,
чтобы перевести 150 дол. со счета /11 на счет А2. В то же самое время транзакция Тг
выполняет Р, чтобы перевести 250 дол. со счета >12 на счет /13. Тогда возможны
следующие события:
I. Т, выполняет шаг I и добавляет 250 дол. к счету АЗ, на котором теперь
стало 550 дол.
2. Т| выполняет шаг I и добавляет 150 дол. к счету /12, на котором теперь
стало 350 дол.
3. 7j выполняет тест шага 2 и обнаруживает, что на счете А2 достаточно
денег (350 дол.), чтобы перевести 250 дол. со счета /12 на счет АЗ.
4. Т\ выполняет тест шага 2 и обнаруживает, что на счете А1 недостаточно
денег (100 дол.), чтобы перевести 150 дол. со счета AI на счет /12.
5. 7j выполняет шаг 2Ь. Она снимает 250 дол. со счета А2, на котором
остается 100 дол., и принимает результат.
6. Г| выполняет шаг 2а. Она снимает 150 дол. со счета /12, на котором
остается -50 дол., и прекращает работу.
3!6
Глава 7 Системные аспекты SOL
Общая сумма денег не изменилась; на трех счетах по-прежнему 600 лол. Но поскольку
на третьем шаге из перечисленных шести Т, считывала "грязные" данные, пот вился
отрицательный счет, что должен был предотвратить тест первого счета, предназначен-
ный для того, чтобы определ! ь, достато1 но ли на нем денег. □
Пример 7,16. Рассмотрим другой вариант функции поиска места из примера 7.11.
Он заключается в следующем.
I. Находим свободное место и резервируем его. устанавливая атрибут
оса. pied для этого места в значение I.
2. Просим клиента подтвердить предложенное место. При подтверждении
результат принимается. В противном случае место освобождается уста-
новкой occuped в значение 0 и повторяется шаг I для получения другого
места.
Если две транзакции выполняют этот алгоритм практически одновременно,
одна из них может зарезервировать место 5, от которого позже клиент откажется.
Если вторая транзакция выполняет шаг I, когда место S отмечено как занятое,
клиент этой транзакции лишается возможности получить место 5.
Как и в примере 7.15. проблема связана с "грязным" чтением. Вторая транзак-
ция видела кортеж (с местом S. отмеченным как занятое), записанный п позже
измененный первой транзакцией □
Насколько важно то, что чтение было "грязным"? В примере 7 15 он очень ва-
жен, так как привел к появлению отрицательного счета вопреки всем защитным
средствам. В примере 7.16 проблема не выглядит столь серьезной. Конечно, второй
клиент может не получить любимого места в самолете или даже получит сообще-
ние, что свободных мест пег. Но в последнем случае повторный запуск транзакш и
почти наверняка определит доступность места 51 Такая функция выбора мест,
допускающая "грязное" чтение, ускоряет среднюю скорость запросов о резервиро-
вании, поэтому ее целесообразно применять.
SQL2 позволяет явно указать, что "грязное" чтение приемлемо для данной
транзакции Для этого применяется оператор SET TRANSACTION, упоминавшийся
в разделе 7 2.4. Подходящая форма транзакции, подобно той, что была приведена
в примере 7.16: 1 2
1) SET TRANSACTION READ WRITE
2) ISOLATION LEVEL READ UNCOMM TTED
Этот оператор выполняет две функции.
I Строка (I) показывает, что транзакция читает и записывает данные.
7 Сгрока (2) означает что следующая за ней транзакция действует на уровне
изоляции, допускающем чтение зафиксированных данных. Четыре уровня
изоляции рассматриваются в разделе 7.2.6. В данный момент читателю
известны два из них: возможность преобразования в последовательную
форму и чтение зафиксированных данных.
Если транзакция предназначена не только пя чтения (т.е записывает в БД
to крайней мере один элемент данных) и определен уровень изоляшп READ
UNCOMMINTTED. необходимо указать также READ WRITE. В разделе 7.2.4 было
сказано, что транзакция по умолчанию определена для чтения и записи. Случай,
когда допустимо "tразное" чтение, является в SQL2 исключением По умолчанию
транзакция принята юлько для чтения, поскольку транзакция с "грязным" 1Тением
сопряжена с серьезным риском. Если транзакция для чтения и записи выполняется
с уровнем изоляции, допускающим чтение незафиксированных данных, она
должна спеш филироваться явно с помощью READ WRITR
7.2 Транзакции в SQL
317
7.2.6 Другие уровни изоляции
SQL2 обеспечивает четыре уровня изоляции: возможность преобразования
в последовательную форму, чтение зафиксированных данных (разрешено грязное”
чтение), чтение только зафиксированных данных и повторное чтение. Последние два
определяются для данной транзакции с помощью операторов
SET TRANSACTION ISOLATION LEVEL READ COMMITTED ;
ii
SET TRANSACTION ISOLATION LEVEL REPEATABLE READ
соответственно. В обоих случаях транзакция по умолчанию предназначена для
чтения и записи, поэтому при желании можно добавить READ ONLY к любому из
этих операторов. Можно также явно определить
SET TRANSACTION ISOLATION LEVEL SERIALIZABLE ;
но делать это необязательно, поскольку такой режим в SQI 2 принят по умолчанию.
Уровень изоляции, допускающий чтение только зафиксированных данных,
запрещает чтение "грязных” (незафиксированных) данных, но он позволяет одной
транзакции многократно повторять один и тот же запрос и получать на него разные
ответы, пока эти ответы отражают данные, записанные уже зафиксированными
транзакциями.
Пример 7.17. Рассмотрим заново функцию выбора мест из примера 7.16, пред-
полагая, что она выполняется на уровне изоляции, допускающем чтение принятых
данных. Тогда при поиске мест на шаге I функция не обнаружит места зарезерви-
рованными, если другая транзакция зарезервировала их, но ее результат еще не
зафиксирован.5 Если же клиент отвергает предлагаемые места и единственное вы
полнение функции многократно запрашивает их, при каждом запросе получается
разное количество свободных мест, в связи с тем что другие транзакции параллель-
но резервируют или освобождают места. □
Рассмотрим уровень изоляции, допускающий повторное чтение данных. На
этом уровне нет гарантии, что при многократном повторении запроса будет полу-
чен один и тот же ответ. При первом извлечении кортежа можно быть уверенным,
что при повторении запроса будет получен этот же кортеж. Но возможно и то,
что при втором и последующих выполнениях запроса будут получены иллюзорные
кортежи, являющиеся результатом операций вставки в БД, произведенной во
время выполнения нашей транзакции.
Пример 7.18. Вернемся к проблеме выбора мест из примеров 7.16 и 7.17. Если
такая функция выполняется на уровне изоляции, допускающем повторное чтение,
место, доступное по первому запросу на шаге I, остается доступным и при после-
дующих запросах.
Но предположим, что в отношение Flights вводятся новые кортежи. Например,
авиалиния предоставила для рейса более вместительный самолет, создавая новые
кортежи, которых раньше не было, или резервирование мест вообще отменено.
Тогда на уровне изоляции, допускающем повторное чтение, последующие запросы
могут извлекать информацию и о новых, свободных местах. □
s Происходящее может показаться таинственным, так как мы ис обращались
к алгоритмам введения раз.- ичных уровней изоляции. Возможно, если две транзакции
увидят место свободным и попытаются зарезервировать его. система прервет
одну из них. даже если в ней нет оператора ROLLBACK.
318
Глава 7 Системные аспекты SOL
7-2.7 Упражнения к разделу 7.2
Упражнение 7.2.1 Это и следующее упражнения включают в себя программы,
действующие на двух отношениях
Product(maker, model, type)
PC(model. speed ram, hd, cd, price)
Запишите кратко перечисленные ниже программы, используя встроенный SQL
и подходящий главный язык. Не забудьте применить операторы COMMIT и
ROLLBACK н нужных местах. И, если транзакции предназначены только для чтения,
сообщи е об этом системе.
а) По заданным скорости и объему RAM (в качестве аргументов функции)
найдите ПК. с этими параметрами и напечатайте номера их моделей и
цены
*Ь) По заданному номеру модели удалите кортеж для этой модели из отноше
ний PC и Product
с) По заданному номеру модели уменьшите цену ПК этой модели на 100 дол
d) По заданному имени производителя, номеру модели, скорости процессо-
ра, объему RAM, размеру жесткого диска, скорости CD и цене убедитесь,
что модели с такими параметрами не существует. Если она есть, напеча-
тайте для пользователя сообщение об ошибке. Если такой модели нет,
введите информацию о ней в таблицы PC и Product.
! Упражнение 7.2.2. Для каждой программы упражнения 7.2.1 рассмотрите проб-
лему атомарности, которая может возникнуть при сбое системы в процессе выпол-
нения программы.
I Упражнение 7.2 3. Пусть одна из программ упражнения 7.2.1 выполняется в
виде транзакции Т\ и примерно в это же время другие транзакции могут выполнять
эту программу или любую из оставшихся трех. Укажите особенности поведения Т
при запуске всех транзакций на уровне изоляции READ UNCOMMITTED, которые
невозможны при запуске всех программ на уровне изоляции SERIALIZABLE. Рас-
смотрите отдельно случаи, когда Т— одна из программ пунктов (а) — (d) упражне-
ния 7.2.1.
*!! Упражнение 7 2.4. Пусть Т— транзакция, которая выполняется всегда и каж-
дый час проверяет, существует ли ПК со скоростью не менее 200 МГц и иеной
ниже 1000 дол. Обнаружив такой компьютер, она печатает о нем информацию и
прекращает работу'. В это время могут работать другие транзакции, выполняющие
одну из программ упражнения 7.2.1. Покажите результаты действия Т на каждом из
четырех уровней изоляции.
7-3 Среда SQL
В этом разделе будут рассмотрены наиболее широкие аспекты СУБД, а также
БД и программ, поддерживающих эти системы, определение БД и их оформление
в кластеры, каталоги и схемы, способы связи программ с данными, которыми они
манипулируют. Многие детали зависят от конкретной реализации, поэтому мы
сосредоточимся лишь на общих идеях, содержащихся в стандарте SQL2,
7.3 Среда SQL
319
7-3.1 Среды
Среда SQL — это структура, в которой могут существовать данные, и на них
выполняются операции SQL. На практике среда SQL — это СУБД, действующая при
конкретной инсталляции. Например, компания АВС покупает лицензию на СУБД
для работы с парком компьютеров корпорации Dandy-DB Система, действующая
на этих компьютерах, является средой SQL.
Вес упоминавшиеся ранее элементы БД определяются в среде SQL и упорядо-
чиваются в иерархию структур, каждой из которых в этой иерархии отведена своя
роль. Структуры, определенные стандартом SQL2, показаны на рис. 7.1 L
Рис. 7.11. Организация элементов БД в среде
Основными структурами БД являются:
I. Схемы6— это наборы таблиц, представлений допущений и областей а
также некоторых других типов информации, не рассмотренных в данной
книге (см. в разделе 7 3.2 заключенный в рамку текст под названием "Что
еше входит в схему") Схемы — это базовые единицы организации По
смыслу термин "схема” близок к термину "БД", но из пункта 3 станет
ясно, что он обозначает нечто меньшее чем БД
2. Каталоги — это множества схем Они являются базовой единицей пол
держки единообразной доступной терминологии. Каждый каталог содержит
одну и более схем. Имена схем в каталоге должны быть уникальными.
Каждый каталог содержит специальную схему INFORMATION_SCHEMA,
в которой хранится информация о всех схемах этого каталога
6 Термин 'схема" в данном контексте обозначает схему БД, а не схему отношения.
320
Глава 7 Системные аспекты SQL
3. Кластеры — это множества каталогов. С каждым иолыоп.пелем связан
отдельный кластер — множество доступных пользователю каталогов
ГВ разделе 7 4 показано. как осуществляется контроль доступа к каталогам
и другим элементам). В SQL2 точно не определено, что такое кластер
и могут лн кластеры различных пользователей частично совпадать, не
будучи идентичными. Кластер — это максимальная область, п которой
мож нт вып ушить запрос. Поэтому ио существу, кластер — по база
данных, с точки зрения отдельного пользователя.
7.3-2 Схемы
Простейшая форма описания схемы включает а себя три элемента:
I. Ключевые слона CREATE SCHEMA
2. Имя схемы
3. Список описаний элементов схемы: таблиц, представлений. операторов
контроля и областей
Синтаксическая форма описания схемы:
CREATE SCHEMA <нмя с\емы> <01 исання элемептов>
Формы описания элементов были показаны в разделах 5.7. 5.8 и в главе 6 Система
SQL2 позволяет описать в схеме и некоторые другие вилы элементов, которые мы
не рассматривали.
।
Что еще входит в схему j
Помимо таблиц представлений, областей н операторов контроля, сущест 1
вуют и другие виды элементов схемы Во-первых схема может определять i
множество символов и метод их кодирования. Самое известное множество \
• символов — это ASCII, но реализация SQL2 поддерживает и многие другие. !
i например множества иностранных языков i
I Во-вторых, в схеме можно определить сравнение для множества символов. ?
. Напомним, что строки символов сравниваются лексикографически, в предпо i
ложении, что любые два символа можно сравнить с помощью отношения < -
("меньше чем Сравнение показывает, какие символы "меньше, чем" 1
другие. Например можно применить упорядочение согласно программе ASCII ,
I или отождествить буквы нижнего и верхнего регистров и не сравнивать *
символы, не являющиеся буквами.
В-третьих, схемы могут содержать переводы те методы конвертирования 3
одного множества символов в другое 1-1 последний вид элементов, которые
могут появиться в схеме,— это "оператор прав допуска", определяющий, кто имеет ,
‘ доступ к схеме. Права и привилегии доступа рассматриваются в разделе 7 4 i
Пример 7.19. На рис. 7.Р показано описание схемы, куда входят пять отношений,
касающиеся фильмов, а также другие элементы, например представлений □
Her необходимости описывать всю схему сразу. Ее можно изменить или доба
Пить к ней подходящий оператор — CREATE, DROP или ALTER, например оператор
CREATE TABLE, за которым следует описание новой таблиц i для данной схемы
Одна из проблем ыключаегся в том. что система SQL должна знать, к какой схеме
принадлежит новая таблица При изменении или удалении таблицы пли другого
7.3 Среда SQL 321
элемента схемы нужно уточнить имя этого элемента. t«ik как две и более схем
могут иметь различные элементы с одним и тем же именем. "Текущая" схема изме-
няется с помощью оператора SET SCHEMA Например:
SET SCHEMA MovieSchema;
делает текущей схему, описанную на рис. 7.12. и тогда любые описания элементен
схемы добавляются именно и эту схему или изменяют уже существующие и ней
эле.мен гы.
CREATE SCHEMA MovieSchema
CREATE DOMAIN CertDomam ... как в примере 6.8
Описа зпя других областей
CREATE TABLE MovleSlar . как на рис. 6.4
Операторы со |дания для остальных четырех таблиц
CREATE VIEW MovieProd ... как в примере 5.40
Описания других представлений
CREATE ASSERTION Rich Pres . каки примере 6.10
Рис. 7.12. Описание схемы
J -- ....- ..•Л-1..Л*-- ». Ч. СТ .««•* <>.!> WS'>..*nra_T* . - ««»:•»₽. 1 WW.rl --
5 :
Полные имена элементов схемы
j «
Формально имя элемента схемы типа таблицы состоит из имени каталога,
имени схемы и собственного имени элемента, разделенных точками. Напри-
’ мер. на таблицу Movie из схемы MovieSchema и каталоге MovieCatalog можно
ссылаться по имена
MovieCatalog.MovieSchema Movie j
Если каталог задан по умолчанию или является текущим, первый элемент
имени можно пропустить. Если принятой по умолчанию или текущей является
схема, ее имя тоже можно не указывать, и. как обычно, останется одно имя ;
! элемента. Но для доступа к тому, что находится вне текущей схемы или »
каталога, нужно применять полное имя.
7.3.3 Каталоги
Как элементы создаются н изменяются внутри схемы, так и сами схемы созда
ются и изменяются внутри каталога. В принципе можно предположить, что про
зесс создания и наполнения каталога аналогичен процессу создания и наполнения
схем. К сожалению, в SQL? не определен стандарт этих действий типа оператора
CREATE CATALOG <пмя каталогам
за которым следует список схем, принадлежащих данному каталогу, t описания
этих схем.
Однако н SQL? определен оператор
SET CATALOG <имя кат;ьтога>
- от оператор позволяет установить текущий каталог, н и результате новые схемы
будут попал пь именно в этот каталог, а в случае неясности с именами изменения
схемы будут от носиться к схемам именно этого каталога.
322
Глава 7 Системные аспекты SQL
7-3-4 Клиенты и серверы в среде SQL
Среда SQL—нечто большее чем множество каталогов и схем. Она содержит
элементы для поддержки операций на БД представленных каталогами и схемами.
В среде SQL есть два особых вида процессов: SQL-клиенты и SQL-серверы Сервер
поддерживает операции на элементах БД, а клиент обеспечивает связь пользователя
с сервером. Как правило, сервер работает на большом компьютере и хранит БД,
а клиент работает на другом компьютере, возможно, на персональной р<бочей
станции удаленной от сервера, хотя они и могут находиться на одном компьютере.
7-3-5 Связи
Для запуска содержащей SQL программы на клиенте SQL нужно открыть связь
между клиентом и сервером с помощью оператора SQL:
CONNECT ТО <имя сервера> AS <имя связи>
Имя сервера зависит от инсталляции. Ключевое слово DEFAULT, подставленное
вместо имени сервера, подключает пользователя к любому серверу, определенному
в данной инсталляции в качестве "сервера по умолчанию”
Имя связи можно использовать для последующих ссылок на эту связь Такие
ссылки нужны потому, что SQL2 позволяет пользователю открывать множество
связен, но в определенный момент активной может быть только одна из них.
Для переключения с одной связи на другую связь connl нужно сделать активной
с помощью оператора
SET CONNECTION connl;
При этом любая другая активная в данный момент связь становится бездействующей
до тех пор. пока не будет снова введена в действие другим оператором — SET
CONNECTION, в котором она явно упоминается
Удалить связь можно, указав ее имя в операторе
DISCONNECT connl;
В результате связь уничтожается и в дальнейшем ее невозможно активизировать
Если вообще не нужно ссылаться на установленную связь, слово AS и имя
связи из оператора CONNECT ТО можно удалить. Можно вообще не указывать
операторы связи. Если операторы SQL просто выполняются на компьютере с
SQL клиентом, автомагически устанавливается связь, заданная по умолчанию
7-3-6 Сеансы
Операции SQL. выполняемые во время пребывания связи в активной форме,
называются сеансом. Сеанс зависит от создавшей его связи. Например, если связь
бездействует, ее сеанс тоже бездействует, а реактивация этой связи с помощью
оператора SET CONNECTION вновь делает его активным На рис. 7.13 сеанс и связи
изображены в виде двух аспектов соединения клиента с сервером.
Каждый сеанс имеет текущий каталог и текущую схему в этом каталоге, кото-
рые можно определить с помощью операторов SET SCHEMA и SET CATALOG, рас-
смотренных в разделах 7.3.2 и 7 3.3. Как будет показано в разделе 7 4. для каждого
сеанса существует авторизованный пользователь.
7.3 Среда SQL
323
Рис 7.13. Взоимодействие клиента и сервера SQL
7-3.7 Модули
Модуль — это термин SQL2, обозначающий прикладную программу Согласно
стандарту SQL2 существует три типа модулей и по крайней мере один из них
доступен для пользователя.
I. Общий интерфейс SQL. Пользователь может набирать операторы, которые
выполняются сервером SQL В таком режиме каждый запрос или сам
оператор является модулем. Он предполагается в большинстве примеров
этой книги, но на практике применяется редко.
2. Встроенный SQL Этот способ работы рассматривался в разделе 7.1:
операторы SQL появляются внутри программ главного языка и вводятся
с помощью EXEC SQL. Предполагается, что препроцессор превращает
встроенные операторы SQL в подходящие функции или вызовы процедур
из системы SQL, которые выполняются в подходящий момент при
выполнении компилированной программы главного языка.
3. Истинные модули. Наиболее общий тип модулей SQL2 — множество
хранимых функций или процедур, состоящее из программ главного языка
и SQL-операторов, которые взаимодействуют между собой путем передачи
параметров или с помощью разделяемых переменных.
Выполнение модуля называется SQL-агентом На рис. 7 13 модуль и SQL-агент
показаны как один элемент, вызываемый на SQL-клиенте для установления связи.
Однако следует помнить, что различие между модулем и SQL-агентом аналогично
различию между программой и процессом; первое — это запись программы а вто-
рое — ее выполнение.
324
Глава 7 Системные аспекты SQL
7.4 Защита и авторизация пользователя
в SQL2
В SQL2 постулируется сур ествование идентификаторов (ID) авторизации, ко-
торые, по существу, являются именами пользователей. В SQL есть специальный ID
авторизации PUBLIC, включающий is себя любого пользователя ID авторизаиии
могут быть присвоены привилегии. Они присваиваются но многом так же, как
п в среде файлово) системы, поддерживаемой операционной системой. Например,
система UNIX обычно контролирует три вида привилегии чтения, записи и выпол-
ню 1ия. Список привилегий имеет смысл, так как защищаемыми объектами системы
UNIX являются файлы и эти тр л привилегии хорошо отражают то. что обычно
можно сделать с файлами Но БД намного сложнее файловых систем и, соответст-
венно, в SQL2 используются более сложные привилегии
В этом разделе сначала будут рассмотрены привилегн л. допустимые на элемен-
ч 1х БД по стандарту SQL2, а затем мы покажем, как их может получить пользова-
тель (т.е. 1D авторизации) и как он может их лишиться.
7-4-1 Привилегии
В SQL2 определено шесть типов привилегий:
1. SELECT
2. INSERT
3. DELETE
4 UPDATE
5. REFERENCES
6. USAGE
Первые четыре типа относятся к отношениям, которые могут быть таблицами
базы или представлениями. В соответствии со своими названиями они дают обла-
дателю привилегии запрашива ь отношение (выбирать что-то из него), вводить,
удалять пли изменять кортежи отношения. Модуль, содержащий SQL-предложение,
невозможно выполнить без привилегии, связанной с этим модулем: например.
Предложение типа select-from-where требует привилегии SELECT для каждой исполь-
зуемой в нем таблицы Рассмотрим, как модуль .может получить перечисленные
привилегии
Привилегия REFERENCES — это право ссылаться на отношение в о раничении
целостности. Такне ограничения могут иметь любую форму из описанных в главе 6.
Ограничение нельзя проверить, есл л схема, содержащая это ограничение, не имеет
пр шнлеги I REFERENCES на все данные, содержащиеся в ограничении.
Привилегия на область и и на другие виды элементов схемы, отличные от
отношений и допущений (см. раздел 7 3.2),—это право использовать эп элементы
is ci их собственных описаниях.
Три привилегии — INSERT, UPDATE и REFERENCES — могут бы ь присвоены
единственному атрибуту, выступающему в ка1есгве аргумента. В этом случае при-
nn.iei ия относился олько к указанному атрибуту Можно применить множество
привилегий, каждая из которых относится к единственному атрибуту, и так 1,м
образом автор вовать доступ к любому подмножеству столбцов отношения
Пример 7.20. Рассмотрим, какие пр1пилегии нужны для выполнен! я всталки
। ортежей нз । не. 5.12, воспроизведенного на рис. 7.14 Здесь выполняется вс авка
кортежей в оиюшенне Studio, поэтому нхжна привилегия INSERT на это отношен ле.
Но поскольку вставка касается единственного компонента атрибута name, поен оч
нз ыеть на это отношение привилегию INSERT или привилегию INSERT(name)
7.4 Защита и авторизация пользователя в SQL2
325
Последняя позволяет вставлять кортежи отношения Studio, которые определяют
только компонент name н оставляют другие компоненты с их значениями по
умолчанию пли NULL, что и показано на рис. 7.14.
1) INSERT INTO Studio(name)
2) SELECT DISTINCT studioName
3) FROM Movie
4) WHERE studioName NOT IN
5) (SELECT name
6) FROM Studio);
Рис. 7.14. Дсбовление новых студий
Однако оператор вставки на рис 7.14 содержит два подзапроса, начинающиеся
на строках (2) и (5). Для их выполнения нужны привилегии для подзапросов
Таким образом, необходима привилегия SELECT на оба отношения — Movie
и Studio, включенные в пункты FROM. Заметим, что иметь привилегию INSERT
на отношение Studio совсем не значит иметь привилегию SELECT на это же отно-
шение и. наоборот, иметь вторую из них не значит иметь и первую. О
7.4-2 Создание привилегий
Рассмотрим теперь, как получить привилегии для выполнения SQL-предложений
Есть два момента присвоения привилегий: их первоначальное создание и передача
от пользователя пользователю. Создание привилегий рассматривается в этом разделе
а их передача в разделе 7.4.4.
Прежде всего элементы SQL, такие кик схемы или модули, принадлежат вла-
дельцу, который имеет связанные с ними привилегии. В SQL владение устанавли-
вается о трех случаях:
1. При создании схемы предполагается, что она. все ее таблицы и прочие
элементы принадлежат создавшему их пользователю, который имеет все
возможные привилегии на элементы этой схемы
2. При запуске сеанса с помошью оператора CONNECT есть возможность
указать пользователя, применив ключевое слово USER. Например, опера-
тор связи
CONNECT ТО Startleet-sql-server AS connl USER kirk;
создает для пользователя kirk связь connl с сервером Starfleet-sql-server
Предполагается, что реализация SQL верифицирует имя пользователя,
например запрашивая пароль.
3. При создании модуля ему можно присвоить владельца, используя ключевое
слово AUTHORIZATION Подробности создания модулей здесь не рассмат-
риваются. так как стандарт SQL2 обеспечивает в этом плане широкие воз-
можности для различных реализаций. И все же можно считать, что пункт
AUTHORIZATION picard
в операторе создания модуля делает picard владельцем этого модуля. Если
владельца модуля не указывать, то этот модуль может выполняться любым
пользователем; по в таком случае привилегии, необходимые для выпол-
нения любой операции в модуле, должны поступи ь из какого-то другого
источника, например от пользователя, относящегося к данной связи
и сеансу, в течение которого выполняется модуль. _____
326
Глава 7 Системные аспекты SQL
7 4-3 Процесс контроля привилегий
Каждая схема, каждый модуль и сеанс имеют связанного с ними пользователя;
в терминолог in SQL это означает, что для них существуют 1D авторизации. Любая
операция SQL имеет дне стороны.
I. Элементы БД. на которых выполняется операция.
2. Агент, выполняющий операцию.
Привилегии агента выводятся из конкретного 1D авторизации, который зазывается
текущим ID авторизации и является:
a) ID авторизации модуля, если модуль, выполняемый агентом, имеет 1D;
b) ID авторизации сеанса, если у модуля нет 1D.
Операцию SQL можно выполнить, только если текущий ID авторизации имеет все
привилегии, необходимые для выполнения этой операции.
Пример 7.21. Чтобы понять механизм проверки привилегий, рассмотрим
пример 7.20 Можно предположить, что отношения Movie и Studio — части схемы
MovieSchema, созданной пользователем janeway и принадлежащей ему. Тогда поль-
зователь janeway имеет все привилегии на эти таблицы и на псе остальные элементы
схемы MovieSchema. Некоторые привилегии он может передать другим при помо-
щи механизма, показанного в разделе 7.4.4, но сейчас мы предполагаем, что ни
одна привилегия еще не передана. Операция вставки из примера 7.20 выполняется
различными способами.
I. Введение можно выполнить как часть модуля, созданного пользователем
janeway и содержащего оператор AUTHORIZATION Janeway. ID авторизации
модуля, если он существует, всегда становится текущим ID авторизации
Значит, этот модуль и SQL-предложения вставки имеют такие же приви-
легии, как и janeway, т.е. все привилегии на отношения Movie и Stud'o.
2. Вставка м ожег быть частью модуля, не имеющего владельца. Пользователь
janeway открывает связь, вводя USER janeway в оператор CONNECT ТО.
Теперь janeway — это текущий 1D авторизации и предложение вставки
имеет все необходимые привилегии.
3. Пользователь janeway передает все привилегии на отношения Movie и Studio
пользователю sisko или пользователю PUBLIC, обозначающему "всех Поль
зователей”. Предложение вставки находится в модуле с оператором
AUTHORIZATION sisko;
ПосколbKv текущим ID авторизации теперь является sisko и он имеет
необходимые привилегии, введение разрешено.
4. Как и в предыдущем случае (пункт 3), пользователь janeway передает поль-
зователю sisko необходимые привилегии. Предложение вставки находится
в модуле без владельца и выполняется в сеансе, ID авторизации которого
установлен оператором USER sisko. Значит, текущим 1D авторизации
является sisko и этот ID имеет все необходимые привилегии. □
Пример 7.?1 иллюстрирует несколько принципов.
• Необходимые привилегии всегда доступны, если данными владеет пользова-
тель, чей 1D является текущим ID авторизации. Это иллюстрируют описан-
ные выше ситуации (1) и (2).
7.4 Защита и аеюризация пользователя в SQL2
327
• Необходимые привилегии доступны, если они были переданы владельцем
данных пользователю, чей 1D является текущим ID авторизации или поль-
зователю PUBLIC. Это иллюстрируют описанные выше ситуации (3) и (4).
• Необходимые привилегии становятся доступными, когда модуль выполняется
тем. кто владеет и этим модулем, и данными, или тем, кому были переданы
привилегии на эти данные. Это иллюстрируют описанные выше ситуации (I)
и (3».
• Законный способ выполнения операции — выполнение модуля п течение
сеанса 1D авторизации которого совпадает с ID пользователя, имеющего все
необходимые привилегии. Это иллюстрируют описанные выше ситуации (2)
и (4).
7-4.4 Присвоение привилегий
Пример 7.21 показывает, как важно для пользователя (т.е. ID авторизации)
иметь привилегии. Ранее было сказано, что создатель и владелец элемента БД имеют
на него все привилегии. Присвоить их другому пользователю можно с помощью
оператора GRANT При этом привилегии сохраняются и у того, кто их присваивает,
поэтому GRANT можно считать копией привилегий.
Между присвоением привилегии и ее копированием есть одно существенное
различие. С любой привилегией связан режим передачи. Один пользователь на
отношение Movie может иметь привилегию типа SELECT с правом передачи,
а другой — без этого права Тогда первый пользователь может присвоить эту приви-
легию третьему пользователю, причем с правом или без права передачи, в то время
как второй пользователь, лишенный права передачи, не имеет возможности при-
своить ее больше никому. Если третий пользователь получает эту же привилегию
с правом передачи, он может присвоить ее четвертому пользователю с правом или
без права передачи и т.д. В оператор присвоения входят следующие элементы
1. Ключевое слово GRANT.
2. Список привилегий, напрнмер SELECT или INSERT(name) Здесь при же-
лании можно применить ключевые слова ALL PRIVILEGES для сокраще-
ния списка всех привилегий, которые владелец может законно присвоить
рассматриваемому элементу БД (элементу, упоминаемому ниже, в пункте 4).
3. Ключевое слово ON.
4. Элемент БД Обычно это отношение, т.е таблица базы или представле-
ние. Элементом может быть также область или другой элемент, который
здесь не рассматривается (см. заключенный в рамку текст под названием
"Что еше входит в схему” в разделе 7.3.2), но в этом случае имени элемента
должно предшествовать ключевое слово DOMAIN или другие подходящие
ключевые слова.
5. Ключевое слово ТО.
6. Список пользователей (список ID авторизации).
7. Ключевые слова WITH GRANT OPTION (при необходимости)
Форма оператора присвоения привилегий:
GRANT Ссписок привилегий> ON <элемент БД> ТО <список пользователей>
В конце могут стоять ключевые слова WITH GRANT OPTION
Для корректного выполнения этого оператора выполняющий его пользователь
должен иметь псе присваиваемые привилегии, причем с правом передачи. Однако
он может иметь и более общую привилегию (с правом передачи) по сравнению
328
Глава 7 Системные аспекты SQL
с той, которуо он присваивает кому-то другому. Например, можно присвоить
кому-то привилегию NSERT(name) на таблицу S udio. имея на эту табл ту более
общую привилегию INSERT с правом передач! .
Пример 7.22. Пользователь janeway, являющийся владельцем схемы MoveSchema.
содержащей два отношения;
Move(title, year, length nColor studioName, producerC#)
Studio(name, address, presC#)
присваивает пользователям kirk и picard привилегии INSERT и SELECT на таблицу
Sludio и пр 11 легию SELECT на таблицу Movie Эти привилегии црисваииа отся
с правом передачи Опер;торы присвоения-
GRANT SELECT, INSERT ON Studio TO kirk, picard
WITH GRANT OPTION;
GRANT SELECT ON Move TO kirk, picard
WITH GRANT OPTION,
Теперь picard присваивает пользователю ssko те же привилегии, но уже без
прана передачи:
GRANT SELECT INSERT ON Studio TO sisko;
GRANT SELECT ON Movie TO sisko;
kirk присваивает sisko к ннимальные привплеп и, необходимые для операции вставки
из рис. 7.14, а именно INSERT(name) и SELECT на таблицу Studio и SELECT на
таблицу Movie:
GRANT SELECT, INSERT(name) ON Studio TO sisko;
GRANT SELECT ON Movie TO sisko;
Заметим, что sisko получил привилегию SELECT на Studio и Move от двух различ-
ных пользователей и дважды получил привилегию INSERT(name) на Studio прямо
от пользователя kirk и косвенно через более общую привилегию INSERT от пользо
вателя picard □
7-4-5 Диаграммы присвоения привилегий
Поскольку в результате ряда присвоений может возникнуть сложная сеть
присвоений и частично перекрывающихся привилегий, полезно представлять при-
своения в виде диаграмм присвоения привилегий. Система SQL использует такую
дна рамму для отслеживания привилегий и их источников (в случае отмены приви-
легии, см. раздел 7.4.6). Диаграмма присвоения привилегий — это граф, каждый
узез которого соответствует пользователю и привилегии. Если пользователь t/при
cuai вает npi вилегию Р пользователю И и это присвоение основано на ом. что U
имеет пр юилегию Q (Q может совпадать с Р в режиме передачи или быть обобще-
н |ем Р с режимом передачи!, проводится ориентированное ребро от узла U/Q
к узлу И/Р.
Пример 7.23. На рис. 7 15 показана диаграмма присвоения, которая получается
из ряда применений операторов присвоения привилегий из примера 7.22. По согла
и синю, символ ® после комбинации "пользователь — привилегия" обозначает право
передачи, символ означает, что привилегия вытекает из владения рассматривав
мым элементом БД, а не присвоена каким-то другим ис очником. Последзее
различие важно при анализе отмены привиле ий (см раздел 7.4.6). Привилегия,
отмеченная двумя звездочками, автоматически предполагает право передачи. □
7.4 Защита и авторизация пользователя в SQL2
329
Рис. 7.15. Диогромма присвоения привилегий
7.4- 6 Отмена привилегий
Присвоенная привилегия может быть отменена в любое время Фактически от-
мену привилегий можно проводить каскадно в том смысле что отмена принилегии
с правом передачи, которая была передана другим пользователям, может требовать,
чтобы все пользователи были лишены згой привилегии Простой оператор отмены
включает в себя следующие элементы:
I. Ключевое слово REVOKE
2. Список привилегий
3. Ключевое слово ON
4. Элемент БД. представленный в пункте (4) описания
оператора присвоения привилегии
5. Ключевое слово FROM
б. Список пользователей (список 1D авторизаиии)
Форма оператора отмены привилегий
REVOKE <спнсок привилегий:* ON <элемент БД> FROM <список пользоватезей>
330
Глава 7 Систем! ыс аспекты SOL
В этот онерато) можно включать дополнительные элементы.
• Оператор может згкаич! пяться ключевым словом CASCADE. В этом случае
при отмене указан! ых в операторе привилегий отменяются все привилегии,
присвоенные только благодаря отмененным привилегиям Точнее говоря,
если пользователь U л> шает пользователя К прпвплеп и Р. основанной
на привплеп и О. принадлежащей U. из диаграммы присвоения удаляется
ор 1ентнрованное ребро от U/Q к VIР. При этом удаляется каждь й узел,
недостижимы! i з узла владения (ума. отмеченного двумя звездочками).
• Оператор может заканчиваться ключевым словом RESTRICT, означают.! .и,
что оператор отмены привилегий не выполним, если правило каскада,
описанное в предыдущем абзаце, приводит к отмене какой-либо привилегии
из-за того, что отменяемые этим оператором привилегии были переданы
другим пользователям.
• При замене REVOKE на REVOKE GRANT OPTION FOR сами привилегии
сохраняются, но возможность передачи их другим ликвидируется. Такой
вариант можно использовать в комбинации с CASCADE или RESTR СТ. При
этом по диаграмме npi своения определяется, нужно ли отменять какие-то
другое присвоенные привилегии.
Пример 7.24. Продолжая пример 7.22, предположим, что janeway отменяет
привилегии, присвоенные picard, с помощью операторов
REVOKE SELECT INSERT ON Studio FROM picard CASCADE;
REVOKE SELECT ON Movie FROM picard CASCADE;
На рис. 7.15 удаляются ориентированные ребра от привилегий janeway к со-
ответствующим привилегиям picard. Поскольку применяется CASCADE, нужно
проверить, есть ли привилегии, которые недостижимы в графе из привилеги I,
отмеченной двумя звездочками (основанной на владении). Анализ рис. 7.15 пока-
зывает, что привилегии пользователя picard больше недостижимы из отмеченного
двумя звездочками узла (они могли быть достижимы, если бы к узлу picard сущест-
вовал другой путь). Привилегия INSERT пользователя sisko на таблицу Studio тоже
больше недостижима. Значит из диаграммы присвоения удалены не только приви-
легии пользователя picard. но и привилегия INSERT пользователя sisko.
Заме им, что нс удаляются привилегии SELECT пользователя sisko на таблицы
Movie и Studio или его привилегия INSERT(name) на Studio, так как все он <
достижимы из основанных на владении привилегий пользов отеля janeway через
привилеп и пользователя kirk. В результате получается диаграмма, представленная
на рис. 7.16. □
Пример 7.25 В процедуре удаления есть тонкости, которые мы проиллюстри-
руем на абстрактных примерах Прежде всего, удаляя об дую привилегию р. мы
не удаляем привидепно, являющуюся ее частным случаем. Рассмотрим, например,
Поспеловагепьность шагов, в которой пользователь (I, владелец отношения /?,
присваивает пользователю V привплеп и INSERT и INSERT(A) на отношение R
Кем
Шаг выполняется Действие
1 L7 GRANT INSERT ON R TO V
2 U GRANT INSERT(A) ON R TO V
3 U REVOKE INSERT ON R FROM V RESTRICT
7.4 Защита и авторизация пользователя в SOL2
331
Рис. 7.16. Диаграмма присвоения после отмены ивилегии пользователя picard
Когда U лишает V привилегии INSERT, привилегия NSERT(A) сохраняется
Днаграмма присвоения привилегий после шагов (2) и (3) показана иа рис. 7 17.
(а) После шага (2)
Рис. 7.17. Отмене общей привилегии сохраняет более частную привилегию
(Ь) После шага (3)
332
Глава 7 Системные аспекты SQL
Заметим, что после шага (2) остается два отдельных узла для двух похожих, но
не о.пн аковых привилегий которые имеет пользователь И Режим RESTRICT на
шаге (3) не предотвращает отмену привилегии, так как пользователь И никому ье
передавал привилегии Фактически он не мог этого сделать поскольку' получил
привилегии без права передачи □
Пример 7.26. Рассмотрим пример, в котором пользователь U присваивает
пользователю F привилегию р с правом передачи, а затем отменяет только это право.
В этом случае нужно изменить узел пользователя К чтобы отразить утрату1 права
передачи и отменить все присвоения привилегии р, выполненные пользователем К
удалив ребра исходящие из узла V/р Получается следующий ряд шагов:
Кем
Шаг выполняется Действие
1 и GRANT р ТО И WITH GRANT OPTION
2 V GRANT p TO W
3 и REVOKE GRANT OPTION FOR p FROM К CASCADE
На шаге (1) пользователь U присваивает пользователю V привилегию р с правом
передачи. На шаге (2) пользователь У использует право передачи для присвоения
привилегии р пользователю IV. В результате получается диаграмма показанная на
рис. 7.18 (а)
(а) После шага (2)
(Ь) После шага (3)
Рис. 7.18. Отмене право передачи сохраняет базовую привилегию
Затем на шаге (3) пользователь U лишает пользователя У права передачи
привилегии р, но не лишает К самой этой привилегии. В результате звездочка
удаляется из узла для К и р Но нз узла без звездочки не может исходить ориенти
рованное ребро, поскольку такой узел не является источником присвоения приви-
легии. Значит, нужно удалить и ориентированное ребро от узла V/р к узлу W/p.
Теперь к узлу W/p нет пути от узла с двумя звездочками, представляющего
источник привилегии р. В результате узел W/p удаляется из диаграммы. Однако
узел V/р остается: он только изменяется за счет удаления одной звездочки, обозна
чающей право передачи привилегии. Результирующая диаграмма присвоения пока
зана на рис 7.18 (Ь) □
7.4- 7 Упражнения к разделу 7.4
Упражнение 7.4.1. Укажите, какие привилегии нужнь для выполнения пере-
числе 1ных hi же запросов. В каждом случае выделите наиболее частные принте
гни, а также общие привилегии. которых достаточно для выполнения запросов.
а) Запрос нз рис 5 3
Ь) Запрос । з рис. 5.5
®с) Операция вставки нз рис. 5.12
d) Операция уличения из примера 5.29
7.4 Защита и авторизация пользователя в SQL2
333
е) Операция изменения из примера 5.31
0 Основанная на кортеже проверка из рис. 6.4
g) Допущение из примера 6.10
* Упражнение 7.4 2. Покажите диаграммы присвоения полномочий, которые
получаются после шагов (4) — (6) в последовательности действий, показанной на
рис. 7.19, считая, что А - владелец отношения, на которое распространяется при-
вилегия р.
Шаг Кем выполняется Действие
1 А GRANT р ТО В WITH GRANT OPTION
2 А GRANTp TO C
3 В GRANT p TO D WITH GRANT OPTION
4 D GRANT p TO В. С. E WITH GRANT OPTION
5 В REVOKE p FROM D CASCADE
6 А REVOKE p FROM C CASCADE
Рис. 7.19. Последовотельнооъ действии для упражнения 7 4 2
Упражнение 7.4.3. Покажите диаграммы присвоения полномочий которые
получаются после шагов (5) и (6) в последовательности действий показанной на
рис. 7.20, считая, что А — владелец отношения, на которое распространяется при-
вилегия р.
Шаг Кем выполняется Действие
1 А GRANT р ТО В. Е WITH GRANT OPTION
2 В GRANT p TO C WITH GRANT OPTION
3 С GRANT p TO D WITH GRANT OPT ON
4 Е GRANT p TO C
5 Е GRANT p TO D WITH GRANT OPTION
6 А REVOKE GRANT OPTION FOR p FROM В CASCADE
Рис. 7.20. Последовательность действий для упражнения 7.4 3
! Упражнение 7.4.4. Покажите диаграмму которая получается в результате вы-
полнения следующих шагов, предполагая, что А — владелец отношения, на которое
распространяется привилегия р.
Кем
Шаг выполняется Действие
1 A GRANT р ТО В WITH GRANT OPTION
2 В GRANT р ТО В WITH GRANT OPTION
3 A REVOKE р FROM В CASCADE
334
Глава 7 Cue емные аспекты SO
7.5 Итоги
+ Встроенный SQL. Вместо применения общего интерфейса запросов для выра-
жения запросов SQL и изменений i lacryio более улоб го п ic-пь программы,
встраивающие за цтосы SQL в обычный главный язык программирования.
+ Несогюсованность моделей. Модели данных SQ1 кардинально отличаются от
мо- ’лей данных обыч зы.х главных языков. Поэтому информация между SQL
н данным языком передаете) с помощью разделяемых переменных, которые
могут представлять компоненты кортежей в SQL фрагменте программы
+ Курсоры. Курсор — это переменная SQL. обозначающая один из кортежей
отношения. Связь между главным языком и SQL осуществляется путем пере-
мещения курсора по всем кортежам отношения. При этом определенные
компоненты выбираются из текущего кортежа, вводятся в разделяемые пере-
менные п обрабатываются с помощью главного языка.
+ Динамический SQL. Вместо погружения отдельных операторов SQL в про
грамму главного языка эта программа может создавать строки символов, ко-
торые интерпретируются и выполняются системой SQL как операторы SQL
+ Контроль параллельности. В SQL2 есть два механизма предотвращения
взаимного влияния параллельных операций транзакции и ограничения на
курсоры. Ограничен тя на курсоры предполагают возможность объявления
курсора "нечувствительным". В результате курсор нс реагирует ни на какие
измене! ия своего отношения
+ Транзакции. SQL позволяет программисту группировать операторы SQL
в транзакции, которые могут быть приняты или отменены (прерваны).
В последнем случае все изменения, внесенные транзакцией, отменяются.
+ Уровни изоляции. С помощью SQL2 можно выполнять транзакции на четырех
уровнях изоляции, которые по стеленi их строгости называются: приведение
в последовательную форму (транзакция должна выполняться либо полностью
до другой транзакции, либо полностью после нее), повторное чтение (каждь й
кортеж, прочитанный в ответ на запрос, появляется снова при повторении
этого запроса), чтение принятых данных (для транзакции доступны только
данные, записанные другой транзакцией, которая уже принята), чтение не
принятых данных (нет иикакт х ограничений на данные, доступные транзакции).
ь Курсоры и транзакции только для чтения. Курсор и транзакция могут пред-
назначаться только для чтения. Такой режим гарантирует, что курсор или
транзакция не изменит БД. и информирует систему SQL о том, что они не
повлияют па другой курсор или транзакцию, не нарушат нечувствительность,
последовательную форму или другие требования.
+ Организация БД. Инсталляция СУБД, реалп уюшей SQL2. создает среду SQL.
В этой среде этементь БД группируются в схемы (БД), каталоги и кластеры
Каталог — это множество схем, а кластер самое большое множество эле-
ментов доступное пользователю.
+• Системы клиент/сервер. Клиент SQL подключается к серверу SQL создавая
с ним связь (соеди ение двух процессов) и сеанс (последовательность
опера । й) Вы олняемая во время сеанса программа поступает из модуля,
а выполнение модуля называется агентом SQL.
7.6 Литература к главе 7
335
♦ Привилегии. Для обеспечения защиты данных в SQL2 предусмотрено множест
во типов привилегий, которые нужно получить для работы с элементами БД
Эти привилегии включают в себя право выбирать (читать), вводить, удалять
или изменять отношение, а кроме того, ссылаться на отношение (при введе-
нии ограничения). Привилегии вставки и изменения, а также привилегии
ссылок можно получить и на отдельные столбцы отношения.
♦ Диаграммы присвоения привилегий. Обладатели привилегия могут присвоить
их другим пользователям или пользователю PUBLIC. Если привилегии при-
сваиваются с правом передачи, их можно присваивать другим пользователям.
Привилегии можно отменить. Диаграмма присвоения привилегий — удобный
способ запоминания истории присвоений и отмен привилегий, необходимый
для отслеживания того, кто какие привилегии имеет и откуда он их получил.
7.6 Литература к главе 7
Информацию о стандарте SQL2 можно найти в библиографических примеча-
ниях к главе 5. Проблемы этого стандарта, связанные с транзакциями и курсорами,
рассматриваются в работе [1] приведенного списка литературы.
Наиболее важная идея реализации транзакций под названием двухфазового за-
мыкания предложена в книге |3]. Другая информация об управлении транзакциями
и их реализации содержится в работах [2] и [5]. Идеи, являющиеся основой автори-
зации SQL2. разработаны в книгах [6] и [4].
1. Berenson, Н., Р. A. Bernstein, J N. Gray, J. Melton, E O’Neil, and P.O Neil,
"A crtique of ANSI SQL isolation levels," Proceedings of ACM S1GM0D Ind.
Conf, on Management of Data, pp. 1-10, 1995.
2. Bernstein, P A., V. Hadzilacos, and N. Goodman. Concurrency Control and
Recovery in Database Systems, Addison-Wesley, Reading, MA, 1987.
3. Eswaran, К. P., J. N. Gray, R. A. Lorie and I L. Traiger, "The notions of
consistency and predicate locks in a database system," Communications of the
ACM 19:11, pp. 624-633, 1976.
4. Fagin. R, "On an authorization mechanism," ACM Transactions on Database
Systems. 3 3, pp. 310-319, 1978.
5. Gray, J. N. and A Reuter, Transaction Processing: Concepts and Techniques,
Morgan-Kaufmann, San Francisco, 1993.
6. Griffiths, P. P. and B. W. Wade, "An authorization mechanism for a relational
database system," ACM Transactions on Database Systems, 1.3, pp. 242-255, 1976.
Глава 8
Объектно-ориентированные
языки запросов
В этой главе рассматриваются два способа ввести объектно-ориентированное
программирование и мир БД. OQL и SQL3 — это зарождающиеся стандарты, а не
широко реализуемые языки. Тем не менее они находят применение и их идеи
быстро внедряются в коммерческие системы.
Объектный язык запросов (OQL) — это попытка стандартизовать объектно-ори-
ентированные языки запросов в форме языка, соединяющего в себе декларативное
программирование SQL высокого уровня с объектно-ориентированной парадигмой
программирования. Данная глава начинается с обсуждения методов и степеней
ODL — языка определения объектов, введенного в качестве средства моделирова-
ния в главе 2. Его характерные свойства существенно влияют на язык запросов
OQL. Затем будут рассмотрены различные аспекты программирования в OQL.
Если OQL — это попытка ввести SQL в объектно-ориентированную область, то
SQL3 можно считать переносом всего самого лучшего из объектно-ориентированной
области в реляционный мир. В определенном смысле эти два языка "в чем-то
согласуются", но в то же время между ними есть существенная разница. Поэтому,
рассмотрев объектно-ориентированных свойства стандарта SQI..3, мы сравним воз-
можности этих двух языков.
В сущности, два подхода к объектной ориентации рахличаются ответами на
вопрос: "Насколько важным является отношение?" Объектно ориентиропанное
сообщество, сложившееся вокруг ODL и OQL, отвечает: 'Отношение не очень важно".
При таком подходе используются объекты всех типов, в том числе множества
или мультимножества структур (те отношения). Для сообщества SQL3 отношение
остается фундаментальным понятием структурирования данных При подходе SQL3,
который часто называется объектно-реляционным, реляционная модель расширя-
ется за счет введения более сложных типов для кортежей отношений и для
областей, принадлежащих атрибутам отношений. Объекты п классы вводятся
в реляционную модель только внутри какого-то отношения.
8.1 Свойства OD£, связанные с запросами
В этом разделе будет продолжено обсуждение ODI из главы 2. Сначала мы
рассмотрим, как классы ODL взаимодействуют со средой программирования,
в которую они введены, а затем перейдем к "степеням" класса, которые играют
в OQL роль, аналогичную роли отношений в SQL.
8.1 Свойства ODL, связанные с запросами
337
8.1.1 Операции па объектах ODL
Язык OQL позволяет выразить операции, имеющие реляционные, или осно-
ванные на множествах, особенности, во .многом гак же. как и SQL Однако в нем
часто приходится выполнять другие операции, нс связанные с множествами
Например, если объектами являются документы, может потребоваться проверить;
содержит ли данный документ определенное ключевое слово. Если объект —эле-
мент карты или рисунка, может понадобиться показать его точное место располо-
жения Даже обычные, ориентированные на записи данные типа нашего примера
с фильмами можно использовать для специальных операций типа построения графа,
сражающего число фильмов, в которых данная кинозвезда играла в каждом году. ’
В SQL такие операции выполняются программой, которая написана на обычном,
или главном, языке программирования типа Сив которую встроены операторы
SQL. Значения передаются между переменными SQL и главного языка с помощью
механизмов, введенных в разделе 7.1.
Определения ODL связаны с главным языком более тесно. Предполагается,
что главный язык — это объектно-ориентированный язык С ь+ или Smalltalk Каж
дый из них достаточно близок к ODL, чтобы описания ODL можно было прямо
перевести на главный язык Переменные главного языка легко выражают объекты,
описанные в операторах ODL.1
Соединять главный язык с описаниями ODL и запросами OQL еще удобнее ODL
допускает третий вид свойств (помимо атрибутов и связей) — методы Метод — это
функция, связанная с классом. Она применима к объекту класса, но может иметь н
другие аргументы. Методы можно применять в ODL почти так, будто они являются
атрибутами класса.
8.1.2 Описание сигнатур метода в ODL
В ODL можно описать имена методов, связанных с классом, и типы ввода/
вывода этих методов. Эти описания, называемые сигнатурами, похожи на описания
функций в С и C++ (в отличие от определений функций, представляющих программы
реализации этих функций). Реальная программа для метода пишется на главном
языке и не является частью ODL.
Описания методов входят вместе с атрибутами и связями в описание интерфей-
са. В объектно-ориентированных языках каждый метод обычно связан с классом
(т.е. с интерфейсом) и вызывается на объекте этого класса Таким образом, объект
является "скрытым' аргументом метода Этот подход позволяет использовать одно
имя метода для нескольких различных классов, поскольку смысл конкретного метода
определяется объектом, на котором выполняется операция Такое имя метода назы-
вается переопределенным (оно появляется в качестве метода для нескольких классов).
Синтаксис описания методов похож на синтаксис описания функций в языке С
с двумя важными дополнениями.
I. Параметры функции определяются как in, out или mout. Это значит, что
они применяются для ввода и вывода параметров пли того и другого
соответственно. Последние два типа параметров можно изменить с по-
мощью функции; параметр in не изменяется. Параметры out и inout
передаются с помощью ссылки, а параметры in — с помощью значения.
Функция может иметь возвращаемое значение — это способ получения
результата функции, отличающийся от приписывания значения параметру
out или inout.
1 Напомним, чтп типы переменных главного языка, например натуральные числа,
не соответствуют фунл, ментальным типам данных SQL кортежам и отношениям.
Поэтому, как было показано п разделе 7 I. соединение SQL с главным языком
является достаточно громонким. _____ —ш
330
Глава 8 Объектно-ориентированные языки запросов
2. Функции могут порождать исключении — особые отпеты, выходящие за
рамки нормальной передачи значений и механизма ответа посредством
которого взаимодействуют функции. Исключение обычно выражает
ненормальное или неожиданное условие, которое будет "использоваться"
какой-то вызвавшей его функцией (возможно, косвенно, через последова
тельность вызовов). Деление на нуль — пример условия, которое можно
считать исключением. В ODL за описанием функции может следовать
ключевое слово raises и заключенный в скобки список исключений,
которые способна породить данная функция.
Значение сигнатур
Значение сигнатур состоит в том, что при реализации схемы в реальном j
j языке программирования можно автоматически проверять соответствие г
1 конкретной реализации проекту, выраженному в схеме. Нельзя проверить, '
' правильно ли выражен в реализации смысл операций, но можно, по крайней [
( мере, проверить число и тип параметров ввода и вывода. f
L.... ==, . . — =- — — .1
Пример 8.1. На рис. 8.1 показано развитие определения интерфейса для класса
Movie, ранее представленного на рис. 2 6.
1) interface Movie
2) (extent Movies
3) key (title, year))
{
4) attribute string title;
5) attribute integer year;
6) attribute integer length,
7) attribute enumeration(coloi. blackAndWhite) filmType
8) relationship Set<Star> stars
inverse Star:: starredln
9) relationship Studio ownedBy
inverse Studio :: owns;
10) float lengthlnHours() raises(noLengthFound);
11) starNames(out Set<String>),
12) otherMovies(in Star, out Set<Movie>)
raises(noSuchStar);
}.
Рис. 8.1. Добовление сигнатур метода к классу Movie
Здесь есть два изменения, не связанных с методами.
1. В строке (2) стоит "описание extent" Его назначение будет рассмотрено
в разделе 8.1 3
2. В строке (3) title и year описываются в качестве ключа для отношения Movie.
В описание этого интерфейса включены методы. Строка (10) описывает метод
lengthlnHours Можно считать, что он порождает в виде возвращаемого значения
длительность объекта "фильм’, к которому он применяется, но при этом переводит
минуты (представленные в атрибуте length) в часы, выраженные числом с плавающей
точкой. Эта функция не использует параметры Объект отношения Movie, к которому
применяется метод, является "скрытым" аргументом и именно из него возможная
реализация lengthlnHours получает продолжительность фильма в минутах
8 1 Свойства ODL, связанные с запросами
339
Функция может порождать исключение noLengthFound. Вероятно, оно возникает
•югда когда атрибут length объекта, к которому применяется метод lengthlnHours,
имеет неопределенное значение, не способное выразить правильную продолжи-
тельность (например, отрицательное число).
Обратите внимание: в описании нет ничего, что требовало бы от метода
выполнения того, что следует нз его имени Например, можно реализовать метод
lengthlnHours с помощью функции, всегда возвращающей 3,14159 независимо от
объекта отношения Movie, к которому она применяется Можно также реализовать
его в виде функции, возврашаюшей квадрат продолжительности фильма, переве-
денный п число с плавающей точкой. Здесь применима любая функция, которая
не использует аргументов (кроме объекта, к которому опа применяется), воз-
вращает число с плавающей точкой и не порождает никаких исключений,
кроме noLengthFound.
На строке (II) находится сигнатура другого метода — функции starNames. У этой
функции нет возвращаемого значения, но она имеет параметр вывода, типом
которого является множество строк. Предполагается, что значением параметра,
вычисляемого этой функцией, служит множество строк, являющихся значениями
атрибута name, к которому применяется данный метод. Однако нет никакой гаран-
тии, что реализуемая функция действует именно так.
И наконец, на строке (12) находится третий метод otherMovies Эта функция
имеет параметр ввода типа Star. Возможна следующая ее реализация. Функция
предполагает, что данная кинозвезда снимается в фильме. Если это не так, порож-
дается исключение noSuchStar. Если же кинозвезда участвует в фильме, к которому
применяется метод, тогда множество всех других фильмов, где снималась эта кино-
звезда, приписывается в качестве значения параметру вывода, типом которого
является множество фильмов. □
8.1.3 Экстент класса
Для каждого класса (интерфейса) ODL можно определить его экстент — имя
текущего множества объектов этого класса. Экстент описывается ключевым словом
extent, за которым следует выбранное имя. Это описание должно стоять непосред-
ственно за именем интерфейса (класса).
По существу экстент класса анало1ичен имени отношения, а само определе-
ние класса аналогично описанию типов атрибутов этого отношения. Как будет
показано далее, запросы OQL относятся к степени класса, а не к его имени.
Пример 8.2. Строка (2) на рис. 8 1 иллюстрирует определение степени класса
Movie. Имя этой степени — Movies. Значением Movies всегда является множество
всех объектов класса Movie, существующих в БД в данный момент. □
8.1.4 Упражнения к разделу 8.1
Упражнение 8.1.1. Рис. 8.2 — это описание, в котором все три типа продуктов
сделаны подклассами главного класса Product. Тип продукта можно получить или из
атрибута type, или из подкласса, к которому он принадлежит. Этот метод не самый
лучший, так как он допускает возможность совпадения атрибута type объекта PC с
laptop или printer Однако он обеспечивает интересные режимы выражения запросов.
Поскольку Pnnter наследует type из суперкласса Product, необходимо переиме-
новать атрибут type класса Printer в pnnterType. Последний выражает способ печати
(например, лазерный или струйный), a type из Product имеет значения типа ПК
ПК блокнот или принтер.
Добавьте к программе ODL (рис. 8.2) сигнатуры методов, подходящие для
функций, выполняющих следующие задачи:
*а) Выделите х из иены продукта Предполагается, что х — это параметр
ввода данной функции
340
Глава 8 Объектно-ориентированные языки запросов
interface Product
(extent Products
key mode)
{
attribute integer model;
attribute string ma Tufactu er;
attribute string type,
attribute real price;
}:
interface PC : P oduct
(extent PCs)
{
att ibute integer speed;
att ibute integer ram;
attribute integer hd;
attribute st ing cd;
};
nterface Laptop: Product
(extent Laptops)
{
attr bute in eger speed;
attribute integer ram;
attr bute integer hd;
attr bute real screen,
};
nterface Printer: Product
(extent Pnnters)
I
attribute boolean color,
attribute st ing printerType;
}.
Рис. 8.2. Схема Product в ODL
4b) Возвратите скорость продукта, если им является ПК или ПК-блокнот,
и генерируйте исключение notComputer в противном случае.
с) Установите размер экрана П К-блокнота в определенное значение ввода т.
! d) Для заданного продукта р определит, имеет ли продукт q, к которому
применяется метод, более высокую скорость и меньшую цену,
чем продукт р. Генерируйте исключение badlnput, если продукт р
не имеет скорости (т.е. не является ни ПК, ни ПК-блокнотом),
и исключение noSpeed, если продукт q не имеет скорости
Упражнение В.1.2. Рис. 8.3 — это описание ODL БД боевых кораблей. Добавь-
те к нему следующие сигнатуры методов:
а) Вычислите огневую мощь корабля, те. число орудий умноженное на куб
их калибра
Ь) Найдите корабли-"близнены" для каждого корабля. Генерируйте исключе-
ние noSisters, если корабль является единственным в своем классе
с) Принимая сражение Ь в качеснзе параметра и приме! яя метод к кораблю s,
найдите корабли, потопленные в сражении b при условии, что в этом
сражении участвовал корабль 5. Генерируйте исключение, если корабль s
не участвовал в сражении b
8.2 Введение в 00L
341
d) Принимая имя и год спуска корабля на воду в качестве параметров,
добавьте этот корабль к классу, к которому применяется метод.
interface Class
(extent Classes
key name)
(
attribute string name;
attribute string country;
attribute integer numGuns
attribute integer bore;
attribute integer displacement;
relationship Set<Ship> ships inverse Ship::classOf;
}:
interface Ship
(extent Ships
key name)
{
attribute name;
attribute integer launched;
relationship Class classOf inverse Class'rships
relationship Set<Outcome> inBattles inverse Outcome.-theShip;
};
Interface Battle
(extent Battles
key name)
{
attribute name;
attribute Date dateFought;
relationship Set<Outcome> results inverse Outcome:.theBattle;
};
Interface Outcome
(extent Outcomes)
{
attribute enum Stat (ok.sunk.damaged) status,
relationship Ship theShip inverse ShiprinBattles;
relationship Battle theBattle Inverse Battle..results,
}:
Рис. 8.3 БД боевых кораблей в ODL
8.2 Введение в OQL
В этом разделе вводится понятие языка объектных запросов OQL. Он рассмат-
ривается не так подробно, как SQL. Здесь будут описаны только наиболее важные
виды операторов и характерные особенности OQL, но в нем сушествует и множе-
ство других средств. Часто они похожи на соответствующие средства SQL или
типичных объектно-ориентированных языков программирования.
OQL не позволяет выразить произвольные функции так. как они выражаются
it обычных языках программирования типа С. Он обеспечивает сходную с SQL но-
тацию для выражения конкретных запросов на более высоком уровне абстракции,
чем типичные операторы обычного языка. Предполагается, что OQL применяется
как расширение главного объектно-ориентированного языка типа C++. Smalltalk
пли Java Объектами манипулируют и запросы OQL, и обычные операторы главного
языка Возможность соединять операторы главного языка с запросами OQL без
явного переноса значений между двумя языками имеет более высокий уровень, чем
способ встраивания SQL в главный язык, рассмотренный в ргзделе 7.1.
Глава 8 Объекгно-ориентированные языки запросов
8.2.1 Объектио-ориентированный пример
Для иллюстрации выражений OQL в качестве примера возьмем знакомые
классы Movie. Star п Studio н используем определение Movie из рис. 8.1. Опреде
пения Star и Studio, введенные на рис. 2.6, дополняются ключом и описанием степе-
ни. но в них не вводятся методы (см. рис. 8.4).
nterface Star
(extent Stars
key name)
{
attribute string name;
attribute Struct Addr
{string street, string city) address,
relationship Set<Movie> starredln
inve se Movie- stars;
}
interface Studio
(extent Studios
key name)
{
attribute string name,
attribute string address;
relationship Set<Movie> owns
inverse Movie. ownedBy;
}
Рис. 8.4. Часть обоектно-ориеигированной БД фильмов
8.2.2 Система типов OQL
Типы в OQL строятся во многом так же, как и в описаниях ODL (см. раздел 2.1.7).
Однако в OQL существует предел вложения конструкторов типов.
Рассматривая систему типов языка программирования нужно различать описание
типа переменной (иногда называемая изменчивым объектом) и выражение постоянного
значения (иногда называемого неизменным объектом). Переменные, используемые
в операторах OQL, описываются в окружающем главном языке с помощью нотации
ODL (раздел 2.1 7) или чего-то подобного. Как язык определения данных ODL не
нуждается в константах, но в программах OQL они нужны. Поэтому необходимо
знать, как в OQL создаются константы произвольного типа Они строятся на опи-
санном далее базисе с помощью конструкторов типов
1. Базовые типы
(а) Натуральные числа числа с плавающей точкой, символы, строки
н булеаны. Все они представляются так же, как в SQL, только строки
заключаются в двойные кавычки.
(Ь) Перечисления. Значения в перечислениях реально описываются в ODL.
Любое из этих значений можно использовать в качестве константы
2. Сложные типы строятся из следующих конструкторов типов
(a) Set(..)
(b) Вад( )
(с) List(. .)
(d) Array(...)
(е) Struct( )
8 2 Введение в 001 343
Первые четыре называются типами множества. Их и Struct можно при-
менять к любым значениям подходящих базовых или сложных типов.
Используя Struct надо определить имена полей и соответствующие нм
значения. За каждым именем поля следует двоеточие и значение а пары
значений полей разделяются запятыми.
Пример 8.3. Выражение bag(2.1,2) обозначает мультимножество, и которое
число 2 входит дважды, а число I — один раз. Выражение
struct(foo: bag(2, 1, 2), bar; "baz")
обозначает структуру с двумя полями. Одно поле с именем too в качестве своего
значения имеет упомянутое выше мультимножество, а значением второго поля baz
является строка baz □
8.2.3 Выражения с путем доступа
Для доступа к компонентам переменных со сложным типом используется
точечная нотация, аналогичная точкам, применяемым в языке С, и связанная
с точками в SQL. Общее правило выглядит следующим образом Если а обозначает
объект, принадлежащий классу С, а р — некоторое свойство класса (атрибут, связь
или метод), то а.р обозначает результат применения р к а.
I. Если р —атрибут, то ар — значение этого атрибута в объекте а
2. Если р — связь, то а.р — объект или множество объектов,
соединенных с а связью р.
3. Если р — метод (возможно, с параметрами), то а.р — результат
применения р к а.
4
i
f
I
I
I
I
i
t
i
j
Стрелки вместо точек
В OQL стрелка -> — синоним точки. Это соглашение частично соответст- J
кует духу языка С. в котором точка и стрелка применяются для получения |
компонентов структуры Однако в языке С стрелка и точка имеют разные зна- i
чения, а в OQL — одно и то же. В С предполагается, что в выражении a f бук
ва а обозначает структуру, а в выражении p->f буква р обозначает указатель j
на структуру. Оба выражения порождают значение поля 1 этой структуры
Пример 8.4. Пусть myMovie — переменная главного языка, значением которой
является объект класса Movie.
• Значением myMovje.length является продолжительность фильма, т.е. значение
атрибута length для объекта Movie, обозначенного как myMovie
• Значением myMovie lengtHnHours() является действительное число, т.е.
продолжительность фильма в часах, вычисленная путем применения метода
lengthtnHours к объект) myMovie
» Значение myMovie.stars — это множество объектов класса Star, соединенных
с фильмом myMovie связью stars.
• Выражение myMovie.starNames(myStars) не возвращает никакого значения
(г.е. в C++ типом этого выражения является void). Однако в качестве побоч-
ного эффекта оно делает множество строк значением выходной переменной
myStars метода starNames, эти строки обозначают имена кинозвезд, играю
щих в фильме. □
344
Глава 8 Объектно-ориентированные языки запросов
Выражение можно формулировать с множестзом точек, если это имеет смысл
Например, если myMovIe обозначает объект Movie, то myMovie ownedBy обозн1Ч1ет
объект Studio старый владеет фильмом, a myMov е ownedBy.name обозначает строку,
выражающую имя этой студии.
8.2.4 Выражения типа select-from-where в OQL
OQL позволяет записывать выражения с помощью синтаксиса select-from-where,
аналогичного известной форме запроса SQL. Приведем пример запроса о годе вы-
пуска фильма "Gone With the Wind":
SELECT m.year
FROM Movies m
WHERE m title = "Gone With the W nd"
Если исключить двойные кавычки, в которые заключена строка-константа, то этот
запрос будет запросом SQL, а не OQL Единственным несоответствием является то,
что пункт FROM запроса SQL обычно записывается как
FROM Movies AS m
Однако в OQL ключевое слово AS применяется по выбору, как и в SQL. Оказь ва-
ется. что в OQL вполне разумно пропускать это слово, так как выражение Movies m
означает, что m — переменная, указывающая на каждый объект из степени Movies
т.е. из текущего множества объектов класса Movie.
В общем случае в выражение OQL типа select-from-where входят следующее элементы:
1. Ключевое слово SELECT, за которым следует список выражений.
2. Ключевое слово 7ROM, за которым следует список описаний переменных.
Переменная описывается с помощью
(а) выражения, значение которого имеет тип множества, например
множества пли мультимножества;
(b) npi меняемого по выбору ключевого слова AS;
(с) имени переменной.
Обычно выражением в пункте (а) является экстент некоторого класса,
скажем Moves для класса Movie. Экстен — аналог отношения в пункте FROM
запроса SQL. Но в описании переменной применимо любое выражение,
порождающее множество, например другое выражение типа select-from-
where. В SQL2 нет прямого аналога такой возможности, хотя некоторые
коммерческие системы SQL допускают подзапросы в пунктах FROM.
3 Ключевое слово WHERE и булевозначное выражение. В нем как и в выра-
жении. следующем за SELECT, в качестве операндов используются только
константы и переменные, указанные в пункте FROM. Операторь сравнения
тс, что и n SQL. по для выражения применяется символ ! =, а не <>.
Логические операторы AND, OR и NOT имеют такой же смысл, как и в SQL.
Запрос порождает мультимножество объектов. Оно вычисляется путем рас-
смотрения возможных значений переменных в предложении FROM во вложенных
ни ах. Если любая комбинаи |я значении этих переменных удовлетворяет условию
предложения WHERE, то объект, описанный предложением SELECT, добавляется
к мультимножеству. являющемуся результатом оператора типа select-from-where
Пример 8.5. Запишем более сложный запрос OQL. иллюстрирующий стрхктуру
select- from-where:
SELECT s.name
FROM Movies m, r.stars s
WHERE m tit e = "Casablanca"
8 2 Введение в OQL 345
Он относится к именам кинозвезд из фильма "Casablanca" Обратите внимание на
порядок термов в пункте FROM Сначала m определяется как произвольный объект
класса Movie указанием на то, что m входит в степень класса Movies. Затем утверж-
дается, что для каждого значения m, s есть объект класса Star из множества m stars
кинозвезд данного фильма т, т.е в двух вложенных циклах рассматриваются все
такие пары (m, s), в которых m — фильм as — кинозвезда, играющая в данном
фильме. Вычисление этого запроса может быть представлено следующим образом:
FOR each m in Movies DO
FOR each s in m.stars DO
IF m.title = "Casablanca" THEN
add s.name to the output bag
Пункт WHERE ограничивает сферу поиска теми парами в которых m совпадает
с объектом Movie, имеющим название Casablanca. Пункт SELECT порождает муль-
тимножество (в данном случае оно будет множеством) всех атрибутов имен объек-
тов кинозвезд s в парах (m, s), удовлетворяющих пункту WHERE. Эти имена явля-
ются именами кинозвезд из множества ' т,..stars, где тс обозначает объект
Casablanca. □
8-2.5 Устранение дубликатов
Технически запрос, аналогичный запросу из примера 8 5, порождает в качестве
отпета мультимножество, а не множество, т.е., в OQL, как и в SQL, дубликаты по
умолчанию не устраняются из ответа на запрос, если это не оговорено специально
Как и в SQL. их можно устранить с помощью ключевых слов DISTINCT и SELECT
Пример 8.6. Допустим, нужно выяснить имена кинозвезд, играющих в филь-
мах студни Disney. Это можно сделать с помощью следующего запроса, устраняя
дубликаты имен гогда. когда одна кинозвезда появляется во многих фильмах.
SELECT DISTINCT s.name
FROM Movies m. m stars s
WHERE m ownedBy.name = "Disney"
Стратегия этого запроса аналогична стратегии запроса из примера 8.5. Здесь
тоже рассматриваются пары "кинозвезда — фильм" в двух вложенных циклах. Но
теперь условие для пары (m, s) заключается в том, что Disney — это имя студии,
объектом которой в классе Studio является m ownedBy □
8.2.6 Сложные входные выражения
Выражения в пункте SELECT необязательно простые переменные. В них могут
входить другие выражения, построенные конструкторами типов. Например, можно
применить конструктор Struct к нескольким выражениям и получить запрос типа
select-from-where, порождающий множество или мультимножество структур.
Пример 8.7. Предположим, нужно найти .множество пар кинозвезд, проживаю-
щих по одному адресу. Это можно сделать с помощью следующего запроса
SELECT DISTINCT Slruct(star1: s1 star2: s2)
FROM Stars s1. Stars s2
WHERE s1.addr= s2.addr AND sl.name < s2.name
Рассматриваются пары кинозвезд s1 и s2. Пункт WHERE проверяет, имеют ли они
один адрес, предшествует ли имя первой кинозвезды имени второй в алфавитном
порядке, поэтому невозможно получить пару, куда одно имя входит дважды, или
Две пары, и которые одни и те же кинозвезды входят в разном порядке.
346
Глава Б Объектно-ориентированные язькн запросов
Для каждой пары, прошедшей проверку, порождается структура записи. Тип
этой структуры — запись с полями starl и star2. Типом каждого поля является Star,
так как это тип переменных s1 и s2, обеспечивающих значения двух полей.
Формально типом этой структуры является
Struct N {starl: Star star2. Star}
для некоторого имени Л'. Тип результата запроса — множество таких структур
типа Л', т.е.
Set<Struct N {starl: Star, star2: Star}>
Тип результата данного запроса — пример типа, который может появиться в про-
граммах OQL. но он не будет типом атрибута или связи в описании ODL. □
Оказывается, результат примера 8.7 можно получить, не определяя явно тип
структуры, а перечислив компоненты и имена полей после клю iccoro слона SELECT.
Тогда первая строка запроса из примера 8.7 будет выглядеть следующим образом:
SELECT start . s1, Star2: s2
8.2.7 Подзапросы
Выражения типа select-from-where можно использовать везде, где применяются
множества. В частности, подзапросы допускается размешать в пункте FROM, где
множество, являющееся областью переменной, можно построить с помощью выра-
жения типа select-from-where. Аналогичное средство — применение выражения
определяющего таблицу вместо имени таблицы,— входит в предполагаемый стан
дарт SQL3 и доступно в некоторых коммерческих системах.
Пример 8.8. Сформулируем заново запрос из примерз 8.6 о кинозвездах филь-
мов студии Disney. Множество фильмов этой студии можно получить по запросу:
SELECT m
FROM Movies m
WHERE m ownedBy name - "Disney"
Далее этот запрос используется в качестве подзапроса для определения множества,
по которому может пробегать переменная d, обозначающая фильмы студии Disney:
SELECT DISTINCT s name
FROM (SELECT in
FROM Movies m
WHERE m ownedBy name - "Disney") d,
d. stars s
Это выражение запроса "Найти кинозвезд, снявшихся в фильмах студии D’sney"
не короче запроса из примера 8.6, но оно иллюстрирует новую форму построения
запросов в OQL В этом запросе пункт FROM содержит два вложенных цикла.
В первом из них переменная d пробегает множество фильмов студии Disney, явля-
ющееся результатом подзапроса из пункта FROM. Во втором цикле, вложенном
в первый, переменная s пробегает множество кинозвезд, играющих в фильме d.
Заметим, что при этом пункт WHERE не нужен. □
8.2 8 Упорядочение результата
В OQL результатом выражения типа select-from-where является мультимноже-
ство или множество (если применяется DISTINCT). Вывод можно сделать сп зеком и
при этом задать определенный порядок его элементов, применяя пункт ORDER BY
в конце выражения sclect-from-where. ORDER BY в OQL анало ичен такому же
пункту в SQL За ключевыми словами ORDER BY следует список выражений.
8.2 Введение в OQL
347
Первое из них оценивается для каждого объекта из результата запроса, и объекты
упорядочиваются по этому значению. Соединения, если они существуют, прерыва-
ются значением второго выражения, затем третьего и т.д.
Пример. 8.9. Найдем множество фильмов студии Disney и представим резуль-
тат и виде списка фильмов, упорядоченных по их продолжительности. Фильмы
одинаковой продолжительности будем упорядочивать по алфавиту.
SELECT m
FROM Movies m
WHERE m.ownedBy.name = "Disney"
ORDER BY m.length, m.title
Пермь e три строки этого запроса идентичны подзапросу из примера 8.8. Четвертая
строка означает, что объекты т, порождаемые запросом seleci-from-where, должны
быть упорядочены по значению m.length (т.е. по продолжительности фильма), а при
одинаковой продолжительности по значению m.titie (т.е по названию фильма) Та-
ким образом, значением, порождаемым этим запросом, является список объектов
класса Movie. По умолчанию этот порядок восходящий, но восходящий или
нисходящий порядок можно задать явно, указав ключевое слово ASC или DESC
соответственно в конце пункта ORDER BY. как и в SQL. □
8.2.9 Упражнения к разделу 8.2
Упражнение 8.2.1. Используя схему ODL упражнения 8.LI и рис. 8.2, запи-
шите следующие запросы OQL:
*а) Найдите номера моделей всех продуктов, являющихся ПК с ценой
менее 2000 дол.
Ь) Найдите номера моделей всех ПК с объемом RAM не менее 32 Мбайт.
* с) Найдите производителей, выпускающих по крайней мере две модели
лазерных принтеров.
d) Найдите множество таких пар (г, Л), чтобь ПК или ПК-блокнот имели
t Мбайт RAM и h Гбайт на жестком диске.
е) Создайте список номеров моделей ПК (объектов а не номеров моделей),
упорядоченных по возрастанию скорости процессора.
!f) Создайте список номеров моделей ПК-блокнотов, имеющих не менее
16 Мбайт RAM, упорядоченных по убыванию размера экрана
! Упражнение 8.2.2. Повторите каждую часть упражнения 8.2.1, применяя в каж-
дом запросе по крайней мере один подзапрос.
Упражнение 8.2.3. Используя схему ODL упражнения 8.1.2 и рис. 8.3, запи-
шите следующие запросы OQL:
а) Найдите имена классов кораблей, имеющих не менее девяти орудий.
Ь) Найдите корабли (объекты, а не имена кораблей), имеющие не менее
девяти орудий.
с) Найдите имена кораблей водоизмещением менее 30 тыс. тонн. Результат
представьте в виде списка, упорядоченного по самому раннему году
спуска на воду, а при совпадении годов — по названиям в соответствии
с алфавитом.
d) Найдите пары объектов, являющихся кораблям и-“близнеиами‘ (те. корабля
ми одного класса) При этом нужны сами объекты, а не имена кораблей.
348
лава 8 Объектно ориентированные языки запросов
!е) Найдите названия сражений, в которых были потоплены корабли
по меньшей мере двух стран.
!! 0 Найдите названия сражений, в которых ни один корабль не был поврежден.
8.3 Дополнительные формы
выражений OQL
8 этом разделе рассмотри иаются другие операторы, применяемые для построе-
ния выражений OQL- логи1еские кванторы ("для всех" и "сушествует”), операторы
ирегании, оператор "группирования по." и теоретико-множестве ные операторы
(объединенье, пересечение и разность).
8.3.1 Выражения с кванторами
Можно проверить, удовлетворяют ли заданному условию все члены множества
или по крайней мере один его член Для проверки удовлетзоряют ли все члены
множеств! Л условию С(х). где х — переменная, используем выражение OQL
FOR ALL л- IN 5 . С(л)
Резуль ат выражения 1 меет значение TRUE, если каждый х удовлетворяет С(х), и
значение FALSE — в противном случае. Выражение
EXISTS л- IN 5 : С(х)
имеет значение TRUE, еслг сущее вует по крайней мере один х, удовлетворяющий
условию С(л'), и значение FALSE в противном случае.
Пример В.10. Олин из способов выражения запроса "Найти кинозвезд, играю
шпх в флльмах киностудии Disney" показан на рис. 8.5 Требуется выяснить:
снималась ли кинозвезда s в фильмах кнностуди Disney. Условие в строке (3)
выбирает все кинофильмы т, из набора s.starredln, в которых играла кг нозвезда s.
Условие в строке (4 выбирает кинофильмы т, созданные на киностудии Disney.
При обнаружении хотя бы одного такого фильма выражение EXISTS в строках (3) и (4)
примет значение TRUE, в противном случае — FALSE. □
1) SELECT s
2) FROM Stars s
3) WHERE EXISTS m IN s.starred n :
4) m.ownedBy.name = "Disney"
Рис. 8.5. Применение подзапроса с квантором существования
Пример 8.11. Применим оператор FOR ALL для записи запроса о кг нозвездах,
играющих в фильмах студии Di 1 еу. Такой запрос показан на рис. 8.6. Технически
в это множество входят кинозвезды, которые вообще не появляются ни в од| ом
фильме (в соотве стяни с рассматриваемой БД). К запросу можно добавить усло-
в ie согласно которому кинозиезда появляется по крайней мере в одном фильме,
но мы оставляем это изменение в качестве упражнения □
1) SELECT s
2) FROM Stars s
3) WHERE FOR ALL m IN s.starredln
4) m.ownedBy.name = 1 Disney
Рис. 8.6. Применение подзапросе с квантором всеобщности
8.3 Дополнительные формы выражений OQL
349
8.3-2 Выражения агрегации
В OQL применяются те же пять операторов агрегации, что и в SQL: AVG,
COUNT, SUM, MIN и MAX. Но в SQL они применяются к выделенному столбцу
отношения, а n OQL — к множеству с членами подходящего типа. COUNT приме-
няется к любому множеству; SUM и AVG — к множеству арифметических типов,
a M1N и МАХ — к множествам любого типа, которые можно сравнивать, например
К арифметическим значениям строк.
Пример 8.12. Для вычисления средней продолжительности всех фильмов со-
здадим мультимножество длительности всех фильмов. Нам не нужно множество
длительности фильмов, так как в нем два фильма одинаковой продолжительности
считались бы одн гм
AVG(SELECT m.length FROM Movies m)
Здесь используется подзапрос, извлекающий компоненты продолжительности
фильмов. Он порождает мультимножество продолжительности фильмов, и приме-
нение AVG к этому мультимножеству дает желаемый результат. □
8.3.3 Выражения GROUP BY
В выражение GROUP BY языка OQL входят следующие элементы.
I. Ключевые слова GROUP BY.
2. Список разделенных запятыми атрибуты разбиения, каждый из которых
включает в себя;
(а) имя поля
(Ь) столбец
(с) выражение
Форма оператора GROUP BY:
GROUP BY fr e„ .........
Оператор GROUP BY следует за запросом типа select-from-where. В выражениях
Ъ....
могут использоваться переменные пункта FROM. Чтобы упростить объяснение
действия оператора GROUP BY, ограничимся обычным случаем, когда пункт FROM
содержит единственную переменную х. Значение х пробегает некоторое множество С.
Для каждого члена i множества С, удовлетворяющего условию пункта WHERE, мы
оцениваем все выражения, следующие за GROUP BY, приписывая им значения
et (/). е-. (0. - , е„ (/) Сей список есть группа, к которой принадлежит значение /.
Реальное значение возвращаемое оператором GROUP BY,— это множество
структур. Члены этого множества имеют форму
Struct(/, : и,, /,: и2, ... f„: v„, partition Р)
Первые п полей обозначают группу, т.е. г2, ..., v„ — это список значений,
полученных при оценке е( (/), е2 И. —• (0 по. крайней мере для одного значения i
и множестве С, удовлетворяющего условию пункта WHERE.
Последнее поле имеет специальное имя partition Его значение Р — это значе-
ния /, принадлежащие к данной группе. Точнее говоря, Р — это мультимножество
состоящее из структур вида Structfx . i), где х—переменная пункта FROM.
Пункт SELECT выражения типа select-from where, содержащего оператор GROUP
BY, может относиться к полям результата GROUP BY. а именно к/, f2, и
partition С помощью partition можно ссылаться иа поле х, входящее в структуры,
являющиеся членами мультимножества Р, формирующего значение partition Зна-
чит, ссылаться на переменную х, входящую в пункт FROM, можно только внутри
оператора агрегации, воздействующего на все члены мультимножества Р.
350
Глава 8 Объектно-ориентированные языки запросов
Пример 8.13. Построим таблицу обшей продолжительности фильмов для
каждой студии н каждого года. При этом в OQL на самом деле строится мульти-
множество структур, каждая из которых состоит из трех компонснтог студии,
гола и обшей продолжительности фильмов, выпушенных этой студией в данном
году. Запрос показан на рис. 8.7.
SELECT std, yr, sumLength. SUM(SELECT p.m.length
FROM partition p)
FROM Movies m
GROUP BY std m.studio. yr: m.year
Рис. 8.7. Группировоние фильмов по студии и году выпуске
Начнем анализ запроса с пункта FROM. Переменная т пробегает по всем объек-
там класса Movie. Поэтому т здесь играет роль переменной х, которая применялась
ранее । ри рассъ отренин общего случая. В операторе GROUP BY есть два поля - std
и уг, соответствующих выражениям m.studio и m.year.
Например, "Pretty Woman" — это фильм, выпушенный студией Disney в 1990 г.
Когда т является объектом для этого фильма, значением m studio является Disney,
а значением m.year — 1990. В результате множество, созданное оператором GROUP
BY, содержит в качестве своего члена структуру
Struct(std:"Disney", yr: 1990, partition : Р}
Здесь Р- множество структур, содержащее структуру Struct(m: т^), где — объект
класса Movie для фильма "Pretry Woman". В Р входят также однокомпонентные
структуры с именем поля m для каждого другого фильма, выпушенного студией
Disney в 1990 г.
Теперь рассмотрим пункт SELECT. Для каждой структуры из множества, явля-
ющегося результатом оператора GROUP BY, строится одна структура, входящая в
результирующее мультимножество подзапроса. Первым компонентом является std,
т.е. 1мя поля std, а его значение — это значение поля std из структуры, полученной
в результате действия оператора GROUP BY. Второй компонент результата имеет
имя поля уг н значение, равное компоненту' уг из результата действия оператора
GROUP BY.
Третьим компонентом каждой структуры вывода является
SUM(SELECT p.m.length FROM partition p)
Здесь переменная p пробегает по членам поля partition из структуры, входящей в ре-
зультат оператора GROUP BY. Каждое значение р — это структура вида Struct(m : о).
где о — объект фильма. Следовательно, выражение р m обозначает объект о, а
p.m.length — компонент длительности этого объекта класса Movie.
В результате запрос типа seiect-from порождает мультимножество длительности
фильмов в отдельной группе. Например, если std имеет значение Disney, а уг —зна-
чение “1990", результатом запроса является мультимножество длительности фильмов,
выпушенных студней Disney в 1990 г. Применив к этому мультимножеству оператор
SUM. мы получим сумму продолжительности фильмов в данной группе. Значит,
одной из структур результирующего мультимножества может быть
Struct(std."Disney', уг 1990, sumLength: 234)
если 1234 — правильная общая продолжительность всех фильмов, выпушенных
студией Disney в 1990 г. □
8.3 Дополнительные формы выражений OOL
35
Если в пункт FROM входит несколько переменных, интерпретация запроса
изменяется незначительно, но общий принцип остается таким же как и в случае
с одной переменной. Пусть в пункт FROM входят переменные х, х2, .., хЛ. Тогда
I Все переменные х,, п, .... х„ можно использовать в выражении е(, е2. , е„
оператора GROUP BY.
2. Структуры мультимножества, являющегося значением поля partition, имеют
поля с именами хт, xj....х*.
3. Пусть /|, к, .... /* — значения переменных лт, Хг, ..., х* соответственно, ко-
торые делают пункт WHERE истинным. Тогда в данном множестве суще-
ствует структура, являющаяся результатом оператора GROUP BY, вида
Struct(/| е, (/,. /,. 4)> - f„ e>i O’i. '2. -> '*) partition : А)
и в мультимножестве Р существует структура
Stnjct(X|: /|, хг: /2. хк: i,.)
8.3-4 Операторы HAVING
В OQL за оператором может следовать оператор HAVING с таким же значением,
как и HAVING в SQL. Оператор вида
HAVING <условие>
служит для устранения некоторых групп, созданных оператором GROUP BY. Усло-
вие относится к значению поля partition каждой структуры в результате выполнения
оператора GROUP BY. При выполнении условия эта структура передается в вывод
для обработки, как было показано в разделе 8.3.3; в противном случае она не
используется в результате запроса.
Пример 8.14. Повторим пример 8.13, но теперь запросим сумму продолжитель-
ности только тех фильмов и лет, которые относятся к студии, выпустившей по
крайней мере один фильм продолжительностью более 120 мин. Запрос показан на
рис. 8.8.
SELECT std yr, sumLength: SUM(SELECT p.m.iength
FROM partition p)
FROM Movies m
GROUP BY std: m.studio, yr: m year
HAVING MAX(SELECT p m.length FROM partition p) > 120
Рис 8.8. Ограничение рассматриваемых групп
Заметим, что для получения мультимножества продолжительности фильмов для за-
данной студии и года в пункте HAVING используется тот же запрос, что и в пункте
SELECT. В пункте HAVING также берется максимальная продолжительность и срав-
нивается со значением I20 мин. □
8.3.5 Операторы множеств
К двум объектам типа множеств или мультимножеств можно применять опера-
торы объединения, пересечения и разности которые, как и в SQL, выражаются
ключевыми словами UNION, INTERSECT и EXCEPT соответственно
352
Г ава 8 Объектно-ориентированные языки запросов
Пример 8.15. Множество фильмов, в которых играет Harrison Ford, но кото-
рые выпушены не студией Disney, можно найти с помощью разности двух запросов
типа select-from-where. показанной на рис. 8.9.
1) (SELECT DISTINCT m
2) FROM Movies m, m.stars s
3) WHERE s.name = "Harrison Ford")
4) EXCEPT
5) (SELECT DISTINCT m
6) FROM Movies m
7) WHERE m.owredBy.name = "Disney")
Рис. 8.9. Запрос, использующий разность двух множеств
Строки (I) — (3) находят множество фильмов, в которых играет Harr son Ford,
а строки (5) — (7) множество фильмов, выпущенных студией Disney. EXCEPT на
строке (4) вычисляет их разность. □
Следует отметить значение ключевого слова DISTINCT в строках (I) и (5) на
рис. 8.9 Оно делает результаты запросов множествами. Без этого слова они были
Ся мультимножествами. В OQL операторы UNION, INTERSECT и EXCEPT действу-
ют как на множествах, так и на мультимножествах Когда оба аргумента являются
множествами, эти операторы имеют обычный теоретико-множественный смысл.
Если же оба аргумента или один из них являются мультимножествами, опера-
торы приобретают мультнмножественный смысл. В один объект может входить
в мультимножество несколько раз. Сформулируем правила операций на мультимноже-
ствах. Пусть В| и В2 — мультимножества, ах— объект, входящий раз в В{ и и, раз
в В2. Значения л, и п2 по отдельности и одновременно могут быть 0.
• В В, u В2. х входит л, + л, раз.
• В В| гт В,, х входит min(«j, л3) раз.
• В Bt Вг. х входит
I. О раз, если л, < л3
2. и - л, раз, если л, > л,.
Для запроса из примера 8.9 фильм входит в результат любого подзапроса 0 или
I раз, поэтому результат не зависит от применения DISTINCT. Но он влияет на тип
резуг ьтата. При применении DISTINCT типом результата является Set<Movie>. Если
этого оператора нет в обоих подзапросах, типом результата будет Bag<Movie>.
8.3.6 Упражнения к разделу 8-3
Упражнение 8.3.1. Используя схему ODL упражнения 8.1 1 и рис. 8.2, запи-
шите следующие запросы OQL:
*а) Найдите производителей, выпускающих ПК и принтеры.
*Ь) Найдите производителей, выпускающих ПК с жестким диском
не менее 2 Гбайт.
с) НЛйдите производителей, выпускающих ПК, но не ПК-блокноты.
6.3 Дополнительные формы выражений OQL 353
’чЗ) Найдите среднюю скорость ПК.
*е) Для каждой скорости CD найдите средний объем RAM на ПК.
! О Найдите производителей, выпускающих продукт с RAM
не менее 16 Мбайт и продукт, иена которого менее 1000 ДОЛ.
11 g) Найдите производителей, выпускающих ПК со средней скоростью
не менее 150 МГн, и укажите максимальный объем RAM их ПК.
Упражнение 8.3.2. Используя схему ODL упражнения 8.1 2 и рис. 8.3, запи-
шите следующие запросы OQL:
а) Найдите классы кораблей, спущенных на воду до 1919 г.
Ь) Найдите максимальное водоизмещение каждого класса.
! с) Для каждого калибра орудия укажите год, в котором был спущен на воду
корабль с орудиями такого калибра.
*!! cl) Для каждого класса кораблей, из которых по крайней мере один был
спущен на воду до 1919 г., укажите число кораблей этого класса,
потопленных в сражении
!с) Найдите среднее число кораблей в классе.
If) Найдите среднее водоизмещение корабля.
!! g) Найдите сражения (объекты, а не имена), в которых принимал участие
по крайней мере один корабль Великобритании и было потоплено
по крайней мере два корабля.
I Упражнение 8.3.3. В примере 8.1 i говорилось, что запрос OQL на рис. 8.6 мо-
жет возвращать имена кинозвезд, которые не играли вообще ни в каких фильмах.
Перепишите запрос так, чтобы он возвращал имена только тех кинозвезд, которые
появлялись хотя бы в одном фильме, и любой фильм, в котором они появлялись
и который был бы выпущен студией Disney
8.4 Создание и назначение объектов в OQL
В этом разделе рассмагривается способ связи OQL с главным языком, которым
в наших примерах является C++, хотя можно применять и другой объектно-
ориентированный язык программирования общего назначения.
8.4-1 Приписывание значений
переменным главного языка
В отличие от SQL, который требует перемещения данных между компонентами
кортежей и переменными главного языка, OQL естественным образом вписывается
и главный язык. Выражения OQL порождают объекты в виде значений. Каждой
переменной главного языка правильного типа можно приписать значение, являю-
щееся результатом одного из выражений OQL.
Пример 8.16. Выражение OQL
SELECT m
FROM Movies m
WHERE m.year <1920
Глава 8 Обьектно-ориентированные языки запросов
354
порождает множество фильмов, снятых до 1920 г Его типом является Set<Movie>
Если oldMovies — переменная главного языка такого же типа, можно записать
(в C++, расш фенном за счет OQL):
oldMovies = SELECT DIST NCT m
FROM Movies m
WHERE m year <1920;
и значением oldMovies станет множество этих объектов класса Movie. □
8.4- 2 Извлечение элементов из множества
Поскольку выражения типа select-from-where и group-by порождают множества
или мультимножества, для получения единственного элемента нужны дополнитель-
ные средства. Это верно, даже когда точно известно, что множество состоит из
единственного элемента. Оператор ELEMENT в OQL превращет одноэлементное
множество или мультимножество в единственный его член. Этот оператор можно
применить, например к результату запроса, который заведомо возвращает одноэле-
ментное мультим ножество.
Пример 8.17. Допустим, переменной gwtw типа Movie (т.е. ее типом является
класс Movie) нужно присвоить объект, представляющий фильм ‘Gone With the Wind".
Результатом запроса
SELECT m
FROM Movies m
WHERE m.title - "Gone With the Wind’’
является мультимножество, содержащее один этот объект. Невозможно прямо при-
своить это мультимножество переменной gwtw, так как это разные типы Но если
сначала применись оператор ELEMENT:
gwtw = ELEMENT(SELECT m
FROM Movies m
WHERE m.title = "Gone With the Wind"
);
типы переменной и выражения будут соответствовать друг другу и приписывание
будет допустимо □
8.4.3 Получение каждого члена множества
Получить каждый член множества или мультимножества доста очно сложно,
но все же проще чем применять основанные на курсорах алгоритмы SQL. Сначала
нужно превратить множество или мультимножество в список с помощью выраже-
ния типа select- from where с оператором ORDER BY Результатом такого вь ражения
будет список выбранных объектов или значений.
Пример 8 18 Предположим, нужно получить список всех объектов класса
Movie Для этого можно использовать название и год выпуска фильма, так как
(title, year) является ключом для Movie. Выражение
movieList ~ SELECT m
FROM Movies m
ORDER BY m.title, m year,
приписывает переменной главного языка movieList список всех объектов класса Movie,
упорядоченных по названию и году □
8.4 Создание и назначение объектов в OOL
355
Каждый элемент упорядоченного или неупорядоченного списка, можно полу-
чить по номеру: /-й элемент списка L получается как выражение £|г- I] Предпола-
гается что списки и наборы всегда нумеруются, начиная с 0, как в С или в C++.
Пример 8.19. Допустим, нужно написать функцию C++, печатающую назва-
ние, гол выпуска и продолжительность каждого фильма. Краткая запись этой
функции дана на рис. 8.10.
1) movieLlst = SELECT m
FROM Movies m
ORDER BY m.title, m year;
2) numberOfMovies = COUNT(Movies);
3) for(i=0; i«numberOfMovies; i++) (
4) movie = movieList[i];
5) count« movie.title «“ “ « movie year« ""
6) « movie.length «"\n"
7) )
Рис. 8.10. Проверке и вывод но печоть кождого фильма
Строка (I) сортирует класс Movie, помещая результат сортировки в переменную
movieList с типом List<Movie>. Строка (2) вычисляет количество фильмов с помощью
оператора OQL COUNT. Строки (3) — (7) — это цикл, в котором числовая перемен-
ная 7 гробегает по всем позициям списка. Для удобства r-й элемент списка припи-
сывается переменной movie. На строках (5) и (6) печатаются соответствующие
атрибуты фильма. □
8.4.4 Создание новых объектов
Выражения OQL типа select-from-wliere позволяют создавать новые объекты
путем вычислений на множестве существующих объектов. Можно создавать объек-
ты и объединением констант или других выражений в структуры и применением
конструкторов типов к значениям. Вместо угловых скобок, применяемых при
описании типов, при конструировании значений используются круглые скобки.
Соглашение проиллюстрировано в примере 8.7, где строка
SELECT DISTINCT Struct(star1: s1 star2 s2)
означает, что результатом запроса является множество объектов, с типом
Struct{star1 Star, star2: Star). Имена полей starl и star2 определяют структуру,
а типы этих полей можно вывести из типов переменных s1 и s2.
Пример 8.20. Множества можно создать применяя любой нз конструкторов
(Ser. Bag, List или Array) к объектам одного типа. Рассмотрим последовательность
присвоений
x = Struct(a 1, b 2)
у = Вад(х, х, Structfa . 3, b 4));
Первое нз них присваивает переменной х значение типа
Struct(a : Integer, b • integer)
т.е. структуру с двумя численнозначными полями а и b Значения такого типа
можно считать не именами полей а и Ь, а кортежами, компонентами которых
являются натуральные числа. Поэтому значение х можно представить как (1,2).
Второе определяет у как мультимножество, членами которого являются структуры
того же типа, что и х. Пара (1,2) входит в это мультимножество два раза, а
пара (3,4) — один раз. □
356
Глава 8 Объектно-ориентированные языки запросов
Если задан тип и запрос порождает множество объектов этого типа, вместо
явного выражения данного типа можно использовать его имя. Пример 8.7 показал
создание явным образом множества пар кинозвезд. За ключевым словом SELECT
указывалось выражение, в котором конструктор типов Struct применялся для по-
строения объектов, содержащих два поля, значениями которых были объекты,
представляющие кинозвезд.
Предположим, тип StarPair определен как
Struct{star1 Star. star2: Star}
Тогда можно переписать запрос из примера 8.7, используя этот тип в пункте SELECT:
SELECT DISTINCT StarPair(starf: s1, star2: s2)
FROM Stars s1, Stars s2
WHERE s1.addr - s2.addr AND st name < s2.name
Единственное изменение старого запроса состоит в том, что результат его нового
варианта имеет тип Set<StarPair> и может быть приписан переменной главного
языка, имеющей этот же тип.
Применение имени типа к аргументам особенно полезно, когда именем типа
является класс. Классы обычно имеют множество различных форм функций-конст-
рукторов. зависящих от того, какое свойство инициируется явным образом, а какое
имеет значение по умолчанию. Например, методы наверняка не инициируются,
большинство атрибутов получает исходные значения, а связи могут быть сначала
заданы в виде пустого множества и добавлены позже. Имя каждой такой
функции-конструктора — это имя класса, и различаются они по именам полей,
упомянутых в их аргументах. Детали определения таких функций зависят от глав-
ного языка.
Пример 8.21 Рассмотрим одну из возможных функинй-конструкторов для
объектов класса Movie. Из значений атрибутов title, year, length и ownedBy она
порождает объект, имеющий эти значения в перечисленных полях и пустое множе-
ство кинозвезд. Если mgm — переменная, значением которой является объект
MGM Studio, можно создать объект "Gone With the Wind" с помощью выражения:
gwtw = Movie(title: "Gone With the Wind",
yesr: 1939,
length. 239
ownedBy: mgm);
Этот оператор дает два результата.
I. Создается новый объект класса Movie, который становится частью
степени Movies
? Этот объект становится значением переменной главного языка gwtw. □
8.4-5 Упражнения к разделу 8.4
Упражнение 8.4.1. Присвойте переменной главного языка х константы:
®а) Множество {1,2,3}.
Ь) Мультимножество {1,2, 3, 1}
с) Список {1.2, 3, I а.
8.4 Создание и назначение объектов в OQL
357
d) Структуру, компонент которой а —это множество (I, 2|,
а компонент Ь— мультимножество (), I}.
е) Мультимножество структур, каждая из которых содержит два поля - а и Ь.
Трем структурам этою мультимножества соответствуют
пары значений (1,2), (2. I) и (1,2).
Упражнение 8.4.2. Используя схему ODL упражнения 8.1.1 и рис. 8.2, запи-
шите в языке C++ (или в другом объектно-ориентированном главном языке по
вашему выбору), расширенном за счет OQL, операторы, выполняющие следующие
задачи-
*а) Присвойте переменной х главного языка объект, представляющий ПК
с номером модели 1000.
Ь) Присвойте переменной у главного языка множество всех объектов,
представляющих ПК-блокноты, имеющие RAM не менее 16 Мбайт.
с) Присвойте переменной г главного языка среднюю скорость ПК,
имеющих пену менее 1500 дол.
Id) Найдите все лазерные принтеры, напечатайте список номеров их моделей
и цен, а затем сообщение о номере модели, имеющей самую низкую иену.
!! е) Напечатайте таблицу, показывающую минимальную и максимальную
цены, установленные производителями ПК.
Упрожнение 8.4.3. В этом упражнении применяется схема ODL из упражне-
ния 8.1.2 и рис. 83. Предполагается, что для каждого из четырех классов этой
схемы есть функция-конструктор с тем же именем, использующая в качестве
аргументов значения каждого атрибута и однозначные связи многозначные связи
считаются пустыми. Для однозначных связей с другими классами можно объявить
переменную главного языка, текущим значением которой является связанный
объект. Создайте перечисленные ниже объекты и в каждом случае сделайте создан-
ный объект значением переменной главного языка.
*а) Линкор "Colorado" класса Maryland, спущенный на воду в 1923 г
Ь) Линкор "Graf Spee" класса Lutzow, спущенный на воду в 1936 г.
с) В результате сражения при Малайе (Malaya) был потоплен
линкор "Prince of Wales".
d) Сражение при Малайе произошло в 1941 г.
е) Класс Hood британских линкоров имел 15-дюймовые орудия
н водоизмещение 41 тыс.тонн.
8.5 Объекты кортежей в SQL3
В OQL нет специального понятия отношения, а используются множества
(мультимножества) структур. Однако в SQL понятие отношения настолько важно,
что SQL3 сохраняет "отношение" в качестве основного понятия В SQL3 есть два
вида объектов;
I. Строковые объекты, которые, в сущности, являются кортежами.
2. Абстрактные типы данных (ADT или согласно некоторым документам
по SQL3 значения ADT) — общие объекты, которые можно использовать
только в качестве компонентов кортежей
35S
Глава В Объектно-ориентированные языки запросов
8.5-1 Типы строки
В SQL3 можно определить тип кортежа, строго соответствующий классу
объектов. 13 описание типа строки «ходят следующие элементы:
I Ключевые слова CREATE ROW TYPE
2. Имя типа
3. Заключенный и скобки список атрибутов и их типов
Форма определения типа строки Т:
CREATE ROW TYPE Т (<описаиия компонентов?)
Пример 8.22. Можно создать тип строки, представляющий кинозвезд фильма
и аналогичный классу Star из рис. 8.4. Однако множество фильмов невозможно
представить непосредственно в виде поля в кортежах отношения Star. Поэтому мы
начнем только с компонентов name и address этих кортежей.
Тип адреса на рис. 8 4 —это кортеж с компонентами street и city. Значит,
нужны два определения типа одно для адресов, а другое для кинозвезд. В SQL3
допускается использовать тип строки в качестве типа компонента другого типа
строки или отношения. Требуемые определения показаны на рис. 8.11.
CREATE ROW TYPE AddressTypef
street CHAR(50),
city CHAR(2C)
):
CREATE ROW TYPE StarType(
name CHAR(30),
address AddressType
):
Рис. 8.11. Дво определения типо строки
Кортеж типа AddressType имеет два компонента, атрибутами которых являются
street и city. Типы этих компонентов — строки длиной в 50 и 20 символов соответ
ственно. Кортеж типа StarType тоже имеет два компонента Первый из них — атри-
бут name, типом которого является строка из 30символов, а второй — address
типом которого является AddressType. т.е. кортеж с компонентами street и city. □
<8.5.2 Описание отношений
с типом "строка таблицы ’
При наличии описания типа "строка таблицы" можно описать отношения,
кортежи которых имеют этот же тип. По форме такое описание похоже на описа-
ние из раздела 5.7.2. но при этом в обычном описании таблицы SQL вместо списка
атрибутов применяется выражение
OF TYPE Симя типа "строка таблицы"?
8.5 Объекты кортежей в SQL3
359
Пример 8.23. MovieStar можно описать как отношение, кортежи которого
имеют тип StarType. Для этою применяется выражение
CREATE TABLE MovieStar OF TYPE StarType;
В результате таблица MovieStar имеет дна атрибута — name и address. Заметим,
п о типом второго из них является тип "строка таблицы”, что обычно не допускает
ся и стандартах SQL, предшествующих SQL3. □
Обычно для каждого типа "строка таблицы" имеется единственное отношение,
и это отношение интерпретируется как экстент класса (в смысле раздела 8.1.3),
соответствующего типу данного кортежа. Но для заданного типа "строка таблицы"
может существовать несколько отношений или не существовать ни одного.
8.53 Доступ к компонентам
тина "строка таблицы"
Поскольку в SQL3 компоненты могут содержать структуры, то возникает
необходимость в доступе к их компонентам. В SQL3 применяются двухточечная
нотация, соответствующая одноточечной нотации OQL или С.
Пример 8.24. Запрос на рис. 8.12 находит имя каждой кинозвезды, проживаю-
щей в Beverly Hills, н название улицы на которой она проживает.
SELECT MoveStar.name, MovieStar.address..street
FROM MovieStar
WHERE MovieStar.address..city = 'Beverly Hills';
Рис. 8.12. Доступ к компонентам компонентов
Полные имена атрибутов используются только для иллюстрации разницы в ис-
пользовании одной и двух точек. На самом деле MovieStar и одна точка здесь
необязательны, так как нет никаких неясностей, связанных с атрибутами пате
и address. □
Г’"’ ‘ ’ П
Области значений и типы строк таблицы
В разделе 5.7.6 рассматривались области значений, схожие с описаниями г
t типов. Между областями и типами “строка таблицы" есть по крайней мере два J
! важных различия Явное различие: области определяют типы компонентов j
’. кортежей, а типы "строка таблицы" относятся к целым кортежам. j
J Менее глубокие различия заключаются в следующем. Области значений — t
[ это вид сокращений. Две области могут представлять один и тот же тип,
> и значения таких областей не различаются. Предположим, два типа "строка ;
i таблицы" — Г, и Т, — имеют идентичные определения. Тогда кортежи .
• отношений, имеющих эти типы, не относятся к взаимозаменяемым Напри- :
[ мер. атрибут, типом которого является ссылка на Г,, не может ссылаться на г
; кортеж, типом которого является Т}.
360 Глава В Ооъектно ориентированные языки запросов
8-5-4 Ссылки
Эффект идентификации объектов в объектно-ориентированных языках до-
стигается в SQL3 за счет понятия ссылки. Компонентом некоторого типа "строка
таблицы" может быть ссылка на другой тип "строка таблицы”. Если Т — тип
"строка таблицы", то REF(7) — тип ссылки на кортеж типа Т. Если кортеж считается
объектом, ссылка на него является его ID.
Пример 8.25. В MovieStar невозможно записать все фильмы, в которых кино-
звезды играли, но можно записать их лучший фильм. Сначала нужно описать отно-
шение Movie. При желании можно одновременно описать и тип "строка таблицы"
для этого отношения. Описание простого типа для фильмов, исключающее связи
с кинозвездами, студиями или президентами студии, выглядит следующим образом:
CREATE ROW TYPE MovieType(
title CHAR(30),
year INTEGER,
inColor BIT(1)
);
Затем можно описать отношение с кортежами этого типа;
CREATE TABLE Movie OF TYPE MovieType;
Теперь необходимо изменить тип MovieStar, включив в него ссылку на лучший
фильм каждой кинозвезды (В SQL3 нет ALTER TYPE или других операторов, позво-
ляющих изменить существующее определение типа. Поэтому для изменения ранее
определенного типа "строка таблицы" практически нужно удалить тип строки и все
определяемые им таблицы, а затем заново определить тип и восстановить таблицы).
Новое определение StarType выглядит так:
CREATE ROW TYPE StarType(
name CHAR(30).
address AddressType,
bestMovie REF(MovieType)
); □
Пример 8.26. Допустим, между фильмами и кинозвездами существует стандартная
связь "многие-ко-многим"; кинозвезда играет во множестве фильмов и в фильме
играет множество кинозвезд. В то время как ODL допускает множество кинозвезд
в качестве компонента фильмов, в SQL3, наоборот сохраняется реляционный
подход, которому мы следуем в данной книге. Хотя некоторые варианты стандарта
SQL3 допускают типы-коллекнии (например, множества или отношения) в каче-
стве типов атрибутов, скорее всего, эти типы будут отложены до стандарта SQL4.
Тем не менее связь типа "многие-ко-многим" можно представить в виде отдельного
отношения, содержащего пары связанных элементов
На рис. 8.I3 показано, как можно представить связь "играет в" между фильмами
и кинозвездами. В стандартах. предшествующих SQL3, связь "многие-ко-многим"
можно выразить только путем спаривания ключей двух связанных классов. SQL3
позволяет ссылаться на объекты ( точнее, на кортежи) прямо через атрибуты, 1 мею-
щис тип ссылки
Начнем с определения типов MovieType и StarType для отношений Movie и
MovieStar соответственно. Для отношения Movie мы возвращаемся к исходному
типу StarType, который нс содержит лучший фильм. Тип StarsInType, определенный
для отношения Starsln, содержит пары ссылок. Каждая такая пара обозначает кино-
звезду и фильм, в котором она играет.
За определениями типов "строка таблицы” следуют описания трех таблиц
Movie, MovieStar и Starsln, в которых применяются три этих типа Заметим, что тип
AddressType используется не в качестве типа таблицы, а в качестве типа атрибута
address в StarType
8.5 Объекты кортежей в SQL3
361
CREATE ROW TYPE MovieType(
title CHAR(30),
year INTEGER.
inColor B1T(1)
CREATE ROW TYPE AddressType(
street CHAR(50).
city CHAR(20)
);
CREATE ROW TYPE StarType(
name CHAR(30).
address AddressType,
):
CREATE ROW TYPE StarslnType(
star REF(StarType)
movie REF(MovieType)
);
CREATE TABLE Movie OF TYPE MovieType:
CREATE TABLE MovieStar OF TYPE StarType;
CREATE TABLE Starsin OF TYPE StarsInType;
Рис. 8.13. Кинозвезды, фтьмы и связь между ними
Сравните представленное здесь отношение Starsin с одноименным отношением
схемь БД из раздела 3.9. Последнее содержит атрибуты movieTille и movieYear вмес-
то ссылок на кортеж, представляющий фильм, и атрибут starName вместо ссылки
на кортеж, представляющий кинозвезду. □
8.5-5 Следование по ссылкам
Когда компонент одного кортежа может быть ссылкой на кортеж другого
(или того же самого) отношения, вполне естественно расширить SQL оператором
разыменования. В SQL3 используется оператор ->, имеющий тот же смысл, что и в С.
Если х — ссылка на кортеж I, а о — атрибут этого кортежа, тогда х -> а — это значе-
ние атрибута а в кортеже г. Этот оператор полезен во многих запросах SQL3, так
как его можно подставлять вместо определенных соединений, необходимых в SQL2.
Пример 8.27. Используя схему на рис. 8 13. найдем названия всех фильмов
с участием Mel Gibson Стратегия поиска — это проверка каждой пары в Starsin.
Если кинозвезда, на которую делается ссылка, — Mel Gibson, в качестве части резуль-
тата порождается название фильма, на который ссылается второй компонент пары.
Запрос SQL3
SELECT movie -> title
FROM Starsin
WHERE star -> name = Mel Gibson';
интерпретируется следующим образом. Как и при любом запросе SQL типа
select-from-where рассматривается каждый кортеж отношения, упомянутого в пункте
FROM например (,v. m). Здесь .г—ссылка на кортеж, представляющий кинозвезду,
ат - на кортеж, представляющий фильм Пункт WHERE требует определить, сов-
падает ли компонент name кортежа MovieStar, на который ссылается s, с именем
Mel Gibson. Если да. то мы получаем значение компонента title кортежа из отноше-
ния Movie. на который ссылается т. и это значение — один из кортежей, порождас
мых запросом □
ЗЕ2 Глава о Объектно-ориентированные языки запросов
— — __? . к -_. • _ -________xx_-i_3 --.nLL.k-w;* ni—, .— —-—— ши|тч«11«—Tft—.Т —.
Разыменование к извлечение компонентов
Одно из различии между SQL3 и OQL — трактовка использованиям
и точки. В OQL точка п-> янляются синонимами Каждый из них применим ;
к объекту. являющемуся кортежем и возвращает компонент этого объекта
В SQL3 как и н С, эти операторы различны. Оператор-> используется только ;
г для ссылки на кортеж, а к самим переменным можно применять только ?
оператор точки (и SQL3 обозначается двумя точками). Как и в языке С, ?
если г — ссылка на кортеж /, то г->а дает то же знамен те, что и t..a.
8-5-6 Контексты ссылок
Для ответа на запрос, подобный приведенному в примере 8.27, система БД SQL3
должна интерпретировать выражение следования по ссылке типа star-> name как
ссылку на поле name отдельного отношения. Один из простых способов действия
состоит в том, чтобы просмотреть каждый кортеж в Starsln, последовать его ссылке
star и выяснить, имеет ли кортеж, на который сделана ссылка, имя Mel Gibson. Ио
такой способ потребует много времени, если отношение Starsln велико.
Есть более эффективный путь, если DBMS допускает создание индексов на
атрибуте пате отношения Л, которые позволяют по отдельному значению (напри
мер. "Mel Gibson") найти кортежи отношения Stars п, ссылающиеся на кортежи
отношения Л с компонентом пате, совпадающим с "Mel Gibson". Но в каком
именно отношении Л’ вести поиск с помощью этих индексов? В данном примере
известно, что атрибут star каждого кортежа отношения Starsln имеет значение,
являющееся ссылкой на какой-то кортеж, и что этот кортеж должен находиться
в отношении, типом которого является StarType. Показано лишь одно такое отно-
шение, MovieStar, поэтому можно ожидать, что ссылка относится именно к нему
Могут существовать и другие отношения с типом StarType, а значит, необходи-
мо найти принадлежащие каждому из них индексы для имени "Mel Gibson”. Поиск
может оказаться бесполезным, если по причинам, известным проектировщику, все
ссылки сделаны на кортежи одного и того же отношения, как это и должно быть.
Поэтому в SQL3 есть способ определить, на какое отношение ссылается атрибут,
содержащий ссылку. К описанию отношения, содержащего атрибут, типом которо-
го является ссылка, добавляется оператор
SCOPE FOR <атрибут> IS <отношение>
Этот оператор означает, что указанный в нем атрибут типом которого должна быть
ссылка, всегда ссылается на указанное в нем отношение.
Пример S 2S. Для получения гарантии, что ссылки star в таблице MovieStar
всегда относятся к кортежам отношения MovieStar, а ссылки movie к кортежам
отношения Movie, можно дать описание отношения Starsln (рис. 8.14). □
CREATE ROW TYPE StarslnType(
star REF(StarType),
movie REF(MovieType)
);
CREAT TABLE Starsln OF TYPE StarsInType
SCOPE FOR star IS MovieStar,
SCOPE FOR movie IS Movie;
Рис. 8.14. Описание областей для атрибутов ссылки
6 5 Объекты кортежей в SQL3
363
8.5- 7 Идентификаторы объектов как значения
Согласно обшему принципу объектно-орнентированных языков, идентифика-
торы (ID; —это внутренние значения системы, недостижимые с использованием
языка запросов Такое допущение принимается, например, в OQL Однако в прин
mine не существует никаких препятствий для явной ссылки на 1D объекта и SQL3
обеспечивает такую возможность. В описании отношения или типа его строк может
быть атрибут, значением которого является ссылка на кортеж того же типа. При
включении в описание таблицы или типа строк предложения
VALUES FOR <атрибут> ARE SYSTEM GENERATED
значениями указанного в нем атрибута становятся ссылки на кортеж в котором
появляется эта ссылка. Следовательно, такой атрибут может служить и первичным
ключом отношения, и объектом ID для его атрибутов.
Пример 8 29. Перепишем предложение на рис. 8.13 так, чтобы отношения
MovieSta и Movie имели атрибуты, являющиеся 1D объектов, с названиями starjd
и moviejd соответственно. Результат такого изменения показан на рис. 8.15.
CREATE ROW TYPE MovieType(
moviejd REF(MovieType),
title CHAR(30),
year INTEGER.
inColor BIT(1)
CREATE ROW TYPE AddressType(
street CHAR (50),
city CHAR(20)
);
CREATE ROW TYPE StarType(
starjd REF(StarType),
name CHAR(30)
address AddressType
);
CREATE ROW TYPE StarslnTypef
star REF(StarType).
movie REF(MovieType)
)
CREATE TABLE Movie OF TYPE MovieType
VALUES FOR moviejd ARE SYSTEM GENERATED;
CREATE TABLE MovieStar OF TYPE StarType
VALUES FOR star_id ARE SYSTEM GENERATED
CREATE TABLE Starsln OF TYPE StarsInType
SCOPE FOR star IS MovieStar,
SCOPE FOR movie IS Movie;
Рис. 8.15. Добавление объекта ID к отношениям
Этот рисунок отличается от рис. 8.13 по следующим пунктам
1. К типу строки MovieType добавлен атрибут movie_id
2 К типу строки StarType добавлен атрибут starjd.
364
Глава 8 Объектно-ориентированные языки запросов
3. К описанию таблицы добавлено указание, что значение moviejd
и таблице Movie генерируется системой.
4. К описанию таблицы добавлено указание, что значение starjd
в таблице MoveStar генерируется системой.
5. Сохранено описание контекста SCOPE из примера 8.28.
Появился более удобный способ записи сформулированного в примере 8.27.
запроса о фильмах с участием Mel Gibson Ссылки, содержащиеся в отношении
Starsin из пункта WHERE, можно отождествить с ID-атрибутами объектов в отно-
шениях MovieStar и Movie являющимися ссылками на собственные кортежи-
SELECT Movie.title
FROM Starsin, MovieStar, Movie
WHERE Starsln.star - MovieStar.star id AND
Starsln.rnovie - Movie.movie d AND
MovieStar.name - ’Mel Gibson';
Согласно пункту FROM рассматривается все множество кортежей, состоящее из
кортежей отношении Starsin, MovieStar и Movie соответственно. По первому условию
пункта WHERE кортеж отношения Starsin ссылается (в своем компоненте star) на
кортеж отношения MovieStar. По второму условию кортеж отношения Starsin ссы
лается (в своем компоненте movie) на кортеж отношения Movie. Сочетание этих
условий требует, чтобы кортежи отношений MovieStar и Movie представляли кино-
звезду и фильм, составляющие пару в кортеже отношения Starsin.
По третьему условию кинозвездой должен быть Mei G bson, а пункт SELECT
порождает название нужного фильма. Этот запрос можно записать и методом
следования по ссылке (пример 8.27). Фактически то бьл более простой метод
формулировки такого запроса, но способ записи, примененный в данном примере
иллюстрирует определенные возможности, которые открывает применение атрибу-
тов. являющихся 1D обз>ектов □
8.5.8 Упражнения к разделу 8.5
Упражнение 8 5.1. Составьте описания следующих типов "строка таблицы":
a) NameFype с компонентами для имени отчества, фамилии и формы
обращения к человеку (мистер, мадам и т.д.).
*b) PersonType с именем человека и ссылками на людей, являющихся его
отцом п матерью. При описании нужно использовать тип из пункта (а).
с) Mar lageType с датой бракосочетания и ссылками на мужа и жену.
Упражнение 8 5.2. Постройте заново схему БД компьютерных продуктов из
упражнения 4 I 1 используя описания типов и атрибуты ссылок. В частности, в от-
ношениях PC Laptop и Printer сделайте атрибу model ссылкой на кортеж Product
для данной юделн.
Упражнение 8.5.3. Используя схему отношения из упражнения 8.5.2, запиши-
те перечисленные ниже запросы Применяйте ссылки везде, 1де это возможно,
а) Найдите производителей ПК с объемом жесткого диска более 2 Гбайг.
Ь) Найдите производителей лазерных принтеров
'с) Постройте таблицу, в которой для каждой модели ПК блокнота указан
ПК-блокнот с самой высокой скоростью процессора среди всех
ПК-блокнотов, выну каемых данным производителем.
8.6 Абстрактные типы данных в SQL3
365
! Упражнение 8.5.4. В упражнении 8.5.2. предполагалось, что имена моделей в
отношениях PC, Laptop и Printer могут быть ссылками на кортежи таблицы Product,
Можно ли сделать атрибут model из отношения Product ссылкой на кортеж в отно-
шении, представляющем данный тип продукта? Почему?
* Упражнение 8 5 5. Постройте заново схему БД боевых кораблей из упраж-
нения 4.1.3, используя описания типов и атрибуты ссылок. По схеме упражнения 8.1.2
можно выяснить, где именно полезны атрибуты ссылок. Найдите связи "многие-
к-одному” и постарайтесь вь разить их с помощью атрибута с типом ссылки
Упражнение 8.5.6. Используя схему отношения из упражнения 8.5.5, запишите
перечисленные ниже запросы. Где возможно, применяйте ссылки. Избегайте соеди-
нений (используя подзапросы или несколько переменных кортежей в пункте FROM).
*<|) Найдите корабли водоизмещением более 35 тыс. тонн.
Ь) Найдите сражения, и которых был потоплен хотя бы один корабль.
!с) Найдите классы, содержащие корабли, спущенные на воду после 1930 г
!! d) Найдите сражения, в которых был поврежден по крайней мере
один корабль США.
8.6 Абстрактные типы данных в SQL3
Типы "строка таблицы" и ссылки SQL3 обеспечивают большую часть функ-
циональности объектов OQL. Они позволяют изменять "объекты" с помощью удобных
операторов SQL типа вставки и удаления. В OQL предполагается, что подобные из-
менения выполняются в окружающем объектно-ориентированном языке типа C++.
Но типы "строка таблицы" не обеспечивают инкапсуляции доступной в объектно-
ориентированных языках. Класс инкапсулируется для гарантии, что его объекты
изменяются только с помощью фиксированного множества операций из определения
этого класса. Назначение инкапсуляции — предотвратить программные ошибки,
возникающие при использовании данных непредусмотренными способами.
Типы “строка таблицы" не инкапсулируются. Над кортежами этого типа допус-
кается выполнять любые операции, которые можно выразить в SQL3. Интерфейсы
(классы) OQL инкапсулируются не полностью, так как доступ к компонентам
объекта можно получить с помощью запросов OQL. Запросы к внутренней структуре
объектов, как правило, менее опасны, чем изменения объектов незапланированными
способами. В OQL невозможно изменять объекты иначе как с помощью методов
(см раздел 8.1 2). При этом предполагается, что методы, описанные на окружаю-
щем обычном языке типа C++, применимы только к объектам данного класса.
В SQL3 существует другой вид определения "класса", не поддерживающий
инкапсуляцию,— абстрактный тип данных (ADT). Объекты ADT предназначены
для использования в качестве компонентов кортежей, а не в качестве самих корте-
жей. Однако обычно они имеют структуру кортежей, как и объекты ODL.
8.6.1 Определение ADT
Форма определения ADT показана на рис 8.16.
I) CREATE TYPE <имя типа> (
2) список атрибутов и их типов
3) произвольное описание функций = и < для данного типа
4) описание Функции (методов) дпя данного типа
5) I,
Рис. 3.16. Определение абстрактных типов донных
366
Глава 6 Объектио-ориенгированные языки запросов
Строка (I) — оператор CREATE, вводящий иля ADT. Строка (2) представляет
собой список имен атрибутов в их типов разделенных запятыми. Строка (3) на
рис. 8.16 содержит произвольные описания операторов сравнения = i < Форма
описания ранен тви
EQUALS <имя функции. реализующей равенствах
Функция < определяется аналогично, заменой ключевого слова EQUALS на LESS
THAN. Согласно стандарту SQL3, эти функции, возможно, не будут интерпретиро-
ваться каким-то особым образом, но их нужно определять и применять, как
и любые другие функции для этого типа. Четыре других оператора не нужно опре-
делять явно, их можно построить с помощью операторов = и <. Например. < — то
же самое, что "= или <", а > выражается через "не <*. Если операторы = и <
оп| еделены. то значения данного ADT молено сравнивать в пунктах WHERE так же
как и значения обычных типов SQL.
Строка (4) — описание других функций (методов) для ADT В SQL3 каждый
А ОТ сопровождается следующими "встроенными" методами, которые не нужно
отдельно опнсывль или определять.
I. Функция-конструктор, воз вращающая новый объект данного типа Перво-
начально значениями всех атрибутов этого объекта являются NULL
Если Г — имя ADT, то Т() — функция-конструктор
2. Функция иаб.иодения для каждого атрибута, возвращающая его значение.
Если ,4 — имя атрибута, а .¥—переменная, значением которой является
объект ADT. то А (Д') — значение атрибута А объекта X. Для последнего
можно применять более удобное обозначение — Х.А.
3 Функдая изменения, заменяющая старое значение каждого атрибута новым.
Обычно применяется в левой части оператора приписывания (см. раздел 8.6.2).
Для инкапсуляции необходимо блокировать неконтролируемое применение
этой функции В SQL3 для функций существует привилегия EXECUTE, ко-
торую можно присвоить или отменить так же, как шесть привилегий SQL2,
описанных и разделе 7 4.1.
Другие функции определяются внутри или вне оператора CREATE TYPE. Если
они определены вне этого оператора, они могут использовать лишь функции, опре-
деленные внутри, включая перечисленные выше встроенные функции.
Пример 8 ЗС. В примере 8 22 адреса, состоящие из улицы и города, были о -
несены к типу "строка таблицы". Их можно определить также в виде ADT с такой
же структурой Результат этого подхода — инкапсуляция адресов- невозможно
получить доступ к компонентам адреса, выражающим улицу и город, не сделав
общедоступными их функции изменения и наблюдения.
На рис. 8.17 показано определение ADT с именем AddressADT, не содержащее
реальных определений связанных с ним функций или методов.
Строки (2) и (3) определяют кортеж с компонентами street и city. Их типами,
как и в примере 8.22. являются строки длиной в 50 и 20 символов соответственно
1) CREATE TYPE AddressADT (
2) street CHAR(50)
3) city CHAR(20),
4) EQUALS addrEq,
5) LESS THAN addrLT
здесь можно описать другие функции
)
Рис. 8.17. Определение RDT адреса
8.6 Абстрактные типы данных е SQL3 367
Согласно строкам (4) и (5), функция равенства для AddressADT называется
addrEq, а функция сравнения — addrLT. При этом неизвестно, что именно делают
эти функции, так как отсутствуют их определения. Наши версии этих определе
пий приведены в примере 8.32. Адреса здесь упорядочены лексикографически,
сначала по названию города, затем по названию улицы. □
f
MPEG-кодирование видеофильмов
? Поскольку для хранения видео нужен большой объем памяти, они ко-
! дируются по одной из многих стандартных схем уплотнения. В наиболее
' распространенной из них MPEG используется тот факт, что любой фрейм
• движущейся картины очень похож на предшествующий. Поэтому области
,* любого фрейма можно представить с помощью указателя на аналогичную
i область предыдущего, при этом она может оставаться иа прежней позиции
I (если является частью стационарного основания) или перейти на другую
позицию (если она часть движущегося объекта).
Несмотря на то что MPEG уплотняет видео лучше стандартных схем
! уплотнения. MPEG-кодирование требует 1 Гбайт памяти на каждый час филь-
J ма. Более того, поскольку допускаются небольшие различия между соответст-
5 вующими друг другу областями, качество фильма часто снижается. И все же
i MPEG выражает разумный баланс между качеством фильма, используемым
I объемом памяти и требуемой вычислительной мощностью.
Следующий пример показывает способность ADT вводить в программы SQL
типы данных, выходящие за рамки классических представлений об использовании
СУБД. Стало оправданным хранение в БД больших объектов типа образов, аудио-
клипов или фильмов. Операции над такими объектами отличаются от "стандартных”
операций SQL, таких как сравнение, печатание, агрегация и т.д. Выводить эти объек-
ты на экран часто приходится с помощью сложных алгоритмов декодирования.
Пример 8.31. Предположим, нужен ADT Мрад, т.е. MPEG, содержащий
закодированный фильм (MPEG — стандартная форма уплотнения видеофильмов
см. заключенный в рамку текст в коннс этого раздела) Технически кодирование
MPEG — это строка символов, поэтому в данном случае подходит тип VARCHAR.
Однако длина MPEG кодировки видеофильма часто настолько велика (измеряется
в гигабайтах), что представлять видеофильмы в форме строк весьма неудобно.
Для поддержки видео и других очень больших экземпляров данных применяет-
ся специальный тип данных BLOB (Binary, Large, OBjecr) — особый внд битовой
строки, которая может быть очень длинной и измеряться в гигабайтах В этом
примере предполагается, что BLOB —это встроенный тип для БД. Определение
ADT Мред показано на рис 8 18.
1) CREATE TYPE Мред(
2) video BLOB.
3) length INTEGER,
4) copyright VARCHAR(255),
5) EQUALS DEFAULT,
6) LESS THAN NONE
определения функций
):
Рис. 8.18. Определение RDT MP6G
368
Глава 8 Объектно ориентированные языки запросов
Согласно строке (2) типом атрибута video является BLOB. Этот атрибут содер-
жит очень большой закодированный видеофильм. Строки (3) и (4) определяют два
других "обычных” атрибута: продолжительность видеофильма и указатель авторского
права на него. Согласно строке (5) равенство значений типа Mpeg по умолчанию
определяется через идентичность: два объекта Mpeg равны, если и только если они
полностью совпадают до последнего бита по своим соответствующим друг другу
атрибутам. Можно построить более сложное определение равенства, отразив идею,
согласно которой два значения Mpeg “равны', если они не отличаются друг от друга
при декодировании и выводе на экран с приемлемым разрешением, но здесь не
будут обсуждаться такие определения. Строка (6) означает, что отношение < между
знгче! иями Mpeg не определено, т.е. запрещено писать /I < В, если А и В — значе-
ния типа Mpeg. □
8.6.2 Определение методов для ADT
После списка атрибутов ADT можно добавить любом список описаний функ-
ц пТ, построенных по форме
FUNCTION <имя> (<аргумснты>) RETURNS <тип>;
Каждый аргумент состоит из имени переменной и ее типа и отделен от другого
аргумс зга запятой.
Функции бывают двух типов — внешние и внутренние. Первые записываются
в главном языке, и лишь их сигнатура появляется в определении ADT (см. раздел 8.6.3).
Вторые записываются на расширенном язьке SQL. Ниже перечислены некоторые
способы их описания, включая расширения SQL2 и язык запросов SQL3.
• := применяется в качестве оператора присваивания.
• Переменную, являющуюся локальной относительно функции,
можно объявить с помощью имени, которому предшествует двоеточие.
После имени указывается его тип.
• Оператор точки применяется для доступа к компонентам структуры.
• Булевы значения можно выражать так же, как в пунктах WHERE.
• BEGIN и END нужны для объединения различных операторов в тело функции.
Пример 8.32. Продолжим пример 8.30. На рис. 8.19 описаны функции, которые
можно включить в определение с помощью оператора создания типа (рис. 8.17).
Ci роки (1) — (6) определяют функцию-конструктор для ADT AddressADT SQL3
имеет без аргументов встроенный конструктор с именем AddressADT (с именем
самого ADT). Но нам нужен другой конструктор, имеющий в качестве аргументов
значения улицы и города. Назвать ею можно как угодно, но допустимо и приемлемо
npricnai вать ему имя класса.
Строка (I) описан ге новой функдиг конструктора с двумя аргументами — л и с,
представляющими улицу и город. Их типы — это строки длиной в 50 и 20 символов
соответственно Эта функция возвращает значения типа AddressFDT. Согласно
строке (2) а- локальная переменная типа AddressADT. Строки (3) —- (6) составляют
тело функции. На строке (3) встроенный конструктор AddressADT() применяется
.для создания нового объекта и делает его значением переменной :а. Встроенную
функцию-конструктор невозможно перепутать с описываемой функцией, так как у
них разные аргументы. То есть, строку (3) нельзя интерпретировать как рекурсивный
вызов. Строка (4) копирует первый аргумент в компонент street переменной л. а стро-
ка (5) — второй аргумент в компонент cty этой же переменной. И наконец, строка (6)
возвращает построенное значение о. Строки (7) и (8) определяют функцию равенст-
ва для ADT AddressADT Согласно строке (4) рис. 8.17 этой функции бьло присвоено
в 6 Абстрактные типы данных в SQL3
369
имя addrEq, поэтому именно его необходимо использовать. Данная простая функ-
ция возвращает значение TRUE, если и только если компоненты двух значений для
улицы и города совпадают между собой. Фактически такая функция может быть
принята по умолчанию (пример 8.31). Строки (9) и (10) выражают функцию < с
именем addrlT. Здесь говорится, что первый адрес предшествует второму, если город
первого лексикографически меньше города второго (предшествует ему по алфавиту)
При совпадении названий городов сравниваются названия улиц. Строки (II) —(14)
определяют функцию fullAddr аргументом которой является объект типа AddressADT
Она возвращает полный адрес: название улииы, города и код региона из девяти
цифр. На строке (12) описывается локальная переменная :z, временно хранящая
код региона. Строка (13) вызывает функцию findZip, которая определена внешним
образом и имеет два строковых аргумента, представляющих улицу и город. Внеш-
ние функции рассматриваются далее.
1) FUNCTION AddressADT(:s CHAR(50), с CHAR(20)
RETURNS AddressADT.
2) :a AddressADT;
BEGIN
3) a = AddressADTO,
4) a.street := -s;
5) a.city := :c;
6) RETURN .a;
END
7) FUNCTION addrEq(:a1 AddressADT, a2 AddressADT)
RETURNS BOOLEAN
8) RETURN ( a1.street ~ ,a2.street AND
:a1.city = :a2.city)
9) FUNCTION addrLT( a1 AddressADT, ,a2 AddressADT)
RETURNS BOOLEAN
10) RETURN ((;a1.city < :a2.city) OR
(:a1 city = :a2 city) AND (:a1.street < :a2.street));
11) FUNCTION fuflAddr( a AddressADT) RETURNS CHAR(82);
12) :zCHAR(10);
BEGIN
13) :z = findZip(.a.street, a.city);
14) RETURN ( a.street || *' II a city ||111| ;z);
END;
Рис. 8.19. Некоторые функции для адреса RDT
В результате сложного процесса, который может происходить в другой БД, или
в результате серии решений findZip возвращает правильный код региона для заданной
улицы и города. Данная функция здесь нс описывается. И наконец, на строке (14)
находятся улица н город из объекта :а, а также код региона из z. Эти три компо-
нента адреса разделены пробелами. □
370
Глава 8 Объектно-ориентированные языки запросов
Большие бинарные объекты
Большие бинарные объекты (BLOB) могут выглядеть как большие бито
' вые строки, но н.\ реализация гораздо сложнее реализации строк символов
! малой длины с пределом в 255 байт. Например, не имеет смысла хранить
i огромные строки в виде компонентов кортежей; их нужно хранить отдельно,
. обычно с помошыо окружающей файловой системы
| В модели клиснт/сервср (см. раздел 7.3.4) предполагается, что значения и .
I кортежи имеют средние размеры, и сервер передает клиенту целые кортежи,
| отвечающие на запрос. Не имеет смысла передавать клиенту BLOB целиком.
1 Если клиент, например, запрашивает у сервера видеоклип, сервер посылает I
ему только часть видео. Клиент может начинать просмотр фильма. Он не I
( должен локально хранить множество гигабайт видео или ждать, пока получит
. весь фильм целиком, а сразу же приступать к его просмотру.
I________ ___-__________________=~—____—__________________________!
8,6.3 Внешние функции
ADT могут иметь методы, написанные на главном языке, а не на SQL3. При
использовании таких функции в определение ADT входит только их сигнатура -
вместе с информацией о языке, на котором они написаны Форма внешнего
описания:
DECLARE EXTERNAL <нмя функции> <сигнатура>
LANGUAGE <название языка>
Пример 8 33. Для применения внешней функции findZip из примера 8.32
в определении ADT нужно описать AddressADT. Поскольку у этой функции два
аргумента в виде строк длиной в 50 и 20 символов и она возвращает строку длиной
в 10 символов, правильным ее описанием будет
DECLARE EXTERNAL findZip
CHAR(50) CHAR(20) RETURNS CHAR(10)
LANGUAGE C;
Указание на язык С в данном описании означает что аргумент адреса передается
функции findZip в виде подходящей для С программы □
8.6.4 Упражнения к разделу 8.6
Упражнение 8.6.1. Определите абстрактный тип данных "PC", объекты кото-
рого представляют персональные компьютеры, а также скорость их процессоров,
RAM. размер жесткого диска, скорость CD н цену
Упражнение 8.6.2. Запишите следующие функции для ADT из упражнения 8.6.1,
используя для внешних функций язык С.
*а) Функиию-конструктор newPC, принимающую значения пяти атрибутов PC
ADT и возвращающую новый объект этого типа. При определении этой
функции можно (и нужно) применять встроенный конструктор РС().
8.7 Сравнение подходов OOL/OOL и SQL3
371
*Ь) Функцию value с объектом PC в качестве аргумента. Опа возврашает
оценку PC в виде действительного числа, показывающего "значение"
компьютера Формула его “значения" — скорость процессора плюс объем
RAM {в мегабайтах), умноженный на 5. плюс объем жесткого диска
(в гигабайтах), умноженный на 50, плюс скорость CD, умноженная на 10.
с) Функцию better. Она использует объект PC как аргумент и возвращает
другой объект PC. имеющий ту же цену, но вдвое большие скорость
процессора, RAM, жесткий диск и скорость CD. В описании функции
можно использовать конструктор newPC из части (а) этого упражнения.
d) Функцию equalPC, выражающую равенство объектов PC. Эта функция
определяет два PC как "равные", если их скорости и объемы жестких
дисков совпадают, не учитывая значений других компонентов.
е) Функцию НРС, выражающую отношение "меньше чем" для ADT PC. Она
определяет р, < р>, если "значение" PC Pi меньше "значения" PC рг-
"Значение” определено в части (bj данного упражнения; можно использо-
вать также функцию из этой части.
Упражнение 8.6.3. Определите абстрактный тип данных Ship для корабля,
включающий его название, дату спуска на воду, число орудий, водоизмещение,
видеоклип о его действиях в MPEG-кодировке и документ, отражающий его
историю.
Упражнение 8.6.4. Дайте описания и определения перечисленных ниже функ-
ций на Ship ADT из упражнения 8.6.3.
а) Функции firePower с объектом Ship в качестве аргумента, возвращающей
"огневую мощь" (число орудий корабля, умноженное на куб их калибра).
Ь) Функции playVideo с объектом Ship в качестве аргумента, которая показы-
вает видеофильм о корабле с помощью проигрывающей файл MPEG
внешней функции playMpeg (которую нужно описать).
с) Функции-конструктора newShlp со значениями имени в качестве аргу-
ментов, которая возврашает новый объект Ship с этим именем.
d) Функции equalShlps, выражающей равенство объектов Ship. Эта функция
определяет два корабля как "равные", если они имеют одно и то же назва-
ние и год спуска на воду, не учитывая значений других компонентов.
е) Функции ItShips, выражающей отношение “меньше чем" для ADT Ship.
Она определяет j| < .fj, если название корабля s, по алфавиту меньше име-
ни корабля ть при одинаковых названиях s, спущен на воду раньше sj.
8.7 Сравнение подходов ODL/OQL и SQL3
Два главных стандарта управления объектно-ориентированными БД —ODL/OQL
и SQL3 — различаются по нескольким параметрам, но сходства между ними больше.
Несмотря на го что они базируются на различных моделях, в каждом нз них эффек-
тивно используется то, что является фундаментальным для другого.
В этом разделе перечислены принципиальные различия между двумя упомяну-
тыми стандартами и между* способами, с помощью которых в них достигаются
возможные сбалансированные решения. В то же время будет показано, чем типы
"строка таблицы" SQL3 и ADT отличаются друг от друга и от всех других форм ин-
терфейсов (классов) в ODL. Таким образом, сравниваются три различных подхода
к реализации объектно-ориентированного подхода к ODL/OQL, типы "строка
таблицы” SQL3 и типы значений SQL3.
372
Глава 8 Объектно ориентированные языки запросов
I. Среда программирования. В OQL предполагается, что его операторы встрое-
ны в язык программирования, используют й такие же модели програм-
мирования и данных. Этот язык является объектно-ориентированным,
например C++, Smalltalk или Java. Напротив, SQL3 предполагает, что его
объекты не являются объектами окружающего главного языка. Так же как
в стандартах и реализациях SQL, здесь используется ограниченный интер-
фейс, позволяющий передавать переменные между хранимыми данными
SQL и переметными главного языка. ADT SQL3 является дополнитель-
ным механизмом коммуникации для обычного интерфейса SQL/главный
язык, мссмотренного в разделе 7.1.
2. Роль отношений. При рассмотрении данных в SQL3 отношения сохраняют
ключевую роль. Типы строк действительно описывают отношения, a ADT
описывают новые типы для атрибутов. В OQL фундаментальными пеня
тнями являются множества и мультимножества объектов или структур
благодаря их роли в выражениях типа select-from-where. Наборы структур
в ODL/OQL имеют большое сходство с отношениями SQL3.
3. Пикапе пяния. Типы "строка таблицы” не инкапсулируются. Естественна
возможность запрашивать и изменять отношения, кортежи и компоненты
заданного типа строки всеми способами, допустимыми в SQL Абстракт-
ные типы данных SQL3 инкапсулируются в обычном смысле. Методы
инкапсуляции классов ODL и ADT SQL3 имеют большое сходство.
4. Экстенты кмссов. В OQL предполагается, что каждому классу приписана
единственная степень. Ссылки (т.е, связи в терминологии OQL) sceiaa
относятся к некоторым членам этого экстента. При желании степень
в SQL3 можно использовать для типа “строка таблицы", т.е. для отно пе-
ния, содержащего кортеж данного типа. Если для экстента тип строки не
определен, могут возникнуть проблемы с поиском отношения, содержа-
щего кортеж, на который делается конкретная ссылка (см. раздел 8.5.6).
5. Изменяемость объектов. Созданный объект неизменен', ни одна часть его
значеш я не может быть изменена. Объекты элементарного типа, напри-
мер натуральные числа или строки, в этом смысле неизменны. Если ком-
поненты объекта могут изменяться, в то время как сам объект сохраняет
свою объектную уникальность, он изменяем. Классы ODL и типы "строка
таблицы" SQL3 определяют классь изменяемых объектов, а в ODL/OQL
предполапется, что изменения объектов происходят в окружающем языке
программирования. ADT SQL3 не являются изменяемыми в строгом
смысле этого слова. Однако функции изменения, примененные к их
стапым значениям, дают новые значения, подобно тому как применение
оператора UPDATE языка SQL к атрибуту с целым значением может
породить новое целое число, которое заменит старое в кортеже.
б Идентификация обоектов. ODL и ADT SQL3 допускают обычную интер-
претацию идентификации объектов как генерируемой системой величи-
ны, которую нельзя хранить и которой нельзя манипулировать. Для ссы-
лок I SQL3 такая интерпретация не подходит. Пользователь может
созда ь столбец о ношения, где идентификация объекта сохраняется в
самом кортеже подобно обычному значению. В результате идентифика-
ция одною или нескольких объектов может быть ключом отношения Эта
особенность имеет определенное значение, хотя и влечет за собой введе-
ние и БД висящих ссылок в результате изменений или удалений. Есл t
нденти 11 кания обьекта не считается атрибутом, у отношений обычно два
ключа' гдентнфикация объекта н суррогат значения типа номеров страхо-
вого полиса или “сертификатов" из наших примеров.
8 8 Итоги
373
8.8 Итоги
Методы в ODL. В дополнение к атрибутам и связям, рассмотренным я главе 2
ODL позволяет описывать методы в виде части определения интерфейса
При этом определяется только сигнатура метода, т.С. ТИПЫ параметров ввода
И вывода. Сами методы определяются в окружающей программе и записыва-
ются на объектно-ориентированном главном языке
♦ Система типов OQL. Типы OQL строятся из имен классов и атомарных
типов. Конструктор типов Struct применяется для построения структур и
множественных типов для множеств мультимножеств, списков и наборов.
Поэтому данная система типов является такой же, как в ODL, за исключени-
ем того, что в OQL нет предела степени вложения конструкторов типов
♦ Выражения select-from-where в OQL Эти выражения соответствуют предложе-
ниям вида select-from-where в SQL. В пункте FROM можно описать перемен-
ные пробегаю ине любое множество включая степени классов (аналогичные
отношениям) и множества, являющиеся значениями атрибутов в объектах
Обычные операторы OQL В OQL применяются операторы 'для всех", “суще-
ствует" 1N. объединения, пересечения разности и агрегации, сходные по
своей сути с операторами SQL. Однако агрегация всегда проводится на
множестве, а не на столбце отношения.
♦ Оператор GROUP BY Оператор GROUP BY языка OQL — оператор в предло-
жении select-from-where. аналогичный такому же оператору SQL Но в OQL
множество объектов каждой группы явно достижимо через имя поля'partition
♦ Извлечение элементов из множеств в OQL. Единственный элемент одноэле-
ментного множества .можно получить с помошью оператора ELEMENT Для
получения элементов множеств, содержащих более одного члена, сначала
нужно превратить это множество в список, применив оператор ORDER BY
в предложении select from-where, а затем использовать никл в программе
окружающего главного языка для извлечения каждого элемента этого списка
Объекты в SQL3 В SQL3 есть два вида объектов: типы "строка таблицы"
и абстрактные типы данных. Первые являются типами для кортежей, п вто-
рые — для компонентов кортежей.
♦ Идентификация объектов для типов "строка таблицы". Для каждого типа
"строка таблицы" существует тип ссылки, значением которого является ID
объекта для конкретного кортежа В SQL3 типом атрибута может быть
ссылка на тип кортежей отношения, куда входит этот атрибут Его значением
может быть ID обгектз для корзежа, содержащего этот атрибут, что позволяет
данному ID служить и и качестве ключевого атрибута всего отношения
♦ Абстрактные типы данных. ADT в SQL3 описываются с помощью оператора
CREATE TYPE Значения ADT — это структуры записей с одним или более
компонентами с которыми могут быть связаны определенные методы
♦ Методы в ADT языка SQL3. Для ADT можно задать функции (методы). Они
могут быть описаны либо на языке программирования, сходном с SQL, либо
п виде внешних функций, выраженных на главном языке
Глава 8 Обьегтно-орментированные языки запросов
8.9 Литература к главе 8
Информация no OQL п ODL дана и книге [ ]. Материал по SQL3 ищите го
библиограф: ческим ссылкам к главе 5. Отчет [3) является источником информации
о строковых объектах. В отчете |2| дано раннее описание абстрактных типов дан-
ных SQL3. нт которого различными путями развивается определенны!”! ста щарт.
I. CatteH. К. G.G (ей.), The Object Database Standard: ODMG-93 Release 12,
Morgan-Kaufmann. San Francisco, 1996.
2 Mellon. J.. .1 Bauer, and К Kulkarni, "Object ADT (with improvements for
value ADT's)." ISO WG3 report X3H2 91-083. April. 1991.
3. Kulkarni. К., M. Caiey, L. DeMicbiel, N Mattos, W. Hong, and M Ube I,
"Introducing reference types and cleaning up SQL3's object model.” ISO WG3
герои X3H2-95-456, Nov , 1995.
Книги издательства "ЛОРИ"
Вы можете приобрести:
В Москве:
"Московский Дом Книга'
ул. Новый Арбат, 6
"Библио-Глобус"
ул Мясницкая, 6
' Дом Texi ической Книги"
Ленинский пр-т., 40
В Санкт Петербурге:
ЗАО 'Диалект
(812) 534-4578
"Техническая книга"
ул. Пушкинская. 2
"Дом Книги"
Невский пр-т., 24
' Мнр"
Ленинградский пр-т.,78
' Молодая гвардия”
ул Большая полянка, 28
"Магазин на Ладожской"
ул. Ладожская 8
В Киеве:
'Техническая книга"
(044) 419-7061
(044) 464-6895
Виртуальные книжные магазины
В Санкт-Петербурге
В Риге
WWW BOOKS.RU
WWW.636.LV
В Новосибирске WWW TOP-KNIGA.RU
В Нью-Йорке WWW KNIGA.COM
г. Санкт Петербург, "Дом Книги", отдел "Книга почтой'
тел. (812) 219-6224
г. Новосибирск, "Топ Книга"
тел. (3832) 36 10 26, 36-10-27