Об’єктно-орієнтовані бази даних – основні концепції, організація і управління: короткий огляд, Інші СУБД, Бази даних, статті

Напрямок об’єктно-орієнтованих баз даних (ООБД) виникло порівняно давно. Публікації з’являлися вже в середині 1980-х (наприклад, [96]). Проте найбільш активно цей напрямок розвивається в останні роки. З кожним роком збільшується число публікацій і реалізованих комерційних і експериментальних систем. Виникнення напрямки ООБД визначається насамперед потребами практики: необхідністю розробки складних інформаційних прикладних систем, для яких технологія попередніх систем БД не була цілком задовільною. Звичайно, ООБД виникли не на порожньому місці. Відповідний базис забезпечують як попередні роботи в області БД, так і давно розвиваються напрямки мов програмування з абстрактними типами даних і об’єктно-орієнтованих мов програмування.

Що стосується зв’язку з попередніми роботами в області БД, то на наш погляд найбільш сильний вплив на роботи в області ООБД надають опрацювання реляційних СУБД і наступне хронолігіческі за ними сімейство БД, в яких підтримується управління складними об’єктами [52-56]. Крім того, винятковий вплив на ідеї та концепції ООБД і, як здається, всього об’єктно-орієнтованого підходу надав підхід до семантичного моделювання даних (наприклад, [57-59], хоча загальне число публікацій по семантичному моделювання воістину безмежно). Достатня вплив роблять також розвиваються паралельно з ООБД напрямки дедуктивних і активних БД [10, 42, 82, 84].


Серед мов і систем програмування найбільше первинне вплив на ООБД надав Smalltalk [34, 36]. Ця мова сам по собі не є повністю поінерскім, хоча в ньому була введена нова термінологія, є тепер найбільш поширеною в об’єктно-орієнтованому програмуванні. Насправді, Smalltalk заснований на ряді раніше висунутих концепцій. Хороший огляд ідей і підходів об’єктно-орієнтованого програмування представлений, наприклад, в [3].


Велика кількість робіт не означає, що всі проблеми ООБД повністю вирішені. Як наголошується в Маніфесті групи провідних вчених, що займаються ООБД, [8] сучасна ситуація з ООБД нагадує ситуацію з реляційними системами середини 1970-х. При наявності великої кількості експериментальних проектів (і навіть комерційних систем) відсутня загальноприйнята об’єктно-орієнтована модель даних, і не тому, що немає жодної розробленої повної моделі, а через відсутність загальної згоди про вжиття якою-небудь моделі. Насправді, є й більш конкретні проблеми (наприклад, [5, 7]), пов’язані з розробкою декларативних мов запитів, виконанням і оптимізацією запитів, формулюванням та підтриманням обмежень цілісності, синхронізацією доступу та управлінням транзакціями і т.д.


Тематика ООБД дуже широка, обсяг цього огляду не дозволяє розглянути всі питання. Тим не менш, ми постараємося в систематичній манері проаналізувати найважливіші аспекти ООБД (критерії відбору тим і джерел повністю суб’єктивні). Огляд побудований за таким планом: Перший розділ – справжнє введення. У другому розділі викладаються основні поняття об’єктно-орієнтованого підходу і їх специфічне переломлення в контексті ООБД. У третьому розділі розглядаються основні поняття об’єктно-орієнтованого моделювання даних. Четвертий розділ присвячений мовам програмування і мов запитів ООБД. У п’ятому розділі коротко бачаться характерні представники об’єктно-орієнтованих СУБД – ORION і O2. Шостий розділ присвячується проблематиці виконання та оптимізації запитів до ООБД. У сьомому розділі розглядаються питання синхронізації доступу та управління транзакціями в ООБД. Восьмий розділ стосується зв’язку ООБД і дедуктивних і активних БД. Нарешті, дев’ятий розділ – короткий висновок.


Загальні поняття об’єктно-орієнтованого підходу та їх переломлення в ООБД


У найбільш загальної та класичної постановці [11] об’єктно-орієнтований підхід базується на концепціях:


– Об’єкта і ідентифікатора об’єкта;


– Атрибутів і методів;


– Класів;


– Ієрархії і спадкування класів.


Будь сутність реального світу в об’єктно-орієнтованих мовах і системах моделюється у вигляді об’єкта. Будь-який об’єкт при своєму створенні отримує генерований системою унікальний ідентифікатор, який пов’язаний з об’єктом у весь час його існування і не змінюється при зміні стану об’єкта.


Кожен об’єкт має стан і поведінку. Стан об’єкта – набір значень його атрибутів. Поведінка об’єкта – набір методів (програмний код), що оперують над станом об’єкта. Значення атрибута об’єкта – Це теж певний об’єкт або безліч об’єктів. Стан і поведінка об’єкта інкапсульовані в об’єкті; взаємодія між об’єктами здійснюється на основі передачі повідомлень та виконанні відповідних методів.


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


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


Однією з пізніших ідей об’єктно-орієнтованого підходу є ідея можливого перевизначення атрибутів і методів суперкласу в підкласі (перевантаження методів). Ця можливість збільшує гнучкість, але породжує додаткову проблему: при компліляціі об’єктно-орієнтованої програми можуть бути невідомі структура і програмний код методів об’єкта, хоча його клас (в загальному випадку – суперклас) відомий. Для вирішення цієї проблеми застосовується так званий метод пізнього зв’язування, що означає, по суті справи, інтерпретаційний режим виконання програми з розпізнаванням деталей реалізації об’єкта під час виконання посилки повідомлення до нього. Введення деяких обмежень на спосіб визначення підкласів дозволяє домогтися ефективної реалізації без потреб в інтерпретації [97].


Як видно, при такому наборі базових понять, якщо не брати до уваги можливості спадкування класів і відповідні проблеми, об’єктно-орієнтований підхід дуже близький до підходу мов програмування з абстрактними (або довільними) типами даних [77].


З іншого боку, якщо абстрагуватися від поведінкового аспекту об’єктів, об’єктно-орієнтований підхід дуже близький до підходу семантичного моделювання даних [58] (навіть і за термінологією). Фундаментальні абстракції, що лежать в основі семантичних моделей, неявно використовуються і в об’єктно-орієнтованому підході. На абстракції агрегації грунтується побудова складних об’єктів, значеннями атрибутів яких можуть бути інші об’єкти. Абстракція групування – основа формування класів об’єктів. На абстракціях спеціалізації / узагальнення засноване побудова ієрархії або решітки класів.


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


Специфіка застосування об’єктно-орієнтованого підходу для організації та управління БД зажадала уточненого тлумачення класичних концепцій і деякого їх розширення [6]. Це визначається потребами довготривалого зберігання об’єктів у зовнішній пам’яті, асоціативного доступу до об’єктів, забезпечення узгодженого стану ООБД в умовах мультидоступ і тому подібних можливостей, властивих баз даних [8]. В [6] виділяються три аспекти, відсутні в традиційній парадигмі, але потрібні у ООБД.


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


