1. Введення

1.1 Причини появи
об'єктно-орієнтованих баз даних

Розвиток обчислювальної техніки і збільшення обсягів збереженої інформації привело до необхідності виділення технології баз даних в окрему науку. Як правило, бази даних схованки, багато однотипних даних, надаючи користувачеві сервіс доступу до потрібної йому інформації. На зміну ієрархічним і мережевих баз даних прийшли реляційні бази даних. Успіх реляційних баз даних обумовлений їх більш простою архітектурою, наявністю ненавігаціонного мови запитів і, головне, ясністю математики реляційної алгебри.
На етапі зародження технології баз даних при побудові будь-якої бази даних будувалася фізична модель. З накопиченням досвіду стало зрозуміло, що потрібен перехід до даталогіческой моделі, яка дозволяє абстрагуватися від конкретної СУБД. З'явилося поняття схеми бази даних, яка описує організацію даних в СУБД. Програми стали працювати з базою даних не безпосередньо, а через схему БД. Такий підхід забезпечив можливість змінювати структуру БД без необхідності змінювати логіку програм. Поява і стандартизація SQL надала єдиний інтерфейс для роботи з даними. Ієрархічна і мережна моделі баз даних стали застосовуватися вкрай рідко. Це було викликано, насамперед, труднощами модифікації схем ієрархічних і мережевих баз даних і сильно залежить від додатків навігацією в цих базах даних.


 

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

Рис 1: Етапи проектування БД

Оскільки фізична модель вимагала залучення експерта в галузі конкретної СУБД для отримання ефективного розміщення даних, фізична модель стала будуватися самої СУБД зі схеми БД, що вводиться користувачем на основі даталогіческой моделі предметної області. Потім з'явилися CASE-засоби, що дозволяють створювати інфологіческую модель предметної області і транслюють її в даталогіческую модель.
Здавалося б, що мета досягнута, - проектувальник працює тільки з інфологіческой моделлю, але насправді, до тих пір, поки робота відбувається з реляційної бази даних, існує розрив між мовою програмування (логікою користувача) та мовою опису даних (поданням даних), який повинен долати програміст. Суть розриву можна сформулювати так: можливості роботи з даними програми та з даними СУБД повинні бути однакові.
Наприкінці 80-х - початку 90-х років масове впровадження персональних комп'ютерів призвело до розвитку мультимедіа-технологій і настільних САПР, структури даних у яких занадто складні для процедурного програмування або ж незвичайні (наприклад, звук). Це, а також те, що об'єктно-орієнтоване програмування дозволяє істотно знизити складність розробки та забезпечити адекватне поданням моделювання предметної області, призвело до того, що в області мов програмування відбулося злиття стилів мов високого рівня. Домінуючим підходом стало запровадження в них технологій об'єктно-орієнтованого програмування. Не залишилися осторонь і мови, вбудовані в СУБД. Як приклад вищевикладеного можна навести продукт Visual FoxPro фірми Microsoft. Ця СУБД має об'єктно-орієнтованою мовою програмування, але, по суті, є реляційної СУБД, оскільки зберігаються дані представлені у вигляді таблиць, а таблиці є безліччю кортежів, які містять атомарні значення. Така невідповідність і призвело до буму в галузі розробки постреляціонних баз даних.
Ситуація, що склалася хоча чимось і нагадує час переходу до реляційних баз даних, але багато в чому і відрізняється. Перш за все, відсутній математична модель, яка була б однозначно визнана всіма провідними розробниками постреляціонних СУБД. Немає документа, який однозначно визначив би вимоги до таких СУБД. І, нарешті, немає самої системи, яка вважалася б еталоном для інших систем, як це було з СУБД System-R фірми IBM.
Одним з основних критеріїв вибору СУБД завжди була продуктивність. Однак, незважаючи на те, що об'єктно-орієнтовані бази даних існують вже близько 10 років, стандартних тестів на продуктивність поки немає. Тому є кілька причин: відсутність стандартної мови запитів, канонічних додатків, різниця в архітектурі і т.д.
Що ж є? Є численний досвід розробок, наприклад Jasmine, POSTGRES, та інших. Три документи, що містять побажання щодо можливостей постреляціонних СУБД: [3], [12] та [14].

