Обектно-ориентиран модел на данни

Обектно-ориентираният модел на данни е продължение на разпоредбите на обектно-ориентираното програмиране (докато релационният модел възниква на базата на теорията на множеството, именно като модел на данни). Стандартът ODMG-93 (Object DataBase Management Group) е разработен от групата за управление на обектно-ориентирана база данни. Този стандарт все още не е напълно внедрен.

Структурата на обектно-ориентирана база данни е графично представена под формата на дърво, чиито възли са обекти. Видимата структура на обекта се определя от свойствата на неговия клас. класвключва обекти, докато структурата и поведението на обектите от един и същи клас са еднакви. Всеки обект, а именно екземпляр на клас, се счита за потомък на обекта, в който е дефиниран като свойство. Свойства на обекта- или стандартен тип, като низ, или конструиран от потребителя тип клас. Поведението на обектите се задава с помощта на методи. МетодТова е операция, която може да се приложи към обект.

Като пример, разгледайте базата данни "LIBRARY" (фиг.4.4). За всеки обект са определени свойства, техните типове и стойности. В БД:

"БИБЛИОТЕКА" - родител (предшественик) за "АБОНАМЕНТ", "КАТАЛОГ", "БРОЙ";

"КАТАЛОГ" е родител за "КНИГА".

„КНИГА” – различните обекти могат да имат едни и същи или различни родители. Ако един и същ родител (един автор), тогава инвентарните номера са различни, но isbn, UDC, заглавието и авторът са едни и същи.

Логическата структура на обектно-ориентирана база данни е подобна на йерархичната, основната разлика е в методите за манипулиране на данни. Действия като логически операции, подобрени от обектно-ориентирани методи за капсулиране, наследяване и полиморфизъм, могат да се извършват в базата данни.

Капсулиранеограничава обхвата на името на свойството до границите на обекта, в който е дефинирано. Така че, ако имотът е добавен към "КАТАЛОГ" телефонавтора на книгата, получена след това по същия начин в "АБОНАМЕНТ" и "КАТАЛОГ". Значението на свойството ще се определя от обекта, в който е капсулиран.

Наследствообратно, разширява обхвата на свойството до всички наследници на обекта. По този начин на всички обекти от типа "BOOK", които са наследници на "CATALOG", могат да бъдат присвоени свойствата на родителския isbn, UDC, име и автор.

Полиформизъмозначава способността на един и същ програмен код да работи с различни типове данни. С други думи, това означава, че е допустимо в обекти от различен тип да има методи - процедури и функции - с еднакви имена. По време на изпълнението на обектна програма едни и същи методи работят с различни обекти в зависимост от типа на аргумента. За базата данни "LIBRARY" това означава, че обекти от клас "BOOK", имащи различни родители от клас "CATALOG", могат да имат различен набор от свойства, т.е. програмите за работа с обект от клас "BOOK" могат да съдържат полиморфен код. В клас методът няма тяло, тоест не е дефинирано какви конкретни действия трябва да изпълнява. Всеки подклас изпълнява необходимите операции. Капсулирането скрива подробности за внедряването от всички обекти извън дадената йерархия.

Предимствата на обектно-ориентирания модел в сравнение с релационния модел са възможността за показване на информация за сложни връзки на обекти, липсата на ограничения в структурите за съхранение на данни. Обектно-ориентирана база данни може да съхранява не само структурата, но и поведенческите аспекти на данните. С помощта на обектно-ориентирания подход могат да се създават и бази данни с големи количества семантична информация, като мултимедия и специализирана за конкретни предметни области (географски, дизайнерски и др.).

Недостатъците на този подход включват висока концептуална сложност, неудобство при обработката на данни и ниска скорост на изпълнение на заявката.

През 90-те години бяха създадени прототипи на опериращи обектно-ориентирани бази данни. Това са POET (ПОЕТ SoftWare), JASMINE (COMPUTER ASSOCIATES), IRIS, ORION, POSTGRES.

Тема 5

Релационен подход при изграждане на информационно-логически модел: основни понятия

Модел на релационни данни. Основни понятия

Както беше отбелязано в раздела на предишната лекция, релационният модел в момента е един от най-разпространените модели на пазара на бази данни. Този модел се основава на набор от взаимосвързани таблици (релации).

Основните теоретични идеи на релационния модел са представени в трудовете по теория на отношенията от американския логик Чарлз Содерс Пърс (1839-1914) и немския логик Ернст Шрьодер (1841-1902), както и от американския математик Едгар Код .

В работите на Пърс и Шрьодер е доказано, че множеството отношения е затворено по отношение на някои специални операции, които заедно образуват абстрактна алгебра. Това най-важно свойство на връзките беше използвано в релационния модел за разработване на език за манипулиране на данни.

През 1970 г. се появява статия на Е. Код за представянето на данни, организирани в двуизмерни таблици, наречени отношения. Код е първият, който въвежда основните понятия и ограничения на релационния модел като основа за съхранение на данни и показва възможността за обработка на данни с помощта на традиционни операции върху множества и специално въведени релационни операции.

Основните понятия на релационния модел са дадени в табл. 3.1.

Обектите на релационния модел са предимно таблици (релации). Цялостността на данните се осигурява от външни и първични ключове (вижте стр. „Цялост на релационни данни“).

Операторите в релационния модел са набор от инструкции, които извличат и манипулират данни.

