Formularele normale nu sunt doar pentru baze de date

Puteți aplica reguli similare și tipurilor de obiecte de date.

Probabil ai învățat termenul Formă normală în contextul definirii schemelor pentru baze de date relaționale. Normalizarea bazei de date se străduiește să reducă redundanța datelor în rândurile și coloanele tabelului. În consecință, este mai puțin probabil să apară anomalii ale datelor.

Ce este o anomalie a datelor?

Să presupunem că am avut această situație:

Tabelul A conține valori pentru proprietățile X, Y, Z pentru un rând identificat prin ID-ul lui X; acestea sunt afirmații despre x. Să spunem Y la rând X se afirmă a fi valoarea 3.

Tabelul B conține, de asemenea, aceleași afirmații despre motivul pentru care Y pentru X

Tabelul A este spus mai târziu: „Faptele s-au schimbat. Y are acum 4 ”

Tabelul B este interogat ulterior și spune că Y este încă 3.

Acum A și B afirmă două fapte diferite despre Y, în funcție de ce tabel interogați.

Aceasta este o anomalie a datelor: două afirmații diferite despre un fapt. Și faptele contează în sistemele informatice.

Ce și de ce pentru formele normale?

Voi folosi termenul tip pentru a indica metadatele unui obiect. Acest lucru ar putea fi implementat printr-un clasă definiție, mixin, trăsătură, timbru, sau orice mecanism acceptă preferința și limba de alegere. De asemenea, mă voi concentra asupra obiecte de date, precum POJO-uri, PODO-uri, JSON și obiecte simple similare.

Afirmate informal, primele trei forme normale sunt descrise după cum urmează:

Prima formă normală (1NF): nu există elemente repetate sau grupuri de elemente

A doua formă normală (2NF): Toate atributele non-cheie depind de toate cheile

A treia formă normală (3NF): nu există dependențe de atributele non-cheie

Este o lectură destul de uscată. Dar aplicarea acestor principii la definițiile tipului de obiect este de fapt destul de intuitivă. Odată ce ați interiorizat aceste reguli, nici nu vă veți mai gândi la ele în mod conștient.

Obiectele sunt și ele relaționale

Suport baze de date relaționale asociațiile prin intermediul constrângerilor cheii primare și străine. Ierarhiile sunt implicite, dacă există. Asociațiile sunt mai libere decât ierarhiile și taxonomiile, dar și mai greu de gândit.

Într-o ierarhie, aveți relații părinte-copil. Există adesea și o ierarhie a tipurilor de date (clasă-subclasă) care este, de asemenea, modelată. Relațiile dintr-o ierarhie de izolare a obiectelor sunt mai constrânse, în general unidirecționale (de la părinte la copil), dar și mai ușor de înțeles decât o asociere mai generală (și mai flexibilă).

1NF: Nu există elemente repetate sau grupuri de elemente

Să presupunem că avem următoarele informații de contact:

Unde sunt elementele care se repetă?

1. Atribute de nume: aceasta ar putea fi considerată o relație unu-la-mulți, în care numărul de nume este nedeterminat (cum ar fi regalitatea britanică). În practică, totuși, primul, ultimul și, eventual, numele de mijloc sunt suficiente pentru majoritatea domeniilor aplicației, deci nu este nevoie reală de a normaliza aceste câmpuri.
2. telefoane: Repetarea atributelor telefonului pare a fi o problemă potențială: sunt suficiente două telefoane? Și ce se întâmplă dacă mai multe informații sunt asociate ulterior cu numărul de telefon, cum ar fi timpul disponibil?
3. linii de adresă: din nou, sunt suficiente două? În unele țări, adresele stradale pot avea patru rânduri, dar aceasta este limita. Deoarece sunt șiruri simple, nu este o tragedie dacă mai sunt adăugate una sau două linii de adresare mai târziu.

Iată un posibil model, cu tipuri de contacte și telefoane:

2NF: Toate atributele non-cheie sunt dependente de toate cheile

Ce înseamnă acest lucru în engleză simplă? Într-o bază de date, înseamnă că toate coloanele dintr-un rând ar trebui să fie direct dependente de oricare chei de candidat din acel rând.

