8/4/2019 Access Tehnici de Proiectare a Bazelor de Date

1/6

1

Tehnici de proiectare a bazelor de date

Nici un alt factor individual nu are o atat de mare influenta asupra succesului uneiaplicatii de baze de date ca insasi proiectarea bazei de date. Modul in care organizatielementele individuale din tabele si apoi corelati aceste tabele una cu alta intr-o baza de dateformeaza fundamentul aplicatiei. Un fundament prost conceput determina ca programele sa fie

scrise mai dificil, ingreuneaza intretinerea si mareste dificultatea de dezvoltare a softului. Inplus, proiectarea incorecta poate forta programatorul sa foloseasca metode mai putin eficientede codificare, ceea ce va consuma mai mult timp si sunt mai susceptibile deerori.

Probabil ati invatat din cursurile de la clasa ca metodele bune de proiectare incep de lainceput. Pe de alta parte, este posibil sa fi invatat programarea prin executarea ei si sa invatatimetodele de proiectare bune prin incercari si din erori. Indiferent de situatie, acest capitoltrebuie sa va ajute sa va insusiti deprinderile existente pentru crearea celor mai bune proiectede baze de date. Pentru a face acest lucru, sa examinam cateva zone ale gestiunii bazelor dedate.

Normalizarea datelor

Cel mai important lucru pe care trebuie sa-l faceti cand incepeti o noua aplicatie este

proiectarea cu grija a structuriii tabelelor voastre. O baza de date insuficient structurata va aveaca rezultat un cod ineficient; mai rau, poate duce la imposibilitatea implementarii unor facilitati.Pe de alta parte, un set bine proiectat de tabele nu numai ca va rezolva problema curenta, darva furniza flexibilitate raspunsurile intrebarilor pe care inca nu le-ati anticipat. Probabil ca multmai important, veti scrie programe multa mai rapide prin fructificarea avantajelor instructiunilorSQL SELECT pentru regasirea si intretinerea datelor. In sfarsit, rapoartele care ar fi putut aveanevoie de o codificare manuala incomoda in cazul structurilor nenormalizate, se vor scrieaproape singure cand cand veti folosi generatorul de rapoarte pentru structuri normalizate.

In general, structura de date a unei aplicatii, mai mult de cat orice alt factor, asigurasuccesul aplicatiei. Visual FoxPro se bazeaza pe modelul relational al bazelor de date propusde E.F. Codd in 1970. Codd isi bazeaza modelul sau pe principiile matematice care guverneazateoria relatiilor multimilor. Urmand doar un numar foarte mic din regulile specifice ce definesccrearea multimilor, ele va asigura ca puteti manipula datele foarte usor. Aceasta tehnica adevenit cunoscuta ca normalizarea datelor.Intreaga teorie a bazelor de date relationale se invarte in jurul conceptului utilizarii campurilorcheie pentru definirea relatiilor dintre tabele. Cu cat aveti mai multe tabele, cu atat va suntnecesare mai multe relatii FoxPro pentru a le conecta. Teoria multimilor nu este o pretentie orichiar ceea ce credeti, ca fiecare tabela sa f ie conectata direct la orice alta tabela. Totusi,deoarece fiecare tabela este conectata la cel putin una, astfel ca toate tabelele bazei de date audirect sau indirect relatii una cu cealalta.

Pentru a explica conceptele normalizarii, aceasta sectiune examineaza exemplulTasmanian Traderfurnizat de Visual FoxPro. Totusi, vizualizarea precisa a inceperii procesuluide dezvoltare a aplicatiei se va face dupa stabilirea necesitatilor de date.

Dependente functionale

Presupunand ca ati decis ce campuri de date va sunt necesare, urnatorul pas esteimpartirea lor in tabele (Desigur, puteti sa puneti toate campurile intr-o singura tabela). Chiar sifara normalizarea datelor, este evident ca nu vreti sa repetati toate informatiile desprefunctionari, clienti, produse, furnizori si livrarile pentru fiecare element comandat. Singurametoda de a determina ce campuri se vor afla impreuna in fiecare tabela este analizadependentelor functionale(nu din punct de vedere al terminalelor calculatorului).

