KAKŠNA JE TRETJA NORMALNA OBLIKA? (BAZE PODATKOV) - TEHNOLOGIJA - 2025

Tretja normalna oblika (podatkovne baze) je relacijska načrtovanje podatkovne baze tehniko, kjer se različne tabele, ki ga sestavljajo, v skladu ne le z drugo normalno obliko, ampak vsi njegovi atributi ali polja so neposredno odvisni od primarnega ključa.

Pri načrtovanju baze podatkov je glavni cilj ustvariti natančno predstavitev podatkov, razmerja med njimi in omejitve za podatke, ki so pomembni.

Vir: pixabay.com

Za dosego tega cilja je mogoče uporabiti nekatere tehnike oblikovanja baz podatkov, med katerimi je normalizacija.

To je postopek organiziranja podatkov v bazi podatkov, da se prepreči odpuščanje in morebitne nepravilnosti pri vstavljanju, posodabljanju ali odpravi podatkov, pri čemer nastane enostavna in stabilna zasnova konceptualnega modela.

Začne se s preučevanjem funkcionalnega odnosa ali odvisnosti med atributi. Te opisujejo neko lastnost podatkov ali razmerje med njimi.

Običajne oblike

Normalizacija uporablja vrsto testov, imenovanih običajne oblike, ki pomagajo določiti optimalno združevanje teh lastnosti in na koncu vzpostavijo ustrezen nabor odnosov, ki podpirajo potrebe po podatkih podjetja.

Se pravi, da je tehnika normalizacije zgrajena okoli koncepta normalne oblike, ki definira sistem omejitev. Če razmerje ustreza omejitvam določene normalne oblike, naj bi bilo razmerje v normalni obliki.

Prva normalna oblika (1FN)

Tabela naj bi bila v 1FN, če vsi atributi ali polja v njej vsebujejo samo enkratne vrednosti. Se pravi, vsaka vrednost za vsak atribut mora biti nedeljiva.

Po definiciji bo relacijska podatkovna baza vedno normalizirana na prvo normalno obliko, saj so vrednosti atributov vedno atomske. Vsa razmerja v bazi podatkov so v 1FN.

Vendar pa preprosto zapuščanje baze podatkov takšno povzroči številne težave, kot so odveč in morebitne napake pri nadgradnji. Za odpravo teh težav so bile razvite višje normalne oblike.

Druga normalna oblika (2FN)

Ukvarja se z odstranjevanjem krožnih odvisnosti s tabele. Kaže se, da je razmerje v 2FN, če je v 1FN, poleg tega pa je vsako ne-ključno polje ali atribut v celoti odvisno od primarnega ključa, ali natančneje, zagotavlja, da ima tabela en sam namen.

Atribut brez ključa je vsak atribut, ki ni del primarnega ključa za odnos.

Tretja normalna oblika (3FN)

Ukvarja se z odpravo prehodnih odvisnosti iz tabele. To pomeni, da odstranite ne-ključne atribute, ki niso odvisni od primarnega ključa, ampak od drugega atributa.

Prehodna odvisnost je vrsta funkcionalne odvisnosti, pri kateri je vrednost ne-ključnega polja ali atributa določena z vrednostjo drugega polja, ki prav tako ni ključno.

Iščite ponavljajoče se vrednosti v ne-ključnih atributih, da zagotovite, da ti ključni atributi niso odvisni od nič drugega kot od primarnega ključa.

Kaže se, da so atributi medsebojno neodvisni, če noben od njih ni funkcionalno odvisen od kombinacije drugih. Ta medsebojna neodvisnost zagotavlja, da se atributi lahko posodabljajo posamično, ne da bi prišlo do vpliva na drug atribut.

Zato mora biti odnos v bazi podatkov v tretji običajni obliki v skladu z:

- Vse zahteve 2FN.

