1. Date, informatii, cunostinte

Auzim adesea vorbindu-se despre "Era informatiilor" sau "societate informationala" sau "tehnologia informatiei" insa de multe ori cuvantul 'informatie' este folosit fara a intelege clar sensul acestui cuvant, diferenta dintre date, informatii, cunostinte.

In general, continutul gandirii umane opereaza cu urmatoarele concepte:

Date - constau in material brut, fapte, simboluri, numere, cuvinte, poze fara un inteles de sine statator, neintegrate intr-un context, fara relatii cu alte date sau obiecte. Ele se pot obtine in urma unor experimente, sondaje etc.

Informatii - prin prelucrarea datelor si gasirea relatiilor dintre acestea se obtin informatii care au un inteles si sunt integrate intr-un context. Datele organizate si prezentate intr-un mod sistematic pentru a sublinia sensul acestor date devin informatii. Pe scurt informatiile sunt date prelucrate. Informatiile se prezinta sub forma de rapoarte, statistici, diagrame etc.

Cunostintele sunt colectii de date, informatii, adevaruri si principii invatate, acumulate de-a lungul timpului. Informatiile despre un subiect retinute si intelese si care pot fi folosite in luarea de decizii, formeaza judecati si opinii devin cunostinte. Cu alte cuvinte, cunostintele apar in momentul utilizarii informatiei .

2. Colectarea si analizarea datelor. Modelul conceptual

Primul pas in realizarea unei aplicatii de baze de date este analiza datelor si realizarea unei scheme conceptuale (model conceptual) al acestor date.

In aceasta etapa sunt analizate natura si modul de utilizare a datelor. Sunt identificate datele care vor trebui memorate si procesate, se impart aceste date in grupuri logice si se identifica relatiile care exista intre aceste grupuri.

Analiza datelor este un proces uneori dificil, care necesita mult timp, insa este o etapa absolut obligatorie. Fara o analiza atenta a datelor si a modului de utilizare a acestora, vom realiza o baza de date care putem constata in final ca nu intruneste cerintele beneficiarului. Costurile modificarii acestei baze de date este mult mai mare decat costurile pe care le-ar fi implicat etapa de analiza si realizare a modelului conceptual. Modificarea modelului conceptual este mult mai usoara decat modificarea unor tabele deja existente, care eventual contin si o multime de date. Ideea de baza a analizei datelor si construirii modelului conceptual este 'sa masori de doua ori si sa tai o singura data'.

Informatiile necesare realizarii modelului conceptual se obtin folosind metode conventionale precum intervievarea oamenilor din cadrul organizatiei si studierea documentelor folosite.

Odata obtinute aceste informatii ele trebuiesc reprezentate intr-o forma conventionala care sa poata fi usor inteleasa de toata lumea. O astfel de reprezentare este diagrama entitati-relatii, numita si harta relatiilor, sau ERD-ul (Entity Relationship Diagram). Aceste scheme sunt un instrument util care usureaza comunicarea dintre specialistii care proiecteaza bazele de date si programatori pe de o parte si beneficiari, pe de alta parte. Acestia din urma pot intelege cu usurinta o astfel de schema, chiar daca nu sunt cunoscatori in domeniul IT.

In concluzie putem sublinia cateva caracteristici ale ERD-urilor:

sunt un instrument de proiectare

sunt o reprezentare grafica a unui sistem de date

ofera un model conceptual de inalt nivel al bazelor de date

sprijina intelegerea de catre utilizatori a datelor si a relatiilor dintre acestea

sunt independente de implementare.

In cele ce urmeaza vom prezenta principalele elemente care intra in componenta unui ERD precum si conventiile de reprezentare a acestora.

3. Entitati. Instante. Atribute. Identificator unic.

O entitate este un lucru, obiect, persoana sau eveniment care are semnificatie pentru afacerea modelata, despre care trebuie sa colectam si sa memoram date. O entitate poate fi un lucru real, tangibil precum o cladire, o persoana, poate fi o activitate precum o programare sau o operatie, sau poate fi o notiune abstracta.

O entitate este reprezentata in ERD printr-un dreptunghi cu colturile rotunjite. Numele entitatii este intotdeauna un substantiv la singular si se scrie in partea de sus a dreptunghiului cu majuscule, ca in figura I.1.1.

