25.6. Резюме

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

Затем обсуждались две грубейшие ошибки. Первая заключалась в отождествлении объектных классов и переменных-отношений (уравнение, которое, к сожалению, выгля­дит привлекательно). Мы выдвинули предположение, что ошибка возникла из-за путани­цы с двумя совершенно различными интерпретациями термина объект. Был подробно рассмотрен пример, который наглядно продемонстрировал, какой может быть система, в которой допущена первая грубейшая ошибка, а также показал, к каким последствиям приводит такая ошибка. Одним из последствий этой ошибки является то, что она приво­дит непосредственно ко второй грубейшей ошибке, а именно — к смешиванию указате­лей и отношений (хотя на самом деле вторая ошибка может быть допущена и без первой, и почти все системы на современном рынке, к сожалению, ее допускают). На наш взгляд, вторая грубейшая ошибка нарушает концептуальную целостность реляционной модели во многих отношениях. В частности, она нарушает принцип взаимозаменяемости базо­вых и производных отношений.

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

И наконец мы познакомились с матрицей классификации СУБД Стоунбрейкера и крат­ко обсудили те преимущества, которые могли бы быть получены от истинного сближения объектных и реляционных технологий (здесь под "истинным сближением" подразумевает­ся, в частности, что не допущены две указанные выше грубейшие ошибки).

Список литературы

В последние годы было создано несколько объектно-реляционных прототипов. Среди них наиболее известны система Postgres, разработанная в университете штата Калифор­ния в Беркли ([25.26], [25.30], [25.32]), и система Starburst, разработанная в корпорации IBM ([25.14], [25.17], [25.21], [25.22]). Обратите внимание, что ни одна из них не может быть отнесена, по крайней мере в оригинальной версии, к системам, объектный подход которых основывался бы на "очевидно корректном" уравнении домен = класс.

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

25.1. Brooks F.P., Jr. The Mythical Man-Month (20th anniversary edition). — Reading, Mass.: Addison-Wesley, 1995.

25.2. Carey M.J., Mattos N.M., Nori A.K. Object/Relational Database Systems: Principles, Products, and Challenges // Proc. 1997 ACM SIGMOD Int. Conf. on Management of Data. — Tucson, Ariz., May, 1997.

Цитата из работы: "Абстрактные типы данных, определяемые пользователем функции, типы строк, ссылки, наследование, подтаблицы, коллекции, триггеры... Что же все-таки это такое?". Хороший вопрос! В списке есть восемь возможностей и по умолчанию предполагается, что они присутствуют в языке SQL3. Мы могли бы доказать, что четыре из них нежелательны, две другие относятся к тому же раз­ряду, а остальные две не являются специфическими для объектно-реляционной системы (см. приложение Б).

25.3. Carey M.J. et al. The BUCKY Object/Relational Benchmark // Proc. 1997 ACM SIGMOD Int. Conf. on Management of Data. — Tucson, Ariz., May, 1997.

Цитата из резюме: "BUCKY (Benchmark of Universal or Complex Kwery Ynterfaces [так!]) — эталонный тест, ориентированный на запросы, с помощью которого про­веряются многие из ключевых возможностей объектно-реляционной системы, включая типы строк и наследование, ссылки и выражения путей, множества ато­марных значений и ссылок, методы и позднее связывание, а также определяемые пользователем абстрактные типы данных и их методы".

4. Cattell R.G.G. What Are Next-Generation DB Systems? // CACM. — October, 1991. — 34, № 10.

5. Chamberlin D.D. Relations and References — Another Point of View // InfoDB. — April, 1997.— 10, №6.

См. аннотацию к [25.11].

25.6. Chaudhuri S., Gravano L. Optimizing Queries over Multi-Media Repositories // Proc. 1996 ACM SIGMOD Int. Conf. on Management of Data. — Montreal, Canada, June, 1996.

Объектно-реляционные базы данных могут быть использованы как "мультимедиа-хранилища". Для запросов мультимедиаданных обычно недостаточно просто мно­жества результирующих объектов; необходимо еще знать степень соответствия для каждого такого объекта, которая показывает, в какой мере он удовлетворяет поисковому условию (например, "степень красноты" изображения). Такими запро­сами можно задавать порог степени соответствия, а также квоту [6.4]. В этой ста­тье рассматривается оптимизация таких запросов.

7. Chaudhuri S., Shim К. Optimizing Queries with User-Defined Predicates // Proc. 22nd Int. Conf. on Vary Large Data Bases. — Mumbai (Bombay), India, September, 1996.

8. Codd E.F. and Date CJ. Interactive Support for Nonprogrammers: The Relational and Network Approaches // Date С J. Relational Database: Selected Writings. — Reading, Mass.: Addison-Wesley, 1986.

В статье вводится понятие существенности— концепция, которая очень важна для правильного понимания моделей данных (в обоих смыслах этого термина! — см. главу 1, раздел 1.3). Реляционная модель в своей основе имеет лишь одну су­щественную конструкцию, а именно — отношение. Объектная модель, напротив, имеет много конструкций: множества, мультимножества, списки, массивы и т.д. (не говоря уже об идентификаторах объектов). См. [25.9], [25.10] и [25.13].

25.9. Date C.J. Support the Conceptual Schema: The Relational and Network Approaches // Relational Database Writings 1985-1989. — Reading, Mass.: Addison-Wesley, 1990. Один из аргументов против смешивания указателей и отношений [25.11]— это сложность, к которой приводят указатели. В данной статье приводится пример, очень ясно иллюстрирующий эту сложность (рис. 25.5 и 25.6).

MAJOR Р#	MINOR Р#	QTY
Р1	Р2	2
Р1	Р4	4
Р5	РЗ	1
РЗ	Р6	3
Р6	Р1	9
Р5	Р6	8
Р2	Р4	3

Рис. 25.5. Отношение спецификации материалов

Сплошные линии: "входимость деталей" Пунктирные линии: "где используется"

Рис. 25.6. Аналог отношения, показанного на рис. 25.5, который основан на ука­зателях

25.10.Date C.J. Essentiality // Relational Database Writings 1991-1994.— Reading, Mass.: Addison-Wesley, 1995.

25.11.Date C.J. Don't mix Pointers and Relations! и Don't mix Pointers and Relations! — Please // Date C.J., Darwin H. and McGoveran D. Relational Database Writings 1994— 1997. — Reading, Mass.: Addison-Wesley, 1998.

В первой из этих статей приводятся аргументы против второй грубейшей ошибки. В [25.5] Чемберлин опровергает некоторые аргументы данной статьи. Вторая ста­тья является прямым ответом на опровержение Чемберлина. 25.12.Date C.J. Objects and Relations: Forty-Seven Points of Light // Date C.J., Darwin H. and McGoveran D. Relational Database Writings 1994-1997.— Reading, Mass.: Addison-Wesley, 1998.

Подробный ответ на [25.19]. 25.13.Date C.J. Relational Really Is Different. Выпуск № 10 серии статей [5.9]. www.intelligententerprise.com.

25.14.DeMichael L.G., Chamberlin D.D., Lindsay B.G., Agrawal R. and Arya M. Polyglot: Extentions to Relational Databases for Shrable Types and Functionas in a Muti-Language Environment// IBM Research Report RJ8888. — 1992. Цитата из резюме: "Polyglot — расширяемая система типов реляционной базы дан­ных, поддерживающая наследование, инкапсуляцию и динамическое назначение методов". (Динамическое назначение методов (dynamic method dispatch)— это другое название связывания во время выполнения программы (синонимы: позднее связывание (late binding) и динамическое связывание (dynamic binding). — Прим. перев.) Далее: "[Polyglot] позволяет использовать несколько прикладных языков, причем объекты сохраняют свое поведение при переходе между приложениями баз данных и прикладными приложениями. В статье описано устройство системы Polyglot, расширения языка SQL для поддержки используемых системой типов и методов и реализация системы в [прототипе] проекта Starburst". Система Polyglot имеет непосредственное отношение к вопросам этой главы (а также глав 5, 19 и 24). Здесь следует сделать несколько замечаний. Во-первых, реляцион­ный термин домен в статье ни разу не упоминается (что очень удивительно). Во-вторых, в системе Polyglot имеются встроенные генераторы типов (в терминах этой системы — метатипы): базовый тип, тип-кортеж, переименованный тип, тип-массив и тип-язык, но (что также удивительно) нет типа-отношения. Однако в системе имеется возможность вводить новые генераторы типов.

25.15.DeWitt D.J., Karba N., Luo J., Patel J.M., Yu J.-B. Client-Server Paradise // Proc. 20th Int. Conf. on Vary Large Data Bases. — Santiago, Chile, September, 1994. Система Paradise (Parallel Data Information System — информационная система параллельных данных)— это разработанный в Висконсинском университете объектно-реляционный прототип системы, "созданный для ГИС-приложений" (ГИС — геоинформационная система). В статье описаны архитектура и реализа­ция системы Paradise.

25.16.Godfrey М., Mayr Т., Seshadri P. and Thorsten von Eichen. Secure and Portable Database Extensibility // Proc. 1998 ACM SIGMOD Int. Conf. on Management of Data. — Seattle, Wash, June, 1998.

"Поскольку операторы, определяемые пользователем, поставляются неизвестными или ненадежными клиентами, в СУБД должны быть предусмотрены меры предосто­рожности по отношению к операторам, которые могут разрушить систему, модифи­цировать ее файлы или непосредственно память (в обход механизма санкционирова­ния), монополизировать центральный процессор, память или дисковые ресурсы" (цитата несколько изменена). Очевидно, необходим дополнительный контроль. В этой статье рассказывается об исследованиях данного вопроса с использованием языка Java и объектно-реляционного прототипа PREDATOR [25.24]. В обнадежи­вающем заключении говорится, что система базы данных "может поддерживать безопасные и переносимые расширения с использованием языка Java без значи­тельных потерь в производительности".

25.17.Haas L.M., Freytag J.C., Lohman G.M., Pirahesh Н. Extensible Query Processing in Starburst // Proc. ACM SIGMOD Intern. Conf. on Management of Data. — Portland, Ore., June, 1989.

В работе представлены цели расширенного проекта Starburst [25.21]: "В Starburst предусмотрено добавление новых методов хранения таблиц, новых типов доступа и ограничений целостности, новых типов данных, функций и новых операций с таблицами". При этом система делится на два основных компонента, Core и Corona, которые соответствуют компонентам RSS и RDS оригинальной системы System R [4.2]. В компоненте Core поддерживаются функции расширения, описанные в [25.21], а в компоненте Corona— язык за­просов Hydrogen, который является диалектом языка SQL. В этом диалекте ис­ключено большинство ограничений реализации языка SQL, принятого в систе­ме System R, он более независим, поддерживает рекурсивные запросы и может быть расширен пользователем. В статье содержится интересное обсуждение проблемы "переписывания запросов", т.е. правил преобразования выражений (см. главу 17). Об этом также можно прочесть в [17.50].

25.18.Hellerstein J.M., Naughton J.F. Query Execution Techniques for Caching Expensive Methods // Proc. 1996 ACM SIGMOD Int. Conf. on Management of Data. — Montreal, Canada, June, 1996.

25.19.Kim W. On Marrying Relations and Objects: Relation-Centric and Object-Centric Perspectives // Data Base Newsletter. — November/December, 1994. — 22, № 6.

В этой статье приводятся аргументы, оспаривающие мнение, согласно которому отождествление переменных-отношений и классов— серьезная ошибка ("первая грубейшая ошибка"). Статья [25.12] — ответ на данную статью.

25.20.Kim W. Bringing Object/Relational Down to Earth // DBP&D. — July, 1997.— 10, №7.

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

1. Модель данных

2. Язык запросов

3. Критические к сбоям службы

4. Вычислительная модель

5. Производительность и масштабируемость

6. Инструменты базы данных

7. Полнота использования вычислительной

мощности

Отдавая должное первому критерию (самому важному), Ким придерживается точки зрения (отличной от той, которая представлена в Третьем манифесте [3.3]), что модель данных должна быть "основной объектной моделью, опреде­ленной группой Object Management Group (OMG)", которая "включает реляци­онную модель данных, а также основные концепции объектно-ориентированного моделирования объектно-ориентированных языков программирования". По мне­нию Кима, сюда входят следующие понятия: класс (в статье добавляется "или тип"), экземпляр, атрибут, ограничения целостности, идентификаторы объ­ектов, инкапсуляция, (множественное) наследование классов, (множественное) наследование ADT, данные типа ссылок, атрибуты со значениями-множествами, атрибуты классов, методы классов и т.п. Заметим, что отноше­ния, которые мы относим и к критическим, и к фундаментальным понятиям, ни­где явно не упоминаются. Ким утверждает, что основная объектная модель груп­пы OMG в дополнение ко всему перечисленному в списке полностью включает реляционную модель, хотя на самом деле это не так.

25.21.Lindsay В., McPherson J., Pirahesh Н. A Data Management Extension Architecture // Proc. ACM SIGMOD Intern. Conf. on Management of Data. — San Francisco, Calif., May, 1987.

В работе описана архитектура прототипа системы Starburst, в котором "реализованы расширения управления данными для реляционных СУБД". Описа­ны два типа таких расширений: на основе определенных пользователем структур хранения и методов доступа, а также на основе определенных пользователем огра­ничений целостности (но непременно все ограничения целостности должны быть определены пользователем?) и триггерных процедур. Однако "помимо этих, суще­ствуют также другие направления расширения СУБД, включая определенные пользователем абстрактные типы данных и технологии оценки запросов". 25.22.Lohman G.M. et al. Extensions to Starburst: Objects, Types, Functions and Rules // CACM. — October, 1991. — 34, № 10.

25.23. Maier D. Comments on the Third-Generation Database Sytem Manifesto // Tech. Report No. CS/E 91-012. — Oregon Gradulate Center, Ore. — April, 1991. Майер весьма критичен буквально ко всему материалу статьи [25.34]. Мы согласны с некоторыми его критическими замечаниями, но не согласны с остальными. Однако нас заинтересовали следующие высказывания (в них поддерживается наша точка зрения, что концепция объектов содержит лишь одну хорошую идею, а именно — надлежащую поддержку типов данных): "Многие из нас добивались очищения тео­рии объектно-ориентированных систем баз данных от сути "объектной ориентиро­ванности"... Мои взгляды на то, что является наиболее важным в объектно-ориентированных базах данных, менялись с течением времени. Сначала я думал, что это было наследование и модель сообщений. Позже я пришел к выводу, что идентич­ность объектов, поддержка сложного состояния и инкапсуляция поведения более важны. Но в последнее время, когда я услышал мнение пользователей объектно-ориентированных СУБД о том, чему они придают наибольшее значение в таких сис­темах, я считаю, что решающее — это возможность расширения типа. Идентич­ность, сложное состояние и инкапсуляция по-прежнему важны, но лишь настолько, насколько они поддерживают создание новых типов данных". 25.24.Patel J. et al. Bilding a Scalable Geo-Spacial DBMS: Technology, Implementation, and Evaluation // Proc. ACM SIGMOD Int. Conf. on Management of Data. — Tucson, Ariz. — May, 1997.

Цитата из резюме: "В этой статье представляется ряд методов для распараллелива­ния геокосмических систем баз данных и обсуждается их реализация в объектно-реляционной системе баз данных Paradise" [25.15].

25.25. Ramakrishnan R. Database Management Systems. — Boston, Mass.: McGraw-Hill. — 1998.

