Характеристики і мотивація об’єктно-орієнтованих баз даних

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

 

Деякі класи додатків, які стали актуальними в 80-і роки, зокрема автоматизоване проектування (Computer-Aided Design, CAD) і автоматизована розробка програмного забезпечення (Computer-Aided Software (or Systems) Engineering, CASE) або систем, яскраво проявили ці недоліки, оскільки CAD, CASE, а також подібні їм додатки виявлялися надзвичайно важкими для виконання у вигляді надбудови над реляційними системами баз даних Якщо виразити цю ситуацію в більш спеціальних термінах, розробники додатків зіткнулися з великими труднощами, пов’язаними з відображенням структур даних, необхідних для CAD- або CASE-систем, в табличні структури реляційних баз даних.

 

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

 

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

- Типи даних. Реляційні СУБД підтримують обмежену множину типів даних (літерні, цілі, з плаваючою крапкою, дати і деякі інші); моделі реального світу і моделі проміжного представлення відводять важливе місце абстрактним типам даних, що визначаються користувачем (наприклад, тип „відео”).

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

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

 

Мал. 6.1. Сурогатний об’єктно-орієнтований рівень

 

 

Мал. 6.2. Просте середовище ООСУБД/ООБД (більше ніяких відображень)

 

 

Об’єктно-орієнтовані бази даних (або об’єктно-орієнтований підхід взагалі) мають наступні характеристики:

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

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

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

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

Мотивація використовування об’єктно-орієнтованих баз даних, а також сукупності їх характеристик, що сформувалася з часу первинних експериментів в 80-х років, витікає головним чином з мети - представлення реального світу.