Маніфест систем об'єктно-орієнтованих баз даних

Манифест систем объектно-ориентированных баз данных

1. Введение

В період із 1989 по 1995 рр. авторські групи, які включають відомих спеціалістів у галузі баз даних, підготували і опублікували три документа [1−3], що відбивали погляду авторів щодо розвитку технології баз даних. З її легкої руки авторів хронологічно першого документа цих документів дістали назву маніфестів, що, загалом, відбивало їх суть: у кожному з документів проголошувався набір ідей вимог, у яких, на думку авторів, мали базуватися системи баз даних наступного поколения.

Интересно відзначити різницю між колективами авторів кожного з маніфестів. «Маніфест систем объектно-ориентированных баз даних» [1] (далі у цій статті для стислості ми називати його Першим маніфестом) написано академічними дослідниками; майже всі є професорами різних університетів. Звісно, це виявилося у стилі Першого маніфесту — дуже м’якому і помірковано рекомендаційному (хоча слідство з духом пропозиції цього маніфесту були дуже радикальными).

Авторы документа «Системи баз даних третього покоління: Маніфест» (Другого маніфесту) були представниками індустрії (вірніше, индустриально-ориентированных досліджень). Другий маніфест писався у більш жорсткому стилі часу та багато в чому спрямовано захист інвестицій великих компаній-виробників програмного забезпечення SQL-ориентированных СУБД. Звісно, Другий маніфест багато в чому був реакцію індустрії на революційні пропозиції Першого маніфесту. Ці пропозиції піддавалися критиці, але якщо дуже грубо, критика в тому, що, по думці авторів Другого маніфесту, можна домогтися аналогічних результатів, не виробляючи революцію у області технології баз даних, а еволюційно розвиваючи технологію SQL-ориентированных СУБД.

«Третий маніфест» (і називатимемо його далі) був одночасно найбільш консервативним і буде найрадикальнішим. Консервативність Третього маніфесту у тому, що його усіма силами стверджують необхідність, і достатність використання їх у системах базах даних для наступного покоління класичної реляційної моделі даних. Радикальність у тому, що (a) автори абсолютно заперечують підходи, пропоновані у перших двох маніфестах, розцінюючи їх як необгрунтовані, погано опрацьовані, надлишкові і навіть шкідливі (крім однієї загальної ідеї про потреби забезпечення розвиненою системи типів); (b) фактично, автори повністю відкидають технологію, створену індустрією баз даних протягом останніх 25 років, і пропонують повернутися до початків реляційної моделі даних, тобто. до початковим статтям Еге. Кодда [4].

После видання маніфестів відбулися середньому близько 20 років. Як здається автору цієї статті, що час озирнутися і оцінити, яким чином реально вплинули цих документів в розвитку технології баз даних. Чи справдилися очікування авторів хоча самого з маніфестів? Не час придумувати новий маніфест, або ж час маніфестів минуло? У цій статті не робляться спроби зазирнути у майбутнє (як історія, це завдання є невдячною й безнадійною). Обмежимося поглядом на недавнє минуле і настоящее.