O entitate este de fapt o clasa de obiecte si pentru orice entitate exista mai multe instante ale sale. O instanta a unei entitati este un obiect, persoana, eveniment, particular din clasa de obiecte care formeaza entitatea. De exemplu, elevul X din clasa a IX-a A de la Liceul de Informatica din localitatea Y este o instanta a entitatii ELEV

Dupa cum se vede pentru a preciza o instanta a unei entitati, trebuie sa specificam unele caracteristici ale acestui obiect, sa-l descriem (precizam de exemplu numele, clasa, scoala etc). Asadar, dupa ce am identificat entitatile trebuie sa descriem aceste entitati in termeni reali, adica sa le stabilim atributele. Un atribut este orice detaliu care serveste la identificarea, clasificarea, cuantificarea, sau exprimarea starii unei instante a unei entitati. Atributele sunt informatii specifice ce trebuie cunoscute si memorate.

De exemplu atributele entitatii ELEV sunt nume, prenume, adresa, numar de telefon, adresa de email, data nasterii etc.

In cadrul unui ERD, atributele se vor scrie imediat sub numele entitatii, cu litere mici. Un atribut este un substantiv la singular (vezi figura I.1.2).

Un atribut poate fi obligatoriu sau optional. Daca un atribut este obligatoriu, pentru fiecare instanta a entitatii respective trebuie sa avem o valoare pentru acel atribut, de exemplu este obligatoriu sa cunoastem numele elevilor. Pentru un atribut optional putem avea instante pentru care nu cunoastem valoarea atributului respectiv. De exemplu atributul email al entitatii ELEV este optional, un elev putand sa nu aiba adresa de email. Un atribut obligatoriu este precedat in ERD de un asterisc , iar un atribut optional va fi precedat de un cerculet o

Atributele care definesc in mod unic instantele unei entitati se numesc identificator unic (UID). UID-ul unei entitati poate fi compus dintr-un singur atribut, de exemplu codul numeric personal poate fi un identificator unic pentru entitatea ELEV. In alte situatii, identificatorul unic este compus dintr-o combinatie de doua sau mai multe atribute. De exemplu combinatia dintre titlu, numele autorului si data aparitiei poate forma unicul identificator al entitatii CARTE. Oare combinatia titlu si nume autor nu era suficienta? Raspunsul este NU, deoarece pot exista de exemplu mai multe volume scrise de Mihai Eminescu avand toate titlul Poezii, dar aparute la date diferite.

Atributele care fac parte din identificatorul unic al unei entitati vor fi precedate de semnul diez (figura I.1.2 si I.1.3). Atributele din UID sunt intotdeauna obligatorii, insa semnul este suficient, nu mai trebuie pus si un semn asterisc in fata acestor atribute.

Valorile unor atribute se pot modifica foarte des, ca de exemplu atributul varsta. Spunem in acest caz ca avem de a face cu un atribut volatil. Daca valoarea unui atribut insa se modifica foarte rar sau deloc (de exemplu data nasterii) acesta este un atribut non-volatil. Evident este de preferat sa folosim atribute non-volatile atunci cand acest lucru este posibil.

4. Relatii intre entitati

In lumea reala, obiectele nu exista izolat.Intre ele exista relatii Asadar, dupa ce ati identificat care sunt entitatile si atributele acestor entitati este timpul sa punem in evidenta relatiile care exista intre aceste entitati, modul in care acestea comunica intre ele. O relatie este o asociere, legatura, sau conexiune existenta intre entitati si care are o semnificatie pentru afacerea modelata. Orice relatie este bidirectionala, legand doua entitati sau o entitate cu ea insasi. De exemplu, elevii studiaza mai multe materii, o materie e studiata de catre elevi.

Orice relatie este caracterizata de urmatoarele elemente:

1. numele relatiei ; 2.optionalitatea relatiei; 3. gradul (cardinalitatea) relatiei.

Sa luam de exemplu relatia existenta intre entitatile JUCATOR si ECHIPA. Vom spune:

Un JUCATOR joaca intr-o ECHIPA. Si La o ECHIPA trebuie sa joace unul sau mai multi JUCATORI

Numele relatiei este: joaca.

Pentru a stabili optionalitatea relatiei trebuie sa raspundem la urmatoarea intrebare: Un jucator trebuie sa joace intr-o echipa? Se poate ca un jucator sa nu joace in nici o echipa? Daca acceptam ca toti jucatorii trebuie sa joace intr-o echipa relatia este obligatorie sau mandatorie si vom spune: Un JUCATOR trebuie sa joace intr-o ECHIPA

