Conventii de reprezentare a relatiilor

Conventii de reprezentare a relatiilor

In cadrul diagramei entitati-relatii, o relatie va fi reprezentata printr-o linie ce uneste cele doua entitati.

Deoarece o relatie este bidirectionala, linia ce uneste cele doua entitati este compusa din doua segmente distincte, cate una pentru fiecare entitate. Tipul segmentului ce pleaca de la o entitate ne va indica optionalitatea relatiei dintre aceasta entitate si entitatea aflata in cealalta parte a relatiei. Daca acest segment este continuu este vorba de o relatie obligatorie, o linie intrerupta indica o relatie optionala.

De exemplu in figura I.1.4 segmentul ce pleaca de la entitatea JUCATOR fiind intrerupta inseamna ca un jucator poate juca la o echipa, adica relatia este optionala. Segmentul ce pleaca dinspre entitatea ECHIPA este continua, deci la o echipa trebuie sa joace jucatori.

Figura I.1.4. Reprezentarea relatiilor

Modul in care o linie se termina spre o entitate este important. Daca se termina printr-o linie simpla, inseamna ca o instanta si numai una a acestei entitati este in relatie cu o instanta a celeilalte entitati. In exemplul anterior, linia de la JUCATOR la ECHIPA se termina in partea dinspre ECHIPA cu o linie simpla, deci un jucator joaca la o echipa si numai una.

Daca linia se termina cu trei linii (picior de cioara) inseamna ca mai multe instante ale entitatii pot corespunde unei instante a celeilalte entitati. In exemplul anterior linia de la ECHIPA la JUCATOR se termina cu piciorul de cioara, inseamna ca unei instante a entitatii ECHIPA ii corespund mai multe instante ale entitatii JUCATOR, adica o echipa are unul sau mai multi jucatori.

Tipuri si subtipuri

In lumea reala obiectele sunt deobicei clasificate. Astfel vorbim despre animale vertebrate si nevertebrate, despre licee teoretice, colegii, grupuri scolare etc. E normal ca in modelarea bazelor de date sa putem modela si astfel de clasificari.

Un subtip sau o subentitate este o clasificare a unei entitati care are caracteristici comune cu entitatea generala, precum atribute si relatii. Subtipurile se reprezinta in cadrul hartii relatiilor ca entitati in interiorul altei entitati. Atributele si relatiile comune tuturor subtipurilor se vor reprezenta la nivelul supertipului, sau superentitatii. Atributele si relatiile supertipului vor fi mostenite de catre subtipuri.

Un subtip poate avea la randul sau alte subtipuri incluse.

Figura I.4.1. Folosirea subtipurilor si supertipurilor

Subtipurile trebuie sa respecte doua reguli importante:

-       trebuie sa acopere toate cazurile posibile de instante ale supertipului, cu alte cuvinte, orice instanta a supertipului trebuie sa apartina unui subtip. De multe ori ERD-urile includ un subtip 'ALTUL' pentru a acoperi toate situatiile, si pentru a permite viitoare dezvoltari ale modelului.

subtipurile trebuie sa se excluda reciproc. Aceasta regula se traduce pe exemplul de mai sus in faptul ca un angajat nu poate fi, de exemplu, si manager si secretara in acelasi timp.

Documentare Business Rules

Pentru ca modelul conceptual sa fie complet se definesc reguli structurale (-indica tipuri de info ce vor fi stocate si cum relationeaza ele) si reguli procedurale (legate de timp , etc, -acestea ne se repr pe ERD, ci trebuie implementate in programare ).

Tipuri de relatii

Variantele de relatii ce pot exista intre doua entitati sunt prezentate mai jos:

-          relatii one-to-one - acest tip de relatie este destul de rar intalnit. Uneori astfel de relatii pot fi modelate transformand una dintre entitati in atribut al celeilalte entitati.

-  

Figura I.1.5. Relatii one-to-one

-          relatii one-to-many - sunt cele mai intalnite tipuri de relatii, insa si aici cazurile c si d prezentate in figura I.1.6 sunt mai putin uzuale.

