[ SQL ] ADVANCED. - Printable Version

[ SQL ] ADVANCED. - Printable Version

+- Jucausii.Net - Just play it! (https://jucausii.net/forum)
+-- Forum: Arhiva / Archive (https://jucausii.net/forum/forum-20.html)
+--- Forum: Gunoi / Garbage (https://jucausii.net/forum/forum-21.html)
+--- Thread: [ SQL ] ADVANCED. (/thread-10684.html)

[ SQL ] ADVANCED. - Dexter. - 30-04-2016

În această serie de articole, adresată avansaţilor , vom explica noţiunile de start precum bază de date, tabel, înregistrare, redundanţă, reguli de normalizare şi vom studia elementele de bază ale limbajului SQL. Exemplul din acest prim articol constă în realizarea designului bazei de date (folosind Microsoft Access, eventual Microsoft SQL Server) pentru un sistem de gestiune a cheltuielilor lunare ale unei familii sau companii. (Se presupune că utilizatorul poate folosi, la un nivel minimal, meniurile şi comenzile din Microsoft Access.)

Varianta 1 (greşită – acest prim scenariu de lucru are rolul de a ne permite să înţelegem rolul regulilor de normalizare în conceperea bazelor de date relaţionale):

1. Creăm, o nouă bază de date (Blank database...) pe care o numim varianta1.mdb.

2. Creăm un tabel, folosind opţiunea Create table in Design View.

În bazele de date relaţionale, datele sunt stocate în tabele. Fiecare tabelă are un număr finit de coloane (câmpuri) şi un număr, teoretic nelimitat de rânduri (înregistrări).

3. În acest tabel creăm următoarele câmpuri:
- Produs, Text (50)
- Pret, Currency
- Cantitate, Number
- Data, Date/Time

4. Salvăm tabelul cu numele Cumparaturi (în acest tabel vom stoca cumpărăturile efectuate, câte o linie pentru fiecare produs cumpărat).

În fereastra Relationships tabelul va fi vizualizat astfel:

[Image: tutorial_sql1_1.jpg]

5. Deocamdată, la întrebarea „Do you want to create a primary key now?” vom răspunde cu „No”.

6. Schimbăm în modul de afişare View.

7. Introducem următoarele înregistrări:

Produs
Pret
Cantitate
Data
Camasa
$100.00
1
3/22/2006
Camasa
$80.00
1
4/23/2006
Mere
$4.00
1
4/22/2006

Se poate observa că acest mod de stocare a datelor putea fi obţinut utilizând, de pildă Microsoft Excel. Acest gen de stocare nu utilizează deloc potenţialul real al bazelor de date relaţionale şi, vom vedea în continuare, are unele inconveniente grave.

8. Pentru a determina suma cheltuită (valoarea totală) pe fiecare categorie de produs vom crea următorul query (îl salvăm cu numele Query1): alegem „Create query in Design view”, adăugăm tabela Cumpărături, din meniul View, bifăm Totals, apoi introducem datele din imaginea de mai jos:

[Image: tutorial_sql1_2.jpg]

În câmpul Field am introdus formula: Valoare: [Cantitate]*[Pret], iar în câmpul Total am selectat Sum.

În modul SQL acest query va fi:

Code:
SELECT Cumparaturi.Produs, SUM([Cantitate]*[Pret]) AS Valoare

 FROM Cumparaturi

 GROUP BY Cumparaturi.Produs;

9. În modul View acest query va afişa următorul rezultat:

Produs
Valoare
Camasa
$180.00
Mere
$4.00

10. În tabelul Cumparaturi introducem următoarea înregistrare (cu câmpul Produs scris greşit!):

Produs
Pret
Cantitate
Data
Kamasa
$90.00
1
5/10/2006

11. Deschidem din nou query-ul Query1, în mod View şi acesta va afişa:

Produs
Valoare
Camasa
$180.00
Kamasa
$90.00
Mere
$4.00

Prin urmare, orice eroare de scriere a denumirilor produselor va produce o eroare în date. Dacă un operator, care în mod natural poate să greşească, ar introduce în tabelul definit mai sus câteva zeci, sute sau mii de înregistrări pe zi, numărul de erori nu ar mai putea fi ţinut sub control şi, la un moment dat, datele ar deveni inutilizabile.
Soluţia normală de protecţie împotriva erorilor este de aceea de a nu mai introduce la fiecare înregistrare numele produsului ci de a îl selecta dintr-o listă. Acest lucru presupune crearea unui alt tabel, în care să fie stocate, ca într-un nomenclator, categoriile de produse.

12. Introducem o nouă înregistrare:

Produs
Pret
Cantitate
Data
Camasa
$80.00
1
4/23/2006

Din greşeală această înregistrare mai fusese introdusă o dată. Pentru că nu au fost create nici un fel de reguli privind unicitatea înregistrărilor ea a putut fi adăugată fără probleme.

Acum tabelul conţine două înregistrări absolut identice, deşi, în mod normal ar fi trebuit modificată cantitatea la înregistrarea deja existentă:

Produs
Pret
Cantitate
Data
Camasa
$100.00
1
3/22/2006
Camasa
$80.00
1
4/23/2006
Mere
$4.00
1
4/22/2006
Kamasa
$90.00
1
5/10/2006
Camasa
$80.00
1
4/23/2006

Pentru a proteja datele faţă de asemenea erori ar fi trebuit definită o constrângere, astfel încât să nu poată fi introduse două înregistrări cu acelaşi produs şi aceeaşi dată.

Dacă în baza de date am fi dorit să stocăm şi date privind furnizorii, adresele şi datele de contact ale acestora (ceea ce înseamnă să adăugam la structura tabelului Cumpărături câmpurile Producător, Adresa şi Contact) tabela de mai sus ar fi arătat astfel:

Produs
Pret
Cantitate
Data
Producător
Adresa
Contact
Camasa
$100.00
1
3/22/2006
SC Textila SRL
Strada Industriei nr. 10
Popescu Ion, 321.32.13.21
Camasa
$80.00
1
4/23/2006
SC Textila SRL
Strada Industriei nr. 10
Popescu Ion, 321.32.13.21
Mere
$4.00
1
4/22/2006
SC Fructe SRL
Str. Livezii nr. 21
Georgescu Ion, 123.12.31.23
Kamasa
$90.00
1
5/10/2006
SC Textila SRL
Strada Industriei nr. 10
Popescu Ion, 321.32.13.21
Camasa
$80.00
1
4/23/2006
SC Textila SRL
Strada Industriei nr. 10
Popescu Ion, 321.32.13.21

Înregistrarea în mod repetat, a unor anumite date se numeşte redundanţă.
Redundanţa, în afară de consumul nejustificat de spaţiu de stocare, mai are şi un alt efect negativ: dacă adresa unuia dintre furnizori s-ar modifica atunci modificarea în baza de date ar presupune modificarea tuturor înregistrărilor în care apare acel furnizor. Ori, în mod normal, o modificare de acest fel ar trebui făcută într-un singur loc.