Daca insa acceptam ca exista jucatori care nu joaca in nici o echipa (de exemplu li s-a terminat contractul si in momentul de fata nu mai joaca la nici o echipa), atunci relatia este optionala.

In acest caz vom spune: Un JUCATOR poate juca la o ECHIPA

Cardinalitatea relatiei este data de numarul de instante ale entitatii din partea dreapta a relatiei care pot intra in relatie cu o instanta a entitatii din partea stanga a relatiei. Adica va trebui sa raspundem la intrebari de genul: La cate echipe poate juca un jucator? Raspunsurile posibile sunt unul si numai unul, sau unul sau mai multi. Vom spune:

Un JUCATOR trebuie/poate sa joace la o ECHIPA si numai una.

sau Un JUCATOR trebuie/poate sa joace la una sau mai multe ECHIPE

Cea mai realista varinata a relatiei este asadar: Un JUCATOR poate sa joace la o ECHIPA si numai una.

4.Conventii de reprezentare a relatiilor

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

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

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

Figura I.1.4. Reprezentarea relatiilor

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

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

Tipuri si subtipuri

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

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

Un subtip poate avea la randul sau alte subtipuri incluse.

Figura I.4.1. Folosirea subtipurilor si supertipurilor

Subtipurile trebuie sa respecte doua reguli importante:

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

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

Documentare Business Rules

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

Tipuri de relatii

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

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

Figura I.1.5. Relatii one-to-one

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

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

Figura I.1.6. Relatii one-to-many

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

Figura I.1.7. Relatii many-to-many

Transferabilitate

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

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

Figura I.4.5. Relatii nontransferabile

Rezolvarea relatiilor many-to-many

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

Figura I.1.14

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

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

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

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

crearea noilor relatii

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

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

numele noilor relatii

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

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

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

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

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

UID artificial si compus

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

Ce este normalizarea?

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

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

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

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

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

Prima forma normala

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

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

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

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

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

Figura I.2.1.

Figura I.2.2

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

Figura I.2.5

Figura I.2.6.

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

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

A doua forma normala

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

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

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

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

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

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

A treia forma normala

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

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

Figura I.2.10.

Figura I.2.11.

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

3. Relatii exclusive (arce)

In unele situatii, relatiile se pot exclude reciproc, adica dintr-un grup de relatii, la un moment dat doar una dintre ele poate avea loc. De exemplu, un cont anume la o banca este detinut fie de o persoana fizica fie de o firma dar nu de ambele tipuri de clienti simultan. Un grup de relatii exclusive este reprezentat in harta relatiilor printr-un arc peste relatiile care fac parte din respectivul grup, ca in figura I.4.2. Toate relatiile ce fac parte din grupul de relatii exclusive trebuie sa aiba aceeasi optionalitate. Un arc apartine unei singure entitati, adica va include doar relatii care pleaca de la o aceeasi entitate.

O entitate poate avea mai multe arce, dar o anumita relatie nu poate face parte decat dintr-un singur arc.

Exista doua tipuri de relatii exclusive

- relatii exclusive obligatorii in care toate relatiile ce fac parte din arcul respectiv sunt obligatorii, ceea ce inseamna ca de fiecare data, una dintre relatii are obligatoriu loc. Este si cazul din figura 1 Evident ca un cont trebuie sa fie detinut de o persoana fizica sau de o firma, o a treia varianta neexistand.

relatii exclusive optionale caz in care toate relatiile ce fac parte din arc sunt optionale. In acest caz de fiecare data are loc cel mult una dintre relatii, existand varianta ca pentru o instanta a entitatii careia apartine arcul sa nu aiba loc nici una din relatiile din grupul respectiv. In figura 2, este exemplificata situatia in care un elev poate opta sa faca parte din echipa de fotbal, sau sa participe la cercul literar sau la cercul de informatica. Insa regulile scolii prevad ca un elev sa nu participe la doua astfel de activitati extrascolare. Relatiile fiind optionale, inseamna ca un elev are libertatea de a decide sa nu participe la nici o activitate extrascolara.

. Relatii exclusive obligatorii Relatii exclusive optionale

Relatii ierarhice. Relatii recursive