25.26.Rowe L.A., Stonebraker M.R. The Postgres Data Model // Proc. 13th Int. Conf. on Vary Large Data Bases. — Brighton, UK. — September, 1987.

25.27.Samet H. The Design and Analysis of Spatial Data Structures.— Reading, Mass.: Addison-Wesley, 1990.

25.28. Saracco CM. Universal Database Management: Guide to Object/Relation Technolody. — San Francisco, Calif.: Morgan Kaufrnann, 1999.

Интересный обзор, написанный на высоком уровне. Однако отметим, что его автор не отвергает (как, кстати, и Стоунбрейкер в [25.31]) очень сомнительную форму наследования, включающую версию идеи подтаблиц и супертаблиц (о которой мы отзываемся весьма скептически в начале [13.12]). Данная версия существенно от­личается от последней версии, включенной в язык SQL3. Поясним это на примере. Предположим, что таблица PGMR (программисты) определена как подтаблица таб­лицы ЕМР (служащие). Тогда Саракко и Стоунбрейкер считают, что таблица ЕМР содержит строки лишь для служащих, которые не являются программистами, в то время как в языке SQL3 эта таблица воспринималась бы как содержащая строки для всех служащих (см. приложение Б). 25.29.Seshadri P., Paskin М. PREDATOR: An OR-DBMS with Enhanced Data Types // Proc. 1997 ACM SIGMOD Int. Conf. on Management of Data. — Tucson, Ariz., May, 1997. Суть системы PREDATOR— предоставить механизм для каждого типа данных, чтобы можно было задавать семантику их методов. Эта семантика затем использу­ется для оптимизации запросов.

25.30.Stonebraker М. The Design of the POSTGRES Storage System // Proc. 13th Intern. Conf. on Very Large Data Bases. — Brighton, UK, September, 1987.

25.31.Stonebraker M., Brown P. (with Moore D.) Object/Relational DBMSs: Tracking the Next Great Wave (2nd edition). — San Francisco, Calif: Morgan Kaufrnann, 1999. Эта книга представляет собой руководство по объектно-реляционным системам. В большой степени — фактически почти исключительно — она базируется на продукте Universal Data Option для СУБД Informix's Dynamic Server. Этот продукт основывает­ся на более ранней системе, которая называлась Illustra (коммерческий продукт, в разработке которого Стоунбрейкер лично принимал участие). В [3.3] можно найти дополнительный анализ и критику этой книги. См. также аннотацию к [25.28].

25.32. Stonebraker M, Kemnitz G. The Postgres Next Generation Database Management System // CACM. — October, 1991. — 34, № 10.

25.33.Stonebraker M., Rowe L.A. The Design of Postgres // Proc. ACM SIGMOD Intern. Conf. on Management of Data. — Washington, D.C., June, 1986.

В работе приведены основные цели создания системы Postgres.

1. Обеспечение усовершенствованной поддержки сложных объектов.

2. Обеспечение расширяемости типов данных, операторов и методов доступа.

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

4. Упрощение кода СУБД для восстановления после разрушения системы.

5. Проектирование СУБД с учетом преимуществ оптических дисков, многопро­цессорных рабочих станций и специальных чипов на основе сверхбольших ин­тегральных схем.

6. Минимальное количество изменений реляционной модели (а может быть, даже отсутствие изменений).

25.34.Stonebraker М. et al. Third Generation Database System Manifesto // ACM SIGMOD.— September, 1990. — 19, № 3.

Отчасти эта работа противопоставляется [24.1], в которой, между прочим, по су­ществу, полностью игнорируется реляционная модель. Цитата: "Системы второго поколения внесли большой вклад в развитие непроцедурного доступа к данным и независимости от данных, и этим вкладом нельзя пренебрегать при разработке систем третьего поколения". Приведенные ниже положения являются, по сути, требованиями (в некоторой степени перефразированными), которые предъявляют­ся к "СУБД третьего поколения".

1. Обеспечение традиционных служб базы данных, а также более развитых объ- ектных структур и правил

• Система с более развитыми типами

• Наследование

• Функции и инкапсуляция

• Необязательные идентификаторы кортежей

• Правила (например, правила целостности), не связанные с конкретными объектами

2. Преемственность СУБД второго поколения

• Использование путей для адресации объектов только в крайнем случае

• Определения интенсиональных и экстенсиональных множеств (которые оз­начают коллекции, автоматически поддерживаемые со стороны системы, и коллекции, поддерживаемые вручную пользователем)

• Обновляемые представления

• Кластеризация, индексирование и т.д., скрытые от пользователя

3. Поддержка открытых систем

• Поддержка нескольких языков

• Ортогональная перманентность типов

• Поддержка языка SQL

• Запуск запросов и вывод результатов, осуществляемые на самом низком уровне общения между клиентом и сервером

В [3.3] содержатся подробный анализ и критика этой статьи. См. также [25.23]. Замечание. Кстати, сейчас можно пояснить, почему Третий манифест называется третьим... Он был написан именно после двух предыдущих манифестов (см. [24.1] и [25.34]) и, мы надеемся, что заменил их.

25.35.Wilkes M.V. Software and the Programmer // CACM. — May, 1991. — 34, № 5.

Приложения

В приложении А приводятся подробные сведения о синтаксисе и семантике выраже­ний языка SQL/92, что позволяет использовать его как соответствующий справочник. В приложении Б содержится обзор основных функций языка SQL3, в частности "объектных" и "объектно-реляционных". В приложении В представлен перечень наибо­лее важных сокращений и специальных символов, используемых в данной книге, вместе с кратким описанием их значения.

Приложение

^{выражения языка}

АЛ. Введение

Выражения языка SQL, точнее — табличные, условные и скалярные SQL-выражения, составляют основу этого языка. В данном приложении детально описаны синтаксис и семантика подобных выражений (в соответствии со стандартом SQL/92). Однако необходимо сразу же отметить, что названия синтаксических категорий и конст­рукций языка SQL чаще всего отличаются от тех, которые употребляются в самом стан­дарте SQL/92 (см. [4.22]). Такой подход выбран потому, что используемые в стандарте термины часто не совсем удачны, в частности сами термины табличное выражение, ус­ловное выражение и скалярное выражение не являются стандартными.

А. 2. Табличные выражения

Сначала представим BNF-грамматику для выражений типа <табличное выраженчё>. В грамматике полностью исключены опции, имеющие отношение к NULL-значениям (см. раздел 18.7 главы 18). Отметим, что в данном приложении широко используются со­глашения о списках, которые были представлены в разделе 4.6 главы 4.

<табпичное выражение>

::= ^выражение соединения таблиц> | <выражение без соединения таблицу

<выражение соединения таблицу

::= <ссыпка на таблицу> [ NATURAL ] JOIN <ссылка на таблицу> [ ON <условное выражение> j USING ( <список имен столбцов> ) } | <ссылка на таблицу> CROSS JOIN <ссылка на табпщу> | (<выражение соединения таблицу)

<ссылка на таблицу>

::= <имя таблицЫ> [ [ AS ] <имя переменной диапазона> [ (<список имен столбцов>) ] ] | (<табличное выражение> ) [ AS ] <перемежая диапазона>

[ {<список имен столбцов> ) } | <выражение соединения таблиц>

<выражение без соединения таблиц> ::= <терм без соединения таблицу

| <табпичное выражение> UNION [ ALL ]

[ CORRESPONDING [ BY (<список имен столбцозУ ) ] ]

<табличный терм> | <табличяое выражение> EXCEPT [ ALL ] [ CORRESPONDING [ BY {<список имен стол6цов>) ] ]

<табличвый терм>

<терм без соединения таблицу

::= <первичная таблица без соединения > | табличный терм> INTERSECT [ ALL ] [ CORRESPONDING [ BY (<список имен столбцов> ) } ] <первичная таблица>

<та6личный теры>

::= <терм без соединения таблицу | <выражение соединения таблицу

<первичная таблица>

::- <первичная таблица без соединения > | <выражение соединения таблицу

<первичная таблица без соединения > ::= TABLE <имя таблицыУ <конструктор таблицьо <выражение выборкиУ (<выражение без соединения таблицу )

<конструктор таблице

;:= VALUES <список конструкторов строку

<конструктор строку

::= <скалярное зыражениеУ

(<список скалярных аыраженийУ ) (<табличное выражение> )

<выражение выборкиУ

::= SELECT [ ALL | DISTINCT ] <список выбираемых элементовУ FROM <список ссылок на таблицыУ [ WHERE <условное выражениеУ ]

[ GROUP BY <список имен стопбцоаУ ] [ HAVING <условное выражениеУ ]

<зыбираемый элементу

::= <скалярное выражениеУ [ [ AS ] <столбецУ ] | [ <переменная диапазонаУ . ] *

Рассмотрим конкретный случай, бесспорно, наиболее важный на практике, а имен­но — выражения типа <выражение выборкиУ. Их можно рассматривать, хотя и упрощен­но, как выражения типа <табпичное выражениеУ, которые не содержат ключевых слов

JOIN, UNION, EXCEPT и INTERSECT. Мы говорим "упрощенно", поскольку, разумеется, та­кие операторы могут включаться в выражения, которые вложены в рассматриваемое вы­ражение типа <выражение выборки>. Предложения JOIN, UNION, EXCEPT и INTERSECT под­робно обсуждаются в разделе 7.7 главы 7.

Как видно из приведенного выше определения, выражение типа <выражение выборки> включает в указанной последовательности предложения SELECT, FROM и необя­зательные предложения WHERE, GROUP BY и HAVING. Рассмотрим их поочередно.

Предложение SELECT

Предложение SELECT имеет следующий вид

SELECT [ ALL | DISTINCT ] <список выбираемых элементов>

Пояснения

1. Параметр <список выбираемых эпементов> не должен быть пустым (формат пара­метра <вы6ираемый элемент> рассматривается ниже).

2. Если уточнения ALL и DISTINCT не указаны, то по умолчанию подразумевается ALL.

3. Допустим, предложения FROM, WHERE, GROUP BY и HAVING уже обработаны. Не имеет значения, какие из них указаны и какие опущены; концептуальный результат обра­ботки этих предложений всегда будет таблицей (возможно, "сгруппированной" таблицей, что поясняется ниже). Обозначим эту таблицу как Т1, хотя такой проме­жуточный концептуальный результат на самом деле не имеет имени.

4. Пусть таблицей Т2 будет таблица, которая является производной от Т1 и была по­лучена посредством вычисления заданных параметров <выбираемый элемеит> для таблицы Т1 (см. ниже).

5. Пусть таблица ТЗ будет таблицей, которая является производной от Т2. Таблица ТЗ получается посредством исключения лишних дублирующих строк из таблицы 12, ес­ли указано ключевое слово DISTINCT, или идентична таблице Т2 в противном случае.

6. Полученная таблица ТЗ представляет собой окончательный результат выполнения всей операции.

Рассмотрим допустимые значения параметра <выбираемый элементу. Возможны два случая, причем второй случай представляет собой просто сокращение для списка элемен­тов выборки первого вида. Таким образом, первый случай по сути является основным.

Случай 1. Параметр <выбираемый элементу принимает следующий вид.

<скалярное выражениё> [ [ AS ] <столбец> ]

Параметр <скалярное выражение> обычно (но необязательно) задает один или не­сколько столбцов таблицы Т1 (см. приведенный выше п. 3). Для каждой строки таблицы Т1 указанное скалярное выражение в результате вычисления дает некоторое скалярное значение. Список таких результатов (соответствующих вычислению всех заданных па­раметров <выбираемый элемент> в предложении SELECT для одной строки таблицы Tl) составляет одну строку таблицы Т2 (см. приведенный выше п. 4). Если параметр <выбираемый элемент> включает предложение AS, то неуточненное значение параметра

<стол6ец> из этого предложения присваивается в качестве имени соответствующему столбцу таблицы Т2 (необязательное ключевое слово AS является лишним и может быть опущено без какого-либо ущерба). Если же параметр <вы6яраетй элемент> не включает предложение AS, то, если он содержит просто (возможно, уточненное) имя <стол6ец>, это имя назначается соответствующему столбцу таблицы Т2. В противном случае соот­ветствующий столбец таблицы Т2 фактически не будет иметь имени (на самом деле при­сваивается имя, "зависящее от реализации"; см. [4.19], [4.22]). Рассмотрим некоторые дополнительные аспекты.

• Поскольку используется имя столбца именно таблицы Т2, а не Т1, представленное предложением AS имя не может употребляться в предложениях WHERE, GROUP BY и HAVING, включаемых непосредственно в конструкцию таблицы Т1. Однако на это имя можно ссылаться в предложении ORDER BY (в частности, при определении курсора в предложении DECLARE CURSOR), а также во "внешнем" выражении типа <та6личяое выражение>, которое содержит рассматриваемое выражение типа <выражение зы6орки> как вложенное.

• Если некоторый параметр <выбираешй элемент> включает вызов оператора обоб­щения и параметр <выражение выборкй> не включает предложение GROUP BY (см. ниже), то ни один параметр <вы6ираешй элемент> в предложении SELECT не может включать никаких ссылок на столбец таблицы Т1, кроме случаев, когда такая ссылка является аргументом (или частью аргумента) в вызове оператора обобщения.

Случай 2. Параметр <выбираемый элемент> принимает следующий вид.

г

[ <перемевяая диапазона> . ] *

Если уточнение опущено, т.е. элемент выборки <вы6яраемый элемент> представляет собой просто неуточненный символ "*", такой элемент выборки должен быть единствен­ным элементом выборки в предложении SELECT. Этот вид элемента выборки является сокращением для списка всех имен столбцов таблицы Т1 в порядке их следования слева направо. Если используется уточнение и параметр <выбираемый элемент> представляет собой символ "*", уточненный именем переменной кортежа R, т.е. "J?.*", то такой пара­метр представляет список имен столбцов для всех столбцов таблицы, соответствующей переменной кортежа R, в порядке их следования слева направо. (Напомним, что, как ука­зывалось в разделе 7.7, имя таблицы может использоваться и часто используется, как яв­ная переменная кортежа. Поэтому параметр <выбираетй элемент> чаще представляется в виде "Т.*", а не в виде "J?.*".)

Предложение FROM

Предложение FROM имеет следующий вид. FROM <список ссылок яа табляцы>

Параметр <список ссылок яа таблицы> не должен быть пустым. Пусть указанный список ссылается на таблицы А, В, ... С. Тогда результат вычисления предложения FROM будет представлять таблицу, которая равна декартову произведению таблиц Л, В,... С.

Замечание. Напомним, что декартово произведение одной таблицы Т совпадает с са­мой таблицей Т (см. упр. 6.12 в главе 6). Иначе говоря, в предложении FROM допускается наличие лишь одного параметра <ссылка на таблицуу.

Предложение WHERE

Предложение WHERE имеет следующий вид. WHERE <условное выражение>

Пусть таблица Т представляет собой результат вычисления непосредственно предше­ствующего предложения FROM. Тогда результат вычисления предложения WHERE является таблицей, производной от таблицы Т. Результирующая таблица формируется путем ис­ключения из таблицы Т всех строк, для которых вычисление выражения, заданного па­раметром <условное выражение>, дает ложь. Если предложение WHERE опущено, резуль­татом будет просто таблица Т.

Предложение GROUP BY

Предложение GROUP BY имеет следующий вид. GROUP BY <список имен столбцов>

Параметр <список имен столбцов> не должен быть пустым. Пусть таблица Т пред­ставляет собой результат вычисления непосредственно предшествующих предложений FROM и WHERE (если такие имеются). Каждый параметр <имя стол6ца>, указанный в предложении GROUP BY, должен являться именем столбца (необязательно уточненным) таблицы 2". Результат вычисления предложения GROUP BY представляет собой сгруп­пированную таблицу, т.е. множество групп строк, производных от строк таблицы Т, посредством ее концептуального переупорядочения в минимальное количество групп, в которых все строки имеют одно и то же значение для сочетания столбцов, опреде­ляемых предложением GROUP BY. Подчеркнем, что результат будет "ненастоящей таб­лицей", поскольку он представляет таблицу групп, а не таблицу строк. Однако пред­ложение GROUP BY никогда не используется без соответствующего предложения SELECT, назначение которого заключается в получении настоящей таблицы (т.е. таблицы строк) из таблицы групп, так что такое временное отклонение от реляци­онных правил является лишь небольшим изъяном.

Если параметр <выражение выборки> включает предложение GROUP BY, то на вид соответствующего предложения SELECT накладываются определенные ограничения. А именно, каждый параметр <вы6ираемый элементу в предложении SELECT, включая лю­бой элемент, который подразумевается под сокращением "*", должен принимать единственное значение в пределах каждой группы. Поэтому параметры <выбираемый элементу не должны включать никаких ссылок на столбцы таблицы Т, которые не указаны в самом предложении GROUP BY, за исключением такой ссылки, ко­торая представляет собой аргумент, или часть аргумента, в вызове оператора обобще­ния (поскольку в результате такого вызова некоторое множество скалярных значений в группе сводится к одному скалярному значению).

Предложение HAVING

Предложение HAVING имеет следующий вид. HAVING <условное выражение>

Пусть G— сгруппированная таблица, полученная в результате вычисления непосредст­венно предшествующих предложений FROM, WHERE (если оно задано) и GROUP BY (если они заданы). Если предложение GROUP BY не указано, то таблица G будет результатом вычисле­ния только предложений FROM и WHERE и будет рассматриваться как сгруппированная таб­лица, которая содержит ровно одну группу⁵. Другими словами, в этом случае имеется не­явное концептуальное предложение GROUP BY, в котором не указано никаких группируемых столбцов. Результат вычисления предложения HAVING является таблицей, производной от таблицы G путем исключения всех групп, для которых вычисление выражения, заданного параметром <условное выражениё>, дает в результате значение ложь.

Приведем некоторые особенности использования предложения HAVING.

• Если предложение HAVING опущено, а предложение GROUP BY указано, результатом будет просто таблица G. Если оба предложения, HAVING и GROUP BY, опущены, ре­зультатом будет просто "настоящая", т.е. не сгруппированная, таблица Г, которая будет получена в результате вычисления предложений FROM и WHERE.

• Любое выражение типа <скалярное выражение> в предложении HAVING должно иметь одно значение в группе (как и скалярное выражение в предложении SELECT, если имеется предложение GROUP BY).

Подробный пример

В заключение нашего обсуждения выражений типа <выражение вмборки> рассмотрим достаточно сложный пример. С его помощью будут проиллюстрированы некоторые (но отнюдь не все) особенности, объяснявшиеся выше. Сформулируем запрос: "Для каждой красной и синей demaiu, которых в сумме поставлено более 350 штук (исключая из всех поставок demaiu, количество которых меньше ши равно 200 штук), определить номер, вес в граммах, цвет и максимальное количество ". Приведем возможную формулировку этого запроса на языке SQL.

SELECT P.Pi,

'Вес в граммах =' AS ТЕХТ1, P.WEIGHT * 454 AS GMWT, P.COLOR,

'Максимальное количество =' AS TEXT2,

MAX ( SP.QTY ) AS MXQTY FROM P, SP WHERE P.Pi = SP.Pi

AND { P.COLOR = 'Red' OR P.COLOR = 'Blue' )

AND SP.QTY > 200

GROUP BY P.Pi, P.WEIGHT, P.COLOR

HAVING SUM ( SP.QTY ) > 350 ;

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

1. FROM. Вычислив предложение FROM, получим новую таблицу, которая является де­картовым произведением таблиц Р и SP.

2. WHERE. Результат выполнения шага 1 преобразуется путем исключения всех строк, ко­торые не удовлетворяют условию, указанному в предложении WHERE. В данном при­мере это строки, которые не удовлетворяют следующему условному выражению.

P.Pi = SP.Pi AND ( P.COLOR = 'Red' OR P.COLOR = 'Blue' )' AND SP.QTY > 200

3. GROUP BY. Результат выполнения шага 2 группируется по значениям столбцов, ко- торые указаны в предложении GROUP BY. В данном примере это столбцы Р.Р#, P.WEIGHThP.COLOR.

Замечание. Теоретически здесь для группирования было бы достаточно одного столбца Р.Pi, поскольку столбцы P.WEIGHT и P.COLOR имеют лишь одно значение для каждого номера детали, т.е. они функционально зависимы от номера детали. Однако язык SQL "не знает" об этом факте, и возникнет ошибка, если в предложе­нии GROUP BY столбцы P.WEIGHT и P.COLOR будут опущены, поскольку они упомя­нуты в предложении SELECT. (См. статью [10.6], где обсуждается этот вопрос.)

4. HAVING. Из результата выполнения шага 3 исключаются группы, которые не удов- летворяют заданному условному выражению.

SUM ( SP.QTY ) > 350

5. SELECT. Каждая образованная в результате выполнения шага 4 группа порождает одну итоговую строку, причем следующим образом. Во-первых, из группы извле- каются атрибуты "номер детали", "вес", "цвет" и "максимальное количество". Во- вторых, значение веса преобразуется в граммы по заданной формуле. В-третьих, в соответствующие места в строке вставляются две символьные строки: 'Вес в граммах =' и 'Максимальное количество ='. В отношении фразы "вставляются в соответствующие места в строке" заметим, что мы полагаемся здесь на принятую в языке SQL упорядоченность столбцов таблицы слева направо. Эти текстовые стро- ки потеряют всякий смысл, если не будут помещены в "соответствующие места".

Конечный результат будет подобен приведенному ниже.

Р#	ТЕХТ1	GMWT	COLOR	TEXT2	MXQTY
Р1	Вес в граммах —	5448	Red	Макс, количество =	300
Р5	Вес в граммах =	5448	Blue	Макс, количество =	400
РЗ	Вес в граммах =	7718	Blue	Макс, количество =	400

Не забывайте, что описанный выше алгоритм был приведен исключительно как кон­цептуальное объяснение того, как в языке SQL должно вычисляться выражение типа <выражение вы6орки>. Этот алгоритм, безусловно, корректен, в том смысле, что он га­рантирует получение правильного результата. Однако буквальное следование данному алгоритму при его реализации было бы неэффективным. Например, необходимо считать очень неудачным решением реальное вычисление в системе декартова произведения таблиц на шаге 1. Именно соображения, подобные приведенному, послужили причиной появления в реляционных системах оптимизаторов, обсуждавшихся в главе 17. Фактиче­ски основная задача оптимизатора в SQL-системе заключается в том, чтобы найти такую процедуру реализации, которая давала бы тот же результат, что и концептуальный алго­ритм, кратко описанный выше, но была бы эффективнее его.

А.З. Условные выражения

Подобно выражениям типа <та6личвое выражениеУ. выражения типа <условное выражениеУ используются в различных контекстах языка SQL, в частности в предложе­нии WHERE при определении требуемых или исключаемых строк для последующей обра­ботки⁶. В этом разделе будут рассмотрены некоторые наиболее важные особенности данного типа выражений. Заметим, однако, что здесь, разумеется, не ставилась задача исчерпывающе осветить этот вопрос. В частности, не рассмотрены особенности обра­ботки NULL-значений. Как указывалось в главе 18, если учитывать наличие NULL-значений, то для выражений типа <условвое выражение> потребуется существенно более расширенное толкование. Некоторые форматы условного выражения, которые не приво­дятся в этом приложении, относятся исключительно к аспектам, связанным с поддерж­кой NULL-значений. Однако данные аспекты обсуждались в главе 18.

Как и в предыдущем разделе, начнем с BNF-грамматики. Затем перейдем к обсужде­нию некоторых специфических случаев, а именно— параметров <условие like>, <условие match>, <условие all или апу> и <условие unique>, которые будут рассмот­рены более подробно (все другие случаи или обсуждались ранее в этой книге, или на­столько просты и понятны, что не требуют разъяснений).

<условное выражение> ::= <терм условияУ

| <условное выражениё> OR <терм условияУ

<терм условияУ

::= <фактор условия>

| <терм условияУ and <фактор условия>

<фактор условияУ

::= [ NOT ] <первичное условие>

<первичвое условие>

::= <простое условиёУ \ (<условное выражениеУ )

<простое условие»

<условие сравнения» <условие in> <условие Ике» <условие match> <условие all или апу> <условие exists> <условие unique>

<условие сравнения»

:;= <конструктор строки»

<оператор сравнения> <конструктор строкй>

<оператор сравнения>

-.:= = | < | <= | > | >= | о

<условие in>

::= <конструктор строки> [ NOT ] IN (<табличное выражениё> ) | <скалярное выражение> [ NOT ] IN

(<список скалярных выражение )

<условие like>

:: = <выражение из символьных строк> [ NOT ] LIKE <шаблон>

[ ESCAPE <исключения> ]

<условие match>

::= <конструктор строки» MATCH UNIQUE {<табличное выражение> )

<условие all или апу>

::= <конструктор строки>

<оператор сравнения» ALL (<табличное выражение» ) | <конструктор строки»

<оператор сравнения» ANY (<та6личное выражение» )

<условие exists>

::= EXISTS (<та6личное выражение» )

<условие unique»

::= UNIQUE (<та6личное выражение» )

Условие LIKE

Условия LIKE предназначены для простой проверки соответствия символьных строк заданному шаблону. Еще раз приведем синтаксис этого условия.

<выражение из символьных строк» [ NOT ] LIKE <шаблон»

[ ESCAPE <исключение> ]

Здесь параметр <ша6лон> представляет собой произвольное выражение наподобие символьной строки, а параметр <исключение> (если указана фраза ESCAPE) — выражение наподобие символьной строки, которое в результате вычисления дает единственный символ. Рассмотрим пример.

SELECT P.PI, P.PNAME FROM Р

WHERE P.PNAME LIKE 'C%';

Это сформулированный на языке SQL запрос "Определить номера и наименования деталей, назвавания которых начинаются с буквы С". Результат выполнения запроса представлен ниже.

р#	PNAME
Р5	Cam
Р6	Cog

Поскольку предложение ESCAPE не указано, символы в параметре <шаблон> интерпре­тируются так.

• Символ подчеркивания "_" задается для любого отдельного символа.

• Символ процента "4" устанавливается для любой последоватечьности из п симво­лов, где л может быть равно нулю.

• Все остальные символы представляют сами себя.

В данном примере по запросу будут возвращены строки из таблицы Р, для которых значение в столбце PNAME начинается с большой буквы "С", за которой следует произ­вольная последовательность символов (в количестве, большем либо равном нулю).

Приведем еще несколько примеров.

ADDRESS LIKE Дает результат истина, если в любом месте значения в столб-

' ^Berkley' _це ADDRESS содержится строка "Berkley"

SI LIKE 'S ' Дает результат истина, если значение в столбце St состоит

ровно из трех символов и первый символ — "S"

PNAME LIKE '%С ' Дает результат истина, если значение в столбце PNAME состоит

из четырех или более символов и последним трем предшест­вует символ "С"

MYTEXT LIKE '=_%' Дает результат истина, если значение в столбце MYTEXT начи-ESCAPE '=' нается с символа подчеркивания (см. ниже)

В последнем примере символ "=" указан как символ исключения, означающий, что специальное назначение для символов "I" и "_" может быть отменено, если им будет предшествовать символ "=".

И наконец отметим, что в предложении LIKE <условие like> условие вида

х NOT LIKE у [ ESCAPE Z ]

определяется как равносильное следующему.

NOT ( X LIKE у [ ESCAPE Z ] )

Условие MATCH

Параметр <условие match> имеет следующий формат. <конструктор строки» MATCH UNIQUE (<табличное выражение» )

Пусть rl — строка, которая получается в результате вычисления значения параметра <конструктор строки», и пусть Т— таблица, которая получается в результате вычисле­ния выражения в параметре <та6лйчное выражение». Тогда условие, определенное пара­метром <условие match>, будет истинным, если и только если таблица Г содержит ровно одну строку (скажем, г2), такую, что операция сравнения

rl = г2

дает для нее результат истина. Приведем пример.

SELECT SP.* FROM SP

WHERE NOT ( SP.Sf MATCH UNIQUE { SELECT S.Sf FROM S ) ) ;

Это сформулированный на языке SQL запрос "Найти поставки, которые выполнятся более чем одним поставщиком из таблицы поставщиков". Он может быть полезен при проверке целостности базы данных, поскольку, если база данных корректна, таких по­ставок, безусловно, не должно быть. Отметим, что для выполнения этой же проверки могло бы использоваться условие принадлежности (вхождения) <условие in>.

Кроме того, в фразе MATCH UNIQUE ключевое слово UNIQUE может быть опущено, но тогда фраза MATCH превратится в синоним фразы IN (по крайней мере, если не учитывать NULL-значения).

Условие ALL или ANY

Параметр <условие all или апу» имеет следующий общий синтаксис.

<конструктор строки» <оператор сравнения» <квалификатор>

(<табличное выражение» )

Здесь параметр <оператор сравнения» представляет любой оператор из обычного набора операторов сравнения (=, о и т.д.), а уточнение <квалификатор> может иметь значение ALL или ANY. В общем случае параметр <условие all или апу» принимает зна­чение истина, если и только если результат соответствующего сравнения при значении квалификатора ALL (либо ANY) является истиной для всех (соответственно для каких-нибудь) строк в таблице, определяемой значением параметра <таблнчное выражение». (Если таблица пуста, то условие ALL всегда дает значение истина, а условие ANY — зна­чение ложь). Приведем пример: "Определить наименования деталей, вес которых боль­ше, чем вес любой из голубых деталей".

SELECT DISTINCT PX.PNAME FROM P AS PX

WHERE PX.WEIGTH > ALL ( SELECT PY.WEIGTH

FROM P AS PY

WHERE PY.COLOR = 'Blue' ) ;

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

PNAME Cog

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

Замечание. Здесь уместно предупредить читателя, что при использовании параметра <условие all или апу> неискушенные пользователи часто делают ошибки. В формули­ровке предыдущего запроса на языке SQL было бы естественнее использовать ключевое слово "любой" (ANY) вместо "каждый" (ALL), что привело бы к (неверному) использова­нию сравнения > ANY вместо > ALL. Аналогичные замечания справедливы и для всех ос­тальных операторов сравнения с квалификаторами ANY и ALL.

Условие UNIQUE

Параметр <условие unique> используется для проверки, является ли каждая строка некоторой таблицы уникальной (т.е. не имеет ли дубликатов). Синтаксис этого условия следующий.

UNIQUE ( табличное выражение> )

Условие принимает значение истина, если в результате вычисления выражения, за­данного параметром <табличное выражение>, получается таблица, в которой все строки различны, и ложь — в противном случае.

А.4. Скалярные выражения

В языке SQL допустимые значения параметра <скалярное выражение> образуют достаточно типичный набор и вполне самоочевидны. Здесь мы ограничимся переч­нем наиболее важных операторов, которые могут быть использованы в конструкци­ях таких выражений, и дадим лишь несколько комментариев для операторов CASE и CAST, смысл которых, возможно, не совсем очевиден. Список операторов в алфавит­ном порядке выглядит так.

Арифметические операторы (+, -,

BIT_LENGTH

CASE

CAST

CARACTER_LENGTH Операция конкатенации (11) CURRENT USER LOWER

OCTETJLENGTH

POSITION

SESSION USER

SUBSTRING

SYSTEMJJSER

TRIM

UPPER

USER

Отметим, что обращение к оператору обобщения также может использоваться внутри значения параметра <скалярное выражение», поскольку такой оператор всегда возвра­щает скалярное значение. Более того, результат вычисления выражения, заданного пара­метром <табличное выражение» и заключенного в круглые скобки, также может считать­ся скалярным значением, поскольку в результате вычисления получается таблица ровно с одной строкой и одним столбцом.

Теперь рассмотрим операторы CASE и CAST.

Оператор CASE

Оператор CASE возвращают одно значение из указанного множества значений в зави­симости от заданного условия, как, например, показано ниже.

CASE

WHEN S.STATUS < 5 THEN 'Обращаться в крайнем случае'

WHEN S.STATUS < 10 THEN 'Сомнительный'

WHEN S.STATUS < 15 THEN 'He очень хороший'

WHEN S.STATUS < 20 THEN 'Посредственный'

WHEN S.STATUS < 25 THEN 'Приемлемый'

ELSE 'Отличный'

END

Оператор CAST

Оператор CAST преобразует заданное скалярное значение в указанный скалярный тип данного, как, например, показано ниже.

CAST ( P.WEIGHT AS FLOAT )

Не все пары типов данных взаимно преобразуемы. Например, не поддерживаются пре­образования между числами и битовыми строками. (См. публикацию [4.22], где подробно и точно описано, какие типы данных могут быть преобразованы и в какие именно типы.)

Приложение

Обзор языка SQL3

Б.1. Введение

Язык SQL3, возможно, будет утвержден как стандарт (SQL/99) приблизительно в то время, когда будет напечатана эта книга. Однако мы не стали ранее при его обсуждении основываться на версии SQL3 по причинам, которые указывались в главе 4, а также по­тому, что рассматриваем язык SQL3, мягко говоря, как какое-то недоразумение, как бы его ни защищали. С другой стороны, мы сочли необходимым включить в эту книгу обзор по крайней мере наиболее важных особенностей языка SQL3.

В языке SQL3, конечно, имеются все функциональные возможности, предусмотрен­ные стандартом SQL/92, за исключением некоторых второстепенных (ни одна из них в книге не рассматривалась), которые были исключены сознательно. К ним относятся: ключевое слово SQLCODE, целые без знака вместо имен столбцов в предложении ORDER BY, "представители" идентификаторов, некоторые множества символов, определяемые пользователем, а также сопоставления, преобразования и несколько других возможно­стей. Но по вполне понятным причинам основное внимание здесь будет уделено тем возможностям, которые были добавлены после 1992 года, и для удобства обсуждения под "языком SQL3" далее мы будем подразумевать именно эти возможности. Из них, не­сомненно, наиболее важными являются возможности, которые связаны с типами данных, определяемыми пользователем (мы рассмотрим их в разделах Б.2-Б.5). Самые важные из других возможностей будут представлены в разделе Б.6.

Замечание. Подробный анализ и критику по теме разделов Б.2-Б.5 можно найти в [3.3].

Прежде чем перейти к обсуждению непосредственно языка SQL3, необходимо ска­зать несколько слов о SQLJ [4.6]. Так неформально называют проект, в котором учиты­вается возможность определенной степени интеграции между языками SQL и Java (этот проект создается объединенными усилиями нескольких известных поставщиков СУБД). Часть 0 этого проекта связана с внедрением операторов языка SQL в программы на язы­ке Java. В части 1 исследуется идея обращения к программам на языке Java из среды SQL (например, вызов хранимых процедур, которые написаны на языке Java). А в части 2 ре­шается задача использования классов Java как типов данных языка SQL (например, в ка­честве основы для определения столбцов в SQL-таблицах). Ни один из этих замыслов формально не стал частью языка SQL3 как такового, но часть 0 проекта SQLJ уже была опубликована в виде первого компонента новой части 10 чернового варианта стандарта языка SQL [4.22] и, по-видимому, вскоре последуют части 1 и 2 проекта SQLJ (возможно, ко времени формального опубликования описания языка SQL3).

Также вероятно, что приблизительно в то же время появится новая версия интерфей­са SQL/CLI (см. главу 4).

Необходимо сделать несколько редакционных замечаний. Во-первых, в примерах книги и, в частности, этого приложения часто используется символ "I" в наименова­ниях столбцов, хотя на самом деле в языке SQL3 это не допускается. Также использу­ется точка с запятой ";" как символ завершения оператора. Во-вторых, необходимо подчеркнуть, что последующее изложение вопросов далеко не полное. И наконец, без­условно, в порядке вещей, что некоторые детали ко времени утверждения стандарта SQL3 могут измениться.

Б.2. Новые типы данных

Как указывалось в предыдущем разделе, все наиболее очевидные аспекты новизны в языке SQL3 связаны с типами данных⁷. Появились новые встроенные типы данных, точнее — новые встроенные скалярные типы данных, а также новые генераторы типов, которые в языке SQL3 называются конструкторами типа. Оператор CREATE TYPE по­зволяет пользователям определять собственные типы (конечно, имеется и соответст­вующий оператор DROP TYPE). Рассмотрим все эти возможности по порядку.

Встроенные скалярные типы данных

В языке SQL3 поддерживаются три новых скалярных типа данных.

■ BOOLEAN. Тип BOOLEAN — это, конечно, тип логических значений. Поддерживаются обычные логические операторы (NOT, AND, OR), а логические выражения могут ис­пользоваться, грубо говоря, везде, где обычно используются скалярные выраже­ния. Однако отметим, что в языке SQL предполагается три логических значения, а не два, как уже указывалось в главе 18. Этим значениям соответствуют литералы TRUE, FALSE и UNKNOWN. Тем не менее тип BOOLEAN включает только два значения, а не три. Неизвестное (UNKNOWN) логическое значение представлено — совершенно неправильно! — NULL-значением. Например, присвоение значения UNKNOWN пере­менной типа BOOLEAN на самом деле приведет к установке ее значения равным NULL. Чтобы понять, насколько это серьезная ошибка, можно поразмышлять об аналоге числового типа, который для представления нуля использовал бы NULL-значение вместо числа нуль.

Еще одна экстравагантность заключается в том, что в языке SQL3 (удивительно!) про­стая ссылка на логическую переменную не считается экземпляром того, что в прило­жении А называлось параметром <первичное условие». Таким образом, например, ес­ли переменная В относится к типу BOOLEAN, то предложение WHERE В недопустимо!

Наряду с типом BOOLEAN в языке SQL3 вводятся два новых оператора обобщения, EVERY (Каждый) — а не ALL (Все) по какой-то причине — и ANY (Любой). В обоих случаях аргумент представляет столбец значений типа BOOLEAN (почти наверняка производный столбец, как, например, в предложении WHERE ANY (QTY > 200)). Если столбец пустой, оба оператора возвращают значение неизвестно (или, правильнее, NULL-значение)⁸. Если столбец не пустой, то оператор EVERY возвращает значение истина, если каждое значение в столбце — истина, и значение ложь в противном случае; а оператор ANY возвращает значение ложь, если каждое значение в столб­це — ложь, и значение истина в противном случае. Как и для других операторов обобщения, NULL-значения перед выполнением операции исключаются.

• CL0B ("большой символьный объект"). Этот тип представляет собой символьную строку переменной длины, по существу, неограниченного размера. Сопутствую­щий механизм локатора аналогичен (до некоторой степени) привычному меха­низму курсора и позволяет иметь доступ к отдельным частям таких строк. Многие операторы обычных символьных строк не поддерживают подобные строки. Среди тех, которые все-таки поддерживают, — "=" и LIKE.

• BLOB ("большой двоичный объект"). Этот тип аналогичен предыдущему, но стро­ки являются строками "октетов", т.е., по сути, байтов, а не символов.

Генерируемые типы

В языке SQL3 имеются следующие генераторы типов: REF, ARRAY и ROW. Однако един­ственный способ определить "тип REF"— неявный, представляющий собой побочный эффект определения "структурированного типа" с помощью оператора CREATE TYPE (читайте далее этот раздел). Поэтому мы пока не будем его рассматривать. Что касается генераторов типов ARRAY и ROW, то они, по существу, вообще не могут быть определены как таковые (поскольку не существует специальных операторов CREATE ARRAY TYPE и CREATE ROW TYPE). Они могут использоваться только путем обращения к соответствую­щему генератору типа, "подключенному", например, к оператору CREATE TABLE. Приве­дем пример, в котором показано, как используется тип ARRAY.

CREATE TABLE SALES

( ITEM! CHAR(5),

QTY INTEGER ARRAY [12], PRIMARY KEY ( ITEMi ) ) ;

Здесь столбец QTY представляет значения-массивы, причем каждое значение QTY яв­ляется массивом из 12 элементов, каждый из которых имеет тип INTEGER.

Замечание, Массивы языка SQL ограничиваются одним измерением, и его элементы не могут быть, в свою очередь, массивами.

Ниже приведен пример запроса к определенной выше таблице SALES.

SELECT ITEMi FROM SALES WHERE QTY [3] > 100 ;

(Смысловое значение запроса — "Получить номера товаров, которые были проданы в марте в количестве, превышающем 100 единиц".) Далее следует пример вставки строки.

INSERT INTO SALES ( ITEMI, QTY ) VALUES ( 'X4320',

ARRAY [ 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0 ] ) ;

(Обратите внимание на использование литерала массива.)

Типы ROW аналогичны, как, например, показано ниже.

CREATE TABLE CUST

( CUST i CHAR(3), ADDR ROW ( STREET CHAR(50), CITY CHAR(25), STATE CHAR(2), ZIP CHAR(5) ) PRIMARY KEY ( CUSTt ) ) ;

Пример запроса выглядит следующим образом.

SELECT CUSTi FROM CUST

WHERE ADDR.STATE = 'CA' ;

Далее приведен пример вставки строки.

INSERT INTO CUST ( CUSTi, ADDR )

VALUES ( '001', ROW ( '1600 Pennsylvania Ave.',

'Washington', 'DC', '20500' ) ) ;

Типы DISTINCT

С помощью нового оператора CREATE TYPE создается тип, определяемый пользова­телем. К нему относится или тип DISTINCT, или структурированный тип (отметим, кста­ти, что генерируемые типы — см. предыдущий раздел — не считаются "типами, опреде­ляемыми пользователями", в том же смысле). В данном подразделе будет рассматри­ваться только тип DISTINCT. Название типа DISTINCT, переводимое как "отдельный", здесь пишется прописными буквами, чтобы подчеркнуть, что это слово используется не в его обычном смысле. Тип DISTINCT ограничивается специальным случаем типа, опре­деляемого пользователем. В частности, его физическая реализация должна включать ровно один из встроенных скалярных типов. Ниже приводится синтаксис для определе­ния типа DISTINCT.

CREATE TYPE <имя типа>

AS <имя встроенного скалярного тнпа> FINAL [ <режим приведения» ] [ <список спецификаций методов» ] ;

Пример определения подобного пользовательского типа приведен ниже. CREATE TYPE WEIGHT AS NUMERIC (5,1) FINAL ; Пояснения

1. Тип WEIGHT наследует операторы сравнения, которые применяются к основному типу, т.е. к типу NUMERIC. Однако отметим, что значения типа WEIGHT сравнимы с другими его значениями и больше с никакими. Таким образом, если WT — SQL-переменная типа WEIGHT, следующее сравнение недопустимо.

WT > 14.7

Однако, если в параметре <режим приведение указаны соответствующие опции приве­дения (детали здесь не уточняются), следующие сравнения уже будут допустимыми.

WT > CAST ( 14.7 AS WEIGHT ) CAST ( WT AS NUMERIC ) > 14.7

Более того, два предыдущих обращения к преобразованию CAST могут быть приве­дены к виду WEIGHT (14.7) и NUMERIC (WT) соответственно.

Замечание. Имена функций WEIGHT и NUMERIC здесь указываются определителем типа (в параметре <режим приведение). Они не подразумеваются именем типа, ко­торый был определен, или именем их основного типа.

2. Аналогичные замечания применимы и к операции присвоения, т.е. значение типа WEIGHT может быть присвоено только результату типа WEIGHT и никакому другому.

3. Тип WEIGHT автоматически не наследует другие операторы от основного типа. Од­нако определение метода в параметре Спецификация метода> (ни один пример не приведен) позволяет определяющему тип пользователю определить "методы" (см. следующий подраздел), которые применимы к значениям и переменным типа WEIGHT. Можно, например, определить функцию ADDW, которая складывает два веса, получая третий. Поэтому пользователь может написать такие выражения.

ADDW ( WT1, WT2 )

ADDW ( WT1, WEIGHT ( 14.7 ) )

4. В определении типа должна присутствовать спецификация FINAL (см. следующий подраздел).

Структурированные типы

Еще один вид типа, определяемого пользователем, — структурированный тип. Ниже представлены два примера³.

CREATE TYPE POINT AS ( X FLOAT, Y FLOAT ) FINAL ;

CREATE TYPE LINESEG AS ( BEGIN POINT, END POINT ) FINAL ; Пояснения

1. Говорят, что тип POINT имеет атрибуты X и Y (не путайте с атрибутами кортежей и от­ношений, которые определялись в части II этой книги). Аналогично тип LINESEG также имеет атрибуты BEGIN и END. Атрибут может относиться к любому известному типу.

2. К сожалению, атрибуты, которые указаны в определении структурированного типа, представляют физическую реализацию его значений, а не "возможное представле­ние" в смысле главы 5. Поэтому, например, точки BEGIN POINT и END POINT будут физически реализованы в терминах их декартовых координат.

3. Определение каждого атрибута автоматически приводит к определению одного оператора считывания— наблюдателя (проще говоря, оператора "get" — "получить") и одного оператора изменения —мутатора (проще говоря, оператора

На самом деле второй пример неверный, поскольку BEGIN и END— это зарезервированные слова.

"set" — "установить"), для которых используется синтаксис уточнения с помощью точки⁹. Пусть, например, Z, Р и LS— SQL-переменные типов FLOAT, POINT и LINESEG соответственно. Тогда допустимы следующие выражения.

Р.Х /* Получить значение компонента X точки Р */

LS.BEGIN.X /* Получить значение компонента 1*1

I* точки BEGIN сегмента линии LS */

SET Р.Х = Z ; /* Установить значение Z для */

/* компонента X точки Р */

SET LS.BEGIN.X = Z ; /* Установить значение Z для */

/* компонента X точки BEGIN */ /* сегмента линии LS */

4. Поскольку какие-либо дополнительные операторы не были определены, из других операторов для этих типов допустимы лишь операторы сравнения на равенство и операторы присвоения, которые допустимы для всякого типа. В частности, отме­тим, что "операторы-селекторы" типов POINT и LINESEG (в смысле главы 5) не оп­ределяются автоматически, поэтому нет и литералов типов POINT и LINESEG.

5. Уточнение FINAL означает, что любая попытка определить другой тип как собст­венный подтип любого из этих типов приведет к ошибке (см. раздел Б.З). Иначе го­воря, оба эти типа — листовые и будут такими оставаться всегда.

6. Являются ли типы POINT и LINESEG (или структурированные типы вообще) "инкапсулированными"? К сожалению, ответ на этот вопрос зависит от контекста. Например, если структурированный тип используется как тип некоторого столбца, ответ будет "Да" (пожалуй). Однако, если он используется как тип некоторой таб­лицы (см. раздел Б.4), конечно, ответ будет "Нет ".

Замечание. В первом случае добавление "пожалуй" означает, что даже в этой ситуа­ции операторы "получить" ("get") и "установить" ("set"), по существу, предоставляют атрибуты данного типа (как уже указывалось) и не могут быть замещены. Возможно, для первого случая уместно использовать термин "псевдоинкапсулированные типы" или псевдоскаляры.

Приведем общий синтаксис для определения структурированного типа, который не является каким-либо подтипом (см. раздел Б.З, где рассматривается случай определения подтипов).

CREATE TYPE <имя mna>

AS ( <список определений атрибутов» ) [ реализация ссылочного типа» ] [ [ NOT ] INSTANTIABLE ]

[ NOT ] FINAL [ <список спецификаций методов» ] ;

Пояснения

1. Параметр <список определений атрибутов> не должен быть пустым,

1. Необязательный параметр <реализация ссылочного типа> подробно обсуждается в разделе Б.4.

2. Уточнение NOT INSTANTIABLE означает, что тип является фиктивным типом в смысле главы 19. По умолчанию заданным считается уточнение INSTANTIABLE.

3. Уточнение NOT FINAL означает, что тип может иметь собственные подтипы; в про­тивном случае используется уточнение FINAL.

4. К значениям и переменным данного структурированного типа Т применяются сле­дующие операторы.

а) Наблюдатели и мутаторы атрибутов, уже описанные выше.