1.2 Підходи у розробці ООБД

За час існування баз даних накопичено величезну кількість інформації. Розроблено величезна кількість програм для роботи з базами даних. Це призвело до появи двох конкуруючих концепцій архітектур постреляціонних СУБД:
1. Об'єктно-реляційні бази даних
2. Об'єктно-орієнтовані бази даних

Об'єктно-реляційні бази даних являють собою реляційні бази даних, доповнені надбудовою, що представляє ці дані як об'єкти. Все як і раніше, зберігається у вигляді таблиць. Цей підхід дозволяє плавно перейти від технології сховища таблиць до технології сховища об'єктів. Залишається можливість вибірки даних за допомогою SQL-запитів. Сам SQL розширено командами роботи з об'єктами. Найбільш відомим продуктом, в якому реалізований подібний підхід є Oracle ver.8. Комітет ANSI X3H2, що розробив стандарт SQL-92, зараз працює над SQL3. Основними удосконаленнями в SQL3 повинні стати можливість процедурного доступу нарівні з декларативним і підтримка об'єктів. Основним недоліком об'єктно-реляційних СУБД є необхідність розбирати об'єкти для розміщення їх у таблицях і збирати їх для передачі користувачу з таблиць [2].
Об'єктно-орієнтовані бази даних зберігають об'єкти цілком. Для вибірки об'єктів за допомогою запитів розробляється мова OQL (Object Query Language), в який було включено стандарт SQL'92. Єдність опису структури БД досягається застосуванням мови визначення об'єктів ODL (Object Definition Language), запропонованого ODMG (Object Database Management Group), що є розширенням мови IDL. Ці види баз даних володіють високою продуктивністю, часто в кілька разів вищою, ніж реляційні бази даних. Найбільш відомими ООСУБД є Jasmine, ObjectStore і POET.
З вітчизняних розробок в області постреляціонних баз даних достовірно відомо лише про існування ООСУБД ODB-Jupiter. Схоже, вона була написана спеціально для створення продукту ODB-Text. Принаймні, ні про які інші додатках написаних на ODB-Jupiter нічого не відомо. Також в Internet було виявлено опис якоїсь вітчизняної об'єктно-орієнтованої бази даних версії 1.2. Точніше, це був модуль, що надає функції об'єктно-орієнтованої СУБД. Документ навіть не мав назви. У ньому детально розглядалася організація зберігання даних і принцип роботи. Схоже, розробка обгрунтовувалася лише на принципах, яким повинна задовольняти СУООБД. Найбільш цікава ідея: призначення рядках унікальних ідентифікаторів і видалення рядків тільки при упаковці бази. Це дає суттєвий виграш у порівнянні рядків, так як об'єкти-рядки з однаковим змістом мають однакові ідентифікатори.

1.3 Короткий порівняльний аналіз постреляціонних і традиційних баз даних

