baze de date relationale in cateva cuvinte

Bazele de date relaionale

Noiuni generale despre bazele de date relaionale i despre proiectarea

acestora

SESIUNEA 1

Modelul Relaional Modelul de date relaional a fost conceput si dezvoltat de E.F. Codd. El

este un model formal de organizare conceptual a datelor, destinat reprezen-

trii legturilor dintre date, bazat pe teoria matematic a relaiilor.

Modelul relaional este alctuit numai din relaii i, prin urmare, orice

interogare asupra bazei de date este tot o relaie.

Caracteristicile unui model relaional sunt:

1. Structura relaional a datelor

2. Operatorii modelului relaional

3. Regulile de integritate (restricii de integritate)

Aceste trei elemente corespund celor trei componente ale ingineriei

software: informaie, proces, integritate.

1. Structura relaional a datelor Modelul relaional are la baz urmtoarele concepte: - Atribut = o caracteristic a datelor (echivalentul n nelesul DB: coloan) - Tuplu = un set ordonat de valori care descrie caracteristicile datelor la un

anumit moment (echivalentul n nelesul DB: nregistrare) - Domeniu = set de valori atomice care sunt de acelai tip (echivalentul n

nelesul DB: mulimea valorilor unei coloane) - Valoare = cea mai mic unitate de date dintr-o baz de date relaional

(echivalentul n nelesul DB: cmp) - Relaia = este esena bazei de date relaionale. O relaie pe anumite domenii

D1, D2, ... Dn (nu neaparat distincte) const din Header i Body.

- Headerul const ntr-un set fix de atribute A1, A2, , An, a.. fiecare atribut Ai corespunde domeniului Di care st la baza sa.

- Body-ul const n seturi de tupluri variabile in timp, unde fiecare tuplu, la rndul su, const ntr-un set de atribute-valori (Ai - Vi), o pereche pentru fiecare atribut (Ai) din header. Pentru orice pereche dat Ai Vi, Vi este o valoare din domeniul unic Di asociat atributului Ai.

(echivalentul n nelesul DB: tabel)

Tip Vehicol Productor Model An fabricaie Culoare

Limuzin Mercedes S500 2012 Gri

Van VW Transporter 2009 Verde

4x4 Jeep Cherokee 2011 Negru

SUV Toyota RAV4 2010 Alb

Minivolum Opel Zafira 2008 Viiniu

Sport Renault Megane RS 2015 Galben

Header

Body

Atribut

Valoare

Tuplu

Relaie

2. Operatorii modelului relaional

Aa cum am explicat anterior, modelul relaional se bazeaz pe algebra relaional. Ceea ce nseamn c operaiunile posibile ntr-o baz de date relaional se bazeaz pe cele din algebra relaional: Select, Project, Join, Intersect, Union, Difference i Product. SELECT: arat toate tuplurile dintr-o relaie care ndeplinesc criteriile cerute PROJECT: arat valorile atributelor selectate JOIN: combin informaiile dintr-una sau mai multe relaii INTERSECT: arat toate tuplurile care exist in ambele relaii UNION: combin tuplurile din mai multe relaii i elimin duplicatele DIFFERENCE: arat toate tuplurile dintr-o relaie care NU EXIST n alt relaie PRODUCT: combin toate tuplurile din dou sau mai multe relaii (nu conine duplicate)

Dup cum putei vedea, este vorba de un set de operaii destul de puternic, care permite manipularea datelor ntr-un mod destul de complex.

3. Restricii de integritate - pot fi structurale i de comportament.

Restricii structurale:

Restricia de unicitate a cheii - ntr-o tabel nu trebuie s existe mai multe tupluri cu aceeai valoare pentru ansamblul cheie;

Restricia referenial - ntr-o tabel t1 care refer o tabel t2, valorile cheii externe trebuie s figureze printre valorile cheii primare din t2 sau s ia valoarea NULL (neprecizat);

Restricia entitii - ntr-o tabel, atributele din cheia primar nu trebuie s ia valoarea NULL.

Restriciile de comportament: sunt cele care se definesc prin comportamentul

datelor i in cont de valorile din baza de date.

Restricia de domeniu - Domeniul corespunztor unui atribut dintr-o tabel trebuie s se ncadreze ntre anumite valori;

Restricii temporare - Valorile anumitor atribute se compar cu nite valori temporare (rezultate din calcule etc.).

Fiind foarte generale, acestea se gestioneaz fie la momentul descrierii datelor

(de exemplu prin clauza CHECK), fie n afara modelului la momentul execuiei.

