Sisällytä johdonmukaisia, ei-redundantteja ja suhteellisia tietoja tietokanta on erittäin hyödyllistä. Tätä tarkoitusta varten tietokannan normalisointi prosessi suoritetaan. Tiedämme erittäin hyvin, että tietokanta on järjestelmä, joka järjestää tiedot jäsennellysti. Siksi, tietokannan normalisointi prosessin avulla voit hallita tietokantojen tietoja hyvin jäsennellysti ja tarkasti.

Sisällysluettelo

• Mikä on tietokannan normalisointi?
• Tietokannan normalisoinnin tavoitteet
• Anomaliat tietokannan normalisoinnissa
• Avaimet tietokannassa
• Toiminnalliset riippuvuudet tietokannassa
• Tietokannan normalisoinnin eri muodot
• Johtopäätös
• Suositellut artikkelit

Mikä on tietokannan normalisointi?

The tietokannan normalisointi prosessi eliminoi tietojen redundanssi ja parantaa tietojen eheys . Datan redundanssi tarkoittaa toistuvaa dataa. Se vie levyllä suuremman tilan ja johtaa levymuistin tuhlaukseen. Jos tietoja yhdessä paikassa muutetaan, se on muutettava kaikissa paikoissa, missä niitä on. Näin ollen redundanttien ja toistuvien tietojen pitäminen tietokantataulukoissa ei ole mahdollista.

Toinen termi, tietojen eheys , tarkoittaa tietojen täydellisyyttä ja johdonmukaisuutta. Tietokannan tietojen tulee olla tarkkoja ja merkityksellisiä. Tietokannan normalisointia käytetään siis tietojen eheyden ja toistumattomuuden varmistamiseksi.

Tietojen redundanssin poistamisen ja tietojen eheyden parantamisen lisäksi tietokannan normalisointi prosessi poistaa erilaisia ​​tietokannan poikkeavuuksia, kuten lisäämisen, poistamisen ja päivityksen. Tietokannan poikkeama heikentää tietojen eheyttä.

Normalisoinnin ensisijaisena tavoitteena on jakaa tietokannan suuremmat taulukot tai relaatiot pienempiin ja esitellä niiden välinen suhde. Jokaisella taulukolla tai suhteella tulee olla yksittäiset attribuuttiarvot, joita kutsutaan atomiarvoiksi. Tietokantataulukossa tulisi olla vain suhteelliset tiedot, ei muita epäolennaisia ​​tietoja.

Tietokannan normalisoinnin tavoitteet

Kun normalisoit tietokannan, varmista, että saavutat seuraavat tavoitteet:

• Tietokannan tiedot tulee tallentaa loogisesti. Suuremmat pöydät on ryhmitelty pienempiin. Jokaisen pienemmän ryhmän tulee heijastaa suuremman ryhmän osaa.
Datan redundanssitulee poistaa, koska se vie enemmän tietokantatilaa.
• Varmista, että tietokanta on johdonmukainen. Tietokantaan tehdyt muutokset, kuten lisääminen, poistaminen ja päivitys, eivät saa vahingoittaa tietojen eheyttä.
• Jos samat tiedot ovat eri paikoissa, sinun on muokattava niitä kaikilla alueilla. Kun normalisoit tietokannan, varmista, että sinun on päivitettävä tiedot vain yhdessä paikassa.

Anomaliat tietokannan normalisoinnissa

Jonkin sisällä tietokannanhallinta järjestelmä (DBMS), on kolme erilaista poikkeavaa, nimittäin lisäys, poisto ja päivitys. Nämä kolme poikkeavuutta vaikuttavat tietojen eheysperiaatteeseen.

Keskustellaan jokaisesta kolmesta poikkeavuudesta. Mutta tarkastelkaamme ensin suhdetta tai taulukkoa Työntekijä. Siinä on neljä attribuuttia, Emp_ID, Emp_Name, Emp_Add ja Ep_Dept, jotka tallentavat työntekijöiden tiedot.

Työntekijä

