Normalisointi on minimointiprosessi redundanssi suhteesta tai suhdejoukosta. Redundanssi suhteessa voi aiheuttaa lisäys-, poisto- ja päivitysvirheitä. Joten se auttaa minimoimaan suhteiden redundanssin. Normaalit muodot käytetään poistamaan tai vähentämään redundanssia tietokantataulukoissa.

DBMS:n normalisointi Ranjan Heron toimesta

Tietokannan hallintajärjestelmissä (DBMS) normaalit lomakkeet ovat joukko ohjeita, jotka auttavat varmistamaan, että tietokannan suunnittelu on tehokasta, organisoitua ja vapaata tietopoikkeavuuksista. Normalisointitasoja on useita, joista jokaisella on omat ohjeistonsa, jotka tunnetaan normaaleina muotoina.

Tärkeitä kohtia DBMS:n normaaleista lomakkeista

• Ensimmäinen normaalimuoto (1NF): Tämä on normalisoinnin alkeellisin taso. 1NF:ssä jokaisen taulukon solun tulee sisältää vain yksi arvo, ja jokaisella sarakkeella tulee olla yksilöllinen nimi. Ensimmäinen normaalilomake auttaa poistamaan päällekkäisiä tietoja ja yksinkertaistamaan kyselyitä.
• Toinen normaalimuoto (2NF): 2NF eliminoi ylimääräiset tiedot vaatimalla, että jokainen ei-avainmäärite on riippuvainen ensisijaisesta avaimesta. Tämä tarkoittaa, että jokaisen sarakkeen tulee liittyä suoraan ensisijaiseen avaimeen, ei muihin sarakkeisiin.
• Kolmas normaalimuoto (3NF): 3NF rakentuu 2NF:lle vaatimalla, että kaikki ei-avainattribuutit ovat toisistaan ​​riippumattomia. Tämä tarkoittaa, että jokaisen sarakkeen tulee liittyä suoraan ensisijaiseen avaimeen, ei muihin saman taulukon sarakkeisiin.
• Boyce-Coddin normaalimuoto (BCNF): BCNF on tiukempi muoto 3NF:stä, joka varmistaa, että jokainen taulukon determinantti on ehdokasavain. Toisin sanoen BCNF varmistaa, että jokainen ei-avainattribuutti on riippuvainen vain ehdokasavaimesta.
• Neljäs normaalimuoto (4NF): 4NF on BCNF:n lisäjalostus, joka varmistaa, että taulukko ei sisällä moniarvoisia riippuvuuksia.
• Viides normaalimuoto (5NF): 5NF on normalisoinnin korkein taso, ja siihen kuuluu taulukon hajottaminen pienempiin taulukoihin tietojen redundanssin poistamiseksi ja tietojen eheyden parantamiseksi.

Normaalit lomakkeet auttavat vähentämään tietojen redundanssia, lisäämään tietojen johdonmukaisuutta ja parantamaan tietokannan suorituskykyä. Korkeammat normalisointitasot voivat kuitenkin johtaa monimutkaisempiin tietokantasuunnitelmiin ja kyselyihin. Tietokantaa suunniteltaessa on tärkeää löytää tasapaino normalisoinnin ja käytännöllisyyden välillä.

Normaalin muodon edut

• Vähentynyt tietojen redundanssi: Normalisointi auttaa poistamaan päällekkäiset tiedot taulukoista, vähentämään tarvittavan tallennustilan määrää ja parantamaan tietokannan tehokkuutta.
• Parannettu tietojen johdonmukaisuus: Normalisointi varmistaa, että tiedot tallennetaan johdonmukaisesti ja järjestelmällisesti, mikä vähentää tietojen epäjohdonmukaisuuksien ja virheiden riskiä.
• Yksinkertaistettu tietokantasuunnittelu: Normalisointi antaa ohjeita taulukoiden ja tietosuhteiden järjestämiseen, mikä helpottaa tietokannan suunnittelua ja ylläpitoa.
• Parannettu kyselyn suorituskyky: Normalisoiduista taulukoista on yleensä helpompi etsiä ja noutaa tietoja, mikä johtaa nopeampaan kyselyn suorituskykyyn.
• Helpompi tietokannan ylläpito: Normalisointi vähentää tietokannan monimutkaisuutta jakamalla sen pienempiin, paremmin hallittaviin taulukoihin, mikä helpottaa tietojen lisäämistä, muokkaamista ja poistamista.

