Об'єктно-орієнтована мова запитів (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 Особливості архітектури ООСУБД: користувач може отримати доступ до об'єктів у зовнішній пам'яті, варіанти архітектури «клієнт-сервер», управління методами в ООСУБД
У той час як архітектури РСУБД дуже схожі (орієнтація на клієнт-серверну організацію, опора на індекси, процесор виконання виразів реляційної алгебри) і мають характеристики продуктивності та масштабованості, що відрізняються на невеликі відсотки, архітектури ООСУБД значно різняться і демонструють абсолютно різні характеристики. Після стількох років, протягом яких людей привчали, що все РСУБД поводяться практично однаково, було досить природно застосувати ці висновки до ООСУБД і оголосити, що і вони є майже однаковими. При використанні цього припущення, якщо який-небудь першопроходець вибирав деяку ООСУБД, яка погано відповідала потребам його додатків, можна було легко прийти до висновку, що ніяка ООСУБД не зможе задовольнити ці потреби. Ці нелогічні міркування привели до виникнення неправильних уявлень про ООСУБД: вони є занадто повільними, не забезпечують високий рівень паралелізму, що не масштабуються для роботи з великими обсягами даних і т.д. і т.п. Все це неправильно, а реальність полягає в тому, що потрібно уважно проаналізувати характеристики програми та зрозуміти, яка архітектура ООСУБД їм найбільше відповідає. При виборі правильної архітектури СУБД показники продуктивності і масштабованості можуть підвищуватися на порядки величин, а не на відсотки, як у випадку реляційних реалізацій. Розібравшись в цьому, проаналізуємо відмінності в архітектурі ООСУБД, щоб допомогти користувачам приймати рішення, які ведуть до успішного вибору технології.