Як ми зазначали у вступі, в співтоваристві дослідників ООБД і розробників систем відсутня повна згода, але в більшості практичних робіт використовується деяке розширення об’єктно-орієнтованого підходу.


Об’єктно-орієнтовані моделі даних


Першою формалізованої і загальновизнаною моделлю даних була реляційна модель Кодда [98]. У цій моделі, як і у всіх наступних, виділялися три аспекти – структурний, цілісний і маніпуляційний. Структури даних в реляційній моделі грунтуються на плоских нормалізованих відносинах, обмеження цілісності виражаються за допомогою засобів логіки першого порядку і, нарешті, маніпулювання даними здійснюється на основі реляційної алгебри або равносильного їй реляційного числення. Як відзначають багато дослідників, своїм успіхом реляційна модель даних багато в чому зобов’язана тому, що спиралася на строгий математичний апарат теорії множин, відносин і логіки першого порядку. Розробники будь-якої конкретної реляційної системи вважали своїм обов’язком показати відповідність своєї конкретної моделі даних загальної реляційної моделі, яка виступала в якості міри “реляційної” системи.


Основні труднощі об’єктно-орієнтованого моделювання даних є наслідком того, що такого розвиненого математічекого апарату, на який могла б спиратися загальна об’єктно-орієнтована модель даних, не існує. У великій мірі тому до цих пір немає базової об’єктно-орієнтованої моделі. З іншого боку, в [63] з посиланням на недоступну нам роботу Майера [99] стверджується, що загальна об’єктно-орієнтована модель даних в класичному сенсі і не може бути визначена через непридатність класичного поняття моделі даних до парадигми об’єктної орієнтованості.


Не наводячи доказів на користь цього твердження Майера, але і не заперечуючи його, Беєр [63] пропонує в загальних рисах формальну основу ООБД, далеко не повну і не є моделлю даних в традиційному сенсі, але дозволяє дослідникам і розробникам систем ООБД принаймні говорити на одній мові (якщо, звичайно, пропозиції Беер будуть розвинені і отримають підтримку). Незалежно від подальшої долі цих пропозицій ми вважаємо корисним коротко їх переказати.


По-перше, слідуючи практиці багатьох ООБД, пропонується виділити два рівні моделювання об’єктів: нижній (структурний) і верхній (поведінковий). На структурному рівні підтримуються складні об’єкти, їх ідентифікація та різновиди зв’язку “isa”. База даних – це набір елементів даних, пов’язаних відносинами “входить в клас” або “є атрибутом”. Таким чином, БД може розглядатися як орієнтований граф. Важливим моментом є підтримання поряд з поняттям об’єкта поняття значення (пізніше ми побачимо, як багато на цьому побудовано в одній з успішних об’єктно-орієнтованих СУБД O2 [29]).


Важливим аспектом є чіткий поділ схеми БД і самої


БД. В якості первинних концепцій схемного рівня ООБД


виступають типи і класи. Зазначається, що у всіх системах,


використовують тільки одне поняття (або тип, або клас) це


поняття неминуче перевантажено: тип передбачає наявність деякого безлічі значень, що визначається структурою даних цього типу; клас також припускає наявність безлічі об’єктів, але це безліч визначається користувачем. Таким чином, типи і класи грають різну роль, і для строгості і недвозначності потрібні одночасне підтримку обох понять.


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


Важливим, хоча і недостатньо обгрунтованим припущенням Беер є те, що двох традиційних рівнів – схеми і даних для ООБД недостатньо. Для точного визначення ООБД потрібно рівень мета-схеми (Див. також [65]), вміст якої має визначати види об’єктів і зв’язків, допустимих на схемному рівні БД. Мета-схема повинна грати для ООБД таку ж роль, яку відіграє структурна частина реляційної моделі даних для схем реляційних баз даних.


Є достатня кількість інших публікацій, отноcящіхся до теми об’єктно-орієнтованих моделей даних [61-62, 64, 65-68], але вони або зачіпають досить приватні питання, або використовують занадто серйозний для цього огляду математичний апарат (до числа останніх відноситься робота Леллані і Спіратоса [68], в якій об’єктно-орієнтована модель даних визначається на основі теорії категорій).


Для ілюстрації поточного стану справ ми коротко розглянемо особливості конкретної моделі даних, що застосовується в об’єктно-орієнтованої СУБД O2 [29, 32] (це, звичайно, теж не модель даних в класичному сенсі).


В O2 підтримуються об’єкти і значення. Об’єкт – це пара (ідентифікатор, значення), причому об’єкти інкапсульовані, тобто їх значення доступні тільки через методи – процедури, прив’язані до об’єктів. Значення можуть бути атомарними або структурними. Структурні значення будуються із значень або об’єктів, представлених своїми ідентифікаторами, за допомогою конструкторів множин, кортежів і списків. Елементи структурних значень доступні за допомогою визначених операцій (примітивів).


Можливі два види організації даних: класи, екземплярами яких є об’єкти, що інкапсулює дані і поведінку, і типи, екземплярами яких є значення. Кожному класу зіставляється тип, описує структуру екземплярів класу. Типи визначаються рекурсивно на основі атомарних типів і раніше визначених типів і класів із застосуванням конструкторів. Поведінкова сторона класу визначається набором методів.


Об’єкти і значення можуть бути іменованими. З ім’ям об’єкта або значення пов’язана довготривалість його зберігання (persistency): будь-які іменовані об’єкти або значення довготривалі; будь об’єкт або значення, що входять як частина в іншій іменований об’єкт або значення, довготривалі.


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


Метод – програмний код, прив’язаний до конкретного класу і застосовний до об’єктів цього класу. Визначення методу в O2 проводиться в два етапи. Спочатку оголошується сигнатура методу, тобто його ім’я, клас, типи або класи аргументів і тип або клас результату. Методи можуть бути публічними (доступними з об’єктів інших класів) або приватними (доступними тільки всередині даного класу). На другому етапі визначається реалізація класу на одній з мов програмування O2 (докладніше мови обговорюються в наступному розділі нашого огляду).


У моделі O2 підтримується множинне спадкування класів на основі відношення супертіп / підтип. В підкласі допускається додавання та / або перевизначення атрибутів і методів. Можливі при множині спадкуванні двозначності (по іменування атрибутів і методів) вирішуються або шляхом перейменування, або шляхом явного вказівки джерела успадкування. Об’єкт підкласу є об’єктом кожного суперкласу, на основі якого породжений даний підклас.


Підтримується зумовлений клас “Оbject”, що є коренем решітки класів; будь-який інший клас є неявним спадкоємцем класу “Object” і успадковує зумовлені методи (“is_same”, “is_value_equal” і т.д.).


