Normálne formuláre nie sú určené iba pre databázy

Podobné pravidlá môžete použiť aj na typy dátových objektov.

Termín Normálna forma ste sa pravdepodobne naučili v súvislosti s definovaním schém pre relačné databázy. Normalizácia databázy sa snaží znížiť redundanciu údajov v riadkoch a stĺpcoch tabuľky. V dôsledku toho je pravdepodobnosť výskytu anomálií údajov nižšia.

Čo je to anomália údajov?

Predpokladajme, že sme mali túto situáciu:

Tabuľka A obsahuje hodnoty pre vlastnosti X, Y, Z pre riadok identifikovaný ako id x ; to sú tvrdenia o x. Povedzme, že Y v riadku x sa považuje za hodnotu 3.

Tabuľka B obsahuje rovnaké tvrdenia o tom, prečo Y pre x

Tabuľka A je uvedená neskôr: „Fakty sa zmenili. Y je teraz 4 ”

Tabuľka B je položená neskôr a hovorí, že Y je stále 3.

Teraz A a B tvrdia dva rôzne fakty o Y, podľa toho, na ktorú tabuľku sa pýtate.

To je údajová anomália: dve rôzne tvrdenia o skutočnosti. A v počítačových systémoch záleží na faktoch.

Čo a prečo normálne formy

Termín typ použijem na označenie metaúdajov objektu. To by sa dalo implementovať definíciou triedy, kombináciou, znakom, pečiatkou alebo akýmkoľvek mechanizmom, ktorý podporuje vaša preferencia a jazyk voľby. Zameriam sa tiež na dátové objekty , ako sú POJO, PODO, JSON a podobné jednoduché objekty.

Neformálne povedané, prvé tri bežné formy sú opísané takto:

Prvý normálny tvar (1NF): Žiadne opakujúce sa prvky alebo skupiny prvkov

Druhý normálny tvar (2NF): Všetky nekľúčové atribúty závisia od všetkého kľúča

Tretí normálny formulár (3NF): Žiadne závislosti od nekľúčových atribútov

To je dosť suché čítanie. Ale použitie týchto princípov na definície typov objektov je v skutočnosti dosť intuitívne. Len čo ste tieto pravidlá zvnútornili, už na ne nebudete ani vedome myslieť.

Objekty sú tiež relačné

Relačné databázy podporujú asociácie prostredníctvom obmedzení primárneho a cudzieho kľúča. Hierarchie sú implicitné, ak vôbec existujú. Asociácie sú voľnejšie ako hierarchie a taxonómie, ale tiež je ťažšie na ne myslieť.

V hierarchii máte vzťahy rodič - dieťa. Často existuje aj hierarchia dátových typov (trieda-podtrieda), ktorá sa tiež modeluje. Vzťahy v hierarchii zadržiavania objektov sú obmedzenejšie, spravidla jednosmerné (z rodiča na dieťa), ale tiež ich možno ľahšie pochopiť ako všeobecnejšie (a flexibilnejšie) združenie.

1NF: Žiadne opakujúce sa prvky alebo skupiny prvkov

Povedzme, že máme nasledujúce kontaktné informácie:

Kde sú opakujúce sa prvky?

  1. Atribúty mien: dalo by sa to považovať za vzťah typu jedna k mnohým, kde je počet mien neurčitý (napríklad britská kráľovská hodnosť). V praxi však pre väčšinu aplikačných domén postačuje prvé, posledné a možno aj druhé meno, takže nie je potrebné tieto polia normalizovať.
  2. telefóny: ​​Opakovanie atribútov telefónu vyzerá ako potenciálny problém: stačia dva telefóny? A čo keď sa k telefónnemu číslu neskôr spoja ďalšie informácie, napríklad čas, ktorý je k dispozícii?
  3. riadky adresy: opäť stačia dva? V niektorých krajinách môžu byť adresy ulíc dlhé štyri riadky, ale to je limit. Pretože sú to jednoduché reťazce, nie je žiadnou tragédiou, ak neskôr pridáte ešte jeden alebo dva ďalšie riadky adresy.

Tu je možný model s typmi kontaktov a telefónov:

2NF: Všetky nekľúčové atribúty závisia od všetkého kľúča

Čo to znamená v jednoduchej angličtine? V databáze to znamená, že všetky stĺpce v riadku by mali byť priamo závislé od akýchkoľvek kandidátskych kľúčov daného riadku.

