Proiectare baze de date relationale
Sarcina de proiectare a unei baze de date relațională poate fi considerat pentru a realiza un astfel de sistem
relații care ar putea reproduce baza de date a declarațiilor necesare cu privire la zona de subiect, și cu toate informațiile cu privire la zona de subiect ar fi reprezentat în baza de date o dată, nu se repetă. Acest design, spre deosebire de modelul relațional nu este descrierii matematice și este determinată în mare măsură de bunul simț și experiența dezvoltator.
Teoria existentă a designului bazei de date relaționale nu învață cum să construiască o bază de date. In schimb, ea ne învață ce este plină de probleme de proiectare „greșit“: acesta este uneori numit „o sursă bună de exemple negative.“
O parte semnificativă a efortului de a proiecta o bază de date relațională este asociată cu eliminarea redundanței. Redundanța declanșează „actualizare anomalie“ de date, ceea ce a dus la o formă de cereri formatate corect pentru a putea da baza de date cu informații incorecte. Pentru acest lucru avem două observații importante. În primul rând, redundanța, se înțelege așa cum se aplică la descrierea de date logice, în timp ce stocarea fizică redundante pot fi rezonabile și justificate. În al doilea rând, eliminarea redundanței, fiind necesară pentru a „corecta“ construirea bazei de date în sine nu garantează acuratețea domeniului de simulare.
Un exemplu simplu este prezentat mai jos eliminarea redundanței.
Să presupunem că, în ceea ce privește reprezentarea datelor privind personalul, există atribute ale „salariu“, „comisioane“ și „venituri“. În cazul în care regulile venitului angajat al domeniului modelat este format exclusiv din salariu și comision, unul dintre următoarele atribute ar trebui să fie eliminate din definiția relației - cel mai probabil, acesta va fi „venituri“:
Cu toate că, în general, lupta cu date redundante în baza de date - non-formal proces cunoscut două tehnici pentru a elimina redundanța și aduse la descrierea matematică a nivelurilor: normalizare și ortogonalizarea. Mai jos declarația lor introductivă nonstrict.
Normalizarea bazei de date relaționale
Normalizarea este atitudinea actuală a „vizualizarea normală“, prin divizarea in mai multe alte chei străine conexe. Concasare este de construcție realizată proiecții raport originale, dar problema este că legătura inversă care rezultă din zdrobirea relațiile s-ar fi întors la ruda sa inițială, și anume că aceste pierderi au avut loc fără a fi strivit (distorsiune) informații.
Cele mai populare schema a acestui „drept“ este de a elimina fragmentarea relațiilor de schimb dependențe funcționale. Datele pentru care funcționează independent unul de altul, în cazul în care una dintre ele pot fi definite folosind alte.
Să presupunem că, în ceea ce privește datele angajaților și numărul de departament prezent angajat, și numele departamentului. Pentru a rezolva relația dintre numărul și numele departamentului în ceea ce privește „angajați“, suficient să-l lase doar unul dintre cele două atribute (cel mai probabil, acesta va fi un „număr de card“), pentru a crea o relație, „departamente“ cu atributele „numărul de card“ și „numele“ , declara cheia acesta „numărul de card“. „Departamentul de număr“ la „angajați“ ar trebui să fie declarată o cheie străină, asociindu-l cu un „număr de card“ de „departamente“:
Pentru a scapa de acest tip de dependență funcțională într-o relație este posibilă, până când acestea sunt reduse la „Normal Forma BCNF“, Boyce-Codd (Boyce-Codd); prin dreptul de primatul trebuie să se numească o „formă normală a Heath“ (Heath). În aceste privințe, la figurat vorbind, „fiecare reducere se aplică cheii, toate cheile (cu toate atributele sale), și numai cheia“ (în fraza originală în limba engleză în loc de „informații“ literalmente a spus „fapt“), cu adăugarea că cheile pot exista mai multe. Cu alte cuvinte, în ceea ce privește BCNF satisfăcătoare. valori arbitrare este determinată doar reguli cheie - cheie, probabil, străine și tipuri de atribute. versiune oarecum mai puțin strictă a BCNF numit „forma a treia normală.“
În cazul în care cheile sunt în relații constau din grupuri de atribute (nu sunt „simple“), pentru a scăpa de dependențe suplimentare de date funcționale vor trebui, de asemenea, pentru a aduce relația cu o „formă normală a cincea.“ Dacă zdrobirea ia în considerare o versiune generalizată a operațiunilor de proiecție și conexiuni, apoi, în plus, este necesar pentru a aduce relația cu o „formă normală a șasea.“ Astfel, în practică, pentru a beneficia de normalizarea cel mai simplu mod de a face cu (odnoatributnymi) chei simple în relații.
Toate formele normale propuse sunt ordonate liniar, astfel încât realizarea împotriva unora dintre ele, prin definiție, înseamnă îndeplinirea unui număr de „precedent“.
Aceasta contribuie la normalizarea relațiilor:
- eliminarea datelor redundante în baza de date;
- ca urmare, a scăpa de unele dintre anomaliile din actualizarea datelor;
- simplifica modificări, și, uneori, cererile de date;
- Facilitarea constrângerilor de integritate de formulare;
- reprezentarea domeniului de date în baza de date într-un mod mai natural.
Adesea, procesul de eliminare redundanță atrage după sine în mod automat alte beneficii enumerate. Aducerea relația cu forme normale nu este în măsură să elimine toate tipurile de redundanță, dar este un mijloc eficient de a atinge acest obiectiv. Uneori numit normalizarea datelor de expresie formalizată de bun simț. În același timp:
- amestecare mecanică pentru a forma BCNF normală în cazul cheilor compuse pot fi nejustificate și conflict cu necesitatea de a păstra o anumită proporție a modelului redundanță;
- stocarea datelor redundante, inclusiv relațiile nedonormalizovannosti datorate, poate duce la actualizări de anomalii;
- date normalizate poate fi mai dificil să se schimbe;
- Normalizarea este adesea ambiguă și permite diferite moduri de tabele de divizare;
- Normalizarea nu rezolvă toate problemele de modelare, ceea ce face dezvoltator de baze de date să recurgă la normele suplimentare pentru constrângerile de integritate a datelor.
Viața în normalizarea sistemelor SQL (cu referire la tabelele) nu sunt adesea respectate în favoarea așteptare pentru viteza de acces, ușurința de modificări de date și prezentarea acestora. Pentru a indica o practică deliberată a folosit chiar și un termen special: „de-normalizare“. Uneori, aceste așteptări sunt îndeplinite, cu toate acestea, ca și reversul acestei creează riscul de divergență în baza de date model pentru zona de subiect, și chiar modelul utilizat incorect. Unii experți cred că beneficiile, care, în anumite circumstanțe pot da denormalizare - mitic.
În timp ce normalizarea relațiilor are ca scop eliminarea redundanței în cadrul relațiilor individuale, Ortogonalizarea date care încearcă să scape de comune repetari de date în diferite moduri. Se completează astfel normalizarea.
O versiune simplificată a principiului ortogonalizarea datelor susține că același set de valori nu pot fi repetate în diferite moduri. De exemplu, din punctul de vedere al acestui principiu, este de dorit să următoarele relații de transformare în baza de date:
Există, de asemenea, o formulare mai complexă a principiului relațiilor ortogonalitate pentru a ilustra proiectat necesitând exemple mai puțin evidente.