Специфічною особливістю моделі O2 є можливість оголошення додаткових “виняткових” атрибутів і методів для іменованих об’єктів. Це означає, що конкретний іменований об’єкт-представник класу може мати типом, що є підтипом типу класу. Звичайно, з такими атрибутами не працюють стандартні методи класу, але спеціально для іменованого об’єкта можуть бути визначені додаткові (Або перевизначені стандартні) методи, для яких додаткові атрибути вже доступні. Підкреслюється, що додаткові атрибути і методи прив’язуються не до конкретного об’єкта, а до імені, за яким в різні моменти часу можуть стояти взагалі кажучи різні об’єкти. Для реалізації виняткових атрибутів і методів потрібно розвиток техніки пізнього зв’язування.


В [29] наводиться досить формалізований опис моделі O2, ми для простоти викладу й розуміння слідували [32], де модель описується на змістовному рівні. У наступному розділі ми серед іншого розглянемо особливості мов програмування і запитів системи O2, які, звичайно, тісно пов’язані зі специфікою моделі даних.


Мови програмування систем ООБД і мови запитів


Як відзначають багато дослідників і розробники (наприклад, [8, 70]), об’єктно-орієнтована система БД являє собою об’єднання системи програмування і СУБД (альтернативна, але не більше прояснює суть справи точка зору полягає в тому, що об’єктно-орієнтована СУБД – це СУБД, заснована на об’єктно-орієнтованої моделі даних [8]).


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


Ця сторона ООБД найбільш близька родинному напрямку мов програмування БД [77]. Мови програмування ООБД і БД в багатьох своїх рисах різняться тільки термінологічно; істотною відмінністю є лише підтримка в мовах першого класу підходу до спадкоємства класів. Крім того, мови другого класу, як правило, більш розвинені як щодо системи типів, так і щодо керуючих конструкцій.


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


До моменту написання цього огляду нам невідомий небудь мову програмування ООБД, який був би спроектований цілком заново, починаючи з нуля. Природним підходом до побудови такої мови було використання (з необхідними розширеннями) деякого існуючого об’єктно-орієнтованої мови. Початок розквіту напрямки ООБД збіглося з піком популярності мови Smalltalk-80. Ця мова надав великий вплив на розробку перших систем ООБД, і, зокрема, використовувався в якості мови програмування [34, 36]. Багато в чому спирається на Smalltalk і відома комерційно доступна система GemStone [22-24].


Труднощі з ефективною практичною реалізацією мови Smalltalk спонукали розробників систем ООБД до пошуку альтернативних базових мов. Відома близькість об’єктно-орієнтованого та функціонального підходів до програмування дозволяє досить успішно опиратися на функціональні мови програмування. Зокрема, мова Лісп (Common Lisp) є основою проекту ORION [17]. У цьому проекті Лісп є і інструментальним мовою, і базою об’єктно-орієнтованої мови програмування в середовищі ORION.


Потреби в ще більш ефективної реалізації змушують використовувати в якості основи об’єктно-орієнтованої мови мови більш низького рівня. Наприклад, у системі VBASE [24] поряд із спеціально розробленим мовою TDL, призначеним для визначення типів, використовується об’єктно-орієнтоване розширення мови Сі – COP (C Object Processor). У вже згадуваному проекті O2 [29-32] поряд з функціональним об’єктно-орієнтованим мовою програмування [41] використовуються два об’єктно-орієнтованих розширення мов Бейсік і Сі. При цьому, наскільки можна судити з публікацій, найбільше поширення серед користувачів цієї системи (вона вже комерційно доступна) отримав мова CO2, який є розширенням мови Сі. Можливо це пов’язано лише з широкою (і все більш зростаючій) популярністю мови Сі (і його об’єктно-орієнтованого нащадка Сі + +), що став воістину девізом “справжніх програмістів”. Може бути, причини більш глибинні. (наприклад, мови вищого рівня надто обмежувальні для програмістів-професіоналів; недарма більшість сучасних реалізацій мов більш високого рівня виконуються саме на мові Сі). Тим не менш, сучасна ситуація саме така, і ми вважаємо корисним привести короткий опис основних особливостей мови CO2 [31-32, 70].


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


Ім’я будь-якого об’єкта трактується як покажчик на значення цього об’єкта; разіменованіе проводиться за допомогою звичайного оператора Сі “*”. Доступ до значення об’єкта можливий тільки з методу його класу, якщо тільки при перерахуванні методів оператор “*” не оголошений явно публічним.


Підтримується операція породження нового об’єкта вказаного класу. На відміну від мови Сі + + в CO2 неможливо поєднати створення нового об’єкта з його ініціалізацій (поняття методу-конструктора початкового значення об’єкта в CO2 не підтримується). Для ініціалізації необхідно або явно звернутися до відповідного методу класу з зазначенням новоствореного об’єкта (підтримується відповідний механізм “Передачі повідомлень”, що означає насправді виклик функції), або скористатися оператором “*” і явно присвоїти нове значення, якщо “*” – публічний оператор для даного класу.


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


Основою маніпулювання об’єктами, збереженими в БД, є розширене порівняно з мовою Сі засіб ітерації. Ітератор застосуємо до значень-множинам або списками. Фактично він означає послідовне застосування оператора-тіла циклу до всіх елементів безлічі або списку. Якщо ми згадаємо, що довготривало що зберігається класу об’єктів неявно соответствут однойменне значення-множина з елементами-об’єктами даного класу, то стає зрозуміло, що ітератор мови CO2 забезпечує явну навігацію в класах об’єктів. Єдине, що залишається від звичних користувачам СУБД мов запитів, – це обмежена можливість вказівки характеристик необхідних в циклі об’єктів (це робиться шляхом використання оператора разіменованія і явної вказівки умов на атрибути; звичайно, для цього потрібно, щоб оператор “*” був оголошений публічним в даному класі).


Розробники O2 підкреслюють, що вони навмисне зробили CO2 біднішим за можливостями, ніж, наприклад, мова Сі + +, тому що багато чого по частині управління об’єктами бере на себе загальний менеджер об’єктів системи, явно викликається з робочої програми.


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


Беєр [63] відзначає існування трьох підходів. Перший підхід


– Мови, що є об’єктно-орієнтованими розширеннями мов запитів реляційних систем. Найбільш поширені мови з синтаксисом, близьким до відомого мови SQL [100]. Це пов’язано, звичайно, з загальним визнанням і надзвичайно широким поширенням цієї мови. Зокрема, у своєму Маніфесті третього покоління [9] СУБД М. Стоунбрекер і його колеги по комітету перспективних систем БД стверджують необхідність підтримки SQL-подібного інтерфейсу у всіх СУБД наступного покоління.


Другий підхід грунтується на побудові повного логічного об’єктно-орієнтованого обчислення. З приводу побудови такого обчислення є теоретичні роботи (наприклад, [101]), але закінчений і практично реалізований мову запитів нам невідомий. Мабуть, до цього ж напрямку строго теоретично обгрунтованих мов запитів можна віднести і роботу Леллані і Спіратоса [68], засновану на алгебраїчної теорії категорій.