Dependenta functionaladefineste relatiile de legatura dintre un atribut sau un grup deatribute dintr-o tabela cu atributul sau grupul de atribute intr-o alta tabela. In aceasta discutie,

8/4/2019 Access Tehnici de Proiectare a Bazelor de Date

2/6

2

termenul atributse refera la campuri. De aceea, este necesar sa vedeti ce campuri depind dealte campuri. De exemplu, numele de familie al unei persoane depinde de codul sau personal(prescurtat, CNP). Pentru orice CNP exista doar un singur nume ce ii corespunde - nu neparatun nume unic, dar numai un singur nume.

Cu alte cuvinte, un CNP nu depinde de un nume. Pentru un nume de familie dat, potexista sute si chiar mii de CNP-uri. Chiar daca la numele de familie adaugati si prenumele, esteposibil sa nu identificati un singur CNP. De exemplu, imaginati-va cate persoane Ionescu Ions-

ar putea sa existe la noi in tara.Deci, puteti concluziona ca un nume de familie este dependent functional de un CNP.In continuare, probabil veti dori sa gasiti si alte atribute ce depind functional de un CNP.

Analizand toate campurile, s-ar putea sa obtineti o lista similara celei din tabelul 4.1.Tabelul 4.1 Campurile dependente functional de CNPAdresa Nume Parola RegVanzariDataNastere IdGrup Foto SsnLocalitate DataAngajare Pozitie SalariuInitialStat TelefonAcasa CodPostal UtilizSistemIdFunct Prenume Regiune TaskDescExtensie NoLicenta RaportLa Titlu

Ca un prim pas in proiectarea tabelelor, este posibil sa grupati aceste campuri intr-otabela. Apoi, urmand o logica similara, probabil veti determina dependentele functionale in

campurile ramase. In continuare se grupeaza acele atribute care au aceeasi dependenta inaceeasi tabela. Ca efect, numarul dependentelor functionale determina numarul tabelelornecesare.

In realitate, daca respectati aceasta metoda de grupare a campurilor, tabelele obtinutetrebuie deja sa fie foarte aproape de o forma normalizata. Totusi, pentru a garanta ca ele suntnormalizate, trebuie sa verificati ca ele respecta primele trei reguli ale normalizarii datelor:

Prima forma de normalizare: elimina campurile ce se repeta si valorile neatomice; A doua forma de normalizare: impune ca fiecare coloana sa fie dependenta de cheia

primara; A treia forma de normalizare: solicita ca toate campurile ce nu sunt primare sa depinda

in mod individual de campurile primare.

Prima forma de normalizare

Prima forma de normalizare elimina campurile care se repeta si valorile neatomice. Ovaloare atomicainseamna ca respectivul camp reprezinta un singur lucru, nu o concatenare devalori - la fel cum un atom reprezinta un singur element.

La inceputurile bazelor de date relationale, exista o anumita limitare a numarului de

campuri dintr-o inregistrare. Ca urmare, era posibil ca un camp sa contina ceva de genul:12/03/9412/15/9401/05/95T

In realitate, aceasta valoare reprezenta patru campuri: data comenzii, data de incepere aproductiei, data de terminare si indicatorul ce specifica daca comanda a fost livrata.

Formarea relatiilor dintre campuri, regasirea datelor si executarea altor operatii nu esteusoara atunci cand un camp contine mai multe valori. Necesitatea de a executa cautareasubsirurilor si de a aniliza campurile incetineste foarte mult aplicatia, ne mai luand in calcul sicomplexitatea codificarii. Pentru a aduce o asemenea tabela in prima forma de normalizare,

acest camp trebuie impartit in patru campuri separate: trei campuri Date si un camp Logical.O alta problema comuna adresata de prima forma de normalizare este repetareacampurilor. Din nou, era ceva anormal pentru dezvoltatorii bazelor de date anterioare sacodifice separat numarul de elemente pe care le putea comanda un client. Ei plasauidentificatorul produsului comandat in aceeasi inregistrare cu informatiile generale ale comenzii,asa cum se prezinta in urmatorul tabel:IdComanda DataComanda IdProd1 IdProd2 IdProd3 IdProd4 Net