Restriciile de integritate suportate de Oracle sunt:

NOT NULL: nu permite valori NULL n coloanele unei tabele;

UNIQUE: nu sunt permise valori duplicat n coloanele unei tabele;

PRIMARY KEY: nu permite valori duplicate sau NULL n coloana sau coloanele

definite astfel;

FOREIGN KEY: presupune c fiecare valoare din coloana sau setul de coloane

definite astfel s aib o valoare corespondent identic n tabela de legtur,

tabel n care coloana corespondent este definit cu restricia UNIQUE sau

PRIMARY KEY;

CHECK: elimin valorile care nu satisfac anumite cerine (condiii) logice.

Termenul de chei (keys) este folosit pentru definirea ctorva categorii de

constrngeri cum ar fi: primary key, unique key, foreign key, referenced key.

Regulile lui Codd

n anul 1985, E.F. Codd a publicat un set de 13 reguli n raport cu

care un sistem de gestiune a bazelor de date poate fi apreciat ca

relaional. Nici un sistem de gestiune a bazelor de date pus n vnzare

pe piaa comercial nu respect absolut toate regulile definite de Codd,

dar acest lucru nu mpiedic etichetarea acestor sisteme drept

relaionale.

Nu trebuie apreciat un SGBD ca fiind relaional sau nu, ci msura

n care acesta este relaional, deci numrul regulilor lui Codd pe care

le respect.

Regula 0: Regula privind gestionarea datelor la nivel de relaie

Sistemul trebuie s gestioneze BD numai prin mecanisme relaionale. Acest

lucru nseamn s-i ndeplineasc toate funciile prin manipulri n care

unitatea de informaii s fie mulimea sau relaia.

Regula 1: Regula privind reprezentarea logic a datelor

ntr-o baz de date relaional, informaia este reprezentat la nivel logic sub forma unor tabele care poart numele de relaii.

Regula 2: Regula privind accesul la date

Orice dat din BDR trebuie s poat fi accesat prin specificarea numelui de

tabel a valorii cheii primare, i a numelui de coloan. Aceast regul exprim

cerina ca limbajul de cereri al SGBDR s permit accesul la fiecare valoare

atomic din BD.

Regula 3: Regula privind valorile NULL Sistemele trebuie s permit declararea i manipularea sistematic a VALORILOR NULL, cu semnificaia unei DATE LIPS sau INVALIDABILE. Valorile NULL sunt importante pentru implementarea restriciilor de integritate. O cheie primar NU POATE FI NULL. Orice expresie aplicata valorii NULL trebuie s returneze tot NULL Regula 4: Regula privind metadatele Descrierea bazei de date (dicionarul de date) trebuie s fie reprezentat la nivelul logic tot sub form de tabele, astfel ncat asupra acesteia s se poat aplica aceleai operaii ca i asupra datelor propriu-zise. Regula 5: Regula privind limbajele utilizate O baz de date poate fi accesat doar de un limbaj cu o sintax liniar, care permite crearea, manipularea datelor i operaiuni specifice managementului tranzaciilor. Acest limbaj s poat fi utilizat att in mod direct, ct i prin intermediul altor aplicaii. Dac baza de date permite accesul la date i prin alt modalitate dect printr-un asemenea limbaj, acest lucru este considerat o violare a regulilor bazei de date.

Regula 6: Regula de actualizare a tabelelor virtuale (view-uri)

Toate view-urile dintr-o baz de date care sunt teoretic updatabile, trebuie s

fie updatabile de SGBD. Un SGBD trebuie s poata determina dac un view

poate s fie actualizat sau nu.

Regula 7: Regula manipulrii datelor

Baza de date trebuie s suporte manipularea datelor la toate nivelurile. Adic

nu trebuie s fie limitat la o singur nregistrare. Operaiile de manipulare a

datelor trebuie s poat fi facute asupra oricrui set de date care poate fi

selectat (adic operaiunile de manipulare a datelor trebuie s suporte i

operatori de genul Union, Intersect sau Minus).

Regula 8: Physical Data Independence

Aplicaiile (la nivel logic) nu trebuie s depind de modul de stocare i accesare

fizic a datelor. Orice schimbare n structura fizic a bazei de date nu trebuie s

aib nici un impact asupra modului cum sunt accesate datele de ctre aplicaiile

externe.