Нарешті, третій підхід грунтується на застосуванні дедуктивного підходу. В основному це відображає прагнення розробників до зближення напрямків дедуктивних і об’єктно-орієнтованих БД. Прикладом простого дедуктивного об’єктно-орієнтованої мови запитів може служити [82].


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


У мові запитів об’єктно-орієнтованої СУБД ORION [11, 71] повністю підтримується принцип інкапсуляції об’єктів. У реалізованому варіанті мови запити можуть грунтуватися лише на одному класі (хоча в [71] описується підхід до визначення запиту на декількох класах в стилі розширення семантики реляційного оператора з’єднання). Синтаксис мови орієнтований на SQL. Дуже розвинений набір допустимих предикатів селекції. Зокрема, для атрибута, доменом якого є суперклас, можна вказати ім’я цікавить користувача підкласу.


Мова запитів системи Iris [8, 20] знаходиться в значній мірі під впливом реляційної парадигми. Навіть назва цієї мови OSQL відображає його тісний зв’язок з реляційних мовою SQL. По суті справи, OSQL – Це реляційний мову, розрахований на роботу з ненормалізованих відносинами. Природно, при такому підході в OSQL порушується інкапсуляція об’єктів


На наш погляд, особливий інтерес представляє декларативний мову запитів системи O2 RELOOP [74]. У загальних словах, це декларативний мову запитів з SQL-орієнтованим синтаксисом, заснований на спеціально розробленої для моделі O2 алгебрі об’єктів і значень. (До речі, це не єдина робота в напрямку побудови алгебри для об’єктно-орієнтованих моделей даних. Див, наприклад, [76].) На наш погляд, особливо вражаючим якістю мови RELOOP є природність його побудови в загальному контексті моделі O2. Запит задається завжди на значенні-безлічі або списку. Якщо ми згадаємо, що довготривалого класу в O2 відповідає однойменне значення-безліч, то тим самим можна визначити запит на будь-якому доглянутому класі. Результатом запиту може бути об’єкт, значення-безліч або значення-список. При цьому елементами значень-множин можуть бути об’єкти (проста вибірка), або значення-кортежі з елементами-об’єктами різних класів (наприклад). У сукупності ці особливості мови дозволяють формулювати запити над декількома класами (специфічне з’єднання, що породжує не нові об’єкти, а кортежі з існуючих об’єктів), а також вживати вкладені підзапити.


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


Ідея нашої пропозиції грунтується на наступному спостереженні. Серед операцій реляційної алгебри є два види операцій: теретіко-множинні операції і операція селекції формують з операндів-відносин ставлення-результат з тією ж схемою; операції ж проекції та з’єднання формують ставлення-результат зі схемою, яка в загальному випадку не описувалася статично в складі схеми БД, тобто в іншій термінології ці операції формують не тільки значення, але й тип цього значення. І це не викликає ніякої двозначності, бо схему відносини-результату (тип результату) можна визначити в статиці до виконання операції.


Постає питання: чому б не спробувати поширити подібний підхід на класи об’єктів? Можливо, наприклад, наступне неформальне визначення алгебри класів об’єктів. Ця алгебра включає набір теоретико-множинних операцій, а також операції декартова твори, селекції та проекції. Теоретико-множинні операції визначаються для “однотипних” класів, і клас результату поміщається в грати класів схеми БД відповідно до семантикою включення. (Під час обчислення алгебраїчного виразу одночасно формується відповідний тимчасовий варіант решітки класів.) Операція декартового добутку формує клас, до складу об’єднання наборів методів класів-операндів і є їх підкласом. Операція селекції формує клас, який є підкласом класу-операнда. Операція проекції формує клас, включає вказане підмножина методів класу-операнда і є його суперкласом. З використанням операцій декартова твори і проекції можна визначити операцію з’єднання класів. Можна розширити алгебру операцією привласнення, і в цьому випадку клас, якому присвоюється результат алгебраїчного виразу повинен бути визначений в схемі БД заздалегідь.


Ми не розглядаємо питання можливої ​​реалізації подібної алгебри, яка, звичайно, викликає багато проблем. (Як, наприклад, має відбитися виконання операції проекції на внутрішній структурі об’єктів класу-результату?) Але зовнішня семантика операцій визначається однозначно. Наші пропозиції мають дуже попередній характер, але на нашу думку заслуговують хоча б обговорення.


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


В даний час ведеться дуже багато експериментальних і виробничих робіт в області об’єктно-орієнтованих СУБД [12-47]. Найбільше університетських робіт, які в основному носять дослідницький характер. Але вже рік тому зазначалося існування щонайменше тринадцяти комерційно доступних систем ООБД [10]. Серед них уже згадувані в нашому огляді системи O2 (французький консорціум Altair) [29-32], ORION (американська компанія MCC) [11-17], GemStone (американська фірма Servio Logic) [22-24] і Iris (Hewlett-Packard) [18-19]. На жаль, з приводу багатьох комерційних систем практично відсутні доступні публікації, а й наявної інформації достатньо, щоб охарактеризувати типову організацію сучасної об’єктно-орієнтованої СУБД.


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


З числа архітектур з традиційною організацією найбільший вплив на об’єктно-орієнтовані СУБД надали реляційні системи. Багато об’єктно-орієнтовані системи (по крайней мере в прототипних варіантах) будуються над деякою існуючої реляційної СУБД [37, 45-46]. Крім такого застосування реляційних систем для спрощення розробки об’єктно-орієнтованої СУБД, розвинені в реляційних СУБД методи застосовуються і в заново розробляються об’єктно-орієнтованих системах.


Безпосереднім попередником об’єктно-орієнтованих СУБД є системи, що підтримують організацію складних об’єктів [52-56]. Ці постреляціонних системи здебільшого з’явилися через невідповідність можливостей реляційних СУБД потребам нетрадиційних додатків (автоматизація проектування, інженерія тощо). По суті справи, в таких системах частково підтримується структурна частина ООБД (без можливостей успадкування). Багато об’єктно-орієнтовані СУБД (зокрема, ORION) розроблялися на базі попередніх робіт зі складними об’єктами.


Інший основою об’єктно-орієнтованих СУБД є так звані розширювані системи [48-51]. Основна ідея таких систем полягає в підтримці набору модулів з чітко обумовленими інтерфейсами, на базі якого можна швидко побудувати СУБД, що спирається на конкретну модель даних або призначену для конкретної області застосувань. Зокрема, як показує досвід системи EXODUS [48], засоби розширюваних систем добре придатні і для побудови об’єктно-орієнтованої СУБД.


Нарешті, торкнемося напрямки третього покоління СУБД [9]. Як виявляється з Маніфесту третього покоління, прихильники цього напряму дотримуються принципу еволюційного розвитку можливостей СУБД без корінний ломки попередніх підходів і зі збереженням приемственности з системами попереднього покоління. Тим не менш, незважаючи на відмінну термінологію і зміщені акценти, системи третього покоління не так вже й далекі від об’єктно-орієнтованих СУБД.


Однією з найбільш відомих СУБД третього покоління є система POSTGRES [26-28], а творець цієї системи М. Стоунбрекер, по всій видимості, є натхненником всього напряму. В POSTGRES реалізовані багато цікавих засоби: підтримується темпоральна модель зберігання і доступу до даних і в зв’язку з цим абсолютно перемотрен механізм журналізації змін, відкатів транзакцій та відновлення БД після збоїв; забезпечується потужний механізм обмежень цілісності; підтримуються ненормалізованих відносини (робота в цьому напрямку почалася ще в середовищі INGRES [25]).


Але одна властивість системи POSTGRES дійсно зближує її з об’єктно-орієнтованими СУБД. В POSTGRES допускається зберігання в полях відносин даних абстрактних, визначених користувачами типів. Це забезпечує можливість впровадження поведінкового аспекту в БД, тобто вирішує ту ж задачу, що і ООБД, хоча, звичайно, семантичні можливості моделі даних POSTGRES істотно слабкіше, ніж у об’єктно-орієнтованих моделей даних.


Перейдемо тепер до чисто об’єктно-орієнтованим СУБД. Ми розглянемо особливості організації двох таких систем – ORION [11-17] і O2 [29-32].


Проект ORION здійснювався з 1985 по 1989 р. фірмою MCC під руковоством відомого ще з робіт у проекті System R Вона Кіма. Під назвою ORION насправді ховається сімейство трьох СУБД: ORION-1 – Однокористувальницька система; ORION-1SX, призначена для використання в якості сервера в локальній мережі робочих станцій; ORION-2 – повністю розподілена об’єктно-орієнтована СУБД. Реалізація всіх систем проводилася з використанням мови Common Lisp на робочих станціях (і їх локальних мережах) Symbolics 3600 з ОС Genera 7.0 і SUN-3 в середовищі ОС UNIX. Опис реалізації ORION-2 поки не опубліковано, тому ми розглянемо тільки ORION-1 і ORION-1SX.


Основними функціональними компонентами системи є підсистеми управління пам’яттю, об’єктами і транзакціями. В ORION-1 всі компоненти, природно, розташовуються в одній робочій станції; в ORION-1SX – Рознесені між різними робочими станціями (зокрема, управління об’єктами здійснюється в робочій станції-клієнта). Застосування в ORION-1SX для взаємодії клієнт-сервер механізму віддаленого виклику процедур дозволило використовувати в цій системі практично без переробки багато модулі ORION-1. Мережеві взаємодії грунтувалися на стандартних засобах операційних систем.


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


Підсистема управління об’єктами включає подкомпоненти обробки запитів, управління схемою і версіями об’єктів. Версії підтримуються тільки для об’єктів, при створенні яких така необхідність була явно вказана. Для схеми БД версії не підтримуються; при зміні схеми відстежується вплив цієї зміни на інші компоненти схеми і на існуючи об’єкти. При обробці запитів використовується техніка оптимізації, аналогічна застосовуваної в реляційних системах (тобто формується набір можливих планів виконання запиту, оцінюється вартість кожного з них і вибирається для виконання найбільш дешевий) [102].


Підсистема управління транзакціями забезпечує традиційну серіалізуемость транзакцій, а також підтримує кошти журналізації змін і відновлення БД після збоїв. Для сериализации транзакцій застосовується різновид двофазного протоколу синхронізаційних захоплень з різним ступенем гранулювання [103]. Звичайно, при синхронізації враховується специфіка ООБД, зокрема, наявність ієрархії класів. Журнал змін забезпечує відкати індивідуальних транзакцій і відновлення БД після м’яких збоїв (архівні копії БД для відновлення після поломки дисків не підтримуються).


Проект O2 реалізується французькою компанією Altair, утвореною спеціально для цілей проектування та реалізації об’єктно-орієнтованої СУБД. Початок проекту датується вереснем 1986 р., і він був розрахований на п’ять років: три роки на Прототипування і два роки на розробку промислового зразка. Поточний прототип системи функціонує в режимі клієнт / сервер в локальній мережі робочих станцій SUN c відповідним поділом функцій між сервером і клієнтами.


Основними компонентами системи (не рахуючи розвиненого набору інтерфейсних засобів) є інтерпретатор запитів і підсистеми управління схемою, об’єктами і дисками. Управління дисками, тобто підтримання базової середовища постійного зберігання забезпечує система WiSS [104], яку розробники O2 перенесли в оточення ОС UNIX.


Найбільшу функціональне навантаження несе компонент управління об’єктами. У число функцій цієї підсистеми входить:


– Управління складними об’єктами, включаючи створення і знищення об’єктів, вибірку об’єктів по іменах, підтримку визначених методів, підтримку об’єктів зі внутрішньою структурою-безліччю, списком і кортежем;


– Управління передачею повідомлень між об’єктами;


– Управління транзакціями;


– Управління комунікаційним середовищем (на базі транспортних протоколів TCP / IP в локальній мережі Ethernet);


– Відстеження довготривало збережених об’єктів (нагадаємо, що в O2 об’єкт зберігається в зовнішній пам’яті до тих пір, поки досяжний з якогось довготривало зберігається об’єкта);


– Управління буферами оперативної пам’яті (аналогічно ORION, подання об’єкта в оперативній пам’яті відрізняється від його представлення на диску);


– Управління кластеризацією об’єктів у зовнішній пам’яті;


– Управління індексами.


Кілька слів про управління транзакціями. Розрізняються режими, коли допускається паралельне виконання транзакцій, що змінюють схему БД, і коли паралельно виконуються тільки транзакції, що змінюють внутрішність БД. Перший режим звичайно використовується на стадії розробки БД, другий – на стадії виконання додатків. Засоби відновлення БД після збоїв і відкатів транзакцій також можуть включатися і вимикатися. Нарешті, підтримується режим, при якому всі постійно зберігаються об’єкти завантажуються в оперативну пам’ять при початку транзакції для збільшення швидкості роботи прикладної системи.


Компонент управління схемою БД реалізований над підсистемою управління об’єктами: в системі підтримуються кілька невидимих ​​для програмістів класів і в тому числі класи “Class” і “Method”, екземплярами яких є, відповідно, об’єкти, що визначають класи, і об’єкти, що визначають методи. (Як видно, ситуація нагадує реляційні системи, в яких теж звичайно підтримуються службові відносини-каталоги, описують схему БД.) Видалення класу, який не є листом ієрархії класів або використовується в іншому класі або сигнатурі-якого методу, заборонено.


Навіть наведене короткий опис особливостей двох об’єктно-орієнтованих СУБД показує прагматичність сучасного підходу до організації таких систем. Їх розробники не прагнуть до повного дотримання чистоти об’єктно-орієнтованого підходу і застосовують найбільш прості рішення проблем, які насправді ще не вирішені. Поки в співтоваристві розробників об’єктно-орієнтованих систем БД не видно роботи, яка могла б зіграти в цьому напрямі роль, аналогічну ролі System R [105] по відношенню до реляційних системам. Правда, і проблеми ООБД набагато складніші, ніж вирішуються в реляційних системах.


Проблеми виконання та оптимізації запитів до ООБД


У цьому розділі ми зупинимося на проблемах виконання запитів до ООБД, сформульованих на якомусь декларативному мовою. Яким би не був цей мову, в кінцевому рахунку буде потрібно за зовнішнім поданням запиту сформувати план його виконання, який мінімізував би загальні накладні витрати системи, що вимагаються для виконання запиту. Іншими словами, до виконання запиту необхідно виконати його оптимізацію, враховуючи в загальному випадку необхідність обмінів із зовнішньою пам’яттю.


Публікації, що стосуються оптимізації запитів до ООБД, практично відсутні. Це свідчить про недостатню розвиненість будь-яких оригінальних підходів.


Як ми бачили на прикладах конкретних систем в попередньому розділі, в них по суті справи застосовується той самий підхід до оптимізації запитів, який використовувався в реляційних системах: формується набір альтернативних планів, оцінюється вартість кожного з них і вибирається план з найменшою вартістю. (Докладний огляд сучасних методів оптимізації запитів в реляційних СУБД і невирішених проблем можна знайти в [106].) Можливість застосування такого підходу в СУБД ORION і O2 (та й в інших) спирається на те, що об’єкти в цих системах не повністю інкапсульовані. Поряд з методами, в об’єктах видно і деякі атрибути, і якщо умова вибірки задано через ці атрибути, оптимізатор запитів, якому відомі внутрішня структура об’єктів і набір існуючих індексів, отримує можливість вибору. Якщо ж умова вибірки можна формулювати лише через методи, при підходах ORION і O2 єдиним можливим способом вибірки об’єктів класу буде послідовний перегляд всіх об’єктів цього класу.


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


Як здається, з останніх публікацій, які зачіпають проблеми оптимізації запитів, найбільший вплив на оптимізатори систем ООБД може надати [108]. Ця робота не пов’язана безпосередньо зі специфікою ООБД, але перевага пропонованого підходу пов’язано як раз з максимальною незалежністю від особливостей організації БД. Пропонується не оцінювати план виконання запиту, а враховувати реальну вартість вже використаного плану і на цій основі змінювати критерії вибору оптимізатора. Може бути, таким чином вдасться впоратися з невідомою оптимізатору алгеброю визначаються користувачами типів.


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


Особливості управління транзакціями в системах ООБД


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


Якої-небудь підхід, в якому пропонувався б повний набір засобів управління транзакціями, повністю узгоджується з парадигмою об’єктної орієнтованістю, нам невідомий. Одна з найбільш просунутих робіт, що проводяться в цьому напрямку в рамках німецького проекту VODAK, описується в [93].


В основі управління транзакціями в системі VODAK знаходиться розроблений раніше в контексті інженерних СУБД механізм транзакцій з вкладеними подтранзакціямі [109]: виклик будь-якої дії в об’єкті рівносильний утворення нової подстранзакціі. На відміну від традиційного механізму вкладених подтранзакцій в даному випадку заздалегідь не визначена максимальна вкладеність транзакцій. При синхронізації транзакцій використовується знання про семантику об’єктів, у тому числі інформація про коммутативности операцій. (Аналогічний підхід описаний в [110].)


Не дуже зрозуміло, як при такому підході надходити з журналізацію змін. В принципі тільки сам об’єкт знає, яка інформація може знадобитися для його відновлення, і тільки сам об’єкт може виконати таке відновлення. Може бути, слід застосовувати техніку темпоральних БД, і при кожній зміні стану об’єкта заводити його нову версію. Загалом, як нам видається, проблема журналізації і відновлення в ООБД поки залишається відкритою.


Зв’язок ООБД з дедуктивними і активними базами даних


Зв’язок напрямки ООБД з напрямком дедуктивних БД носить двоякий характер. По-перше, для структуризації дедуктивних (і взагалі логічних) БД останнім часом прагнуть використовувати парадигму об’єктної орієнтованості [83-84]. Це окрема тема, для її розгляду було б необхідно попереднє введення в концепції дедуктивних БД, що знаходиться за межами даного огляду.


По-друге, деякі механізми дедуктивних БД намагаються використовувати в контексті звичайних (може бути, кілька розширених семантично) ООБД. Це перш за все відноситься до мов запитів [82] (як ми зазначали в розд. 4, один із напрямів розвитку декларативних мов запитів до ООБД – дедуктивні мови). На логічному виведенні грунтуються в ряді проектів доказ коректності схеми ООБД і динамічний контроль цілісності [85-86]. Мабуть, в майбутніх системах ООБД логіка буде грати ще велику роль.


Роботи з інтеграції об’єктно-орієнтованих і активних БД знаходяться в початковій стадії. Відомо, що основною проблемою систем активних БД є побудова ефективного механізму обчислення на основі вступників подій умов і виклику при необхідності відповідних дій. В [42] описується експериментальна робота, виконана на базі об’єктно-орієнтованої СУБД PROBE, в якій активність ООБД забезпечується за допомогою визначення двох спеціальних класів об’єктів “active-object” і “activelist-object”. При виникненні одного із зумовлених в системі подій викликається один з методів відповідного об’єкта класу “active-object”, в якому в залежності від стану і запропонованого набору правил приймається рішення про подальші дії. Основний висновок, який можна зробити на підставі викладеного в [42] матеріалу, – це придатність основних засобів типової ООБД і для забезпечення її активності.


Висновок


У цьому огляді ми розглянули (дуже коротко) далеко не всі питання, пов’язані з ООБД. Зовсім не були розглянуті проблеми проектування ООБД і взагалі об’єктно-орієнтованого проектування БД [59], питання підтримки різнорідної (multi-media) інформації в ООБД [12], підходи до інтеграції неоднорідних БД на основі об’єктно-орієнтованого підходу [87-88], проблеми підтримки різних уявлень ООБД [89] і т.д.


Ми прагнули показати загальний стан справ (наскільки це можливо в такому короткому огляді) в найбільш важливих областях, пов’язаних з управлінням ООБД. На нашу думку, практично у всіх цих областях є маса невирішених проблем, і потреба в розвинених об’єктно-орієнтованих СУБД стимулює вирішення цих проблем.


Література:


1. Mattbew Rapaport. Object-Oriented Data Bases: The Next Step in DBMS Evolution // Comp. Lang.- 5, N 10.- 1988.- 91-98


2. Michael Stonebraker. Future Trends in Database Systems // IEEE Trans. Knowledge and Data Eng.- 1, N 1.- 1989.- 33-44


