Normalizarea bazelor de date cu redundanță minimă - IONOS

Unul dintre conceptele de bază ale modelării relaționale a datelor este normalizarea. în modelul bazei de date relaționale un design bun al bazei de date se caracterizează printr-un minim de redundanță. Motivul: datele redundante duc la anomalii semantice. La rândul său, acest lucru complică prelucrarea automată a datelor și întreținerea bazei de date. Normalizarea este o strategie de eliminare a concedierilor din bazele de date relaționale. Vă vom arăta cum să o faceți.

1. Ce este normalizarea?
2. Normalizare: Cum să vă normalizați baza de date
   1. 1. Formă normală (1NF)
   2. 2. Formă normală (2NF)
   3. 3. Forma normală (3NF)
3. Forme mai normale
   1. Boyce-Codd formă normală (3.5NF)
   2. 4. Forma normală
   3. 5. Forma normală
4. Pro și contra ale normalizării

Ce este normalizarea?

Normalizarea este o abordare de proiectare a bazei de date care este utilizată în baze de date relaționale este folosit pentru a evita concedierile.

Modelul bazei de date relaționale este cel mai răspândit concept pentru gestionarea datelor asistată de computer. În bazele de date relaționale, informațiile sunt stocate ca Înregistrări în tabele stocate care sunt legate între ele prin intermediul tastelor. O înregistrare de date constă din mai multe intervale de valori, care sunt atribuite anumitor atribute prin coloane de tabel.

Următorul tabel prezintă datele de facturare salvate pentru un montator de companie fictiv. Max Mustermann a comandat 10 monitoare, 12 mouse pad-uri și 1 scaun de birou pentru compania sa. Comanda de la Erika Musterfrau include 2 laptopuri și 2 căști.

În baza de date a magazinului online, datele facturii sunt atribuite atributelor numărului de factură (nr. R.), dată, client, număr client (K. nr.), Adresă, număr articol factură (nr. P.), articol, număr articol (Art.- Nr.), Număr (număr) și preț atribuit. Fiecare linie a tabelului reprezintă o înregistrare de date. O astfel de înregistrare se numește a Tuple desemnat.

Secțiunea bazei de date prezentată mai sus acționează ca un Exemplu de aproiectare proastă a bazei de date. La prima vedere se observă că tabelul are numeroase concedieri. În plus, intervalele de valori din coloanele Client și Adresă conțin date cu valori multiple. Se vorbește despre o bază de date non-normalizată.

Principalul dezavantaj al bazelor de date non-normalizate este cererea crescută de memorie datorită valorilor redundante. În plus, atributele care conțin date cu valori multiple sunt dificil de citit și de relaționare între ele.

Exemplu: Ambii clienți din secțiunea bazei de date enumerate mai sus au sediul în Musterhausen. Dar, deoarece aceste informații nu au fost colectate separat, baza de date nu poate fi ușor filtrată pentru clienții din aceeași locație.

Pentru a evita intervalele de valori duble și multiple, există trei valori consecutive în cadrul modelelor de baze de date relaționale Forme normale a fost dezvoltat.

O formă normală este o stare țintă definită. Pentru fiecare formă normală, au fost specificate cerințe speciale care trebuie îndeplinite dacă va apărea această stare țintă. O bază de date corespunde cu prima, a doua sau a treia formă normală dacă sunt îndeplinite toate cerințele pentru forma normală respectivă.

Normalizarea este transformarea unui tabel de baze de date într-o formă normală de grad superior. Conversia într-o formă normală de grad inferior se numește denormalizare.

Normalizare: Cum să vă normalizați baza de date

Pentru a ilustra conversia unei baze de date relaționale în prima, a doua și a treia formă normală, vom juca etapele individuale ale Normalizarea pe baza unui exemplu de. Punctul de plecare este secțiunea bazei de date enumerată mai sus.

1. Formă normală (1NF)

Un tabel într-o bază de date relațională corespunde primei forme normale (1NF) dacă sunt îndeplinite următoarele cerințe:

• Toate datele sunt atomice.
• Toate coloanele tabelului conțin valori similare.

Se consideră că este o înregistrare atomic, dacă fiecare informație (fiecare fapt) este alocată unui câmp de date separat.

Mai jos veți găsi tabelul nostru privind datele de facturare, în care am evidențiat în roșu toate intervalele de valori care sunt fie non-atomice, fie care nu conțin date echivalente.

Numeroasele evidențieri arată: tabelul nostru de pornire încalcă ambele cerințe și, prin urmare, nu corespunde cu prima formă normală.

Dacă secțiunea listată a bazei de date trebuie normalizată în conformitate cu primul formular normal, este necesară următoarea procedură:

1. Împărțiți toate datele cu mai multe valori în coloane separate.
2. Verificați asemănarea valorilor din fiecare coloană.

Pentru a aduce înregistrările de date din tabelul de exemplu într-o formă atomică, atributele clientului și adresei trebuie împărțite în atributele mai specifice prenume și prenume sau stradă, număr de casă (H.-Nr.), cod poștal (cod poștal) și oraș.

Punctul în care o valoare este considerată atomică depinde de contextul de utilizare. De exemplu, dacă nu este necesară separarea numelui și a prenumelui, numele complet al unei persoane poate fi considerat și atomic. Cu toate acestea, în practică, este recomandabil să împărțim valorile multipart în cele mai mici unități posibile.

Coloana de preț conține informații în euro și cenți. Decideți exact un tip de specificație pentru a crea intervale de valori similare.

Rezultatul este un tabel care corespunde primei forme normale, dar totuși datorită valorilor duble nicio prelucrare eficientă a datelor permis. Prin urmare, este recomandabil să convertiți tabelul la a doua formă normală pentru a elimina concedierile.

Prima formă normală prescrie intervale de valori atomice și astfel permite interogări în baza de date. Datele care fac parte dintr-un interval non-atomic de valori nu pot fi interogate separat.

2. Formă normală (2NF)

Un tabel care ar trebui să corespundă celui de-al doilea formular normal trebuie să îndeplinească toate cerințele primului formular normal și, de asemenea, să îndeplinească următoarea condiție:

• Fiecare atribut non-cheie trebuie să fie complet funcțional dependent de cheia primară.

În introducere, o bază de date relațională a fost definită ca un sistem de tabele individuale care sunt legate între ele prin intermediul tastelor.

În bazele de date relaționale, cheile sunt utilizate pentru a identifica în mod unic înregistrările de date (tupluri). O cheie care permite numirea în mod unic a liniilor individuale ale unei tabele de baze de date Super cheie numit. O astfel de cheie poate rezulta din valorile unei singure coloane sau din suma valorilor mai multor coloane.

În exemplul nostru, o posibilă super cheie rezultă din atributele numărului de factură (R.-Nr.), numărul clientului (K.-Nr.) și numărul articolului de factură (P.-Nr.). Am evidențiat super-tasta de culoare în tabelul de mai jos.

O cheie formată din numărul facturii, numărul clientului și numărul articolului de factură cu valorile face posibilă, de exemplu, identificarea clară a înregistrării de date care reprezintă achiziționarea unui laptop de către Erika Musterfrau:

Cu toate acestea, nu toate detaliile supercheii selectate sunt necesare pentru o astfel de identificare unică. O combinație între numărul facturii și numărul articolului de factură - adică un subset al supercheii - ar fi suficientă pentru a identifica înregistrările de date individuale. Astfel de taste cu un număr minim de atribute vor fi Candidați cheie sau Tasta alternativă numit.

De regulă, este selectat un candidat cheie pentru fiecare tabel pentru cartografierea tabelului. Numerotarea consecutivă este ideală. O astfel de cheie se numește Cheia principala denotă și indică ordinea înregistrărilor de date.

Ca orice candidat cheie, cheia primară poate fi o singură parte sau - ca în exemplul nostru - o cheie compusă. Tabelul nostru de exemplu folosește o cheie principală compusă care rezultă din numărul de factură și numărul articolului de factură.

Pentru a converti o tabelă a bazei de date la a doua formă normală, nu este important doar să determinați cheia primară și toate atributele non-cheie, ci și relația lor între ele. Urmați acești pași:

1. Verificați dacă toate atributele non-cheie sunt pe deplin dependente funcțional de cheia primară. O astfel de dependență există numai dacă toate atributele cheii primare sunt necesare pentru a identifica în mod unic atributul non-cheie. Aceasta înseamnă, de asemenea, că tabelele cu chei primare dintr-o singură parte corespund automat cu a doua formă normală dacă sunt îndeplinite toate cerințele pentru prima formă normală.
   
2. Mutați toate atributele care nu sunt cheie care nu depind din punct de vedere funcțional de întreaga cheie primară în tabele separate.

Dacă vă uitați atent la eșantionul de tabel, veți vedea că Cerințe pentru a doua formă normală din următoarele motive neîmplinit sunt: ​​Coloana de dată depinde doar de numărul facturii (R.-Nr.), nu de numărul articolului de factură (P.-Nr.). Același lucru este valabil și pentru numele clientului prenume, prenume, stradă, număr de casă (H.-Nr.), cod poștal și oraș.

Pentru a converti tabelul de date în al doilea formular normal, externalizăm toate atributele care depind numai de numărul facturii într-un tabel separat numit „Factură”.

---