Deci, să aruncăm o privire din nou pe Contact:

Aici cheia este o valoare de identificare generată, uneori denumită o cheie surogat. Atributele de adresă depind de ID-ul de contact? Bine…

Totul depinde de domeniu.

Cele șase proprietăți de adresă nu sunt cu siguranță atribute ale contactului, ci sunt mai degrabă mijloace de identificare a unei locații fizice. Este posibil ca un contact să aibă mai multe adrese și poate că o adresă are multe contacte.

Ar trebui să fie modelat ca o relație de mai mulți la mulți, cu un anumit tip de obiect ContactAddress care are un ID de contact și un ID de adresă? Va depinde de ceea ce este important pentru domeniul aplicației dvs. Unele aplicații pot trata contactele ca entități puternice, independente de adresă, dar adresele ca entități slabe, dependente de un contact pentru existență. În acest caz, un contact poate avea mai multe adrese și fiecare adresă se referă la un contact, ca acesta:

Există o potențială anomalie a datelor: dacă modificați adresa unui contact, nu modificați aceeași adresă pentru toate contactele. Dacă contactul este sursa dvs. principală de referință, atunci acesta poate fi comportamentul dorit: contactul dvs. se mută (să spunem într-o altă organizație), iar contactele rămase rămân la locul lor.

3NF: Nu există dependențe de atribute non-cheie

Privind din nou adresa, s-ar putea să observați cele două câmpuri dependente, regiune și țară. O țară poate avea sau nu regiuni, dar o regiune are o țară: nu doriți să le amestecați.

O modalitate de a vă asigura că regiunea aparține țării corecte este crearea unui identificator pentru fiecare pereche (țară, regiune), apoi adresați-vă să se refere la identificator, mai degrabă decât la regiune și țară independent:

Un cuvânt despre identificatorii generați

În opinia mea, identificatorii generați sunt un detaliu de implementare și sunt într-adevăr necesari doar de codul clientului atunci când modificați sau ștergeți o înregistrare back-end (cum ar fi un rând dintr-o bază de date), dar niciodată ca parte a unei interogări de numai citire. De asemenea, nu ar trebui niciodată să fie văzute de utilizatorul sistemului, deoarece nu au sens.

Tabel pe tip, Tabel pe tip ierarhie

Lucrul îngrijit la tipurile de obiecte normalizate este că acestea se mapează cu ușurință la tabelele de baze de date relaționale. Pentru o implementare a bazei de date relaționale, tabelele reflectă tipurile de obiecte (Tabel pe tip) sau cel puțin conțin informații pentru mai multe tipuri derivate dintr-un tip de bază (Tabel pe tip de ierarhie). Acest lucru poate suna de parcă pledez Cartografiere obiect-relațională, dar nu … Pur și simplu spun că este benefic să ai Model logic împărtășesc aceleași caracteristici ale Model fizic la o conceptual nivel. Implementarea este un alt subiect în întregime.

Referințe

Există resurse suficiente despre normalizarea schemelor bazei de date de relații:

Normalizarea bazei de date: prima, a doua și a treia formă normală – Andrew Rollins
Am citit o explicație excelentă a primei, a doua și a treia forme normale acum câteva săptămâni. Pentru cei care știu ce bază de date …
www.andrewrollins.com

Baza de date A doua formă normală explicată în engleză simplă
Cel de-al doilea post s-a concentrat pe prima formă normală, definiția acesteia și exemple pentru a-l acapara. Acum este timpul să …
www.essentialsql.com

Ce este a doua formă normală (2NF)? – Definiție din Techopedia
A doua formă normală 2NF Definiție – A doua formă normală (2NF) este al doilea pas în normalizarea unei baze de date. 2NF construiește …
www.techopedia.com

Baza de date A treia formă normală explicată în engleză simplă
Cel de-al treilea post s-a axat pe a doua formă normală, definiția acesteia și exemple pentru a-l acapara. Odată ce o masă este în …
www.essentialsql.com

De asemenea, când am cercetat această postare, am întâlnit o abordare oarecum diferită cu privire la modul de aplicare a regulilor de normalizare tipurilor de obiecte.

Introducere în normalizarea clasei
www.agiledata.org