Warning: Cannot modify header information - headers already sent by (output started at /home/intheory/public_html/ro/tutorial_sql_baze_de_date_normalizarea.php:2) in /home/intheory/public_html/counter.inc on line 31
 Tutorial SQL. Baze de date (partea III-a). Normalizarea
in-theory.info

Tutorial SQL. Baze de date (partea III-a). Normalizarea

Etichete: Baze de date, SQL

Continuarea exemplului din prima parte

Exemplul început în prima parte arată cum datele pot fi afectate de redundanţă sau inconsistenţă. Corectarea problemei presupune realizarea unei structuri în care datele să fie accesibile oriunde este nevoie prin relaţii nu prin duplicare.

În a doua parte a seriei sunt prezentate regulile care trebuie respectate pentru evitarea acestor probleme.


Pentru a rezolva problema datele vor fi separate în două tabele.
Principiul care stă la baza acestei separări şi care a fost încălcat în varianta 1 spune că două entităţi diferite trebuie separate în tabele diferite. În cazul nostru cele două entităţi sunt: produsul şi tranzacţia (prin tranzacţie înţelegând o operaţie de cumpărare). Se poate observa că un produs poate fi tranzacţionat de mai multe ori.


Prin urmare, vom crea două tabele, pentru fiecare entitate câte unul şi vom crea o legătură (relaţie) între ele. Cele două tabele vor fi: Produse şi Tranzacţii.


Paşii sunt următorii (din nou, presupunem că se foloseşte Microsoft Access):

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.
3. În acest tabel creăm următoarele câmpuri:
Denumire câmpTip de dată
DenumireProdusText(50)


4. Salvăm tabelul cu numele Produse.
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:

DenumireProdus
Camasa
Mere


8. Creăm un nou tabel, folosind opţiunea Create table in Design View. Denumirea tabelului va fi Tranzacţii.
9. În acest tabel creăm următoarele câmpuri:

Denumire câmpTip de dată
ProdusText(50)
PretCurrency
CantitateNumber
DataDate/Time


10. În acest moment, dacă încercăm să mai introducem încă o dată înregistrarea „Camasa” în tabelul Produse, putem observa că acest lucru este perfect posibil. Asta înseamnă ni se acceptă fără probleme introducerea a două înregistrări identice (iarăşi un scenariu greşit, v-aţi prins!).
11. Încercăm să creăm o relaţie între cele două tabele. În fereastra Relationships (butonul ) adăugăm cele două tabele şi selectăm câmpul DenumireProdus din tabelul Produse, apoi cu drag-and-drop tragem peste câmpul Produs din tabela Tranzactii. Bifăm Enforce Referential Integrity şi apăsăm butonul Create.
Acum Microsoft Access sesizează că în tabela Produse pot exista înregistrări identice şi întoarce un mesaj de eroare.
12. Pentru a putea crea o relaţie care să garanteze integritatea datelor este nevoie să revenim la tabela Produse, în modul Design.
13. Selectăm coloana DenumireProdus şi apăsăm butonul . În acest fel câmpul DenumireProdus devine cheie primară iar valoarea proprietăţii Indexed devine „Yes (No Duplicates)”. Acest lucru înseamnă că în câmpul DenumireProdus nu pot exista două înregistrări identice. Dacă încercăm să salvăm acum tabela Produse, vom primi un mesaj de eroare care ne indică faptul că există înregistrări identice.
14. Revenim în tabela Produse, în modul View şi ştergem ultima înregistrare introdusă. Refacem pasul al 11-lea, de data aceasta, cu succes. (Dacă după aceasta vom încerca să mai introducem înregistrări duplicate vom primi un mesaj de eroare.) Tabela are acum o cheie primară.
15. Acum, între cele două tabele vom crea o relaţie (cu drag-and-drop tragem peste câmpul Produs din tabela Tranzactii. Bifăm Enforce Referential Integrity şi apăsăm butonul Create):

Definirea relatiilor

