5

REALIZAREA UNUI PROIECT

5.1. Realizarea modelului conceptual; harta relaiilor

Realizarea diagramei entitate-relaie presupune parcurgerea mai multor etape: Identificarea entitilor Obiectivul este identificarea entitilor din modelul conceptual al utilizatorului asupra necesitilor afacerii sale. Modelul de date conceptual const n definirea principalelor obiective care pot prezenta interes pentru utilizator/beneficiar. O metod de identificare a entitilor const n examinarea specificaiei cerinelor din documentaia beneficiarului cu privire la cerinele pe care trebuie s le ndeplineasc modelul de date. Din aceast specificaie se identific substantivele sau expresiile substantivale menionate, se caut obiectivele principale, cum ar fi: personale, locurile sau conceptele de interes, excluzndu-se substantivele care reprezint doar caliti ale obiectelor. O modalitate alternativ de identificare a entitilor este de a cuta obiectele care exist pe cont propriu. Uneori, entitile sunt greu de identificat, datorit modului n care sunt prezentate n cadrul specificaiei cerinelor utilizatorului, deoarece utilizatorii se exprim prin exemple sau analogii. Nu este ntotdeauna evident dac un anumit obiect este o entitate, o relaie sau un atribut. Exist situaii n care nu se identific de la nceput toate entitile care apar n diagram, dar aceste vor fi deduse n fazele urmtoare de realizare , de exemplu la normalizare (verificarea respectrii celor trei forma normale). Pe msur ce se identific entitile, li se atribuie denumiri (substantive luate la singular) care s aib semnificaie i s fie evidente pentru utilizatori. Identificarea tipurilor de relaii n aceast etap obiectivul este identificarea relaiilor care exist ntre entitile identificate. Atunci cnd se identific entitile (substantive), relaiile sunt indicate prin expresii verbale. n majoritatea cazurilor relaiile sunt binare (exist doar ntre dou entiti), dar exist i relaii ierarhice sau recursive, care implic un singur tip de entitate. Trebuie detectate toate relaiile care sunt: explicite sau implicite, deduse din exemplele din specificaiile utilizatorului. n majoritatea cazurilor pentru a modela un fapt real, se ajunge la o reea complex de relaii. Determinarea cardinalitii relaiilor Dup identificarea relaiilor care trebuie modelate, urmeaz determinarea cardinalitii fiecreia, care poate fi: unu-la-unu (1:1), unu-la-multi (1:M) sau multi-la-multi (M:M). Determinarea numelor de relaii Pe msur ce se identific tipurile de relaii, li se atribuie denumiri (verbe sau expresii verbale) care au semnificaie i sunt evidente pentru utilizator. Desenarea diagramei entitate relaie (ERD) preliminar Vizualizarea unui sistem complex este mai uoar dac se folosesc imagini dect dac se folosesc explicaii prin texte lungi. Deci imediat dup ce au fost identificate entitile i relaiile este potrivit s se recurg la desenarea unei prime forme a diagramei entitate-relaie.
181

Identificarea i asocierea atributelor cu entiti sau relaii Obiectivul acestei etape const n asocierea atributelor cu entitile sau relaii adecvate. Atributele pot fi identificate acolo unde substantivul (devenit entitate) exprim o proprietate, o calitate, o caracteristic a uneia dintre acele entiti sau relaii. Atribute simple/compuse n cadrul acestei etape, se identific toate atributele simple (atomice) care vor fi reprezentate n modelul de date conceptual. Exist cazuri cnd se identific atribute compuse. Exist situaii n care atributele par s fie asociate mai multor tipuri de entiti i aceste atrebuie clarificate. Imediat ce se identific atributele, li se atribuie denumiri care sunt semnificative i evidente pentru utilizatori. Apoi pentru fiecare atribut se stabilete dac este mandatoriu sau opional, se stabilete tipul valorilor atributului (tipul de date i lungimea lor), valorile prestabilite ale atributelor (dac apar n specificaie). Se stabilete dac atributul are valori multiple, deoarece acest inconvenient trebuie eliminat n procesul de normalizare. Determinarea atributelor unic identificator (UID) Se face identificarea atributelor care ar putea fi unic identificator pentru fiecare entitate i dac exist mai multe astfel de atribute. Unicul identificator poate fi simplu (un singur atribut) sau compus (format din mai multe atribute). Exist entiti pentru care nu se poate stabili din specificaie un unic identificator i atunci se introduce un nou atribut care s conin numai valori unice acesta devenind unic identificator artificial. Specializarea/generalizarea tipurilor de entiti Obiectivul este identificarea tipurilor de entiti supertip i subtip , atunci cnd este adecvat. Dac se alege tratarea prin specializare se evideniaz diferenele prin definirea uneia sau a mai multor subtipuri ale unei entiti numit i supertip. Nu exist indicaii stricte privind situaiile n care s se foloseasc supertipuri i subtipuri, depinde de caracteristicile particulare a situaiei de modelat. Uneori pot fi modelate prin folosirea relaiilor arc. Desenarea diagramei entitate relaie (ERD) mbuntite Obiecti vul acestei etape const n desenarea unei diagrame Entitate-Relaie (ER) care s fie o reprezentare fizic a modelului conceptual al beneficiarului. Revizuirea modelului de date fizic, mpreun cu utilizatorul Aceasta se face pentru a garanta c modelul este o reprezentare real a dorinei utilizatorului adic, dac modelul conceptual coincide cu modeul fizic. n cazul n care exist anomalii n modelul de date, trebuie efectuate modificrile necesare, chiar relund etapele anterioare. Se repet acest proces pn cnd utilizatorul consider c este o reprezentare corect a ceea ce trebuie modelat. Validarea modelului de date prin utilizarea tehnicii de normalizare respectarea constrngerilor cerute La ncheierea acestei etape, trebuie s se obin un model al cerinelor utilizatorului care s fie: riguros, cuprinztor i fr echivoc. Presupune urmarea mai multor etape: Eliminarea relaiilor de tip M:M Relaia de tip M:M este nlocuit cu dou relaii de tip 1:M, corespunztoare entitii nou identificate.