00006 08/04/94 A3426 B8483 C398 59.34

8/4/2019 Access Tehnici de Proiectare a Bazelor de Date

3/6

3

In acest exemplu, nu exista o problema atata timp cat clientul nu comanda mai mult depatru elemente in acelasi timp (in acest exemplu au fost comandate numai trei elemente).Totusi, era foarte dificil cautarea in baza de date pentru a determina cate de multe unitati dinfiecare produs au sold, deoarece programul trebuia sa verifice fiecare coloana de produs si sainsumeze rezultatele. Rapoartele care afisau o lista a clientilor ce au comandat un anumitprodus se realizau cu destula dificultate. De fapt, majoritatea rapoartelor aveau nevoie de ocodificare complexa astfel ca ele sa poata cauta in f iecare coloana. Ca urmare, rapoartele

aveau tendinta de a genera erori si necesitau mult timp de executie.Desigur, puteti mari numarul produselor posibile pe care le poate cumpara un client, dar

cat de multe sunt suficente (5, 10 sau 20)? Ce se intampla daca stabiliti 20 si cei mai multiclienti cumpara doar doua produse? Baza de date care va rezulta va necesita un spatiu mare,mult din el fiind neocupat. Mai important, in functie de modul in care codul citeste acestecampuri, puteti consuma un timp mare cu procesarea campurilor goale.

O alternativa este definirea unei baze de date care sa aiba un numar variabil decampuri. De fapt, unele sisteme de baze de date din anii anteriori suportau aceasta facilitate;ele chiar avansau aceasta ca cea mai buna solutie, dupa opinia departamentului de marketingal acestora. Din fericire, FoxPro continua sa admita adevaratul suport relational de definire altabelelor, pastrand fixa lungimea inregistrarilor.

Prima forma de normalizare impune inlocuirea campurile ce se repeta cu un singurcamp. Aceasta apoi creaza cate inregistrari sunt necesare (una pentru fiecare elementcomandat), asa cum se prezinta in tabelul urmator:IdComanda DataComanda IdProdus NetComanda

00006 08/04/94 A3426 59.3400006 08/04/94 B8483 59.3400006 08/04/94 C398 59.34

Dupa executarea acestei analize pe fiecare tabela din baza de date, modelul relationalpreliminar al datelor este terminat. Aceasta prima forma de normalizare este denumitanormalizare structuralasau sintactica. Totusi, ea nu trebuie sa fie niciodata obiectivul final. Potexista inca probleme in date si ele ar putea cauza o complexitate a codului mai mare decat estenecesara.

In mod intuitiv, puteti constata ca solutia oferita in exemplul anterior nu este finala. Earepeta valorile nu in interiorul inregistrarilor, ci de-a lungul mai multor inregistrari. Si dacavalorile se repeta, se pot produce inconsistente. Aceasta este problema adresata in formele denormalizare ce urmeaza.

A doua forma de normalizare

A doua forma de normalizare cere ca fiecare coloana sa fie dependenta de cheiaprimare. Sa privim din nou la tabela care rezulta din prima forma de normalizare:COMENZI.DBFIdComanda DataComanda IdProdus NetComanda

00006 08/04/94 A3426 59.3400006 08/04/94 B8483 59.3400006 08/04/94 C398 59.34

00007 08/05/94 B8483 9.18

Prin transformarea efectuata de prima forma de normalizare, IdComandanu mai este

unic; in tabela nu mai exista un camp unic individual. Totusi, combinatia IdComandasi IdProduspoate fi unica. Utilizand aceasta ca o prezumtie de lucru, este necesar sa examinati incontinuare celelalte campuri pentru a vedea daca ele depind de noua cheie primara.

DataComandadepinde numai de IdComanda, nu si de combinatia IdComandasiIdProdus. Acest lucru este adevarat si pentru NetComanda. De aceea, potrivit celei de a douaforma de normalizare, trebuie sa eliminati aceste campuri si sa le plasati intr-o tabela separatacu o copie a campului de care ele depind: IdComanda. Astfel au rezultat doua tabele. Numeleuneia care foloseste IdComandadrept cheie primara este COMENZI.DBF; numele celeilalte,

