morozov_lektsiyi

Тема 6. Об’єктно-орієнтовані бази даних

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

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

Деякі класи додатків, які стали актуальними в 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-х років, витікає головним чином з мети - представлення реального світу.

6.2.Концепції об’єктно-орієнтованих баз даних

З характеристик об’єктно-орієнтованих баз даних викристалізувався ряд концепцій. До їх числа відносяться:

-індивідуальність об’єктів;

-атрибути;

-методи;

-класи;

-ієрархії класів і наслідування.

6.2.1.Індивідуальність об’єктів

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

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

6.2.2. Атрибути

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

6.3.3. Методи

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

Якщо наш об’єкт - це CD (компакт-диск), то можна застосувати такі методи:

-Метод 1 - введення даних. Перш ніж ввести дані, переконатися, що ID для даного CD, що вводиться є унікальним.

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

-Метод 3 - зняття з продажу. Понизити ціну на кожний CD цього типу, що є в даний час в магазині, на 40% зараз і додатково на 20% наступного тижня для залишку; більше не замовляти такі CD.

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

6.3.4.Класи

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

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

Якщо розглянути приклад про службовців і товари, то такий приклад ієрархії класів, в якій підкласи успадковують атрибути суперкласу (іноді використовуються терміни „підтип” і „супертип”) і мають також деякі нові атрибути, специфічні для цих об’єктів. Наприклад, клас Товари має деяку множину атрибутів (Назва, Кількість в наявності і т.д.), які відносяться як до CD, так і до відеокасет. Підклас CD має, разом з ними і такі атрибути, як Число доріжок, Ім’я артиста, Головний розповсюджувач. Підклас Відеокасети не має цих атрибутів CD, але має інші атрибути - Звичайна і Поточна ціни прокату, чи Є записаний на касеті фільм продовженням і т.д.

6.3.6. Довготривале зберігання

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

-включаюча мова програмування є також і мовою маніпулювання даними (ММД);

-моделі, пов’язані з представленням в оперативній пам’яті і в зовнішній пам’яті, зливаються;

-не вимагається ніякого перетворення коду між моделями і мовами.

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

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

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

6.5. Об’єктно-орієнтовані механізми управління даними і моделі

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

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

Маніфест встановлює три категорії характеристик ООБД:

1)обов’язкові - система повинна володіти цими характеристиками для того, щоб вона „заслуговувала” права вважатися ООБД;

2)необов’язкові – ці характеристики покращують функціональні можливості системи, але не є обов’язковими;

3)відкриті ~ характеристики, які проектувальник може вибирати серед прийнятних альтернатив.

Обов’язкові характеристики були далі розбиті на два класи:

1. Система повинна бути СУБД, і це означає, що вона повинна підтримувати:

-довготривале зберігання даних;

-управління зовнішньою пам’яттю;

-паралелізм;

-відновлення;

-засоби обробки нерегламентованих запитів.

Перераховані характеристики є широко відомими функціями, які вже розглядалися. Тому не обговорюватимемо їх тут детально.

2. Система повинна бути ООСУБД, і тому їй повинні бути властиві наступні вісім характеристик:

-підтримка складних об’єктів;

-індивідуальність об’єктів;

-інкапсуляція;

-типи і класи;

-спадкоємство;

-перевантаження в поєднанні з пізнім зв’язуванням;

-обчислювальна повнота;

-розширюваність.

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

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

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

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

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

2.Перевірка типів і вивід типів. Кращим є таке середовище, в якому велика частина перевірки типів здійснюється на стадії компіляції. Проте маніфест залишає відкритим питання про те, чи має це місце і якою мірою виконується така перевірка на стадії компіляції.

3.Розподіл. Обговорення технологій розподілених баз даних відноситься також і до об’єктно-орієнтованих баз даних.

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

5.Версії. Вельми бажана підтримка множини версій об’єктів.

Нарешті, до числа відкритих характеристик, для яких існує безліч варіантів, авторами Маніфесту віднесено:

1.Парадигма програмування. Розробник повинен мати нагоду використовувати будьяку парадигму, яку він побажає, - процедурну, декларативну, засновану на правилах і т.д.

2.Система уявлення. Атомарні типи (з мов програмування) і конструктори (конструктори множин, списків і кортежів) можуть бути розширені багатьма різними способами для підтримки об’єктної орієнтації.

3.Система типів. Всі „формувачі типів”, за винятком інкапсуляції, такі, як родові типи

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

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

6.6. Діяльність ODMG по стандартизації

Object Database Management Group, яка взяла на себе рішення цих проблем. Мета ODMG полягала в тому, щоб забезпечити переносимість:

- схем даних;

-зв’язування мов програмування;

-мов маніпулювання даними;

-мов запитів.

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

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

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

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

Тип

Об’єкт Об’єкт

Об’єкт Об’єкт

Операції

Поведінка

Об’єкт

Властивості

Зв’язки

Мал. 6.5. Основні елементи об’єктної моделі ODMG

Модель ODMG підтримує три різні варіанти часу життя об’єкту:

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

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