Kaiken kaikkiaan normaalien lomakkeiden käyttö DBMS:ssä auttaa parantamaan tietojen laatua, lisäämään tietokannan tehokkuutta ja yksinkertaistamaan tietokannan suunnittelua ja ylläpitoa.

Ensimmäinen normaali muoto

Jos relaatio sisältää yhdistetyn tai moniarvoisen attribuutin, se rikkoo ensimmäistä normaalimuotoa tai relaatio on ensimmäisessä normaalimuodossa, jos se ei sisällä yhdistelmä- tai moniarvoista attribuuttia. Relaatio on ensimmäisessä normaalimuodossa, jos kaikki sen suhteen attribuutit ovat yksiarvoinen attribuutti .

• Esimerkki 1 – Taulukon 1 suhde STUDENT ei ole 1NF:ssä moniarvoisen attribuutin STUD_PHONE vuoksi. Sen hajoaminen 1NF:ksi on esitetty taulukossa 2.

Esimerkki

• Esimerkki 2 –

ID Name Courses ------------------ 1 A c1, c2 2 E c3 3 M C2, c3>

• Yllä olevassa taulukossa Course on moniarvoinen attribuutti, joten se ei ole 1NF:ssä. Alla oleva taulukko on muodossa 1NF, koska siinä ei ole moniarvoista attribuuttia

ID Name Course ------------------ 1 A c1 1 A c2 2 E c3 3 M c2 3 M c3>

Toinen normaali muoto

Jotta relaatio olisi toisessa normaalimuodossa, sen on oltava ensimmäisessä normaalimuodossa eikä relaatio saa sisältää osittaista riippuvuutta. Relaatio on 2NF:ssä, jos se on Ei osittaista riippuvuutta, eli , mikään ei-prime-attribuutti (attribuutit, jotka eivät ole osa ehdokasavainta) ei ole riippuvainen taulukon minkä tahansa ehdokasavaimen oikeasta osajoukosta. Osittainen riippuvuus - Jos ehdokasavaimen oikea osajoukko määrittää ei-prime-attribuutin, sitä kutsutaan osittaiseksi riippuvuudeksi.

• Esimerkki 1 – Tarkastele taulukkoa 3 seuraavasti.

STUD_NO COURSE_NO COURSE_FEE 1 C1 1000 2 C2 1500 1 C4 2000 4 C3 1000 4 C1 1000 2 C5 2000>

• {Huomaa, että monella kurssilla on sama kurssimaksu} Tässä COURSE_FEE ei voi yksin päättää kurssin COURSE_NO tai STUD_NO arvoa; COURSE_FEE yhdessä STUD_NO:n kanssa ei voi päättää kurssin COURSE_NO arvoa; COURSE_FEE yhdessä COURSE_NO:n kanssa ei voi päättää STUD_NO:n arvoa; Näin ollen COURSE_FEE ei ole prime-attribuutti, koska se ei kuulu ainoaan ehdokasavaimeen {STUD_NO, COURSE_NO}; Mutta COURSE_NO -> COURSE_FEE, eli KURSSIMAKSUS on riippuvainen COURSE_NO:sta, joka on ehdokasavaimen oikea osajoukko. Ei-prime-attribuutti COURSE_FEE on riippuvainen ehdokasavaimen oikeasta osajoukosta, joka on osittainen riippuvuus, joten tämä relaatio ei ole 2NF:ssä. Muuntaaksesi yllä olevan suhteen 2NF:ksi, meidän on jaettava taulukko kahteen taulukkoon, kuten: Taulukko 1: STUD_NO, COURSE_NO Taulukko 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>