Yllä oleva taulukko tallentaa työntekijätiedot. Mutta se ei ole normalisoidussa muodossa. Kun taulukko ei ole normalisoitu, saatat kohdata useita ongelmia mielenkiintoisten uusien tietojen, olemassa olevien tietojen poistamisen tai nykyisten tietojen päivittämisen aikana.

Lisää:

Lisäysvirhe ei salli käyttäjien lisätä uusia tietoja tietokantaan. Tämä johtuu tiettyjen tietojen puuttumisesta. Harkitse yllä olevaa työntekijäsuhdetta. Jos yritykseen tulee uusi työntekijä, eikä hänelle ole osoitettu osastoa, kyseisen työntekijän tietoja ei voida lisätä taulukkoon. Tämä johtuu siitä, että emme voi lisätä NULL-arvoa Emp_Dept.

Poistaa:

Toinen poikkeama on deleetiopoikkeama. Tässä tilanteessa tietojen poistaminen ei olisi mahdollista, koska se voi johtaa tietojen menetykseen. Harkitse yllä olevaa työntekijätaulukkoa. Oletetaan, että osasto D08 sulkeutuu, Sammiin liittyvät tiedot poistettaisiin Työntekijä-taulukosta. Näin ollen yritys menettää Sammyn tiedot, koska hän työskentelee vain yhdellä osastolla.

Päivittää:

Päivityspoikkeama on toinen elementti, joka aiheuttaa tietojen epäjohdonmukaisuutta. Otamme esimerkin Työntekijä-taulukosta ymmärtääksemme päivityspoikkeaman. Harkitse työntekijää Johnia, joka työskentelee D01- ja D022-osastoilla. Jos haluat muuttaa Johnin osoitetta, sinun on päivitettävä molemmat rivit D01 ja D022; se voi vahingoittaa tietojen eheyden periaatetta. Jos osoite muuttuu yhdellä rivillä ja toinen rivi pysyy samana kuin edellinen, se päättyy päivitysvirheeseen.

The tietokannan normalisointi on hyödyllinen poistamaan kaikki edellä mainitut kolme poikkeavuutta, jotka johtavat heikkoon tietokantataulukkoon. Normalisoinnilla on useita sääntöjä tai muotoja. Ennen kuin sukeltaa syvälle normalisointimuotoihin, opimme ensin erilaisia ​​avaimia tietokantajärjestelmässä. Sinun on tiedettävä avainten tyypit, ennen kuin opit tietokannan normalisoinnin.

Avaimet tietokannassa

Tietokannan avaimilla on keskeinen rooli siinä olevien tietojen tunnistamisessa. Näppäimien avulla löydät kaikki tiedot taulukosta nopeasti ja helposti. Suuret pöydät on jaettu pienempiin, ja pienempiä pöytiä käytetään avaimilla.

Katsotaanpa erityyppisiä avaimia, joita käytetään DBMS:ssä.

Pääavain:

The pääavain on taulukon attribuutti, joka tunnistaa minkä tahansa rivin tai monikon yksilöllisesti. Sinun on valittava ensisijainen avain, joka löytää yksilöllisesti kaikki tiedot taulukosta.

Harkitse suhdetta työntekijää. Siinä on attribuutit, kuten Emp_ID, Emp_Name, Emp_Add, Passport_Number ja License_Number. Työntekijäsuhteen ensisijainen avain on Emp_ID, koska se tunnistaa yksilöllisesti jokaisen työntekijän tiedot. Lisäksi Passport_Number ja License_Number voivat toimia myös ensisijaisina avaimina, koska ne ovat yksilöllisiä jokaiselle työntekijälle.

Ehdokasavain:

The ehdokasavain Mikä tahansa taulukko on joukko vähimmäismääritteitä ja voi tunnistaa minkä tahansa rivin yksilöllisesti suhteessa. Yhdelle suhteelle voi olla yksi tai useampi ehdokasavainta.

