Proiectarea bazelor

de date

Proiectarea fizică a bazelor de date

si monitorizarea acestora

1
Introducere
◼ Procesul de proiectare al unei baze de date
constă în trei faze:
 Proiectarea conceptuală
 Proiectarea logică
◼ preocupată în principal de ce-uri
 Proiectarea fizică
◼ preocupată de cum-uri
◼ proiectantul bazei de date fizice trebuie să cunoască
sistemul de operare al calculatorului pe care rulează
SGBD-ul ţintă şi funcţionalităţile acestui SGBD

2
Proiectarea fizică a bazei de date
◼ procesul de realizare a unui plan de implementare a
bazei de date, într-o capacitate de stocare secundară
 Necesită informaţii colectate in fazele anterioare de
proiectare:
◼ Tabelele normalizate si numărul estimat de înregistrări pentru
fiecare
◼ Definiţia fiecărui atribut împreuna cu specificaţiile fizice (lungime
maximă)
◼ Descrierea modului si frecvenţei de utilizare a datelor
◼ Aşteptările şi necesităţile referitoare la
 timpii de răspuns
 integritate
 securitate
 recuperarea bazei de date şi copiile de siguranţă
◼ Descrierea tehnologiei ce se va utiliza pentru implementarea bazei
de date
3
◼ Solicita câteva decizii critice care vor afecta integritatea si
performantele sistemului
 Alegerea formatului de stocare (tipul datelor) pentru fiecare atribut din
modelul logic
◼ Formatul si parametrii asociaţi se vor alege astfel încât spaţiul de stocare
sa fie minimizat si sa se maximizeze integritatea datelor
 Gruparea atributelor din modelul logic in înregistrări fizice
◼ Se poate întâmpla ca deşi coloanele unui tabel relaţional sa reprezinte o definiţie
naturala a conţinutului unei înregistrări fizice, acestea sa nu fie întotdeauna cea mai
dezirabilă grupare de atribute
 Organizarea fişierelor in care sunt păstrate înregistrările cu structuri similare
să permită operaţii rapide de stocare, regăsire si actualizare
◼ Se va acorda atenţie si operaţiilor de protecţie si recuperare a datelor
 Alegerea acelor structuri de stocare si asociere a fişierelor (indecşi si
arhitecturi de baze de date) care sa permită regăsirea eficienta a datelor
interconectate
 Pregătirea unei strategii de manipulare a interogarilor asupra bazei de date
care sa optimizeze performanţele si sa foloseasca avantajele oferite de
organizarea fişierelor si indecşii specificaţi.
◼ Acest lucru este posibil numai dacă interogarile si SGBD-ul care le executa sunt
reglate pentru a utiliza inteligent aceste structuri

4
 Schema fizică

Schema Analiza volumului Create Table (…)

logică a bazei estimat de date si a Create Table (…)
de date utilizării bazei de Create Table (…)
date ……..
Create Table (…)

◼ Planul de implementare conţine următoarele elemente:

 Structurile de date declarate în DDL
 indecşii declaraţi pentru aceste structuri
 grupări de date (clustering) acolo unde este nevoie
 un set de constrângeri de integritate exprimate în DDL si un set de
constrângeri de integritate exprimate în limbaje corespunzătoare
 o strategie de distribuţie a sistemului de baze de date, inclusiv un plan
de distribuţie a datelor
 un set de interogări optimizate
 o mulţime de useri autorizaţi să acceseze baza de date

5
Proiectarea reprezentării fizice
◼ scop - determinarea organizării fişierelor şi a metodelor de acces care vor fi
utilizate pentru a stoca relaţiile de bază
◼ Eficienţa modului de stocare a datelor pe suportul secundar de memorie este
măsurată prin intermediul următorilor factori
 transferul de tranzacţii – dat de numărul de tranzacţii ce pot fi prelucrate într-un