182

Eliminarea relaiilor complexe O relaie complex este cea format din trei sau mai multe entiti. n cazul cnd n modelul conceptual este identificat o reprezentare complex, ea trebuie descompus prin identificarea unei entiti intermediare. Relaia complex este nlocuit cu numrul necesar de relaii de tip 1:M, corespunztoare noii entiti identificate. Eliminarea relaiilor recursive n cazul cnd n modelul conceptual este reprezentat o relaie recursiv (o entitate are o relaie cu ea nsi), trebuie s o descompunem pentru a identifica o entitate intermediar. Eliminarea relaiilor cu atribute n cazul n care n modelul de date este reprezentat o relaie cu atribute (relaie barat), ea trebuie s fie descompus pentru a identifica o entitate. Eliminarea atributelor cu valori multiple Un atribut cu valori multiple conine mai multe valori pentru o singur entitate. n cazul cnd modelul de date conceptual este reprezentat un atribut cu valori multiple, el trebuie descompus pentru a identifica o entitate. Eliminarea relaiilor redundante O relaie este redundant dac aceeai informaie poate fi obinut prin intermediul altor relaii. Relaiile redundante nu sunt necesare, acestea trebuie eliminate, fapt care se realizeaz dup ce se analizeaz semnificaia fiecrei relaii dintre entiti. In final rezult o simplificare a modelulului de date conceptual. Tipuri de relaii unu-la-unu (1:1) Entitatea care particip parial n relaie este desemnat drept entitate printe, iar cea care particip total este desemnat drept entitate copil. O copie a cheii primare a entitii printe este plasat n relaia care reprezint entitatea copil . n cazul n care ambele tipuri de entiti particip total sau parial ntr-o relaie de tip 1:1, desemnarea entitilor printe, respectiv copil, este arbitrar. Tipuri de relaii binare unu-la-muli (1:M) Ca i anterior, pentru a reprezenta aceast relaie, o copie a cheii primare a entitii printe este plasat drept cheie strin n relaia reprezentnd entitatea copil . Totui, mai exist i alii factori care pot influena alegerea final, cum ar fi dac subtipurile sunt implicate n relaii diferite. Validarea modelului conceptual prin utilizarea normalizrii Normalizarea este utilizat pentru a mbuntii modelul , astfel nct acesta s satisfac diverse constrngeri care evit dublarea inutil a datelor. Normalizarea garanteaz c modelul este mai apropiat de realitate, este coerent i are o redundan minim. Normalizarea are rolul de stabilire a atributelor care aparin unui tip de entitate. Conceptul fundamental al teoriei relaionale este acela c atributele sunt grupate, mpreun ntr-o entitate deoarece ntre ele exist o legtur logic. n general n favoarea normalizrii pledeaz arguumentul c proiectul normalizat organizeaz datele conform dependenelor lor funcionale. Normalizarea implic nelegerea n totalitate a fiecrui atribut care trebuie s fie reprezentat n baza de date. Normalizarea realizeaz validarea fiecrei entiti, conform celor trei forme normale Procesul de normalizare conine urmtoarele etape: - prima form normal (1NF), care elimin gruprile repetitive. - a doua form normal (2NF), care elimin dependenele pariale de cheia primar.
183

