BAZE DE DATE

2. MODELAREA DATELOR

lect. univ. Tîrșu Valentina

Conținut

1. Modelul relațional, concepte de bază

2. Structura relațională a datelor
3. Costrângeri de integritate
3.1. Tipuri de atribute deținute de entitate
3.2. Tipuri de relații
3.3. Organizarea relațiilor între tabele
3.4. Operațiuni asupra datelor în Modelul relațional
3.5. Avantajele și dezavantajele Modelelor de date relaționale
4. Proiectarea BD relaționale
4.1. Analiza de sistem (domeniu de aplicare)
4.2. Proiectarea conceptuală - modelul entitate-relație
4.3. Elaborarea schemei conceptuale
4.4. Transformarea în model relațional
4.5. Normalizarea bazelor de date relaționale
Obiective

 să descrieți conceptele de bază ale modelului relațional;

 să distingeți componentele unui model de date;
 să cunoașteți metodologia de realizare a BD;
 să descrieți construcțiile de bază ale modelării entitate – relație;
 să utilizați etapele de proiectare a modelului de date;
 să aplicați normalizarea BD;
 să proiectați corect structura unei BD.
1. Modelul relațional, concepte de bază

În 1970, matematicianul american Edgar F. Codd a publicat un articol care marchează începutul existenței MR:
Codd E.F. (1970). A relational model of data for large shared data banks. Comm. ACM, 13(6), pp. 377-387
Regulile lui Codd:
Regula fundamentală: Orice sistem care pretinde sau i se face reclamă de a fi un SGBDR trebuie să fie
capabil să gestioneaze în întregime bazele de date prin capacităţile sale de relaţionare.
1. Reprezentarea informaţiilor. La nivelul logic, toate informaţiile dintr-o BD relaţională sunt reprezentate
explicit într-un singur mod – prin valorile din tabele (relaţii de bază).
2. Accesul garantat. Se garantează faptul că orice element (dată) dintr-o BDR este accesibil din punct de
vedere logic prin apelarea la o combinaţie de nume de tabel, valoare a cheii primare şi nume de coloană.
3. Tratarea sistematică a valorilor null. Valorile null sunt acceptate pentru a reprezenta informaţiile lipsă şi
pe cele care nu pot fi aplicate în mod sistematic, indiferent de tipul de date.
4. Catalog dinamic online, bazat pe modelul relaţional. Descrierea BD este reprezentată la nivel logic în
acelaşi mod ca şi datele obişnuite, astfel încât utilizatorii autorizaţi pot folosi pentru interogarea acesteia
acelaşi limbaj relaţional aplicat datelor curente.
5. Sublimbaje de date cuprinzătoare. Un sistem relaţional poate accepta mai multe limbaje şi diverse moduri
de utilizare a terminalelor. Totuşi trebuie să existe cel puţin un limbaj ale cărui instrucţiuni să poată exprima
următoarele: •• definirea datelor •• definirea vederilor •• manipularea datelor •• constrângerile de integritate ••
autorizarea •• limitele tranzacţiilor (început, efectuare şi rulare înapoi).
1. Modelul relațional, concepte de bază (continuare)

Regulile lui Codd (continuare)

6. Reactualizarea vederilor. Toate vederile care sunt teoretic reactualizabile, pot fi reactualizate de către
sistem.
7. Operaţii de inserare, reactualizare şi ştergere de nivel înalt Capacitatea de tratare a unei relaţii de bază
sau a unei relaţii derivate (vedere) ca pe un singur operand se aplică nu numai regăsirii datelor în BD, ci şi
inserării, reactualizării şi ştergerii acestora.
8. Independenţa fizică de date Programele de aplicaţii şi activităţile de la terminale rămân logic intacte ori de
câte ori sunt făcute modificări, fie în metodele de stocare, fie în metodele de acces la date.
9. Independenţa logică de date Programele de aplicaţii şi activităţile de la terminale rămân logic intacte ori de
câte ori sunt făcute modificări în tabelele de bază cu păstrarea informaţiilor sau deteriorarea acestora.
10. Independenţa de integritate Constrângerile de integritate specifice unei anumite BDR trebuie să poată fi
definite în sublimbajul relaţional de date şi stocate în catalogul de sistem, nu în programele de aplicaţii.
11. Independenţa de distribuţie. Sublimbajul de manipulare a datelor dintr-un SGBDR trebuie să permită
programelor de aplicaţii şi interogărilor să rămână aceleaşi din punct de vedere logic dacă şi ori de câte ori
datele sunt centralizate sau distribuite fizic.
12. Regula de nonsubversiune. Dacă un sistem relaţional are un limbaj de nivel jos (câte-o-înregistrare-o-
dată), atunci acel nivel nu poate fi folosit pentru a submina sau a ocoli regulile de integritate şi constrângerile
exprimate în limbajul relaţional de nivel mai înalt (mai-multe-înregistrări-deodată).
1. Modelul relațional, concepte de bază (continuare)

