Tutoriale HTML - Relatii intre entitati

În lumea reală, obiectele nu există izolat.Intre ele exista relatii Aşadar, după ce aţi identificat care sunt entităţile şi atributele acestor entităţi este timpul să punem în evidenţă relaţiile care există între aceste entităţi, modul în care acestea comunică între ele. O relaţie este o asociere, legătură, sau conexiune existentă între entităţi şi care are o semnificaţie pentru afacerea modelată. Orice relaţie este bidirecţională, legând două entităţi sau o entitate cu ea însăşi. De exemplu, elevii studiază mai multe materii, o materie e studiată de către elevi.

Orice relaţie este caracterizată de următoarele elemente:

-       1. numele relaţiei ;                 2.opţionalitatea relaţiei;                                3. gradul (cardinalitatea) relaţiei.

Să luăm de exemplu relaţia existentă între entităţile JUCĂTOR şi ECHIPĂ. Vom spune:

Un JUCĂTOR joacă într-o ECHIPĂ. Si La o ECHIPĂ trebuie să joace unul sau mai mulţi JUCĂTORI.

 

-       Numele relaţiei este: joacă.

-       Pentru a stabili opţionalitatea relaţiei trebuie să răspundem la următoarea întrebare: Un jucător trebuie să joace într-o echipă? Se poate ca un jucător să nu joace în nici o echipă? Dacă acceptăm că toţi jucătorii trebuie să joace într-o echipă relaţia este obligatorie sau mandatorie şi vom spune:            Un JUCĂTOR trebuie să joace într-o ECHIPĂ.

Dacă însă acceptăm că există jucători care nu joacă în nici o echipă (de exemplu li s-a terminat contractul şi în momentul de faţă nu mai joacă la nici o echipă), atunci relaţia este opţională.

 În acest caz vom spune:                                                      Un JUCĂTOR poate juca la o ECHIPĂ.

-       Cardinalitatea relaţiei este dată de numărul de instanţe ale entităţii din partea dreaptă a relaţiei care pot intra în relaţie cu o instanţă a entităţii din partea stângă a relaţiei. Adică va trebui să răspundem la întrebări de genul: La câte echipe poate juca un jucător? Răspunsurile posibile sunt unul şi numai unul, sau unul sau mai mulţi. Vom spune:

                  Un JUCĂTOR trebuie/poate să joace la o ECHIPĂ şi numai una.

sau        Un JUCĂTOR trebuie/poate să joace la una sau mai multe ECHIPE.

Cea mai realistă varinată a relaţiei este aşadar: Un JUCĂTOR poate să joace la o ECHIPĂ şi numai una.

Convenţii de reprezentare a relaţiilor

 

În cadrul diagramei entităţi-relaţii, o relaţie va fi reprezentată printr-o linie ce uneşte cele două entităţi.

Deoarece o relaţie este bidirecţională, linia ce uneşte cele două entităţi este compusă din două segmente distincte, câte una pentru fiecare entitate.  Tipul segmentului ce pleacă de la o entitate ne va indica opţionalitatea relaţiei dintre această entitate şi entitatea aflată în cealaltă parte a relaţiei. Dacă acest segment este continuu este vorba de o relaţie obligatorie, o linie întreruptă indică o relaţie opţională.

De exemplu în figura I.1.4 segmentul ce pleacă de la entitatea JUCĂTOR fiind întreruptă înseamnă că un jucător poate juca la o echipă, adică relaţia este opţională. Segmentul ce pleacă dinspre entitatea ECHIPĂ este continuă, deci la o echipă trebuie să joace jucători.

tutorial oracle

Figura I.1.4. Reprezentarea relaţiilor

Modul în care o linie se termină spre o entitate este important. Dacă se termină printr-o linie simplă, înseamnă că o instanţă şi numai una a acestei entităţi este în relaţie cu o instanţă a celeilalte entităţi. În exemplul anterior, linia de la JUCATOR la ECHIPĂ se termină în partea dinspre ECHIPĂ cu o linie simplă, deci un jucător joacă la o echipa şi numai una.

