Sunteți pe pagina 1din 21

Noiune de baz de date.

Printre multiplele forme de organizare a datelor, bazele de date ocup un loc aparte.
O baz de date (BD) reprezint o colecie de date integrat, anume structurat i dotat cu o descriere a structurii i a relaiilor dintre date.n funcie de modul de organizare a informaiilor, se cunosc cteva modele de BD:ierarhic (arborescent), reea, relaional .a. Gestiunea bazelor de date. Sistemul de gestiune a bazelor de date (SGBD) este acel sistem de programe care faciliteaz i supervizeaz introducerea de informaii n baza de date, actualizarea i extragera din baz, controlul i autorizarea accesului la date. Un sistem de gestiune a bazelor de date trebuie s fie capabil s ndeplineasc urmtoarele funcii: de descriere ,care rezid n definirea structuriidatelor, a relaiilor dintre acestea i a condiilor de acces la informaile coninute n baza de date; de actualizare, care presupune inserarea, redactarea i suprimarea datelor; de interogare a BD, care permite obinerea diferitor informaii din BD conform unor criterii de cutare; de obinere de date noi, care const n prelucrarea informaiei iniiale n scopul obinerii unor totaluri, medii etc.; de ntreinere, care const n crearea copiilor de rezerv, compactarea BD i repararea ei n cazul deteriorrii; de securitate a datelor, care rezid n protejarea BD mpotriva accesului neautorizat i n atribuirea drepturilor de acces. Lansarea sistemului MS Access 2007 Exist mai multe modaliti de lansare a sistemului Access, una din ele fiind executarea consecutiv a aciunilor Start/All Programs(sau Programs)/Microsoft Office/Microsoft Office Access 2007. Ca rezultat, obinem o fereastr, asemntoare cu cea din figura 1.

Figura 1. Lansarea sistemului Access

Crearea / accesarea unei baze de date Dup cum am mai menionat, elementele principale ale unei baze de date sunt tabelele. Dar o baz de date poate conine i alte elemente care se creeaz pe baza tabelelor (interogri, formulare, rapoarte etc.). Aceste elemente, mpreun cu tabelele, formeaz aa-numitele clase de obiecte ale bazei de date. 1. Pentru a crea o baz de date nou, dam click pe butonul Microsoft Office , apoi facei

clic pe New. 2. n caseta File Name, tastai un nume de fiier. Pentru a modifica locaia, facei clic pe

pictograma folderului pentru a rsfoi. 3. Facei clic pe Create.

Pentru a deschide o baz de date existent n zona butonul Microsoft Office a ferestrei reprezentate n figura 1 executm un clic pe Open. n caseta de dialog care apare indicm numele BD (de ex., BIBL) i localizarea ei (discul, dosarul).Obinem fereastra urmatoare(figura 2):

Figura. 2 Fereastra Access O baz de date proiectat corespunztor furnizeaz acces la informatii precise, actualizate. Microsoft Office Access 2007 organizeaz informatiile n tabele: liste de rnduri si coloane ce amintesc de registrul unui contabil sau de o foaie de lucru din Microsoft Office Excel 2007. ntr-o baz de date simpl, se poate s aveti doar un singur tabel. Pentru cele mai multe baze de date va trebui s aveti mai multe. De exemplu, se poate s aveti un tabel care stocheaz informatii despre produse, alt tabel care stocheaz informatii despre comenzi si un altul cu informatii referitoare la clienti.

Fiecare rnd se mai numeste nregistrare si fiecare coloan, de asemenea, se mai numeste cmp. O nregistrare este o modalitate semnificativ si consistent de a combina anumite informatii. Un cmp este un element singular de informatie - un tip de element care apare n orice nregistrare. De exemplu, n tabelul produse, fiecare rnd sau nregistrare ar contine informatii despre un produs. Fiecare coloan sau cmp contine un anumit tip de informatie despre acest produs, cum ar fi numele sau pretul. Proiectarea unei baze de date Anumite principii ghideaz procesul de proiectare al unei baze de date. Primul principiu este acela c informatiile dublur (numite si date redundante) au o influent negativ, deoarece consum spatiu si sporesc probabilitatea producerii de erori si inconsistente. Al doilea principiu l reprezint importanta corectitudinii si caracterului complet al informatiilor. Dac 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 luat bazndu-v pe aceste rapoarte va fi gresit informat. O proiectare bun a unei baze de date este, dup cum urmeaz, una care:

mparte informatiile n tabele pe baza subiectelor, pentru a reduce datele redundante. Furnizeaz programului Access informatiile necesare pentru a asocia informatiile din tabele dup necesitti. Asist si asigur acuratetea si integritatea informatiilor. Adapteaz necesittile de procesare a datelor si cele de raportare.

Procesul de proiectare const n urmtorii pasi:


1. Determinarea scopului bazei de date

Acesta ajut la pregtirea pasilor rmasi.


2. Gsirea si organizarea informatiilor necesare

Adunarea tuturor tipurilor de informatii pe care le nregistrati n baza de date, cum ar fi numele produsului si numrul comenzii.
3. mprtirea informatiilor n tabele

mprtirea elementelor de informatii n entitti sau subiecte majore cum ar fi Produse sau Comenzi. Apoi, fiecare subiect devine un tabel.
4. Transformarea elementelor de informatii n coloane

Decideti ce informatii s stocati n fiecare tabel. Fiecare element devine un cmp care este afisat sub form de coloan n tabel. De exemplu, un tabel Angajati poate include cmpuri, cum ar fi Nume de familie si Data angajrii.
5. Specificarea cheilor primare

Alegeti cheia primar pentru fiecare tabel. Cheia primar este o coloan care se utilizeaz pentru a identifica n mod unic fiecare rnd. Un exemplu poate fi ID produs sau ID comand. 4

6. Configurarea relatiilor din tabel

Priviti fiecare tabel si decideti cum se asociaz datele dintr-un tabel cu datele din alte tabele. Adugati cmpuri la tabele sau creati noi tabele pentru a clarifica relatiile, dup necesitti. Determinarea scopului bazei de date 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 clientilor pstreaz o list a informatiilor despre clienti n scopul producerii de liste de corespondent si de rapoarte." Dac baza de date este mai complex sau este utilizat de mai multe persoane, cum se ntmpl de obicei ntr-o conjunctur corporativ, scopul se poate ntinde pe mai multe paragrafe si trebuie s includ cnd si de ctre 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 instructiune v ajut s v concentrati asupra obiectivelor atunci cnd 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 cnd doriti s vedeti rezultatele. De exemplu, s presupunem c exist un raport Produse comandate care afiseaz subtotalul unittilor comandate, pentru fiecare categorie de produse din baza de date. Cu toate acestea, nu exist o coloan Subtotal Unitti comandate n niciun tabel. n schimb, tabelul Produse include o coloan Unitti comandate, care stocheaz unittile comandate din fiecare produs. Utiliznd aceste date, Access calculeaz subtotalul de fiecare dat cnd imprimati raportul. Subtotalul nu trebuie stocat ntr-un tabel. CREAREA UNUI TABEL Un tabel conine date despre un anumit subiect, cum ar fi clienii sau produsele. Fiecare nregistrare dintr-un tabel conine informaii despre un element, cum ar fi un anumit angajat. O nregistrare este compus din cmpuri, cum ar fi numele, adresa i numrul de telefon. O nregistrare este denumit n mod obinuit rnd, iar un cmp este denumit coloan.

nregistrare sau rnd 5

Cmp sau coloan

Baza dvs. de date poate conine mai multe tabele, fiecare cu informaii referitoare la anumit subiect. Fiecare tabel poate conine mai multe cmpuri de diferite tipuri, inclusiv text, numere, date i imagini. Urmtoarea list afieaz exemple obinuite de tabele: Un tabel client care listeaz clienii firmei i adresele lor element Un tabel de activiti care urmrete activitile i datele scadente Un inventar de echipament sau stoc disponibil un catalog de produse pe care le vindei, inclusiv preurile i imaginile pentru fiecare

