Gestiunea tabelelor

în Microsoft Access
 Crearea şi lucrul cu tabele – privire de ansamblu

 Proprietățile câmpurilor din tabel

 Reguli de validare la nivel de câmp și înregistrare

 Relații între tabele

 Forme normale
Privire de ansamblu MS Access
Crearea tabelelor în MS Access 2013
 Prelucrare Câmpuri

Tip vizualizare

Creare Structură Tabel(Definire Proprietăţi ale câmpurilor unui tabel)

 NUMELE
CÂMPULUI
TIPUL DE DATE
CONŢINUT DE CÂMP

DIMENSIUNEA
CÂMPULUI.
SETĂRI SUPLIMENTARE
RELATIV LA CÂMPUL
DEFINIT.

SETĂRI SPECIFICE
CONŢINUTULUI
CÂMPULUI

Structura Tabel Produse

SETĂRI CARACTERISTICE CÂMPULUI

• FORMAT- permite alegerea unor formate prestabilite sau crearea

unui format personalizat pentru tipul de dată ales.
• DECIMAL PLACES -stabileşte numărul de zecimale între 0-15.
• INPUT MASK -se aplică tipului text şi dată calendaristică un
format personalizat de afişare. Ex.Tel.(0262)655-224.
• CAPTION -nume atribuit cîmpului la vizualizare(diferit de cel
intern,deja atribuit).
• DEFAULT VALUE -valoarea inclusă implicit, înainte de
actualizarea câmpului

7
 SETĂRI CARACTERISTICE CÂMPULUI
 VALIDATION RULE - regula de validare testată pe baza criteriului
definit sub forma unei expresii. Acestea folosesc:
 Operatori: = ,- ,*, /, Mod ,< ,> ,≤ ,≥ ,AND,OR ,BETWEEN ,IN ,
IS NULL.
 Indentificatori: în paranteze drepte [ ].

 Funcţii.

 Constante.

 VALIDATION TEXT -mesajul care apare în cazul nerespectării

regulii de validare.
 REQUIRED -se stabileşte la yes dacă este strict necesară completarea
acestui câmp.
 INDEXED - se alege opţiunea pentru un index neduplicat (primar) sau
duplicat . Câmpul indexat este util în operaţiile de căutare în baza de
8
date.
 Modificare structura tabela
Pas1. Se selectează tabela.
Pas2. View\ Design View
Pas2. Se selectează pagina Design a lui Table Tools
Modificare Ştergere

Navigare Adaugare
Filtrare

Căutare

Gestionare Varianta I Conţinut Tabel

Înregistrare Nouă
Ştergere Modificare
Înregistrare

Modificare-Salvare
TOTAL

Gestionare Varianta II Conţinut Tabel

Modificare înregistrare
Ordonare înregistrări
Ordonare înregistrări
Pas1.Se selectează câmpul după care se doreşte
ordonare
Pas2. Se selectează săgeată în jos exitent în
dreptul numelui câmpului şi din meniul derulant
se selectează comanda de sortare (Ascending
sau Descending)
Sau se selectează buronul aferent ordonării din
secțiunea Sort&Filter a filei Home

Pentru a aranja înregistrările în ordinea în care se aflau

în momentul inițial, se selectează din secțiunea
Sort&Filter opțiunea Clear All Sorts.
 Filtrarea

Un filtru este o restricție care se pune

înregistrărilor unei tabele, unei forme sau
unui raport pentru a afișa doar anumite
înregistrări specificate.
Filtrarea micșorează temporar numărul de
înregistrări afișate, conform criteriilor de
selecție.
Exemplu
Ștergere Filtru

SAU
 Index
Indexurile accelerează căutarile, catalogând
conținutul unui anumit câmp.
Câmpul cheie primară este indexat în mod
automat.
Se pot crea indecși și pentru câmpurile ce nu
sunt cheie primară dar se folosesc la căutări,
sortări sau filtrări
Nu se poate indexa un camp ale cărui date sunt
de tip Memo, Hyperlink sau obiect OLE.
 Etape indexare