Harkitse yllä olevaa työntekijän suhdetta. Näimme, että ensisijainen avain on Emp_ID, joka on ainutlaatuinen ja ei-toistuva jokaiselle työntekijälle. Kaksi muuta attribuuttia, Passport_Number ja License_Number, eivät myöskään toistu. Joten ne molemmat voivat toimia ehdokasavaimina.

Superavain:

Kuten pääavain ja ehdokasavain tunnistaa jokaisen monikon yksilöllisesti, superavain auttaa myös löytämään taulukon ainutlaatuisen monikon. Ehdokasavain on superavaimen osajoukko. Superavaimia voi olla yksi tai useita.

Käytämme samaa työntekijäsuhdetta saadaksemme selkeän käsityksen superavaimesta. Emp_ID-attribuutti voi yksilöllisesti selvittää minkä tahansa työntekijän tiedot. Attribuuttia Emp_Name ei voi käyttää ensisijaisena avaimena, koska kahdella työntekijällä voi olla sama nimi. Mutta Emp_ID:n ja Emp_Name:n yhdistelmä voi löytää työntekijän tiedot yksilöllisesti. Joten (Epm_ID, Emp_Name) toimii työntekijäsuhteen superavaimina.

Passprt_Number ja License_Number ovat myös työntekijäsuhteen superavaimia.

Vieras avain:

Vierasavain on melko erilainen kuin edellä mainitut kolme avainta. Sitä käytetään muodostamaan yhteys kahden suhteen välille. Tarkastellaan kahta relaatiota A ja B. Oletetaan mikä tahansa attribuutti relaatiossa A on relaatio B ensisijainen avain; tätä attribuuttia kutsutaan vierasavaimeksi.

Katsomme yksinkertaista esimerkkiä ymmärtääksemme vieraan avaimen käsitteen. Otetaan esimerkkinä yrityksen työntekijät. Jokainen työntekijä on määrätty eri osastoille. Siksi käytämme kahta suhdetta, työntekijä ja osasto.

Määrittelemme työntekijäsuhteet työntekijäksi ( Emp_ID , Emp_Name, Passport_Number, License_Number, Dept_ID) ja osastosuhde osastona ( Osaston_ID , Osaston_nimi).

Työntekijäsuhteessa Emp_ID on ensisijainen avain, kun taas Dept_ID on osastorelaation ensisijainen avain. Attribuutti Dept_Id on yksi attribuutti Työntekijä-relaatiossa, joka on osastorelaation ensisijainen avain. Siksi Dept_ID toimii viiteavaimena.

Yhdistelmäavain:

Yhdistelmäavain on attribuuttiryhmä, joka löytää yksilöllisesti erittäin työntekijän tiedot suhteesta. Yhdistelmäavain on kahden ja useamman kuin kahden attribuutin yhdistelmä.

Yllä olevasta työntekijäsuhteesta Emp ( Emp_ID , Emp_Name, Passport_Number, License_Number), yhdistelmäavain on (Emp_name, Emp_ID).

Ennen kuin tietojen normalisointi muodostuu, toinen käsite, joka sinun on opittava, on toiminnalliset riippuvuudet ja avaintyypit. Kerro meille yksityiskohtaisesti toiminnalliset riippuvuudet.

Toiminnalliset riippuvuudet tietokannassa

E.F. Codd kehitti toiminnallisen riippuvuuden käsitteen tarpeettomien tietojen välttämiseksi tai poistamiseksi. Toiminnallinen riippuvuus on suhde minkä tahansa kahden saman suhteen attribuutin tai sarakkeen välillä. Toisin sanoen yksi attribuutti löytää yksilöllisesti toisen attribuutin. Molemmat attribuutit kuuluvat samaan suhteeseen.

Tarkastellaan esimerkiksi saman taulukon kahta saraketta A ja B. Toiminnallinen riippuvuus on A:n ja B:n välillä vain, jos sarake A löytää yksiselitteisesti sarakkeen B. Se esitetään muodossa A -> B ja luetaan, koska B on toiminnallisesti riippuvainen A:sta. Voit viitata A:han determinanttina ja B:hen riippuvaisena .