Crearea unui tabel nou ntr-o baz de date nou 4. 5. Facei clic pe butonul Microsoft Office , apoi facei clic pe Nou.

n caseta Nume fiier, tastai un nume de fiier. Pentru a modifica locaia, facei clic pe

pictograma folderului pentru a rsfoi. 6. Facei clic pe Creare.

Se deschide baza nou de date, apoi se creeaz i se deschide un tabel nou denumit Tabel1 n vizualizarea Datasheet View. Crearea unui tabel nou ntr-o baz de date existent 1. 2. 3. Facei clic pe butonul Microsoft Office , apoi facei clic pe Open.

n caseta de dialog Open, selectai i deschidei baza de date. n fila Create, n grupul Tabele, facei clic pe Tabel.

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

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 cmpurilor Pentru fiecare cmp al tabelului se specific 3 caracteristici, i anume: Field Name (denumirea cmpului, obligatoriu); Data Type (tipul cmpului, obligatoriu); Description (descrierea cmpului, opional). 7

Regimul Design View nu permite introducerea nregistrrilor n tabel, ci doar descrierea cmpurilor care alctuiesc tabelul. Denumirea cmpului poate conine diferite caractere, inclusiv spaii, cu excepia unor semne speciale ( ".", "!" .a.). n caz de necesitate, denumirea poate conine semnul "_" (subliniere). Lungimea denumirii cmpului (mpreun cu spaiile) nu poate depi 64 de caractere. Exemple: autorul;Id_ rii; locul_ de_ munc; LoculDeMunc; Locul de Munc. Tipul cmpului poate fi unul din urmtoarele: Text - pentru texte sau numere care nu vor fi folosite n calcule; Memo - pentru texte lungi (biografia autorului, rezumatul crii etc.). Number - pentru numere care vor fi folosite n calcule; Date/Time - pentru date calendaristice; Currency - pentru valori bneti; AutoNumber - pentru numere ntregi care i mresc n mod automat valorile (numrul de ordine, de exemplu); Yes/No - pentru valori logice care pot lua numai dou valori: Yes (adevr), No (fals); OLE Object - pentru imagini (fotografia autorului), sunete (imnul rii). Hyperlink - pentru adrese Hyperlink. Valorile acestui cmp pot fi adrese Internet (de exemplu, www.google.com) sau locaii (calea spre un fiier sau dosar din calculator) Lookup Wizard - reprezint, de fapt, nu un tip de date, ci o proprietate a cmpului prin care valorile lui pot fi selectate din alt tabel. Acest mod de abordare simplific procedura introducerii valorilor cmpului i, n plus reduce riscul comiterii unor erori. Pentru a schimba tipul cmpului (implicit tipul este Text), trecem n coloana Data Type (fig.4) i din lista derulant alegem tipul dorit. Apoi trecem (dac e cazul) n coloana Description, pentru a introduce note explicative, sau n rndul urmtor, pentru descrierea altui cmp. Stabilirea cheilor primare Fiecare tabel ar trebui s includ o coloan sau un set de coloane care identific, n mod unic, fiecare rnd stocat n tabel. De obicei, se utilizeaz un numr unic de identificare, cum ar fi numrul de ID al unui angajat sau un numr de serie. n terminologia bazelor de date, aceste informatii reprezint cheia primar a tabelului. Access utilizeaz cmpuri de tipul cheie primar pentru a asocia rapid date din tabele multiple si a cumula datele. Dac aveti deja un identificator unic pentru un tabel, cum ar fi un numr de produs care identific n mod unic fiecare produs din catalog, aveti posibilitatea s utilizati acel identificator ca si 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 utilizati numele oamenilor pentru cheia primar, deoarece numele nu sunt unice. Este foarte posibil s existe doi oameni cu acelasi nume n acelasi tabel. 8

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 si component ntr-o cheie primar. Trebuie ntotdeauna s alegeti o cheie primar a crei valori nu se va schimba. ntr-o baz de date care utilizeaz mai multe tabele, se poate utiliza cheia primar a unui tabel care referint 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 sansele de a se desincroniza cheia primar cu tabelele care fac referint la ea. Deseori, e utilizeaz ca si cheie primar un numr unic arbitrar. De exemplu, i se poate atribui fiecrei comenzi un numr unic de comand. Singurul scop al numrului de comand este identificarea unei comenzi. O dat atribuit, nu se schimb niciodat. Dac nu aveti o coloan sau un set de coloane care se poate utiliza ca si cheie primar, luati n considerare utilizarea unei coloane care are tipul de date AutoNumerotare. Cnd se utilizeaz tipul de date AutoNumerotare, Access atribuie automat o valoare. Un astfel de identificator nu are date; nu contine informatii care descriu rndul pe care l reprezint. Identificatorii fr date sunt ideali pentru rolul de cheie primar, deoarece nu se modific.