Concepte :
 Modelul relațional nu include regulile, structurile, operațiile referitoate la
implementarea fizica a unui sistem de baze de date;
 Modelul relațional oferă o metodă declarativă pentru specificarea relațiilor la etapa
proiectării BD;
 Datele sunt reprezentate ca structuri bidimensionale, relatii.
 O relatie este alcatuita dintr-un numar finit de elemente numite atribute.
 Fiecare atribut poate lua valori intr-un domeniu finit, numit domeniu.
 Numarul de atribute ale unei relatii: aritate (cardinalitate).
 Elementele unei relatii: tupluri (tuples) sau inregistrari (records).
Relatie Tabel
Inregistrare Rand in tabela
2. Structura relațională a datelor

 MR se bazează pe teoria mulțimilor.

 Domeniul D – reprezintă un ansamblu de valori, caracterizat printr-un nume.
 Produsul cartezian al domeniilor este setul tuturor combinațiilor posibile de valori de
domeniu:
D1 × D2 × ... × Dn = {(d1i, d2i, ..., dni)}, unde dki 𝛜 Dk
 (d1i, d2i, ..., dni) – mulțimea de atribute, un element al produsului cartezian.
 Exemplu: D1 = (1, 2), D2 = (a, b, c).
D1 × D2 = {(1, a), (1, b), (1, c), (2, a), (2, b), (2, c)}
 O relație este un subset al produsului cartezian al domeniilor.

Relația are următoarele caracteristici.

 Are un nume distinct de numele tuturor celorlalte relații din baza de date relațională.
 Fiecare câmp a unei relații conține o singură valoare atomică (indivizibilă).
 Fiecare atribut are un nume unic.
 Valorile atributelor sunt preluate din același domeniu.
 Exemplu de produs cartezian

Postul NP Postul Salariu

manager Calalb Irina manager 10000
inginer Calalb Irina manager 7500
economist Calalb Irina inginer 10000
Calalb Irina inginer 7500
NP Calalb Irina economist 10000
Calalb Irina Calalb Irina economist 7500
Dionis Andrei Dionis Andrei manager 10000
Salapai Ion Dionis Andrei manager 7500
Gandul Ana Dionis Andrei inginer 10000
Dionis Andrei inginer 7500
Salariu Dionis Andrei economist 10000
10000 … … …
7500 Salapai Ion economist 10000

Înregistrările corespunzătoare instanțelor entității sunt evidențiate cu caractere aldine.

Terminologia proprietăților unei relației

Coloană,
Relație, tabel, entitate Domeniu
Cheie
primară
Descriere
Anul
Cod NP Funcția Salariu (schema
angajării
relației)
023 Marchiz Dana inginer 7600 2005

Câmpuri, 113 Slivca Dumitru maager 10000 2001 Rând,

atribute Înregistrare,
Tuplu

Relația are două proprietăți principale:

1. Relația nu trebuie să aibă tupluri care să se repete, deoarece este o mulțime.
2. Ordinea tuplurilor în relație este irelevantă.
3. Costrângeri de integritate

Constrângerile de integrare pot fi divizate în

două grupuri:
Constrângeri de comportament, care se referă la caracteristicile unui atribut
(sau domeniu) (de ex.: valori diferite de 0, pozitive sau o anumită perioadă
calendaristică., etc);

Constrângeri de dependență între date, specifică legătura dintre atribute

(domenii) (de ex.: un student este înscris într-o grupă, pe când grupa include
mai mulți studenți, etc.)
3.1. Tipuri de atribute deținute de entitate

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: un atribut care are valori unice pentru fiecare înregistrare
 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ă
 Cheie externă: atribut sau un set de atribute ale unei relații care corespunde unei chei candidat a altei
relații (posibil aceeași). De obicei servește pentru organizarea relațiilor între tabele.
Stabilirea cheii primare CP a unei entităţi (Bruce, 1992)
 (i) cheia candidat a unei entități care nu-şi modifică valoarea pe toată durata de viaţă a oricărei instanţe
 (ii) pentru orice instanţă a entității, atributele CP au valori valide şi non-nule
 (iii) dacă CP are prea multe atribute, se înlocuieşte cu o cheie surogat
 (iv) nu folosi chei “inteligente” (clasificare, localizare, structurare)