Regula 9: Regula independenei logice a datelor Structura logic a datelor ntr-o baz de date trebuie s fie independent de aplicaiile de pe acea baz, a.. orice schimbare n aceast structur logic a datelor nu trebuie s afecteze aplicaiile care folosesc acele date. Aceasta este cel mai greu de aplicat regul. Regula 10: Regula independenei datelor din punctul de vedere al integritii O baz de date trebuie s fie capabil s-i asigure integritatea n mod de sine stttor, n loc s depinda de aplicaii pentru asta. Toate constrngerile de integritate s poat fi modificate independent, fr necesitatea de a schimba ceva n vreuna din aplicaiile existente. n plus, aceste reguli de integritate trebuie stocate in dicionarul de date. Aceast regul nseamn c baza de date este independent de aplicaiile de front-end sau de alte interfee. Regula 11: Regula independenei datelor din punctul de vedere al distribuirii End-user-ul nu trebuie s vad dac datele sunt distribuite n mai multe locaii din reea. El trebuie s aib ntotdeauna impresia c datele sunt localizate ntr-un singur loc. Aceast regul este privit drept fundamentul sistemelor de baze de date distribuite.

Regula 12: Prelucrarea datelor de catre un limbaj de nivel inferior

Dac SGBD-ul pune la dispoziia utilizatorilor o interfa de nivel inferior (la

nivel de nregistrare), atunci interfaa nu trebuie s submineze sistemul (de

ex. prin nerespectarea unei constrngeri de integritate)

n practic, n conformitate cu tipul de cerine pe care le exprim, regulile lui

Codd pot fi grupate n urmtoarele categorii:

R0 R1 R2 R3 R4 R5 R6 R7 R8 R9 R10 R11 R12

Reguli de baz (fundamentale)

DA DA

Reguli structurale DA DA

Reguli privind integritatea datelor

DA DA

Reguli privind manipularea datelor

DA DA DA DA

Reguli privind independena datelor

DA DA DA

Deoarece regulile lui Codd sunt prea severe pentru a fi respectate de un

SGBD operaional, s-au formulat criterii minimale de definire a unui sistem

de gestiune relaional.

Un SGBD este minimal relaional dac:

toate datele din cadrul bazei sunt reprezentate prin valori n tabele;

nu exist pointeri observabili de ctre utilizator;

sistemul suport operatorii relaionali de proiecie, selecie si compunere

natural, fr limitri impuse din considerente interne.

Un SGBD este complet relaional dac este minimal relaional i

satisface n plus condiiile:

sistemul suport restriciile de integritate de baz (unicitatea cheii

primare, constrngerile refereniale, integritatea entitii).

sistemul suport toate operaiile de baz ale algebrei relaionale.

ntr-o baz de date relaional exist 5 reguli foarte importante:

1. Ordinea tuplurilor i a atributelor nu este important

2. Fiecare tuplu este unic. Asta nseamn c fiecare nregistrare dintr-o tabel conine ceva care o identific in mod unic de alte nregistrri

3. Valoarea dintr-un atribut este atomic.

4. Toate valorile dintr-un atribut provin din acelai domeniu. Asta nseamn c oricum ar fi definit un atribut, valorile corespunztoare fiecrui tuplu corespund aceleiai definiii. (Dac atributul a fost definit de tip Dat Natere, nu putem introduce ci lei are, mrimea de la cma sau numrul de la pantofi)

5. Numele tabelei dintr-o baz de date trebuie sa fie unic, iar, n cadrul tabelei, numele coloanei trebuie s fie unic.

Putem considera un SGBD ca un sistem format din 3 nivele: intern, conceptual

i extern.

Nivelul intern: este nivelul responsabil de cum anume sunt stocate (fizic)

datele pe HDD. Folosete limbaj de nivel foarte jos (cod maina) si este gestionat

de SGDB.

Nivelul conceptual: adic definiiile logice ale bazei de date, este cunoscut i

sub numele de community view. Data model i diagrama schematic sunt ambele

explicaii logice ale bazei de date la nivel conceptual. De obicei, acest nivel este

gestionat de ctre arhitectul bazei de date (DBA, analist, developer), adic de

ctre cel care definete efectiv obiectele din baza de date.

Nivelul extern: este cel vizibil end-userilor sau aplicaiilor care acceseaza baza

de date.

n figura urmtoare avei o reprezentare grafic a celor 3 nivele:

End User 1

Application Programer 1

HARDWARE

NIVELUL INTERN

NIVELUL CONCEPTUAL

NIVELUL EXTERN

Am informaii despre angajatul

Popescu Radu

Aplicaia mea poate procesa comenzile

de la clienii lui Popescu Radu

Emp_ID Emp_Name Dept_ID 10 Popescu Radu 110

BYTES = 20 FF52 BYTE 1 FF68 BYTE 2 .....