- a treia form normal (3NF), care elimin dependenele tranzitive de cheia primar. Validarea modelului conform specificaiei utilizatorului Aceast etap const n verificarea faptului c modelul fizic cuprinde toate cerinele utilizatorilor. Acestea au fost desuse din documentaia acestora. Dac apare o neconcordan, nseamn c exist o problem n cadrul modelului de date, care este necesar s fie rezolvat. n acest caz, este posibil s se fi omis o entitate o relaie sau un atribut din componena modelului de date. Desenarea diagramei Entitate-Relaie (ERD) finale Obiectivul acestei etape const n desenarea unei diagrame entitate-relaie (ERD) finale, care s constituie o reprezentare logic a datelor utilizatorului. Aceast diagram a fost validat prin utilizarea procesului de normalizare. Definirea constrngerilor de integritate Constrngerile de integritate trebuie impuse pentru a proteja baza de date fa de situaia de a deveni incoerent. n aceasta se va specifica numai ce constrngeri de integritate sunt necesare, fr a stabili modul n care se va realiza aceasta. Constrngerile se refer la: - Datele necesare. Se identific atributele care trebuie s conin obligatoriu o valoare, adic atributele care nu au voie s conin informaii lips sau valori NULL. - Domeniile atributelor. Domeniul unui atribut definete mulimea de valori permise pe care le poate conine acesta. - Integritatea entitilor. Cheia primar a unei entiti nu trebuie s admit valori NULL. - Integritatea referenial. n general relaiile dintre entiti sunt reprezentate prin crearea unei copii a cheii primare a entitii printe n relaia copil . Integritatea referenial semnific faptul c, dac cheia strin a unei relaii copil conine o valoare, acea valoare trebuie s se refere la o apariie existent i valabil din relaia printe. Se va asigura integritatea referenial prin specificarea unor constrngeri de existen asupra cheilor primare i strine. Aceste constrngeri definesc condiiile n care sunt reactualizate sau terse apariiile unei chei primare, respectiv inserate sau reactualizate apariiile unei chei strine. Revizuirea modelului de date fizic mpreun cu utilizatorul Se valideaz modelul de date relizat, prin revizuirea acestuia mpreun cu utilizatorulbeneficiarul. Este foarte important ca modelul, s constituie o reprezentare adevrat a lumii reale aa cum este perceput de ctre beneficiar. Diagrama acioneaz ca un mijloc de comunicare ntre realizatorul modelului i utilizatorul lui. Este foarte important ca utilizatorii s analizeze documentaia realizat de ctre programator, care susine i explic modelul. n cazul cnd utilizatorii constat un punct slab n model sau documentaie, trebuie repetate etapele necesare pentru corectarea problemelor aprute. Modelul de date fizic cuprinde un model ERD i documentaie care descrie componentele acesteia.

184