Toiminnallisia riippuvuuksia on erilaisia. Katsotaanpa joitain näistä toiminnallisista riippuvuuksista tässä.

Triviaali toiminnallinen riippuvuus:

Tarkastellaan kahta saman suhteen attribuuttia, A ja B. Triviaali toiminnallinen riippuvuus pätee vain, jos B on A:n osajoukko.

A -> B, jos B on A:n osajoukko.

Harkitse työntekijäsuhdetta. Ota kaksi attribuuttia, Emp_ID ja Emp_Name. Attribuutti Emp_Id on toiminnallisesti riippuvainen arvosta {Emp_ID, Emp_Name}.

{Emp_ID, Emp_Name} -> Emp_ID

Tässä Emp_ID on arvon {Emp_ID, Emp_Name} osajoukko. Tästä syystä {Emp_ID, Emp_Name} -> Emp_ID on triviaali toiminnallinen riippuvuus.

Ei-triviaali toiminnallinen riippuvuus:

Ei-triviaali toiminnallinen riippuvuus on triviaalin toiminnallisen riippuvuuden vastakohta. Otetaan kaksi saraketta, P ja Q, joilla on sama suhde. Ei-triviaali toiminnallinen riippuvuus pätee, jos Q ​​ei ole P:n osajoukko.

P -> Q, jos Q ​​ei ole P:n osajoukko

Jos P-leikkaus Q on NULL, se on täydellinen ei-triviaali toiminnallinen riippuvuus.

Harkitse työntekijäsuhteen kolmea saraketta, Emp_ID, Emp_Name ja Emp_Add.

Emp_ID -> Emp_Name

Yllä oleva riippuvuus on ei-triviaali toiminnallinen riippuvuus, koska Emp_Name ei ole Emp_ID:n osajoukko.

Transitiivinen toiminnallinen riippuvuus:

Transitiivinen toiminnallinen riippuvuus sisältää kaksi erillistä toiminnallista riippuvuutta. Se muodostuu epäsuorasti kahdella riippuvuudella. Tarkastellaan saman taulukon kolmea attribuuttia, A, B ja C. Triviaaliriippuvuus A -> C pätee, jos

• A -> B
• B ei pidä A:ta
• B -> C

Harkitse opiskelijataulukkoa. Ota kolme saraketta, Stud_ID, Stud_Name ja Stud_Age. Transitiivinen toiminnallinen riippuvuus Stud_ID -> Stud_Age pito, jos

• Stud_Id -> Stud_Name
• Stud_Name ei sisällä Stud_Id:tä.
• Stud_Name -> Stud_Age

Näin ollen, jos tiedämme opiskelijan tunnuksen, voimme selvittää hänen ikänsä.

Moniarvoinen riippuvuus:

Yhdelle determinantille missä tahansa toiminnallisessa riippuvuudessa on kaksi tai useampi riippuvainen. Tarkastellaan toiminnallista riippuvuutta X -> Y. Moniarvoisessa riippuvuudessa jokaiselle X:lle on useita Y:n arvoja.

Moniarvoisen riippuvuuden tyydyttämiseksi suhteessa tulee olla vähintään kolme attribuuttia. Esimerkiksi R(X, Y, Z). Jos X:n ja Y:n välillä on moniarvoinen toiminnallinen riippuvuus, niin Y- ja Z-attribuuttien tulee olla toisistaan ​​riippumattomia.

Olemme nähneet kaikki olennaiset elementit, joita tarvitaan ymmärtämään tietokannan normalisointi . Siirrytään nyt kohti ydinaihetta, tietokannan normalisointi lomakkeita.

Liity riippuvuuteen:

Tarkastellaan relaatiota R, jolla on A-, B-, C- ja D-attribuutit. Relaatio R jaetaan kahdeksi muuksi suhteeksi, R1 ja R2, joissa R1:llä on attribuutit A, B ja C ja R2:lla C- ja D-attribuutit. Jos yhdistämme R1:n ja R2:n yhteisellä attribuutilla C ja tuloksena oleva relaatio on sama kuin R:n relaatio, niin liittyä riippuvuuteen olemassa.