Procesul de proiectare a bazelor de date include urmtorii pai:

Adunarea cerinelor de business/ale userilor (nceperea analizei).

Dezvoltarea modelului conceptual E-R (cunoscut ca si diagrama E-R) bazat pe cerinele de business/ale userilor.

Conversia diagramei E-R n modelul relaional.

Normalizarea relaiilor n vederea eliminrii anomaliilor.

Implementarea bazei de date prin crearea tabelelor pentru fiecare relaie din modelul relaional

Modelul ENTITATE-RELAIE Modelul entitate-relaie este cel mai utilizat model conceptual, care reprezint

schema conceptual a bazei de date cu ajutorul entitilor i a relaiilor dintre

acestea, precum i a atributelor entitilor. Acest model a fost introdus n anul

1976 de Peter Pin-Shan Chen.

Crearea diagramei E-R, care este printre primii pai n proiectarea unei baze de

date, ajut proiectanii s transpuna businessul ntr-o form intermediar, care

poate fi folosit apoi n designul bazei de date.

Crearea diagramei E-R

1. Entitatea Este un obiect al lumii reale, cu o existen independent i care poate

reprezenta un obiect fizic, o activitate sau un concept.

Exemple: persoan particular, automobil, companie, activitate, curs universitar.

Entitile pot fi: independente sau dependente (entitate slab). Cele dependente sunt cele care depind de alte entiti (nu au un atribut cheie al lor).

n SGBD-ul ORACLE, convenia este urmatoarea: entitile se reprezint prin aa-numitele soft-box (dreptunghiuri rotunjite la coluri). Numele entitii va fi singular (adic un singur cuvnt), scris doar cu majuscule, avnd n paranteze numele sinonimului (dac este cazul).

ANGAJAI (S_ANGAJAI) DEPARTAMENT

2. Atributul Orice entitate are o serie de proprieti numite atribute, proprieti care descriu entitatea respectiv. De exemplu, angajatul Popescu Radu are drept atribute ID-ul, Numele, Departamentul unde lucreaz. 110 (departamentul) reprezint valoarea acelui atribut. Majoritatea datelor dintr-o baz de date reprezint valori ale atributelor. Setul tuturor valorilor posibile ale unui atribut reprezint domeniul acelui atribut. Exemplu: intervalul 0 100 (dac are peste 100 de ani, nu are ce cuta intr-o companie) pentru vrst.

Identificatorul Unic

Un identificator unic - unique identifier (UID) este orice combinaie ntre atribute sau relaii (sau ambele) care servete la identificarea n mod unic a unei entiti (mai bine spus, n cadrul entitii: fiecare angajat trebuie s poat fi identificat n mod unic). Cteodat, valoarea unui atribut nu este cunoscut sau lipsete, cteodat nu

este aplicabil. n aceste situaii, atributul poate avea valoarea (special) NULL.

Oracle folosete urmtorul mod de a reprezenta grafic atributele:

Un nume singular scris cu litere mici

Asterisc pentru a marca atributele care sunt obligatorii (a cror valoare

trebuie tiut)

Caracterul # se folosete pentru a marca UID-ul (identificatorul unic)

Litera o pentru atributele opionale (a cror valoare poate fi tiut)

Atributele pot fi: simple, compuse, derivate, single-value, multi-value

ANGAJAI (S_ANGAJAI) #* emp_id * emp_name * dept_id o job_title

DEPARTAMENT #* dept_id * dept_name o dept_location

3. Relaia n proiectarea bazelor de date se definesc relaii sau asocieri ntre mulimile de

entiti componente, pentru a reprezenta anumite aspecte ale realitii pe care o

modeleaz baza de date. Aadar o relaie este corespondena dintre dou sau mai

multe entiti.

Exist 3 tipuri de relaii: binare, recursive sau ternare (multiple).

ANGAJAI (S_ANGAJAI) #* emp_id * emp_name * dept_id o job_title

DEPARTAMENT #* dept_id * dept_name o dept_location

lucreaz n

este compus din

UID marcat cu simbolul #

1. Relaii binare: nseamn relaiile dintre dou entiti.

Acestea pot fi:

a. One-To-One.

Acestea se ntlnesc mai rar n viaa real.

b. One-To-Many

c. Many-To-Many

STUDENT CURS nscris la

STUDENT CURS nscrii la

STUDENT CURS nscrii la

frecventat de

frecventate de

2. Relaii recursive: atunci cnd o entitate este in relaie cu ea nsi.

3. Relaii ternare (multiple)

ANGAJAI

conduce

este condus de