Haideti sa analizam care este structura personalului intr-o firma oarecare. In figura I.1.8 este prezentata doar o parte din organigrama unei firme.

Figura I.1.8. Organigrama unei firme

Un model de proiectare a unei astfel de structuri intr-o baza de date ar fi cea din figura urmatoare:

Figura I.1.9. Implementarea unei structuri ierarhice

Problema este ca fiecare tip de angajat din figura anterioara este de fapt un angajat si probabil exista foarte multe atribute comune tuturor acestor entitati ca de exemplu nume, prenume, adresa, telefon, email, data nasterii etc. Vom putea de aceea modela aceasta structura cu ajutorul unei singure entitati numita ANGAJAT. Insa fiecare angajat poate fi condus de catre un alt angajat. Asadar vom avea o relatie de la entitatea ANGAJAT la ea insasi. O astfel de relatie se numeste relatie recursiva.

Figura I.1.10. Implementarea unei structuri ierarhice folosind relatii recursive

Relatii redundante si multiple

Atunci cand o relatie poate fi dedusa din alte relatii spunem ca acea relatie este redundanta. Relatia se poate elimina.pot exista si relatii multiple intre entitati

Modelarea datelor istorice

Viata inseamna schimbare, orice lucru se schimba de-a lungul timpului, si nu doar obiectele se modifica in timp dar chiar si relatiile dintre aceste obiecte se schimba. Pretul produselor poate suferi modificari destul de des. Factorii care duc la aceste modificari pot fi dintre cei mai diversi, rata inflatia, anotimpul etc. Asadar atributul pret din cadrul entitatii produs se modifica de-a lungul timpului. Daca nu ne intereseaza decat pretul actual al fiecarui produs modelul este foarte simplu, ca cel din fig.Daca insa pentru afacerea modelata este important sa retinem un istoric al preturilor pentru fiecare produs, atunci atributul pret se va transforma intr-o noua entitate

Atributul data_sfarsit este optional, deoarece data pana la care este valabil pretul curent al unui produs nu este de obicei cunoscut.

Vom considera acum o situatie putin mai dificila. Sa presupunem ca dorim sa modelam o baza de date pentru o biblioteca. Evident este important de retinut un istoric al tuturor imprumuturilor, deoarece pe baza acestora, se pot afla domeniile de interes ale cititorilor, si astfel vom sti ce achizitii de carte sa facem in viitor, vom putea determina uzura cartilor astfel incat sa le putem inlocui etc.

Intr-o prima faza vom obtine o relatie de many-to-many intre entitatile CARTE si CITITOR. Fiecare carte poate fi imprumutata de mai multi cititori (evident nu in acelasi timp), si fiecare cititor poate imprumuta mai multe carti .

Sa rezolvam aceasta relatie many-to-many. Aplicand ceea ce am invatat in capitolele anterioare vom obtine schema din fig. a 2 a

Sa verificam ca acest caz este cel corect. Cheia primara este acum combinatia coloanelor cod_carte si data_imprumut. Poate un cititor imprumuta doua carti in aceeasi data? Adica urmatoarele doua inregistrari pot exista simultan in tabela ISTORIC_IMPRUMUTURI? Raspunsul este DA, combinatia celor doua coloane, pentru cele doua inregistrari fiind unica.

Deci bararea automata a celor doua relatii dinspre entitatea de intersectie nu este intotdeauna o solutie corecta. Pentru a evita aceste complicatii putem recurge la introducerea unei chei artificiale in entitatea de intersectie. In exemplul nostru se poate decide ca pentru fiecare imprumut in parte sa se completeze cate o fisa separata care are un numar unic. Obtinem modelul din figura I.4.13, care este de asemenea unul corect.

Fig. Introducerea unei chei artificiale

Conventii de ridabilitate: Se aplica conventiile Oracle de scriere a ERD-ului:

Entitatea se scrie cu majuscule, singular in interiorul unui dreptunghi cu vf rotunjite.Atributele se scriu cu litere mici , avand in fata unul din semnele #,*,o(UID, obligatoriu, optional).Orientarea liniilor este de la V la E si de sus in jos, evitand intersectia. Se pot folosi subdiagrame de explicare a diagramelor complexe, si explicarea entitatilor cu multe atribute.

Modelarea generica