Постреляціонние бази даних увібрали в себе всі кращі риси ієрархічних, мережних і реляційних баз даних.
Хоча існують деякі схожості, як, наприклад, використання покажчиків і вкладена структура записів в мережевій моделі. Однак треба зазначити, що СУООБД використовують логічні покажчики для забезпечення цілісності, а також підтримують ієрархію класів, спадкування і методи. Таких коштів немає в ієрархічних та мережевих моделях [4].
Реляційні СУБД, ідеально відповідні своєму призначенню в традиційних областях застосування баз даних, - банківська справа, системи резервування і т.д. - У даному випадку виявляються незручними і неефективними з багатьох причин. Основна вимога реляційної моделі - нормалізація - у разі складноструктороване даних з численними взаємозв'язками призводить до складних запитах з з'єднанням таблиць. Тобто до того, до чого реляційні СУБД не пристосовані, оскільки не можуть забезпечити високу продуктивність, необхідну інтерактивним системам.
Продуктивність реляційних СУБД в таких випадках може поступатися СУООБД у багато разів. Крім того, додатки розвиваються, і число таблиць збільшується. Невелика зміна в організації даних може привести до необхідності змінити початкові тексти програми. При цьому вносяться додаткові помилки. Об'єктно-орієнтовані мови БД дозволяють досягти того ж результату локальними змінами у властивостях і методах цікавлять об'єктів. Крім того, методи роботи з об'єктами зберігаються в базі разом з об'єктами.

1.4 Підстави дипломної роботи

Відносно обраних математичних моделей

Значна частина цієї дипломної роботи грунтується на двох математичних моделях.


Модель єдиного уявлення даних поводжень
та повідомлень в об'єктно-орієнтованої бази даних

Модель [17] чудова тим, що не тільки описує що являють собою об'єкти і як вони взаємодіють між собою, але і є замкнутою, самодостатньою. Вона дозволяє описати якісно новий вид взаємодії в об'єктно-орієнтованої системі: алгебру об'єктів. Ця алгебра є по своїй суті і важливості аналогом реляційної алгебри в теорії реляційних баз даних. У цій алгебрі об'єктів визначається що являють собою такі операції, як селекція, проекція і інші добре відомі з теорії реляційних баз даних операції. Таким чином, ця модель поєднує два способи отримання інформації: посилка повідомлення об'єкту (що типово для об'єктно-орієнтованого програмування) і виконання запиту над сукупністю збережених даних (що типово для реляційних баз даних).

Модель узгодженого управління в об'єктно-орієнтованої бази даних

Ця модель [19] також зробила значний вплив на цю роботу, оскільки доповнила собою модель представлення даних. Жодна сучасна система управління базою даних не може обійтися без підсистеми транзакцій. Природа транзакцій у таких програмах, як CAD, мультимедійні бази даних, є досить різною. Ці програми характеризуються спільно виконуваними тривалими транзакціями з довільними операціями. У тривалих користувацьких транзакцій час виконання може бути розтягнуто на годинник, а то і дні. Ця умова приводить до того, що добре відомий, і що став вже класичним для традиційних баз даних, критерій серіалізуемості стає непридатний безпосередньо.
Про сам критерії серіалізуемості і способи реалізації механізму транзакцій досить докладно викладено в [9] і [22].
Механізм узгодженого управління дозволяє підвищити продуктивність СУООБД за рахунок складання розкладу виконання транзакцій, у тому числі тривалих, надає транзакцій використовувати проміжні результати інших транзакцій, враховує об'єктну орієнтованість даних і допускає узагальнення операцій (не тільки читання і запис).

Інші роботи, також вплинули на організацію структури системи управління

У статті [20] викладається досить цікава точка зору на стан об'єктно-орієнтованого програмування, а також розповідається про застосування дещо відмінного від традицій об'єктно-орієнтованого програмування підходу. Зокрема, успадкування реалізується за допомогою механізмів включення і делегування. Це дозволяє вирішити проблему множинного спадкоємства. Вводиться поняття фільтрів, що представляють собою продукції, які можуть обробляти вхідні повідомлення і навіть перенаправляти їх на інші об'єкти, зберігаючи в тілі цих повідомлень посилання на початковий об'єкт, до якого було надіслано повідомлення. Причому, фільтри можуть реагувати не тільки на вхідні, а й на вихідні від об'єкта повідомлення.
Принципи журналізацію запозичені із системи POSTGRES [23] та [15].
Принципи кешування взяті з [1].

Щодо мови реалізації

