Навіщо потрібна теоретична модель ?

М.І.Жарких, Ю.Б.Кабаков

Теоретичні моделі вживаються далеко не в усіх розділах комп’ютерної науки. Скажімо, ніхто ніколи не чув за теорію, яка лежить в основі текстових процесорів чи електронної пошти. Ніхто не журиться питанням, чи операції “вирізати / скопіювати / вставити” утворюють повний набір операцій над текстом, і тим не менше тексти пишуться, текстові процесори вдосконалюються, виходячи з чисто практичних міркувань.

Чому ж не можна обійтись без теоретичних викладок в царині баз даних (БД) ? Це пов’язано насамперед з неймовірною складністю процесів визначення та обробки структуризованих і формалізованих даних за допомогою комп’ютерів. Якщо досконалий текстовий процесор можна уподібнити автомобілю, то будь-яка база даних в порівнянні з ним – це літак. Автомобіль можна збудувати, виходячи з міркувань здорового глузду та практичних потреб, але спроба будувати літак без аеродинамічних розрахунків неодмінно буде невдалою.

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

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

Наявність реляційної теорії вважається серйозною перевагою промислово підтримуваних систем управління базами даних, які скорочено умовно називаються “реляційними”. Всі вони, в тому чи іншому ступеню, використовують мову структурних запитів (structured query language, SQL) в якості формальної мови опису даних та маніпулювання даними. Але попри популярність терміну “реляційний” в назвах і рекламних оголошеннях поширених СУБД, з правдивою реляційністю у цих продуктів є великі проблеми. Навіть якщо не звертати уваги на 333 ознаки справді реляційної СУБД, сформульовані Коддом, досить сказати, що жодна з “реляційних” СУБД не підтримує такої важливої операції реляційної алгебри, як перетин множин записів; нема такої операції і в стандарті SQL (в SQL визначено операцію об’єднання множин записів (оператор SELECT … UNION), яка підтримується в більшості продуктів).

Тому твердження, що “реляційні” програмні продукти є втіленням теоретичної моделі, є певним перебільшенням; правильніше сказати, що ці продукти розвивались під впливом реляційної теорії.

Ми хочемо запропонувати увазі читачів новий варіант теорії баз даних – об’єктну модель. Ця теоретична модель буде зручною для реалізації – хоча б тому, що реалізувати об’єктну модель у відповідності до теоретичних накреслень простіше, ніж всупереч ним.

Об’єкти

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

замкненість (incapsulation). В силу цієї властивості об’єкт захищає свої дані та методи від стороннього втручання, визначаючи правила звертання до даних та методів (interface). Наслідком замкненості є принцип актуалізму : допустимими (або примітивними) є тільки такі операції над об’єктами, які не вимагають зміни стану інших об’єктів. Операція, яка вимагає зміни стану одразу кількох об’єктів, не є примітивною. Її треба захищати об’єктною трансакцією;

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

наслідування (inheritance). Дана властивість встановлює ієрархічні відносини між класами об’єктів, в силу якої клас-нащадок успадковує всю поведінку класу-предка, додаючи до неї в міру потреби щось нове;

поліморфізм (polymorphism). Дана властивість означає, що ми можемо розглядати об’єкти підкласів як об’єкти суперкласу без будь-яких обмежень;

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

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

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

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

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

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

вирази (expressions). Псевдоатрибути, значення яких вираховується за значеннями атрибутів та інших виразів. Вони відрізняються від атрибутів тим, що їх значення не зберігаються в базі даних;

індекси (indices). Атрибути або вирази, з яких формуються структури швидкого доступу до об’єктів в базі даних. За допомогою індексу ми можемо дізнатись про значення даного атрибуту, не відкриваючи сам об’єкт;

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

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

методи (methods). Процедури обробки даних, які визначають динамічну поведінку об’єктів. Методи визначені в класі об’єктів і є однаковими для всіх екземплярів класу;

події (events). Ситуації, що виникають під час виконання тих чи інших методів об’єктів;

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

Про три останні групи властивостей ми в даному повідомленні говорити практично не будемо; ми зосередимо увагу на об’єктах бази даних як на статичних структурах даних.

Постійні об’єкти

В основу об’єктної бази даних покладено постійний об’єкт (persistent object, ПерсОб’єкт). Це абстрактний системний клас, який є кореневим (ultimate ancestor) для всіх інших об’єктів.

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

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

Цей клас визначає три властивості :

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

логічне ім’я – віртуальний вираз рядкового типу, який допомагає людині розпізнати об’єкт [Додаткові міркування про ід та логічне ім’я : Жарких М.І., Кабаков Ю.Б. Універсальна об’єктна база даних “Археометрика” // АРОІКС. – Вип. 2. – 1998. – С. 44]; віртуальність означає, що класи-нащадки можуть визначати власні вирази для логічного імені, можливо, з урахуванням значення успадкованого виразу;

користувачі є виразом з типом даних “множина об’єктів” (див. далі); ця множина містить усі об’єкти, які посилаються на даний об’єкт (тобто використовують даний об’єкт).

В цьому класі повинна бути реалізована основна поведінка об’єктів бази даних, тобто методи :

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

ретипізація. Як виняток з попереднього правила можна допустити тільки перетворення екземпляра суперкласу на екземпляр одного з його підкласів. При цьому новоутворений екземпляр підкласу має визначеними тільки ті атрибути, які він успадкував від суперкласу. Такий екземпляр може виявитись “нежиттєздатним” через порушення правил підкласу;

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

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

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

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

З кожним із цих методів може бути зв’язана пара подій (ПередВиконаннямМетоду / ПісляВиконанняМетоду); додаткові події можуть бути зв’язані, скажімо, з обчисленням значень виразів або з виявленням порушення правил класу.