Noțiuni de bază despre proiectarea bazelor de date

O bază de date proiectată corespunzător furnizează acces la informații precise, actualizate. Deoarece o proiectare corectă este esențială pentru atingerea scopurilor utilizării unei baze de date, investiția în timpul necesar învățării principiilor unei bune proiectări este esențială. În cele din urmă, veți reuși să creați o bază de date care să vă îndeplinească necesitățile și care să poată fi modificată cu ușurință.

Acest articol furnizează indicații pentru planificarea unei baze de date desktop. Veți învăța cum să decideți de ce informații aveți nevoie, cum să împărțiți aceste informații în tabele și coloane potrivite și cum să faceți ca aceste tabele să interacționeze între ele. Acest articol trebuie citit înainte de a crea prima bază de date desktop.

 Important   Microsoft Access 2010 furnizează o nouă experiență de proiectare, care vă permite să creați aplicații de baze de date pentru Web. Multe aspecte legate de proiectare sunt diferite atunci când proiectați pentru mediul Web. Acest articol nu dezbate proiectarea de aplicații de baze de date Web. Pentru mai multe informații, consultați articolul Construirea unei baze de date pentru partajarea pe Web.

În acest articol


Termeni de știut despre bazele de date

Access 2010 organizează informațiile în tabele: liste de rânduri și coloane ce amintesc de un registru contabil sau de o foaie de calcul. Într-o bază de date simplă, se poate să aveți doar un singur tabel. Pentru cele mai multe baze de date va trebui să aveți mai multe. De exemplu, se poate să aveți un tabel care stochează informații despre produse, alt tabel care stochează informații despre comenzi și un altul cu informații referitoare la clienți.

Imagine descriind trei tabele în foi de date

Fiecare rând se numește mai adecvat înregistrare și fiecare coloană se mai numește câmp. O înregistrare este o modalitate semnificativă și consistentă de a combina anumite informații. Un câmp este un element singular de informație: un tip de element care apare în orice înregistrare. De exemplu, în tabelul produse, fiecare rând sau înregistrare ar conține informații despre un produs. Fiecare coloană sau câmp conține un anumit tip de informație despre acest produs, cum ar fi numele sau prețul.

Începutul paginii Începutul paginii

Ce reprezintă o proiectare bună a unei baze de date?

Anumite principii ghidează procesul de proiectare al unei baze de date. Primul principiu este acela că informațiile dublură (numite și date redundante) au o influență negativă, deoarece consumă spațiu și sporesc probabilitatea producerii de erori și inconsistențe. Al doilea principiu îl reprezintă importanța corectitudinii și caracterului complet al informațiilor. Dacă baza de date conține informații incorecte, orice rapoarte care extrag informații din baza de date vor conține, de asemenea, informații incorecte. Drept urmare, orice decizie luată bazându-vă pe aceste rapoarte va fi greșit informată.

O proiectare bună a unei baze de date este, după cum urmează, una care:

  • Împarte informațiile în tabele pe baza subiectelor, pentru a reduce datele redundante.
  • Furnizează programului Access informațiile necesare pentru a asocia informațiile din tabele după necesități.
  • Asistă și asigură acuratețea și integritatea informațiilor.
  • Adaptează necesitățile de procesare a datelor și cele de raportare.

Începutul paginii Începutul paginii

Procesul de proiectare

Procesul de proiectare constă în următorii pași:

  • Determinarea scopului bazei de date    

Acesta ajută la pregătirea pașilor rămași.

  • Găsirea și organizarea informațiilor necesare     

Adunarea tuturor tipurilor de informații pe care le înregistrați în baza de date, cum ar fi numele produsului și numărul comenzii.

  • Împărțirea informațiilor în tabele    

Împărțirea elementelor de informații în entități sau subiecte majore cum ar fi Produse sau Comenzi. Apoi, fiecare subiect devine un tabel.

  • Transformarea elementelor de informații în coloane    

Decideți ce informații să stocați în fiecare tabel. Fiecare element devine un câmp care este afișat sub formă de coloană în tabel. De exemplu, un tabel Angajați poate include câmpuri, cum ar fi Nume de familie și Data angajării.

  • Specificarea cheilor primare    

Alegeți cheia primară pentru fiecare tabel. Cheia primară este o coloană care se utilizează pentru a identifica în mod unic fiecare rând. Un exemplu poate fi ID produs sau ID comandă.

  • Configurarea relațiilor din tabel    

Priviți fiecare tabel și decideți cum se asociază datele dintr-un tabel cu datele din alte tabele. Adăugați câmpuri la tabele sau creați noi tabele pentru a clarifica relațiile, după necesități.

  • Rafinarea proiectării    

