logo

TechCodeview

Običajni obrazci v DBMS

Normalizacija je proces minimiziranja odvečnost iz relacije ali niza relacij. Redundanca v zvezi lahko povzroči anomalije pri vstavljanju, brisanju in posodabljanju. Torej pomaga zmanjšati odvečnost v odnosih. Normalne oblike se uporabljajo za odpravo ali zmanjšanje redundance v tabelah baze podatkov.

Ranjan Hero za normalizacijo DBMS

V sistemih za upravljanje baz podatkov (DBMS) so običajni obrazci vrsta smernic, ki pomagajo zagotoviti, da je zasnova baze podatkov učinkovita, organizirana in brez podatkovnih anomalij. Obstaja več ravni normalizacije, vsaka s svojim naborom smernic, znanih kot normalne oblike.



Pomembne točke v zvezi z običajnimi obrazci v DBMS

  • Prva normalna oblika (1NF): To je najosnovnejša raven normalizacije. V 1NF mora vsaka celica tabele vsebovati samo eno vrednost, vsak stolpec pa mora imeti edinstveno ime. Prva običajna oblika pomaga odpraviti podvojene podatke in poenostaviti poizvedbe.
  • Druga normalna oblika (2NF): 2NF odpravlja odvečne podatke tako, da zahteva, da je vsak atribut brez ključa odvisen od primarnega ključa. To pomeni, da mora biti vsak stolpec neposredno povezan s primarnim ključem in ne z drugimi stolpci.
  • Tretja normalna oblika (3NF): 3NF gradi na 2NF tako, da zahteva, da so vsi ne-ključni atributi neodvisni drug od drugega. To pomeni, da mora biti vsak stolpec neposredno povezan s primarnim ključem in ne z drugimi stolpci v isti tabeli.
  • Boyce-Codd normalna oblika (BCNF): BCNF je strožja oblika 3NF, ki zagotavlja, da je vsaka determinanta v tabeli kandidatni ključ. Z drugimi besedami, BCNF zagotavlja, da je vsak atribut brez ključa odvisen samo od ključa kandidata.
  • Četrta normalna oblika (4NF): 4NF je nadaljnja izboljšava BCNF, ki zagotavlja, da tabela ne vsebuje odvisnosti z več vrednostmi.
  • Peta normalna oblika (5NF): 5NF je najvišja raven normalizacije in vključuje dekompozicijo tabele na manjše tabele, da se odstrani odvečnost podatkov in izboljša celovitost podatkov.

Običajni obrazci pomagajo zmanjšati odvečnost podatkov, povečati doslednost podatkov in izboljšati učinkovitost baze podatkov. Vendar pa lahko višje stopnje normalizacije privedejo do bolj zapletenih zasnov baze podatkov in poizvedb. Pri načrtovanju baze podatkov je pomembno najti ravnovesje med normalizacijo in praktičnostjo.

Prednosti običajne oblike

  • Zmanjšana redundanca podatkov: Normalizacija pomaga odpraviti podvojene podatke v tabelah, zmanjša količino potrebnega prostora za shranjevanje in izboljša učinkovitost baze podatkov.
  • Izboljšana doslednost podatkov: Normalizacija zagotavlja, da so podatki shranjeni na dosleden in organiziran način, kar zmanjšuje tveganje nedoslednosti podatkov in napak.
  • Poenostavljena zasnova baze podatkov: Normalizacija zagotavlja smernice za organiziranje tabel in odnosov podatkov, kar olajša načrtovanje in vzdrževanje baze podatkov.
  • Izboljšana zmogljivost poizvedb: Po normaliziranih tabelah je običajno lažje iskati in iz njih pridobiti podatke, zaradi česar je poizvedba hitrejša.
  • Enostavnejše vzdrževanje baze podatkov: Normalizacija zmanjša kompleksnost baze podatkov, tako da jo razdeli na manjše, bolj obvladljive tabele, kar olajša dodajanje, spreminjanje in brisanje podatkov.

Na splošno uporaba običajnih obrazcev v DBMS pomaga izboljšati kakovost podatkov, povečati učinkovitost baze podatkov ter poenostaviti načrtovanje in vzdrževanje baze podatkov.

Prva normalna oblika

Če relacija vsebuje sestavljen ali večvrednostni atribut, krši prvo normalno obliko ali pa je relacija v prvi normalni obliki, če ne vsebuje nobenega sestavljenega ali večvrednega atributa. Relacija je v prvi normalni obliki, če je vsak atribut v tej relaciji atribut z enojno vrednostjo .



  • Primer 1 – Relacija STUDENT v tabeli 1 ni v 1NF zaradi večvrednega atributa STUD_PHONE. Njegova razgradnja v 1NF je prikazana v tabeli 2.