anumit interval de timp.
 timpul de răspuns- este timpul scurs până la încheierea unei singure tranzacţii.
 capacitatea de stocare pe disc – spaţiul de pe disc necesar stocării fişierelor bazei de
date, spaţiu care trebuie minimizat.
◼ Proiectarea fizică a bazei de date nu este un proces static.
 odată implementat proiectul iniţial, acesta va fi monitorizat şi reglat funcţie de
rezultatele observate şi funcţie de modificarea cerinţelor.
 Activităţile implicate de proiectarea fizică a bazei de date
1. analiza volumului de date
2. analizarea tranzacţiilor
3. alegerea organizării fişierelor
4. alegerea indexurilor secundare
5. estimarea necesarului de spaţiu pe disc.

6
Analiza volumului estimat de date
◼ Este unul din aspectele critice ale proiectării fizice
◼ Este necesar să se estimeze atât numărul mediu cât şi
cel maxim de instanţe pentru fiecare obiect al bazei
de date
 Numărul maxim de instanţe posibile – util pentru a decide
necesităţile reale de stocare
 Numărul mediu de instanţe estimat a fi folosite de sistem –
imagine a abilităţii modelului de a satisface cerinţele de
acces la date

7
 Analizarea tranzacţiilor
◼Obiectiv:
 cunoaşterea funcţionalităţii tranzacţiilor care vor fi executate în cadrul bazei de date
 analizarea celor mai importante dintre acestea.
◼Informaţiile care trebuie cunoscute despre tranzacţii se referă la:
 frecvenţa estimată cu care vor fi rulate tranzacţiile
 relaţiile şi atributele accesate de către tranzacţii şi tipul de acces (interogare, inserare,
reactualizare sau ştergere)
 atributele utilizate în cadrul oricăror predicate (se verifică dacă predicatele implică
corespondenţa de modele, căutările de intervale sau regăsirea cheilor prin corespondenţă
exactă).
 pentru interogări - atributele implicate în uniunea relaţiilor, deoarece acestea pot
constitui candidaţi pentru structurile de acces;
 constrângerile de timp impuse asupra tranzacţiilor ( de ex. o tranzacţie trebuie efectuată
într-o secundă)
◼practic este indicată analiza pentru tranzacţiile considerate importante.
 se poate folosi o hartă de utilizare a tranzacţiilor, care arată ce relaţii accesează fiecare
tranzacţie şi indică schematic care dintre acestea va fi, potenţial, utilizată masiv.
◼este important să se cunoască nu numai numărul mediu şi maxim de execuţii pe oră, ci
şi ziua şi ora la care sunt rulate tranzacţiile, inclusiv momentul probabil în care se va
produce încărcarea maximă.

8
Analiza volumului si utilizării datelor
◼ Estimarea dimensiunii si tiparelor de utilizare a bazei de date –
aspecte critice in proiectarea fizică
◼ Poate fi generată pe durata fazei de analiză a sistemului, când
se analizează activitatea si operaţiile de prelucrare curenta si
de perspectiva a datelor
 Poate fi reprezentata prin notaţii adăugate diagramei ER extinse (EER)
◼ Statisticile referitoare la volumul datelor reprezintă
dimensiunea afacerii si ar trebui calculate luând in considerare
creşterea afacerii cel puţin pentru o perioadă de câţiva ani
◼ frecventele de acces sunt estimate din planificarea
evenimentelor, volumul tranzacţiilor, numărul utilizatorilor
concurenţi si activitatea de raportare si interogare
 Majoritatea bazelor de date suporta si accese ad-hoc, care se pot
modifica semnificativ in timp
◼ => frecventa acceselor are un grad scăzut de precizie

9
Analiza volumului si utilizării datelor
◼ In baza de date exista 1000 de piese
 supertipul PIESE are 2 subtipuri:
◼ produse proprii – 40% din toate piesele sunt produse proprii
◼ cumparate – 70% sunt cumparate
 Pentru ca unele piese pot fi atat cumparate cat si produse proprii suma procentelor este >100
