О'екгно-СУБД
Зміст
1. 20 років еволюції програмного забезпечення.
2. Реляційні бази даних.
3. Об'єктно-реляційні методи.
4. Об'єктно-орієнтовані бази даних.
4.1 Why ODBMS?
4.2 Спірні моменти технології.
4.3 Стандарти об'єктних баз даних.
4.4 Постачальники ООСУБД.
5. Висновок.
6. Глосарій
1.
2. 20 років еволюції
програмного забезпечення.
Малюнок 1
Управління інформацією завжди було основною сферою застосування комп'ютерів і, треба думати, буде грати ще велику роль у майбутньому.
Системи управління базами даних [1] (СУБД, DBMS - Database Management System) протягом всього шляху розвитку комп'ютерної техніки удосконалювалися, підтримуючи все більш складні рівні абстрактних
даних, заданих користувачем, і забезпечуючи взаємодію компонентів, розподілених в глобальних мережах і поступово інтегрується з
телекомунікаційними системами. Дозволивши собі міркування у стилі Білла Гейтса, припустимо, що результатом буде становлення систем управління
інформацією однієї з частин повсякденному житті кожного.
Історія розвитку комп'ютерної техніки - це історія безперервного руху від мови та рівня комунікації машини до рівня
користувача. Якщо перші машини вимагали від користувача оформлення того, що йому потрібно (тобто написання програм), в машинних кодах, то мови
програмування четвертого рівня (4GLs) дозволяли кінцевим користувачам, які не є
професійними програмістами, отримувати доступ до інформації без детального опису кожного кроку, але тільки з вбудованими зумовленими типами даних
- Наприклад, таблицями.
Останнім кроком у цьому напрямку стала об'єктно-орієнтована технологія,
радикально змінила сферу розробки програмного забезпечення вже в 1990-х роках (Малюнок
1). Об'єктно-орієнтований підхід дозволяє упаковувати дані та код для їх обробки разом. Таким чином практично знімається обмеження на
типи даних, дозволяючи працювати на будь-якому рівні абстракції.
Еволюція систем управління інформацією йшла паралельно цьому прогресу, починаючи з низькорівневих програм, які, наприклад, напряму
виробляли операції читання і запису з усією пам'яттю без обмеження доступу, стрічкою, циліндрами і доріжками диска і більш високорівневі засобами --
файловими системами, які оперували з такими поняттями, як масиви, записи та індекси для підвищення продуктивності. Бази даних у свою чергу
починали з моделі записів та індексів (ISAM тощо), набуваючи з часом здатність відновлення
після збоїв, перевірки цілісності даних і можливості роботи декількох користувачів одночасно. Ці ранні моделі даних (CODASYL) належали радше до рівня
машинної орієнтації. Надалі реляційні бази даних, що прийшли на зміну в 1980-х роках, придбали механізм запитів, що дозволяє користувачеві вказати потрібне, надавши СУБД самої оптимальним чином знайти результат,
використовуючи динамічну індексацію.
об'єктно-орієнтовані СУБД (ООСУБД) стали розроблятися із середини 80-х років в
основному для підтримки програм САПР. Складні структури даних систем автоматизованого проектування виявилося дуже зручно оформляти у вигляді
об'єктів, а технічні креслення простіше зберігати в базі даних, ніж у файлах. Це дозволяє обійтися без декомпозиції графічних структур на елементи і запису їх у файли після
завершення роботи з кресленням, виконання зворотної операції при внесенні будь-якої зміни. Якщо типові реляційні бази даних мають зв'язку глибиною в два
рівня, то ієрархічна інформація креслень САПР звичайно включає близько десяти рівнів, що вимагає досить складних операцій для "складання"
результату. Об'єктні бази даних добре відповідали подібним завданням, і еволюція багатьох СУБД почалася саме з ринку САПР.
Тим часом ринок САПР був швидко насичений, і на початку 90-х років виробники ООСУБД звернули увагу на інші області застосування, вже
міцно зайняті реляційними СУБД. Для цього було потрібно оснастити ООСУБД функціями оперативної обробки транзакцій (OLTP), утилітами адміністратора баз даних (database administrator - DBA), коштами резервного
копіювання/відновлення і т.д. Роботи в даному напрямку тривають і сьогодні, але вже можна сказати, що перехід до комерційних програм йде
досить успішно.
3. Реляційні бази даних.
У реляційних базах даних (Relational Database System, RDBS) всі дані відображаються в двовимірних таблицях. База даних, таким чином, це не що інше,
як набір таблиць. RDBS і орієнтовані на записи системи організовані на основі стандарту B-Tree або
методі доступу, заснованому на індексації - Indexed Sequential Access Method (ISAM) і є стандартними системами,
використовуються в більшості сучасних програмних продуктів. Для забезпечення комбінування таблиць для визначення зв'язків між даними, які
практично повністю відсутні в більшості програмних реалізацій B-Tree і ISAM, використовується мови, подібні SQL (IBM), Quel (Ingres) і RDO (Digital Equipment), причому стандартом галузі в
даний час стала мова SQL, підтримується усіма виробниками реляційних СУБД.
Оригінальна версія SQL - це інтерпретується мова, призначена для виконання
операцій над базами даних. Мова SQL був створений на початку 70-х як інтерфейс для взаємодії з базами даних, заснованими на новій для того часу
реляційної теорії. Реальні програми зазвичай написані на інших мовах, що генерують код на мові SQL
і передають їх в СУБД у вигляді тексту в форматі ASCII. Потрібно також зазначити, що практично всі реальні реляційні (і не тільки реляційні) системи крім
реалізації стандарту ANSI SQL, відомого зараз в останній редакції під ім'ям SQL2 (або SQL-92), містять у собі додаткові
розширення, наприклад, підтримка архітектури клієнт-сервер або засоби розробки додатків.
Рядки таблиці складені з полів, заздалегідь відомих базі даних. У більшості систем не можна додавати нові типи даних. Кожен рядок
в таблиці відповідає запису. Положення цього рядка може змінюватися разом з видаленням або вставкою нових рядків.
Щоб однозначно визначити елемент, йому повинні бути зіставлені поле або набір полів, що гарантують унікальність елемента всередині
таблиці. Таке поле або поля називаються первинним ключем (primary key) таблиці і часто є числами. Якщо одна таблиця
містить первинним ключ іншого, це дозволяє організувати зв'язок між елементами різних таблиць. Це поле називається
зовнішнім ключем (foreign key).
Оскільки всі поля однієї таблиці повинні містити постійне число полів заздалегідь визначених типів, доводиться створювати додаткові
таблиці, що враховують індивідуальні особливості елементів, за допомогою зовнішніх ключів. Такий підхід сильно ускладнює створення скільки-небудь складних
взаємозв'язків в базі даних. Бажаючим переконається, що це дійсно так і що не пошкодували на це певний відрізок
часу, компанія POET Software люб'язно надає можливість ознайомитися з прикладом у своїй "білій книзі" "POET Technical Reference". База даних рядового підприємства громадського харчування (клієнти - Джордж Буш і Едді Мерфі) складається з
чотирьох таблиць.
Ще один великий недолік реляційних баз даних - це висока трудомісткість маніпулювання інформацією та зміни зв'язків.
4. Об'єктно-реляційні методи.
Незважаючи на розглянуті в п. 3 недоліки реляційних баз даних, вони мають ряд переваг:
розділення таблиць різними програмами;
розгорнутий "код повернення" у разі помилок;
висока швидкість обробки запитів (команда SELECT
мови SQL; результатом вибірки є таблиця, яка містить поля, що задовольняють заданому критерію);
Малюнок 2 Можливі підходи до об'єднання об'єктних і реляційних БД.
сама концепція об'єктних баз даних досить складна і
вимагає від програмістів серйозного і тривалого навчання;
відносно висока швидкість при роботі з великими
об'ємами даних.
Крім того, у всьому світі значні кошти вже інвестовані в реляційні СУБД.
Багато організацій не впевнені, що витрати, пов'язані з переходом на об'єктні бази даних, окупляться.
Тому багато користувачів зацікавлені в комбінованому підході, який би дозволив їм скористатися перевагами об'єктних баз
даних, не відмовляючись повністю від своїх реляційних БД. Такі рішення дійсно існують. Якщо перехід від реляційної бази до об'єктної
обходиться занадто дорого, то застосування останньої в якості розширення та доповнення реляційних СУБД часто є більш економічною альтернативою.
Компромісні рішення дозволяють дотримати баланс між об'єктами і реляційними таблицями (Малюнок
2).
Об'єктно-реляційні адаптери. Цей метод передбачає використання так званого
об'єктно-реляційного адаптера, який автоматично виділяє програмні об'єкти і зберігає їх у реляційних базах даних. Об'єктно-орієнтовані
додаток працює як пересічний користувач СУБД. Незважаючи на деяке зниження продуктивності, такий варіант дозволяє програмістам цілком
сконцентруватися на об'єктно-орієнтованої розробки. Крім того, всі наявні на підприємстві програми як і раніше, можуть звертатися до даних,
що зберігаються в реляційної формі.
Деякі об'єктні СУБД, наприклад GemStone компанії GemStone Systems, можуть самі виконувати
роль потужного об'єктно-реляційного адаптера, дозволяючи об'єктно-орієнтованим програмам звертатися до реляційних БД.
Об'єктно-реляційні адаптери, такі як Odapter компанії Hewlett-Packard для СУБД Oracle, можна з успіхом використовувати під
багатьох областях, наприклад в якості сполучного ПО, що об'єднує об'єктно-орієнтовані програми з реляційними СУБД.
Об'єктно-реляційні шлюзи. При використанні такого методу користувач взаємодіє з БД
за допомогою мови ООСУБД, а шлюз замінює всі об'єктно-орієнтовані елементи цієї мови на їх реляційні компоненти. За це знову приходиться
розплачуватися продуктивністю. Наприклад, шлюз повинен перетворити об'єкти в набір зв'язків, згенерувати оригінальні ідентифікатори (original identifier - OID) об'єктів і передати це
в реляційну БД. Потім шлюз повинен кожного разу, коли використовується інтерфейс реляційної СУБД, перетворювати OID, знайдений у базі, у відповідний об'єкт, який було збережено в
РСУБД.
Продуктивність в розглянутих двох підходах залежить від способу доступу до реляційної бази даних. Кожна РСУБД складається з двох
рівнів: рівня управління даними (data manager layer) та рівня управління носієм (storage manager layer). Перший з них
обробляє оператори на мові SQL, а другий відображає дані в базу. Шлюз або адаптер можуть взаємодіяти як
з рівнем даних (тобто звертатися до РСУБД за допомогою SQL), так і з рівнем носія (викликами
процедур низького рівня). Продуктивність в першому випадку набагато нижче (наприклад, система OpenODB
фірми Hewlett-Packard, яка може виконувати роль шлюзу, підтримує тільки на високому рівні).
Гібридні СУБД. Ще одним рішенням може стати створення гібридних об'єктно-реляційних СУБД,
які можуть зберігати і традиційні табличні дані, і об'єкти. Багато аналітиків вважають, що майбутнє за такими гібридними БД. Провідні постачальники
реляційних СУБД починають (або планують) додавати до своїх продуктів об'єктно-орієнтовані засоби. Зокрема, Sybase і Informix збираються в наступних версіях
СУБД ввести підтримку об'єктів. Такі розробки мають намір вести і незалежні фірми. Наприклад, компанія Shores готується оснастити об'єктно-орієнтованими засобами
СУБД Oracle8, випуск якої запланований на кінець 1996 р.
З іншого боку, виробники об'єктних СУБД, такі як компанія Object Design,
усвідомлюють, що об'єктно-орієнтовані бази даних у доступному для огляду майбутньому не замінять реляційні СУБД. Це змушує їх створювати шлюзи для підтримки
реляційних та ієрархічних баз даних йди різного роду інтерфейси, характерним прикладом яких є об'єктно-Реляційний інтерфейс Ontos Integration Server фірми Ontos, що застосовується у
поєднанні з її ООБД Ontos/DB.
5. Об'єктно-орієнтовані бази даних.
5.1
Why ODBMS?
"білими книгами" з назвою, винесеним у заголовок, з надлишком забезпечить будь-яка компанія, що займається об'єктними базами даних. Дещо
про переваги і недоліки об'єктно-орієнтованих СУБД вже згадувалося вище, підведемо в такому разі підсумок.
Об'єктно-орієнтовані бази даних застосовуються з кінця 1980-х для забезпечення управління базами даних додатками, побудованими в
Відповідно до концепції об'єктно-орієнтованого програмування. Об'єктна технологія розширює традиційну методику розробки додатків новим
моделюванням даних і методами програмування. Для повторного використання коду та поліпшення збереження цілісності даних в об'єктних програмуванні
дані та код для їх обробки організовані в об'єкти. Таким чином, практично повністю знімаються обмеження на типи даних.
Якщо дані складаються з коротких, простих полів фіксованої довжини (ім'я, адреса, баланс банківського рахунку), то кращим рішенням буде
застосування реляційної бази даних. Якщо, однак, дані містять вкладену структуру,, змінюваний розмір, визначені користувачем
довільні структури (мультимедіа, наприклад), подання їх у табличній формі буде, як мінімум, непростим. У той же час в ООСУБД кожна певна
користувачем структура - це об'єкт, безпосередньо керований базою даних.
У РСУБД зв'язку управляються користувачем, що створює зовнішні ключі. Потім для виявлення зв'язків динамічно під час виконання система
переглядає два (або більше) таблиці, порівнюючи зовнішні ключі до досягнення відповідності. Цей процес, званий об'єднанням (join), є слабкою стороною
реляційної технології. Більше двох або трьох рівнів об'єднань - сигнал, щоб шукати краще рішення. У ООСУБД користувач просто оголошує зв'язок, і СУБД
автоматично генерує методи управління, динамічно створюючи, видаляючи і перетинаючи зв'язку. Посилання при цьому прямі, немає необхідності в перегляді і
порівнянні або навіть пошуку індексу, який може сильно позначитися на продуктивності. Таким чином, застосування об'єктної моделі переважно
для баз даних з великою кількістю складних зв'язків: перехресних посилань, посилань, що зв'язують кілька об'єктів з декількома (many-to-many relationships)
двонаправленими посиланнями.
На відміну від реляційних, ООСУБД повністю підтримують об'єктно-орієнтовані мови програмування. Розробники, що застосовують С + +
або Smalltalk, мають справу з одним набором правил (що дозволяють використовувати такі переваги
об'єктної технології, як наслідування, інкапсуляція і поліморфізм). Розробник не повинен вдаватися до трансляції
об'єктної моделі в реляційну і назад. Прикладні програми звертаються і функціонують з об'єктами, збереженими в базі даних, яка використовує
стандартну об'єктно-орієнтовану семантику мови та операції. Навпаки, реляційна база даних вимагає, щоб розробник транслював об'єктну
модель до підтримуваної моделі даних і включив підпрограми, щоб забезпечити це відображення під час виконання. Наслідком є додаткові зусилля
при розробці та зменшення ефективності.
І, нарешті, ООСУБД підходять (знову ж таки без трансляцій між об'єктної і реляційної моделями) для організації розподілених обчислень.
Традиційні бази даних (у тому числе і реляційні та деякі об'єктні) побудовані навколо центрального сервера, що виконує всі операції над базою. За
суті, ця модель мало відрізняється від мейнфреймовой організації 60-х років з центральною ЕОМ - мейнфреймів (mainframe), що виконує всі обчислення, і пасивних терміналів.
Така архітектура має ряд недоліків, головним з яких є питання масштабованості. В даний час робочі станції (клієнти) мають
обчислювальну потужність близько 30 - 50% потужності сервера бази даних, тобто велика частина обчислювальних ресурсів розподілена серед клієнтів.
Тому все більше додатків, і в першу чергу бази даних і засоби прийняття рішень, працюють в розподілених середовищах, в яких об'єкти
(об'єктні програмні компоненти) розподілені по багатьох робочих станцій і серверів і де будь-який користувач може отримати доступ до будь-якого об'єкта.
Завдяки стандартам межкомпонентного взаємодії (про це пізніше) всі ці фрагменти коду комбінуються один з одним незалежно від апаратного,
програмного забезпечення, операційних систем, мереж, компіляторів, мов програмування, різних засобів організації запитів і формування звітів
і динамічно змінюються при маніпулюванні об'єктами без втрати працездатності.
5.2 Спірні
моменти технології.
Всі ООСУБД за визначенням підтримують збереження і розділення об'єктів. Але, коли справа доходить до практичної розробки
додатків на різних ООСУБД, виявляється безліч відмінностей у реалізації підтримки трьох характеристик:
Цілісність;
Масштабованість;
Відмовостійкість.
Відзначимо, що ООБД не вимагають багатьох з тих внутрішніх функцій і механізмів, які настільки звичні і є необхідними в реляційних БД.
Наприклад, при невеликому числі користувачів, довгих транзакцій і незначною завантаженні сервера об'єктні СУБД не потребують підтримки складних механізмів
резервного копіювання/відновлення (історично склалося так, що перша ООБД проектувалися для підтримки невеликих робочих груп - близько десяти
чоловік - і не були пристосовані для обслуговування сотень користувачів). Проте технологія БД визначено дозріла для великих проектів.
Для
ілюстрації першої категорії розглянемо механізм кешування об'єктів. Більшість об'єктних СУБД поміщають код додатку безпосередньо в той же
адресний простір, де працює сама СУБД. Завдяки цьому досягається підвищення продуктивності часто в 10-100
разів у порівнянні з окремими адресними просторами. Але при такій моделі об'єкт з помилкою може пошкодити об'єкти і зруйнувати базу даних.
Існують два підходи до організації реакції СУБД для запобігання втрати даних.
Більшість систем передають додатком покажчики на об'єкти, і рано чи пізно такі покажчики обов'язково стають невірними. Так, вони завжди неправильні
після переходу об'єкта до іншого користувача (наприклад, після переміщення на інший сервер). Якщо програміст, який розробляє програму, пунктуальний, то
помилки не виникає. Якщо ж програма спробує застосувати покажчик у невідповідний для цього момент, то в кращому випадку відбудеться крах системи, у
гіршому - буде втрачено інформація в середині іншого об'єкта і порушиться цілісність бази даних.
Є метод, кращий, ніж використання прямих покажчиків (Малюнок 3). СУБД додає
додатковий вказівник і при необхідності, якщо об'єкт переміщується, система може автоматично вирішити ситуацію (перезавантажити, якщо це необхідно,
об'єкт) без виникнення конфліктної ситуації.
Існує ще одна причина для застосування непрямої адресації: завдяки цьому можна
відслідковувати частоту викликів об'єктів для організації ефективного механізму свопінгу.
Це необхідно для реалізації вже друга необхідного властивості баз даних - масштабованості. Знову варто згадати організацію
розподілених компонентів. Класична схема клієнт-сервер, де основне навантаження припадає на клієнта (така архітектура називається ще "товстий
тонкий клієнт-сервер "), краще справляється з цим завданням, ніж мейнфреймовая структура, однак її все одно не можна масштабувати до рівня підприємства.
Завдяки багатоланкової архітектури клієнт-сервер (N-Tier architecture) відбувається рівномірне
розподіл обчислювального навантаження між сервером і кінцевим користувачем. Навантаження розподіляється за трьома і більше ланок, що забезпечує додаткову
обчислювальну потужність. До чого ж ще веде така практика? "Архітектура клієнт-сервер, ще зовсім недавно вважалася складною середовищем, поступово
перетворилася на виключно складну середу. Чому? Завдяки прискореного переходу до використання систем клієнт-сервер декількох ланок "(PCMagazine).
Розробникам доводиться розплачуватися додатковими труднощами, великими витратами часу і безліччю проблем, пов'язаних з інтеграцією. Залишимо
чергове згадка розподілених компонентів на цьому не позбавленою оптимізму ноті.
Малюнок 3 Пряма і непряма адресації.
Третє необхідну якість бази даних - це відмовостійкість. Саме ця властивість відрізняє програмний
продукт від "прилад". Існують кілька способів забезпечення відмовостійкості:
резервне копіювання і відновлення;
розподіл компонентів;
незалежність компонентів;
копіювання.
Керуючись принципом перше, програміст визначає потенційно небезпечні ділянки коду і вставляє
в програму деякі дії, що відповідають початку транзакції - збереження інформації, необхідної для відновлення після збою, і закінчення транзакції --
відновлення або, у разі неможливості, прийняття якихось інших заходів, наприклад, відправлення повідомлення адміністратору. В сучасних СУБД цей механізм
забезпечує відновлення у випадку виникнення практично будь-якої помилки системи, додатки або комп'ютера, хоча, звичайно, не можна говорити про ідеальну
захист від збоїв.
У мейнфреймовой архітектурі єдиним джерелом збоїв була центральна ЕОМ. При переході до розподіленої багатоланкової організації
помилки можуть викликати не тільки комп'ютери, включені в мережу, але й комунікаційні канали. У багатоланкової архітектури при збої одного з ланок
без спеціальних заходів результати роботи інших виявляться марними. Тому при розробці розподілених систем забезпечується принципово вищий
рівень забезпечення відмовостійкості. Назвемо обов'язкові для сучасних розподілених СУБД властивості:
прозорий доступ до всіх об'єктів незалежно від їх
місця розташування, завдяки чому користувачеві доступні всі сервіси СУБД і може проводитися перерозподіл компонентів без небажаних наслідків.
так званий "трифазний монітор транзакцій" (third-party transaction monitor), завдяки якому
транзакція виконується не в два, а в три етапи - спочатку надсилається запит про готовність до транзакції.
Що станеться, якщо один з компонентів вийде з ладу? Система, створена відповідно тільки до вищевикладених доводами,
призупинить роботу всіх користувачів і перерве всі транзакції. Тому важливо така властивість СУБД, як незалежність компонентів.
При мережевому збої мережа поділяється на частини, компоненти кожної з яких не можуть взаємодіяти з компонентами іншій частині. Для того,
щоб зберегти можливість роботи усередині кожної такої частини, необхідно дублювання критично важливої інформації всередині кожного сегмента. Сучасні
системи дозволяють адміністратору бази даних динамічно визначати сегменти мережі, варіюючи таким чином рівень надійності всієї системи в цілому.
І, нарешті, про копіювання (replication) даних. Найпростішим способом є додавання до кожного (основного) серверу резервного. Після кожної
операції основний сервер передає змінені дані резервному, який автоматично включається у разі виходу з ладу основного. Природно, така
схема не позбавлена недоліків. По-перше, це призводить до значних накладних витрат при дублювання даних, що не тільки позначається на
продуктивності, але й саме по собі є потенційним джерелом збоїв. По-друге, у разі збою, що спричинило за собою розрив з'єднання між двома
серверами, кожен з них повинен буде працювати в своєму сегменті мережі в якості основного сервера, причому зміни, зроблені на серверах за час роботи в
такому режимі, буде неможливо синхронізувати навіть після відновлення працездатності мережі.
Більш досконалим є підхід, коли створюється необхідне (підбирається у відповідності з необхідним рівнем надійності) число
копій в сегменті. Таким чином збільшується доступність копій і навіть (при розподілі навантаження між серверами) підвищується швидкість читання. Проблема
допускати оновлення даних декількома серверами одночасно у разі їх взаємної недоступності вирішується за рахунок дозволу проведення модифікацій
тільки в одному з сегментів, наприклад що має найбільше число користувачів. При добре налагодженої схемою кешування витрати на накладні витрати при
дублювання модифікованих даних близькі до нуля.
5.3 Стандарти
об'єктних баз даних.
Для забезпечення переносимості додатків (додаток може працювати на різних СУБД) і сумісність з СУБД (може взаємодіяти з
різними СУБД), природно, необхідне вироблення стандартів. Відразу зауважимо, що встановлення стандартів позбавляє виробника до деякої міри свободи в
прийнятті рішень і збільшує вартість продукту за рахунок ліцензійних відрахувань і більше не будемо обговорювати доцільність (прямо скажемо,
очевидну) стандартизації.
В області об'єктних СУБД в даний час вироблені стандарти для:
об'єктної моделі;
мови опису об'єктів;
мови організації запитів (Object Query Language - OQL);
"сполучного" мови (C + + і, звичайно ж, Smalltalk);
адміністрування;
обміну (імпорт/експорт);
інтерфейсів інструментарію та ін
Хоча в Microsoft і свою думку з цього приводу, організацією, виробила найбільш використовувані на
сьогодні і усталені стандарти, є консорціум постачальників ООСУБД ODMG (ООСУБД), якого підтримують
практично всі дійові особи галузі. У співпраці з OMG, ANSI, ISO та іншими
організаціями був створений стандарт ODMG-93. Цей стандарт включає в себе засоби для побудови
закінченого додатка, що буде працювати (після перекомпіляції) в будь-якій сумісній з цією специфікацією ООСУБД. До книги ODMG-93 входять наступні розділи:
Мова визначення об'єктів (Object Definition Language - ODL);
Мова об'єктних запитів (Object Query Language - OQL);
Малюнок 4 Схема використання ODL для побудови додатку.
Зв'язування з C ++;
Зв'язування з Smalltalk.
ODL. В якості мови визначення об'єктів (ODL) ODMG був обраний існуючий мова IDL
(Interface Definition Language - мова опису інтерфейсів), який був доповнений такими необхідними для
об'єктних БД властивостями, як визначення колекцій, двонаправлених зв'язків типу "багато-до-багатьох", ключів та ін У поєднанні із засобами мови IDL визначення атрибутів і операцій, це дозволяє визначати практично будь-які об'єкти. Всі доповнення реалізовані у вигляді
довизначення методів, що забезпечує сумісність зі стандартами OMG, наприклад стандартом CORBA.
Малюнок 4 показує працездатну схему для побудови програми на стандартних мовах програмування, в процесі якої автоматично
генеруються метадані, заголовки та методи. Наведемо також приклад мовою ODL з "білої книги" компанії Objectivity, який
ілюструє зв'язку типу "один-ко-многим", оголошені між викладачем і студентами:
interface professor: employee (
attribute string name;
unique attribute lang unsigned ssn;
relationship dept works_in inverse faculty; relationship set
teaches inverse taught_by;. . . operations. . .
(
interface section: class (
. . . taught_by: professor. . . ;
. . .
)
OQL. За основу мови OQL була взята команда SELECT мови SQL2 (або SQL-92) і додані можливість
направляти запит до об'єкта або колекції об'єктів і можливість викликати методи в рамках одного запиту. Дані, отримані в результаті запиту, можуть
бути скалярними (включаючи кортежі), об'єктами або колекціями об'єктів. Деякі приклади на
мовою OQL (той же джерело):
• Select x from x in faculty where x.salary>
x.dept.chair.salary
•
sort s in (select struct (name: x.name, s: x.ssn) from
x in faculty where for all y in
x.advisees: y.agename = "Smith";
prof-> age + prof-> age 1;
На цьому, мабуть, почуття вдячності компанії Objectivity значною мірою ослабне, тому що прикладів на мові Smalltalk знайти не вдалося.
Smalltalk . ODMG-93 підтримує ту ж об'єктну модель для Smalltalk, що і для C + +, IDL та запити на мові OQL; це дозволяє розділяти
один і той самий об'єкт користувачам С + + і Smalltalk. Специфікація підтримує типи (можливі бестіповие поля) і синтаксис оригінальній версії Smalltalk.
Малюнок 5 ООСУБД, побудована на основі стандартів ODMG у взаємодії з CORBA.
Взаємодія з іншими стандартами. Багато стандарти сумісні з об'єктними базами даних, наприклад STEP, CFI,
TINA-C, ISO ODP, ANSI X3H7, OpenGIS та ін Зараз вони можуть безпосередньо взаємодіяти з будь-якою стандартною ООСУБД, хоча в деякі з них і були
внесені зміни для забезпечення сумісності. Два інших стандарти заслуговують більш детального опису - OMG
і SQL.
Стандарти OMG. Першим результатом діяльності OMG стало твердження (OMG не створює стандартів, а
приймає одну з існуючих реалізацій) архітектура брокера об'єктних запитів (Common Object Request Broker Architecture - CORBA) --
засоби диспетчеризації запитів між об'єктами і користувачами; в подальшому були додані деякі сервіси. Інтерфейс ODMG зараз повністю
адаптований до специфікації Persistence Object Service консорціуму OMG, що дозволяє користувачам систем, заснованих на архітектурі
CORBA, користуватися перевагами від ООСУБД, які можуть містити об'єкти, що відповідають стандарту OMG і використовуються так само, як і будь-які інші ( "дрібні")
об'єкти специфікації OMG (Малюнок 5). Об'єкти OMG в свою чергу доступні через інтерфейс ODMG.
Мова SQL. З-за поширеності SQL був закладений в основу OQL,
який був доповнений засобами підтримки об'єктної моделі. В даний час розробляється версія мови SQL,
відома під назвою SQL3, в якій буде реалізована підтримка об'єктів і SQL буде приведений у відповідність сучасним поняттям про повноцінний мовою
програмування. На відміну від ODMG, в SQL не планується прив'язка до ODL, а також C + + і Smalltalk, які
важливі для користувачів ООСУБД. Незважаючи на це, можливості SQL3 в організації запитів збігаються з можливостями OQL. Коли SQL3 буде готовий (розробки ведуться зараз на ранній
стадії обговорення основних питань щодо об'єктної моделі), ODMG, ймовірно, доповнить його, як це вже зроблено для C + + і Smalltalk.
5.4
Постачальники ООСУБД.
Малюнок 6 Сучасний ринок СУБД.
Список сучасних комерційних об'єктно-орієнтованих систем включає в себе такі продукти:
Objectivity/DB компанії Objectivity, Inc. (остання версія - 2.1) ідеально, за
заявами фірми, підходить для додатків, які працюють в розподілених середовищах, вимагають гнучкої модифікації даних, організації складних зв'язків, а також
потребують високої продуктивності і роботи з великими об'ємами даних. Ймовірно, всі компанії, що виробляють ООСУБД, ставлять собі за мету скласти таке
враження щодо власних розробок у читачів поширюваних ними документів (хоча деякі і роблять це в більш делікатній формі). Більше
змістовно, Objectivity забезпечила інтеграцію інструментарію СУБД і розробки додатків з такими
засобами програмування, як SoftBench і C + + SoftBench. Завдяки інтегрованого графічного інтерфейсу розробки схеми БД та інструментів
налагодження та аналізу спрощується завдання моделі бази даних і, відповідно, розробки додатків для Objectivity/DB.
СУБД GemStone корпорації GemStone Systems, Inc. відома
в останній редакції під номером 5.0. GemStone традиційно зосереджена на ринку Smalltalk (хоча не так давно і була випущена версія для C + +) і має
замовників, здатних продемонструйать на виробництві великомасштабні, цільові застосування її продуктів. На жаль, списком цих замовників обсяг
інформації, яку компанія хоче донести до цікавляться (WWW), обмежується.
ONTOS Corp., розробник СУБД ONTOS (хто б
подумав), за традицією займається розвитком сервера об'єктно-орієнтованої СУБД, але останнім часом надає особливого значення своїм Служб Інтеграції
Об'єктів (Object Integration Services).
Побудована на основі реляційної СУБД AllBase, система OpenODB фірми Hewlett- Packard також, як і Objectivity/DB,
інтегрована з системою SoftBench й існує у версії для C + +. Завдяки глибокій інтеграції, SoftBench розпізнає файли додатків OpenODB для встановлення оптимальної
конфігурації, може створювати бази даних формату OpenODB зі своєї інтегрованого середовища, забезпечує оперативну допомогу з середовища розробки і т. д.
Object Design Inc. зі свого СУБД ObjectStore займає
лідируюче положення в галузі, здійснюючи близько 33% поставок на ринку об'єктно-орієнтованих СУБД і остання модернізація системи (клієнт мови
SQL і шлюз до реляційної СУБД) повинні лише зміцнити становище фірми. Object Design підтримує версії
своєї СУБД як для С + +, так і для Smalltalk.
Versant Object Technology, Inc. (СУБД Versant ) проводить подвійну
стратегію, пропонуючи засіб забезпечення об'єктно-орієнтованої СУБД високого класу для телекомунікацій та інструментальні засоби для Smalltalk
більш загальних випадків розробки додатків. Використовуючи розроблений фірмою інтерфейс VERSANT Smalltalk Language Interface, СУБД сумісна як з версією
мови Smalltalk компанії ParcPlace-Digitalk, так і з Visual Age for Smalltalk корпорації IBM.
СУБД UniSQL компанії UniSQL Inc. - добре
усталена система, що дозволяє користувачам здійснювати запити і модифікацію бази за допомогою розробленого компанією мови SQL/X (подібні мови, які мають умовну назву Object SQL, розроблені і деякими
іншими постачальниками). Вся БД UniSQL може складатися одночасно із зв'язків у локальних РСУБД і
класів в локальних об'єктних базах UniSQL. Завдяки механізму каталогів, СУБД передає запити і
модифікації даних в локальні бази даних і, обробивши (переклад в інший формат, групування, сортування і т. д.) отриманий від них результат,
повертає його користувачеві.
Крім того ООСУБД пропонують: Object Database, Inc. (Object Database), Itasca
Systems Inc. (Itasca) O2 Technology (O2) і деякі інші компанії.
6. Висновок.
У 1996 р. намітився помітний зсув в області освоєння об'єктних СУБД. Уже існують приклади практичного їх використання великими
біржами, банками, страховими компаніями, а також у сфері виробництва і телекомунікацій, де баз даних, що містять гігабайти інформації, доводиться
обслуговувати сотні користувачів. Вони виявилися хорошою альтернативою у тих випадках, коли застосування реляційних БД змушувало будувати складну схему з
надмірно великим числом межтаблічних зв'язків.
Завдяки значного прогресу у розвитку об'єктної технології, за останні п'ять років виробникам вдалося довести свої ООСУБД до
такого рівня, що вони стали цілком відповідати реальним вимогам ринку.
Незважаючи на те, що технологія об'єктних СУБД дозріла дл
