Normalizarea Bazelor de Date

3

Cuprins

Capitolul I ............................................................................................................... 5

Despre baze de date .............................................................................................. 5

Introducere .................................................................................................................. 6

1.1 Istoric[20] ............................................................................................................... 7

1.2 Elemente de fond .................................................................................................. 9

1.3 Arhitectura unei baze de date [13] ........................................................................ 9

1.4 Modele conceptuale pentru sisteme de gestiune a bazelor de date .................... 14

1.5. Proiectarea logică a datelor ............................................................................... 26

1.6. Obţinerea modelului logic de date ...................................................................... 31

CAPITOLUL II ....................................................................................................... 32

MODELUL LOGIC RELATIONAL. NORMALIZAREA .......................................... 32

Modelul logic relaţional ....................................................................................... 33

2.1. Concepte de bază [20] ....................................................................................... 33

2.2 Relaţii între tabele (Relationships)[12] ................................................................. 34

2. 3 Restricţii de integritate ........................................................................................ 36

2.4 Regulile lui Codd [17] .......................................................................................... 37

2.5.Proiectarea bazelor de date relaţionale [17] ........................................................ 38

2.6 Normalizarea bazei de date ................................................................................. 40

2.7 Prima formă normală (1NF – First Normal Form) [11] ........................................ 42

2.8 Dependenţe funcţionale [11] ................................................................................ 45

2. 9 A doua formă normală (2NF – Second Normal Form) [11] ................................. 46

2. 10 A treia formă normală (3NF – Third Normal Form) ........................................... 47

2.11 Studiu de caz ..................................................................................................... 50

CAPITOLUL III ...................................................................................................... 53

Aspecte didactice ale predării normalizării ....................................................... 53

în cadrul unităţii de învăţare ............................................................................... 53

4

"MODELAREA DATELOR” .................................................................................. 53

3.1 Experimentul didactic .......................................................................................... 54

3.2 Caracterizarea claselor cuprinse în experiment .................................................. 54

3.3 Unitatea de învăţare Modelarea datelor ............................................................. 55

3.4 Normalizarea. Prima formă normală .................................................................... 78

3.5 A doua formă normală ......................................................................................... 86

3.6 A treia formă normală .......................................................................................... 92

3.7 Proiect final ........................................................................................................ 101

Concluzii .................................................................................................................. 102

Bibliografie............................................................................................................... 104

5

Capitolul I

Despre baze de date

6

Introducere

Bazele de date se regăsesc la tot pasul în viaţa noastră de zi cu zi: la şcoală,

la magazin, la agenţia CFR sau la bancă, oriunde. În spatele acestor aplicaţii atât de

raspândite şi de uşor de utilizat se află o întreagă echipă care a analizat activitatea

respectivă, a identificat cerinţele beneficiarilor, a realizat un model care să permită

rezolvarea eficientă a acestor cerinţe, apoi l-au implementat, rezultând o bază de

date şi un pachet de programe care să permită exploatarea acesteia.

Modelarea datelor reprezintă prima etapă în dezvoltarea aplicațiilor orientate

pe baze de date şi constă în analiza datelor şi a relaţiilor dintre acestea în scopul

elaborării modelului conceptual.

Eficienţa modelului realizat este determinantă pentru aplicația creată.

Deşi pentru un dezvoltator de baze de date studiul modelării datelor este echivalent

cu studiul algoritmicii pentru un programator, modelarea datelor nu este studiată

sistematic şi riguros în şcoală, accentul fiind plasat pe partea de implementare şi de

exploatare.

Se studiază amănunţit elemente de sintaxă a unui limbaj de manipulare a

datelor şi cum se utilizează elementele limbajului pentru interogarea bazei de date,

dar... nu învăţăm să proiectăm baza de date. Nu învăţăm să comunicăm cu

beneficiarii, sa analizăm cerinţele acestora pentru a identifica datele relevante şi

relaţiile importante care există între acestea.

In lucrarea de faţă se încearcă să se arate rolul analizei proiectării bazelor de

date şi necesitatea realizării unor judecăţi cât mai corecte despre viziunea de

ansamblu a situaţiilor ce pot apărea în practică.

7

1.1 Istoric[20]

Când vine vorba despre stocarea informaţiilor, pentru unii acest termen

înseamnă o agenda veche în care sunt trecute toate datele importante de care au

nevoie: adrese, numere de telefon, informaţii financiare s.a.m.d.. Pentru cei din

domeniul IT şi nu numai, înseamnă sisteme dedicate special stocării datelor

importante.

În acest articol voi face o istorie a ceea ce înseamnă stocare datelor cu

ajutorul produselor informatice.

Primele baze de date erau dezvoltate pe sisteme mainframe şi erau

manipulate de oameni special pregătiţi pentru a gestiona aceste sisteme. Aceste

baze de date erau simple Sisteme de Gestiune a Bazelor de Date (SGBD). Primul

Sistem de Baze de Date Relaţionale (SGBDR) a fost lansat de Oracle

Corporation şi folosea limbajul de interogare SQL. Deşi versiunea originală a fost

dezvoltată pentru sisteme VAX/VMS, Oracle a fost unul dintre primii furnizori care

a lansat o versiune şi pentru sistemele PC pe sistemul de operare DOS.

La jumătatea anilor 80, Sybase a lansat propriul sau SGBDR - SQL Server.

Acesta avea biblioteci client pentru accesul la baza de date. Asigurând suportul

pentru proceduri rezidente (astăzi denumite "proceduri stocate") şi

interoperabilitatea cu o diversitate de reţele, SQL Server a devenit un produs de

succes în scurt timp, mai ales în mediile client/server.

O dată cu dezvoltarea sistemelor personale (PC), au apărut şi primele aplicaţii

de baze de date care foloseau un singur fişier pentru a stoca toata informaţia din

baza de date (denumite baze de date "flat file"). Ele erau de tip Xbase, un limbaj

care s-a răspândit foarte repede fiind folosit in special la manipularea datelor.

Sistemele care l-au folosit, daca mai este nevoie sa le enumer, au fost dBase,

FoxBase, FoxPro. Aceste versiuni rulau sub sistemul MS-DOS şi împărtăşeau

limitările acestuia. Cea mai răspândită aplicaţie care folosea limbajul xBase a fost

FoxPro, sistem dezvoltat de firma Fox Software. Chiar şi în zilele noastre există

firme care stochează alte extrem de importante în baze de date FoxPro, iar cel

mai cunoscut exemplu este cel al organizaţiei care gestionează Euro Tunel.

Aceasta foloseşte o aplicaţie care gestionează câteva sute de GB de date.

8

La începutul anilor 90, firma Microsoft Corporation a lansat aplicaţia Access,

aplicaţie care se bazează în mare parte pe logica de stocare a sistemului FoxPro,

sistem care fusese achiziţionat de firmă în 1989. Aplicaţia Access a devenit, în

scurt timp, cea mai folosită aplicaţie de gestiune a bazelor de date "flat file" de pe

sistemele personale. Ajuns acum la versiunea 9 (denumită 2000), sistemul de

stocare s-a schimbat fiind pregătit să fie scalat oricând către o baza de date

Microsoft SQL Server. Totodată, începând cu versiunea 7 i s-a adăugat un limbaj

de programare dedicat (Visual Basic for Applications - VBA), bazat pe limbajul de

programare Visual Basic. Prin intermediul acestuia se puteau manipula datele

mai uşor, se puteau folosi automatisme pentru diverse interogări, afişări etc.

Începând cu versiunea 9, limbajul integrat este compatibil cu Visual Basic şi cu

limbajul folosit de MS SQL Server.

În privinţa sistemelor server, piaţa s-a dezvoltat uimitor de repede deoarece s-

a constatat cât de folositoare sunt sistemele dedicate acestui lucru. Oracle a

lansat şi şi-a dezvoltat baza de aplicaţii server, astăzi ajungând la versiunea 9.

Începând cu versiunea şi, au fost introduse extensii orientate pe obiecte. Lansată

cu ocazia Oracle OpenWorld , Oracle şi reprezintă cea mai completă

infrastructura pregătită pentru rularea aplicaţiilor Internet. Oracle şi include Oracle

şi Database şi Oracle şi Application Server şi pachetul de unelte de dezvoltare

Oracle şi Developer Suite.

În ceea ce priveşte corporaţia Microsoft, aceasta a lansat tot în anul 2000

serverul de baze de date SQL Server 2000. Aplicaţia se doreşte a fi un concurent

direct pentru aplicaţiile Oracle, iar pentru acest fapt i s-a adăugat suport 100%

pentru limbajul XML prin intermediul căruia se poate interoga direct serverul dintr-

un browser (dacă serverul a fost configurat să suporte această facilitate).

Tot în 2000, compania IBM a lansat varianta 7 a aplicaţiei DB 2. Această

aplicaţie, ca şi Oracle, este implementata pe mai multe platforme (inclusiv Linux),

fiind o aplicaţie pur obiectuală. Şi pentru ca am ajuns la aplicaţii de baze de date

obiectuale, trebuie să amintim şi de aplicaţia companiei Computer Associates,

Jasmine. Deoarece despre aceasta aplicaţie nu se ştiu prea multe în România,

promit ca am sa revin cu mai multe detalii.

Pe sistemele Linux, cel mai folosit server de baze de date este MySQL. Cu

toate că există un alt produs gratuit (MySQL este gratuit atât timp cât aplicaţia

9

dezvoltata nu este revânduta) - PostgreSQL, MySQL rămâne preferatul

programatorilor de Linux. De ce? Pentru că limbajul cel mai folosit pe partea de

server web - PHP - dispune de o extensie MySQL înglobată. Dar nu numai acest

lucru a influenţat folosirea MySQL. Una dintre alegeri a fost şi datorită uşurinţei

administrării acestui sever, el dispunând de un client de accesare inclus.

1.2 Elemente de fond

Organizarea datelor se realizează intr-o formă centralizată care prezintă o serie

de avantaje:

1. reducerea redundanţei datelor memorate;

2. evitarea inconsistenţei datelor memorate;

3. posibilitatea partajării datelor;

4. încurajarea introducerii standardelor

5. posibilitatea aplicării restricţiilor de securitate;

6.Menţinerea integrităţii datelor.

Independenţa datelor este o problemă a cărei rezolvare constituie un scop

în sine în concepţia şi organizarea oricărei baze de date. Independenţa datelor

înseamnă ca există o delimitare netă între reprezentarea fizică a datelor şi

imaginea pe care o are utilizatorul asupra acestor date (memorarea şi orga-

nizarea datelor este transparentă pentru utilizator).

1.3 Arhitectura unei baze de date [13]

Arhitectura sistemului de baze de date este formată din următoarele

componente (Figura 1):

• baza/bazele de date – reprezintă componenta de tip date a sistemului (colecţiile de

date propriu-zise, indecşii);

• sistemul de gestiune a bazei/bazelor de date – ansamblul de programe prin care

se asigură gestionarea şi prelucrarea complexă a datelor şi care reprezintă

componenta software a sistemului de baze de date (Sistem de Gestiune a Bazelor de

Date – SGBD);

10

• alte componente – proceduri manuale sau automate, inclusiv reglementări

administrative, destinate bunei funcţionări a sistemului, dicţionarul bazei de date

(metabaza de date) care conţine informaţii despre date, structura acestora, elemente

de descriere a semanticii, statistici, documentaţii, mijloacele hardware utilizate,

personalul implicat.

Arhitectura internă a unui sistem de baze de date conform standardului

ANSI/X3/SPARC (1975) conţine trei niveluri funcţionale. O caracteristică

fundamentală a bazelor de date este aceea că produce câteva niveluri de

abstractizare a datelor prin ascunderea (transparenţa) detaliilor legate de stocarea

datelor, utilizatorilor.

Se defineşte modelul datelor, ca un set de concepte utilizat în descrierea structurii

datelor. Prin structura bazei de date se înţelege tipul datelor, legătura dintre ele,

restricţiile aplicate datelor. O structură de date asociată unei baze de date poate fi

reprezentată pe trei niveluri, Figura 2, astfel [17]:

Nivelul intern – constituit din schema internă ce descrie structura de

stocare fizică a datelor în baza de date, utilizând un model al datelor fizice.

La acest nivel se descriu detaliile complete ale stocării şi modul de acces la

date.

Nivelul conceptual – sau schema conceptuală, descrie structura întregii baze

de date pentru o cumunitate de utilizatori. La nivel conceptual se face o

descriere completă a bazei de date ascunzându-se detaliile legate de stocarea

fizică şi detaliind descrierea entităţilor, tipurilor de date, relaţiile dintre ele şi

restricţiile asociate.

Nivelul extern – sau nivelul vizual (utilizator), include o colecţie de scheme

externe ce descriu baze de date prin prisma diferiţilor utilizatori.

11

Scheme externe [6]

O schemă externă reprezintă conţinutul bazei de date aşa cum este ea văzută

de un utilizator particular.

Exemplu:

Pentru un utilizator poate să apară într-o vedere atributul număr străchini (=

numărul fragmentelor ceramice de tipul “N”), dar la nivel logic şi fizic acest atribut nu

este indicat, din cauza permanentei modificări a conţinutului său. În acest caz se

foloseşte la nivel logic atributul ceramică (= numărul total general de fragmente

ceramice) din care se scad atributele nr. oale, nr. farfurii, nr. chiupuri, etc. (= numărul

fragmentelor ceramice “M”≠”N”) din baza de date. Astfel se permite aflarea numărului

exact al fragmentelor ceramice de tip strachină din baza de date.

Pentru utilizatorul obişnuit, modul de definire a vederilor este transparent, el

putând să obţină sau să modifice informaţiile dorite prin intermediul unor comenzi cu

12

structură dată, folosind formule predefinite pe care le completează sau poate utiliza

un sistem de meniuri.

În reprezentarea intuitivă a vederilor intervin noţiunile de entitate, relaţie,

atribut, cheie, funcţionalitate, diagramă, şi altele pe care le vom definii ulterior.

Scheme conceptuale

O schemă conceptuală este o reprezentare a întregii informaţii conţinute în baza de

date ce combină subschemele vederilor ce privesc o anumită aplicaţie într-un model

unitar. Acest tip de schemă trebuie să se bazeze pe un model teoretic şi să fie

simplă, adică uşor de înţeles şi de prelucrat.

Sistemele de gestiune a bazelor de date au fost clasificate în trei grupe mari,

în funcţie de tipul elementelor cu care lucrează şi a structurilor obţinute:

a. modelul reţea – permite lucrul cu entităţi şi relaţii binare de

tipul 1:1 şi 1:N, diagrama rezultată fiind un graf oarecare;

b. modelul arborescent (ierarhic) – permite lucrul cu entităţi şi relaţii binare

