logo

TechCodeview

Normale skjemaer i DBMS

Normalisering er prosessen med å minimere overflødighet fra en relasjon eller et sett med relasjoner. Redundans i forhold kan forårsake innsetting, sletting og oppdateringsavvik. Så det hjelper å minimere redundansen i relasjoner. Normale former brukes til å eliminere eller redusere redundans i databasetabeller.

Normalisering av DBMS av Ranjan Hero

I databasestyringssystemer (DBMS) er normale skjemaer en rekke retningslinjer som bidrar til å sikre at utformingen av en database er effektiv, organisert og fri for dataavvik. Det er flere nivåer av normalisering, hver med sitt eget sett med retningslinjer, kjent som normale former.



Viktige punkter angående normale skjemaer i DBMS

  • Første normale form (1NF): Dette er det mest grunnleggende nivået av normalisering. I 1NF skal hver tabellcelle bare inneholde en enkelt verdi, og hver kolonne skal ha et unikt navn. Den første normale formen hjelper til med å eliminere dupliserte data og forenkle spørringer.
  • Andre normalform (2NF): 2NF eliminerer redundante data ved å kreve at hvert ikke-nøkkelattributt er avhengig av primærnøkkelen. Dette betyr at hver kolonne skal være direkte relatert til primærnøkkelen, og ikke til andre kolonner.
  • Tredje normalform (3NF): 3NF bygger på 2NF ved å kreve at alle ikke-nøkkelattributter er uavhengige av hverandre. Dette betyr at hver kolonne skal være direkte relatert til primærnøkkelen, og ikke til noen andre kolonner i samme tabell.
  • Boyce-Codd normal form (BCNF): BCNF er en strengere form for 3NF som sikrer at hver determinant i en tabell er en kandidatnøkkel. Med andre ord sikrer BCNF at hvert ikke-nøkkelattributt kun er avhengig av kandidatnøkkelen.
  • Fjerde normalform (4NF): 4NF er en ytterligere forbedring av BCNF som sikrer at en tabell ikke inneholder noen avhengigheter med flere verdier.
  • Femte normalform (5NF): 5NF er det høyeste nivået av normalisering og innebærer å dekomponere en tabell i mindre tabeller for å fjerne dataredundans og forbedre dataintegriteten.

Normale skjemaer bidrar til å redusere dataredundans, øke datakonsistensen og forbedre databaseytelsen. Imidlertid kan høyere nivåer av normalisering føre til mer komplekse databasedesign og spørringer. Det er viktig å finne en balanse mellom normalisering og praktisk når du designer en database.

Fordeler med normal form

  • Redusert dataredundans: Normalisering bidrar til å eliminere dupliserte data i tabeller, reduserer mengden lagringsplass som trengs og forbedrer databaseeffektiviteten.
  • Forbedret datakonsistens: Normalisering sikrer at data lagres på en konsistent og organisert måte, noe som reduserer risikoen for datainkonsekvenser og feil.
  • Forenklet databasedesign: Normalisering gir retningslinjer for organisering av tabeller og datarelasjoner, noe som gjør det enklere å designe og vedlikeholde en database.
  • Forbedret søkeytelse: Normaliserte tabeller er vanligvis lettere å søke etter og hente data fra, noe som resulterer i raskere søkeytelse.
  • Enklere databasevedlikehold: Normalisering reduserer kompleksiteten til en database ved å dele den opp i mindre, mer håndterbare tabeller, noe som gjør det enklere å legge til, endre og slette data.

Totalt sett bidrar bruk av normale skjemaer i DBMS til å forbedre datakvaliteten, øke databaseeffektiviteten og forenkle databasedesign og vedlikehold.

Første normalform

Hvis en relasjon inneholder sammensatte attributter eller attributter med flere verdier, bryter den med første normalform, eller en relasjon er i første normalform hvis den ikke inneholder noen sammensatt attributt eller attributt med flere verdier. En relasjon er i første normalform hvis hver attributt i den relasjonen er enkelt verdsatt attributt .



  • Eksempel 1 – Relasjonen STUDENT i tabell 1 er ikke i 1NF på grunn av attributtet STUD_PHONE med flere verdier. Dekomponeringen til 1NF er vist i tabell 2.