Analizați proiectarea Pentru eliminarea erorilor. Creați tabele și adăugați câteva înregistrări de date eșantion. Vedeți dacă reușiți să obțineți rezultatele dorite din tabele. Efectuați ajustări ale proiectării, după necesitate

  • Aplicarea regulilor de normalizare    

Aplicați regulile de normalizare a datelor pentru a vedea dacă tabelele sunt corect structurate. Efectuați ajustări pentru tabele, după necesitate

Începutul paginii Începutul paginii

Determinarea scopului bazei de date

Este o idee bună să vă notați scopul bazei de date pe o hârtie: destinația acesteia, modul cum doriți să o utilizați și cine o va utiliza. Pentru o bază de date mică pentru o afacere de familie, de exemplu, se poate nota ceva simplu, cum ar fi "Baza de date a clienților păstrează o listă a informațiilor despre clienți în scopul producerii de liste de corespondență și de rapoarte." Dacă baza de date este mai complexă sau este utilizată de mai multe persoane, cum se întâmplă de obicei într-o conjunctură corporativă, scopul se poate întinde pe mai multe paragrafe și trebuie să includă când și de către cine va fi utilizată baza de date. Ideea principală este să se descrie riguros misiunea bazei de date, care să fie consultată în cadrul procesului de proiectare. O astfel de instrucțiune vă ajută să vă concentrați asupra obiectivelor atunci când luați decizii.

Începutul paginii Începutul paginii

Găsirea și organizarea informațiilor necesare

Pentru a găsi și organiza informațiile necesare, începeți cu informațiile existente. De exemplu, se pot înregistra comenzile de cumpărare într-un registru sau se pot ține informații despre clienți în formulare, într-un dulap pentru dosare. Colectați aceste documente și treceți în listă fiecare tip de informații afișate (de exemplu, fiecare casetă completată dintr-un formular). Dacă nu aveți formulare existente, imaginați-vă că trebuie să proiectați un formular pentru a înregistra informații despre clienți. Ce informații ați dori să puneți în formular? Ce casete de completat ați crea? Identificați și treceți în listă toate aceste elemente. De exemplu, să presupunem că în prezent țineți lista de clienți pe fișe indexate. Examinând aceste fișe veți descoperi că fiecare fișă conține numele, adresa, orașul, statul, codul poștal și numărul de telefon ale unui client. Fiecare dintre aceste elemente poate reprezenta o coloană din tabel.

Pe măsură ce pregătiți lista, nu vă faceți griji dacă nu este perfectă din prima încercare. În schimb, treceți în listă fiecare element la care vă gândiți. Dacă va utiliza și altcineva baza de date, cereți-i părerea. Lista se poate îmbunătăți ulterior.

Apoi, luați în considerare tipurile de rapoarte sau de liste poștale pe care doriți să le obțineți din baza de date. De exemplu, se poate crea un raport de vânzări pentru un produs, care afișează vânzările în funcție de regiune sau un raport de rezumare a inventarului, care afișează nivelurile de inventar ale produselor. De asemenea, se pot genera scrisori formale, care li se vor trimite clienților pentru a îi anunța de evenimente sau de oferte speciale. Proiectați mintal raportul și imaginați-vă cum ar arăta. Ce informații ați dori să puneți în raport? Treceți fiecare element în listă. Faceți același lucru pentru scrisoarea formală și pentru orice alt raport pe care considerați că îl veți crea.

Imaginarea unui raport de inventar pentru produse

Proiectarea mentală a rapoartelor și a listelor poștale pe care doriți să le creați vă ajută la identificarea elementelor de care veți avea nevoie în baza de date. De exemplu, să presupunem că le oferiți clienților oportunitatea de a se abona (sau a se dezabona) la actualizări periodice prin poștă electronică și că doriți să imprimați o listă a celor care s-au abonat. Pentru a înregistra acele informații, adăugați o coloană “Abonat la mesaje de poștă electronică” la tabelul pentru clienți. Pentru fiecare client, se poate seta câmpul la Da sau la Nu.

Necesitatea de a le trimite mesaje de poștă electronică clienților sugerează alt element de înregistrat. După ce știți că un client dorește să primească mesaje de poștă electronică, va trebui să aflați adresa de poștă electronică la care să le trimiteți. Așadar, trebuie înregistrată o adresă de poștă electronică pentru fiecare client.

Este logic să se construiască un prototip al fiecărui raport sau listare de ieșire și să se ia în considerare elementele necesare pentru a produce raportul. De exemplu, când examinați o scrisoare formală, se poate să vă vină în minte alte idei. Pentru a include o formulă introductivă corespunzătoare, de exemplu, șirul "Dl.", "Dna." sau "Dra." cu care începe o formulă de salut, va trebui creat un element pentru introducere. De asemenea, este mai bine să se înceapă scrisorile cu “Dragă Dl. Georgescu”, decât cu “Dragă Dl. Florin Georgescu”. Așadar, de obicei este mai bine să se stocheze numele de familie separat de prenume.