O coloan setat la tipul de date AutoNumerotare 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 cmpuri 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 si ID Produs. Cnd o cheie primar utilizeaz mai mult de o coloan, aceasta se mai numeste si cheie compus. n cazul bazei de date pentru vnzri de produse, se poate crea o coloan de tipul AutoNumerotare pentru fiecare dintre tabele, pentru a ndeplini rolul de cheie primar: IDProdus pentru tabelul Produse, IDComand pentru tabelul Comenzi, IDClient pentru tabelul Clienti si IDFurnizor pentru tabelul Furnizori.

Pentru a stabili cheia primar, selectm cmpul respectiv, apoi executm un clic pe butonul bara cu instrumente. Ca rezultat, n partea din stnga a cmpului respectiv apare semnul cheii (vezi fig. ).

din

Dup ncheierea procedurii de descriere a cmpurilor i de stabilire a cheii primare, salvm tabelu. Dac nu am stabilit o cheie primar (acest lucru nu este obligatoriu), sistemul ne va avertiza, sugerndu-ne stabilirea cheii pe un cmp de tip AutoNumber. Pentru a confirma, acionm butonul Yes. n acest caz sistemul stabilete automat cheia primar pe un cmp AutoNumber (dac el exist) sau creeaz suplimentar un asemenea cmp (dac el nu exist), stabilind pe el cheia primar. Pentru a renuna la stabilirea cheii primare, acionm butonul No. Proprietile cmpurilor n afar de tipul cmpului, putem stabili i unele proprieti ale sale, cum ar fi mrimea (lungimea), numrul cifrelor zecimale, formatul datei calendaristice etc. Fiecare tip de date are proprieti prestabilite, dar ele pot fi modificate, executnd un clic pe cmpul respectiv (fig. , partea de sus) i modificnd valorile prestabilite care apar n partea de jos. Cmpurile de ti p Text pot avea lungimi cuprinse ntre l i 255 de caractere. Implicit, mrimea cmpului este de 50, dar ea poate fi modificat n limitele amintite, n funcie de lungimea maxim preconizat a valorilor cmpului respectiv. Astfel, pentru Id client (identificatorul clientului), modificm mrimea cmpului din 50 (valoarea prestabilit) n 8 (valoarea necesar). La fel procedm i cu caracteristicile altor cmpuri.

10