Таблица 5.1. Елементи на релационни модели

Термин на релационен модел	Описание
база данни (DB)	Набор от таблици и други обекти, необходими за абстрактно представяне на избраната предметна област
DB схема	Набор от заглавки на таблицата, които са свързани помежду си
Поведение	Таблица - набор от обекти от реалния свят, които се характеризират с общи свойства и характеристики (полета на таблицата)
Заглавие на връзката	Заглавка на таблицата - имената на полетата (колоните) на таблицата
Тяло на връзката	Тяло на таблицата - колекция от стойности за всички обекти в реалния свят, които могат да бъдат представени като записи на таблица (редове на таблица)
Диаграма на връзката	Ред от заглавия на колони в таблицата (заглавка на таблицата)
Атрибут на връзката	Име на колона в таблицата (поле на таблица)
Кортеж за връзки	Ред на таблица (запис) - Недвусмислено представяне на обект от реалния свят, създаден с помощта на стойностите на полетата на таблицата
домейн	Много валидни стойности на атрибути
Стойност на атрибута	Стойност на полето в запис (кортежа)
Първичен ключ	Един или повече (в случай на съставен ключ) атрибути, които уникално дефинират стойността на кортежа (стойността на реда на таблицата)
Външен ключ	Атрибут на таблица, чиито стойности съответстват на стойностите на първичния ключ в друга свързана (родителска, първична) таблица. Външният ключ може да се състои от един или няколко атрибута (съставен външен ключ). Ако броят на атрибутите на външния ключ е по-малък от броя на атрибутите на съответния първичен ключ, тогава той се нарича съкратен (частичен) външен ключ
Степента (арност) на връзката	Брой колони на таблицата
Силата на връзката	Брой редове (кортежи) на таблицата
Пример за връзка	Наборът от записи (кортежи) за дадена таблица (връзка). Инстанцията може да се промени с течение на времето. Тъй като обикновената база данни в момента работи само с една версия на връзката, такъв екземпляр на връзката се нарича текуща.
Тип данни	Тип стойност на елементите на таблицата
Основна връзка	Връзка, съдържаща една или повече колони, характеризиращи свойствата на обекта, както и първичен ключ
Произведено съотношение	Не е основна връзка, т.е. не характеризира свойствата на обекта и се използва за осигуряване на връзки между други таблици, може да не съдържа първичен ключ. Ако е посочен първичен ключ, той се състои от външни ключове, свързани с първичните ключове на основната връзка
Връзка	Установява връзка между съвпадащи стойности в ключови полета - първичен ключ на една таблица и външния ключ на друга
Връзка едно към едно (1:1)	Когато се използва този тип връзка, запис в една таблица може да има най-много един свързан запис в друга таблица. И в двете таблици ключовите полета трябва да са първични. Използва се за разделяне на таблици с множество полета или за изисквания за защита на данните
Връзка един към много (1: M)	Когато се използва този тип връзка, всеки запис от една таблица може да съответства на няколко записа от втората, но всеки запис от втората таблица съответства само на един запис от първата таблица. Първичният ключ трябва да бъде посочен в първата таблица, а външният ключ във втората.
Връзка много към много (N: M)	При този тип връзка един запис в първата таблица може да съответства на няколко записа от втората таблица, но един запис от втората таблица може да съответства на няколко записа от първата. Уникалността на ключовете за такива таблици не се изисква. В процеса на проектиране на схема на база данни такива връзки се трансформират. За да направите това, трябва да въведете спомагателна връзка, която ви позволява да замените връзката много към много с две връзки едно към много.

Структурата на данните на релационния модел предполага представянето на предметната област на разглеждания проблем като набор от взаимосвързани връзки.

Във всяка връзка едната връзка може да действа като основна (базова, родителска), а другата - като подчинена (производна, дете). За да поддържат тези връзки, и двете релации трябва да съдържат набор от атрибути, чрез които са свързани: в основната релация това е първичният ключ на релацията (уникално идентифицира кортежа на основната релация); подчинената връзка трябва да има набор от атрибути, съответстващи на първичния ключ на основната връзка. Тук този набор от атрибути вече е вторичен ключ или външен ключ, т.е. дефинира набора от кортежи на производната релация, свързани с единичен кортеж на базовата релация.

Оформят се множество взаимосвързани таблици db схема.

Така че отношението Ре двуизмерна таблица, съдържаща някои данни.

Математически н-арна връзка РПредставлява набор от декартово произведение D 1 × D 2 ×… × D nнабори (домейни) D 1, D 2,…, D n(н≥1), не е задължително да се различават:

R D 1 × D 2 ×… × D n,

където D 1 × D 2 ×… × D n- пълен декартов продукт, т.е. набор от всички възможни комбинации от n елемента всяка, където всеки елемент е взет от своя собствен домейн.

домейне семантично понятие, което може да се разглежда като подмножество от стойности на някакъв тип данни, които имат специфично значение.

Свойства на домейн:

Домейнът има уникално име (в рамките на базата данни),

Дефиниран върху някакъв прост тип данни или в друг домейн,

Може да има някакво булево условие за описание на подмножество от разрешените данни за този домейн,

Носи определено семантично натоварване.

Основното значение на домейните е, че те ограничават сравненията: не можете да сравнявате стойности от различни домейни, дори ако имат един и същ тип данни.

Атрибутвръзката е двойка от формата

<Имя_атрибута: Имя_домена>(или<A: D>).

