Normalizacija relacijskih baz podatkov — pomen in normalne oblike

Normalizacija relacijskih baz podatkov: pomen, 1.–3. normalna oblika ter kako zmanjšati redundanco, izboljšati integriteto in optimizirati oblikovanje zbirk.

Normalizacija podatkovnih zbirk je pristop k oblikovanju podatkovnih zbirk, ki ga je v sedemdesetih letih prejšnjega stoletja uvedel Edgar F. Codd. Nekatere zbirke podatkov, znane kot relacijske zbirke podatkov, omogočajo shranjevanje podatkov v ločenih skupinah. Vsaka skupina se običajno imenuje tabela. Za zagotavljanje uporabnih informacij so te skupine med seboj povezane. Na primer, učenci so lahko shranjeni v eni skupini, razredi pa v drugi skupini. Da bi pokazali, da je učenec vpisan v razred, se vzpostavi "razmerje" med eno in drugo skupino. Učenec ima lahko povezavo z več razredi, v katere je vpisan, medtem ko ima razred povezavo z več učenci.

Tradicionalna alternativa je "podatkovna zbirka z ravnimi datotekami", v kateri so vsi podatki združeni kot v preglednici. Težava pri podatkovnih zbirkah z ravnimi datotekami je, da imajo lahko veliko praznih mest in da je treba pri vsakem vnosu ponoviti veliko informacij. To pomeni, da je podatkovna zbirka večja, kot bi morala biti, zato je večja verjetnost, da bodo v njej napake. Relacijske podatkovne zbirke z razdelitvijo podatkov v skupine zmanjšujejo možnost napak in ne zavzemajo več prostora, kot je potrebno. Vendar mora biti za njeno delovanje dobro zasnovana.

Normalizacija podatkovnih zbirk je metoda oblikovanja dobrih relacijskih podatkovnih zbirk. Obstaja več "normalnih oblik", od katerih ima vsaka pravila, ki jih mora zbirka podatkov izpolnjevati. Codd je prvotno določil tri sklope meril, ki jih morajo izpolnjevati različne podatkovne zbirke: prva, druga in tretja normalna oblika.

Če relacija (ali tabela podatkovne zbirke) ustreza določeni normalni obliki, ni ranljiva za določene spremembe, ki bi vplivale na celovitost podatkov. Slabost izpolnjevanja takšnih meril je običajno ta, da je poizvedovanje po določenih podatkih iz zbirke podatkov težje.

Zakaj normalizirati?

Glavni cilji normalizacije so:

• odstraniti podvajanje (redundanco) podatkov,
• preprečiti anomalije pri posodabljanju, vstavljanju in brisanju podatkov,
• zagotoviti jasne odvisnosti med podatki in ohraniti integriteto.

Normalizacija pomaga zagotoviti, da je vsaka informacija shranjena na enem mestu (enkrat), kar zmanjša možnost neskladij in napak. Brez normalizacije se lahko pojavljajo:

• Update anomalije — ob posodobitvi podatka ga je treba spremeniti na več mestih;
• Insert anomalije — ni mogoče vstaviti novega zapisa, ker manjkajo drugi podatki;
• Delete anomalije — z brisanjem zapisa se izgubi druge pomembne informacije.

Normalne oblike (povzetek)

Normalne oblike so naraščajoči nabor pravil. Če tabela izpolnjuje višjo normalno obliko, izpolnjuje tudi vse nižje.

