МОСКОВСЬКИЙ ДЕРЖАВНИЙ ІНСТИТУТ ЕЛЕКТРОНІКИ І МАТЕМАТИКИ
Кафедра Автоматизації та інтелектуалізації Процесів Управління
ПОЯСНЮВАЛЬНА ЗАПИСКА
До дипломної роботи
На тему : «Розробка прототипу системи управління
об'єктно-орієнтованої базою даних»
Студент Юдін Ілля Вікторович
Керівник дипломної роботи: Нечаєв Анатолій Михайлович
Спеціальна частина: Тітов Віктор Іванович
М О С К В А
1 9 9 9
Зміст
1. Вступ 3
1.1 Причини появи об'єктно-орієнтованих баз даних 3
1.2 Підходи у розробці ООБД 4
1.3 Короткий порівняльний аналіз постреляціонних і традиційних баз даних
5
1.4 Підстави дипломної роботи 5
1.5 Аналіз отриманого результату 7
2. Уточнення методів вирішення задачі 8
2.1 Спадкування 8
2.2 Інкапсуляція 10
2.3 Ідентифікатор об'єкта 11
2.4 Ідентифікатор поля агрегату 13
2.5 тригери. Обмеження доступу 13
2.6 Дія (knowhow) 14
2.7 Об'єкти-поведінки 14
2.8 Принципи взаємодії об'єктів 14
2.9 Транзакції і механізм узгодженого управління 17
3. Розробка структури СУ 18
3.1 Положення справ в області інтероперабельності систем 18
3.2 Менеджер пам'яті 20
3.3 Віртуальна пам'ять і канали 20
3.4 Система управління кешуванням об'єктів 21
3.5 Система управління журналізацію і відновленням 23
3.6 Принципи реалізації механізму узгодженого управління 24
4. Представлення даних в ООБД 28
4.1 Базові об'єкти системи 28
4.2 Будова об'єкта 28
4.3 Контекст транзакції 30
5. Опис операцій над об'єктами в БД 31
6. Вимоги до технічних і програмних засобів 33
7. Реалізація прототипу 34
7.1 Будівник 34
7.2 заголовкові модуль для каналів 34
7.3 Менеджер віртуальної пам'яті 35
7.4 Система управління зберіганням об'єктів 38
7.5 Система управління каналами 39
7.6 Робота з базовими об'єктами 40
7.7 Виконання дій 42
7.8 Кешування об'єктів 42
8. Контрольний приклад, який демонструє можливості технології 44
9. Оцінка трудомісткості розробки ПЗ з використанням традиційного тапропонованого підходів 45
9.1 Табличні бази даних з низькорівневими операціями доступу 45
9.2 Реляційні бази даних 45
9.3 Об'єктно-орієнтовані бази даних 46
9.4 Майбутнє застосування різних баз даних 46
10. Література 47
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. Точніше, це був модуль,що надає функції об'єктно-орієнтованої СУБД. Документ навіть немав назви. У ньому детально розглядалася організація зберігання даних іпринцип роботи. Схоже, розробка обгрунтовувалася лише на принципах,яким повинна задовольняти СУООБД. Найбільш цікава ідея: призначеннярядках унікальних ідентифікаторів і видалення рядків тільки при пакуваннібази. Це дає суттєвий виграш у порівнянні рядків, так як об'єкти -рядки з однаковим змістом мають однакові ідентифікатори.
4 Короткий порівняльний аналіз постреляціонних і традиційних баз даних
Постреляціонние бази даних увібрали в себе всі кращі рисиієрархічних, мережних і реляційних баз даних.
Хоча існують деякі схожості, як, наприклад, використанняпокажчиків і вкладена структура записів в мережевій моделі. Однак требавідзначити, що СУООБД використовують логічні покажчики для забезпеченняцілісності, а також підтримують ієрархію класів, спадкування і методи.
Таких коштів немає в ієрархічних та мережевих моделях [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) повинні бути припустимі довільні розміри кластерів < p> 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 викликаються по закінченнідії транзакції при виконанні операції видалення транзакційнихзалежностей.
Всі тригери множин і послідовностей можна розбити на двакласифікації: це тригери, що стежать за цілісністю безлічі
(послідовності), зберігаючи відношення порядку на послідовності,огранич
