DBMS normalizacija: 1NF, 2NF, 3NF primjer baze podataka

Normalizacija ukratko

Normalizacija je proces strukturiranja baze podataka kako bi se smanjila redundancija i poboljšala konzistentnost. Jednostavno rečeno, ona razbija velike, neuredne tablice u manje, dobro organizirane. To osigurava logičko pohranjivanje podataka, čineći baze podataka učinkovitima, jednostavnima za održavanje i bez dupliciranja ili pogrešaka.

Što je normalizacija baze podataka?

Normalizacija baze podataka je tehnika dizajna baze podataka koja smanjuje redundantnost podataka i eliminira nepoželjne karakteristike poput anomalija umetanja, ažuriranja i brisanja. Pravila normalizacije dijele veće tablice u manje tablice i povezuju ih pomoću odnosa. Svrha normalizacije u SQL-u je eliminirati suvišne (ponavljajuće) podatke i osigurati da su podaci pohranjeni logično.

Izumitelj je relacijski model Edgar Codd je predložio teoriju normalizacije podataka uvođenjem prve normalne forme, a nastavio je proširivati ​​teoriju drugom i trećom normalnom formom. Later pridružio se Raymondu F. Boyceu kako bi razvio teoriju Boyce-Coddovog normalnog oblika.

Zašto nam je potrebna normalizacija?

Bez normalizacije, baze podataka brzo postaju nekonzistentne i redundantne. Problemi poput anomalije umetanja (nepotpuni zapisi se ne mogu dodati), ažuriranje anomalija (promjene na jednom mjestu ne odražavaju se svugdje) i anomalije brisanja (slučajno uklanjanje podataka briše vrijedne informacije) često se javljaju. Normalizacija uklanja te probleme, osigurava integritet podataka, smanjuje dupliciranje i pojednostavljuje upravljanje bazom podataka.

Koje su vrste normalnih formi u DBMS-u?

Ovdje je popis normalnih obrazaca u SQL-u:

• 1NF (Prvi normalni oblik): Osigurava da je tablica baze podataka organizirana tako da svaki stupac sadrži atomske (nedjeljive) vrijednosti, a svaki je zapis jedinstven. Ovo eliminira grupe koje se ponavljaju, čime se podaci strukturiraju u tablice i stupce.
• 2NF (drugi normalni oblik): Nadovezuje se na 1NF prema Moramo ukloniti suvišne podatke iz tablice koji se primjenjuju na više redaka. i stavljajući ih u zasebne tablice. Zahtijeva da svi ne-ključni atributi budu potpuno funkcionalni na primarnom ključu.
• 3NF (Treći normalni oblik): Proširuje 2NF osiguravajući da su svi ne-ključni atributi ne samo potpuno funkcionalni na primarnom ključu, već i neovisni jedni o drugima. Ovo eliminira tranzitivnu ovisnost.
• BCNF (Boyce-Coddov normalni oblik): Poboljšanje 3NF-a koje rješava anomalije koje 3NF ne rješava. Zahtijeva da svaka determinanta bude ključ kandidata, čime se osigurava još strože pridržavanje pravila normalizacije.
• 4NF (četvrti normalni oblik): Rješava ovisnosti s više vrijednosti. Osigurava da u zapisu nema više neovisnih viševrijednih činjenica o entitetu.
• 5NF (peti normalni oblik): Također poznat kao "Projection-Join Normal Form" (PJNF), odnosi se na rekonstrukciju informacija iz manjih, različito raspoređenih dijelova podataka.
• 6NF (šesti normalni oblik): Teoretski i nije široko primijenjen. Bavi se vremenskim podacima (rukovanje promjenama tijekom vremena) daljnjom dekompozicijom tablica kako bi se uklonila sva nevremenska redundantnost.

Teorija normalizacije podataka u MySQL poslužitelj se i dalje razvija. Na primjer, rasprave se vode čak i na 6^th Normalna forma. Međutim, u većini praktičnih primjena normalizacija najbolje postiže u 3^rd Normalna forma. Evolucija normalizacije u SQL teorijama ilustrirana je u nastavku-

Normalizacija baze podataka s primjerima

Baza podataka Primjer normalizacije može se lako razumjeti uz pomoć studije slučaja. Pretpostavimo da videoteka održava bazu podataka iznajmljenih filmova. Bez ikakve normalizacije u bazi podataka, sve informacije su pohranjene u jednoj tablici kao što je prikazano u nastavku. Razumimo bazu podataka normalizacije s primjerom normalizacije s rješenjem:

Evo vidite Stupac Iznajmljeni filmovi ima više vrijednosti. Sada prijeđimo na 1. normalne forme:

Prvi uobičajeni obrazac (1NF)

• Svaka ćelija tablice treba sadržavati jednu vrijednost.
• Svaki zapis mora biti jedinstven.

Gornja tablica u 1NF-

1NF primjer

Prije nego što nastavimo, shvatimo nekoliko stvari —

Što je KEY u SQL-u

A KEY u SQL-u je vrijednost koja se koristi za jedinstvenu identifikaciju zapisa u tablici. SQL KEY je jedan stupac ili kombinacija više stupaca koji se koriste za jedinstvenu identifikaciju redaka ili torki u tablici. SQL ključ se koristi za identifikaciju dupliciranih informacija, a također pomaže uspostaviti odnos između više tablica u bazi podataka.

Napomena: Stupci u tablici koji se NE koriste za jedinstvenu identifikaciju zapisa nazivaju se neključni stupci.

Što je primarni ključ?

Primarna je vrijednost jednog stupca koja se koristi za jedinstvenu identifikaciju zapisa baze podataka.

Ima sljedeće atribute

• A Osnovni ključ ne može biti NULL
• Vrijednost primarnog ključa mora biti jedinstvena
• Vrijednosti primarnog ključa rijetko bi se trebale mijenjati
• Primarni ključ mora dobiti vrijednost kada se umetne novi zapis.

Što je kompozitni ključ?

Složeni ključ je primarni ključ sastavljen od više stupaca koji se koriste za jedinstvenu identifikaciju zapisa

U našoj bazi podataka imamo dvije osobe s istim imenom Robert Phil, ali žive na različitim mjestima.

Stoga zahtijevamo i puno ime i adresu kako bismo jedinstveno identificirali zapis. To je kompozitni ključ.

Prijeđimo na drugu normalnu formu 2NF

Drugi normalni obrazac (2NF)

• Pravilo 1- Budite u 1NF
• Pravilo 2- Primarni ključ jednog stupca koji funkcionalno ne ovisi ni o jednom podskupu relacije ključa kandidata

Jasno je da ne možemo krenuti naprijed kako bismo napravili našu jednostavnu bazu podataka u 2^nd Normalizacijski obrazac osim ako ne podijelimo gornju tablicu.

Našu tablicu 1NF podijelili smo u dvije tablice, tj. Tablica 1 i Tablica 2. Tablica 1 sadrži podatke o članovima. Tablica 2 sadrži podatke o posuđenim filmovima.

Uveli smo novi stupac pod nazivom Membership_id koji je primarni ključ za tablicu 1. Zapisi se mogu jedinstveno identificirati u tablici 1 pomoću ID-a članstva

Baza podataka – strani ključ

U tablici 2, Membership_ID je vanjski ključ

Strani ključ upućuje na primarni ključ druge tablice! Pomaže u povezivanju vaših tablica

• Strani ključ može imati različit naziv od primarnog ključa
• Osigurava da redovi u jednoj tablici imaju odgovarajuće retke u drugoj
• Za razliku od primarnog ključa, oni ne moraju biti jedinstveni. Najčešće nisu
• Strani ključevi mogu biti null iako primarni ključevi ne mogu

Zašto vam treba strani ključ?

Pretpostavimo da početnik unese zapis u tablicu B kao što je

U svoj vanjski ključ moći ćete umetnuti samo vrijednosti koje postoje u jedinstvenom ključu u nadređenoj tablici. To pomaže u referencijalnom integritetu.

Gore navedeni problem može se prevladati deklariranjem ID-a članstva iz Tablice2 kao stranog ključa ID-a članstva iz Tablice1

Sada, ako netko pokuša umetnuti vrijednost u polje ID članstva koja ne postoji u nadređenoj tablici, prikazat će se pogreška!

Što su tranzitivne funkcionalne ovisnosti?

Prijelazna funkcionalna ovisnost je kada mijenja ne-ključni stupac, može uzrokovati promjenu bilo kojeg drugog ne-ključnog stupca

Razmotrite tablicu 1. Promjena punog imena u stupcu koji nije ključ može promijeniti pozdrav.

Idemo u 3NF

Treći uobičajeni obrazac (3NF)

• Pravilo 1- Budite u 2NF
• Pravilo 2- Nema tranzitivnih funkcionalnih ovisnosti

Da bismo našu tablicu 2NF premjestili u 3NF, ponovno moramo podijeliti našu tablicu.