Menionm i cu aceast ocazie, c pentru cmpurile ce conin 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 cutarea informaiei n baza de date. Cmpurile de tip Number au lungimi diferite n funcie de opiunea specificat pentru proprietatea Field Size. Opiunea implicit pentru cmpurile de tip Number este, de regul, Single, dar ea poate fi modificat, utiliznd comanda Options din meniul Tools. Pentru cmpurile de tip Number poate fi stabilit i proprietatea Format, n care specificm modul de afiare a valorilor (numrul cifrelor zecimale etc.). Cmpurile de t i p Date/Time au lungimi variabile n funcie de formatul datei/orei specificat pentru proprietatea Format a cmpului. Cmpurile de tip logic (Yes/No) ocup n memoria calculatorului un octet i pot fi reprezentate n 4 moduri, n funcie de opiunea specificat pentru proprietatea Format a acestui cmp, i anume: Yes/No, True/False, On/Off, -1/0. n ultimul caz valoarea - l corespunde strii True (adevr), iar valoarea 0 - strii False (fals). Specificarea valorilor prestabilite Dac o bun parte din valorile unui cmp se repet frecvent (de exemplu, n cazul cnd orasul este acelasi), putem specifica o valoare prestabilit (implicit) a cmpului respectiv. Valoarea prestabilit ( n cazul nostru "Timisoara") se specific pentru proprietatea Default Value a cmpului. In procesul introducerii datelor sistemul atribuie cmpului valoarea prestabilit n mod automat, utilizatorul urmnd s modifice doar valorile care difer de cea prestabilit. Valoarea prestabilita pentru campurile de tip data calendaristica face referire la data curenta. In acest caz pentru proprietatea Default Value a cmpului de tip data calendaristica se introduce Date(). Stabilirea unor condiii de validare Pentru a diminua riscul introducerii unor valori greite, putem stabili condiii (reguli) de validare pentru valorile cmpurilor respective. Regulile de validare se stabilesc pentru proprietatea Validation Rule a cmpului. Totodat, pentru proprietatea Validation Text se specific mesajul care trebuie s fie afiat n cazul nerespectrii regulii. Astfel, dac se tie c preul produselor nu depete valoarea 20000, specificm pentru proprietatea Validation Rule a cmpului Pre condiia <=20000, iar pentru proprietatea Validation Text -mesajul "Preul produsului nu poate fi mai mare de 200 de lei. Reintroducei preul crii. La fel, data comenzii nu poate depi data curent, astfel c pentru cmpurile Data comanda putem stabili condiia <=Date() pentru proprietatea Validation Rule. Mesajul specificat pentru proprietatea Validation Text va fi i el adecvat. In fiecare din situaiile descrise vor fi afiate mesajele respective n cazul introducerii unor valori care nu corespund condiiilor de validare stabilite n procesul definirii cmpurilor.

11

Modificarea descrierii unui tabel n cazul cnd apare necesitatea modificrii descrierii iniiale a unui tabel (adugarea sau excluderea unuia sau mai multor cmpuri, schimbarea ordinii, modificarea unor caracteristici etc), deschidem tabelul respectiv n regimul Design View i efectum modificrile necesare . Introducerea datelor n tabel Dup ce am efectuat procedurile de descriere a tabelului , putem introduce date n cmpurile lui. Pentru a iniia procesul de introducere a datelor , deschidem BD (dac nu este deschis) , apoi n fereastra Database (fig.4) selectm tabelul necesar (de exemplu Clienti). Ca rezultat, se afieaz cmpurile tabelului respectiv fig.7(iniial tabelul conine doar un rnd liber).

fig.7 Introducerea i modificarea datelor n tabel Nu este absolut obligatoriu s completm toate cmpurile; astfel dac anumite date nu snt deocamdat cunoscute, introducerea lor poate fi amnat. Excepie fac cmpurile pentru care au fost stabilite chei primare. Aceste cmpuri nu pot avea valori nule, de aceea valorile lor trebuie introduse n mod obligatoriu. Ordinea introducerii datelor poate fi i ea oricare. Dac a fost stabilit o cheie primar , la o nou deschidere a tabelului nregistrrile vor fi afiate n ordinea cresctoare a valorilor cmpului respectiv. Datorit acestui fapt, orice nregistrare nou se adaug la sfritul tabelului, avnd certitudinea c ulterior ea va fi plasat n locul corespunztor. Dup terminarea introducerii datelor nchidem tabelul, acionnd butonul meniul File (modificrile efectuate se salveaz automat). sau executnd comanda Close din

Remarc: Tipul i caracteristicile datelor introduse trebuie s corespund ntocmai tipului i caracteristicilor cmpurilor respective definite n procesul crerii (descrierii) tabelului.