Eksempel

Eksempel

  • Eksempel 2 – 
ID Name Courses ------------------ 1 A c1, c2 2 E c3 3 M C2, c3>
  • I tabellen ovenfor er Kurset et attributt med flere verdier, så det er ikke i 1NF. Tabellen nedenfor er i 1NF ettersom det ikke er noen attributt med flere verdier
ID Name Course ------------------ 1 A c1 1 A c2 2 E c3 3 M c2 3 M c3>

Andre normalform

For å være i andre normalform, må en relasjon være i første normalform og relasjon må ikke inneholde noen delvis avhengighet. En relasjon er i 2NF hvis den har Ingen delvis avhengighet, dvs. , ingen ikke-primære attributter (attributter som ikke er en del av noen kandidatnøkkel) er avhengig av et riktig delsett av en kandidatnøkkel i tabellen. Delvis avhengighet – Hvis det riktige undersettet av kandidatnøkkelen bestemmer ikke-primeattributtet, kalles det delvis avhengighet.

  • Eksempel 1 – Vurder tabell-3 som følger nedenfor.
STUD_NO COURSE_NO COURSE_FEE 1 C1 1000 2 C2 1500 1 C4 2000 4 C3 1000 4 C1 1000 2 C5 2000>
  • {Merk at det er mange kurs som har samme kursavgift} Her kan ikke COURSE_FEE alene bestemme verdien av COURSE_NO eller STUD_NO; COURSE_FEE sammen med STUD_NO kan ikke bestemme verdien av COURSE_NO; COURSE_FEE sammen med COURSE_NO kan ikke bestemme verdien av STUD_NO; Derfor vil COURSE_FEE være et ikke-primeattributt, siden det ikke tilhører den eneste kandidatnøkkelen {STUD_NO, COURSE_NO} ; Men, COURSE_NO -> COURSE_FEE, dvs. COURSE_FEE er avhengig av COURSE_NO, som er en riktig delmengde av kandidatnøkkelen. Non-prime attributt COURSE_FEE er avhengig av en riktig delmengde av kandidatnøkkelen, som er en delvis avhengighet, og derfor er denne relasjonen ikke i 2NF. For å konvertere relasjonen ovenfor til 2NF, må vi dele tabellen i to tabeller som: Tabell 1: STUD_NO, COURSE_NO Tabell 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>
  • MERK: 2NF prøver å redusere redundante data som blir lagret i minnet. For eksempel, hvis det er 100 studenter som tar C1-kurs, trenger vi ikke å lagre gebyret som 1000 for alle de 100 postene, i stedet, når vi kan lagre det i den andre tabellen, da kursavgiften for C1 er 1000.
  • Eksempel 2 – Vurder å følge funksjonelle avhengigheter i forhold R (A, B , C, D )
AB ->C [A og B bestemmer sammen C] BC -> D [B og C bestemmer sammen D]>

I forholdet ovenfor er AB den eneste kandidatnøkkelen, og det er ingen delvis avhengighet, det vil si at en hvilken som helst delmengde av AB ikke bestemmer noen ikke-primære attributter.



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

Eksempel 1: I forhold STUDENT gitt i tabell 4, FD-sett: {STUD_NO -> STUD_NAME, STUD_NO -> STUD_STATE, STUD_STATE -> STUD_COUNTRY, STUD_NO -> STUD_AGE}

Kandidatnøkkel: {STUD_NO}

For denne relasjonen i tabell 4 er STUD_NO -> STUD_STATE og STUD_STATE -> STUD_COUNTRY sanne.

Så STUD_COUNTRY er transitivt avhengig av STUD_NO. Det bryter med den tredje normalformen.

delvis avledet lateks

For å konvertere den til tredje normalform, vil vi dekomponere relasjonen STUDENT (STUD_NO, STUD_NAME, STUD_PHONE, STUD_STATE, STUD_COUNTRY_STUD_AGE) som: STUDENT (STUD_NO, STUD_NAME, STUD_PHONE, STUD_STATE, STUD_AGE) STATE_COUNTRY (STATE, COUNTRY)