3.2. Tipuri de relații
MEDICI
N
Cardinalitatea unei relații este PAT
tratament
SALON
determinată de numărul de 1 1
instanțe de entitate incluse în M
1 N
relație. ocupa PACIENTI internare

Legăturile prezentate în figură, ținând cont de semantică, înseamnă următoarele:

 pat-pacient (1: 1) - fiecare pacient ocupă un pat, fiecare pat la un moment dat poate fi
ocupat de un singur pacient;
 salonul pacientului (1: n) - fiecare pacient se află într-un salon, fiecare salon poate avea
mai mulți pacienți;
 pacient-medic (n: m) - fiecare pacient poate fi tratat de mai mulți medici, fiecare medic
poate trata mai mulți pacienți.

12
3.3. Organizarea relațiilor între tabele
Legătura unu-la-mulți: Secții – Angajați
Tabelul Angajați Tabelul Secții
Cod NP angajat Sectia Număr Denumire sectie
023 Lupu Adriana 2 sec?ie
113 Marandici Dana 1 1 Resurse umane
101 Stratulat Andrei 2 2 Finante
056 Margine Octavian 1 3 Marketing
... ... ... ... ...
098 Didica Anatol 9 9 Proiectare

Secția: Număr secție:

– cheie externă în tabelul Angajați – cheie primară în tabelul Secții

De fapt, o cheie externă este o constrângere de integritate, conform căreia setul de valori
cheie străine este un subset al valorilor cheie potențiale ale unei anumite relații.
3.3. Organizarea relațiilor între tabele

Legătura mulți-la-mulți: Proiecte – Angajați

Tabelul Angajați Tabelul Proiecte
NP Număr Cod Denumire proiect
Veveri?a Ada 023
Tabelul Participare 23/Н Economia cirsulară
Russu Ion 113 18-C Energie
Participant Functia Proiect regenerabilă
Mogea Dina 101 113 executant 23/Н
101 manager 18-C
09/Р Ecologie
Curcan Dinu 056
056 executant 18-C ... ...
Tertea Dima 098 101 consultant 09/Р
... ... 098 manager 23/Н
... ... ...

În tabelul Participare:
Participant– cheie externă în tabelul Angajați
Proiect – cheie externă în tabelul Proiecte
3.4. Operațiuni asupra datelor în Modelul relațional

Operațiunile sunt aplicate tuplurilor de relații.

Următoarele operațiuni sunt utilizate în Modelul de date relaționate:
 memorizarea: introducerea informațiilor în baza de date (necesită formarea de valori
cheie unice și atribute obligatorii ale tuplurilor);
 extragerea: citire date;
 actualizarea: modificarea datelor - schimbarea valorilor atributelor tuple-urilor;
 lichidarea: ștergerea fizică sau logică a datelor (tuple).
 La prezența cheilor străine, operațiile de modificare a datelor sunt, de asemenea,
responsabile pentru stabilirea / schimbarea / ruperea legăturilor.
3.5. Avantajele și dezavantajele Modelelor de date relaționale

Avantaje:
 prezența unei baze teoretice;
 gradul maxim de independență a datelor față de programe;
 disponibilitatea unui limbaj de interogare declarativă.

Dezavantaje:
 eficiență scăzută a execuției interogărilor;
 lipsa corespondenței clare între entitățile domeniului de activitate și tabelele bazelor de
date relaționale.
ANGAJAȚI

ADRESE TELEFOANE …. STUDII

4. Proiectarea BD relaționale

1. Analiza de sistem – cerințe privind BD

2. Elaborarea Modelului entitate-relație (ER)
3. Elaborarea schemei conceptuale
4. Transformarea în model relațional –
crearea design-ului logic al bazei de date
5. Normalizarea bazei de date
4. Proiectarea BD relaționale

Realizarea unei baze de date

LMD – Limbaj de manipulare a datelor
LDD – Limbaj de definire a datelor
4.1. Analiza de sistem

◆ Se realizeaza analiza segmentului din lumea reala care va fi

gestionat de aplicatia respectiva.
◆ Rezulta o specificatie neformalizata a cerintelor constand din doua
componente:
• Cerinte privind continutul bazei de date: categoriile de date
care vor fi stocate şi interdependentele dintre acestea.
• Cerinte privind prelucrarile efectuate de aplicatie:
prelucrarile efectuate asupra datelor, arborele de meniuri al
aplicatiei, machetele formatelor de introducere şi prezentare a
datelor şi ale rapoartelor tiparite de aceasta.
4.1. Analiza de sistem (continuare)

Activități:
 Analiza activitatii desfasurate la momentul respectiv de beneficiarul aplicatiei sau de o multime