de tipul 1:1 şi 1:N, iar diagrama este alcătuită dintr-o mulţime de arbori;

c. modelul relaţional – în care intervin numai relaţii şi operaţii cu aceste

relaţii.

Scheme interne

Schemele interne descriu diferitele fişiere utilizate pentru memorarea

informaţiilor bazei de date şi modul de operare cu ele. Există mai multe moduri de

organizare a fişierelor, cele mai cunoscute fiind:

organizarea secvenţială;

organizarea cu index rar;

organizarea cu index dens;

organizarea cu dispersie;

organizarea folosind B-arbori.

Sistemul de gestiune a bazelor de date (DBMS) este softul (programul)

care coordonează toate accesele la baza de date, în modul următor:

a. un utilizator emite o cerere de acces, folosind un limbaj particular de

manipulare a datelor;

b. DBMS-ul interceptează cererea şi o interpretează;

13

c. DBMS-ul inspectează, pe rând, schema externă, maparea

externă/conceptuală, schema conceptuală, maparea conceptuală/internă şi

definiţia de structură de memorare;

d. DBMS-ul realizează operaţiile necesare asupra bazei de date memorate.

Administratorul bazei de date (DBA) urmează apoi să gestioneze operaţiile

specifice, responsabilităţile lui incluzând:

decizia asupra conţinutului informaţiei inclusă în baza de date;

decizia asupra structurii de memorare şi a structurii de acces;

legătura cu utilizatorii;

definirea procedurilor de verificări autorizate şi de validări;

definirea unei strategii pentru salvări şi restaurări;

monitorizarea performanţei şi răspunsuri la schimbări de cerinţe.

Instrumentul utilizat de DBA în lucrul cu programele utilitare este dicţionarul

de date. El este o bază de date ce conţine date despre date, adică descrieri ale

obiectelor sistemului.

De asemenea atât DBA cât şi utilizatorul beneficiază de o interfaţă

utilizator pentru a uşura accesul la date. Această interfaţă poate fi definită ca un

ecran în sistem, sub care totul devine invizibil pentru utilizator. Interfaţa se află

întotdeauna la nivelul extern.

Într-un sistem de baze de date (DBMS) datele sunt memorate la locaţia la care

sunt folosite mai des, dar ele sunt disponibile (prin reţeaua de comunicaţii) şi

utilizatorilor din alte locaţii. Acest tip de bază de date, împrăştiată într-o reţea de

calculatoare se numeşte bază de date distribuite.

14

1.4 Modele conceptuale pentru sisteme de gestiune a bazelor de

date

1.4.1. Modelul entitate-relaţie (E-R)

1.4.2. Modelarea conceptuală a datelor folosind modelul E-R

1.4.3. Generalizarea

1.4.4. Paşi în modelarea datelor

1.4.5. Exemplu de modelare E-R

1.4.1 Modelul entitate-relaţie (Entity-Relaţionship Model, E-R, ERD) [19]

Lumea noastră bogată în tehnologie produce cantităţi vaste de fapte care au

nevoie de structură şi ordine.

Conceptele cu care lucrează sunt entitate, relaţie, atribut

Ca rezultat al utilizării acestei modelări se va obţine o diagramă E-R, în fapt schema

conceptuală .

Entitate

este un obiect distinct de lumea reală; poate fi o persoană, un lucru, un loc,

obiecte, evenimente, concepte din mediul utilizatorului pentru care organizaţia

doreşte să deţină date

exemple:

persoană: ANGAJAT, STUDENT, PACIENT

loc: STAT, REGIUNE, ŢARĂ

obiect: MAŞINĂ, CLĂDIRE, AUTOMOBIL

eveniment: VÂNZARE, ÎNREGISTRARE, SCHIMBARE

concept: CONT BANCAR, CURS UNIVERSITAR, CENTRU DE PRELUCRARE

Tip de entitate (clasă de entitate)

grupează toate entităţile care au proprietăţi sau caracteristici comune

se exprimă printr-un substantiv la singular (scris cu majuscule)

Instanţă de entitate (realizare a entităţii)

apariţie singulară a entităţii

De exemplu, să analizăm dacă este câinele o instanţă sau o entitate.

15

Depinde de:

- Dacă suntem interesaţi în diferite tipuri de animale, este logic să ne gândim

la un animal entitate cu câinele cazuri, pisica, cai şi aşa mai departe.

- Dar daca vom rula o afacere de câine-de rasă? Avem nevoie de a păstra

date despre rase diferite de câini, dar nu şi pe alte specii de animale.

- Pentru un câine-de rasa, aceasta este mai natural să ne gândim la un

câine cu instanţe ca CIOBĂNESC, DALMAȚIAN, LABRADOR şi aşa mai

departe.

Set de entităţi

reprezintă o colecţie de entităţi de acelaşi tip.

Notaţii E-R

Simboluri de bază

Gradul relaţiilor

Atributele

atribut:

proprietate sau caracteristică a unui tip de entitate care prezintă interes

este memorată în fiecare instanţă a tipului de entitate respective

toate instanţele unui tip de entitate au aceleaşi atribute

valorile unui atribut diferă de la o instanţă a lui E la alta

exemple de tipuri de entităţi şi atribute:

STUDENT: NUMĂR MATRICOL, NUME, ADRESĂ, NUMĂR TELEFON

ANGAJAT: MARCĂ, NUME, ADRESĂ, CALIFICARE

ŢARĂ: DENUMIRE, CONTINENT, SUPRAFAŢĂ, POPULAŢIE

AUTOMOBIL: NUMĂR ÎNMATRICULARE, CULOARE, GREUTATE, PUTERE

VÂNZARE: DATA, CINE VINDE, CUI VINDE, VALOARE

16

CURS UNIVERSITAR: DENUMIRE, SPECIALIZARE, SEMESTRU, PROFESOR,

NUMĂR ORE PE SĂPTĂMÂNĂ, FORMĂ DE EXAMINARE

Clasificarea atributelor unui tip de entitate

atribut cheie: identifică o instanţă a entităţii

cheie simplă - un singur atribut

cheie compusă - un grup de atribute

atribut non-cheie

Tipuri de atribute cheie

cheie candidat: identifică unic o instanţă a entităţii

o entitate poate avea mai multe chei candidat

cheie primară: cheia candidat ca identificator pentru tipul de entitate

atributele ce formează cheia primară sunt subliniate în diagrama E-R

cheie surogat: atribut artificial pe post de cheie primară

Stabilirea cheii primare CP a unei entităţi E [Bruce, 1992]

(i) cheia candidat a lui E care nu-şi modifică valoarea pe toată durata de viaţă a

oricărei instanţe

(ii) pentru orice instanţă a lui E, atributele lui CP au valori valide şi non-nule

(iii) dacă CP are prea multe atribute, se înlocuieşte cu o cheie surogat

(iv) nu folosim chei “inteligente” (clasificare, localizare, structurare)

Atribute şi cheie primară - reprezentare E-R

Atribute cu valori multiple

Atribut cu o singură valoare: o instanţă are o valoare pentru el

Atribut cu valori multiple (repetitiv): o instanţă are mai multe valori pentru el

17

Relaţii

relaţie:

asociere între instanţe ale uneia sau mai multor tipuri de entităţi care

prezintă interes pentru problema studiată

Relaţie în notaţia E-R

Relaţie cu atribut

Situaţie

Fie entităţile CÂNTEC şi GEN.

Putem avea un gen muzical fără nici un cântec?

De ce aveţi un gen muzical fără nici un cântec?

CÂNTECUL are un tip.

Câte genuri îi pot aparţine unui cântec?

Reguli de apartenenţă determină cardinalitatea sau gradul unei relaţii.

18

Gradul unei relaţii

numărul de tipuri de entităţi care participă în relaţie

Clasificarea relaţiilor după gradul lor:

unare sau recursive (de gradul 1)

binare (de gradul 2)

ternare (de gradul 3)

O relaţie se poate referi la o entitate în sine.

Examinați-va următorul scenariu.

Un angajat gestionează SALARIAŢI

Un angajat este gestionat de un angajat

„Fiecare angajat are un singur manager, inclusiv directorul general, care

gestionează el / ea. Fiecare manager poate gestiona mai mulţi angajaţi. "

Din moment ce managerii sunt, de asemenea, angajaţi, există o singură entitate

aici: Angajat.

Cardinalitatea unei relaţii

Luăm un exemplu

Fie entităţile CLIENŢI şi COMENZI.

19

CLIENT are comenzi: opţionalitate şi cardinalitate.

Opţionalitate: trebuie sau poate?

Fiecare comandă trebuie să fie plasată către un CLIENT.

Fiecare client trebuie să plaseze una sau mai multe comenzi.

Cardinalitatea = Câte?

Fiecare comandă trebuie să fie plasate către un (şi numai unul) CLIENT.

Fiecare client trebuie să plaseze una sau mai multe comenzi.

La modul general, considerăm două entităţi A şi B; numim cardinalitate:

de la entitatea A la entitatea B: numărul de instanţe ale entităţii B asociate

unei instanţe a entităţii A.

de la entitatea B la entitatea A: numărul de instanţe ale entităţii A asociate

unei instanţe a entităţii B.

Relaţii unare

Relaţii binare (stânga spre dreapta)

20

Relaţii binare (dreapta spre stânga)

Relaţie ternară

Exprimarea cardinalităţii m:M se pune la capătul B pentru relaţia de la A la B

m - cardinalitate minimă: numărul minim de instanţe ale lui B asociate unei instanţe a

lui A

M - cardinalitate maximă : numărul maxim de instanţe ale lui B asociate unei instanţe

a lui A

m = 0 - relaţie opţională

m > 0 - relaţie obligatorie

m = M - se specifică numai unul dintre ele

21

Exprimarea cardinalităţii în diagramele E-R [18]

1.4.2 Modelarea conceptuală a datelor folosind modelul E-R (entitate-relaţie)[16]

În faza de proiectare conceptuală a bazelor de date se proiectează schema

conceptuală şi schemele externe ale bazei de date.

Modelul Entitate-Relaţie (Entity-Relaţionship Model) este un model conceptual

de nivel înalt al unei baze de date, care defineşte mulțimile de entităţi şi asocierile

dintre ele, dar nu impune nici un mod specific de structurare şi prelucrare a datelor.

Elementele esențiale ale modelului Entitate-Relaţie sunt entitățile (entities) şi

asocierile dintre acestea (Relationships).

Toate entităţile similare, care pot fi descrise prin aceleaşi atribute, aparţin unui

acelaşi tip de entitate (entity type), iar colecţia tuturor entităţilor de acelaşi tip dintr-o

bază de date constituie o mulţime de entităţi (entities set). În general, în modelul E-A

se foloseşte aceeaşi denumire atât pentru un tip de entitate cât şi pentru mulţimea

entităților de acel tip.

Fie următorul exemplu între două entităţi:

Entitate A entitate B

Fiecare entitate A Opţionalitate (trebuie să fie / pot fi) Cardinalitatea entitatea B;

O relaţie are două sensuri, prin urmare deosebim:

22

entitate părinte

entitate dependentă (slabă)

Entitate părinte şi entitate dependentă

Intre două entităţi se poate stabili următoarea regulă: cheia primară a entităţii părinte

este prima componentă a cheii primare a entităţii slabe

Putem avea atribute cu valori multiple cum ar fi în exemplul de mai jos calificările

unui angajat mai multe la număr:

Pot apărea şi mai multe atribute cu valori multiple, de exemplu, pentru entitatea

STUDENT – vom avea atribute repetitive pentru DISCIPLINA, DATA EXAMEN,

NOTA:

23

Modelarea datelor dependente de timp (time-stamping)

Fie entitatea PRODUS din imaginea de mai jos; spre deosebire de situaţiile de mai

sus aici intervin atribute repetitive dependente de momentul în care un produs este

înregistrat:

24

1.4.3 Generalizarea[16]

Generalizare se numeşte procesul de minimizare a diferenţelor dintre entităţi, pentru

identificarea caracteristicilor comune.

Tehnici de gestionare:

– definirea şi descompunerea asocierilor;

– clasificarea în entităţi şi atribute;

– definirea asocierilor (se specifică gradul, conectivitatea şi obliga-

tivitatea);

– integrarea vederilor (pentru baze de date complexe diagramele

rezultate trebuiesc integrate având grijă să nu apară probleme de

redundanţă sau inconsistenţă)

1.4.4 Exemplu de modelare E-R [20]

2. Descrierea problemei

Vacanţe la Munte şi la Mare (VMM) este o firmă de turism care are în

proprietate şi închiriază cabane de vacanţă în toată ţara. Există două tipuri majore

de proprietăţi: montane şi marine. Majoritatea închirierilor se fac pe durata unei

săptămâni (unitatea de închiriere este săptămâna).

Se cere să se realizeze o aplicaţie pentru planificarea închirierii

proprietăţilor VMM.

2. Definirea entităţilor şi atributelor acestora

Modelarea conceptuală a datelor porneşte de la patru documente folosite

în sistemul de evidenţă manuală: Client, Contract de închiriere, Proprietate

marină şi Proprietate montană. Fiecare document va considerat ca entitate şi va fi

modelat separat.

2.1. Entitatea CLIENT

CLIENT

NUME ADRESĂ TELEFON SUMA

MAXIMĂ

Petre Ionescu Soporului 15, 3400 Cluj-Napoca 064-145321 200.000

Georgiana Duţu Mărului 21, 1900 Timişoara 056-234543 250.000

Romeo Tudor Fraţii Buzeşti 3/20, 75112

Bucureşti

01- 8989891 300.000

a) Documentul CLIENT

25

Entităţile PROPRIETATE MARINĂ şi PROPRIETATE MONTANĂ

Explicarea diagramei E-R

1. Există o relaţie între PROPRIETATE MARINĂ şi PROPRIETATE, ca şi între

PROPRIETATE MONTANĂ şi PROPRIETATE.

2. Există o relaţie numită Semnează între CLIENT şi CONTRACT DE

ÎNCHIRIERE. Cardinalitatea acesteia este opţională 0-M de la CLIENT la

CONTRACT DE ÎNCHIRIERE şi obligatorie de la CONTRACT DE ÎNCHIRIERE la

PROPRIETATE MARINĂ

STRADA ORAS JUDEŢ COD NUMĂR

CAMERE

CHIRIE

UZUALĂ

DISTANŢĂ

PLAJĂ

Valului 12 Mamaia, CT, 1200 3 75 2

Tomis 25 Mangalia, CT, 1230 4 120 1/2

PROPRIETATE MONTANĂ

STRADA ORAS JUDEŢ COD NUMĂR

CAMERE

CHIRIE

UZUALĂ

SCHI

Bradului 1 Sinaia, PH, 2200 3 150 C

Stibinei 2 Borşa, MM, 4230 4 75 C, F

(a) Documentele PROPRIETATE MARINĂ şi PROPRIETATE MONTANĂ

26

CLIENT. Prin urmare nu poate exista un contract de închiriere semnat şi fără

chiriaş valid.

1.5. Proiectarea logică a datelor

1.5.1. Modelul logic de date

1.5.2. Transformarea diagramelor E-R în relaţii

1.5.3. Transformarea entităţilor în relaţii (tabele) ale modelului relaţional

1.5.4. Reprezentarea relaţiilor din diagrama E-R în modelul relaţional

1.5.1. Modelul logic de date

Scopul modelării logice a datelor este obţinerea unui model de date adecvat

pentru implementare.

Caracteristicile unui model de date bun

Un model de date descrie structura datelor adică modul în care utilizatorul percepe

datele precum şi operaţiile efectuate asupra datelor (accesare, modificare):

• (a) simplitate

• (b) non-redundanţă

• (c) flexibilitate şi adaptabilitate la întreţinere

• (d) independenţa de maşină şi de softul de sistem folosit

Clase de modele logice de date

– ad-hoc

– ierarhic

– reţea

– relaţional

– orientat pe obiecte

Modelul ad-hoc

– fiecare aplicaţie are propriul său model de date

– caracteristici :

• lipsa controlului centralizat asupra datelor

• lipsa operaţiilor abstracte de manipulare a datelor

27

• dependenţa de implementarea concretă

• modele matematice: modelul relaţional şi modelul orientat pe

obiecte

Modelul ierarhic

– istoric: începutul/mijlocul anilor 70

– avantaje

• regăsire foarte eficientă a datelor

• adecvat modelelor stabile de date (nu se modifică în timp)

– dezavantaje

• rigiditate

• lipsă de flexibilitate

– orice modificare a definiţiei datelor provoacă reorganizări

masive

Modelul reţea

– istoric: începutul/mijlocul anilor 70

• generalizare a modelului ierarhic

– avantaje

• regăsire foarte eficientă a datelor

• mai flexibil decât modelul ierarhic

28

Modelul relaţional

– deosebirea faţă de modelul ierarhic: legăturile dintre

tabele nu se exprimă prin adrese fizice, ci prin valori de

câmpuri

– avantaje

• mai flexibil decât modelul reţea

• SQL - nivel înalt, neprocedural

– dezavantaje

• mai puţin eficient decât modelele anterioare

• o tabelă are structură liniară

• elementele unei coloane sunt de acelaşi tip

– implementări

• dBase, FoxPro

• Oracle

• Microsoft SQL Server

• Informix

Modelul orientat pe obiecte

- deosebirea faţă de modelul ierarhic :

– obiecte complexe, operaţii complexe (grafică,

transformare)

– avantaje

• elimină liniaritatea modelului relaţional

• aplicaţii specifice

– CAD, GIS,

29

1.5.2. Transformarea diagramelor E-R în relaţii

paşi

1. Transformarea entităţilor în relaţii (tabele) ale modelului relaţional

2. Reprezentarea relaţiilor din modelul E-R în modelul relaţional

Exemple

30

1.5.3. Transformarea entităţilor în relaţii (tabele) ale modelului relaţional

Fiecare tip de entitate din diagrama E-R se reprezintă printr-o tabelă, în care:

– (a) cheia primară a tabelei este cheia primară a tipului de entitate

– (b) fiecare atribut non-cheie al tipului de entitate devine atribut

(coloană) non-cheie a tabelei

1.5.4. Reprezentarea relaţiilor din diagrama E-R în modelul relaţional

Se adaugă chei străine la tabelele realizate în pasul anterior, care reprezintă relaţiile

existente între entităţile corespunzătoare

Există următoarele situaţii distincte:

– (i) relaţii binare (a) 1:N, 0:N şi (b) 1:1

– (ii) relaţii binare M:N

– (iii) relaţii unare

– (iv) relaţii ISA

(ia) Relaţii binare 1:N şi 0:N A (1) R (1-N) B, A (1) R (0-N) B şi A (1) R (1) B

– cheia primară a entităţii A se adaugă pe post de cheie străină în tabela

B

– PACIENT (1) are (1-M) FIŞĂ DE CONSULTAŢIE

• FIŞĂ DE CONSULTAŢIE(DATA, MEDIC, DIAGNOSTIC, COD

PACIENT)

– FILM (1) este stocat sub formă de (0-M) COPIE FILM

• COPIE FILM(NUMĂR COPIE, TIP SUPORT, ANUL

FABRICAŢIEI, COD FILM)

(ib) Relaţii binare 1:1 A (1) R (1) B

– variante de rezolvare

• cheia primară a lui A se adaugă pe post de cheie străină la B

• cheia primară a lui B se adaugă pe post de cheie străină la A

• ambele de mai sus

(ii) Relaţii binare M:N şi 0:N A (1-M) R (1-N) B

• se creează o nouă tabelă C cu cheia primară formată din cheia

primară a lui A + cheia primară a lui B; dacă R are atribute,

acestea se adaugă la C (coloane non-cheie)

31

(iii) Relaţii unare A (0-1) R (0-1) A şi A (1) R (1-M) A

• se adaugă la A un atribut nou, pe post de cheie străină, care

este cheia primară a instanţei cu care A este în relaţie;numele

atributului trebuie să sugereze relaţia

– PERSOANĂ (0-1) este căsătorită cu (0-1) PERSOANĂ

PERSOANĂ(COD NUMERIC PERSONAL, NUME, ADRESĂ, DATA NAŞTERII,

COD NUMERIC PERSONAL SOŢ)

1.6. Obţinerea modelului logic de date

paşi

1. Verificarea entităţilor

2. Normalizarea entităţilor din modelul E-R

1.6.1. Verificarea entităţilor

Precondiţie pentru normalizare: orice tip de entitate trebuie să aibă cheie primară.

Situaţii posibile

(a) entităţile din modelul conceptual de date au specificată cheia primară:

• se verifică dacă cheia primară asigură proprietatea de

identificare unică, folosind conceptul de dependenţă

funcţională (BD)

(b) entităţile din modelul conceptual de date au specificate numai atributele:

• se determină cheile candidat

• se alege dintre ele cheia primară

• dacă cheia candidat are prea multe atribute, se poate

introduce o cheie surogat

1.6.2. Normalizarea entităţilor din modelul E-R

– respectă etapele descrise la normalizare (BD)

• relaţie cu tip de entitate (entitate)

• linie cu instanţă de entitate

– la fiecare pas se examinează toate entităţile curente

– se produc entităţi noi, iar cele existente sunt supuse revizuirii

32

CAPITOLUL II

MODELUL LOGIC RELATIONAL. NORMALIZAREA

33

Modelul logic relaţional

2.1. Concepte de bază [20]

Modelul relaţional îşi datorează numele noţiunii matematice numită RELAŢIE. O

relaţie poate fi simbolizată astfel: R(a1, a2, a3,an) unde R=numele relaţiei, a1, a2, ... an

sunt numele atributelor sau ale constituenţilor.

Prin definirea şi utilizarea operatorilor relaţionali, teoria relaţiilor permite

fundamentarea cercetărilor efectuate în domeniul proiectării bazelor de date

relaţionale şi al limbajelor relaţionale. Algebra relaţională conţine, pe lângă operatorii

de mulţimi care tratează relaţiile ca pe mulţimi de elemente cu operaţiile cunoscute

{reuniunea, intersecţia, diferenţa, produsul cartezian) şi operatorii relaţionali specifici

(selecţia, proiecţia, compunerea sau joncţiunea).

Fără a intra în fundamentele matematice ale modelului relaţional, dorim să ne

familiarizăm cu termenii şi conceptele specifice acestui model.

O relaţie este o tabelă; o realizare este o linie sau un tuplu; un atribut este o

coloană

Cheia primară a unei relaţii este un atribut (sau grup) care identifică fără

ambiguitate fiecare linie a relaţiei. Atunci când cheia este compusă, nici un atribut al

său nu poate fi eliminat fără distrugerea unicităţii tuplului.

O cheie străină este un grup de atribute care pune în legătură linii din două relaţii

(tabele).

Legătura dintre tabele este stabilită între o tabelă (numită părinte) şi o alta

(numită copil) prin intermediul unui câmp comun.

Ca efect, atunci când se deplasează pointerul de fişier în tabela părinte,

automat se poziţionează şi pointerul fişierului copil pe primul articol care are valoarea

cheii egală cu cea din fişierul părinte.

34

2.2 Relaţii între tabele (Relationships)[12]

Relaţiile se formează prin stabilirea unei legături între un câmp (o combinaţie

de câmpuri) dintr-un tabel şi câmpurile corespunzătoare din alt tabel.

Legăturile între tabele sunt de trei tipuri:

1. Relaţia unu-la-unu (one-to-one)- are loc între două tabele care au aceeaşi cheie

primară. Se defineşte prin intermediul ei o tabelă compusă din cele două tabele

iniţiale. Relaţia este utilă în cazul structurilor mari, care au nevoie de mai mult de

255 de câmpuri (limita Access-ului pentru un singur tabel) sau pentru creşterea

vitezei de căutare a datelor, dacă nu toate înregistrările din primul tabel au

corespondent în al doilea tabel.

Fie entităţile Clase->1,1->Profesori cu relaţia „diriginte".

Clase profesori

1:1 (diriginte)

Entitatea Clase are atributele cod, profil, sala, iar cod este cheia unică de

identificare. Entitatea Profesori are atributele cod, nume, specialitatea, iar cod este

cheia de identificare. Pe baza acestei relaţii putem afla pentru o clasă X care este

specializarea profesorului

diriginte şi plecând de la profesorul X putem afla care este profilul clasei la care

este diriginte, dacă are această atribuţie.

în modelul relaţional atributele vor fi grupate în două tabele:

a. tabela CLASE(cod, profil, sala, cod-dirig), unde cod este codul unic al clasei şi

este cheie primară cod-dirig este codul profesorului diriginte şi este cheie externă

pentru că face legătura cu tabela Profesori şi este un atribut unic, deoarece o clasă

nu poate avea decât în singur diriginte.

b. tabela PROFESORI(cod, nume, specialitate, cls-dirig), unde cod este codul unic

al profesorului cheie primară, clasa-dirig este codul clasei la care este diriginte şi este

cheie externă unică pentru că face legătura cu o singură linie din tabela Clase.

2. Relaţia unu la mai mulţi (one-to-many) – este cea mai frecvent utilizată şi se

realizează între cheia primară a tabelei T1 şi un câmp similar, ca tip şi ca dimensiune

din T2, numit şi cheie străină. Semnificaţia legăturii este că oricărei valori a câmpului

cheie străină-C21 trebuie să-i corespundă o valoare a câmpului cheie cheie-C1. În

timp ce în tabela T1 valoarea este unică, în tabela T2 ea se poate repeta de un

număr infinit de ori.

Cod, profil,

sala

Cod, nume,

specialitate

35

Tabela T1 Tabela T2

C1 – Primary Key C2 – Primary Key

................ C21 – Foreign Key

................ ..........

Fie entităţile Clase->1, n->Elevi, cu relaţia „învaţă". Entitatea Clase are atributele

cod, profil, sala, iar cod este cheia de identificare unică.

Entitatea Elevi are atributele cod, nume, adresa, medie, iar cod este cheia de

identificare. Pe baza acestei relaţii putem afla pentru o clasă X care sunt elevii clasei,

iar pentru elevul X putem afla care este profilul şi dirigintele clasei în care învaţă.

Clase elevi

Invaţă (1:n)

Relaţia 1-n presupune crearea a două tabele în modelul relaţional:

CLASE(cod, profil, sala, cod-dirig), unde cod este codul unic al clasei şi este cheie

primară

ELEVI(cod, nume, media, cod-clasa) unde cod este codul unic al elevului şi cheie

primară, iar cod-clasa este codul clasei unde învaţă elevul şi este cheie externă pentru

că face legătura cu tabela Clase. Valorile acestui atribut nu sunt unice - pentru că o

clasă poate avea mai mulţi elevi.

CLASE

Cod Profil sala Alte-

informații

12a Info P2

12b ştiinte 15

12 Litere P6

ELEVI

Cod Nume Media Cod-

clasa

lonescu 7.50 12b

2 Albulescu 10 12c

3 Enachescu 8.90 12 c

4 Enache 10 12a

5 Anania 8.00 12b

1

Cod, profil,

sala

Cod, nume,

medie

36

3. Relaţia mai mulţi la mai mulţi (many-to-many) – se aplică la cazurile în care

valorii unui câmp din prima tabelă îi corespund mai multe valori în a doua tabelă şi

invers, unei valori a unui câmp din a doua tabelă îi corespund mai multe valori din

prima tabelă.

T3.

O schemă relaţională poate fi definită ca un ansamblu de relaţii asociate semantic

prin domeniul lor de definiţie şi prin anumite restricţii de integritate. Schema relaţională

este independentă în timp.

2. 3 Restricţii de integritate

Păstrarea integrităţii unei baze de date se realizează prin reguli de integritate, ce

sunt memorate odată cu structura bazei şi se verifică la orice acţiune asupra bazei.

Regulile de integritate pot fi:

a. Restricţiile cheilor primare - se referă la condiţia de unicitate şi de valori non-

nule;

b. Restricţii referenţiale - apar atunci când o tabelă este în relaţie cu alta. De

exemplu, cheia străină nu trebuie să aibă valori care nu se regăsesc drept

valori ale cheii primare în tabela de referinţă.

c. Restricţii de comportament - pot fi impuse asupra valorilor diferitelor atribute

sau asupra întregii înregistrări.

37

2.4 Regulile lui Codd [17]

1. Regula reprezentării logice a datelor: Intr-o baza de date Relaţională, toate datele

sunt reprezentate la nivel logic intr-un singur mod, şi anume sub formă de valori

logice în tabele.

2. Regula accesului la date: Toate datele individuale din tabele trebuie sa fie

accesibile prin furnizarea numelui tabelului, numelui coloanei si valorii cheii

primare.

3. Regula reprezentării valorilor necunoscute: Un sistem Relaţional trebuie sa

permită declararea si manipularea sistematica a valorilor Null, cu semnificaţia unor

valori necunoscute sau inaplicabile.

4. Regula dicţionarului de date: Descrierea bazei de date (dicţionarul de date)

trebuie să fie reprezentată la nivelul logic tot sub forma de tabele, astfel încât asupra

acesteia

sa se poată aplica aceleași operații ca si asupra datelor propriu-zise.

5. Regula limbajului de acces: Intr-un sistem Relaţional trebuie sa existe cel putin

un limbaj de accesare a datelor, care sa asigure următoarele operații: definirea

tabelelor

de baza si a tabelelor virtuale (view-uri, vederi); manipularea si interogarea datelor

