BAZE DE DATE CAP.

8 Metodologia de proiectare fizică a bazelor de date pentru

bazele de date relaţionale
Proiectarea fizică a bazelor de date este procesul de descriere a implementării bazei de date
într-o capacitate de stocare secundară; se descriu structurile de stocare şi metodele de acces
utilizate pentru asigurarea unui acces eficient la date.

8.1 Pasul 4. Transformarea modelului de date logic global pentru un

SGBD ţintă

Acest pas presupune transformarea relaţiilor extrase din modelul de date logic global într-o
formă care să poată fi implementată in SGBD ţintă.
Este necesară cunoaşterea funcţionalităţii SGBD ţintă, de exemplu:
- dacă sistemul acceptă definirea cheilor primare, străine şi alternative;
- dacă sistemul acceptă definirea datelor necesare (adică a unor atribute ca fiind NOT
NULL)
- dacă sistemul acceptă definirea domeniilor
- dacă sistemul acceptă definirea constrângerilor întreprinderii
- cum se creează relaţiile de bază.

Pasul 4.1 Proiectarea relaţiilor de bază pentru SGBD ţintă

Trebuie confruntate şi asimilate informaţiile referitoare la relaţii (tabele) obţinute prin

modelarea logică a datelor.
Aceste informaţii sunt obţinute din definiţia relaţiilor (în DBDL) şi din dicţionarul de date.

Pentru fiecare relaţie identificată în modelul de date logic global vom avea o definiţie formată
din:
- denumirea relaţiei
- listă de atribute simple (între paranteze)
- cheia primară (PK), şi după caz, cheile alternative (AK) şi cheile străine (FK)
- constrângerile de integritate corespunzătoare oricărei chei străine (FK) identificate

Din dicţionarul de date, pentru fiecare atribut există şi:

- domeniul atributului, care constă din tipul de date, lungimea acestora şi constrângeri
asupra domeniului
- opţional, o valoare prestabilită a atributului
- dacă atributul poate conţine NULLuri
- dacă atributul este derivat, şi în acest caz cum trebuie calculat.

De exemplu în cazul BD a agenţiei imobiliare discutată, proiectul pentru relaţia de bază

(tabelul) Proprietate_de_Închiriat, în DBDL, pentru implementarea cu ajutorului SGBD MS-
Access este redat în figura de mai jos.

1
BAZE DE DATE CAP. 8

Proiectul logic iniţial a fost adaptat funcţionalităţii SGBD ţintă (MS-Access). În continuare
sunt prezentate câteva exemple ale acestui proces de adaptare (rafinare):

2
BAZE DE DATE CAP. 8

Atributul Proiectul logic Proiectul fizic pt. MS- Explicaţii

Access
Nr_Proprietate Şir variabil de Tip de date Text, Access nu
(PK) caractere, max. 5 lungimea 5 deosebeşte între
şiruri de caractere
cu lungime fixă şi
variabilă
Nr_ProprietarP Nr_Proprietar Nr_ProprietarP (FK) Access nu acceptă
(FK) → Nr_Proprietar din → Nr_Proprietar din ca o aceeaşi FK
Nr_ProprietarA „Proprietar_Privat” „Proprietar_Privat” dintr-un tabel copil
(FK) şi în totodată iar să bată în 2 tabele
Nr_Proprietar Nr_ProprietarA (FK) părinte diferite
Admit NULLuri → Nr_Proprietar din → Nr_Proprietar din (integrit. ref.)
„Proprietar_Afacere” „Proprietar_Afacere”
Nr_Filiala (FK) Regula de Regula de MS Access oferă
reactualizare: reactualizare: doar:
CASCADE CASCADE Regula de
Regula de ştergere: Regula de ştergere: reactualizare:
SET DEFAULT NO ACTION CASCADE
Regula de ştergere:
NO ACTION
MS Access nu
acceptă:
SET NULL şi
SET DEFAULT