reprezentativa de beneficiari;
 Analiza continutului de date şi a functionalitatii aplicatiilor software - daca exista - care vor fi inlocuite de
noua aplicatie (meniuri, machete ecran, machete rapoarte);
 Analiza formularelor tipizate şi a altor documente utilizate de beneficiar pentru realizarea activitatii
respective;
 Identificarea interdependentelor dintre datele stocate in baza de date şi a restrictiilor privind valorile lor;
 Identificarea prelucrarilor care se declanseaza automat atat in cazul modificarii bazei de date cat şi la
momente prestabilite de timp (de exemplu sfarsit de luna, de an, etc.);
 Identificarea operatiilor care sunt necesare beneficiarului in activitatea curenta dar care in acest moment nu
sunt realizate prin intermediul aplicatiilor software folosite precum si a operatiilor care pot fi incluse in
mod natural in noua aplicatie.
 Identificarea bazelor de date existente care pot fi folosite de noua aplicatie - direct sau printr-un import
initial de date - evitandu-se reintroducerea manuala a acestora.
 Identificarea modalitatilor de transfer de date intre noua aplicatie şi alte aplicatii care ruleaza deja la
beneficiar şi care vor fi folosite şi in viitor de catre acesta.
 Identificarea necesitatilor privind datele şi prelucrarile care pot fi in viitor necesare beneficiarului, deci a
posibilelor dezvoltari in timp ale aplicatiei.
4.2. Elaborarea Modelului entitate-relație (ER)

Model conceptual (semantic)

 surprinde cunoştinţele esenţiale referitoare la un domeniu de
aplicaţie, aşa cum sunt ele percepute de analist;
 a fost introdus în metodologiile structurate de analiză şi proiectare;
 operează numai asupra domeniului problemei;
 stabilirea unor definiţii riguroase a construcţiilor folosite.
Model conceptual de date
 obiective
 identificarea şi definirea elementelor din domeniul problemei pentru care trebuie
memorate date;
 identificarea şi definirea relaţiilor dintre acestea.

21
4.2. Elaborarea Modelului entitate-relație (ER)(continuare)
Avantaje:
 Nu este legat direct de nici unul dintre modelele folosite de sistemele de
gestiune a bazelor de date (relational sau orientat obiect) dar exista
algoritmi de transformare din model ER in celelalte modele de date.
 Este intuitiv, rezultatul modelarii fiind o diagrama care defineste atat datele
stocate in baza de date cat şi interdependentele dintre acestea.
 Poate fi usor de inteles de nespecialisti si faciliteaza punerea de acord cu
beneficiarul asupra structurii bazei de date a aplicatiei, evitandu-se in acest
fel o proiectare neconforma cu realitatea sau cu cerintele
 Proiectarea se poate face pe portiuni, diagramele partiale rezultate putand fi
apoi integrate pe baza unor algoritmi şi metode bine puse la punct.

22
4.2. Elaborarea Modelului entitate-relație (ER)(continuare)

Modelul entitate-relaţie (Entity-Relationship Model, E-R)

P.P. Chen, The entity-relationship model: toward a unified view of data, ACM
Transactions on Database Systems 1(1976), No.1, 9-36

 reprezentare detaliată şi structurată a datelor din domeniul problemei

 Elementele modelului ER
 entitate
 legătură
 atribut

 se reprezintă grafic prin diagrama entitate-relaţie (diagrama E-R, Entity-

Relationship Diagram)
 foloseşte notaţiile E-R
 4.2. Elaborarea Modelului entitate-relație (ER)(continuare)

Notaţii E-R

Entitate Legătură Cheie primară Atribut Atribut cu valori multiple

Simboluri de bază

Unară Binară Ternară

Gradul legăturilor

24
4.2. Proiectarea conceptuală - modelul entitate-relație (continuare)

Entităţile - modeleaza clase de obiecte concrete

sau abstracte despre care se colecteaza
informatii, existenta independenta şi pot fi
identificate in mod unic. Ele definesc persoane,
locuri, obiecte, evenimente, concepte din mediul MEDIC
utilizatorului pentru care organizaţia doreşte să ANGAJAT
deţină date tratament
exemple: manager
 persoană; ANGAJAT, STUDENT, PACIENT
PACIENT
 loc: STAT, REGIUNE, ŢARĂ
а) legatura unara PROFESOR
 obiect: MAŞINĂ, CLĂDIRE, AUTOMOBIL b) legătură binară
 eveniment: VÂNZARE, ÎNREGISTRARE, SCHIMBARE
 concept: CONT BANCAR, CURS UNIVERSITAR, CENTRU STUDENTТ examinaere DISCIPLINA