Trebuie să se țină cont de faptul că informațiile trebuie despărțite în cele mai mici părți utile. În cazul unui nume, pentru ca numele de familie să fie ușor disponibil, se va despărți numele în două părți: Nume și Prenume. Pentru a sorta un raport după numele de familie, de exemplu, este util să se stocheze separat numele de familie ale clienților. În general, pentru a sorta, căuta, celula sau raporta în funcție de un element informațional, trebuie pus acel element într-un câmp propriu.

Gândiți-vă la întrebările la care doriți să răspundă baza de date. De exemplu, câte vânzări s-au finalizat pentru produsul principal? Unde locuiesc cei mai importanți clienți? Cine este furnizorul produsului care se vinde cel mai bine? Anticiparea acestor întrebări că ajută să vă dați seama de elementele suplimentare care trebuie înregistrate.

După ce colectați aceste informații, sunteți gata pentru pasul următor.

Începutul paginii Începutul paginii

Împărțirea informațiilor în tabele

Pentru a împărți informațiile în tabele, alegeți cele mai importante entități sau subiecte. De exemplu, după ce găsiți și organizați informațiile unei baze de date pentru vânzări de produse, lista preliminară poate conține:

Elemente informaționale scrise de mână, grupate pe subiecte

Entitățile principale afișate aici sunt produsele, furnizorii, clienții și comenzile. Așadar, este logică să porniți cu aceste patru tabele: unul pentru date despre produse, unul pentru date despre furnizori și unul pentru date despre comenzi. Deși lista este incompletă, este un punct de pornire bun. Lista se poate rafina până când se ajunge la un proiect care funcționează bine.

Când examinați prima dată lista preliminară de elemente, veți fi tentat(ă) să le plasați pe toate într-un singur tabel, în locul celor patru afișate în imaginea precedentă. Veți învăța acum de ce nu este o idee bună. Luați în considerare tabelul afișat aici:

Imagine care afișează un tabel care conține produsele și furnizorii

În acest caz, fiecare rând conține informații atât despre produs, cât și despre furnizorul lui. Deoarece se poate ca multe produse să aibă același furnizor, numele și informațiile furnizorului se repetă de multe ori. Acest lucru irosește spațiul de pe disc. Înregistrarea informațiilor despre furnizor o singură dată, într-un tabel separat denumit Furnizori, iar apoi legarea acelui tabel cu tabelul Produse, este o soluție mult mai bună.

A doua problemă a acestui proiect apare atunci când trebuie modificate informațiile despre furnizor. De exemplu, să presupunem că trebuie schimbată adresa unui furnizor. Deoarece apare în multe locuri, se poate, în mod accidental, să modificați adresa într-un loc și să uitați să o modificați în celelalte. Înregistrarea adresei furnizorului într-un singur loc rezolvă problema.

Când proiectați baza de date, încercați să înregistrați fiecare informație o singură dată. Dacă se repetă aceeași informație, cum ar fi adresa unui anumit furnizor, în mai multe locuri amplasați informația într-un tabel separat.

În final, să presupunem că există un singur produs furnizat de Coho Winery și că doriți să ștergeți produsul, dar să păstrați numele și informațiile furnizorului. Cum se poate șterge înregistrarea produsului fără a pierde informațiile despre furnizor? Este imposibil. Deoarece fiecare înregistrare conține date despre un produs, cât și despre un furnizor, este imposibil să se șteargă separat. Pentru a menține datele separate, trebuie împărțit tabelul în două tabele: unul pentru informații despre produse și celălalt pentru informații despre furnizori. Ștergerea înregistrării unui produs ar trebui să șteargă doar datele despre produs, nu și datele despre furnizor.

După ce alegeți subiectul reprezentat de un tabel, coloanele din acel tabel trebuie să stocheze numai datele despre acel subiect. De exemplu, tabelul pentru produse trebuie să stocheze numai date despre produse. Deoarece adresa unui furnizor este o informație despre furnizor, și nu una despre produs, aparține de tabelul pentru furnizori.

Începutul paginii Începutul paginii

Transformarea elementelor informaționale în coloane