APPLICATION EVENT

DEVICE

COMPONENT

has causes

triggers

PRACTIC

S se creeze modelul E-R pentru o baz de date numit Universitate.

n faz preliminar, dup analiza cerinelor, se cunosc urmtoarele informaii:

aceast universitate are n componen mai multe faculti. Fiecare facultate

are asociate un cod, o denumire, o adres.

studenii au stocate n baza de date informaiile personale ale fiecruia (cnp,

nume, prenume, iniiala tatlui, data naterii etc.) dar i informaii legate de

starea lor actual (grupa n care se afl, facultatea de care aparin etc.)

n aceast baz de date stocm i materiile studiate n facultile din acea

universitate. Se consider materii diferite i acele materii care au aceeai

denumire dar sunt predate de profesori diferii.

vom stoca i notele obinute de fiecare student la materia la care a fost

evaluat prin examen.

SESIUNEA 2

Pai generali:

1. Fiecare entitate va deveni o tabel

2. Fiecare atribut va deveni o coloan

3. UID-ul fiecrei entiti independente va deveni PK (primary key)

4. Relaiile dintre entiti vor fi implementate prin intermediul FK (foreign key)

5. Entitile independente vor deveni tabele care au PK, pe cnd entitile dependente vor deveni tabele care au ca FK, cheia primar din tabela de care depind

FACULTATE #*cod_facultate * nume_facultate * adres

STUDENTI_P #* cod_student * nume * prenume * data_natere * cnp * cod_potal o adres o numr_telefon

STUDENTI_F #* cod_student * cod_facultate * grup * an_colar

NOTE * cod_student * cod_materie * not * dat

MATERII #* cod_materie * nume_materie * cod_profesor * cod_facultate

PROFESORI #* cod_profesor * nume * prenume * cod_facultate * cod_materie o numr_telefon

Cod_Fac Nume_Fac Adres

F01 Medicin Strada S1, nr.100

F02 Informatic

F03 Mecanic Strada S2, nr.200

Cod_Prof Nume Prenume Cod_Fac

P01 Ion Popescu F01

P02 Marin Ionescu F01

P03 Ana Vasilescu F02

P04 Dan Georgescu F02

P05 Alina Popescu F03

P06 Vasile Preda F03

P07 Radu Toma F03

Cod_Materie Nume_Materie Cod_Prof Cod_Fac

M011 Anatomie P01 F01

M012 Chimie P02 F01

M021 Matematic P03 F02

M022 Informatic P04 F02

M031 Fizic P05 F03

M032 Mecanic P06 F03

M033 Mecanic P07 F03

FACULTATE PROFESOR MATERII

Cod_ Stud

Nume Prenume Data_ Natere

Cod_ Potal

CNP Adres

Nr_Tel

S0100 Ionel Popa 01/03/98 300301 111 555

S0101 Mihai Preda 02/03/99 600601 112 666

S0102 Alina Ionescu 03/06/98 400401 113 aaa

S0103 Mirel Adam 04/07/98 500501 114 888

S0104 Dan Popescu 05/04/99 700701 115 bbb

S0105 Viorel Ionescu 06/09/98 200201 116 222

S0106 Dana George 07/11/99 100101 117 cccc

S0107 Maria Manole 08/10/98 900901 118 444

Cod_ Stud

Cod_ Fac

Grup An_ colar

S0100 F01 G1 1

S0101 F01 G1 1

S0102 F02 G2 2

S0103 F02 G2 2

S0104 F03 G3 2

S0105 F03 G3 2

S0106 F03 G4 3

S0107 F03 G4 3

Cod_ Stud

Cod_ Materie

Not Data

S0100 M011 9 01/10/2015

S0103 M022 8 02/10/2015

S0105 M031 9 02/10/2015

S0106 M032 7 03/10/2015

S0107 M032 10 03/10/2015

STUDENT_P STUDENT_F NOTE

PK

PK

PK PK

PK

FK FK FK

FK

FK FK

Definiie: Procesul de normalizare este o metod formal, care identific relaiile bazndu-se pe cheile primare ale acestora i pe dependenele funcionale dintre atributurile lor. Normalizarea ajut proiectanii de baze de date, prin prezentarea unei serii de teste care pot fi aplicate relaiilor individuale, pentru a preveni apariia anomaliilor de manipulare.

Normalizarea bazei de date este o tehnic de reorganizare a datelor n

baza de date ce const n descompunerea sistematic a tabelelor n scopul

eliminrii redundanei datelor i a anomaliilor la manipulare.

