Sunteți pe pagina 1din 39

Cursul

8
Normalizare
Definitie BDR
—  O bază de date relaţională (BDR) reprezintă un
ansamblu de relaţii (tabele) de date împreună cu
legăturile dintre ele.
Normalizarea
—  Este o teorie construită de EF Codd în jurul conceptului de
forme normale (FN), care ameliorează structura BD prin
înlăturarea treptată a unor neajunsuri şi prin adăugarea
unor facilităţi sporite privind manipularea datelor.
—  Scopul proiectării unei BDR este ca informațiile sa fie
stocate într-un singur loc, în locul cel mai potrivit.
Normalizarea
—  Tehnica de normalizare este utilizată în activitatea de
analiza/proiectare a structurii BDR şi constă în eliminarea
unor anomalii (neajunsuri) de actualizare din structură.
—  Se realizează organizând coloanele (atributele) şi tabelele
(relaţiile) unei BDR pentru reducere redundanţei şi
îmbunătăţirea integrităţii
—  Normalizarea utilizează ca metodă descompunerea top-
down a unei tabele în două sau mai multe tabele, păstrând
informaţii (atribute) de legătură.
Anomaliile de actualizare
—  anomalia de modificare = este dificil de modificat o
valoare pentru o coloană atunci când ea apare în mai
multe rânduri.

Simbol Emitent Cod_Fiscal Cod_Piata Den_Piata Data Val_totala


SNP Petrom 1590082 REGS Regular 07.01.2014 1.600.000
SNP Petrom 1590082 ODDS Odd lot 07.01.2014 500.000
TLV Banca Transilvania 5022670 REGS Regular 07.01.2014 1.200.379
TLV Banca Transilvania 5022670 ODDS Odd lot 07.01.2014 119.000
TLV Banca Transilvania 5022670 REGS Regular 08.01.2014 1.258.379
Anomaliile de actualizare
—  anomalia de ştergere = stergând un rand dintr-o tabelă,
pe lângă informaţiile şterse, se pierd şi informaţiile
utile existente în tuplul respectiv;

Simbol Emitent Cod_Fiscal Cod_Piata Den_Piata Data Val_totala


SNP Petrom 1590082 REGS Regular 07.01.2014 1.600.000
SNP Petrom 1590082 ODDS Odd lot 07.01.2014 500.000
TLV Banca Transilvania 5022670 REGS Regular 07.01.2014 1.200.379
TLV Banca Transilvania 5022670 ODDS Odd lot 07.01.2014 119.000
TLV Banca Transilvania 5022670 REGS Regular 08.01.2014 1.258.379
Anomaliile de actualizare
—  anomaliile de adăugare = nu pot fi incluse noi
informaţii necesare într-o tabelă deoarece nu se
cunosc şi alte informaţii utile (de exemplu valorile
pentru cheie), informațiile işi pot pierde consistenţa

Simbol Emitent Cod_Fiscal Cod_Piata Den_Piata Data Val_totala


SNP Petrom 1590082 REGS Regular 07.01.2014 1.600.000
SNP Petrom 1590082 ODDS Odd lot 07.01.2014 500.000
TLV Banca Transilvania 5022670 REGS Regular 07.01.2014 1.200.379
TLV Banca Transilvania 5022670 ODDS Odd lot 07.01.2014 119.000
TLV Banca Transilvania 5022670 REGS Regular 08.01.2014 1.258.379
Dependente funcționale
—  Atributul B este dependent funcţional de atributul A dacă şi numai
dacă fiecare valoare a atributului A este asociată cu exact o valoare a
atributului B.
—  Valorile din B sunt in mod unic determinate de valorile din A.
—  Se spune că A este determinant al lui B, sau că A determină pe B şi se
notează A→B.
—  Simbol → Denumire, Simbol → Cod_Fiscal, Cod_Fiscal → Denumire,
Cod_Fiscal → Simbol
—  Simbol + Cod_Piata + Data → Val_totala
—  Cod_Piata → Den_Piata, Den_Piata → Cod_Piata

Simbol Denumire Cod_Fiscal Cod_Piata Den_Piata Data Val_totala