Имената на атрибути са уникални в рамките на една връзка. Често имената на атрибутите са същите като съответните имена на домейни.

Връзката R, дефинирана в множество домейни, съдържа две части: заглавие и тяло.

Заглавие на връзката- фиксиран брой атрибути на връзката, описващи декартовия продукт на домейни, върху които е посочена връзката:

(<А 1: Г 1>, <А 2: Г 2 >, …, <A n: D n>).

Заглавката е статична: не се променя по време на работа с базата данни.Ако връзката е променена, добавена или премахната атрибути, тогава се получава друга релация. Дори със запазено име.

ТялоВръзката съдържа много кортежи за връзки.

Всеки кортеже набор от двойки от вида:

<Имя_атрибута: Значение атрибута>:

Р(<A 1: Вал 1>, <A 2: Вал 2 >, …, <A n: Val n>).

Такава, че стойността Вал иатрибут А ипринадлежи към домейна D i.

Тялото на релация е колекция от кортежи, тоест подмножество на декартовото произведение на домейни. По този начин тялото на релация само по себе си е релация в математическия смисъл на думата. Тялото на връзката може да се промени по време на работа с базата данни, тъй като кортежите могат да се променят, добавят и изтриват с течение на времето.

Връзката обикновено се записва като:

Р(<А 1: Г 1>, <А 2: Г 2 >, …, <A n: D n>),

или съкратено: Р(А 1, А 2, …, A n) или Р.

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

S R =(А 1, А 2, …, A n), A i D i, и = 1, ..., n.

Ако атрибутите приемат стойности от същия домейн, тогава те се наричат ​​θ-сравними, където θ е наборът от валидни сравнения, посочени за този домейн.

Например, ако домейн съдържа числови данни, тогава всички операции за сравнение са разрешени за него: θ == (=,<>,>=,<=,<,>). Въпреки това, дори за домейни, съдържащи символни данни, могат да бъдат посочени не само операции за равенство и неравенство. Ако за даден домейн е посочено лексикографско подреждане, то той също има пълен набор от операции за сравнение.

Схемите на двете връзки се наричат еквивалентенако имат една и съща степен и подреждането на имената на атрибутите в схемите е възможно, така че сравнимите атрибути да бъдат на едни и същи места, т.е. атрибути, които приемат стойности от един и същи домейн.

По този начин са изпълнени следните условия за еквивалентни отношения:

Наличието на същия брой атрибути;

Наличието на атрибути със същите имена;

Наличието на едни и същи низове в релация, като се има предвид, че редът на атрибутите може да се различава;

Връзките от този вид са различни образи на една и съща връзка.

Свойства на връзкатаследват директно от дефиницията на релация, дадена по-рано. Тези свойства са основно разликата между връзките на релационния модел на данни и простите таблици:

Уникалността на името на връзката. Името на една връзка трябва да се различава от имената на други връзки.

Уникалност на кортежи. Няма идентични кортежи в релация. Всъщност тялото на релация е набор от кортежи и, както всеки набор, не може да съдържа неразличими елементи. Таблиците, за разлика от релациите, могат да съдържат едни и същи редове. Всяка клетка на връзка съдържа само атомна (неделима) стойност.

Неподредени кортежи. Кортежите не са подредени (отгоре надолу), тъй като тялото на релацията е множество и множеството не е подредено (за сравнение, редовете в таблиците са подредени). Една и съща връзка може да бъде представена от различни таблици, в които редовете са в различен ред.

Разстройство на атрибутите. Атрибутите не са подредени (отляво надясно).

Уникалността на името на атрибута в рамките на връзката. Всеки атрибут има уникално име в рамките на връзката, което означава, че редът на атрибутите няма значение (за сравнение колоните в таблицата са подредени). Това свойство е малко по-различно от математическото определение на връзката. Една и съща връзка може да бъде представена от различни таблици, в които колоните са в различен ред.

Атомарност на стойностите на атрибутите. Всички стойности на атрибута са атомарни. Това следва от факта, че основните атрибути имат атомни стойности, тоест определен диапазон от стойности (отделен елементарен тип) е свързан с всеки атрибут, стойностите на атрибутите са взети от един и същ домейн. Схемите на релациите и кортежите са набори, а не списъци, така че редът, в който са представени, няма значение. За сравнение в клетките на таблицата може да се постави различна информация: масиви, структури, други таблици и др.

коментар:

От свойствата на релацията следва, че не всекитаблицата може да бъде релация. За да може някаква таблица да зададе връзка, е необходимо таблицата да има проста структура (съдържа само редове и колони и всеки ред трябва да има еднакъв брой полета), таблицата не трябва да има идентични редове, нито една колона от таблицата трябва да съдържа данни само от един тип, всички използвани типове данни трябва да са прости.

Трябва да се отбележи, че релационният модел е база данни под формата на набор от взаимосвързани връзки, които се наричат схема на релационна база данни.

Обектно-ориентиран модел на данни

Обектно-релационен модел на данни

Други модели на данни

Нарастващата сложност на приложенията за бази данни и ограниченията на релационния модел доведоха до разработването на модела на Codd, първо наречен ĸᴏᴛᴏᴩᴏᴇ разширен релационен модел, а по-късно получи своето развитие в обектно-релационния модел на данни. Базите данни, базирани на тези модели, обикновено се наричат ​​поколение III.

