[TIP] Relatii intre tabelele unei baze de date Access

trucuri, sfaturi si alte idei pentru imbunatatirea lucrului cu Access
Închis
DR.ACCESS
Moderator
Moderator
Mesaje: 300
Membru din: Lun Sep 05, 2011 5:06 pm

[TIP] Relatii intre tabelele unei baze de date Access

Mesaj de DR.ACCESS » Mie Feb 05, 2014 9:58 am

La nivel de concept, relatiile intre tabele sunt de 3 tipuri:
1. unu la unu (1→1)
2. unul la mai multi (1→∞)
3. mai multi la mai multi(∞→∞)
Relatia 1→1
Sa presupunem ca avem un tabel angajati cu urmatoarele campuri (coloane): Marca_Ang, Nume_Prenume, Data nasterii, CNP, Adresa Acasa, Telefon acasa, Starea Civila, Studii, Data Angajarii, Salariul de incadrare, Functia, Departamentul.
ang 1.jpg
Doresc sa extrag, la un moment dat, un raport cu comenzile procesate de fiecare angajat. Voi face o interogare si… observ ca lucrurile se misca foarte greu. Interogarea merge incet si nu intelegem de ce. Pentru ca am cerut sa se faca o cautare prin toate campurile. O sa spuneti ca nu i-am cerut decat marca si numele! Daca nu am indexat coloanele, cautarea se face de la stanga la dreapta si de sus in jos, trecand prin toate liniile si prin toate coloanele. O suma impresionanta de procese. La fel si la Excel, la functiile de cautare!
Cum simplificam lucrurile? Vom scinda tabelul in doua. Unul Angajat_DatePersonale si altul Angajat_Date_Profeionale. Fiecaruia îi vom asigna cheia unica de identificare a angajatului astfel incat, fiecarui rand din fiecare tabel sa-i corespunda un angajat, si numai unul. E ceea ce intalnim, in limbaj tehnic, sub numele de “Cheie Primara”.
Apoi, in fereastra Relationship cream legatura intre cele doua tabele pe campul comun, Marca_Angajat.
ang 2.jpg

Functionalitatea originala nu se pierde, asa cum am fi inclinati sa credem. Campul de legatura ne permite sa “citim” datele cursiv, astfel ca, informatiile corespunzatoare unai Marci din ambele tabele, sunt privite la nivel logic ca fiind pe o aceeasi linie continua. Astfel ca putem “citi” numele dintr-un tabel si sa continuam cu toate informatiile asociate cheii comune in celalalt tabel. Ca functionalitate logica, ambele variante reprezinta acelasi lucru.
Ce ne surprinde in Access? Faptul ca relatia e semnalizata ca si cand ar fi de tip 1→∞. Nici nu vom vedea altfel. De aceea am spus inca de la inceput ca aceasta impartire se face “la nivel de concept”.

Relatia 1→∞

Aceasta relatie se stabileste intre doua tabele organizate astfel:
Un tabel (Parinte) de tipul Categorii care contine conform regulilor de organizare a datelor un singur rand pentru fiecare categorie in parte cu ID_categorie cheie unica de identificare (PK-Primary Key) si un alt tabel (Copil), sa zicem Produse, in care acem cate un rand pentru fiecare produs, o cheie unica de identificare a produsului, ID_produs si, un camp Categoria,in care introducem Id-ul categoriei din care face parte respectivul produs, camp pe care il regasim in literatura de specialitate sub denumirea FK-Foreign Key sau cheie secundara.
unu_multi.jpg
O asemenea relatie o “citim” dinspre tabelul copil, chiar daca vi se pare un pic “peste mana”. Adica, in momentul in care “citesc un rand din tabelul Produse si ajung la Categoria, e ca si cum in locul acelui numar asociat as avea tot randul corespunzator acelei categorii.
unu_multi2.jpg
Relatia poarta acest nume deoarece, unei inregistrari din tabelul Categoria îi corespund una sau mai multe in tabelul Produs (un id_categorie se poate regasi de mai multe ori pe coloana corespunzatoare din Produse).

Relatia ∞→∞