The liittyä riippuvuuteen sanotaan häviöttömäksi, jos liitoksen jälkeen tuloksena olevan suhteen attribuutit ovat samat kuin R:n attribuutit.

Tietokannan normalisoinnin eri muodot

Useita muotoja tietokannan normalisointi on kehitetty poistamaan tietojen redundanssi ja parantamaan tietojen eheys . Seuraavat ovat erilaiset tietokannan normalisointilomakkeet ja niiden esiintymät.

Ensimmäinen normaalimuoto (1NF):

Ensimmäinen muoto tietokannan normalisointi on ensimmäinen normaali muoto. Tietokantarelaatio on ensimmäisessä normaalimuodossa vain silloin, kun sen kaikilla attribuutilla on yksi tai atomiarvo. Mikään taulukon attribuutti ei saa sisältää useita arvoja. Katsotaanpa esimerkkiä, kuinka taulukko noudattaa ensimmäistä normaalimuotoa.

Harkitse Työntekijä-taulukkoa, jonka attribuutteina on Emp_ID, Emp_Name, Emp_Add ja Emp_Mobile_Number.

Työntekijä

Yllä oleva taulukko ei ole ensimmäisessä normaalimuodossa (1NF); työntekijänä Samilla on kaksi matkapuhelinnumeroa. Näin ollen yllä oleva taulukko ei ole ensimmäisen normaalimuodon mukainen. Ensimmäinen normaalimuoto sanoo, että jokaisella attribuutilla tulee olla atomiarvo. Siksi meidän on tehtävä yllä oleva taulukko ensimmäisessä normaalimuodossa.

Työntekijä 1

Yllä oleva Työntekijä1-suhde on ensimmäisessä normaalimuodossa, koska jokaisella attribuutilla on yksi arvo.

Ennen kuin aloitamme toisen normaalimuodon, sinun on tiedettävä ei-alku- ja alkumääritteet. Ensisijainen attribuutti on se, joka on ehdokasavaimessa. Ja ei-prime-attribuutti on se, jota ei ole ehdokasavaimessa.

Toinen normaalimuoto (2NF):

Toinen tietokannan normalisointi muoto on toinen normaalimuoto. Mikä tahansa tietokantarelaatio tai taulukko noudattaa toista normaalimuotoa, jos se täyttää seuraavat ehdot:

• Taulukon on oltava ensimmäisen normaalimuodon mukainen.
• Taulukon ei-prime-attribuutit eivät saa olla riippuvaisia ​​ehdokasavaimen oikeasta osajoukosta.

Voit saada selkeän käsityksen toisesta normaalimuodosta katsomalla alla olevaa esimerkkiä.

Harkitse opettajan suhdetta, jonka attribuutteina on Opettajan_tunnus, Aihe ja Opettajan_ikä. Taulukko on seuraava:

Opettaja

Tässä ehdokasavaimet ovat {Teacher_ID, Subject}, joka löytää yksilöllisesti opettajien tiedot. Koska attribuutti Teacher_Age ei ole ehdokasavaimessa, se palvelee ei-prime-attribuuttina.

Kun tarkastellaan yllä olevaa suhdetta, voimme päätellä, että taulukko noudattaa ensimmäistä normaalimuotoa tietokannan normalisointi . Jokainen attribuutti on yksiarvoinen. Mutta se ei ole toisessa normaalimuodossa. Voimme tunnistaa minkä tahansa opettajan iän vain Teacher_ID-attribuutin avulla. Koska Teacher_Age on ei-prime-attribuutti ja Opettajan_ID on ehdokasavaimen oikea osajoukko, se rikkoo 2NF-sääntöä.

Jotta yllä oleva relaatio voidaan tehdä toisessa normaalimuodossa, meidän on jaettava se kahteen taulukkoon seuraavasti:

Opettajan_ikä

Aihe