3NF primjer

Ispod je primjer 3NF u SQL bazi podataka:

Ponovo smo podijelili naše stolove i napravili novu tablicu koja pohranjuje pozdrave.

Nema tranzitivnih funkcionalnih ovisnosti, pa je stoga naša tablica u 3NF

U tablici 3 ID pozdrava je primarni ključ, au tablici 1 ID pozdrava je stran primarnom ključu u tablici 3

Sada je naš mali primjer na razini koja se ne može dalje dekomponirati da bi se postigla viša normalna forma tipova normalizacije u DBMS-u. Zapravo, već je u višim oblicima normalizacije. U složenim bazama podataka obično su potrebni zasebni napori za prelazak na sljedeće razine normaliziranja podataka. Međutim, u nastavku ćemo ukratko raspravljati o sljedećim razinama normalizacije u DBMS-u.

Boyce-Coddov normalni oblik (BCNF)

Čak i kada je baza podataka u 3^rd Normalan oblik, ipak će biti anomalija ako ima više od jednog Kandidat Ključ.

Ponekad se BCNF također naziva 3.5 Normalni oblik.

Četvrti normalni oblik (4NF)

Ako nijedna instanca tablice baze podataka ne sadrži dva ili više neovisnih i viševrijednih podataka koji opisuju relevantni entitet, tada je u 4^th Normalna forma.

Peti normalni oblik (5NF)

Stol je u 5^th Normalni oblik samo ako je u 4NF i ne može se rastaviti na bilo koji broj manjih tablica bez gubitka podataka.

Predloženi šesti normalni oblik (6NF).

6^th Normal Form nije standardiziran, ali stručnjaci za baze podataka raspravljaju o njemu već neko vrijeme. Nadamo se da ćemo imati jasnu i standardiziranu definiciju za 6^th Normalna forma u bliskoj budućnosti…

Koje su prednosti normalizacije?

• Poboljšajte dosljednost podataka: Normalizacija osigurava da je svaki podatak pohranjen na samo jednom mjestu, čime se smanjuju šanse nedosljednih podataka. Kada se podaci ažuriraju, potrebno ih je ažurirati samo na jednom mjestu, čime se osigurava dosljednost.
• Smanjite redundantnost podataka: Normalizacija pomaže eliminirati duple podatke tako što ih dijeli u više povezanih tablica. To može uštedjeti prostor za pohranu i učiniti bazu podataka učinkovitijom.
• Poboljšajte izvedbu upita: Normalizirane baze podataka često je lakše postavljati upite. Budući da su podaci organizirani logično, upiti se mogu optimizirati za brže izvođenje.
• Učinite podatke smislenijim: Normalizacija uključuje grupuping podatke na način koji ima smisla i intuitivan je. To može olakšati razumijevanje i korištenje baze podataka, posebno za ljude koji nisu dizajnirali bazu podataka.
• Smanjite šanse za anomalije: Anomalije su problemi koji se mogu pojaviti prilikom dodavanja, ažuriranja ili brisanja podataka. Normalizacija može smanjiti šanse za ove anomalije osiguravajući da su podaci logično organizirani.

Koji su nedostaci normalizacije?

• Povećana složenost: Normalizacija može dovesti do složenih odnosa. Velikim brojem tablica sa stranim ključevima može biti teško upravljati, što dovodi do zabune.
• Smanjena fleksibilnost: Zbog strogih pravila normalizacije, može biti manje fleksibilnosti u pohranjivanju podataka koji se ne pridržavaju tih pravila.
• Povećani zahtjevi za pohranu: Iako normalizacija smanjuje redundanciju, možda će biti potrebno dodijeliti više prostora za pohranu za smještaj dodatnih tablica i indeksa.
• Dodatni troškovi izvedbe: Spajanje više tablica može biti skupo u smislu izvedbe. Što su podaci normaliziraniji, potrebno je više spajanja, što može usporiti vrijeme dohvaćanja podataka.
• Kontekst gubitka podataka: Normalizacija rastavlja podatke u zasebne tablice, što može dovesti do gubitka poslovnog konteksta. Ispitivanje povezanih tablica neophodno je za razumijevanje konteksta podataka.
• Potreba za stručnim znanjem: Implementacija normalizirane baze podataka zahtijeva duboko razumijevanje podataka, odnosa između podataka i pravila normalizacije. To zahtijeva stručno znanje i može oduzimati puno vremena.

To je sve za SQL normalizaciju!!!

Pitanja i odgovori

Rezime