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

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

Etichete: Baze de date, SQL

Aşa cum se poate vedea în prima parte datele pot fi afectate de două mari probleme: redundanţa şi inconsistenţa. Rezolvarea presupune realizarea unei structuri în care datele să fie accesibile oriunde este nevoie prin relaţii nu prin duplicare.

Astfel, relaţiile dintre tabele fac posibilă eliminarea redundanţei datelor şi păstrarea integrităţii referenţiale a datelor.
Eliminarea redundanţei se face prin realizarea unor legături între anumite date şi locurile unde aceste date sunt folosite, evitând astfel duplicarea lor, în fiecare loc în care acestea sunt folosite. Integritatea datelor este protejată tocmai prin utilizarea datelor fără redundanţe, astfel încât actualizarea lor să se facă într-un singur loc, fără posibilitatea de a greşi.

În subsidiar, pentru ca datele să poată fi relaţionate şi utilizate corect este necesară normalizarea bazei de date. Acest lucru presupune încadrarea în formele de normalizare de mai jos:


1. Prima formă de normalizare (1NF)

Într-o bază de date relaţională, entităţi diferite trebuie stocate în tabele diferite. Este recomandabil ca pentru fiecare entitate (de business) să se creeze un tabel separat. În exemplul din această serie de articole, produsele şi tranzacţiile sunt entităţi diferite.

Foarte adesea această formă de normalizare este prezentată într-un alt mod (am ales modul de mai sus pentru că este mai cuprinzător). În această formulare se spune că valoarea unui atribut al unei entităţi (modelat, în mod normal, în baza de date printr-o coloană) nu poate lua valori multiple (ceea ce ar însemna utilizarea mai multor coloane de acelaşi fel). Astfel, este greşită alegerea unei structuri de genul:

FirmăAdresă 1Adresă 2
Alfa s.r.l.Str. Preciziei nr. 3Bd. Bucureşti nr. 201


Modelul corect pentru exemplul acesta presupune stocarea adreselor, câte o înregistrare pentru fiecare adresă:

FirmăAdresă
Alfa s.r.l.Str. Preciziei nr. 3
Alfa s.r.l.Bd. Bucureşti nr. 201


În realitate însă, normalizarea completă constă în separarea datelor în două tabele, creând o relaţie între înregistrări:

- tabelă cu firmele:
CodFirmăDenumireFirmă
ALFAAlfa s.r.l.
BETABeta s.r.l.


- tabela cu Adresele firmelor:

CodUnicAdresaCodFirmăAdresă
1Alfa s.r.l.Str. Preciziei nr. 3
2Alfa s.r.l.Bd. Bucureşti nr. 201




2. A doua formă de normalizare (2NF)

O tabelă este în a doua formă de normalizare dacă şi numai dacă se găseşte în prima formă de normalizare şi, în plus, orice înregistrare dintr-o tabelă poate fi identificată în mod unic printr-o cheie primară şi fiecare atribut (valoare dintr-o coloană) depinde în mod direct de întreaga cheie primară.

Pentru a asigura dependenţa faţă de întreaga cheie primară, este necesar ca în tabelele care au cheie compusă, fiecare atribut să depindă de toate coloanele care compun cheia primară. Dacă un tabel are cheie unică el intră automat în a doua formă de normalizare.



3. A treia formă de normalizare (3NF)

O tabelă este în a treia formă de normalizare dacă şi numai dacă se găseşte în a doua formă de normalizare şi, în plus, câmpurile care nu sunt chei primare sunt independente unul de altul, în sensul că nici un câmp să nu să fie obţinut prin aplicarea unei funcţii asupra valorii altor câmpuri (câmpurile care nu sunt chei primare sunt independente între ele şi depind numai de cheia primară).

Încălcarea acestei forme poate fi detectată analizând care câmpuri trebuie actualizate atunci când se actualizează un alt câmp.

IDProdusPretCantitateDataProducătorAdresa
1Camasa$100.0013/22/2006SC Textila SRLStrada Industriei nr. 10
2Camasa$80.0014/23/2006SC Textila SRLStrada Industriei nr. 10
3Mere$4.0014/22/2006SC Fructe SRLStr. Livezii nr. 21


De exemplu, în tabela de mai sus, câmpul Adresa nu depinde de cheia primară ci de câmpul Producător.


În afară de aceste trei forme de normalizare, în literatura de specialitate mai sunt descrise şi altele. În general însă, acestea trei sunt acoperitoare şi se acceptă că o bază de date este normalizată dacă se găseşte în a treia formă de normalizare.



Relaţii

Relaţiile într-o bază de date relaţională pot fi:

- unu la unu (1:1): unei înregistrări din tabela părinte îi corespunde o înregistrare în tabela copil (de exemplu, o persoană are o singură adresă de domiciliu sau un singur act de identitate).

- unu la mai mulţi (1:n): unei înregistrări din tabela părinte îi corespund mai multe înregistrări în tabela copil (de exemplu, un produs poate avea mai multe reţete şi poate fi vândut în mai multe tranzacţii).


Aici este important de observat că în viaţa reală, între entităţi pot exista şi relaţii de mai mulţi la mai mulţi (n:n). Acest tip de relaţii sunt modelate în baza de date prin crearea unei tabele de legătură.

Denormalizarea

Este important de reţinut că regulile de normalizare pot fi încălcate uneori, pentru un design optimal al bazei de date. De pildă, anumite probleme de performanţă pot fi rezolvate prin introducerea voită a unei anumite redundanţe a datelor.

Adrian Ionescu





Colecția:  🐬 Colecţia Tutorial SQL

Articolul precedent:  Tutorial SQL. Baze de date (I). Crearea unui exemplu
Articolul următor:  Tutorial SQL. Baze de date (partea III-a). Normalizarea



👍 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