(atât interactiv cat si prin program); definirea restricțiilor de integritate, autorizarea

accesului la date, delimitarea tranzacțiilor.

6. Regula de actualizare a tabelelor virtuale: Un SGBD trebuie sa poată determina

daca o vedere poate sa fie actualizata sau nu.

7. Regula manipulării datelor: Un sistem Relaţional trebuie sa ofere posibilitatea

procesării tabelelor nu numai in operațiile de interogare a datelor cat si in cele de

inserare, actualizare si ștergere.

8. Regula independentei fizice a datelor: Programele de aplicaţie nu trebuie sa

depindă de modul de stocare si accesare fizica a datelor.

9. Regula independentei logice a datelor: Programele de aplicaţie nu trebuie sa fie

afectate de nici o restructurare logica a tabelelor bazei de date care conserva datele.

10. Regula independentei datelor din punctul de vedere al integrității: Regulile de

integritate a bazei de date trebuie sa fie definite in limbajul utilizat de sistem pentru

38

definirea datelor şi nu in cadrul aplicațiilor individuale; in plus, aceste reguli de

integritate trebuie stocate in dicționarul de date.

11. Regula independenţei datelor din punctul de vedere al distribuirii: Programele de

aplicaţie nu trebuie sa fie afectate de distribuirea pe mai multe calculatoare a bazei

de date.

12. Regula privind prelucrarea datelor de către un limbaj de nivel inferior: Orice limbaj

Relaţional folosit pentru accesarea datelor trebuie sa respecte aceleaşi condiţii de

integritate ca şi limbajul Relaţional de acces.

0. Regula de baza: Un SGBD Relaţional trebuie sa fie capabil sa gestioneze

baza de date exclusiv pe baza caracteristicilor sale Relaţionale.

2.5.Proiectarea bazelor de date relaţionale [17]

Etape

I. Crearea schemei conceptuale

II. Crearea design-ului logic al bazei de date

III. Normalizarea bazei de date

I Crearea schemei conceptuale [12]

Aici avem modelul entitate-relaţie, model entitate-legatură şi model

relaţional.

Model entitate-relaţie

39

Model entitate-legătură

O entitate devine un tabel Un atribut al unei entităţi devine o coloana a tabelului respectiv

II Crearea design-ului logic al bazei de date

Transformarea entităților

• Entitățile devin tabele

• Entitățile dependente devin tabele dependente

• Subentităţile devin subtabele.

Transformarea relaţiilor

• Relaţiile 1:1 devin chei străine, cheia străină fiind plasată în tabelul cu mai puţine

înregistrări.

• Relaţia N:1 devine cheie străină plasate în tabelul care se afla in partea “mulți” a

relaţiei. Exemplu: o facultate are mai mulți studenți, un student e la o singura

facultate

• O relaţie mulţi-mulţi N:M se transformă intr-un tabel asociativ, care are doua chei

străine pentru cele două tabele asociate. Exemplu: mai mulți studenţi-la mai multe

cursuri.

Transformarea atributelor

• Atributele simple ale unei entităţi devin coloane in tabelul provenit din Relaţie.

• Atributele repetitive (multivaloare) devin tabele dependente care conțin o cheie

străina ce face referința la cheia primară a entității şi atributul multi-valoare.

40

• Atributele simple ale unei Relaţii M:N vor deveni coloane ale tabelului asociativ.

2.6 Normalizarea bazei de date

Conform Wikipedia, a normaliza o bază de date înseamnă o modelare logică

a structurii acesteia pentru a o pregăti să satisfacă o actuală şi potenţial viitoare plajă

largă de cereri.

Obiectivele normalizării sunt patru la număr:

a) eliminarea anomaliilor de adăugare, actualizare și ștergere a datelor dintr-o bază

de date.

b) reducerea necesităţii de a reorganiza tabelele dintr-o bază de date în cazul în care

sunt introduse noi tipuri de date, mărind astfel durata de viaţă a aplicaţiilor construite

pe respectiva bază de date.

c) modelul relaţional să fie cât mai intuitiv pentru utilizatori.

d) tabele dintr-o bază de date nu trebuie să fie proiectate doar pentru anumite

cereri/query-uri.

Scopul normalizării [11]

Normalizarea reprezintă o tratare de jos în sus a proiectării bazelor de date,

care începe prin examinarea relaţiilor dintre atribute. Totuşi, de multe ori metodologia

de proiectare abordează o tratare de sus în jos a BD (care începe prin identificarea

principalelor entităţi şi relaţii), caz în care normalizarea este folosită ca tehnică de

validare.

Unul din principalele scopuri urmărite la proiectarea BD relaţionale, este

gruparea atributelor în relaţii în aşa fel încât să se minimizeze redundanţa

datelor şi prin aceasta să se reducă spaţiul de stocare necesar relaţiilor de bază

implementate.

Anomaliile de reactualizare se clasifică în:

• anomalii de inserare care pot fi de două tipuri:

− anomalii privind identitatea datelor redundante: de ex, pentru

inserarea noilor membri ai personalului, trebuie incluse detalii

despre filiala la care vor lucra, detalii care trebuie să coincidă cu

41

valorile aflate pe celelalte rânduri ale relaţiei, altfel provocăm o

incoerenţă a BD.

− anomalii privind necesitatea introducerii de rânduri cu null pentru

cheia primară: de ex, pentru a insera o nouă filială, care nu are nici

un personal, este necesară introducerea de null-uri pentru atributele

personalului; dar PersID este cheie primară şi nu e permis null-ul

(deoarece se violează integritatea entităţilor)

• anomalii de ştergere: ştergerea anumitor înregistrări duce la pierderea unor

detalii care nu sunt stocate în altă parte: dacă se şterge ultimul membru al

personalului de la o filială, se pierd detaliile despre filială

Procesul de normalizare este o metodă formală, care identifică relaţiile

bazându-se pe cheile primare ale acestora şi pe dependenţele funcţionale dintre

atributele lor. Normalizarea ajută proiectanţii de BD, prin prezentarea unei serii de

teste care pot fi aplicate relaţiilor individuale, pentru a preveni apariţia anomaliilor

de reactualizare.

• anomalii de modificare: necesitatea modificării unei date redundante,

presupune modificarea ei în toate înregistrările în care ea apare: dacă trebuie

modificat unul din atributele unei filiale, este necesară reactualizarea rândurilor

corespunzătoare pentru toţi membrii personalului de la filiala respectivă, altfel

BD devine incoerentă.

Această analiză arată că relaţiile Personal şi Filiala au o structură mai bună

decât PersonalFiliala. Procesul de normalizare furnizează o tehnică de

proiectare a unor relaţii mai bine structurate.

Proiectarea unei baze de date relaţionale începe prin definirea entităţilor şi a

relaţiilor dintre ele. Apoi se definesc tabelele care vor memora atât datele din

entităţi, cât şi relaţiile dintre acestea. Atenţia proiectanţilor trebuie îndreptată către

construirea unor tabele care să evite anomaliile de actualizare şi dificultăţile de

prelucrare.

O tabelă de date este corect formulată - deci este o relaţie conform restricţiilor

impuse de teoria relaţiilor a lui A.F. Codd - dacă:

1. în cadrul unei baze de date are nume distinct;

2. fiecare celulă a relaţiei conţine o singură valoare;

42

3. fiecare atribut are un nume distinct;

4. orice valoare a unui atribut face parte din domeniul pe care a fost definit acesta;

5. ordinea dispunerii atributelor în relaţie nu prezintă importanţă;

6. orice linie este distinctă de celelalte;

7. ordinea liniilor nu influenţează conţinutul informaţional al relaţiei.

2.7 Prima formă normală (1NF – First Normal Form) [11]

Prima formă normală este o formă normală utilizată în normalizarea bazelor

de date.

Prima formă normală exclude posibilitatea existenţei grupurilor repetitive

cerând ca fiecare câmp într-o baza de date sa cuprindă numai o valoare

indivizibilă . De asemenea, prima formă normală cere şi ca fiecare înregistrare

să fie definită astfel încât să fie identificată în mod unic prin intermediul unei

chei primare.

Încălcări ale primei forme normale (1) Mai multe valori semnificative in acelaşi câmp

EXEMPLUL 1

După procesul de normalizare vom avea următoarele tabele:

Persoana Jocuri preferate

Ion Doom2, Zelda, Sims

Maria Zelda, Sims, SuperMario

Daniel WOW, Zelda

Oras Servicii publice

Bucuresti Politie, Salubritate, Canalizare

Brasov Politie, Canalizare, Salubritate

Scornicești Politie

43

(2) Mai multe coloane reprezentând acelaşi tip de date/fapte/obiecte

EXEMPLUL 2:

O soluţie după normalizare:

ID Oraș Servicii publice

1 București Politie

2 Brașov Politie

3 Scornicești Politie Oraș Servicii publice

4 București Salubritate București Politie

5 Brașov Canalizare Brașov Politie

6 București Canalizare Scornicești Politie

7 Brașov Salubritate București Salubritate

Brașov Canalizare

București Canalizare

Brașov Salubritate

Pentru a asigura unicitatea unei înregistrări, se va utiliza cheia primară. In exemplul

de mai sus, prin introducerea unei coloane adiţionale de tip întreg, auto-incrementat,

se asigură unicitatea fiecărei înregistrări.

Exemplul 3 [11]

Persoana Jocuri preferate(1) Jocuri preferate(2) Jocuri preferate(3)

Ion Doom2 Zelda Sims

Maria Zelda Sims SuperMario

Daniel WOW Zelda

Oras Servicii publice Servicii publice(2) Servicii publice(3)

București Politie Salubritate Canalizare

Brașov Canalizare Politie Salubritate


44

Să presupunem că tabelul următor reţine codurile produselor solicitate la o

comandă, precum şi numărul, data şi valoarea comenzii:

Verificăm respectarea definiţiei anterioare: nu sunt linii identice, nu sunt valori de

tipuri diferite în coloane, cheia este atributul Com (număr comandă).

Dar

1. dacă există comenzi cu mai mult de 4 produse?

2. dacă sunt comandate cantităţi diferite din toate produsele?

3. unde este plasat preţul fiecărui produs?

4. prelucrări de tipul« valoarea totală a comenzilor pentru produsul 'b66'»

necesită verificarea tuturor coloanelor şi însumarea rezultatelor pentru

întreaga bază de date, lucru care conduce la un timp mare de răspuns.

Deci se impune eliminarea câmpurilor care se repetă şi astfel se ajunge la prima

formă normală:

Prima formă normală este identificată cu noţiunea de relaţie

Dar nu toate relaţiile sunt egal acceptabile, deoarece anumite relaţii pot conduce la

dificultăţi de actualizare sau de manevrare.

Operaţia de „spargere" a relaţiei care manifestă anomalii în alte relaţii

poartă numele de normalizare.

O relaţie se află în a doua formă normală dacă toate atributele non-cheie sunt

dependente de întreaga cheie

Deci problema apare când cheia este compusă din mai multe atribute O relaţie car

are chei simple este în a doua formă normală.

Comanda data furn adr cod1 cod2 cod3 cod4 cant val 006 01.03.2011 f1 Bc a23 b66 c33 10 1290

007 01.09.2011 f1 Bc c33 12 1200

comanda data furn adr codprod cant pret valoare

006 01.03.11 f1 Bc a23 10 100 1298

006 01.03.11 f1 Bc b66 10 200 1298

006 01.03.11 f1 Bc c33 10 150 1298

007 01.09.11 f1 Bc c33 12 150 1200 în această tabelă, cheia este compusă din atributele (comanda + codprod).

45

Observăm că atributele non-cheie nu sunt dependente de întreaga cheie. Normalizăm şi

împărţim tabela în două alte tabele.

2.8 Dependenţe funcţionale [11]

Dependenţele funcţionale sunt concepte fundamentale în procesul de

normalizare.

Când există o dependenţă funcţională, ea este specificată ca o constrângere între

atribute. Atributul din stânga săgeţii se numeşte determinant.

Exemplu: să considerăm atributele PersID şi Salariu din relaţia Personal

Personal (PersID, NumeP, AdresaP, Funcţie, Salariu, FilialaID)

PersID → Salariu deci un membru al personalului are un singur salariu

Salariu ×→ PersID un salariu nu determină un singur membru al personalului

Exemplu: Să identificăm dependenţele funcţionale din relaţia PersonalFiliala

PersonalFiliala (PersID, NumeP, AdresaP, Funcţie, Salariu, FilialaID, AdresaF,TelF)

Dependenţa funcţională descrie legăturile dintre atributele unei relaţii: fie

A şi B două atribute ale relaţiei R; atributul B este dependent funcţional de A (notat

A→B) dacă fiecărei valori a atributului A îi corespunde o singură valoare a

atributului B. A şi B pot fi simple sau compuse.

PersID → NumeP PersID → AdresaP, PersID → Funcţie, PersID → Salariu, PersID→ FilialaID, PersID → AdresaF, PersID → TelF, FilialaID→ AdresaF, FilialaID→ TelF, AdresaF→ FilialaID, AdresaF→ TelF, TelF→ FilialaID, TelF→ AdresaF În această relaţie sunt 13 dependenţe funcţionale cu PersID, FilialaID, AdresaF şi

TelF ca determinanţi.

Pentru a identifica cheia candidat (sau cheile candidat) din relaţia

PersonalFiliala, este necesar să recunoaştem atributul (sau grupul de atribute)

care identifică în mod unic fiecare rând din relaţie. Dacă o relaţie are mai mult de o

chei candidat, trebuie identificată cheia primară. Toate atributele care nu fac parte din

cheia primară, trebuie să fie dependente funcţional de această cheie. Singura cheie

candidat pentru relaţia PersonalFiliala (deci şi cheie primară) este PersID, deoarece

toate celelalte atribute ale relaţiei sunt dependente funcţional de aceasta. Cu toate că

atributele FilialaID, AdresaF, TelF sunt determinanţi în această relaţie, ele nu

constituie chei candidat pentru ea.

46

In orice relaţie, atributele sunt dependente funcţional de faţă de cheile

acesteia, deoarece orice cheie are proprietatea că identifică în mod unic fiecare

tuplă, deci determină în mod univoc valorile atributelor tuplei.

2. 9 A doua formă normală (2NF – Second Normal Form) [11]

A doua formă normală cere ca toate elementele unei tabele sa fie dependente

funcţional de totalitatea cheii primare.

Dacă unul sau mai multe elemente sunt dependente funcţional numai de o parte a

cheii primare, atunci ele trebuie sa fie separate în tabele diferite.

Dacă tabela are o cheie primară formata din numai un atribut, atunci ea este automat

in 2NF (a 2-a forma normala).

Exemplul 1: fie o tabela “Comanda”:

Cheia primară este o cheie compusa, formata din ComandaID şi ReperID.

ReperNume depinde numai de ReperID, nu si de ComandaID.

Pentru a fi in 2NF, tabelul trebuie modificat in felul următor:

Exemplul 2

Fie următorul tabel:

Cod Comanda

ReperID ReperNume Cantitate

C1 2 Memorie 1

C2 2 Memorie 2

C1 21 Mouse 31

C4 22 Tastatura 22

47

cod client nume client

nr telefon cod comanda data cod articol nume_articol cost articol

cantitate

A1 Petrescu 2338291 C1 12.05.2008 P1 pantalon 50

100

A1 Petrescu 2338291 C1 12.05.2008 P3 camasa 45

20

A2 Vasilescu 3485734 C2 13.05.2008 P1 pantalon 50

200

A2 Vasilescu 3485734 C2 13.05.2008 P3 camasa 45

300

A2 Vasilescu 3485734 C2 13.05.2008 P2 bluza 35

10

A1 Petrescu 2338291 C3 13.05.2008 P3 camasa 45

20

A3 lonescu 5409054 C4 13.05.2008 P1 pantalon 50

30

Dependenţe funcţionale : cod_client -> {nume_client, număr_telefon} cod_comanda -> {data, cod_client, nume_client, nr_telefon} cod_articol -> {nume_articol, cost_articol}

Pentru a fi in 2NF, tabelul trebuie modificat in felul următor:

cod_articol nume_articol cost_articol

P1 pantalon 50

P2 bluza 35

P3 camasa 45

VÂNZĂRI

cod comanda cod_articol cantitate

C1 P1 100

C1 P3 20

C2 P1 200

C2 P3 300

C2 P2 10

C3 P3 20

C4 P1 30

2. 10 A treia formă normală (3NF – Third Normal Form)

COMANDA

cod_comanda data cod_client

C1 12.05.2008 A1

C2 13.05.2008 A2

C3 13.05.2008 A1

C4 13.05.2008 A3

48

Toate atributele non-chei ale unei relaţii depind numai de chei candidate ale acelei relaţii. Toate atributele non-cheie sunt (trebuie sa fie) mutual independente. EXEMPLUL 1

Tabela Piese de schimb, in care cheia primară (şi cheie unică) este Piese de

schimb

trebuie reorganizată astfel pentru a fi in a 3-a forma normală:

Producător

ProducătorNume ProducatorAdresa

Dacia Pitesti

Daewo Mangalia

Dacia Pitesti

EXEMPLUL 2

Fie tabelele de mai jos:

Să urmărim exemplul în continuare. Cheia relaţiei la tabela COMENZI este

comanda. Ştiind numărul de comandă, putem afla numele furnizorului. Deci

(comanda)>>>(furn). Ştiind furnizorul, putem determina adresa (furn)>>>(adr). Pare

că adresa depinde funcţional prin tranzitivitate de comandă, ceea ce nu este

adevărat.

O relaţie se află în a treia formă normală dacă se află în forma a doua şi nu

prezintă dependenţe tranzitive

După normalizare se obţine:

Piese de schimb ProducatorNume ProducatorAdresa

1256 Dacia Pitesti

1425 Daewo Mangalia

1621 Dacia Pitesti

Pi Piese de schimb

Piese de schimb ProducatorNume

1256

Dacia

1425

Daewo

1621

Dacia

COMENZI PRODUSE comanda Data furn adr valoare comanda codprod cant pret

006 01.03.2011 f1 Bc 1298 006 a23 10 100

007 01.09.2011 f2 Gl 1200 006 b66 10 200 006 c33 10 150 007 c33 12 150

49

Ca o recapitulare:

Prima formă normală este identificată cu definiţia unei relaţii.

A doua formă normală impune ca toate atributele non-cheie să fie dependente de

întreaga cheie.

A treia formă normală presupune inexistenţa dependenţelor tranzitive.

In concluzie prin normalizare spectrul anomaliilor de care suferă o relaţie se

restrânge foarte mult. Toate aceste forme normale sunt folositoare, dar niciuna

nu garantează că au fost eliminate toate anomaliile!

FURNIZORI COMENZI

codfurn adr

comanda

data furn val

f1 Bc 006 01.03.2011 f1 12980

f2 Gl 007 01.09.2011 f2 12000

50

2.11 Studiu de caz

Evidenţa meciurilor, a echipelor şi a jucătorilor de fotbal din cluburile

româneşti [10]

Să facem analiza şi să proiectăm structura unei baze de date pentru cerinţa de mai

sus. Pentru analiza problemei trebuie sa răspundem la următoarele întrebări:

• Care sunt entităţile? Jucători, echipe, meciuri.

• Care sunt atributele, caracteristicile pentru fiecare entitate?

JUCĂTORI (cod, nume, datanasterii, foto, CV, este-casatorit, are_copii, adresa),

ECHIPE (cod echipa, nume, dataînfiintarii, sediu),

MECIURI (cod_meci, echipa 1, echipa_2, goluri_1, goluri_2, stadion, data, ora)

• Care sunt Relaţiile dintre ele?

Un jucător poate sa fi fost înscris la mai multe echipe, o echipa are mai mulţi

jucători.

Un meci este jucat de doua echipe; o echipa participă la mai multe meciuri

• Cum arată SCHEMA conceptuală a bazei de date?

5. Cum se modelează SCHEMA pentru o baza de date Relaţională?

Relaţia jucători- echipe este spartă in două relaţii prin intermediul entităţii

Participanți (codul jucătorului, codul echipei, data-intrarii-în-echipa, data-ieşirii-din-

echipă, funcția). Relaţia echipe- meciuri va fi modelata ca atare prin reținerea a

două câmpuri despre echipe (echipa 1 este cea care joacă „acasă" iar echipa 2

este cea din „deplasare”. Fiecare entitate şi Relaţie se structurează sub forma unui

tabel. Obţinem deci următoarele tabele:

JUCĂTORI

Id Nume Data n Casat Adr Copii Foto cv

100 Mutu 1..12.1978 T București T

101 Popescu 3.05.1978 F Cluj F

ECHIPE

Id Nume Data insc Sediu 1 Steaua 1.1.1800 Buc 2 Dinamo 1.1.1980 Buc

51

PARTClPANTI

Id Cod juc Cod ech Data-intr Data-ies post

1 100 1 1.1.2009 1.12.2010 Portar

2 100 2 1.1.2011 Fundas

3 101 2 15.7.2008 portar

MECIURI

Id E1 E2 G1 G2 Stadion Data Ora

1 1 2 1 3 Lia Manoliu 1.5.2011 15

2 2 1 0 0 Dinamo 7.5.2011 17

6. Care sunt cheile unice ale fiecarei tabele?

Pentru simplificarea lucrului am numit un câmp special “ Id” care să joace

rolul de cheie unică. Desigur putem folosi denumirile cod-echipa, cod-jucător, cod-

participant sau cod-meci!

7. Care sunt cheile străine ? ( cele care asigură legăturile dintre tabele)

Participant.cod_ech, Participanti.codJuc - pentru legătura cu tabelele Echipe

şi Jucători şi Meciuri.e1, Meciuri.e2 pentru legătura cu tabela Echipe.

8. Care sunt restricţiile de integritate a bazei de date?

a. Un articol în participant nu poate fi introdus dacă nu se regăsește

valoarea din câmpul Participant.CodJuc in Jucatori.id şi valoarea din câmpul

Participant.cod_ech in Echipe.id

b. Un articol in tabela Meciuri nu poate fi introdus daca codurile celor două

echipe nu figurează deja in tabela Echipe.

c. Modificarea cheii Echipe.id trebuie să determine modificarea cheilor

străine Participant.codech şi Meciuri.E1 sau Meciuri.E2.

d. Modificarea cheii Jucatori.id trebuie să determine modificarea cheii

Participant.codJuc.

e. Ștergerea unei echipe - adică scoaterea ei din evidenţă - nu va

determina şi anularea activităţii jucătorilor prin eliminarea liniilor din tabela

Participanţi dar va provoca ştergerea meciurilor planificate cu această echipă.

(meciurile deja jucate pot rămâne!)

9. Care sunt restricţiile de validitate asupra câmpurilor din tabele?

Data planificării unui meci trebuie sa fie mai mare decât data planificata trebuie sa

fie intre 8-20.

52

In tabela Participanți data-intrării mai mica decât data-ieşi rii în /dintr-o echipa.

10. Care sunt evenimentele care determina acțiuni asupra datelor?

• planificarea unui meci;

• desfășurarea unui meci;

• înscrierea unui jucător la o echipa;

• plecarea unui jucător de la o echipa;

• înscrierea unui nou jucător;

• înființarea unei noi echipe;

• schimbarea unor valori pentru un meci: alt stadion, alta ora/data;

• modificarea unor valori pentru un jucător: casătorie, schimbarea adresei;

• modificarea unor valori pentru echipa: alt sediu etc.

53

CAPITOLUL III

Aspecte didactice ale predării normalizării

în cadrul unităţii de învăţare

"MODELAREA DATELOR”

54

3.1 Experimentul didactic

Practica educaţională se află într-o perioadă de tranziţie accelerată de la ceea

ce unii autori numesc învăţământul tradiţional spre învățământul modern. Tendinţele

înnoitoare se manifestă şi în domeniul evaluării. Idei importante ce trebuie subliniate

şi scoase în evidenţă, încă de la început, aşa cum se desprind ele din literatura de

specialitate şi care reprezintă caracteristici ale procesului de învățământ în deceniile

următoare. O primă idee este că importanţa şi necesitatea realizării unei evaluări

pertinente au devenit atât de evidente încât se vorbeşte frecvent despre "învăţare

asistată de evaluare"i.

În majoritatea sistemelor de învăţământ se acordă o atenţie sporită asigurării

obiectivităţii, transparenţei şi comparabilităţii evaluării şcolare. Notarea, reprezintă

doar simboluri ale unor judecăţi de valoare asupra performanţelor elevilor în diferite

momente ale instruirii.

Evaluarea de tip formativ are drept obiectiv ajutarea profesorilor de a-şi

ameliora acţiunea şi mijloacele de derulare a acesteia [2].

3.2 Caracterizarea claselor cuprinse în experiment

La clasele cu profil matematică-informatică primul modul care se studiază

obligatoriu indiferent de celelalte module alese pentru studiu este modelarea

datelor; timpul alocat acestui modul este de şase săptămâni;

Am ales clasa a XII-a A matematică informatică- an şcolar 2010-2011 pentru a

experimenta proiectele propuse la această unitate de învăţare.

In primul semestru al clasei a XII-a A experimentul didactic a fost efectuat pe

parcursul semestrului I.

Au fost supuşi testării atât individual prin fişe de lucru, testare finală cât şi în

lucru pe echipe, organizând două grupe, cea a băieţilor şi cea a fetelor- stabilind

roluri comune celor două grupe;

Pe parcursul perioadei de predare elevii au manifestat interes fiind un

domeniu nou şi în acelaşi timp dovedind caracterul practic, media pe clasă a evaluării

finale fiind 6.24.

55

3.3 Unitatea de învăţare Modelarea datelor

Structura generală [4]

Sunt prezentate obiectivele didactice care pot fi atinse utilizând acest material.

3.3.1. Obiective didactice

Obiectiv Detaliere

Obiective de referinţă

R1 Înţelegerea necesităţii modelării datelor

R2 Înţelegerea modalităţilor de modelare a datelor

R3 Construirea unor diagrame corecte

R4 Utilizarea cunoştinţelor dobândite în elaborarea unor diagrame

de modelare a datelor corecte

Obiective operaţionale

OP1 Defineşte noţiunea de entitate, specificând elementele sale

caracteristice

OP2 Identifica entităţile care intervin în descrierea unei activitati

practice.

OP3 Oferă exemple de entităţi, descriind contextul în care acestea

intervin.

OP4 Face distincţie între entitate şi instanţele acesteia.

OP5 Defineşte noţiunea de atribut.

OP6 Identifică atributele entităţilor care intervin în descrierea unei

activităţi practice.

OP7 Face distincţie între atribut şi valoarea acestuia.

OP8 Identifică atributele obligatorii şi atributele opţionale într-un

context dat.

OP9 Reprezintă, aplicând conventiile ERD, entităţi şi atributele

acestora.

OP10 Defineşte noţiunea de identificator unic.

56

OP11 Stabileşte un identificator unic pentru entităţile care intervin în

descrierea unei activităţi practice, justificând alegerea.

OP12 Oferă exemple de situații în care este utilă definirea unui

identificator unic artificial.

OP13 Defineşte identificatori unici secundari.

OP14 Defineşte identificatori unici compuşi .

OP15 Utilizează convenţiile de reprezentare a identificatorilor unici în

diagrame E-R.

OP16 Identifică şi denumește relaţiile semnificative dintre entităţi.

OP17 Specifică opţionalitatea şi cardinalitatea unei relaţii.

OP18 Formulează corect o Relaţie dintre două entităţi.

OP19 Reprezintă corect o Relaţie, respectând conventiile de

reprezentare a relaţiilor în diagrame ER.

OP20 Clasifică relaţiile din punctul de vedere al cardinalităţii.

OP21 Utilizează convenţiile de reprezentare în diagrama ERD a relaţiei

rezolvate. Identifică relaţiile ierarhice dintre date.

OP22 Reprezintă corect relaţiile ierarhice, respectând convenţiile de

reprezentare a Relaţiilor în diagrame ER.

OP23 Identifică subentităţile (subtipurile) unei entităţi..

OP24 Defineşte prima regulă de normalizare(1NF – First Normal

Form).

OP25 Analizează o diagramă pentru a stabili dacă aceasta respectă

1NF.

OP26 Modifică o diagrama astfel încât diagrama obținuta sa respecte

1NF.

OP27 Defineşte a doua regula de normalizare (2NF – Second Normal

Form).

OP28 Analizează o diagramă pentru a stabili daca aceasta respecta

2NF.

OP29 Modifică o diagramă astfel încât diagrama obținuta sa respecte

2NF.

57

OP30 Defineşte a treia regula de normalizare (3NF – Third Normal

Form).

OP31 Analizează o diagramă pentru a stabili daca aceasta respecta

3NF.

OP32 Modifică o diagramă astfel încât diagrama obținută sa respecte

3NF.

3.3.2 Conţinut

Se prezintă lista obiectelor de conţinut (notate cu M) şi caracteristicile lor generale.

M1.1 – Crearea unei atmosfere specifice orei şi partea introductivă

Timp de predare 15 min

Tip de interacţiune cu elevii metode de comunicare orală: expunere,

conversaţie

metode de acțiune: exercițiul, învăţarea prin

descoperire

procedee de instruire: explicația în etapa de

comunicare;

Descriere prezentarea modulului

prezentarea modului de selecție a personajului şi

a modalităţii

de configurare şi salvare

prezentarea tipurilor de: par, fete, haine, pantaloni,

pantofi

prezentarea celor opt poziții

M1.2 – Entităţi

Obiective didactice OP1, OP2, OP3, OP4


Tip de interacţiune cu

elevii

metode de comunicare orală: expunere,

conversaţie


descoperire

procedee de instruire: explicația în etapa de

comunicare;

învăţarea prin descoperire dirijata, inductiva,

58

experimentala,

exercițiul de consolidare

Descriere prezentarea definiţiei unui entităţi

prezentarea unor aspecte practice în care pot fi

identificate entităţi

prezentarea unor exemple

prezentarea unor convenții de reprezentare

prezentarea animaţiilor

determinarea soluțiilor corecte şi explicarea lor

Cuvinte cheie entitate

instanța

diagrama ER

Obiective didactice OP5, OP6, OP7, OP8, OP9



elevii


conversaţie


descoperire

procedee de instruire: explicația; învăţarea prin

descoperire dirijata, experimentala, exercițiul de

consolidare

Descriere prezentarea definiţiei atributului

prezentarea unor convenții de reprezentare

prezentarea unui exemplu animat


rezolvarea sarcinilor de lucru – 6 exerciții

Cuvinte cheie atribut

instanța

atribut obligatoriu

atribut opțional

opționalitate

diagrama ER

M3.1 – Identificator unic

Obiective didactice OP10, OP11, OP12, OP13, OP14, OP15

59



elevii


conversaţie


descoperire


descoperire dirijata, inductiva, experimentala,


Descriere prezentarea noțiunii de identificator unic

prezentarea convențiilor de reprezentare


rezolvarea sarcinilor de lucru

Cuvinte cheie identificator unic

identificator unic simplu

identificator unic compus

M3.2 – Relaţii

Obiective didactice OP16, OP18, OP19



elevii


conversaţie, studiu de caz


descoperire


descoperire

dirijata, experimentala, exercițiul de consolidare

Descriere prezentarea noțiunii de Relaţie

prezentarea modalităţii de reformulare a Relaţiilor

prezentarea metricii Relaţiilor

prezentarea convențiilor de reprezentare


realizarea celor șase sarcini de lucru

Cuvinte cheie Relaţie

opționalitate

cardinalitate

matricea Relaţiilor

60

diagrama ER

M4.1 – Clasificarea Relaţiilor

Obiective didactice OP20



elevii


conversaţie, studiu

de caz


descoperire


descoperire

dirijata, inductiva, experimentala, exercițiul de

consolidare

Descriere prezentarea categoriilor de Relaţii

prezentarea tipurilor


realizarea sarcinilor de lucru

Cuvinte cheie Relaţie One-to-Many

Relaţie One-to-One

Relaţie Many-to-Many

M4.2 – Rezolvarea Relaţiilor

Obiective didactice OP21, OP22, OP23, OP24



elevii




descoperire




Descriere prezentarea exemplelor

61

realizarea sarcinilor de lucru

Cuvinte cheie entitate de intersecție

M5.1 – Prima formă normală




elevii




descoperire




Descriere definirea noțiunii de 1NF – First Normal Form

prezentarea necesităţii utilizării 1NF

realizarea sarcinii de lucru

Cuvinte cheie 1NF

M5.2 – A doua forma normala




elevii




descoperire




Descriere definirea noțiunii de 2NF – Second Normal Form

prezentarea necesităţii utilizării 2NF

62


Cuvinte cheie 2NF

M5.3 – A treia forma normală

Obiective didactice OP30, OP31



elevii




descoperire




Descriere definirea noțiunii de 3NF – Third Normal Form

prezentarea necesitatii utilizării 1NF


Cuvinte cheie • 3NF

M6 Aplicaţii; miniproiect



elevii



metode de acțiune: exercițiul


descoperire dirijata, exercițiul de consolidare

Descriere rezolvarea de exerciţii şi probleme recapitulative

realizarea unui miniproiect în echipe - de

gestionarea unei afaceri de succes pe baza unui

model dat;elevii vor identifica tabelele necesare,

relaţiile dintre ele şi vor realiza normalizări.

63

2.3. Model de structurare şi predare

64

3.3.3 Obiecte de conţinut – detaliere

1. Entităţi

Definiţie

O entitate este denumită printr-un substantiv singular şi reprezintă un element

generic semnificativ pentru activitatea care trebuie să fie modelată.

De exemplu:

ORAȘ, CARTE, STUDENT, ELEV, SCRIITOR, VEHICUL

Entităţile admit instanţe, care sunt exemple concrete, cazuri particulare ale

entităţilor.

Stabilirea faptului că un anumit element este o entitate sau o instanţă poate depinde

de contextul activităţii pe care o modelăm.

Pentru activitatea de gestiune a unei biblioteci, SCRIITOR este o entitate. Dar, de

exemplu pentru Oficiul Forţelor de Muncă SCRIITOR ar putea fi o instanţă a entităţii

PROFESIE.

2 Convenţii de reprezentare

O entitate va fi reprezentată sub forma unui dreptunghi cu colţurile rotunjite

(softbox).

În partea de sus a dreptunghiului va fi scris cu majuscule numele entităţii.

65

Temă

Un elev merge la o firmă de turism pentru a studia ofertele de croazieră din vacanta

asta. A primit o broșură de genul:

Se solicită elevului sa realizeze o asociere între entităţi şi instanțe.

Pentru a asocia o entitate cu o instanţă, se trage o linie între ele.

3. Atribute

Definiţie

Un atribut reprezintă o informaţie semnificativă pentru activitatea care trebuie

să fie modelată, informaţie care descrie, cuantifică, clasifică sau califică o

entitate.

Pentru o anumită instanţă a unei entităţi, orice atribut poate avea o singură

valoare. Valoarea respectivă este de un anumit tip (numeric, şir de caractere,

dată calendaristică, etc).

Pentru o bună modelare a activităţii, anumite atribute trebuie să aibă o

valoare. Aceste atribute le vom numi obligatorii.

Pentru identificarea corectă a unui student numele şi prenumele sunt

obligatorii. De asemenea numărul matricol, data naşterii şi adresa.

66

Convenţii de reprezentare

Atributele vor fi specificate în dreptunghiul care reprezintă entitatea, sub

numele entităţii, câte un atribut pe o linie.

Numele unui atribut obligatoriu va fi precedat de caracterul *.

Numele unui atribut opţional trebuie să fie precedat de caracterul °.

Exerciţiu temă

Fie entităţile FARMACIE, MEDIC, DEPOZIT şi INTERPRET .

Desenaţi entităţile după modelul dat şi plasaţi atribute pentru acestea indicând corect

opţionalitatea (obligativitatea).

67

4. Identificator unic

Pentru orice entitate trebuie să definim (cel puţin) un identificator unic (UID -

Unique IDentifier). Identificatorul unic este un atribut sau o combinaţie de

atribute care permit identificarea în mod unic a oricărei instanţe a entităţii

respective.

Un identificator unic format dintr-un singur atribut se numeşte simplu.

Un identificator unic format din mai multe atribute se numeşte compus.

Atributele care intră în componenţa unui identificator unic trebuie să fie

obligatorii.

Uneori există mai multe variante posibile de identificare în mod unic a instanţelor unei

entităţi. În acest caz se alege un atribut/combinaţie de atribute ca identificator unic

principal şi apoi, opţional, se pot alege unul sau mai mulţi identificatori unici

secundari.

Prin urmare, trebuie să existe un singur identificator unic principal, dar pot

exista mai mulţi identificatori unici secundari.

Stabilirea unor identificatori unici secundari oferă utilizatorilor sistemului pe

care îl proiectăm mai multe variante de a accesa sistemul, astfel sistemul devine mai

flexibil.


Pentru a marca în diagrama ERD faptul că un atribut este identificator unic sau intră

în componenţa identificatorului unic, acesta va fi precedat de simbolul #.

Dacă identificatorul unic al entităţii este compus din mai multe atribute, atunci fiecare

dintre acestea va fi precedat de caracterul #.

În acest caz nu mai este necesară precedarea atributului de simbolul *, acesta fiind

implicit.

Pentru a reprezenta în diagrama E-R un identificator unic secundar vom preceda

numele atributului/ atributelor ce constituie identificatorul unic secundar de #1 (dacă

este primul identificator unic secundar), #2 (pe cel de al doilea) etc.

