внутренним кодированным представлением в виде строк байтов. Однако в действительности более полезен был бы индекс, построенный на основании областей, охватываемых этими многоугольниками.

Замечание. В главе 21 мы назвали такие индексы функциональными.

25.5. Преимущества реального сближения двух технологий

В [25.1] Стоунбрейкер предлагает матрицу классификации для СУБД (рис. 25.4). Квадрант 1 этой матрицы представляет приложения, которые обрабатывают простые данные и которым не требуется поддержка произвольных запросов (обычный текстовый процессор - неплохой пример для этого случая). Такие приложения на самом деле не являются приложениями баз данных в полном смысле этого слова. СУБД , которая лучше всего подойдет для подобных приложений, - встроенная файловая система, предоставляемая пользователю как часть операционной системы.

есть запросы нет запросов

простые данные сложные данные

Рис. 25.4. Матрица классификации СУБД, предложенная Стоунбрейкеро.м

Квадрант 2 представляет приложения, которые предусматривают ввод произвольных запросов, но все же имеют дело лишь с относительно простыми данными. В эту категорию попадает большинство современных бизнес-приложений. Подобные приложения довольно хорошо поддерживаются традиционными реляционными СУБД (или по крайней мере СУБД, использующими язык SQL).

Квадрант 3 представляет приложения, в которых используются сложные данные и выполняется обработка запросов, но лишь заранее запланированных. К этой категории, например, могут принадлежать приложения САПР/АСУТП. Современные объектные СУБД первоначально нацеливались именно на этот сегмент рынка, поскольку традиционные СУБД не слишком хорошо справляются с задачами, характерными для данной категории приложений.

Квадрант 4 представляет приложения, которые нуждаются как в поддержке сложных данных, так и в обработке произвольных запросов к этим данным. В качестве примера Стоунбрейкер приводит базу данных, содержащую оцифрованные 35-миллиметровые слайды, и типичный запрос к этой базе - Получить все снимки закатов, сделанные в пределах 20 миль от Сакраменто, Калифорния . Затем он продолжает приводить аргументы в поддержку своей позиции; он считает, что объектно-реляционные СУБД необходимы для приложений, попадающих в этот квадрант, и через несколько лет в него бу-

Напомним, что, как указывалось в главе 24, традиционные системы предоставляют тип данных BLOB для обработки больших двоичных объектов . В объектно-реляционных системах значения данных некоторых типов, определяемых пользователем, могут физически храниться как данные типа BLOB.

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

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

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

Произвольные запросы, определение представлений и поддержка декларативных Офаничений целостности данных

Методы, которые охватывают классы (нет необходимости в выделении целевого операнда )

Динамически определяемые классы (для размещения результатов произвольных запросов)

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

Отложенные проверки целостности (до момента фиксации)

Ограничения переходов

Семантическая оптимизация

Связи, степень которых больше двух

Правила внешних ключей (ON DELETE CASCADE и т.п.)

Возможности оптимизации

И т.д. Кроме того, желательно следующее.

Идентификаторы и указатели используются неявно и полностью скрыты от пользователя

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

Преимущества инкапсуляции как таковые используются, но по отношению к скалярным значениям в отношениях, а не к самим отношениям

Реляционные системы теперь могут справляться с задачами в области сложных приложений, таких как САПР/АСУТП, которые нами уже обсуждались

При этом реляционный подход остается концептуально чистым.

25.6. Резюме

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

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

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

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

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

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

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