Exemplu: Centru sportiv i de recuperare Managerul firmei Active Life care ofer servicii de recuperare medical i diverse activiti sportive dorete s rein ntr-o baz de date informaiile referitoare la firm: activitile oferite, orarul lor, evidena personalului i a clienilor, sponsorizrile pe care le primete. Aceast baz de date trebuie s fie optimizat i s corespund cerinelor fimei. De asemenea trebuie s fie flexibil s permit dezvoltarea, extinderea activitilor fimei. Centrul sportiv Active Life ofer servicii de recuperare medical (fizioterapie i gimnastic de recuperare) i cursuri de not, patinaj, aerobic, sala de culturism i fitness, tenis de mas pentru meinerea formei fizice. Pentru aceasta are la dispoziia clienilor un centru cu o sal de sport i mai multe cabinete de fizioterapie. Acestea nu se afl ntr-o singur locaie. Din cauza lipsei de spaiu, cabinetele se afl ntr-o cldire, iar sala de sport la alt adres. Pentru cei care doresc s se nscrie la un curs de not, deoarece nu dispune de un bazin propriu, nchiriaz n anumite zile din sptmn un bazin de la o baz sportiv cu care are ncheiat un parteneriat. Iarna nchiriaz, n condiii similare, de la o firm partener, un patinoar. Centrul pune la dispoziia celor care se nscriu pentru antrenamente, la disciplinele sportive enumerate, antrenori de specialitate. Acetia lucreaz n funcie de specialitatea lor n diversele locaii n care firma i desfoar activitatea. La centru se nscriu pe baza unui abonament i persoane care au suferit diverse accidente i au nevoie de recuperare medical. Pentru cei care doresc s urmeze un tratament la fizioterapie sau gimnastic medical centrul pune la dispozie medici care urmresc evoluia clientului i evalueaz periodic starea sa de sntate i progresele realizate n recuperare. Aceste evaluri se fac pe baza unor teste din care rezult un anumit punctaj i sunt trecute ntro fi personal a clienior centrului. Clienii care doresc s vin la centru i fac un abonament pe o perioad dorit, firma punnd la dispoziia lor mai multe oferte n acest sens. Un anumit client se poate nscrie (abona) la diferite discipline sportive n acelai timp, dar, deoarece se urmrete i obinerea unor performane, nu poate s se nscrie i la fizioterapie sau gimanstic de recuperare deoarece se presupune c un astfel de client este sntos i poate face un efort fizic susinut. Antrenamentele sunt astfel concepute inct cei care se nscriu s poat s obin performane notabile. Unii dintre clieni chiar particip la competiii sportive astfel nct firme care produc materiale i echipamente sportive sunt interesate s sponsorizeze centrul. Unele sponsorizeaz direct prin donarea unor sume de bani pentru susinerea sportivilor care particip la competiii, altele susin centrul prin anumite materiale promoionale de exemplu, echipament sportiv, altele ofer diverse servicii, de exemplu stagii de pregtire suplimentar pentru cei care sunt capabili de performane. De asemenea, unele companii farmaceutice s-au artat interesate s promoveze anumite produse pentru tratamente n cadrul centrului. Pentru fiecare sponsorizare se reine data la care a fost fcut. Centrul, pe lng medici i antrenori mai are i ali angajai: cei care se ocup de partea financiar i de relaiile cu clienii (contabili, secretare), persoane care se ocup de curenie i ntreinerea bazei sportive. Are, pentru fiecare tip de servicii oferite i cte un responsabil. De asemenea are un manager general. Unele posturi sunt libere. Cei care lucreaz de mai mult timp n cadrul firmei i au dovedit caliti manageriale pot promova pe un post superior sau pot s se schimbe pe alt post. Fiecare client achit contravaloarea abonamentului prin una sau mai multe facturi. Conform cererilor clientului trebuie identificate entitile, atributele i relaiile dintre ele. ntr-o prim faz diagrama entitate relaie arta n felul urmtor:

185

FACTURA #ID *data *valoare s fie pltit

FIA #ID *data test *punctaj s nscrie

s plteasc CLIENT #ID *nume *adresa *telefon *boal o observaii

s fie nscris

ACTIVITATE #ID *data nceperii *data terminrii

efectuat s participe

s fie coordonat SPONSOR #nume *adresa *telefon o web site s coordoneze ANGAJAT #CNP *nume *adresa *telefon *specialitatea *data naterii *vechimea *salariu s susin

s fie susinut s lucreze s aib DEPARTAMENT #cod *denumire s posede

s ocupe

s fie ocupat POST #cod *cerine o observaii

s gzduiasc LOCAIE #cod *adresa *telefon

Proiectanii de baze de date trebuie s aib o vedere selectiv asupra lumii i s poat s clasifice i s interpreteze lucrurile legate de cerinele beneficiarului.
186

Reprezentarea necesitilor firmei trebuie realizat astfel nct s fie un model ct mai apropiat de modul n care se desfoar activitile ei. Datele trebuie stocate astfel nct s fie permis o cutare ct mai eficient. Design-ul bazei trebuie s fie flexibil astfel nct s poat fi adaugate noi sporturi s apar noi departamente, s poat fi adugai noi sponsori, s fie realizat o eviden a angajailor. La baza de date astfel construit trebuie s aib acces i angajaii firmei, pentru a completa informaii (adaugarea unor noi clieni, a unor noi sponsori, a unor noi angajai, etc). In viitor se poate avea n vedere crearea unei pagini web care s conin informaiile referitoare la centru, accesarea acestora putnd fi fcut de ctre potenialii clieni. Patru pai n realizarea unui proiect: 1. Analiza presupune citirea cu atenie a ntregii documentaii oferite de beneficiar i nelegerea fenomenelor specifice care trebui modelate. 2. Strategia presupune definirea pailor importani n realizarea proiectului, necesit conlucrarea tuturor membrilor echipei care se ocup de proiect pentru a alege cele mai potrivite idei de rezolvare a problemelor care apar dup parcurgerea documentaiei. 3. Design-ul const n realizarea modelului conceptual, a diagramei entitate-relaie care s cuprind ntreg ansamblul de situaii care trebuie modelate. De obicei n aceast faz se prezint beneficiarului modelul realizat pentru a da verdictul: modelul corespunde sau nu necesitilor sale. 4. Construcia presupune implementarea efectiv n calculator, a modelului conceptual realizat Dar la aceast prim diagram, pentru a fi corect, sunt mai multe probleme care necesit rezolvare: sunt relaii M:M care trebui rezolvate sunt relaii care au nume incorecte sunt relaii care nu au corect definit opionalitatea relaiile de tip 1:M trebuie s aib captul care indic mai muli orientat numai spre nord i vest sau spre sud i est unele entiti au subtipuri s acestea nu sunt precizate trebuie definite relaii recursive i relaii arc, dac este necesar trebuie verificate cele trei forme normale