- Če obstajajo atributi, ki niso povezani s primarnim ključem, jih je treba odstraniti in postaviti v ločeno tabelo, ki povezuje obe tabeli s tujim ključem. Se pravi, prehodnih odvisnosti ne bi smelo biti.

Primeri tretje normalne oblike

Primer 1

Tabela naj bo STUDENT, katere primarni ključ je identifikacija študenta (STUDENT_ID) in je sestavljena iz naslednjih atributov: STUDENT_NAME, STREET, CITY in POST_CODE, ki izpolnjujejo pogoje za 2FN.

V tem primeru STREET in CITY nimata neposrednega odnosa s primarnim ključem STUDENT_ID, saj nista neposredno povezana s študentom, ampak sta popolnoma odvisna od poštne številke.

Ker se študent nahaja na mestu, ki ga določa CODE_POSTAL, sta STREET in CITY povezana s tem atributom. Zaradi te druge stopnje odvisnosti teh atributov ni treba shraniti v tabelo ŠTUDENT.

Ustvari novo tabelo

Recimo, da ima več študentov nameščenih v isti poštni številki, pri čemer ima tabela STUDENT ogromno zapisov in je treba spremeniti ime ulice ali mesta, potem je treba to ulico ali mesto najti in posodobiti v celotni tabeli ŠTUDENT.

Če morate na primer spremeniti ulico "El Limón" v "El Limón II", boste morali poiskati "El Limón" v celotni tabeli ŠTUDENT in jo nato posodobiti na "El Limón II".

Iskanje v ogromni tabeli in posodabljanje posameznih ali več zapisov bo trajalo dolgo in bo torej vplivalo na delovanje baze podatkov.

Namesto tega se te podrobnosti lahko hranijo v ločeni tabeli (POSTCARD), ki je povezana s tabelo STUDENT z uporabo atributa POST_CODE.

Tabela POST bo imela razmeroma manj zapisov in to tabelo POST bo treba posodobiti le enkrat. To se bo samodejno odrazilo v tabeli ŠTUDENT in poenostavilo bazo podatkov in poizvedbe. Torej bodo tabele v 3FN:

Primer 2

Naslednja tabela naj bo uporabljena s poljem Project_Num kot primarnim ključem in s ponovljenimi vrednostmi v atributih, ki niso ključi.

Vrednost telefona se ponovi vsakič, ko se prikaže ime upravitelja. To je zato, ker je telefonska številka odvisna le od druge stopnje od projektne številke. Res je najprej odvisno od vodje, to pa je odvisno od števila projektov, kar je prehodna odvisnost.

Atribut Project_Manager ne more biti možen ključ v tabeli Projekti, ker isti upravitelj upravlja z več projekti. Rešitev za to je odstranitev atributa s ponovljenimi podatki (Phone) in ustvarjanje ločene tabele.

Ustrezne atribute je treba združiti in ustvariti novo tabelo, da jih shranite. Podatki se vnesejo in preveri, ali ponovljene vrednosti niso del primarnega ključa. Primarni ključ je nastavljen za vsako tabelo in po potrebi so dodani tuji ključi.

Za skladnost s tretjim običajnim obrazcem je ustvarjena nova tabela (Managerji) za rešitev težave. Obe tabeli sta povezani v polju Project_Manager:

Reference

1. Teradata (2019). Prvi, drugi in tretji običajni obrazec. Izvedeno iz: docs.teradata.com.
2. Tutorial Cup (2019). Tretja normalna oblika (3NF). Vzeto iz: tutorialcup.com.
3. Baza podatkov Dev (2015). Tretja normalna oblika (3NF) - normalizacija podatkovne baze. Vzeto iz: databasedev.co.uk.
4. Relacijski DB Design (2019). Uvod v tretjo normalno obliko. Vzeto iz: relationaldbdesign.com.
5. Lutke (2019). Prvi, drugi in tretji običajni obrazec SQL. Vzeto iz: dummies.com.