Stavljanje baze podataka u drugu normalnu formu
Tokom proteklog mjeseca, pogledali smo nekoliko aspekata normalizacije tabele baze podataka. Prvo smo razgovarali o osnovnim principima normalizacije baze podataka. Prošli put smo istražili osnovne zahteve koje je postavio prvi normalni oblik (1NF). Sada, nastavimo putovanje i pokrivamo principe drugog normalnog oblika (2NF).
Podsjetimo na opšte zahtjeve 2NF:
- Uklonite podskupove podataka koji se odnose na više redova tabele i stavite ih u zasebne tabele.
- Stvorite odnose između ovih novih tabela i njihovih prethodnika koristeći strane ključeve.
Ova pravila se mogu rezimirati u jednostavnom izlaganju: 2NF pokušava smanjiti količinu redundantnih podataka u tablici tako što će ga izvući, staviti u novu tabelu i stvoriti veze između tih tabela.
Pogledajmo primer. Zamislite online prodavnicu koja održava informacije o kupcima u bazi podataka. Možda imaju jednu tablicu koja se naziva Kupci sa sledećim elementima:
- CustNum
- Ime
- Prezime
- Adresa
- Grad
- Država
- ZIP
Kratak pogled na ovu tabelu otkriva malu količinu redundantnih podataka. Mi čuvamo "Sea Cliff, NY 11579" i "Miami, FL 33157" stavke dvaput svaki. Sada, to možda ne izgleda kao previše dodato skladištenje u našem jednostavnom primeru, ali zamislite izgubljeni prostor ako imamo na hiljadama redova na našem stolu. Pored toga, ako bi se poštanski broj za morsku skalu morao promijeniti, moramo izvršiti tu promjenu na mnogim mjestima u cijeloj bazi podataka.
U strukturi baze podataka koja odgovara 2NF, ove redundantne informacije se izdvajaju i čuvaju u posebnoj tabeli. Naša nova tabela (naziva se ZIPs) može imati sljedeća polja:
- ZIP
- Grad
- Država
Ako želimo da budemo super-efikasni, možemo čak i popuniti ovu tabelu unaprijed - pošta pruža imenik svih važećih poštanski kodova i odnosa između njih i grada / države. Sigurno ste naišli na situaciju u kojoj se koristi ova vrsta baze podataka. Neko ko je naručio nalog možda je prvo tražio vaš poštanski broj, a zatim je znao grad i državu iz kojeg ste pozvali. Ova vrsta aranžmana smanjuje grešku operatora i povećava efikasnost.
Sada kada smo uklonili duplikate podataka iz tabele Kupci, zadovoljili smo prvo pravilo drugog normalnog oblika. I dalje moramo da koristimo inostrani ključ za povezivanje dve tabele zajedno. Mi ćemo koristiti ZIP kod (primarni ključ iz tabele ZIPs) da biste kreirali taj odnos. Evo nove tabele kupaca:
- CustNum
- Ime
- Prezime
- Adresa
- ZIP
Sada smo minimizirali količinu redundantnih informacija čuvanih u bazi podataka i naša struktura je u drugoj normalnoj formi!
Ako želite osigurati normalizaciju vaše baze podataka, istražite naše ostale članke u ovoj seriji:
- Osnovne osnove za bazu podataka
- Postavljanje vaše baze podataka u prvu normalnu formu
- Postavljanje vaše baze podataka u drugu normalnu formu
- Postavljanje vaše baze podataka u treću normalnu formu