Лекции по бази данни


Ограничения върху релациите



страница8/10
Дата16.12.2016
Размер1.96 Mb.
#11293
ТипЛекции
1   2   3   4   5   6   7   8   9   10

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

  1. Ако R е израз от релационната алгебра, то R =  е ограничението, което казва, че няма кортежи в релацията, която е резултат от изчислението на R.

  2. Ако R, S са изрази от релационната алгебра, то R  S е ограничението, което казва, че всеки кортеж в релацията, която е резултат от изчислението на R е кортеж в релацията, която е резултат от изчислението на S.

Двата начина за изразяване на ограничения са еквивалентни.

Действително, ограничението R  S може да бъде записано по следния еквивалентен начин: R - S = .

От друга страна, ограничението R =  може да бъде записано по следния еквивалентен начин: R  . Формално погледнато,  не е израз на релационната алгебра, така че трябва да използваме израз, чиято стойност е , например R - R.

Еквивалентността на двете ограничения е в сила дори когато R, S са мултимножества, стига R  S да се интепретира по следния начин:

всеки кортеж се среща поне толкова пъти в S, колкото в R.


В SQL най-често се използва първият начин за изразяване на ограничения.
Ограничения за референтна цялостност
В релационния модел ограничение за референтна цялостност се дефинира по следния начин: ако v е стойност на кортеж в релация R, то тази стойност v трябва да присъства в кортеж на друга релация S.

Ще разгледаме примери. Нека разгледаме следните релации