б) Операторы присвоения "=" и, возможно, сравнения "<" (оба оператора опреде- ляются с помощью отдельного оператора CREATE ORDERING FOR Т, хотя зачем требуется упорядочение, если нужно просто определить оператор присвоения "=", не совсем понятно).

в) Процедуры и функции, которые определяются, чтобы получить параметр типа Г (или любой из его собственных подтипов; см. раздел Б.З).

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

Замечание. Здесь под методами подразумеваются методы в традиционном объект­ном смысле (см. главу 24), т.е. они являются операторами, которые рассматривают один параметр как специальный. Если метод М определен для типа Т и X— выра­жение типа Т, то специальный синтаксис точечного уточнения Х.М используется для вызова метода N для объекта X. (Здесь для простоты подразумевается, что ме­тод М никаких других параметров не имеет.)

В параметре спецификация метода> задаются "определения сигнатур" метода в смысле глав 19 и 24. Однако они также включают многое другое, что относится к реали­зации и, по мнению автора, здесь неуместно. Реальный код, реализующий методы, опре­деляется в другом месте.

Б.З. Наследование типов

В языке SQL3 поддержка наследования типов не полностью ортогональна, поскольку применяется только к структурированным типам, т.е. не поддерживается наследование типов для типов встроенных, генерируемых¹⁰ и типов DISTINCT. Кроме того, совсем не поддерживается множественное наследование типов. В этом разделе будет рассмотрено только наследование для "псевдоскалярных" структурированных типов, которое может считаться реализованным более или менее удовлетворительно. Обсуждение наследова­ния нешкапсулированных структурированных типов откладывается до раздела Б.5.

Перечислим самые существенные различия между моделью наследования типов, которая была представлена в главе 19, и наследованием "псевдоскалярных" типов в языке SQL3.

• В языке SQL3 поддерживаются структурное наследование, а также наследование поведения.

• В языке SQL3 неверно различаются значения и переменные, и поэтому, в частно­сти, не различаются заменимость значений и заменимость переменных.

• В языке SQL3 нет поддержки ограничений типа, и поэтому также нет поддержки специализации посредством ограничения.

• В языке SQL3 требуется, чтобы операторы обновления ("мутаторы") наследова­лись безусловно.

Вследствие этих различий в языке SQL3 допускаются "некруглые окружности" и дру­гие несуразности, которые обсуждались в главе 19. Кроме того, некоторые операции сравнения в языке SQI .3 в результате дают значение ложь, когда они должны бы давать значение истина (поскольку, например, значение менее конкретного типа ELLIPSE может иметь равные полуоси и, значит, соответствовать окружности в обычном понимании).

Ниже приводятся примеры описания типов эллипсов и окружностей на языке SQL3.

CREATE TYPE ELLIPSE

AS { A LENGTH, В LENGTH, CTR POINT ) NOT FINAL ;

CREATE TYPE CIRCLE UNDER ELLIPSE

AS ( R LENGTH ) - нереалистично! (см. ниже)

NOT FINAL ;

Однако отметим, что в этих определениях физической реализации типа CIRCLE исполь­зуются четыре компонента-— А, В и CTR (наследуемые от типа ELLIPSE) и R (указываемый только для типа CIRCLE). Для любой данной окружности, конечно, три из этих компонентов будут иметь одинаковые значения. В качестве альтернативы вместо атрибута R можно оп­ределить метод R для типа CIRCLE. Тогда тип CIRCLE будет иметь ту же физическую реали­зацию, что и тип ELLIPSE, и эта реализация будет менее избыточна. С другой стороны, если С — переменная объявленного типа CIRCLE, присвоение C.R будет допустимо в первом из этих проектов, но не допустимо во втором. И опять же, присвоение C.R, если оно поддер­живается, будет, вообще говоря, давать такую "окружность", что С .R Ф С.А!

Ниже перечислены некоторые особенности в различии между моделью наследования типов, описанной в главе 19, и наследованием, которое поддерживается в языке SQL3.

• В языке SQL3 используется термин "direct" в понятии direct subtype для обозначе­ния прямого непосредственного подтипа вместо более соответствующего случаю термина "immediate".

• В языке SQL3 вместо термина "корневой тип" используется термин "максимальный супертип".

• В языке SQL3 поддерживается оператор TREAT (аналог оператора TREAT DOWN). Например, в этом языке аналогом выражения TREAT_DOWN_AS_CIRCLE(E) будет выражение TREAT Е AS CIRCLE.

■ В языке SQL3 также имеется оператор, который можно рассматривать как опера­тор TREAT UP, Приведем, например, следующую формулировку оператора.

МЕЛ ( С AS ELLIPSE )

Уточнение AS ELLIPSE обеспечивает вызов версии ELLIPSE для оператора AREA, даже если объявленный тип переменной С будет CIRCLE.

Замечание. Этот оператор может использоваться лишь в определенном контексте, " а именно -— для операции TREAT UP по отношению к аргументу при вызове неко­торого оператора, определенного пользователем, как в данном примере. Нужно сказать, что обеспечение такой функциональности, похоже, приводит к некоторой путанице между вопросами модели и реализации, ведь пользователи не должны даже знать, что существуют две версии оператора AREA.

• В языке SQL3 также поддерживается метод вида X.SPECIFICTYPE, который воз­вращает наиболее конкретный тип своего аргумента X как символьную строку.

• В языке SQL3 аналоги операторов вида IS_T(X) и IS_MS_rj^) выглядят следую­щим образом.

x IS OF j т )

X IS OF ( ONLY T )

Б.4. Ссылочные типы

Напомним, что, как утверждалось в главе 24, в объектных системах есть лишь одна хорошая идея, а именно — надлежащая поддержка типов данных (или две идеи, если считать наследование типа отдельно). Как видим, в язык SQL3 включены некоторые из этих "хороших" функциональных возможностей, хотя их поддержке еще далеко до со­вершенства. Однако, к сожалению, в язык SQL3 включены и связанные с ними возмож­ности, которые, по нашему убеждению, очень плохие. Фактически язык SQL3 довольно близко подошел к возможности допустить и первую грубейшую ошибку (приравнивание таблиц и классов), и вторую грубейшую ошибку (смешивание указателей и таблиц). Так­же необходимо сказать, что "оправдания" для выбора такого подхода не совсем понятны, по крайней мере автору; в сущности, они представляют собой лишь некую неясную идею о том, что рассматриваемые возможности каким-то образом делают язык SQL3 более "объектно-подобным".

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

CREATE TYPE DEPT TYPE AS ( DEPTi CHAR(3), DNAME CHAR(25), BUDGET MONEY ) REF IS SYSTEM GENERATED... ;

CREATE TABLE DEPT OF DEPTJTYPE

{ REF IS DEPT ID SYSTEM GENERATED, PRIMARY KEY~( DEPTI ), UNIQUE ( DEPT_ID ) )... j

Пояснения

1. Для данного определения структурированного типа Т система автоматически гене­рирует связанный ссылочный тип ("REF-тип"), обозначаемый как REF( Г). Значения типа REF (Т) представляют собой "ссылки" на строки типа Т в базовой таблице¹¹, ко­торая определена как таблица, "относящаяся к" ("OF") типу Т (см. п. 3). Замечание. Тип Т, конечно, может быть использован и в другом контексте, напри­мер как объявленный тип для некоторой переменной V или некоторого столбца С. Однако никакие значения REF (Т) не связаны с другими такими его применениями.

2. Предложение REF IS SYSTEM GENERATED в операторе CREATE TYPE означает, что ре­альные значения связанного REF-типа предоставляются системой. Может исполь­зоваться и другая опция REF IS USER GENERATED, но здесь она рассматриваться не будет. Опция REF IS SYSTEM GENERATED применяется по умолчанию.

3. Базовая таблица может быть определена (с помощью оператора CREATE TABLE) как таблица, "относящаяся к" некоторому структурированному типу. Однако ключевое слово OF здесь не совсем подходит, поскольку ни таблица в целом, ни даже отдель­ные ее строки на самом деле не "относятся к" рассматриваемому типу¹². В частно­сти, для таблицы могут быть определены дополнительные столбцы вдобавок к "столбцам" (или, скорее, к атрибутам) самого структурированного типа. Фактиче­ски должен быть указан по крайней мере один дополнительный столбец, а имен­но— столбец подходящего REF-типа. Синтаксис для определения такого столб­ца — это не обычный синтаксис для определения столбца, который выглядит так. REF IS <имя столбца» SYSTEM GENERATED

Дополнительный столбец используется для размещения уникальных идентифика­торов ("ссылок") для строк данной базовой таблицы (подразумевается уточнение UNIQUE (<имя столбца»), хотя оно может указываться и явно, как в нашем приме­ре). Идентификатор присваивается для данной строки, когда она вставляется, и ос­тается связанным с этой строкой¹³, пока она не будет удалена.

Замечание. Повторение уточнения SYSTEM GENERATED, конечно, необходимо. (Возможно, это покажется странным, но генерируемый системой столбец может быть целевым столбцом в операциях INSERT и UPDATE, хотя и используется по особым соображениям. Подробности здесь не рассматриваются.) Но непонятно, почему тре­буется определять таблицу как "относящуюся к" некоторому структурированному типу вместо того, чтобы просто определить соответствующий столбец обычным спо­собом и обеспечить функциональные возможности "уникального идентификатора".

4. Как отмечалось в разделе Б.2, структурированный тип, например DEPTJTYPE, не рассматривается в качестве инкапсулированного, если он используется как основа для определения базовой таблицы, несмотря на то что считается (в определенной степени) таковым во всех других контекстах. Поэтому в данном примере базовая таблица DEPT имеет четыре столбца, а не два, как это было бы, если бы тип DEPT TYPE был инкапсулированным.

5. Столбец DEPTi был описан как первичный ключ для таблицы DEPT. Однако, если строки таблицы DEPT имеют уникальные идентификаторы ("ссылки"), эти идентификаторы могли бы при желании использоваться в качестве значения первичного ключа.

CREATE TABLE DEPT OF DEPTJTYPE

( REF IS DEPT_ID SYSTEM GENERATED, PRIMARY KEY ( DEPT_ID ), UNIQUE { DEPTi ) )... ;

Теперь расширим пример, представив базовую таблицу ЕМР следующего вида.

CREATE TABLE ЕМР