Pas1. se deschide tabelul în modul de
vizualizare DESIGN.
Pas2. Se selectează din zona Show/Hide opțiunea
Index
Vizualizare continut tabel
Exemple de tipuri câmpuri
Câmp de tip TEXT
-Sirul de lungime 0 = sir vid= se introduce prin “” ( 2 ghilimele fara
spatiu intre ele) si numai in cazul in care AllowZeroLength a campului
este pozitionta pe YES
-Daca in cp nu este nimic Access ii asigneaza (atribuie) valoarea
NULL – (care difera de sirul cu lungime zero)

Câmp DATE/TIME – pentru anii 100 respectiv 9999 – exista o

corespondenta intre valoarea tastata de noi si reprezentarea in
memorie – pe baza unui algoritm specific
Câmp CURRENCY – in calcule economice fara rotunjiri – cu 15 cifre
parte intreaga si 4 cifre partea zecimala

Câmp AUTONUMBER – daca s-a sters o inregistrae din tabel

valoarea cp aNumber nu mai poate fi utilizata pentru alta inregistrare

Câmp YES/NO - cu valori True/False, 0/1, on/off

tabul Lookup câmpul naţionalitate – valorile: română, maghiară, germană
- Display Control de la Text Box la List Box
- in linia cu Row Source Type alegem Value List
- la Row Source - scriem direct lista, între ghilimele, separată de punct şi
virgulă, sau
- dăm click pe cele trei puncte de la finalul liniei şi vom avea captura de
mai jos (câte o intrare pe linie).
 Reguli de validare
O regulă de validare limitează sau controlează ceea ce utilizatorii pot introduce într-
un câmp de tabel sau control (cum ar fi o casetă text) de formular;
Regulile de validare pot fi văzute ca un set de niveluri — aveți posibilitatea să utilizați
unele niveluri sau toate nivelurile pentru a vă asigura că utilizatorii introduc datele în
mod corect.
 Tipurile de date - primul nivel de validare. Când proiectați un tabel de bază de date, definiți un
tip de date pentru fiecare câmp din tabel, iar acel tip de date restricționează ceea ce pot introduce
utilizatorii.
- un câmp Dată/Oră acceptă numai date și ore
- un câmp Monedă acceptă numai date monetare
 Dimensiunile câmpurilor -alt strat de validare. De exemplu, în cazul în care creați un câmp
care stochează prenume, aveți posibilitatea să îl setați să accepte maxim 20 de caractere;
 Reguli comerciale – alt nivel cu validare la nivel de camp si validare la nivel de inregistrare
La nivel de camp - un câmp Dată, și introduceți >=#01.01.2007# în proprietatea Validation
Rule
La nivel de inregistrare - când trebuie să verificați valorile dintr-un câmp cu valorile din alt
câmp.
- expedierea produselor în termen de 30 de zile –
[DatăNecesară]<=[DataComandă]+30 pentru a vă asigura că nu se introduce o dată de
expediere (valoarea din câmpul DataNecesară) care depășește termenul impus
 Exemple de Validation Rule
Conditie tastata Test efectuat de către ACCESS

<>0 Valoarea tastata trebuie sa fie diferita de zero

>100 AND <500 Valoarea tastata trebuie sa fie cuprinsa intre 101 si 499

LIKE "411???" Valoarea tastata trebuie sa inceapa cu 411 si ca contina celmult 6

caractere!

>DATE() Valoarea tastata trebuie sa fie mai mare decat data calendaristica curenta

>#01/01/1999# Valoarea tastata trebuie sa fie mai mica decat data 01/01/1999

“G1 “OR “G2 “OR “G3 " Valoarea tastata trebuie sa fie una dintre valorile G1sau G2 sau G3

>=#01/01/2000# AND Valoarea tastata trebuie sa fie mai mare decat 01/01/2000 si mai mica
decat 01/01/2011
#<01/01/2011#