DE PRELUCRARE
 tip de entitate (clasă de entitate) c) legătură ternara
 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

25
4.2. Proiectarea conceptuală - modelul entitate-relație (continuare)

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;
 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
• CURS UNIVERSITAR: DENUMIRE, SPECIALIZARE, SEMESTRU, PROFESOR,
NUMĂR ORE PE SĂPTĂMÂNĂ, FORMĂ DE EXAMINARE
4.2. Proiectarea conceptuală - modelul entitate-relație (continuare)

Casificare atribute
 atributele de identificare (formand impreuna identificatorul entitatii) reprezinta acea
multime de atribute care permit distinctia intre instantele aceleiasi entitati.

 atributele de descriere (sau descriptori) sunt folositi pentru memorarea

caracteristicilor suplimentare ale instantelor.

 Exemplu: Pentru entitatea STUDENTI

• Matricola este atribut de identificare
• celelalte atribute sunt descriptori
 Valoarea unui atribut poate fi:
• obligatorie (opţiunea NOT NULL, notată uneori cu prefixul „asterisc” *)
• opţională (opţiunea NULL, notată cu un „cerculeţ” o)
4.2. Proiectarea conceptuală - modelul entitate-relație (continuare)

Exercițiu

Dati exemple de atribute ale urmatoarelor entitati:

- CLIENȚI
- MAȘINI
- ANGAJAT
- SERVICIU
- TRANZACȚII
- CONTRACT DE MUNCĂ
4.2. Proiectarea conceptuală - modelul entitate-relație (continuare)

Entitate Atribute
CLIENȚI nume, prenume, data nașterii, adresa, telefon
MAȘINI model, culoare, preț
SRVICIU denumire, descriere
TRANZACȚII suma, data
CONTRACT DE MUNCĂ data_început, salariu
4.2. Elaborarea Modelului entitate-relație (ER) (continuare)

NUMĂR NUME ADRESĂ NUMĂR

MATRICOL TELEFON

STUDENT

Atribute şi cheie primară - reprezentare E-R

MARCĂ NUME ADRESĂ CALIFICARE
ANGAJAT

ANGAJAT

Eprezentare grafică - atribute cu valori multiple

4.2. Elaborarea Modelului entitate-relație (ER) (continuare)

Legături (asocieri)
 asociere între instanţe ale uneia sau mai multor tipuri de entităţi care prezintă
interes pentru problema studiată

STUDENT Urmează CURS

Relaţie în notaţia E-R

DATA
EXAMINĂRII

STUDENT Urmează CURS

Relaţie cu atribut
4.2. Elaborarea Modelului entitate-relație (ER) (continuare)

1. Gradul de asociere a unei legături

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

2. Cardinalitatea unei legături

 Numărul de participanţi la asociere, exprimat în ambele sensuri

Grad de asociere unar

PERSOANĂ Căsătorită ANGAJAT Conduce

cu

0:1 0:M

32
4.2. Elaborarea Modelului entitate-relație (ER) (continuare)

Grad de asociere binar

ANGAJAT Are atribuit LOC DE PARCARE

1:1
PLAN DE
ÎNVĂŢĂMÂNT Conţine SEMESTRU

1:M

STUDENT Urmează CURS

M:N

33
4.2. Elaborarea Modelului entitate-relație (ER) (continuare)

Grad de asociere ternar

MATERIAL

FURNIZOR Expediază MAGAZIE

CANTITATE

34
4.2. Elaborarea Modelului entitate-relație (ER) (continuare)

Atribut asociat

 In acest caz informatii ca anul absolvirii, media, specializarea nu pot fi conectate nici la
STUDENT (pentru ca un student poate fi absolventul mai multor facultati in ani diferiti, cu
medii diferite, etc.) si din motive similare nici la FACULTATE.
 Ele descriu asocierea unui student cu o facultate si de aceea vor fi atasate asocierii
A_ABSOLVIT.
 Toate atributele unei asocieri sunt atribute descriptive, neexistand in acest caz un
identificator al asocierii.
35
 4.2. Elaborarea Modelului entitate-relație (ER) (continuare)

Exprimarea cardinalităţii în diagramele E-R

Cardinalitate obligatorie 1

Cardinalitate M (multiplă: 1, 2, ..., M)

Cardinalitate opţională 0 sau 1

Cardinalitate opţională 0 sau M

(0, 1, 2, ..., M)

Exprimarea cardinalităţii m:M

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 36
m = M - se specifică numai unul dintre ele
4.2. Elaborarea Modelului entitate-relație (ER) (continuare)

1. Exprimarea cardinalităţii de tip „unu la unu” sunt asocieri în care maximele