Dacă linia se termină cu trei linii (picior de cioară)  înseamnă că mai multe instanţe ale entităţii pot corespunde unei instanţe a celeilalte entităţi. În exemplul anterior linia de la ECHIPĂ la JUCĂTOR se termină cu piciorul de cioară, înseamnă că unei instanţe a entităţii ECHIPĂ îi corespund mai multe instanţe ale entităţii JUCĂTOR, adică o echipă are unul sau mai mulţi jucători.

Caracteristica relaţiei

Valoare

Mod de reprezentare

Numele relaţiei

un verb

se scrie deasupra relaţiei

Opţionalitatea

relaţie obligatorie

(TREBUIE)

linie continuătutorial oracle

relaţie opţională

(POATE)

linie întreruptătutorial oracle

Cardinalitatea

una şi numai una

linie simplă              tutorial oracle

una sau mai multe

picior de cioarătutorial oracle

Tipuri şi subtipuri

În lumea reală obiectele sunt deobicei clasificate. Astfel vorbim despre animale vertebrate şi nevertebrate, despre licee teoretice, colegii, grupuri şcolare etc. E normal ca în modelarea bazelor de date să putem modela şi astfel de clasificări.

Un subtip sau o subentitate este o clasificare a unei entităţi care are caracteristici comune cu entitatea generală, precum atribute şi relaţii. Subtipurile se reprezintă în cadrul hărţii relaţiilor ca entităţi în interiorul altei entităţi. Atributele şi relaţiile comune tuturor subtipurilor se vor reprezenta la nivelul supertipului, sau superentităţii. Atributele şi relaţiile supertipului vor fi moştenite de către subtipuri.

Un subtip poate avea la rândul său alte subtipuri incluse.

tutorial oracle

Figura I.4.1. Folosirea subtipurilor şi supertipurilor

Subtipurile trebuie să respecte două reguli importante:

-     trebuie să acopere toate cazurile posibile de instanţe ale supertipului, cu alte cuvinte, orice instanţă a supertipului trebuie să aparţină unui subtip. De multe ori ERD-urile includ un subtip "ALTUL" pentru a acoperi toate situaţiile, şi pentru a permite viitoare dezvoltări ale modelului.

subtipurile trebuie să se excludă reciproc. Această regulă se traduce pe exemplul de mai sus în faptul că un angajat nu poate fi, de exemplu, şi manager şi secretară în acelaşi 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 relaţii

 

Variantele de relaţii ce pot exista între două entităţi sunt prezentate mai jos:

-       relaţii one-to-one – acest tip de relaţie este destul de rar întâlnit. Uneori astfel de relaţii pot fi modelate transformând una dintre entităţi în atribut al celeilalte entităţi.

-  tutorial oracle

Figura I.1.5. Relaţii one-to-one

 

-       relaţii one-to-many – sunt cele mai întâlnite tipuri de relaţii, însă şi aici cazurile c şi d prezentate în figura I.1.6 sunt mai puţin uzuale.

Să facem câteva observaţii pe marginea exemplelor din figura I.1.6. Cazul a este foarte des întâlnit. La cazul b, am ales o relaţie opţională dinspre POEZIE spre POET deoarece poate fi vorba de o poezie populară şi în acest caz nu există un poet cunoscut. La cazul c, am considerat că o formaţie nu poate exista fără a avea cel puţin un membru, însă un artist poate avea o carieră solo, deci nu face parte din nici o formaţie.  Varianta d modelează o colecţie de filme memorate pe CD-uri. Pentru afacerea considerată, un CD conţine obligatoriu un film, dar unul singur, însă un film poate să nu încapă pe un singur CD de aceea el este poate fi memorat pe unul sau mai multe CD-uri.

 

tutorial oracle

Figura I.1.6. Relaţii one-to-many

