LUCRAREA DE LABORATOR NR.

8
Тема: Crearea bazelor de date multitabelare

Scopul lucrării: De a obţine deprinderi practice şi cunoştinţe referitoare la crearea tabelelor

în BD multitabelare şi relaţionarea datelor.

Microsoft Access este un SGBD eficient pentru crearea şi administrarea BD relaţionale.

Tabelul - un obiect fundamental al bazei de date ce conţine date privind o anumită temă
(entitate) cum ar fi clienţi sau produse. Tabelul reprezintă un obiect informaţional ce are nume, cheie
primară, câmpuri, înregistrări. Toate datele stocate în BD sunt sistematizate în tabele.
Înregistrarea – rând în tabel. Fiecare înregistrare conţine informaţii despre un element al
entităţii cum ar fi un anumit client sau produs.
Câmpul – o înregistrare este compusă din câmpuri cum ar fi numele, adresa şi numărul de
telefon pentru un client. Câmpul conţine date de acelaşi tip pentru toate elementele entităţii.
Cheie primară – un câmp, valorile căruia în cadrul tabelului sunt unice.
Relaţia – o metodă ce permite combinarea datelor aflate în două tabele.
Integritatea referenţială a datelor – reprezintă un set de reguli care controlează modul în
care sunt adăugate, lichidate sau modificate datele în tabele relaţionale.

Formularea subproblemei:
De proiectat tabelele BD multitabelare pentru o unitate economică (soluţionarea
subproblemei este prezentată în baza exemplului de mai jos).

8.1. PROIECTAREA BD MULTITABELARE

Problema se soluţionează pe baza domeniului de aplicare descris în lucrarea de laborator

nr.1. Se cere de proiectat o BD multitabelară pentru unitatea economică „Omega”. O astfel de
proiectare a BD necesită o abordare complexă.
Etapele de proiectare a BD [3]:
I) Definirea scopului şi domeniului de aplicăre a BD – scopurile şi sarcinile în baza
exemplului domeniului de aplicare „Televiziunea digitală” (vezi LL nr.7).

1
 II) Definirea tabelelor pe care trebuie să le conţină BD, stabilirea câmpurilor ce urmează a fi
incluse în tabele şi legăturile dintre ele.
Una dintre cele mai importante etape ale procesului de proiectare a BD este elaborarea
tabelelor.
La proiectarea tabelelor se recomandă a se respecta următoarele restricţii:
1. Informaţia în tabele nu se dublează (depozitarea informaţiei într-un singur tabel
permite redactarea informaţiei doar într-un singur tabel). Acest principiu face lucrul mult mai
eficient şi exclude posibilitatea de necorespundere a informaţiei dacă s-a repetat în mai multe tabele.
De exemplu, adresa şi telefonul clienţilor se păstrează în acelaşi tabel.
2. Fiecare tabel conţine informaţia bine structurată ce descrie o anumită entitate.
Informaţia separată pentru fiecare entitate se prelucrează mult mai uşor dacă este depozitată
independent una faţă de alta. De exemplu, adresa şi serviciile comandate de clienţi se vor depozita în
diferite tabele, astfel ca la lichidarea comenzii informaţia despre client să se păstreze în BD.
La stabilirea câmpurilor pentru fiecare tabel este necesar să se ţine cont de următoarele:

1. Fiecare câmp are legătură cu informaţia stocată în tabel.

2. Denumirile (etichetele) câmpurilor descriu esenţa conţinutului.
3. În tabele nu se includ date care pot fi calculate în baza altor date.
4. Se recomandă evitarea îmbinării mai multor date în aceeaşi coloană (de exemplu, se
separă în coloane diferite numele şi prenumele ...).
Să analizâm tabelul Abonaţi (vezi LL nr.7, Figura 7.6) pentru a depista unele incomodităţi şi
neajunsuri.

Primul neajuns – dublarea datelor în tabel: în fiecare lună se introduce informaţia despre clienţi
(NP, adresa, sectorul, numărul contractului) şi pachete (denumirea pachetului, preţul şi numărul de
canale), deşi aceste date sunt constante.

Al doilea neajuns – dificultăţile care apar odată cu modificarea datelor. Dacă clientul îşi
schimbă adresa (sau adresa a fost scrisă greşit) va fi nevoie să se modifice informaţia în toate
înregistrările corespunzătoare din tabel, ceea ce este neefectiv.

Al treilea neajuns – dificultatea lichidării datelor. Dacă clientul refuză serviciile, atunci toată
informaţia ce se referă la datele personale ale clientului trebuie lichidată, însă în acest caz se pierde
şi informaţia despre achitarea serviciilor de către el, ceea ce nu este de dorit.

2
 Pentru a evita aceste neajunsuri, este necesar ca tabelul Abonaţi să fie divizat în mai multe
tabele, fiecare dintre care va conţine informaţia cu referire la o anumită entitate:

Pachete – informaţia despre pachete

Pachet Preţ pachet Nr. de canale

