techIT.ro Do we have a problem? Let's tech it!    












Daca ai impresia ca educatia e scumpa,
atunci încearca sa vezi cum e ignoranta.
Andy McIntyre









Home  |  Dictionar IT  |  Download  |  Forum  |  Despre noi  |  Contact

Tutorial SQL. Baze de date (I). Crearea unui exemplu

În această serie de articole, adresată începătorilor, 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:

Tabelul Cumparaturi in fereastra Relationships

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:

ProdusPretCantitateData
Camasa$100.0013/22/2006
Camasa$80.0014/23/2006
Mere$4.0014/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:

Crearea unei interogari

Î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:
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:

ProdusValoare
Camasa$180.00
Mere$4.00

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

ProdusPretCantitateData
Kamasa$90.0015/10/2006

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

ProdusValoare
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:

ProdusPretCantitateData
Camasa$80.0014/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ă:

ProdusPretCantitateData
Camasa$100.0013/22/2006
Camasa$80.0014/23/2006
Mere$4.0014/22/2006
Kamasa$90.0015/10/2006
Camasa$80.0014/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:

ProdusPretCantitateDataProducătorAdresaContact
Camasa$100.0013/22/2006SC Textila SRLStrada Industriei nr. 10Popescu Ion, 321.32.13.21
Camasa$80.0014/23/2006SC Textila SRLStrada Industriei nr. 10Popescu Ion, 321.32.13.21
Mere$4.0014/22/2006SC Fructe SRLStr. Livezii nr. 21Georgescu Ion, 123.12.31.23
Kamasa$90.0015/10/2006SC Textila SRLStrada Industriei nr. 10Popescu Ion, 321.32.13.21
Camasa$80.0014/23/2006SC Textila SRLStrada Industriei nr. 10Popescu 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.

techit.ro





Colecţia:  Colecţia Tutorial SQL

Articolul următor:  Tutorial SQL. Baze de date (partea II-a). Crearea unui nou exemplu



  


  Adauga un comentariuSpune-ti parerea despre acest articol!