Tutoriale HTML - Tipuri de relatii in ORACLE

Relaţii exclusive (arce)

În unele situaţii, relaţiile se pot exclude reciproc, adică dintr-un grup de relaţii, la un moment dat doar una dintre ele poate avea loc. De exemplu, un cont anume la o bancă este deţinut fie de o persoană fizică fie de o firmă dar nu de ambele tipuri de clienţi simultan. Un grup de relaţii exclusive este reprezentat în harta relaţiilor printr-un arc peste relaţiile care fac parte din respectivul grup, ca în figura I.4.2. Toate relaţiile ce fac parte din grupul de relaţii exclusive trebuie să aibă aceeaşi opţionalitate. Un arc aparţine unei singure entităţi, adică va include doar relaţii care pleacă de la o aceeaşi entitate.

O entitate poate avea mai multe arce, dar o anumită relaţie nu poate face parte decât dintr-un singur arc.

Există două tipuri de relaţii exclusive:

- relaţii exclusive obligatorii în care toate relaţiile ce fac parte din arcul respectiv sunt obligatorii, ceea ce înseamnă că de fiecare dată, una dintre relaţii are obligatoriu loc. Este şi cazul din figura 1 Evident că un cont trebuie să fie deţinut de o persoană fizică sau de o firmă, o a treia variantă neexistând.

- relaţii exclusive opţionale caz în care toate relaţiile ce fac parte din arc sunt opţionale. În acest caz de fiecare dată are loc cel mult una dintre relaţii, existând varianta ca pentru o instanţă a entităţii căreia aparţine arcul să nu aibă loc nici una din relaţiile din grupul respectiv. În figura 2, este exemplificată situaţia în care un elev poate opta să facă parte din echipa de fotbal, sau să participe la cercul literar sau la cercul de informatică. Însă regulile şcolii prevăd ca un elev să nu participe la două astfel de activităţi extraşcolare. Relaţiile fiind opţionale, înseamnă că un elev are libertatea de a decide să nu participe la nici o activitate extraşcolară.

. Relaţii exclusive obligatorii Relaţii exclusive opţionale

tipuri de relatii oracle

tipuri de relatii oracle

Relaţii ierarhice. Relaţii recursive

Haideţi să analizăm care este structura personalului într-o firmă oarecare. În figura I.1.8 este prezentată doar o parte din organigrama unei firme.

tipuri de relatii oracle

Figura I.1.8. Organigrama unei firme

Un model de proiectare a unei astfel de structuri într-o bază de date ar fi cea din figura următoare:

tipuri de relatii oracle

Figura I.1.9. Implementarea unei structuri ierarhice

Problema este că fiecare tip de angajat din figura anterioară este de fapt un angajat şi probabil există foarte multe atribute comune tuturor acestor entităţi ca de exemplu nume, prenume, adresă, telefon, email, data naşterii etc. Vom putea de aceea modela această structură cu ajutorul unei singure entităţi numită ANGAJAT. Însă fiecare angajat poate fi condus de către un alt angajat. Aşadar vom avea o relaţie de la entitatea ANGAJAT la ea însăşi. O astfel de relaţie se numeşte relaţie recursivă.

tipuri de relatii oracle

Figura I.1.10. Implementarea unei structuri ierarhice folosind relaţii recursive

Relaţii redundante si multiple

Atunci când o relaţie poate fi dedusă din alte relaţii spunem că acea relaţie este redundantă. Relatia se poate elimina.pot exista si relaţii multiple între entităţi

tipuri de relatii oracletipuri de relatii oracletipuri de relatii oracle

Modelarea datelor istorice

Viaţa înseamnă schimbare, orice lucru se schimbă de-a lungul timpului, şi nu doar obiectele se modifică în timp dar chiar şi relaţiile dintre aceste obiecte se schimbă. Preţul produselor poate suferi modificări destul de des. Factorii care duc la aceste modificări pot fi dintre cei mai diverşi, rata inflaţia, anotimpul etc. Aşadar atributul preţ din cadrul entităţii produs se modifică de-a lungul timpului. Dacă nu ne interesează decât preţul actual al fiecărui produs modelul este foarte simplu, ca cel din fig.Dacă însă pentru afacerea modelată este important să reţinem un istoric al preţurilor pentru fiecare produs, atunci atributul preţ se va transforma într-o nouă entitate

tipuri de relatii oracletipuri de relatii oracleAtributul data_sfarsit este opţional, deoarece data până la care este valabil preţul curent al unui produs nu este de obicei cunoscut.

Vom considera acum o situaţie puţin mai dificilă. Să presupunem că dorim să modelăm o bază de date pentru o bibliotecă. Evident este important de reţinut un istoric al tuturor împrumuturilor, deoarece pe baza acestora, se pot afla domeniile de interes ale cititorilor, şi astfel vom şti ce achiziţii de carte să facem în viitor, vom putea determina uzura cărţilor astfel încât să le putem înlocui etc.

Într-o primă fază vom obţine o relaţie de many-to-many între entităţile CARTE şi CITITOR. Fiecare carte poate fi împrumutată de mai mulţi cititori (evident nu în acelaşi timp), şi fiecare cititor poate împrumuta mai multe cărţi .

tipuri de relatii oracle

tipuri de relatii oracle

Să rezolvăm această relaţie many-to-many. Aplicând ceea ce am învăţat în capitolele anterioare vom obţine schema din fig. a 2 a

tipuri de relatii oracleSă verificăm că acest caz este cel corect. Cheia primară este acum combinaţia coloanelor cod_carte şi data_imprumut. Poate un cititor împrumuta două cărţi în aceeaşi dată? Adică următoarele două înregistrări pot exista simultan în tabela ISTORIC_IMPRUMUTURI? Răspunsul este DA, combinaţia celor două coloane, pentru cele două înregistrări fiind unică.

Deci bararea automată a celor două relaţii dinspre entitatea de intersecţie nu este întotdeauna o soluţie corectă. Pentru a evita aceste complicaţii putem recurge la introducerea unei chei artificiale în entitatea de intersecţie. În exemplul nostru se poate decide ca pentru fiecare împrumut în parte să se completeze câte o fişa separată care are un număr unic. Obţinem modelul din figura I.4.13, care este de asemenea unul corect.

Fig. Introducerea unei chei artificiale