Scrigroup - Documente si articole

Username / Parola inexistente      

Home Documente Upload Resurse Alte limbi doc  

CATEGORII DOCUMENTE





loading...

AccessAdobe photoshopAlgoritmiAutocadBaze de dateCC sharp
CalculatoareCorel drawDot netExcelFox proFrontpageHardware
HtmlInternetJavaLinuxMatlabMs dosPascal
PhpPower pointRetele calculatoareSqlTutorialsWebdesignWindows
WordXml


Colectarea si analizarea datelor. Modelul conceptual

baze de date

+ Font mai mare | - Font mai mic







DOCUMENTE SIMILARE

Trimite pe Messenger
DINAMICA FUNCTIUNILOR FIRMEI
Avantajele si dezavantajele BDOO
Premisele BDOO
Agregarea, compunerea si descompunerea – date obiect
Protectia bazelor de date
Seminar Baze de date
ORDONARI IN TABELE
BAZE DE DATE SI SISTEME DE GESTIUNE A BAZELOR DE DATE
Baze de date. Proiectare. Implementare. Gestionare
LIMBAJE DE DEFINIRE A DATELOR

Deprecated: mysql(): This function is deprecated; use mysql_query() instead in /home/svadan38/public_html/calculatoare/baze-de-date/Colectarea-si-analizarea-datel33597.php on line 124

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:




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

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

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

Caracteristica relatiei

Valoare

Mod de reprezentare

Numele relatiei

un verb

se scrie deasupra relatiei

Optionalitatea

relatie obligatorie

(TREBUIE)

linie continua

relatie optionala

(POATE)

linie intrerupta

Cardinalitatea

una si numai una

linie simpla              

una sau mai multe

picior de cioara

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:


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

2)      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

3)      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.

4)      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.

5)      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 1: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:

Tipul de date

Descriere

Dimensiune Maxima

VARCHAR2

Sir de caractere de lungime variabila

4000 bytes

CHAR

Sir de caractere de lungime fixa

2000 bytes
 

NUMBER(p,s)

Numar avand p cifre din care s la partea zecimala. (s negativ reprezinta numarul de cifre semnificative din fata punctului zecimal)

p (precizia) intre 1 si 38.

s (scala) intre -84 si 127.

DATE

Data calendaristica

De la

1 Ianuarie 4712 BC pana la 

31 Decembrie, 9999 AD.

TIMESTAMP

Se memoreaza data calendaristica, ora, minutul, secunda si fractiunea de secunda

Fractiunea de secunda este memorata cu o precizie de la 0 la 9.

INTERVAL YEAR

TO MONTH

perioada de timp in ani si luni.

INTERVAL DAY

TO SECOND

memoreaza un interval de timp in zile, ore, minute si secunde

 

CLOB

Character Large Object

4 Gigabytes

BLOB

Binary Large Object

4 Gigabytes

BFILE

Se memoreaza adresa unui fisier binar de pe disc

4 Gigabytes

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.

Figura I.3.4.

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.

Numele coloanei

Tip

Tip cheie

Optionalitatea

Marca

Number

Pk

*

Nume

Varchar2

*

Prenume

Varchar2

*

Data_angajarii

Date

*

Adresa

Varchar2

*

Telefon

Varchar2

o

Email

Varchar2

o

Marca_sef

Number

Fk

o

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

Numele coloanei

Tip

Tip cheie

Optionalitatea

denumire

Varchar2

Pk

*

Tabelul I.3.5. Tabela ATRIBUTE

Numele coloanei

Tip

Tip cheie

Optionalitatea

denumire_atribut

Varchar2

Pk

*

denumire_entitate

Varchar2

Pk, Fk

*

optionalitate

Varchar2

*

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

Numele coloanei

Tip

Tip cheie

Optionalitate

Id_angajat

Number

Pk

*

Nume

Varchar2

*

Adresa

Varchar2

*

Data_nasterii

Date

*

Id_departament

Number

Fk

*

Zona_vanzari

Varchar2

*

Permis_conducere

Varchar2

*

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

Numele coloanei

Tip

Tip cheie

Optionalitatea

Id_angajat

Number

Pk

*

Nume

Varchar2

*

Adresa

Varchar2

*

Id_departament

Number

Fk

*

Data_nasterii

Date

*

Bonus

Number

o

Id_depart_condus

Number

Fk

o

Zona_vanzari

Varchar2

o

Permis_conducere

Varchar2

o

Tip_angajat

Numeric

*

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

10

125

5

(null)

(null)

1

121

(null)

(null)

Transilvania

568147

2

245

(null)

(null)

(null)

(null)

3

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.



loading...







Politica de confidentialitate

DISTRIBUIE DOCUMENTUL

Comentarii


Vizualizari:
Deprecated: mysql(): This function is deprecated; use mysql_query() instead in /home/svadan38/public_html/calculatoare/baze-de-date/Colectarea-si-analizarea-datel33597.php on line 7213

Deprecated: mysql(): This function is deprecated; use mysql_query() instead in /home/svadan38/public_html/calculatoare/baze-de-date/Colectarea-si-analizarea-datel33597.php on line 7219
3880
Importanta: rank

Comenteaza documentul:

Te rugam sa te autentifici sau sa iti faci cont pentru a putea comenta

Creaza cont nou

Termeni si conditii de utilizare | Contact
© SCRIGROUP 2019 . All rights reserved

Distribuie URL

Adauga cod HTML in site