-       relaţii many-to-many – aceste tipuri de relaţii apar în prima fază a proiectării bazei de date, însă ele trebuie să fie ulterior eliminate. Figura I.1.7 prezintă câteva exemple de relaţii many-to-many. La punctul b am considerat că un curs poate apărea pe oferta de cursuri a unei facultăţi, însă poate să nu fie aleasă de nici un student de aceea un curs poate fi urmat de unul sau mai mulţi studenţi. Invers, este posibil ca un student să fi terminat studiile şi să se pregătească pentru susţinerea examenului de licenţă şi de aceea el nu mai frecventează nici un curs. La punctul c, un profesor angajat al unei şcoli trebuie să predea cel puţin o disciplină. Iar o disciplină din planul de învăţământ trebuie să fie predată de cel puţin un profesor.

tutorial oracle

Figura I.1.7. Relaţii many-to-many

Transferabilitate

Spunem că o relaţie este nontransferabilă dacă o asociaţie între două instanţe ale celor două entităţi, odată stabilită, nu mai poate fi modificată. Nontransferabilitatea unei relaţii se reduce la faptul că valorile cheii străine corespunzătoare relaţiei respective nu pot fi modificate.Condiţia de nontransferabilitate a unei relaţii este asigurată prin program. De aceea trebuie să documentăm această restricţie.În ERD o relaţie nontransferabilă se notează cu un romb pe linia corespunzătoare relaţiei, înspre entitatea a cărei cheie străină nu este permis să o modificăm (adică în partea cu many a unei relaţii one-to-many).

În figura I.4.5 este dat un exemplu de relaţie nontransferabilă. Este vorba despre notele date elevilor. Este normal ca o notă dată unui elev să nu poată fi apoi transferată unui alt elev.

tutorial oracle

Figura I.4.5. Relaţii nontransferabile

tutorial oracle Rezolvarea relaţiilor many-to-many

După cum am precizat mai devreme relaţiile many-to-many pot apărea într-o primă fază a proiectării bazei de date însă ele nu au voie să apară în schema finală. Să considerăm relaţia din figura I.1.14 dintre entităţile STUDENT şi CURS. Se ştie că orice curs se termină în general cu un examen. Unde vom memora nota studentului la fiecare examen?

 

Figura I.1.14

Dacă încercăm să introducem atributul NOTA la entitatea STUDENT, nu vom şti cărei materii corespunde acea notă, întrucât unei instanţe a entutăţii student îi corespund mai multe instanţe ale entităţii CURS. Invers dacă încercăm să memorăm nota în cadrul entităţii CURS, nu vom ştii cărui student îi aparţine acea notă.

Rezolvarea unei relaţii many-to-many constă introducerea unei noi entităţi numită entitate de intersecţie, pe care o legăm de entităţile originale prin câte o relaţie one-to-many.

Paşii în rezolvarea unei relaţii many-to-many sunt următorii:

1)   se găseşte entitatea de intersecţie, pentru exemplul nostru vom introduce entitate INSCRIERE.

2)      crearea noilor relaţii

-        opţionalitatea: relaţiile care pleacă din entitatea de intersecţie sunt întotdeauna obligatorii în această parte. În partea dinspre entităţile originale, relaţiile vor păstra opţionalitatea relaţiilor iniţiale.

-        cardinalitatea: ambele relaţii sunt de tip one-to-many, iar partea cu many va fi întotdeauna înspre entitatea de intersecţie.

-        numele noilor relaţii

3)      adăugarea de atribute în cadrul entităţii de intersecţie, dacă acestea există. În exemplul nostru ne poate interesa de exemplu data la care s-a înscris un student la un curs, data la care a finalizat cursul precum şi nota obţinută la sfârşitul cursului.

4)      stabilirea identificatorului unic pentru entitatea de intersecţie: dacă entitatea de intersecţie nu are un identificator unic propriu, atunci acesta se poate forma din identificatorii unici ai entităţilor iniţiale la care putem adăuga atribute ale entităţii de intersecţie.

În exemplul nostru, identificatorul unic al entităţii de intersecţie este format din id-ul studentului, id-ul cursului şi data înscrierii la curs.

5)      Faptul că identificatorul  unic al unei entităţi preia identificatorul unic din altă entitate cu care este legată este reprezentat grafic prin bararea relaţiei respective, înspre entitatea care preia UID-ul celeilalte entităţi.

tutorial oracle

 

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.