Modelul generic aduce beneficii daca cerintele afacerii se schimba des. Atunci e nevoie de entitati si atribute noi.Se poate modela o singura entitate Article type care sa pastreze oricate tipuri de articole e nevoie, aceasta reduce nr de entitati.

Procesul maparii

Transformarea modelului conceptual, a ERD-ului, in modelul fizic, adica in baza de date propriu zisa, se numeste mapare. Acest proces implica transformarea fiecarui element al ERD-ului.

Numele coloanei	Tip	Tip cheie	Optionalitatea
titlu	Varchar2	Pk
autor	Varchar2	Pk
data_aparitiei	Date
Format	Varchar2
Nr_pagini	Number

Entitati à tabele, (CARTE-carti.dbf)

atributeà campuri,

coloane, UIDàcheie primara,

relatieàcheie straina,

business rules àconstrangeri

Se mapeaza procesul de transformare in diagrama tabelei:

Tipuri de date in Oracle:

daca relatia pe partea many este optionala atunci si coloanele cheii straine vor fi optionale. Ce inseamna acest lucru? Faptul ca un jucator poate la un moment dat sa nu joace la nici o echipa, atunci campul cod_echipa va ramane necompletat in dreptul lui (va avea valoarea NULL). Daca insa relatia este obligatorie pe partea many atunci coloanele ce fac parte din cheia straina vor fi optionale.

In gereral, la maparea unei relatii de tip one-to-many, vom introduce in tabela corespunzatoare entitatii de pe partea many a relatiei cheia primara a entitatii de pe partea one a relatiei. Campurile astfel introduse se vor numi cheie straina (foreign key).

Asadar:

cheia straina a unei tabele este cheia primara din tabela referinta

cheia straina este intotdeauna introdusa in tabela corespunzatoare entitatii din partea many a relatiei.

Maparea relatiilor one-to-one

Dandu-se doua entitati A si B legate intre ele printr-o relatie one-to-one, este evident ca putem include cheia primara A in cadrulul tabelei B, dar putem proceda la fel de bine si invers, incluzand cheia primara a tabelei B in cadrul tabelei A, deoarece fiecarei instante a entitatii A ii corespunde cel mult o instanta a entitatii B, dar si invers, oricarei instante a entitatii B ii corespunde cel mult o instanta a entitatii A

Pentru relatia din figura I.3.3 de exemplu putem memora pentru fiecare persoana seria de pasaport, dar si invers, pentru fiecare pasaport putem memora cnp-ul detinatorului.

Figura I.3.3.

Decizia depinde de specificul afacerii modelate. Daca de exemplu ne intereseaza in primul rand persoanele si abia apoi datele de pe pasapoarte, atunci vom adopta probabil prima varianta, a memorarii seriei de pasaport in cadrul tabelei PERSOANE, daca insa baza de date este destinata evidentei pasapoartelor, atunci probabil vom adopta varianta a doua.

Uneori este convenabil sa memoram cheia straina in ambele parti ale relatiei, in exemplul nostru pentru fiecare pasaport sa memoram cnp-ul persoanei care il detine, dar si pentru fiecare persoana sa memoram seria de pasaport.

Maparea relatiilor recursive

Daca vom privi o relatie recursiva ca pe o relatie de tipul one-to-many intre o entitate si ea insasi, atunci acest caz se reduce la ceea ce deja am discutat. Sa exemplificam relatia din figura I.3.4. Relatia recursiva din aceasta figura poate fi privita ca o relatie intre doua entitati identice, ca in figura I.3.5.

Asadar vom introduce in cadrul tabelei ANGAJATI, marca sefului sau. Diagrama de tabela va arata ca mai jos.

Tabelul I.3.4.

I.3.4. Maparea relatiilor barate

Relatiile barate sunt mapate ca cheie straina in tabela aflata in partea many a relatiei, la fel ca la maparea oricarei relatii one-to-many. Bara de pe relatie exprima faptul ca acele coloane ce fac parte din cheia straina vor devenii parte a cheii primare a tabelei din partea many a relatiei barate.

Pentru exemplul din figura I.3.6, cheia primara a tabelei ATRIBUTE va fi format din coloanele denumire_atribut si denumire_entitate, aceasta din urma fiind de fapt cheie straina in tabela ATRIBUTE

Figura I.3.6. Maparea relatiilor barate

Tabelul I.3.5. Tabela ENTITATI

Tabelul I.3.5. Tabela ATRIBUTE