Ce sunt aceste anomalii de manipulare? Sunt probleme care pot prea la

operaiile de INSERT/UPDATE/DELETE ntr-o baz de date proiectat greit.

Deci, putem avea 3 tipuri de anomalii:

- anomalia de inserare (INSERT)

- anomalia de tergere (DELETE)

- anomalia de actualizare (UPDATE)

Anomalia de inserare se refer la o situaie n care nu putem insera date

n baza de date din cauza unei dependene artificiale dintre coloanele unui

tabel.

exemplu: s-a construit o nou sal de curs (S001) dar nc nu a fost alocat vreunei materii sau vreunui profesor=> la inserare vom avea materii i profesori cu valoarea NULL => Cod_Materie este PK => conflict.

Cod_Materie Cod_Prof Clas Supraf_Clas Limit_studeni

M011 P01 A532 200 60

M022 P04 I320 100 30

M012 P02 C940 400 120

M032 P07 M940 400 120

M031 P05 F210 200 60

M021 P03 M940 400 120

S001 300 90

Anomalia de tergere este invers celei de inserare: se refer la situaia n

care tergerea unor date duce la pierderea neintenionat a altor date.

exemplu: dac dorim s tergem cursul de Informatic din tabela de mai sus, detaliile slii de clas (I320) vor fi de asemenea terse.


M011 P01 A532 200 60

M022 P04 I320 100 30

M012 P02 C940 400 120

M032 P07 M940 400 120

M031 P05 F210 200 60

M021 P03 M940 400 120

Anomalia de actualizare se refer la o situaie n care actualizarea unei singure valori necesit actualizarea mai multor rnduri.

exemplu: sala de clas M940 a fost mbuntit (i s-a mrit suprafaa la 500). Pentru a modifica aceasta valoare (Supraf_Clas), va trebui s modificm 2 nregistrri.


M011 P01 A532 45 40

M022 P04 I320 100 60

M012 P02 C940 400 150

M032 P07 M940 500 150

M031 P05 F210 200 80

M021 P03 M940 500 150

Adeseori, normalizarea este executat sub forma unei serii de pai. Fiecare

pas corespunde unei anumite forme normale, care are proprieti cunoscute.

Pe msur ce se desfoar normalizarea, relaiile devin n mod progresiv mai

restrictive (mai puternice) ca format i mai puin vulnerabile la anomaliile de

reactualizare. Pentru modelul relaional, numai prima form normal (1NF) este

de importan critic n crearea de relaii adecvate. Toate formele normale

urmtoare sunt opionale. Totui, pentru evitarea anomaliilor de reactualizare,

se recomand efectuarea normalizrii pn la cel puin forma 3NF.

Pentru moment, s reinem definiiile formelor 1, 2 i 3. 1NF (First Normal Form) Informaiile sunt stocate n tabele relaionale i fiecare coloan conine valori atomice, neexistnd grupuri de coloane care se repet 2NF (Second Normal Form) Tabela se afl n 1NF i toate coloanele depind de cheia primar. 3NF (Third Normal Form) Tabela se afl n 2NF i nu exist dependen tranzitiv pe cheia primar.

Formele de normalizare sunt progresive, adic, pentru a se califica pentru

forma a 3NF, o baza trebuie s fie deja n forma 2NF.

1st NF

2nd NF

3rd NF

BCNF

4th NF

5th NF

NF

Forma Nenormalizat (UNF) este aceea n care tabelele pot conine unul sau mai multe grupuri repetitive. Un grup repetitiv este un atribut sau un grup de atribute din cadrul relaiilor care apare cu valori multiple pentru o singur instan a atributului cheie.

1NF Prima form normal: eliminarea datelor repetate

Condiiile care trebuiesc satisfacute ca o relaie s fie in prima form normal sunt:

relaia conine date stocate n tupluri&atribute, iar fiecare tuplu (nregistrare) conine unul sau mai multe atribute care identific n mod unic acea nregistrare

fiecare atribut conine valori atomice (nu conine valori multiple)

Curs Coninut

Programare Java, C++

Web_Design HTML, PHP

Curs Coninut

Programare Java

Programare C++

Web_Design HTML

Web_Design PHP

trebuie s o re-modelm astfel:

Fiecare atribut trebuie s conin doar o singur valoare din domeniul aferent acelui atribut.

Pentru a converti urmtoarea tabel la prima form normal:

O relaie este n 1NF atunci cnd nu conine atribute cu valori multiple

(atribute muli valoare), adic atribute care au mai multe valori pentru acelai

rnd de date. ntr-o relaie, orice intersecie a unui rnd cu o coloan trebuie s