12

Redactarea datelor Dac apare necesitatea modificrii (editrii) nregistrrilor 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 instrumente.

din bara de

In cele ce urmeaz vom descrie cteva proceduri de redactare a datelor. a) Adugarea tabelului . b) unor nregistrri noi. nregistrrile noi sunt plasate la sfritul

Excluderea unor nregistrri. Pentru a terge una sau mai multe nregistrri consecutive, marcm aceste nregistrri prin glisarea ("tragerea") mouse-ului pe verticala din stnga tabelului, apoi apsm tasta Delete sau

alegem comanda Delete . Copierea unor blocuri de date. Pentru a copia un bloc de date, marcm blocul, apoi acionm butonul Copy din bara cu instrumente. Ca rezultat, coninutul blocului se copie n memoria Clipboard. Din acest moment, coninutul memoriei Clipboard poate fi "lipit" oriunde. In acest scop marcm locul inserrii (blocul-destinaie) i acionm butonul Paste din bara cu instrumente. c) Remarc: Dimensiunile i caracteristicile blocului-destinaie trebuie s corespund ntocmai dimensiunilor i caracteristicilor blocului-surs. Modificrile efectuate n orice nregistrare a tabelului se salveaz n mod automat de fiecare dat cnd trecem la o alt nregistrare, sau la nchiderea tabelului. Aceasta nseamn c dup terminarea lucrului cu un tabel nu este neaprat nevoie s-1 salvm, - sistemul o va face singur. Utilizatorul trebuie doar s aib grij s nchid tabelul n caz c nu-1 va mai utiliza. Dac, ns, am efectuat modificri ce i n de aspectul tabelului (limea coloanelor, ordinea lor etc.) i dorim ca aceste modificri s fie prezente la o nou deschidere, nainte de a nchide tabelul, l salvm cu comanda Save din meniul File.

Relaii dintre tabele. Integritatea datelor 13

Relaiile dintre dou tabele se stabilesc, de regul, prin intermediul unor cmpuri identice (cu aceeai denumire, de aceeai lungime, cu aceleai proprieti) prezente n ambele tabele. n cazul relaiei de tipul unu la muli n tabelul primar (din partea cruia se realizeaz relaia "unu") trebuie s existe un cmp, numit cheie primar, n care nu se admit valori care se repet, iar n tabelul secundar (din partea cruia se realizeaz relaia "muli") trebuie s existe un cmp analogic cu cel din tabelul primar, numit cheie strin, care poate admite valori care se repet. Luati n considerare acest exemplu: tabelele Furnizori si Produse din baza de date pentru comenzi de produse. Un furnizor poate furniza oricte 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 primar din partea "unu" a relatiei si adugati-o ca o coloan suplimentar la tabelul din partea "maimulti" a relatiei. n acest caz, de exemplu, se adaug coloana ID furnizor, din tabelul Furnizori, la tabelul Produse. Access poate utiliza numrul de ID al furnizorului n tabelul Produse pentru a gsi furnizorul potrivit pentru fiecare produs. Coloana ID furnizor din tabelul Produse se numeste cheie extern. O cheie extern este cheia primar a unui alt tabel. Coloana ID furnizor din tabelul Produse este o cheie extern, deoarece este si cheia primar a tabelului Furnizori.

14

Furnizati baza pentru a uni tabelele legate prin stabilirea perechilor de chei primare si chei externe. Dac nu sunteti sigur care tabele ar trebui s partajeze o coloan comun, identificarea unei relatii unu-la-mai-multi va asigura necesitatea unei coloane partajate ntre cele dou tabele implicate.