3. Oscar Nierstrasz. A Survey of Object-Oriented Concepts // In Object-Oriented Concepts, Databases and Applications, ed.


W. Kim, F. Lochovski, ACM Press and Addison-Wesley, 1989.- 3-21


4. M. A. Garvey, M. S. Jackson. Introduction to Object-Oriented Databases // Inf. and Software Technol.- 31, N


10.- 1989.- 521-528


5. Fereidoon Sadri. Object-Oriented Database Systems // COMPSAC”89 13th Annu. Int. Comput. Software and Appl. Conf., Orlando, Fla, Sept. 20-22, 1989.- 195-196


6. Stanley Y. W. Su. Extensions to the Object-Oriented Paradigm // COMPSAC”89 13th Annu. Int. Comput. Software and Appl. Conf., Orlando, Fla, Sept. 20-22, 1989.- 197-199


7. Stanley Zdonik. Directions in Object-Oriented Databases // COMPSAC”89 13th Annu. Int. Comput. Software and Appl. Conf., Orlando, Fla, Sept. 20-22, 1989.- 200


8. Malkolm Atkinson, Francois Bansilhon, David DeWitt, Klaus Dittrich, David Maier, Stanley Zdonik. The Object-Oriented Database System Manifesto // 1st Int. Conf. Deductive and Object-Oriented Databases, Kyoto, Japan, Dec. 4-6, 1989


9. The Committee for Advanced DBMS Function (Michael Stonebraker, Bruce Lindsay, Jim Gray, Make Carey, David Beech). Third Generation Data Base System Manifesto // Proc. ACM SIGMOD Int. Conf. Manag. Data, Atlanta City, NJ, USA, May 23-25, 1990, ACM SIGMOD Record.- 19, N 2.- 1990.- 34-43


10. R. P. van de Riet. Introduction to the Special Issue on Deductive and Object-Oriented Databases // Data and Knowledge Eng.- 5.- 1990.- 255-261


11. Won Kim. Object-Oriented Databases: Definition and Research Directions // IEEE Trans. Data and Knowledge Eng.- 2, N 3.- 1990.- 327-341


12. D. Woelk, W. Kim. Multimedia Information Management in a Object-Oriented Database System // 13th Int. Conf. Very Large Data Bases, Brighton, England, Sept. 1-4, 1987.- 319-330


13. Won Kim, Nat Ballou, Hong-Tai Chou, Jorge F. Garza, Darrell Woelk. Integrating an Object-Oriented Programming System with a Database System // Proc. OOPCLA”88, San Diego, Calif., USA, Sept. 25-30, 1988.- 142-152


14. Kyung-Chang Kim, Won Kim, Darrell Woelk. Acyclic Query Processing in Object-Oriented Databases // Entity-Relationship Approach: Bridge User: 7th Int. Conf., Rome, Nov. 16-18,


1988.- 329-346


15. Elisa Bertino, Won Kim. Indexing Techniques for Queries on Nested Objects // IEEE Trans. Knowledge and Data Eng.- 1, N


2.- 1989.- 196-214


16. B. Paul Jenq, Darrell Woelk, Won Kim, Wan-Lik Lee. Query Processing in Distributed ORION // Advances in Database Technology – EDBT”90.- Lecture Notes in Computer Science.- 416, 1990.- 169-187


17. Won Kim, Jorge F. Garza, Nathaniel Ballou, Darrell Woelk. Architecture of the ORION Next-Generation Database System // IEEE Trans. Knowledge and Data Eng.- 2, N 1.- 1990.- 109-124


18. D. H. Fishman. An Overview of the Iris Object-Oriented DBMS // Digest of papers, 33rd CompCon, Spring 1988, Feb. 29 – Mar. 4, USA.- 177-180


19. Peter Lyngbaek, Kevin Wilkinson, Waqar Hasan. The Iris Kernel Architecture // Advances in Database Technology – EDBT”90.- Lecture Notes in Computer Science.- 416, 1990.- 348-362


20. Kevin Wilkinson, Peter Lyngbaek, Waqar Hasan. The Iris Architecture and Implementation // IEEE Trans. Knowledge and Data Eng.- 2, N 1.- 1990.- 63-75


21. David Maier, Jacob Stein, Allen Otis, Alan Purdy. Development of an Object-Oriented DBMS // Proc. OOPCLA”86, Portland, Oreg., USA, Sept. 29 – Oct. 2, 1986.- 472-482


22. D. Jacob Penney, Jacob Stein. Class Modification in the GemStone Object-Oriented DBMS // Proc. OOPCLA”87, Orlando, Fla, USA, Oct. 4-8, 1987.- 111-117


23. Won Kim, Jay Banerjee, Hong-Tai Chou, Jorge F. Garca, Darrell Woelk. Composite Object Support in an Object-Oriented Database System GemStone Object-Oriented DBMS // Proc. OOPCLA”87, Orlando, Fla, USA, Oct. 4-8, 1987.- 118-125


24. Tomothy Andrews, Craig Harris. Combining Language and Database Advances in an Object-Oriented Development Environment GemStone Object-Oriented DBMS // Proc. OOPCLA”87, Orlando, Fla, USA, Oct. 4-8, 1987.- 430-440


25. Michael Stonebraker, Jeff Anton, Eric Hanson. Extending a Database System with Procedures // ACM Trans. Database Syst.- 12, N 3.- 1987.- 350-376


26. L. Rowe, M. Stonebraker. The POSTGRES Data Model // 13th Int. Conf. Very Large Data Bases, Brighton, England, Sept. 1-4, 1987.- 83-96


27. M. Stonebraker. The Design of the POSTGRES Storage System // 13th Int. Conf. Very Large Data Bases, Brighton, England, Sept. 1-4, 1987.- 289-300


28. Michael Stonebraker, Lawrence A. Rowe, Machael Hirohama. The Implementation of POSTGRES // IEEE Trans. Knowlwdge and Data End.- 2, N 1.- 1990.- 125-141


29. Christophe Lecluse, Philippe Richard, Fernando Velez. O2, an Object-Oriented Data Model // Proc. ACM SIGMOD Int. Conf. Manag. Data, Chicago, Ill, USA, June 1-3, 1988, ACM SIGMOD Record.- 17, N 3.- 1988.- 424-433


30. F. Velez, G. Bernard, V. Darnis. The O2 Object Manager: An Overview // 15th Int. Conf. Very Large Data Bases, Amsterdam, Aug. 22-25, 1989.- 357-366


31. C. Lecluse, P. Richard. The O2 Database Programming Language // 15th Int. Conf. Very Large Data Bases, Amsterdam, Aug. 22-25, 1989.- 411-422


32. O. Deux et al. The Story of O2 // IEEE Trans. Knowledge and Data Eng.- 2, N 1.- 1990.- 91-108


33. O. Niestrasz, D. Tsichritzis. An Object-Oriented Environment for OIS Applications // 11th Int. Conf. Very Large Data Bases, Stockholm, Aug. 21-23, 1985.- 83-96


