Notiune de baza de date.

Printre multiplele forme de organizare a datelor, bazele de date ocupa un loc aparte.

O baza de date (BD) reprezinta o colectie de date integrata, anume structurata si dotata cu o descriere a structurii si a relatiilor dintre date.Īn functie de modul de organizare a informatiilor, se cunosc cīteva modele de BD:ierarhic (arborescent), retea, relational s.a.

Gestiunea bazelor de date.

Sistemul de gestiune a bazelor de date (SGBD) este acel sistem de programe care faciliteaza si supervizeaza introducerea de informatii īn baza de date, actualizarea si extragera din baza, controlul si autorizarea accesului la date. Un sistem de gestiune a bazelor de date trebuie sa fie capabil sa īndeplineasca urmatoarele functii:

de descriere ,care rezida īn definirea structuriidatelor, a relatiilor dintre acestea si a conditilor de acces la informatile continute īn baza de date;

de actualizare, care presupune inserarea, redactarea si suprimarea datelor;

de interogare a BD, care permite obtinere 616p152g a diferitor informatii din BD conform unor criterii de cautare;

de obtinere de date noi, care consta īn prelucrarea informatiei initiale īn scopul obtinerii unor totaluri, medii etc.;

de īntretinere, care consta īn crearea copiilor de rezerva, compactarea BD si repararea ei īn cazul deteriorarii;

de securitate a datelor, care rezida īn protejarea BD īmpotriva accesului neautorizat si īn atribuirea drepturilor de acces.

Lansarea sistemului MS Access 2007

Exista mai multe modalitati de lansare a sistemului Access, una din ele fiind executarea consecutiva a actiunilor Start/All Programs(sau Programs)/Microsoft Office/Microsoft Office Access 2007.

Ca rezultat, obtinem o fereastra, asemanatoare cu cea din figura 1.

Figura 1. Lansarea sistemului Access

Crearea / accesarea unei baze de date

Dupa cum am mai mentionat, elementele principale ale unei baze de date sunt tabelele. Dar o baza de date poate contine si alte elemente care se creeaza pe baza tabelelor (interogari, formulare, rapoarte etc.). Aceste elemente, īmpreuna cu tabelele, formeaza asa-numitele clase de obiecte ale bazei de date.

Pentru a crea o baza de date noua, dam click pe butonul Microsoft Office , apoi faceti clic pe New.

Īn caseta File Name, tasta i un nume de fi ier. Pentru a modifica loca ia, face i clic pe pictograma folderului pentru a rasfoi.

Face i clic pe Create.

Pentru a deschide o baza de date existenta īn zona butonul Microsoft Office a ferestrei reprezentate īn figura 1 executam un clic pe Open. Īn caseta de dialog care apare indicam numele BD (de ex., BIBL) si localizarea ei (discul, dosarul).Obtinem fereastra urmatoare(figura 2):

Figura. 2 Fereastra Access

O baza de date proiectata corespunzator furnizeaza acces la informatii precise, actualizate. Microsoft Office Access 2007 organizeaza informatiile īn tabele: liste de rānduri si coloane ce amintesc de registrul unui contabil sau de o foaie de lucru din Microsoft Office Excel 2007. Īntr-o baza de date simpla, se poate sa aveti doar un singur tabel. Pentru cele mai multe baze de date va trebui sa aveti mai multe. De exemplu, se poate sa aveti un tabel care stocheaza informatii despre produse, alt tabel care stocheaza informatii despre comenzi si un altul cu informatii referitoare la clienti.

Fiecare rānd se mai numeste īnregistrare si fiecare coloana, de asemenea, se mai numeste cāmp. O īnregistrare este o modalitate semnificativa si consistenta de a combina anumite informatii. Un cāmp este un element singular de informatie - un tip de element care apare īn orice īnregistrare. De exemplu, īn tabelul produse, fiecare rānd sau īnregistrare ar contine informatii despre un produs. Fiecare coloana sau cāmp contine un anumit tip de informatie despre acest produs, cum ar fi numele sau pretul.

Proiectarea unei baze de date

Anumite principii ghideaza procesul de proiectare al unei baze de date. Primul principiu este acela ca informatiile dublura (numite si date redundante) au o influenta negativa, deoarece consuma spatiu si sporesc probabilitatea producerii de erori si inconsistente. Al doilea principiu īl reprezinta importanta corectitudinii si caracterului complet al informatiilor. Daca baza de date contine informatii incorecte, orice rapoarte care extrag informatii din baza de date vor contine, de asemenea, informatii incorecte. Drept urmare, orice decizie luata bazāndu-va pe aceste rapoarte va fi gresit informata.

O proiectare buna a unei baze de date este, dupa cum urmeaza, una care:

Īmparte informatiile īn tabele pe baza subiectelor, pentru a reduce datele redundante.

Furnizeaza programului Access informatiile necesare pentru a asocia informatiile din tabele dupa necesitati.

Asista si asigura acuratetea si integritatea informatiilor.

Adapteaza necesitatile de procesare a datelor si cele de raportare.

Procesul de proiectare consta īn urmatorii pasi:

Determinarea scopului bazei de date

Acesta ajuta la pregatirea pasilor ramasi.

Gasirea si organizarea informatiilor necesare

Adunarea tuturor tipurilor de informatii pe care le īnregistrati īn baza de date, cum ar fi numele produsului si numarul comenzii.

Īmpartirea informatiilor īn tabele

Īmpartirea elementelor de informatii īn entitati sau subiecte majore cum ar fi Produse sau Comenzi. Apoi, fiecare subiect devine un tabel.

Transformarea elementelor de informatii īn coloane

Decideti ce informatii sa stocati īn fiecare tabel. Fiecare element devine un cāmp care este afisat sub forma de coloana īn tabel. De exemplu, un tabel Angajati poate include cāmpuri, cum ar fi Nume de familie si Data angajarii.

Specificarea cheilor primare

Alegeti cheia primara pentru fiecare tabel. Cheia primara este o coloana care se utilizeaza pentru a identifica īn mod unic fiecare rānd. Un exemplu poate fi ID produs sau ID comanda.

Configurarea relatiilor din tabel

Priviti fiecare tabel si decideti cum se asociaza datele dintr-un tabel cu datele din alte tabele. Adaugati cāmpuri la tabele sau creati noi tabele pentru a clarifica relatiile, dupa necesitati.

Determinarea scopului bazei de date

Pentru o baza de date mica pentru o afacere de familie, de exemplu, se poate nota ceva simplu, cum ar fi "Baza de date a clientilor pastreaza o lista a informatiilor despre clienti īn scopul producerii de liste de corespondenta si de rapoarte." Daca baza de date este mai complexa sau este utilizata de mai multe persoane, cum se īntāmpla de obicei īntr-o conjunctura corporativa, scopul se poate īntinde pe mai multe paragrafe si trebuie sa includa cānd si de catre cine va fi utilizata baza de date. Ideea principala este sa se descrie riguros misiunea bazei de date, care sa fie consultata īn cadrul procesului de proiectare. O astfel de instructiune va ajuta sa va concentrati asupra obiectivelor atunci cānd luati decizii.

Nu includeti date calculate

Īn cele mai multe cazuri, nu trebuie stocate rezultatele unor calcule īn tabele. Īn schimb, Access poate efectua calculele atunci cānd doriti sa vedeti rezultatele. De exemplu, sa presupunem ca exista un raport Produse comandate care afiseaza subtotalul unitatilor comandate, pentru fiecare categorie de produse din baza de date. Cu toate acestea, nu exista o coloana Subtotal Unitati comandate īn niciun tabel. Īn schimb, tabelul Produse include o coloana Unitati comandate, care stocheaza unitatile comandate din fiecare produs. Utilizānd aceste date, Access calculeaza subtotalul de fiecare data cānd imprimati raportul. Subtotalul nu trebuie stocat īntr-un tabel.

CREAREA UNUI TABEL

Un tabel con ine date despre un anumit subiect, cum ar fi clien ii sau produsele. Fiecare īnregistrare dintr-un tabel con ine informa ii despre un element, cum ar fi un anumit angajat. O īnregistrare este compusa din cāmpuri, cum ar fi numele, adresa i numarul de telefon. O īnregistrare este denumita īn mod obi nuit rānd, iar un cāmp este denumit coloana.

 Īnregistrare sau rānd

       Cāmp sau coloana

Baza dvs. de date poate con ine mai multe tabele, fiecare cu informa ii referitoare la anumit subiect. Fiecare tabel poate con ine mai multe cāmpuri de diferite tipuri, inclusiv text, numere, date i imagini. Urmatoarea lista afi eaza exemple obi nuite de tabele:

Un tabel client care listeaza clien ii firmei i adresele lor

un catalog de produse pe care le vinde i, inclusiv pre urile i imaginile pentru fiecare element

Un tabel de activita i care urmare te activita ile i datele scadente

Un inventar de echipament sau stoc disponibil

Crearea unui tabel nou īntr-o baza de date noua

Faceti clic pe butonul Microsoft Office , apoi faceti clic pe Nou.

Īn caseta Nume fi ier, tasta i un nume de fi ier. Pentru a modifica loca ia, face i clic pe pictograma folderului pentru a rasfoi.

Face i clic pe Creare.

Se deschide baza noua de date, apoi se creeaza i se deschide un tabel nou denumit Tabel1 īn vizualizarea Datasheet View.

Crearea unui tabel nou īntr-o baza de date existenta

Faceti clic pe butonul Microsoft Office , apoi faceti clic pe Open.

Īn caseta de dialog Open, selecta i i deschide i baza de date.

Īn fila Create, īn grupul Tabele, faceti clic pe Tabel.

Se insereaza un tabel nou īn baza de date i se deschide īn vizualizarea Foii de date (Figura 3).

Figura3 Vizualizarea foii de date

Pentru a stabili campurile tabelului si proprietatile acestora se deschide tabelul in modul Design View(butonul View din figura de mai sus). In modul Design View se vor introduce pe rand cimpurile tabelului si apoi proprietatile acestora (Figura 4).

Figura 4 Modul Design View

Caracteristicile cīmpurilor

Pentru fiecare cīmp al tabelului se specifica 3 caracteristici, si anume:

Field Name (denumirea cīmpului, obligatoriu);

Data Type (tipul cīmpului, obligatoriu);

Description (descrierea cīmpului, optional).

Regimul Design View nu permite introducerea īnregistrarilor īn tabel, ci doar descrierea cīmpurilor care alcatuiesc tabelul.

Denumirea cīmpului poate contine diferite caractere, inclusiv spatii, cu exceptia unor semne speciale ( ".", "!" s.a.). Īn caz de necesitate, denumirea poate contine semnul " " (subliniere). Lungimea denumirii cīmpului (īmpreuna cu spatiile) nu poate depasi 64 de caractere.

Exemple: autorul;Id_ tarii; locul de_ munca; LoculDeMunca; Locul de Munca.

Tipul cīmpului poate fi unul din urmatoarele:

Text - pentru texte sau numere care nu vor fi folosite īn calcule;

Memo - pentru texte lungi (biografia autorului, rezumatul cartii etc.).

Number - pentru numere care vor fi folosite īn calcule;

Date/Time - pentru date calendaristice;

Currency - pentru valori banesti;

AutoNumber - pentru numere īntregi care īsi maresc īn mod automat valorile (numarul de ordine, de exemplu);

Yes/No - pentru valori logice care pot lua numai doua valori: Yes (adevar), No (fals);

OLE Object - pentru imagini (fotografia autorului), sunete (imnul tarii).

Hyperlink - pentru adrese Hyperlink. Valorile acestui cīmp pot fi adrese Internet (de exemplu, www.google.com) sau locatii (calea spre un fisier
sau dosar din calculator)

Lookup Wizard - reprezinta, de fapt, nu un tip de date, ci o proprietate a cīmpului prin care valorile lui pot fi selectate din alt tabel. Acest mod de abordare simplifica procedura introducerii valorilor cīmpului si, īn plus reduce riscul comiterii unor erori.

Pentru a schimba tipul cīmpului (implicit tipul este Text), trecem īn coloana Data Type (fig.4) si din lista derulanta alegem tipul dorit. Apoi trecem (daca e cazul) īn coloana Description, pentru a introduce note explicative, sau īn rīndul urmator, pentru descrierea altui cīmp.

Stabilirea cheilor primare

Fiecare tabel ar trebui sa includa o coloana sau un set de coloane care identifica, īn mod unic, fiecare rānd stocat īn tabel. De obicei, se utilizeaza un numar unic de identificare, cum ar fi numarul de ID al unui angajat sau un numar de serie. Īn terminologia bazelor de date, aceste informatii reprezinta cheia primara a tabelului. Access utilizeaza cāmpuri de tipul cheie primara pentru a asocia rapid date din tabele multiple si a cumula datele.

Daca aveti deja un identificator unic pentru un tabel, cum ar fi un numar de produs care identifica īn mod unic fiecare produs din catalog, aveti posibilitatea sa utilizati acel identificator ca si cheie primara a tabelului - dar numai daca valorile din aceasta coloana vor fi īntotdeauna diferite pentru fiecare īnregistrare. Nu pot exista valori duplicate īntr-o cheie primara. De exemplu, nu utilizati numele oamenilor pentru cheia primara, deoarece numele nu sunt unice. Este foarte posibil sa existe doi oameni cu acelasi nume īn acelasi tabel.

O cheie primara trebuie īntotdeauna sa aiba o valoare. Daca este posibil ca valoarea unei coloane sa devina neatribuita sau necunoscuta (valoare lipsa) la un anumit moment, nu se poate utiliza ca si componenta īntr-o cheie primara.

Trebuie īntotdeauna sa alegeti o cheie primara a carei valori nu se va schimba. Īntr-o baza de date care utilizeaza mai multe tabele, se poate utiliza cheia primara a unui tabel care referinta īn alte tabele. Daca se schimba cheia primara, modificarea trebuie aplicata oriunde se face referire la cheie. Utilizarea unei chei primara care nu se va modifica reduce sansele de a se desincroniza cheia primara cu tabelele care fac referinta la ea.

Deseori, e utilizeaza ca si cheie primara un numar unic arbitrar. De exemplu, i se poate atribui fiecarei comenzi un numar unic de comanda. Singurul scop al numarului de comanda este identificarea unei comenzi. O data atribuit, nu se schimba niciodata.

Daca nu aveti o coloana sau un set de coloane care se poate utiliza ca si cheie primara, luati īn considerare utilizarea unei coloane care are tipul de date AutoNumerotare. Cānd se utilizeaza tipul de date AutoNumerotare, Access atribuie automat o valoare. Un astfel de identificator nu are date; nu contine informatii care descriu rāndul pe care īl reprezinta. Identificatorii fara date sunt ideali pentru rolul de cheie primara, deoarece nu se modifica.

 O coloana setata la tipul de date AutoNumerotare este o cheie primara potrivita. Nu exista doua ID-uri identice pentru produse.

Īn unele cazuri, este de preferat sa se utilizeze doua sau mai multe cāmpuri care īmpreuna asigura cheia primara a unui tabel. De exemplu, un tabel Detalii Comenzi care stocheaza elemente de linie pentru comenzi ar folosi doua coloane īn cheia sa primara : ID Comanda si ID Produs. Cānd o cheie primara utilizeaza mai mult de o coloana, aceasta se mai numeste si cheie compusa.

Īn cazul bazei de date pentru vānzari de produse, se poate crea o coloana de tipul AutoNumerotare pentru fiecare dintre tabele, pentru a īndeplini rolul de cheie primara: IDProdus pentru tabelul Produse, IDComanda pentru tabelul Comenzi, IDClient pentru tabelul Clienti si IDFurnizor pentru tabelul Furnizori.

Pentru a stabili cheia primara, selectam cīmpul respectiv, apoi executam un clic pe butonul din bara cu instrumente. Ca rezultat, īn partea din stīnga a cīmpului respectiv apare semnul cheii (vezi fig. ).

Dupa īncheierea procedurii de descriere a cīmpurilor si de stabilire a cheii primare, salvam tabelu. Daca nu am stabilit o cheie primara (acest lucru nu este obligatoriu), sistemul ne va avertiza, sugerīndu-ne stabilirea cheii pe un cīmp de tip AutoNumber. Pentru a confirma, actionam butonul Yes. n acest caz sistemul stabileste automat cheia primara pe un cīmp AutoNumber (daca el exista) sau creeaza suplimentar un asemenea cīmp (daca el nu exista), stabilind pe el cheia primara. Pentru a renunta la stabilirea cheii primare, actionam butonul No.

Proprietatile cīmpurilor

Īn afara de tipul cīmpului, putem stabili si unele proprietati ale sale, cum ar fi marimea (lungimea), numarul cifrelor zecimale, formatul datei calendaristice etc. Fiecare tip de date are proprietati prestabilite, dar ele pot fi modificate, executīnd un clic pe cīmpul respectiv (fig. , partea de sus) si modificīnd valorile prestabilite care apar īn partea de jos.

Cīmpurile de tip Text pot avea lungimi cuprinse īntre l si 255 de caractere. Implicit, marimea cīmpului este de 50, dar ea poate fi modificata īn limitele amintite, īn functie de lungimea maxima preconizata a valorilor cīmpului respectiv. Astfel, pentru Id client (identificatorul clientului), modificam marimea cīmpului din 50 (valoarea prestabilita) īn 8 (valoarea necesara). La fel procedam si cu caracteristicile altor cīmpuri.

Mentionam si cu aceasta ocazie, ca pentru cīmpurile ce contin numai valori numerice (identificatori numerici), care nu vor fi folosite īn calcule, vom prefera tipul Text īn locul tipului Number. Acest mod de abordare va facilita ulterior cautarea informatiei īn baza de date.

Cīmpurile de tip Number au lungimi diferite īn functie de optiunea specificata pentru proprietatea Field Size.