Pentru a stabili coloanele dintr-un tabel, decideți asupra informațiilor necesare pentru subiectul înregistrat în tabel. De exemplu, pentru tabelul Clienți, Nume, Adresă, Oraș-CodPoștal, Abonat la mesaje de poștă electronică, Formulă introductivă și Adresă de poștă electronică reprezintă o listă de coloane bună, pentru început. Fiecare înregistrare a tabelului conține același set de coloane, așadar se pot stoca informațiile din câmpurile Nume, Adresă, Oraș-CodPoștal, Abonat la mesaje de poștă electronică, Formulă introductivă și Adresă de poștă electronică pentru fiecare înregistrare. De exemplu, coloana pentru adrese conține adresele clienților. Fiecare înregistrare conține date despre un client, iar câmpul pentru adresă conține adresa acelui client.

După ce stabiliți setul inițial de coloane pentru fiecare tabel, aveți posibilitatea să îmbunătățiți coloanele. De exemplu, este logic să se stocheze numele clienților în două coloane: prenume și nume de familie, pentru a fi posibilă sortarea, căutarea și indexarea pentru una singură dintre coloane. Similar, adresa este alcătuită din cinci componente separate, adresă, oraș, județ, cod poștal și țară/regiune, și este logic să se stocheze și acestea în coloane separate. Pentru a efectua o operațiune de căutare, filtrare sau sortare după județ, de exemplu, trebuie ca informațiile despre județ să se stocheze într-o coloană separată.

De asemenea, trebuie să se știe dacă informațiile conținute în baza de date au doar caracter intern sau și internațional. De exemplu, dacă planificați să stocați adrese internaționale, este mai bine să aveți o coloană Regiune în locul coloanei Județ, deoarece o astfel de coloană poate conține județe naționale sau alte țări/regiuni. Asemănător, codul poștal este mai bun decât codul Zip dacă stocați adrese internaționale.

Următoarea listă afișează câteva sfaturi pentru stabilirea coloanelor.

  • Nu includeți date calculate    

În cele mai multe cazuri, nu trebuie stocate rezultatele unor calcule în tabele. În schimb, Access poate efectua calculele atunci când doriți să vedeți rezultatele. De exemplu, să presupunem că există un raport Produse comandate care afișează subtotalul unităților comandate, pentru fiecare categorie de produse din baza de date. Cu toate acestea, nu există o coloană Subtotal Unități comandate în niciun tabel. În schimb, tabelul Produse include o coloană Unități comandate, care stochează unitățile comandate din fiecare produs. Utilizând aceste date, Access calculează subtotalul de fiecare dată când imprimați raportul. Subtotalul nu trebuie stocat într-un tabel.

  • Stocați cele mai mici părți logice din informații.    

Poate fi tentant să creați un singur câmp pentru nume complete, sau pentru numele produselor împreună cu descrierile produselor. Dacă se combină mai multe tipuri de informații într-un câmp, este dificil să se regăsească ulterior date individuale. Încercați să despărțiți informațiile în părți logice; de exemplu, creați câmpuri separate pentru prenume și pentru nume de familie, sau pentru numele produselor și pentru categorii și descrieri.

Lista elementelor cu informații în timpul procesului de proiectare

După îmbunătățirea coloanelor de date din fiecare tabel, se poate alege cheia primară a fiecărui tabel.

Începutul paginii Începutul paginii

Specificarea cheilor primare

Fiecare tabel ar trebui să includă o coloană sau un set de coloane care identifică, în mod unic, fiecare rând stocat în tabel. De obicei, se utilizează un număr unic de identificare, cum ar fi numărul de ID al unui angajat sau un număr de serie. În terminologia bazelor de date, aceste informații reprezintă cheia primară a tabelului. Access utilizează câmpuri de tipul cheie primară pentru a asocia rapid date din tabele multiple și a cumula datele.

Dacă aveți deja un identificator unic pentru un tabel, cum ar fi un număr de produs care identifică în mod unic fiecare produs din catalog, aveți posibilitatea să utilizați acel identificator ca și cheie primară a tabelului, dar numai dacă valorile din această coloană vor fi întotdeauna diferite pentru fiecare înregistrare. Nu pot exista valori duplicate într-o cheie primară. De exemplu, nu utilizați numele oamenilor pentru cheia primară, deoarece numele nu sunt unice. Este foarte posibil să existe doi oameni cu același nume în același tabel.

O cheie primară trebuie întotdeauna să aibă o valoare. Dacă este posibil ca valoarea unei coloane să devină neatribuită sau necunoscută (valoare lipsă) la un anumit moment, nu se poate utiliza ca și componentă într-o cheie primară.

Trebuie întotdeauna să alegeți o cheie primară a cărei valori nu se va schimba. Într-o bază de date care utilizează mai multe tabele, se poate utiliza cheia primară a unui tabel care referință în alte tabele. Dacă se schimbă cheia primară, modificarea trebuie aplicată oriunde se face referire la cheie. Utilizarea unei chei primară care nu se va modifica reduce șansele de a se desincroniza cheia primară cu tabelele care fac referință la ea.

