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

Основні поняття

визначення 1

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

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

визначення 2

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

Стандартний тип (наприклад, строковий - string) Або тип, створений користувачем ( class), Описує властивості об'єктів.

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

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

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

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

визначення 3

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

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

визначення 4

спадкування, Назад інкапсуляції, відповідає за поширення області видимості властивості щодо всіх нащадків об'єкта.

Наприклад, всім об'єктам КНИГА, які є нащадками об'єкта КАТАЛОГ, можуть бути приписані властивості об'єкта-батька: автор, назва, уДК і isbn.

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

Таким чином, властивості номер і квиток в об'єкті БІБЛІОТЕКА успадковуються всіма дочірніми об'єктами ВИДАЧА, КНИГА і АБОНЕНТ. Саме тому значення цієї властивості класів АБОНЕНТ і ВИДАЧА однакові - 00015 (рисунок 1).

визначення 5

поліморфізм дозволяє одному і тому ж програмного коду працювати з різнотипними даними.

Інакше кажучи, він допускає в об'єктах різних типів мати методи (функції або процедури) з однаковими іменами.

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

Переваги і недоліки об'єктно-орієнтованої моделі

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

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

На сьогоднішній день такі системи досить широко поширені. До них відносяться СУБД:

• Postgres,
• Orion,
• Iris,
• ODBJupiter,
• Versant,
• Objectivity / DB,
• ObjectStore,
• Statice,
• GemStone
• G-Base.

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

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

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

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

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

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

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

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

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

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

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

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

ГО СУБД

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

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

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

· Відсутня проблема невідповідності моделі даних в додатку і БД (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) \u200b\u200b- це внутрішній для бази даних спосіб позначки індивідуальних об'єктів. Користувачі, що працюють з діалогової програмою завдань запитів або перегляду інформації, як правило, не бачать цих ідентифікаторів. Вони призначаються і використовуються самої СУБД. Семантика ідентифікатора в кожній СУБД своя. Вона може бути як випадковим значенням, так і містити інформацію, необхідну для пошуку об'єкта в файлі бази даних, наприклад, номер сторінки в файлі і зміщення об'єкта від її початку. Саме ідентифікатор повинен використовуватися для організації посилань на об'єкт.

Всі об'єкти є інкапсульованими, т. Е. Уявлення або внутрішня структура об'єкта залишаються прихованими від користувача. Замість цього користувачеві відомо тільки, що даний об'єкт може виконувати деякі функції. Так, для об'єкта СКЛАД можуть застосовуватися такі методи як ПРІНЯТЬ_ТОВАР, ВИДАТЬ_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).

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

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

Стандартизована об'єктно-орієнтована модель описана в рекомендаціях стандарту ODMG-93 (Object Database Management Group - група управління об'єктно-орієнтованими базами даних).

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

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

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

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

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

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

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

Мал. 2.9 Логічна структура БД бібліотечної справи

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

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

До об'єктно-орієнтованим СУБД відносяться POET, Jasmine, Versant, O2, ODB-Jupiter, Iris, Orion, Postgres.

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

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

За формою власності БНД діляться на державні і недержавні. За ступенем доступності розрізняють загальнодоступні і з обмеженим колом користувачів.

Інші види класифікації пов'язані з окремими компонентами БНД.

1. Розробка банків даних складається з 4-х етапів:

1 етап. Формування та аналіз вимог до системи:

Складається специфікація системи, що включає список завдань, які повинен вирішувати БНД;

Перелік кінцевих користувачів і їхніх функцій;

Перелік вимог до БД;

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

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

3 етап. Проектування реалізації: вибирається обчислювальна система, системні програмні засоби і СУБД; проектується структура даних і будується даталогіческая модель БД (схема БД), яка представляє собою опис логічної структури БД на мові конкретної обраної СУБД.

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

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

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

Перелічимо основні функції та завдання, які вирішуються персоналом при розробці та експлуатації бази даних:

1) аналіз предметної області (визначення потреб кінцевих користувачів, побудова інформаційної моделі предметної області, виявлення обмежень цілісності);

2) проектування структури бази даних (визначення складу і структури файлів БД, опис її схеми на мові опису даних);

