Download - 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
Scornicești Politie
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
Timp de predare 35 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;
î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
Timp de predare 40 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; î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
prezentarea animaţiilor
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
Timp de predare 20 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; învăţarea prin
descoperire dirijata, inductiva, experimentala,
exercițiul de consolidare
Descriere prezentarea noțiunii de identificator unic
prezentarea convențiilor de reprezentare
prezentarea animaţiilor
rezolvarea sarcinilor de lucru
Cuvinte cheie identificator unic
identificator unic simplu
identificator unic compus
M3.2 – Relaţii
Obiective didactice OP16, OP18, OP19
Timp de predare 30 min
Tip de interacţiune cu
elevii
metode de comunicare orală: expunere,
conversaţie, studiu de caz
metode de acțiune: exercițiul, învăţarea prin
descoperire
procedee de instruire: explicația; învăţarea prin
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
prezentarea animaţiilor
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
Timp de predare 20 min
Tip de interacţiune cu
elevii
metode de comunicare orală: expunere,
conversaţie, studiu
de caz
metode de acțiune: exercițiul, învăţarea prin
descoperire
procedee de instruire: explicația; învăţarea prin
descoperire
dirijata, inductiva, experimentala, exercițiul de
consolidare
Descriere prezentarea categoriilor de Relaţii
prezentarea tipurilor
prezentarea animaţiilor
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
Timp de predare 30 min
Tip de interacţiune cu
elevii
metode de comunicare orală: expunere,
conversaţie, studiu de caz
metode de acțiune: exercițiul, învăţarea prin
descoperire
procedee de instruire: explicația; învăţarea prin
descoperire dirijata, inductiva, experimentala,
exercițiul de consolidare
Descriere prezentarea exemplelor
61
realizarea sarcinilor de lucru
Cuvinte cheie entitate de intersecție
M5.1 – Prima formă normală
Obiective didactice OP24, OP25, OP26
Timp de predare 20 min
Tip de interacţiune cu
elevii
metode de comunicare orală: expunere,
conversaţie, studiu de caz
metode de acțiune: exercițiul, învăţarea prin
descoperire
procedee de instruire: explicația; învăţarea prin
descoperire dirijata, inductiva, experimentala,
exercițiul de consolidare
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
Obiective didactice OP27, OP28, OP29
Timp de predare 20 min
Tip de interacţiune cu
elevii
metode de comunicare orală: expunere,
conversaţie, studiu de caz
metode de acțiune: exercițiul, învăţarea prin
descoperire
procedee de instruire: explicația; învăţarea prin
descoperire dirijata, inductiva, experimentala,
exercițiul de consolidare
Descriere definirea noțiunii de 2NF – Second Normal Form
prezentarea necesităţii utilizării 2NF
62
realizarea sarcinii de lucru
Cuvinte cheie 2NF
M5.3 – A treia forma normală
Obiective didactice OP30, OP31
Timp de predare 20 min
Tip de interacţiune cu
elevii
metode de comunicare orală: expunere,
conversaţie, studiu de caz
metode de acțiune: exercițiul, învăţarea prin
descoperire
procedee de instruire: explicația; învăţarea prin
descoperire dirijata, inductiva, experimentala,
exercițiul de consolidare
Descriere definirea noțiunii de 3NF – Third Normal Form
prezentarea necesitatii utilizării 1NF
realizarea sarcinii de lucru
Cuvinte cheie • 3NF
M6 Aplicaţii; miniproiect
Obiective didactice OP21, OP22, OP28
Tip de interacţiune cu
elevii
metode de comunicare orală: expunere,
conversaţie, studiu de caz
metode de acțiune: exercițiul
procedee de instruire: explicația; învăţarea prin
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.
Convenţii de reprezentare
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.
Convenţii de reprezentare
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)
București Politie Salubritate Canalizare
Brașov Canalizare Politie Salubritate
Scornicești Politie
84
Oraș Servicii publice Servicii publice(2) Servicii publice(3)
București Politie Salubritate Canalizare
Brașov Canalizare Politie Salubritate
Scornicești Politie
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
Scornicești 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.
Se stabilesc relaţiile necesare între noile
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.
Se stabilesc relaţiile necesare între noile
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
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