Sa consideram acum un exemplu in care exista mai multe relatii barate, in cascada.

Figura I.3.7. Relatii barate in cascada

Tabelul I.3.6. Tabela A Tabelul I.3.7. Tabela B

Numele coloanei	Tip cheie	Optionalitate
idA	Pk
C1

Numele coloanei	Tip cheie	Optionalitate
idB	Pk
C2
idA	Pk, Fk

Tabelul I.3.8. Tabela C Tabelul I.3.9. Tabela D

Numele coloanei	Tip cheie	Optionalitate
idC	Pk
C3
idA	Pk, Fk
idB	Pk, Fk

Numele coloanei	Tip cheie	Optionalitatea
idD	Pk
C4
idA	Fk

. Operatii specifice prelucrarii bazelor de date

Orice sistem de gestiune a bazelor de date (SGBD) trebuie sa asigure urmatoarele functii:

definirea structurii bazei de date

incarcarea datelor in baza de date (adaugarea de noi inregistrari la baza de date)

accesul la date pentru:

o       interogare (afisarea datelor, sortarea lor, calcule statistice etc.)

o       stergere

o       modificare

intretinerea bazei de date:

o       refacerea bazei de date prin existenta unor copii de siguranta

o       repararea in caz de incident

o       colectarea si refolosirea spatiilor goale

posibilitatea de reorganizare a bazei de date prin:

o       restructurarea datelor

o       modificarea accesului la date

securitatea datelor.

O parte din aceste operatii pot fi realizate cu ajutorul limbajului SQL, altele cu ajutorul unor programe specializate, care sunt puse la dispozitia administratorului bazei de date de catre sistemul de gestiune al bazelor de date.

. Reguli de integritate

Detalierea caracteristicilor pe care trebuie sa le prezinte un SGBD pentru a fi considerat relational s-a facut de E. F. Codd in 1985 sub forma a 13 reguli. Una dintre aceste reguli precizeaza ca restrictiile de integritate trebuie sa poata fi definite in limbajul utilizat de SGBD pentru definirea datelor.

Regulile de integritate garanteaza ca datele introduse in baza de date sunt corecte si valide. Aceasta inseamna ca daca exista orice o regula sau restrictie asupra unei entitati, atunci datele introduse in baza de date respecta aceste restrictii. In Oracle, regulile de integritate se definesc la crearea tabelelor folosind constrangerile. Dar asupra acestora vom reveni in partea a doua a manualului.

Tipurile de reguli de integritate sunt urmatoarele:

Integritatea entitatilor - indica faptul ca nici o coloana ce face parte din cheia primara nu poate avea valoarea NULL. In plus, pentru fiecare inregristrare, cheia primara trebuie sa fie unica.

Integritatea de domeniu - acest tip de reguli permite ca intr-o anumita coloana se introduca doar valori dintr-un anumit domeniu. De exemplu putem impune ca salariul unui angajat sa fie cuprins intre 4500 si 5000 RON.

Integritatea referentiala - este o protectie care asigura ca fiecare valoare a cheii straine sa corespunda unei valori a cheii primare din tabela referita. De exemplu, referindu-ne la tabelele JUCATORI si ECHIPE, corespunzatoare ERD-ului din figura I.3.2, cod este cheie primara in tabela ECHIPE, iar in tabela JUCATORI cod devine cheie straina. Astfel valoarea campului cod din cadrul tabelei JUCATORI corespunzatoare unui anumit jucator trebuie sa se regaseasca printre valorile campului cod din tabela ECHIPE, altfel ar insemna ca jucatorul respectiv joaca la o echipa inexistenta (vezi figura I.3.8).

Figura I.3.8. Exemplu de incalcare a integritatii referentiale

Situatii de incalcare a integritatii referentiale pot aparea:

la adaugarea unei noi inregistrari in baza de date, se poate incerca introducerea unor valori invalide pentru campurile cheii straine;

la actualizarea bazei de date;

la stergerea unei inregistrari. De exemplu se sterge inregistrarea corespunzatoare unei anumite echipe (echipa se desfiinteaza). Inregistrarile jucatorilor care au jucat la acea echipa vor incalca integritatea referentiala, deoarece se vor referi la o echipa care nu mai exista. Solutiile posibile sunt ca la stergerea unei echipe, toti jucatorii care au activat la acea echipa sa fie si ei stersi din baza de date (stergere in cascada) sau valoarea campului cod_echipa pentru acei jucatori sa fie setata la NULL, ceea ce va inseamna ca acei jucatori nu activeaza la nici o echipa.