Se trece la crearea bazei de date în MS_Access, pornind de la Blank Database. Modul de

creare a tabelelor (relaţiilor) în MS_Access este detaliat în partea a doua a cursului. Mai jos
este prezentată vizualizarea de proiectare (Design View) a tabelului corespunzător relaţiei
Proprietate_de_Închiriat.

3
BAZE DE DATE CAP. 8

În cadrul tabelelor:
- se specifică cheia primară
- se setează proprietăţile câmpurilor: field size, format, input mask, caption, default
value, validation rule/text, required.
- Se creează liste de tip „lookup”, ca cea pentru tipul de proprietate:

O dată create toate tabelele proiectate, se realizează relaţiile dintre acestea şi se impune
integritatea referenţială.

4
BAZE DE DATE CAP. 8

Cascade Update Related Fields: modificarea unei valori din cheia primară din tabelul părinte
declanşează automat reactualizarea valorilor corespunzătoare din toate înregistrările legate.

Cascade Delete Related Records: ştergerea unei înregistrări din tabelul părinte duce la
ştergerea tuturor înregistrărilor legate din tabelul copil.

Pasul 4.1 se încheie cu documentarea proiectului fizic prin DBDL .

Pasul 4.2. Proiectarea constrângerilor întreprinderii pentru SGBD ţintă

Constrângerile întreprinderii, provenite din lumea reală, pot influenţa reactualizările relaţiilor.
Exemplu: Un angajat nu poate administra mai mult de 10 proprietăţi. Constrângerile trebuie
reproiectate în funcţie de SGBD ales, respectiv invers, SGBD se alege astfel încât să permită
implementarea acestei constrângeri.
Pentru Access implementarea constrângerilor de întreprindere se realizează de exemplu cu
limbajul Visual Basic, care lucrează cu baze de date în Access.

8.2 Pasul 5. Proiectarea reprezentării fizice

Se determină organizarea fişierelor şi metodelor de acces utilizate pentru stocarea relaţiilor de

bază. Stocarea eficientă a datelor se evaluează prin:
- transferul de tranzacţii: număr de tranzacţii prelucrabile în timp
- timpul de răspuns: timpul scurs până la încheierea unei singure tranzacţii (de
minimizat)
- capacitatea de stocare pe disc: spaţiul pe disc necesar stocării fişierelor bazei de date
(de minimizat).
Proiectantul trebuie să cunoască cele 4 componente hardware care interacţionează şi afectează
performanţele sistemului: memoria principală, unitatea CPU, discul I/O, reţeaua.

Pasul 5.1 Analizarea tranzacţiilor

Pentru fiecare tranzacţie se determină:
- frecvenţa estimată cu care vor fi rulate tranzacţiile
- relaţiile şi atributele accesate de tranzacţie şi tipul de acces (interogare, inserare,
reactualizare, ştergere)
- constrângerile de timp impuse tranzacţiilor

În cazul BD a unei agenţii imobiliare se consideră – cu titlu de exemplu – următoarele

tranzacţii:

A: realizarea unui raport în care sunt enumerate proprietăţile de închiriat din cadrul fiecărei
filiale
B: crearea şi întreţinerea înregistrărilor referitoare la clienţii din cadrul fiecărei filiale
C: enumerarea vizitelor efectuate de clienţi, cunoscând adresele proprietăţilor vizitate

5
BAZE DE DATE CAP. 8

Hărţile de utilizare a tranzacţiilor

a) Harta cu modelul ER simplificat cu numerele estimate de apariţii ale fiecărei entităţi

Figura 1. Harta cu modelul ER simplificat cu numerele estimate de apariţii ale fiecărei entităţi