SNP Petrom 1590082 REGS Regular 07.01.2014 1.600.000
SNP Petrom 1590082 ODDS Odd lot 07.01.2014 500.000
TLV Banca Transilvania 5022670 REGS Regular 07.01.2014 1.200.379
TLV Banca Transilvania 5022670 ODDS Odd lot 07.01.2014 119.000
TLV Banca Transilvania 5022670 REGS Regular 08.01.2014 1.258.379
Cheie candidata
—  Fie relaţia R = {A1, A2, ... , An}. O supercheie este un
set de atribute S⊆ R cu proprietatea ca nu exista doua
tupluri t1 si t2 pentru care t1[S]=t2[S].
—  O cheie candidata este o supercheie minima pentru
relația respectiva, adică un set de atribute alese astfel
încât:
—  Relația nu are doua tupluri cu valori identice pentru
aceste atribute (numite si atribute prime);
—  Nu exista un subset al acestor atribute care sa identifice
in mod unic fiecare tuplu.
Forma normala 1
—  O relaţie R este în FN1 dacă domeniile pe care sunt
definite atributele relaţiei sunt constituite numai din
valori atomice (elementare). Deci, un tuplu nu trebuie
să conţină atribute sau grupuri de atribute repetitive.
—  Este forma de bază a relaţiilor, care figurează ca
cerinţă minimală în cazul majorităţii SGBDR.
Forma normala 1
Emitenti
Simbol (PK)
Denumire Atribute repetitive?
Cod_Fiscal
Cod_Poştal
Adresă
Conturi_bancare
[…]
Forma normala 1
Emitenti
Conturi_Bancare
Simbol (PK) Emitenti
#Simbol (PK,FK)
Denumire #Simbol (PK)
#Cont_Bancar
Cod_Fiscal Denumire
Cod_Poştal Cod_Fiscal
Adresă Adresa
Conturi_bancare
[…] Cont_Bancar devine o
relatie avand o cheie
compusa, toate atributele
sale vor avea o singura
valoare per instanta.
Ta b e l e l e E m i t e n t i s i
Conturi_Bancare sunt in
FN1.
Forma normala 2
—  O relaţie R este în FN2 dacă este în FN1 şi oricare
dintre atributele non-cheie este dependent funcţional
complet de o cheie candidata a relaţiei.
—  FN2 interzice manifestarea unor dependenţe
funcţionale parţiale în cadrul relaţiei.
Forma normala 2
Emitenti
#Simbol (PK) Cotatii

Denumire #Simbol (PK,FK)

Cod_fiscal #Data_cot (PK)

Cod_Postal #Cod_Piata (PK)

Adresa Den_Piata

Oras Valoare_totala

Dependenţe funcţionale parţiale?


Simbol Data Cod_Piata Den_Piata Val_totala
SNP 07.01.2014 REGS Regular 1.600.000
SNP 07.01.2014 ODDS Odd lot 500.000
TLV 07.01.2014 REGS Regular 1.200.379
TLV 07.01.2014 ODDS Odd lot 119.000
TLV 08.01.2014 REGS Regular 1.258.379
Forma normala 2 Piete
#Cod_piata
(PK)
Emitenti
Den_Piata
#Simbol (PK) Cotatii

Denumire #Simbol (PK,FK) Emitenti Cotatii


#Data_cot (PK) #Simbol (PK) #Simbol (PK, FK)
Cod_fiscal
Denumire #Data_cot (PK)
Cod_Postal #Cod_Piata (PK)
Cod_Fiscal #Cod_piata (PK,FK)
Adresa Den_Piata Cod_Postal Valoare_totala
Valoare_totala Adresa
Oras
Oras
Atributul den_piata nu este bine Atributul den_piata acum este bine
plasat. El depinde doar de atributul plasat, depinde doar de cod_piata
cod_piata si nu de întreaga cheie
(Simbol+Data_cot+cod_piata).
Relatia Cotatie nu este in FN2.
Forma normala 3
—  O relație R este în FN3 dacă este în FN2 și atributele
non-cheie nu sunt dependente tranzitiv de o cheie
candidată a relației.
—  FN3 interzice manifestarea dependențelor funcționale
tranzitive în cadrul relației.
—  Dependența tranzitivă: X → Y și Y → Z => X → Z
Forma Normala 3
Emitenti
#Simbol (PK)
Unde e dependenta
Denumire tranzitiva?
Cod_Fiscal
Cod_Postal
Adresa
Oras
Forma Normala 3
Emitenti Emitenti Adrese
#Simbol (PK) #Simbol (PK) #Localitate
Denumire Denumire #Strada
Cod_Fiscal Cod_Fiscal #Nr
Adresa Localitate Cod Postal
Oras Strada
Cod_Postal Nr
Oraș + Adresa → Cod_Postal
Se creează o tabela noua
Cod_Postal → Simbol
Adrese, ambele fiind in
Deci, Oraș + Adresa → Simbol, iar
FN3.
simbol este cheie candidata
Forma normală Boyce-Codd
(BCNF)
—  Este o varianta mai restrictiva a FN3.
—  O relație este în BCNF dacă dependențele funcționale
netriviale care se manifestă în cadrul relației conțin în
partea stângă (ca determinant) o cheie candidată.
—  Dacă A→B, fiecare determinant A din relație trebuie
sa fie cheie candidata
—  O relație care are chei candidate cu atribute comune
nu este în BCNF
Forma normală Boyce-Codd
(BCNF)
Studenti
Inscrieri_An2
ID_Stud Nume Data_nasterii Serie
Id_Materie ID_Stud Id_Prof
1 Ion 01.01.1989 B

