Tutoriale ORACLE - Relații între entități

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

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.

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.

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.

- 

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.

 

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.

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.

Figura I.4.5. Relații nontransferabile

 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.

 

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.