16. Pentru a vedea efectele noii relaţii, vom încerca să introducem în tabela Tranzactii o înregistrare greşită (vom scrie „Cămşă” în loc de „Camasa”):

ProdusPretCantitateData
Cămşă$100.0012/22/2006


Microsoft Access va sesiza că nu există o înregistrare corespunzătoare în tabela Produse şi va întoarce un mesaj de eroare care ne avertizează că este necesară o înregistrare corespunzătoare în tabela Produse. Dacă vom corecta cuvântul „Camasa”, înregistrarea va fi salvată în baza de date fără probleme.

Important! În acest exemplu se poate vedea modul în care datele din tabela „copil” (Tranzacţii) sunt protejate la erori, astfel încât să nu se poată introduce produse care nu sunt definite în tabela „părinte” (Produse). Această protecţie a tabelei „copil” se numeşte integritate referenţială. Practic, existenţa ei face ca în tabela „copil” să nu poată exista înregistrări „orfane”.

17. Pentru a corecta structura bazei de date vom crea o cheie primară şi în tabela Tranzacţii. Pentru aceasta vom crea câmpul CodTranzactie de tip AutoNumber pe care îl vom defini drept cheie primară (las dumneavoastră plăcerea de a vă descurca singuri cu acest lucru!).
18. După aceasta creăm un nou query, cu structura de mai jos:

Crearea unui query

Formula introdusa pentru Valoare este [Pret]* [Cantitate], iar pentru Total selectăm „Sum”.
În modul View acest query va afişa valorile cheltuite pentru fiecare dintre produsele cumpărate:

DenumireProdusValoare
Camasa$180.00
Mere$4.00


Adrian Ionescu





Colecția:  🐬 Colecţia Tutorial SQL

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




👍 Topul celor mai citite articole

1. Analiza cerinţelor software. Introducere
Această serie de articole este destinată tuturor persoanelor implicate în proiecte de dezvoltare de software: şefi de departament, şefi de proiec...

2. Despre Analiza cerinţelor
Analiza cerinţelor software (pe care o vom numi în continuare Analiza de business sau Analiză software) este aceea dintre disciplinele existente î...

3. Axiomele dezvoltării software
Adevăruri ale dezvoltării software care susțin nevoia Analizei cerințelor. Unul dintre ele este: "Întotdeauna, într-un proiect software apar si...

4. Ciclul de dezvoltare al produsului software (SDLC)
Deşi în limba engleză este denumit Software Development Life Cycle (SDLC) am ales traducerea „Ciclul de dezvoltare al produsului software”, chi...

5. Ciclul de dezvoltare iterativ
Asumarea realităţii că întotdeauna, în decursul proiectului, cerinţele se vor schimba a condus la apariţia unui model de dezvoltare realist, ca...

6. Locul Analizei în proiectul de dezvoltare software
Analiza Software este o disciplină care se află în relaţie de dependenţă cu celelalte discipline din proiect. Concret, task-urile din proiectul ...

7. Modele teoretice de abordare a problemelor. Decompoziţia
Modalităţile teoretice de abordare a problemelor sunt universale şi pot fi folosite oriunde însă pentru domeniul nostru, este important să le co...

8. Modele teoretice de abordare a problemelor. Sinteza
Sinteza este o modalitate, prin care, din manifestări punctuale se determină problema reală. Cel mai simplu şi clar exemplu este acela al mediculu...

9. Modele teoretice de abordare a problemelor. Crearea unui trunchi de bază
De foarte multe ori, în viaţa reală, o problemă nu poate fi punctată decât cu un efort substanţial sau chiar deloc. Pur şi simplu, obţinerea ...

10. Modele teoretice de abordare a problemelor. Abordarea iterativă
Metoda iterativă presupune rezolvarea unei probleme cunoscute printr-o abordare iterativă, la fiecare iteraţie făcând un pas către rezolvarea pr...



📜 Căutare după etichetă:

Analiza Business
Baze de date
C#
Cerințe software
CSS
Dictionar IT
HTML
MySQL
PHP
Riscuri
SDLC
Specificații software
SQL
UML