Relatii exclusive (arce)

Relatii exclusive (arce)

In unele situatii, relatiile se pot exclude reciproc, adica dintr-un grup de relatii, la un moment dat doar una dintre ele poate avea loc. De exemplu, un cont anume la o banca este detinut fie de o persoana fizica fie de o firma dar nu de ambele tipuri de clienti simultan. Un grup de relatii exclusive este reprezentat in harta relatiilor printr-un arc peste relatiile care fac parte din respectivul grup, ca in figura I.4.2. Toate relatiile ce fac parte din grupul de relatii exclusive trebuie sa aiba aceeasi optionalitate. Un arc apartine unei singure entitati, adica va include doar relatii care pleaca de la o aceeasi entitate.

O entitate poate avea mai multe arce, dar o anumita relatie nu poate face parte decat dintr-un singur arc.

Exista doua tipuri de relatii exclusive

- relatii exclusive obligatorii in care toate relatiile ce fac parte din arcul respectiv sunt obligatorii, ceea ce inseamna ca de fiecare data, una dintre relatii are obligatoriu loc. Este si cazul din figura 1 Evident ca un cont trebuie sa fie detinut de o persoana fizica sau de o firma, o a treia varianta neexistand.

relatii exclusive optionale caz in care toate relatiile ce fac parte din arc sunt optionale. In acest caz de fiecare data are loc cel mult una dintre relatii, existand varianta ca pentru o instanta a entitatii careia apartine arcul sa nu aiba loc nici una din relatiile din grupul respectiv. In figura 2, este exemplificata situatia in care un elev poate opta sa faca parte din echipa de fotbal, sau sa participe la cercul literar sau la cercul de informatica. Insa regulile scolii prevad ca un elev sa nu participe la doua astfel de activitati extrascolare. Relatiile fiind optionale, inseamna ca un elev are libertatea de a decide sa nu participe la nici o activitate extrascolara.

. Relatii exclusive obligatorii    Relatii exclusive optionale

Relatii ierarhice. Relatii recursive

Haideti sa analizam care este structura personalului intr-o firma oarecare. In figura I.1.8 este prezentata doar o parte din organigrama unei firme.

Figura I.1.8. Organigrama unei firme

Un model de proiectare a unei astfel de structuri intr-o baza de date ar fi cea din figura urmatoare:

Figura I.1.9. Implementarea unei structuri ierarhice

Problema este ca fiecare tip de angajat din figura anterioara este de fapt un angajat si probabil exista foarte multe atribute comune tuturor acestor entitati ca de exemplu nume, prenume, adresa, telefon, email, data nasterii etc. Vom putea de aceea modela aceasta structura cu ajutorul unei singure entitati numita ANGAJAT. Insa fiecare angajat poate fi condus de catre un alt angajat. Asadar vom avea o relatie de la entitatea ANGAJAT la ea insasi. O astfel de relatie se numeste relatie recursiva.

Figura I.1.10. Implementarea unei structuri ierarhice folosind relatii recursive

Relatii redundante si multiple

Atunci cand o relatie poate fi dedusa din alte relatii spunem ca acea relatie este redundanta. Relatia se poate elimina.pot exista si     relatii multiple intre entitati

Modelarea datelor istorice

Viata inseamna schimbare, orice lucru se schimba de-a lungul timpului, si nu doar obiectele se modifica in timp dar chiar si relatiile dintre aceste obiecte se schimba. Pretul produselor poate suferi modificari destul de des. Factorii care duc la aceste modificari pot fi dintre cei mai diversi, rata inflatia, anotimpul etc. Asadar atributul pret din cadrul entitatii produs se modifica de-a lungul timpului. Daca nu ne intereseaza decat pretul actual al fiecarui produs modelul este foarte simplu, ca cel din fig.Daca insa pentru afacerea modelata este important sa retinem un istoric al preturilor pentru fiecare produs, atunci atributul pret se va transforma intr-o noua entitate

Atributul data_sfarsit este optional, deoarece data pana la care este valabil pretul curent al unui produs nu este de obicei cunoscut.

Vom considera acum o situatie putin mai dificila. Sa presupunem ca dorim sa modelam o baza de date pentru o biblioteca. Evident este important de retinut un istoric al tuturor imprumuturilor, deoarece pe baza acestora, se pot afla domeniile de interes ale cititorilor, si astfel vom sti ce achizitii de carte sa facem in viitor, vom putea determina uzura cartilor astfel incat sa le putem inlocui etc.

Intr-o prima faza vom obtine o relatie de many-to-many intre entitatile CARTE si CITITOR. Fiecare carte poate fi imprumutata de mai multi cititori (evident nu in acelasi timp), si fiecare cititor poate imprumuta mai multe carti .

Sa rezolvam aceasta relatie many-to-many. Aplicand ceea ce am invatat in capitolele anterioare vom obtine schema din fig. a 2 a