Було вирішено реалізовувати прототип СУООБД на ДССП. ДССП - діалогова система структурного програмування - була розроблена в 1980 році М. П. Брусенцова в МГУ [5]. Система має під собою теоретичне обгрунтування. Принцип ДССП «Слово є слово», тобто одне слово програми відповідає одному слову коду. Принципи керуючих конструкцій успадковуються від трійчастий обчислювальної машини Сетунь-70, що мала пам'ять на магнітних сердечниках. Словник і позначення - від мови Ч. Мура Forth. ДССП перевершує Forth за багатьма параметрами. Мова ДССП має істотно нижчою, ніж мова асемблера трудомісткістю в програмуванні, не поступаючись йому в компактності коду та швидкодії, дозволяє перевіряти роботу підпрограм в інтерактивному режимі і має можливість модифікації програм практично без внесення змін в інші частини коду.

Основні риси ДССП:
* Двухстековая архітектура
* Зворотний польський запис
* Словники
* Підтримка спадного програмування
* Вбудований відладчик з рекомпіляціей
* Високорівневі структури даних і операції
* Високорівневі механізм програмних переривань і виняткових ситуацій
* Компактний код
* Гнучкість, мобільність, нарощуваність
* Наявність сопрограммного механізму

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

1.5 Аналіз отриманого результату

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

У вигляді програмного коду реалізовано:
* Створення, відкриття ООБД
* Менеджер віртуальної пам'яті
* Система управління каналами
* Система управління кешуванням об'єктів
* Створення основних об'єктів
* Клонування об'єктів
* Перевизначення поводжень і дій
* Зміна даних в об'єктах
* Журналізацію змін в об'єктах
* Виконання дій (knowhow)
2. Уточнення методів рішення задачі

2.1 Спадкування

Спадкування є потужним засобом моделювання (оскільки коротко і точно описує світ) і допомагає програмісту розробляти нові версії класів і методів, не побоюючись зашкодити працюючу систему. Спадкування сприяє повторному використанню коду, тому що кожна програма перебуває на тому рівні, на якому її може використовувати найбільше число об'єктів.
Сукупності властивостей об'єкта в об'єктно-орієнтованої базіданих приділяється більше уваги, ніж у багатьох об'єктно-орієнтованих мовах програмування, оскільки вони є також метою запитів. Об'єкт = стан + поведінку. Частіше всього існує тільки одна ієрархія наслідування. Цей підхід перейшов і в C + +. Однак, можливо поділ ієрархій спадкування даних і наслідування поводжень. Не завжди бажано мати таку саму ієрархію наслідування поведінки, як і ієрархію наслідування властивостей. Поділ цих двох ієрархій підвищує можливості перевикористання (reuse) поводжень.

Значення перевикористання поводжень

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




Рис. 2: Діаграма успадкування
Властивості класів Студент і Аспірант успадковуються від класу Учень.
Поведінка класу Аспірант успадковується від Студент. Зазвичай підклас успадковує всі атрибути і методи з суперкласу. У додатку до спадкоємства поводжень це означає, що клас-учень (demandclass) полягає у ставленні Переіспользовать-ось (Reuse-Of) з іншим класом, званим класом-вчителем (supplyclass), і клас-учень повинен наслідувати всі поведінки від класу-вчителя .

Еталони успадкування: класи або прототипи?

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

Спосіб успадкування: делегування або конкатенація?