• HUOMAUTUS: 2NF yrittää vähentää redundanttien tietojen tallentumista muistiin. Jos esimerkiksi C1-kurssilla on 100 opiskelijaa, meidän ei tarvitse tallentaa sen Maksua 1000:na kaikille 100 tietueelle, vaan kun voimme tallentaa sen toiseen taulukkoon, koska C1:n kurssimaksu on 1000.
• Esimerkki 2 – Harkitse seuraavia toiminnallisia riippuvuuksia suhteessa R (A, B , C, D )

AB ->C [A ja B yhdessä määrittävät C] BC -> D [B ja C yhdessä määrittävät D]>

Yllä olevassa suhteessa AB on ainoa ehdokasavain, eikä siinä ole osittaista riippuvuutta, ts. mikään oikea AB:n osajoukko ei määritä mitään ei-prime-attribuuttia.

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

Esimerkki 1: Taulukossa 4 annetussa suhteessa STUDENT, FD-joukko: {STUD_NO -> STUD_NAME, STUD_NO -> STUD_STATE, STUD_STATE -> STUD_COUNTRY, STUD_NO -> STUD_AGE}

Ehdokasavain: {STUD_NO}

Tälle taulukon 4 suhteelle STUD_NO -> STUD_STATE ja STUD_STATE -> STUD_COUNTRY ovat tosi.

Joten STUD_COUNTRY on transitiivisesti riippuvainen STUD_NO:sta. Se rikkoo kolmatta normaalimuotoa.

Muuntaaksesi sen kolmanteen normaalimuotoon, puramme suhteen STUDENT (STUD_NO, STUD_NAME, STUD_PHONE, STUD_STATE, STUD_COUNTRY_STUD_AGE) muotoon: STUDENT (STUD_NO, STUD_NAME, STUD_PHONE, STUD_STATE, STUD_AGE) STATE_COUNTRY (STATE, COUNTRY)

Harkitse relaatiota R(A, B, C, D, E) A -> BC, CD -> E, B -> D, E -> A Kaikki mahdolliset ehdokasavaimet yllä olevassa suhteessa ovat {A, E, CD, BC} Kaikki attribuutit ovat oikealla puolella, kaikki toiminnalliset riippuvuudet ovat ensisijaisia.

Esimerkki 2: Etsi korkein normaalimuoto relaatiolle R(A,B,C,D,E), kun FD on asetettu muotoon {BC->D, AC->BE, B->E}

Vaihe 1: Kuten näemme, (AC)+ ={A,C,B,E,D}, mutta mikään sen osajoukosta ei voi määrittää kaikkia relaatiomääritteitä, joten AC on ehdokasavain. A:ta tai C:tä ei voida johtaa mistään muusta suhteen attribuutista, joten ehdokasavain on vain yksi {AC}.

Vaihe 2: Ensisijaiset attribuutit ovat attribuutteja, jotka ovat osa ehdokasavainta {A, C} tässä esimerkissä, ja muut ovat ei-alkumääritteitä {B, D, E} tässä esimerkissä.

Vaihe 3: Relaatio R on ensimmäisessä normaalimuodossa, koska relaatiotietokantajärjestelmä ei salli moniarvoista tai yhdistelmäattribuuttia. Suhde on 2. normaalimuodossa, koska BC->D on 2. normaalimuodossa (BC ei ole ehdokasavaimen AC oikea osajoukko) ja AC->BE on toisessa normaalimuodossa (AC on ehdokasavain) ja B->E on 2. normaalimuodossa (B ei ole ehdokasavaimen AC oikea osajoukko).

