Пример за обектно-ориентиран модел на данни. Обектно-ориентиран модел на база данни. Недостатъчна поддръжка за сложни обекти

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

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

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

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

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

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

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

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

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

Полиформизъмозначава способността на един и същ програмен код да работи с различни типове данни. С други думи, това означава, че е допустимо в обекти от различен тип да има методи - процедури и функции - с еднакви имена. По време на изпълнението на обектна програма едни и същи методи работят с различни обекти в зависимост от типа на аргумента. За DB "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.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

коментар:

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

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

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

Определение 1

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

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

Определение 2

Графично представянеобектно-ориентирана структура на база данни е дърво, чиито възли представляват обекти.

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

На фигура 1 обектът LIBRARY е родител на обектите DIRECT, SUBSCRIBER и REFERENCE. Различни обекти от типа BOOK могат да имат един или различни родители. Обектите от тип BOOK, които имат един и същи родител, трябва да имат поне различни инвентарни номера (уникални за всяко копие на книгата), но едни и същи стойности на свойствата автор, заглавие, udkи isbn.

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

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

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

Определение 3

Цел капсулации- ограничаване на обхвата на името на свойството до границите на обекта, в който е дефинирано.

Например, ако към обекта DIRECTORY се добави свойство, което задава телефонния номер на автора и има името телефон, свойствата със същото име ще бъдат получени за обектите DIRECTORY и SUBSCRIBER. Значението на дадено свойство се определя от обекта, в който е капсулирано.

Определение 4

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

Например, на всички обекти BOOK, които са наследници на обекта DIRECTORY, могат да бъдат присвоени свойствата на родителския обект: автор, заглавие, udkи isbn.

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

И така имотите стаяи билетв обекта LIBRARY се наследяват от всички дъщерни обекти REFERENCE, BOOK и SUBSCRIBER. Ето защо стойностите на това свойство на класовете SUBSCRIBER и OUTPUT са еднакви - 00015 (Фигура 1).

Определение 5

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

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

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

Предимства и недостатъци на обектно-ориентирания модел

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

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

Днес подобни системи са доста разпространени. Те включват СУБД:

• Postgres,
• Орион,
• Ирис,
• ODBJupiter,
• Versant,
• Обективност / БД,
• ObjectStore,
• Статис,
• Скъпоценен камък
• G-база.

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

Стандартът OOM е описан в препоръките на стандарта ODMG-93 (Object Database Management Group). Препоръките на ODMG-93 все още не са изпълнени напълно. За да илюстрирате ключовите идеи, разгледайте малко опростен модел на обектно-ориентирана база данни.

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

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

Пример за логическата структура на OO DB на библиотекарството е показан на фиг. 3.14. Тук обект от тип LIBRARY е родителски обекти, например, на класовете SUBSCRIBER, DIRECTORY и OUTPUT. Различните обекти от тип BOOK, имащи един и същи родител, трябва да бъдат различни, поне по инвентарния номер (уникален за всяко копие на книгата), но да имат еднакви стойности на свойства isbn, udk, имеи автор.

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

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

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

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

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

наследство,напротив, разширява обхвата на собствеността върху всички низходящи на обекта. И така, на всички обекти от типа BOOK, които са наследници на обект от типа DIRECTORY, могат да бъдат присвоени свойствата на родителския обект: isbn, udk, имеи автор.Ако е необходимо да се разшири ефектът на механизма за наследяване върху обекти, които не са непосредствени роднини (например между двама потомци на един и същи родител), тогава в общия им предшественик се дефинира абстрактно свойство от тип abs. И така, определението за абстрактни свойства билети стаяв обект LIBRARY причинява тези свойства да бъдат наследени от всички дъщерни обекти SUBSCRIBER, BOOK и REFERENCE. Неслучайно стойностите на имота билетот класовете АБОНАТ и ИЗДАВАНЕ, показани на фигурата, ще бъдат еднакви - 00015.

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

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

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

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

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

Нека се обърнем отново към задачата Orders, представена под формата на релационен модел на данни на фиг. 3.8 и го разгледайте от гледна точка на обектно-ориентирана база данни. Има общо три класа: " Клиенти», « Поръчки" и " Стоки". Обекти от класа " Клиенти»Конкретни клиенти ли са; свойства на класа - клиентски номер, име на клиента град, статус и т.н. Методи на класа - " Създайте поръчка», « Платете фактура" и т.н. Методът е някакъв вид операция, която може да се приложи към обект; методът е това, което обектът трябва да прави. Класът, съответстващ на таблицата " Подробности за поръчката", не е задължително. Данните от таблицата могат да бъдат част от класа " Поръчки". Присъствие в класа " Клиенти"метод" Създайте поръчка„Довежда до взаимодействие с обекти от класовете“ Поръчки" и " Стоки". В този случай потребителят не трябва да знае за това взаимодействие на обекти. Потребителят се позовава само на обекта " Поръчки"И използва метода" Създайте поръчка". Въздействието върху други бази данни може да бъде скрито от потребителя. Ако методът " Създайте поръчка", От своя страна се отнася до метода" Проверете кредитоспособността на клиента“, Този факт също може да бъде скрит от потребителя. В релационни бази данни изпълнението на същата функционалност изисква процедури за писане във Visual Basic за приложения (VBA).