Movie (title, year, length, inColor, studioName, producerC#)

MovieExec (name, address, cert#, netWorth).

При тези две релации можем да наложим следното ограничение за референтна цялостност: за всеки филм, producerC# трябва да е номер на продуцент, описан в таблицата MovieExec. То се изразява в релационната алгебра по следните еквивалентни начини:

producerC# (Movie)  cert# (MovieExec),

producerC# (Movie) - cert# (MovieExec) = .
Нека разгледаме и релацията

StarsIn (movieTitle, movieYear, starName).

Можем да наложим следното ограничение за референтна цялостност: всеки филм, който участва в StarsIn трябва да е описан в Movie.

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

movieTitle, movieYear (StarsIn)  title, year (Movie),

movieTitle, movieYear (StarsIn) - title, year (Movie) = .


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

MovieStar (name, address, gender, birthdate) да предположим, че е в сила функционалната зависимост name  address.

Тогава тя се изразява по следния начин в релационната алгебра:

MS1.name = MS2.name AND MS1.address MS2.address (MS1 (MS) x MS2 (MS)) = .

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

Ще разгледаме пример.

За релацията MovieStar имаме следното ограничение по домен: атрибутът gender може да приема само две стойности - ‘M’ или ‘F’.

Това ограничение се изразява в релационната алгебра по следния начин:

gender FAND gender M (MovieStar) = .
Има ограничения, които не попадат в разгледаните категории.

Това са общите ограничения. Релационната алгебра предоставя възможност за изразяване на най-различни общи ограничения върху базата от данни. Като пример да разгледаме двете релации

MovieExec (name, address, cert#, netWorth)

Studio (name, address, presC#).

Поставяме общо ограничение президент на студио да притежава поне 10000000$. То се изразява по следните еквивалентни начини:

netWorth<10000000 (Studio ⋈presC# = cert# MovieExec) = ;

presC# (Studio)  cert# (netWorth10000000 (MovieExec)).

Други модели на данните
Моделът същност-връзки и релационният модел са само два от моделите на данни, които се използват в съвременните бази от данни.
Първо ще разгледаме обектно-ориентираният модел на данните. Един начин за въвеждане на обектно-ориентираните концепции в базите от данни е да се разширят обектно-ориентираните езици, като C++ и JAVA в посока устойчивост на данните. При програмиране на тези езици се предполага, че обектите изчезват след приключване на програмата, докато при базите от данни се изисква обектите да се съхраняват произволно дълго, докато потребителят сам не реши да ги да мофицира или изтрие. Ще разгледаме чист обектно-ориентиран модел на данните, който се нарича ODL (object definition language) и е разработен от

ODMG (object data management group).


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

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

Моделът предоставя по-голяма гъвкавост при структуриране на схемата на една база от данни. Реализацията на тази концепция е езикът XML (extensible mark-up language). Основното предназначение на XML е да представя документите като набор от вгнездени елементи от данни.

В наше време се счита, че данните, представени с XML са най-добри за обмяна между различни приложения. В бъдеще се предполага, че XML ще може да се използва и за съхранение на данни.


Концепции в обектно-ориентирания подход
Обектно-ориентираното програмиране е инструмент за по-добра организация и по-надеждна реализация на програмите. Първият обектно-ориентиран език за програмиране е Smalltalk и неговите концепции се пренасят в езика C++, който вече е обектно-ориентиран

(за разлика от C). В наши дни езикът JAVA, който поддържа значително по-добра преносимост на програмите от C++ също е

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

Основните концепции при обектно-ориентирания подход са следните:



  1. Мощна система за типизация – всяка система, която използва обектно-ориентирания подход трябва да може да създава нови типове.

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

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

  4. Наследственост - класовете се организират в йерархии, като всеки клас наследява свойствата на по-горните класове в йерархията.


Система за типизация
Всяка система за типизация предоставя атомарни типове - като цяло число, реално число, булев тип, символен низ и средства за създаване на нови типове - конструктори. Конструкторите са приложими както към атомарни, така и към новосъздадени типове. Обикновено се поддържат следните конструктори:

  1. Конструктор за структури от записи - по дадени типове

T1, T2, …, Tn и по съответни имена на полета f1, f2, …, fn се конструира нов тип запис, който се състои от n компоненти. В този тип i-тата компонента е от тип Ti и достъп до нея се осъществява чрез нейното името fi, i = 1, 2, …, n. Структурите записи са точно тези типове, които в C и C++ се дефинират със “struct”.

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

  2. Конструктор на референтен тип (reference) - по даден тип T се конструира нов тип, чиито стойности са подходящи за намиране на стойност от тип T. В C и C++ това са указатели към стойности, т.е. виртуални адреси на стойности.

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

Обектите биват два вида - неизменяеми и изменяеми. Неизменяемите обекти са стойности от тип този клас – например, { 1, 2, 5} е неизменяем обект от тип множество от цели числа. Изменяемите обекти са променливи от тип този клас и тяхното съдържание може да се променя.


Идентификация на обектите
Всеки обект има идентификатор OID (object identifier). Не е възможно два различни обекта да имат едно и също OID, нито пък един обект да има два различни OID. За разлика от модела ER, където всяка същност трябва да има ключ, който е уникален, в обектно-ориентирания модел може да има два различни обекта с еднакво съдържание - те ще се отличават по OID.
Методи
Във всеки клас има асоциирани функции, наречени методи. Всеки метод има поне един аргумент, който е обект на класа. Методът може да има и други аргументи - обекти от други класове или от същия клас.

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

В някои ситуации класовете се наричат абстрактни типове данни.

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


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

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

Ще разгледаме пример.

Можем да опишем неформално клас Account по следния начин:

CLASS Account = { accountNo : integer;

balance : real;

owner : REF Customer;

}

С други думи, типът на Account е структура с три полета - номер на сметка, баланс на сметката и собственик на сметката, който е reference към обект от клас Customer (няма да го дефинираме).



Можем да дефинираме методи на класа Account, например:

deposit (a : Account, m : real) - метод за внасяне на пари в сметка,

withdraw (a : Account, m : real) - метод за теглене на пари от сметка.

Също можем да дефинираме подклас на Account - например, клас TimeDeposit, който има допълнително поле dueDate - датата, в която собственикът може да изтегли парите. Към този клас може да има допълнителен метод penalty (a : TimeDeposit), който изчислява глоба за предсрочно теглене като функция на dueDate и текущата дата.


Въведение в ODL
ODL е език за представяне на структурата на базите от данни в

обектно-ориентиран стил. Той е разширение на IDL (interface description language), който е част от CORBA (common object resource broker architecture) - архитектура за разпределени изчисления върху множество компютри. Обектите в CORBA са машинно независими и тяхното описание се осъществява на IDL.


При обектно-ориентираното проектиране, светът е съставен от обекти.

От концептуална гледна точка обектите са аналогични на същностите в ER-модела, въпреки че с тях могат да се асоциират методи.

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

При организация на информацията обектите с подобни свойства се групират в класове. В контекста на ODL групирането на обектите се извършва по следните два критерия:



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

  2. Свойствата на обектите трябва да са едни и същи. Много често обектите се разглеждат като записи, съставени от полета.

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

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



  • атрибути - те представят стойности, свързани с обекта;

  • връзки - те свързват обекта с един или няколко обекта от други класове;

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


Декларация на клас в ODL
Декларацията на клас в ОDL има следния синтаксис:

class име_на_класа {

списък_от_свойства

} ;
Свойствата са атрибути, връзки или методи, записани в произволен ред.

За разделител в списъка се използва ;.
Атрибути в ODL
Най-простите свойства са атрибутите. Те описват някакъв аспект на обекта, като асоциират с него стойност от фиксиран тип. За разлика от модела ER, не е задължително стойностите на атрибутите да са от атомарни типове. Например, клас, който описва хора може да съдържа атрибут дата на раждане, който е от тип структура с три полета - ден, месец, година. Ще разгледаме примери.

class Movie {

attribute string title;

attribute integer year;

attribute integer length;

attribute enum Film { color, blackAndWhite} type;

} ;

class Star {



attribute string name;

attribute struct Addr

{ string street, string city} address;

} ;


Чрез ключовата дума enum в ODL се дефинира изброен тип - задават се явно допустимите стойности в този тип.

Чрез ключовата дума struct в ODL се дефинира структура, подобно на C.

Изброеният тип в класа Movie и структурата в класа Star имат имена, въпреки че това изглежда излишно. Това позволява тези типове да се използват извън класа чрез операцията :: за разрешаване на достъп.

Например, в клас Camera можем да използваме атрибут uses,

дефиниран по следния начин: attribute Movie::Film uses;.
Връзки в ODL
Както вече споменахме, връзките са свойства на обектите, чрез които един обект се свързва с един или повече обекти от друг клас или от същия клас. Например, ако искаме да свържем всеки филм, който е обект от клас Movie с множеството от звездите, участващи в него, които са обекти от клас Star в декларацията на Movie трябва да добавим следния ред (на произволно място): relationship Set stars;.

По този начин с всеки обект от клас Movie се свързва с множество от

reference към обекти oт клас Stars. Името на това множество е stars.

По-нататък, ако искаме да свържем всяка звезда, която е обект от клас Star с множеството от филмите - обекти от клас Movie, в които тя участва в декларацията на Star трябва да добавим следния ред:

relationship Set starredIn;.

По този начин, обаче, изпускаме една важна особеност на връзките.

Връзката между звездите и филмите е двупосочна, което означава, че ако една звезда S участва във филм M, то S трябва да присъства в множеството за M и M трябва да присъства в множеството за S.

Такава двупосочност се предполага в ER модела и в релационния модел.

За да означим, че връзките starredIn от класа Star и star от класа Movie са свързани по този начин, трябва да добавим в декларациите и на двете ключовата дума inverse, последвана от името на обратната връзка.

В класа Movie промяната изглежа по следния начин:

relationship Set stars inverse Star::starredIn;.

В класа Star промяната изглежда по следния начин:

relationship Set starredIn inverse Movie::stars;.

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

Като пример ще дефинираме класовете Movie, Star, Studio.

class Movie {

attribute string title;

attribute integer year;

attribute integer length;

attribute enum Film { color, blackAndWhite} type;

relationship Set stars inverse Star::starredIn;

relationship Studio ownedBy inverse Studio::owns;

} ;

class Star {



attribute string name;

attribute struct Addr { string street, string city } address;

relationship Set starredIn inverse Movie::stars;

} ;


class Studio {

attribute string name;

attribute Star::Addr address;

relationship Set owns inverse Movie::ownedBy;

} ;
Да отбележим, че всеки филм се притежава от единствено студио и затова ключовата дума Set не е използвана при задаване на типа на връзката ownedBy. Ще разгледаме по-подробно този момент.
Мултипликативност на връзките
Подобно на ER модела, връзките в ODL могат да бъдат класифицирани в следните групи - връзки много към много, връзки много към един, връзки един към един. Различните типове връзки в ODL се отличават по декларациите им:


  1. При връзка много към много между класовете C и D, типът на връзката в класа C е Set, а типът на връзката в класа D е Set. Например, такава е връзката между Movie и Star.

  2. При връзка много към един от класа C към класа D, типът на връзката в класа C е просто D, а типът на връзката в класа D е

Set. Например, такава е връзката между Movie и Studio.

  1. При връзка един към един между класовете C и D, типът на връзката в класа C е просто D, а типът на връзката в класа D е просто C.

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

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

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

Обектът, за който се извиква един метод е скрит параметър за този метод. Уникалност на имената на методите се изисква само в рамките на класа, т.е. възможно е два различни класа да притежават методи с еднакви имена.

Синтаксисът на декларацията на методите е подобен на синтаксиса на декларацията на функции в C със следните особености:


  1. Всеки параметър на метода се предшества от ключова дума in, out или inout, което означава, че той се използва като входен, изходен или входно-изходен параметър. Методът може да модифицира изходните и входно-изходните параметри, но не може да модифицира входните. Изходните и входно-изходните параметри се предават по reference, а входните параметри се предават по стойност. Такава функционалност задължително трябва да се поддържа от базовия език.

  2. Методите могат да възбуждат изключения (exceptions). Това са специални ситуации, които не са част от механизма за предаване на параметрите или връщане на резултата, чрез който методите комуникират. Изключението означава, настъпване на ненормално събитие. Обработката на изключенията не е част от стандарта на ODL. В декларацията на един метод, обаче, можем да да използваме ключовата дума raises, след която описваме изключенията, които методът може да възбуди.

Ще разгледаме няколко примера. В класа Movie можем да добавим на произволно място декларацията на следните три метода:

float lengthInHours () raises (noLengthFound);

void starName (out Set);

void otherMovie (in Star, out Set) raises (noSuchStar).
Първият метод lengthInHours би могъл да връща като резултат дължината на филма-обект, за който е извикан в часове. Този метод може да възбуди изключение noLengthFound, ако дължината на филма не е дефинирана (има стойност NULL).

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

Третият метод otherMovie има един входен параметър - звезда-обект от клас Star и един изходен параметър множество от филми-обекти от клас Movie. Също така, методът може да възбуди изключение noSuchStar.

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


Типове в ODL
Системата за типизация в ODL е подобна на тази в C++. Както всяка система за типизация тя се изгражда от базови типове и правила по които се строят по-сложни типове от по-прости.

Базовите типове в ODL са следните:



  1. Атомарни типове - integer (цяло число), float (реално число), char (символ), string (символен низ), boolean (булев тип),

enum (изброен тип). Изброеният тип е краен списък от имена на абстрактни стойности - например, типът Film в класа Movie.

  1. Имена на класове - например, Movie и Star.

Тези базови типове се комбинират в по-сложни типове с помощта на следните конструктори:

  1. Конструктор Set. Ако T е тип, то типът Set има за стойности крайни множества от елементи от тип T.

  2. Конструктор Bag. Ако T е тип, то типът Bag има за стойности крайни мултимножества от елементи от тип T. Да напомним, че за разлика от множеството, в мултимножеството един елемент може да присъства повече от един път.

  3. Конструктор List. Ако T е тип, то типът List има за стойности крайни списъци от елементи от тип T. Да напомним, че за разлика от множествата и мултимножествата в списъка има наредба на елементите.

  4. Конструктор Array. Ако T е тип, n е естествено число, то типът Array има за стойности масиви с дължина n с

елементи от тип T.

  1. Конструктор Dictionary. Ако T и S са типове, то типът Dictionary има за стойности крайни множества от наредени двойки с първи елемент от тип Т и втори елемент от тип S. Типът T се нарича ключов тип, а типът S се нарича област от стойности. Изисква се да няма две наредени двойки с един и същи ключ. Предполага се, че този тип се реализира по такъв начин, че да се осигурява ефективно търсене по ключ.

  2. Конструктор Struct. Ако T1, T2, …, Tn са типове и f1, f2, …, fn са имена, типът Struct { T1 f1, T2 f2, …, Tn fn } има за стойности структури от n компоненти, i-тата компонента е достъпна чрез името си fi и е от тип Ti, i = 1, 2, …, n. Пример е типът Addr, който се използва в класа Star.

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

По отношение на типовете, които могат да се използват в декларацията на класовете трябва да отбележим следното:


  1. Върху типовете на атрибутите няма никакви ограничения.

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

Ще дадем примери за допустими типове.

integer

Struct N { string field1, string field2 }



List

Array

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

Struct N { Movie field1, Star field2 }

Set

Set>


Каталог: materials
materials -> Исторически преглед на възникването и развитието на ес
materials -> Съюз на математиците в българия-секция русе коледно математическо състезание – 12. 2006 г. 4 клас
materials -> Великденско математическо състезание 12. 04. 2008 г. 2 клас Времето за решаване е 120 минути
materials -> Съюз на математиците в българия-секция русе коледно математическо състезание – 09. 12. 2006г
materials -> Съюз на математиците в българия-секция русе коледно математическо състезание – 12. 2006 г. 8 клас
materials -> Великденско математическо състезание 12. 04. 2008г. 3 клас
materials -> К а т е д р а " информатика"
materials -> Зад. 2 Отг.: 5- 3т Зад. 3 Отг.: (=,-);(+,=);(+,=) по 1т., общо 3т. За
materials -> Іv клас От 1 до 5 зад по 3 точки, от 6 до 10 – по 5 и от 11 до 15 – по 7


Сподели с приятели:
1   2   3   4   5   6   7   8   9   10




©obuch.info 2024
отнасят до администрацията

    Начална страница