Relaatio ei ole 3. normaalimuodossa, koska BC->D:ssä (BC ei ole superavain eikä D ole alkumäärite) ja B->E:ssä (B ei ole superavain eikä E ole alkumäärite) vaan täyttää 3. normaalin, joko FD:n LHS:n tulee olla superavain tai RHS:n on oltava prime-attribuutti. Suhteen korkein normaalimuoto on siis 2. normaalimuoto.

Otetaan esimerkiksi relaatio R(A, B, C) A -> BC, B -> A ja B ovat molemmat superavaimia, joten yllä oleva relaatio on BCNF:ssä.

Kolmas normaalimuoto

Relaation sanotaan olevan kolmannessa normaalimuodossa, jos meillä ei olisi transitiivista riippuvuutta ei-prime-attribuuttien suhteen. Kolmannen normaalimuodon perusehto on, että suhteen tulee olla toisessa normaalimuodossa.

Alla on mainittu perusehto, jonka täytyy olla voimassa ei-triviaalissa toiminnallisessa riippuvuudessa X -> Y:

• X on superavain.
• Y on ensisijainen attribuutti (tämä tarkoittaa, että Y:n elementti on osa ehdokasavainta).

Katso lisätietoja Kolmas normaalimuoto DBMS:ssä.

BCNF

BCNF (Boyce-Codd Normal Form) on vain edistynyt versio kolmannesta normaalimuodosta. Tässä on joitain lisäsääntöjä kuin kolmas normaalilomake. Perusedellytys minkä tahansa suhteen olevan BCNF:ssä on, että sen on oltava kolmannessa normaalimuodossa.

Meidän on keskityttävä joihinkin BCNF:n perussääntöihin:

1. Table must be in Third Normal Form. 2. In relation X->Y, X on oltava superavain suhteessa.>

Katso lisätietoja BCNF DBMS:ssä.

Neljäs normaalimuoto

Neljäs normaalilomake ei sisällä ei-triviaalia moniarvoista riippuvuutta ehdokasavainta lukuun ottamatta. Neljännen normaalimuodon perusehto on, että suhteen on oltava BCNF:ssä.

Perussäännöt on mainittu alla.

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

Katso lisätietoja Neljäs normaalimuoto DBMS:ssä.

Viides normaalimuoto

Viidettä normaalimuotoa kutsutaan myös projisoiduksi normaalimuodoksi. Viidennen normaalimuodon perusehdot mainitaan alla.

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

Katso lisätietoja Viides normaalimuoto DBMS:ssä.

Normaalimuotojen sovellukset DBMS:ssä

• Tietojen johdonmukaisuus: Normaalit lomakkeet varmistavat, että tiedot ovat johdonmukaisia ​​eivätkä sisällä ylimääräistä tietoa. Tämä auttaa estämään epäjohdonmukaisuudet ja virheet tietokannassa.
• Datan redundanssi: Normaalit lomakkeet minimoivat tietojen redundanssin järjestämällä tiedot taulukoiksi, jotka sisältävät vain ainutlaatuisia tietoja. Tämä vähentää tietokannan vaatiman tallennustilan määrää ja helpottaa sen hallintaa.
• Vasteaika: Normaalit lomakkeet voivat parantaa kyselyn suorituskykyä vähentämällä tietojen hakemiseen tarvittavien liitosten määrää. Tämä auttaa nopeuttamaan kyselyn käsittelyä ja parantamaan järjestelmän yleistä suorituskykyä.
• Tietokannan ylläpito: Normaalit lomakkeet helpottavat tietokannan ylläpitoa vähentämällä päivitettävän, poistettavan tai muokattavan redundantin tiedon määrää. Tämä auttaa parantamaan tietokannan hallintaa ja vähentämään virheiden tai epäjohdonmukaisuuksien riskiä.
• Tietokannan suunnittelu: Normaalit lomakkeet tarjoavat ohjeita tehokkaiden, joustavien ja skaalautuvien tietokantojen suunnitteluun. Tämä auttaa varmistamaan, että tietokantaa voidaan helposti muokata, päivittää tai laajentaa tarpeen mukaan.