Deseori, e utilizează ca și cheie primară un număr unic arbitrar. De exemplu, i se poate atribui fiecărei comenzi un număr unic de comandă. Singurul scop al numărului de comandă este identificarea unei comenzi. O dată atribuit, nu se schimbă niciodată.

Dacă nu aveți o coloană sau un set de coloane care se poate utiliza ca și cheie primară, luați în considerare utilizarea unei coloane care are tipul de date Numerotare automată. Când se utilizează tipul de date Numerotare automată, Access atribuie automat o valoare. Un astfel de identificator nu are date; nu conține informații care descriu rândul pe care îl reprezintă. Identificatorii fără date sunt ideali pentru rolul de cheie primară, deoarece nu se modifică. Este mai posibil ca o cheie primară care conține date despre un rând, de exemplu, un număr de telefon sau numele unui client, să se modifice, deoarece se poate modifica informația în sine.


Imagine care ilustrează tabelul de Produse cu câmp cheie primară.

Explicație 1 O coloană setată la tipul de date Numerotare automată este o cheie primară potrivită. Nu există două ID-uri identice pentru produse.

În unele cazuri, este de preferat să se utilizeze două sau mai multe câmpuri care împreună asigură cheia primară a unui tabel. De exemplu, un tabel Detalii Comenzi care stochează elemente de linie pentru comenzi ar folosi două coloane în cheia sa primară : ID Comandă și ID Produs. Când o cheie primară utilizează mai mult de o coloană, aceasta se mai numește și cheie compusă.

În cazul bazei de date pentru vânzări de produse, se poate crea o coloană de tipul Numerotare automată pentru fiecare dintre tabele, pentru a îndeplini rolul de cheie primară: IDProdus pentru tabelul Produse, IDComandă pentru tabelul Comenzi, IDClient pentru tabelul Clienți și IDFurnizor pentru tabelul Furnizori.

Imagine care afișează informațiile, în timpul procesului de proiectare

Începutul paginii Începutul paginii

Crearea relațiilor tabelelor

După ce ați împărțit informațiile în tabele, este nevoie de o asociere utilă a informațiilor. De exemplu, următorul formular include informații din mai multe tabele.


Formularul Comenzi

Explicație 1 Informațiile din acest formular provin din tabelul Clienți...
Explicație 2 …tabelul Angajați...
Explicație 3 …tabelul Comenzi...
Explicație 4 …tabelul Produse...
Explicație 5 …și tabelul Detalii Comandă.

Access este un sistem de gestionare a bazelor de date relaționale. Într-o bază de date relațională, informațiile se împart în tabele separate, bazate pe subiecte. Se pot utiliza relațiile dintre tabele pentru a asocia informațiile în moduri utile.

Începutul paginii Începutul paginii

Crearea unei relații de tipul unul-la-mai-mulți

Luați în considerare acest exemplu: tabelele Furnizori și Produse din baza de date pentru comenzi de produse. Un furnizor poate furniza oricâte produse. Așadar, pentru orice furnizor din tabelul Furnizori pot exista multe produse în tabelul Produse. Relația dintre tabelul Furnizori și tabelul Produse este, prin urmare, o relație de tipul unul-la-mai-mulți.

Conceptul relației de tipul unul la mai mulți

Pentru a reprezenta o relație de tipul unul-la-mai-mulți în proiectul bazei de date, luați cheia primară din partea "unu" a relației și adăugați-o ca o coloană suplimentară la tabelul din partea "mai-mulți" a relației. În acest caz, de exemplu, se adaugă coloana ID furnizor, din tabelul Furnizori, la tabelul Produse. Access poate utiliza numărul de ID al furnizorului în tabelul Produse pentru a găsi furnizorul potrivit pentru fiecare produs.

Coloana ID furnizor din tabelul Produse se numește cheie externă. O cheie externă este cheia primară a unui alt tabel. Coloana ID furnizor din tabelul Produse este o cheie externă, deoarece este și cheia primară a tabelului Furnizori.

Lista elementelor cu informații în timpul procesului de proiectare

Furnizați baza pentru a uni tabelele legate prin stabilirea perechilor de chei primare și chei externe. Dacă nu sunteți sigur care tabele ar trebui să partajeze o coloană comună, identificarea unei relații unu-la-mai-mulți va asigura necesitatea unei coloane partajate între cele două tabele implicate.

Începutul paginii Începutul paginii

Crearea unei relații mai-mulți-la-mai-mulți

Luați în considerare relația dintre tabelul Produse și tabelul Comenzi.