Optiunea implicita pentru cīmpurile de tip Number este, de regula, Single, dar ea poate fi modificata, utilizīnd comanda Options din meniul Tools. Pentru cīmpurile de tip Number poate fi stabilita si proprietatea Format, īn care specificam modul de afisare a valorilor (numarul cifrelor zecimale etc.).

Cīmpurile de tip Date/Time au lungimi variabile īn functie de formatul datei/orei specificat pentru proprietatea Format a cīmpului.

Cīmpurile de tip logic (Yes/No) ocupa īn memoria calculatorului un octet si pot fi reprezentate īn 4 moduri, īn functie de optiunea specificata pentru proprietatea Format a acestui cīmp, si anume: Yes/No, True/False, On/Off, -1/0. Īn ultimul caz valoarea - l corespunde starii True (adevar), iar valoarea 0 - starii False (fals).

Specificarea valorilor prestabilite

Daca o buna parte din valorile unui cīmp se repeta frecvent (de exemplu, īn cazul cīnd orasul este acelasi), putem specifica o valoare prestabilita (implicita) a cīmpului respectiv. Valoarea prestabilita (īn cazul nostru "Timisoara") se specifica pentru proprietatea Default Value a cīmpului. In procesul introducerii datelor sistemul atribuie cīmpului valoarea prestabilita īn mod automat, utilizatorul urmīnd sa modifice doar valorile care difera de cea prestabilita.

Valoarea prestabilita pentru campurile de tip data calendaristica face referire la data curenta. In acest caz pentru proprietatea Default Value a cīmpului de tip data calendaristica se introduce Date()

Stabilirea unor conditii de validare

Pentru a diminua riscul introducerii unor valori gresite, putem stabili conditii (reguli) de validare pentru valorile cīmpurilor respective. Regulile de validare se stabilesc pentru proprietatea Validation Rule a cīmpului. Totodata, pentru proprietatea Validation Text se specifica mesajul care trebuie sa fie afisat īn cazul nerespectarii regulii. Astfel, daca se stie ca pretul produselor nu depaseste valoarea 20000, specificam pentru proprietatea Validation Rule a cīmpului Pret conditia <=20000, iar pentru proprietatea Validation Text -mesajul "Pretul produsului nu poate fi mai mare de 200 de lei. Reintroduceti pretul cartii." La fel, data comenzii nu poate depasi data curenta, astfel ca pentru cīmpurile Data comanda putem stabili conditia <=Date() pentru proprietatea Validation Rule. Mesajul specificat pentru proprietatea Validation Text va fi si el adecvat. In fiecare din situatiile descrise vor fi afisate mesajele respective īn cazul introducerii unor valori care nu corespund conditiilor de validare stabilite īn procesul definirii cīmpurilor.

Modificarea descrierii unui tabel

Īn cazul cīnd apare necesitatea modificarii descrierii initiale a unui tabel (adaugarea sau excluderea unuia sau mai multor campuri, schimbarea ordinii, modificarea unor caracteristici etc), deschidem tabelul respectiv īn regimul Design View si efectuam modificarile necesare .

Introducerea datelor īn tabel

Dupa ce am efectuat procedurile de descriere a tabelului , putem introduce date īn cīmpurile lui. Pentru a initia procesul de introducere a datelor , deschidem BD (daca nu este deschisa) , apoi īn fereastra Database (fig.4) selectam tabelul necesar (de exemplu Clienti). Ca rezultat, se afiseaza cīmpurile tabelului respectiv fig.7(initial tabelul contine doar un rīnd liber).

fig.7 Introducerea si modificarea datelor īn tabel

Nu este absolut obligatoriu sa completam toate cīmpurile; astfel daca anumite date nu sīnt deocamdata cunoscute, introducerea lor poate fi amīnata.

Exceptie fac cīmpurile pentru care au fost stabilite chei primare. Aceste cīmpuri nu pot avea valori nule, de aceea valorile lor trebuie introduse īn mod obligatoriu. Ordinea introducerii datelor poate fi si ea oricare. Daca a fost stabilita o cheie primara , la o noua deschidere a tabelului īnregistrarile vor fi afisate īn ordinea crescatoare a valorilor cīmpului respectiv. Datorita acestui fapt, orice īnregistrare noua se adauga la sfīrsitul tabelului, avīnd certitudinea ca ulterior ea va fi plasata īn locul corespunzator. Dupa terminarea introducerii datelor īnchidem tabelul, actionīnd butonul sau executīnd comanda Close din meniul File (modificarile efectuate se salveaza automat).

Remarca: Tipul si caracteristicile datelor introduse trebuie sa corespunda īntocmai tipului si caracteristicilor cīmpurilor respective definite īn procesul crearii (descrierii) tabelului.

