Normalisointi on tietokannan suunnittelutekniikka, jota käytetään relaatiotietokantataulukon suunnittelussa korkeammalle normaalimuodolle. Prosessi on progressiivinen, ja korkeammalle tasolle tietokantojen normalisointia ei voida saavuttaa, elleivät edelliset tasot ole täyttyneet.
Tämä tarkoittaa, että datalla on epänormaalia muotoa (vähiten normalisoitua) ja tavoitteena on saavuttaa korkein Normalisointitasolla ensimmäinen askel olisi varmistaa, että noudatetaan ensimmäistä normaalia muotoa, toinen vaihe on varmistaa, että toinen normaalimuoto täyttyy, ja niin edelleen yllä mainitussa järjestyksessä, kunnes tiedot ovat kuudennen normaalin muodon mukaisia.
On kuitenkin syytä huomata, että 4NF: n ulkopuolella olevat normaalit muodot ovat pääasiassa akateemisen mielenkiinnon kohteena, koska niiden ratkaisemiseksi esiintyviä ongelmia esiintyy harvoin käytännössä.
Huomaa, että seuraavan esimerkin tiedot olivat suunniteltu tarkoituksellisesti ristiriidassa useimpien normaalien muotojen kanssa. Todellisessa elämässä on täysin mahdollista ohittaa jotkut normalisointivaiheet, koska taulukossa ei ole mitään ristiriitaa annettuun normaaliin muotoon. Yleensä tapahtuu myös, että yhden normaalin muodon rikkomisen korjaaminen korjaa myös korkeamman normaalin muodon rikkomisen prosessissa. Jokaisessa vaiheessa on myös valittu yksi taulukko normalisointia varten, mikä tarkoittaa, että tämän esimerkkiprosessin lopussa saattaa vielä olla joitain taulukoita, jotka eivät täytä korkeinta normaalimuotoa.
Initial dataEdit
Anna tietokantataulukon, jolla on seuraava rakenne:
| Otsikko | Kirjoittaja | Kirjoittajan kansallisuus | Muoto | Hinta | Aihe | sivut | paksuus | Julkaisija | Julkaisijan maa | Julkaisutyyppi | Lajityyppi | Lajityyppi |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| MySQL-tietokannan suunnittelu ja optimointi | Chad Russell | amerikkalainen | Kovakantinen | 49.99 | MySQL,
Tietokanta, Suunnittelu |
520 | Paksu | Apress | Yhdysvallat | E-kirja | 1 | Opetusohjelma |
Oletamme tässä esimerkissä, että jokaisella kirjalla on vain yksi kirjoittaja.
1NFEditin tyydyttäminen
1NF: n tyydyttämiseksi taulukon jokaisen sarakkeen arvojen on oltava atomi. Alkuperäisessä taulukossa Aihe sisältää joukon aihe-arvoja, mikä tarkoittaa, että se ei noudata.
Yksi tapa saavuttaa 1NF olisi erottaa päällekkäisyydet useisiin sarakkeisiin käyttämällä toistuvia Aihe-ryhmiä:
| Otsikko | Muoto | Kirjoittaja | Kirjoittajan kansalaisuus | Hinta | Aihe 1 | Aihe 2 | Aihe 3 | Sivut | Paksuus | Julkaisija | Julkaisijan maa | Genre ID | Genre Name |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| MySQL-tietokannan suunnittelun ja optimoinnin alku | Kovakantinen | Chad Russell | Amerikkalainen | 49.99 | MySQL | Tietokanta | Suunnittelu | 520 | Paksu | Apress | Yhdysvallat | 1 | opastus |
Vaikka nyt taulukko täyttää muodollisesti 1NF: n (on atominen), tämän ratkaisun ongelma on ilmeinen – jos kirjassa on enemmän kuin kolme aihetta, sitä ei voi lisätä tietokantaan muuttamatta sen rakennetta.
Ongelman ratkaisemiseksi tyylikkäämmällä tavalla on tarpeen tunnistaa taulukossa esitetyt entiteetit ja erottaa ne omiin taulukoihinsa. Tässä tapauksessa se johtaisi kirja-, aihe- ja julkaisijataulukoihin:
| Otsikko | Muoto | Kirjoittaja | Kirjoittajan kansallisuus | Hinta | Sivut | Paksuus | Lajityyppi | Lajityyppi | Julkaisijan tunnus |
|---|---|---|---|---|---|---|---|---|---|
| MySQL-aloitus Tietokannan suunnittelu ja optimointi | Kovakantinen | Chad Russell | Amerikkalainen | 49.99 | 520 | Paksu | 1 | Opetusohjelma | 1 |
|
|
Lähtötietojen yksinkertainen jakaminen useisiin taulukoihin katkaisi yhteyden tietojen välillä. Tämä tarkoittaa, että uusien käyttöön otettujen taulukoiden väliset suhteet on määritettävä. Huomaa, että Kirjan taulukon Publisher ID -sarake on vieras avain, joka toteuttaa monenvälisen suhteen kirjan ja kustantajan välillä.
Kirja mahtuu monille aiheille, samoin kuin aihe voi Tämä tarkoittaa myös sitä, että on määriteltävä monta monelle -suhde, joka on luotava luomalla linkkitaulukko:
|
Yhden epänormaalin taulukon sijasta on nyt 4 1NF: n mukaista taulukkoa.
Tyydyttävä 2NFEdit
Kirjataulukossa on yksi ehdokasavain (joka on siis ensisijainen avain), yhdistelmäavain {Otsikko, Muoto}. Harkitse seuraavaa taulukon osaa:
| Otsikko | muoto | Kirjoittaja | Kirjoittajan kansallisuus | Hinta | sivut | Paksuus | Genre ID | Genre Name | Publisher ID |
|---|---|---|---|---|---|---|---|---|---|
| MySQL-tietokannan suunnittelu ja optimointi | Kovakantinen | Chad Russell | amerikkalainen | 49.99 | 520 | paksu | 1 | Opetusohjelma | 1 |
| MySQL-tietokannan suunnittelun ja optimoinnin aloittaminen | E-kirja | Chad Russell | amerikkalainen | 22.34 | 520 | Paksu | 1 | Opetusohjelma | 1 |
| Tietokannan hallinnan relaatiomalli: Versio 2 | E-kirja | EFCodd | brittiläinen | 13.88 | 538 | paksu | 2 | Popular science | 2 |
| Tietokannan relaatiomalli nagement: Versio 2 | Pehmeäkantinen | EFCodd | Brittiläinen | 39.99 | 538 | Paksu | 2 | Suosittu tiede | 2 |
Kaikki määritteet, jotka eivät ole osa ehdokasavainta, riippuvat otsikosta, mutta vain hinta riippuu muodosta. 2NF: n mukauttamiseksi ja päällekkäisyyksien poistamiseksi jokaisen ei-ehdokasavain-määritteen on oltava riippuvainen koko ehdokasavaimesta, ei vain sen osasta.
Tämän taulukon normalisoimiseksi tee {Title} (yksinkertainen) ehdokasavain (ensisijainen avain) siten, että jokainen muu kuin ehdokasavain -attribuutti riippuu koko ehdokasavaimesta, ja poista hinta erilliseen taulukkoon, jotta sen riippuvuus muodosta voidaan säilyttää:
|
|
Nyt, kirjataulukko on 2NF: n mukainen.
3NFEditin tyydyttäminen
Kirjataulukossa on edelleen transitiivinen toiminnallinen riippuvuus ({Author Nationality} on riippuvainen {Author}, joka riippuu {Title }). Samanlainen rikkomus on olemassa tyylilajeitakin ({Genre Name} riippuu {Genre ID}, joka riippuu {Title}). Siksi Book-taulukko ei ole 3NF: ssä. Tehdäkseen sen 3NF: ssä, käytä seuraavaa taulukkorakennetta eliminoimalla transitiiviset toiminnalliset riippuvuudet sijoittamalla {Author Nationality} ja {Genre Name} omiin taulukoihinsa:
| Otsikko | Tekijä | Sivut | Paksuus | Genre ID | Publisher ID |
|---|---|---|---|---|---|
| MySQL-tietokannan suunnittelu ja Optimointi | Chad Russell | 520 | Paksu | 1 | 1 |
| Tietokannan hallinnan relaatiomalli: Versio 2 | EFCodd | 538 | Paksu | 2 | 2 |
|
| Kirjoittaja | Kirjoittajan kansalaisuus |
|---|---|
| Chad Russell | amerikkalainen |
| EFCodd | britti |
| Gen re ID | Lajityyppi |
|---|---|
| 1 | Opetusohjelma |
| 2 | kansantiede |
EKNFEditin tyydyttäminen
Alkeisavainnormaalimuoto (EKNF) on tiukasti 3NF: n ja BCNF: n välillä, eikä siitä ole paljon keskusteltu kirjallisuudessa. Se on tarkoitettu ”vangitsemaan sekä 3NF: n että BCNF: n keskeiset ominaisuudet” välttäen samalla molempien ongelmia (nimittäin, että 3NF on ”liian anteeksiantava” ja BCNF on ”altis laskennallisen monimutkaisuudelle”). Koska se mainitaan harvoin kirjallisuudessa, se ei sisälly tähän esimerkkiin.
4NFEditin tyydyttäminen
Oletetaan, että tietokanta on kirjan vähittäiskauppiasyrityksen omistuksessa, jolla on useita franchising-edunsaajia, jotka omistavat kauppoja eri paikoissa.Siksi jälleenmyyjä päätti lisätä taulukon, joka sisältää tietoja kirjojen saatavuudesta eri paikoissa:
| Franchise-ID | Otsikko | Sijainti |
|---|---|---|
| 1 | MySQL-tietokannan suunnittelun ja optimoinnin aloitus | Kalifornia |
| 1 | MySQL-tietokannan suunnittelun ja optimoinnin alku | Florida |
| 1 | MySQL-tietokannan suunnittelu ja optimointi | Texas |
| 1 | Tietokannan hallinnan relaatiomalli: Versio 2 | Kalifornia |
| 1 | Tietokannan hallinnan relaatiomalli: Versio 2 | Florida |
| 1 | Tietokannan hallinnan relaatiomalli: Versio 2 | Texas |
| 2 | MySQL-tietokannan suunnittelu ja optimointi | Kalifornia |
| 2 | MySQL-tietokannan suunnittelun ja optimoinnin alku | Florida |
| 2 | MySQL-tietokannan suunnittelun ja optimoinnin alku | Texas |
| 2 | Tietokannan hallinnan relaatiomalli: Versio 2 | Kalifornia |
| 2 | Tietokannan hallinnan relaatiomalli: Versio 2 | Florida |
| 2 | Tietokannan hallinnan relaatiomalli: Versio 2 | Texas |
| 3 | MySQL-tietokannan suunnittelu ja optimointi | Texas |
Koska tämä taulukkorakenne koostuu yhdistetystä ensisijaisesta avaimesta, se ei sisällä ei-avaimen määritteitä ja se on jo BCNF: ssä (ja täyttää siten myös kaikki aikaisemmat normaalit muodot). Jos kuitenkin oletamme, että kaikkia saatavilla olevia kirjoja tarjotaan kullakin alueella, saatamme huomata, että otsikko ei ole yksiselitteisesti sidottu tiettyyn sijaintiin, joten taulukko ei täytä 4NF: ää.
Tämä tarkoittaa, että Neljännen normaalimuodon tyydyttämiseksi myös tämä taulukko on hajotettava:
|
|
||||||||||||
| Franchise ID | Sijainti | ||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 1 | Kalifornia | ||||||||||||
| 1 | Florida | ||||||||||||
| 1 | Texas | ||||||||||||
| 2 | Kalifornia | ||||||||||||
| 2 | Florida | ||||||||||||
| 2 | Texas | ||||||||||||
| 3 | Texas |
Jokaisen tietueen tunnistaa yksiselitteisesti superavain, joten 4NF on tyytyväinen.
ETNFEditin tyydyttäminen
Oletetaan, että luvakkeensaajat voivat myös tilata kirjoja eri toimittajilta. Olkoon suhteelle myös seuraava rajoitus:
- Jos tietty toimittaja toimittaa tietyn otsikon
- ja otsikko toimitetaan franchising-asiakkaalle
- ja toimittaja toimittaa franchise-edunsaajalle
- sitten toimittaja toimittaa oikeuden franchising-asiakkaalle.
| Toimittajan tunnus | Otsikko | Franchise-ID |
|---|---|---|
| 1 | MySQL-tietokannan suunnittelu ja optimointi | 1 |
| 2 | Tietokannan hallinnan relaatiomalli: Versio 2 | 2 |
| 3 | SQL-oppiminen | 3 |
Tämä taulukko on 4NF-muodossa, mutta toimittajan tunnus on yhtä suuri kuin sen projektioiden liitos: {{Toimittajan tunnus, Kirja}, {Kirja, franchise-tunnus}, {Franchise-tunnus, toimittaja ID}}.Mikään kyseisen liitosriippuvuuden komponentti ei ole superavain (ainoa super-avain, joka on koko otsikko), joten taulukko ei täytä ETNF: ää ja voidaan hajottaa edelleen:
|
|
|
Hajoaminen tuottaa ETNF-yhteensopivuuden.
5NFEditin tyydyttäminen
Jos haluat löytää taulukon, joka ei täytä 5NF: tä, on yleensä tarpeen tutkia tiedot perusteellisesti. Oletetaan, että taulukossa on 4NF-esimerkki pienellä muutoksella tiedoissa ja tutkitaan, tyydyttääkö se 5NF:
| Franchise-ID | Otsikko | Sijainti |
|---|---|---|
| 1 | MySQL-tietokannan suunnittelun ja optimoinnin alku | Kalifornia |
| 1 | SQL-oppiminen | Kalifornia |
| 1 | Tietokannan hallinnan relaatiomalli: Versio 2 | Texas |
| 2 | Tietokannan hallinnan relaatiomalli: Versio 2 | Kalifornia |
Jos hajotamme tämän taulukon, pienennämme irtisanomisia ja saamme seuraavat kaksi taulukkoa:
|
|
Mitä tapahtuu, jos yritämme liittyä näihin taulukoihin? Kysely palauttaisi seuraavat tiedot:
| Franchise-ID | Otsikko | Sijainti |
|---|---|---|
| 1 | MySQL-tietokannan suunnittelu ja Optimointi | Kalifornia |
| 1 | SQL-oppiminen | Kalifornia |
| 1 | Tietokannan hallinnan relaatiomalli: Versio 2 | Kalifornia |
| 1 | Tietokannan hallinnan relaatiomalli: Versio 2 | Texas |
| 1 | SQL-oppiminen | Texas |
| 1 | MySQL-tietokannan suunnittelu ja optimointi | Texas |
| 2 | Tietokannan hallinnan relaatiomalli: Versio 2 | Kalifornia |
Ilmeisesti JOIN palauttaa kolme riviä enemmän kuin pitäisi – yritetään lisätä ano taulukon avulla selvittää suhde.Meillä on kolme erillistä taulukkoa:
|
|
|
Mitä JOIN palauttaa nyt? Näihin kolmeen pöytiin ei todellakaan ole mahdollista liittyä. Tämä tarkoittaa, että luvakkeensaajan – kirjan sijaintia ei ollut mahdollista hajottaa ilman tietojen menetystä, joten taulukko täyttää jo 5NF: n.
CJ Date on väittänyt, että vain 5NF: n tietokanta on todella ”normalisoitu”.
DKNFEditin tyydyttäminen
Katsotaanpa edellisten esimerkkien Kirjataulukkoa ja katsotaan, täyttääkö se Domain-avaimen normaalin muodon:
| Otsikko | Sivut | Paksuus | Genre ID | Julkaisijan tunnus | ||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| MySQL-tietokannan suunnittelu ja optimointi | 520 | Paksu | 1 | 1 | ||||||||||||||||||||||||||
| Tietokannan hallinnan relaatiomalli: Versio 2 | 538 | Paksu | 2 | 2 | ||||||||||||||||||||||||||
| SQL-oppiminen | 338 | Ohut | 1 | 3 | ||||||||||||||||||||||||||
| SQL-keittokirja | 636 | Paksu | 1 | 3 |
|
|
Tällä tavoin verkkotunnuksen eheysrikkomus on poistettu ja taulukko on DKNF-muodossa.
Tyydyttävä 6NFEdit
Kuudennen normaalin muodon yksinkertainen ja intuitiivinen määritelmä on, että ”taulukko on 6NF: ssä, kun rivi sisältää ensisijaisen avaimen ja enintään yhden muun attribuutin”.
Tämä tarkoittaa esimerkiksi Publisher-taulukkoa, joka on suunniteltu luomalla 1NF
| Julkaisijan_ID | Nimi | Maa |
|---|---|---|
| 1 | Apress | USA |
on edelleen hajotettu kahteen taulukkoon:
|
|
6NF: n ilmeinen haittapuoli on sellaisten taulukoiden lisääntyminen, joita tarvitaan yhden yksikön tietojen esittämiseen. Jos 5NF: n taulukossa on yksi ensisijaisen avaimen sarake ja N attribuuttia, samat tiedot 6NF: ssä edustavat vaativat N taulukkoa; usean kentän päivitykset yhteen käsitteelliseen tietueeseen edellyttävät päivityksiä useisiin taulukoihin; ja lisäykset ja poistot edellyttävät samalla tavalla toimintoja useissa taulukoissa. Tästä syystä tietokannoissa, jotka on tarkoitettu palvelemaan verkkotapahtumien käsittelyä, 6NF: ää ei tule käyttää.
Kuitenkin tietovarastoissa, jotka eivät salli interaktiivisia päivityksiä ja jotka ovat erikoistuneet nopeaan kyselyyn suurissa tietomäärissä , tietyt DBMS: t käyttävät sisäistä 6NF-esitystä – joka tunnetaan nimellä Columnar-tietovarasto. Tilanteissa, joissa sarakkeen yksilöllisten arvojen lukumäärä on paljon pienempi kuin taulukon rivien lukumäärä, sarakekohtainen varastointi sallii merkittävän tilansäästön tietojen pakkaamisen avulla. Pylväsvarasto mahdollistaa myös alueen kyselyjen nopean suorittamisen (esim. Näytä kaikki tietueet, joissa tietty sarake on X: n ja Y: n välillä tai alle X.)
Kaikissa näissä tapauksissa tietokannan suunnittelija ei kuitenkaan täytyy suorittaa 6NF-normalisointi manuaalisesti luomalla erilliset taulukot. Jotkut varastointiin erikoistuneet DBMS: t, kuten Sybase IQ, käyttävät oletusarvoisesti pylväsvarastoa, mutta suunnittelija näkee silti vain yhden monisarakkeisen taulukon. Muut DBMS: t, kuten Microsoft SQL Server 2012 ja uudemmat, antavat sinun määrittää sarakekaupan hakemisto tietylle taulukolle.