O comandă poate include mai multe produse. Pe de altă parte, un produs poate apărea în mai multe comenzi. De aceea, pentru fiecare înregistrare din tabelul Comenzi, pot exista mai multe înregistrări în tabelul Produse. Și pentru fiecare înregistrare din tabelul Produse, pot exista mai multe înregistrări în tabelul Comenzi. Această relație este de tipul mai-mulți-la-mai-mulți, deoarece pentru orice produs pot exista mai multe comenzi; și pentru orice comandă pot exista mai multe produse. Rețineți faptul că pentru a detecta relațiile de tipul mai-mulți-la-mai-mulți dintre tabele, este important să luați în considerare ambele sensuri ale relației.

Subiectele celor două tabele — comenzi și produse — se află într-o relație mai-mulți-la-mai-mulți. Acest lucru prezintă o problemă. Pentru a înțelege problema, imaginați-vă ce s-ar întâmpla dacă ați încerca să creați o relație între două tabele adăugând câmpul ID produs la tabelul Comenzi. Pentru a avea mai mult de un produs pentru fiecare comandă, aveți nevoie de mai mult de o înregistrare pentru fiecare comandă în tabelul Comenzi. S-ar repeta informațiile despre comandă pentru fiecare rând asociat cu o comandă  — rezultând o proiectare ineficientă care poate produce date exacte. Aceeași problemă apare dacă se adaugă câmpul ID comandă la tabelul Produse — rezultă mai multe înregistrări în tabelul Produse pentru fiecare produs. Cum se rezolvă această problemă?

Răspunsul este crearea celui de-al treilea tabel, numit adesea tabel de joncțiune, care separă relația mai-mulți-la-mai-mulți în două relații unu-la-mai-mulți. Inserați cheia primară a fiecăruia dintre cele două tabele în al treilea tabel. Ca rezultat, al treilea tabel înregistrează fiecare apariție sau instanță a relației.

O relație mai-mulți-la-mai-mulți

Fiecare înregistrare din tabelul Detalii comandă reprezintă un element linie într-o comandă. Cheia primară a tabelului Detalii comandă constă în două câmpuri — cheile externe ale tabelelor Comenzi și Produse. Utilizarea câmpului ID comandă singur nu funcționează ca o cheie primară pentru acest tabel, deoarece o comandă poate avea mai multe elemente linie. ID comandă se repetă pentru fiecare element linie dintr-o comandă, astfel încât câmpul nu conține valori unice. Nici utilizarea câmpului ID produs singur nu funcționează, deoarece un produs poate apărea în mai multe comenzi diferite. Dar, împreună, cele două câmpuri produc întotdeauna o valoare unică pentru fiecare înregistrare.

În baza de date pentru vânzări de produse, tabelele Comenzi și Produse nu sunt asociate direct. În schimb, ele sunt asociate indirect prin tabelul Detalii comandă. Relația mai-mulți-la-mai-mulți între comenzi și produse se reprezintă în baza de date utilizând două relații unu-la-mai-mulți:

  • Între tabelele Comenzi și Detalii comandă există o relație unu-la-mai-mulți. Fiecare comandă are mai mult de un element line, dar fiecare element linie este conectat cu o singură comandă.
  • Între tabelele Produse și Detalii comandă există o relație unu-la-mai-mulți. Fiecare produs poate avea mai multe elemente linie asociate, dar fiecare element linie face referire la un singur produs.

Din tabelul Detalii comandă, se pot determina toate produsele dintr-o anumită comandă. De asemenea, se pot determina toate comenzile pentru un anumit produs.

După incorporarea tabelului Detalii comandă, lista tabelelor și câmpurilor poate arăta cam așa:

Lista elementelor cu informații în timpul procesului de proiectare

Începutul paginii Începutul paginii

Crearea unei relații de tipul unu-la-unu

Un alt tip de relație este relația unu-la-unu. De exemplu, să presupunem că trebuie înregistrate câteva informații speciale despre produse suplimentare, de care veți avea nevoie rar sau care se aplică numai câtorva produse. Deoarece veți avea nevoie rar de aceste informații și stocarea informațiilor în tabelul Produse ar produce spații libere pentru fiecare produs la care acestea nu se aplică, amplasați-le într-un tabel separat. Ca și tabelul Produse, ID produs se utilizează cu rolul de cheie primară. Relația dintre acest tabel suplimentar și tabelul Produs este o relație de tipul unu-la-unu. Pentru fiecare înregistrare din tabelul Produs, există o singură înregistrare care se potrivește în tabelul suplimentar. Când identificați o astfel de relație, ambele tabele trebuie să partajeze un câmp comun.