Tenk på relasjon R(A, B, C, D, E) A -> BC, CD -> E, B -> D, E -> A Alle mulige kandidatnøkler i relasjonen ovenfor er {A, E, CD, BC} Alle attributter er på høyre side av alle funksjonelle avhengigheter er prime.

Eksempel 2: Finn den høyeste normalformen av en relasjon R(A,B,C,D,E) med FD satt som {BC->D, AC->BE, B->E}

Trinn 1: Som vi kan se, (AC)+ ={A,C,B,E,D}, men ingen av undergruppene kan bestemme alle attributtene til relasjonen, så AC vil være kandidatnøkkelen. A eller C kan ikke utledes fra noen andre attributter i relasjonen, så det vil bare være 1 kandidatnøkkel {AC}.

Steg 2: Primære attributter er de attributtene som er en del av kandidatnøkkelen {A, C} i dette eksemplet, og andre vil være ikke-prime {B, D, E} i dette eksemplet.

Trinn 3: Relasjonen R er i 1. normal form ettersom et relasjonelt DBMS ikke tillater flerverdier eller sammensatte attributter. Relasjonen er i 2. normalform fordi BC->D er i 2. normalform (BC er ikke en riktig delmengde av kandidatnøkkel AC) og AC->BE er i 2. normalform (AC er kandidatnøkkel) og B->E er i 2. normalform (B er ikke en riktig delmengde av kandidatnøkkel AC).

Relasjonen er ikke i 3. normalform fordi i BC->D (verken BC er en supernøkkel eller D er en primattributt) og i B->E (verken B er en supernøkkel eller E er en primattributt) men til tilfredsstille 3. normal for, enten LHS av en FD skal være supernøkkel eller RHS skal være prime attributt. Så den høyeste normalformen for relasjon vil være 2. Normalform.

streng jsonobject

Tenk for eksempel på relasjon R(A, B, C) A -> BC, B -> A og B er begge supernøkler, så relasjonen ovenfor er i BCNF.

Tredje normalform

En relasjon sies å være i tredje normalform, hvis vi ikke hadde noen transitiv avhengighet for ikke-primære attributter. Grunnbetingelsen med den tredje normalformen er at forholdet må være i andre normalform.

Nedenfor nevnt er den grunnleggende betingelsen som må holdes i den ikke-trivielle funksjonelle avhengigheten X -> Y:

  • X er en supernøkkel.
  • Y er et primært attributt (dette betyr at element av Y er en del av kandidatnøkkelen).

For mer, se Tredje normalform i DBMS.

BCNF

BCNF (Boyce-Codd Normal Form) er bare en avansert versjon av Third Normal Form. Her har vi noen tilleggsregler enn Third Normal Form. Grunnbetingelsen for at enhver relasjon skal være i BCNF er at den må være i tredje normalform.

Vi må fokusere på noen grunnleggende regler som er for BCNF:

1. Table must be in Third Normal Form. 2. In relation X->Y, X må være en supernøkkel i en relasjon.>

For mer, se BCNF i DBMS.

Fjerde normalform

Fjerde normalform inneholder ingen ikke-triviell multivaued avhengighet bortsett fra kandidatnøkkel. Grunnbetingelsen med fjerde normalform er at relasjonen må være i BCNF.

De grunnleggende reglene er nevnt nedenfor.

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

For mer, se Fjerde normalform i DBMS.

Femte normalform

Femte normalform kalles også for projisert normalform. De grunnleggende betingelsene for Fifth Normal Form er nevnt nedenfor.

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

For mer, se Femte normalform i DBMS.

