Об'єктно-орієнтовані СУБД

Оъекгно-СУБД.

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).

дозволяли кінцевим користувачам, не являющимсяпрофессиональными програмістами,.

отримувати доступом до інформації без детального описи кожного кроку, але з.

умонтованими спричиненими типами даних- наприклад, таблицами.

Останнім кроком у цьому напрямі стала объектно-ориентированная.

технология, радикально змінила сферу розробки програмного забезпечення вже у.

90-х роках (Рисунок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?

«Білими книжками» під назвою, винесеним в заголовок, з головою забезпечить будь-яка.

компанія, що займається об'єктними базами даних. Кое-чтоо перевагах та.

недоліках объектно-ориентированных СУБД згадувалося вище, підіб'ємо у тому.

разі итог.

Об'єктно-орієнтовані бази даних застосовуються з кінця 80-х задля забезпечення.

управління базами даних додатками, побудованими всоответствии з концепцією.

объектно-ориентированного програмування. Объектная технологія розширює.

традиційну методику розробки додатків новыммоделированием даних, і.

методами програмування. Для використання коду і поліпшення.

схоронності цілісності даних в об'єктному программированииданные і код їхнього.

обробки зорганізовані у об'єкти. Отже, практично цілком знімаються.

обмеження на типи данных.

Якщо є складаються з коротких, простих полів фіксованою довжини (ім'я, адресу,.

баланс банківського рахунки), то найкращим рішенням будетприменение реляційної бази.

даних. Якщо, проте, дані містять вкладену структуру, динамічно.

изменяемый розмір, зумовлені пользователемпроизвольные структури.

(мультимедіа, наприклад), уявлення в табличній формі буде, принаймні,.

непростим. У той самий час у ООСУБД кожна определеннаяпользова телем структура -.

це об'єкт, безпосередньо керований базою данных.

У РСУБД зв’язку управляються користувачем, що створює зовнішні ключі. Потім для.

виявлення зв’язків динамічно під час виконання системапросматривает дві (чи.

більше) таблиці, порівнюючи зовнішні ключі до відповідності. Цей.

процес, званий об'єднанням (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);

«зв'язувальної» мови (З++ звісно ж, 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 p. 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.

З++. Специфікація 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, і навіть З++ і Smalltalk, которыеважны для.

користувачів ООСУБД. Попри це, можливості SQL3 у створенні запитів.

збігаються з можливостями OQL. Коли SQL3 буде готовий (розробки ведуться.

на раннейстадии обговорення основних питань щодо об'єктної моделі),.

ODMG, мабуть, доповнить його, що й зроблено З++ і Smalltalk.

5.4Поставщики ООСУБД.

Малюнок 6 Сучасний ринок СУБД.

Список сучасних комерційних объектно-ориентированных систем включає у собі.

такі продукты:

Objectivity/DB компанії Objectivity, Inc. (остання версія — 2.1) ідеально,.

позаявлениям фірми, адресований додатків, які працюють у розподілених.

середовищах, вимагають гнучкою модифікації даних, організації складних зв’язків, а.

такженуждаются у високій продуктивності і з великими обсягами.

даних. Мабуть, всі компанії, що виробляють ООСУБД, ставлять за мету.

скласти такоевпечатление щодо власних розробок у читачів.

розповсюджуваних ними документів (хоча дехто й роблять це в.

делікатній формі). Болеесодержательно, Objectivity забезпечила інтеграцію.

інструментарію СУБД і розробки додатків з такимисредствами.

програмування, як SoftBench і З++ SoftBench. Завдяки інтегрованому.

графічної інтерфейсу розробки схеми БД і инструментамотладки і грунтовного аналізу.

спрощується завдання моделі бази даних, і, відповідно, розробки додатків.

для Objectivity/DB.

СУБД GemStone корпорації GemStone Systems, Inc. известнав останньої редакції.

під номером 5.0. GemStone традиційно зосереджена над ринком Smalltalk (хоча.

нещодавно і було випущена версія для З++) і имеетзаказчиков, здатних.

продемонструвати з виробництва великомасштабні, цільові застосування.

продуктів. На жаль, списком цих замовників объеминформации, яку.

компанія хоче донести її до цікавляться (WWW), ограничивается.

ONTOS Corp., розробник СУБД ONTOS (хто быподумал), традиційно займається.

розвитком серверу объектно-ориентированной СУБД, але протягом останнього час надає.

особливе значення своїм Службам ИнтеграцииОбъектов (Object Integration.

Services).

Побудована з урахуванням реляційної СУБД AllBase, система OpenODB фірми.

Hewlett-Packard як і Objectivity/DB, интегрирована і системи SoftBench.

і є в версії для З++. Завдяки глибокої інтеграції, 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),.

ItascaSystems Inc. (Itasca) O2 Technology (O2) та інших компании.

6.

Заключение

.

У 1996 р. намітився помітний зрушення у сфері освоєння об'єктних СУБД. Вже.

є приклади практичного їх використання крупнымибиржами, банками,.

страхові компанії, соціальній та сфері виробництва та телекомунікацій, де.

баз даних, що містить гігабайти інформації, приходитсяобслуживать сотні.

користувачів. Вони були хорошою альтернативою у випадках, коли.

застосування реляционных БД змушувало будувати складну схему счрезмерно великим.

числом межтабличных связей.

Завдяки значному прогресу у розвитку об'єктної технології, протягом останніх.

п’ять років виробникам вдалося довести свої ООСУБД дотакого рівня, що вони.

стали цілком відповідати реальним вимогам рынка.

Попри те що, що технологія об'єктних СУБД дозріла до великих проектів, для.

справді масового розповсюдження необходимспециальный инструментарий.

Нині відчувається нагальна потреба у інтеграції ООСУБД з.

існуючими інструментальними засобами. Разработчикиуже сьогодні міг би.

продуктивно використовувати версії Visual Basic, Power Builder, Forte чи Delphi,.

підтримують ООСУБД. Большинство продуктів до створення додатків у тієї чи тієї.

тією мірою є объектно-ориентированными, але працюють як і з.

реляционными БД. Специалисты вважають, що партнерство виробників ООСУБД і.

коштів програмування може призвести до появі такого.

необходимогоинструментария.

Експерти вже неодноразово оголошували наступний Новий рік «роком об'єктних баз.

даних", проте нині все свідчить, що 1997 г. действительно має.

нарешті їм стати. Основними стимулами зростаючого інтересу до ООСУБД аналітики.

вважають розширення применениямультителиа-приложений і нових засобів, що поліпшують.

їх стыкуемость з базами данных.

7. Глоссарий.

4GL (4th Generation Language) — Мова програмування четвертого покоління.

?Языкпрограммирования, під час створення якого використовуються мови програмування.

третього рівня (3GL) -процедурні мови типу З і Pascal. 4GL простіше в.

використанні, ніж 3GL, їм зазвичай віддають перевагу під час упорядкування програм.

обслуговування баз даних, і застосовують всочетании з відповідними засобами.

разработки.

Blob (Binary Large Object) — Двоїчний великий об'єкт, блоб. ?Длинныйлинейный.

блок даних (наприклад, цифрове зображення чи відеокліп), який найбільш.

адресований зберігання ЕВР у ООСУБД.

CORBA (Common Object Request Broker Architecture) Архітектура брокера об'єктних.

запитів ?Стандартвзаимодействия розподілених компонентів, розроблений OMG.

DBMS (Database Management System) — Систему керування базами даних, СУБД.

N — звенная архітектура (N-Tier Model) ?Архитектура клиент-серврер, у якій.

застосовуються кошти розбивки программили розподілені об'єкти потреби ділити.

обчислювальної навантаження серед такої кількості серверів додатків, яке.

необхідно за наявного уровненагрузки. При многозвенной моделі системи.

кількість можливих клієнтських місць значно більше, аніж за використанні.

двухзвенной моделі. Див також middleware.

ODBMS (Object Database Management System) — Объектно-ориентированная СУБД -.

ООСУБД. ?СУБД, що зберігає дані і взаємозв'язку між її елементами безпосередньо.

у самій базеданных як об'єктів, містять, зазвичай, алгоритми обробки.

цих данных.

ODMG (Object Database Management Group) ?Консорциум производителейобъектных баз.

даних розробки стандартів (ODMG-93, ODMG-95).

OMG (Open Management Group) ?Консорциум постачальників всфере об'єктної технології.

розробки стандартів межкомпонентного взаємодії. Об'єднує практично.

усіх провідних виробників (більш чем500); членство Microsoft, певне, лише.

условно.

OQL (Object Query Language) Мова об'єктних запитів ?Разработанныйконсорциумом.

ODMG мову описи запитів, в основі якого було прийнято SQL-92.

RDBMS (Relational Database Management System) — Реляційна СУБД — СУБД,.

що зберігає взаємозв'язку междуэлементами як двовимірні таблиць і яка використовує для.

запитів мову SQL.

SQL (Structured Query Language) — Мова структурованих запитів.

?Интерпретируемыйязык, описує операції (створення, обробка й витягування).

над реляционнымибазами данных.

Архітектура клієнт-сервер (Client-server architecture) ?Архитектура,.

обеспечивающаяраспределение навантаження між клієнтом і сервером. Зазвичай це.

функції виконують дві різні комп’ютера, об'єднаних з допомогою сети.

Атрибути (Attributes) ?Видимая поза об'єкта інформацію про стані.

цього объекта.

«Білу книгу» (White Paper) ?Официальноеиздание.

Гібриди (Hybrids) ?1. Засоби зв’язку між світами об'єктних і реляционных баз.

даних, включаючи базыданных, які зберігають інформацію в реляційної формі, але.

використовують об'єктні буферні кошти. Див. також объектно-реляционныеметоды 2.

СУБД, що потенційно можуть зберігати і табличні дані, і об'єкти. Цього визначення я.

старалсяпридерживаться.

Ідентичність (Identity) ?Возможность отримання унікального адреси об'єкта.

незалежно з його місцеположення і атрибутов.

Інкапсуляція (Encapsulation) ?Объединениеданных і коду до одного модуль — об'єкт,.

доступом до якому може здійснювати аж через суворо певний.

интерфейс.

Метадані (Metadata) ?Данные, є описом інших даних (наприклад,.

схема бази даних із відношенню кее содержимому).

Успадкування (Inheritance) ?Механизм, завдяки якому вона визначення класу.

поширюється на класи, що лежать нижеего в ієрархії узагальнення класів. Це.

дозволяє багаторазово змінювати визначення, вносячи за необхідності.

зміни, пов’язані соспециализацией.

Объектно-реляционные методи (Object-relational Approaches) ?Подходы,.

позволяющиевоспользоваться перевагами об'єктних баз даних, не відмовляючись.

повністю від реляционных БД.

Відображення (Mapping) ?Процесс встановлення перетинів поміж додатками,.

побудованими вокругобъектно-ориентированных і реляционных баз данных.

Поліморфізм (Polymorphism) ?Способностьобъектов різних класів та самих.

класів задовольняти у тому ж протоколів чи.

сообщениям, выполняя у своїй різні дії, передбачені їх своїми.

методами.

Проміжне забезпечення (Middleware) ?ПО, служащее посередником між клієнтом.

і сервером, наприклад, надання загальних інтерфейсів. Дотримуючись традиції, і це.

теж напишу, що проміжне ПО — этослэш в терміні «клиент/сервер».

Протокол (Protocol) ?Набор повідомлень, куди зміг відповісти клас (протокол.

класу) або його объекты (протокол об'єкта). Протокол визначається заданими.

методами. Усі об'єкти одного класу відповідають одному протоколу.

СУБД — Система Управління Базами Данных.?Лежащая основу бази данныхприкладная.

програма, виконує операції над береженої информацией.

Транзакція (Transaction) — обробка запиту? Выполнение элементарнойцелостной.

операції над даними, протягом якого база даних перебуває у нестійкому.

состоянии.

ООСУБД (ODBMS) — Объектно-Ориентированная Система Управління Базами Данных.