Olemme tarkastelleet useita tietokannatustaulukon normalisoinnin osa-alueita. Ensin keskustelimme tietokannan normalisoinnin perusperiaatteista. Viime kerralla selvitimme ensimmäisen normaalin muodon (1NF) mukaiset perusvaatimukset. Nyt jatketaan matkaa ja katetaan toisen normaalin muodon (2NF) periaatteet.
2NF: n yleiset vaatimukset
- Poista taulukon useisiin riveihin sovellettavat tietoryhmät ja aseta ne erillisiin taulukoihin.
- Luo suhteita näiden uusien taulukoiden ja niiden edeltäjien välillä käyttämällä vieraita avaimia.
Nämä säännöt voidaan tiivistää yksinkertaisella lausunnolla: 2NF pyrkii vähentämään taulukossa olevan redundanttisen tiedon määrää poimimalla sen, asettamalla sen uuteen taulukkoon ja luomalla näiden taulukkojen välisiä suhteita.
Katsotaanpa esimerkkiä. Kuvittele verkkokauppa, joka ylläpitää asiakastietoja tietokannassa. Heillä voi olla yksi taulukko asiakkaiksi, joilla on seuraavat elementit:
- CustNum
- Etunimi
- Sukunimi
- Osoite
- Kaupunki
- Osavaltio
- POSTINUMERO
Tämän taulukon lyhyt tarkastelu paljastaa pienen määrän tarpeettomia tietoja. Tallennamme "Sea Cliff, NY 11579" ja "Miami, FL 33157" merkinnät kahdesti. Tämä ei ehkä näytä liiallisesta lisävarastosta yksinkertaisessa esimerkissämme, vaan kuvitella hukkatilaa, jos meillä oli tuhansia riviä taulukossamme. Lisäksi, jos Sea Cliffin postinumero muuttuisi, meidän olisi tehtävä tämä muutos monissa paikoissa koko tietokannassa.
2NF-yhteensopivassa tietokantarakenteessa tämä ylimääräinen tieto uutetaan ja tallennetaan erilliseen taulukkoon. Uusi taulukko (kutsutaan ZIP-nimellä) voi olla seuraavat kentät:
- POSTINUMERO
- Kaupunki
- Osavaltio
Jos haluamme olla erittäin tehokas, voimme jopa täyttää tämän taulukon etukäteen - postitoimisto tarjoaa hakemiston kaikista voimassa olevista postinumeroista ja niiden kaupunki / valtio-suhteista. Olet varmasti joutunut tilanteeseen, jossa tällaista tietokantaa käytettiin. Joku tilauksen vastaanottamisesta saattoi ensin kysyä sinusta ZIP-koodia ja sitten tietää kaupungin ja valtion, johon soitat. Tämän tyyppinen järjestely vähentää käyttäjän virheitä ja lisää tehokkuutta.
Nyt kun olemme poistaneet päällekkäiset tiedot Asiakkaat-taulukosta, olemme täyttäneet toisen normaalin muodon ensimmäisen säännöt. Meidän on vielä käytettävä ulkomaista avainta kahden pöydän yhdistämiseen. Luomme kyseisen suhteen ZIP-koodin (ensisijainen avain ZIP-taulukosta). Tässä on uusi asiakkaamme taulukko:
- CustNum
- Etunimi
- Sukunimi
- Osoite
- POSTINUMERO
Olemme nyt minimoineet tietokannassa olevien tarpeettomien tietojen määrän ja rakenteemme ovat toisessa normaalissa muodossa.