Redactarea datelor

Daca apare necesitatea modificarii (editarii) īnregistrarilor unui tabel, deschidem tabelul īn regimul Datasheet View, dand click pe numele tabelului din partea stanga a bazei de date. Comutarea intre cele doua moduri de vizualizare, Design View si Datasheet View se face alegind butonul View din bara de instrumente.

In cele ce urmeaza vom descrie cīteva proceduri de redactare a datelor.

a) Adaugarea unor īnregistrari noi nregistrarile noi sunt plasate la sfīrsitul
tabelului .

b)      Excluderea unor īnregistrari Pentru a sterge una sau mai multe
īnregistrari consecutive, marcam aceste īnregistrari prin glisarea ("tragerea")
mouse-ului pe verticala din stīnga tabelului, apoi apasam tasta Delete sau
alegem comanda Delete

c)      Copierea unor blocuri de date. Pentru a copia un bloc de date, marcam
blocul, apoi actionam butonul Copy din bara cu instrumente. Ca rezultat,
continutul blocului se copie īn memoria Clipboard. Din acest moment, continutul

memoriei Clipboard poate fi "lipit" oriunde. In acest scop marcam locul inserarii (blocul-destinatie) si actionam butonul Paste din bara cu instrumente.

Remarca: Dimensiunile si caracteristicile blocului-destinatie trebuie sa corespunda īntocmai dimensiunilor si caracteristicilor blocului-sursa.

Modificarile efectuate īn orice īnregistrare a tabelului se salveaza īn mod automat de fiecare data cīnd trecem la o alta īnregistrare, sau la īnchiderea tabelului. Aceasta īnseamna ca dupa terminarea lucrului cu un tabel nu este neaparat nevoie sa-1 salvam, - sistemul o va face singur. Utilizatorul trebuie doar sa aiba grija sa īnchida tabelul īn caz ca nu-1 va mai utiliza. Daca, īnsa, am efectuat modificari ce tin de aspectul tabelului (latimea coloanelor, ordinea lor etc.) si dorim ca aceste modificari sa fie prezente la o noua deschidere, īnainte de a īnchide tabelul, īl salvam cu comanda Save din meniul File.

Relatii dintre tabele. Integritatea datelor

Relatiile dintre doua tabele se stabilesc, de regula, prin intermediul unor cīmpuri identice (cu aceeasi denumire, de aceeasi lungime, cu aceleasi proprietati) prezente īn ambele tabele.

Īn cazul relatiei de tipul unu la multi īn tabelul primar (din partea caruia se realizeaza relatia "unu") trebuie sa existe un cīmp, numit cheie primara, n care nu se admit valori care se repeta, iar īn tabelul secundar (din partea caruia se realizeaza relatia "multi") trebuie sa existe un cīmp analogic cu cel din tabelul primar, numit cheie straina, care poate admite valori care se repeta.

Luati īn considerare acest exemplu: tabelele Furnizori si Produse din baza de date pentru comenzi de produse. Un furnizor poate furniza oricāte produse. Asadar, pentru orice furnizor din tabelul Furnizori pot exista multe produse īn tabelul Produse. Relatia dintre tabelul Furnizori si tabelul Produse este, prin urmare, o relatie de tipul unul-la-mai-multi.

Pentru a reprezenta o relatie de tipul unul-la-mai-multi īn proiectul bazei de date, luati cheia primara din partea "unu" a relatiei si adaugati-o ca o coloana suplimentara la tabelul din partea "mai-multi" a relatiei. Īn acest caz, de exemplu, se adauga coloana ID furnizor, din tabelul Furnizori, la tabelul Produse. Access poate utiliza numarul de ID al furnizorului īn tabelul Produse pentru a gasi furnizorul potrivit pentru fiecare produs.

Coloana ID furnizor din tabelul Produse se numeste cheie externa. O cheie externa este cheia primara a unui alt tabel. Coloana ID furnizor din tabelul Produse este o cheie externa, deoarece este si cheia primara a tabelului Furnizori.

Furnizati baza pentru a uni tabelele legate prin stabilirea perechilor de chei primare si chei externe. Daca nu sunteti sigur care tabele ar trebui sa partajeze o coloana comuna, identificarea unei relatii unu-la-mai-multi va asigura necesitatea unei coloane partajate īntre cele doua tabele implicate.

Relatia multi la multi poate fi transformata īn doua relatii de tipul unu la multi prin definirea unui tabel intermediar, īn care se introduc, īn calitate de chei straine, cheile primare ale primelor douг tabele. Astfel, pentru a evita relatia multi la multi dintre tabelele COMENZI si PRODUSE , a fost definit tabelul DETALII COMENZI īn care au fost incluse cīmpurile ID COMANDA si ID PRODUS din tabelele respective.