3) завдання обмежень цілісності БД;

4) завантаження і ведення БД (до ведення БД відноситься зміна, видалення і додавання записів); розробка технології завантаження і ведення; розробка форм введення даних; введення і контроль даних;

5) захист даних (розмежування користувачів, вибір і перевірка засобів захисту, фіксація спроб несанкціонованого доступу);

6) забезпечення відновлення БД;

7) аналіз ефективності БНД і розвиток системи;

8) робота з користувачами (збір відгуків, навчання);

9) супровід системного програмного забезпечення (придбання, установка і розвиток);

10) організаційно-методична робота (вибір методів проектування і модернізації, планування розвитку БНД, розробка документації).

3. Учасники банків даних

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

проектування,

Реалізація,

підтримка,

Оновлення та розробка,

Повна реорганізація.

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

кінцеві користувачі

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

Адміністратори банку даних

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

Розробники та адміністратори додатків

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

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

Розглянемо їх більш детально.

Частина групи адміністратора БНД повинна бути:

Системні коментатори;

Розробники структур даних і зовнішнього вигляду щодо банку даних інформаційної підтримки;

Розробники технологічних процесів обробки даних;

Системні та прикладні програмісти;

Діючі компанії і експерти в ремонтній службі.

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

Основні функції групи адміністраторів БД

1. Дослідження області даних: опис області даних, укладання тексту обмежень цілісності, визначення стану (доступність, конфіденційність) інформація, визначення потреб споживачів, визначення відповідності "споживачі даних", визначення скроневих обсягом характеристик обробки даних.

2. Розробка будови БД: визначення твори і будова файлів БД і зв'язку проміжний, вибір методів оптимізації даних і методів доступу для інформації, опису БД на мові опису даних (МОД).

3. Завдання обмежень цілісності в описі структури БД і процедурах обробки БД:

Завдання декларативних обмежень цілісності, властивої від області даних;

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

Визначення обмежень цілісності викликається будовою БД;

Розробка процедур підтримки цілісності БД при введенні і коригування даних;

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

4. Ініціювання завантаження і керівництво БД

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

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

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

5. Запобігання даних

Визначення системи паролів, принципів пристрілки споживачів, створення груп споживачів, що володіють ідентичними правами доступу до даних;

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

Розробка засобів фіксації доступу до даних і спробам порушення системи захисту;

Тестування системи захисту;

Дослідження випадків порушення системи захисту і розробки динамічних методів запобігання інформації в БД.

6. Підтримка відновлення БД

Розробка організаційних означає архівування та принципи відновлення БД;

Розробка додаткового матобеспеченія і технологічні процеси відновлення БД після відмов.

7. Дослідження викликів споживачів БД: набір статистики на символі запитів, часу включення їх продуктивності, відповідно до необхідних вихідними документами

8. Дослідження ефективності функціонування БнД:

Дослідження індексів функціонування БнД

Плануюча перебудова структури (структурна зміна) БД і реорганізація БНД.

9. Робота з кінцевими користувачами:

Збір інформації про зміну області даних;

Збір інформації про оцінку робіт БНД;

Тренування споживачів, консультація споживачів;

Розробка необхідної систематичної і освітньої документації щодо роботи кінцевих користувачів.

10. Приготування та підтримка системних засобів:

Дослідження матобеспеченія, існуючого на ринку і дослідженні можливості та необхідності їх використання в рамках БНД;

Розробка необхідних організаційних і технічних програмою рухів для розробки БНД;

Перевірка працездатності викупленого матобеспеченія перед їх з'єднанням з БнД;

Контроль з'єднання нового матобеспеченія до БнД.

11. Організаційно-систематична робота при розробці БНД:

Вибір або створення методу розробки БД;

Визначення цілей і напрямок розробки системи в цілому;

Планування стадій розвитку БНД;

Розробка довідників генеральних словників проекту БНД і концептуальної моделі;

Монтаж зовнішніх моделей розроблених додатків;

Контроль з'єднання нового додатка до роботи БНД;

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

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

стандартна ООМ описана в рекомендаціях стандарту 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.