În colţul din stânga sus al fiecărei entităţi este trecut estimarea numărului total de apariţii ale
acesteia (numărul de înregistrări din tabel). Se indică de asemenea valorile medii şi maxime
ale apariţiilor dintr-o entitate copil, asociate unei apariţii din entitatea părinte.
Astfel:
- În tabelul „Filiala” sunt înregistrate 50 de filiale.
o Unei filiale îi sunt alocate în medie 240 şi maxim 300 proprietăţi de închiriat.
o La o filială sunt înregistraţi în medie 400 şi maxim 500 de chiriaşi.
- În tabelul „Proprietate_de_Închiriat” sunt înregistrate estimativ 12000 proprietăţi (50
filiale x 240 proprietăţi, în medie/filială).
o O proprietate de închiriat este vizitată (apare în „Vizitare”) în medie de 20 şi
maxim de 40 de ori.
- În tabelul „Chiriaş” sunt înregistraţi estimativ 20000 de chiriaşi (50 filiale x 400
chiriaşi în medie/filială)
o Un chiriaş efectuează în medie 10 şi maxim 20 de vizitări.
- În tabelul „Vizitare” sunt înregistrate estimativ 360000 vizitări (12000 proprietăţi de
închiriat x 30 vizitări /proprietate)

6
BAZE DE DATE CAP. 8

Harta căilor şi operaţiilor tranzacţiilor A, B şi C

Figura 2. Harta căilor şi operaţiilor tranzacţiilor A, B şi C

În harta b) sunt afişate operaţiile de inserare (I), citire (C), reactualizare (R) sau ştergere (Ş)
împreună cu calea corespunzătoare tranzacţiilor A, B şi C.

A: realizarea unui raport în care sunt enumerate proprietăţile de închiriat din cadrul
fiecărei filiale
Tranzacţia A deci necesită accesarea tabelului „Filiala” şi citirea (C) a datelor din acest tabel.
Prin intermediul atributului Nr_Filială (cheie primară în Filiala şi cheie străină în
Proprietate_de_Închiriat) se citesc (C) proprietăţile de închiriat oferite de fiecare filială.

B: crearea şi întreţinerea înregistrărilor referitoare la clienţii din cadrul fiecărei filiale

Tranzacţia B necesită inserarea (I) a clienţilor (chiriaşilor) înregistraţi în tabelul „Chiriaş” şi în
acelaşi timp la o anume filială, reactualizarea (R) şi ştergerea (Ş) datelor referitoare la chiriaşi.
Pentru executarea tranzacţiei B se va accesa tabelul „Filiala”, iar prin atributul Nr_Filială
(cheie primară în „Filiala” şi cheie străină în „Chiriaş”) se vor insera, citi, reactualiza sau
şterge chiriaşii înregistraţi la fiecare filială.

C: enumerarea vizitelor efectuate de clienţi, cunoscând adresele proprietăţilor vizitate

Tranzacţia C necesită accesarea tabelului „Proprietate_de_Închiriat”, punct de acces fiind
atributul adresa proprietăţii, cunoscut. Prin atributul Nr_Proprietate (cheie primară în

7
BAZE DE DATE CAP. 8

„Proprietate_de_Închiriat” şi cheie străină în „Vizitare”) se citesc (C) vizitelor efectuate la

acea proprietate.

De asemenea se pot înregistra şi ziua şi ora estimată la care va fi rulată fiecare tranzacţie,
inclusiv momentul sau intervalul de încărcare maximă. Pentru tranzacţiile care accesează
frecvent baza de date, modelul lor de execuţie se documentează ca în cazul exemplului de mai
jos, referitor la tranzacţia D:

D: căutarea proprietăţilor de închiriat oferite de o anumită filială, care satisfac un

anumit tip de proprietate cerut de un potenţial chiriaş.