34. D. Decouchart. Design of a Distributed Object Manager for the Smalltalk-80 System // Proc. OOPCLA”86, Portland, Oreg., USA, Sept. 29 – Oct. 2, 1986.- 444-452


35. Karen E. Smith, Stanley B. Zdonik. Intermedia: A Case Study of the Differences Between Relational and Object-Oriented Database Systems // Proc. OOPCLA”87, Orlando, Fla, USA, Oct. 4-8, 1987.- 452-465


36. Andrew Straw, Fred Mellender, Steve Riegel. Object Management in a Persistent Smalltalk System // Software Pract. and Exper.- 19, N 8.- 1989.- 719-737


37. Nick Roussopoulus, Hyun Soon Kim. ROOST: A Relational Object-Oriented System // Lect. Notes Comput. Sci.- 367.-


1989.- 404-420


38. T. F. Keefe, W. T. Tsai, M. B. Thuraisingham. SODA: A Secure Object-Oriented Database System // Computers and Security.- 8, N 6.- 1989.- 517-533


39. Prasun Dewan, Ashish Vikram, Bharat Bhargava. Engineering the Object-Oriented Database Model in O-Raid // Lect. Notes Comput. Sci.- 367.- 1989.- 389-403


40. Scott E. Hudson, Roger King. Cactis: A Self-Adaptive, Concurrent Implementation of an Object-Oriented Database Management System // ACM Trans. Database Syst.- 14, N 3.-


1989.- 291-321


41. Gilles Barbedette. LISPO2: A Persistent Object-Oriented LISP // Advances in Database Technology – EDBT”90.- Lecture Notes in Computer Science.- 416, 1990.- 332-347


42. Sharma Chakravarthy, Susan Nesson. Making an Object-Oriented DBMS Active: Design, Implementation, and Evaluation of a Prorotype. // Advances in Database Technology


– EDBT”90.- Lecture Notes in Computer Science.- 416, 1990.- 393-406


43. R. Agrawal, N. H. Gehani, J. Srinivasan. OdeView: The Graphical Interface to Ode // Proc. ACM SIGMOD Int. Conf. Manag. Data, Atlanta City, NJ, USA, May 23-25, 1990, ACM SIGMOD Record.- 19, N 2.- 1990.- 34-43


44. Stefano Ceri, Stafano Crespi-Reghizzi, Roberto Zicari, Gianfranco Lamperti, Luigi A. Lavazza. Algres: An Advanced Database System for Complex Applications // IEEE Software.- 7, N 4.- 1990.- 68-78


45. Michael L. Nelson, J. Michael Moshell, Ali Orooji. A Relational Object-Oriented Management System // 9th Annu. Int. Phoenix Conf. Comput. and Commun.- Scottsdale, Aris., USA, March 21-23, 1990.- 319-323


46. Stefan Bottcher. Attribute Inheritance Implemented on Top of a Relational Database System // 6th Int. Conf. Data Eng., Los Angeles, Calif., USA, Febr. 5-9, 1990.- 503-509


47. Simon Gibbs, Vassilis Prevelakis. Xos: An Overview // In Object Management, Ed. D. Tsichritzis, Centre Universitaire d”Informatique, Universite de Geneve, 1990.- 37-61


48. M.J. Carey, D.J. DeWitt et al. Object and File Management in the EXODUS Extensible Database System // 12th Int. Conf. Very Large Data Bases, Kuoto, Japan, Aug. 1986.- 91-100


49. D. S. Batory, J. R. Barnett, J. F. Garza, K. P. Smith, K. Tsukuda, T. E. Wise. GENESIS: An Extensible Database Management System // // IEEE Trans. on Software Eng.- 14, N


11.- 1988.- 1711-1730


50. Hans-Joerg Schek, Heinz-Bernhard Paul, Marc H. Scholl, Gerhard Weikum. The DASDBS Project: Objectives, Experiences, and Future Prospects // IEEE Trans. Knowledge and Data Eng.- 2, N 1.- 1990.- 25-43


51. Laura M. Haas, Walter Chang, Guy M. Lohman et al. Starburst Mid-Flight: As the Dust Clears // IEEE Trans. Knowledge and Data Eng.- 2, N 1.- 1990.- 143-159


52. Raymond Lorie, Won Kim, Dan McNabb, Wil Plouffe. Supporting Complex Objects in a Relational System for Engineering Databases // In Query Processing in Database Systems, ed. Won Kim, David S. Reiner, Dan. S. Batory, Springer-Verlag, 1985.- 145-155


53. Raymond A. Lorie, Jean-Jacques P. Daudenarde. On Extending the Realm of Application of Relational Systems // In Information Processing 86, ed. H.-J. Kugler, Elsevir Science Publishers, 1986.- 889-894


54. Won Kim, Hong-Tai Chou, Jay Banerjee. Operations and Implementation of Complex Objects // IEEE Trans. on Software Eng.- 14, N 7.- 1988.- 985-996


55. Mohammad A. Ketabchi, Valdis Berzins. Mathematical Model of Composite Objects and Its Application for Organizing Engineering Databases // IEEE Trans. on Software Eng.- 14, N


1.- 1988.- 71-84


56. Anant Jhingran, Michael Stonebraker. Alternatives in Complex Object Representation: A Performance Persrective // 6th Int. Conf. Data Eng., Los Angeles, Calif., USA, Febr. 5-9,


1990.- 94-102


57. Serge Abiteboul, Richard Hull. IFO: A Formal Semantic Database Model // ACM Trans. Database Syst.- 12, N 4.- 1987.- 525-565


58. Joan Peckham, Fred Maryanski. Semantic Data Models // ACM Comp. Surv.- 20, N 3.- 1988.- 153-189


59. Shamkant B. Navathe, Mohan K. Pillalamarri. OOER: Toward Making the E-R Approach Object-Oriented // Entity-Relationship Approach: Bridge User: 7th Int. Conf., Rome, Nov. 16-18,


1988.- 185-206


60. Craig Damon, Gordon Landis. Abstract Types and Storage Types in an OO-DBMS // Digest of papers, 33rd CompCon, Spring 1988, Feb. 29 – Mar. 4, USA.- 172-176


61. Richard Hull, Katsumi Tanaka, Masatoshi Yoshikawa. Behavior Analysis of Object-Oriented Databases: Method Structure, Execution Trees, and Reachibility // Lect. Notes Comput. Sci.- 367.- 1989.- 372-388


62. Mojtaba Mozaffari, Yuzuri Tanaka. ODM: An Object-Oriented Data Model // New. Generat. Comp.

Схожі статті:


Сподобалася стаття? Ви можете залишити відгук або підписатися на RSS , щоб автоматично отримувати інформацію про нові статтях.

Коментарів поки що немає.

Ваш отзыв

Поділ на параграфи відбувається автоматично, адреса електронної пошти ніколи не буде опублікований, допустимий HTML: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

*

*