Nämä kaksi yksinkertaista sääntöä auttavat tietokannan normalisoimisessa
Ensimmäinen normaali lomake (1NF) asettaa organisaation tietokannan perussäännöt:
- Poista päällekkäiset sarakkeet samasta taulukosta.
- Luo erilliset taulukot kullekin liittyvien tietojen ryhmälle ja tunnista jokainen rivin yksilöllisellä sarakkeella (ensisijainen avain).
Mitä nämä säännöt merkitsevät, kun tarkastellaan tietokannan käytännön suunnittelua? Se on itse asiassa melko yksinkertainen.
1. Poista kopiointi
Ensimmäinen sääntö määrää, että emme saa kopioida tietoja samassa taulukon rivissä. Tietokantayhteisön sisällä tätä käsitettä kutsutaan taulukon atomisyydeksi. Tämän säännön mukaiset taulukot sanotaan atomisiksi. Tutkitaan tätä periaatetta klassisella esimerkillä: taulukko henkilöstötietokannasta, joka tallentaa johtajan ja alaisen suhteen. Esimerkkinä määrittelemme liiketoimintasäännön, että jokaisella johtajalla voi olla yksi tai useampi alainen, kunilla kaikilla alisteilla voi olla vain yksi johtaja.
Kun luomme luettelon tai laskentataulukon näiden tietojen seuraamiseksi, voimme luoda taulukon, jossa on seuraavat kentät:
- johtaja
- Subordinate1
- Subordinate2
- Subordinate3
- Subordinate4
Muista kuitenkin 1NF: n asettama ensimmäinen sääntö: poista päällekkäiset sarakkeet samasta taulukosta. Selvästi Subordinate1-Subordinate4 sarakkeet ovat päällekkäisiä. Ota hetki ja mieti tämän skenaarion aiheuttamia ongelmia. Jos johtajalla on vain yksi alainen, Subordinate2-Subordinate4 sarakkeet ovat yksinkertaisesti hukkaan tallennustilaa (arvokas tietokanta hyödyke). Lisäksi kuvitella, missä johtajalla on jo neljä alaista - mitä tapahtuu, jos hän ottaa toisen työntekijän? Koko pöydän rakenne vaatisi muutoksia.
Tässä vaiheessa tietokannan aloittelijoille tavallisesti tapahtuu toinen kirkas idea: Emme halua enemmän kuin yhtä saraketta ja haluamme sallia joustavan määrän tallennusta. Yritä jotain tällaista:
- johtaja
- alaistensa
Ja alaisten kentät sisältävät useita merkintöjä muodossa "Mary, Bill, Joe".
Tämä ratkaisu on lähempänä, mutta se on myös pienempi kuin merkki. Alisteiden sarake on edelleen päällekkäinen ja ei-atominen. Mitä tapahtuu, kun meidän on lisättävä tai poistettava alainen? Meidän täytyy lukea ja kirjoittaa koko taulukon sisältö. Se ei ole iso asia tässä tilanteessa, mutta entä jos yksi johtajalla oli sata työntekijää? Lisäksi se vaikeuttaa tietokannan tietojen valintaa tulevissa kyselyissä.
Tässä on taulukko, joka täyttää 1NF: n ensimmäisen säännön:
- johtaja
- alisteinen
Tässä tapauksessa kullakin alisteella on yksi merkintä, mutta johtajilla voi olla useita merkintöjä.
2. Tunnista ensisijainen avain
Nyt, mitä toinen sääntö: tunnistat jokaisen rivin yksilöllisellä sarakkeella tai sarakkeilla ( ensisijainen avain )? Voit tarkastella yllä olevaa taulukkoa ja ehdottaa alaisen sarakkeen käyttöä ensisijaisena avauksena. Itse asiassa alainen sarake on hyvä hakija ensisijaisen avaimen takia, että liiketoimintasääntömme täsmentävät, että kaikilla alisteilla voi olla vain yksi johtaja. Kuitenkin tiedot, jotka olemme päättäneet tallentaa taulukkomme, tekevät tästä vähemmän kuin ihanteellinen ratkaisu. Mitä tapahtuu, jos palkata toinen työntekijä nimeltä Jim? Kuinka tallennamme johtaja-alaiset suhteet tietokantaan?
On parasta käyttää todella yksilöllistä tunnistetta (kuten työntekijän tunnusta) ensisijaisena avauksena . Finaalipöytämme näyttäisi näin:
- Manager ID
- Alistustunnus
Nyt pöydämme on ensimmäisessä normaalissa muodossa! Jos haluat jatkaa normalisoinnin oppimista, lue lisää tämän sarjan artikkeleista: