Объектно-ориентированный язык запросов OQL

Объектно-ориентированный язык запросов (Object Query Language - OQL) представляет собой декларативное средство доступа к объектно-ориентированной базе данных, использующее SQL-подобный синтаксис. В нем не предусмотрены операторы явного обновления, поскольку подобные функции предоставляются операциям, определенным в объектных типах. Так же, как и в случае языка SQL, язык OQL может использоваться как самостоятельный или как язык, операторы которого внедряются в программы на другом, базовом языке, для чего в стандарте ODMG определен порядок их связывания. В настоящее время поддерживаются базовые языки Smalltalk, C++ и Java. Язык OQL может вызывать операции, которые программируются на этих языках. Запрос на языке OQL является функцией доставки того объекта, чей тип может быть логически выведен на основании оператора, входящего в состав выражения для данного запроса. Прежде чем обсуждать создание ОQL-запросов, следует предварительно познакомиться с правилами составления выражений.

Выражение для определения запроса имеет вид «DEFINE Q AS е», где Q - имя запро­са, а «е» - выражение запроса.

Выражение может состоять из следующих компонентов:

- атомарного литерала, например 10, 16.2, 'х', "abcde", true, nil;

- именованного объекта;

- переменной итератора из предложения FROM оператора SELECT-FROM-WHERE, например е аs х, или е х, или х in е, где е - коллекция типов (Т), а х – некий объект типа Т;

- выражение определения запроса.

Разработчики языка основывались на следующих основных принципах:

- OQL опирается на объектную модель ODMG.

- OQL очень близок к SQL/92. Расширения относятся к объектно-ориентированным понятиям, таким как сложные объекты, объектные идентификаторы, путевые выражения, полиморфизм, вызов операций и отложенное связывание.

- В OQL обеспечиваются высокоуровневые примитивы для работы с множествами объектов, но, кроме того, имеются настолько же эффективные примитивы для работы со структурами, списками и массивами.

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

- OQL не является вычислительно полным языком. Он представляет собой простой язык запросов.

- Операторы языка OQL могут вызываться из любого языка программирования, для которого в стандарте ODMG определены правила связывания. И наоборот, в запросах OQL могут присутствовать вызовы операций, запрограммированных на этих языках.

- В OQL не определяются явные операции обновления, а используются вызовы операций, определенных в объектах для целей обновления.

- В OQL обеспечивается декларативный доступ к объектам. По этой причине OQL -запросы могут быть легко оптимизированы.

26 Особенности архитектуры ООСУБД: способы доступа к объектам во внешней памяти, варианты архитектуры «клиент-сервер», управление методами в ООСУБД

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