Anvendelser av normale former i DBMS

  • Datakonsistens: Vanlige skjemaer sikrer at data er konsistente og ikke inneholder overflødig informasjon. Dette bidrar til å forhindre inkonsekvenser og feil i databasen.
  • Dataredundans: Normale skjemaer minimerer dataredundans ved å organisere data i tabeller som bare inneholder unike data. Dette reduserer mengden lagringsplass som kreves for databasen og gjør den enklere å administrere.
  • Responstid: Vanlige skjemaer kan forbedre spørringsytelsen ved å redusere antallet sammenføyninger som kreves for å hente data. Dette bidrar til å øke hastigheten på spørringsbehandlingen og forbedre den generelle systemytelsen.
  • Databasevedlikehold: Vanlige skjemaer gjør det enklere å vedlikeholde databasen ved å redusere mengden redundante data som må oppdateres, slettes eller endres. Dette bidrar til å forbedre databaseadministrasjonen og redusere risikoen for feil eller inkonsekvenser.
  • Databasedesign: Vanlige skjemaer gir retningslinjer for utforming av databaser som er effektive, fleksible og skalerbare. Dette bidrar til å sikre at databasen enkelt kan endres, oppdateres eller utvides etter behov.

Noen viktige punkter om normale former

  • BCNF er fri for redundans forårsaket av funksjonelle avhengigheter.
  • Hvis en relasjon er i BCNF, er 3NF også tilfredsstilt.
  • Hvis alle attributter av relasjon er prime attributter, så er relasjonen alltid i 3NF.
  • En relasjon i en relasjonsdatabase er alltid og minst i 1NF-form.
  • Hver binær relasjon (en relasjon med bare 2 attributter) er alltid i BCNF.
  • Hvis en relasjon bare har singleton-kandidatnøkler (dvs. hver kandidatnøkkel består av bare 1 attributt), så er relasjonen alltid i 2NF (fordi ingen delvis funksjonell avhengighet er mulig).
  • Noen ganger kan det å gå for BCNF-form ikke bevare funksjonell avhengighet. Gå i så fall til BCNF bare hvis den(e) tapte FD(ene) ikke er nødvendig, ellers normaliser bare til 3NF.
  • Det er mange flere normale former som eksisterer etter BCNF, som 4NF og mer. Men i databasesystemer i den virkelige verden er det vanligvis ikke nødvendig å gå utover BCNF.

Konklusjon

Som konklusjon kan relasjonsdatabaser ordnes i henhold til et sett med regler som kalles normale former i database administrering (1NF, 2NF, 3NF, BCNF, 4NF og 5NF), som reduserer dataredundans og bevarer dataintegriteten. Ved å løse ulike typer dataavvik og avhengigheter, utvider hver påfølgende normalform seg til den som kom før den. De spesielle kravene og egenskapene til dataene som lagres bestemmer hvilken normal form som skal brukes; høyere normale former gir strengere dataintegritet, men kan også resultere i mer kompliserte databasestrukturer.

Spørsmålslenker til forrige år

  • GATE CS 2012, spørsmål 2
  • GATE CS 2013, spørsmål 54
  • GATE CS 2013, spørsmål 55
  • GATE CS 2005, spørsmål 29
  • GATE CS 2002, spørsmål 23
  • GATE CS 2002, spørsmål 50
  • GATE CS 2001, spørsmål 48
  • GATE CS 1999, spørsmål 32
  • GATE IT 2005, spørsmål 22
  • GATE IT 2008, spørsmål 60
  • GATE CS 2016 (sett 1), spørsmål 31

Vanlige spørsmål på Normal Form

Q.1: Hvorfor er normalisering viktig i DBMS?

Svar:

Normalisering hjelper til med å forhindre databasen fra uregelmessigheter, som til slutt sikrer konsistensen av databasen og hjelper til med enkelt vedlikehold av databasen.

Q.2: Er det mulig å overnormalisere databasen?

Svar:

Ja, overdreven normalisering vil gå til komplekse søk og reduserer også ytelsen. Det skaper balanse mellom normalisering og praktisk.

Q.3: Er det nødvendig å normalisere en database til høyeste normalform som (BCNF eller 4NF)?

Svar:

Det er ingen sikker nødvendig betingelse for noen databasenormalisering. Mange ganger kan lavere form være tilstrekkelig for spesifikk ytelse og enkelhet.