Programe de validare si de actiune

In realizarea modelului conceptual al unei baze de date se tine cont de modul in care functioneaza afacerea modelata, datele care trebuie sa fie memorate, relatiile dintre acestea etc. Modul de utilizare a diferitelor date, modul in care acestea sunt relationate pot diferi de la o afacere la alta.

Regulile afacerii unei organizatii se refera in esenta la procesele si fluxurile tuturor datelor si activitatilor zilnice din cadrul organizatiei. Cum functioneaza organizatia? Care sunt activitatile sale?

Regulile afacerii acopera urmatoarele aspecte ale unei organizatii:

Orice tip de politici organizationale de orice tip si de la orice nivel al organizatiei.

Orice tip de formule de calcule (ca de exemplu modul de calcul al ratelor pentru diverse imprumuturi, modul de calcul al salariilor etc)

Orice tip de reguli impuse de lege sau reguli interne ale organizatiei.

Regulile simple ale afacerii pot fi implementate in modelul bazei de date prin intermediul relatiilor dintre entitati. Acest tip de reguli se numesc reguli structurale.

Alte reguli ale afacerii pot fi implementate folosind regulile de integritate despre care am discutat in paragraful anterior. Exista totusi reguli pentru implementarea carora va trebui sa scriem programe speciale folosind limbaje specializate specifice SGBD-ului utilizat. Acest tip de reguli se numesc numite reguli procedurale. In Oracle acest tip de programe se vor scrie folosind limbajul PL/SQL (Procedural Language/Structuded Query Languge) si se numesc declansatoare (triggere).

Exista doua tipuri de declansatoare:

declansatoare de aplicatie care se executa cand apar anumite evenimente la nivelul anumitor evenimente;

declansatoare ale bazei de date care sunt lansate in executie cand apar diverse evenimente asupra datelor (de exemplu la executarea unor comenzi ca INSERT UPDATE DELETE) sau la aparitia unor evenimente system (logarea la baza de date sau delogarea).

Orice declansator poate avea rol de validare a unei operatii, poate realiza diferite operatii suplimentare, ca de exemplu diferite calcule, caz in care vom spune ca e vorba de un declansator de actiune.

Maparea tipurilor si subtipurilor

Nici un sistem de gestiune a bazelor de date nu suporta in mod direct supertipurile si subtipurile. Putem adopta mai multe solutii ale acestei probleme. Vom exemplifica aceste variante pentru schema din figura I.4.1, in care, pentru simplitate, vom presupune ca nu avem nevoie de subentitatea ALTUL

Varianta 1. Vom crea o tabela pentru supertip si cate o tabela pentru fiecare subtip. Diagramele de tabela in acest caz vor fi

Tabelul I.4.1. Tabela ANGAJATI Tabelul I.4.2. Tabela SECRETARE

Numele coloanei	Tip	Tip cheie	Optionalitatea
Id_angajat	Number	Pk
Nume	Varchar2
Adresa	Varchar2
Data_nasterii	Date
Id_departament	Number	Fk

Numele coloanei	Tip	Tip cheie	Optionalitatea
Id_angajat	Number	Pk

Tabelul I.4.3. Tabela MANAGERI Tabelul I.4.4. Tabela REPREZENTANTI_VANZARI

Numele coloanei	Tip	Tip cheie	Optionalitatea
Id_angajat	Number	Pk
Bonus	Number
Id_depart condus	Number	Fk	o

Numele coloanei	Tip	Tip cheie	Optionalitatea
Id_angajat	Number	Pk
Zona_vanzari	Varchar2
Permis_conducere	Varchar2

Am notat cu Id_depart_condus codul departamentului pe care il conduce un manager, iar cu Id_departament codul departamentului in care lucreaza un anumit angajat.

Cheia primara a supertipului va fi inclusa in toate tabelele corespunzatoare subtipurilor si va deveni cheia primara a acelei tabele.

Atributele si cheile straine provenite din relatiile de la nivelul supertipului vor fi memorate in tabela corespunzatoare supertipului. Atributele si relatiile de la nivel de subtip, se vor memora doar in tabela corespunzatoare subtipului respectiv.