2 Maria 01.02.1989 B
BD 1 101
3 Mircea 01.07.1989 B
Materii PO 1 102
Id_Mater
ie Den Materie Tip Materie Tip Verificare BD 2 101
BD Baze de date O E
PO 2 102
PO POO O E
Comert CI 2 104
CI International A V
Manag, rel cu
MN clientii A V

Profesori
Id_Prof Nume Data_ang
Chei candidate având atribute comune?
101 George 01.01.2000

102 Alina 01.01.2010

103 Anca 01.01.2009

104 Laurentiu 01.10.2005


Forma normală Boyce-Codd
(BCNF) Studenti_Materii

ID_Student Id_materie
ID_Stu
d Nume Data_nasterii Seria 1 BD
1 Ion 01.01.1989 B
2 Maria 01.02.1989 B 1 PO

3 Mircea 01.07.1989 B 1 CI

Id_Mater
2 BD
ie Den Materie Tip Materie Tip Verificare

BD Baze de date O E 2 PO
PO POO O E
2 MN
Comert
CI International A V
Manag, rel cu Profesori_Materii
MN clientii A V
ID_Profesor Materie Serie
Id_Prof Nume Data_ang
101 BD B
101 George 01.01.2000
102 PR A
102 Alina 01.01.2010

103 Anca 01.01.2009 103 PR B

104 Laurentiu 01.10.2005 104 CI A

105 MN A
Forma normala 4
—  O relatie este în FN4 dacă şi numai dacă este în FN3 şi
nu conţine două sau mai multe dependenţe
multivaloare.
Forma normala 4
Clienti_Zone_deservite

Broker Tip_Client Zona


ANA PF A
ANA PF B
ANA PJ Micro A
ANA PJ Micro B
MARIUS PJ Medii si Mari A
MARIUS PJ Medii si Mari B
MARIUS PJ Medii si Mari C

Exista doua dependente multivaloare non-triviale: Broker → Tip_client si Broker →


Zona
Tipul de client deservit nu depinde de zona
Forma normala 4
Brokeri_tipclienti
Broker Tip_client Se construiesc aceste doua entitati
ANA PF care sunt conforme FN4, care permit
mai usor inregistrarea zonelor si
ANA PJ Micro
tipurilor de clienti gestionati de catre
MARIUS PJ Medii si Mari fiecare broker.
Brokeri_zone
Broker Zona
ANA A
ANA B
MARIUS A
MARIUS B
MARIUS C
Forma normala 5
—  O relatie este în FN5 dacă şi numai dacă este în FN4 şi
fiecare dependenţă joncţiune este generată printr-un
candidat cheie al tabelei.
—  Altfel spus, o relatie este in FN5 daca nu poate fi
descompusa in relatii mai mici fara pierderi de
informatii
Forma normala 5
R5_A:

Magazin Curier Tip Produs

Emag Fan Electronice mici

Emag Fan Alimentare

Evomag Fan Electronice mari

Evomag Urgent Electronice mici

Daca se considera ca o firma de curierat poate livra orice combinație de tipuri


de produse de la orice magazin online, atunci relația R5_A nu încalcă FN5 si
nu mai poate fi normalizata. In R5_A, se poate observa ca Fan Curier nu
livrează electronice mari pentru Emag deși are capacitatea (știm asta
deoarece livrează electronice mari pentru Evomag). Asta înseamnă că nu
putem face o descompunere fără a pierde această informație si fără a rezulta
alte redundante.
R5_B:
Magazin Curier Tip Produs