◼ Sunt 50 de furnizori si acestia realizeaza cu firma, in medie cate 50de tranzactii
 Rezulta cca 2500 de tranzactii (furnizari)
◼ Liniile punctate reprezinta frecventele de acces
◼ Aplicatiile realizeaza aprox. 200 de accese/ora la datele referitoare la Piese si acestea produc, pe
baza procentelor estimate pentru subtipuri, aprox. 140 accese/ora la datele Piese cumparate
◼ Exista, suplimentar, 60 de accese directe la
datele Piese cumparate
 din cele 200 de accese la Piese cumparate,
80 de accese solicita date de legatura
(Furnizează) si din aceste 80 de accese 70
solicita si accesul la Furnizori

◼ Piese are 1000 de instante – daca are un numar mare de atribute si unele dintre acestea sunt lungi poate fi
importanta stocarea eficienta a datelor
◼ Pentru fiecare din cele 40 de ori pe ora când Furnizează este accesat via Furnizori se acceseaza de
asemenea si Piese cumparate => diagrama ar putea sugera o posibila combinare a celor doua tipuri de
entitati intr-un tabel (sau fisier)
 este un caz de denormalizare
◼ Pentru piesele cumparate si cele produse exista o suprapunere de 10 procente => poate fi utila separarea lor
in doua tabele diferite – se poate admite stocarea redundanta a acelor piese care sunt atat cumparate cat si
produse

10
Proiectarea campurilor
◼ Campul – cea mai mica unitate de date
recunoscuta de un sistem software (limbaj
de programare sau SGBD)
◼ Decizii referitoare la campuri:
 tipuldatelor utilizate pentru reprezentarea
valorilor din camp
 controalele de integritate a datelor construite
in baza de date
 cum ar trebui să gestioneze sistemul datele
lipsa din camp

11
Alegerea tipului datelor
◼ tipul datei - schema de codificare detaliata recunoscuta de
sistem pentru reprezentarea datelor organizaţionale
 tiparul de biţi al schemei este transparent pentru utilizator dar spaţiul de
stocare si viteza de acces a datelor sunt o consecinţă a proiectării bazei
de date fizice
◼ alegerea depinde de SGBD-ul vizat
◼ selecţia unui tip de data implica 4 obiective:
 minimizarea spaţiului de stocare
 reprezentarea tuturor valorilor posibile
 îmbunătăţirea integrităţii datelor
 suport pentru toate operaţiile necesare de manipulare a datelor
◼ orice constrângere de domeniu specificată în modelul
conceptual poate ajuta la alegerea tipului de data corect

12
Controlul integritatii datelor
◼ Conditie fundamentala pentru asigurarea conformitatii cu legea Sarbane-Oxley
(SOX)
 solicita audit cuprinzător pentru toate procedurile care lucrează cu date financiare
 controlul integrităţii la nivel de câmp este vazută favorabil in contextul auditului
 triggerele, procedurile stocare si log-urile funizează modalitaţi de a asigura că
numai valorile legitime sunt memorate în bazele de date
 pentru conformitate cu SOX toate controalele de integritate a datelor trebuie să fie
documentate corespunzător
◼ o formă de documentare este chiar definirea acestor controale pentru SGBD
◼ schimbările în controalele de integritate a datelor trebuie sa apara dupa o documentare
corespunzătoare a procedurilor de schimbare a acestora
 Pentru cele mai multe SGBD-uri controlul integrităţii datelor poate fi implementat în structura
fizică a câmpurilor şi respectarea sa va fi forţată de către SGBD
 tipul datei -> formă de control al integrităţii datelor deoarece poate limita tipul
valorilor din câmp (caracter, numeric) şi dimensiunea acestor valori
 controlul integrităţii datelor poate fi suportat de SGBD prin:
◼ valori implicite
◼ controlul gamei de valori
◼ controlul null-urilor
◼ integritate referenţială