Sa facem cateva observatii pe marginea exemplelor din figura I.1.6. Cazul a este foarte des intalnit. La cazul b, am ales o relatie optionala dinspre POEZIE spre POET deoarece poate fi vorba de o poezie populara si in acest caz nu exista un poet cunoscut. La cazul c, am considerat ca o formatie nu poate exista fara a avea cel putin un membru, insa un artist poate avea o cariera solo, deci nu face parte din nici o formatie. Varianta d modeleaza o colectie de filme memorate pe CD-uri. Pentru afacerea considerata, un CD contine obligatoriu un film, dar unul singur, insa un film poate sa nu incapa pe un singur CD de aceea el este poate fi memorat pe unul sau mai multe CD-uri.

Figura I.1.6. Relatii one-to-many

-          relatii many-to-many - aceste tipuri de relatii apar in prima faza a proiectarii bazei de date, insa ele trebuie sa fie ulterior eliminate. Figura I.1.7 prezinta cateva exemple de relatii many-to-many. La punctul b am considerat ca un curs poate aparea pe oferta de cursuri a unei facultati, insa poate sa nu fie aleasa de nici un student de aceea un curs poate fi urmat de unul sau mai multi studenti. Invers, este posibil ca un student sa fi terminat studiile si sa se pregateasca pentru sustinerea examenului de licenta si de aceea el nu mai frecventeaza nici un curs. La punctul c, un profesor angajat al unei scoli trebuie sa predea cel putin o disciplina. Iar o disciplina din planul de invatamant trebuie sa fie predata de cel putin un profesor.

Figura I.1.7. Relatii many-to-many

Transferabilitate

Spunem ca o relatie este nontransferabila daca o asociatie intre doua instante ale celor doua entitati, odata stabilita, nu mai poate fi modificata. Nontransferabilitatea unei relatii se reduce la faptul ca valorile cheii straine corespunzatoare relatiei respective nu pot fi modificate.Conditia de nontransferabilitate a unei relatii este asigurata prin program. De aceea trebuie sa documentam aceasta restrictie.In ERD o relatie nontransferabila se noteaza cu un romb pe linia corespunzatoare relatiei, inspre entitatea a carei cheie straina nu este permis sa o modificam (adica in partea cu many a unei relatii one-to-many).

In figura I.4.5 este dat un exemplu de relatie nontransferabila. Este vorba despre notele date elevilor. Este normal ca o nota data unui elev sa nu poata fi apoi transferata unui alt elev.

Figura I.4.5. Relatii nontransferabile

Rezolvarea relatiilor many-to-many

Dupa cum am precizat mai devreme relatiile many-to-many pot aparea intr-o prima faza a proiectarii bazei de date insa ele nu au voie sa apara in schema finala. Sa consideram relatia din figura I.1.14 dintre entitatile STUDENT si CURS. Se stie ca orice curs se termina in general cu un examen. Unde vom memora nota studentului la fiecare examen?

Figura I.1.14

Daca incercam sa introducem atributul NOTA la entitatea STUDENT, nu vom sti carei materii corespunde acea nota, intrucat unei instante a entutatii student ii corespund mai multe instante ale entitatii CURS. Invers daca incercam sa memoram nota in cadrul entitatii CURS, nu vom stii carui student ii apartine acea nota.

Rezolvarea unei relatii many-to-many consta introducerea unei noi entitati numita entitate de intersectie, pe care o legam de entitatile originale prin cate o relatie one-to-many.

Pasii in rezolvarea unei relatii many-to-many sunt urmatorii:

1) se gaseste entitatea de intersectie, pentru exemplul nostru vom introduce entitate INSCRIERE.

2)      crearea noilor relatii

-        optionalitatea: relatiile care pleaca din entitatea de intersectie sunt intotdeauna obligatorii in aceasta parte. In partea dinspre entitatile originale, relatiile vor pastra optionalitatea relatiilor initiale.

-        cardinalitatea: ambele relatii sunt de tip one-to-many, iar partea cu many va fi intotdeauna inspre entitatea de intersectie.

-        numele noilor relatii

3)      adaugarea de atribute in cadrul entitatii de intersectie, daca acestea exista. In exemplul nostru ne poate interesa de exemplu data la care s-a inscris un student la un curs, data la care a finalizat cursul precum si nota obtinuta la sfarsitul cursului.