Singurele operaţii necesare pentru tranzacţia D sunt de citire (C), documentate în figura de
mai sus. Atributele utilizate ca puncte de acces, de intrare sunt notate cu (P).
În cadrul tranzacţiei D se accesează tabelul „Filiala”, punctul de acces fiind atributul cheie
primară Nr_Filială, care se citeşte (C). Din tabelul „Filiala”, prin mecanismul cheie primară-
cheia străină (Nr_Filiala) se citesc (C) în tabelul „Proprietate_de_Închiriat” datele referitoare
le toate proprietăţile oferite de o anumită filială. Atributul „Tipul” se utilizează ca punct de
intrare pentru interogare (clientul caută un anumit tip de proprietate).
La accesarea unui număr de filială din „Filiala” se accesează tabelul
„Proprietate_de_Inchiriat” de 48 – 300 ori (există minim 48 de proprietăţi din fiecare tip
disponibile la o filială, şi o filială oferă maxim 300 de proprietăţi).

Analizând toate tranzacţiile (nu numai A, B, C, şi D exemplificate) asupra întregii baze de

date a agenţiei imobiliare se constată că foarte multe tranzacţii necesită accesarea tabelului
„Proprietate_de_Închiriat”.

8
BAZE DE DATE CAP. 8

Pasul 5.2 Alegerea organizării fişierelor

Se alege tipul adecvat de fişier, care poate fi: heap; hash; ISAM – Indexed Sequential Access
Method; arbore B+.
În majoritatea cazurilor SGBDurile bazate pe PCuri (de ex. MS-Access) nu permit
utilizatorului alegerea sau modificarea organizării fişierelor din tabelele de bază.

Pasul 5.3 Alegerea indexurilor secundare

Trebuie de determinat dacă adăugarea de indexuri secundare îmbunătăţeşte performanţele
sistemului. Indexurile secundare oferă un mecanism de specificare a unei chei adiţionale,
pentru regăsirea mai eficientă a datelor.
Exemplu: pentru entitatea Proprietate_de_Inchiriat se va indexa cheia primară
Nr_Proprietate (index primar) şi se poate constitui un index secundar pentru atributul Chirie,
ca fiind de interes.

Indicaţii referitoare la indexare:

- se indexează cheia primară
- nu se indexează relaţii mici
- se indexează cheia străină dacă e frecvent utilizată
- nu se indexează atribute frecvent reactualizate
- nu se indexează atribute cu şiruri lungi de caractere.

MS-Access indexează automat cheile primare şi cheile străine din tabele.

În cazul interogării a mai multe tabele simultan (interogare de tabele multiple) viteza de
interogare poate fi mărită prin indexarea câmpurilor din ambele părţi ale firului relaţiei (din
ambele părţi ale uniunii) şi prin indexarea câmpurilor pentru care se utilizează criterii de
interogare. De exemplu în tabelul „Proprietate_de_Închiriat” se vor indexa câmpurile frecvent
interogate „tipul” şi „zona”.

Este indicat să se creeze numai indexuri care se presupune că vor îmbunătăţi performanţele
sistemului, deoarece întreţinerea indexurilor încarcă suplimentar resursele, ceea ce ar putea
avea ca rezultat final scăderea vitezei sistemului.

Crearea indexurilor secundare se documentează, împreună cu motivaţia pentru care au fost

considerate necesare.

Pasul 5.4 Considerarea introducerii unei redundanţe controlate

Trebuie de determinat dacă introducerea de redundanţă controlată prin relaxarea normalizării
(denormalizare) duce la îmbunătăţirea performanţelor sistemului. Datorită denormalizării
implementarea BD este mai dificilă, scade flexibilitatea BD, se pot accelera regăsirile dar se
încetinesc reactualizările.

Pasul 5.4.1 Considerarea datelor derivate

Valorile atributelor derivate pot fi calculate din valorile altor atribute. Stocarea unui atribut
derivat în BD duce la:
- costuri suplimentare de stocare şi menţinere a concordanţei datelor derivate cu datele
operaţionale din care au fost derivate;
- costuri de calculare a datelor derivate de fiecare dată când este necesar.

9
BAZE DE DATE CAP. 8

Exemplu: Entitatea Personal poate conţine un nou atribut derivat (Nr_Proprietati) care arată
câte proprietăţi administrează fiecare membru al personalului. Valoarea acestui atribut se
derivă din entitatea Proprietate_de_Inchiriat, după atributul NrPer (fig. 1.45).