Обектният релационен модел на данни (ORMD) се реализира с помощта на релационни таблици, но включва обекти, подобни на концепцията за обект в обектно-ориентираното програмиране. ORMD използва обектно-ориентирани компоненти като потребителски дефинирани типове данни, капсулиране, полиморфизъм, наследяване, отмяна на метод и т.н.

За съжаление, досега разработчиците не са стигнали до консенсус за това какво трябва да осигури ORMD. През 1999 г. ᴦ. е приет стандартът SQL-99, а през 2003 г. ᴦ. беше пуснато второто издание на този стандарт, наречено SQL-3, което дефинира основните характеристики на ORMD. Но досега обективно-релационните модели, поддържани от различни доставчици на СУБД, се различават значително един от друг. Перспективите в тази посока се доказват от факта, че водещите производители на СУБД, включително Oracle, Informix, INGRES и други, разшириха възможностите на своите продукти до обектно-релационна СУБД (ORDBMS).

В повечето реализации на ORMD обектите се разпознават като агрегат и таблица (връзка), която може да бъде част от друга таблица. Методите за обработка на данни са представени като съхранени процедури и тригери, които са процедурни обекти на база данни и са свързани с таблици. На концептуално ниво всички данни в обектно-релационна база данни се представят като връзка и ORDBMS поддържа езика SQL.

Друг подход за изграждане на база данни е използването на обектно-ориентиран модел на данни (OOMD). Моделирането на данни в OOMD се основава на концепцията за обект. ODM обикновено се използва в сложни предметни области, в които липсва функционалността на релационния модел за моделиране (например за системи за автоматизация на проектиране (CAD), системи за публикуване и др.).

При създаване на обектно-ориентирана СУБД (OODBMS) се използват различни методи, а именно:

• вграждане в обектно-ориентирания език на средства, предназначени за работа с база данни;
• разширение на съществуващия език за работа с бази данни с обектно-ориентирани функции;
• създаване на обектно-ориентирани библиотеки от функции за работа с база данни;
• създаване на нов език и нов обектно-ориентиран модел на данни

Предимствата на OOMD включват широки възможности за моделиране на домейна, изразителен език за заявки и висока производителност. Всеки обект в OOMD има уникален идентификатор (OID - идентификатор на обект). Проверките на OID са значително по-бързи от търсенето на релационни таблици.

Сред недостатъците на OOMD трябва да се отбележи липсата на общоприет модел, липсата на опит в създаването и експлоатацията на OODB, сложността на използване и недостатъчните средства за защита на данните.

През 2000 г. ᴦ. Работната група ODMG (Object Database Management Group), сформирана от производителите на OODBMS, пусна следващия стандарт (ODMG 3.0) за OODBMS, който описва обектния модел, езика за дефиниране на заявки, езика за заявки за обекти и свързващите езици C + +, Smalltalk и Java. Стандартите на ODMG не са официални. Подходът на ODMG към стандартизацията по същество се състои в това, че след приемането на следващата версия на стандарта от организациите-членки на ODMG се публикува книга, която съдържа текста на стандарта.

Сега нека разгледаме как поддръжката на модела на данни се прилага в реални системи за управление на бази данни.

Обектно-ориентиран модел на данни – концепция и видове. Класификация и характеристики на категорията "Обектно-ориентиран модел на данни" 2017, 2018.

Обектно ориентирана база данни(OODB) е база данни, в която данните се моделират под формата на обекти, техните атрибути, методи и класове.

Обектно-ориентирани бази данни обикновено се препоръчват за онези случаи, когато се изисква високопроизводителна обработка на данни със сложна структура.

Манифестът на OODB предлага необходимите характеристики, на които трябва да отговаря всеки OODB. Изборът им се основава на 2 критерия: системата трябва да е обектно-ориентирана и да бъде база данни.

Задължителни характеристики

1. Поддръжка на сложни обекти. Системата трябва да предвижда възможност за създаване на съставни обекти чрез използване на конструкторите на съставни обекти. Конструкторите на обекти трябва да са ортогонални, тоест всеки конструктор може да бъде приложен към всеки обект.

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

3. Поддръжка за капсулиране. Правилното капсулиране се постига поради факта, че програмистите имат право на достъп само до спецификацията на интерфейса на методите, а данните и реализацията на методите са скрити вътре в обектите.

4. Поддръжка за типове и класове. OODB трябва да поддържа поне една концепция за разграничение между типове и класове. (Терминът "тип" е по-съвместим с концепцията за абстрактен тип данни. В езиците за програмиране променливата се декларира с индикация за нейния тип. Компилаторът може да използва тази информация, за да провери извършените операции върху променливата за съвместимост с неговия тип, което помага да се гарантира коректността на софтуера. От друга страна, класът е вид шаблон за създаване на обекти и предоставя методи, които могат да бъдат приложени към тези обекти. По този начин понятието "клас" е по-скоро време за изпълнение, а не време за компилиране.)

5. Подкрепа за наследяване на типове и класове от техните предци. Подтип или подклас трябва да наследи атрибути и методи от своя супертип или суперклас, съответно.

6. Претоварване, съчетано с пълно обвързване. Методите трябва да се прилагат към обекти от различен тип. Реализацията на метод трябва да зависи от типа обекти, към които се прилага методът. За да се осигури тази функционалност, обвързването на имената на методите в системата не трябва да се извършва до момента на изпълнение на програмата.