Ei, aici e aici! Mai ales ca fizic, in Access nu se poate realiza asa ceva doar cu Drag and Drop.
O asemenea relatie se stabileste, din punct de vedere logic, pe doua tabele in care corelatia dintre inregistrari e ceva de genul: unei inregistrari din primul tabel îi pot corespunde una sau mai multe din al doilea, si invers.
Sa zicem ca suntem in situatia Client-Produs. Am un tabel cu clientii, unul cu produse. Cum le legam? Stim ca un client poate comanda mai multe produse (daca produc unicate, relatia este unul la mai multi intre client si produse). In aceasta situatie (a produselor unicat) introduc in tabelul produse coloana cu codul clientului si gata. In practica insa, e putin probabil sa producem doar unicate si cum un produs poate fi comandat de mai multi clienti… cum facem legatura? Ca ar trebui si o relatie 1→∞ de la produs catre client. Pai, parca spuneam ca in tabelele respective scriem informatiile asociate unui client sau a unui produs o singura data! Si atunci, cum procedam? Vom crea un tabel “de legatura” care sa contina perechile de id-uri asociate client-produs comandat, ca in imagine
multi_multi.jpg
Avand datele organizate logic, fara duplicate a caror gestionare ne poate crea mari probleme pe viitor, putem realiza aplicatii functionale, putem raporta orice, oricand, si oricum!
Spor!
Nu aveţi permisiunea de a vizualiza fişierele ataşate acestui mesaj.
D. Tanase
MCT, MCTS
MOS Master Instructor

malasorte
Mesaje: 337
Membru din: Lun Ian 23, 2012 5:56 pm
Localitate: Galati

Re: [TIP] Relatii intre tabelele unei baze de date Access

Mesaj de malasorte » Sâm Iul 26, 2014 8:18 am

si dupa ce am realizat relationarea cu facem cu formularele sa le legam intre ele?

Tzica
Mesaje: 639
Membru din: Sâm Aug 11, 2012 10:52 pm

Re: [TIP] Relatii intre tabelele unei baze de date Access

Mesaj de Tzica » Dum Iul 27, 2014 7:08 pm

O sa incerc eu sa raspund, desi nu cred ca am inteles intrebarea.
Le putem construi "legate", in sensul sa fie vizibile , fie putem alege ca subformularul (tabelul copil) sa se deschida fie prin apasare de buton sau la declansarea unui event ( o comanda noua de exemple), dar pentru inceput sa alegem calea cea mai simpla, sa le vizualizam.
1.Putem sa ne folosim de Wizzard."Dezavantajul" e ca o sa pierdem foarte mult timp designul ulterior.Dar...ne ajuta sa intelegem mai bine procesul, functionarea a doua (sau mai multe) formulare legate intre ele prin chei (PrimaryKey / ForeignKey)
2.Putem sa-il construim noi.Ca sa ramanem in cadrul topicului, am construit un crochiu pentru Comenzi.E putin mai atipica, aceasta abordare, cei drept pentru subformulare folosesc DatasheetView.Am un formular principal, in care am introdus cele doua subformulare, iar legatura se face prin campul txtCL. Se poate remarca, faptul ca de fapt e vorba de CheiaPrimara a tabelului tblComenzi, care devine cheie straina(secundara) ForeignKey in tblDetComenzi.De obicei il ascund, dar ajuta la vizualizare.Click-aind pe un rand in formul principal (sbfrmComenzi) vedem cum se schimba cheia primara.In
Legaturile, se fac de regula, in foaia de proprietati, tab-ul Data, unde avem LinkMasterChild si LinkChilFields.
In fine, poate se revine cu intrebari punctuale.
Acuma, topicul fiind despre importanta cheilor/legaturilor in/intre tabele, adaug si eu faptul ca oricare din campurile dintr-un tabel parinte poate fi vizibil intr-un formular (sau raport) cu ajutorul functiei DLookUp.De asemenea ID-urile sunt importante in cazul in care folosim functiile globale (DSum,DCount) pentru partea de criterii.
Nu aveţi permisiunea de a vizualiza fişierele ataşate acestui mesaj.

Închis

Înapoi la “Tips and tricks in Access (indiferent de versiune)”