Abonaţi – informaţia despre clienţi

Nume Prenume Adresa Sector

Achitări – achitările efectuate de clienţi

Nr. de contract Suma spre achitare Data achitării Perioada de achitare

Figura 8.1. Tabelele BD la a doua etapă de proiectare

III) Stabilirea cheilor primare şi legăturilor dintre tabele.
Pentru ca mediul Access să combine datele amplasate în diferite tabele, ele trebuie să conţină
un câmp (sau un set de câmpuri) cu un identificator unic pentru fiecare înregistrare. Un astfel de
câmp (set de câmpuri) este numit cheie primară. Dacă pentru tabel s-a stabilit câmpul cheii primare,
aplicaţia Access exclude dublarea sau includerea valorilor NULL în acest câmp.
Legătura dintre tabele este bazată pe câmpul comun, indentic (după tipul de date) în ambele
tabele. De obicei, câmpul comun este cheia primară în tabelul de bază şi cheia străină în al doilea
tabel.
Să stabilim cheile primare şi străine pentru tabelele create:
Pachete – câmpul pachet este cheie primară.
Abonaţi – ar fi logic să stabilim cheia primară compusă pentru câmpurile nume şi prenume,
dar întrucât câmpurile conţin până la 30 de simboluri nu este comod a fi utilizat în calitate de câmp
de legătură cu alt tabel. Pentru identificarea fiecărei înregistrări, în tabelul Abonaţi includem câmpul
nr. de contract, stabilim acest câmp - cheia primară.
Câmpul pachet îl adăugăm în tabelul Abonaţi pentru a face legătura tabelului Abonaţi cu
tabelul Pachet. Câmpul pachet în tabelul Abonaţi – cheia străină.
Achitări – acest tabel va fi legat cu tabelul Abonaţi prin intermediul câmpului nr. de
contract. Câmpul nr. de contract în tabelul Abonaţi - cheia străină. Tabelul Achitări nu conţine cheia
primară.

3
 Pentru comoditate, câmpul luna (perioada de achitare) în tabelul Luni este definit ca cheie
primară. În continuare, tabelul Luni îl vom utiliza în calitate de lista lunilor.
Stabilim câmpul comun luna pentru combinarea tabelelor Luni şi Achitări.
După modificările efectuate, BD va arăta în modul următor:

Figura 8.2. Schema BD la etapa a treia de proiectare

Notă. Câmpurile cheie primară pe desen sunt subliniate.

8.2. CREAREA TABELELOR ÎN REGIM DESIGN

Exemplul 1. Vom considera o BD nouă, cu numele data2.accdb ce conţine 4 tabele conform

structurilor prezentate în Figura 8.2. Pentru câmpurile marcate se vor stabili setările proprietăţilor
câmpurilor prezentate în Figura 8.3-2.12 (vezi Anexa 4).
1. Se crează tabelul Pachete (vezi Figura 8.3).

Figura 8.3. Tabelul Pachete în regim Design

4
 2. Se crează tabelul Luni (vezi Figura 8.4).

Figura 8.4. Tabelul Luni în regim Design

Figura 8.5. Tabelul Abonaţi în regim Design

3. Se crează tabelul Abonaţi (vezi Figura 8.5). Pentru câmpul cheie străină – pachet din
tabelul Abonaţi se fixează tipul datelor Lookup Wizard…, astfel se crează o listă fixă cu valori pentru
acest câmp. În cazul dat, selectarea valorilor pentru câmpul pachet din tabelul Abonaţi se va face
direct din câmpul pachet aflat în tabelul Pachete. Pentru a crea lista derulantă, se vor urma
indicaţiile programului Wizard (Figura 8.6-8.11).
5
Figura 8.6. Caseta Lookup Wizard la pasul 1

Figura 8.7. Caseta Lookup Wizard la pasul 2

Figura 8.8. Caseta Lookup Wizard la pasul 3

6
Figura 8.9. Caseta Lookup Wizard la pasul 4

Figura 8.10. Caseta Lookup Wizard la pasul 5

Figura 8.11. Caseta Lookup Wizard la pasul 6

7
 4. Se crează tabelul Achitări (vezi Figura 8.12).

Figura 8.12. Tabelul Achitări în regim Design

5. Stabilind tipul datelor Lookup Wizard... pentru câmpul luna din tabelul Achitari, se
crează legătura dintre tabelele Luna şi Achitari (vezi p.3, crearea tabelului Abonaţi).

8.3. PROIECTAREA RELAŢIILOR DINTRE TABELE ŞI ADĂUGAREA DATELOR

Într-o BD relaţională, informaţia este divizată în tabele separate, bazate pe subiecte. De