cardinalităţii au valoarea 1.

Exemplu:

37
4.2. Elaborarea Modelului entitate-relație (ER) (continuare)

 Exprimarea cardinalităţii de tip „unu la mai mulţi” sunt asocieri în care maxima
cardinalităţii unei entităţi este unu, iar a celeilalte entităţi are valoarea „mulţi”.

Exemplu:

38
4.2. Elaborarea Modelului entitate-relație (ER) (continuare)

 Exprimarea cardinalităţii de tip „mulţi la mulţi” sunt asocieri în care maximele

cardinalităţii au valoarea „mulţi”.

Exemplu:

39
4.2. Elaborarea Modelului entitate-relație (ER) (continuare)
Observaţie:

Asocierea de tip „mulţi la mulţi” se transformă în două asocieri de tipul „unul la mulţi” fiind, de
regulă, mai uşor de implementat şi de utilizat şi anume:

 Exemplu: În cazul exemplului de mai sus, transformarea asocierii „mulţi la mulţi” în asocieri de
tipul „unu la mulţi” se poate realiza prin construirea unei noi entităţi DEPOZIT_PRODUS astfel:

40
 4.3. Elaborarea schemei conceptuale

Diagrama Entitate-Relaţie (ERD – Entity -

Relation Diagram) modelează grafic BD. În
această diagramă sunt reprezentate
entităţile, relaţiile şi, eventual, atributele, sub
forma unui graf neorientat.
Entitate - obiect de interes pentru care
trebuie sa existe date înregistrate.
Reguli de creare a entităților:
 Entitatile au informatii descriptive, pe cand
atributele nu poseda astfel de informatii. • Fiecare entitate e denumita in mod unic
 Atributele vor fi atasate la entitatile pe • Pentru fiecare entitate se da o descriere
care le descriu in mod nemijlocit. detaliata
 Folosirea identificatorilor compusi va fi
evitata.
4.3. Elaborarea schemei conceptuale(continuare)
4.3. Elaborarea schemei conceptuale (continuare)
4.3. Elaborarea schemei conceptuale (continuare)
4.3. Elaborarea schemei conceptuale (continuare)

Relație
 Entitatile pot forma relatii intre ele
 Relatiile sunt reprezentate prin verbe
 Intre doua entitati poate exista mai mult decat o relatie
Cardinalitatea unei relatii: numarul maxim de tupluri din fiecare entitate care participa la
o relatie.
 Exemple: M 1
Student Facultate
studiază la
 Multi-la-unul (many-to-one N:1)
1 1
 Unu la unu (one-to-one 1:1) Profesor Facultate
angajat

 Multi la multi (many-to-many N:M) M N

Student Curs
studiază la
4.3. Elaborarea schemei conceptuale (continuare)

Diagrama entitate-legatura
4.3. Elaborarea schemei conceptuale (continuare)

• Relației M:N se
evită prin
crearea unei
relații
suplimentare
4.3. Elaborarea schemei conceptuale (continuare)

 Entitate dependenta/entitate master

Modul e o entitate dependenta de entitatea curs (un curs e format din mai multe
module). Cardinalitate intre master si detaliu: 1:M, cel putin 1:0 (un curs nu are nici un
modul).
 Entitate recursiva PROFESORI PROFESORI

manager
4.3. Elaborarea schemei conceptuale (continuare)

Diagrama entitate-relație – identificarea ierarhiilor

 In cazul in care despre anumite subclase ale unei clase de obiecte exista informatii
specifice, clasa şi subclasele (care la pasul anterior au fost catalogate ca entitati)
sunt interconectate intr-o ierarhie de incluziune sau generalizare, dupa cum este
cazul.

 La acest pas se face şi o reatasare a atributelor pentru evitarea redundantei

Rearanjare atribute:

 La entitatea tata vor fi atasate atributele care formeaza identificatorul şi descriptorii

care modeleaza informatii specifice intregii clase.

 La entitatile fiu vor fi atasate atributele de identificare (aceleasi ca ale tatalui) şi

atributele care modeleaza informatii specifice doar acelei subclase de obiecte.
4.3. Elaborarea schemei conceptuale (continuare)

Diagrama entitate-relație – identificarea ierarhiilor

NUME . . ..
MATR

STUDENT

CAMERA
MATR

CAMINIST
CAMIN
4.4. Transformarea în model relațional

Transformarea entitatilor
• Entitatile devin tabele
• Entitatile dependente devin tabele dependente
• Subentitatile devin subtabele (tabele ale caror cheie primara contine cheie straina ce
face referinta la cheia primara a tabelul superentitate).

