Tutoriale ORACLE - Tipuri de relații în 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

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.

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:

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ă.

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

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

Atributul 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 .

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

Să 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