Acest model este cel mai natural dar poate crea multe probleme privind eficienta intrucat sunt necesare multe operatii de interogare din tabele multiple, pentru a obtine informatii suplimentare despre toti angajatii.

Varianta 2. Vom crea cate o tabela pentru fiecare subtip. Atributele si cheile straine provenite din relatiile de la nivelul supertipului vor fi introduse in fiecare tabela astfel obtinuta, acestea fiind mostenite de catre fiecare subtip.

Tabelul I.4.5. Tabela SECRETARE Tabelul I.4.6. Tabela MANAGERI

Numele coloanei	Tip	Tip cheie	Optionalitate
Id_angajat	Number	Pk
Nume	Varchar2
Adresa	Varchar2
Id_departament	Number	Fk
Data_nasterii	Date

Numele coloanei	Tip	Tip cheie	Optionalitate
Id_angajat	Number	Pk
Nume	Varchar2
Adresa	Varchar2
Data_nasterii	Date
Bonus	Number
Id_depart condus	Number	Fk	o
Id_departament	Number	Fk

Tabelul I.4.7. Tabela REPREZENTANTI_VANZARI

Varianta 3. Vom crea o singura tabela pentru supertip. Aceasta tabela va contine toate coloanele corespunzatoare atributelor de la nivelul supertipului, dar si toate coloanele corespunzatoare tuturor atributelor din toate subtipurile. Atributele de la nivelul supertipului isi vor pastra optionalitatea, insa atributele de la nivelul subtipurilor, vor fi toate introduse in tabela, dar vor fi toate optionale.

Relatiile de la nivelul supertipului se transforma normal. Relatiile de la nivelul subtipurilor se vor implementa cu ajutorul cheilor straine optionale.

Tabelul I.4.8. Tabela ANGAJATI

Am introdus un atribut suplimentar Tip_angajat, cu ajutorul caruia vom codifica daca un angajat este manager, secretara sau reprezentant de vanzari. Deoarece atributele de la nivelul subtipurilor sunt obligatorii pentru subtipul respectiv, va trebui sa stabilim o regula de integritate la nivel de inregistrare, care sa verifice ca pentru o inregistrare de un tip anume sunt completate campurile corespunzatoare. De exemplu, la adaugarea unui nou manager in tabela ANGAJATI, trebuie sa verificam daca este completat campul bonus.

Se observa ca vor fi multe campuri cu valoarea null, ceea ce inseamna o risipa de spatiu de memorie.

Tabelul I.4.9. Tabela ANGAJATI

Id angajat	Bonus	Id_departament_condus	Zona_vanzari	Permis_conducere	Tip_angajat
			(null)	(null)
	(null)	(null)	Transilvania
	(null)	(null)	(null)	(null)

In acest tabel am codificat managerii cu 1, reprezentantii de vanzari cu 2, iar secretarele cu 3. Asadar aceasta varianta de implementare este convenabila cand exista putine atribute si relatii la nivelul subtipurilor.

Maparea arcelor

Pentru a mapa un arc vom crea atatea chei straine cate relatii exista in arcul respectiv. Pentru modelul din figura I.4.2 vom obtine urmatoarele tabele

Tabelul I.4.10. Tabela CONTURI Tabelul I.4.11. Tabela PERSOANE_FIZICE

Numele coloanei	Tip	Tip cheie	Optionalitatea
IBAN	Number	Pk
Sold curent	Number
Data_deschiderii	Date
Cnp	Number	Fk1	o
Autorizatie_functionare	Number	Fk2	o

Numele coloanei	Tip	Tip cheie	Optionalitatea
Cnp	Number	Pk
Nume	Varchar2
Prenume	Varchar2
Adresa	Varchar2
Telefon	Number

Numele coloanei	Tip	Tip cheie	Optionalitatea
Autorizatie_functionare	Number	Pk
Nume	Varchar2
Adresa	Varchar2
Telefon	Number
Fond_social	Number

Tabelul I.4.12. Tabela FIRME Desi relatiile din arc sunt obligatorii, cheile straine corespunzatoare au fost setate ca fiind optionale, deoarece pentru fiecare inregistrare trebuie sa avem completata una din cele doua chei straine, iar cealalta cheie straina trebuie sa ramana necompletata (principiul exclusivitatii). Va trebui sa implementam o conditie de integritate care sa verifice aceasta conditie.