Poďme sa teda opäť pozrieť na Kontakt:

Tu je kľúčom vygenerovaná hodnota ID, ktorá sa niekedy označuje ako náhradný kľúč. Závisia atribúty adresy od ID kontaktu? No ...

Všetko záleží na doméne.

Šesť vlastností adresy určite nie sú atribútmi Kontaktu, ale sú skôr prostriedkom na identifikáciu fyzického umiestnenia. Je možné, že kontakt môže mať veľa adries a adresa môže mať veľa kontaktov.

Malo by sa to modelovať ako vzťah medzi mnohými, s niektorým typom objektu ContactAddress, ktorý má ID kontaktu a ID adresy? Bude to závisieť od toho, čo je pre vašu doménu aplikácie dôležité. Niektoré aplikácie môžu považovať kontakty za silné entity nezávislé od adresy, ale adresy za slabé entity závislé od existencie kontaktu. V takom prípade môže mať jeden kontakt veľa adries a každá adresa odkazuje na kontakt, napríklad takto:

Existuje potenciálna anomália údajov: ak zmeníte adresu jedného kontaktu, nezmeníte rovnakú adresu pre všetky kontakty. Ak je kontakt vašim primárnym zdrojom referencie, môže to byť požadované správanie: kontakt sa presunie (povedzme do inej organizácie) a zostávajúce kontakty zostanú na svojom mieste.

3NF: Žiadne závislosti od nekľúčových atribútov

Pri opätovnom pohľade na adresu môžete zistiť dve závislé polia, región a krajinu. Krajina môže, ale nemusí mať regióny, ale región má krajinu: nechcete ich miešať.

Jedným zo spôsobov, ako zabezpečiť, aby región patril do správnej krajiny, je vytvorenie identifikátora pre každý pár (krajina, región), potom adresa musí odkazovať na identifikátor, a nie na región a krajinu nezávisle:

Slovo o generovaných identifikátoroch

Podľa môjho názoru sú vygenerované identifikátory podrobnosťou implementácie a kód klienta ich skutočne potrebuje iba pri úprave alebo odstránení back-end záznamu (napríklad riadku v databáze), nikdy však nie ako súčasť dopytu iba na čítanie. Používateľ systému by ich tiež nemal nikdy vidieť, pretože sú nezmyselné.

Tabuľka podľa typu, hierarchia tabuliek podľa typu

Úhľadné na normalizovaných typoch objektov je, že sa ľahko mapujú na tabuľky relačnej databázy. Pre implementáciu relačnej databázy tabuľky odrážajú typy objektov (tabuľka podľa typu) alebo aspoň obsahujú informácie o viacerých typoch odvodených od základného typu (hierarchia tabuliek podľa typov). Môže to znieť, akoby som obhajoval objektovo-relačné mapovanie, ale nie ... iba hovorím, že je užitočné, aby váš logický model zdieľal rovnaké vlastnosti ako fyzikálny model aj pri koncepčnomúrovni. Implementácia je úplne ďalším predmetom.

Referencie

Existuje veľa zdrojov o normalizácii schém relačnej databázy:

Normalizácia databázy: Prvá, druhá a tretia normálna forma - Andrew Rollins

Pred niekoľkými týždňami som si prečítal skvelé vysvetlenie prvej, druhej a tretej normálnej formy. Pre tých, ktorí vedia, aká databáza ...

www.andrewrollins.com

Druhá normálna forma databázy vysvetlená v jednoduchej angličtine

Druhý príspevok sa zameral na prvú normálnu formu, jej definíciu a príklady, ktoré ju kladú domov. Teraz je čas ...

www.essentialsql.com

Čo je druhá normálna forma (2NF)? - Definícia z Techopedia

Definícia druhej normálnej formy 2NF - Druhá normálna forma (2NF) je druhým krokom pri normalizácii databázy. 2NF stavia…

www.techopedia.com

Tretia normálna forma databázy vysvetlená jednoduchou angličtinou

Tretí príspevok sa zameral na druhú normálnu formu, jej definíciu a príklady, ktoré ju kladú domov. Akonáhle je stôl v ...

www.essentialsql.com

Pri výskume tohto príspevku som tiež narazil na trochu iný pohľad na to, ako uplatňovať normalizačné pravidlá na typy objektov.

Úvod do normalizácie triedy

www.agiledata.org