4)      stabilirea identificatorului unic pentru entitatea de intersectie: daca entitatea de intersectie nu are un identificator unic propriu, atunci acesta se poate forma din identificatorii unici ai entitatilor initiale la care putem adauga atribute ale entitatii de intersectie.

In exemplul nostru, identificatorul unic al entitatii de intersectie este format din id-ul studentului, id-ul cursului si data inscrierii la curs.

5)      Faptul ca identificatorul unic al unei entitati preia identificatorul unic din alta entitate cu care este legata este reprezentat grafic prin bararea relatiei respective, inspre entitatea care preia UID-ul celeilalte entitati.

Analiza CRUD-se refera la CREATE, RETRIVE, UPDATE, DELETE-(crea , reface, actualiza, sterge) operatii ce fac din ERD un model complet.Se verifica daca modelul exprima toate operatiile ce se pot face si nu are elem inutile, etc.

UID artificial si compus

UID-(Unique Identifier)-e atributul ce identifica in mod unic entitatea(ex: CNP, cod, id,). Daca e nevoie de o combinatie de mai multe atribute care sa identifice in mod unic entitatea , e vorba de un UID compus. Daca se recurge la o modalitate de identificare printr-un cod artificial oferit in mod automat de program, e vorba de UID artificial.

Ce este normalizarea?

Normalizarea este o tehnica de proiectare a bazelor de date prin care se elimina (sau se evita) anumite anomalii si inconsistente a datelor. O baza de date bine proiectata nu permite astfel ca datele sa fie redundante, adica aceeasi informatie sa se gaseasca in locuri diferite, sau sa memorezi in baza de date, informatii care se pot deduce pe baza altor informatii memorate in aceeasi baza de date. Anomaliile care pot sa apara la o baza de date nenormalizata sunt urmatoarele:

anomalii la actualizarea datelor la o biblioteca se inregistreaza intr-o tabela urmatoarele date despre carti: ISBN, titlu, autor, pret, subiect, editura, adresa editurii. La un moment dat o editura isi schimba adresa. Bibliotecara va trebui sa modifice adresa editurii respective, in inregistrarile corespunzatoare tuturor cartilor din biblioteca aparute la respectiva editura. Daca aceasta modificare nu se face cu succes, unele dintre inregistrari ramanand cu vechea adresa, apare din nou o inconsistenta a datelor.

-                       anomalii de inserare - in exemplul anterior, nu vom putea memora adresa unei edituri, lucru inacceptabil daca dorim sa avem informatii si despre edituri a caror carti nu le avem in biblioteca, eventual de la care dorim sa facem comenzi.

-                       anomalii de stergere - sa presupunem ca intr-o tabela memoram urmatoarele informatii: codul studentului, codul cursului, codul profesorului. La un moment dat, nici un student nu mai doreste sa participe la un anume curs. Stergand toate inregistrarile corespunzatoare cursului, nu vom mai putea sti niciodata cine preda acel curs.

Edgar Codd a definit primele trei forme normale 1NF, 2NF si 3NF. Ulterior s-au mai definit formele normale 4NF, 5NF, 6NF care insa sunt rar folosite in proiectarea bazelor de date.

Prima forma normala

O entitate se gaseste in prima forma normala daca si numai daca:- nu exista atribute cu valori multiple;- nu exista atribute sau grupuri de atribute care se repeta. Cu alte cuvinte toate atributele trebuie sa fie atomice, adica sa contina o singura informatie.

Daca un atribut are valori multiple, sau un grup de atribute se repeta, atunci trebuie sa creati o entitate suplimentara pe care sa o legati de entitatea originala printr-o relatie de 1:m. In noua entitate vor fi introduse atributele sau grupurile de atribute care se repeta.

Sa consideram entitatea din figura I.2.1, referitoare la notele elevilor unei clase. Cateva observatii referitoare la aceasta entitate: cate discipline are un elev? Cate perechi (disciplina, nota) va trebui sa aiba entitatea Elevi? Sa spunem ca stim exact cate discipline maxim poate studia un elev. Ce se intampla daca in anul viitor scolar acest numar de discipline va fi mai mare? In plus, la o materie un elev poate avea mai multe note. Cate note? Cum memoram aceste note? Le punem in campul corespunzator disciplinei cu virgula intre ele?