68

Exerciţiu

Care dintre următoarele atribute poate fi considerat identificator unic pentru

entitatea INSULĂ?

69

Exerciţiu

Asociază fiecărei entităţi unul sau mai multe atribute ce pot constitui un identificator

unic pentru entitatea respectivă.

Exerciţiu

Poate fi codul poştal un identificator unic pentru o stradă din România?

70

5 Modelarea datelor. Relaţii

În procesul de modelare, după identificarea entităţilor şi a atributelor acestora,

trebuie să identificăm relaţiile care există între entităţi.

În acest scop vom examina fiecare pereche de entităţi şi vom stabili dacă

există între entităţile respective o relaţie semnificativă pentru activitatea pe

care o modelăm.

Când identificăm o relaţie între două entităţi A şi B trebuie să precizăm atât

relaţia în care A se află cu B, cât şi relaţia în care B se află cu A. De

asemenea trebuie să specificăm opţionalitatea şi cardinalitatea relaţiei.

O relaţie poate fi opţională (acest lucru se specifică prin cuvântul poate) sau

obligatorie (acest lucru se specifică prin cuvântul trebuie).

Cardinalitatea specifică numărul de instanţe ale entităţii implicate în relaţie

(una singură, respectiv una sau mai multe).

Pentru standardizare a fost definit un "şablon" care trebuie respectat atunci

când specificăm o relaţie între două entităţi.


Relaţiile se reprezintă printr-o linie care conectează cele două entităţi implicate

în relaţie. Linia este constituită din două jumătăţi.

Să notăm cu A şi B cele două entităţi între care este definită relaţia.

Jumătatea care are o extremitate în A reprezintă relaţia în care entitatea A se

află cu entitatea B; jumătatea care are o extremitate în B reprezintă relaţia în

care se află entitatea B cu entitatea A.

Numele relaţiei este scris pe fiecare dintre cele două jumătăţi.

71

Exerciţiu

Analizează relaţia dintre entităţile STUDENT şi DISCIPLINĂ.

Formulează corect relaţia STUDENT-DISCIPLINĂ, specificând opţionalitatea şi

cardinalitatea, apoi specificaţi relaţia DISCIPLINĂ-STUDENT.

Exerciţiu

Formulează relaţiile reprezentate în diagrama ERD alăturată, citind mai întâi relaţia

de la stânga la dreapta, apoi relaţia de la dreapta la stânga.

Exerciţiu

Care dintre următoarele variante corespunde relaţiilor reprezentate în diagrama E-R?

72

Exerciţiu

Urmăreşte cu atenţie animaţia pentru a identifica relaţiile existente între entităţile

CLIENT, SERVICIU TURISTIC, OFERTĂ DE CAZARE.

Reprezintă relaţiile existente între entităţile CLIENT, SERVICIU TURISTIC, OFERTĂ

DE CAZARE respectând convenţiile de reprezentare specifice diagramelor ER

.

73

Exerciţiu

Formulează corect relaţiile cu ajutorul cuvintelor din partea de jos:

Exerciţiu

Reprezintă relaţiile existente între entităţile CLIENT, SERVICIU TURISTIC, OFERTĂ

DE CAZARE respectând convenţiile de reprezentare specifice diagramelor ER

.

74

Modelarea datelor. Clasificarea relaţiilor

Din punctul de vedere al cardinalităţii relaţiile pot fi clasificate în 3 categorii:

1. Relaţii One-to-Many (1:M)

2. Relaţii One-to-One (1:1)

3. Relaţii Many-to-Many (M:M)

Relaţii One-to-Many (1:M)

Sunt cele mai frecvent întâlnite şi, în funcţie de opţionalitate, pot fi de 4 tipuri.

Exemplu de relaţii One-to-Many (1:M).

75

Relaţiile 1:1

sunt mai rar întâlnite în diagramele ER.

În funcţie de opţionalitate, relaţiile 1:1 sunt de 3 tipuri.

Exemplu

Analizând relaţia TURIST-PAŞAPORT, deducem că aceasta este o relaţie One-

to-One (1:1).

76

Relaţii Many-to-Many (M:M)

Într-o primă etapă de analiză şi de elaborare a modelului unei activităţi, relaţiile M:M

sunt frecvent întâlnite.

Într-o a doua etapă, aceste relaţii vor dispărea, fiind transformate în relaţii 1:M.

Din punctul de vedere al opţionalităţii, există 3 tipuri de relaţii M:M.

Exemplu

Analizând relaţia CARTE-SCRIITOR, deducem că aceasta este o relaţie Many-to-

Many (M:M).

Exemplu

Urmărind animaţia şi analizând relaţia FILM-ACTOR, deducem că aceasta este o

relaţie Many-to-Many (M:M).

77

Fişă de lucru

Clasificaţi relaţiile specificate în zona punctată:

78

3.4 Normalizarea. Prima formă normală

Pentru ca un model să fie eficient datele trebuie să fie organizate astfel încât

să fie uşor de accesat şi de întreţinut.

Pentru a obţine un model eficient au fost definite o serie de reguli pe care trebuie să

le respecte modelul conceptual. Aceste reguli sunt denumite reguli de normalizare

sau forme normale.

Definiţie

Normalizarea reprezintă procesul de descompunere a unui tabel Relaţional în mai

multe tabele care satisfac anumite reguli şi care stochează aceleaşi date ca şi

tabelul inițial astfel încât să fie eliminate redundanta în date şi anomaliile la

actualizare.

E. F. Codd a demonstrat că într-o anumită formă relaţiile posedă proprietăţi nedorite,

pe care le-a numit anomalii de actualizare. Aceste anomalii sunt:

► Anomalia de ştergere, care constă în faptul că anumite date care urmează să fie

şterse fac parte din tupluri în care se găsesc şi alte date care sunt necesare şi în

continuare, ori ştergerea făcându-se la nivelul tuplului, acestea se pierd;

► Anomalia de adăugare, constă în faptul că anumite date care urmează să fie

adăugate fac parte din tupluri incomplete (pentru care nu se cunosc toate datele),

ceea ce face ca acestea să nu poată fi adăugate;

► Anomalia de modificare, care rezultă din faptul că este dificil de modificat o

valoare a unui atribut atunci când ea apare în mai multe tupluri ale relaţiei.

Pentru a înlătura aceste anomalii, E. F. Codd a stabilit trei forme normale pentru

relaţii şi a introdus procesul de normalizare care se bazează pe noţiunea de

dependenţă funcţională (FD) ca relaţie între atributele unei entităţi cu caracter

