Descrierea normalizarii bazei de date – Office

• 17.05.2021
• 5 minute de citit

• • M

  • h

  • d

  • s

• Se aplica la:

  Microsoft Office Access 2007, Microsoft Office Access 2003

In acest articol

Numar original KB:   283878

Acest articol explica terminologia de normalizare a bazei de date pentru incepatori. O intelegere de baza a acestei terminologii este utila atunci cand se discuta despre proiectarea unei baze de date relationale.

Descrierea normalizarii

Normalizarea este procesul de organizare a datelor intr-o baza de date. Aceasta include crearea de tabele si stabilirea de relatii intre aceste tabele in conformitate cu regulile concepute atat pentru a proteja datele, cat si pentru a face baza de date mai flexibila, eliminand redundanta si dependenta inconsecventa.

Datele redundante irosesc spatiul pe disc si creeaza probleme de intretinere. Daca datele care exista in mai multe locuri trebuie schimbate, datele trebuie schimbate exact in acelasi mod in toate locatiile. O modificare a adresei clientului este mult mai usor de implementat daca aceste date sunt stocate numai in tabelul Clienti si nicaieri altundeva in baza de date.

Ce este o „dependenta incoerenta”? Desi este intuitiv pentru un utilizator sa caute in tabelul Clienti adresa unui anumit client, este posibil sa nu aiba sens sa caute acolo salariul angajatului care apeleaza la acel client. Salariul angajatului este legat de sau este dependent de acesta si, prin urmare, ar trebui mutat in tabelul Angajatilor. Dependentele incoerente pot face dificila accesul la date, deoarece calea de gasire a datelor poate lipsi sau este rupta.

Exista cateva reguli pentru normalizarea bazei de date. Fiecare regula este numita „forma normala”. Daca se respecta prima regula, se spune ca baza de date se afla in „prima forma normala”. Daca sunt respectate primele trei reguli, baza de date este considerata a fi in „a treia forma normala”. Desi sunt posibile alte niveluri de normalizare, a treia forma normala este considerata cel mai inalt nivel necesar pentru majoritatea aplicatiilor.

La fel ca in cazul multor reguli si specificatii formale, scenariile din lumea reala nu permit intotdeauna respectarea perfecta. In general, normalizarea necesita tabele suplimentare si unii clienti considera acest lucru greoi. Daca decideti sa incalcati una dintre primele trei reguli de normalizare, asigurati-va ca aplicatia dvs. anticipeaza orice probleme care ar putea aparea, cum ar fi date redundante si dependente incoerente.

Urmatoarele descrieri includ exemple.

Prima forma normala

• Eliminati grupurile care se repeta in tabele individuale.
• Creati un tabel separat pentru fiecare set de date conexe.
• Identificati fiecare set de date conexe cu o cheie primara.

Nu utilizati campuri multiple intr-un singur tabel pentru a stoca date similare. De exemplu, pentru a urmari un articol de inventar care poate proveni din doua surse posibile, o inregistrare de inventar poate contine campuri pentru Codul furnizorului 1 si Codul furnizorului 2.

Ce se intampla cand adaugati un al treilea furnizor? Adaugarea unui camp nu este raspunsul; necesita modificari de program si de tabel si nu se potriveste fara probleme unui numar dinamic de furnizori. In schimb, plasati toate informatiile furnizorului intr-un tabel separat numit Furnizori, apoi conectati inventarul la furnizori cu o cheie de numar de articol sau furnizorii la inventar cu o cheie de cod furnizor.

A doua forma normala

• Creati tabele separate pentru seturi de valori care se aplica mai multor inregistrari.
• Relationati aceste tabele cu o cheie straina.

Inregistrarile nu ar trebui sa depinda de altceva decat de cheia primara a unui tabel (o cheie compusa, daca este necesar). De exemplu, luati in considerare adresa unui client intr-un sistem de contabilitate. Adresa este necesara in tabelul Clienti, dar si in tabelele Comenzi, Expediere, Facturi, Conturi de primit si Incasari. In loc sa stocati adresa clientului ca o intrare separata in fiecare dintre aceste tabele, stocati-o intr-un singur loc, fie in tabelul Clienti, fie intr-un tabel de adrese separat.

A treia forma normala

• Eliminati campurile care nu depind de cheie.