Joitakin tärkeitä kohtia normaaleista muodoista

• BCNF on vapaa toiminnallisten riippuvuuksien aiheuttamasta redundanssista.
• Jos relaatio on BCNF:ssä, myös 3NF täyttyy.
• Jos kaikki suhteen attribuutit ovat alkumääritteitä, relaatio on aina 3NF:ssä.
• Relaatiotietokannassa oleva relaatio on aina ja ainakin 1NF-muodossa.
• Jokainen binäärirelaatio (relaatio, jossa on vain 2 attribuuttia) on aina BCNF:ssä.
• Jos suhteella on vain yksittäisiä ehdokasavaimia (eli jokainen ehdokasavain koostuu vain yhdestä attribuutista), relaatio on aina 2NF:ssä (koska osittainen toiminnallinen riippuvuus ei ole mahdollista).
• Joskus BCNF-muodon käyttäminen ei välttämättä säilytä toiminnallista riippuvuutta. Käytä siinä tapauksessa BCNF:ää vain, jos kadonneita FD:itä ei vaadita, muuten normalisoi vain 3NF:ään.
• BCNF:n jälkeen on olemassa monia muita normaaleja muotoja, kuten 4NF ja muita. Mutta reaalimaailman tietokantajärjestelmissä ei yleensä vaadita BCNF:ää pidemmälle.

Johtopäätös

Lopuksi relaatiotietokannat voidaan järjestää sääntöjen mukaan, joita kutsutaan normaalimuodoiksi tietokanta hallinta (1NF, 2NF, 3NF, BCNF, 4NF ja 5NF), jotka vähentävät tietojen redundanssia ja säilyttävät tietojen eheyden. Ratkaisemalla erilaisia ​​tietopoikkeavuuksia ja riippuvuuksia jokainen myöhempi normaalimuoto laajenee sitä edeltävään muotoon. Tallennettavien tietojen erityisvaatimukset ja ominaisuudet määräävät, mitä normaalimuotoa tulisi käyttää; korkeammat normaalimuodot tarjoavat tiukemman tiedon eheyden, mutta voivat myös johtaa monimutkaisempiin tietokantarakenteisiin.

Java-esimerkki

Edellisen vuoden kysymyslinkit

• GATE CS 2012, kysymys 2
• GATE CS 2013, kysymys 54
• GATE CS 2013, kysymys 55
• GATE CS 2005, kysymys 29
• GATE CS 2002, kysymys 23
• GATE CS 2002, kysymys 50
• GATE CS 2001, kysymys 48
• GATE CS 1999, kysymys 32
• GATE IT 2005, kysymys 22
• GATE IT 2008, kysymys 60
• GATE CS 2016 (sarja 1), kysymys 31

Normaalilomakkeen usein kysytyt kysymykset

K.1: Miksi normalisointi on tärkeää DBMS:ssä?

Vastaus:

Normalisointi auttaa estämään tietokannan poikkeavuuksia, mikä viime kädessä varmistaa tietokannan johdonmukaisuuden ja helpottaa tietokannan ylläpitoa.

K.2: Onko mahdollista ylinormalisoida tietokantaa?

Vastaus:

Kyllä, liiallinen normalisointi johtaa monimutkaisiin kyselyihin ja heikentää myös suorituskykyä. Se löytää tasapainon normalisoinnin ja käytännöllisyyden välillä.

K.3: Onko tarpeen normalisoida tietokanta korkeimpaan normaalimuotoon, kuten (BCNF tai 4NF)?

Vastaus:

Tietokannan normalisoinnille ei ole tiettyjä välttämättömiä ehtoja. Usein pienempi muoto voi olla riittävä tiettyyn suorituskykyyn ja yksinkertaisuuteen.