n urma rezolvrii acestor probleme rezult o diagram mult mai complex. Poziionarea entitilor i a relaiilor dintre ele trebuie realizat astfel nct s fie uor de citit i s fie ct mai clare. Pe ct posibil, relaiile nu trebuie s aib schimbri de direcie i n nici un caz s nu se intersecteze. Diagrama entitate-relaie final:
187

FACTURA #ID *data *valoare

s fie pltit

EVALUARE *data pentru s plteasc CLIENT #ID *nume *adresa *telefon *boal o observaii

pentru

pentru NSCRIS *data pentru s participe

s fie nscris

s nscrie FIA #ID *data test *punctaj

efectuat ACTIVITATE #ID *data nceperii *data terminrii s includ s includ

SPONSORIZARE #data BANI *valoare

o

MATERIAL PROMOIONAL *denumire *valoare

o

SERVICIU *denumire *durata

o

clauza

descriere

descriere *web site s fie oferit

s fie inclus ANTRENAMENT #cod *durata *performana

s fie inclus TRATAMENT #cod *durata *rezultate *contraindicaii s fie urmrit

s fie fcut de

s ofere SPONSOR #nume *adresa *telefon o web site

s fie coordonat

s coordoneze ANGAJAT #CNP *nume *adresa *telefon *vechimea *salariu

s urmreasc s lucreze

s conduc

ANTRENOR *specializare *rezultate

MEDIC *specializare

ALII *funcia

s primeasc

s aib DEPARTAMENT #cod *denumire

s fie condus

s ocupe

s posede s fie ocupat

s gzduiasc LOCAIE #cod *adresa *telefon

POST #cod *cerine o observaii

188

Explicaii ale diagramei entitate-relaie: - fiecare departament are activiti specifice. De exemplu departamentul contabilitate trebuie s rezolve toate problemele legate de gestionarea fondurilor: achiziionarea de materiale, sponsorizrile, banii obinui din abonamente. - la anumite intervale de timp pot realizate evaluri ale clienilor pentru a vedea evoluia lor n timp. Pentru cei aflai sub tratament este chiar necesar o evaluare periodic. - Exist personal cu diverse atribuii de aceea trebuie folosite subtipuri pentru definirea entitii angajat. Sponsorii pot contribui prin diverse forme n susinerea sportivilor sau a persoanelor aflate la tratament. - Pentru serviciile de care beneficiaz, clientului i este emis o factur. n realizarea modelului trebuie respectate constrngeri: a) Fiecare departament are unul sau mai muli angajai care ocup posturi specifice. Nu poate s existe un angajat n afara unui departament. Intre angajai exist o relaie de subordonare (un angajat este eful celorlali) figurat n ERD prin intermediul unei relaii recursive de la entitatea angajat a ea nsi. b) Pot exista doi angajai cu aceeai meserie (de exemplu, doi antrenori sau doi medici). Pe un post poate fi la un moment dat un singur angajat, dar un angajat i poate schimba postul, dac promoveaz. Unele posturi pot fi vacante. c) Departamentul contabilitate poate avea realii cu unul sau mai muli sponsori. Acetia pot oferi susinere financiar sau prin materiale promoionale sau prin servicii (transport, aparatur, etc.) Pentru fiecare sponsorizare se nregistreaz data la care a fost fcut. d) Un client se poate nscrie la una sau mai multe din activitile clubului. El se poate nscrie fie numai la antrenamente fie numai la tratamente. Antenamentele sunt obligatoriu coordonate de un antrenor, iar tratamentele sunt supervizate de un medic din centru. e) Clientul poate s pltesc una sau mai multe facturi. f) Tratamentul sau antrenamentul const din una sau mai multe activiti la care s-a nscris clientul. Fiecare client este nscris la o activitate. Un medic nu poate coordona un antrenament. Un antrenor nu poate supraveghea un client aflat sub tratament. Modelul conceptual surprinde fenomenele care au loc n interiorul firmei aa cum le-a perceput proiectantul bazei de date, dar unele clarificri se vor face la momentul ntlnirii dintre proiectant i beneficiar. Acestea vor fi incorporate n modelul final.

5.2. Construirea bazei de date i implementarea ei