invariant.

Procesul de normalizare a relaţiilor se realizează în mai mulţi paşi, începând cu

forma normală unu (1NF) şi ajungând (după ultimele cercetări) la forma normală cinci

(5NF). Aceasta constă în descompunerea unei relaţii în conformitate cu mulţimea

dependenţelor funcţionale F, într-o colecţie de relaţii care să conserve informaţiile şi

dependenţele funcţionale din relaţia iniţială (descompunerea fără pierderi).

79

Prima formă normală

bază de date este în forma normală 1 dacă şi numai dacă toate câmpurile din

tabelele ei nu sunt repetate şi conţin numai valori indivizibile;

Orice atribut poate avea o singură valoare pentru fiecare instanţă a unei

entităţi.

În cazul în care pentru o entitate identificăm un atribut care are valori multiple,

vom crea o nouă entitate pe care o vom relaţiona cu entitatea iniţială printr-o

relaţie de tip M:M.

Pentru entitatea STUDENT am identificat următoarele elemente de caracterizare

(atribute): Nume, Prenume, Număr Matricol, Data naşterii, Domiciliu, Număr telefon,

Adresă e-mail şi Facultate.

Acest model nu respectă prima regulă de normalizare deoarece există studenţi acre

sunt înscrişi la mai multe facultăţi, adică atributul Facultate poate avea valori multiple.

Vom rezolva această situaţie creând o nouă entitate FACULTATE pe care o vom

relaţiona cu entitatea STUDENT.

80

Exerciţiu

Examinaţi entităţile de mai jos. Respectă prima formă normală? Găsiţi o soluţie

pentru fiecare situaţie.

1.

2

Soluţie

aparţine

BON

# nr bon

* nr casa

* ora

o produse

MAGAZINE

# nr crt

* nume

* director

* CUI

* telefon

o filiala

PRODUSE

# nr crt

* denumire

BON

# nr bon

* nr casa

* ora

o produse

81

Exerciţiu

Să analizăm entitatea CARTE cu următoarea structură:

Această entitate nu respectă prima formă normală, deoarece o carte trebuie

să fie scrisă de unul sau mai mulţi autori, prin urmare, atributul Autor are valori

multiple.

O soluţie posibilă este:

82

Fişă de lucru

Desenaţi diagrama entităţi-relaţii (ERD) pentru care, citind relaţia existentă, se obţine: Fiecare PERSOANĂ trebuie să locuiască într-o LOCALITATE şi numai una. Fiecare LOCALITATE poate fi locuită de una sau mai multe PERSOANE.

Găsiţi corespondenţa dintre entităţile din stânga şi tipurile de relaţii din dreapta:

ELEV şi CLASĂ M:1

AUTOR şi CARTE M:M

PERSOANĂ şi CNP 1:M

ORAŞ şi STRADĂ 1:1

Stabiliţi corespondenţele corecte dintre noţiunile de atribut, entitate şi relaţie din

coloana stângă şi afirmaţiile din coloana dreaptă.

atributul se stabileşte între entităţi

entitatea poate avea mai multe instanţe

relaţia are o singură valoare

Se consideră entităţile şi atributele:

INFORMAŢIE METEO temperatură

CLIENT cont

ELEV preţ

PRODUS număr matricol

Stabiliţi corespondenţele corecte între noţiuni şi reprezentările lor grafice.

atribut opţional #

atribut obligatoriu *

identificator unic o

Utilizaţi săgeţile pentru a face asocierea corectă.

entitate tabelă

instanţă coloană

atribut linie

83

Încălcări ale primei forme normale.

(1) Mai multe valori semnificative in acelaşi câmp

(2) Mai multe coloane reprezentând acelaşi tip de date/fapte/obiecte

Exemple:

Interogările pentru a selecta înregistrări pe baza componentei câmpurilor repetitive

sunt foarte dificile.

De exemplu, o interogare pentru a selecta acele orașe care oferă acelaşi tip de

Serviciu public, sa spunem "Politie" (acesta putând să apară în oricare din coloanele

"Servicii publice") va genera căutări in 9 perechi separate de coloane.

Exemple:

Persoana Jocuri preferate

Ion Doom2, Zelda, Sims

Maria Zelda, Sims,

SuperMario

Daniel WOW, Zelda

Oraș Servicii publice

Dej Politie, Salubritate, Canalizare

Cluj Politie, Canalizare, Salubritate

Bistriţa Politie

Persoana Jocuri preferate(1) Jocuri preferate(2) Jocuri preferate(3)

Ion Doom2 Zelda Sims

Maria Zelda Sims SuperMario

Daniel WOW Zelda

Oraș Servicii publice Servicii publice(2) Servicii publice(3)




84

Oraș Servicii publice Servicii publice(2) Servicii publice(3)




ID Oraș Servicii

publice

1 București Politie

2 Brașov Politie

3 Scornicești Politie

4 București Salubritate

5 Brașov Canalizare

6 București Canalizare

7 Brașov Salubritate

Oraș Servicii publice

București Politie

Brașov Politie


București Salubritate

Brașov Canalizare

București Canalizare

Brașov Salubritate

Pentru a asigura unicitatea unei înregistrări, se va utiliza cheia primară. In

exemplul de mai sus, prin introducerea unei coloane adiționale de tip întreg, auto-

incrementat, se asigura unicitatea fiecarei înregistrări.

85

Fişă de lucru

1. Atunci când verificaţi un model de bază de date pentru prima formă normală ce se

face exact?

2. Care este regula pentru 1nF în procesul de normalizare?

3. Verificaţi dacă următoarele tabele verifică prima formă normală. Dacă nu, faceţi

schimbările necesare pentru a fi corect.

4.Creaţi entităţile ELEV şi Nota; Verificaţi dacă tabelele create respectă regula

pentru 1nF; dacă nu, faceţi schimbările necesare;

Timp de lucru 35 min;

86

3.5 A doua formă normală

Definiţie

O relaţie este în FN2 dacă şi numai dacă:

1. Este deja în FN1

2. Oricare dintre atributele sale care nu fac parte din cheia primară este complet

dependent funcţional de cheia primară.

Aducerea unei relaţii la FN2

Fie e o entitate aflată în FN1; aducerea ei la FN2 necesită:

1. Identificarea tuturor dependenţelor funcţionale dintre atributele entităţii

2. Descompunerea entităţii E în entităţi noi astfel:

Fiecare dependenţă funcţională completă defineşte o nouă entitate

Din fiecare dependenţă funcţională parţială se elimină acea parte a

cheii primare care este răspunzătoare de incompletitudinea

dependenţei şi apoi se defineşte noua relaţie

3. Stabilirea relaţiilor dintre noile entităţi (în scopul recuperării informaţiilor de

legătură, pierdute eventual prin înlocuirea entităţii iniţiale cu entităţile normalizate)

Exemplul 1

Fie diagrama de mai sus care conţine colecţia facturilor de plată la un magazin;

Observăm ca avem o cheie primară compusă din două atribute; celelalte atribute

sunt dependente doar de o parte a cheii primare.

De asemenea nu avem date care să se repete, prin urmare nu este vorba de prima

formă normală.

Realizarea acestei probleme se realizează prin introducerea unei entităţi noi

DEPARTAMENT

# cod_departament

# IDangajat

*data_nasterii

*adresa

87

Exemplul 2

Despre conturile de la o bancă, fie entitate de mai jos:

Se pune problema posibilelor anomalii.

Observăm că şi alte bănci pot fi titulari de conturi cu acelaşi număr de cont;

Locaţia băncii se poate schimba în timp, sau pot apărea alte filiale, nu este

dependentă de numărul contului;

O modelare a structurii impune crearea unei noi entităţi care să se refere la date

despre bănci care să fie pusă in relaţie cu entitatea cont.

Exerciţiu

Să analizăm fragmentul din diagrama de mai jos care modelează activitatea de

împrumut al cărţilor din bibliotecă.

CONT

# nrcont

*sold

*data desch

*locaţia bancii

88

Identificatorul unic al entităţii FISA ÎMPRUMUT este compus din Data, ID-ul cititorului

şi Cota cărţii. Atributul titlu nu depinde de întregul identificator unic, ci doar de Cota

cărţii.

Prin urmare, pentru a respecta cea de-a doua formă normală, atributul Titlu trebuie

să facă parte din entitatea CARTE.

Exerciţiu

Să analizăm fragmentul de diagramă de mai jos care modelează relaţia CLIENT-

SERVICIU TURISTIC. Aceasta este o relaţie M:M, care a fost rezolvată prin

intermediul entităţii CONTRACT. Această diagramă nu respectă cea de a doua formă

normală.

Modificaţi diagrama astfel încât să respecte cea de a doua formă normală.

89

Soluţie

Exerciţiu

Fie entitatea de mai jos:

Verifică condiţiile 2NF? Avem o cheie compusă formată din entităţile nr mașina şi

cnp; observăm că celelalte entităţi depind de una din entităţile cheii primare: nume-

persoana de cnp şi adresa tot de cnp;

Prin urmare vom descompune tabela în două tabele:

O persoană poate avea mai multe maşini şi fiecare maşină are un singur proprietar;

Relaţia este de tipul 1 la n.

Persoana

#nr masina

#cnp

*marca masina

*nume persoana

*adresa

90

Problemă

1. Se dau două tabele. Primul se numeşte Proprietari şi conţine numele proprietarului

şi codul terenului pe care acesta în deţine. Al doilea se numeşte terenuri şi conţine

codul terenului şi suprafaţa sa. Se ştie că un proprietar poate avea mai multe terenuri

dar un teren un singur proprietar. Fiecare tabel are drept cheie primară codul

terenului.

a) sunt cele două tabele in 2NF? Daca nu, aduceţi-le la această formă. Ce relaţie se

poate stabili între cele două tabele?

b)Stabiliţi relaţia în baza de date astfel încât tabelul părinte să fie Terenuri.

c) Stabiliţi valoarea de adevăr a următoarelor afirmaţii:

- In tabelul Terenuri nu pot introduce un teren cu un cod inexistent în tabelul

Proprietari.

- In tabelul Proprietari nu pot introduce un proprietar care are un teren de cod

inexistent în tabelul Terenuri.

91

3.5.1 Proiect în echipă

Se împarte clasa în două grupe: grupa băieţilor şi grupa fetelor;

Fiecare echipă, realizează un proiect despre datele care le conţin – echipele de

fotbal pentru băieţi şi genuri de muzică pentru fete;

Echipa va conţine:

“informaticianul”- cel care proiectează relaţiile

designerul- cel care se ocupă de grafică, aspect;

“reporterii” – cei care caută informaţii pe internet;

“centralizatorii”- cei care asamblează datele şi le transformă în informaţii

pentru tabele;

Observatorii- cei care verifică corectitudinea datelor culese;

Un arbitru- cel care oferă puncte echipelor;

Juriul- cei care stabilesc criteriile de evaluare şi analizează munca echipelor.

Grupele vor culege date de la mai multe formaţii sau echipe;Rezultatul va fi prezentat

cu videoproiectorul- prin realizarea unei prezentări în Powerpoint.

Se vor puncta:

entităţile create;

atributele şi felul lor (obligatorii, opţionale), relaţiile dintre entităţi;

tipul de legături între entităţi;

Modele de date ce pot fi obţinute prin crearea relaţiilor între tabele;

Corectitudinea datelor culese;

Aspectul prezentării;

Proiectul câştigător ca fi expus şi altor clase;

Timp de lucru: două ore

92

3.6 A treia formă normală

Nici un atribut nu poate să fie dependent de un atribut care nu este identificator unic

al entităţii.

Exemplu -CD

Dacă ne gândim la tipul de informaţii pe care dorim să le stocăm despre un

CD, informaţia despre magazinul de unde am cumpărat CD-ul fac parte din aceeaşi

entitate? În cazul în care adresa magazinului s-a schimbat, va trebui să se schimbe

informaţii cu privire la toate CD-urile.

Exemplu Adrese prieteni

Dorim să introducem diferite tipuri de informaţii pentru un prieten din agenda

personală: numărul de telefon, adresa, numele de şcoală sau la locul de muncă.

Dacă avem mai mulţi prieteni care merg la aceeaşi scoală, şi introducem adresa

şcolii -stradă, împreună , nu ar fi numai duplicarea datelor, dar cauzează probleme -

de exemplu, în cazul în care şcoala si-a schimbat adresa, va trebui să modificăm

peste tot!

Exemplu- oraş

Să considerăm un sistem care monitorizează informaţii despre

oraşe - mărimea, populaţia, primarul şi aşa mai departe.

Primul model prezintă o entitate care include informaţii ce depind de

stat- suma alocată de stat pentru infrastructură.

Deoarece banii alocaţi se schimbă, tabela se va împărţi în două

tabele- ce va corespunde formei a treia de normalizare.

ORAS

#id

*Nume

*Suprafata

*populaţie

*judeţ

*bani alocaţi

ORAS

#id

*Nume

*Suprafata

*populaţie

JUDET

#id

*Nume

*bani alocaţi

93

Exemplu afaceri

Să presupunem regulă de afaceri următoarele: fiecare angajat poate avea un

partener.

Acest model încalcă a treia formă normală, deoarece data naşterii partenerului este

un atribut de partener, nu de angajat.

O posibilă soluţie de normalizare a tabelei este:

Exemplu- CARTE

Să analizăm entitatea CARTE:

Această entitate nu respectă cea de-a treia regulă

de normalizare deoarece atributul Adresa

editurii depinde de atributul Editura, atribut care

ne este identificator unic al entităţii CARTE.

Pentru a respecta a treia formă normală vom crea

o nouă entitate numită EDITURA pe care o vom

relaţiona cu entitatea CARTE. Atributul Adresa

editurii va fi atribuit entităţii EDITURA.

94

Exerciţiu

Să analizăm entitatea CLIENT modelată mai jos. Această entitate nu respectă cea de

a treia formă normală.

O soluţie posibilă ar fi:

3.6.1Procesul normalizării prin etapele FN1, FN2, FN3 [5]

95

Condiţie de verificat Soluţie(normalizare)

FN1 Toate atributele entităţii trebuie sa

ia o singură valoare

Fiecare atribut care ia mai multe valori pentru

aceeaşi instanţă se transformă într-o nouă

entitate.

Se stabilesc relaţiile necesare între noile

entităţi şi entitatea iniţială modificată.

FN2 Entitatea este în FN1.

Cheia sa primară constă din mai

multe atribute.

Toate atributele care nu fac parte

din cheia primară sunt complet

dependente funcţional de cheia

primară.

Fiecare parte a cheii primare, împreună cu

atributele care depind funcţional complet de ea

formează o nouă entitate.


entităţi care au înlocuit-o pe cea iniţială.

FN3 Entitatea este în FN2.