Primer

Primer

  • Primer 2 – 
ID Name Courses ------------------ 1 A c1, c2 2 E c3 3 M C2, c3>
  • V zgornji tabeli je Tečaj atribut z več vrednostmi, zato ni v 1NF. Spodnja tabela je v 1NF, ker ni atributa z več vrednostmi
ID Name Course ------------------ 1 A c1 1 A c2 2 E c3 3 M c2 3 M c3>

Druga normalna oblika

Da je relacija v drugi normalni obliki, mora biti v prvi normalni obliki in relacija ne sme vsebovati nobene delne odvisnosti. Relacija je v 2NF, če je Brez delne odvisnosti, tj. , noben neprime atribut (atributi, ki niso del nobenega kandidatnega ključa) ni odvisen od katere koli ustrezne podmnožice katerega koli kandidatnega ključa v tabeli. Delna odvisnost – Če ustrezna podmnožica kandidatnega ključa določa atribut, ki ni prvi, se to imenuje delna odvisnost.

  • Primer 1 – Razmislite o tabeli 3, kot sledi spodaj.
STUD_NO COURSE_NO COURSE_FEE 1 C1 1000 2 C2 1500 1 C4 2000 4 C3 1000 4 C1 1000 2 C5 2000>
  • {Upoštevajte, da obstaja veliko tečajev z enako ceno tečaja} Tukaj COURSE_FEE ne more sam določiti vrednosti COURSE_NO ali STUD_NO; COURSE_FEE skupaj s STUD_NO ne more določiti vrednosti COURSE_NO; COURSE_FEE skupaj s COURSE_NO ne more določiti vrednosti STUD_NO; Zato bi bil COURSE_FEE neprimarni atribut, saj ne pripada edinemu ključu kandidata {STUD_NO, COURSE_NO}; Toda COURSE_NO -> COURSE_FEE, tj. COURSE_FEE je odvisen od COURSE_NO, ki je pravilna podmnožica ključa kandidata. Neprime atribut COURSE_FEE je odvisen od ustrezne podmnožice ključa kandidata, ki je delna odvisnost, zato ta relacija ni v 2NF. Če želite zgornjo relacijo pretvoriti v 2NF, moramo tabelo razdeliti na dve tabeli, kot sta: Tabela 1: STUD_NO, COURSE_NO Tabela 2: COURSE_NO, COURSE_FEE
   Table 1     Table 2  STUD_NO COURSE_NO COURSE_NO COURSE_FEE  1 C1 C1 1000 2 C2 C2 1500 1 C4 C3 1000 4 C3 C4 2000 4 C1 C5 2000>
  • OPOMBA: 2NF poskuša zmanjšati odvečne podatke, ki se shranjujejo v pomnilniku. Na primer, če tečaj C1 obiskuje 100 študentov, nam ni treba shraniti njegove pristojbine kot 1000 za vseh 100 zapisov, temveč jo lahko shranimo v drugo tabelo, saj je cena tečaja za C1 1000.
  • Primer 2 – Razmislite o naslednjih funkcionalnih odvisnostih v relaciji R (A, B, C, D)
AB ->C [A in B skupaj določata C] BC -> D [B in C skupaj določata D]>

V zgornjem razmerju je AB edini možni ključ in ni delne odvisnosti, kar pomeni, da nobena ustrezna podmnožica AB ne določa nobenega atributa, ki ni primarni.



X is a super key. Y is a prime attribute (each element of Y is part of some candidate key).>

Primer 1: V razmerju STUDENT, podanem v tabeli 4, FD nastavite: {STUD_NO -> STUD_NAME, STUD_NO -> STUD_STATE, STUD_STATE -> STUD_COUNTRY, STUD_NO -> STUD_AGE}

Ključ kandidata: {STUD_NO}

Za to relacijo v tabeli 4 veljata STUD_NO -> STUD_STATE in STUD_STATE -> STUD_COUNTRY.

STUD_COUNTRY je torej prehodno odvisna od STUD_NO. Krši tretjo normalno obliko.

Za pretvorbo v tretjo normalno obliko bomo relacijo STUDENT (STUD_NO, STUD_NAME, STUD_PHONE, STUD_STATE, STUD_COUNTRY_STUD_AGE) razgradili kot: STUDENT (STUD_NO, STUD_NAME, STUD_PHONE, STUD_STATE, STUD_AGE) STATE_COUNTRY (STATE, COUNTRY)