Relaia muli la muli poate fi transformat n dou relaii de tipul unu la muli prin definirea unui tabel intermediar, n care se introduc, n calitate de chei strine, cheile primare ale primelor dou tabele. Astfel, pentru a evita relaia muli la muli dintre tabelele COMENZI si PRODUSE , a fost definit tabelul DETALII COMENZI n care au fost incluse cmpurile ID COMANDA i ID PRODUS din tabelele respective. Luati n considerare relatia dintre tabelul Produse si tabelul Comenzi. O comand poate include mai multe produse. Pe de alt parte, un produs poate aprea n mai multe comenzi. De aceea, pentru fiecare nregistrare din tabelul Comenzi, pot exista mai multe nregistrri n tabelul Produse. Si pentru fiecare nregistrare din tabelul Produse, pot exista mai multe nregistrri n tabelul Comenzi. Aceast relatie este de tipul mai-multi-la-mai-multi, deoarece pentru orice produs pot exista mai multe comenzi; si pentru orice comand pot exista mai multe produse. Retineti faptul c pentru a detecta relatiile de tipul mai-multi-la-mai-multi dintre tabele, este important s luati n considerare ambele sensuri ale relatiei. Subiectele celor dou tabele comenzi si produse se afl ntr-o relatie mai-multi-la-mai-multi. Acest lucru prezint o problem. Pentru a ntelege problema, imaginati-v ce s-ar ntmpla dac ati ncerca s 15

creati o relatie ntre dou tabele adugnd cmpul ID produs la tabelul Comenzi. Pentru a avea mai mult de un produs pentru fiecare comand, aveti nevoie de mai mult de o nregistrare pentru fiecare comand n tabelul Comenzi. S-ar repeta informatiile despre comand pentru fiecare rnd asociat cu o comand rezultnd o proiectare ineficient care poate produce date exacte. Aceeasi problem apare dac se adaug cmpul ID comand la tabelul Produse rezult mai multe nregistrri n tabelul Produse pentru fiecare produs. Cum se rezolv aceast problem? Rspunsul este crearea celui de-al treilea tabel, numit adesea tabel de jonctiune, care separ relatia mai-multi-la-mai-multi n dou relatii unu-la-mai-multi. Inserati cheia primar a fiecruia dintre cele dou tabele n al treilea tabel. Ca rezultat, al treilea tabel nregistreaz fiecare aparitie sau instant a relatiei.

Fiecare nregistrare din tabelul Detalii comand reprezint un element linie ntr-o comand. Cheia primar a tabelului Detalii comand const n dou cmpuri cheile externe ale tabelelor Comenzi si Produse. Utilizarea cmpului ID comand singur nu functioneaz 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 nct cmpul nu contine valori unice. Nici utilizarea cmpului ID produs singur nu functioneaz, deoarece un produs poate aprea n mai multe comenzi diferite. Dar, mpreun, cele dou cmpuri produc ntotdeauna o valoare unic pentru fiecare nregistrare. n baza de date pentru vnzri de produse, tabelele Comenzi si Produse nu sunt asociate direct. n schimb, ele sunt asociate indirect prin tabelul Detalii comand. Relatia mai-multi-la-mai-multi ntre comenzi si produse se reprezint n baza de date utiliznd dou relatii unu-la-mai-multi: 16

ntre tabelele Comenzi si Detalii comand exist o relatie unu-la-mai-multi. Fiecare comand are mai mult de un element line, dar fiecare element linie este conectat cu o singur comand. ntre tabelele Produse si Detalii comand exist 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 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 si cmpurilor poate arta cam asa:

Relaia de tipul unu la unu presupune existena n ambele tabele a unei chei primare cu aceleai caracteristici, n fond, dou tabele ntre care exist o relaie de tipul unu la unu pot fi oricnd unite ntr-un singur tabel; la fel, orice tabel poate fi divizat n dou sau mai multe tabele ntre care se stabilete o relaie de tipul unu la unu. Divizarea unui tabel n modul menionat mai sus poate fi util n cazul unui tabel cu un numr foarte mare de cmpuri (un tabel Access, de exemplu, nu poate conine mai mult de 255 de cmpuri), dar i n situaia cnd o parte din informaia care se refer la o entitate are un caracter confidenial, sau se utilizeaz foarte rar. n concluzie, dei relaiile de tipul unu la unu nu sunt caracteristice unei baze de date de tip relaional, totui n unele situaii acest tip de relaii este preferabil sau chiar necesar.