Делегування являє собою таку форму спадкування, в якій об'єднання інтерфейсів реалізовано за допомогою поділу батьківських інтерфейсів, тобто з використанням посилань. Конкатенація досягає аналогічного ефекту за допомогою копіювання батьківських інтерфейсів в інтерфейс породжуваного класу або об'єкта, - як результат, отриманий інтерфейс є безперервним. У будь-якому випадку дочірній об'єкт здатний відповідати як на повідомлення, що визначені в батьківських інтерфейсах, так і на повідомлення, додані до інтерфейсу об'єкта. При делегуванні ті повідомлення, які не можуть бути оброблені об'єктом, повинні бути спрямовані батькам. При конкатенації кожен об'єкт є самодостатнім, і необхідність перенаправлення повідомлень відсутній. Введення ідентифікаторів полів дозволяє поширити підходи делегування та конкатенації і на агрегатні об'єкти.
І конкатенація, і делегування мають свої переваги і недоліки. Делегування забезпечує можливість гнучкого розповсюдження змін: будь-яка зміна властивостей батька автоматично відбивається на нащадках. Підхід, який використовує конкатенацію, допускає зміну властивостей батьків і нащадків незалежно один від одного, що також може бути корисним у багатьох ситуаціях. Делегування зазвичай вимагає менших витрат по пам'яті, у той час як конкатенація є ефективнішою за часом. Simula і C + + є прикладами мов, які реалізують успадкування на основі класів з використанням делегування. У Smalltalk реалізовано успадкування на основі прототипів з використанням делегування.

Обгрунтування обраного механізму успадкування

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

Визначення спорідненості

Залишається важливе питання: як визначити, чи є об'єкт нащадком іншого об'єкта? Поділ наслідувань стану та поведінки призводить до того, що слово «нащадок об'єкта» набуває подвійне значення. З одного боку, це нащадок за даними, з іншого боку, це нащадок по поведінці.
Насправді, у чистій об'єктно-орієнтованої системи дані об'єктів надійно захищені від втручання користувача через механізм інкапсуляції. Доступ до даних здійснюється через методи. Таким чином, спорідненість об'єктів слід визначати виключно через їх інтерфейси. У системі на основі класів зазвичай будується дерево успадкування. У системі на основі прототипів з конкатенації визначення спорідненості досягається за рахунок операцій перетину інтерфейсів. Поведінка об'єкта становлять методи, що зберігаються в об'єкті-багато, а значить для визначення спорідненості необхідно виконати операцію перетину множин. Якщо вийшов у результаті перетину інтерфейс збігається з інтерфейсом одного з двох порівнюваних об'єктів, то інший об'єкт - його нащадок. Фактично, це алгоритм визначення загального предка двох об'єктів. Використання множин для зберігання інтерфейсів дозволяє поглянути на операцію успадкування конкатенації як на операцію злиття множин.

2.2 Інкапсуляція

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

2.3 Ідентифікатор об'єкта

Призначення ідентифікатора

Об'єкти в БД мають індивідуальність. Навіть при зміні структури і поведінки об'єкта, його індивідуальність зберігається. Два об'єкти в системі відрізняються своїми ідентифікаторами. Ідентифікатор є характеристикою індивідуальності. Поняття індивідуальності нове для реляційних баз даних. У чисто реляційної БД всі кортежі в межах однієї таблиці відрізняються між собою. Характеристика відмінності - первинний ключ. Багато сучасних реляційні бази даних допускають існування в межах однієї таблиці однакових кортежів. І потреба в цьому є, інакше не було б кваліфікаторов DISTINCT в оператора SQL SELECT.
Ідентифікатор об'єкта в БД дозволяє розрізнити між собою два однакових за значенням об'єкта. Фактично, він грає роль дескриптора адреси об'єкта. Таким чином, користувач працює з об'єктом не через його адресу, а через його ідентифікатор.

Будова ідентифікатора

У сучасних ООБД для прискорення доступу до об'єктів ідентифікатори наділяються складовою структурою.

Є два основні підходи для ідентифікації об'єктів:
* Складовою адреса (Structured address)
* Замінник (Surrogate)