Transformarea relatiilor
• Relatiile 1:1 devin chei straine, cheia straina fiind plasata in tabelul cu mai putine
inregistrari
• Relatia N:1 devine cheie straina plasate in tabelul care se afla in partea “multi” a
relatiei. Exemplu: o facultate are mai multi studenti, un student e la o singura facultate
• O relatie multi-multi N:M se transforma intr-un tabel asociativ, care are doua chei
straine pentru cele doua tabele asociate. Exemplu: mai multi studenti-la mai multe cursuri

Transformarea atributelor
• Atributele simple ale unei entitati devin coloane in tabelul provenit din relatie.
• Atributele repetitive (multivaloare) devin tabele dependente care contin o cheie
straina ce face referinta la cheia primara a entitatii si atributul multi-valoare.
• Atributele simple ale unei relatii M:N vor deveni coloane ale tabelului asociativ.
4.4. Transformarea în model relațional (continuare)

Etapele proiectării:

 Normalizarea BD – schema conceptuală a BD;

 Exista o serie de reguli care descriu ce inseamna o structura corecta. Ele definesc asa
numitele forme normale.
 Pe baza structurii bazei de date şi a dependentelor rezultate atat din transformare şi a altor
dependente identificate de proiectant in analiza de sistem se poate face o operatie numita
normalizare: se modifica structura bazei de date astfel incat toate tabelele din aceasta sa fie in
forma normala dorita.

 Implimentarea specifică SGBD-lui folosit.

 In aceasta etapa se realizeaza crearea structurii bazei de date obtinuta in etapa precedenta pe baza
facilitatilor oferite de sistemul de gestiune a bazelor de date ales.
 Rezultatul ei este programul de creare scris in limbajul de definitie a datelor acceptat de SGBD-ul
utilizat.
4.5. Normalizarea bazelor de date relaționale

Dependente functionale pentru care determinantul nu este cheie a tabelului:

cod_client -> {nume_client, numar_telefon}
cod_comanda -> {data, cod_client, nume_client, nr_telefon}
cod_articol -> {nume_articol, cost_articol}
4.5. Normalizarea bazelor de date relaționale (continuare)

Datorita dependentelor prezente intre atributele relatiei, pot aparea urmatoarele anomalii:
- redundante in date;
- Anomalii de actualizare:
- Anomalie la insertie;
- Anomalie la stergere;
- Anomalie la modificare;
Anomaliile apar datorita dependentelor din baza de date, dependente pentru care
determinantul nu este cheie a tabelului.
Normalizarea: procesul reversibil de descompunere a unui tabel relational in tabele cu o
structura mai simpla, proces care are ca scop evitarea redundantei datelor si evitarea
anomaliilor de actualizare.
Reversibil: descompunerea se face fara pierdere de informatie.
4.5. Normalizarea bazelor de date relaționale (continuare)
4.5. Normalizarea bazelor de date relaționale (continuare)

Normalizarea bazei de date

• Prima forma normala (1NF – First Normal Form)
• A doua forma normala (2NF – Second Normal Form)
• A treia forma normala (3NF – Third Normal Form)
• Forma normala Boyce-Codd (BCNF – Boyce-Codd Normal Form)
• A patra forma normala (4NF – Fourth Normal Form)
4.5.1. Prima forma normala (1NF – First Normal Form)

Prima forma normala este o forma normala utilizata in normalizarea bazelor de date, care exclude
posibilitatea existentei grupurilor repetitive cerand ca fiecare camp intr-o baza de date sa cuprinda
numai o valoare atomica. De asemenea, prima forma normala cere si ca fiecare inregistrare sa fie
definita astfel incat sa fie identificata in mod unic prin intermediul unei chei primare.

Incalcari ale primei forme normale.

(1) Mai multe valori semnificative in acelasi camp
4.5.1. Prima forma normala (1NF – First Normal Form) (continuare)
Mai multe coloane reprezentand acelasi tip de date/fapte/obiecte

Interogarile pentru a selecta inregistrari pe

baza componentei campurilor repetitive sunt
foarte dificile.
De exemplu, o interogare pentru a selecta
acele orase care ofera acelasi tip de Serviciu
public, sa spunem “Politie” (acesta putand sa
apara in oricare din coloanele “Servicii
publice”) va genera cautari in 9 perechi
separate de coloane.

Pentru a asigura unicitatea unei inregistrari,

