О'екгно-СУБД
Зміст
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.1Why 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.age
• Chair.salary
• Students except TAs
• list (1,2) + list (count (jse.advisees), 1 +2)
• exists x in faculty [1: n]: x.spouse.age
C + +. Специфікація ODMG-93 дозволяє програмістам легко використовувати об'єкти в
той час як ООСУБД прозрачнимобразом керує ними. При визначенні стандарту
члени ODMG керувалися наступними принципами:
Використання стандартних компіляторів забезпечується тим, що всі розширення
реалізуютсясредствамі мови - бібліотеками класів і перевантаженням операторів.
Визначення тимчасових примірників (Transient Instance) і примірників,
створюваних на тривалий термін (Transient Instance) пріпомощі оператора new ().
У разі перевантаження оператора new () обидва типи примірників можуть створюватися від
одного класу, який може існувати продолжітельноевремя.
Забезпечення стійкості через стандартний механізм спадкування; користувач
можетопределять екземпляри тимчасові і розраховані на тривалий
використання засобами оригінальній версії мови.
Використання спеціального механізму покажчиків (Smart Pointers). Зв'язок між
об'єктами оголошуються за допомогою шаблону Ref і перевантаження оператора ->; це
дозволяє використовувати спеціальні покажчики (контрольовані системою; см.,
наприклад, ідентичність в словничок (стор. 21) і згадка косвеннойадресаціі
(стор. 10) як звичайні.
class Professor: Employee (
long ssn;
char * name;
int age;
Refdept inverse faculty;
Set teachesinverse taught_by;
. . .
void grant_tenure ()
void assign_course (section)
)
. . .
Refprof;
. . .
prof = new (db, Professor);
prof-> name = "Smith";
prof-> age + prof-> age 1;
На цьому, мабуть, почуття вдячності компанії Objectivity значною мірою
ослабне, тому що прикладів на мові Smalltalk знайти не вдалося.
Smalltalk. ODMG-93 підтримує ту ж об'єктну модель для Smalltalk, що і для
С + +, 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% п