Складовою адреса складається з фізичної частини (сегмента і номера сторінки) і логічної частини (внутрістранічний індекс), які є масками фіксованої довжини і, поєднуючись, дають ідентифікатор. Складові адреси більш популярні в сучасних ООБД як більш ефективні: за один дисковий доступ можна отримати адреса об'єкту. Використання складного адреси як ідентифікаторів призводить до залежності від організації фізичного зберігання. Це призводить до труднощів при переміщенні даних для зберігання на інший пристрій.
Замінник - чисто логічний ідентифікатор, що генерується за певним алгоритмом, що гарантує унікальність. У замінниках, індекс (також називається директорією об'єкта), часто використовується для відображення ідентифікаторів в розташування об'єктів. Ефективність операцій з базою даних багато в чому визначається швидкістю доступу до одиночного об'єкту. Часто об'єкти пов'язані між собою і доступ до одного об'єкту відбувається через доступ до іншого. Наприклад, через об'єкт-списку відбувається доступ до її елементів. У багатьох випадках створення об'єкта (наприклад, глибоким копіюванням) призводить до каскадному створення інших об'єктів, що складають його вміст. Використання кластеризації допомагає організації швидкого доступу до групи пов'язаних об'єктів. Крім того, розміщення об'єктів в одній області дискового простору також збільшує швидкодію.
В роботі [16] описаний підхід до побудови ідентифікаторів-замінників. Ідентифікатор складається з двох частин: коду кластеру і номери в послідовності. Такий підхід грунтується на наступних трьох принципах:
1) Ідентифікатор об'єкта повинен містити інформацію про кластері, який групує спільно використовувані об'єкти
2) Повинні бути припустимі довільні розміри кластерів
3) Ідентифікатори об'єктів повинні підкорятися досить одноманітного поданням, щоб вони могли виступати в якості псевдоключей динамічного хешування.

Є три ознаки, за якими СУБД можуть приймати рішення про місце розміщення об'єктів:
1) Правила, задані в схемі БД
2) Вказівка користувача
3) Статистика доступу

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

Ідентичність та еквівалентність

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

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

Визначення N-еквівалентності
Нехай 0-еквівалентність (позначається? 0) те ж саме, що перевірка ідентичності?. Тоді для будь-яких двох об'єктів o1, o2? O, o1 і o2 n-еквівалентні (позначається o1? N o2) для n> 0, якщо:

Існує атомарний об'єкт c, такий, що значення (o1) = значення (o2) та їх поведінки ідентичні;
Існує об'єкт-агрегат c, такий, що FID кожного поля з присутня в o1 і o2, а також вірно протилежне: FID кожного поля o1 (o2) присутня в c,
значення (o1) = [A1: x1, ..., Am: xm] і значення (o2) = [A1: y1, ..., Am: ym], і при цьому
xi? n-1 yi для 1? i? n; або
Існує об'єкт-умова c, такий, що значення (o1) = і значення (o2) = і xi? N-1 yi для 1? i? 3; або
Існує об'єкт-безліч c, такий, що значення (o1) = (x1, ..., xl) і значення (o2)
= (Y1, ..., ym) і l = m і для кожного xi (yj) існує один yj (xi): xi? N-1 yj для 1? i, j? l; або
Існує об'єкт-список c, такий, що значення (o1) = (x1, ..., xl) і значення (o2) = (y1, ..., ym) і l = m і xi? N-1 yi для 1? i? l.
Два об'єкти називаються еквівалентними (o1? O2) тоді і тільки тоді, коли
o1? n o2 для деякого n> 0.


2.4 Ідентифікатор поля агрегату

Введення ідентифікатора поля дозволяє подолати труднощі визначення розміщення даних полів агрегатів. Суть проблеми полягає в тому, що якщо ми успадковуємо класи B і C від класу A, а потім успадковуємо множественно клас D від класів B і C, то екземпляр класу D одночасно є екземпляром класів A, B і C. При цьому важливо, щоб "старий" клас (наприклад, A) умів працювати з об'єктами класу D. Ця проблема розглядається в роботі [10], в якій автори вводять такі обмеження цілісності структури об'єктів:

1. В БД не можуть існувати окремі власні частини підкласів
2. Кожній частині складного об'єкта повинна відповідати тільки одна власна частина.