conin cel mult o valoare pentru ca relaia s fie n 1NF.

Ca urmare, procesul de normalizare pentru obinerea primei forme normale

cere s transformai coloanele repetate si valorile repetate din coloane n rnduri

repetate ntr-un tabel separat.

Un alt exemplu de tabel care trebuie sa fie adus in 1NF:

Employee_ ID

Sales_ Office

Office_ No

Customer_ Name1

Customer_ City1

Customer_ Name2

Customer_ City2

Customer_ Name3

Customer_ City3

100 Office_ Sales_A

Off1 XXX City_1 YYY City_2

ZZZ City_3

200 Office_ Sales_B

Off2 AAA City_4

BBB City_5

CCC City_6

2 NF A doua form normal: eliminarea dependenelor pariale

nainte de a explora a doua form normal, trebuie definit conceptul de dependen funcional. Pentru a explica aceast noiune vom folosi 2 atribute: atributul A1 (care va mai fi numit i atribut cheie) i atributul A2 (atribut non- cheie). Spunem c atributul A2 este dependent funcional de atributul A1 dac n nici un moment nu exist mai mult de o valoare a atributului A2 asociat atributului A1 . A spune c atributul A2 este dependent funcional de atributul A1 nseamn c atributul A1 determin atributul A2 , sau c A1 este determinant (identificator unic) pentru atributul A2 . Se spune c o relaie e in a doua form normal dac ndeplinete urmtoarele criterii: relaia este n prima form normal toate atributele non-cheie sunt dependente funcional de UID A doua form normal se aplic doar relaiilor care au UID-ul format din 2 (sau mai multe) atribute. Drept urmare, o relaie n 1NF care are UID-ul (PK) format dintr-un singur atribut este automat in 2NF.

Tabela de mai sus are UID-ul format din 2 atribute cheie (A1): Cod_Stud i

Cod_Proiect. Dup cum se poate vedea, atributele non-cheie depind unul de un atribut

cheie i cellalt de celalalt atribut cheie. Acest lucru se numete dependen parial, si

acest lucru se corecteaza prin 2NF.

De aceea, pentru a aduce aceasta tabela in forma 2 de normalizare, o vom modifica

n felul urmtor (o vom descompune in 2 tabele):

Cod_Stud Cod_Proiect Nume_Student Nume_Proiect

S0100 PR_50 Ionel Proiect_1

S0100 PR_60 Ionel Proiect_2

A1 A2 A2

Cod_Stud Nume_Student Nume_Proiect

S0100 Ionel Proiect_1

S0100 Ionel Proiect_2

Cod_Proiect Nume_Proiect

PR_50 Proiect_1

PR_60 Proiect_2

A1 A1

A1

A2 A2 A2

3NF A treia form normal: eliminarea dependenelor tranzitive

Pentru a nelege a treia form normal, trebuie s se definesc conceptul

de dependen tranzitiv. Despre un atribut care depinde de un atribut care nu

este identificator unic (cheie primar) a relaiei se spune c este dependent

tranzitiv.

Se spune c o relaie este n a treia form normal dac ndeplineste

urmtoarele dou criterii:

Relaia este n a doua form normal.

Nu exist dependene tranzitive (cu alte cuvinte, toate atributele non-cheie depind numai de identificatorul unic).

Pentru a aduce la a 3NF o relaie aflat n 2NF, se mut atributele depen-

dente tranzitiv n relaii n care depind numai de cheia primar. Se las atributul

de care depind acestea n relaia original, cu rolul de cheie extern.

Cod_ Stud


CNP Nr_Tel Cod_ Potal

Adres Ora

S0100 Ionel Popa 01/03/98 111 555-555-555 300301 Strada Potei nr.1 Iai

S0101 Mihai Preda 02/03/99 112 666-666-666 600601 Strada Armatei nr.2, Bloc B1, Ap.7 Suceava

S0102 Alina Ionescu 03/06/98 113 111-111-111 400401 Strada Domneasc nr.100 Galai

S0103 Mirel Adam 04/07/98 114 888-888-888 500501 Strada Viitorului nr.9 Timioara

S0104 Dan Popescu 05/04/99 115 333-333-333 700701 Strada Libertii nr.3, bloc M4, Ap.8 Iai

S0105 Viorel Ionescu 06/09/98 116 222-222-222 200201 Strada Abatorului nr.100, Bucureti

S0106 Dana George 07/11/99 117 777-777-777 100101 Strada Avntului nr.8, Buzu

S0107 Maria Manole 08/10/98 118 444-444-444 900901 Strada Popa apc nr1 Galai