Când observați necesitatea unei relații unu-la-unu în baza de date, gândiți-vă dacă se pot pune informațiile din cele două tabele împreună într-un singur tabel. Dacă, dintr-un anumit motiv, nu doriți să faceți acest lucru, poate pentru că ar rezulta multe spații libere, lista următoare vă arată cum se reprezintă relația în proiectare:

  • Dacă cele două tabele au același subiect, probabil se poate configura relația utilizând aceeași cheie primară în ambele tabele.
  • Dacă cele două tabele au subiecte diferite, cu chei primare diferite, alegeți unul din tabele (oricare) și inserați cheia sa primară în celălalt tabel pe post de cheie externă.

Determinarea relațiilor dintre tabele vă ajută să vă asigurați că aveți tabelele și coloanele corecte. Când există o relație unu-la-unu sau unu-la-mai-mulți, tabelele implicate trebuie să partajeze o coloană sau mai multe coloane comune. Când există o relație mai-mulți-la-mai-mulți, este necesar un al treilea tabel pentru a reprezenta relația.

Începutul paginii Începutul paginii

Rafinarea proiectării

Din momentul în care aveți tabelele, câmpurile și relațiile de care aveți nevoie, trebuie să creați și să populați tabelele cu date eșantion și să încercați să lucrați cu informațiile: creând interogări, adăugând înregistrări noi și așa mai departe. Acest lucru ajută la evidențierea problemelor potențiale — de exemplu, este posibil să aveți nevoie să adăugați o coloană pe care ați uitat să o inserați în timpul fazei de proiectare, sau este posibil să aveți un tabel care să trebuiască separat în două tabele pentru a elimina duplicarea.

Vedeți dacă se poate utiliza baza de date pentru a obține răspunsurile dorite. Creați schițe neprelucrate ale formularelor și rapoartelor, și vedeți dacă vă arată datele pe care le așteptați. Căutați dubluri inutile de date și, dacă le găsiți, modificați proiectarea pentru a le elimina.

Pe măsură ce testați baza de date inițială, probabil veți descoperi că se pot face îmbunătățiri. Câteva lucruri care trebuie verificate:

  • Ați uitat vreo coloană? Dacă da, apar informațiile în tabelele existente? Dacă informațiile sunt despre altceva, este posibil să fie nevoie să creați un alt tabel. Creați o coloană pentru fiecare element informațional care trebuie urmărit. Dacă informațiile nu se poate calcula de pe o altă coloană, probabil aveți nevoie de o coloană nouă pentru asta.
  • Sunt inutile unele coloane, pentru că se pot calcula din câmpuri deja existente? Dacă un element informațional se poate calcula dintr-o altă coloana deja existentă — ca, de exemplu, prețul redus calculat din prețul de vânzare — este mai bine, în general, să se procedeze așa și să se evite crearea unei coloane noi.
  • Introduceți în mod repetat informații dublate în unul din tabele? Dacă da, probabil că trebuie împărțit tabelul în două tabele între care să existe o relație de tipul unu-la-mai-mulți.
  • Aveți tabele cu multe câmpuri, un număr limitat de înregistrări și multe câmpuri goale în înregistrările individuale? Dacă da, gândiți-vă la reproiectarea tabelului astfel încât să aibă mai puține câmpuri și mai multe înregistrări.
  • A fost împărțit fiecare element informațional în cele mai mici părți utile? Dacă trebuie efectuate operații de raportare, sortare, căutare sau calculare pentru un element informațional, puneți acel element în propria sa coloană.
  • Conține fiecare coloană date despre subiectul tabelului? Dacă o coloană nu conține informații despre subiectul tabelului, aceasta aparține unui alt tabel.
  • Sunt toate relațiile dintre tabele reprezentate prin câmpuri comune sau printr-un al treilea tabel? Relațiile unu-la-unu și unu-la-mai-mulți necesită coloane comune. Relațiile mai-mulți-la-mai-mulți necesită un al treilea tabel.

Rafinarea tabelului Produse

Să presupunem că fiecare produs din baza de date vânzări intră într-o categorie generală, cum ar fi băuturi, condimente, sau fructe de mare. Tabelul Produse poate conține un câmp care arată categoria fiecărui produs.

Să presupunem că, după examinarea și redefinirea proiectului bazei de date, decideți să stocați o descriere a categoriei alături de numele acesteia. Dacă adăugați un câmp Descriere categorie la tabelul Produse, trebuie repetată descrierea fiecărei categorii pentru fiecare produs care intră in acea categorie — iar aceasta nu este o soluție bună.

O soluție mai bună ar fi să faceți Categorii un subiect nou de urmărit pentru baza de date, cu propriul tabel și propria cheie primară. Se poate adăuga cheia primară de la tabelul Categorii la tabelul Produse, cu rol de cheie externă.

Între tabelele Categorii și Produse există o relație unu-la-mai-mulți: o categorie poate include mai mult de un produs, dar un produs poate aparține numai unei categorii.

