- 10.1 Об’єктно-орієнтована модель ODMG
- 10.2 Мова опису об’єктів ODL ODMG
- 10.3 Об’єктна мова запитів OQL ODMG
- 10.4 Архітектура ООСКБД
Ключові терміни:
OQL ODMG, клас, літерал, об’єкт, поведінка об’єкта, поліморфізм, реалізаційна частина, стан об’єкта, успадкування, інтерфейсна частина10.1 Об’єктно-орієнтована модель ODMG
В об’єктно-орієнтованій моделі дані та методи, що їх обробляють, об’єднуються в структури, які називаються об’єктами. Типи об’єктів називаються класами. З точки зору баз даних є такі важливі особливості об'єктно-орієнтованої моедлі (далі ООМ):
- підтримка структур даних, що мають довільний рівень складності;
- ідентифікованість та унікальність об’єктів;
- належність об’єктів класам;
- інкапсуляція;
- успадкування та ієрархії класів;
- поліморфізм.
Складні структури даних. Складні об’єкти будуються з простіших за допомогою конструкторів. Найпростішими об’єктами є: числа, символи, символьні рядки довільної довжини, булеві змінні тощо. Існують різні конструктори складних об’єктів (кортежів, множин, мультимножин, списків та масивів). Мінімальний набір конструкторів, який повинна мати система, - це конструктори множин, списків і кортежів. Множини необхідні, оскільки завдяки їм набори об’єктів реального світу зображуються в природний спосіб. Кортежі надають спосіб зображення властивостей сутностей. Списки та масиви потрібні для відображення впорядкованості об’єктів реального світу, а також для зображення широкого кола математичних об’єктів.
Будь-який конструктор має бути застосовним до будь-якого об’єкту (наприклад, повинна надаватися можливість побудови множини з масивів або масиву з множин). Конструктори реляційної моделі не мають такої властивості, оскільки конструкція множини може бути застосована лише до кортежів, а конструкція кортежу - лише до атомарних значень. Навіть реляційна модель, що підтримує ненормалізовані відношення (тобто відношення, які не перебувають у першій нормальній формі), не має вказаної властивості, оскільки конструкцією верхнього рівня завжди має бути відношення.
Маніпулювання складними об’єктами забезпечується відповідними операціями, які часто розповсюджуються на всі компоненти таких об’єктів. Прикладом може бути вибирання чи видалення складного об’єкту або створення його копії. Існує можливість визначати додаткові операції над складними об’єктами.
Ідентифікованість, унікальність і стан об’єктів. Кожний об’єкт є унікальним, тобто забезпечується унікальна ідентифікація об’єктів (для мов програмування унікальними ідентифікаторами можуть бути адреси пам’яті, за якими зберігаються об’єкти).
Стан об’єкта — це поточне значення, приписане об’єкту. Об’єкт може мати єдиний стан протягом свого життєвого циклу або переходити з одного стану в інший. Оскільки об’єкти мають властивість інкапсуляції (що буде розглянута нижче), то стан об’єкта є абстракцією, яка визначається лише через його поведінку (методи).
Унікальність об’єкта не залежить від його стану. Два об’єкти, що перебувають в одному й тому ж стані, є рівними, але не ідентичними. Не може існувати двох або більше екземплярів одного об’єкта (двох копій одного й того самого об’єкта з одним і тим самим ідентифікатором) У моделі з ідентифікованістю об’єктів об’єкт існує незалежно від свого значення. Отже, є два поняття еквівалентності об’єктів: об’єкти можуть бути ідентичними (бути одним і тим самим об’єктом) або вони можуть бути рівними (перебувати в одному й тому самому стані). У цьому контексті слід розглянути такі два аспекти: розрізнення та змінення об’єктів.
Розрізнення об’єктів. У моделі з об’єктами, що ідентифікуються, два об’єкти можуть спільно використовувати компоненти (зокрема інші об’єкти). Отже, схематичним відображенням складного об’єкта є граф, натомість у системі без ідентифікованості об’єктів - це дерево.
Розглянемо такий приклад: людина має ім’я, вік і дітей. Припустимо, що Іван і Марія мають сина на ім’я Петро. У реальному житті можуть мати місце дві ситуації: Іван і Марія є батьками однієї і тієї самої дитини або кожний із них має по сину. У моделі з ідентифікованістю об’єктів адекватно відображуються обидві ситуації.
Зміна об’єктів. Припустимо, що Іван і Марія є батьками хлопчика на ім’я Петро. Тоді зміни, що стосуються сина Марії, будуть виконуватися з об’єктом Петро, відтак і з сином Івана.
Поведінка об’єктів. Поведінка об’єкта це сукупність операцій (методів), які він надає. Лише через ці операції розкривається семантика об’єкта. Виконання операцій є єдиним способом взаємодії між об’єктами. Всі можливі операції об’єкта утворюють його інтерфейс. Лише використовуючи операції, можна змінити стан об’єкта.
Класи об’єктів. В об’єктно-орієнтованій моделі клас узагальнює спільні риси об’єктів, що мають однакові властивості, й відповідає поняттю абстрактного типу даних. Клас означує спосіб реалізації множини об’єктів, встановлюючи їхню структуру, поведінку та інтерфейс, тобто спосіб запам’ятовування інформації про їхні стани. Проте власне стан має запам’ятовувати сам об’єкт.
Клас є водночас фабрикою та сховищем об’єктів. Як фабрика об’єктів клас використовується для створення нових об’єктів. Термін сховище об’єктів означає, що до класу приєднується набір об’єктів, які є його екземплярами. Отже, класи використовуються для створення об’єктів і маніпулювання ними.
Однією з основних властивостей класу, відтак і його об’єктів, є інкапсуляція.
Інкапсуляція. Інкапсуляція вимагає, щоб дані та програмні коди для маніпулювання даними були приховані. З цієї точки зору об’єкт поділяється на інтерфейсну й реалізаційну частини. Інтерфейсна частина є специфікацією набору операцій, допустимих над об’єктом. Лише ця частина об’єкта видима для методів інших об’єктів. Реалізаційна частина складається з даних, що описують стан об’єкта, і процедур, що реалізують операції над об’єктом. Інкапсуляція специфікується на рівні оголошення класу.
Успадкування. Успадкування є механізмом, що дає змогу створювати нові класи з використанням даних і методів інших класів. Це дає можливість деякі властивості, спільні для багатьох класів, описувати в базовому класі.
Наприклад, якщо необхідно додати новий клас Одяг, що повністю збігається з класом Товар, за винятком наявності додаткових відомостей про розмір, мовою Java це можна записати так:
public class Одяг extends Товар {
int розмір:
}
У такий спосіб ми вказали, що Одяг — це Товар, тому перший має всі дані й методи другого, а також власні дані, що зберігаються в змінній розмір. Успадкування дає змогу будувати ієрархію класів.
Поліморфізм. Принцип поліморфізму є розширенням принципу успадкування й дає змогу переозначувати методи в успадкованих класах.
Наприклад, є кілька різновидів товарів, для яких властиві специфічні правила обчислення ціни. Зокрема товарами можуть бути продукти, на які не діють націнки, та одяг, на який націнка встановлена. Всі товари успадковують метод Сумарна ціна() з базового класу Товар, але правила обчислення ціни можуть бути різними. Це означає, що кожний клас, який є нащадком класу Товар, може мати власну реалізацію методу Сумарна_ціна(). Тому вираз х. Сумарна ціна () може означати різні правила обчислення ціни залежно від того, екземпляром якого класу є об’єкт х.
10.2 Мова опису об’єктів ODL ODMG
Будь-яка СКБД має мову опису даних (МОД), що використовується для опису схем баз даних. Мова опису об’єктів ODL ODMG розглядається як розширення МОД, призначене для опису об’єктів, їхніх атрибутів, зв’язків та операцій. Основою цієї мови стала мова IDL (Interface Definition Language), розроблена групою OMG.
Мова ODL є абстрактною в тому розумінні, що згенерована ODL-схема має бути незалежною від мов програмування та конкретної СКБД. У зв’язку з цим в ODL розглядаються лише аспекти означення об’єктів різних типів і повністю ігноруються питання реалізації методів. Згенерована ODL-схема може вільно переміщуватися між СКБД, що підтримують концепцію ODMG, використовуватися програмами, записаними різними мовами програмування, і навіть транслюватися в конкретні МОД, наприклад ті, які базуються на стандарті SQL-1999.
10.2.1. Основні положення
ODL - це мова, призначена насамперед для специфікації класів. Вона підтримує об’єктну модель ODMG і не є мовою програмування. Більше того, ODL незалежна від мов програмування. Основна мета розробки цієї мови - створити єдину основу для опису об’єктів і тим самим забезпечити перенесення схем об’єктних даних між різними ООСКБД.
Основні положення об’єктної моделі даних ODMG:
- базовим поняттям моделі є об’єкт;
- поведінка об’єкта визначається за допомогою множини його операцій;
- стан об’єкта визначається за допомогою множини його властивостей:
- об’єкти належать до класів, саме через класи вони специфікуються;
- клас має інтерфейсну та реалізаційну частини;
- клас є об’єктом;
- ODL специфікує класи.
В об’єктній моделі ODMG мова йде насамперед про типи, а вже потім про класи. Клас розглядається як різновид типу, що має одну реалізацію. У загальному випадку допускається, що тип має кілька реалізацій. Множинність реалізацій типу необхідна для підтримки неоднорідних баз даних, розподілених у мережі, та середовищ з різними мовами програмування й компіляторами. Нас не пікавить реалізація, тому далі основна увага приділятиметься класам.
10.2.2. Система типів ODL
Базовими типами мови є: integer, float, string, boolean, перелічувані типи, що створюються за допомогою ключового слова enum, та класи. Похідні типи створюються за допомогою конструкторів типів. Є конструктор Struct для структур і чотири конструктори для типів колекцій: Set, Bag, List, Array. Опис структур і колекцій наведено далі.
10.2.3. Об’єкти
Основні характеристики об’єктів:
- OID унікально ідентифікує об’єкт, відрізняючи його від інших об’єктів тієї предметної області, де він був створений. Будь-який об’єкт має лише один OID, але може мати більше одного імені. Об’єкти можуть ідентифікуватися предикатами, визначеними на їхніх властивостях.
- Видалення об’єкта не призводить до рекурсивного видалення пов’язаних із ним об’єктів.
На рис. 10.1 наведена класифікація об’єктів.
Рисунок 10.1 – Класифікація об’єктів у ODL
10.2.4. Літерали
Літерали — це об’єкти, екземпляри яких не можна змінювати. Для наперед визначених типів літералів не можна змінювати операції. На рис. 10.2 наведена класифікація літералів.
Рисунок 10.2 – Класифікація літералів
10.3 Об’єктна мова запитів OQL ODMG
OQL ODMG - це незалежна мова запитів до об’єктної моделі даних ODMG, синтаксис якої базується на мові SQL. Окрім того, передбачається можливість її використання в мовах програмування.
Мова запитів орієнтована на побудову виразів, її конструкції мають такі властивості:
- будь-який запит є виразом, що має тип — об’єкт або літерал;
- вирази та операції над ними можуть вкладатися одне в одне;
- результатом виконання запиту є об’єкти, що належать типам, означеним у моделі ODMG, і можуть брати участь у формуванні виразів.
Мова має високорівневі примітиви для маніпулювання множинами, об’єктами, структурами, масивами і списками. У ній відсутні оператори оновлення, замість них використовуються операції, визначені для об’єктів. Передбачається, що всі створювані об’єкти мають OID, а літерали унікально ідентифікуються своїм значенням.
10.3.1. Запити OQL
В OQL запитом може бути будь-який вираз, що повертає об’єкт, колекцію об’єктів, літерал або колекцію літералів. Оскільки запит — це вираз, а будь-який вираз має тип, то й будь-якому запиту ставиться у відповідність тип.
Найпоширенішим різновидом запиту, як і в SQL, є select-запит.
Приведений нижче запит знаходить множину осіб чоловічої статі, й при цьому типом значення, що повертається, буде Bag<Person>:
SELECT х
FROM persons x
WHERE x.sex = ‘M’
Зазначимо, що select-вираз повертає колекцію типу Bag, тобто мультимножину (множина зі значеннями, що повторюються). Використання слова DISTINCT приводить до того, що тип колекції, яка повертається, - Set, тобто множина. Наведений нижче запит повертає список номерів факультетів для людей на ім’я Pete, тобто літерал типу Set<integer>.
SELECT DISTINCT x.faculty_id FROM persons x WHERE x.name = 'Pete'
Зауважте, що в запитах слід звертатися саме до екстентів, а не до класів.
10.3.2. Обчислення проміжних результатів
Запит можна не лише сформулювати для виконання, але й визначити для подальшого використання в інших запитах (певний аналог віртуальних таблиць, створюваних командою CREATE VIEW у мові SQL). Це досягається за допомогою означення запиту, що має такий вигляд:
define ім’я_запиту as вираз
define Joe as element (
SELECT x
FROM students x
WHERE x.name = 'Joe')
Тут element є перетворювачем типу, що зводить тип одноелементної колекції до типу елементу. Отже, Joe є іменем об’єкта класу students із значенням атрибута name рівним 'Joe'. Тепер до об’єкта Joe можна звернутися, наприклад, для отримання значень його атрибутів. Так, вирази Joe.Віrthdate. Joe.faculty_id. Joe.passport повертають дату народження, номер факультету і номер паспорта студента на ім’я Joe.
Ім'я запиту розглядається як елементарний вираз, як і змінні, атоми та пойменовані об’єкти. Приклади елементарних виразів: 27, nil, students, Joe.
10.4 Архітектура ООСКБД
Є різні підходи до створення ООСКБД. Крім розробки власне об’єктно- орієнтованих СКБД, є численні способи поєднання об’єктно-орієнтованої та реляційної моделей даних. Усі ці підходи ми розглянемо далі.
10.4.1. Розширення реляційних СКБД
Реляційні СКБД надають можливість звертатися до них програмам, написаним різними, зокрема об’єктно-орієнтованими, мовами програмування. У цьому випадку об’єктно-орієнтовані прикладні програми виконують усі функції, пов’язані з відображенням об’єктної моделі в реляційну, тобто перетворюють об’єкти на структури даних, які можуть бути безпосередньо записані в табличні БД, підтримують властивості успадкування, інкапсуляції, зв’язування з об’єктами їхніх методів.
РСКБД бере на себе єдину функцію - зберігання даних, які пов’язані з об’єктами, причому зберігання у вигляді реляційних таблиць, усе інше виконує прикладна програма.
Даний підхід передбачає включення до складу РСКБД засобів, які полегшують процес відображення об’єктів у базі даних і маніпулювання ними. Тобто сама РСКБД удосконалюється, полегшуючи обробку об’єктів, але залишається при цьому реляційною. До можливих розширень РСКБД належать такі.
- Надання можливості автоматичного створення унікальних ідентифікаторів кортежів відношень. Наприклад, в Огасlе є тип rowid, який виконує цю функцію. Такий тип сприяє вирішенню проблеми підтримки OID, хоча й не вирішує її повністю, оскільки OID має бути унікальним у всій базі даних, а не в межах одного відношення, як rowid.
- Створення механізмів означення нових типів даних (такі механізми є в мовах програмування). Введення нових типів, навіть якщо вони відповідають досить складним структурам даних, не суперечить реляційній моделі. Інша річ, що реляційна модель в «чистому» вигляді не надає можливості працювати зі складеними структурами даних, вони розглядаються як атомарні.
Перевага підходу, який базується на розширенні реляційних СКБД, полягає в тому, що надається можливість використовувати всю потужність реляційних систем баз даних. Недолік - слабка розвиненість засобів зображення об’єктів і маніпулювання ними, багато з цих функцій виконують прикладні програми.
10.4.2. Створення самостійних ООСКБД
Об’єктно-орієнтовані СКБД реалізують гнучку модель даних, яка базується на тій же парадигмі, що й об’єктно-орієнтовані мови програмування. ООБД забезпечують глибшу інтеграцію з об’єктно-орієнтованими додатками, ніж реляційні бази даних, і мінімізують обсяг роботи з програмування збереження і вибирання об’єктно-орієнтованих даних.
Переваги використання однакових моделей у додатках та базі даних виявляються тоді, коли об’єктно-орієнтовані моделі є складними. Якщо ієрархія успадкування є багаторівневою, колекції перетворюють граф об’єкта на павутину, застосуванням складно використовувати поліморфізм та посилання, об’єктна база даних робить такі застосування меншими і їхня продуктивність підвищується. Це знижує витрати на написання і налагодження програмного коду й підвищує загальну продуктивність застосувань
Самостійні ООСКБД забезпечують повну підтримку об’єктно-орієнтованої парадигми. Це передбачає безпосередню інтеграцію з об’єктно-орієнтованими мовами програмування, підтримку об’єктних типів, зв’язків між об’єктами та операцій бази даних, які інтерпретують об’єкти (найчастіше об’єкти інтерпретуються як записи) Прикладами об’єктно-орієнтованих операцій бази даних можуть бути: створення посилань на об’єкти і завантаження з бази даних об’єктів, на які є посилання, забезпечення блокування на об’єктному рівні й повернення об’єктів як результатів запитів або операцій з курсорами.
Інкапсуляція. Стабільна (persistent) поведінка класу є незалежною від проектування бази даних, яке не потребує змінення реалізацій класів.
Успадкування. Об’єкт інтерпретується одним записом незалежно від того, наскільки глибокою є ієрархія успадкування. Всі дані об’єкту запам’ятовуються в єдиному записі. Коли об’єкт вибирається з бази даних, усі дані базового класу та всі дані похідних класів завжди доступні.
Поліморфізм. Концепція поліморфізму тісно пов’язана з успадкуванням. Стосовно об’єктно- орієнтованих баз даних це означає, що можна оперувати різними класами за допомогою спільного базового класу, одержуючи дані з об’єктів необхідного похідного класу. Тобто об’єкт базового класу може мати тип похідного класу. Якщо ви послідовно переглядаєте всі екземпляри базового класу, то будете одержувати всі об’єкти цього класу, незалежно від того, якого вони типу. Видалення екземпляра базового класу призводить до видалення всього об’єкту, включаючи дані похідних об’єктів.
Ідентифікованість об’єкта. ООСБД поєднують ідентифікованість об’єкта в базі даних з ідентифіковашстю об’єкта в оперативній пам’яті. Якщо виконується збереження об’єкта, то ООСБД «знає», чи відповідає він об’єкту з бази даних (чи є він у базі даних), а під час вибирання об’єкта з бази даних - чи є він у пам’яті. Програмісту не потрібно власноруч підтримувати відповідність між об’єктами бази даних і об’єктами в пам’яті.
Посилання на об’єкти. Самостійні ООСКБД дають можливість створювати в пам’яті посилання на об’єкти, а потім відображувати їх у базі даних і навпаки.
Переваги та недоліки. Перевагою ООСКБД є їхня повна узгодженість із об’єктно-орієнтованою парадигмою програмування, що знімає всі проблеми, пов’язані зі зберіганням і маніпулюванням об’єктами у базі даних.
Основний недолік пов’язаний з тим, що для самостійних ООСКБД слід вирішувати весь комплекс проблем, пов’язаних із СКБД, які вже вирішені в наявних реляційних СКБД.
10.4.3. Об’єктно-реляційні СКБД
Особливість даного підходу полягає в тому, що на базі наявних реляційних СКБД реалізується об’єктно-орієнтований інтерфейс. Робота з цим інтерфейсом здійснюється так само, як і в ООСКБД, але всі проблеми, пов’язані зі створенням і веденням баз даних, вирішуються в реляційній СКБД.
Основна проблема, пов’язана зі створенням такого інтерфейсу, — відображення об’єктно-орієнтованої моделі в реляційну. Є кілька способів інтеграції об’єктного і реляційного підходів, що будуть розглянуті далі.
Об’єктно-реляційний шлюз
Об’єктно-реляційний шлюз автоматично виділяє об’єкти програми й зберігає їх у реляційній базі даних.
Об’єктно-орієнтований додаток працює як звичайний користувач СКБД (рис. 10.3). Такий варіант дає змогу програмістам повністю сконцентруватися на об’єктно-орієнтованому проектуванні
Рисунок 10.3 – Використання об’єктно-реляційного шлюзу
Об’єктно-реляційний прошарок між об’єктною та реляційною СКБД
У разі використання об’єктно-орієнтованого прошарку програма взаємодіє з БД за допомогою мови ООСКБД, а прошарок замінює всі об’єктно-орієнтовані елементи цієї мови на їхні реляційні еквіваленти (рис. 10.4).
Рисунок 10.4 – Використання об’єктно-реляційного прошарку
За це доводиться розплачуватися продуктивністю. Окрім іншого, прошарок має перетворювати об’єкти на набори зв’язаних відношень, генерувати унікальні OID об’єктів і передавати ці дані до реляційної БД.
Уніфікована об’єктно-реляційна СКБД
Цей підхід передбачає створення гібридних об’єктно-реляційних СКБД, що можуть зберігати як табличні дані, так і об’єкти. Вважається, що майбутнє саме за гібридними СКБД. Сьогодні розробники реляційних СКБД починають додавати до своїх продуктів об’єктно-орієнтовані засоби.
