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

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

Бинарната връзка sequel_of отразява, че един филм е продължение на друг. Ролята original обозначава оригиналът на даден филм (той е единствен и затова връзката sequel_of в ролята original е много към един). Ролята sequel обозначава продълженията на даден филм.

Във връзката contracts участват две роли на Studios. Ролята

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

Така всеки екземпляр на връзката се състои от наредени четворки от вида (studio1, studio2, movie, star), където star е конкретна звезда, movie е конкретен филм, studio1 е конкретно студио в ролята movie_producer, което е сключило договор със star, studio2 е конректно студио в ролята star_owner, което продуцира movie.

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

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

В диаграмата отразяваме факта, че дадена звезда по даден филм получава точно определена заплата.

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

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

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

Като пример ще преобразуваме множественaта връзка от по-горе, в която има роли.


star_of


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

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

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

по-горни подкласове и множества.

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

Съответствие

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

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

Добавянето на всяка една връзка трябва да бъде добре обмисляно – трябва да се внимава дали новата връзка не е следствие от дефинираните преди това връзки. Определянето на точните връзки се извършва въз основа на проучвания в приложната област.

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

Нека E е множество от същности. Нека са изпълнени следните условия:

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

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

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

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

Естествено, това не изключва възможността стойностите на някои атрибути от K за e₁ и e₂ да съвпадат. Последното е възможно в случай, че K се състои от повече от един атрибут.

Всяко множество от същности трябва да притежава ключ. Всъщност, това не е абсолютно задължително за модела ER – възможно е две конкретни същности да се различават по начина на свързване с конкретни същности от други множества.

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

Когато едно множество от същности участва в isa-йерархия, то в ключа на това множество задължително трябва да участват само атрибути на коренното множество.

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

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

Има няколко начина, по които ограниченията на единствената стойност се представят в диаграмата ER.

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

Има няколко начина, по които можем да наложим ограничения за референтна цялостност:

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

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

Стрелките се интерпретират по следния начин:

• 
  стрелката от owns към Studios означава, че всеки филм трябва да се притежава от единствено съществуващо студио;
  
• 
  стрелката от runs към Studios означава, че всеки президент трябва да управлява единствено същестуващи студио;
  
• 
  стрелката от runs към Presidents означава, че всяко студио се управлява най-много от един президент, но може да има студия, които в определен момент нямат президенти.
  

Частен случай на такова ограничение са връзките много към един

(в частност един към един). В модела ER всяко ребро, което свързва връзка с множество същности можем да надпишем с ограничение за броя на същностите, които могат да са във връзка с конкретни същности от другите множества на връзката. Ще разгледаме пример.

Ограничението означава, че във всеки филм може да участват

най-много 10 звезди. Чрез такъв тип ограничения можем да представяме

стрелките – вместо обикновената стрелка можем да надписваме съответното ребро с  1, а вместо закръглена стрелка можем да надписваме съответното ребро с =1.

Слаби множества от същности се използват когато имаме множества от същности, които са организирани в йерархия на класификация, която не е isa-йерархия. Ако същностите на едно множество E са подсъщности на друго множество F, то е възможно имената на същностите от E да не са уникални, докато не се вземат под внимание имената на същностите

от F, на които съответните същности от E са подсъщности.

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

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

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

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

Преобразували сме тернарната връзка между звезда, филм и студио в бинарни. Ключът на същностите от множеството Contracts се формира от ключовете на множествата Movies, Stars и Studios.

Нека E е слабо множество от същности.

Тогава неговият ключ се състои от:

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

• 
  тя е бинарна и е много към един от E към някое множество F;
  
• 
  съществува ограничение за референтна цялостност от E към F, т.е. всяка конкретна същност от E трябва да е свързана с точно една конкретна същност от F чрез връзката R (в диаграмата ER трябва да има закръглена стрелка от R към F).
  

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

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

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

title	year	length	type
Star Wars	1977	124	color
Mighty Ducks	1991	104	color
Wayne’s World	1997	95	color

Relation (Attr1, Attr2, …, AttrN). Например, схемата на горната релация е:

Movies (title, year, length, type).
Атрибутите на една релация са множество, а не списък. Въпреки това се предполага, че при визуализация атрибутите се записват в определен стандартен ред. Този стандартен ред винаги ще определяме от записа на схемата на релацията.
Схема на една база от данни наричаме множеството от схемите на релациите, които участват в тази база от данни.
Всеки кортеж притежава една компонента за всеки атрибут на релацията. За да обозначаваме отделен кортеж на една релация обикновено записваме неговите компоненти, заградени в скоби и разделени със запетаи. При това, компонентите на кортежа записваме в съответствие със стандартния ред на атрибутите.

Например, за релацията Movie първият кортеж се обозначава по следния начин: (Star Wars, 1977, 204, color).

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

Например, за релацията Movies атрибутът title има домен символен низ, атрибутите length и year имат домен цяло число, атрибутът type има домен множеството { color, blackAndwhite }.
Релациите са множества от кортежи, не списъци от кортежи. Поради тази причина, редът в който се записват кортежите на една релация е незначителен. Освен това, редът в който се записват атрибутите на една релация също е незначителен. Когато променяме този ред, обаче, трябва да променяме и редът в който се записват компонентите на съответните кортежи.

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

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

Преобразуването на ER диаграма в релационна схема се осъществява по следния начин:

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

Този начин не се прилага в следните ситуации, при които се изисква

по-специално преобразуване:

• 
  преобразуване на слаби множества от същности;
  
• 
  преобразуване на isa-връзки;
  
• 
  понякога две релации се комбинират в една – например, релация за множество същности E се комбинира с релация за връзка много към един от E към някое друго множество от същности.
  

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

Movies (title, year, length, type)

Stars (name, address)

Studios (name, address)

Presidents (name)

Екземплярите на множествата същности се преобразуват по естествен начин към кортежи. Пример за екземпляр на релацията Stars:

name	address
Carrie Fisher	123 Maple Str., Hollywood
Mark Hamill	456 Oak Rd., Brentwood
Harrison Ford	789 Palm Dr., Beverly Hills

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

StarsIn (title, year, starName)

Owns (title, year, studioName)

Runs (studioName, presidentName)

Ключовите атрибути на множеството Movies са title, year, ключовият атрибут на множеството Stars е name, ключовият атрибут на множеството Studios е name, ключовият атрибут на множеството Presidents е name. Преименуването на атрибутите за връзката Runs е съществено, тъй като ключовите атрибути на множествата Studios и Presidents имат еднакви имена.

Като друг пример, връзката с ролите на Studios се преобразува към следната схема на релация:

Contracts (title, year, starName, producingStudio, studioOfStar).

Ключовите атрибути на Studios участват два пъти, тъй като множеството Studios има две роли във връзката contracts. Поради това извършваме преименуване. Ако връзката contracts има атрибут salary, то този атрибут salary също трябва да се включи към атрибутите на релацията.

i = 1, 2, …, n се преобразува към кортеж, като за всяка конкретна същност e_i компонентите на кортежа, съответни на ключовите атрибути за множеството E_i са стойностите на тези ключови атрибути за същността e_i, i = 1, 2, …, n. Естествено, ако връзката има атрибути, то с наредената n-торка са свързани стойности за тези атрибути, така че компонентите на кортежа, които съответстват на атрибутите на връзката ще приемат тези стойности.