Cum rezolvam aceasta problema? Vom crea o noua entitate in care vom introduce disciplina si nota la disciplina respectiva (vezi figura I.2.2.).

In acest fel fiecarui elev ii pot corespunde oricate note, iar la o disciplina poate avea oricate note, singura restrictie conform acestui model fiind ca un elev nu va putea primi in aceeasi zi la aceeasi materie mai multe note.

Un alt exemplu de incalcare a regulilor primei formei normale, putin mai 'ascuns', este prezentat in figura I.2.5. De ce? Pentru ca adresa este de forma 'str. Florilor, bl. 45, sc. A, ap. 28, etaj 3, Brasov, cod 123123', forma care de fapt contine mai multe informatii elementare. Asadar, in mod normal acest atribut ar trebui 'spart' in mai multe atribute ca in figura I.2.6.

Noile atributele introduse sunt optionale intrucat daca elevul locuieste la casa, probabil atributele bloc, apartament, scara, etaj, nu au sens. Invers daca elevul locuieste la bloc, probabil nu poate fi completat numarul.

Pentru acest tip de incalcare a regulilor formei normale 1NF poate fi totusi ignorata, decizia depinzand de natura fenomenului, sau afacerii modelate. In exemplul anterior, intrucat datele din interiorul unei adrese este putin probabil sa se modifice, modificandu-se el mult adresa completa a unui elev, se poate decide sa nu operam modificarea anterioara. Daca insa aceste informatii s-ar modifica frecvent, de exemplu denumirile strazilor s-ar modifica mereu, atunci probabil modificarea este de dorit.

A doua forma normala

O entitate se gaseste in a doua forma normala daca si numai daca se gaseste in prima forma normala si in plus orice atribut care nu face parte din UID (unique identifier) va depinde de intregul UID nu doar de o parte a acestuia.

De exemplu daca memoram angajatii unui departament intr-o entitate ca mai jos:

Se observa ca data_nasterii si adresa sunt doua atribute care depind doar de id-ul angajatului nu de intregul UID care este combinatia dintre atributele id_dep si id_angajat. Aceasta situatie se rezolva prin crearea unei noi entitati ANGAJAT, pe care o legam de entitatea DEPARTAMENT printr-o relatie 1:m.

O situatie mai speciala este in cazul relatiilor barate, cand trebuie tinut seama ca UID-ul unei entitati este compus din atribute din entitatea respectiva plus un atribut sau mai multe atribute provenite din relatia barata. Sa consideram urmatorul exemplu:

Se observa ca UID-ul entitatii APARTAMENT este compus din combinatia a trei atribute: numarul apartamentului, numarul blocului si strada. Deci toate atributele din entitatea APARTAMENT care nu fac parte din UID, trebuie sa depinda de intregul UID. Dar se stie ca atributul cod_postal depinde doar de strada si de numarul blocului, nu si de numarul apartamentului. Acest lucru ne spune ca acest atribut nu este memorat la locul potrivit. Deoarece depinde doar de combinatia (strada, nr_bloc), inseamna ca de fapt depinde de UID-ul entitatii bloc. Asadar vom muta atributul cod_postal in entitatea BLOC.

Observatie. Daca o entitate se gaseste in prima forma normala si UID-ul sau este format dintr-un singur atribut atunci ea se gaseste automat in a doua forma normala.

A treia forma normala

O entitate se gaseste in a treia forma normala daca si numai daca se gaseste in a doua forma normala si in plus nici un atribut care nu este parte a UID-ului nu depinde de un alt atribut non-UID. Cu alte cuvinte nu se accepta dependente tranzitive, adica un atribut sa depinda de UID in mod indirect.

Luam ca exemplu entitatea CARTE din figura I.2.10. Atributul biografie_autor nu depinde de ISBN ci de atributul autor. Nerezolvarea acestei situatii duce la memorarea de date redundante, deoarece biografia unui autor va fi memorata pentru fiecare carte scrisa de autorul respectiv. Rezolvarea acestei situatii este sa cream o noua entitate AUTOR, pe care o legam de entitatea CARTE printr-o relatie 1:m (figura I.2.11.).

Atributul nu por avea alte atribute, asa ca el devine entitate.