( EMPi CHAR(5), ENAME CHAR(25), SALARY MONEY,

DEPT ID REF ( DEPTJTYPE ) SCOPE DEPT REFERENCES ARE CHECKED ON DELETE CASCADE, PRIMARY KEY ( EMPI ) >... ;

Обычно базовая таблица EMP включает в качестве внешнего ключа столбец DEPTI, который ссылается на отделы с помощью номеров отделов. Здесь, однако, в качестве "ссылочного" столбца используется столбец DEPT ID, который неявно объявлен в качестве столбца внешне­го ключа и который ссылается на отделы с использованием значений "ссылок". Предложение SCOPE DEPT указывает соответствующую таблицу для ссылок. Предложение REFERENCES ARE CHECKED означает, что поддерживается контроль целостности; опция REFERENCES ARE NOT CHECKED допускает наличие "висящих ссылок" (непонятно, зачем кому-либо когда-либо может потребоваться указывать такую опцию). Опциями ON DELETE... задаются правила удаления, аналогичные обычным правилам удаления внешнего ключа (поддерживаются те же самые опции). Однако отметим, что если это в действительности будет случай, когда столбец DEPT_ID в базовой таблице DEPT не может быть обновлен (см. п. 3 приведенного выше переч­ня), то не требуется никакого соответствующего правила ON UPDATE.

Теперь рассмотрим несколько примеров запросов в этой базе данных. Вот формулиров­ка на языке SQL3 запроса "Получить номера отделов для служащего с номером ' ЕГ ".

SELECT EX.DEPT_ID -> DEPTi AS DEPTi

FROM EMP EX

WHERE EX.EMPi = 'El' ;

Обратите внимание на операцию разыменовывания¹⁴ в предложении SELECT (выражение EX.DEPT_ID —* DEPTi возвращает значение DEPTI из строки DEPT, на кото­рую указывает данное значение идентификатора DEPT_ID). Также обратите внимание, что спецификация AS здесь в определенной степени необходима (если бы она была опущена, результирующий столбец был бы задан с именем, "зависящим от реализации"). И нако­нец, отметим интуитивно непонятный характер построения предложения FROM— полу­чаемое значение DEPTi извлекается из DEPT, а не из ЕМР, но значение DEPT_ID извлекается из ЕМР, а не из DEPT.

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

Кстати сказать, если бы запрос был сформулирован как "Получить отдел (вместо просто номера отдела) для служащего с номером 'Е1'", операция разыменовывания бы­ла бы совсем иной.

SELECT DEREF (EX.DEPT_ID ) AS DEPT

FROM EMP EX

WHERE EX.EMPi = 'El' ;

Более того, вызов операции DEREF возвращал бы не значение строки, а "инкапсу­лированное" (скалярное) значение.

Вот еще один пример: "Получить номера служащих, работающих в отделе 'D1'" (обратите внимание на разыменовывание в предложении WHERE).

SELECT EX.EMPi FROM EMP EX

WHERE EX.DEPTJD -> DEPTi = 'Dl' ;

Ниже приводится пример операции INSERT (вставка сведений о некотором служащем).

INSERT INTO ЕМР ( EMPi, DEPT_ID )

VALUES ( 'E5', ( SELECT DX.DEPT_ID FROM DEPT DX WHERE DX.DEPTi = 'D2' ) ) ;

Б.5. Подтаблицы и супертаблицы

Рассмотрим следующие структурированные типы (описывающие служащего и про­граммиста).

CREATE TYPE EMP_TYPE

AS ( EMPi ...7 DEPTi ... ) REF IS SYSTEM GENERATED NOT FINAL ... ;

CREATE TYPE PGMR TYPE UNDER EMP_TYPE AS { LANG ... J NOT FINAL ... ;

Заметим, что определение типа PGMR_TYPE не имеет предложения REF IS .... Вместо этого оно фактически наследует такое предложение от своего непосредственного супертипа EMP_TYPE.

Теперь рассмотрим следующие определения базовых таблиц.

CREATE TABLE ЕМР OF ЕМР TYPE

( REF IS EMP ID SYSTEM GENERATED, PRIMARY KEY ( EMPi ), UNIQUE { EMP_ID ) ) ;

CREATE TABLE PGMR OF PGMR_TYPE UNDER EMP ;

Обратите внимание на спецификацию UNDER ЕМР в определении базовой таблицы PGMR (также обратите внимание на отсутствие спецификаций REF IS PRIMARY KEY и UNIQUE для этой базовой таблицы). Такие базовые таблицы, как PGMR и ЕМР, называются подтаблицей и соответствующей непосредственной супер­таблицей. Таблица PGMR наследует столбцы таблицы ЕМР и имеет один дополни­тельный собственный столбец LANG. Интуитивно в этом примере утверждается, что не программист имеет лишь некоторую строку в таблице ЕМР, а программист имеет строку в обеих таблицах, поскольку каждая строка в таблице PGMR имеет эквивалент в таблице ЕМР, но обратное неверно.

Операции обработки данных для этих таблиц выполняются следующим образом.

■ Операция SELECT. Для таблицы ЕМР операция SELECT выполняется так, как обычно, а для таблицы PGMR -— как будто в этой таблице PGMR действительно содержатся столбцы таблицы ЕМР и столбец LANG.

Замечание. Уточнение ONLY может использоваться в параметре <ссылочная таблица> для исключения строк, которые имеют эквиваленты в некоторой подтаблице данной таблицы. Поэтому, например, операция SELECT ... FROM ONLY ЕМР выполняется так, как будто в таблицу ЕМР включе­ны только строки, которые не имеют эквивалентов в таблице PGMR.

• Операция INSERT. Для таблицы ЕМР операция INSERT выполняется так, как обычно. В результате ее выполнения для таблицы PGMR новые строки вставляются в обе таблицы, PGMR и ЕМР.

• Операция DELETE. При выполнении операции DELETE для таблицы ЕМР удаляются строки из таблиц ЕМР и (если эти строки соответствуют программистам) PGMR. Удаление строк из таблицы PGMR приводит к удалению строк из обеих таблиц.

• Операция UPDATE. Обновление столбца LANG, обязательно через таблицу PGMR, приводит к обновлению лишь таблицы PGMR. Обновления других столбцов через таблицу PGMR или ЕМР приводят к обновлению обеих таблиц (концептуально).

Укажем на некоторые следствия из предыдущих правил.

• Предположим, что служащий 'Joe' стал программистом. Если просто вставить строку для 'Joe' в таблицу PGMR, система попытается вставить строку для 'Joe' также в таблицу ЕМР, что, конечно, приведет к ошибке. Вместо этого необходимо удалить строку служащего 'Joe' из таблицы ЕМР, а затем вставить соответствую­щую строку в таблицу PGMR.

• И наоборот, предположим, что служащий 'Joe' перестал быть программистом. На этот раз необходимо удалить строку ' Joe' из таблицы ЕМР или PGMR (какую бы таблицу мы ни указали, в результате строки будут удалены из обеих таблиц). За­тем нужно вновь вставить соответствующую строку в таблицу ЕМР.

А что делать с наследованием типа? Насколько мы можем судить, ответ на этот во­прос — "Ничего", т.е. ничего, кроме того (по соображениям, которые непонятны), что язык SQL3 требует, чтобы подтаблица и ее непосредственная супертаблица были опре­делены через структурированные типы, которые являются подтипом и его непосредст­венным супертипом соответственно. Подчеркнем, что никакой заменимости эта схема не включает и, кроме того, рассматриваемые типы, совершенно определенно, не "инкапсулированы".

Итак, насколько привлекательны для нас подтаблицы и супертаблицы? Ответ, по-видимому, будет "Слегка", по крайней мере на уровне модели™. Действительно, опре­деленная экономия в реализации может быть достигнута, если подтаблица и супертаблица физически хранятся как одна таблица на диске. Но такие соображения, безусловно, никак не должны влиять на модель как таковую. Другими словами, непо­нятно не только, как указывалось в предыдущем абзаце, почему "под- и супертабли­цы" должны зависеть от "под- и суперструктурированных" типов, но и зачем такая возможность вообще поддерживается.

Б.6. Другие возможности Создание таблиц

В языке SQL3 в предложении CREATE TABLE поддерживается опция LIKE, позволяю­щая скопировать некоторые или все определения новой базовой таблицы из некоторой существующей именованной таблицы (отметим, что именованная не означает возмож­ность указать произвольное табличное выражение вместо имени таблицы).

Табличные выражения

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

¹⁰ Вероятно, стоит напомнить, какой подход к этому вопросу мы считаем более предпоч­тительным: подход, в котором используются представления (см. пример в конце раздела 13.5).

WITH LONG_TERM_EMPS AS ( SELECT * FROM EMP

WHERE DATE_HIRED < DATE '1980-01-01' )

SELECT EMPf, { LONG_TERM_CT - 1 ) AS ♦ OF_FELLOW LONG_TERM_EMPS FROM LONG_TERM_EMPS AS LI,

( SELECT DEPTi, COUNT(*) AS LONG_TERM_CT

FROM LONG_TERM_EMPS

GROUP BY DEPTi ) AS L2 WHERE LI.DEPTi = L2.DEPTi ;

(Словесная формулировка запроса такова: "Для каждого служащего, который работа­ет в компании с 1979 года или ранее, получить номер служащего и количество других служащих в том же отделе".)

В языке SQL3 предложение WITH может быть использовано, в частности, для форму­лирования определенных рекурсивных запросов. Например, для данной таблицы PARENT_OF (PARENT, CHILD J следующий рекурсивный запрос возвращает все пары людей {а, Ь), таких, что а— предок Ь. Обратите внимание, что определение, которое вводит имя ANCESTOR_OF, включает ссылку на само имя ANCESTOR_OF.

WITH RECURSIVE ANCESTOR OF ( ANCESTOR, DESCENDANT ) AS ( SELECT PARENT, CHILD

FROM PARENT_0F

UNION

SELECT A.PARENT, P.CHILD

FROM ANCESTOR OF AS A, PARENT_0F AS P

WHERE A.CHILD = P.PARENT )

SELECT *

FROM ANCEST0R_0F

Условные выражения

В языке SQL3 предоставляется новое условие DISTINCT (не путайте с существующим условием UNIQUE; см. приложение А). Оно предназначено для проверки, являются ли две строки "различными". Пусть заданы две строки Left и Right. В них должно содержаться одно и то же количество, например п, компонентов. Пусть i-e компоненты строк Left и Right— Li и J?i (i = 1, 2, л) соответственно. Тип компонента Li должен быть совмес­тимым с типом компонента Ri. Тогда после вычисления выражения

Left IS DISTINCT FROM Right

будет получен результат ложь, если и только если для всех i либо выражение "Li = Ri" имеет значение истина, либо Li и Ri оба равны NULL-значениям. В противном случае возвращается истина. (Иначе говоря, строки Left и Right являются "различными", если и только если они не "дублируют" одна другую в смысле главы 18.) Отметим, что условие DISTINCT никогда не дает в результате значение неизвестно.

В языке SQL3 также предоставляется новое условие SIMILAR, которое (как и условие LIKE) служит для шаблонного сравнения символьных строк, т.е. с его помощью проверя­ется, удовлетворяет ли данная символьная строка некоторому заданному шаблону. Отли­чие заключается в том, что условие SIMILAR поддерживает более широкий диапазон воз­можностей ("символы-заменители" и т.п.) по сравнению с условием LIKE. Синтаксис этого условия следующий.

<выражение типа символьной строки» [NOT] SIMILAR ТО <шаблон>

[ ESCAPE <исключевие> ]

Здесь параметры <шаблон> и <исключение> по сути те же, что и в условии LIKE, но параметр <шаблон> может включать дополнительные специальные символы — не просто " " и "%", как в условии LIKE, а также "*", "+", "-" и многие другие. Общее их назначение заключается в поддержке правил анализа выражений, записанных на некотором фор­мальном языке.

Замечание. Стоит упомянуть, что правила для условия SIMILAR были скопированы с подобного оператора в языке POSIX.

В завершение этого подраздела отметим, что при наличии нового встроенного типа BOOLEAN условные выражения становятся просто скалярными выражениями специально­го вида (чем, впрочем, они и должны были быть всегда).

Целостность

В языке SQL3 поддерживается ограничение RESTRICT «ссылочное действие», кото­рое подобно, но не идентично опции NO ACTION (для уяснения различия обратитесь к главе 8). Также включена некоторая поддержка триггерных процедур (триггеров), в частности имеется оператор CREATE TRIGGER, которым определяется триггер — комби­нация определений события и действия.

Ш Событие — это операция INSERT, UPDATE (необязательно для указанных столбцов) или DELETE для указанной именованной таблицы.

■ Действие — это действие (фактически — процедура), которое будет выполнено AFTER (после) или BEFORE (до) обработки указанного события.

Точнее, действие состоит из необязательного условного выражения (по умолчанию равного истине) и SQL-процедуры, которая будет выполнена, если и только если усло­вие истинно, когда событие произойдет. Пользователь может указать, будет ли действие выполняться один раз, когда случается событие, или же один раз для каждой строки FOR EACH ROW таблицы, с которой данное событие связано. Более того, спецификации действия могут ссылаться на значения "до" и "после" в таблице, связанной с конкретным событием, предоставляя таким образом примитивный уровень поддержки для, помимо всего прочего, ограничений перехода.

Обновление представлений

В языке SQL3 расширена поддержка обновления представлений за счет включения представлений типа UNION ALL и представлений, определенных на базе соединений типа "один ко многим" и "многие ко многим". Аналогичные расширения имеются и для курсоров.

Управление транзакциями

В язык SQL3 включено несколько новых возможностей управления транзакциями.

• Использование явного оператора STMT TRANSACTION (с теми же операндами, что и у оператора SET TRANSACTION; см. главу 14)

• Использование опции WITH HOLD для оператора объявления курсора DECLME CURSOR (опять же, см. главу 14)

• Поддержка контрольных точек (см. аннотацию к [14.11])

Безопасность

В языке SQL3 поддерживаются привилегии выборки конкретных столбцов

(привилегии SELECT (х) позволяют их обладателю ссылаться на конкретный столбец х конкретной именованной таблицы в параметре <табличное выражевие>). Также поддер­живаются определяемые пользователем роли. В качестве примера можно привести роль ACCG, означающую любого сотрудника бухгалтерии. Однажды созданная роль может на­деляться привилегиями точно так, как если бы это был идентификатор пользователя. Бо­лее того, роли могут предоставляться, подобно привилегиям, и так же, как все привиле­гии, могут предоставляться или пользователю, или другой роли.

Отсутствующая информация

Здесь мы ограничимся лишь одним наблюдением. Использование возможностей но­вых типов в языке SQL3 (как и ожидалось) усложняется наличием NULL-значений. На­пример, пусть V— переменная некоторого структурированного типа Т. Тогда может быть так, что значение некоторого компонента переменной V равно NULL-значению (в этом случае условное выражение V = V вычисляется, как значение неизвестно), тем не менее условное выражение V IS NULL вычисляется, как ложь\ Фактически в общем слу­чае можно сказать, что если ((V = V) IS NOT TRUE) IS TRUE— истина, то или значе­ние У равно NULL-значению, или переменная V включает компонент, значение которого равно NULL-значению.

Поддержка принятия решений

В язык SQL3 включена поддержка опций GROUPING SETS, R0LLUP и CUBE для предло­жения GROUP BY, как было описано в главе 21.

Приложение

Сокращения и специальные символы

ACID	atomicity/consistency/	атомарность/согласованность/
	isolation/durability	изолированность/продолжительность
ACM	Association for Computing Machinery	Ассоциация по вычислительной технике
ADT	abstract data type	абстрактный тип данных
ANSI	American National Standards	Американский национальный институт
	Institute	стандартов
ANSI/SPARK	ANSI/Systems Planning and	Американский национальный институт
	Requirements Committee	стандартов/Комитет системного плани­рования и требований (упоминался в главе 2 в связи с трехуровневой архитек­турой систем баз данных)
ARIES	algorithm for recovery and	алгоритм восстановления и использую-
	isolation exploiting semantics	щей изоляцию семантики
BB	GB	то же самое, что гигабайт (Гбайт)
BCNF	Boyce/Codd normal form	нормальная форма Бойса-Кодда (НФБК)
BCS	British Computer Society	Британское компьютерное общество
BLOB	binary large object	большой двоичный объект
BNF	Backus-Naur form or Backus	форма Бэкуса-Наура или нормальная
	normal form	форма Бэкуса
CACM	Communications of the ACM	Средства коммуникации АСМ (издание
	(ACM publication)	АСМ)
CAD/CAM	computer-aided	автоматизированное проектирование/ ав-
	design/computer-aided	томатизированное производство
	manufacturing	(САПР/АСУТП)
CASE	computer-aided software	автоматизация разработки программного
	engineering	обеспечения
CDO	class-defining object	объект, определяющий класс
CIM	computer-integrated	автоматизированное интегрированное
	manufacturing	производство
CLI	Call-Level Interface	интерфейс уровня вызова (процедур)
CLOB	character large object	большой символьный объект
CNF	conjunctive normal form	конъюнктивная нормальная форма

CODASYL Conference on Data Systems Ассоциация по языкам систем данных;

Languages используется при ссылке на определенные

дореляционные системы, такие как IDMS CPU central processing unit центральный процессор (ЦП)

CS cursor stability (DB2) стабильность курсора (в СУБД DB2)

CWA Closed World Assumption допущение о замкнутости мира

DA data administrator администратор данных (АД)

DB/DC database/data communications база данных/передача данных

DBA database administrator администратор базы данных (АБД)

DBMS database management system система управления базой данных (СУБД)

DBP&D Database Programming & Программирование и проектирование

Design баз данных (журнал, в настоящее время

интерактивный)

DBTG Data Base Task Group группа задач баз данных; используется

взаимозаменяемо с CODASYL в контек­сте баз данных

DC data communications передача данных

DCO "domain check override" замещение проверки домена

DDB distributed database распределенная база данных

DDBMS distributed DBMS распределенная СУБД (РСУБД)

DDL data definition language язык определения данных (ЯОД)

DES Data Encryption Standard стандарт шифрования данных

DK/NF domain-key normal form доменно-ключевая нормальная форма

DML data manipulation language язык обработки данных (ЯОД)

DNF disjunctive normal form дизъюнктивная нормальная форма

DRDA Distributed Relational архитектура распределенных реляцион-

Database Architecture ных баз данных

DSL data sublanguage подъязык данных

DSS decision support system система поддержки принятия решений

DUW distributed unit of work распределенная часть работы

E/R entity/relationship "сущность/связь"

ЕВ exabyte (1024РВ) эксабайт (Ебайт); равен 1024 петабайт

(Пбайт)

EDB extensional database экстенсиональная база данных

EKNF elementary key normal form нормальная форма с элементарными

ключами

EMVD embedded MVD внедренная многозначная зависимость

FD functional dependence функциональная зависимость (ФЗ)

GB gigabyte (1024MB) гигабайт (Гбайт); равен 1024 мегабайт

(Мбайт)

GIS geographic information system географическая информационная система

HOLAP	hybrid OLAP
I/O	input/output
IDB	intensional database
IDMS	Integrated Database
	Management System
IEEE	Institute for Electrical and
	Electronics Engineers
IMS	Information Management
	System
IND	inclusion dependence
IS	intent shared lock;
	information system
ISBL	Information System Base
	Language
ISO	International Organization for
	Standardization
IT	information technology
IX	intent exclusive (lock)
JACM	Journal of the ACM (ACM
	publication)
JD	join dependence
JDBC	Java Database Connectivity
К	1024 (sometimes 1000)
KB	kilobyte (1024 bytes)
LAN	local area network
LOB	large object
MB	megabyte (1024 KB)
MLS	multi-level secure
MOLAP	multi-dimensional OLAP
MVD	multi-valued dependence
NCITS	National Committee on Infor-
	mation Technology Standards
NCITS/H2	NCITS database committee
NF2	"NF squeared" = NFNF = non
	first normal form (?)
ODBC	Open Database Connectivity
ODMG	Object Data Management
	Group

гибридная система OLAP ввод-вывод

интенсиональная база данных

интегрированная система управления ба­зой данных — одна из первых СУБД Институт инженеров электрики и элек­троники (США)

система управления информацией — од­на из первых СУБД включаемая зависимость разделяемая блокировка намерения; ин­формационная система язык баз информационных систем

Международная организация по стандар­тизации

информационная технология (ИТ) эксклюзивная блокировка намерения Журнал АСМ (издание АСМ)

зависимость соединения (ЗС) Java-интерфейс для установки связи с ба­зами данных 1024 (иногда 1000) килобайт (Кбайт); равен 1024 байт локальная сеть (ЛВС) большой объект

мегабайт (Мбайт); равен 1024 килобайт (Кбайт)

многоуровневая система защиты многомерные базы данных OLAP многозначная зависимость (МЗЗ) Национальный комитет по стандартам информационных технологий комитет по базам данных NCITS "NF-квадрат" = NFNF = не первая нор­мальная форма (?)

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

Группа управления объектными данны­ми (ODMG также называют предложе­ния группы: ODL, OQL и т.д.)

ODS	operational data store			операционное хранилище данных
OID	object ID			идентификатор объекта
OLAP	online analytic processing			оперативная аналитическая обработка
OLCP	online complex processing			оперативная комплексная обработка
OLDM	online decision management			оперативное управление решениями
OLTP	online transaction processing			оперативная обработка транзакций
OMG	Object Management Group			Группа управления объектами
OO	object-oriented; object			объектно-ориентированный; объектная
	orientation			ориентация (00)
OODB	object-oriented database			объектно-ориентированная база данных
OOPL	object-oriented programming			объектно-ориентированный язык про-
	language			граммирования
OQL	Object Query Language			объектный язык запросов (часть стан-
				дарта ODMG)
OSI	Open System Interconnection			открытый интерфейс взаимодействия
				систем
OSQL	"Object SQL"			"объектный SQL"
PB	petabyte (1024TB)			петабайт (Пбайт); равен 1024 терабайт
				(Тбайт)
PC	personal computer			персональный компьютер (ПК)
PJ/NF	projection-join normal form			нормальная форма проекции-соединения
PODS	Principles of Database Systems			принципы систем баз данных
PRTV	Peterlee Relational Test			экспериментальная реляционная систе-
	Vehicle			ма, разработанная в городе Питерли
PSM	Persistent Stored Modules			постоянные хранимые модули
QBE	Query-By-Example			запрос-по-образцу
QUEL	Query Language			язык запросов
RAID	redundant array of			надежный массив недорогих дисков
	inexpensive disks
RDA	Remote Data Access			удаленный доступ к данным
RDB	relational database			реляционная база данных
RDBMS	relational DBMS			реляционная СУБД
RID	(stored) record ID or row ID			(хранимый) идентификатор записи или
				идентификатор строки
ROLAP	relational OLAP			реляционная система OLAP
RM/T	relational model/Tasmania			реляционная модель/Тасмания
RM/V1	relational model/Version 1			реляционная модель/версия 1
RM/V2	relational model/Version2			реляционная модель/версия 2
RPC	remote procedure call			удаленный вызов процедур (протокол)
RR	repeatable read			повторяющееся чтение
RUW	remote unit of work			удаленная часть работы
RVA		relation-valued attribute	атрибут, значение которого — отношение
S		shared (lock)	разделяемая (блокировка)
SIGMOD		Special Interest Group on	Специальная группа по управлению дан-
		Management of Data (ACM	ными (специальная группа АСМ)
		special interest Group)
SIX		shared intent exclusive (lock)	эксклюзивная разделяемая блокировка
			намерения
SPARC		see ANSI/SPARC	см. ANSI/SPARC
SQL		Structured Query Language,	структурированный язык запросов, стан-
		Standard Query Language	дартный язык запросов
ТВ		terabyte (1024GB)	терабайт (Тбайт); равен 1024 гигабайт
			(Гбайт)
TCB		Trusted Computing Base	надежная вычислительная база
TCP/IP		Transmission Control	протокол управления переда-
		Protocol/Internet Protocol	чей/протокол Internet
TID		(stored) tuple ID	(хранимый) идентификатор кортежа
TOPS		Transaction on Database	Транзакции в системах баз данных
		Systems (ACM publication)	(издание АСМ)
TPC		Transaction Processing Council	Совет по обработке транзакций
и		update (lock)	(блокировка) обновления
UDT		user-defined type	тип, определяемый пользователем
UML		Unified Modeling Language	единый язык моделирования
unk		unknown (null)	неизвестное значение (NULL-значение)
UOW		unit of work	часть работы
VLDB		very large database; Very	очень большая база данных; Очень
		Large Data Bases (annual	большие базы данных (ежегодные кон-
		conference)	ференции)
VSAM		Virtual Storage Access Method	метод доступа к виртуальной памяти
WAL		write-ahead log	предварительная запись в журнал
WAN		wide area network	глобальные сети (ГВС)
WFF		well-formed formula	правильно построенная формула
WORM		write once/read many times	запись однажды/чтение многоразовое
WYSIWYG		what you see is what you get	что видите, то и получаете
X		exclusive (lock)	эксклюзивная, без взаимного доступа
			(блокировка)
X3		see NCITS	см. NCITS
X3H2		see NCITS/H2	см. NCITS/H2
INF		first normal form	первая нормальная форма (ШФ)
2NF		second normal form	вторая нормальная форма (2НФ)
2PC		two-phase commit	двухфазная фиксация (протокол)

2PL two-phase locking двухфазная блокировка

2VL two-valued logic двузначная логика

20C same as 2PC то же самое, что и 2РС

20L same as 2PL то же самое, что и 2PL

3GL third generation language язык (программирования) третьего поко-

ления

3VL three-valued logic трехзначная логика

3NF third normal form третья нормальная форма (ЗНФ)

4GL fourth generation language язык (программирования) четвертого по-

коления

4NF fourth normal form четвертая нормальная форма (4НФ)

4VL four-valued logic четырехзначная логика

5NF fifth normal form (same пятая нормальная форма (ЗНФ) (то же

PJ/NF) самое, что и PJ/NF)

е принадлежит

0 оператор сравнения (=, < и т.д.)

0 пустое множество

—> функционально определяет

—* многозначно определяет

= равносильно (тождественно)

=> следует (логическая связка)

h следует (металингвистический символ)

Н всегда справедливо

(металингвистический символ)

1 конец (доказательства, примера и т.п.)

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

с

CODASYL, 58

D

DataJoiner, 799 DBTG, 58

Е

ER-диаграмма, 42; 510; 514

свойство, 515

связь, 516

сущность, 515 ER-модель, 510; 522

F

false, 693; 695

N

NULL, 693; 704; 706; 825

О

ODBC, 135; 797 OID, 953 OLAP, 836

HOLAP, 844

MOLAP, 842

ROLAP, 842

перекрестные таблицы, 841 OLTP, 41; 813; 818

Q

QBE, 283

R

RDA, 794

s

SQL, 34; 69; 108; 119: 266; 322; 380; 794; 797; 801; 807; 838; 1028 CLI, 135 SQL3,1041

базовые переменные, 128 базовые таблицы, / 77 вложенные подзапросы. 126 внедрение операторов, 126 внешние ключи, 324 группирование, 272; 1032 динамический, 134 домены. 174

значения по умолчанию, 130 инициализация транзакции, 126; 555 каталог, 124 ключи, 714 комментарий, 123 курсоры. 129; 131; 132; 548 манипулирование данными, 122 недостатки, 136 неопределенные значения, 711 обновление данных, 123 обобщающие функции. 271 ограничения домена, 323 ограничения таблицы. 323 ограничения целостности, 322; 326 определение данных, 120; 712 определитель NULL, 271 относительное имя, 267 поддержка представлений, 380 поддержка транзакций, 554 подзапросы, 273 потенциальные ключи, 323 предложение SELECT, /050 предоставление полномочий, 626 представления. 125; 626 проверочные условия, 324 скалярные выражения, 713 сортировка результата, 268 транзакции, 126; 801 условия выборки, 1032 условные выражения, 712

т

timestamp, 855 true, 693; 695 Tutorial D, 856

V

unknown, 695

A

АБД, 68; 75 Агент, 779

Администратор базы данных, 75 Администратор данных, 75 Аксиомы, 900

дедуктивные, 901 Аксиомы Армстронга, 405 Алгоритм редукции Кодла, 257 Аномалии, 432 Архитектура, 65; 108

ANSI/SPARC, 65

внешнее представление. 71

внешний уровень, 68

внутренний уровень, 73

клиент/сервер, 81; 793

концептуальный уровень, 72

отображение, 74 Атрибуты, 152; 431

домены, 698

замыкание множества, 407 неключевые, 431 отношения, 474 специальные значения, 711 типа отношения, 448

Б

База знаний, 899 Базовые переменные, 128 Базы данных, 32; 40; 45

администраторы, 40

аппаратное обеспечение, 37

восстановление, 544; 549

интенсиональные, 918

логические, 899

локальные, 768

однородные, 769

поддержки принятия решений, 815; 817

пользователи, 39

принцип относительности, 357

Базы данных

программное обеспечение, 38 проектирование, 887 распределенные, 86; 767; 770 связи, 41

статистические, 615

статистические показатели, 653

сущности, 41

транзакции, 545

уровень детализации, 832

хронологические, 853; 855; 863; 887 Банк данных, 814 Банк оперативных данных, 829 Блокировка, 569; 791

граф ожидания, 575

двухфазная, 577

протокол, 571

стратегия первичной копии, 791

в

Объекты, 988 Восстановление, 544

носителей, 552

системы, 550 Временная отметка, 855 Время транзакции, 858 Высказывание, 904

допустимое время, 857

Г

ГВС, 780

Граф ожидания, 575; 792 Группирование, 222

д

Данные, 44

временные, 853 встроенные типы, 1042 защита, 602 интервалы, 868 логическая независимость, 354 независимость, 50 обобщение, 836 объекты, 944 ограничения, 602; 864 операционные, 813 подтип, 725

Данные

распределенные, 770 репликация, 777 структуры хранения, 1015 супертип, 725 тип, 725

физическая независимость, 818; 950

хронологические, 855

целостность, 602

шифрование, 621

экземпляр, 52 Двухфазная фиксация, 553; 779 Декомпозиция, 426

вертикальная, 889

горизонтальная, 887 Декомпозиция запросов, 654 Денормализация, 483 Дерево запроса, 643

Доказательно-теоретический подход, 900 Домен, 152; 512 Допустимое время, 857

Ж

Журнал регистрации, 547; 549

3

Зависимость, 400

включаемая, 820

соединения, 477 Загрузка данных, 828 Законы

ассоциативный, 649

идемпотентности, 650

коммутативный, 649

преобразования, 702

распределительный, 648 Заменимость, 733: 736; 739; 757 Замыкание множества, 405; 407 Запрос, 79; 1014

каноническая форма, 644

произвольный, 973

распределенный, 807

рекурсивный, 899; 924

удаленный, 807 Защита

избирательный контроль, 603; 605 обязательный контроль, 603; 611 полномочия, 605 привилегии, 605

Защита данных, 602 ограничения, 49 Зернистость, 859; 869 "Золотое правило", 309

И

Идентичность, 508

Избирательная схема контроля, 603; 605 Избыточность, 47: 404; 422; 544; 824

контролируемая, 820 Индексы, 821 Инкапсуляция, 871; 950 Интервал времени, 867; 871 Исчисление, 903

высказываний, 902

доказательство, 905

кортежей, 245

правила вывода, 904

предикатов, 899; 907

термы, 903

формулы, 903 Итоговые таблицы, 824

К

Кардинальность, 152 Каталог, 104; 156; 783 Квант времени, 858 Кванторы

EXISTS, 696

FORALL, 696 Классы

конструктор, 958

сообщения, 951 Клиент, 82; 84

Ключ, 311; 431; 704; 714; 865; 881 альтернативный, 314: 705 внешний, 315; 318; 324: 706 первичный, 151; 314; 318; 705 потенциальный, 311; 314; 323; 432; 442 потенциальный хронологический, 884 суперключ, 408 суррогатный, 957

КНФ, 651

Коллекции, 958

Конвейерная обработка, 94

Контрольные точки, 551

Координатор, 553

Кортеж, 152:164 О-кортеж, 220

л

Литералы, 157 Ловушка соединения, 43 Логика, 700; 902

высказывания, 904

дублирующиеся кортежи, 699

логическая импликация, 904

теорема, 900

трехзначная, 695 Логическая база данных, 899 Логические выражения, 695 Логическое значение

false, 693

true, 693

unknown, 693

м

Магазины данных, 831

Маркер настоящего момента, 887

Массовые параллельные системы, 802

Менеджер

передачи данных, 81; 768

ресурсов, 553; 787

транзакций, 79 Метаданные, 80; 104 Многозначная зависимость, 469; 472 Модели данных, 44; 56

"сущность-связь", 510

RM/T, 508

дедуктивная, 58

иерархическая, 57

инвертированные списки, 57

многомерная, 58

объектная, 944

объектно-ориентированные, 58

объектно-реляционные, 58

реляционная, 44; 92; 96; 1011

сетевая, 57

функциональная, 995 Моделирование, 505

ER-модель, 522

правила целостности, 508

семантическое, 506; 507 Момент времени, 858 Моментальные снимки, 378; 787 Мутатор, 751

н

Наблюдатель, 751 Наследование, 726; 728; 756 Настройка систем, 76 Независимость данных, 50 Неизвестное значение, 693 Неопределенные значения, 693 Нормализация, 423; 424; 481; 489; 490; 887

(3,3)НФ, 491

1НФ, 423; 424; 431

2НФ, 424; 435

ЗНФ, 430; 431; 438

4НФ, 474

5НФ, 479

атомарная переменная-отношение, 441 декомпозиция. 425; 426; 439; 443 ДКНФ, 490 другие НФ, 490 зависимость соединения, 477 многозначная зависимость, 469; 472; 477 нормальные формы, 424 НФБК, 425; 442; 444: 472 ПСНФ, 479

функциональная зависимость, 477

О

Обобщающие функции, 217; 220 Обобщение, 743 Обратное восстановление, 552 Объекты, 944; 948; 949; 962; 1002

идентификатор, 953; 957

иерархия классов, 961

инкапсуляция, 950

класс, 949; 958

коллекции, 958; 965

конфигурации, 989

переменные экземпляра, 950; 951

полиморфизм, 962

указатель, 1011

экземпляры, 958 Обязательная схема контроля, 603; 611 Овеществление, 54; 358 Ограничения целостности, 49; 301; 303; 308;

309; 402; 652; 700; 705; 819; 860; 870

золотое правило, 307; 309

ограничение ключа. 490

ограничения атрибута, 305; 490

ограничения базы данных, 306; 310

ограничения отношения, 305

ограничения подмножеств, 677

Ограничения целостности

ограничения причастности, 677

ограничения типа, 303

отношения, 310; 313

ссылочная целостность, 316; 706 Операторы, 742; 748

COALESCE, 874

TREAT DOWN, 739

UNFOLD, 874

выбора, 725; 754

обновления, 885

обобщения для интервалов, 873

присвоения, 726; 737

проверки типа, 726; 746

равенства, 726

скалярные для интервалов, 871

сравнения, 744

чтения и обновления. 751 Операция

хронологическая проекция, 878

хронологическая разность, 880 Оптимизация. 101; 213; 639; 642; 702: 778:

781; 1014

ассоциативный закон, 649

декомпозиция запросов, 654

дерево запроса, 643

закон идемпотентности, 650

каноническая форма, 644

коммутативный закон, 649

логические выражения, 650

отделение подзапросов. 655

план запроса, 646

подстановка кортежей. 655

правила преобразования, 645

процедуры реализации, 645

распределительный закон, 648

семантические преобразования, 651

скалярные выражения. 650

формула стоимости, 646 Ортогональность

языка, 271 Отказы

носителей, 550

системы, 550 Отношения, 97; 151; 423; 1002; 1011

0-кортеж, 220

атрибут, 152

дублирующиеся кортежи, 699 заголовок, 99; 163; 195 значения, 163 "золотое правило", 359 избыточность, 404; 422

Отношения

кардинальность, 152; 163 кортеж, 152 обновление, 360; 377

выборки, 367

пересечений, 366

проекции, 368

разности, 367

расширений, 370

соединений, 372 свойства, 166 степень. 152; 163 тело. 99; 163

функциональная зависимость, 400

хронологическое, 855 Отображение, 67; 74; 75; 77 Отображения, 71

п

Параллельная обработка, 84 Параллельность, 566; 791

блокировка, 569

блокировка намерения, 580

взаимная блокировка, 575

графики, 577

метод управления, 566

упорядочиваемость, 576 Перегрузка, 876 Передача данных

соединения, 801 Переменная кортежа, 244; 247; 251

свободная, 248

связанная, 248 Переменная-отношение, 97: 169; 194; 308;

401; 403;423; 1007; 1011

атомарная, 441

базовая, 105

виртуальная, 350

декомпозиция, 439

распределенная, 771

самоссылающаяся, 317

фрагментация, 773 Переменные экземпляра, 951 Перманентность. 40 План запроса, 646

Поддержка принятия решений, 813 Покрытие, 409 Полиморфизм, 732; 962 Полномочия, 605 Потенциальный ключ, 403; 866 Правило вывода, 901; 904

Предварительная запись, 549 Предикат, 100; 169; 244; 307; 309; 899; 903; 907

Представления, 106; 108; 350; 353; 775

обновление, 358 объединений, 363

определение, 352

параметризованные, 627

принцип взаимозаменяемости, 357

процедура подстановки, 351 Привилегии доступа, 605 Принцип подстановки, 961 Проектирование

ER-диаграмма, 514

ER-моделирование, 516

логическое, 75; 817; 818

ортогональное, 486

физическое, 75; 817; 820 Прозрачность

расположения, 773

репликации, 777 Протоколы

предварительной записи в журнал, 549 Прямое восстановление, 552

Р

Разгруппирование, 223 Разработка данных, 844 Распределенная обработка, 83; 84 Расчетные столбцы, 824 Резервная копия, 552 Резолюция, 925 Рекурсия, 924

Реляционная алгебра. 192; 211:222; 225;

243; 257; 261; 351; 696

логическая импликации, 256

семантика, 199

синтаксис, 197

сравнения, 744 Реляционная замкнутость, 94 Реляционная модель, 97

замкнутость, 195 Реляционная полнота, 261 Реляционное исчисление, 243; 257; 260; 302;

696

вычислительные возможности, 262 исчисление доменов, 263 исчисление кортежей, 245 кванторы, 249 реляционная полнота, 266 синтаксис, 245

Реляционное исчисление

условие принадлежности, 263

формула WFF, 246; 248; 249; 251; 252 Реляционные операции, 197; 252; 699; 861

внешнее соединение, 707

выборка, 202

вычитание, 200

группирование, 222

деление, 207

звездообразное соединение, 834

обобщение, 217; 218; 220

объединение, 199

переименование, 196

пересечение, 200

полувычитание, 214

полусоединение, 214

проекция, 203; 427

произведение, 201

прототип кортежа, 252

разгруппирование, 223

расширение, 215

реализация, 658

соединение, 205

сравнения, 225

транзитивное замыкание, 221 Репликация, 777; 823 РСУБД, 796

именование объектов, 783

С

Свойство, 512; 515; 520

многозначное, 512

однозначное, 512

производное, 512 Связь, 41; 113; 508; 510; 512; 516; 517

рекурсивная, 516

свойства, 43

участие сторон, 512 Сервер, 82; 84 Сигнатура, 749 Системный каталог. 301; 639 Системы клиент/сервер, 792; 795 Словарь данных, 80 Составные столбцы, 819 Специализация. 741; 742; 748; 757 Ссылочная диаграмма, 316 Ссылочная целостность, 318

ссылочные операции, 319 Статистические показатели, 653 Степень, 152 Страницы, 73

СУБД. 35: 38; 77; 767; 768; 780; 980

восстановление носителей, 552 системы. 550

доступность, 773

инструментальные средства, 82

каталог, 104; 783

многомерные, 842

многопользовательская, 35

надежность, 775

объектно-реляционные, 999

однопользовательская. 35

оптимизация, 101; 642

подсистема защиты, 604

пользовательский интерфейс, 80

распределенные, 796

резервная копия. 552

РСУБД, 768

утилиты,83

экспертная, 899 Сущность, 41; 75; 113; 507; 511; 515; 516;

725

подтип, 520

подтипы,513

свойства, 43

сильная, 511

слабая, 511

супертип, 513

тип, 507 Схема "звезда", 825 Схемы, 77; 104

внешняя, 71

внутренняя, 73; 75

концептуальная, 71; 72; 75

отображения, 104

т

Теорема Хета, 428 Термы, 903

Тип, 725; 738; 743; 757; 1002; 1007; 1014; 1042

заменимость, 733 иерархия, 729 интервал. 868: 869 корневой, 731 листовой, 731 наследование, 1047 несвязанный, 732 ограничения, 725 подтип, 731; 758 полиморфизм. 733

Тип

представление, 725

проверка, 746

супертип, 731 Типы данных, 152: 169

допустимые представления, 156

ограничения, 156

преобразование, 161

скалярность, 154

физическое представление. 153 Точка фиксации, 548 Транзакции, 48; 109; 307; 545; 807

АСГО-свойства. 786

атомарность, 563

восстановление, 547

временные отметки, 590

двухфазная фиксация. 553; 779; 787

параллельность, 566

поддержка в SQL, 554

предполагаемая фиксация, 790

распределенные, 779; 787

режим доступа, 555

упорядоченность, ПО; 576

уровень изоляции, 555; 578

четырехфазная фиксация, 810 Трехзначная логика, 693 Триггеры, 302; 321; 888

У

Узел, 767; 772 Унификация, 913: 925 Упорядоченность, 110 Упорядочиваемость, 576 Уровень детализации, 832 Уровень изоляции, 578 Уровни архитектуры. 65

внешний. 68 Утилиты. 73; 82; 83

копирования/восстановления, 552

Ф

Фрагментация, 821

Функциональная зависимость, 400; 403; 405; 425; 426; 443; 472; 473; 817; 818 детерминант, 402 диаграмма, 429; 432 замыкание \i, 442 замыкание множества, 405 неприводимое множество, 409 сохранение, 439

Функциональная зависимость транзитивная, 405; 436; 439; 443 тривиальная, 404; 405

X

Хранилища данных, 41; 829

OLAP, 836

загрузка данных, 828

звездообразное соединение, 834

извлечение данных, 827

консолидация данных, 827

магазины данных, 831

очистка данных, 827

размерность, 833

разработка данных, 844

схема типа "снежинка", 836

таблица размерностей, 833

таблица фактов, 833 Хранимые процедуры, 302; 795 Хроники, 560 Хронон, 858

ц

Целостность данных, 97; 301; 602

ч

Четырехфазная фиксация, 810

ш

Шифрование, 621 RSA-схема, 623 алгоритм, 621 ключ, 621

открытый текст, 621

с открытым ключом, 623

стандарты, 622

DES, 623 шифрованный текст, 621 Шлюзы, 796

Я

Языки

базовый язык, 69

обработки данных, 69

определения данных, 69; 71; 78

подъязык данных, 69 Языки запросов, 79

Научно-популярное издание К. Дж. Дейт

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

Литературный редактор Верстка

Художественный редактор Технический редактор Корректоры

Л.Н. Красножон И. В. Родюк С.А. Чернокозинский Г.Н. Горобец

Л.А. Гордиенко, Л.В. Коровкина,

О.В. Мишутина, Л. В. Чернокозинская

Издательский дом "Вильяме". 101509, Москва, ул. Лесная, д. 43, стр. 1. Изд. лиц. ЛР № 090230 от 23.06.99 Госкомитета РФ по печати.

Подписано в печать 11.08.01. Формат 70x100/16. Гарнитура Times. Печать офсетная. Усл. печ. л. 80,04. Уч.-изд. л. 66,7. Тираж 5000 экз. Заказ № 1379.

Отпечатано с диапозитивов в ФГУП "Печатный двор"

Министерства РФ по делам печати, телерадиовещания и средств массовых коммуникаций. 197110, Санкт-Петербург, Чкаловский пр., 15.

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

Колин Дж. Уайт (Colin J. White),

основатель компании DataBase Associates International, Inc.

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

Шудха Рам (Sudha Ram), университет штата Аризона.

"В книге К. Дж. Дейта возможности языка SQL представлены яснее и подробнее, чем в большинстве других книг. Читатель сможет не только получит! теоретические знания, но и научиться применять их на практике."

— лоч и >>у i_ui, университет штата Оклахома.

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

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

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

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

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

К основному материалу книги добавлены два новых приложения. Одно из них содержит обобщенные сведения о синтаксисе и семантике операторов языка SOL, а другое представляет собой краткий обзор нового стандарта SQL3, принятие которого ожидается в ближайшем будущем.

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

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

Некоторые другие изданий, выпущенные с участием К. Дж. Дейта

Foundation for Object/Relational Databases: The Third Manifesto (Addison-Wesley, 1998)

Relational Database Writings 1994-1997

(Addison-Wesley, 1998)

A Guide to the SQL Standard, Fourth Edition

(Addison-Wesley, 1997)

Relational Database Writings 1991-1994

(Addison-Wesley, 1995)

A Guide to DB2. Fourth Edition (Addison-Wesley, 1993)

A Guide to Sybase and SQL Server

(Addison-Wesley, 1992)

Relational Database Writings 1989-1991

(Addison-Wesley, 1992)

A Guide to SQL ZDS

(Addison-Wesley. 1989)

1Отметим, что мы, несомненно, поддерживаем эволюционный, а не революционный путь развития СУБД. Для сравнения приведем цитату из книги группы ODMG [24.13]: "[Объектные СУБД] — это результат революционного, а не эволюционного развития ". Мы не верим, что ры­нок в целом готов к революционным переменам, и не считаем, что они необходимы или должны непременно произойти. В частности, поэтому работа "The Third Manifesto" [3.3] — это, по су­ти, именно эволюционный манифест, а не революционный.

2 В частности, такие системы послужили слишком широкому распространению заблужде­ния, что реляционные системы могут поддерживать только ограниченное количество очень простых типов. Вот довольно типичные выдержки из литературы по объектным базам данных: "Реляционные системы баз данных поддерживают очень малый фиксированный набор типов данных" [25.25], "Реляционная СУБД может поддерживать лишь... встроенные типы [в основ-

ном, просто числа, строки, даты и время]" [24.38], "Объектно-реляционные модели расширяют реляционную модель данных, предоставляя более богатую систему типов" [17.61]; и т.д.

3 Термин концептуальная целостность получил распространение благодаря Фреду Бруксу (Fred Brooks), который в [25.1] сказап следующее; "[Концептуальная] целостность— это наиболее важный вопрос в системном проектировании. Лучше не включить в систему определенные несо­вместимые возможности [и] отразить единый ряд проектных идей, чем иметь систему, кото­рая поддерживает много полезных, но несвязанных и несогласованных идей". Спустя 20 лет он добавил: "Цельный первоклассный программный продукт должен представлять... логически по­следовательную мысленную модель... [Концептуальная] целостность— наиболее важный фак­тор для удобства в использовании... И сейчас я в этом убежден больше, чем когда бы то ни было. Концептуальная целостность — это основа для получения качественного продукта".

4³ Напомним, что, как указывалось в главе 24, традиционные системы предоставляют тип данных BLOB для обработки "больших двоичных объектов". В объектно-реляционных системах значения данных некоторых типов, определяемых пользователем, могут физически храниться как данные типа BLOB.

5' Так говорится в стандарте, хотя логичнее следовало бы сказать "самое большее одну груп­пу", поскольку групп может не быть совсем, если в результате вычисления предложений FROM и WHERE получится пустая таблица.

6 Напомним, что, как указывалось в главе 8, условные выражения представляют в языке SQL аналог того, что в книге мы называли булевыми или логическими выражениями.

7' Все же добавим, что одним из наиболее неочевидных аспектов являются "домены " в стиле языка SQL (см. главы 4 и 5), которые, по-видимому, были тихо забыты.

8 Сравните в этом отношении свойства условий ALL или ANY (см. приложение А).

9Следует отметить, что этот "мутатор" не является настоящим мутатором в смысле главы 5, т.е. типичным оператором обновления, поскольку по определению он возвращает значе­ние. Обсуждение последствий (неприятных) этого факта, к сожалению, выходит за рамки дан­ного короткого приложения. (См. [3.3], где этот вопрос обсуждается подробно.)

10 За исключением, может быть, строчных типов. Однако существуют некоторые проблемы, связанные с наследованием строчных типов, которые здесь не освещаются, поскольку это выхо­дит за рамки данного приложения.

11 Или, возможно, в некотором представлении. Использование представления в этом прило­жении не рассматривается.

12 В частности, отметим, что если объявленным типом некоторого параметра Р для неко­торого оператора Ор является некоторый структурированный тип Т, то строка базовой таб­лицы, которая была определена как таблица, "относящаяся к" типу Т, не может передаваться как соответствующий аргумент при вызове оператора Ор.

13* Здесь присутствует некоторый порочный круг: "такая строка" может означать лишь "строку, которая имеет конкретный идентификатор". Обратите внимание на смешивание зна­чения и переменной!

14В большинстве языков, в которых поддерживается операция разыменовывания, также поддерживается операция привязки, но в языке SOL3 — нет.

7

Глава 20. Распределенные базы данных