Yllä olevat kaksi suhdetta ovat toisessa normaalimuodossa.

Kolmas normaalimuoto:

Kolmas normaalimuoto on pesä tietokannan normalisointi muodossa. Minkä tahansa suhteen sanotaan olevan kolmannessa normaalissa, jos se täyttää seuraavat ehdot:

• Suhteen tulee noudattaa toista normaalimuotoa (2NF).
• Millään ei-prime-attribuutilla ei pitäisi olla transitiivista toiminnallista riippuvuutta superavaimesta.

Voit myös määritellä kolmannen normaalimuodon tietokannan normalisointi koska taulukon pitäisi olla 2NF:ssä ja toiminnallisen riippuvuuden X -> Y tulee noudattaa jotakin seuraavista ehdoista:

• X:n tulisi olla suhteen superavain.
• Y:n tulee olla suhteen alkumäärite.

Katsotaan kuinka taulukko on kolmannen normaalimuodon mukainen. Harkitse työntekijäsuhdetta, jolla on Emp_ID, Emp_Name, Emp_Zip, Emp_State, Emp_City ja Emp_District. Tämä suhde esitetään seuraavasti:

Työntekijä

Työntekijäsuhteen superavaimet ovat {Emp_ID}, {Emp_ID, Emp_Name}, {Emp_ID, Emp_Name, Emp_Zip} ja monet muut. Ehdokasavain on {Emp_ID}. Tästä syystä EMP_ID on prime-attribuutti ja kaikki muut eivät ole prime-attribuutteja.

Voit nähdä, että kolme attribuuttia, Emp_State, Emp_City ja Emp_District, ovat toiminnallisesti riippuvaisia ​​Emp_Zip-attribuutista. Voimme löytää postinumeron käyttämällä Emp_ID-attribuuttia. Tästä syystä Emp_Zip on riippuvainen Emp_ID:stä.

Kolme attribuuttia, Emp_State, Emp_City ja Emp_District, eivät ole prime-määritteitä. Ne ovat epäsuorasti riippuvaisia ​​Emp_ID-attribuutista, joka rikkoo 3NF-sääntöjä. Jotta työntekijäsuhde olisi kolmannen normaalimuodon (3NF) mukainen, meidän on jaettava taulukko pienempiin taulukoihin seuraavasti:

Henkilöstökortti

Employee_Zip

Yllä olevat kaksi taulukkoa ovat kolmannessa normaalimuodossa.

Boyce Coddin normaalimuoto (BCNF):

Boyce Codd Normaali muoto tietokannan normalisointi on 3NF:n laajennettu versio. Sitä kutsutaan nimellä 3.5NF. Mikä tahansa taulukko tai relaatio on BCNF:n mukainen, jos se täyttää seuraavat ehdot:

• Suhteen tulee olla kolmannessa normaalimuodossa (3NF).
• Kaikille funktionaalisille riippuvuuksille A -> B relaatiossa A:n tulisi olla superavain.

Ymmärrät selkeästi BCNF-konseptin esimerkin avulla useiden yritysten osastoilla työskentelevistä työntekijöistä. Harkitse työntekijäsuhdetta, jonka attribuutteina on Työntekijätunnus, Työntekijän_kansallisuus, Työntekijän_osasto, Osaston_tyyppi, Työntekijöiden_määrä. Relaatiolla on seuraavat arvot:

Työntekijä

Yllä olevan suhteen ehdokas on {Emp_ID, Emp_Dept}. Yksittäinen Emp_ID-attribuutti ei voi tarjota osastotietoja, eikä Emp_Dept voi määrittää työntekijätietoja. Joten yllä oleva suhde ei ole BCNF:n mukainen. Jos haluat tehdä yllä olevan taulukon BCNF:ssä, jaa se kolmeen taulukkoon seuraavasti:

Työntekijän kansalaisuus

Tässä Emp_ID on ehdokasavain. Toiminnallinen riippuvuus on Emp_ID -> Emp_Nationality. Siksi se on BCNF:ssä.