Transformarea modelului conceptual n modelul fizic: Transformarea modelului conceptual n model fizic se numete mapare. Entitile se transform n tabele. Numele entitii (substantiv luat la singular) devine numele tabelei (substantiv luat la plural). Atributele entitii devin coloane ale tabelei i primesc numele de cmpuri. Toate valorile de pe o coloan a tabelei sunt de acelai tip.
189

 O instan a unei entiti devine o linie din tabela (o nregistrare). Atributul care este unic identificator (UID) devine cheie primar (notat pk). Unic identificator secundar devine chei unice (notat uk), care va fi cheie candidat. Atributul unei tabele A care este cheie primar n tabela B cu care A se afl n relaie, poart denumirea de cheie strin (notat fk). Cmpurile (coloanele) care sunt chei primare, strine sau unice trebuie s conin obligatoriu o valoare pentru fiecare nregistrare . Celelalte cmpuri pot conine i valoarea NULL sau 0 ntr-un cmp. Unicul identificator, devenit cheie primar are, n plus, obligativitatatea de a avea valori diferite pentru fiecare dintre instane, deoarece trebuie fcut diferenierea ntre oricare dou ntegistrri din tabel. Constrngerile formulate ca explicaii la crearea modelului conceptual trebuie cuprinse n modelul fizic prin constrngeri de integritate. Observaii: -

La trecerea de la entitate la tabel numele coloanelor poate fi acelai cu numele atributelor din modelul conceptual. Spaiile din numele unui atribut de la modelul conceptual se scriu cu liniu de subliniere n modelul fizic, de exemplu, cod potal devine cod_potal. Dar coloanle pot fi denumite i folosind prescurtri, de exemplu, pentru cod potal poate fi cod_p sau codp. Un cmp cu un anumit nume poate s apar n mai multe tabele. - Numele de tabele i coloane trebuie s ncep obligatoriu cu o liter, nu conin mai mult de 30 de caractere i pe lng litere mai pot conine caracterele $, #, -. Nu poate fi un nume de tabel sau de cmp un cuvnt rezervat. Intr-o baz de date nu exist mai multe tabele care s aib acelai nume. Entitile CLIENT i FACTURA ntre care exist o relaie 1:M devin dou tabele CLIENTI ;I FACTURI. Pentru fiecare dintre ele transformarea n tabele se face astfel:

FACTURA #ID *data *valoare

s fie pltit s plteasc

CLIENT #ID *nume *adresa *telefon *boal o observaii

FACTURI Nume cmp ID_fact Data Valoare Client_id

Chei Optionalitate pk * * * fk *

CLIENI Nume cmp ID_cli Nume Adresa Telefon Boala Obs

Chei Optionalitate pk * * * * *
o

190

Tabela FACTURI are cheie primar cmpul ID_fact, tabela CLIENTI cmpul ID_cli. Cheia primar din entitatea CLIENTI devine cheie strin n tabela FACTURI. Scrierea efectiv a tabelelor se face prin comanda SQL: CREATE TABLE Facturi ( id_fact VARCHAR2(6) PRIMARY KEY, data DATE NOT NULL, valoare NUMBER(6,2), client_id VARCHAR2(6) FOREIGN KEY) ; CREATE TABLE Clienti ( id_cli VARCHAR2(6) PRIMARY KEY, nume varchar2(40) NOT NULL, adresa varchar2(75), telefon varchar2(10), boala varchar2(75), obs varchar2(75)) ; Cnd trebuie s trecem n tabele o entitate de intersecie, inem cont c ea preia atribute din cele dou entiti iniiale, dar poate avea i atribute proprii. Unicul identificator al entitii de intersecie provine din atribute din cele dou entiti iniiale, este cel mai adesea o combinaie de atribute, dar se poate defini i un unic identificator artificial. Pentru entitile ACTIVITATE i CLIENT ntre care s-a introdus o entitate de intersecie INSCRIS pentru rezolvarea relaiei M:M, vor fi trecute n tabele n felul urmtor:
pentru NSCRIS *data pentru s participe CLIENT #ID *nume *adresa *telefon *boal o observaii

efectuat ACTIVITATE #ID *data nceperii *data terminrii

ACTIVITATI Nume Chei Optiocmp nalitate ID_act pk * Data_inc * Data_term *

INSCRIERI Nume Chei cmp Data ID_act pk,fk ID_cli pk,fk

Optionalitate * * *

CLIENTI Nume cmp ID_cli Nume Adresa Telefon Boala Obs

Chei Optionalitate pk * * * * *
o