• Prva normalna oblika (1NF): vsi atributi morajo biti atomski (ne-manjski/seznam) in tabela mora imeti definirano primarno ključ. Ni več polj, ki vsebujejo več vrednosti v eni celici.
• Druga normalna oblika (2NF): tabela je v 1NF in vsi neključni atributi so popolnoma funkcionalno odvisni od celotnega primarnega ključa. To zlasti zadeva tabele z sestavljenim (večstolpčnim) primarnim ključem — ne sme biti delnih odvisnosti.
• Tretja normalna oblika (3NF): tabela je v 2NF in noben neključni atribut ni transitivno odvisen od primarnega ključa (tj. ne obstajajo odvisnosti tipa A → B → C, kjer sta B in C neključna).
• Boyce–Codd normalna oblika (BCNF): strožja različica 3NF; zahteva, da je za vsako funkcionalno odvisnost X → Y, X superključ. Uporablja se, ko 3NF še vedno dopušča določene anomalije.
• Četrta normalna oblika (4NF): tabela je v BCNF in nima večmnožičnih odvisnosti (multi-valued dependencies), kjer en atribut neodvisno navaja več vrednosti povezanih z istim ključem.
• Peta normalna oblika (5NF): tabela je razbitna tako, da se vse informacije lahko rekonstruirajo samo z naravnimi združitvami (joins) brez izgub; obravnava kompleksne odvisnosti (join dependencies).

Funkcionalne odvisnosti in ključi

Temelj normalizacije so funkcionalne odvisnosti: relacija med atributi, kjer vrednost enega (ali skupine) atributov enolično določa vrednost drugega atributa. Identificiranje primarnih ključev in teh odvisnosti je prvi korak pri normalizaciji. Primarni ključ je atribut ali kombinacija atributov, ki enolično identificira vrstico v tabeli; tu so pomembni tudi tuji ključi za modeliranje povezav med tabelami.

Primer (poenostavljeno)

Imamo tabelo Vpis s stolpci: UcenecID, UcenecIme, RazredID, RazredIme. Če se ime razreda ponavlja za več učencev, imamo redundanco. Normalizacija bi povzročila dve tabeli: Ucenec(UcenecID, UcenecIme) in Razred(RazredID, RazredIme) ter povezovalno tabelo Vpis(UcenecID, RazredID). Tako se ime razreda shrani samo enkrat.

Prednosti in kompromisi

• Prednosti: manjše shranjevanje, manj napak, lažja vzdržljivost podatkov, boljša integriteta.
• Slabosti: več poizvedb in združitev (joins) za pridobitev istovrstnih informacij, kar lahko zmanjša učinkovitost pri branju; kompleksnejše sheme in več tabel.

V praksi se pogosto uporablja kompromis: normalizacija za ohranjanje integritete in smiselna denormalizacija na mestih, kjer so zahteve po zmogljivosti visoke (npr. v sistemih za poročanje ali pri velikih OLAP poizvedbah).

Praktični nasveti

• Začnite z modeliranjem entitet, atributov in povezav ter identificirajte primarne ključe in funkcionalne odvisnosti.
• Uporabite normalizacijo postopoma: dosežite vsaj 3NF ali BCNF, razen če imate utemeljen razlog za denormalizacijo.
• Uporabite indekse na stolpcih, ki se pogosto uporabljajo v poizvedbah in pri povezavah (FOREIGN KEY), da ublažite stroške joinov.
• Uvedite omejitve celovitosti (constraints) in tuje ključe, da baza avtomatsko preprečuje neskladne podatke.
• Pri načrtovanju upoštevajte tipične poizvedbe in obremenitve: če baza predvsem bere podatke za poročila, je smiselna omejena denormalizacija.
• Testirajte s primeri vstavitev, posodobitev in brisanja, da preverite, ali so odpravljene anomalije.

Zaključek

Normalizacija je temeljna tehnika za načrtovanje relacijskih podatkovnih zbirk, ki izboljša zanesljivost in zmanjšuje redundanco. Poznavanje normalnih oblik in funkcionalnih odvisnosti pomaga ustvariti čiste, enostavne za vzdrževanje podatkovne modele. Hkrati pa je treba pri načrtovanju upoštevati tudi zmogljivost — v realnih sistemih navadno kombiniramo ustrezno normalizacijo s premišljeno denormalizacijo tam, kjer je to potrebno za dosego zahtevanih performans.

Vprašanja in odgovori

V: Kaj je normalizacija podatkovnih zbirk?

V: Kaj je podatkovna zbirka s ploščatimi datotekami?

V: Kako relacijske podatkovne zbirke zmanjšajo možnost napak?

V: Kaj so normalne oblike?

V: Katere so pomanjkljivosti izpolnjevanja določenih sklopov meril za normalne oblike?

Išči po črki