8/4/2019 Access Tehnici de Proiectare a Bazelor de Date

4/6

4

care contine o cheie primara pe campurile IdComandasi IdProduseste LINIECDA.DBF. Acestenoi tabele arata astfel:COMENZI.DBFIdComanda DataComanda NetComanda

00006 08/04/94 59.3400007 08/05/94 9.18LINIECDA.DBF

IdComanda IdProdus NrLinie00006 A3426 000100006 B8483 000200006 C398 000300007 B8483 0001

Doar prin respectarea primelor doua reguli ale normalizarii, ati obtinut datele facturiioriginale si ati derivat o structura ce este continuta in doua tabele: o tabela cu informatiigenerale despre factura si alta cu detaliile pentru fiecare element din factura. Remarcati ca intabela LINIECDA.DBFs-a adaugat un nou camp: NrLinie. Acest camp suplimentar contorizeazaelementelor din factura. Campul are o dimensiune fixata la patru cifre; astfel ca, in aceeasifactura pot sa apara pana la 9999 articole.

Pentru a asocia informatia din COMENZI.DBFcu LINIECDA.DBF, formati o relatie intreele bazata pe IdComanda. Aceasta relatie este de tipul unu la mai multi (1m), deoarece

pentru fiecare factura din COMENZI.DBF, poate exista mai multe inregistrari in LINIECDA.DBF.De fapt, nu exista o limitare a numarului de articole pe care le poate comanda un client - unarticol sau un milion de articole (In realitate, ati stabilit o limita arbitrara la 9999 prin marimeacampului NrLinie, dar ea poate fi marita prin cresterea dimensiunii campului). Programul, dacaeste scris pentru a utiliza fisierele corelate, manipuleaza la fel de bine ambele situatii.

A treia forma de normalizare

Pentru a aplica a treia forma de normalizare, tabela trebuie sa fie deja normalizata inprima si a doua forma. Apoi, determinati ce camp sau combinatie de campuri reprezinta cheiaprimara. Pentru tabela salariatilor, o alegere logica va fi CNP sau identificatorul (pe scurt ID)salariatului. Pentru tabela facturilor, campul IdComandaeste o buna optiune.

In tabela liniilor facturii nu exista un camp singular care sa poata identifica in mod unic oinregistrare. Pot exista mai multe inregistrari al detaliilor pentru IDComandasau IdProdus.

NrLinierepeta aceeasi secventa, incepand cu 1 pentru fiecare comanda. Totusi, combinatiaIdComandasi NrLinieeste unica. Chiar daca acelasi element apare de mai multe ori intr-osingura comanda, valoarea de element a acestuia va fi diferita. Deci, acest fisier va necesita ocheie primara compusa.

Pentru a ilustra a treia forma de normalizare, a fost adaugat un alt camp, NumeProd. Sapresupunem ca tabela detaliilor comenzii include urmatoarele campuri:LINIECDA.DBFIdComanda NrLinie IdProdus NumeProd

00006 0001 A3426 Tape Drives00006 0002 B8483 Modems

00006 0003 C398 Track Balls00007 0001 B8483 Modems

Pentru a fi in a treia forma de normalizare, toate campurile ce nu sunt primare trebuie sa

depinda doar de cheia primara. In primul rand se determina daca IdProdusdepinde doardepinde de combinatia campului cheie IdComandasi NrLinie. Raspunsul este Da, deoareceexista numai un singur IdProduspentru fiecare combinatie IdComandasi NrLinie.

IdProdusdepinde de numele produsului? Aceasta este o intrebare ciudata. In anumitecazuri, acesta depinde, dar numele produselor pot sa nu fie unice. Unele produse pot avea maimulte marimi, culori sau alte atribute. Fiecare produs are un IdProduspropriu unic. De aceea,IdProdus nu depinde doar de numele produsului.

8/4/2019 Access Tehnici de Proiectare a Bazelor de Date

5/6

5