Luati īn considerare relatia dintre tabelul Produse si tabelul Comenzi.

O comanda poate include mai multe produse. Pe de alta parte, un produs poate aparea īn mai multe comenzi. De aceea, pentru fiecare īnregistrare din tabelul Comenzi, pot exista mai multe īnregistrari īn tabelul Produse. Si pentru fiecare īnregistrare din tabelul Produse, pot exista mai multe īnregistrari īn tabelul Comenzi. Aceasta relatie este de tipul mai-multi-la-mai-multi, deoarece pentru orice produs pot exista mai multe comenzi; si pentru orice comanda pot exista mai multe produse. Retineti faptul ca pentru a detecta relatiile de tipul mai-multi-la-mai-multi dintre tabele, este important sa luati īn considerare ambele sensuri ale relatiei.

Subiectele celor doua tabele - comenzi si produse - se afla īntr-o relatie mai-multi-la-mai-multi. Acest lucru prezinta o problema. Pentru a īntelege problema, imaginati-va ce s-ar īntāmpla daca ati īncerca sa creati o relatie īntre doua tabele adaugānd cāmpul ID produs la tabelul Comenzi. Pentru a avea mai mult de un produs pentru fiecare comanda, aveti nevoie de mai mult de o īnregistrare pentru fiecare comanda īn tabelul Comenzi. S-ar repeta informatiile despre comanda pentru fiecare rānd asociat cu o comanda  - rezultānd o proiectare ineficienta care poate produce date exacte. Aceeasi problema apare daca se adauga cāmpul ID comanda la tabelul Produse - rezulta mai multe īnregistrari īn tabelul Produse pentru fiecare produs. Cum se rezolva aceasta problema?

Raspunsul este crearea celui de-al treilea tabel, numit adesea tabel de jonctiune, care separa relatia mai-multi-la-mai-multi īn doua relatii unu-la-mai-multi. Inserati cheia primara a fiecaruia dintre cele doua tabele īn al treilea tabel. Ca rezultat, al treilea tabel īnregistreaza fiecare aparitie sau instanta a relatiei.

Fiecare īnregistrare din tabelul Detalii comanda reprezinta un element linie īntr-o comanda. Cheia primara a tabelului Detalii comanda consta īn doua cāmpuri - cheile externe ale tabelelor Comenzi si Produse. Utilizarea cāmpului ID comanda singur nu functioneaza ca o cheie primara pentru acest tabel, deoarece o comanda poate avea mai multe elemente linie. ID comanda se repeta pentru fiecare element linie dintr-o comanda, astfel īncāt cāmpul nu contine valori unice. Nici utilizarea cāmpului ID produs singur nu functioneaza, deoarece un produs poate aparea īn mai multe comenzi diferite. Dar, īmpreuna, cele doua cāmpuri produc īntotdeauna o valoare unica pentru fiecare īnregistrare.

Īn baza de date pentru vānzari de produse, tabelele Comenzi si Produse nu sunt asociate direct. Īn schimb, ele sunt asociate indirect prin tabelul Detalii comanda. Relatia mai-multi-la-mai-multi īntre comenzi si produse se reprezinta īn baza de date utilizānd doua relatii unu-la-mai-multi:

Īntre tabelele Comenzi si Detalii comanda exista o relatie unu-la-mai-multi. Fiecare comanda are mai mult de un element line, dar fiecare element linie este conectat cu o singura comanda.

Īntre tabelele Produse si Detalii comanda exista o relatie unu-la-mai-multi. Fiecare produs poate avea mai multe elemente linie asociate, dar fiecare element linie face referire la un singur produs.

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

Dupa incorporarea tabelului Detalii comanda, lista tabelelor si cāmpurilor poate arata cam asa:

Relatia de tipul unu la unu presupune existenta īn ambele tabele a unei chei primare cu aceleasi caracteristici, īn fond, doua tabele īntre care exista o relatie de tipul unu la unu pot fi oricīnd unite īntr-un singur tabel; la fel, orice tabel poate fi divizat īn doua sau mai multe tabele īntre care se stabileste o relatie de tipul unu la unu. Divizarea unui tabel īn modul mentionat mai sus poate fi utila īn cazul unui tabel cu un numar foarte mare de cīmpuri (un tabel Access, de exemplu, nu poate contine mai mult de 255 de cīmpuri), dar si īn situatia cīnd o parte din informatia care se refera la o entitate are un caracter confidential, sau se utilizeaza foarte rar. Īn concluzie, desi relatiile de tipul unu la unu nu sunt caracteristice unei baze de date de tip relational, totusi īn unele situatii acest tip de relatii este preferabil sau chiar necesar.

