Об'єктно-орієнтована модель. Об'єктно-орієнтована модель даних. Обмежена підтримка обмежень цілісності

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

Стандартна ООМ описана у рекомендаціях стандарту ODMG-93 (Object Database Management Group – група управління об'єктно-орієнтованими базами даних). Реалізувати в повному обсязі рекомендації ODMG-93 поки що не вдається. Для ілюстрації ключових ідей розглянемо дещо спрощену модель об'єктно-орієнтованої БД.

Структура ГО БД графічно представлена як дерева, вузлами якого є об'єкти. Властивості об'єктів описуються деяким стандартним типом (наприклад, рядковим - string) або типом, що конструюється користувачем (визначається як class).

Значення якості типу string є рядок символів. Значення якості типу class є об'єктом, що є екземпляром відповідного класу. Кожен об'єкт-примірник класу вважається нащадком об'єкта, у якому визначено як властивість. Об'єкт-примірник класу належить своєму класу і має одного з батьків. Родові відносини у БД утворюють пов'язану ієрархію об'єктів.

Приклад логічної структури ГО БД бібліотечної справи наведено на рис. 3.14. Тут об'єкт типу БІБЛІОТЕКА є батьківським для об'єктів-примірників класів АБОНЕНТ, КАТАЛОГ та ВИДАЧА. Різні об'єкти типу КНИГА, що мають одного і того ж батька, повинні відрізнятися принаймні інвентарним номером (унікальний для кожного екземпляра книги), але мають однакові значення властивостей isbn, удк, назваі автор.

Рис.3.14.Логічна структура бази даних бібліотечної справи

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

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

Розглянемо коротко поняття інкапсуляції, успадкування та поліморфізму стосовно ООМ БД.

Інкапсуляціяобмежує область видимості імені властивості межами об'єкта, в якому воно визначено. Так, якщо до об'єкта типу КАТАЛОГ додати властивість, що задає телефон автора книги та має назву телефон,то ми отримаємо однойменні властивості об'єктів АБОНЕНТ і КАТАЛОГ. Сенс такої властивості визначатиметься тим об'єктом, у якому він інкапсульований.

успадкування,навпаки, поширює область видимості якості всіх нащадків об'єкта. Так, усім об'єктам типу КНИГА, що є нащадками об'єкта типу КАТАЛОГ, можна приписати властивості об'єкта-батька: isbn, удк, назваі автор.Якщо необхідно розширити дію механізму спадкування на об'єкти, що не є безпосередніми родичами (наприклад, між двома нащадками одного з батьків), то в їхньому загальному предку визначається абстрактна властивість типу abs. Так, визначення абстрактних властивостей квитокі номерв об'єкті БІБЛІОТЕКА призводить до успадкування цих властивостей усіма дочірніми об'єктами АБОНЕНТ, КНИГА та ВИДАЧА. Невипадково тому значення властивості квитоккласів АБОНЕНТ та ВИДАЧА, показаних на малюнку, будуть однаковими – 00015.

Поліморфізмв объектно-ориентированных мовами програмування означає здатність однієї й тієї ж програмного коду працювати з різнотипними даними. Іншими словами, він означає допустимість в об'єктах різних типів мати методи (процедури чи функції) з однаковими іменами. Під час виконання об'єктної програми одні й самі методи оперують з різними об'єктами залежно від типу аргументу. Стосовно нашої ГО БД поліморфізм означає, що об'єкти класу КНИГА, які мають різних батьків класу КАТАЛОГ, можуть мати різний набір властивостей. Отже, програми з об'єктами класу КНИГА можуть містити поліморфний код.

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

Основним гідністюООМ даних у порівнянні з реляційною є можливість відображення інформації про складні взаємозв'язки об'єктів. ООМ даних дозволяє ідентифікувати окремий запис бази даних та визначити функції їх обробки.

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

Рис.3.15.Фрагмент бази даних з об'єктом-метою

Знову звернемося до завдання Замовлення, поданого у вигляді реляційної моделі даних на рис. 3.8, та розглянемо її в термінах об'єктно-орієнтованої бази даних. Загалом у прикладі три класи: « Клієнти», « Замовлення» та « Товари». Об'єктами класу « Клієнти» є конкретні клієнти; характеристики класу - № клієнта, Ім'я клієнта Місто, Статус і т.п. Методи класу – « Створити замовлення», « Оплатити рахунок" і т.п. Метод - це деяка операція, яку можна застосувати до об'єкта; Метод – те, що повинен робити об'єкт. Клас, що відповідає таблиці « Відомості про замовлення", не вимагається. Дані таблиці можуть бути частиною класу Замовлення». Наявність у класі « Клієнтиметоду « Створити замовлення» призводить до взаємодії з об'єктами класів « Замовлення» та « Товари». При цьому користувачеві не треба знати про цю взаємодію об'єктів. Користувач лише звертається до об'єкта « Замовлення» та використовує метод « Створити замовлення». Факт на інші бази даних може бути прихований від користувача. Якщо метод « Створити замовлення», у свою чергу, звертається до методу « Перевірити кредитоспроможність клієнта», цей факт також може бути прихований від користувача. У реляційних базах даних для виконання тих самих функцій потрібно писати процедури мовою Visual Basic for Application (VBA).

У 90-х роках існували експериментальні прототипи ГО систем управління базами даних. В даний час такі системи набули широкого поширення. Зокрема, до них належать наступні СУБД: POET (POET Software), Jasmine (Computer Associates), Versant (Versant Technologies), O2 (Ardent Software), ODB-Jupiter (науково-виробничий центр «Інтелтек Плюс»), а також Iris , Orion та Postgres.

Об'єктно-орієнтована база даних(ООБД) - база даних, у якій дані моделюються як об'єктів, їх атрибутів, методів і класів.

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

У маніфесті ООБД пропонуються обов'язкові характеристики, яким має відповідати будь-яка ООБД. Їх вибір заснований на 2 критеріях: система має бути об'єктно-орієнтованою і являти собою базу даних.

Обов'язкові характеристики

1. Підтримка складних об'єктів. У системі має бути передбачено можливість створення складових об'єктів за рахунок застосування конструкторів складових об'єктів. Необхідно, щоб конструктори об'єктів були ортогональними, тобто будь-який конструктор можна було застосовувати до будь-якого об'єкта.

2. Підтримка особливості об'єктів. Усі об'єкти повинні мати унікальний ідентифікатор, який не залежить від їх атрибутів.

3. Підтримка інкапсуляції. Коректна інкапсуляція досягається за рахунок того, що програмісти мають право доступу тільки до специфікації інтерфейсу методів, а дані та реалізація методів приховані всередині об'єктів.

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

5. Підтримка успадкування типів та класів від їхніх предків. Підтип, або підклас, повинен успадковувати атрибути та методи від його супертипу, або суперкласу відповідно.

6. Перевантаження у поєднанні з повним зв'язуванням. Методи повинні застосовуватися до різних типів об'єктів. Реалізація методу має залежати від типу об'єктів, яких даний метод застосовується. Для забезпечення цієї функціональності зв'язування імен методів у системі не повинно виконуватися до виконання програми.

7. Обчислювальна повнота. Мова маніпулювання даними має бути мовою програмування загального призначення.

8. Набір типів даних має бути розширеним. Користувач повинен мати засоби для створення нових типів даних на основі набору визначених системних типів. Більш того, між способами використання системних та користувацьких типів даних не повинно бути жодних відмінностей.

ГО СУБД

Об'єктно-орієнтовані бази даних– бази даних, у яких інформація представлена як об'єктів, як і об'єктно-орієнтованих мовами програмування.

Застосовувати чи не застосовувати об'єктно-орієнтовані системи управління базами даних (ООСУБД) у реальних проектах сьогодні? У яких випадках їх застосовувати, а яких немає?

Ось перевагивикористання ООСУБД:

· Відсутня проблема невідповідності моделі даних у додатку та БД (impedance mismatch). Усі дані зберігаються в БД у тому вигляді, як у моделі докладання.

· Не потрібно окремо підтримувати модель даних на стороні СУБД.

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

Стандарт ODMG

Перший маніфестформально був лише статтею, представленою на Конференцію з об'єктно-орієнтованих та дедуктивних баз данихгрупою приватних осіб. Як ви могли бачити в попередньому підрозділі, вимоги Маніфесту були скоріше емоційними, аніж явно специфікованими. У 1991 р. був утворений консорціум ODMG (тоді ця абревіатура розкривалася як Object Database Management Group, але згодом придбала ширше трактування – Object Data Management Group). Консорціум ODMG тісно пов'язаний із набагато більшим консорціумом OMG ( Object Management Group), який був утворений на два роки раніше. Основною вихідною метою ODMG було вироблення промислового стандарту об'єктно-орієнтованих баз даних (загальної моделі). За основу було прийнято базову об'єктну модель OMG COM ( Core Object Model). Протягом більш ніж десятирічного існування ODMG опублікувала три базові версії стандарту, остання з яких називається ODMG 3.0. 16

Цікаво, що хоча ODMG (на думку автора) вийшла з OMG, останніми роками деякі стандарти OMG спираються на об'єктну модель ODMG. Зокрема, модель ODMG спирається специфікація мови OCL ( Object Constraint Language), що є частиною загальної специфікації мови UML 1.4 (і UML 2.0). У цій статті ми не ставимо за мету провести детальне зіставлення підходів OMG та ODMG та надсилаємо зацікавлених читачів до Енциклопедії Когаловськогота матеріалам сайтів цих консорціумів. Ми обмежимося коротким викладом основних ідей, які у стандарті ODMG -3.

Архітектура ODMG

Пропонована ODMG архітектура показана на рис. 2.1. У цій архітектурі визначаються спосіб зберігання даних та різні види користувальницького доступу до цього “сховища даних” 17 . Єдине сховище даних доступне з мови визначення даних, мови запитів та низки мов маніпулювання даними. 18 На рис. 2.1 ODL означає Object Definition Language (мова визначення об'єктів), OQL – Object Query Language (мова об'єктних запитів)та OML – Object Manipulation Language (мова маніпулювання об'єктами).

Рис. 2.1. Архітектура ODMG

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

Основними компонентами архітектури є такі.

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

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

Мова об'єктних запитів (ODL).Мова має синтаксис, подібний до синтаксису мови SQL, але спирається на семантику об'єктної моделі ODMG . У стандарті допускається пряме використання OQL та його вбудовування в одну з мов категорії OML.

Реляційна модель даних

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

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

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

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

Введемо поняття, необхідних розуміння процесу приведення моделі до реляційної схеми.

Ставлення- абстракція описуваного об'єкта як сукупність його властивостей. Проводячи інфологічний етап проектування, ми говорили про абстракцію об'єктів і приписували деякі властивості. Тепер, проводячи концептуальне проектування, ми переходимо до наступного рівня абстракції. На даному етапі об'єктів як таких вже не існує. Ми оперуємо сукупністю властивостей, які визначають об'єкт.

Примірник відносини- Сукупність значень властивостей конкретного об'єкта.

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

Простий атрибут- атрибут, значення якого є неподільними.

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

Поняття сутності.

Домен

Поняття домену більш специфічне для баз даних, хоча має деякі аналогії з підтипами в деяких мовах програмування. У загальному вигляді домен визначається завданням деякого базового типу даних, якого відносяться елементи домену, і довільного логічного висловлювання, застосовуваного елемента типу даних. Якщо обчислення цього логічного висловлювання дає результат "істина", то елемент даних є елементом домену.

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

Слід зазначити також семантичну навантаження поняття домену: дані вважаються порівнянними лише тому випадку, що вони ставляться одного домену. У нашому прикладі значення доменів "Номери перепусток" та "Номери груп" відносяться до типу цілих чисел, але не є порівнянними. Зауважимо, що у більшості реляційних СУБД поняття домену не використовується, хоча Oracle V.7 воно вже підтримується.

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

Автоматизоване проектування;

Автоматизоване виробництво;

Автоматизована розробка програмного забезпечення;

Офісні інформаційні системи;

Мультимедіа системи;

Геоінформаційні системи;

Видавничі системи та інші – продемонстрували обмежені можливості статичної концепції з погляду моделювання об'єктів реального світу.

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

Побудова ООМД виходить із припущення, що предметну область можна описати сукупністю об'єктів. Кожен об'єкт є унікальною сутністю, що містить атрибути, що описують стан об'єктів «реального світу», і пов'язані з ними дії. Поточний стан об'єкта описується одним або декількома атрибутами, які можуть бути складними або простими. Простий атрибут може мати примітивний тип (наприклад, ціле число, рядок тощо) і набувати літерального значення. Складовий атрибут може містити колекції та/або посилання. Посилальний атрибут є зв'язком між об'єктами.

Ключовою властивістю об'єкта є унікальність його ідентифікації. Тому у кожного об'єкта в об'єктно-орієнтованій системі має бути свій ідентифікатор.

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

Усі об'єкти є інкапсульованими, тобто уявлення чи внутрішня структура об'єкта залишаються прихованими від користувача. Натомість користувачеві відомо лише, що цей об'єкт може виконувати деякі функції. Так, для об'єкта Склад можуть застосовуватися такі методи як ПРИЙНЯТИ_ТОВАР, ВИДАТИ_TOBAP і т. д. Перевага інкапсуляції полягає в тому, що вона дозволяє змінювати внутрішнє уявлення об'єктів, не переробляючи додатків, в яких використовуються ці об'єкти. Інакше висловлюючись, інкапсуляція передбачає незалежність даних.

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

Об'єкти, які мають один і той же набір атрибутів і відповідають на ті самі повідомлення, можуть бути згруповані в клас(У літературі терміни «клас» і «тип» часто використовуються як синоніми). Кожен такого класу має свій представник - об'єкт, який і є елементом даних. Об'єкти деякого класу називаються його екземплярами.

У деяких об'єктно-орієнтованих системах клас також є об'єктом і має власні атрибути та методи, які називаються атрибутами класу та методами класу.

Важливими поняттями ООП є ієрархія класів та ієрархія контейнерів.

Ієрархія класівпередбачає можливість наявності у кожного класу, званого в такому випадку суперкласом, свого підкласу. Як приклад можна навести такий ланцюжок: всі програмісти будь-якого підприємства є його співробітниками, отже, кожен програміст, який у рамках ООМД є об'єктом класу ПРОГРАМІСТИ, він також і співробітником, який, своєю чергою, є об'єктом класу СПІВРОБІТНИКИ. Таким чином, ПРОГРАМІСТИ будуть підкласом, СПІВРОБІТНИКИ – суперкласом. Але програмісти можуть також поділятися на системні та прикладні. Отже, ПРОГРАМІСТИ будуть суперкласом до підкласів СІС_ПРОГРАМ-МІСТИ та ПРИКЛ_ПРОГРАМІСТИ. Продовжуючи цей ланцюжок далі, ми отримаємо ієрархію класів, за якої кожен об'єкт підкласу успадковує екземпляри змінних та методи відповідного суперкласу.

Існує кілька видів успадкування - одиничне, множинне та вибіркове. Одиничне успадкування є випадком, коли підкласи успадковують лише у одного суперкласса. Множинне успадкування – успадкування більш ніж в одного суперкласу. Виборче успадкування дозволяє підкласу успадковувати обмежену кількість властивостей суперкласу.

Успадкування екземплярів змінних називається структурним наслідуванням, успадкування методів - поведінковим наслідуванням, а здатність використовувати один і той же метод для різних класів або, швидше, застосовувати різні методи з одним і тим самим ім'ям для різних класів називається поліморфізмом.

Об'єктно-орієнтованій архітектурі притаманний також інший тип ієрархії - ієрархія контейнерів. Він у тому, деякі об'єкти можуть концептуально утримуватися всередині інших. Так, об'єкт класу ВІДДІЛ повинен містити загальнодоступну змінну НАЧАЛЬНИК, що є посиланням на відповідний начальнику відділу об'єкт класу СПІВРОБІТНИКИ, а також повинен містити посилання на сукупність посилань на об'єкти, що відповідають працівникам, що працюють у даному відділі.

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

Користувач та об'єкт взаємодіють за допомогою повідомлень. У відповідь кожне повідомлення система виконує відповідний метод.

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

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

У ООМД може бути реалізовані як традиційні зв'язку, а й зв'язку, зумовлені успадкуванням.

Зв'язок типу один до одного (1: 1)між об'єктами А і В реалізується шляхом додавання посилального атрибуту на об'єкт В об'єкт А і (для підтримки цілісності посилання) посилального атрибута на об'єкт А в об'єкт В.

Зв'язок типу один-до-багатьом (1: М)між об'єктами А і В реалізується шляхом додавання в об'єкт А посилального атрибуту на об'єкт В і атрибута, що містить набір посилань на об'єкт А, об'єкт В (наприклад, в об'єкт А додається атрибут посилань В(ОID2, OID3...), і в екземпляри об'єкта В з OID2, OID3,... додається атрибут посилань А: OID1.

Зв'язок типу багато-багатьом (М: N)між об'єктами А і реалізується шляхом додавання в кожен об'єкт атрибута, що містить набір посилань.

В ООМД можна скористатися зв'язком виду «ціле-частина», що описує, що об'єкт одного класу містить об'єкти інших класів як своїх частин. У разі виробничої БД між класом ВИРОБ та класами ДЕТАЛЬ та ЗБІРКА існувала б зв'язок «ціле-частина». Даний зв'язок - це варіант зв'язку «багато-багатьом», що володіє спеціальною семантикою. Зв'язок «ціле-частина» реалізується, як будь-який інший зв'язок «багатьом-багатьом», за допомогою безлічі ідентифікаторів пов'язаних об'єктів. Однак вона, на відміну від звичайного зв'язку «багато-багатьом», має інше смислове значення.

Оскільки объектно-ориентированная парадигма підтримує успадкування, то ООМД можна застосовувати зв'язок типу «є» і зв'язок типу «розширює». Зв'язок «є», який ще називають ставленням узагальнення-спеціалізації, породжує ієрархію спадкування, в якій підкласи виявляються окремими випадками суперкласів. Це дозволяє не описувати повторно успадковані ознаки. При використанні зв'язку «розширює» підклас розвиває функціональність суперкласу, а не обмежується його окремим випадком.

Розглянемо, як реалізуються в ООМД такі компоненти, як обмеження цілісності та операції над даними.

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

Специфіка ООМД диктується специфікою об'єкта. Вона проявляється у необхідності угруповання об'єктів у класи. Кожен об'єкт входить у той чи інший клас залежно від завдання, причому один об'єкт може належати відразу кільком класам (наприклад, сімейству ПРОГРАМІСТИ і ВИСОКОПЛАЧУВАНІ). Інший специфікою об'єкта і те, що може «перебігати» з одного класу (підкласу) в інший. Так, СИСТЕМНИЙ ПРОГРАМІСТ може стати згодом ПРИКЛАДНИМ. Таким чином, ієрархія класів не є аналогом ієрархічної моделі, як це могло здатися раніше, але вимагає від системи здатності змінювати розташування кожного об'єкта всередині ієрархії класів, наприклад, переміщатися «вгору» або «вниз» всередині даної ієрархії. Але можливий і складніший процес - система має забезпечувати можливість об'єкта бути приєднаним (від'єднаним) до довільної вершини ієрархії у час.

Важливу роль ООМД грають обмеження цілісності зв'язків. Щоб зв'язки в об'єктно-орієнтованій МД могли працювати, ідентифікатори об'єктів з обох сторін зв'язку мають відповідати один одному. Наприклад, якщо є зв'язок між СЛУЖАЧИМИ та їхніми ДІТЬМИ, то має бути якась гарантія, що при вставці об'єкта, що описує дитину, в об'єкт, що відображає службовця, ідентифікатор останнього додається у відповідний об'єкт. Такий вид цілісності зв'язків, у чомусь аналогічний цілісності посилання в реляційній моделі даних, встановлюється за допомогою зворотних зв'язків. Щоб гарантувати цілісність зв'язків, проектувальнику надається спеціальна синтаксична конструкція, необхідна завдання місця знаходження зворотного ідентифікатора об'єкта. Обов'язок ставити обмеження цілісності зв'язків (як і цілісності посилання в реляційної БД) лежить на проектувальнику.

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

Проблемами стандартизації технології об'єктних БД займається група ODMG (Object Database Management Groop). Вона розробила об'єктну модель (версію ODMG 2.0 було прийнято у вересні 1997 р.), яка визначає стандартну модель для семантики об'єктів БД. Ця модель має велике значення, оскільки визначає вбудовану семантику, яку розуміє та може реалізувати об'єктно-орієнтована СУБД (ООСУБД). Структура бібліотек та додатків, що використовують цю семантику, має бути переносимою серед різних ООСУБД, які підтримують цю об'єктну МД. Основними компонентами архітектури ODMG є: об'єктна модель (ОМ), мова визначення об'єктів (ODL), мова об'єктних запитів (OQL), а також здатність зв'язування з мовами C++, Java та Smalltalk.

Об'єктна модель даних відповідно до стандарту ODMG 2.0 характеризується такими властивостями:

Базовими конструктивними елементами є об'єкти та літерали. Кожен об'єкт має унікальний ідентифікатор. Літерал немає власного ідентифікатора і може існувати окремо як об'єкт. Літерали завжди вбудовані в об'єкти, і не можна посилатися індивідуально;

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

Стан об'єкта визначається набором поточних значень, що реалізуються безліччю властивостей. Цими властивостями можуть бути атрибути об'єкта або зв'язку між об'єктом та одним або декількома іншими об'єктами;

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

Визначення бази даних зберігається у схемі, записаній мовою визначення об'єктів Object Definition Language (ODL). База даних зберігає об'єкти, дозволяючи їх спільно використовувати різним користувачам та програмам.

СУБД, що базуються на ООМД, називають об'єктно-орієнтованими СУБД (ООСУБД). Ці СУБД належать до СУБД третього покоління* (* Історію розвитку моделей зберігання даних часто розбивають на три етапи (покоління): перше покоління (кінець 1960 - початок 70-х років) - ієрархічна та мережева моделі; друге покоління (приблизно 1970-1980-і роки) - реляційна модель; третє покоління (1980-і роки – початок 2000-х років) – об'єктно-орієнтовані моделі..

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

Додаток складається з великої кількості взаємодіючих елементів. Кожна з них має свою поведінку, яка залежить від поведінки інших;

Система повинна обробляти великі обсяги неструктурованих або складних структур даних;

Додаток здійснюватиме передбачуваний доступ до даних, тому навігаційна природа об'єктно-орієнтованих БД не буде істотним недоліком;

Потреба у незапланованих запитах обмежена;

Структура даних, що зберігаються, має ієрархічну або подібну природу.

Зараз на ринку ПЗ присутня безліч об'єктно-орієнтованих СУБД. У табл. 10.6 представлені деякі із комерційних систем даного класу.

Таблиця 10.6

Сучасні комерційні ООСУБД,

їх фірми-виробники та галузі застосування

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

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

Велике значення для ООСУБД має можливість переміщення об'єктів з однієї бази до іншої.

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

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

Як видно із рис. 10.17 у структурі існують різні класи, орієнтовані на обробку документальної інформації - TOdbText, TOdbDocument, TODBTextDocument та ін. Кожен документ представлений окремим об'єктом. У такий спосіб забезпечується природність зберігання документів. Однією з найважливіших операцій є пошук документів на запит. Більшість класів реалізована можливість пошуку об'єктів за значенням певного ключа. Для класу TOdbText реалізовано можливість формування пошукового запиту за фразою, записаною природною мовою.

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

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

41. Особливості проектування прикладної ІС. Фази розвитку ІС. (Тема 11, с. 100-103).

11.1.3. Особливості системного проектування прикладної ІС

При побудові (виборі, адаптації) інформаційної системи можна використовувати дві основні концепції, два основних підходи (третя концепція – їх комбінація):

1. орієнтація на проблеми, які потрібно вирішувати з допомогою цієї інформаційної системи, тобто. проблемно-орієнтований підхід (або індуктивний підхід);

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

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

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

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

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

Системне проектування (розробка) та використання будь-якої прикладної (корпоративної) інформаційної системи має пройти наступний життєвий цикл інформаційної системи:

- Передпроектний аналіз (досвід створення інших аналогічних систем, прототипів, відмінності та особливості системи, що розробляється та ін), аналіз зовнішніх проявів системи;

- Внутрісистемний аналіз, внутрішній аналіз (аналіз підсистем системи);

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

– визначення критеріїв адекватності, ефективності та стійкості (надійності);

- функціональний опис підсистем системи (опис моделей, алгоритмів функціонування підсистем);

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

- "складання" та тестування системи - реалізація повноцінних функціональних підсистем та критеріїв, оцінка моделі за сформульованими критеріями;

- функціонування системи;

– визначення цілей подальшого розвитку системи та її додатків;

- Супровід системи - уточнення, модифікація, розширення можливостей системи в режимі її функціонування (з метою її еволюціонування).

Ці етапи – основні для інформаційного реінжинірингу систем.

Розробка корпоративної інформаційної системи, зазвичай, виконується для цілком певного підприємства. Особливості предметної діяльності підприємства, безумовно, впливатимуть на структуру інформаційної системи. Але водночас структури різних підприємств загалом схожі між собою. Кожна організація, незалежно від її діяльності, складається з низки підрозділів, безпосередньо здійснюють той чи інший вид діяльності підприємства. І ця ситуація справедлива практично для всіх організацій, хоч би яким видом діяльності вони займалися.

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

Функціональні зв'язки – кожен підрозділ виконує певні види робіт у рамках єдиного бізнес-процесу;

Інформаційні зв'язки - підрозділи обмінюються інформацією (документами, факсами, письмовими та усними розпорядженнями тощо);

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

Спільність структури різних підприємств дає змогу сформулювати деякі єдині принципи побудови корпоративних інформаційних систем.

У випадку процес розробки інформаційної системи може бути розглянутий з двох точок зору:

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

Інформаційна система підприємства розробляється як проект. Багато особливостей управління проектами і фази розробки проекту (фази життєвого циклу) є загальними, не залежними як від предметної області, а й від характеру проекту (неважливо, це інженерний проект чи економічний). Тому має сенс спочатку розглянути низку загальних питань управління проектами.

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

Зазвичай для складного поняття (яким, зокрема, є поняття проекту) важко дати однозначне формулювання, яке повністю охоплює всі ознаки поняття, що вводиться. Тому наведене визначення не претендує на єдиність та повноту.

Можна виділити такі основні ознаки проекту як об'єкта управління:

Мінливість - цілеспрямований переклад системи з того, що існує в деяке

бажаний стан, що описується в термінах цілей проекту;

Обмеженість кінцевої мети;

Обмеженість тривалості;

Обмеженість бюджету;

Обмеженість необхідних ресурсів;

Новизна для підприємства, для якого реалізується проект;

Комплексність - наявність великої кількості факторів, що прямо чи опосередковано впливають на прогрес та результати проекту;

Правове та організаційне забезпечення - створення специфічної організаційної структури на час реалізації проекту.

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

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

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

Кожен проект, незалежно від складності та обсягу робіт, необхідних для його виконання, проходить у своєму розвитку певні стани: від стану, коли «проекту ще немає», до стану, коли «проекту вже немає». Сукупність ступенів розвитку від виникнення ідеї до завершення проекту прийнято розділяти на фази (стадії, етапи).

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

Можна виділити такі фази розвитку інформаційної системи:

формування концепції;

Розробка технічного завдання;

Проектування;

Виготовлення;

Введення системи в експлуатацію.

Розглянемо кожну їх докладніше. Другу та частково третю фази прийнято називати фазами системного проектування, а останні дві (іноді сюди включають і фазу проектування) – фазами реалізації.

Концептуальна фаза

формування ідеї, постановку цілей;

формування ключової команди проекту;

Вивчення мотивації та вимог замовника та інших учасників;

Збір вихідних даних та аналіз існуючого стану;

Визначення основних вимог та обмежень, необхідних матеріальних, фінансових та трудових ресурсів;

Порівняльну оцінку альтернатив;

Подання пропозицій, їх експертизу та затвердження.

Розробка технічної пропозиції

Розробка основного змісту проекту, базової структури проекту;

Розробка та затвердження технічного завдання;

планування, декомпозиція базової структурної моделі проекту;

Упорядкування кошторису та бюджету проекту, визначення потреби у ресурсах;

Розробка календарних планів та укрупнених графіків робіт;

Підписання договору із замовником;

Введення в дію засобів комунікації учасників проекту та контролю за ходом робіт.

Проектування

На цій фазі визначаються підсистеми, їх взаємозв'язки, вибираються найефективніші способи виконання проекту та використання ресурсів. Характерні роботи цієї фази:

Виконання базових проектних робіт;

Розробка приватних технічних завдань;

Виконання концептуального проектування;

Складання технічних специфікацій та інструкцій;

Подання проектної розробки, експертиза та затвердження.

Розробка

На цій фазі проводяться координація та оперативний контроль робіт за проектом, здійснюється виготовлення підсистем, їхнє об'єднання та тестування. Основний зміст:

Виконання робіт із розробки програмного забезпечення;

виконання підготовки до впровадження системи;

Контроль та регулювання основних показників проекту.

Введення системи в експлуатацію

На цій фазі проводяться випробування, дослідна експлуатація системи в реальних умовах, ведуться переговори про результати виконання проекту та можливі нові контракти. Основні види робіт:

Комплексні випробування;

42. Концепція життєвого циклу ІС. (Тема 11, с. 103-105).

Вступ

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

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

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

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

Об'єктно-орієнтована модель даних ODMG відрізняється від інших моделей, перш за все, в одному принциповому аспекті. У моделі даних SQL і істинної реляційної моделі даних база даних є набір іменованих контейнерів даних одного родового типу: таблиць або відносин відповідно. В об'єктно-орієнтованій моделі даних база даних – це набір об'єктів (контейнерів даних) довільного типу.

При створенні об'єктно-орієнтованих СУБД (ООСУБД) використовуються різні методи, а саме:

вбудовування в об'єктно-орієнтовану мову засобів, призначених до роботи з БД;

розширення існуючої мови роботи з базами даних об'єктно-орієнтованими функціями;

створення об'єктно-орієнтованих бібліотек функцій до роботи з БД;

створення нової мови та нової об'єктно-орієнтованої моделі даних.

До переваг ООМД можна віднести широкі можливості моделювання предметної області, виразну мову запитів та високу продуктивність. Кожен об'єкт в ООМД має унікальний ідентифікатор (OID – object identifier). Звернення по OID відбувається значно швидше, ніж пошук у реляційної таблиці.

Серед недоліків ООМД слід зазначити відсутність загальноприйнятої моделі, брак досвіду створення та експлуатації ООБД, складність використання та недостатність засобів захисту даних.

Тепер розглянемо, як підтримка моделей даних реалізована у реальних системах управління базами даних.

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

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

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

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

Важливим аспектом є чіткий поділ схеми БД та самої БД. Як первинні концепції схемного рівня ООБД виступають типи і класи. Зазначається, що у всіх системах, що використовують лише одне поняття (або тип, або клас), це поняття неминуче перевантажено: тип передбачає наявність певної кількості значень, що визначається структурою даних цього типу; клас також передбачає наявність безлічі об'єктів, але це безліч визначається користувачем. Таким чином, типи та класи відіграють різну роль, і для суворості та недвозначності потрібна одночасна підтримка обох понять.

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

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

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

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

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

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

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

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

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

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

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

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

У наступному розділі ми серед іншого розглянемо особливості мов програмування та запитів системи O2, які, звичайно, тісно пов'язані зі специфікою моделі даних.