7. Изчислителна пълнота. Езикът за манипулиране на данни трябва да бъде език за програмиране с общо предназначение.

8. Наборът от типове данни трябва да бъде разширяем. Потребителят трябва да разполага със средствата за създаване на нови типове данни въз основа на набор от предварително дефинирани системни типове. Освен това не трябва да има разлика между използването на системни и потребителски дефинирани типове данни.

OO СУБД

Обектно ориентирани бази данни- бази данни, в които информацията се представя под формата на обекти, както в обектно-ориентираните програмни езици.

Да прилагате или не да прилагате обектно-ориентирани системи за управление на бази данни (OODBMS) в реални проекти днес? В какви случаи трябва да се използват и в кои не?

Тук Ползиизползвайки OODBMS:

· Няма проблем с несъответствие между модела на данни в приложението и базата данни (несъответствие на импеданса). Всички данни се съхраняват в базата данни в същата форма, както в модела на приложението.

· Не се изисква отделна поддръжка на модела на данни от страна на СУБД.

· Всички обекти на ниво източник на данни са строго типизирани. Няма повече имена на колони на низове! Рефакторингът на обектно-ориентирана база данни и кода, който работи с нея, вече е автоматизиран, а не досаден и скучен процес.

ODMG стандарт

Първи манифестформално беше просто статия, изпратена до Конференция за обектно-ориентирани и дедуктивни бази данниот група лица. Както можете да видите в предишния подраздел, изискванията на Манифеста бяха по-скоро емоционални, отколкото изрично посочени. През 1991 г. е създаден консорциумът ODMG (тогава това съкращение е разкрито като Група за управление на обектна база данни, но по-късно придоби по-широко тълкуване - Група за управление на обектни данни). Консорциумът ODMG е тясно свързан с много по-големия консорциум OMG ( Група за управление на обекти), който е създаден две години по-рано. Основната първоначална цел на ODMG беше да разработи индустриалния стандарт за обектно-ориентирани бази данни (общ модел). Основният обектен модел OMG COM ( Основен обектен модел). В продължение на повече от десетилетие ODMG публикува три основни версии на стандарта, последната от които се нарича ODMG 3.0. 16

По ирония на съдбата, въпреки че ODMG е (според мнението на автора) извън OMG, през последните години някои от стандартите OMG разчитат на обектния модел ODMG. По-специално, спецификацията на езика OCL ( Език за ограничаване на обекта), който е част от общата езикова спецификация UML 1.4 (и UML 2.0). В тази статия нямаме намерение да правим подробно сравнение на подходите OMG и ODMG и препращаме заинтересованите читатели към Енциклопедии на Когаловскии материали от уебсайтовете на тези консорциуми. Ще се ограничим до кратко обобщение на основните идеи, съдържащи се в стандарта ODMG-3.

ODMG архитектура

Предложената ODMG архитектура е показана на фиг. 2.1. Тази архитектура дефинира начин за съхранение на данни и различни типове потребителски достъп до това „съхранение на данни“ 17. Едно хранилище на данни е достъпно от език за дефиниране на данни, език за заявки и редица езици за манипулиране на данни. 18 На фиг. 2.1 ODL означава Език за дефиниране на обекти, OQL - Език на обектни заявкии OML - Език за манипулиране на обекти.

Ориз. 2.1. ODMG архитектура

Централно място в архитектурата е модел на данникоято представлява организационната структура, в която се съхраняват всички данни, управлявани от OODBMS. Езикът за дефиниране на обекти, езикът на заявките и езиците за манипулиране са проектирани по такъв начин, че всичките им възможности да разчитат на модела на данните. Архитектурата позволява различни внедряващи структури за съхраняване на моделирани данни, но важно изискване е всички софтуерни библиотеки и всички поддържащи инструменти да се предоставят в обектно-ориентирана рамка и трябва да се поддържат в съответствие с данните.

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

• Обектен модел на данни.Всички данни, съхранявани от OODBMS, са структурирани по отношение на конструкции на модел на данни. Моделът на данни дефинира точната семантика на всички понятия (вижте по-долу за повече подробности).

• Език за дефиниране на данни (ODL).Схемите на базата данни са описани в термините на езика ODL, в който конструкциите на модела на данни се инстанцират под формата на език за дефиниции. ODL ви позволява да опишете схема като набор от интерфейси за тип обект, който включва описанието на свойствата на типа и връзките между тях, както и имената на операциите и техните параметри. ODL не е пълен език за програмиране; типовете трябва да бъдат внедрени на един от езиците на категорията OML. Също така, ODL е виртуаленезик в смисъл, че стандартът ODMG не изисква прилагането му в софтуерни продукти OODBMS, които се считат за съвместими със стандарта. Разрешено е тези продукти да поддържат еквивалентни езици за дефиниция, които включват всички ODL възможности, но адаптирани към спецификата на конкретна система. Въпреки това, наличието на ODL спецификацията в стандарта ODMG е важно, тъй като езикът определя свойствата на модела на данни.

• Език на обектни заявки (ODL).Езикът има синтаксис, подобен на този на SQL, но разчита на семантиката на обектния модел ODMG. Стандартът позволява директно използване на OQL и вграждането му в един от езиците от категорията OML.

Модел на релационни данни

Почти всички съвременни системи се основават на релационни(релационен) модел за управление на база данни. име релационние свързано с факта, че всеки запис в такава база данни съдържа информация, свързана само с един конкретен обект.