13
Manipularea valorilor lipsa
◼ Null-urile sunt permise in 2 situaţii:
 Pentru cazul in care valorile nu sunt cunoscute
 Pentru valorile care nu sunt potrivite la un anumit moment dat sau intr-un anumit context
◼ Prevenirea apariţiei valorilor lipsa se face prin:
 valori implicite
 interzicerea valorilor null in câmp (impunere condiţiei not null)
Tehnici de manipulare a valorilor lipsă
◼ Estimarea unei valori care va fi plasată în câpul cu valori lipsă
 Media valorilor explicite
◼ Urmărirea valorilor lipsa a.î. rapoarte speciale sau alte elemente de sistem să permită
rezolvarea rapidă a valorilor necunoscute
 Folosirea triggerelor in definitia bazei de date:
◼ Un trigger ar putea inregistra intrările lipsă, într-un fişier unde sunt stocate valorile null
◼ Alt trigger este rulat periodic penru a crea un raport pentru fişierul log creat anterior
◼ Efectuarea unor teste de sensibilitate a.î. datele lipsă să fie ignorate până în momentul în care
acestea ar putea produce schimbări semnificative în rezultate
 EX. dacă vânzările totale lunare ale unui agent de vânzări sunt aproape de un prag care ar putea
implica un alt nivel de compensaţie a agentului respectiv
 Cea mai complexă metoda de manipulare a valorilor lipsă si solicita cel mai sofisticat mod de
programare
◼ rutinele pot fi scrise în progamele aplicaţie
◼ multe SGBD-uri au capacitaţi de programare sofisticate: expresii CASE, funcţii definite de utilizator (UDF),
triggere

14
Proiectarea inregistrărilor fizice şi denormalizarea
◼ Înregistrarile logice - grupează într-o relaţie acele
atribute care sunt determinate de aceeaşi cheie
primara
◼ Înregistrările fizice – grupuri de câmpuri memorate în
locaţii de memorie adiacente si citite/scrise împreună
ca o unitate de către SGBD
 Proiectarea acestora presupune secvenţierea câmpurilor în
locaţii de memorare adiacente pentru a se realiza două
obiective
◼ utilizarea eficienta a suportului de stocare secundar
◼ obţinerea unei viteze bune de prelucrare a datelor

15
Utilizarea eficienta a suportului de stocare
secundar
◼ Depinde de dimensiunea înregistrărilor fizice şi de structura de
stocare secundară
◼ SO citeşte/scrie date de pe/pe disc , printr-o operaţie de citire/scriere, în
unităţi numite pagini
◼ dimensiunea paginii este fixată de programatorii sistemului pt a utiliza cat
mai eficient RAM-ul pentru toate aplicaţiile
◼ Există SO în care o înregistrare fizică se poate întinde pe mai multe pagini
(2 pag)
 => dacă lungimea paginii nu este un multiplu întreg al lungimii înregistrării
fizice, pot apare spaţii mari, nefolosite, la sfârşitul unei pagini
▪ numarul înregistrarilor fizice/pagină = factor de blocare
▪ daca spatiul de memorare este redus iar inreg. fizice nu pot acoperi mai
multe pagini => crearea mai multor înregistrări fizice dintr-o singură
relaţie logică, va minimiza risipa
◼ Exista SGBD-uri care conţin mai multe înregistrări fizice într-un bloc de
date
 SGBD-ul gestionează blocurile de date
 SO gestionează paginile

16
Prelucrarea eficientă a datelor
◼ Depinde de cât de apropiate sunt pe suportul de memorie datele
cu legătură intre ele
 Adesea, pentru rezolvarea problemelor (interogări sau rapoarte), sunt
necesare date din diferite tabele
◼ relaţiile complet normalizate creează mai multe tabele şi rezolvă
problemele generate de anomaliile de actualizare
 o interogare care procesează date din mai multe relaţii foloseşte resurse