Upoštevajte relacijo R(A, B, C, D, E) A -> BC, CD -> E, B -> D, E -> A Vsi možni kandidatni ključi v zgornji relaciji so {A, E, CD, BC} Vsi atributi so na desni strani vseh funkcijskih odvisnosti, ki so pra.

Primer 2: Poiščite najvišjo normalno obliko relacije R(A,B,C,D,E) s FD, nastavljenim kot {BC->D, AC->BE, B->E}

Korak 1: Kot lahko vidimo, je (AC)+ ={A,C,B,E,D}, vendar nobena njegova podmnožica ne more določiti vseh atributov relacije, zato bo AC kandidat za ključ. A ali C ni mogoče izpeljati iz nobenega drugega atributa relacije, zato bo na voljo samo 1 kandidatni ključ {AC}.

2. korak: Praatributi so tisti atributi, ki so del kandidatnega ključa {A, C} v tem primeru, drugi pa bodo v tem primeru neprimarni {B, D, E}.

3. korak: Relacija R je v 1. normalni obliki, saj relacijski DBMS ne dovoljuje večvrednega ali sestavljenega atributa. Relacija je v 2. normalni obliki, ker je BC->D v 2. normalni obliki (BC ni ustrezna podmnožica kandidatnega ključa AC) in je AC->BE v 2. normalni obliki (AC je kandidatni ključ) in B->E je v 2. normalni obliki (B ni pravilna podmnožica kandidatnega ključa AC).

Relacija ni v 3. normalni obliki, ker v BC->D (niti BC ni superključ niti D ni primarni atribut) in v B->E (niti B ni super ključ niti E ni primarni atribut), ampak izpolnjujejo 3. normalno vrednost, bodisi LHS FD mora biti super ključ ali RHS glavni atribut. Torej bo najvišja normalna oblika relacije 2. normalna oblika.

Na primer, upoštevajte relacijo R(A, B, C) A -> BC, B -> A in B sta super ključa, tako da je zgornja relacija v BCNF.

Tretja normalna oblika

Relacija naj bi bila v tretji normalni obliki, če ne bi imeli tranzitivne odvisnosti za nepraatribute. Osnovni pogoj pri tretji normalni obliki je, da mora biti relacija v drugi normalni obliki.

Spodaj je omenjen osnovni pogoj, ki mora biti izpolnjen v netrivialni funkcionalni odvisnosti X -> Y:

  • X je super ključ.
  • Y je glavni atribut (to pomeni, da je element Y nek del ključa kandidata).

Za več glejte Tretja normalna oblika v DBMS.

BCNF

BCNF (normalna oblika Boyce-Codd) je le napredna različica tretje normalne oblike. Tukaj imamo nekaj dodatnih pravil poleg tretje običajne oblike. Osnovni pogoj, da je katera koli relacija v BCNF, je, da mora biti v tretji normalni obliki.

q1 q2 q3 q4

Osredotočiti se moramo na nekaj osnovnih pravil, ki veljajo za BCNF:

1. Table must be in Third Normal Form. 2. In relation X->Y, X morata biti superključ v relaciji.>

Za več glejte BCNF v DBMS.

Četrta normalna oblika

Četrta normalna oblika ne vsebuje nobene netrivialne odvisnosti z več vrednostmi, razen ključa kandidata. Osnovni pogoj pri četrti normalni obliki je, da mora biti relacija v BCNF.

Osnovna pravila so navedena spodaj.

1. It must be in BCNF. 2. It does not have any multi-valued dependency.>

Za več glejte Četrta normalna oblika v DBMS.

Peta normalna oblika

Peta normalna oblika se imenuje tudi predvidena normalna oblika. Spodaj so navedeni osnovni pogoji pete normalne oblike.

Relation must be in Fourth Normal Form. The relation must not be further non loss decomposed.>

Za več glejte Peta normalna oblika v DBMS.