V релационниВсички обработвани данни в СУБД са представени под формата на плоски таблици. Информацията за обекти от определен тип е представена в табличен вид: различни атрибути на обекти са концентрирани в колоните на таблицата, а редовете са предназначени да намалят описанията на всички атрибути до отделни екземпляри на обекти.

Моделът, създаден на етапа на инфологичното моделиране, отговаря в най-голяма степен на принципите на относителността. Въпреки това, за да конвертирате този модел в релационен модел, трябва да изпълните процедура, наречена нормализиране.

Теорията за нормализиране работи с пет нормални форми... Тези формуляри са предназначени да намалят излишъка на информация, така че всяка следваща нормална форма трябва да отговаря на изискванията на предходната и някои допълнителни условия. В практическото проектиране на база данни четвъртата и петата форма обикновено не се използват. Ограничихме се до разглеждането на първите четири нормални форми.

Нека представим понятията, необходими за разбиране на процеса на редуциране на модел до релационна схема.

Поведение- абстракция на описания обект като съвкупност от негови свойства. По време на етапа на инфологично проектиране говорихме за абстракцията на обектите и им присвоихме някои свойства. Сега, с идейния дизайн, преминаваме към следващото ниво на абстракция. На този етап обектите като такива вече не съществуват. Ние оперираме с набор от свойства, които дефинират обекта.

Пример за връзка- набор от стойности на свойствата на конкретен обект.

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

Прост атрибут- атрибут, чиито стойности са неделими.

Сложен атрибут- атрибут, чиято стойност е набор от стойности на няколко различни свойства на обект или няколко стойности на едно свойство.

Концепции за образувания ..

домейн

Домейнът е по-специфичен за базите данни, въпреки че има някои аналогии с подтиповете в някои езици за програмиране. В най-общата си форма домейнът се дефинира чрез посочване на някакъв основен тип данни, към който принадлежат елементите на домейна, и произволен логически израз, приложен към елемента от типа данни. Ако този булев израз се оцени като истина, тогава елементът от данни е елемент на домейн.

Най-правилната интуитивна интерпретация на понятието домейн е разбирането за домейн като допустим потенциален набор от стойности от даден тип. Например, имената на домейни в нашия пример са дефинирани върху основния тип низове от знаци, но неговите стойности могат да включват само онези низове, които могат да представляват име (по-специално такива низове не могат да започват с мек знак).

Трябва също да се отбележи семантичното натоварване на концепцията за домейн: данните се считат за сравними само ако принадлежат към един и същи домейн. В нашия пример домейните "Празни числа" и "Групови номера" са от целочислен тип, но не са сравними. Имайте предвид, че повечето релационни СУБД не използват концепцията за домейн, въпреки че Oracle V.7 вече я поддържа.

Обектно-ориентиран модел

В обектно-ориентирания модел при представяне на данни е възможно да се идентифицират отделни записи в базата данни. Връзките се установяват между записите и техните функции за обработка, като се използват механизми, подобни на тези в обектно-ориентираните програмни езици.

Стандартизираният обектно-ориентиран модел е описан в препоръките на стандарта ODMG-93 (Object Database Management Group).

Нека разгледаме опростен модел на обектно-ориентирана база данни. Структурата на обектно-ориентирана база данни е графично представена под формата на дърво, чиито възли са обекти. Свойствата на обекта се описват от някакъв стандартен или конструиран от потребителя тип (дефиниран като клас). Стойността на свойство от тип клас е обект, който е екземпляр на съответния клас. Всеки екземпляр на клас се счита за потомък на обекта, в който е дефиниран като свойство. Обект на екземпляр на клас принадлежи на неговия клас и има един родител. Общите връзки в базата данни образуват съгласувана йерархия от обекти. Пример за логическата структура на обектно-ориентирана библиотечна база данни е показан на фиг. 2.9. Тук обект от тип Библиотека е родителски обекти, например, на класовете Абонат, Директория и Издаване. Различните Book обекти могат да имат едни и същи или различни родители. Обектите от тип Книга, които имат един и същи родител, трябва да се различават поне по инвентарния номер (уникален за всяко копие на книгата), но да имат еднакви стойности на isbn, udc, заглавие и автор.

Логическата структура на обектно-ориентирана база данни е външно подобна на структурата на йерархичната база данни. Основната разлика между двете е методите за манипулиране на данни.

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

Капсулирането ограничава обхвата на име на свойство до обхвата на обекта, в който е дефинирано. Така че, ако добавим свойство, което посочва телефонния номер на автора на книгата и има името phone към обект от типа Каталог, тогава получаваме свойствата със същото име за обектите Абонат и Каталог. Значението на такова свойство ще се определя от обекта, в който е капсулирано.

Наследяването, от друга страна, разширява обхвата на собствеността до всички наследници на обекта. По този начин на всички обекти от типа Book, които са наследници на обект от типа Catalog, могат да бъдат присвоени свойствата на родителския обект: isbn, udk, заглавие и автор. Ако е необходимо да се разшири ефектът на механизма за наследяване върху обекти, които не са непосредствени роднини (например между двама потомци на един и същи родител), тогава в общия им предшественик се дефинира абстрактно свойство от тип abs. И така, дефинирането на билет и номер на абстрактни свойства в обекта Library води до наследяване на тези свойства от всички дъщерни обекти Абонат, Книга и Издание. Следователно не е случайно, че стойностите на свойството на билета на класовете Абонат и Издаване, показани на фиг. 2.9 са същите - 00015.