В наступних далі з трьох основних розділах статті по черзі обговорюються основні ідеї маніфестів, і розглядається їхнього впливу розвиток відповідних напрямів області баз даних. Усі наведені характеристики відбивають виключно особисте (та значною мірою суб'єктивне) думка автора.

Объектно-ориентированные СУБД

В останньому підрозділі цього розділу ми обговоримо специфічних рис найвідоміших і поширених у світі ООСУБД. Важко гарантувати, що це обговорення цілком відповідає поточному становищу справ, оскільки змінюється нас дуже швидко, і те, що пишеться сьогодні й цілком відповідає істинному стану справ, може бути ні (чи не) вірним завтра. Але, тим щонайменше, ми вважаємо, що така підрозділ повинен бути присутнім на розділі про Перший маніфест, щоб показати читачам реальне (чи близький до реальному) стан справ у відповідної області інформаційної технологии.

Немного истории

В початку 80-х рр. усвідомлення корисності объектно-ориентированного підходу стосовно логічного організації баз даних призвела до того, що чимало дослідники розпочали творення ООСУБД. У ранніх проектах ООСУБД брали участь групи з університетів й дослідних інститутів, провідних комп’ютерних компаній, і невеликих початківців компаній.

Университетские дослідницькі групи внесли величезний внесок у розвиток технології баз даних, але тільки у сфері реляционных систем. Багато університетські дослідники охоче прийняли объектно-ориентированный підхід, особливо у застосування до області людино-машинних взаємодій. До успішним проектам, у яких проводилися дослідження з об'єднання объектно-ориентированного підходу технологією баз даних, можна віднести следующие:

Encore в Брауновском університеті (Broun University);

Cactis в Колорадском університеті (University of Colorado at Boulder);

Thor в Массачусетському технологічному інституті (MIT);

Exodus в Вісконсинському університеті (University of Wisconsin);

Pisa в університетах Глазго і Св. Ендрю (Universities of Glasgo and St. Andrew).

Среди дослідних інститутів, у яких існували потужні групи, зорієнтовані дослідження у сфері объектно-ориентированных баз даних, входили OGI (Oregon Graduate Institute), MCC (Microelectronics and Computer Technology Corporation) й французький дослідницький центр INRIA. На базі досліджень OGI було створено ООСУБД Gemstone; дослідження, які проводилися в MCC, увінчалися створенням ООСУБД Itasca і UniSQL; внаслідок дослідницького проекту Altair, выполнявшегося в INRIA, з’явилася ООСУБД O 2.

Среди найзначніших прототипів ООСУБД, створених у результаті, які проводились провідних комп’ютерних компаніях, можна назвати систему IRIS компанії HewlettPackard і системи Trellis компанії DEC. Ідеї та фізичні методи, закладені у ці проекти, були згодом використані більшості комерційних ООСУБД. Проте, керівники великих компаній вирішили не виробляти комерційні ООСУБД самостійно, а надати таку можливість початківцям компаниям.

Первыми компаніями, выпустившими ринку ООСУБД в вигляді закінчених продуктів, були такі компании:

Grapael сООСУБД G-Base (1986 р);

Servio-Logic сООСУБД Gemstone (1987 р.);

Symbolics сООСУБД Statice (1988 р.);

Ontologic Ltd. сООСУБД Vbase (1988 р.).

Ко всім раннім реалізаціям ООСУБД применительны такі замечания.

Системи були неприйнятні для практичного використання, оскільки вони повільно працювали, підтримували лише однокористувальницький режим роботи були вкрай ненадійні. Вони не підтримувалися розподілені дані, безпека продукції та можливість відновлення після збоїв. Майже у всіх системах були відсутні розвинені механізми формулювання запитів. При побудові користувальних інтерфейсів не використовувалися навіть які були результати, отримані групами в галузі людино-машинних взаємодій.

Розробники практично всіх систем повністю ігнорували мову З ++, оскільки вважалося, що «застосування цього мови у тих ООСУБД спричиняє істотні проблеми. У системах GBase і Statice використовувався Lisp; Gemstone спиралася на Smalltalk; для Vbase були розроблено власні мови визначення даних (TDL) і маніпулювання даними (COP). У дослідницьких групах також не хотіли спиратися на З ++, а розробляти нову мову, більшою мірою відповідні напрямку досліджень. Серед негативних наслідків ігнорування З ++ було те, що користувачів змушували вивчати новий мову; вони вынуждались одночасно використовувати дві мови; відсутність підтримки З ++ обмежувало ринок ООСУБД.

Новые компанії Objectivity, Object Design і Versant, освічені наприкінці 80х, орієнтувалися створення ООСУБД, які спиралися на З ++. Компанія Ontologic відмовилася з розвитку Vbase і переключилася розробці системи ONTOS, заснованої на З ++. У Європі були утворені компанії O 2Technology і BKS Software. Завданням першої компанії було створення комерційної ООСУБД O2 49 з урахуванням результатів проекту Altair. BKS початку розробку системи POET. У 90-х роках для реалізації комерційних проектів, заснованих на виключно результатах MCC, створили компанії UniSQL 50 і Itasca .

К кінцю 90-х існувало близько 10 компаній, які виробляють комерційні продукти, позиционируемые над ринком як ООСУБД. Кожен продукт мав індивідуальними особливостями, частково определяемыми життєвим досвідом розробників, але здебільшого проистекающими з вимог клієнтів компанії. Далі у тому підрозділі ми коротко охарактеризуємо найвідоміші комерційні ООСУБД, а висновок підрозділу опишемо сучасний стан справ у сфері ООСУБД (яке, на думку автора, є не блестящим).

GemStone

Как уже відзначалося вище, ООСУБД GemStone було одним із перших комерційно доступних ООСУБД. Система розробили компанією ServioLogic що з OGI. У вихідному варіанті системи розробники GemStone спиралися мовою Smalltalk. Хоча у перших випусках системи її основний мову називався Opal, відразу бачили, що насправді усього цього лише Smalltalk із підтримкою стабільного зберігання об'єктів, і назва мови було замінено на GemStone Smalltalk. Згодом у GemStone була забезпечена підтримка мов З і З ++, але в усі часи базовим мовою залишався Smalltalk, проте інші інтерфейси будувалися поверх базового. І серверна, і клієнтська частини системи можуть працювати під керівництвом всіх основних гілок ОС UNIX й коштовності всіх розвинених варіантів Windows. Нині продукт підтримується, розвивається й поширюється компанією GemStone Systems Inc.

Система полягає в триланкової архітектурі клієнт-сервер, у якій прикладна обробка даних виготовляють середньому рівні між процесом взаємодії з користувачем і процесом, які підтримують сховище даних. Важливість цього підходу у тому, що, тоді як додатку використовується багато даних, то код докладання доцільно розмістити за сховища даних, і якщо при застосуванні виробляється багато змін над невеликим обсягом даних, то можна буде розмістити код докладання за користувача. Тим самим було, архітектура дозволяє зменшити обсяг мережного трафіку без перевантаження серверу, що підвищує швидкість обробки данных.

Для управління мультидоступом використовується механізм транзакцій. Механізм грунтується на так званому оптимістичному підході, при якому кожна сесія працює із власної локальної копією сховища об'єктів, і злиття вирощених сесіях змін сховища відбувається за завершенні транзакції. Якщо за завершенні транзакції можна знайти, що вироблені у ній зміни конфліктують зі змінами інших раніше зафіксованих транзакцій, то фіксація транзакції немає, транзакція не завершується, і розв’язання проблеми доручається користувача. Автоматична блокування об'єктів немає, але користувач може явно запросити блокування, що підвищує шанси на успішну фіксацію транзакции.

Для забезпечення безпеки даних підтримується механізм авторизації доступу лише на рівні власника об'єкту і його групи користувачів, отже можна обмежувати доступом до деяким об'єктах чи деяким методам об'єктів. До кожного об'єкту приписується авторизационный об'єкт, у якому дані про те, які користувачі у якому режимі (читання чи зміни) мають доступом до объекту.

Для відновлення бази даних після збоїв апаратури використовуються механізми реплікації, резервного копіювання і журнализации. Будь-який авторизований користувач може запросити виконання повного чи часткового копіювання. Відновлення бази даних після збою системи чи дискових пристроїв починається з використання останньої за часом резервної копії. Після цього за допомоги даних, збережених журнальних файлах, сховище об'єктів наводиться до стану, відповідному останньої досі збою зафіксованої транзакції. Авторизовані користувачі можуть також запросити підтримку реплицирования областей сховища даних.

В системі підтримується цілісність по посилань між усіма об'єктами, бо всі посилання грунтуються на використанні об'єктних ідентифікаторів, і об'єкти, котрим існують посилання від інших об'єктів, неможливо знайти віддалені. На підвищення швидкості доступу до часто що використовуються колекціях забезпечується засіб побудови індексів.

Объекты робляться стабільними (тобто. зберігаються у базі даних) шляхом застосування свого роду стабільного кореня, званого коннектором. Усі об'єкти, безпосередньо чи опосередковано досяжні по об'єктним посилань від коннектора, є стабільними. У GemStone кожного класу, у якому існує хоча б тільки стабільний об'єкт, підтримується еквівалентна серверна версія класу. Інакше кажучи, один варіант класу служить класом в контексті програмування, а інший — у тих бази даних. Такі пари підтримуються автоматично: якщо створюється клас у сенсі Smalltalk, і певний об'єкт цього стає стабільним, то автоматично створюється серверний клас цього об'єкта (клас, у сенсі GemStone). Створення коннектора призводить до появи примірника класу GemStone, еквівалентного класу об'єкта, що має бути зроблено стабільним. Аналогічно, будь-який об'єкт, досяжний від коннектора, автоматично стає стабільним.

В GemStone підтримується динамічна складання сміття (garbage collection). Процесс-«мусорщик» автоматично звільняє пам’ять, зайняту об'єктами, куди відсутні ссылки.

В середовищі GemStone можна використовувати різні реалізації Smaltalk, і навіть мови З і З ++. Класи і об'єкти можна з допомогою будь-якої з цих мов, і об'єкти, створені однією мовою можна залучити до додатках, написаних будь-якому іншому мові. Реалізація мови З є набір функцій й створили набір компонентів, перетворюючих об'єкти GemStone в покажчики і литералы З і навпаки. Реалізація З ++ включає препроцесор в чистий З повагою та бібліотеку классов.

Подключения до реляционным системам (наприклад, Oracle чи IBM DB 2) виробляються через шлюзи. Для синхронізації стану локальної (керованої GemStone) і зовнішніх копій даних забезпечується автоматична модифікація даних. Залежно середовища проживання і вимог до рівня синхронизованности ці відновлення виконуються негайно або ж пакетному режиме.

GemStone можна також ознайомитися використовуватиме управління даними, відповідними стандартам OLE і CORBA. Робота з цими в реляционном стилі підтримуються стандарти SQL і ODBC .

ITASCA

Распределенная ООСУБД ITASCA полягає в результатах проекту Orion, выполнявшегося в MCC. Розробка серії із трьох прототипів завершилася випуском системи, заснованої на архітектурі «багато клиентов-много серверів». Система було доведено рівня комерційного продукту початкуючою техаської компанією, що у 1995 р. придбала компанією IBEX Corp .

В розподіленої архітектурі ITASCA приватні та спільно використовувані бази даних рознесені по вузлам локальної UNIXорієнтованої мережі. Кожній значення даних зберігається щодо одного вузлі, але централізоване управління відсутня; все сервери автономні. На кожному сервері підтримуються кеш сторінок, і кеш об'єктів, й у сервер безліч клієнтів із забезпеченням мультидоступа з урахуванням блокування. На клієнтів підтримується лише кеш об'єктів.

Для управління мультидоступом в ITASCA використовується дво-фаза протокол синхронизационных блокування з сериализацией транзакцій і виявленням глухих кутів. Також підтримуються довгі транзакції з урахуванням переміщення об'єкта з спільно використовуваної бази даних у приватну базі даних (checkout). Задля більшої співпраці припускається кількох користувачів лише у довгої транзакції.

Для всієї розподіленої бази даних підтримується єдина схема з використання подсхем приватних фрагментів бази даних. Модель даних входять такі аспекты:

множественное успадкування;

представление класів як об'єктів;

наличие властивостей і операцій класів;

наличие властивостей і операцій класів;

поддержка обмежень цілісності;

возможность перевантаження операцій.

В час можуть додаватися нові дані, класи, властивості та операції. Задля більшої контролю за поширенням таких операцій як видалення об'єкта є можливість визначення складових об'єктів. Для підтримки мультимедійних додатків є можливість використання лінійних масивних об'єктів, призначених передусім для зберігання послідовних даних, як-от текст чи аудіодані. У просторових масивних об'єктах є виміру, і вони підходять, наприклад, для зберігання изображений.

Восстановление бази даних після збоїв виготовляють основі журналу, покликаного забезпечити анулювання результату виконаних операцій (undo log). Це дозволяє у процесі відновлення усунути ефект всіх транзакцій, не завершених на момент збою. Фіксація транзакції у тому, що у сервері всі об'єкти, змінені даної транзакцией, переміщаються з буфера об'єктів в буфер страниц.

Поддерживается механізм індексування, заснований на використанні техніки B ±дерев. Можна створювати індекси на одне класу тут і одного властивості або заради кількох властивостей кількох классов.

Имеется можливість створення класів, підтримують оповіщення. Є дві форми оповіщення — пасивна й активна. Пасивне оповіщення у тому, що зберігається інформацію про модифікації чи видаленні примірників класу. Додаток може звернутися класу із запитом даних про таких подіях. Активне оповіщення призводить до виклику деякою операції при виконанні операцій модифікації, видалення, створення версії, переміщення об'єкта із загальної бази даних у приватну базі даних (checkout) навпаки (checkin). За умовчанням виконання операції оповіщення призводить до відправлення електронної пошти привілейованому користувачеві (адміністратору системи), але допускається заміна поведінки цієї операции.

Допускается створення тимчасової, робочої чи «випускний» версії об'єкта. Для динамічного чи статичного зв’язування різних версій підтримується ієрархія походження версій. З використанням динамічного зв’язування версій ієрархія автоматично модифікується при створення нових версій.

Безопасность даних забезпечується з урахуванням механізму авторизації доступу, у якому конкретна привілей (доступ читання, доступ за попереднім записом або створення) надається ролі, яку може тупцювати один користувач чи група користувачів. Привілеї може бути під'єднані до баз даних, класам, экстентам, об'єктах, операціям і властивостями. Є авторизація за умовчанням, яка мається на увазі для будь-який ролі й то, можливо доповнена явною авторизацією, позитивної (з додаванням привілеїв) чи негативною (з вилученням привілеї).

При використанні З ++ стабільність досягається шляхом доступу до бібліотеці класів, підтримують стабільність. У CLOS (Common Lisp Object System) забезпечується метакласс стабільності. Стабільні об'єкти би мало бути екземплярами класів, є екземплярами цього метакласса. З іншого боку, можна вказати, деякі властивості стабільного класу є недолговечными.

В ITASCA підтримуються З, З ++, Smalltalk, CLOS. Акцент робиться спроможності динамічного зміни схеми безупинно дії системи та без потреби у масової повторної компіляції і редагування зв’язків. Доступ до програм кожному з мов виробляється через функціональний АПІ. Що стосується використання З ++ автоматично створюється файл заголовків, який зливається з вихідними файлами програмного коду при генерації приложения.

Собственный механізм запитів ITASCA дозволяє вимагати дані у приватному базі даних, загальної базі даних або відразу на обох базах даних. На підвищення продуктивності застосовуються оптимізація запитів і силові методи распараллеливания.

ObjectStore

Компания Object Design було засновано 1988 р. з екстреної метою розробити зважену та вивести ринку ООСУБД, яку почали називати ObjectStore. Наприкінці 1990;х у Object Design встановилися тісні партнерські відносини з IBM, що дозволило привернути увагу до ObjectStore тисячі розробників додатків. За підсумками технології ObjectStore компанією був розроблена одне з перших комерційних СУБД — Excelon, орієнтована управління XMLданими. З початку 2003 р. компанія постало як підрозділ компанії Progress Software.

ООСУБД ObjectStore полягає в архітектурі клієнт-сервер, у якій кожен сервер відпо-відає регулювання доступу до сховища об'єктів і управляє журнализацией оновлень, блокуваннями, установкою контрольних точок, дозволом конфліктів за даними, резервуванням даних, і відновленням бази даних після збоїв. Кожен сервер підтримує безліч клієнтів. У клиентском процесі використовується уявлення даних вищого рівня, і клієнтська частина ObjectStore відпо-відає управління колекціями, виконання запитів і управління транзакциями.

Серверная частина спроектована для використання механізму відображення віртуальної пам’яті, яка поширюється протягом усього мережу і може охоплювати кілька серверів. Вилучувані з даних об'єкти можуть об'єднуватись у пакети передачі через мережу, що дозволяє знизити обсяг мережного трафіку. Для скорочення часу доступу в серверах використовується техніка кластеризації. В кожній клієнтської частини є локальний кеш, у якому зберігаються використовувані об'єкти. Коли об'єкт переміщається в адресне простір клієнта, посилання нього переробляються в такий спосіб, що кожного об'єкта доступу буде достатньо однієї команди компьютера.

Управление мультидоступом грунтується на використанні прозорого для користувача механізму блокування, що включає можливість блокування читання і з записи. Підтримуються рівні деталізації (гранулированности) блокування від рівня сторінок зовнішньої пам’яті бази даних до конфігурацій (указываемых програмістом груп объектов).

Надежность зберігання даних забезпечується з допомогою підтримки журналу вироблених змін. Підсистема управління транзакціями відпо-відає журнализацию всіх вироблених змін основі протоколу WAL (Write Agead Log — упреждающей запис у журнал). Додатково підтримується архівний журнал, у якому авторизований користувач може оцінити архівне копіювання бази данных.

Имеется засіб підтримки версій, яке забезпечує можливість колективної роботи з базами даних з урахуванням механізмів checkin /checkout. У цьому підході грунтується підтримка довгих транзакцій. Для кожної конфігурації об'єктів можна створити історію версій, незалежну від типів объектов.

В ObjectStore стабільність зберігання об'єктів підтримується завдяки наявності поіменованих кореневих стабільних об'єктів класу база даних. База даних створюється з допомогою виклику методу new цього. Є методи відкриття і закриття бази даних. З іншого боку, у п’ятому класі містяться методи до створення стабільних кореневих об'єктів, зазвичай є колекціями, у яких розміщені стабільні об'єкти.

Поддерживаются мови З, З ++ і Smaltalk. Властивість стабільності забезпечується через включення до бібліотеки класів спеціальних системних класів. Є класи, підтримують колекції - списки, безлічі, мультимножества і масиви. Методи цих класів підтримують вибірку об'єктів із колекцій, вставку і видалення об'єктів.

Поддерживаются шлюзові об'єкти, підтримують доступ до реляционным даним, і навіть інструментальні кошти на відображення реляційної схеми в еквівалентну объектно-ориентированное уявлення. Таким чином, з реляционными базами даних можна працювати у інтерфейсі ODBC на основі SQL чи власному інтерфейсі ObjectStore .

Objectivity /DB.

Компания Objectivity утворено 1988 р. У 1990 р. було випущено перша версія системи, яка являла собою розподілену СУБД, засновану на використанні об'єктної технології, высокопропускных локальних мереж, і симетричних мультипроцессоров. Система дбає про всіх основних UNIXплатформах і серед Windows .

Система полягає в клиент-серверной архітектурі, в якої одиницею обміну між сервером і клієнтом є сторінка бази даних. Тим самим було багато системні функції, включаючи кэширование, пошук об'єктів і перетворення їх форматів, виконуються за клієнта. Об'єктні ідентифікатори видаються в 64-разрядном форматі, що забезпечує потенційну можливість роботи з сверхбольшими базами данных.

Поддерживается четырехуровневая структура зберігання даних. Об'єкти зберігають у контейнерах, кожен із яких собою частина локальної бази даних. Локальні ж бази даних можуть комбінуватися в федеративну (розподілену) базі даних. Надійність зберігання даних підтримується механізмом репликации.

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

Допускаются як короткі, і довгі транзакції. Управління короткими транзакціями грунтується на синхронизационных блокировках і розпізнаванні глухих кутів. Довгі транзакції і колективна роботу з базами даних засновані на многоверсионности об'єктів і механізм checkin /checkout .

В системі підтримуються мови З ++ і Smalltalk, але засоби використання мов принципово різняться. Це стосується і до механізмам стабільності, і до засобів визначення даних. Серед З ++ стабільними є об'єкти всіх класів, є спадкоємцями спеціального системного класу. Серед Smalltalk стабільними є всі об'єкти, досяжні від поіменованих кореневих объектов-словарей. Відповідно, в Smalltalk для видалення об'єктів використовується механізм складання сміття, а З ++ - явні операції.

Естественно, бази даних, керовані Objectivity /DB, засновані в одній об'єктної моделі. Ця модель досить близька до моделі ODMG і зокрема, включає можливість визначення двунаправленных зв’язків. Підтримується можливість управління складовими об'єктами з поширенням на подобъекты операції видалення. Проте способи визначення даних у середовищі З ++ і Smalltalk різняться.

В З ++ включено спеціальне розширення мови, призначене визначення даних. Відповідні конструкції обробляються спеціальним препроцесором, який генерує код З ++, у якому відповідні звернення до СУБД. Серед Smalltalk схема бази даних окреслюється набір класів Smalltalk. Інакше кажучи, при використанні Smalltalk докладання, хто з базами даних Objectivity /DB, організуються прозорішим чином, ніж у випадку З ++.

Имеется підтримка мови SQL /89 і лише частково, SQL /92. Реляционный доступом до баз даних, керованих Objectivity /DB, може бути через інтерактивний SQLорієнтований інтерфейс, через наявний драйвер ODBC і через АПІ .

Versant.

С 1988 р. компанія Versant пропонує рішення, засновані на добре масштабируемой объектно-ориентированной архітектурі й що належить компанії алгоритмі кэширования. ООСУБД Versant є одним із небагатьох объектно-ориентированных систем, припускають масштабирование рівня будь-якого підприємства. Рішення з урахуванням Vers ant застосовують у телекомунікації, обороні, на транспорті, і т.д. Система працює як у основних UNIX-платформах, і у середовищі Windows.

Архитектура Versant більшою мірою орієнтована на логічне управління даними, тобто. об'єктами, а чи не на фізичне уявлення даних як, наприклад, сторінок. Управління розміщенням об'єкта здійснюється системою способом, повністю прозорим для користувачів. Для підтримки локальних сховищ об'єктів використовується кэширование.

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

Поддерживаются кластери спільно використовуваних об'єктів, причому вбудовані об'єкти зберігаються всередині своїх объектов-предков, що сприяє зменшенню рівня фрагментації пам’яті. Кластеризація застосовується й при зовнішньому кэшировании. З іншого боку, у системі Versant підтримується зокрема можливість використання персональних баз даних, встановлених на мобільних комп’ютерах. Вони може бути від'єднані від серверу центральної бази даних, використовуватися автономно і зафіксувати свої зміни у базі даних після відновлення сполуки.

Управление транзакціями грунтується, переважно, на синхронизационных блокировках лише на рівні об'єктів, хоча можливі блокування класів та версій об'єктів. Є ціла низка різновидів блокування: короткі блокування для коротких транзакцій, стабільні блокування для довгих транзакцій тощо. Допускається навіть можливість розширення моделі блокування правилами, бажаними для користувачів. Система уникає тупикових синхронизационных ситуацій, не задовольняючи попит на блокування, які можуть призвести до тупику.

Фиксация розподілених транзакцій полягає в двухфазном протоколі фіксації. Підтримуються часткова фіксація кэшей, механізми контрольних крапок і точок збереження. Забезпечується і можливість освіти вкладених транзакцій. При реалізації довгих транзакцій використовується механізм checkin /checkout із установкою стабільної блокування на необхідні об'єкти, предотвращающей доступом до цих об'єктів із боку інших транзакцій до завершення даної довгої транзакції.

Имеется можливість реєстрації на сервері подій, які цікавлять докладання. При реєстрації серверу повідомляється вид події та операція, яку виконувати у разі виникнення події. До подій, які дозволяється реєструвати, ставляться оновлення й видалення класів, створення, оновлення й видалення объектов.

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

Обеспечивается ссылочная цілісність бази даних, і прозорість розташування об'єктів в розподіленої середовищі. Об'єкти можуть мігрувати по вузлам мережі, що сприяє балансуванню навантаження, і важливість залишатися повністю доступними для додатків. Допускається динамічна модифікація класів, яка веде до автоматичної модифікації всіх у базі даних об'єктів цих класів. У цьому система постійно залишається у робочому стані, і мережеві додатки продовжують виконуватися. Підтримується розвинений механізм версій. По відомої версії об'єкта можна було одержати доступом до його предкам, нащадкам і братьям.

Для уявлення перетинів поміж об'єктами бази даних використовується єдиний стабільний вказівний тип. У системі підтримуються приховані від користувачів перетворення покажчиків бази даних у звичайні покажчики З ++ і навпаки. Тому об'єкти створюються й ліквідовуються з допомогою стандартних конструкторів і деструкторів классов.

Для програмування можна використовувати мови З ++ і Smalltalk, причому без жодних розширень. Підтримуються можливості, специфічні до роботи з базами даних. Наприклад, є засіб автоматичної генерації схеми бази даних прямо по файлам заголовків З ++. Це дозволяє уникнути використання спеціалізованих препроцессоров чи компіляторів. Спеціальні системні класи дозволяють працювати з усіма різновидами типів колекцій, специфицированными у стандарті ODMG. Будь-який об'єкт, створений середовищі З ++, доступний серед Smalltalk і наоборот.

Запросы до баз даних Versant можна ставити з допомогою спеціального системного класу, що дозволяє обходити об'єкти колекцій. Підтримується розширений варіант SQL /89. Є драйвер ODBC. Забезпечується доступ з середовища Versant до зовнішніх реляционным баз данных.

Заключение

до подразделу

Приведенный короткий огляд основних особливостей найпопулярніших комерційних ООСУБД показує, передусім, дуже високий технічну різнорідність цих систем. Загалом сенсі, всі системи відповідають базової моделі ODMG, однак слід звернути увагу, що дуже рідко як мови запитів підтримується OQL, і лише у системі не підтримується ODL .

Ни одне з компаній, які виробляють ООСУБД, не змогла набрати критичної маси, достатню у тому, щоб стати лідером, що диктуватиме моду у сфері (як з IBM і Oracle у сфері SQLорієнтованих СУБД). Великі комп’ютерні компанії не зважилися придбати який-небудь продукт ООСУБД, щоб розвивати його й просувати на ринку. Прикладом є поглинання однією з найбільш відомих у світі ООСУБД компанії ObjectSystems не найбільшої комп’ютерної компанією Progress Software. Компанія Progress пішла цей крок не оскільки їй знадобилося володіти ООСУБД ObjectStore, лише через ту причину, як раніше основі цієї СУБД у компанії ObjectSystems створили продукт eXcelon, готовий до управління XMLданными.

Когда з’явився став широко поширюватися мову Java, здавалося, що державна підтримка цієї мови стане сильним козирем ООСУБД. У 1997 р. одну з найбільших софтверних компаній Computer Associates випустила на ринок ООСУБД Jasmine, у якій активно підтримувався мову Java. Оголошуючи про випуску цього продукту, президент компанії заявив, що у його оцінкам протягом п’яти Jasmine ввійде у трійку найдохідніших продуктів Computer Associates. П’ять років минуло, з’явилося співтовариство користувачів Jasmine, але не така велика, як розраховувало керівництво компанії.

2.4 Укладання раздела

Конечно, важко порівнювати технологію объектно-ориентированных СУБД технологією SQLорієнтованих систем51. SQL вийшов із реляционного підходи до управлінню базами даних. Основний ідеєю була максимальна простота логічних структур даних, забезпечує логічний незалежність додатків від використовуваних ними баз даних. ООСУБД вийшли з объектно-ориентированных мов програмування. Основна ідея полягало у бажанні забезпечити збереження до базі даних довільно складних структур даних, які лише припускає мову програмування. Ця принципова відмінність в ідейній основі підходів неминуче призвела до принциповому розбіжності в технологиях.

В цьому розділі спочатку розглянули загальні модельні принципи організації ООСУБД, почавши з Маніфесту объектно-ориентированных баз даних, і перейшовши потім до стандарту ODMG. Слід зазначити, у цілому стандарт ODMG залишає суперечливі відчуття. З одного боку, у документі міститься багато цікавих ідей технічних специфікацій. З іншого боку, деякі важливі частини стандарту здаються не досить проробленими й погано відредагованими. Місцями трапляються протиріччя і прямі помилки. Але це єдиний загальновизнаний стандарт ООСУБД, та її корисно знати хоча в найзагальніших рисах його. Наприкінці розділу ми коротко описали риси кількох відомих комерційних ООСУБД, щоб показати, політика щодо ООСУБД ставлення виробників до стандартів більш анархично, ніж у області SQLорієнтованих СУБД.

Список литературы

[24] До. Дейт. «Введення ЄІАС у системи баз даних». 2-ге вид., М.: Наука.1980.

[25] До. Дейт. «Введення у системи баз даних». 6-те вид., М.; СПб.: Вільямс.- 2000.

[26] До. Дейт. «Введення ЄІАС у системи баз даних». 7-ме вид., М.; СПб.: Вільямс.- 2001.

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