PROPRIETATE_DE_INCHIRIAT
NrPro Strada Zona Orașul CodP Tipul Camere Chirie Nr_Ptr NrPer NrFil
PA14 1 ABC A1 Bucuresti 1234 Casa 6 650 CO46 SA9 B7
PL94 2 DEF B2 Bucuresti 5678 Apart. 4 400 CO87 SL41 B5
PG4 3 GHI C3 Bucuresti 9101 Apart. 3 350 CO40 SG14 B3
PG36 4 JKL D4 Bucuresti 1112 Apart. 3 375 CO93 SG37 B3
PG21 5 MNO E5 Bucuresti 1314 Casa 5 600 CO87 SG37 B3
PG16 6 PQR F6 Bucuresti 1516 Apart. 4 450 CO93 SG14 B3

PERSONAL
NrPer Prenume Nume Adresa MAN Nr_Fil Nr_Proprietati
SL21 I V AB123 WK442011B B5 0
SG37 A B CD456 WL432514C B3 2
SG14 D F RT789 WL220658D B3 2
SA9 M H GH654 WM532187D B7 1
SG5 S D SD963 WK588932E B3 0
SL41 I L BN741 WA290573D B5 1

Figura 3 Relaţia Personal simplificată cu atributul derivat Nr_Proprietăţi

Dacă BD este interogată frecvent asupra numărului de proprietăţi administrate de fiecare

membru al personalului poate fi util de stocat acest atribut derivat în relaţia (entitatea)
Personal.

Exemplu:
Tranzacţia E: Enumerarea numărului proprietăţii, oraşului, tipului, chiriei şi avansului pentru
închiriere (conform regulilor de afaceri: avansul = 2 x chiria).

Interogarea trebuie să cuprindă toate câmpurile cerute plus un câmp calculat (derivat) pentru
„avans”. Pentru a evita rularea repetată a interogării, se preferă adăugarea unui câmp
suplimentar în tabelul de bază, „Proprietate_de_Închiriat”, câmp numit „Avans”, unde se trece
avansul pentru fiecare proprietate, calculat de operatorul uman la înregistrarea sau
actualizarea proprietăţii respective.
Deci la executarea tranzacţiei E nu mai trebuie calculat (prin rularea interogării) avansul
pentru fiecare proprietate.

10
BAZE DE DATE CAP. 8

Pasul 5.4.2 Considerarea dublării atributelor sau grupării (uniunii) relaţiilor

Există situaţii în care se dublează anumite atribute sau se grupează relaţii pentru a reduce
numărul de uniuni necesare pentru efectuarea unei interogări.

Pentru evitarea redundanţei, prin normalizare relaţia

Filiala (Nr-Fil, Strada, Zona, Orasul, CodP, Nr_Tel, Nr_Fax)
se descompune în două relaţii:

Filiala (Nr_Fil, Strada, CodP, Nr_Tel, Nr_Fax)

Cod_Postal_Filiala (Nr_Fil, CodP, Zona, Orasul)

Astfel la introducerea unei filiale noi nu trebuie de repetat toate informaţiile legate de oraş.
Totuşi se întâmplă rar să dorim să accesăm adresa filialei fără atributele corespunzătoare zonei
şi oraşului. Păstrând atributele oraşului într-o relaţie separată înseamnă că, ori de câte ori
dorim adresa completă a filialei, trebuie de efectuat uniunea celor 2 relaţii.

11
BAZE DE DATE CAP. 8

Ca urmare se optează pentru o denormalizare şi se păstrează prima variantă a relaţiei, deşi

conţine date redundante.

Exemplu: Tranzacţia F: a se enumera pentru fiecare proprietate numărul proprietăţii, strada,

oraşul, împreună cu numărul de personal şi numele angajatului responsabil pentru
administrarea proprietăţii respective.