Полиморфизмът в обектно-ориентирани езици за програмиране означава способността на един и същ програмен код да работи с различни типове данни. С други думи, това означава, че е възможно да има методи (процедури или функции) със същите имена в обекти от различен тип. По време на изпълнението на обектна програма едни и същи методи работят с различни обекти в зависимост от типа на аргумента. За този пример полиморфизмът означава, че обектите от класа Book, които имат различни родители от класа Catalog, могат да имат различен набор от свойства. Следователно програмите за работа с обекти от класа Book могат да съдържат полиморфен код.

Търсенето в обектно-ориентирана база данни се състои в откриване на приликата между обекта, посочен от потребителя, и обектите, съхранявани в базата данни.

Ориз. 2.9 Логическата структура на библиотечната база данни

Основното предимство на обектно-ориентирания модел на данни в сравнение с релационния е възможността за показване на информация за сложни връзки между обекти. Обектно-ориентираният модел на данни ви позволява да идентифицирате един запис в базата данни и да дефинирате функциите на тяхната обработка.

Недостатъците на обектно-ориентирания модел са висока концептуална сложност, неудобство при обработката на данни и ниска скорост на заявка.

Обектно-ориентираните СУБД включват POET, Jasmine, Versant, O2, ODB-Jupiter, Iris, Orion, Postgres.

Банките данни като цяло обикновено се класифицират според икономически и правни характеристики.

Според условията на предоставяне на услугите се разграничават безплатни и платени банки, които от своя страна са разделени на търговски и с нестопанска цел (научни, библиотечни или социално значими).

Според формата на собственост БНД се делят на държавни и недържавни. Според степента на достъпност те разграничават публични и с ограничен брой потребители.

Други видове класификация са свързани с отделни BnD компоненти.

1. Разработването на банките данни се състои от 4 етапа:

Етап 1. Формиране и анализ на системните изисквания:

Изготвя се спецификация на системата, включваща списък на задачите за решаване от BND;

Списък на крайните потребители и техните функции;

Списък с изисквания към базата данни;

Изготвя се диаграма на документооборота в организацията.

Етап 2. Идеен проект: създава се информационен модел на системата без референция към вида на компютъра и вида на системния софтуер; изгражда се модел на инфологична база данни, който най-пълно описва предметната област от гледна точка на потребителя.

Етап 3. Проект за внедряване: избират се изчислителна система, системен софтуер и СУБД; се проектира структурата на данните и се изгражда логически модел на база данни (схема на база данни), който представлява описание на логическата структура на базата данни на езика на конкретна избрана СУБД.

Етап 4. Физическа реализация, която включва създаване и зареждане на данни в база данни, разработване и отстраняване на грешки на приложни програми за работа с база данни, писане на документация. На този етап се изгражда физически модел на базата данни, който описва използваните устройства за съхранение, методи за физическа организация на данните. Описанието на физическата структура на база данни се нарича схема за съхранение. В момента има тенденция за намаляване на този вид работа.

2. Основните задачи, решавани от персонала на базата данни

Персоналът на BND включва различни специалисти: администратори на BND, системни анализатори, системни и приложни програмисти, оператори, специалисти по технически средства, маркетинг и др.

Нека изброим основните функции и задачи, решени от персонала по време на разработването и работата на базата данни:

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

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

3) задаване на ограничения за целостта на базата данни;

4) зареждане и поддържане на базата данни (поддръжката на базата данни включва промяна, изтриване и добавяне на записи); разработване на технология за товарене и поддръжка; разработване на формуляри за въвеждане на данни; въвеждане и контрол на данни;

5) защита на данните (диференциране на потребителите, избор и проверка на средствата за защита, регистриране на опити за неоторизиран достъп);

6) осигуряване на възстановяване на базата данни;

7) анализ на ефективността на BnD и развитието на системата;

8) работа с потребителите (събиране на отговори, обучение);

9) поддръжка на системен софтуер (придобиване, инсталиране и разработка);

10) организационна и методическа работа (избор на методи за проектиране и модернизация, планиране на развитието на BND, разработване на документация).

3. Потребители на банки данни

Както всеки софтуерно-организационно-технически комплекс, банката от данни съществува във времето и пространството. Има специфични етапи на развитие:

Дизайн,

внедряване,

Поддържа,

Актуализация и развитие,

Пълна реорганизация.

На всеки етап от съществуването различни категории потребители са свързани към базата данни.

Крайни потребители

Това е основната категория потребители, чиито интереси са свързани с банката данни. В зависимост от спецификата на създаваната банка данни тя може съществено да се различава в кръга на своите крайни потребители. Това могат да бъдат произволни потребители, които от време на време се обръщат към базата данни към базата данни, след като са получили някаква информация, и могат да бъдат обикновени потребители. Случайните клиенти могат да се разглеждат като потенциални клиенти на фирмата, разглеждащи каталог с изпълнения или услуги с обобщено или подробно описание. Служителите, работещи със специално създадени за тях програми, които осигуряват автоматизация на техните действия при изпълнение на функции, могат да бъдат обикновени потребители. Например, администратор, който планира работата на спомагателно подразделение на компютърна компания, има програма, която му помага да планира и подрежда текущите поръчки според инструкциите, да следи напредъка на тяхната производителност и да организира необходимите аксесоари за нови поръчки в склада. Основните, специални знания, които не трябва да се изискват от крайните потребители в областта на езика и компютърните технологии.

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