se va utiliza cheia primara. In exemplul dat,
prin introducerea unei coloane aditionale de
tip intreg, auto-incrementat, se asigura
unicitatea fiecarei inregistrari.
4.5.2. A doua forma normala (2NF – Second Normal Form)
A doua forma normala cere ca toate elementele unei tabele sa fie dependente functional de
totalitatea cheii primare.
Daca unul sau mai multe elemente sunt dependente functional numai de o parte a cheii primare,
atunci ele trebuie sa fie separate in tabele diferite.
Daca tabela are o cheie primara formata din numai un atribut, atunci ea este automat in 2NF (a 2-
a forma normala).
Exemplu : fie o tabelul “Comanda”: Cheia primara este o cheie compusa, formata din
ComandaID si ReperID.
ReperNume depinde numai de ReperID, nu si de
ComandaID.
Pentru a fi in 2NF, tabelul trebuie modificat in felul
urmator:
4.5.3. A treia forma normala (3NF – Third Normal Form)
Toate atributele non-chei ale unei relatii depind numai de chei candidate ale acelei relatii.
Bill Kent: the relation is based on the key, the whole key and nothing but the key", la care unii
adauga: "so help me Codd“ (“relatia depinde de cheie, de intreaga cheie si de nimic altceva decat
de cheie”, la care unii adauga “asa sa ne ajute Codd” ).
Toate atributele non-cheie sunt (trebuie sa fie) mutual independente.
Exemplu:
Tabela Piese de schimb, in care cheia primara (si cheie unica) este Piese de schimb

trebuie reorganizata astfel pentru a fi in a 3-a forma normala:

4.5.4. Forma normala Boyce-Codd (BCNF – Boyce-Codd Normal Form)
Boyce-Codd e o versiune putin mai restrictiva de forma normala 3.
In cazul unei forme normale 3, toate atributele depinde de o cheie, o cheie in intregime si numai de o
cheie (asa sa ne ajute Codd ).
Tabelul de mai jos este in 3NF pentru ca toate atributele depind de o cheie si numai de o cheie; cu
toate acestea, exista o redundanta, deoarece perechile (cod_sofer, cod_autobuz) (S1, A1) , (S2, A2)
apar de cate doua ori in tabela.

Se pot elimina astfel de redundante dupa cum urmeaza: din tabelul initial se elimina coloana
“cod_autobuz”; se creeaza un nou tabel, cu atributele “cod_sofer” si “cod_autobuz”, cu doar 2
coloane, constituind impreuna cheia primara a noului tabel. Tabelele rezultate sunt in FNBC
(BCNF).
4.5.5. A patra forma normala (4NF – Fourth Normal Form)

In exemplul de mai jos, fiecare restaurant livreaza un tip de pizza intr-o arie de distributie. Pentru
ca aici cheia primara este formata din (Restaurant, Tip de pizza, Aria de distributie) si nu exista
atribute non-cheie, nu se incalca nici o forma normala anterioara (1, 2, 3 ori B-C). Dar deoarece
varietatile de pizza oferite de un restaurant sunt independente de ariile de distributie, exista
redundante in tabela: pentru fiecare Restaurant Jerry’s, se mentioneaza de 3 ori ca se ofera Tip de
pizza “Pufos”. De asemenea, daca dorim sa adaugam, de ex. tipul “Subtire” pentru Tip de pizza, la
Jerry’s, va trebui sa adaugam 3 inregistrari, cate una pentru fiecare Arie de distributie.

Solutia este descompunerea in doua tabele, separand dependentele <Restaurant-Tip de pizza> si

<Restaurant- Aria de distributie>
5. Aplicație propusă

 Considerăm scenariul BD a unui magazin online cu un anumit specific. Stabiliţi

întrebările la care trebuie să răspundă aceasta din diverse perspective de utilizare
(client, agent de vânzări, manager). Reprezentaţi diagrama ER, indicând raportul de
cardinalitate al fiecărei relaţii şi atributele de legătură. Verificaţi dacă modelul ER astfel
conceput răspunde întrebărilor beneficiarilor. Formulaţi modul de desfăşurare a unor
tranzacţii şi impuneţi constrângerile necesare pentru funcţionarea corectă a SGBD.
Recapitulare

1. Relatați despre modelul relațional.

2. Identificați necesitatea respectării regulilor definite de E.F. Codd la elaborarea BDR.
3. Descrieți componentele ce le include o relație.
4. Relatați despre produslui cartezian al relațiilor.
5. Clasificați și descrieți constrțngerile de integrare.
6. Relatați despre cardinalitatea unei relații.
7. Relatați despre gradul de asociere a relațiilor.
8. Enumerați etapele de proiectare a BD.
9. Argumentați necesitatea analizei de sistem la proiectarea BD.
10. Relatați despre construirea Modelului entitate – relație (ER).
11. Descrieți etapa de transformare a ER.
12. Definiți etapele de normalizare a BD.