17

Dac la proiectarea tabelelor inem cont de principiile expuse mai sus , atunci Access stabilete automat relaiile dintre tabelele care conin cmpuri comune. Totui putem stabili relaii ntre tabelele bazei de date i n mod explicit, utiliznd comanda Relationships din meniul Datasheet Tools. n acest caz apare

fig.8 Relaiile dintre tabelele bazei de date STUD

o fereastr (fig.8) n care indicm tabelele ntre care se stabilesc relaii,apoi, ului, trasm legturile ntre cmpurile respective. Dac unul din cmpurile de legtur este de tip cheie primar (el are o culoare mai pronunat), trasarea se face pornind de la acest cmp. T a b e l u l de la care se traseaz legtura se numete tabel primar (principal), i a r cellalt - secundar (subordonat). Ca rezultat, apare o caset de dialog (fig.9)

cu ajutorul mouse-

18

fig.9 Stabilirea proprietilor relaiilor n care putem specifica proprietile relaiei (legturii). Pentru relaia dintre dou tabele pot fi stabilite urmtoarele proprieti: 1. Tipul relaiei (Relationship Type) poate fi stabilit ca unu la unu (one to one) sau unul la muli (one to many); 2. Impune integritatea referenial (Enforce Referential Integrity}. Includerea acestui parametru asigur integritatea datelor n procesul introducerii, modificrii sau tergerii nregistrrilor din tabelele legate. Acest lucru este posibil doar n cazul cnd cmpul din tabelul principal este de t i p cheie primar, iar cmpul de legtur din tabelul subordonat are acelai tip de date. Atunci cnd introducem date n cmpul de legtur al tabelului subordonat, sunt acceptate doar acele valori care se conin n cmpul respectiv al tabelului principal. De exemplu, dac nu exist un client cu identificatorul 0472 n tabelul CLIENTI, sistemul nu va admite apariia acestui cod n cmpul respectiv al tabelului COMENZI. In acest caz este necesar s introducem mai nti datele despre clientul n cauz n tabelul CLIENTI, apoi s utilizm identificatorul cititorului n tabelul COMENZI. La fel, nu putem exclude o nregistrare din tabelul principal, dac valoarea cmpului de legtur a acestei nregistrri se conine n una sau mai multe nregistrri ale tabelului subordonat. 3. Modificarea n cascad a nregistrrilor (Cascade Update Related Fields). Dac acest parametru este inclus, sistemul va modifica toate valorile cmpului de legtur ale tabelului subordonat n cazul cnd valoarea cmpului respectiv al tabelului principal se modific. De exemplu, dac un client si-a schimbat numarul de identificare(id client) 0472 i i se remite un nou numr 1465, aceast valoare trebuie s se modifice n toate nregistrrile tabelului COMENZI n care figureaz valoarea veche. In caz contrar, 19

comenzile facute clientul cu identificatorul deoarece nu se cunoate nici o informaie despre clientul n cauz.

0472

nu

sunt

valide,

4. Excluderea n cascad a nregistrrilor (Cascade Delete Related Records). Dac acest parametru este activ, atunci excluderea unei nregistrri din tabelul principal implic excluderea tuturor nregistrrilor din tabelul subordonat, n care valoarea cmpului de legtur coincide cu cea a cmpului respectiv din tabelul principal. De cele mai multe ori asemenea excluderi sunt fireti, deoarece existena unor nregistrri n tabelul subordonat, pentru care valoarea cmpului de legtur nu se conine i n tabelul principal, duce la pierderea integritii datelor. Toate raionamentele de mai sus in de integritatea datelor, asigurarea creia reprezint unul din principiile fundamentale ale proiectrii bazelor de date.

20

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 AddisonWesley Professional, 1989. Riordan, Rebecca M Designing Effective Database Systems Editura Addison-Wesley Professional, 2005.

21

S-ar putea să vă placă și