2
MODELUL ENTITATE-LEGATURA
Objective
sa arate de ce este necesara о abordare $tiintifica in proiectarea bazelor de date $i sa familiarizeze cititorul cu principalele anomalii care pot aparea in lipsa acestei abordari;
♦	sa prezinte notiunea de model de date, ca formalism pentru descrierea datelor, a legaturilor dintre ele $i a operatiilor de manipulare a acestora;
♦	sa listeze principalele etape ale procesului de proiectare a unei baze de date: analiza cerintelor, proiectarea la nivel conceptual, proiectarea la nivel fizic, respectiv proiectarea aplicatiilor;
♦	sa introduca principalele elemente ale modelului Entitate-Legatura, ca instrument principal de modelare a datelor in bazele de date relationale;
♦	sa evidentieze faptul ca exista diverse optiuni de modelare a datelor $i sa ofere recomandari privind alegerea celei mai potrivite astfel de optiuni;
♦	sa sublinieze faptul ca proiectarea unei baze de date este atit §tiinta, cit $i arta, modelarea adecvata a unui segment din lumea reala depinzind, intr-o buna masura, de maiestria cu care designer-ul surprinde legaturile care exista intre datele segmentului respectiv.
2 MODELUL ENTITATE-LEGATURA
Continut
I
2.1	Nevoia de proiectare ^tiintifica a bazelor de date.......................2
2.2	Proiectarea BD $i modelul EL.............................................5
2.3	Elementele modelului EL..................................................9
2.4	Exemple de folosire a MEL...............................................24
2.5	Optiuni privind modelarea BD............................................27
2.6	Constringeri asupra datelor.............................................29
Sumar.......................................................................30
Exercitii...................................................................31
J
2.1	Nevoia de proiectare stiintifica a bazelor de date
Astazi, din ce in ce mai multe organizatii, institutii, firme sau companii i$i fundamenteaza deciziile $i i$i desfa^oara activitatile zilnice pe baza informatiilor extrase din bazele lor de date. Pentru a fi cu adevarat folositoare, datele existente intr-o baza de date trebuie sa fie de actualitate, complete, precise $i la obiect. tn plus, ele trebuie sa fie organizate astfel incit sa poata fi regasite la nevoie, cu u^urinta, in formatul don't de catre utilizator. Programele de aplicatii au $i ele un rol important in acest sens, dar fara о buna proiectare a bazei de date, chiar $i cele mai bune programe nu pot evita probleme generate de datele imprecise sau inconsistente. Aceste probleme sint cauzate intotdeauna de proiectarea necorespunzatoare a bazei de date. О buna proiectare, in schimb, asigura functionalitatea $i performantele dorite pentru baza de date.
Pentru a putea intelege care sint problemele cauzate de efectele nedorite generate de о proiectare “dupa ureche” a bazelor de date, о sa construim un nou exemplu despre un e-magazin, sa-l numim aBCDstore, care vinde online card, CD-uri $i DVD-uri. Clientii acestei firme pot naviga prin catalogul de produse $i pot adresa comenzi prin Internet. Clientii vor plati pentru produsele comandate fie in momentul inregistrarii comenzii, fie ramburs la livrarea acestora. Indiferent de modul de plata, produsele corespunzatoare unei comenzi vor fi impachetate $i trimise spre livrare clientului care le-a solicitat, cit mai curind posibil. Daca stocul pentru unele dintre produsele comandate nu permite onorarea imediata a comenzii, atunci livrarea va fi aminata pina cind se vor obtine de la furnizori produsele in cauza. Astfel, orice comanda este onorata numai integral, ne-existind livrari partiale ale unei comenzi.
2.1 Nevoia de proiectare §tiintifica a bazelor de date 3
Catalogul de produse va stoca date specifice fiecarui produs. Pentru card, de exemplu, se pastreaza informatii despre ISBN, titlu, autor, editura, pret, anul publicarii $i un scurt rezumat al continutului cartii. Clientii aBCDstore se regasesc, de asemenea, in baza de date a firmei, despre ei pastrindu-se informatii referitoare la nume, adresa, telefon $i alte date personale. Pentru a putea deveni client fidel al firmei $i a beneficia de avantajele acestei fidelitati, oricine poate sa se inregistreze in baza de date prin deschiderea unui cont de acces caracterizat de un nume $i о parola. Fiecare astfel de client va fi identificat in baza de date printr-un cod de client unic, generat de catre software-ul bazei de date.
tn continuare, vom construi scenarii exemplificatoare privind diversele situatii la care baza de date a magazinului nostru virtual trebuie sa faca fata. О sa incepem prin a ne gindi care ar fi cea mai buna alegere pentru numarul de client, care ar trebuie sa identifice unic fiecare persoana inscrisa in grupul clientilor fideli. Am putea sa incercam sa construim acest numar pe baza numarului de telefon mobil al unei persoane, dar a$a dupa cum $tim, de multe ori, unele persoane au mai multe numere de telefon proprii, iar altele nu au telefon mobil, deci aceasta optiune nu pare a fi cea mai buna.
О alta solutie ar putea fi folosirea CNP-ului, dar sa ne gindim ca magazinul nostru poate avea $i clienti de peste hotare, pentru care nu avem un astfel de identificator. Se pare ca cea mai buna rezolvare este oferita chiar de baza de date insa$i, care poate genera un numar de ordine seriala, unic pentru fiecare client fidel in parte.
Tn baza de date trebuie sa existe desigur $i о tabela cu date despre produsele comercializate, iar schema acestei tabele, in sensul mdelului relational, ar putea arata a$a:
Produse(denumire, titlu, autor, proprietar, pret, anul realizarii, nume_furnizor, adresa_furnizor)
Pentru о carte, proprietarul va fi editura care a publicat cartea, iar furnizorul va fi libraria care о ofera spre vinzare. La о simpla privire aruncata acestei prime scheme pentru tabela Produse observam un lucru esential: in aceasta nu poate fi stocat ISBN-ul pentru carti ceea ce, pe termen lung, poate genera probleme pentru identificarea in mod unic a cartilor $i chiar a produselor, de orice fel ar fi ele. Tn bazele de date este esential ca fiecare obiect stocat sa poata fi identificat Tn mod unic pentru a se evita confuziile. Astfel schema tabelei de mai sus trebuie sa fie completata cu un cimp pentru codul produsului, cod care Tn cazul cartilor va fi ISBN-ul. Pentru celelalte produse, acest cod va trebui generat de catre baza de date, pentru a se putea asigura unicitatea lui.
Schema de mai sus prezinta $i alte capcane care nu pot fi sesizate de la prima vedere - sa ne gTndim la faptul ca, pentru fiecare produs din baza de date, se stocheaza $i informatii despre furnizorul sau: numele $i adresa. Acest lucru
4 MODELUL ENTITATE-LEGATURA
conduce la repetarea datelor despre un furnizor anume, pentru fiecare produs care provine de la furnizorul respectiv, ceea ce duce la redundante nedorite in baza de date. Redundanta datelor are mai multe consecinte neplacute, unele fiind chiar dezastruoase pentru о functionare normala a bazei de date.
Prima dintre acestea este consumul inutil de spatiu pe disc. Pentru о baza de date de man dimensiuni acest lucru va duce in mod sigur la scaderea performantelor prin faptul ca datele vor fi accesate mai greu, datorita stocarii lor pe mai multe volume fizice de date. Trebuie mentionat totu$i ca sint situatii in care redundanta datelor este acceptata sau chiar necesara, fie din motive tehnice (de exemplu, pentru a create eficienta unor raspunsuri la interogari), fie din motive economice (pentru a fi evitate situatii de pierdere a unor date esentiale pentru functionarea unei organizatii).
Redundanta datelor are $i alte consecinte mai putin evidente. Ce se va intimpla cu baza de date a firmei aBCDstore daca, de exemplu, adresa unui furnizor va fi modificata? Un raspuns simplist ar fi ca se vor modifica toate liniile din tabela pentru produsele provenind de la furnizorul respectiv. Desigur ca aceasta varianta nu este recomandata datorita numarului mare de modificari care trebuie facute. tn plus, daca in tabela exista intrari in care numele furnizorului este sen's gre$it dintr-o eroare de tastare, acesta nu va fi regasit u$or pentru a putea fi modificat. Aceasta problema este cunoscuta sub numele de anomalie de actualizare $i trebuie evitata. О situatie similara apare daca este inserat un produs nou, iar furnizorul sau are о alta adresa decit cea stocata anterior in baza de date - acest lucru poate fi cauzat fie de deschiderea unui nou sediu pentru furnizorul respectiv, fie de mutarea acestuia intr-o alta locatie. Dupa oricare dintre aceaste modificari, continutul bazei de date nu va mai fi consistent, deoarece unui $i acela^i furnizor va fi asociat, in mod neadeevat, cind cu о adresa, cind cu cealalta.
Sa ne gindim acum ce se intimpla in situatia in care am dori sa inseram in tabela cu Produse un posibil furnizor nou, cu care sa incepem о colaborare, dar inca nu ne-am decis ce produse vom prelua de la furnizorul respectiv. Este evident ca, in forma actuala a tabelei de Produse, acest lucru nu este posbil. Aceasta situatie este о anomalie de inserare $i trebuie evitata.
Mai este о consecinta nedorita a redundantei datelor privind furnizorii, $i anume, raspunsul la intrebarea ce se va intimpla daca este $ters din tabela de produse, ultimul produs al unui anumit furnizor. Evident se va pierde $i adresa acestuia, ceea ce nu este recomandat, deoarece colaborarea cu furnizorul respectiv ar trebui sa poata fi continuata $i in aceasta situatie. Aceasta problema trebuie de asemenea evitata $i e cunoscuta sub numele de anomalie de §tergere.
Pentru tabela de produse din schema bazei de date a e-magazinului nostru, toate anomaliile de mai sus pot fi evitate cu u^urinta prin scindarea sa in doua tabele, una cu informatii despre produse $i cealalta cu informatii despre
2.2 Proiectarea BD §i modelul EL 5
furnizorii acestora. Dealtfel, pastrarea de informatii despre mai mult de о multime entitate intr-o tabela este contraindicat (Harrington, 2002).
Produse(cod_produs, denumire, titlu, autor, proprietar, pret, anul realizarii, cod_furnizor) Furnizori(cod_furnizor, nume_furnizor, adresa_furnizor)
Astfel, datele despre furnizori nu vor mai fi redundante $i orice modificare referitoare la adresa unui furnizor va fi operata, о singura data, in tabela Furnizori. $tergerea ultimului produs al unui furnizor nu va conduce $i la pierderea datelor despre furnizorul respectiv. Totu$i pentru о baza de date reala, in care tabelele sint foarte numeroase $i proiectarea se face in echipa, solutiile nu sint atit de u$or de gasit $i nu se pot face “la ochi”. Din fericire, teoria $i practica bazelor de date relationale a dezvoltat proceduri de rezolvare a anomaliilor sub forma tehnicii de normalizare a relatiilor. >
2.2	Proiectarea BD si modelul EL
О baza de date contine, uzual, atit datele propriu-zise, cit $i informatii despre legaturile dintre ele. Ideea centrala a unei baze de date este ca utilizatorul (uman sau program) nu trebuie sa se preocupe cu felul in care datele sint stocate fizic pe disc, ci cu rezolvarea cererilor proprii vizavi de informatiile din baza de date. De cele mai multe ori, acestea sint exprimate in termenii asocierilor dintre datele stocate in baza de date respective.
Conceptual, datele $i legaturile dintre acestea se reprezinta cu ajutorul unui model de date, care este un formalism matematic cu doua parti: о notatie pentru a descrie datele $i legaturile dintre ele, precum $i un set de operatii folosite pentru a manipula aceste date. Exista mai multe modele date care sint sau au fost folosite in bazele de date: ierarhic, retea, relational, functional, obiect $i datalog (un model bazat pe logica).
Desigur ca ne intrebam daca, printre atitea modele de date, exista vreunul care sa fie cel mai bun. Multitudinea de modele existente pare sa arate ca nu. Atunci cind ne propunem sa alegem un model de date pentru о aplicatie care va avea о baza de date suport, trebuie sa luam in considerare mai multe criterii referitoare la urmatoarele aspecte (Ullman, 1988):
□	scopul: majoritatea modelelor de date sint destinate pentru a fi folosite ca notatie pentru datele din baza de date $i, in egala masura, ca mod de exprimare a operatiilor din limbajul de manipulare a datelor (cu exceptia modelului Entitate-Legatura, despre care vom vorbi pe larg in aceasta sectiune, caruia li lipse^te partea de manipulare a datelor);
□	orientarea obiect sau valoare: modelele orientate valoare (modelul relational $i datalog) permit declarativitatea, aceasta avind un
6 MODELUL ENTITATE-LEGATURA
efect profund asupra felului de limbaje pe care acestea le suporta. Modelele non-declarative (procedurale), in schimb, necesita mai putine optimizari $i, de aceea, sistemele bazate pe aceste modele sint disponibile adesea cu ani de zile inaintea celor cu modele orientate valoare. Modelele ierarhic, retea $i obiect furnizeaza identitatea obiectelor $i ca urmare pot fi considerate ca fiind orientate pe obiecte. Chiar $i modelul Entitate-Legatura necesita posibilitatea identificarii obiectelor;
□	rezolvarea problemei redundantei: toate modelele de date ofera utilizatorului posibilitatea de a evita stocarea aceluia^i fapt de mai multe ori, deoarece nu numai ca aceste redundance risipesc spatiu, dar pot conduce la inconsistent datelor, dupa cum am vazut in sectiunea dedicata anomaliilor. Modelele orientate pe obiecte sint, in general, mai bune in rezolvarea acestei probleme, deoarece ele pot lucra cu о singura copie a unui obiect, referindu-se la ea din orice loc din baza de date, prin intermediul pointerilor;
□	reprezentarea legaturilor multi-multi: adesea, un sistem cu baza de date trebuie sa stocheze legaturi intre date, in care fiecare grup de elemente dintr-o multime este legat cu un grup de elemente din alta multime (de exemplu, legatura Frecventeaza dintre Studenti $i Cursuri). Problema este sa se proiecteze о structure de memorare care sa permita un raspuns eficient la interogari de forma: Ce cursuri frecventeaza un anumit student? sau Ce studenti merg la un curs dat?, iar aceasta nu este о problema u$oara. Fiecare model are propria modalitate de rezolvare a acestei probleme.
Mai exista un model, pe care l-am amintit succint aici, numit Modelul Entitate-Legatura (MEL), care este incomplet in termenii definitiei de mai sus, in sensul ca li lipse^te setul de operatii asupra datelor. Acest model se folose^te pentru descrierea bazei de date conceptuale, intr-un mod grafic, scopul sau fiind de a permite ca descrierea schemei conceptuale a unei baze de date (reprezentata cu ajutorul diagramei Entitate-Legatura) sa fie facuta fare a se acorda atentie proiectarii bazei de date fizice sau considerentelor de eficienta, a$a cum este de a^teptat, intr-o oarecare masura, in celelalte modele. Diagramele Entitate-Legatura (EL) vor fi ulterior transformate intr-o schema conceptuala, in termenii specific' ai modelului de date oferit de sistemul respectiv de gestiune a bazelor de date.
Procesul de proiectare a unei bazei de date include $ase etape, care sint prezentate in continuare (Ramakrishnan $i Gehrke, 2002):
1.	Analiza cerintelor - primul pas in proiectarea unei aplicatii cu baze de date consta in a intelege ce date vor fi stocate in baza de date, ce aplicatii vor gestiona aceste date $i care sint operatiile cel mai
2.2 Proiectarea BD §i modelul EL 7
des efectuate, deoarece acestea vor avea un impact semnificativ asupra performantelor viitoarei aplicatii. Pe scurt, este vorba despre ceea ce vor utilizatorii de la baza de date in cauza. De obicei, analiza cerintelor este un proces informal care implica discutii cu grupurile de utilizatori, studierea modului de operare curent din organizatia in care va fi folosita aplicatia $i a modului in care acesta se va schimba dupa introducerea acesteia, precum $i parcurgerea documentatiei referitoare la aplicatiile folosite curent, care fie vor fi inlocuite de noua baza de date, fie vor fi completate de aceasta. Exista mai multe metodologii ($i unelte suport automate) care se folosesc pentru organizarea $i prezentarea informatiilor culese in aceasta etapa;
2.	Proiectarea bazei de date conceptuale - informatiile adunate in faza de analiza sint folosite in continuare, pentru a dezvolta о descriere pe un nivel de abstractiune ridicat a bazei de date, alaturi de constnngerile valabile asupra acestor date. Scopul acestei etape este sa creeze о descriere simpla a datelor (care sa fie conforma cu felul in care utilizatorii $i dezvoltatorii percep datele), a proceselor in care acestea se regasesc, precum $i a actorilor care actioneaza asupra lor. Aceasta descriere va sta la baza unui dialog asupra viitoarei baze de date, atit intre specialist!’, cit $i cu ceilalti utilizatori ai bazei de date. Totu$i, proiectul initial trebuie sa fie sufficient de precis pentru a permite о translatare naturala intr-un model de date suportat de catre un SGBD comercial (modelul relational fiind cel mai folosit). Se pot folosi diverse modele semantice de date pentru a realiza aceasta descriere, dar cel mai folosit este modelul Entitate-Legatura. Cu ajutorul lui se construie^te о diagrama Entitate-Legatura, aceasta fiind о ilustrare grafica a descrierii bazei de date conceptuale;
3.	Proiectarea schemei conceptuale a bazei de date - proiectul bazei de date conceptuale urmeaza sa fie convertit in schema bazei de date, in termenii modelului de date folosit. Pentru sistemele relationale cu baze de date, este vorba despre transformarea diagramei Entitate-Legatura in schema conceptuala a bazei de date relationale. Totu$i, aceasta diagrama este doar о descriere aproximativa a datelor, care se contruie^te in urma unei evaluari subjective a informatiilor colectate in prima etapa;
4.	Rafinarea schemei bazei de date - о analiza mai atenta a descrierii obtinute in etapa anterioara poate sa identifice potentiate anomalii, care pot fi eliminate prin rafinarea (imbunatatirea) acestei scheme. Aceasta rafinare, spre deosebire de etapele anterioare, care sint in
8 MODELUL ENTITATE-LEGATURA
principal subjective, este obiectul unei teorii puternice $i elegante: normalizarea relatiilor;
5.	Proiectarea bazei de date fizice - dupa ce s-a sintetizat cea mai buna schema posibila pentru baza de date, trebuie luate in considerare $i diverse criterii de performanta, alaturi de proiectarea schemei fizice a bazei de date. Se va estima efortul (workload) maxim la care baza de date va trebui sa faca fata in conditii normale de functionare. Daca este necesar, schema bazei de date va fi rafinata in continuare pentru a permite atingerea unor parametri de performanta doriti. Pentru a mic^ora timpul de acces la date $i, implicit, timpul de raspuns la interogari, se vor construi indeed asupra unor tabele, iar altele vor fi supuse unui proces de clustering (stocarea in zone apropiate de disc a datelor care sint corelate de interogarile cel mai des intilnite, cu scopul de a reduce numarul de accese la disc necesare pentru a rezolva interogarile respective) sau de partitionare (implica “spargerea” tabelelor mari in tabele mai mici, astfel incit SGBD-ul sa nu fie nevoit sa incarce о cantitate foarte mare de date la un moment dat) etc.
6.	Proiectarea aplicatiilor §i realizarea securitatii - orice project software, care implica $i un SGBD, trebuie sa considere aspecte specifice aplicatiei in cauza, dincolo de cele legate de baza de date insa$i. Exista metodologii integrate de proiectare $i dezvoltare a aplicatiilor software, cum ar fi UML (Unified Modeling Language), care pot asista dezvoltatorul pe parcursul acestui proces, pe parcursul caruia se vor identifica actorii (utilizatori, grupuri de utilizatori $i compartimente) $i procesele implicate in aplicatie. tn continuare, se descriu rolurile pentru fiecare actor, din fiecare proces, care va avea loc in viitoarea aplicatie. Pentru fiecare astfel de rol, trebuie identificate partile bazei de date care trebuie sa fie accesibile, respectiv ascunse, urmind sa fie luate masuri pentru a asigura respectarea unor reguli de acces. SGBD-urile ofera, de obicei, mecanisme de suport in acest sens.
Trebuie remarcat ca desfa^urarea celor $ase etape de mai sus nu este lineara, ci iterativa, in sensul ca aceste etape se vor intretese $i se vor repeta pina cind se obtine calitatea dorita pentru proiectul viitoarei baze de date (acest proces poate fi considerat о etapa in sine, care poarta numele de optimizarea bazei de date - database tuning). Proiectarea aplicatiei este urmata de implementarea sa intr-un limbaj de nivel inalt, care permite folosirea unui SGBD pentru accesul la date.
2.3 Elementele modelului EL 9
2.3 Elementele modelului EL
A$a dupa cum am vazut mai sus, modelul Entitate-Legatura este un limbaj pentru descrierea bazei de date conceptuale, intr-o maniera independents de modelul de date furnizat de SGBD-ul folosit in dezvoltarea aplicatiei respective. Modelul permite descrierea datelor corespunzatoare unui sistem din lumea reala in termenii entitatilor $i a legaturilor dintre ele, acestea fiind elementele sale conceptuale principale. El furnizeaza instrumente care permit trecerea de la о descriere informala a ceea ce vor utilizatorii, la о descriere mai precisa care poate fi implementata folosind un sistem de gestiune a bazelor de date.
Modelul Entitate-Legatura a fost introdus de catre Peter Chen in articolul The Entity Relationship Model - Toward a Unified View of Data, care este unul dintre cele mai citate articole din domeniul $tiintei Calculatoarelor (Chen, 1976). Acest model serve^te $i ca fundament al metodologiilor de analiza $i proiectare orientate pe obiecte $i web semantic. De asemenea, limbajul de modelare UML i$i are radacinile in modelul Entitate-Legatura.
О entitate este „ceva” despre care stocam date (cu scopul evident de a regasi aceste date la nevoie). Un produs este о entitate. La fel un furnizor. Tot entitati sint un student, un curs, sau о sala de curs. Cu toate ca entitatile nu sint greu de gasit in segmentele lumii reale modelate, notiunea de entitate este greu de definit formal. Termenul de entitate sfideaza notiunea de definitie formala tot atit cit о fac $i notiunea de punct $i linie in geometrie, care sint definite numai implicit, prin axiomele care arata proprietatile lor.
Pentru universul bazelor de date este suficient sa spunem ca о entitate este un lucru care exista in lumea reala $i care se distinge de celelalte (Ullman, 1988). Fiecare persoana sau automobil este о entitate, dar nu putem privi ca entitate fiecare albina decit daca exista о cale de a distinge о albina de alta, de exemplu prin lipirea de numere pe spatele lor © Notiunea de distingere a entitatilor este foarte apropiata de cea de identitate a obiectelor, de aceea modelul Entitate-Legatura este privit, in general, ca un model orientat pe obiecte.
Este evident ca este necesar sa putem identifica (distinge) fiecare entitate in parte, pentru a fi siguri ca, la nevoie, vom regasi exact entitatea sau entitatile care ne intereseaza la un moment dat. Pentru a putea face acest lucru vom folosi fie un atribut, fie un grup de atribute, pe post de identificator pentru fiecare entitate in parte. Unele entitati au identificatori intrinseci cum ar fi ISBN-ul unei carti, CNP-ul unei persoane, numarul unei facturi sau chitante etc.
tn multe situatii este util sa luam in considerare о colectie de entitati similare, о astfel de colectie fiind cunoscuta sub numele de multime entitate
10 MODELUL ENTITATE-LEGATURA
(entity set). Exemple de multimi entitate sint toti studentii, toate persoanele, toate salite de curs etc. Sa observam ca termenul “similare” nu e precis definit $i ca se poate stabili un numar infinit de proprietati prin care sa se defineasca о multime entitate. Din acest motiv, un pas cheie in proiectarea unei baze de date este alegerea multimilor entitate.
Similaritatea va fi stabilita pe baza unor caracteristici comune ale entitatilor, numite atribute, care sint specifice fiecarei multimi entitate in parte. Selectia atributelor relevante pentru multimile entitate este un alt pas critic in proiectarea schemei bazei de date conceptuale. Se poate observa ca multimile entitate sint asemanatoare claselor de obiecte, iar entitatile corespund obiectelor din dezvoltarea orientata pe obiecte a programelor. Diferenta consta in faptul ca modelul Entitate-Legatura prive^te aspectele statice ale datelor $i nu incorporeaza $i operatiile asupra acestora.
Atribute §i chei. Entitatile au proprietati particular (atributele) care asociaza cu fiecare entitate dintr-o multime entitate о valoare dintr-un domeniu de valori posibile, specific atributului respectiv. Un SGBD impune respectarea unui anumit domeniu pentru fiecare atribut prin intermediul unei constnngeri de domeniu. Ori de cite ori о valoare pentru un atribut urmeaza sa fie stocata in baza de date, SGBD-ul verifica ca ea face parte din domeniul de valori pentru atributul respectiv.
Diagramele uzuale folosite pentru a reprezenta grafic elementele modelului Entitate-Legatura, nu includ $i domeniile ca atare, acestea fiind stocate intr-un document asociat, numit dictionar al datelor, care contine metadatele care descriu datele din baza de date. Versiunea Chen pentru diagramele EL permite reprezentarea domeniilor atributelor direct pe diagrama, dupa cum se va vedea in sectiunea care descrie aceste diagrame.
De exemplu, pentru multimea entitate Studenti(nr_matricol, nume, prenume, grupa, adresa, telefon, virsta, media_g) atributele pot avea urmatoarele domenii: nr_matricol poate fi limitat la un numar intreg pozitiv intre 1 $i о limita superioara adecvata numarului de studenti, numele $i prenumele pot avea ca valori §iruri de maxim 100 de caractere, grupa poate fi de asemenea de tip $ir de caractere, virsta poate fi un intreg pozitiv intre 18 $i 100 de ani, media_g va avea valori intre 1 $i 10 etc.
Teoretic, domeniile pentru atribute pot fi alese independent de SGBD-ul pe care urmeaza sa se faca instalarea, dar din punct de vedere practic trebuie ca domeniile alese sa se regaseasca printre cele suportate de catre SGBD-ul in cauza. Majoritatea SGBD-urilor comerciale relationale care folosesc SQL ca limbaj de interogare, ofera urmatoarele tipuri pentru coloanele tabelelor care reprezinta relatiile din baza de date: CHAR ($ir de caractere de lungime fixa, uzual avind maxim 256 caractere), VARCHAR ($ir de caractere de lungime variabila, uzual avind maxim 256 caractere), INT (numar intreg a carui marime depinde de sistemul de operare folosit),
2.3 Elementele modelului EL 11
DECIMAL sau NUMERIC (numere reale, pentru care se precizeaza numarul total de cifre, respectiv numarul de cifre al partii zecimale - de exemplu, un numar in formatul XX.XX ar putea avea domeniul DECIMAL (5,2)), DATE (data calendaristica), TIME (ora), DATETIME (data, ora) $i BOOLEAN (valoare booleana). tn plus, fata de aceste domenii, SGBD-urile comerciale ale zilelor noastre ofera $i un tip numit BLOB (Binary Large Object), care poate stoca orice obiect reprezentat binar, cum ar fi о imagine sau un clip video.
Alegerea domeniilor pentru atribute este foarte importanta, avind о influenta directa in modelarea cit mai naturala $i precisa a segmentului din lumea reala pentru care se construie^te aplicatia de baza de date. De exemplu, daca se reprezinta datele calendaristice ca §iruri de caractere, atunci este posibil sa se obtina rezultate eronate in cazul unor comparatii (de exemplu, data 11-12-2009 va fi considerata calendaristic inaintea datei de 12-12-2008, deoarece lexicografic prima data о precede pe cea de a doua). Prin reprezentarea acestora cu ajutorul tipului DATE, SGBD-ul va ordona corect cele doua date. Mai mult, acesta va putea executa diverse operatii asupra lor, cum ar fi gasirea intervalului dintre doua date sau calcularea unei date care difera de о alta printr-un numar dat de zile.
Un atribut sau un set de atribute minimal, ale caror valori identifica unic fiecare entitate dintr-o multime entitate, se nume^te cheie pentru acea multime entitate. Pot exista mai multe astfel de grupuri de atribute, numite chei candidat, dintre care se alege una, care este desemnata cheie primara. Aceasta va fi folosita de catre SGBD pentru identificarea entitatilor aflate la un moment dat in baza de date, tn principiu, fiecare multime entitate are о cheie, de vreme ce am piecat de la premisa ca fiecare entitate se distinge de celelalte. Cazuri limita sint cele in care am forma cheia din toate atributele entitatilor apartinind multimii entitate respective sau in care cheia este un numar de ordine seriala asociat fiecarei entitati, care este generat de catre SGBD-ul insu$i. Un atribut care apartine unei chei se nume^te atribut prim.
Atribute multivaloare §i grupuri repetitive de atribute. De vreme ce pentru implementarea bazei de date о sa folosim modelul relational, atributele care descriu entitatile trebuie sa aiba valori singulare, atomice (single-value). Aceasta inseamna ca, pentru о instanta data a unei entitati, fiecare atribut poate avea о singura valoare. Atributele multivaloare trebuie evitate deoarece ele pot cauza probleme privind semnificatia datelor din baza de date, incetinirea cautarilor sau limitarea in mod inutil a cantitatii datelor care pot fi stocate in baza de date. Cautarea la nivelul atributelor multivaloare se poate face doar prin scanarea secventiala a valorii fiecarui atribut, ceea ce este extrem de inefficient, deoarece cautarea secventiala este cel mai lent tip de cautare posibila.
Sa ne reamintim ca printre informatiile pastrate in baza de date a unei organizatii, se stocheaza $i date personale despre angajati. Pentru fiecare
12 MODELUL ENTITATE-LEGATURA
angajat, pe linga multe date specifice organizatiei, se pot pastra $i date despre copii persoanei respective, care ar putea fi utile, de exemplu, pentru oferirea de cadouri acestora cu diverse ocazii. Se pune intrebarea cum sa reprezentam informatiile desre copii $i о prima optiune ar putea fi un atribut multivaloare, despre fiecare copii pastnndu-se numele $i data sa de na^tere.
Acest mod de reprezentare ridica problema felului in care se va face asocierea corecta intre fiecare nume $i data de na^tere corespunzatoare. Cel mai simplu raspuns ar fi ca asociem primul nume cu prima data de na^tere, al doilea nume cu a doua data de na^tere $.a.m.d. Dar, nu este disponibil nici-un mijloc pentru a asigura faptul ca exista cite о data de na^tere pentru fiecare nume $i nici ca fiecare data de na^tere este asociata cu un nume. tn plus, nu se poate garanta nici faptul ca о anumita ordine nume 1, data de na§tere 1, nume 2, data de na§tere 2 etc. va fi pastrata cu sfintenie. Se pune de asemenea intrebarea cit de multe valori ar trebuie sa poata fi stocate pentru un atribut multivaloare - de exemplu, daca se fixeaza numarul maxim de copii al unui angajat la 12, ce facem in situatia in care trebuie sa stocam mai mult de 12 copii?
О alta solutie a acestei probleme ar putea parea introducerea unor atribute sau grupuri de atribute care sa se repete pentru fiecare copii - de exemplu, pentru numele sau $i pentru data na^terii. $i in acest caz apar mai multe neajunsuri: nu $tim de cite ori sa repetam cele doua atribute, daca sint prea multe se iroseate spatiu pentru persoanele care nu au atiti copii, iar daca sint prea putine, in anumite cazuri vor fi insuficiente. tn plus, cautarea pentru un anumit copii va fi foarte greoaie, ea trebuie sa se faca in fiecare dintre coloanele care contin nume de copii.
Solutia potrivita pentru situatiile in care sint necesare atributele multivaloare este crearea unei multimi entitate separate pentru a stoca aceste atribute. Pentru exemplul de mai sus, se poate crea о multime entitate Copii care sa fie asociata cu multimea entitate Persoane printr-o legatura, reprezentata dupa cum vom vedea mai tirziu, prin intermediul cheii (marcii) angajatului respectiv, care va aparea pe fiecare linie din tabela Copii, care corespunde unui copii al persoanei in cauza. Un alt exemplu de situatie in care un atribut multivaloare ar fi necesar este daca dorim sa stocam mai multe numere de telefon pentru fiecare entitate apartimnd multimii entitate Studenti, care este stocata in baza de date UniBD. Pentru a modela aceasta situatie, se va crea о multime entitate Telefoane, care va contine numerele de telefon $i care va fi asociata cu fiecare student prin intermediul numarului sau matricol, care este $i cheie.
Instante. Atunci cind reprezentam entitatile in baza de date, de fapt stocam numai atributele acestora. Fiecare grup de atribute care descrie о singura entitate, reprezinta de fapt о instanta pentru entitatea respective. De exemplu, ca instante pentru entitatile Studenti (vezi capitolul I) avem
2.3 Elementele modelului EL 13
liniile din tabela respective, dupa cum urmeaza: (2350, Marin, Ana, 1234, xyz w, 535923, 18, 8.50), (2351, Popa, Ion, 1234, xz yw, 412456, 20, 7.25), (2352, Radu, Ina, 1234, z yx w, 324211, 19, 9.50), (2353, Toma, Dorin, 1235, xyzw, 232421, 22, 9.00).
Atunci cind stocam о instanta a unei entitati in baza de date, vrem ca SGBD-ul sa asigure faptul ca noua instanta are un identificator unic. Aceasta restrictie este un exemplu de constrfngere asupra bazei de date -numita unicitatea cheii - $i este о regula la care datele trebuie sa adere. Dupa cum vom vedea, respectarea constringerilor asupra bazei de date asigura mentinerea consistentei $i acuratetii datelor stocatein aceasta.
lerarhiile isa au fost introduse pentru a permite mo^tenirea unor atribute intre doua multimi entitate. Se spune ca A isa B, care se cite^te “A isa B” (A este un B), daca multimea entitate В este о generalizare a multimii entitate A (ceea ce este echivalent cu A este un caz particular de B). Astfel multimea entitate A poate mo^teni atributele lui B, dar poate avea $i alte atribute in plus, care nu au sens pentru acei membri ai lui В care nu sint $i membri ai lui A. Tehnic vorbind, fiecare entitate a e A este legata cu exact о entitate b e B, astfel incit a $i b sint, de fapt, aceea^i entitate.
In exemplul de ierarhie isa alaturat se poate observa ca manager!! sint caracterizati, in plus fata de ceilalti angajati (care au ca atribute marca, departamentul, numele complet §i salariul), de un atribut care nu ar avea sens pentru angajatii care nu sint manager! §i anume indemnizatia.
Colectii de multimi entitate. Vezi materialul tiparit.
Legaturile (asocierile) sint conexiuni care au loc in contextul aplicatiei de dezvoltat, intre doua sau mai multe entitati. Se nume^te multime legatura о lista ordonata de multimi entitate. Fie Ei, E2, ..., En ni$te multimi entitate intre care exista 0 asociere, fie ea - se poate defini multimea legatura (instanta curenta a lui HQ ca fiind multimea {tk/tk=(ei, £2, en), cu ej e EJ.
14 MODELUL ENTITATE-LEGATURA
Se spune despre entitatile e,-, cu i=1, n ca stau in asocierea iar vectorul (ei, ег, en) se nume^te tuplu. Trebuie mentionat ca о multime entitate poate aparea de mai multe ori in aceasta lista, dupa cum se poate vedea $i in unele dintre exemplele urmatoare.
I I wST | Exemplu I 2>2	Exemple de multimi legatura Preda(Titulari, Cursuri)={(marca, cod_curs)/ unde marca este numarul unic de identificare al titularului care sustine cursul cod_curs} Casato/7t_cu(Persoane, Persoane)={(pl,p2)/persoana pl este casatorita cu persoana p2} /Wama_a(Persoane, Persoane)={(pl,p2)/persoana pl este mama lui p2} Aceasta legatura mai poate fi reprezentata §1 ca о ierarhie isa, de forma Marne isa Persoane, daca se dore§te memorarea anumitor caracteristici ale mamelor, care nu sint necesare pentru multimea entitate Persoane. In acest caz asocierea de mai sus devine Mama_a=(Mame, Persoane).
О instanta unei multimi legatura este un set de legaturi. Intuitiv, о instanta poate fi gindita ca un instantaneu al unei multimi legatura la un anumit moment de timp. De exemplu, pentru legatura Preda dintre Titulari $i Cursuri din baza de date UniBD, instanta curenta contine tuplurile: (123, uni1234312), (123, uni2351345), §i (125, uni4235211).
Atunci cind о multime entitate apare de mai multe ori in cadrul unei legaturi, atunci ea are roluri diferite pentru fiecare dintre aparitii - de exemplu, pentru legatura Casatorit_cu, multimea entitate Persoane are rolul de sot intr-unul dintre capetele legaturii $i rolul de sotie in celalalt capat. Numele pentru fiecare entitate in parte se vor forma din numele rolului concatenat cu numele atributului - de exemplu sot_CNP, sotie_nume $.a.m.d.
Atribute cheie fmprumutate - sint situatii in care este necesar sa formam cheia pentru о multime entitate A cu ajutorul atributelor unei alte multimi entitate B, cu care multimea entitate A este conectata printr-o legatura diferita de ierarhia isa. Este necesar doar ca pentru fiecare a e Asa existe un unic b e В cu care a sa fie legata, dupa cum se poate vedea din exemplul 2.3. Multimile entitate Comenzi, respectiv Persoane din legaturile din acest exemplu ilustreaza notiunea de multime entitate incomplete (weak entity set), care nu poate fi identificata in baza de date decit prin intermediul legaturii pe care о are cu о alta multime entitate. О astfel de multime entitate i$i formeaza cheia cu ajutorul atributelor cheie imprumutate de la entitatea cu care este legata (numita entitate suport sau entitate proprietor identificatoare), la care se adauga unele dintre atributele proprii.
2.3 Elementele modelului EL 15
Identificarea entitatilor incomplete $i a legaturilor (numite legaturi suport sau legaturi de identificare) care sint obligatorii pentru ca ele sa poata fi stocate in baza de date, este importanta pentru mentinerea consistentei $i integritatii bazei de date (Maier, 1983) (Batini et al., 1992). Sa ne imaginam ce ar insemna sa incercam sa contactam un client al aBCDstore, care este cetatean european $i pentru care $tim codul sau unic de identificare in cadrul tarii sale, dar nu $tim din ce tara provine ® Sau cum ar fi sa incercam sa trimitem о comanda unui client care nu poate fi identificat.
Exemple de legaturi suport pentru multimi entitate incomplete
Cetatean_a/(Persoane, Tari). Chela pentru о persoana va fi data de chela pentru tara de rezidenta §i chela care identified о persoana in cadrul tarii respective (de exemplu, Codul Numeric Personal).
P/aseaza(Clienti, Comenzi). О comanda nu are sens daca nu exista un client care sa о plaseze, iar chela pentru о comanda trebuie sa includa §i codul unic al clientului.
Diagramele Entitate-Legatura constituie un limbaj grafic pentru descrierea modelului Entitate-Legatura, fiind practic о extensie a modelului care permite reprezentarea grafica a elementelor acestuia. О diagrama EL completa reprezinta planul conceptual global al bazei de date (schema bazei de date). Principalele elemente cu care se construie^te о diagrama EL sint prezentate in continuarea acestei sectiuni.
J
	. multime entitate -		Multimile entitate se reprezinta cu ajutorul unor | dreptunghiuri in interiorul carora se serie numele | multimii entitate in cauza.
I—	m.e. incomplete	—	Entitatile incomplete se reprezinta uneori | folosind un dreptunghi dublu, in care se serie | numele multimii entitate (m.e.) respective.
			Atributele multimilor entitate sint reprezentate | cu ajutorul unor elipse in interiorul carora se serie | numele pentru fiecare atribut in parte. | Aceste elipse sint legate la dreptunghiurile care | reprezinta multimile entitate prin arce | neorientate. Atributele care fac parte din chei | sint marcate intr-un fel distinct, de obicei prin | sublinierea denumirii. Exceptie de la aceasta |
domeniu
16 MODELUL ENTITATE-LEGATURA
	regula face cazul in care о multime entitate cu un | singur atribut este identificata de atributul insu$i, | situatie in care multimea entitate respective va | lua numele atributului $i va aparea reprezentata | ca un cere, care va fi ata$at la toate legaturile in | care multimea entitate este implicate. Atributele | unei multimi entitate incomplete care participa | la cheia sa sint sublimate cu о linie intrerupta. | Este posibil ca domeniul de valori sa fie adaugat | sub caseta cu numele atributului.
|—	Multimile legatura sint reprezentate cu ajutorul | unor poligoane, in care se inscrie denumirea lor, | care au numarul de noduri egal cu numarul de | multimi entitate implicate in legatura $i care pot | fi legate la acestea prin arce orientate sau prin | arce ne-orientate. Ordinea multimilor entitate | este nerelevanta, cu exceptia cazului in care о | multime entitate apare de mai multe ori in lista.
	Multimile entitate incomplete se identifies prin | intermediul unei legaturi suport, care se | reprezinta cu un poligon dublu, in care se inscrie | numele asocierii respective.
2.3 Elementele modelului EL 17
Multimea entitate E este generalizarea multimilor entitate Ei, E2, En, daca:
*	Ejc E, pentru orice i=1, n
*	Ej n Ej=0, pentru orice i,j=1, n
x и Ej=E pentru orice i=1, n
lerahiile de generalizare sint reprezentate cu ajutorul unor hexagoane, in interiorul carora se precizeaza criteriul dupa care se face generalizarea. Multimile entitate care sint generalizate de catre 0 multime entitate pozitionata in partea superioara a hexagonului, sint reprezentate in partea sa inferioara, in dreptunghiuri unite cu sageti duble de acesta.
Daca ultimele doua conditii dintre cele trei de mai sus lipsesc, se spune ca ierahia este de incluziune. Ea se reprezinta cu ajutorul unui dreptunghi, care contine multimea entitate E, care include multimile entitate Ej, fiecare dintre ele fiind reprezentate tot cu dreptunghiuri.
tn ceea ce prive^te reprezentarea legaturilor, se constata ca este greu de citit in ambele sensuri numele din interiorul poligonului, care reprezinta legatura. Ca alternativa, numele legaturii nu mai apare in interiorul poligonului, ci apare atit linga una dintre entitatile asociate, cit $i linga cealalta, fiind adaptat corespunzator, dupa cum se poate vedea in exemplul alaturat.
Tn figurile care urmeaza sint prezentate exemple de folosire a diagramelor EL, precum $i diverse variante de modelare a unuia $i aceluia^i segment din lumea reala (a, b, c). Tn varianta a, multimea entitate Angajati, care are atributele marca (cheie), nume $i salariu, sta in asocierea Lucreaza_in cu multimea entitate Departamente, caracterizata de atributele nume (cheie), telefon $i locatie. Managerii de departament sint reprezentati ca 0 multime entitate separata, care are un singur atribut propriu, nume, care este $i cheie.
18 MODELUL ENTITATE-LEGATURA
Multimea entitate Manageri este asociata cu Departamente-le conduse prin intermediul asocierii Conduse_de.
tn varianta b, Manageri-i sint reprezentati prin numele lor, care devine pur $i simplu un atribut al Departamente-lor, iar in varianta c, Manageri-i se regasesc intr-o ierarhie isa sub multimea entitate Angajati. Aceasta ultima varianta de reprezentare, are avantajul mo^tenirii de catre manageri a tuturor atributelor specifice angajatilor, astfel ca, la nevoie, putem regasi cu u^urinta aceste informatii. Tn primele doua situatii, gasirea acestor informatii presupune realizarea unor cautari mai laborioase printre entitatile multimii entitate Angajati.
Fiecare dintre cele trei variante diferite de modelare a aceluia^i segment din lumea reala, poate sa fie mai potrivita pentru о anumita aplicatie de baza de date, in functie de semantica datelor reprezentate $i de operatiile efectuate cel mai frecvent asupra acestor date.
Daca este necesara pastrarea mai multor numere de telefon pentru fiecare departament, atunci se creaza о multime entitate separata pentru a stoca aceste atribute, fie ea Telefoane. Aceasta va fi asociata cu multimea entitate Departamente printr-o legatura, care va fi reprezentata prin intermediul numelui departamentului respectiv (care constituie cheia pentru Departamente) $i care va aparea pe fiecare linie din tabela Telefoane, care corespunde unui anumit departament.
La punctul d este ilustrata, partial, situatia din sectiunea 1.1 a acestui capitol, in care produsele gestionate de magazinul nostru online aBCDstore, reprezentate de multimea entitate Produse, erau caracterizate de mai multe atribute (cod_produs - cheie, denumire, titlu, autor, proprietar, pret, anul realizarii $i cod furnizor) $i stateau in asocierea Furnizate_de cu Furnizori-i, care erau descri^i de atributele cod_furnizor (cheie), nume_furnizor $i adresa_furnizor.
2.3 Elementele modelului EL 19
Figura 2.1 Exemple de diagrame EL (1)
20 MODELUL ENTITATE-LEGATURA
Se observa $i faptul ca о legatura poate avea atribute descriptive proprii, cum este cazul cu atributul “timp” pentru legatura Lucreazaja dintre Studenti $i Proiecte, care arata timpul pe care un student il aloca lucrului la un anumit proiect (e). $i legatura Lucreaza_in dintre Angajati $i Departamente, ar putea avea un atribut, $i anume timpul de cind un angajat lucreaza intr-un anumit departament. Totu$i, о legatura va fi identificata cu ajutorul entitatilor participante la ea, $i nu cu ajutorul atributelor ei descriptive. La punctul f se observa ca multimea entitate Persoane apare de doua ori in interiorul legaturii Parinte_al. Sint prezentate $i doua exemple de ierarhii, una de generalizare (g) $i una de incluziune (h).
g. ierarhie de generalizare
h. ierarhie de incluziune
Figura 2.2 Exemple de diagrame EL (2)
2.3 Elementele modelului EL 21
Caracteristici ale legaturilor
Gradul legaturii arata cite multimi entitate sint conectate intr-o anumita legatura. Dupa grad, legaturile pot fi unare, binare, ternare etc. dupa cum se poate vedea $i din exemplele din Figure 2.3 (a, b, respectiv c).
Tipul de apartenenta arata daca existenta unui capat al legaturii implica $i existenta celuilalt capat. Dupa tip, legaturile pot fi obligatorii (b, c) sau optionale (a), sensul fiind evident, dupa cum se vede $i in exemplele din Figure 2.3 - optionalitatea se marcheaza cu ajutorul unui cerculet pozitionat peste liniile care ilustreaza legaturile care sint optionale.
Conectivitatea unei legaturi arata cite entitati sint asociate prin intermediul legaturii respective, la fiecare capat al legaturii. Tntre doua multimi entitate, fie ele Ei $i E2, exista trei tipuri de legaturi, dupa conectivitate: unu-la-unu, multi-unu $i multi-multi.
Tntr-o legatura unu-la-unu, figurata in diagramele EL ca (1,1), pentru orice entitate din fiecare dintre cele doua multimi, exista cel mult 0 entitate asociata din cealalta multime (exista zero sau una). Un exemplu de legatura unu-la-unu este asocierea Conduse-de dintre Departamente $i Manageri, daca piecam de la presupunerea ca un departament poate avea cel mult un manager $i ca un manager poate conduce cel mult un departament. Acela^i lucru se poate spune $i despre legatura Casatorit-cu, dintre doua entitati Studenti, daca excludem casatoriile poligame. tn diagrama am reprezentat $i rolul multimii entitate la fiecare aparitie in cadrul legaturii (sot, sotie).
Pentru 0 asociere multi-unu, ilustrata cu (m,1), in diagrama EL, de la E1 la E2, 0 entitate din multimea entitate E2 este asociata cu zero, una sau mai multe entitati din E1, iar fiecare entitate din E1 este asociata cu cel mult 0 entitate din E2. tn acext context, trebuie sa mentionam $i faptul ca legaturile unu-la-unu sint cazuri particular de legaturi multi-unu, deci in orice situatie ulterioara in care ne vom referi la 0 legatura multi-unu, este subsumat $i cazul legaturilor unu-la-unu.
Ca exemplu se poate considera legatura Mama-a, care este unu-multi, pentru ca 0 persoana poate fi mama mai multor copii biologic', dar acedia pot avea 0 singura mama biologica. Un alt exemplu este constituit de legatura Plaseaza dintre Clienti $i Comenzi, din cadrul bazei de date a magazinului virtual aBCDstore, care are conectivitatea (1,m). Practic, multimea entitate Comenzi nu poate exista in baza de date daca nu se asociaza cu multimea entitate Clienti (nu ar avea sens sa existe 0 comanda care sa nu fie asociata cu un client). О entitate Clienti se poate asocia cu zero, una sau mai multe Comenzi, dar 0 entitate Comenzi se poate asocia cu 0 singura entitate Client.
tn cazul unei legaturi multi-multi, care se noteaza de obicei cu (m,m) in diagramele Entitate-Legatura, orice grup de entitati (zero, una sau mai multe) din prima multime poate fi asociat cu orice grup de entitati din a doua
22 MODELUL ENTITATE-LEGATURA
multime (zero, una sau mai multe). Legaturile Frecventeaza(Studenti, Cursuri), Lucreaza-/a(Studenti, Proiecte), Exporta(Tari, Produse) $i Furnizate-de (Produse, Furnizori) sint, toate, exemple de legaturi multi-multi.
tn figura urmatoare sint exemplificate $i aceste trei tipuri de conectivitati pentru asocieri (a, b, c). Conectivitatea mai poate fi marcata in diagramele EL, ca alternativa la notatia (n,n), fie prin ingro^area coltului poligonului corespunzator capatului “multi” al legaturii, fie prin reprezentarea sa cu doua sageti (in timp ce capatul unu- se reprezinta cu о singura sageata).
a. legatura unara, optionala, unu-la-unu
b. legatura binara, obligatorie, multi-unu
c. legatura ternara, obligatorie, multi-multi
Figure 2.3 Caracteristici ale legaturilor
2.3 Elementele modelului EL 23
tn ceea ce prive^te legaturile prezentate in figurile anterioare, legatura Conduse_de, dintre Departamente $i Manageri, poate fi declarata unu-la-unu, daca se presupune ca un departament este condus de catre un singur manager $i ca un manager poate conduce un singur departament. Este posibil sa existe manageri care nu conduc un departament anume, sau ca un departament sa nu aiba, temporar, manager. Legatura Lucreaza_m, dintre Angajati $i Departamente, poate fi considerata multi-unu de la Angajati la Departamente, daca fiecare angajat este asignat la cel mult un departament, fiind de asemenea posibil ca anumiti angajati, de exemplu, pre^edintele companiei, sa nu fie asignat unui departament anume.
Reprezentarea legaturilor multi-multi nu se poate face ca atare din mai multe motive. Primul tine de faptul ca modelul relational nu le poate gestiona direct, deoarece este limitat la legaturile de tip unu-la-unu, respectiv multi-unu. Ca urmare, legaturile multi-multi din diagramele EL trebuie inlocuite cu un set de legaturi multi-unu. Al doilea motiv este ceva mai subtil $i pentru a-l putea intelege mai u$or, vom reconsidera exemplul cu Studentii care Frecventeaza diverse Cursuri, informatii reprezentate in baza de date UniBD. Este firesc sa ne intrebam unde sa stocam situatia unui anumit student la un curs oarecare: prezenta, note discipline anterioare necesare, nota laborator, nota examen etc. Daca alegem sa stocam aceste informatii la multimea entitate Studenti, atunci nu vom $ti la care curs se refera ele. Invers, daca le stocam la multimea entitate Cursuri, nu vom $ti care este studentul in cauza. Se spune ca acest fel de date sint date de legatura (relationship data), date care se refera mai degraba la legatura dintre cele doua multimi entitate, decit la fiecare multime entitate in parte. Este deci necesara crearea unei multimi entitate artificiale, care sa preia aceste date de legatura, numita multime entitate de compozitie (compozita).
Pentru exemplul cu Studentii care Frecventeaza Cursuri-le, avem nevoie de о multime entitate care sa ne arate care este situatia unui anumit student la un curs dat. Sa numim aceasta multime entitate Situatie_Curs. Legatura dintre multimea entitate Studenti $i multimea entitate Situatie_Curs este о legatura unu-multi, deoarece un student va avea cite о situatie la fiecare curs pe care il frecventeaza. La fel $i legatura dintre multimea entitate Curs $i multimea entitate de compozitie, fiindca un curs va fi asociat cu cite о situatie pentru fiecare student care frecventeaza cursul respectiv. Multimea entitate Situatie_Curs va avea atributele: nr_matricol, cod_curs, nota laborator, nota examen, nota finala, numar prezente etc.
Reprezentarea entitatilor de compozitie, in anumite extensii ale diagramelor Entitate-Legatura clasice (Chen), se face prin inscrierea unui romb ca cel folosit pentru reprezentarea legaturilor binare, intr-un dreptunghi de reprezentare a entitatii, numele entitatii de compozitie scriindu-se in interiorul rombului.
24 MODELUL ENTITATE-LEGATURA
2.4	Exemple de folosire a MEL
tn continuare se vor prezenta exemple de proiectare a modelului Entitate-Legatura al unei baze de date, precum $i de reprezentare a acestuia cu ajutorul diagramelor Entitate-Legatura asociate. Sa reluam mai intii exemplul cu baza de date despre studentii unei universitati, numita UniBD, care frecventeaza diverse cursuri, acestea avind loc in anumite sali $i fiind predate de catre profesori titulari pentru disciplined respective.
Titularii de curs sint angajati ai universitatii respective $i sint asignati la diverse catedre. Salile de curs se gasesc la anumite locatii fizice, adica intr-un anumit corp de cladire, la un anumit etaj $i au un anumit numar. Catedrele $i facultatile sint conduse de catre manageri, numiti $efi de catedra, respectiv decani. Managerii sint $i ei la rindul lor angajati ai universitatii. Studentii sint inscri^i, fiecare, la о anumita facultate. Fiecare catedra este de asemenea arondata uneia dintre facultati.
Din aceasta scurta descriere a universului aplicatiei de baze de date reiese cu u^urinta о prima forma a viitoarei scheme a bazei de date, care va contine multimile entitate Studenti, Cursuri, Sali, Titulari, Angajati, Catedre, Locatii, Manageri $i Facultati. Tntre aceste multimi entitate exista diverse asocieri (intre paranteze sint precizate conectivitatile):
•	Studenti-i Frecventeaza Cursuri (m, m);
•	Studenti-i Lucreaza-la Proiecte (m, m);
•	Cursuri-le Au-loc-m Sali (m, 1);
•	Sali-le/Catedre-le sint Amplasate-m/Situate_m Locatii (1, 1);
•	Salile sint Asociate-la Catedre (m, 1);
•	Angajatii sint Asignati-la Catedre (m, 1);
•	Cursuri-le sint Predate-de Titulari (m, 1);
•	Proiecte-le sint Coordonate-de catre Titulari (m, 1);
•	Studenti-i sint lnscri$i-la Facultati (m, m);
•	Facultati-le sint Administrate-de Manageri (1, 1);
•	Catedrele sint Conduse-de Manageri (1, 1);
•	Facultatile Coordoneaza Catedre-le (1, m).
Avem $i doua ierarhii isa: Titulari-i de cursuri $i Managerii sint cazuri particulare de Angajati. Toate aceste multimi entitate $i legaturi sint reprezentate cu ajutorul unei diagrame EL in figurile urmatoare (2.4 $i 2.5). Fiecare multime entitate are atribute specifice, care pot fi de asemenea observate in diagrama. Din motive de spatiu, aceasta diagrama va fi prezentata pe parti, in doua pagini. Tot din aceste considerente, pentru unele dintre multimile entitate nu vor fi prezentatein diagrama toate atributele.
2.4 Exemple de folosire a MEL 47
Figura 2.4 Diagrama EL pentru UniBD - partea I
26 MODELUL ENTITATE-LEGATURA
Figura 2.5 Diagrama EL pentru UniBD - partea alia
Se observa ca au fost prezentate punctat acele zone din prima parte a diagramei, care au fost re-desenate $i in partea a doua a acesteia. De asemenea, in numele de entitati $i legaturi au fost folosite diacritice pentru ca citirea lor sa se faca mai u$or (conventie valabila $i in continuare). Desigur ca in baza de date pot exista $i alte multimi entitate, de exemplu referitoare la planurile de invatamint, la discipline, la programele analitice pentru acestea sau la colaboratorii in regim plata cu ora ai universitatii.
2.5 Op^iuni privind modelarea BD 27
2.5	Optiuni privind modelarea BD
tn multe privinte proiectarea bazelor de date este la fel de mult arta, pe cit este $tiinta. Ce este potrivit pentru о anumita baza de date, poate fi foarte nepotrivit pentru alta. Optiunile de modelare conceptuala alese in diverse situatii, nu pot fi gindite in termeni de corecte sau gre^ite, daca sint facute conform teoriei bazelor de date relationale $i celei mai bune practici in domeniu. Un design al bazei de date este bun, daca el reflecta in mod natural $i precis realitatea pe care о modeleaza.
De$i mai sint multe de invatat in ceea ce prive^te modelarea Entitate-Legatura a bazei de date, putem deja sa incercam sa articulam trasaturile definitorii ale unui proiect bun, sintetizind de asemenea optiunile care trebuie evitate atunci cind facem modelarea datelor.
Sa reflecte cit mai precis realitatea
tn primul rind, design-ul viitoarei baze de date trebuie sa fie conform cu specificatiile aplicatiei de dezvoltat. Concret, multimile entitate, atributele lor $i asocierile trebuie sa reflecte cit mai precis segmentul din realitate care se modeleaza. De exemplu, nu о sa atribuim un atribut “seria $asiu” pentru un student, dar о s-o facem pentru о marina, lar asocierea Modereaza, dintre Moderatori-i de emisiuni TV $i Emisiuni, dintr-o baza de date despre emisiuni TV, trebuie modelata ca fiind multi-multi, deoarece un moderator poate modera mai multe emisiuni, iar о emisiune poate fi moderata de mai multi moderatori. Declararea acestei legaturi ca fiind multi-unu sau unu-la-unu nu ar fi potrivita, deoarece nu ar reflecta situatia existenta in lumea reala.
Pentru mai multe exemple, vezi materialul tiparit.
Sa evite redundantele nedorite
A$a dupa cum am amintit $i in sectiunea introductiva, trebuie sa avem grija sa nu stocam, in mod nedorit, acela^i lucru de mai multe ori. Sa ne amintim exemplul cu produsele comercializate de magazinul online aBCDstore. Fiecare produs avea un proprietar, al carui nume aparea in schema pentru multimea entitate Produse (pentru carti era editura, pentru CD-urile muzicale era casa de discuri, iar pentru DVD-uri casa de productie).
Este firesc sa ne gindim ca proprietarul este asociat cu produsul printr-o legatura Produs-de, dar este la fel de natural ca numele
28 MODELUL ENTITATE-LEGATURA
proprietarului sa apara in schema pentru produse. Totu$i aceasta dublare de informatii poate crea anomalii.
Pentru mai multe explicatii, vezi materialul tiparit.
Sa fie cit mai simplu
Atunci cind proiecteaza о baza de date, ca $i in multe alte situatii, designer-ii trebuie sa pastreze lucrurile cit mai simple cu putinta $i sa nu introduca nici-un element de design in plus, fata de strictul necesar pentru reflectarea cu acuratete a realitatii modelate. J	J
Pentru mai multe exemple, vezi materialul tiparit.
Sa includa asocierile cele mai potrivite
Multimile entitate pot fi conectate intre ele in diverse moduri, prin asocieri. Totu$i, introducerea tuturor asocierilor posibile nu este de multe ori cea mai buna idee de proiectare. tn primul rind ar produce redundanta, deoarece unele dintre informatiile aduse de unele dinre asocieri pot fi deduse din celelalte. Apoi, baza de date rezultata ar avea nevoie de spatiu mai mult pentru a stoca informatiile redundante, iar modificare datelor din ea ar fi mai complicata deoarece schimbari asupra unor date ar avea efecte care s-ar propaga in multe alte locuri in interiorul bazei de date.
Pentru mai multe explicatii, vezi materialul tiparit.
Sa foloseasca elemental de design potrivit
Uneori exista mai multe posibilitati privind folosirea unui anumit tip de element de proiectare, pentru a reprezenta un fapt sau concept din lumea reala. Multe dintre acestea se refera la folosirea atributelor versus utilizarea de combinatii de multimi entitate $i asocieri. Evident ca, in general, atributele se implementeaza mai u$or decit multimile entitate sau asocierile, dar uneori nu e cea mai buna idee sa facem totul atribut ©
Pentru mai multe exemple, vezi materialul tiparit.
2.6 Constringeri asupra datelor 29
Conditii pentru substituirea unei multimi entitate cu un atribut
Este de preferat sa folosim un atribut A in loc de о multime entitate E sau sa inlocuim pe E cu unui sau mai multe atribute daca urmatoarele conditii sint indeplinite:
1.	in toate relatiile in care E este implicata, ea trebuie sa fie la capatul unu- al legaturilor unu-multi;
2.	atributele lui E trebuie sa identifice in comun о entitate. Daca sint mai multe atribute, atunci nici-un atribut nu trebuie sa depinda de alte atribute (de exemplu, in felul in care adresa unui furnizor este determinate de numele sau);
3.	E nu trebuie sa faca parte de mai multe ori dintr-o asociere.
Daca aceste conditii sint respectate, atunci multimea entitate E poate fi inlocuita cu un atribut sau un set de atribute dupa cum se poate vedea Tn materialul tiparit.
2.6 Constringeri asupra datelor
tn sectiunile precedente am aratat cum se poate modela un segment din lumea reala folosind diverse multimi entitate $i asocierile dintre ele. Exista $i alte aspecte importante ale lumii reale, care nu pot fi surprinse folosind doar aceste doua componente ale modelului Entitate-Legatura. Acestea imbraca de multe ori forma constringerilor asupra datelor, care vin sa se adauge contringerilor de structure $i de tip impuse de definitiile pentru multimile entitate, atribute $i multimile asociere. Principalele constringeri folosite in modelarea bazelor de date se refera la urmatoarele aspecte:
•	cheile sint atribute sau grupuri de atribute care identifica unic о entitate in cadrul multimii sale entitate $i in cadrul intregii baze de date. Este imposibil sa existe doua entitati distincte care sa aiba acelea^i valori pentru toate atributele care constituie о cheie. Acest lucru este permis doar pentru о parte dintre aceste atribute;
•	valoare unica: se impune ca о anumita valoare, intr-un anumit context sa fie unica. Cheile sint о sursa majora de valori unice, deoarece impun ca fiecare entitate din multimea entitate sa aiba о valoare unica pentru atributul (sau atributele) cheie. Astfel de valori seintilnesc $i in cazul legaturilor multi-unu;
•	integritate referentiala: este obligatoriu ca о valoare care este referita de catre un anumit obiect sa existe efectiv in
30 MODELUL ENTITATE-LEGATURA
baza de date. Acest tip de integritate este similar interdictiei privind existenta pointerilor (referintelor) catre nimic (dangling pointers/ references);
•	domeniul unui atribut al unei multimi entitate este restrictionat la un set sau interval specific de valori;
•	constnngerile generale sint asertiuni arbitrare, care tin cont de semantica aplicatiei $i care trebuie sa fie valabile in interiorul bazei de date respective.
Sumar
Ф Proiectarea ^tiintifica a bazelor de date este necesara pentru a se evita producerea de redundance nedorite ale datelor, precum $i aparitia diverselor anomalii: de actualizare, inserare $i $tergere.
Ф Un model de date este un formalism matematic cu doua parti: о notatie pentru a descrie datele $i legaturile dintre ele, precum $i un set de operatii folosite pentru a le manipula.
Ф Proiectarea unei baze de date are loc in mai multe etape: analiza cerintelor, design-ul bazei de date conceptuale, proiectarea schemei conceptuale a bazei de date, rafinarea schemei bazei de date, proiectarea bazei de date fizice, proiectarea aplicatiilor $i realizarea protectiei.
Ф Principalele elementele ale modelului Entitate-Legatura sint multimile entitate $i multimile legatura. Pentru a descrie proprietatile acestora se folosesc atribute, care pot lua valori dintr-un domeniu de valori posibile (constringere de domeniu).
Ф Distingerea intre entitatile din cadrul unei multimi entitate se face cu ajutorul cheilor, care sint atribute sau grupuri de atribute, care identifica unic fiecare entitate dintr-o multime entitate.
J
Ф lerarhiile isa permit mo^tenirea unor atribute intre doua multimi entitate.
Ф Exista entitati incomplete, care nu pot fi identificate unic pe baza atributelor proprii $i atunci ele “imprumuta” atribute cheie de la entitatile cu care sint legate.
Ф Diagramele Entitate-Legatura constituie un limbaj grafic pentru descrierea elementelor modelului Entitate-Legatura.
Exerci^ii 31
Ф Legaturile au diverse caracteristici: gradul (unare, binare, ternare etc.), tipul de apartenenta (optional, obligatoriu) $i conectivitatea (unu-la-unu, multi-unu, multi-multi).
Ф Legaturile multi-multi nu pot fi reprezentate ca atare in modelul relational $i, ca urmare, ele se descompun in doua legaturi multi-unu, prin introducerea unei multimi entitate artificiale (de compozitie).
Ф tn procesul de proiectare a bazei de date exista diverse optiuni de modelare a datelor, alegerile proiectantilor trebuind sa reflecte cit mai precis segmentul din lumea reala care este descris, sa evite redundantele nedorite, sa pastreze lucrurile cit mai simple $i sa foloseasca cele mai potrivite elemente (entitati, legaturi, atribute) pentru proiectare.
Ф Tn multe privinte proiectarea bazei de date este atit §tiinta, cit $i arta. Proiectarea potrivita a unui segment din lumea reala depinde foarte mult de semantica datelor din interiorul segmentului respectiv, de regulile care se respecta in interiorul lui, dar $i de felul in care designer-ul bazei de date reu$e$te sa surprinda cu acuratete legaturile dintre datele apartinind segmentului in cauza.
J Exercitii
2.1	Care sint anomaliile care pot aparea in cazul proiectarii superficiale a bazei de date $i care este cauza lor? Cum pot fi ele solutionate?
2.2	Ce se intelege prin model de date? Care sint cele mai folosite modele de date in bazele de date?
2.3	Modelul Entitate-Legatura poate fi considerat un model de date? Argumentati raspunsul.
2.4	Care sint etapele proiectarii bazei de date? Procesul de proiectare a bazei de date este linear?
2.5	Care sint elementele principale elemente ale modelului Entitate-Legatura? Descrieti-le pe scurt. De ce modelul Entitate-Legatura este privit ca un model orientat pe obiecte?
2.6	Ce este о entitate? Dar о multime entitate? J
2.7	La ce folosesc atributele? Ce legatura este intre ele $i domenii?
2.8	Dati exemple de entitati, multimi entitate $i atribute dintr-un domeniu
32 MODELUL ENTITATE-LEGATURA
la alegere.
2.9	Care sint cele mai folosite tipuri puse la dispozitie de SQL pentru reprezentarea atributelor?
2.10	Ce este о cheie candidat? Dar о cheie primara? Ce este un atribut prim?
2.11	Care sint problemele generate de atributele multivaloare $i cum pot fi ele solutionate? J
2.12	Ce sint instantele $i ce legatura au ele cu entitatile?
2.13	De ce sint necesare ierarhiile isa §i cu ce mecanism din programare seamana ele?
2.14	Dati exemple de legaturi, multimi legatura $i instante ale unei multimi legatura dintr-un domeniu la alegere.
2.15	Ce sint entitatile incomplete? Dar atributele cheie imprumutate?
2.16	Ce sint diagramele Entitate-Legatura $i la ce folosesc ele? Care sint principalele elemente ale unei astfel de diagrame?
2.17	Comparati ierarhiile de generalizare cu cele de incluziune. Dati exemple pentru ambele tipuri.
2.18	Construiti diagrama EL pentru un segment din lumea reala, la alegere.
2.19	Ce sint rolurile? Dar atributele pentru legaturi?
2.20	Care sint principalele caracteristici ale legaturilor? Descrieti-le pe scurt $i dati exemple pentru fiecare tip in parte.
2.21	Dati exemple de legaturi, cu diverse grade, respectiv conectivitati.
2.22	Care sint problemele vizavi de reprezentarea legaturilor multi-multi din modelul Entitate-Legatura in modelul relational? Explicati notiunea de date de legatura, respectiv entitate de compozitie. Dati exemple.
2.23	Care sint principalele recomandari care trebuie urmate pentru a modela cit mai precis realitatea?
2.24	Care sint principalele constringeri folosite in modelarea datelor din bazele de date relationale?
J
Exercitii 33