LIKE "[A-Z]*@[A-Z].com" Introduceți o adresă de poștă electronică validă, cum ar fi una de tip .com,
.net sau .org.
OR "[A-Z]*@[A-Z].net" OR
"[A-Z]*@[A-Z].org"
[DatăFinal] >= Introduceți o dată de terminare
[DatăÎncepere] care să fie data de începere sau
după aceasta.
NOT Testează pentru a găsi valori NOT > 10 (același lucru cu<=10).
opuse. Utilizați înainte de
orice operator de comparație
cu excepția operatorului IS
NOT NULL.

IN Testează pentru a găsi valori IN

egale cu membrii din listă. ("Iași","București","Moscov
Valorile de comparație trebuie a")
să fie o listă cu elementele
separate prin virgulă și
încadrate în paranteze
rotunde.
LIKE Potrivește șirurile model din LIKE "Geo*"
câmpurile Text și Memo.
dat_ang>=dat_nas angajaţii unei societăţi sunt
+(18*365.25); majori la data angajării
Validare - Reguli de scriere

Regulile de validare pot conține expresii — funcții care returnează o singură

valoare.

Expresii - efectueaza calcule, pentru a manipula caractere sau pentru a testa date.

Încadrați numele câmpurilor de tabele cu paranteze pătrate, astfel:

[DatăNecesară]<=[DatăComandă]+30

Încadrați datele cu simboluri diez (#), astfel: <#01.01.2007#

Încadrați valorile text cu ghilimele duble, astfel: IN ("Iași","București","Moscova")

Se separa elementele prin virgulă și se încadreaza listele în paranteze rotunde.

 Relaţii intre tabele Access
Între două tabele se pot defini următoarele tipuri
de relaţii:
 relaţie unu-la-unu;

 relaţie unu-la-mai-multi

 relaţie mai-multi la-unu

 relaţie mai-multi-la-mai-multi

Observatie Cheia primară se setează la

crearea tabelei sau ulterior
Cheie straina sau externa
 CASETĂ DE DIALOG
CREAREA LEGĂTURILOR ÎNTRE
DESCHIDEREA
DESCHISĂ PRIN
MENIUL RAPID

TABELE
INTERFEŢEI PENTRU
CREAREA
LEGĂTURILOR.
PENTRU ADĂUGAREA
TABELELOR ÎN
SUPRAFAŢA
RELAŢIILOR.

33
 CREAREA LEGĂTURILOR ÎNTRE
TABELE
LEGĂTURĂ DE
TIP UNU LA MAI
MULTE.

NUMELE
TABELEI

NUMELE CÂMPULUI
CHEIE PRIMARĂ SAU
CHEIE EXTERNĂ CARE
CREEAZĂ LEGĂTURA.

34
 Integritatea bazelor de date
 este proprietatea datelor de a deţine un nivel de
calitate stabilit aprioric, adecvat şi suficient
într-un context dat.
 este starea existentă atunci când datele sunt
identice cu datele din documentele sursă sau din
domeniul problemei modelate, nefiind expuse la
alterări accidentale sau intenţionate ori distrugeri
fizice.
 este starea existentă atunci când calitatea
informaţiei stocate este protejată de contaminare
sau degradare cu informaţie de slabă calitate.
 Integritatea bazelor de date
Tip de degradare a datelor Descriere

Date Nu toate datele introduse şi stocate sunt valide; în această situaţie,

verificările şi procesele de validare ce asigură coerenţa bazei de date,
nevalide lipsesc.

Date Redundanţa apare atunci cînd aceleaşi date sunt înregistrate şi stocate
în mai multe locuri. Acest lucru poate conduce la incoerenţa datelor şi
redundante la anomalii ale acestora.
Date Apar atunci când date redundante, ce se găsesc în mai multe locuri, nu
prezintă acelaşi conţinut.
incoerente
Anomalii Apar atunci când există date redundante ca urmare a unei proiectări
defectuoase. În aceste situaţii este posibil ca o apariţie a datei
ale datelor redundante să fie modificată, în timp ce alte apariţii rămân
neschimbate.
Incoerenţa citirii Un utilizator nu citeşte întotdeauna ultima dată salvată, iar modificările
datelor facute de acesta sunt vizibile altor utilizatori înainte de salvare.

Date Mai mulţi utilizatori pot accesa şi citi aceleaşi date simultan, dar în
felul acesta se pierde coerenţa citirii.
neconcurente
 Integritatea bazelor de date
Asigurarea integrităţii datelor este condiţionată de
trei elemente :
 fizice: ce garantează stabilitatea în timp a suporturilor
fizice de date şi a procedurilor;

 semantice: care asigură coerenţa datelor stocate în

raport cu semnificaţia acestora independent de
mijloacele materiale utilizate;

 juridice: care controlează accesul la informaţii (prin

intermediul cheilor de acces);
Integritatea bazelor de date

Siguranţa suportului de
date şi a procedurilor
=
Integritate fizică

Autentificarea Validitate+
+ Coerenţa
Confidenţialitate Semantică
+ =
Non-repudiere Integritate
= logică şi
Integritate „juridică”
semantică

Integritatea datelor
 Integritatea bazelor de date
Metodele şi tehnicile ce ţin de integritatea şi securitatea bazelor
de date urmăresc:
 Asigurarea coerenţei datelor stocate în raport cu
semnificaţia acestora (asigurarea integrităţii semantice).
 Controalele de validare a datelor reprezintă una dintre soluţiile de
implementare a integrităţii semantice, rolul acestor controale fiind acela
de a evita introducerea de date neconforme realităţii în baza de date şi de
a verifica faptul că baza de date nu a fost supusă unor alterări de acest
tip.

SGBD-urile oferă o multitudine de facilităţi pentru a garanta

integritatea semantică a datelor (reguli de validare pentru
câmpuri şi controale, instrucţiuni, clauze, descrieri de trigger-e,
etc.) dar nu şi fiabilitatea lor, care ţine de modalitatea în care s-
a organizat şi desfăşurat procesul de culegere a datelor.
 Integritatea bazelor de date
 Asigurarea sincronizării accesului concurent la baza de
date are în vedere acţiunile concurente ale mai multor utilizatori
şi evitarea interferenţei acestora într-un mod prin care să-şi
prejudicieze reciproc acţiunile.
 Asigurarea siguranţei în funcţionare în urma unor defecţiuni
fizice ce pot afecta coerenţa bazei de date (pană de curent,
catastrofe naturale, etc.)
 Asigurarea securităţii de utilizare are în vedere aspectele de:
 confidenţialitate (asigurarea că datele nu pot fi citite decât de persoanele
autorizate),
 autentificare (asigurarea asupra identităţii interlocutorului);
 non-repudiere (ansamblu de mijloace şi tehnici ce permit confirmarea
participării unei entităţi la un schimb de date, pentru prevenirea
nerecunoaşterii tranzacţiei de către expeditor).
 Normalizarea bazei de date
Dependenţele de date (data dependencies) reprezintă
constrângeri care se impun valorilor atributelor unei relaţii şi care
determină proprietăţile relaţiei în raport cu operaţiile de inserare,
ştergere şi actualizare a tuplurilor.

 Pe baza dependenţelor de date se pot stabili reguli de definire a

relaţiilor, astfel încât acestea să prezinte anumite proprietăţi,
proprietăţi care caracterizează formele normale ale relaţiilor (sau
gradele de normalizare ale acestora).

O formă normală a unei relaţii (normal form) presupune

anumite condiţii pe care trebuie să le îndeplinească valorile
atributelor şi dependenţele de date definite pe acea relaţie.

04/03/2019 41
 Normalizarea relaţiilor (normalization) constă în descompunerea lor,
astfel încât relaţiile rezultate să îndeplinească condiţii din ce în ce mai
restrictive în ceea ce priveşte dependenţele de date, adică să corespundă
unor forme normale cât mai avansate.
Prin normalizare se elimină (sau se micşorează) redundanţa datelor
memorate în relaţii şi anomaliile care provin din această redundanţă.
•Exemplu:
Fie relaţia

AP(IdAngajat,Nume,Prenume,Adresa,IdProiect,Ore).

Fiecare tuplu al relaţiei conţine informaţii despre un angajat şi numărul de

ore aferente fiecăruia dintre proiectele la care acesta lucrează.

04/03/2019 42
Dacă se admite că un angajat lucrează la mai multe proiecte, atunci cheia
primară a relaţiei AP este PK = {IdAngajat,IdProiect}.
Se observă că datele despre fiecare angajat (Nume, Prenume, Adresa)
se repetă în fiecare tuplu corespunzător fiecărui proiect la care acesta
lucrează, ceea ce reprezintă un grad ridicat de redundanţă a datelor.
Această redundanţă are ca efect atât creşterea spaţiului de memorare a
relaţiei, cât şi anomalii de actualizare a relaţiei. Anomaliile de
actualizare a relaţiei apar la inserarea, ştergerea sau actualizarea
tuplurilor relaţiei.

04/03/2019 43
Anomalii de inserare:
• nu se pot introduce date despre un angajat (identificatorul
angajatului, numele, prenumele, adresa) dacă nu există cel puţin un
proiect la care acesta să lucreze.

• se poate introduce un nou tuplu care conţine alte valori ale atributelor
Nume, Prenume sau Adresa, pentru aceeaşi valoare a identificatorului
IdAngajat.
De exemplu, se poate introduce tuplul
(1,Dragomir,Eugen,Bucuresti,P3,110)

Acest tuplu este acceptat de SGBD, deoarece are cheia primară (1,P3),
care nu mai există în relaţia AP. Dar în acest moment starea relaţiei AP
nu este consistentă din punct de vedere semantic deoarece există doi
angajati (Ionescu Ion şi Dragomir Eugen) care au acelaşi număr de
identificare (IdAngajat = 1).
04/03/2019 44
Anomalii de ştergere:
•Dacă se şterg toate tuplurile referitoare la un anumit proiect din
relaţia AP, atunci se pot pierde toate datele referitoare la acei
angajaţi care lucrează doar la proiectul respectiv. De exemplu, dacă
se şterg tuplurile referitoare la proiectul P2
(1,Ionescu,Ion,Bucuresti,P2,150),
(2,Popescu,Petre,Craiova,P2,50),
(3,Marin,Mihai,Ploieşti,P2,120),
atunci se pierd toate informaţiile despre angajatul Marin Mihai
(identificatorul angajatului, numele, prenumele, adresa).

04/03/2019 45
 Anomalii de actualizare:
•Dacă se modifică valoarea unuia din atributele care au valori
redundante (Nume,Prenume sau Adresa) într-un tuplu al
relaţiei AP, starea relaţiei poate deveni inconsistentă.
De exemplu, dacă în tuplul
(1, Ionescu,Ion,Bucuresti,P2,150) se modifică
atributul Nume la valoarea Gheorghiu, atunci în relaţie vor
exista tuplurile: (1,Ionescu,Ion, Bucuresti,P1,100)
şi (1,Gheorghiu,Ion,Bucuresti,P2,150), adică doi
angajati cu nume diferite (Ionescu şi Gheorghiu) au acelaşi
număr de identificare (1).
De asemenea, pot să apară numeroase alte situaţii de
inconsistenţă atunci când se fac actualizări într-o astfel de relaţie
care prezintă date redundante.
04/03/2019 46
 Anomaliile descrise mai sus se pot elimina dacă relaţia AP se descompune în
două relaţii echivalente:
•relaţia A(IdAngajat,Nume,Prenume,Adresa), cu cheia primară
IdAngajat
•relaţia P(IdAngajat,IdProiect,Ore), cu cheia primară
{IdAngajat,IdProiect}, iar atributul IdAngajat este o cheie
străină care referă cheia primară cu acelaşi nume din relaţia A.

!!!Aceste relaţii nu mai prezintă redundanţă şi nici anomalii la actualizarea

lor.

04/03/2019 47
Normalizarea este un proces formal de analiză a relaţiilor bazate
pe chei primare (sau pe baza cheilor candidat în cazul BCNF).
Normalizarea presupune îndeplinirea unor reguli prin care baza
de date se poate normaliza până la un anumit grad. Dacă o cerinţă
nu este satisfăcută, relaţia trebuie descompusă în mai multe relaţii,
care individual satisfac cerinţele formei normale.

04/03/2019 48
 FN (forma normala) Normalizare

FN1 Toate valorile asociate atributelor Se descompun atributele ne-

se găsesc la nivel elmentar şi nu elementare sau se elimină şi se
exista atribute sau grupuri de creează o nouă relaţie pentru fiecare
atribute repetitive. atribut, grup de atribute repetitive.

FN2 Doar pentru relaţii cu cheie Se descompune relaţia, atributele

compusă, atributele non cheie dependente parţial vor forma o nouă
depind functional de intreaga cheie relaţie a cărei cheie este parte din
a relatiei, nu există dependente relaţia iniţială.
funcţionale parţiale.

FN3 Nu trebuie să existe dependenţe Se descompune relaţia

functionale între atributele non
cheie, şi astfel să apară dependenţe
funcţionale tranzitive.

3/4/2019 49
 FN1
O relaţie este normalizată în prima formă normală (FN1) dacă fiecare
atribut ia numai valori atomice şi scalare din domeniul său de definiţie.
Exemplu:
PERSOANE(IdPersoana,Nume,Prenume,Adresa,NrTelefon)
atributul NrTelefon poate lua mai multe valori (telefon de acasă, telefon
la birou, telefon mobil), deci este o relaţie nenormalizată.
Această relaţie se poate normaliza prin înlocuirea atributului NrTelefon
cu trei atribute, câte unul pentru fiecare valoare posibilă:
PERSOANE(IdPersoana,Nume,Prenume,Adresa,
TelefonAcasa,TelefonBirou,TelefonMobil)
O soluţie mai eficientă este de a înlocui relaţia dată cu relaţiile:

PERSOANE(IdPersoana,Nume,Prenume,Adresa)
TELEFOANE(IdPersoana,NrTelefon)

04/03/2019 50
 O soluţie mai eficientă este de a înlocui relaţia dată cu relaţiile:

PERSOANE(IdPersoana,Nume,Prenume,Adresa)
TELEFOANE(IdPersoana,NrTelefon)

aflate în asociere 1:N prin cheia străină IdPersoana din

relaţia TELEFOANE, care referă cheia primară cu acelaşi nume
din relaţia PERSOANE.

04/03/2019 51
 FN2
O relaţie este în a doua formă normală, dacă este în prima
forma normală (FN2) şi fiecare atribut, care nu aparţine cheii
primare, este într-o dependenţă funcţională totală faţă de cheia
primară.
Rezultă că, dacă orice cheie a unei relaţii este formată dintr-un
singur atribut, relaţia este în FN2.
De asemenea, este evident faptul că o relaţie compusă din două
atribute este în FN2, deoarece, fie cheia este formată din ambele
atribute şi atunci nu există atribute neprime, fie cheia este
formată dintr-unul din atribute iar dependenţa funcţională a
celuilalt atribut (care este atribut neprim) faţă de cheie este
totală.

04/03/2019 52
Exemplu:
Schema relaţiei este: AP(IdAngajat,Nume,
Prenume,Adresa,IdProiect,Ore), iar mulţimea dependenţelor
funcţionale FAP stabilite pe baza semnificaţiei atributelor este cea specificată
deja, adică:
FAP = {IdAngajat→Nume,IdAngajat→Prenume,
IdAngajat→Adresa,{IdAngajat,IdProiect}→Ore}

a - Dependenţe funcţionale în relaţia AP (AP nu este în FN2); b, c -

descompunerea relaţiei AP în relaţiile A şi P(sunt în FN2).
04/03/2019 53
 FN3

O relaţie este în a treia formă normală, daca este în forma

normală doi şi fiecare atribut care nu aparţine cheii primare
(atribut neprim) nu este într-o dependenţă tranzitivă faţă de
cheia primară. Adică, toate dependenţele funcţionale ale
relaţiei, determinate de cheia primară, sunt totale şi nu există
nici o dependenţă a unui atribut neprim faţă de alt atribut
neprim.

Orice relaţie formată din două atribute este în FN3 deoarece ea

se află în FN2, şi nu poate exista nici un atribut neprim care să
determine funcţional un alt atribut neprim, deoarece o relaţie cu
două atribute nu poate avea decât cel mult un atribut neprim.

04/03/2019 54
Exemplu:
AFS(IdAngajat,Nume,Prenume,Adresa,Func-
tie,Salariu),

cu mulţimea dependenţelor funcţionale

FAFS = {IdAngajat→ Nume, IdAngajat→Prenume,
IdAngajat→Functie, Functie→Salariu}

Cheia primară a relaţiei este atributul IdAngajat, şi ea poate fi

dedusă din mulţimea FAFS a dependenţelor funcţionale.

Se consideră că fiecare atribut ia numai valori atomice şi scalare,

deci relaţia este în FN1.

04/03/2019 55
 Mulţimea dependenţelor funcţionale este formată din dependenţe funcţionale
totale ale unor atribute neprime faţă de cheia primară a relaţiei, deci relaţia
este în FN2.

Dependenţa funcţională (Functie→Salariu) semnifică faptul că în

instituţia respectivă toţi salariaţii cu aceeaşi funcţie au acelaşi salariu (adică
funcţia determină salariul, ceea ce este plauzibil). Această dependenţă
funcţională a atributului neprim Salariu faţă de alt atribut neprim
(Functie), arată că relaţia nu este în a treia formă normală (FN3).

a- Dependenţele funcţionale ale relaţiei AFS (AFS nu este în FN3); b, c -

descompunerea relaţiei AFS în relaţiei AF şi FS.
04/03/2019 56
 Chiar dacă relaţia AFS este în FN2, în aceasta încă mai există redundanţă a
datelor, deoarece valoarea salariului corespunzător unei funcţii se
înregistrează de mai multe ori, pentru fiecare salariat care deţine acea
funcţie.
Această redundanţă provoacă anomalii:
•Inserare: nu se poate înregistra valoarea salariului corespunzător unei
anumite funcţii, dacă nu se înregistrează cel puţin un salariat cu acea
funcţie.
•Ştergere: dacă se şterg tuplurile corespunzătoare tuturor salariaţilor care
deţin o anumită funcţie, atunci se pierde informaţia referitoare la salariul
corespunzător funcţiei respective.
• Actualizare: dacă se modifică salariul fără să se modifice corespunzător
şi funcţia, atunci pot exista în relaţie două sau mai multe tupluri care au
aceeaşi valoare a atributului Functie, dar valori diferite ale atributului
Salariu, deci nu este respectată dependenţa funcţională
Functie→Salariu.

04/03/2019 57
 Astfel de redundanţe şi anomaliile de actualizare pe care le
provoacă se pot elimina dacă se descompune relaţia în două (sau
mai multe) relaţii, care să nu conţină date redundante.
Relaţia AFS se poate descompune în relaţiile:
•AF (IdAngajat,Nume, Prenume,Adresa,Functie)
•FS(Functie,Salariu)
Cheia primară a relaţiei AF este IdAngajat, şi se poate deduce
uşor din dependenţele funcţionale ale relaţiei AF.
Cheia primară a relaţiei este atributul Functie şi se deduce cu
uşurinţă din mulţimea FFS a dependenţelor funcţionale ale acestei
relaţii.

04/03/2019 58
Bibliografie
[Connolly et al. 2005] Thomas Connolly, Carolyn Begg,
Anne Strachan - Database Systems A Practical
Approach to Design, Implementation, and
Management, 3rd Edition. 2005, Addison Wesley
[Date 2003] CJ Date - An Introduction to Database
Systems, Eighth Edition. 2003, Addison Wesley
[Nitchi et al. 2009] S I Nitchi & colab. - Elemente de baze
de date si programare aplicate în economie. 2009.
Risoprint
[Sitar 2009] Databases in the Real Life Economy, Editura
Risoprint, Cluj-Napoca, 2009, ISBN 978-973-751-973-3,
pp. 58–104
[Sitar 2010] Elemente de baze de date pentru economişti,
Editura Risoprint, Cluj-Napoca, 2010, pag. 67–114
http://msdn2.microsoft.com/en-
us/vfoxpro/bb190288.aspx
http://office.microsoft.com/en-us/access/default.aspx