Se realizează o interogare pe tabele multiple, adică o grupare/uniune de tabele (vezi figura de

mai jos), pentru a include numele angajatului (din tabelul „Personal”) în rezultatul interogării.

Pentru a evita rularea interogării de fiecare dată (necesitatea realizării uniunii între cele 2
tabele), în tabelul „Proprietate_de_Închiriat” se introduce o redundanţă controlată, anume
câmpul „Nume” (care există şi în tabelul „Personal”).

12
BAZE DE DATE CAP. 8

Pentru a garanta coerenţa în continuare a BD, se proiectează şi se implementează un program

de aplicaţie prin care orice modificare în câmpul „Nume” în tabelul părinte „Personal” să se
transmită în câmpul „Nume” din tabelul copil „Proprietate_de_Închiriat”.
Pasul 5.4.3 Documentarea introducerii redundanţei

Orice redundanţă introdusă ulterior se documentează şi se motivează. Modelul de date logic

trebuie reactualizat, astfel încât să reflecte orice modificări apărute prin denormalizare.

Pasul 5.5 Estimarea necesarului de spaţiu pe disc

Este obligatorie pentru stabilirea performanţelor hardware cerute pentru implementarea bazei
de date. Se determină astfel dacă pe moment sau în viitor este necesare achiziţionarea de
hardware mai performant.

8.3 Pasul 6. Proiectarea mecanismelor de securitate

Măsurile de securitate pentru baza de date trebuie să corespundă cerinţelor utilizatorilor.

Pasul 6.1 Proiectarea vederilor utilizatorilor

În baza modelelor de date logice local se proiectează vederile utilizatorilor. Vederile se
creează în MS-Access prin interogări QBE, care se bazează pe limbajul de interogare
structurată SQL (Structured Query Language).
Exemplu: Se doresc detalii referitoare la personalul agenţiei imobiliare, vizibile pentru
supervizorul organizaţiei, dar fără informaţii referitoare la salarii.
In timp ce managerul organizaţiei vede relaţia de bază, completă:
Personal (Nr_Personal, Prenume, Nume, Adresa, Telefon, Sex, Functia, Salariu, Nr_Filiala)
Cheie primară: Nr_Personal
Cheie străină: Nr_Filiala, se referă la relaţia, tabelul „Filiala” (cu cheia primară Nr_Filiala).

În urma interogării selective QBE (implicit cu SQL) se generează vederea:

Personal_VedereSupervizor (Nr_Personal, Prenume, Nume, Adresa, Telefon, Sex, Functia,
Nr_Filiala)
Cheie primară: Nr_Personal
Cheie străină: Nr_Filiala, se referă la relaţia, tabelul „Filiala” (cu cheia primară Nr_Filiala).
Aceasta este o vedere pentru un utilizator cu permisiune de acces la date limitată.

Vederea supervizorului, adică răspunsul la interogarea selectivă, se poate edita (reactualiza).

MS-Access va scrie reactualizările în tabelul sau tabelele de bază care au fost interogate. Deci
supervizorul are dreptul la reactualizări asupra tabelului de bază Personal, cu excepţia
câmpului „Salariu”, utilizând interogarea selectivă QBE, respectiv formular corespunzător
interogării.

Figurile de mai jos arată vizualizarea de proiectare (Design View) a interogării selective QBE
(Query By Example) şi formularul realizat în baza interogării, formular cu care lucrează
supervizorul.

13
BAZE DE DATE CAP. 8

Pasul 6.2 Proiectarea regulilor de acces

De regulă utilizatorii nu au acces la relaţiile de bază, ci numai la vederile create pentru ei.
Administratorul de BD atribuie fiecărui utilizator un identificator de autorizaţie care are
asociată o parolă.
Fiecare instrucţiune SQL executată de către SGBD este efectuată în numele unui anumit
utilizator. Identificatorul de autorizaţie determină la ce obiecte din BD se poate referi
utilizatorul şi ce operaţii poate efectua asupra acestor obiecte. Fiecare obiect creat în SQL are
un proprietar identificat prin identificatorul de autorizaţie. Proprietarul este singurul care
cunoaşte existenţa obiectului respectiv şi deci poate efectua operaţii asupra lui.

