MIKÄ ON KOLMAS NORMAALI MUOTO? (TIETOKANNAT) - TEKNIIKKA - 2026

Kolmas normaali muoto (tietokannat) on relaatiotietokanta suunnittelu tekniikka, jossa eri taulukoista, jotka muodostavat se ei vain täytä toisen normaali muoto, mutta kaikki niiden ominaisuuksia tai kentät ovat suoraan riippuvaisia perusavain.

Tietokantaa suunnitellessaan päätavoitteena on luoda tarkka esitys tiedoista, niiden välisistä suhteista ja asiaankuuluviin rajoituksiin.

Lähde: pixabay.com

Tämän tavoitteen saavuttamiseksi voidaan käyttää joitain tietokannan suunnittelutekniikoita, muun muassa normalisointia.

Tämä on prosessi, jossa tiedot järjestetään tietokantaan, jotta vältetään varmennukset ja mahdolliset poikkeamat tietojen lisäämisessä, päivittämisessä tai poistamisessa, jolloin syntyy yksinkertainen ja vakaa konseptimallin suunnittelu.

Se alkaa tutkimalla ominaisuuksien välistä funktionaalista suhdetta tai riippuvuutta. Ne kuvaavat tietojen ominaisuutta tai niiden välistä suhdetta.

Normaalit muodot

Normalisointi käyttää testisarjaa, jota kutsutaan normaaleiksi muotoiksi, jotta voidaan määrittää näiden ominaisuuksien optimaalinen ryhmittely ja lopulta luoda sopiva joukko suhteita, jotka tukevat yrityksen tietovaatimuksia.

Toisin sanoen normalisointitekniikka on rakennettu normaalin muodon käsitteen ympärille, joka määrittelee rajoitusjärjestelmän. Jos suhde täyttää tietyn normaalin muodon rajoitukset, suhteen sanotaan olevan kyseisessä normaalimuodossa.

Ensimmäinen normaali muoto (1FN)

Taulukon sanotaan olevan 1FN: ssä, jos kaikki sen määritteet tai kentät sisältävät vain yksilöllisiä arvoja. Toisin sanoen jokaisen attribuutin jokaisen arvon on oltava jakamaton.

Määritelmän mukaan relaatiotietokanta normalisoidaan aina ensimmäiseen normaalimuotoon, koska ominaisuuksien arvot ovat aina atomia. Kaikki tietokannan suhteet ovat 1FN.

Tällainen tietokannan jättäminen stimuloi kuitenkin useita ongelmia, kuten redundanssi ja mahdolliset päivitysvirheet. Näiden ongelmien korjaamiseksi kehitettiin korkeampia normaalimuotoja.

Toinen normaali muoto (2FN)

Se käsittelee pyöreiden riippuvuuksien poistamista pöydästä. Suhteen sanotaan olevan 2FN: ssä, jos se on 1FN: ssä, ja lisäksi jokainen ei-avainkenttä tai attribuutti riippuu täysin ensisijaisesta avaimesta, tai tarkemmin sanottuna, se varmistaa, että taulukolla on yksi tarkoitus.

Ei-avainattribuutti on mikä tahansa attribuutti, joka ei ole suhteen ensisijainen avain.

Kolmas normaali muoto (3FN)

Se käsittelee transitiivisten riippuvuuksien poistamista taulukosta. Toisin sanoen, poista avaimen määritteet, jotka eivät riipu ensisijaisesta avaimesta, vaan toisesta määritteestä.

Transitiivinen riippuvuus on tyyppinen funktionaalinen riippuvuus, jossa muun kuin avaimen kentän tai määrän arvo määritetään toisen kentän, joka ei myöskään ole avain, arvolla.

Sinun tulisi etsiä toistuvia arvoja muissa kuin avainmääritteissä varmistaaksesi, että nämä ei-avainominaisuudet eivät riipu muusta kuin ensisijaisesta avaimesta.

Ominaisuuksien sanotaan olevan toisistaan ​​riippumattomia, jos yksikään niistä ei ole toiminnallisesti riippuvainen muiden yhdistelmästä. Tämä keskinäinen riippumattomuus varmistaa, että ominaisuudet voidaan päivittää erikseen, ilman vaaraa vaikuttaa toiseen ominaisuuteen.

Siksi, jotta tietokannan suhde olisi kolmannessa normaalimuodossa, sen on oltava seuraavan mukainen:

- Kaikki 2FN: n vaatimukset.