exemplu, tabelele Pachete, Abonaţi, Luni. În acest caz, apare necesitatea de a relaţiona datele din
tabele pentru interogări, formulare şi alte obiecte. O relaţie potriveşte datele din câmpurile cheie
aflate în diferite tabele – câmpuri care deseori au acelaşi nume. Câmpurile respective sunt cheie
primară în tabelul ce formează un identificator unic pentru fiecare înregistrare şi cheie străină în
tabelul care permite repetarea înregistrărilor cu acelaşi identificator.
Relaţiile care se pot stabili între tabele sunt de următoarele tipuri[5,8,10]:
unu la unu (1:1) – presupune existenţa în ambele tabele a unei chei primare cu
aceleaşi caracteristici. Nu este practică şi se aplică rar, de exemplu, pentru a diviza un tabel care
include un număr mare de câmpuri sau pentru a ascunde informaţiile confidenţiale.
unu la mai mulţi (1:∞) – este folosită cel mai frecvent şi presupune că unei
înregistrări din tabelul primar (care include câmpul cheie primară) îi va corespunde mai multe
înregistrări din tabelul secundar (care include câmpul cheie străină). De exemplu, Pachete – tabel
primar şi Abonaţi – tabel secundar.

8
 de la mai mulţi la mai mulţi (∞:∞) – se caracterizează prin faptul că unei înregistrări
din tabelul primar îi corespunde una sau mai multe înregistrări din tabelul secundar, şi invers.
Deseori este transformată în două relaţii de tipul unu la mai mulţi prin definirea unui tabel
intermediar, în care se introduc, în calitate de chei străine, cheile primare ale primelor două tabele.
Aplicaţia Access permite utilizatorului să creeze două modele de relaţii:
relaţii permanente – se stabilesc după definirea tabelelor prin intermediul ferestrei de
dialog Edit Relationships şi sunt înregistrate în structura bazei de date;
relaţii temporare – se stabilesc între tabele la proiectarea interogarilor, nefiind
înregistrate în structura bazei de date.
La stabilirea relaţiilor permanente sau modificarea tipului de legătură avem posibilitatea să
definim parametrii integrităţii referenţiale a datelor (vezi Figura 8.16) [12]:
Enforce Referential Integrity (impune înregistrarea referenţială) – nu permite
modificarea şi lichidarea înregistrărilor tabelului primar care sunt relaţionate cu înregistrările
tabelului secundar, preântâmpină apariţia înregistrărilor în tabelul secundar ce nu corespund
înregistrărilor din tabelul primar.
Cascade Update Related Fields (reactualizarea în cascadă a câmpurilor legate) –
permite, ca la modificarea datelor din câmpul cheie primară amplasat în tabelul principal, să fie
modificate automat datele corespunzătoare din tabelele subordonate.
Cascade Delete Related Records (lichidarea în cascadă a inregistrarilor legate) –
permite, ca la lichidarea înregistrărilor din tabelul principal, să fie lichidate automat înregistrările
corespunzătoare din tabelele subordonate.

Exemplul 2. Pentru a defini integritatatea referenţială şi legătura permanentă dintre tabelele Abonaţi
şi Achitări se vor urma următorii paşi:
1. Din tab-ul Database Tools se apasă buton Relationships pentru a deschide fereastra
Relationships.
2. Automat se va deschide fereastra Show Table din care se adăugă cele patru tabelele
prezente prin dublu clic pe numele tabelului sau activarea butonului Add, în final fereastra se
închide. Repetat, fereastra Show Table, poate fi apelată apăsând butonul Show Table de pe ribbon
(vezi Figura 8.13).

9
 Figura 8.13. Grupul de comenzi Relationships

3. Legăturile formate cu ajutorul programului Lookup Wizard între tabelele Luni,

Achitări, Abonaţi şi Pachete sunt automat stabilite de sistem. Pentru a crea relaţia dintre tabelele
Abonaţi şi Achitări se vor face următoarele acţiuni:
- se selecteazăi câmpul contract din tabelul Abonaţi şi se deplasează în tabelul
Achitări, peste câmpul contract;
- se completează fereastra de dialog Edit Relationships pe care sistemul o afişează
automat, conform desenului 8.14, se finalizează cu activarea butonului Create. Ca rezultat (vezi
Figura 8.15), între tabele va fi creată legătura de tipul unu la mai mulţi (1:∞).

Figura 8.14. Fereastra de organizare a legăturilor dintre tabele

Figura 8.15. Fereastră Relationships

10
 4. Pentru ca BD să reţină legătura efectuată, la închiderea ferestre Relationships se
răspunde cu Yes la întrebarea de salvare a modificărilor efectuate.
Redactarea ulterioară a relaţiilor poate fi efectuată cu ajutorul comenzilor Edit
Relationship..., Delete incluse în meniul contextual apelat pentru linia de relaţie sau utilizând
comenzile incluse în grului Tools din tab-ul Design care apare pe ribbon sub Relationship Tools
(vezi Figura 8.16).

Figura 8.16. Tab-ul contextual Design

5. Tabelele se completează cu date (vezi Figura 8.17, 8.18).

Figura 8.17.Tabelele Pachet şi Luni în regim Datasheet

11
Figura 8.18. Tabelele Abonaţi şi Achitări în regim Datasheet

12