Співвідношення гібридного і розширеного реляційного підходів

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

 

Мал. 6.3. Співвідношення класів СУБД: реляційних, об’єктно-орієнтованих,
гібридних і розширених реляційних

 

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

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

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

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

 

Мал. 6.4. Вірогідна еволюція інтерфейсів між об’єктно-орієнтованими

мовами і Реляційними СУБД

 

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

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