Forma normala 5
Emag Fan Electronice mari
Emag Fan Alimentare
Emag Fan Electronice mici
Evomag Fan Electronice mici
Evomag Urgent Electronice mici

—  Daca însă exista o legătura intre tipurile de produse


care pot fi livrate de o firma si cele oferite de un
magazin, atunci relația încalcă FN5. Adică, daca Fan
Curier poate livra electronice mari iar Emag vinde
electronice mari iar Fan lucrează cu Emag, cu
siguranță va livra si electronice mari. Cu alte cuvinte,
nu va putea refuza livrarea unui tip de produs daca
este capabila sa îl livreze iar magazinul colaborator
vinde respectivul tip.
Forma normala 5
Magazine_produse Curieri_Produse
Magazin Produs Curier Produs
Emag Electronice mari Fan Electronice mari
Emag Electronice mici Fan Electronice mici
Emag Alimentare Fan Alimentare
Evomag Electronice mici Urgent Electronice mici

Magazine_Curieri Relația R5_B poate fi descompusa in cele trei


relații fără pierderi de informații.
Magazin Curier Știm cu siguranță ca daca Emag lucrează cu Fan
Curier, atunci acesta va livra toate produsele pe
Emag Fan care le poate livra si care sunt oferite de Emag. In
cazul de fata, Fan va livra 3 tipuri de produse de la
Emag Urgent Emag iar Urgent doar un tip. Daca in viitor Urgent
Evomag Fan va putea livra si electronice mari, cu siguranță va
livra si acest tip de produse pentru Emag (si pentru
restul firmelor colaboratoare cu Urgent Curier care
oferă acest tip).
Ce FN este incalcat?
Grilă
—  Normalizarea relaţiilor din cadrul bazelor de date
relaţionale oferă posibilitatea:
a)  eliminării anomaliilor de ștergere
b)  eliminării anomaliilor de adăugare de noi coloane
c)  creşterii redundanţei
d)  eliminării protecţiei datelor
e)  regăsirii tuplurilor după mai multe chei secundare
Grilă
—  O tabelă este în FN3 dacă:
a)  este în FN2 şi are cel puţin o dependenţă funcţională
completă între atributele non-cheie şi cheia candidată
a tabelei
b)  este în FN2 şi fiecare atribut non-cheie depinde în
mod netranzitiv de cheia primară a tabelei
c)  este în FN1 şi fiecare atribut cheie primară depinde
tranzitiv de atributele non-cheie
d)  este în FN2 şi are dependenţe complete
e)  este în FN1 şi are dependenţe funcţionale incomplete
Grilă
—  O relaţie este în forma normală doi (FN2) dacă:
a)  este în FN1 şi toate valorile asociate atributelor sunt la nivel
elementar
b)  este în FN1 şi nu există atribute generatoare de valori
repetitive
c)  este în FN1 şi fiecare atribut non-cheie depinde funcţional
complet de o cheie candidată a relaţiei
d)  este în FN1, toate valorile asociate atributelor sunt la nivel
elementar şi nu există atribute generatoare de valori
repetitive
e)  este în FN1 şi nu există dependenţe funcţionale parţiale
Grilă
—  Fie relaţia Materii_Prime(cod_materie_prima,
denumire_ materie_prima, caracteristici_economice,
caracteristici_tehnice, unitate_masura, stoc). Care este
prima FN încălcată
a)  FN1
b)  FN2
c)  FN3
d)  BCNF
e)  Nu încalcă nici o FN
Grilă
—  Fie relaţia Episoade_Seriale(titlu_serial, titlu_episod,
nume_regizor). Care este prima FN încălcată:
a)  FN1
b)  FN2
c)  FN3
d)  BCNF
e)  Nu încalcă nici o FN
Grilă
—  Fie relaţia Episoade(cod_episod, titlu_episod,
nume_regizor, nationalitate_regizor). Care este prima
FN încălcată:
a)  FN1
b)  FN2
c)  FN3
d)  BCNF
e)  Nu încalcă nici o FN
Grilă
—  O relație este sigur în FN2 dacă este în FN1 şi:
a)  are structuri repetitive
b)  are structuri la nivel de grup
c)  are dependenţe incomplete
d)  are dependenţe tranzitive
e)  are cheile candidate formate dintr-un singur atribut
Grilă
—  Normalizarea relaţiilor din cadrul bazelor de date
relaţionale oferă posibilitatea:
a)  eliminării anomaliilor de adăugare de noi coloane
b)  creşterii redundanţei
c)  eliminării protecţiei datelor
d)  regăsirii tuplurilor după mai multe chei secundare
e)  eliminării anomaliilor de ștergere
Grilă
—  Fie tabelele:
—  clienti(id_client number(5) primary key, nume varchar2(32),prenume
varchar2(32), data_angajare date)
—  angajati(id_ang number(5) primary key, nume varchar2(32),prenume
varchar2(32))
—  Care din următoarele fraze SQL implementează corect operatorul de
reuniune:
a)  select nume, prenume from clienti UNION select nume from angajati;
b)  select nume, prenume from clienti c, angajati a;
c)  select nume, prenume from clienti INTERSECT select nume from
angajati;
d)  select data_angajare from clienti UNION select sysdate from dual;
e)  select nume from (select prenume from clienti);
Bibliografie si lecturi
recomandate
—  Ramez Elmasri, Shamkant B. Navathe, Fundamentals
of database systems, 6th ed, Addison-Wesley
Publishing House, 2011, ISBN-13: 978-0-136-08620-8
—  Ion Lungu, Adela Bâra, Constanţa Bodea, Iuliana
Botha, Vlad Diaconiţa, Alexandra Florea, Anda
Velicanu, Tratat de baze de date. Organizare,
proiectare şi implementare, Editura ASE