n tabela NSCRIERI se vor introduce dou cmpuri ID_act i ID_cli care sunt chei primare n tabelele ACTIVITI, respectiv CLIENI. Ele devin chei strine n tabela INSCRIERI. ID_act, ID_cli formeaz chei primare n NSCRIERI datorit faptului c aceasta este o entitate de intersecie.
191

Crearea efectiv a tabelelor se face prin comenzile: CREATE TABLE Activitati ( id_act VARCHAR2(6) PRIMARY KEY, data_inc DATE NOT NULL, data_term DATE) ; CREATE TABLE Inscrieri ( data DATE NOT NULL, id_act VARCHAR2(6) FOREIGN KEY, id_cli VARCHAR2(6) FOREIGN KEY) ; In mod asemntor, se transform n tabele cele trei entiti: CLIENT, EVALUARE i FIA, devenind tabelele CLIENI, EVALURI i FIE:
EVALUARE *data pentru pentru

s fie nscris CLIENT #ID *nume *adresa *telefon *boal o observaii

s nscrie FIA #ID *data test *punctaj

FIE Nume cmp ID_f Data_test Punctaj

Chei Optionalitate pk * * *

EVALURI Nume Chei cmp Data ID_f pk,fk ID_cli pk,fk

Optionalitate * * *

CLIENI Nume cmp ID_cli Nume Adresa Telefon Boala Obs

Chei Optionalitate pk * * * * *
o

Pentru modelarea unui arc, de exemplu pentru entitatea ACTIVITATE, aflat n relaie cu entitile ATRENAMENT sau TRATAMENT, se definesc trei tabele:

192

ACTIVITATE #ID *data nceperii *data terminrii s includ s includ

s fie inclus ANTRENAMENT #cod *durata *performana

s fie inclus TRATAMENT #cod *durata *rezultate *contraindicaii

ANTRENAMENTE Nume cmp Chei Optionalitate Cod pk * Durata * Performana *

ACTIVITI Nume Chei Optiocmp nalitate Data * O Cod_tr fk O Cod_antr fk

TRATAMENTE Nume Chei cmp Cod pk Durata Rezultate Contraind

Optionalitate * * * *

Cheile primare din tabelele TRATAMENTE i ANTRENAMENTE devin chei strine n tabela ACTIVITI. Cmpurile Cod_antr i Cod_tr sunt ns opionale. Cheile strine din tabela ACTIVITTI trebuie s fie opionale deoarece pentru o nregistrare doar una dintre ele este activ, cealalt fiind nul (un client este nscris exclusiv, sau la antrenament, sau la tratament). Entitatea care conine subtipuri, de exemplu SPONSORIZARE poate fi implementat n tabele n dou feluri: A. Folosind o unic tabel n care se insereaz un cmp suplimentar, discriminant, de exemplu Tip sponsorizare (Tip_sp) care face diferena ntre cele trei tipuri de sponsorizri. Acest nou cmp are o valoare pentru fiecare din nregistrri, este obligatoriu.

SPONSORIZARE #data BANI *valoare o clauza

MATERIAL PROMOIONAL *denumire *valoare o descriere *web site

SERVICIU *denumire *durata o descriere

193

Atributele specifice numai unui subtip devin cmpuri opionale n tabela final. n acest caz, cmpurile tabelei vor arta n felul urmtor: SPONSORIZRI Nume Chei cmp Data pk Tip_sp Valoare Clauza Denumire Descriere Durata Optionalitate * * *
o

*
o

B. Folosind trei tabele cte una pentru fiecare subtip care apare n diagram. n acest caz, tabelele vor fi structurate astfel: BANI Nume cmp Data Valoare Clauza OptioChei nalitate pk * *
o

MATERIALE_PROM Nume cmp Chei Optionalitate Data pk * Denumire * Valoare * o Descriere

SERVICII Nume cmp Data Denumire Durata Descriere

Chei Optionalitate pk * * *
o

n continuare, pentru modelarea legturii dintre entitile SPONSORIZARE i SPONSOR innd seama c, relaia dintre ele este netransferabil, la trecerea n tabele (SPONSORIZARI respectiv SPONSORI), cheia primar din SPONSORI trebuie s devin cheie strin n SPONSORIZARI i, n plus trebuie s conin valori care nu se modific, deci va fi o coloan cu valori care nu se pot modifica. Entitatea SPONSORIZARE se poate modela n dou feluri, dup cum am artat, iar relaionarea sa cu entitatea SPONSOR se poate trece n tabele astfel:

SPONSORIZARE #data BANI *valoare

o

MATERIAL PROMOIONAL *denumire *valoare

o

SERVICIU *denumire *durata

o

clauza

descriere *web site

descriere

s fie fcut de

s ofere SPONSOR #nume *adresa *telefon o web site

194