NumeProddepinde doar de campurile cheii primare? In realitate nu. Numele produsuluinu este o functie de IdProdussi NrLinie; in schimb, el depinde de IdProdus. Reamintiti-va cafiecare IdProdusare un nume de produs unic, desi este posibil ca numele de produs sa fieasgnat la mai multi IdProdus. De aceea, acest camp nu respecta regulile celei de a treia formede normalizare.

Solutia in acest caz este mutarea numelui de produs intr-un nou fisier numit PRODUSEin care IdProduseste cheie primara. Este posibil sa ajungeti la aceasta concluzie independent

de analiza dependentelor functionale. Retineti ca regulile normalizarii doar intaresc analizafunctionala si sensul comun. Structura noii tabele este urmatoarea:LINIECDA.DBFIdComanda NrLinie IdProdus

00006 0001 A342600006 0002 B8483

00006 0003 C39800007 0001 B8483PRODUSE.DBFIdProdus NumeProd

A3426 Tape DrivesB8483 ModemsC398 Track Balls

B8483 ModemsDesigur, este necesar sa executati aceleasi analize asupra oricarei tabele din aplicatie.

Cand analiza este terminata, puteti sa spuneti ca aplicatia este normalizata. Desi exista si nivelesuplimentare de normalizare, ele sunt utilizate foarte rar. Daca practicati crearea tabelelor in atreia forma de normalizare, puteti evita multe dintre problemele structurilor de date. In modnormal, nu includeti campuri ce pot fi derivate din alte campuri din aceeasi tabela sau din tabelelegate. De exemplu, probabil ca nu veti dori sa includeti un camp total factura in fisierulfacturilor. Daca fisierul detaliilor contine pretul fiecarui element comandat - este simplu sainsumati preturile individuale pentru a obtine totalul facturii. Desigur, suma reala platita poate fistocata in factura pentru a o putea compara cu totalul datorat. Ganditi-va la ea in modulurmator: clientul achita de regula o factura dar facturarea se bazeaza pe elementele individuale.

Probabil ca sunteti coplesiti de aceste reguli. In realitate, practicandu-le veti ajunge sacreati fisiere normalizate chiar de la inceput. Unele persoane intelepte au spus ca adevarata

intelegere vine numai cand vedeti aceste reguli in vis; adica, cand va uitati la datele unei noiaplicatii si imediat stabiliti mental fisierele, ati inteles adevarata normalizare.

Cand se incalca regulile

Regulile normalizarii nu sunt legi; ele reprezinta doar un ghid care va ajuta sa evitaticrearea unor structuri de date care limiteaza flexibilitatea aplicatiei sau reduc eficienta ei. Totusi,nimeni nu va va inchide usa sau aresta daca incalcati regulile normalizarii (excepatnd probabilseful vostru). Urmatoarele exemple sunt situatii in care incalcarea regulilor normalizarii poate saaiba sens:

Aveti nevoie sa scrieti un sistem pentru o biblioteca care sa interzica oricarui cititor saimprumute mai mult de cinci carti in acelasi timp. Puteti scrie sistemul normalizandfisierul care urmareste cartile imprumutate; acesta va avea de asigurat sa nu exista maimult de cinci inregistrari pentru fiecare cititor. Totusi, o singura inregistrare cu cincicampuri - unul pentru fiecare carte - este posibil sa faca mai usoara dezvoltareaaplicatiei (o alternativa ar fi adaugarea unui camp in tabela cititorilor pentru contorizareanumarului de carti imprumutate in mod curent).

Un identificator de factura consta in realitate din doua cifre reprezentand anul si unnumar secvential de cinci cifre. Deoarece campul altei facturi reflecta deasemenea anul,teoretic il puteti extrage sau puteti folosi data in combinatie cu numarul secvential.

8/4/2019 Access Tehnici de Proiectare a Bazelor de Date

6/6

6

Totusi, este mai usoara referirea la un singur camp in acest caz; incalcandu-se regulanerepetarii valorilor ce pot fi derivate din alte campuri.

Ati acceptat un proiect pentru construirea unei baze de date pentru Asociatia Nationala aGemenilor. Veti crea o inregistrare separata pentru fiecare nume al gemenilor sau vetiinclude gemenii in aceeasi inregistrare?