Niciun atribut care nu face parte

dintr-o cheie candidat nu este

funcţional dependent de un alt

atribut care nu face nici el parte

dintr-o cheie candidat

Se păstrează în entitatea iniţială numai cheia

primară şi atributele care depind funcţional de

ea direct (inclusiv atributul incriminat)

Se creează câte o nouă entitate din fiecare

atribut care nu face parte din cheia primară,

împreună cu toate atributele (care nu fac nici

ele parte din cheia primară a entităţii iniţiale)

care sunt dependente funcţional de acesta.


entităţi şi entitatea iniţială modificată.

3.6.2 Exerciţii recapitulative [21]

1. Precizați ce înseamnă normalizare specificaţi ce este prima formă de normalizare.

Instrucţiuni: Completaţi răspunsul de la tastatură în câmpul de mai jos.

2. Pentru desenarea unei entități se foloseşte:

Alegeţi răspunsul corect din variantele de mai jos.

un romb

96

un dreptunghi rotunjit la colţuri

un cerc;

3. Care dintre următoarele afirmaţi sunt corecte?

Instrucţiuni: Alegeţi răspunsurile corecte din variantele de mai jos.

un subtip moşteneşte toate atributele supertipului

atributele unui subtip sunt atribute ale oricărui subtip

un subtip moşteneşte toate relată supertipului

4. Daţi un exemplu de scenariu cu două entități intre care sa se stabilească o relaţie

unu la mai mulţi. Desenaţi diagrama şi citiţi relaţiile.

5. Scrieţi cate o entitate pentru fiecare dintre instanţele următoare: CRAIOVA, URS,

PECHINEZ, PORUMB precizaţi tipul identificatorilor.

6.

Se consideră diagrama de mai sus. Alegeţi dintre următoarele variante pe cele care

citesc corect relaţiile dintre entitățile STUDENT şi PROFESOR

: Alegeţi răspunsurile corecte din variantele de mai jos.

Fiecare STUDENT trebuie sa fie pregătit de un PROFESOR şi numai unul

Fiecare STUDENT poate sa fie pregătit de un PROFESOR şi numai unul

Fiecare STUDENT trebuie sa fie pregătit de unul sau mai mulţi PROFESORI

Fiecare STUDENT poate fi pregătit de unul sau mai mulţi PROFESORI

Fiecare PROFESOR poate pregăti unul sau mai mulţi STUDENȚI

Fiecare PROFESOR poate pregăti un STUDENT şi numai unul

97

Fiecare PROFESOR trebuie sa pregătească unul sau mai mulţi STUDENȚI

Fiecare PROFESOR trebuie sa pregătească un STUDENT şi numai unul.

7. Se consideră următorul scenariu: intr-o şcoala exista mai mulţi elevi care au

probleme in utilizarea anumitor cunoștințe de informatica. La nivelul şcolii fost stabiliţi

anumiţi profesori care se ocupa cu pregatirea acestor elevi. Fiecare elev face parte

dintr-o grupa de elevi de a căror pregătire se ocupa u singur profesor, însă exista şi

profesori care pregătesc mai multe grupe de elevi.

Specificaţi relaţia care se stabilește intre entitățile ELEV şi PROFESOR, precum şi

opţionalitatea şi cardinalitatea ei. Desenaţi diagrama şi citiţi relaţia ambele sensuri.

Instrucţiuni: Completaţi răspunsul de la tastatura in câmpul de mai jos.

8. Realizaţi diagrama entitate-relaţii (ERD) şi specificaţi regulile structurale şi de

proces pentru o editură. Diagrama va avea minim 4 entități.

9. Se consideră un model care gestionează situaţia elevilor în cei patru ani de liceu.

Entitatea ELEV are unul dintre atribute clasa. Este acesta atribut volatil? Daca da,

înlocuiți-l cu unul care sa nu fie volatil;

10. Un atribut care nu are valoare obligatoriu este:

un atribut care nu poate fi folosit;

un atribut care trebuie precedat de simbolul ;

un atribut care trebuie precedat de simbolul *;

un atribut opțional;

11. Dați exemplu de: entitate, trei instanţe ale acesteia, două atribute, identificator unic.

Pentru entitatea ANGAJAT :

- specificați atributele pe care le considerați importante, precum şi opționalitatea lor

- dați exemple de valori pentru fiecare atribut

- specificați tipul fiecărui atribut

- dați trei exemple de instanțe

12. Scrieţi câte o entitate pentru fiecare dintre atributele următoare: temperatura, preţ,

data de început. Pentru fiecare din entităţile de mai sus indicaţi identificatorul unic

specific.

98

13. Daţi un exemplu de scenariu cu două entităţi între care sa se stabilească o relaţie

unu la mai mulţi. Desenaţi diagrama şi citiţi relaţiile.

14. Se consideră următorul scenariu: intr-o şcoală există mai mulţi elevi care au

probleme în utilizarea anumitor cunoștințe de informatică. La nivelul şcolii fost

stabiliţi anumiţi profesori care se ocupa cu pregatirea acestor elevi. Fiecare elev

face parte dintr-o grupa de elevi de a căror pregătire se ocupa un singur profesor,

însă există şi profesori care pregătesc mai multe grupe de elevi. Specificați relaţia

care se stabilește intre entităţile ELEV şi PROFESOR, precum şi opționalitatea şi

cardinalitatea ei. Desenaţi diagrama şi citiți relaţia în ambele sensuri.

15. Stabiliți care dintre exemplele din stânga sunt exemple de entităţi, instanţe sau

atribute. Utilizaţi săgețile pentru a face asocierea corectă.

16. Se consideră o relaţie de la entitatea STUDENT la entitatea CARNET DE NOTE.

Ce fel de relaţie este aceasta?

Relaţie transferabilă;

Relaţie netransferabilă;

17. Se consideră diagrama de mai jos. Precizaţi dacă există o relaţie redundantă.

da nu

animal Popescu George vârsta

Entitate sau instantă

Instanţă

atribut

99

18. Se încearcă o cercetare privind diversele epidemii apărute în ultimii ani în Europa.

Pentru fiecare spital care participă la această cercetare, se va ţine ( de localitate,

număr doctori, număr paturi. Sunt implicaţi în această cercetare mai multe

specialități pentru care se cunoaşte, numele, adresa de e-mail, specializarea,

spitalul unde profesează. In această cercetare sunt implicaţi şi anumiţi pacienţi

pentru care este important sa se cunoască: vârsta, sex, diagnostic, valoare

glicemie, valoare colesterol, număr leucocite.

Identificați, aşa cum rezultă din scenariul de mai sus, entităţile, atributele şi

optionalităţile lor, precum şi identificatorul unic pentru fiecare entitate în parte.

19. Scrieţi câte o entitate pentru fiecare dintre instanțele următoare: CRAIOVA, URS,

PECHINEZ, PORUMB. Pentru fiecare din entităţile de mai sus subliniaţi şi

identificatorul unic specific.

20. Se consideră o fabrica de confecții care produce: rochii, bluze, pantaloni, fuste.

Pentru fiecare dintre acestea se păstrează informații specifice. Construiţi

diagrama corespunzătoare acestui scenariu.

21. Daţi două exemple de scenarii, unul in care sa avem entitatea CAINE, iar in

celalalt, CAINE sa fie instanța unei entităţi care se va preciza.

22. Se consideră o Relaţie de la entitatea STUDENT la entitatea CURS. Ce fel de

Relaţie este aceasta?

Relaţie transferabila;

Relaţie netransferabila

23. Se consideră două scenarii de afacere:

Scenariul 1) își propune o cercetare pentru o firma care-şi vinde produsele

exclusiv on-line.

Pentru produsele cele mai vândute este importanta identificarea vârstei

cumpărătorilor respectivi şi de aceea una dintre entitățile de interes este CLIENT cu

atributele: nume, vârsta, adresa de e-mail.

Scenariul 2) își propune o cercetare pentru o firmă care-şi vinde produsele exclusiv

printr-un magazin propriu, situat intr-un spaţiu închiriat din incinta unui mall. Pentru

produsele cele mai vândute este importantă identificarea vârstei cumpărătorilor

100

respectivi şi de aceea una dintre entitățile de interes e CLIENT cu atributele: nume,

vârsta, adresa de e-mail.

Precizaţi care sunt opţionalitaţile atributelor pentru fiecare scenariu. Instrucţiuni:

Utilizaţi săgețile pentru a face asocierea corectă.

Scenariu 1 * nume

Scenariu 2 * vârsta

Scenariu 2 * vârsta

Scenariu 1 * nume

Scenariu 1 * adresa de e-mail

Scenariu 2 o adresa de e-mail

101

3.7 Proiect final

Realizaţi în grupe de câte 5 elevi un proiect despre o posibilă afacere în care se

ţine evidenţa datelor mai multor feluri de informaţii;

Identificaţi datele necesare în tabele;

Stabiliţii relaţiile dintre datele din tabele.

Stabiliţi cheile primare;

Desenaţi diagramele corespunzătoare;

Precizaţi 5 rezultate care doriţi să le aflaţi;

Fiecare elev va avea un rol în realizarea proiectului.

Prezentarea se va face cu videoproiectorul după timpul alocat proiectului;

Timp de lucru: 90 minute.

102

Concluzii

Din analiza rezultatelor obţinute la testele aplicate, precum şi din observaţiile

făcute pe tot parcursul experimentului didactic se pot formula o serie de concluzii

care să confirme valoarea evaluării continue aplicată în cadrul secvenţei de instruire

la clasa a XIII-a A, ce a făcut obiectul temei investigate.

Desfăşurarea lecţiilor privind formarea noţiunilor de Entitate, relaţie, formă

normală, cheie primară, prin metode moderne şi prin evaluare formativă, asigură

eficienţa sporită atât sub aspectul trăiniciei cunoştinţelor însuşite cât şi sub aspectul

formării la elevi a unor calităţi şi capacităţi intelectuale, de muncă independentă sau

în grup, dar şi de cercetare individuală sau în grup.

Fiind o evaluare sistematică şi analitică a oferit informaţii concrete în legătură

cu nivelul de atingere a competenţelor elevilor, cu dificultăţile de învăţare întâmpinate

de elevi, sugerând ajustările necesare, sau chiar modificări ale metodelor şi

procedeelor utilizate la clasă.

Evaluarea a fost astfel proiectată şi realizată, încât a motivat elevii să înveţe,

să îşi monitorizeze progresul dar şi lacunele sau erorile.

În urma experimentului didactic am constatat că elevii ajung progresiv să fie

interesaţi de subiect, la început fiind mai greu sa-şi însuşească noţiunile introduse.

Din analiza datelor se constată o evoluţie pozitivă a competenţelor de a-şi

forma o gândire proprie, de a se descurca în diferite situaţii problemă.

Evaluarea de tip formative este centrată pe strategiile specifice folosite de elev în

rezolvarea problemelor, identificând acele strategii care provoacă o dezvoltare a

eficienţei, fiind legate de un domeniu de cunoştinţe de deprinderi. Din studiul efectuat

şi din experimental didactic am observat că elevii se angajează bine în practicile

comunicative şi folosesc bine instrumentele de comunicare . Modelele propuse

evaluării au fost adaptate caracteristicilor elevilor.

Din punct de vedere al dezvoltării intelectuale parcurgerea secvenţelor de învăţare

din unitatea “Modelarea datelor “ elevul a luat la cunoştinţă problemele cu care se

confruntă cel care proiectează o bază de date pentru a putea fi exploatată cât mai

corect posibil;

Elevii au dovedit că au un spirit de echipă, fiind antrenaţi de idei uneori

ingenioase dar apoi dezbătute şi analizate de întreaga clasă, echipele nu au analizat

în proporţie de sută la sută ce şi-au propus dar au reuşit să aducă corect baza de

date la prima formă normală.

103

Susţinerea proiectelor finale cu ajutorul proiectorului a fost cel mai culminant

moment, elevii dând dovadă de simţ practic în prezentările făcute, analizând destul

de bine situaţiile alese;

104

Bibliografie

1. Boriga,R., Huţanu V, –Access Curs pentru liceu , Editura L&S Soft 2005

2. Bocoş, M., Jucan, D, Fundamentele pedagogiei. Teoria şi metodologia

curriculumului., Editura Paralela 45, Piteşti 3. Burţa, Alin - Informatica manual pentru clasa a 12a, Editura ALL 2007

4. Cerchez , E., Serban,M. , Bucă, A -Modelarea datelor Manualul profesorului

documentaţie online

5. Gheorghe M, Tătărâm, M., Achinca C., Pestriţu, I.- Informatică – Manual pentru

clasa a XII-a, Editura Corint, , 2007

6. Lazarovici, Gh, Micle D., G. , Introducere in arheologia informatizată, note

de curs

7. McFadden, F.R., Hoffer, J.A.- Modern Database Management, 4nd ed,

Benjamin/Cummings 1994

8. Nicola,I. Pedagogie, Ed. Didactică şi Pedagogică Bucureşti, 1996

9. Panţiru, M., Panţiru I. – Informatică tehnologii asistate de calculator, varianta

Access manual pentru clasa a 12a,editura L&S 2003

10. Panţiru M., Panţiru, I.,Panţiru I. , Culegere de probleme Visual Fox Pro , ED.

L&S Soft, 2005

11. Panţiru M, Manual pentru clasa a 12a, Editura All 2007

12. Preda,G. - Baze de date în economie, http://www.elth.pub.ro/~preda/

13. Radulescu, F. - note de curs Modelul entitate-asociere clasic

14. Simsion,G., Witt, G, – Data Modeling Essentials, Morgan Kaufman

Publishers, 2005

15. Tâmbulea,L. Access pentru programatori, Editura Promedia Plus 2003,

16. Iacob, P., Neagu, M. - “Baze de date” – documentaţie online

17. Trandafir R., M., Mazilu,I. M., Nistorescu M., Bazele Informaticii

şiLimbaje de Programare, notr de curs, Bucureşti, 2006

http://arheologie.ulbsibiu.ro/membri/lazarovicicv.htm

http://www.elth.pub.ro/~preda/

105

18. Cioban V, note de curs ,

http://www.cs.ubbcluj.ro/~vcioban/Geografie/Anul1/cap03.ppt

19. Cursurile Oracle Internet Academy (http://academy.oracle.com

20. Documentaţie Wikipedia- enciclopedia liberă www.wikipedia.org

21. Referate online- www.referate.ro

21. Teste de evaluare din siteul https://insam.softwin.ro/insam

http://www.cs.ubbcluj.ro/~vcioban/Geografie/Anul1/cap03.ppt

http://academy.oracle.com/

http://www.wikipedia.org/

http://www.referate.ro/

https://insam.softwin.ro/insam

Documents

Normalizarea Bazelor de Date