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

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

есть запросы	2	4
нет запросов	1	3
	простые данные	сложные данные

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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