През 90-те години имаше експериментални прототипи на системи за управление на бази данни OO. В момента такива системи са широко разпространени. По-специално, те включват следните СУБД: POET (ПОЕТ софтуер), Jasmine (Computer Associates), Versant (Versant Technologies), O2 (Ardent Software), ODB-Jupiter (Inteltek Plus Research and Production Center) и Iris, Orion и Postgres.

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

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

Фиг. 3. Обектно-ориентиран модел на данни

Всеки обект има състояние и поведение. Състоянието на обекта е набор от стойности за неговите атрибути. Поведението на обекта е набор от методи (програмен код), които оперират със състоянието на обекта. Стойността на атрибут на обект също е някакъв обект или набор от обекти. Състоянието и поведението на обект се капсулира в обект; взаимодействието на обектите се основава на предаването на съобщения и изпълнението на съответните методи.

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

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

Обектно-ориентираните бази данни се използват най-широко в области като системи за компютърно проектиране/производство (CAD/CAM), системи за компютърно-подпомогната разработка на софтуер (CASE), системи за комбинирано управление на документи, т.е. в области, които не са традиционни за бази данни. Примери за обектно-ориентирани СУБД са POET, Jasmine, Versant, Iris, Orion.

2.2.4 релационен модел на данни

През 1970 г. американският математик Е.Ф. публикува статия, която е революционна по своето съдържание, предлагайки да използва теорията на множествата за обработка на данни. Той твърди, че данните трябва да бъдат обвързани според тяхната логическа връзка (напр. обединение, пресичане), а не физически указатели. Той предложи прост модел на данни, в който всички данни са табличени с уникално именувани редове и колони. Тези таблици се наричат ​​релации (relatio - релация), а моделът е релационен модел на данни, изграден върху концепцията за математически отношения и понякога се нарича още модел на Код. Предложенията на Код бяха толкова ефективни за системите за бази данни, че за този модел той беше удостоен с престижната награда Тюринг за теоретични основи на изчисленията.

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

Фиг. 4. Таблица на релационна база данни.

Всяка колона има свое собствено име. Например в таблицата "Стоки на склад" (фиг. 5.) имената на полетата са както следва: Идентификатор, Продукт, Име на групата, Група, мерна единица, Покупна цена, Продажна цена, Наличност на склад.

Ориз. 5. Таблица „Стоки на склад »

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

Всеки запис се отличава с уникален ключ за запис, които са два вида: първичен и вторичен.

Първичен ключТова е едно или повече полета, които уникално идентифицират запис. Ако първичният ключ се състои от едно поле, той се нарича прост ключ, ако се състои от няколко полета, се нарича съставен ключ.

Вторичен ключТова е поле, чиято стойност може да се повтори в няколко записа на файла, тоест не е уникална.

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

Фиг. 6. Пример за използване на външен ключ

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

Индексирането е средство за ефективен достъп чрез ключ до файл. Индексирането създава допълнителен файл, който съдържа всички ключови стойности на файла с данни по подреден начин. За всеки ключ индексният файл съдържа указател към съответния запис във файл с данни. Указател към запис във файла с данни има директен достъп до този запис.

За работа с релационни бази данни понастоящем често се използва езикът за структурирани заявки (Structured Query Language - SQL). Това е език, използван за създаване, модифициране и манипулиране на данни. SQL не е език за алгоритмично програмиране. Това е информационно-логически език, базиран е на релационна алгебра и е разделен на три части:

· Оператори за дефиниране на данни;

Оператори за манипулиране на данни (Insert, Select, Update, Delete);

· Оператори за дефиниране на достъп до данни.

През 1986 г. SQL е приет като ANSI (Американски национален институт по стандартизация) стандарт за езици на релационни бази данни. Днес тази база данни се счита за стандарт за съвременните информационни системи.

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

Предимствата на релационния модел са:

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

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

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

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

Недостатъците на релационния модел са:

Сравнително ниска скорост на достъп и голямо количество външна памет;

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

Не винаги е възможно да се представи предметна област под формата на набор от таблици.

В момента релационните бази данни са най-разпространени. Мрежовите и йерархичните модели се считат за остарели, обектно-ориентираните модели все още не са стандартизирани и широко разпространени.

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

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

Стандартизиран обектно-ориентиран модел е описан в препоръките на стандарта 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. Разработване на структурата на базата данни: дефиниране на състава и структурата на файловете на базата данни и междинните връзки, избор на методи за оптимизиране на данни и методи за достъп до информация, описване на базата данни на езика за описание на данни (DLS) .

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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