Privilegiile sunt acţiunile pe care un utilizator are voie să le efectueze asupra unei relaţii de
bază sau vederi.

Instrucţiuni pentru acordarea privilegiilor:

SELECT: privilegiul de a regăsi date dintr-o relaţie
Când utilizatorul creează o relaţie folosind instrucţiunea Create Table din limbajul SQL,
utilizatorul de vine automat proprietarul noii relaţii cu privilegii complete
GRANT: se acordă privilegii altor utilizatori asupra relaţiei nou create

14
BAZE DE DATE CAP. 8

REVOKE: revocă privilegii

CREATE VIEW: utilizatorul care creează vederea devine automat proprietarul acesteia, dar nu
neapărat cu privilegii complete, (ca la SELECT)

Exemplu: pentru ca utilizatorul manager să regăsească rânduri din relaţia Personal şi să

insereze, să reactualizeze şi să şteargă date din aceasta, să transmită privilegii utilizatori, se
utilizează următoarea instrucţiune SQL:
GRANT ALL PRIVILEGES
ON personal
TO manager WITH GRANT OPTION.

Exemplu: Utilizatorului cu identificatorul de autorizaţie ADMIN i se acordă privilegiul

SELECT pentru relaţia Personal, cu următoarea instrucţiune SQL:
GRANT SELECT
ON personal
TO admin

MS-Access oferă două metode tradiţionale de securizare a BD:

- stabilirea unei parole a BD (pentru deschiderea BD)
- securitatea la nivel de utilizator (se limitează segmentele din BD care pot fi citite sau
reactualizate la nivel de utilizator)..

Stabilirea unei parole

Figura de mai jos arată caseta de dialog care solicită introducerea parolei pentru deschiderea
bazei de date.

O dată deschisă BD, toate obiectele (tabele, interogări, formulare etc.) sunt puse la dispoziţia
utilizatorului.

Securitatea la nivel de utilizator

Securitatea la nivel de utilizator este similară metodelor utilizate în majoritatea sistemelor

(softurilor) de reţele. Utilizatorului i se cere să se identifice şi să scrie o parolă atunci când
porneşte MS-Access. În cadrul fişierului de informaţii al grupului de lucru (Workgroup
Administrator) utilizatorii sunt identificaţi ca membri ai unui grup. Access defineşte automat
grupurile Admin şi Users, dar pot fi definite şi alte grupuri.

Figura de mai jos ilustrează caseta de dialog pentru definirea grupurilor şi conturilor de
utilizator.

15
BAZE DE DATE CAP. 8

Figura de mai jos ilustrează caseta de dialog pentru acordarea permisiunilor de utilizator şi de
grup. Se reglementează modul în care se lucrează cu fiecare obiect din BD.
Un control mai fin se realizează prin definirea de grupuri (conturi de grup) noi, cărora li se
acordă anumite permisiuni (de grup). Apoi se adaugă utilizatorii care fac parte din acest grup,
care au implicit toate drepturile grupului din care fac parte, dar ale căror drepturi pot fi
modificate individual, astfel încât să fie mai multe sau mai puţine faţă de grup.

16
BAZE DE DATE CAP. 8

Pasul 6.3 Documentarea proiectului măsurilor de securitate şi vederilor utilizatorilor

Proiectarea vederilor individuale şi mecanismele de securitate trebuie complet documentate.

Dacă proiectul fizic afectează modelele de date logice individuale, atunci şi aceste diagrame
trebuie reactualizate.

8.4 Pasul 7. Monitorizarea şi reglarea sistemului operaţional

Obiectiv: Monitorizarea sistemului operaţional şi îmbunătăţirea performanţelor acestuia,

pentru a corecta deciziile inadecvate de proiectare sau pentru a reflecta cerinţele în schimbare.