considerabile pentru joncţiuni
◼ daca implementarea presupune cate o relaţie pentru o înregistrare fizică exista
posibilitatea să nu obţinem o prelucrare eficienta a datelor
 Performanţele interogărilor în bazele de date complet normalizate şi în cele
parţial normalizate diferă
◼ W. Inmon (1988) - experiment referitor la evaluarea performanţelor unei
interogari într-o bază de date in urmatoarele situaţii:
 baza de date complet normalizata – 8 tabele
 baza de date parţial normalizata – 4 tabele
 baza de date parţial normalizata – 2 tabele
▪ În cea mai putin normalizată bază de date, interogarea a fost cu mai mult de
un ordin de mărime mai rapidă decat in cea complet normalizată
17
Denormalizarea
◼ Procesul de transformare a relaţiilor normalizate în specificaţii
pentru înregistrări fizice nenormalizate
◼ Denormalizarea poate:
 Partiţiona o relaţie în mai multe înregistrări fizice
 Combina atributele din mai multe relaţii într-o înregistrare fizică
 Combina operaţiile de mai sus
Critici ale denormalizării
◼ Finkelstein(1988)
 Denormalizarea poate creşte rata de erori şi inconsistenţe datorită
reinroducerii anomalilor de actualizare in baza de date
 Poate forţa reprogramarea sistemului dacă se schimbă regulile afacerii
◼ Ex: copiile redundante ale aceloraşi date datorate violării FN2 nu sunt
întotdeauna actualizate sincronizat
 Pentru obţinerea acestui deziderat sunt necesare module de program
suplimentare
◼ Hoberman(2002) – ghid post-normalizare

18
 Considerente referitoare la aplicarea
denormalizării
◼Scop - să determine dacă introducerea redundanţei într-un mod controlat, prin
relaxarea regulilor de normalizare, va îmbunătăţi performanţele sistemului.
◼Nu este indicat să se renunţe complet la normalizare deoarece aceasta obligă la
înţelegerea completă a fiecărui atribut care trebuie reprezentat în baza de date.
◼Denormalizarea:
 face ca implementarea să fie mai complexă,
 scade flexibilitatea
 accelerează regăsirile de date, dar încetineşte reactualizările.
◼ se referă la rafinarea schemei relaţionale astfel încât gradul de normalizare al
unei relaţii modificate să fie mai mic decât gradul a cel puţin uneia dintre
relaţiile iniţiale.
 Acelaşi termen este utilizat pentru a defini situaţiile în care se combină două
relaţii într-una singură, relaţia nouă fiind încă normalizată, dar conţinând mai
multe null-uri decât cele iniţiale. Denormalizarea mai este denumită şi rafinare
de utilizare
◼în practică, dacă performanţele nu sunt satisfăcătoare şi relaţia are o rată de
reactualizare scăzută şi o rată a interogărilor foarte înaltă, denormalizarea poate
fi o opţiune viabilă

19
◼ Informaţiile necesare acestei decizii sunt obţinute din matricea de referenţiere
încrucişată a tranzacţiilor/relaţiilor. Aceasta prezintă tranzacţiile solicitate de
sistem şi relaţiile pe care acestea le accesează. Matricea însumează într-o manieră
vizuală modelele de acces ale tranzacţiilor care vor fi efectuate în cadrul bazei de
date.

Tranzacţie/ Intreţinerea relaţiilor Enumerarea cărţilor Lista abonaţilor cu

relaţie împrumutate restanţe
I C R S I C R S I C R S
Cărţi X X X X X

Abonaţi X X X X X

Împrumut X X X X X

◼ Poate fi utilizată pentru a evidenţia posibilii candidaţi la denormalizare şi a estima

efectele acesteia
◼ Introducerea unei redundanţe controlate poate fi utilă în unul din următoarele
cazuri:
 in cazul dublării atributelor sau grupării relaţiilor
 în situaţia datelor derivate

20
 Dublarea atributelor sau gruparea relaţiilor
