Biologie | Chimie | Didactica | Fizica | Geografie | Informatica | |
Istorie | Literatura | Matematica | Psihologie |
Interogari in Access
Cererile reprezinta obiectul prin care se extrag informatii dintr-o baza de date. O cerere actioneaza fie asupra unui tabel, fie asupra mai multor tabele corelate prin relatii.
Cateva dintre cele mai importante caracteristici ale unei cereri sunt:
- Tabelele si relatiile care stau la baza unei cereri reprezinta subschema cererii.
- Extragerea de informatii din cereri se face prin operatii de algebra relationala pe multimi.
O interogare (query) este o definitie a datelor care se extrag: care campuri din tabele, din ce tabele, criteriile de selectie, ordinea de sortare. Structura unei interogari indica datele care se vor extrage, Microsoft Access oferind urmatoarele posibilitati:
- selectarea anumitor campuri mai semnificative din inregistrarile unei tabele;
- selectarea inregistrarilor care satisfac anumite criterii;
- sortarea inregistrarilor intr-o ordine precizata de utilizator;
- interogarea mai multor tabele; o interogare permite combinarea inregistrarilor din mai multe tabele si afisarea rezultatului intr-un singur tabel de date;
- interogarea altor baze de date existente in sisteme de gestiune a bazelor de date cum sunt FoxPro, Paradox, dBase, Microsoft SQL Server;
- crearea de campuri pentru afisarea rezultatelor unor calcule;
- crearea de rapoarte, formulare sau alte interogari.
In functie de efectul pe care il are executia unei cereri - deci care va fi rolul informatiile obtinute, exista:
Cererea de selectie - rezultatul acesteia este crearea unui tabel virtual, care se va manifesta in prelucrarile urmatoare ca un tabel obisnuit. De aici se poate deduce ca cererile pot accepta la intrare alte cereri(de selectie). De obicei aceste cereri reprezinta partea de intrare a unui raport
Cererea de actiune - rezultatul acestei cereri va duce la modificari directe in baza de date(actualizari de date sau crearea(modificarea) de structuri de tabele)
In principal, putem considera cererile grupate in mai multe categorii, dupa efectul executiei lor. In continuare sunt prezentate aceste tipuri de cereri:
Cereri care nu modifica datele din tabelele bazei de date
2. Cereri care modifica datele din tabelele bazei de date, denumite cereri actiune |
Observatii:
- Cele patru cereri SQL Specific(Union Query, Pass-Through Query, Sub-Query, Data Definition Query), se scriu direct in SQL.
- Cererea de tip Select, are caracteristici care se regasesc la majoritatea celorlalte tipuri de cereri.
- Pentru simplificarea proiectarii sau modificarii unei cereri, Access pune la dispozitie un instrument grafic, care se numeste QBE(Query By Example).
Interogarile de selectie extrag informatii din unul sau mai multe tabele si le afiseaza sub forma de lista. Sunt cel mai usor de creat si au avantajul ca pot afisa un numar redus de date dintr-un tabel de mare capacitate (datele care indeplinesc conditiile specificate). Ele permit si modificarea rezultatului afisat, modificare ce va fi vazuta si in tabelul sursa. De asemenea, permit si folosirea de parametri, cum este reuniunea de campuri din tabele intre care nu exista nici o legatura.
Interogarile incrucisate centralizeaza in formatul unei foi de calcul tabelar datele din unul sau mai multe tabele. Datele rezultate dupa executia unei astfel de interogari sunt prezentate intr-un format potrivit pentru analiza datelor si crearea de grafice.
Interogarile de actiune creeaza un nou tabel in baza de date sau realizeaza modificari majore ale unui tabel existent. In general, toate interogarile de actiune pot fi realizate pe baza unei interogari de selectie. Ele permit adaugarea, modificarea sau stergerea de inregistrari intr-un tabel. Exista patru tipuri de interogari de actiune:
. interogari de generare a unui nou tabel din datele continute in setul de rezultate al interogarii;
. interogari de adaugare a noi inregistrari intr-un tabel;
. interogari de stergere a unor inregistrari dintr-un tabel;
. interogari de actualizare a unor inregistrari dintr-un tabel, conform cu o conditie ce trebuie indeplinita.
Actiunile acestora sunt ireversibile asupra datelor din tabelele sursa, iar in cazul ultimelor trei dintre ele, trebuie urmarita pastrarea integritatii referentiale atunci cand prin intermediul lor se actioneaza asupra mai multor tabele legate.
Interogarile parametrice nu sunt un tip special de interogari, o functie parametru putand fi folosita pentru toate celelalte interogari prezentate mai sus; ele folosesc in mod repetat o interogare, efectuand modificari in criteriile de selectie.
Microsoft Access include patru modalitati de creare a unei interogari:
1. automat (Query Wizard);
2. manual (Query Design);
3. comenzi SQL;
4. prin program(bibliotecile ActiveX Data Objects, Data Microsoft Access Objects si obiectele QueryDef)
Crearea interogarilor utilizand Query Wizard, este posibila atat pentru interogarile de selectie cat si pentru interogarile incrucisate.
Prin actionarea butonului New, se va deschide o fereastra care permite alegerea urmatoarelor modalitati de creare a unei cereri:
Figura 5.. Crearea unei cereri
Simple Query Wizard este destinat pentru crearea de interogari de selectie in principiu dintr-un singur tabel, dar poate afisa date din doua sau mai multe tabele si interogari intre care exista sau nu legaturi directe. Printre optiunile puse la dispozitia utilizatorului sunt si cele de adunare/contorizare a datelor din campurile ce contin valori numerice.
Figura 5.2 Fereastra Simple Query Wizard
Crosstab Query Wizard Pentru interogarile incrucisate, Microsoft Access dispune de un program Wizard dedicat. In aceast tip de interogare se stabilrdv randurile, coloanele si functia de calcul pentru determinarea unei valori ce se va situa la intersectia dintre linii si coloane. Crosstab Query Wizard este restrictionat de posibilitatea de a totaliza date doar dintr-un singur tabel.
Figura 5.3 Fereastra Crosstab Query Wizard
Find Duplicates Query Wizard este interogarea care localizeaza inregistrarile ce contin valorile duplicat dintr-un anumit camp. Este o interogare extrem de utila atat in gestionarea cresterii dimensiunii unui tabel, prin evitarea incarcarii inutile cu date duble, cat si pentru stabilirea pe parcurs a unui camp drept cheie primara, atunci cand inregistrarile duplicat nu permit acest lucru. In figura 5.4 este prezentat unul dintre ecranele de lucru al acestui program, in care s-a ales campul pentru care se doreste cautarea de duplicate.
Figura 5.4 Fereastra Fiind Duplicates Query Wizard
Find Unmatches Query Wizard. Daca interogarea ce gaseste duplicatele este utila pentru eliminarea inregistrarilor duble ca urmare a unor erori de introducere, interogarea Find Unmatches Query Wizard(cea care gaseste valorile nepotrivite) localizeaza inregistrarile asociate care nu mai au o inregistrare principala corespondenta ca urmare a erorilor de stergere si care afecteaza integritatea referentiala.
Cele patru programe Wizard sunt extrem de utile si de facile in utilizare, dar destul de limitate pentru a face fata tuturor cerintelor unei baze de date de dimensiuni mari.
Figura 5.5 Fereastra Find Unmatches Query Wizard
Design View. Crearea manuala a interogarilor se realizeaza prin intermediul optiuni Query Design care foloseste pentru interfata grafica Query by Example (QBE). Aceasta permite si utilizatorilor care nu stiu limbajul de programare QBE sa gaseasca si sa afiseze informatiile de care au nevoie.
Odata activata optiunea Query Design, Microsoft Access va considera implicit ca orice generare a unei noi interogari este o interogare de selectie. Transformarea tipului de interogare implicit se face prin selectarea tipului dorit din meniul Query
O cerere se poate afla in una din urmatoarele trei stari:
Proiectare - Design View.
Vizualizare - Datasheet View.
Instructiune SQL - SQL View.
Trecerea de la o stare la alta se poate face prin pictograma specifica de pe ToolsBar sau din meniul contextual.
1 Construirea interogarilor prin QBE(Query By Example)
Modulul Query, se lanseaza din fereastra Database, prin selectarea paginii corespunzatoare acesteia (la fel ca la tabele). Pentru simplificarea proiectarii sau modificarii unei cereri, Access pune la dispozitie un instrument grafic, care se numeste QBE(Query By Example).
Cu QBE, se pot defini toate tipurile de cereri acceptate de Access, cu exceptia cererilor SQL Specific. Formularul QBE este constituit din doua parti:
definirea intrarii cererii
definirea prelucrarilor efectuate.
1.1 Schema utilizata de o cerere
Pentru a crea o noua interogare in modul Query Design, se vor parcurge urmatorii pasi:
selectarea tabelelor din care se doresc a fi afisate/prelucrate datele, prin intermediul ferestrei Show Table;
Figura 1.1.1 Fereastra Show Table
selectarea campurilor care se vor transforma in coloanele tabelului rezultat al interogarii;
stabilirea criteriilor de selectie si a campurilor asupra carora vor fi aplicate; se poate apela la un singur criteriu de selectie sau la mai multe criterii, aplicate fie unor campuri diferite, fie formand un criteriu compus aplicat aceluiasi camp;
stabilirea parametrilor de selectie. Parametrii functioneaza pentru interogari asemanator criteriilor de selectie, cu deosebirea ca la fiecare executie trebuie specificata valoarea parametrului in functie de care se va realiza selectia;
stabilirea tipului de sortare a datelor afisate ca rezultat si a campurilor asupra carora va actiona;
specificarea formulei pentru campurile care sunt rezultatul unor operatii executate asupra unora dintre campurile deja existente. Acest lucru se poate face fie prin scrierea directa a formulei, fie prin apelarea la generatoarele de functii pentru calcule mai complicate sau care folosesc functii definite deja in Microsoft Access;
alegerea tipului de interogare prin selectarea din meniul Query a uneia dintre optiunile: interogari de selectie, interogari incrucisate, de generare a unui tabel, de adaugare intr-un tabel, de stergere dintr-un tabel, de actualizare a unui tabel. In functie de optiunea aleasa, Microsoft Access modifica designul interogarii si cere informatii suplimentare astfel:
pentru generarea unui tabel - numele tabelului ce urmeaza a fi creat;
pentru adaugarea intr-un tabel - numele tabelului ce urmeaza a fi incarcat cu date, precum si campurile destinatie;
pentru actualizare - conditiile de actualizare si valoarea la care se doreste actualizarea;
pentru stergere - numele tabelului din care se va sterge si conditia de stergere.
Formularul QBE contine in partea superioara tabelele si relatiile dintre acestea, iar in partea inferioara, definitia iesirii cererii(selectia, proiectia si alte actiuni specifice). O data cu introducerea tabelelor se vor aduce automat si relatiile permanente existente intre tabelele respective. Aceste relatii se pot insa modifica in cerere prin lansarea meniului contextual al relatiei si alegerea optiunii Join Properties prin care se alege tipul de legatura al relatiei respective(Inner Join sau Outer Join). Meniul contextual al relatiei contine doua comenzi
- Join Properties - pentru schimbarea tipului de legatura al relatiei;
- Delete - pentru stergerea relatiei.
Figura 1.1.2 Schema utilizata de o cerere
1.2 Proiectarea iesirii unei cereri
Randurile care trebuiesc completate in QBE al unei cereri sunt prezentate in figura urmatoare. La acestea se poate adauga, eventual, randul cu clauza Total.
Field | |||
Table | |||
Sort | |||
Show | |||
Criteria | |||
Or |
Indiferent de tipul de cerere, se vor efectua urmatoarele operatii:
Includerea campurilor care ne intereseaza in construirea cererii se face prin "tragerea" lor cu ajutorul mouse-ului din tabelele din caseta de sus in randul Field al casetei de jos sau prin executarea unui dublu-clic pe denumirile respective sau prin alegerea din listele derulante, realizandu-se in acest fel 'proiectia' schemei. In felul acesta se completeaza primele doua randuri din QBE, si anume:
Field - numele campului care se trage.
Table - tabela din care provine campul.
Exista posibilitatea ca din tabela sa se traga caracterul (*) - ceea ce duce la preluarea tuturor campurilor tabelei.
Asa cum se observa in figura de pe pagina anterioara(1.1.2), din caseta de selectie a campului se poate lansa prin metoda obisnuita (clic dreapta), meniul contextual al campului, si din acesta proprietatile campului.
Acestea(vezo figura 1.2.1), sunt o parte din proprietatile campurilor stabilite la crearea tabelei si evident - conform a ceea ce am mai aratat referitor la domeniul de valabilitate al setarilor in Access - ele vor fi valabile si in cererea la care participa tabela respectiva, putand fi eventual modificate, dar numai la nivelul obiectului curent
Figura 1.2.1 Proprietatile campurilor
Se marcheaza in randul Show campurile pe care utilizatorul doreste sa le aiba la iesirea din cerere. Acest lucru se datoreaza faptului ca la o cerere, pot participa campuri necesare la prelucrarile efectuate, dar care nu mai sunt necesare in continuare. De exemplu se pot folosi unele campuri care trebuie sa indeplineasca o anumita conditie, fara a fi necesara vizualizarea lor la iesirea din cerere.
In randul Sort, se stabileste cu ajutorul listei derulante a acestuia, daca se doreste ordonarea datelor la iesirea din cerere dupa un anumit camp (campuri), si ordinea, Ascending sau Descending. Daca exista mai multe campuri astfel marcate, atunci ordinea de sortare a acestora, va fi de la stanga la dreapta - campul plasat cel mai in stanga fiind deci primul dupa care se va efectua aceasta operatie.
Criteriile de selectie, se introduc cu ajutorul randurilor Criteria si Or (se pot introduce mai multe randuri Or). Prin acestea se va face o selectie a randurilor(inregistrarilor) care vor apare la iesirea din cerere. Principiul de constituire a criteriilor de selectie este urmatorul:
- In dreptul fiecarui camp, se poate introduce in randurile specificate mai sus, o regula de selectie la care participa acesta (asemanatoare cu cea prezentata la proprietatea Validation Rule, de la campurile tabelelor)
- Mai multe reguli scrise pe acelasi rand vor fi legate prin functia logica AND.
- Doua randuri de reguli, vor fi legate prin functia logica OR.
Practic, in campul Criteria vom defini propriile restrictii care pot fi de genul: mai mare decat o anumita valoare, mai mare sau egal, mai mic sau egal, mai mic, egal sau diferit de o valoare. Vom putea crea si expresii logice cu ajutorul operatorilor logici And si Or.
1.3 Cereri cu campuri calculate
Exista posibilitatea ca un anumit camp din QBE sa nu provina dintr-o tabela sau o cerere ci sa fie introdus printr-o expresie. Pentru construirea unui camp calculat se va folosi urmatoarea sintaxa :
NumeCamp : Expresie
1.4 Cereri cu parametri
In expresiile scrise in QBE sunt admisi parametrii. Acestia sunt niste nume care se initializeaza cu o valoare corespunzatoare, numai in momentul executarii cererii, printr-un dialog initializat de sistem cu utilizatorul. Astfel, valoarea introdusa de utilizator in momentul executarii cererii va inlocui numele parametrului, in calcularea respectivei expresii.
Numele unui parametru, trebuie sa fie diferit de numele campurilor folosite in cerere si trebuie scris intre paranteze drepte.
Implicit parametrii sunt considerati de tip Text. Daca se doreste ca un parametru sa fie de un alt tip de data, se deschide fereastra Parameters, din meniul contextual al ferestrei QBE, ori prin pictograma specifica, sau din meniul Query si se declara in mod explicit tipul parametrului, ca in exemplul alaturat.
Figura5.1.4.1
Fereastra Parameters
1.5 Cereri cu clauza TOTALS
In multe cazuri apare necesitatea de a obtine valori rezumative referitoare la toate inregistrarile din tabel sau pentru o submultime a lor. Clauza TOTALS se poate introduce in QBE din ToolsBar, din meniul View sau din meniul contextual al zonei de prelucrare a cererii. Ea se poate aplica la toate cererile(mai putin Delete si Update). In urma alegerii acestei clauze, in zona de prelucrare a cererii apare randul Total.
Efectul acestei clauze este :
Dupa ce conditiile de selectie de inregistrari ale cererii au fost rezolvate(tipul legaturii si criteriile), datele sunt grupate dupa campul, care in clauza Total, are introdus Group By. Acest lucru inseamna ca toate inregistrarile care au in campul respectiv aceiasi valoare vor fi grupate, urmand ca in urma prelucrarilor efectuate ele sa constituie o singura inregistrare la iesirea din cerere. Se pot introduce pentru mai multe campuri valoarea Group By in randul Total, ceea ce va duce la constituirea de grupe si subgrupe, ordinea fiind - ca si la sortare - de la stanga la dreapta.
Aceasta inregistrare va avea in celelalte campuri valori calculate cu functii agregate SQL - functii al caror domeniu de intrare este constituit din datele unui camp din mai multe inregistrari. Deci, domeniul acestor functii va fi constituit din inregistrarile care au aceiasi valoare in campul Group By. Valoarea NULL, nu este luata in consideratie in calculul functiilor agregate (Atentie! - nu este echivalenta cu zero).
In randul Total, in afara de Group By sau functiile agregate SQL, se mai pot introduce urmatoarele valori:
Where - Camp care nu se va regasi la iesire(se va debifa automat randul Show) si care este folosit numai la introducerea unor criterii.
Expression - Camp calculat, dar obligatoriu cu ajutorul uneia sau mai multor functii agregate SQL.
1.1 Functii agregate SQL
Functiile agregate SQL sunt valabile in cereri, fie in randul Total, fie in campurile calculate.
Figura 1.1.1 Randul Total
In Access exista urmatoarele functii agregate SQL:
Sum, pentru calcularea sumei valorilor campului;
Avg, pentru calcularea mediei aritmetice a valorilor campului;
Min, pentru gasirea valorii minime;
Max, pentru gasirea valorii maxime;
Count, calculeaza numarul de valori ale campului (excluzand-le pe cele vide);
StDev, pentru calcularea deviatiei standard;
Var, pentru calcularea dispersiei;
First, pentru gasirea primei valori a campului respectiv, conform ordinii de sortare active;
Last, pentru gasirea ultimei valori a campului respectiv, conform ordinii de sortare active;
Functiile First si Last nu sunt valabile decat in randul Total - deci nu se pot aplica in campurile calculate.
In campurile calculate, sintaxa pentru functiile agregate este: functie(expresie).
in care:
- expresia identifica campuri (sau parametrii).
- campul trebuie sa apartina schemei cererii si daca exista ambiguitate, trebuie calificat cu numele tabelei din care provine.
1.6 Salvarea, modificarea, stergerea si inchiderea unei interogari
Pentru a salva o interogarea creata cu ajutorul constructorului de interogari vom apela functia Save din meniul File, sau vom apasa butonul corespunzator existent pe bara de instrumente, sau vom apasa tastele Ctrl+S. Pe ecran va aparea fereastra Save As in care vom introduce numele dorit pentru interogare.
Daca vrem putem modifica o interogare adaugand atat restrictii noi cat si tabele noi. Pentru aceasta vom selecta mai intai interogarea dorita, apoi vom apasa pe butonul Design. Pe ecran va aparea constructorul de interogari. Pentru a adauga o tabela noua interogarii, vom selecta din meniul Query optiunea Show Table sau vom apasa butonul existent pe bara de instrumente a aplicatiei, iar pe ecran va aparea o fereastra din care ne vom putea alege tabela dorita.
Pentru a inchide o interogare vom apasa butonul existent in partea dreapta a ferestrei sau vom apela functia Close din meniul File.
Pentru a sterge o interogare vom apasa butonul existent in partea de sus a ferestrei bazei de date dupa ce am selectat in prealabil interogarea dorita sau vom da clic dreapta pe interogarea pe care dorim sa o stergem si vom alege optiunea Delete din meniul aparut sau vom selecta interogarea si apoi vom apasa butonul Delete existent pe tastatura. Pe ecran va aparea o caseta de dialog care ne va cere sa confirmam stergerea interogarii (optiunea Yes pentru stergere, optiunea No pentru anularea stergerii).
2 Proprietatile cererii
Numele cererii se stabileste dupa crearea acesteia in urma unei intrebari explicite facuta de sistem, sau se modifica(ca de altfel orice nume de obiect) din fereastra Database, prin metodele folosite in Windows. (la fel ca la tabele sau ca la orice obiect de rang superior nou creat)
Fereastra de setare a proprietatilor unei cereri se lanseaza din meniul contextual al ferestrei QBE.
Figura 2.1 Proprietatile unei cereri
Dintre proprietatile prezentate, ne vom referi in acest moment numai la cateva, si anume:
Output All Fields - Setata pe Yes, toate campurile din tabelele(cererile) din subschema QBE, vor fi selectate.
Top Values - Limiteaza la un anumit numar (sau procent) inregistrarile care vor fi preluate.
Unique Values - Exista posibilitatea ca in urma proiectiilor efectuate asupra subschemei cererii, la iesirea din aceasta, pot aparea mai multe inregistrari identice (toate campurile din respectivele inregistrari au aceiasi valoare). Setarea acestei proprietati la Yes, face ca la iesire sa nu existe inregistrari la fel. Deci, aceasta proprietate se aplica la iesirea cererii.
Unique Records - Aceasta proprietate este valabila, numai in cazul in care cererea lucreaza cu mai multe tabele (cereri). Si in acest caz, este posibil, ca la intrarea in cerere sa existe inregistrari identice, pentru toate campurile schemei (si nu numai pentru cele care se vor regasi la iesire). Setarea pe Yes a acestei proprietati, elimina duplicatele la intrarea in cerere.
Observatia 1. Numai una din cele doua proprietati Unique poate fi Yes.
Observatia 2. Rezultatul unei cereri trebuie privit ca o tabela virtuala. Practic o cerere creeaza un filtru prin care se poate ajunge la tabelele originale, urmand ca in momentul in care folosim o cerere sa lucram cu campurile din tabelele originale. Deci, o modificare a unui camp dintr-o cerere, va duce la modificarea campului respectiv in tabela originala.
Evident, modificarea unui camp a unei inregistrari dintr-o cerere se poate face numai daca acest camp poate fi identificat intr-o inregistrare din tabela originara. In cazul setarii pe Yes a uneia din proprietatile Unique, aceasta identificare a sursei datelor nu mai poate fi facuta, astfel blocandu-se posibilitatea modificarii campurilor (acelasi lucru e valabil si la campurile calculate).
Source Database
Source Connect Str
Prin aceste proprietati, se poate crea o cerere folosind tabele (fara sa fie importate) care se afla in exteriorul bazei de date curente, in format JET, ISAM sau ODBC. Pentru a folosi tabelele sau cererile unei alte baze de date Access (format Jet), se va introduce in Source Database, calea si numele (fisierul .mdb) acesteia (in Source Connect Str nu se va introduce nimic). In acest caz, cand se va lansa fereastra Show Table, vor aparea tabelele si cererile bazei de date Jet externe, care vor constitui deci, subschema cererii.
Pentru a folosi tabelele unei baze de date in format ISAM, se va introduce in Source Database, calea directorului unde se afla aceasta, iar in Source Connect Str se va introduce tipul bazei de date. In acest caz, cand se va lansa fereastra Show Table, vor aparea tabelele bazelor de date ISAM, care se gasesc in directorul respectiv.
Exemplu: In exemplu de mai jos se arata modalitatea prin care se poate crea in Access o cerere care sa fie definita folosind o subschema formata numai din fisiere DBF, create in FoxPro.
Nu uitati ";" la sfarsit
3 Tipuri de cereri
In continuare vor fi prezentate cele mai utilizate tipuri de cereri.
Select Query
'Select Query', este cea mai utilizata cerere din aplicatiile realizate in Access. Ea consta din proiectia si selectia campurilor si inregistrarilor din schema cererii, in vederea extragerii unor informatii din baza de date, care pot fi utilizate in alte module ale aplicatiei sub forma unui tabel virtual. Este folosita foarte des ca suport pentru realizarea rapoartelor (pentru prezentarea datelor), a formularelor (pentru introducerea datelor), ca intrare pentru alte cereri, in controale, etc.
Executia cererii Select Query, nu modifica direct datele din schema. Totusi, dupa executia cererii, datele afisate prin intermediul ferestrei Datasheet, daca au o adresa precisa, unica in inregistrarile si campurile bazei de date, pot fi modificate de catre operator(lucru care nu se intampla intotdeauna; de exemplu in cererile cu clauza 'Total' sau campurile calculate).
Exemple: Vom urmari ordinea si felul in care sistemul va prelucra (executa) o cerere Select Query in care:
- Schema este formata din doua tabele, PRODUSE si MISCARE;
- Relatia intre tabele este de tip one to many, fiind creata intre campurile Cod (cod produs)
- Tipul de legatura a relatiei (Inner Join) este nesemnificativ deoarece, asa cum se observa, nu exista valori ale campului de legatura care sa nu se gaseasca in ambele tabele
Se selectioneaza si coreleaza inregistrarile conform relatiei si tipului de legatura. In urma acestei operatii se va crea o prima tabela intermediara virtuala, prezentata mai jos:
Cod |
Denumire |
Pret |
UM |
Input |
Output |
Data |
Imprimanta |
buc | |||||
Imprimanta |
buc | |||||
Imprimanta |
buc | |||||
CD-ROM |
Buc | |||||
Televizor |
Buc | |||||
Televizor |
Buc | |||||
Calculator |
Buc |
Daca exista in aceasta tabela virtuala, doua sau mai multe inregistrari identice(ceea ce nu este cazul in exemplul nostru), cele duble vor fi eliminate daca proprietatea cererii: Unique Records este setata.
1. Se vor opera pe tabela intermediara obtinuta, proiectia si selectiile precizate in cerere. Daca vom avea o cerere care in partea de jos a formularului QBE, va avea structura de mai jos atunci aceasta cerere va produce o noua tabela intermediara virtuala dupa aceste prelucrari.
a) Campurile preluate sunt: [Denumire], [Pret], [Input], [Output],[Data];
b) Criteriul de selectie este ca data sa fie cuprinsa in intervalul [4/14/2005 .. 12/30/2005];
c) In tabela virtuala de iesire inregistrarile vor fi sortate crescator dupa campul [Denumire];
d) Campul [Data] va fi folosit numai pentru selectie, el nefiind trimis la iesire.
Rezultatul acestei cereri de selectie este dat de toate inregistrarile tabelei virtuale anterioare care indeplinesc conditia ca [Data] sa fi cuprinsa intre 4/14/2005 si 12/30/2005:
Daca exista in aceasta tabela virtuala, doua sau mai multe inregistrari identice(ceea ce nu este cazul in exemplul nostru), cele duble vor fi eliminate daca proprietatea cererii: Unique Value este setata.
2. Daca vom avea o cerere care in partea de jos a formularului QBE, va avea structura de mai jos atunci aceasta cerere va produce o noua tabela intermediara virtuala dupa aceste prelucrari. Se observa ca avem o cerere de selectie cu clauza Totals, unde vom avea datele grupate dupa campul [Denumire], si pentru fiecare grup vom calcula numarul intrarilor(suma dupa campul [Input]) cu conditia ca data sa fie in intervalul [2/22/200.12/30/2005]. Este o cerere cu camp calculat deoarece se observa in coloana a patra din zona de prelucrare a cererii ca avem un camp format aplicand o functie agregata si o operatie aritmetica asupra altor campuri
Vom arata mai jos cum se formeaza la iesire una dintre inregistrari, si anume aceea cu: [Denumire]= "Imprimanta". Din cele doua tabele sunt selectionate mai intai inregistrarile, conform relatiei si tipului de legatura al acesteia.
Pentru inregistrarea cu [Denumire]= "Imprimanta", se vor selectiona si corela pentru iesire, inregistrarile care au [Cod Produs]=1, formandu-se in prima instanta inregistrari virtuale ca in tabelul de mai jos.
Cod |
Denumire |
Pret |
UM |
Input |
Output |
Data |
Imprimanta |
buc | |||||
Imprimanta |
buc | |||||
Imprimanta |
buc |
Se aplica criteriului de selectie de la campul "data":between #2/22/2005# And #12/30/2005# In urma acestei operatii se elimina prima inregistrare deoarece are data in afara intervalului de selectie.
a) Observam introducerea cu clauza Where, a acestui criteriu, deoarece nu se doreste aparitia datei la iesire(de altfel nu are nici sens).
b) Se aplica proiectiile impuse de campurile selectionate, fiind eliminate celelalte campuri(cele prezentate in tabelul de mai sus cu litere neingrosate)
c) Din inregistrarile ramase se face o grupare pe campul [Denumire] - deoarece are clauza Group By.
d) Pentru toate inregistrarile care au [Denumire]= "Imprimanta" (inregistrarile de pe pozitiile: 2 si 3), se va obtine la iesire o singura inregistrare care va avea:
In campul: [Denumire], valoarea "Imprimanta";
In campul de iesire: [Input], se va calcula numarul acestora:adica 2
Campul calculat de iesire: [Val]=Sum([Input]*[Pret]) a fost introdus in cerere prin introducerea in randul de Total a clauzei Expression. Dupa executia cererii acest camp va avea valoarea 4500.
Pentru a calcula aceasta valoare sistemul va proceda astfel:
pentru inregistrarile selectionate se calculeaza:
[Input]*[Pret] adica:500*4=2000 si 500*5=2500
- Se aplica functia agregata Sum(insumare), pe valorile calculate anterior, adica:
sum(2000,2500)=4500
Celelalte inregistrari de iesire se vor calcula dupa aceiasi metoda. In urma acestor operatii tabela virtuala de iesire va arata ca in figura:
3.2 Crosstab Query
Access permite gruparea si reprezentarea datelor intr-o forma compacta, forma care se aseamana cu un tabel electronic. In acest scop se definesc interogari speciale, numite interogari incrucisate (Crosstab Query).
Crosstab Query(cerere incrucisata) este o cerere de selectie cu clauza Total, prin care se introduc doua grupe prin optiunea Group By. Afisarea prin fereastra Datasheet este insa diferita, luand forma unei table de sah, deoarece valorile pe care le iau datele pentru cele doua grupe vor fi prezentate una ca denumiri ale coloanelor si cealalta ca denumirea randurilor. Exista posibilitatea ca sa se introduca pe randuri mai multe subgrupe, dar maxim 3.
Cererea Crosstab se construieste pornind de la o cerere Select dupa care se selecteaza optiunea Crosstab din meniul Query. Ca rezultat, titlul ferestrei se schimba in Crosstab Query, iar in partea de jos apare randul Crosstab.
Formularul QBE care trebuie completat in cazul acestei cereri, va avea pe langa un rand obisnuit cu clauza Total, un rand specific, cu clauza Crosstab.
Field | |||
Table | |||
Total | |||
Crosstab | |||
Sort | |||
Criteria | |||
Or |
Randul cu clauza Crosstab trebuie completat obligatoriu cu unul din urmatoarele cuvinte:
Column Heading denumirile(titlurile) coloanelor reprezinta practic grupele pe care poate sa le ia un camp. Campul caruia i se atribuie aceasta caracteristica este obligatoriu sa fie camp de grupare definit in clauza Total cu optiunea Group By. Valorile pe care le vor lua datele pentru aceasta grupa vor constitui chiar titlurile(numele) coloanelor cererii Crosstab.
Row Heading - denumirile(titlurile) randurilor - reprezinta la fel ca si la coloane valorile pe care poate le ia un camp din tabela, declarat ca grupa prin clauza Total. In tabelul virtual obtinut dupa executia cererii, datele din aceasta coloana vor arata la fel ca la o cerere obisnuita cu clauza Total. Se pot declara mai multe campuri cu optiunea Row Heading(maxim trei).
Value se atribuie unui camp pentru care se va calcula o functie agregata SQL, care are ca domeniu de definire inregistrarile din ultima subgrupa definita(cea mai din dreapta grupa scrisa in QBE). Afisarea acestei valori in tabela virtuala de iesire se va face chiar la intersectia dintre un rand si o coloana care definesc practic grupa si subgrupa respectiva pentru care s-a calculat functia agregata SQL.
Not Shown se atribuie unui camp care nu va aparea la iesire dar care va fi folosit intr-un criteriu de selectie.
Exemplu: Cu datele din cele doua tabele "PRODUSE" si "MISCARE" se face o cerere crosstab, cu doua grupe, una cu rezultatele pe randuri([Denumire]), cealalta cu rezultatele ca denumiri de coloane ([Pret]). Functia agregata, SUM, se va calcula pe campul [Input].
Rezultatul obtinut in urma executiei acestei cereri va fi afisat sub forma unei tabel de sah, unde datele
sunt grupate dupa denumirea produselor si afisate in capetele de linii,
sunt grupate dupa pretul produselor si acestea sunt afisate in capetele de coloane,
La intersectia dintre linii si coloane se va afisa suma intrarilor produselor din grupele selectionate acest lucru realizandu-se prin stabilirea in randul Total a functiei agregate Sum iar in randul Crosstab a optiunii Value.
In cazul care care adaugam si o conditie cum ar fi [Pret]>400 atunci se vor afisa:
Denumire | ||
Calculator | ||
Imprimanta |
3.3 Union Query
Union Query este o cerere de selectie care permite obtinerea la iesire a unui tabel virtual care sa contina reuniunea(toate inregistrarile a doua tabele) a doua sau mai multe Select Query, care au aceleasi campuri. Este o cerere care nu se poate crea decat direct prin SQL. Realizarea ei este totusi destul de simpla, procedandu-se astfel:
1. Se defineste prin QBE prima cerere de selectie.
2. Se trece aceasta in forma SQL si se copiaza prin comanda obisnuita 'Copy', textul afisat.
3. Se face o noua cerere si i se stabileste tipul Union, prin meniul contextual sau din comanda Query de pe meniul principal urmat de SQL Specific | Union Se observa ca cererea nu va avea decat forma SQL.
4. Se face 'Paste' pe aceasta a textului cererii create la punctul 1 si preluat anterior cu 'Copy'. Se sterge semnul punct si virgula (;) de la sfarsit, care semnifica sfarsitul unei declaratii SQL.
Se tasteaza in continuare Union si eventual ALL. Exista posibilitatea ca din reuniune, sa se obtina la iesire inregistrari duble. Acestea in mod obisnuit sunt eliminate. Daca totusi se doreste pastrarea tuturor inregistrarilor, atunci se va introduce in instructiunea SQL cuvantul ALL
6. Se defineste prin QBE a doua cerere de selectie, care trebuie sa aiba aceleasi campuri de iesire cu a celei dintai.
7. Se trece si aceasta in forma SQL si se copiaza prin comanda 'Copy', formatul SQL al acesteia.
8. Se face 'Paste', si cu aceasta informatie la sfarsitul textului introdus pana atunci pe cererea Union.
9. Se verifica ca textele introduse sa fie separate prin spatii
10. Se introduc eventual si alte cereri de selectie dupa aceiasi metoda.
11. Se inchide cererea si i se da un nume, asa cum se procedeaza de obicei la crearea unei cereri noi.
Exemplu: Sa se realizeze reuniunea a doua cereri astfel :
- prima cerere afiseaza informatii referitoare la denumirea produsului , pretul si calculeaza suma intrarilor cu conditia ca pretul sa fie >400
- a doua cerere afiseaza toate produsele si pretul acestora cu conditia ca suma intrarilor sa fie <
Rezultatul acestei cereri de selectie este:
A doua cerere de selectie construita cu ajutorul instrumentului grafic QBE este:
Rezultatul acesteia este:
Forma SQL pentru cele doua cereri reunite este:
SELECT PRODUSE.Denumire, PRODUSE.Pret, Sum(MISCARE.Input) AS SumOfInput FROM PRODUSE INNER JOIN MISCARE ON PRODUSE.CodProdus = MISCARE.CodProdus GROUP BY PRODUSE.Denumire, PRODUSE.Pret HAVING (((PRODUSE.Pret)>400)) UNION SELECT PRODUSE.Denumire, PRODUSE.Pret, Sum(MISCARE.Input) AS SumOfInput FROM PRODUSE INNER JOIN MISCARE ON PRODUSE.CodProdus = MISCARE.CodProdus GROUP BY
PRODUSE.Denumire, PRODUSE.Pret HAVING (((Sum(MISCARE.Input))<5));
Rezultatul acestei secvente de cod SQL, adica reuniunea a doua cereri, este:
Reuniunea a doua tabele TAB1, TAB2, pentru campurile [C1] si [C2] va arata in formatul SQL astfel:
SELECT Tab1.C1, Tab1.C2 FROM Tab1
UNION SELECT Tab2.C1, Tab2.C2 FROM Tab2;
3.4 Sub-Query
Sub-Query(sub-cerere) este o cerere care nu poate fi utilizata decat in interiorul altei cereri. Ea nu are macheta de proiectare, se scrie direct in SQL si nu poate fi salvata separat ci numai o data cu cererea in care se gaseste. Posibilitatea folosirii de subinterogari este o optiune foarte importanta in crearea dinamica de criterii in interogarile obisnuite.
Sub-cererile sunt utilizate de obicei direct intr-o expresie a unei cereri, folosita pentru definirea unui criteriu de selectie sau a unui camp calculat. Scrierea frazei SQL se face intre paranteze si fara caracterul punct si virgula la sfarsit. O caracteristica a sub-cererii este posibilitatea definirii ei pe orice tabela din baza de date(si nu numai din subschema).
Exemplu: Cererea din exemplul urmator va avea un criteriu de selectie scris direct in SQL. Prin acesta se vor selectiona toate inregistrarile in care datele din campul [Pret] nu sunt mai mari decat media aritmetica a tuturor preturilor (calculate pe acelasi camp al aceleasi tabele)
Rezultatul acestei cereri de selectie care contine o sub-cerere este:
Denumire |
Pret |
Imprimanta | |
CD-ROM | |
Televizor |
3.5 Cereri actiune
Aceste cereri functioneaza in doi timpi :
- In primul moment se realizeaza o cerere de selectie dupa regulile pe care le-am prezentat.
- In al doilea moment se realizeaza cu datele selectate anterior tipul de actualizare a bazei de date specificat de cerere.
Daca se trece in forma Datasheet View, atunci nu se va executa decat pasul 1, deci vor fi afisate numai datele selectate, fara a se trece la modificarea lor.
Aceasta este o facilitate care se poate folosi pentru a se testa o cerere actiune. Modificarea efectiva a datelor se va realiza numai la executia cererii prin OPEN lansat din pagina Query a ferestrei Database, dupa ce in prealabil s-a selectat respectiva cererea actiune, prin dublu clic pe cererea respectiva tot din fereastra Database sau prin actionarea butonului Run din bara de instrumente din formularul QBE. Inainte de executia unei cereri actiune, sistemul avertizeaza utilizatorul asupra faptului ca se vor modifica tabelele bazei de date si a numarului de inregistrari care se vor schimba, oferind optiunea renuntarii la aceasta. Acest avertisment poate fi eliminat:
- Prin folosirea macro-ului Set Warnings;
- In cod VBA prin setarea proprietatii corespunzatoare a obiectului DoCmd - obiect care asa cum se va vedea contine majoritatea comenzilor utilizate in Access. Astfel folosindu-se instructiunea:
- DoCmd.SetWarnings False - se anuleaza mesajele de avertizare.
- DoCmd.SetWarnings True - se activeaza aparitia mesajelor de avertizare.
Tehnologia de realizare a unei cereri actiune este similara cu cea a unei cereri de selectie. Totusi, fiecare tip de cerere actiune are un rand specific in formatul QBE, prin care se precizeaza actiunea pe care o va efectua cererea.
Prezentam in continuare urmatoarele cereri actiune:
3.1 Update Query
Update Query provoaca modificarea unor valori ale datelor din campurile subschemei. Asa cum se vede si din macheta QBE a acestui tip de cerere, specific este randul Update To
Field | |||
Table | |||
Update To | |||
Criteria | |||
Or |
Prin acest rand se va introduce o valoare care o va inlocui pe aceea care se gaseste in campul respectiv in toate inregistrarile selectate de catre cerere. In randul Update To sunt valabile aceleasi obiecte si reguli care se folosesc la criterii sau campuri calculate. Deci se pot folosi literali(constante), se poate face referire la datele din campurile subschemei sau din controalele aflate in formulare deschise, se pot folosi operatiile obisnuite din expresii, etc. Important este ca rezultatul evaluarii expresiei introduse sa fie inclus in domeniul admis pentru campul respectiv si sa respecte regulile de integritate sau existentialitate care sunt eventual introduse. In caz contrar, modificarea pentru campul respectiv nu se va efectua, utilizatorul fiind evident informat despre acest lucru.
In cazul in care se modifica printr-o cerere Update Query, un camp care este cheie externa a unei alte tabele(copil) si daca intre acestea relatia are setata proprietatea Cascade Update Related Fields(a integritatii referentiale), atunci aceasta modificare se va efectua automat si in campul aflat in relatie din tabela copil.
Pentru ca o cerere Update Query sa fie executabila, este necesar ca inregistrarile selectate sa fie actualizabile(updateable). Acest lucru este posibil numai daca in urma cererii de selectie se vor selectiona inregistrari pe care sistemul sa le poata identifica precis. De asemenea, pentru ca cererea Update Query, sa functioneze, este necesar ca si campul care se doreste a fi modificat sa fie actualizabil(updateable). De exemplu un camp calculat nu va putea fi modificat.
Exemple:
Cererea prezentata in figura alaturata va selecta la inceput, din tabela PRODUSE toate inregistrarile care au campul [Pret]=400, apoi va inlocui pretul din aceste inregistrari cu 350.
Intrucat campul [Pret] nu este cheie primara, sau cheie externa pentru alt tabel, in urma executiei acestei cereri se vor produce automat modificarile in toate inregistrarile selectate, care indeplinesc conditia ca pretul sa fie 400. Dupa executia acestei cereri tabela Produse va avea urmatoarele inregistrari:
Cod |
Denumire |
Pret |
UM |
Imprimanta |
|
Buc |
|
CD-ROM |
|
Buc |
|
Televizor |
Buc |
||
Calculator |
Buc |
Cererea prezentata in figura urmatoare, va selecta, la inceput, din tabela PRODUSE, toate inregistrarile care au campul [CodProdus]=1. In continuare pentru toate inregistrarile selectate, se va introduce in campul [CodProdus] valoarea 6. Practic aceasta cerere inlocuieste in toate inregistrarile din tabela PRODUSE, valoarea 1 din campul [CodProdus], cu valoarea 6. Tabela MISCARE, este legata printr-o relatie de tip one to many, de tabela PRODUSE, prin campul [CodProdus]. Aceasta relatie are setata proprietatea de integritate referentiala si optiunea Cascade Update Related Fields. In aceasta relatie, tabela MISCARE fiind la capatul many, va avea rol de tabela copil.
Desi tabela MISCARE nu apartine subschemei acestei cereri, totusi datorita relatiei prezentate, executia cererii Update va produce aceeasi modificare si in campul [CodProdus] al acestei tabele (valorile 1 ale campului sunt modificate in 6).
Cele doua tabele PRODUSE si MISCARE au acum urmatoarele inregistrari:
4.2 Delete Query
Delete Query provoaca stergerea inregistrarilor care au fost selectate, de catre cerere prin criteriile obisnuite de selectie. Deci toate inregistrarile selectate prin aceasta cerere, vor fi sterse din tabela respectiva. Asa cum se vede si din macheta QBE a acestui tip de cerere, specific este randul Delete.
Field | |||
Table | |||
Delete | |||
Criteria | |||
Or |
Prin acest rand se va introduce obligatoriu una dintre valorile Where sau From - care insa se completeaza automat
Randul Delete este important atunci cand se doreste stergerea de inregistrari dintr-o tabela(cu From introdus in randul Delete) care sunt selectate insa prin criteriile introduse intr-o alta tabela cu care aceasta este in relatie(cu Where introdus in randul Delete din care nu se vor sterge inregistrari. Nu trebuie confundata stergerea unei inregistrari, cu stergerea datelor dintr-un camp - care se realizeaza cu o cerere de tip Update (de exemplu actualizarea cu NULL a datelor din acesta)
Actiunea de stergere este ireversibila. Deci in Access, stergerile sunt definitive, efectuandu-se la nivel fizic si nu la nivel logic (cum este in FoxPro de exemplu).
Similar cererilor de tip Update, in cazul in care se sterg inregistrari printr-o cerere Delete dintr-o tabela care este parinte in relatie cu o alta tabela(partea din fata a unei relatii one to one sau one to many) si daca aceasta relatie are setata proprietatea Cascade Delete Related Records(a integritatii referentiale), atunci din tabela copil, se vor sterge automat toate inregistrarile care au pentru campul de relatie, valori care s-au pierdut datorita stergerilor de inregistrari efectuate in tabela parinte. Evident aceasta operatie se efectueaza chiar daca tabela copil nu este inclusa in subschema.
Un lucru foarte important este ca toate stergerile efectuate in Access (inregistrari din tabele, diferite obiecte ale aplicatiei - tabele, formulare, etc.) nu elibereaza spatiul ocupat. Din aceasta cauza, aplicatiile care suporta multe adaugari si stergeri vor prezenta o crestere semnificativa a spatiului ocupat, chiar daca ele nu isi maresc volumul de date. Pentru eliberarea spatiului ocupat este pusa la dispozitia utilizatorului comanda Compact din meniul Tools | Database Utilities.
Exemple:
Cererea de mai jos va exemplifica cum functioneaza optiunile Where si From din clauza Delete.
Se vor sterge toate inregistrarile din tabele MISCARE(unde este clauza From) care au denumire "Televizor"(vezi clauza Where). Tabelele obtinute in urma executiei cererii vor arata astfel:
In cererea Delete din figura de mai sus pornind de la tabelele din exemplul precedent, se sterg din tabela MISCARE, inregistrarile corespunzatoare celor care au [Denumire]="Televizor" in tabela PRODUSE.
Sistemul va selecta la inceput inregistrarea care in tabela PRODUSE are [Denumire]="Televizor".
In acelasi timp se va selectiona din tabela MISCARE toate inregistrarile legate de aceasta prin campul [CodProdus]. Deoarece in tabela PRODUSE, inregistrarea selectionata are pentru campul de relatie [CodProdus]=3, atunci se vor selectiona si din tabela MISCARE, cele doua inregistrari care au aceasta valoare in campul [CodProdus].(vezi cum arata tabela MISCARE inainte de executia cererii in exemplul dat la cererea Update)
In continuare sistemul va trece la stergerea inregistrarilor selectionate numai din tabela care are in clauza Delete optiunea From.
Se observa din figura, ca in urma stergerilor efectuate de cererea Delete, in tabela MISCARE s-au sters cele doua inregistrari cu [CodProdus]=3.
In acelasi timp tabela PRODUSE a ramas neschimbata datorita faptului ca in cerere la aceasta tabela s-a introdus optiunea Where in clauza Delete.
In cazul in care se sterge printr-o cerere Delete Query, un camp care este cheie externa a unei alte tabele(copil) si daca intre acestea relatia are setata proprietatea Cascade Delete Related Records (a integritatii referentiale), atunci aceasta modificare se va efectua automat si in campul aflat in relatie din tabela copil.
In exemplul urmator vom sterge din tabela PRODUSE toate produsele care au pretul mai mare de "1000"
Tabela PRODUSE inainte de executia cererii:
Tabela MISCARE inainte de executia cererii:
Tabela PRODUSE dupa executia cererii:
Tabela MISCARE dupa executia cererii:
Se observa ca din tabelul PRODUSE s-a sters inregistrarea cu [CodProdus]=4 corespunzatoare conditiei [Pret]>1000 si in acelasi timp au fost sterse din tabela MISCARE toate inregistrarile corespunzatoare campului de legatura(o inregistrare cu [CodProdus]=4) deoarece a fost setata proprietatea Cascade Delete Related Records.
4.3 Append Query
Cererile Append Query provoaca adaugarea de noi inregistrari la o tabela existenta (in baza de date curenta sau alta baza de date), denumita in continuare tabela destinatie.
Practic, aceasta cerere va functiona in prima instanta ca o cerere obisnuita de selectie, urmand ca inregistrarile obtinute la iesire sa fie adaugate in tabela destinatie. Specific acestei cereri este randul Append To
Field | |||
Table | |||
Sort | |||
Append To | |||
Criteria | |||
Or |
In acest rand se pot introduce denumiri de campuri ale tabelei destinatie. In felul acesta se va crea o corespondenta intre campul de iesire al cererii, declarat in randul Field, si campul din tabela destinatie, declarat in randul Append To.
Deci adaugarea in tabela destinatie a inregistrarilor virtuale obtinute prin executia cererii Append Query, se va realiza respectand corespondenta obtinuta prin completarea clauzei Append To in formularul QBE.
Totusi, adaugarea unei noi inregistrari in tabela destinatie, se va face numai daca aceasta respecta toate conditiile de integritate ale tabelei destinatie si a campurilor sau relatiilor acesteia. In cazul in care se vor folosi in cererea Append Query, campuri care nu se vor duce in inregistrarea adaugata la tabela destinatie, se va lasa necompletata celula corespondenta din clauza Append To.(de exemplu pentru campurile folosite numai pentru introducerea unor criterii de selectie).
Proiectarea unei asemenea cereri necesita precizarea tabelei destinatie si a locului unde se gaseste. Acest lucru se realizeaza printr-un dialog initiat de sistem la inceputul crearii unei noi cereri Append Query. In felul acesta va fi posibil ca in randul Append To din QBE, sa fie atasate la lista ascunsa a acestuia, numele campurilor din tabela destinatie.
Numele si locul tabelei destinatie, se vor gasi in pagina de proprietati a cererii, si anume in:
- Current Database - numele tabelei destinatie;
- Another Database - numele complet(cu cale) al fisierului care contine tabela destinatie, proprietate care va fi completata numai in cazul in care tabela destinatie nu se gaseste in baza de date curenta.
Exemple:
Cererea pe care o prezentam va crea din tabela MISCARE, printr-o cerere cu clauza de total, inregistrari care se vor adauga la tabela MISCARE.
Tabela MISCARE inainte de executia cererii:
Cererea Append contine pentru cele patru campuri ale tabelei MISCARE noi valori ce se calculeaza in functie de ceea ce se alege in clauza Total si anume:
se grupeaza produsele dupa campul [CodProdus];
se calculeaza suma intrarilor prin aplicarea functiei agregate Sum asupra campului [Input];
se calculeaza media aritmetica a iesirilor prin aplicarea functiei agregate Avg asupra campului [Output];
se determina cea mai mare data cand au avut loc intrari si iesiri prin aplicarea functiei agregate Max asupra campului [Data].
Cererea Append, va grupa inregistrarile din tabela MISCARE, dupa campul [CodProdus]. In tabela MISCARE , vor fi adaugate doua inregistrari, asa cum se poate vedea din figura urmatoare.
Tabela MISCARE dupa executia cererii Append:
Vom adauga in tabela PRODUSE un nou produs a carei denumire este introdusa de la tastatura (cerere cu parametru), care are codul egal cu cel mai mare Cod existent la care se adauga 1, pretul egal cu suma preturilor tuturor produselor existente.
Tabela PRODUSE inainte de executia cererii:
In urma selectiei se va adauga in tabela PRODUSE urmatoarea linie:
Tabela PRODUSE dupa executia cererii de adaugare:
4.4 Make-Table Query
Cererile Make-Table provoaca crearea unei noi tabele cu inregistrarile virtuale ce rezulta din executia unei cereri obisnuite de selectie. Structura acestei tabele (inclusiv numele campurilor) va fi creata automat de sistem functie de campurile care sunt folosite in cererea de selectie.
Cererea Make-Table, nu contine nici un rand suplimentar in formularul QBE. Realizarea ei este similara cu a unei cereri de selectie obisnuite.
Proiectarea unei asemenea cereri necesita ca si la cererea Append precizarea tabelei destinatie si a locului unde se gaseste, tehnologia fiind absolut aceiasi.
Deci la inceputul crearii unei noi cereri Make-Table sistemul initiaza un dialog prin care se solicita numele si locul tabelei destinatie.
Numele si locul tabelei destinatie, se vor gasi in pagina de proprietati a cererii, si anume in:
- Current database - numele tabelei destinatie;
- Another Database - numele complet(cu cale) al fisierului care contine tabela destinatie, proprietate care va fi completata numai in cazul in care tabela destinatie nu se gaseste in baza de date curenta.
La executia unei cereri Make-Table, daca mai exista o tabela cu acelasi nume ca acela al tabelei destinatie, atunci dupa un mesaj de avertizare aceasta va fi stearsa automat, inainte de executarea cererii respective.
Tabelelor create cu cereri de tip Make-Table, nu li se pot seta prin QBE nici un fel de atribute specifice (de exemplu nu li se poate stabili cheia primara, sau campurile index.). Din aceasta cauza daca se doreste crearea unor tabele cu anumite caracteristici, se procedeaza in felul urmator:
- Se creeaza structura tabelei conform dorintei utilizatorului.
- Se sterg toate inregistrarile din aceasta tabela cu o cerere Delete.
- Se foloseste o cerere Append pentru introducerea inregistrarilor.
Exemplu: Se creeaza un tabel cu numele NOU care contine campurile
[CodProdus],
[Denumire],
[Intrari]= [Pret]*[Input],
[Iesiri]=[Pret]*[Output],
[Diferenta]=[Intrari]-[Iesiri]
In urma executiei cererii, noul tabel va fi:
CodProdus |
Number |
Denumire |
Text |
Intrari |
Number |
Iesiri |
Number |
Diferenta |
Number |
In cazul in care dorim ca acest nou tabel sa aiba [CodProdus] ca fiind cheie primara vom construi un tabel din acesta, care sa contina si cheia primara, printr-o cerere Delete vom sterge toate inregistrarile si printr-o cerere Append vom adauga in tabel inregistrarile anterioare.
Copyright © 2024 - Toate drepturile rezervate