В якості рішення вони пропонують використання посилань на класи і кожну власну частину класу зберігати окремо.
У дипломній роботі пропонується замість зберігання посилань на класи встановити для кожного поля свій ідентифікатор. При спадкуванні полі зберігає свій ідентифікатор. Таким чином, перейменування полів не порушує зв'язок успадкування. Дана дія може бути автоматичним, наприклад, через конфлікти імен полів при множині спадкування. Аналогічно надходить оператор SQL Select, коли в якості результату запиту йому потрібно повернути декілька стовпців, які мають однакові імена.
Ідентифікатори полів унікальні в межах бази даних, тобто при оголошенні нового поля в класі, Ідентіфікатор поля в подальшому з'являється тільки в класах-спадкоємців і тільки через спадкування.
Крім того, програмісти можуть використовувати для імен полів звичний для них рідна мова, іншими словами: є можливість створювати синоніми імен полів.

2.5 тригери. Обмеження доступу

У безліч поводжень будь-якого об'єкта можна включити два списки з зумовленими іменами «PRE_TRIGGERS» і «POST_TRIGGERS». Список PRE_TRIGGERS містить об'єкти, що обробляють вхідне повідомлення. Як правило, це об'єкти-умови. Такий підхід називається фільтрацією [20]. Список POST_TRIGGERS містить об'єкти, які перевіряють результат впливу і можуть зробити відкат. POST_TRIGGERS викликаються після закінчення дії транзакції при виконанні операції видалення транзакційних залежностей.
Всі тригери множин і послідовностей можна розбити на дві класифікації: це тригери, що стежать за цілісністю безлічі (послідовності), зберігаючи відношення порядку на послідовності, обмеження суми чисел елементів множини та ін; і стежать за цілісністю одного елемента, що відповідає перевірки значення на відповідність домену.
Список PRE_TRIGGERS дозволяє організувати обмеження доступу, фільтруючи повідомлення, надіслані об'єктом, ктороий не має повноважень для виконання команди, що міститься в повідомленні.
Список POST_TRIGGERS дозволяє виключити частину даних з результату виконаної об'єктом операції, створивши тим самим локальне користувальницьке подання.
Втім, тема безпеки заслуговує окремого розгляду. Як, наприклад, в [9] і [18].


2.6 Дія (knowhow)

Дія являє собою об'єкт типу "рядок", який зберігає текст ДССП-процедури. Посилання на дію може зберігається в полі OBJKH об'єкта, через який і відбувається виклик дії. Алгоритм вибору виконуваного дії розглядається нижче. У інтерфейсах об'єктів вказані ідентифікатори об'єктів, які в полі OBJKH зберігають ідентифікатор дії. Значення цих об'єктів є ім'ям дії. Найбільш зручно використовувати для цієї мети рядкові об'єкти. Використання поля OBJKH дозволяє виконувати один і той же дію для різних методів різних об'єктів.
Коли Ви робите дії з ідентифікатором OIDKH робиться виклик слова з ім'ям kh $. Наприклад, для об'єкта з OIDKH = 0x00000DFC це буде KH $ 00000DFC. Якщо виникає ситуація EXERR, значить слово в словнику відсутній і підлягає компіляції. Для компіляції текст дії доповнюється префіксом ": KH $" і суфіксом ";", після чого компілюється командою TEXEC і виконується. Словник дій називається $ KH_VOC.
У разі зміни тексту методу необхідно повністю очистити словник ДССП $ KH_VOC, який зберігає відкомпілювалися дії, оскільки ці дії містять у своєму коді абсолютні посилання на колишню скомпільованій версію дії. Втім, ця процедура очищення словника виконується лише при перевизначенні тексту дії, що буває досить рідко.

2.7 Об'єкти-поведінки

У відсутності класів, зберігати методи в кожному об'єкті було б занадто