◼ scopul - reducerea numărului de uniuni necesare pentru efectuarea unei
interogări.
◼ nu există reguli fixe pentru stabilirea situaţiilor în care este indicată
denormalizarea
 combinarea relaţiilor unu-la-unu
◼ se face mai întâi o reexaminare a relaţiilor de tip 1:1 pentru a estima efectele
combinării acestora într-o singură relaţie.
◼ soluţie avantajoasă numai pentru relaţiile la care se face referire frecvent ca luate
împreună şi rar ca luate separat.
 dublarea atributelor care nu sunt chei în relaţii de tip 1:M - pentru reducerea
uniunilor
◼ se pot lua în considerare potenţialele avantaje obţinute prin dublarea în relaţia copil a
unuia sau a mai multor atribute ale relaţiei părinte care nu sunt chei, în cadrul unei
relaţii 1:M.
◼ Potenţiale probleme:
1. Dacă datele dublate sunt modificate în relaţia părinte , ele trebuie reactualizate şi în relaţia
copil pentru a menţine coerenţa copiilor multiple. Dacă această reactualizare nu poate fi
automatizată există un pericol sporit de pierdere a integrităţii
2. timpul suplimentar necesar pentru menţinerea coerenţei, la fiecare operaţie de inserare,
reactualizare sau ştergere a unei înregistrări. Această problemă se rezolvă de regulă prin
dublarea acelor atribute a căror valoare este imposibil sau improbabil să se modifice.
3. creşterea spaţiului de stocare ca rezultat al dublării

21
Dublarea atributelor sau gruparea relaţiilor
 tabele de referinţă (tabele de căutare sau liste de culegere )
◼ caz special de relaţii de tip 1:M
◼ conţin de regulă un cod şi o descriere.
◼ Avantajele utilizării unor astfel de tabele sunt:
 reducerea dimensiunilor relaţiei copil
 dacă descrierea se poate schimba, este mai uşor să fie modificată o dată în
tabelul de căutare, spre deosebire de modificarea de mai multe ori în relaţia
copil
 tabelul de căutare poate fi utilizat pentru validarea intrării utilizatorilor
 dublarea atributelor chei străine în relaţiile 1:M - pentru reducerea
uniunilor
◼ trebuie introduse constrângeri suplimentare asupra cheilor străine.
 dublarea atributelor în relaţiile N:M
 introducerea de grupuri repetitive
◼ au fost eliminate din modelul logic, ca rezultat al cerinţei ca toate relaţiile
să se afle în prima formă normală.
◼ acest tip de denormalizare trebuie luat în considerare în următoarele situaţii:
 numărul absolut de articole din grupul repetitiv este cunoscut
 numărul este static şi nu se va modifica în timp
 numărul nu este foarte mare
 crearea de tabele de extragere.
22
Cazul datelor derivate
◼ sunt acele atribute ale căror valori pot fi găsite prin examinarea valorilor altor
atribute (ex. vârsta unei persoane, numărul de studenţi dintr-o grupă etc)
◼ nu apar în modelul de date logic, ci sunt documentate în dicţionarul de date.
◼ Din perspectiva proiectării fizice a bazelor de date, faptul că un atribut derivate este
stocat în baza de date sau calculat de fiecare dată când este necesar constituie o
negociere. Proiectantul trebuie să estimeze:
 costurile suplimentare necesare pentru a stoca datele derivate şi pentru menţinerea
concordanţei acestora cu datele operaţionale din care sunt derivate;
 costul necesar calculării valorilor atributului derivat, de fiecare dată când aceasta se
impune.
◼ In etapa următoare proiectantul trebuie să aleagă cea mai puţin costisitoare
opţiune, care poate constitui subiectul constrângerilor privind performanţele.
◼ observaţie - s-ar putea să fie mai convenabil să se stocheze atributele derivate
oridecâte ori limbajul de interogare al sistemului nu poate trata cu uşurinţă
algoritmul de calcul al acestora

23