- Jos on attribuutteja, jotka eivät liity ensisijaiseen avaimeen, ne on poistettava ja sijoitettava erilliseen taulukkoon, joka liittyy molemmat taulukot vieraan avaimen avulla. Toisin sanoen transitiivisiä riippuvuuksia ei pitäisi olla.

Esimerkkejä kolmannesta normaalimuodosta

Esimerkki 1

Olkoon taulukko STUDENT, jonka pääavain on opiskelijan tunnus (STUDENT_ID) ja joka koostuu seuraavista määritteistä: STUDENT_NAME, STREET, CITY ja POST_CODE, jotka täyttävät 2FN: n ehdot.

Tässä tapauksessa STREET: llä ja CITY: llä ei ole suoraa yhteyttä ensisijaiseen avaimeen STUDENT_ID, koska ne eivät ole suoraan yhteydessä opiskelijaan, mutta ovat täysin riippuvaisia ​​postinumeroista.

Koska opiskelija sijaitsee CODE_POSTAL: n määrittämällä sivustolla, STREET ja CITY liittyvät tähän ominaisuuteen. Tämän toisen riippuvuusasteen takia näitä määritteitä ei tarvitse tallentaa OPISKELIJA-taulukkoon.

Luo uusi taulukko

Oletetaan, että samassa postinumerossa on useita opiskelijoita, ja STUDENT-taulukossa on valtava määrä tietueita ja kadun tai kaupungin nimi on muutettava. Tämän kadun tai kaupungin on löydettävä ja päivitettävä koko taulukossa. OPISKELIJA.

Esimerkiksi, jos joudut vaihtamaan kadun “El Limón” nimeksi “El Limón II”, sinun on haettava ”El Limón” koko STUDENT-taulukosta ja päivitettävä sitten ”El Limón II”.

Valtavasta taulukosta etsiminen ja yhden tai useamman tietueen päivittäminen vie kauan ja vaikuttaa siten tietokannan suorituskykyyn.

Sen sijaan nämä yksityiskohdat voidaan pitää erillisessä taulukossa (POSTCARD), joka liittyy STUDENT-taulukkoon POST_CODE-määritteen avulla.

POST-taulukossa on suhteellisen vähemmän tietueita ja tämä POST-taulukko on päivitettävä vain kerran. Tämä heijastuu automaattisesti STUDENT-taulukkoon, yksinkertaistamalla tietokantaa ja kyselyjä. Joten pöydät ovat 3FN: n kokoisia:

Esimerkki 2

Anna seuraavan taulukon käyttää Project_Num -kenttää ensisijaisena avaimena ja toistettujen arvojen määritteissä, jotka eivät ole avaimia.

Puhelinarvo toistetaan joka kerta, kun johtajan nimi toistetaan. Tämä johtuu siitä, että puhelinnumerolla on vain toisen asteen riippuvuus projektinumerosta. Se riippuu todella ensin managerista, ja tämä puolestaan ​​riippuu projektin numerosta, mikä tekee transitiivisen riippuvuuden.

Project_Manager -attribuutti ei voi olla mahdollinen avain Projects-taulukossa, koska sama johtaja hallinnoi useita projekteja. Ratkaisu tähän on poistaa attribuutti toistuvilla tiedoilla (puhelin) luomalla erillinen taulukko.

Vastaavat attribuutit on ryhmitettävä yhteen luomalla uusi taulukko niiden tallentamiseksi. Tiedot syötetään ja varmistetaan, että toistetut arvot eivät ole osa pääavainta. Ensisijainen avain asetetaan jokaiselle pöydälle ja tarvittaessa lisätään vieraita avaimia.

Kolmannen normaalin muodon noudattamiseksi luodaan uusi taulukko (johtajat) ongelman ratkaisemiseksi. Molemmat taulukot liittyvät Project_Manager-kentän kautta:

Viitteet

1. Teradata (2019). Ensimmäinen, toinen ja kolmas normaali muoto. Otettu: docs.teradata.com.
2. Opastuskuppi (2019). Kolmas normaali muoto (3NF). Otettu: tutorialcup.com.
3. Database Dev (2015). Kolmas normaali muoto (3NF) - Tietokannan normalisointi. Kuvannut: databasedev.co.uk.
4. Suhteellinen DB-suunnittelu (2019). Johdanto kolmanteen normaalimuotoon. Kuvannut: relationaldbdesign.com.
5. Nuket (2019). SQL: n ensimmäinen, toinen ja kolmas normaali muoto. Ostettu: dummies.com.