n aceast tabel avem atributul Cod_Stud care este UID (PK). De acest atribut depinde atributul Cod_Potal care nu este definit ca PK. De Cod_Potal depind atribu-tele Adres i Ora. Aceasta este dependena tranzitiv (un atribut non-PK este determinat de un alt atribut non-PK).

Cod_ Stud


CNP Nr_Tel Cod_ Potal

S0100 Ionel Popa 01/03/98 111 555-555-555 300301

S0101 Mihai Preda 02/03/99 112 666-666-666 600601

S0102 Alina Ionescu 03/06/98 113 111-111-111 400401

S0103 Mirel Adam 04/07/98 114 888-888-888 500501

S0104 Dan Popescu 05/04/99 115 333-333-333 700701

S0105 Viorel Ionescu 06/09/98 116 222-222-222 200201

S0106 Dana George 07/11/99 117 777-777-777 100101

S0107 Maria Manole 08/10/98 118 444-444-444 900901

Cod_ Potal

Adres Ora

300301 Strada Potei nr.1 Iai

600601 Strada Armatei nr.2, Bloc B1, Ap.7 Suceava

400401 Strada Domneasc nr.100 Galai

500501 Strada Viitorului nr.9 Timioara

700701 Strada Libertii nr.3, bloc M4, Ap.8 Iai

200201 Strada Abatorului nr.100, Bucureti

100101 Strada Avntului nr.8, Buzu

900901 Strada Popa apc nr1 Galai

PK

PK

FK

Practic:

1. O companie folosete urmtoarea baz de date pentru a ine evidena

angajailor, a proiectelor la care acetia lucreaz i a managerilor de proiect.

Normalizai aceast baz de date in cel mai eficient mod posibil (tabele, relaiile

dintre ele, PK, FK) tiind c exist urmtoarele dependine funcionale: Emp_ID > Emp_Name

Project_ID

Project_ID -> Project_Name

Manager_ID

Manager_ID -> Manager_Name

Emp_ID Emp_Name Project_ID Project_Name Manager_ID Manager_Name

E100 Popescu Adrian P01 Pr_Name_01 M01 efu_01

E200 Ionescu Marian P02 Pr_Name_02 M02 efu_02

E300 Preda Mihaela P03 Pr_Name_03 M02 efu_02

E400 Popa Ionel P04 Pr_Name_04 M01 efu_01

2. O companie de catering ofer diferite servicii, fiecare taxate n mod diferit. Pentru

a pstra informaiile despre clieni precum i detaliile serviciilor pe care le-a comandat

fiecare, compania are urmatoarea baz de date.

Normalizai aceast baz de date in cel mai eficient mod posibil (tabele, relaiile

dintre ele, PK, FK) tiind c exist urmtoarele dependine funcionale:

Client_Name > Address

Emp_ID -> Name

Service -> Amount_Due

Client_Name, Date -> Emp_ID

Service

Client_Name Address Date Emp_ID Name Service Amount_Due

Client_1 Address_1 01-06-2015 E100 Emp_Name1 Regular 99,99$

Client_2 Address_2 12-03-2015 E200 Emp_Name2 Standard 129,99$

Client_3 Address_3 07-07-2015 E200 Emp_Name2 Super 159,99$

Client_4 Address_4 21-08-2015 E300 Emp_Name3 Deluxe 219,99$

Soluii:

1. Emp_ID Emp_Name Project_ID

E100 Popescu Adrian P01

E200 Ionescu Marian P02

E300 Preda Mihaela P03

E400 Popa Ionel P04

Project_ID Project_Name Manager_ID

P01 Pr_Name_01 M01

P02 Pr_Name_02 M02

P03 Pr_Name_03 M02

P04 Pr_Name_04 M01

Manager_ID Manager_Name

M01 efu_01

M02 efu_02

PK

PK

PK

FK

FK

2. Client_Name Address

Client_1 Address_1

Client_2 Address_2

Client_3 Address_3

Client_4 Address_4

Emp_ID Name

E100 Emp_Name1

E200 Emp_Name2

E300 Emp_Name3

Service Amount_Due

Regular 99,99$

Standard 129,99$

Super 159,99$

Deluxe 219,99$

Client_Name Date Emp_ID Service

Client_1 01-06-2015 E100 Regular

Client_2 12-03-2015 E200 Standard

Client_3 07-07-2015 E200 Super

Client_4 21-08-2015 E300 Deluxe

PK

PK

PK

PK

FK FK

baze de date relationale in cateva cuvinte

Documents