S-ar putea să vă placă și

  • Diagrama
    Diagrama
    Document1 pagină
    Diagrama
    Stefanica Daniel
    Încă nu există evaluări
  • Grile FMO
    Grile FMO
    Document114 pagini
    Grile FMO
    Başchir Camelia
    Încă nu există evaluări
  • Test 1-Barem
    Test 1-Barem
    Document9 pagini
    Test 1-Barem
    Stefanica Daniel
    Încă nu există evaluări
  • Grile FMO
    Grile FMO
    Document114 pagini
    Grile FMO
    Başchir Camelia
    Încă nu există evaluări
  • T80 - Protectia BD
    T80 - Protectia BD
    Document23 pagini
    T80 - Protectia BD
    Andreea Matei
    Încă nu există evaluări
  • T12-Crearea BD PDF
    T12-Crearea BD PDF
    Document23 pagini
    T12-Crearea BD PDF
    Aitul
    Încă nu există evaluări
  • BAZE DE DATE c12
    BAZE DE DATE c12
    Document33 pagini
    BAZE DE DATE c12
    Stefanica Daniel
    Încă nu există evaluări
  • BAZE DE DATE c10
    BAZE DE DATE c10
    Document28 pagini
    BAZE DE DATE c10
    Stefanica Daniel
    Încă nu există evaluări
  • BAZE DE DATE c12
    BAZE DE DATE c12
    Document33 pagini
    BAZE DE DATE c12
    Stefanica Daniel
    Încă nu există evaluări
  • BAZE DE DATE c11
    BAZE DE DATE c11
    Document12 pagini
    BAZE DE DATE c11
    Stefanica Daniel
    Încă nu există evaluări
  • BAZE DE DATE C6si7
    BAZE DE DATE C6si7
    Document39 pagini
    BAZE DE DATE C6si7
    Stefanica Daniel
    Încă nu există evaluări
  • BAZE DE DATE c9
    BAZE DE DATE c9
    Document26 pagini
    BAZE DE DATE c9
    Stefanica Daniel
    Încă nu există evaluări
  • BAZE DE DATE c5
    BAZE DE DATE c5
    Document26 pagini
    BAZE DE DATE c5
    Stefanica Daniel
    Încă nu există evaluări
  • BAZE DE DATE c4
    BAZE DE DATE c4
    Document35 pagini
    BAZE DE DATE c4
    Stefanica Daniel
    Încă nu există evaluări
  • BAZE DE DATE c3
    BAZE DE DATE c3
    Document13 pagini
    BAZE DE DATE c3
    Stefanica Daniel
    Încă nu există evaluări
  • BAZE DE DATE c2
    BAZE DE DATE c2
    Document16 pagini
    BAZE DE DATE c2
    Stefanica Daniel
    Încă nu există evaluări