Työntekijä_osasto

Tässä Emp_Dept on ehdokasavain ja toiminnallinen riippuvuus on {Emp_Dept -> Dept_Type, No_of_Employees}. Siksi yllä oleva suhde on myös BCNF:n mukainen.

Työntekijän_tunnus_osasto

Tälle suhteelle Emp_ID ja Emp_Dept ovat molemmat ehdokasavaimia.

Neljäs normaalimuoto (4NF):

Olemme nähneet moniarvoisen riippuvuuden yllä olevassa osiossa. Taulukon sanotaan olevan neljännessä normaalimuodossa, jos se täyttää kaikki alla olevat ehdot:

• Suhteen tulee noudattaa Boyce Coddin normaalia muotoa.
• Taulukon attribuuttien välillä ei saa olla moniarvoisia riippuvuuksia.

Puhumme neljännestä normaalimuodosta Students-relaatiolla. Opiskelijarelaatiolla on kolme attribuuttia. Stud_ID, Stud_Course ja Stud_Hobby. Taulukon arvot ovat seuraavat:

Opiskelijat

Yllä oleva relaatio ei ole neljännessä normaalimuodossa (4NF), koska siinä on moniarvoisia riippuvuuksia. Attribuutit Stud_Course ja Stud_Hobby ovat riippuvaisia ​​Stud_ID-attribuutista, joka päättyy moniarvoiseen riippuvuuteen. Siksi, jotta voimme tehdä yllä olevan suhteen 4NF:ssä, meidän on jaettava relaatio kahdeksi erilaiseksi suhteeksi seuraavasti:

Opiskelijat_kurssi

Opiskelijat_Hobby

Yllä olevat kaksi suhdetta ovat neljännessä normaalimuodossa.

Viides normaali muoto:

Toinen tietokannan normalisointi muoto on viides normaalimuoto. Siitä käytetään myös nimitystä Project-Join Normal Form (PJ/NF). Mikä tahansa relaatio on viidennen normaalimuodon mukainen, jos se täyttää seuraavat ehdot:

• Taulukko on neljännessä normaalimuodossa (4NF).
• Liittymisriippuvuuksia ei pitäisi olla, ja suhteiden yhdistämisen tulee olla häviötöntä.

Viidennen normaalimuotokäsitteen ymmärtämiseksi näemme esimerkin tiedekunnan suhteesta.

Henkilöstö

Tiedekunnan relaatio ei ole viidennen normaalimuodon (5NF) mukainen. Jos haluat tehdä tiedekunnan suhteen viidennessä normaalimuodossa, hajota se kolmeen eri suhteeseen, kuten alla on esitetty:

Tiedekunta 1

Tiedekunta 2

Tiedekunta 3

Kaikki edellä mainitut kolme relaatiota ovat viidennessä normaalimuodossa.

Johtopäätös

The tietokannan normalisointi prosessi on erittäin hyödyllinen toistuvien tietojen poistamisessa ja tiedon eheysperiaatteen parantamisessa. Lisäksi se säästää levytilaa poistamalla ylimääräiset tiedot tietokannasta. Kun käyt tämän viestin läpi, ymmärrät toisin tietokannan normalisointi muodot ja toiminnalliset riippuvuustyypit.

Avaimet ovat tietokannan pääelementtejä. Niiden avulla käyttäjät voivat hakea tietoja nopeasti ja tehokkaasti. Käsittelimme avaintyypit, ensisijaisen avaimen, ehdokasavaimen, superavaimen, viiteavaimen ja yhdistelmäavaimen.

Tämän artikkelin sisältö antaa sinulle lyhyen käsityksen erilaisista toiminnallisista riippuvuuksien tyypeistä. Olemme käsitelleet kuusi erilaista tietokannan normalisointi muodot, 1NF, 2NF, 3NF, BCNF, 4NF ja 5NF ja niiden vastaavat esimerkit. Toivomme, että löydät kaikki olennaiset tiedot opiskeluun tietokannan normalisointi lomakkeita.