Uporaba normalnih oblik v DBMS

  • Doslednost podatkov: Običajni obrazci zagotavljajo, da so podatki konsistentni in ne vsebujejo odvečnih informacij. To pomaga preprečiti nedoslednosti in napake v bazi podatkov.
  • Redundanca podatkov: Običajni obrazci zmanjšajo odvečnost podatkov z organizacijo podatkov v tabele, ki vsebujejo samo edinstvene podatke. To zmanjša količino prostora za shranjevanje, ki je potreben za bazo podatkov, in olajša upravljanje.
  • Odzivni čas: Običajni obrazci lahko izboljšajo zmogljivost poizvedb z zmanjšanjem števila združevanj, potrebnih za pridobivanje podatkov. To pomaga pospešiti obdelavo poizvedb in izboljša splošno delovanje sistema.
  • Vzdrževanje baze podatkov: Običajni obrazci olajšajo vzdrževanje baze podatkov z zmanjšanjem količine odvečnih podatkov, ki jih je treba posodobiti, izbrisati ali spremeniti. To pomaga izboljšati upravljanje baze podatkov in zmanjšati tveganje za napake ali nedoslednosti.
  • Oblikovanje baze podatkov: Običajni obrazci nudijo smernice za načrtovanje učinkovitih, prilagodljivih in razširljivih baz podatkov. To pomaga zagotoviti, da je bazo podatkov mogoče preprosto spremeniti, posodobiti ali razširiti, kot je potrebno.

Nekaj ​​pomembnih točk o normalnih oblikah

  • BCNF nima redundance, ki jo povzročajo funkcionalne odvisnosti.
  • Če je relacija v BCNF, potem je izpolnjen tudi 3NF.
  • Če so vsi atributi relacije primarni atribut, potem je relacija vedno v 3NF.
  • Relacija v relacijski bazi podatkov je vedno in vsaj v obliki 1NF.
  • Vsaka binarna relacija (relacija z le 2 atributoma) je vedno v BCNF.
  • Če ima relacija samo enojne kandidatne ključe (tj. vsak kandidatni ključ je sestavljen iz samo 1 atributa), potem je relacija vedno v 2NF (ker ni možna delna funkcionalna odvisnost).
  • Včasih uporaba obrazca BCNF morda ne bo ohranila funkcionalne odvisnosti. V tem primeru izberite BCNF samo, če izgubljeni FD(-ji) ni potreben, drugače normalizirajte samo do 3NF.
  • Po BCNF obstaja veliko več normalnih oblik, kot je 4NF in več. Toda v sistemih baz podatkov v resničnem svetu na splošno ni treba preseči BCNF.

Zaključek

Skratka, relacijske baze podatkov je mogoče urediti v skladu z nizom pravil, imenovanih normalne oblike zbirka podatkov administracije (1NF, 2NF, 3NF, BCNF, 4NF in 5NF), ki zmanjšujejo redundanco podatkov in ohranjajo celovitost podatkov. Z razreševanjem različnih vrst podatkovnih anomalij in odvisnosti se vsaka naslednja normalna oblika razširi na tisto, ki je bila pred njo. Posebne zahteve in lastnosti shranjenih podatkov določajo, katero običajno obliko je treba uporabiti; višje normalne oblike ponujajo strožjo celovitost podatkov, vendar lahko povzročijo tudi bolj zapletene strukture baze podatkov.

Povezave vprašanj prejšnjega leta

  • GATE CS 2012, 2. vprašanje
  • GATE CS 2013, vprašanje 54
  • GATE CS 2013, vprašanje 55
  • GATE CS 2005, vprašanje 29
  • GATE CS 2002, vprašanje 23
  • GATE CS 2002, vprašanje 50
  • GATE CS 2001, vprašanje 48
  • GATE CS 1999, vprašanje 32
  • GATE IT 2005, vprašanje 22
  • GATE IT 2008, vprašanje 60
  • GATE CS 2016 (Sklop 1), vprašanje 31

Pogosta vprašanja v običajni obliki

V.1: Zakaj je normalizacija pomembna v DBMS?

odgovor:

Normalizacija pomaga pri preprečevanju anomalij v bazi podatkov, kar na koncu zagotavlja konsistentnost baze podatkov in pomaga pri enostavnem vzdrževanju baze podatkov.

V.2: Ali je mogoče bazo podatkov preveč normalizirati?

odgovor:

Da, prekomerna normalizacija se bo nanašala na zapletene poizvedbe in tudi zmanjšala zmogljivost. Vzpostavlja ravnotežje med normiranjem in praktičnostjo.

V.3: Ali je treba bazo podatkov normalizirati na najvišjo normalno obliko, kot je (BCNF ali 4NF)?

odgovor:

Za kakršno koli normalizacijo podatkovne baze ni določenih nujnih pogojev. Velikokrat lahko nižja oblika zadostuje za specifično delovanje in preprostost.