SPONSORIZRI Nume Chei cmp Data pk Tip_sp Valoare Clauza Denumire Descriere Durata Nume_sp fk

Optionalitate * * *
o

SPONSORI Nume Chei Optiocmp nalitate Nume pk * Adresa * Telefon * o Web_site

*
o

* *

Sponsorizrile se acord unui departament:

SPONSORIZARE #data BANI *valoare
o

MATERIAL PROMOIONAL *denumire *valoare

o

SERVICIU *denumire *durata

o

clauza

descriere

descriere *web site s fie oferit

s fie fcut de

s ofere SPONSOR #nume *adresa *telefon *web site

s primeasc DEPARTAMENT #cod *denumire

DEPARTAMENTE Nume Chei cmp Cod pk Denumire

Optionalitate * *

SPONSORIZRI Nume Chei cmp Data pk Tip_sp Valoare Clauza Denumire Descriere Durata Nume_sp fk Cod_dep fk

Optionalitate * * *
o

SPONSORI Nume Chei Optiocmp nalitate Nume pk * Adresa * Telefon * o Web_site

*
o

* * *

Codul departamentului devine cheie strin n tabela SPONSORIZRI. ntr-un mod asemntor se transform n tabele entitile: DEPARTAMENT i LOCAIE, devenind tabelele DEPARTAMENTE i LOCATII.

195

DEPARTAMENT #cod *denumire s posede

s gzduiasc LOCAIE #cod *adresa *telefon

DEPARTAMENTE Nume Chei cmp Cod pk Denumire Cod_loc fk

Optionalitate * * *

LOCAII Nume cmp Cod Adresa Telefon

Chei Optionalitate pk * * *

Entitatea ANGAJAT poate fi modelat folosind o unic tabel care are, n plus, un cmp discriminator, de exemplu cmpul cod (codul angajatului) care identific departamentul i funcia angajatului i astfel rezult o clasificare a lor. Un angajat (manager) este n relaie cu ceilali angajai, fapt figurat printr-o relaie recursiv. Aceasta va fi trecut n tabel, prin introducerea unui cmp care este cheie strin, de exemplu Man_id. Se va face o relaionare ntre cheia primar (CNP) i aceast cheie strin.
ANGAJAT #CNP *nume *adresa *telefon *vechimea *salariu

s conduc

ANTRENOR *specializare *rezultate

MEDIC *specializare

ALII *funcia

s fie condus

ANGAJATI Nume cmp

CNP Nume Adresa Telefon Vechimea Salariu Specializare Rezultate Functia Cod uk Man_id fk
196

Chei Optionalitate pk * * * * * *
O O O

*
O

Pentru entitatea ANGAJAT trebuie s lum n considerare c se afl n legtur cu entitatea DEPARTAMENT i cu entitatea POST. Astfel nct n tabela ANGAJATI vor aprea nc dou chei strine cod_dep i cod_post.

s conduc

ANGAJAT #CNP *nume *adresa *telefon *vechimea *salariu

s lucreze ANTRENOR *specializare *rezultate MEDIC *specializare ALII *funcia s aib DEPARTAMENT #cod *denumire s ocupe

s fie condus

s fie ocupat POST #cod *cerine o observaii

DEPARTAMENTE Nume cmp Cod Denumire Chei Optionalitate pk * *

ANGAJATI Nume cmp CNP Nume Adresa Telefon Vechimea Salariu Specializare Rezultate Functia Cod Man_id Cod_dep Cod_post Chei Optionalitate pk * * * * * *
O O O

POSTURI Nume cmp Cod Cerine Obs Chei Optionalitate pk * *

o

uk fk fk fk

*
O

* *

Angajaii supervizeaz activitile care se desfoar: un medic supervizeaz tratamentele, un antrenor coordoneaz antrenamentele. Astfel nct se definesc relaii:

197

ANTRENAMENT #cod *durata *performana

TRATAMENT #cod *durata *rezultate *contraindicaii s fie urmrit

s fie coordonat

s coordoneze ANGAJAT #CNP *nume *adresa *telefon *vechimea *salariu

s urmreasc

ANTRENOR *specializare *rezultate

MEDIC *specializare

ALII *funcia

ANTRENAMENTE Nume cmp Chei Optionalitate Cod pk * Durata * Performana * Cod_ang fk *

ANGAJATI Nume cmp CNP Nume Adresa Telefon Vechimea Salariu Specializare Rezultate Functia Cod Man_id Cod_dep Cod_post

Chei Optionalitate pk * * * * * *
O O O

TRATAMENTE Nume Chei cmp Cod pk Durata Rezultate Contraind Cod_ang fk

Optionalitate * * * * *

uk fk fk fk

*
O

* *

198