Reglarea din mers a bazei de date de către administratorul BD prezintă anumite avantaje:
- se evită necesitatea procurării de hardware adiţional
- se poate micşora configuraţia hard
- timpul de răspuns scade, transferul devine mai eficient
- ca urmare cresc productivitatea întreprinderii, moralul angajaţilor şi satisfacţia
clienţilor.

Orice modificare de reglare poate în acelaşi timp îmbunătăţi o aplicaţie şi strica alta. Este de
dorit să se verifice/testeze întâi modificarea pe o bază de date de încercare, sau atunci când
sistemul nu este complet utilizat (în afara orelor de lucru).

Presupunem că după câteva luni de utilizare a BD complet operaţionale a agenţiei imobiliare

au apărut din partea mai multor utilizatori ai sistemului două noi cerinţe:

(1) Capacitatea de a păstra fotografii ale proprietăţilor de închiriat, împreună cu comentariile

care descriu principalele caracteristici ale acesteia.

În MS-Access se introduc câmpuri cu tip de date (data type): OLE (Object Linking and
Embedded = legarea şi înglobarea de obiecte). Acestea permit stocarea de date cum ar fi
documente MS-Word sau MS-Excel, figuri, sunete sau alte tipuri de date binare create în alte
programe. Obiectele OLE pot fi legate de sau înglobate într-un câmp dintr-un tabel sau
formular în Access şi pot fi afişate.

Tabelul Proprietate_de_Închiriat se va restructura astfel încât să cuprindă un câmp numit

„Vedere” cu tip de date OLE, şi un câmp numit „Comentarii”, cu tip de date Memo, capabil de
a cuprinde un text mai lung.

Această cerinţă se satisface prin crearea întâi a unui raport adecvat, care să conţină câmpurile
dorite pentru a fi vizualizate în Internet, după care în baza acestui raport se realizează Pagina
de acces la date. Pentru ca pagina de acces la date creată să fie activată, este necesară legătura
la Internet şi un browser adecvat.

17
BAZE DE DATE CAP. 8

Rezumatul capitolului 8

Proiectarea fizică a bazei de date reprezintă procesul de realizare a descrierii implementării

acesteia în capacitatea de stocare secundară.
Etapa iniţială (pasul 4) constă în transpunerea modelului de date logic global într-o formă
care să poată fi implementată în SGBD relaţional ţintă.
Următoarea etapă (pasul 5): proiectarea organizării fişierelor şi metodelor de acces care vor
fi utilizate pentru stocarea relaţiilor de bază. Aceasta presupune analizarea tranzacţiilor,
alegerea organizării adecvate a fişierelor, adăugarea de indexuri secundare, introducerea de
redundanţă controlată şi estimarea spaţiului necesar pe disc.
Indexurile secundare furnizează un mecanism de specificare a unei chei suplimentare pentru
o relaţie de bază, pentru regăsirea mai eficientă a datelor.
Denormalizarea este o opţiune atunci când performanţele sistemului nu sunt satisfăcătoare şi
o relaţie are o rată de reactualizare scăzută şi o rată de interogare foarte ridicată.
Baza de date trebuie prevăzută cu un mecanism de securitate (pasul 6). Măsurile de securitate
necesare se identifică pe parcursul proiectării logice. Ele se realizează prin crearea de vederi
pentru utilizatori şi utilizarea de mecanisme de control al accesului, scrise în limbajul SQL.
Etapa finală (pasul 7) din proiectarea fizică a BD constă în monitorizarea şi reglarea
neîntrerupte ale sistemului operaţional pentru maximizarea performanţelor.

Teste de autoevaluare

 Explicaţi diferenţa dintre proiectarea conceptuală, logică şi fizică a bazelor de date.

 Descrieţi scopul principalelor etape din metodologia de proiectare fizică a bazelor de
date.
 În ce condiţii se justifică denormalizarea unui model de date logic? Utilizaţi exemple.

18