Sa verificam ca acest caz este cel corect. Cheia primara este acum combinatia coloanelor cod_carte si data_imprumut. Poate un cititor imprumuta doua carti in aceeasi data? Adica urmatoarele doua inregistrari pot exista simultan in tabela ISTORIC_IMPRUMUTURI? Raspunsul este DA, combinatia celor doua coloane, pentru cele doua inregistrari fiind unica.

Deci bararea automata a celor doua relatii dinspre entitatea de intersectie nu este intotdeauna o solutie corecta. Pentru a evita aceste complicatii putem recurge la introducerea unei chei artificiale in entitatea de intersectie. In exemplul nostru se poate decide ca pentru fiecare imprumut in parte sa se completeze cate o fisa separata care are un numar unic. Obtinem modelul din figura I.4.13, care este de asemenea unul corect.

Fig. Introducerea unei chei artificiale

Conventii de ridabilitate: Se aplica conventiile Oracle de scriere a ERD-ului:

Entitatea se scrie cu majuscule, singular in interiorul unui dreptunghi cu vf rotunjite.Atributele se scriu cu litere mici , avand in fata unul din semnele #,*,o(UID, obligatoriu, optional).Orientarea liniilor este de la V la E si de sus in jos, evitand intersectia. Se pot folosi subdiagrame de explicare a diagramelor complexe, si explicarea entitatilor cu multe atribute.

Modelarea generica

Modelul generic aduce beneficii daca cerintele afacerii se schimba des. Atunci e nevoie de entitati si atribute noi.Se poate modela o singura entitate Article type care sa pastreze oricate tipuri de articole e nevoie, aceasta reduce nr de entitati.

Procesul maparii

Transformarea modelului conceptual, a ERD-ului, in modelul fizic, adica in baza de date propriu zisa, se numeste mapare. Acest proces implica transformarea fiecarui element al ERD-ului.

Entitati à tabele, (CARTE-carti.dbf)

atributeà campuri,

coloane, UIDàcheie primara,

relatieàcheie straina,

business rules àconstrangeri

Se mapeaza procesul de transformare in diagrama tabelei:

Tipuri de date in Oracle:

daca relatia pe partea many este optionala atunci si coloanele cheii straine vor fi optionale. Ce inseamna acest lucru? Faptul ca un jucator poate la un moment dat sa nu joace la nici o echipa, atunci campul cod_echipa va ramane necompletat in dreptul lui (va avea valoarea NULL). Daca insa relatia este obligatorie pe partea many atunci coloanele ce fac parte din cheia straina vor fi optionale.

In gereral, la maparea unei relatii de tip one-to-many, vom introduce in tabela corespunzatoare entitatii de pe partea many a relatiei cheia primara a entitatii de pe partea one a relatiei. Campurile astfel introduse se vor numi cheie straina (foreign key).

Asadar:

cheia straina a unei tabele este cheia primara din tabela referinta

cheia straina este intotdeauna introdusa in tabela corespunzatoare entitatii din partea many a relatiei.

Maparea relatiilor one-to-one

Dandu-se doua entitati A si B legate intre ele printr-o relatie one-to-one, este evident ca putem include cheia primara A in cadrulul tabelei B, dar putem proceda la fel de bine si invers, incluzand cheia primara a tabelei B in cadrul tabelei A, deoarece fiecarei instante a entitatii A ii corespunde cel mult o instanta a entitatii B, dar si invers, oricarei instante a entitatii B ii corespunde cel mult o instanta a entitatii A

Pentru relatia din figura I.3.3 de exemplu putem memora pentru fiecare persoana seria de pasaport, dar si invers, pentru fiecare pasaport putem memora cnp-ul detinatorului.

Figura I.3.3.

Decizia depinde de specificul afacerii modelate. Daca de exemplu ne intereseaza in primul rand persoanele si abia apoi datele de pe pasapoarte, atunci vom adopta probabil prima varianta, a memorarii seriei de pasaport in cadrul tabelei PERSOANE, daca insa baza de date este destinata evidentei pasapoartelor, atunci probabil vom adopta varianta a doua.

Uneori este convenabil sa memoram cheia straina in ambele parti ale relatiei, in exemplul nostru pentru fiecare pasaport sa memoram cnp-ul persoanei care il detine, dar si pentru fiecare persoana sa memoram seria de pasaport.

Maparea relatiilor recursive

Daca vom privi o relatie recursiva ca pe o relatie de tipul one-to-many intre o entitate si ea insasi, atunci acest caz se reduce la ceea ce deja am discutat. Sa exemplificam relatia din figura I.3.4. Relatia recursiva din aceasta figura poate fi privita ca o relatie intre doua entitati identice, ca in figura I.3.5.

Asadar vom introduce in cadrul tabelei ANGAJATI, marca sefului sau. Diagrama de tabela va arata ca mai jos.

Tabelul I.3.4.