NORMALIZÁCIA  DATABÁZ

Lekcia normálnych foriem 1NF,2NF,3NF a Boyce-Codd

Prehľad problému.

Vo chvíli keď profesori inštitútu Penn State's Management Information Systems - no môžete si sem dosadiť aj hociakú inú školu - začnú vysvetlovať a učiť normalizáciu a implementáciu návrhu databáz   výchádza najavo, že je tu určitý zádrhel v učebných schopnostiach profesorov. Študenti sa často ocitajú v situácii, keď bojujú s vecami, ktoré by sa efektívnejšie mohli učiť cez Internet - s príkladmi, diagramami a vysvetlivkami. Výsledkom  klasických metódach používaných profesormi je, že študenti sa plahočia v problematike. Samozrejme aj keď profesori často majú obrovské znalosti v danej problematike, nerozumejú jednej veci a to: ako predostrieť znalosti študentom v jednoduchej forme na pochopenie a zapamätanie. 

Skúsenosti - skills Analysis

Skúsenosti na ktoré sa zameriava tento výukový materiál a lekcie sú súčasne analýzou a aplikáciou ideí prezentovaných v tomto projekte. Začneme s definíciami datových entít a jej atribútmi, a ako sa tieto pretransformujú do databázovej tabuľky.  Vytváranie databázových tabuliek a schém je hlavným cieľom týchto lekcií. Uvedieme vás do definícií viacerích databázových normalizačných foriem, od prvej až po tretiu a nakoniec aj  Boyce-Coddovou normalizačnú formu. Študenti potrebujú zvládnuť schopnosť analyzovať každý jeden príklad a konvertovať ho do najvyššej normalnej formy.  Akonáhle skompletizujú prvú polovičku lekcií, presunú sa z abstrtaktnej definície tabuľky do aktuálnej fyzickej definície tabuľky. Budú uvedení do problematiky indexov a ich vplyvu na výkon databázy v závislosti od jej veľkosti.  Toto bude vyžadovať syntézu a  ocenenie všetkých ich abstraktných databázových skúseností  a poznatkov počítačových procesov.

Úvodné skúsenosti a charakteristiky

Pretože cieľové publikum sú študenti kurzov v úvode uvedenej školy Management Information Systems, očakáva sa od nich schopnosť osvojenia si abstraktných koncepcií, akou je teória relačných databáz. Predtým ako študenti začnú tieto lekcie, bude sa od nich očakávať, že budú rozumieť databázovým vzťahom medzi entitami a ako sa tieto transformujú do Entitovo-relačného (Entity-Relationship = ER) modelu diagramov. Taktiež sa od nich očakáva znalosť  SQL jazyka  Structured Query Language (SQL) na výber, vloženie, modifikovanie a rušenie v databázových tabuľkách.  Toto samozrejme vyžaduje znalosť počítačových systémov, ktoré sú potrebné pre hľadanie riešení v učebných textoch a v lekciách.

Väčšina učiacich sa ktorí budú sa podielať na týchto lekciách budú aktívnymi žiakmi a naučia sa veľa používaním týchto skúseností po tom, ako budú uvedení do koncepcie normalizácie. Motiváciou učenia sa na týchto lekciách je  dvojakého druhu, jednak dosiahnutie vysokého stupňa v ich MIS kurzoch, ako aj dlhodobý cieľ profitovania na činnosti založenej na týchto skúsenostiach. Študenti ocenia on_line výuku pretože môžu študovať vo svojom zázemí z ľubovolného počítača s prístupom do internetu. Toto im umožňuje rozčleniť výuku do časových harmonogramov podľa ich výberu v ľubovolný čas dňa.

Prínos výuky

• Je daných 5 príkladov tabuliek schém, študenti budú schopní identifikovať ich normalizačnú úroveň prinajmenšom za 80 percent času.

• Je daný ER model, študenti budú schopní vytvoriť funkčnú množinu normalizovaných tabuliek v Boyce-Codd-ovej normalnej forme.

• Z ich množín normalizovaných tabuliek v predoslých odsekoch, študenti budú schopní navrhnúť fyzickú definíciu tabuľkovej štruktúry, ktorá bude v súlade s najlepšími pravidlami použitých v lekciách. 

• Je daný vzor definície tabuľky, študenti budú schopní posúdiť výhody a nevýhody indexovania každého stĺpca v tabuľke, demonštrovaním poznatkov o prevádzkových efektoch ich použitia.

Príklad

Riešenie Prvej normálnej formy (1NF) 

Uvažujme nad nasledovnou tabuľkou Navštevované kurzy.  

Ktorý študent navštevuje kurz 3100? Na toto je ťažko odpovedať pretože odpoveď sa schováva vo viac hodnotovej položke Kurz.
Preto odstráňme viachodnotovú položku Kurz a nahradme ho jednoúdajovými položkami:

Polia Kurz1,Kurz2,Kurz3  reprezentujú opakujúcu sa skupinu. Takto riešené tabuľky majú niekoľko nevýhod. Nie sú dostatočne univerzálne, aby zohľadnili aj študentov, ktorí navšetevujú viac kurzov napr. 5. Na druhej strane údaje študent navštevujúceho 1 kurz bude zaberať v pamäti databázy 2 zbytočné údajové polia. Ak chceme zistiť odpoveď musíme tabuľku prehľadávať aplikáciou, ktorá osobitne otestuje tri samostatné údajové polia pri každom študentovi. Ak sa v poli údaj nenachádza operácia je zbytočná a len zabrala čas.

 Správna cesta je odstrániť opakujúcu sa skupinu a vytvoriť nasledovnú tabuľku, ktorá vyhovie pravidlám 1.NF.

 Teraz už je jednoduchšie zistiť ktorý kurz je kým navštevovaný. 


Príklad Druhej normálnej formy  (2NF) 

Uvažujme nad tabuľkou Tabuľka kurzov študenta, v ktorej je zložený primárny kľúč z IDStudenta a IDKurzu.

Tu je problém pri modifikovaní údajov. Predstavte si ze sa zmeni Miesto Kurzu. V tej chvíli aplikácia musí nájsť všetky výskyty konkrétneho miesta v záznamoch ktoré súvisia s touto informáciou a všade sa musí uskutočniť zmena. Aby tak nebolo rozdelime tabuľku do samostatných tabuliek takto: 

Tabuľka Študentov

  
Tabuľka Kurzov 

 
Tabuľka študentových kurzov. 

V tejto chvíli zmena názvu miesta kurzu sa týka zmeny jedinej údajovej položky v Tabuľke kurzov.   

Príklad Tretej normálnej formy  (3NF) 

Semestrálna tabuľka Kurzov

Profesor sa v tabuľke jednoznačne identifikuje zloženým kľúčom IDKurzu a Semester. V tomto prípade MenoProfesora závisí od IDProfesora ale nezávisí priamo od zloženého kľúča IDKurzu a Semester. Táto tranzitívna závislosť sa vyrieši rozdelením tabuľky: 

Tabuľka Profesorov

Semestrálna tabuľka Kurzov.

      
Ak by sme vzali do úvahy originál tabuľky Semestrálnej tabuľky kurzov mohla by tu vzniknúť situácia, keď napr. v druhom riadku preklep poškodí meno z David na Davif. V databáze by vznikla nejednoznačnosť. Nikto by nevedel určiť ako má meno správne znieť. Časť informácií by bola správne a časť nesprávne. Po odstránení tranzitívnosti sa situácia zmení v tom zmysle, že meno je evidované len jediný raz. Ak by aj vznikol preklep, jeho zmena sa dá uskutočniť na jedinom mieste pre všetky náväzné súvislosti v databáze.