Valorile dintr-o inregistrare care nu fac parte din cheia inregistrarii respective nu apartin in tabel. In general, oricand continutul unui grup de campuri se poate aplica la mai mult de o singura inregistrare din tabel, luati in considerare plasarea acelor campuri intr-un tabel separat.

De exemplu, intr-un tabel de recrutare a angajatilor, pot fi incluse numele si adresa universitatii unui candidat. Dar aveti nevoie de o lista completa a universitatilor pentru trimiterile de corespondenta. Daca informatiile despre universitate sunt stocate in tabelul Candidati, nu exista nicio modalitate de a enumera universitatile fara candidati actuali. Creati un tabel separat de universitati si conectati-l la tabelul Candidati cu o cheie de cod universitara.

EXCEPTIE: Aderarea la a treia forma normala, desi teoretic este de dorit, nu este intotdeauna practica. Daca aveti un tabel Clienti si doriti sa eliminati toate posibilele dependente intre campuri, trebuie sa creati tabele separate pentru orase, coduri postale, reprezentanti de vanzari, clase de clienti si orice alt factor care poate fi duplicat in mai multe inregistrari. In teorie, normalizarea merita urmarita. Cu toate acestea, multe tabele mici pot degrada performanta sau pot depasi capacitatile de fisiere si de memorie deschise.

Poate fi mai fezabil sa se aplice a treia forma normala numai datelor care se schimba frecvent. Daca raman cateva campuri dependente, proiectati aplicatia dvs. pentru a solicita utilizatorului sa verifice toate campurile conexe atunci cand se modifica unul.

Alte forme de normalizare

A patra forma normala, numita si Boyce Codd Normal Form (BCNF), si a cincea forma normala exista, dar sunt rareori luate in considerare in proiectarea practica. Nerespectarea acestor reguli poate duce la o proiectare mai putin perfecta a bazei de date, dar nu ar trebui sa afecteze functionalitatea.

Normalizarea unui exemplu de tabel

Acesti pasi demonstreaza procesul de normalizare a unui tabel fictiv al elevilor.

1. Tabelul normalizat:

   Student # Consilier Adv-Room Clasa 1 Clasa 2 Clasa 3 1022 Jones 412 101-07 143-01 159-02 4123 Smith 216 101-07 143-01 179-04

2. Prima forma normala: fara grupuri repetate

   Tabelele trebuie sa aiba doar doua dimensiuni. Deoarece un elev are mai multe clase, aceste clase ar trebui sa fie listate intr-un tabel separat. Campurile Class1, Class2 si Class3 din inregistrarile de mai sus sunt indicatii ale problemelor de proiectare.

   Foile de calcul folosesc adesea a treia dimensiune, dar tabelele nu ar trebui. O alta modalitate de a privi aceasta problema este cu o relatie de la unu la mai multi, nu puneti partea una si partea multe in acelasi tabel. In schimb, creati un alt tabel in prima forma normala, eliminand grupul care se repeta (clasa #), asa cum se arata mai jos:

   Student # Consilier Adv-Room Class # 1022 Jones 412 101-07 1022 Jones 412 143-01 1022 Jones 412 159-02 4123 Smith 216 101-07 4123 Smith 216 143-01 4123 Smith 216 179-04

3. A doua forma normala: eliminati datele redundante

   Retineti valorile multiple ale clasei # pentru fiecare valoare # student in tabelul de mai sus. Clasa # nu depinde functional de numarul de student (cheia primara), deci aceasta relatie nu este in a doua forma normala.

   Urmatoarele tabele demonstreaza a doua forma normala:

   Elevi:

   Student # Consilier Adv-Room 1022 Jones 412 4123 Smith 216

   Inregistrare:

   Student # Clasa # 1022 101-07 1022 143-01 1022 159-02 4123 101-07 4123 143-01 4123 179-04

4. A treia forma normala: eliminati datele care nu depind de cheie

   In ultimul exemplu, Adv-Room (numarul biroului consilierului) depinde functional de atributul Consilier. Solutia este de a muta acel atribut din tabelul Studenti in tabelul Facultatii, asa cum se arata mai jos:

   Elevi:

   Student # Consilier 1022 Jones 4123 Smith

   Facultate:

   Nume Room Dept Jones 412 42 Smith 216 42