Това е група потребители, които в началния етап от разработването на базата данни отговарят за нейния оптимален дизайн от гледна точка на едновременната работа на набор от крайни потребители, в поддръжка, етапът отговаря за правилното работа на този пакет от информация в многопотребителски режим. По време на фазата на проектиране и реорганизация, тази група е отговорна да гарантира, че стекът може да бъде реорганизиран правилно, без да се променя или завършва текущата му поддръжка.

Разработчици и администратори на приложения

Това е група потребители, която функционира по време на проектирането, създаването и реорганизацията на базата данни. Администраторите на приложения координират работата на разработчиците, като разработват конкретно приложение или група приложения, обединени във функционална подсистема. Разработчиците на конкретни приложения работят с частта от информацията от базата данни, която е необходима за конкретно приложение.

Не във всяка банка данни е избран всеки тип потребител. Известно е, че разработването на информационни системи с помощта на таблична СУБД, администраторът на банката данни, администраторът на приложения и разработчикът често съществува в едно лице. Въпреки това, когато създавате модерни, сложни корпоративни бази данни, които се използват за автоматизиране на всички или големи части от бизнес процеси в голяма фирма или корпорация, може да има групи от администратори на приложения и отдели за разработка. Най-трудните режими на работа са определени за групата администратори на база данни.

Нека ги разгледаме по-подробно.

Част от администраторската група на BnD трябва да бъде:

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

Разработчици на структури от данни и външен вид във връзка с информационната база данни;

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

Системни и приложни програмисти;

Експлоатационни фирми и експерти в сервиза.

Въпросът за търговска банка данни играе важна роля при продажбата на експерти.

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

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

2. Разработване на структурата на базата данни: дефиниране на състава и структурата на файловете на базата данни и междинните връзки, избор на методи за оптимизация на данни и методи за достъп до информация, описание на базата данни на езика за описание на данни ( DL).

3. Задаване на ограничения за целостта в описанието на структурата на базата данни и процедурите за обработка на базата данни:

Задаване на декларативни ограничения за интегритет, присъщи на областта с данни;

Определяне на динамични ограничения за интегритет, присъщи на областта на данните в хода на промяна на информацията, съхранявана в базата данни;

Дефиницията на ограниченията за целостта се дължи на структурата на базата данни;

Разработване на процедури за поддържане целостта на базата данни при въвеждане и коригиране на данни;

Определяне на ограничения за интегритет чрез паралелна работа на консуматори в многопотребителски режим.

4. Стартирайте изтеглянето и насочвайте базата данни

Разработване на техника за иницииране на зареждане на база данни, която ще се различава от процедурата за промяна и добавяне на данни при редовно използване на базата данни;

Разработване на техника за проверка на въведените данни, реалното състояние на областта с данни. Реалните обекти на моделите на базата данни на дадена област с данни и корелацията са междинни и към момента на началото на текущия ремонт този модел трябва напълно да съответства на състоянието на обектите на областта с данни сега по време;

Съгласно разработената техника за иницииране на зареждане на дизайна на системата може да се наложи иницииране на въвеждане на данни.

5. Защита на данните

Определяне на система с пароли, принципи на насочване към потребителите, създаване на потребителски групи с идентични права за достъп до данни;

Разработване на принципи за защита на определени данни и обекти за разработка; разработване на специализирани методи за кодиране на информация при нейното циркулиране в локални и глобални информационни мрежи;

Разработване на средства за фиксиране на достъп до данни и опити за нарушаване на системата за сигурност;

Тестване на защитната система;

Разследване на случаи на нарушаване на системата за защита и разработване на динамични методи за защита на информацията в базата данни.

6. Поддръжка за възстановяване на база данни

Разработване на принципи за архивиране на организационни средства и възстановяване на база данни;

Разработване на допълнителен софтуер и технологични процеси за възстановяване на база данни след повреди.

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

8. Изследване на ефективността на функционирането на BnD:

Изследване на индексите на функциониране на BnD

Планиране на преструктуриране (структурна промяна) на базата данни и реорганизация на BND.

9. Работа с крайни потребители:

Събиране на информация за промяна на областта на данните;

Събиране на информация за оценката на работата на BnD;

Обучение на потребителите, консултации с потребители;

Разработване на необходимата системна и учебна документация относно работата на крайните потребители.

10. Подготовка и поддръжка на системни инструменти:

Проучване на съществуващ на пазара софтуер и проучване на възможността и необходимостта от използването им в рамките на BND;

Разработване на необходимата организационно-техническа програма на движенията за развитие на БНД;

Проверка на функционалността на изкупения софтуер преди свързването му към BND;

Контрол на свързването на новия софтуер към BND.

11. Организационна и системна работа в развитието на БНД:

Избор или създаване на метод за разработка на база данни;

Определяне на целите и посоката на развитие на системата като цяло;

Планиране на етапите на развитие на BnD;

Разработване на справочници за общи речници на проекта BND и концептуален модел;

Инсталиране на външни модели на разработени приложения;

Контрол на свързването на новото приложение към работата на BnD;

Възможност за комплексно отстраняване на неизправности на набор от приложения, взаимодействащи от една база данни.