Daca la proiectarea tabelelor tinem cont de principiile expuse mai sus , atunci Access stabileste automat relatiile dintre tabelele care contin cīmpuri comune. Totusi putem stabili relatii īntre tabelele bazei de date si īn mod explicit, utilizīnd comanda Relationships din meniul Datasheet Tools. Īn acest caz apare

fig.8 Relatiile dintre tabelele bazei de date STUD

o fereastra (fig.8) īn care indicam tabelele īntre care se stabilesc relatii,apoi, cu ajutorul mouse-ului, trasam legaturile īntre cīmpurile respective.

Daca unul din cīmpurile de legatura este de tip cheie primara (el are o

culoare mai pronuntata), trasarea se face pornind de la acest cīmp. Tabelul

de la care se traseaza legatura se numeste tabel primar (principal), iar

celalalt - secundar (subordonat). Ca rezultat, apare o caseta de dialog (fig.9

fig.9 Stabilirea proprietatilor relatiilor

īn care putem specifica proprietatile relatiei (legaturii).

Pentru relatia dintre doua tabele pot fi stabilite urmatoarele proprietati:

1. Tipul relatiei (Relationship Type) poate fi stabilit ca unu la unu (one
to one) sau unul la multi (one to many);

Impune integritatea referentiala (Enforce Referential Integrity}.
Includerea acestui parametru asigura integritatea datelor īn procesul
introducerii, modificarii sau stergerii īnregistrarilor din tabelele legate. Acest
lucru este posibil doar īn cazul cīnd cīmpul din tabelul principal este de tip
cheie primara, iar cīmpul de legatura din tabelul subordonat are acelasi tip de
date. Atunci cīnd introducem date īn cīmpul de legatura al tabelului
subordonat, sunt acceptate doar acele valori care se contin īn cīmpul
respectiv al tabelului principal. De exemplu, daca nu exista un client cu
identificatorul 0472 īn tabelul CLIENTI, sistemul nu va admite aparitia
acestui cod īn cīmpul respectiv al tabelului COMENZI. In acest caz este
necesar sa introducem mai īntīi datele despre clientul īn cauza īn tabelul
CLIENTI, apoi sa utilizam identificatorul cititorului īn tabelul COMENZI.
La fel, nu putem exclude o īnregistrare din tabelul principal, daca valoarea
cīmpului de legatura a acestei īnregistrari se contine īn una sau mai multe
īnregistrari ale tabelului subordonat.

3. Modificarea īn cascada a īnregistrarilor (Cascade Update Related
Fields). Daca acest parametru este inclus, sistemul va modifica toate valorile
cīmpului de legatura ale tabelului subordonat īn cazul cīnd valoarea cīmpului
respectiv al tabelului principal se modifica. De exemplu, daca un client si-a schimbat numarul de identificare(id client) 0472 si i se remite un nou
numar 1465, aceasta valoare trebuie sa se modifice īn toate
īnregistrarile tabelului COMENZI īn care figureaza valoarea veche. In caz contrar,
comenzile facute clientul cu identificatorul 0472 nu sunt valide,
deoarece nu se cunoaste nici o informatie despre clientul īn cauza.

4. Excluderea īn cascada a īnregistrarilor (Cascade Delete Related
Records). Daca acest parametru este activ, atunci excluderea unei īnregistrari
din tabelul principal implica excluderea tuturor īnregistrarilor din tabelul
subordonat, īn care valoarea cīmpului de legatura coincide cu cea a cīmpului
respectiv din tabelul principal. De cele mai multe ori asemenea excluderi
sunt firesti, deoarece existenta unor īnregistrari īn tabelul subordonat, pentru
care valoarea cīmpului de legatura nu se contine si īn tabelul principal, duce
la pierderea integritatii datelor.

Toate rationamentele de mai sus tin de integritatea datelor, asigurarea careia reprezinta unul din principiile fundamentale ale proiectarii bazelor de date.

Bibliografie:

Hernandez, Michael J Database Design for Mere Mortals: A Hands-On Guide to Relational Database Design, Editia a doua. Editura Addison-Wesley Professional, 2003.

Fleming, Candace C. von Halle, Barbara Handbook of Relational Database Design. Editura Addison-Wesley Professional, 1989.

Riordan, Rebecca M Designing Effective Database Systems Editura Addison-Wesley Professional, 2005.