Când revizualizați structurile tabelului, căutați grupuri repetitive. De exemplu, luați în considerare un tabel care conține următoarele coloane:

  • ID produs
  • Nume
  • ID produs1
  • Nume1
  • ID produs2
  • Nume2
  • ID produs3
  • Nume3

În acest caz, fiecare produs este un grup repetitiv de coloane, care diferă numai prin adăugarea unui număr la sfârșitul numelui coloanei. Când vedeți coloanele numerotate astfel, ar trebui să reanalizați proiectarea.

Un astfel de proiect are mai multe defecte. Pentru început, vă obligă să stabiliți o limită superioară pentru numărul produselor. După ce se depășește această limită, trebuie adăugat un grup de coloane nou la structura tabelului, ceea ce reprezintă o activitate administrativă majoră.

O altă problemă este faptul că furnizorii care au mai puțin decât numărul maxim de produse vor irosi spațiu, din moment ce coloanele suplimentare vor fi goale. Cel mai serios defect al unui astfel de proiect este faptul că efectuarea multor activități, cum ar fi sortarea sau indexarea unui tabel după ID-urile sau numele produselor, devine dificilă.

Oricând vedeți un grup repetitiv, reanalizați cu atenție proiectarea, în ideea de a împărți tabelul în două. În exemplul de mai sus, este mai bine să utilizați două tabele, unul pentru furnizori și unul pentru produse, legate prin ID furnizor.

Începutul paginii Începutul paginii

Aplicarea regulilor de normalizare

Regulile de normalizare a datelor (denumite uneori reguli de normalizare) pot fi aplicate ca un pas din cadrul proiectării. Aceste reguli se utilizează pentru a verifica dacă tabelele sunt structurate corect. Procesul aplicării regulilor la proiectarea bazei de date este denumit normalizarea bazei de date, sau doar normalizare.

Normalizarea este foarte utilă dacă ați determinat toate elementele informaționale și ați creat un proiect preliminar. Scopul este să vă asigurați că ați împărțit elementele informaționale în tabelele corespunzătoare. Normalizarea nu vă poate ajuta să vă asigurați că aveți de la început toate elementele de date corecte.

Regulile se aplică succesiv, asigurându-vă la fiecare pas că proiectul va ajunge la ceea ce se numește o „formă normală”. În principiu, sunt acceptate cinci forme normale: de la prima formă normală până la a cincea. Acest articol le acoperă pe primele trei, deoarece acestea sunt necesare pentru majoritatea proiectelor de baze de date.

Prima formă normală

Prima formă normală presupune că există o singură valoare la fiecare intersecție dintre un rând și o coloană din tabel, și niciodată o listă de valori. De exemplu, nu poate exista un câmp denumit Preț în care să plasați mai multe prețuri. Dacă priviți intersecția dintre un rând și o coloană ca pe o celulă, atunci fiecare celulă poate conține o singură valoare.

A doua formă normală

A doua formă normală necesită ca fiecare coloană care nu este cheie să depindă complet de cheia primară, nu doar de o parte a cheii. Această regulă se aplică când se utilizează o cheie primară care conține mai multe coloane. De exemplu, să presupunem că aveți un tabel care conține următoarele coloane, dintre care ID comandă și ID produs alcătuiesc cheia primară:

  • ID comandă (cheie primară)
  • ID produs (cheie primară)
  • Nume produs

Acest proiect încalcă a doua formă normală, deoarece Nume produs depinde de ID produs, dar nu și de ID comandă, așadar nu depinde de întreaga cheie primară. Nume produs trebuie eliminat din tabel. Aparține de alt tabel (Produse).

A treia formă normală

A treia formă normală necesită ca fiecare coloană care nu este cheie să depindă de întreaga cheie primară, dar și ca toate coloanele care nu sunt chei să fie reciproc independente.

Un alt mod de a spune aste este că fiecare coloană care nu este cheie trebuie să depindă de întreaga cheie primară și numai de cheia primară. De exemplu, să presupunem că aveți un tabel care conține următoarele coloane:

  • ID produs (cheie primară)
  • Nume
  • PSV
  • Reducere

Să presupunem că Reducere depinde de prețul sugerat de vânzare (PSV). Acest tabel încalcă a treia formă normală, deoarece o coloană care nu este cheie, Reducere, depinde de altă coloană care nu este cheie, PSV. Independența coloanelor înseamnă că se poate modifica orice coloană care nu este cheie fără a afecta alte coloane. Dacă se modifică o valoare din câmpul SRP, se modifică în mod corespunzător Reducere, așadar încălcându-se regula. În acest caz, Reducere trebuie mutat în alt tabel pentru care PRV este cheie.

Începutul paginii Începutul paginii

 
 
Se aplică la:
Access 2010