Select the product you need help with
Tietokannan normalisoinnin perusteiden kuvausArtikkelin tunnus: 283878 - Näytä tuotteet, joita tämä artikkeli koskee. Aloittelija: Tässä artikkelissa kuvatut toimet edellyttävät henkilökohtaisessa käytössä olevien tietokoneiden käyttöliittymän tuntemista. Tämän artikkelin Microsoft Access 2000 -sovellusta käsittelevä versio on 209534
(http://support.microsoft.com/kb/209534/FI/
)
(tämä artikkeli saattaa olla englanninkielinen). Tämän artikkelin Microsoft Access 95- tai Microsoft Access 97 -sovellusta käsittelevä versio on 100139
(http://support.microsoft.com/kb/100139/FI/
)
(tämä artikkeli saattaa olla englanninkielinen). Tällä sivullaYhteenveto Tässä artikkelissa on tietokannan normalisointitekniikan kuvaus aloittelijoille. Näiden termien perustiedoista on hyötyä käsiteltäessä relaatiotietokannan rakennetta. HUOMAUTUS: Microsoft tarjoaa myös WebCast-lähetyksen, jossa käsitellään tietokannan normalisoinnin perusteita. Voit katsella tämän WebCast-lähetyksen käymällä seuraavassa Microsoftin verkkosivustossa: http://support.microsoft.com/servicedesks/webcasts/wc060600/wc060600.asp?fr=1
(http://support.microsoft.com/?scid=http%3a%2f%2fsupport.microsoft.com%2fservicedesks%2fwebcasts%2fwc060600%2fwc060600.asp%3ffr%3d1)
Enemmän tietoaNormalisoinnin kuvausNormalisointi on tietokannan tietojen järjestämisen prosessi. Siihen sisältyy taulukoiden luomista ja suhteiden järjestämistä taulukoiden välille noudattamalla sääntöjä, jotka on suunniteltu sekä suojaamaan tietoja että tekemään tietokannasta entistä joustavamman poistamalla redundanssin ja epäyhtenäiset riippuvuussuhteet.Redundantit tiedot kuluttavat turhaan levytilaa ja aiheuttavat ylläpito-ongelmia. Jos useammassa kuin yhdessä sijainnissa olevia tietoja on muutettava, tiedot on muutettava täsmälleen samalla tavalla kaikissa sijainneissa. Asiakkaan osoitteen muutos on paljon helpompi toteuttaa, jos tiedot on tallennettu vain Asiakkaat-taulukkoon, eivätkä mihinkään muuhun sijaintiin tietokannassa. Mikä on "epäyhtenäinen riippuvuussuhde"? Vaikka käyttäjän on intuitiivista etsiä tietyn asiakkaan osoitetta Asiakkaat-taulukosta, kyseiselle asiakkaalle soittavan työntekijän palkkatietoja ei välttämättä ole järkevää etsiä siitä. Työntekijän palkka liittyy (tai on riippuvainen) työntekijästä, joten se tulee siirtää Työntekijät-taulukkoon. Epäyhtenäiset riippuvuussuhteet saattavat tehdä tiedoista vaikeakäyttöisiä, koska tietojen löytämisen polku saattaa puuttua tai olla katkennut. Tietokannan normalisoinnissa on joitakin sääntöjä. Kutakin sääntöä kutsutaan normaalimuodoksi. Jos ensimmäistä sääntöä noudatetaan, tietokannan sanotaan olevan ensimmäisessä normaalimuodossa. Jos ensimmäistä kolmea sääntöä noudatetaan, tietokannan sanotaan olevan kolmannessa normaalimuodossa. Vaikka muut normalisointitasot ovat mahdollisia, kolmatta normaalimuotoa pidetään suurimpana tarpeellisena tasona useimmille sovelluksille. Samoin kuin useiden muodollisten sääntöjen ja määritysten suhteen, todelliset skenaariot eivät aina salli täydellistä noudattamista. Yleisesti ottaen normalisointi edellyttää lisätaulukoita, ja osa asiakkaista kokee tämän vaivalloiseksi. Jos päätät rikkoa jotakin kolmesta ensimmäisestä normalisointisäännöstä, varmista, että sovelluksesi on valmistautunut mahdollisesti ilmeneviin ongelmiin, kuten redundantteihin tietoihin ja epäyhtenäisiin riippuvuussuhteisiin. Seuraavissa kuvauksissa on esimerkkejä. Ensimmäinen normaalimuoto
Mitä tapahtuu, kun lisäät kolmannen valmistajan? Kentän lisääminen ei riitä, vaan ohjelmaa ja taulukkoa on muokattava, eikä se mahdollista sujuvasti dynaamisten valmistajien määrän käyttämistä. Sijoita sen sijaan kaikki valmistajatiedot erilliseen taulukkoon nimeltä Valmistajat ja linkitä varasto valmistajaan käyttämällä nimikenumeroavainta tai valmistajat varastoon käyttämällä valmistajakoodiavainta. Toinen normaalimuoto
Kolmas normaalimuoto
Esimerkiksi hakijan yliopiston nimi ja osoite saattaa sisältyä Työntekijöiden työhönotto -taulukkoon. Tarvitset kuitenkin täydellisen luettelon yliopistoista ryhmäpostituksia varten. Jos yliopistojen tiedot on tallennettu Hakijat-taulukkoon, ei ole mitään tapaa näyttää luetteloa yliopistoista, joista ei ole nykyisiä hakijoita. Luo erillinen Yliopistot-taulukko ja linkitä se Ehdokkaat-taulukkoon käyttäen yliopistokoodiavainta. POIKKEUS: Kolmannen normaalimuodon noudattaminen ei ole aina käytännöllistä, vaikka se on teoreettisesti tavoiteltavaa. Jos sinulla on Asiakkaat-taulukko ja haluat poistaa kaikki mahdolliset kenttienväliset riippuvuussuhteet, sinun on luotava erilliset taulukot kaupungeille, postinumeroille, myyntiedustajille, asiakasluokille ja kaikille muille tekijöille, jotka saattavat olla kahdentuneina useissa tietueissa. Teoriassa normalisointi on tavoittelemisen arvoista. Useiden pienten taulukoiden käyttäminen saattaa kuitenkin heikentää suorituskykyä tai ylittää avointen tiedostojen ja muistin kapasiteetit. Kolmatta normaalimuotoa voi olla hyödyllistä käyttää vain tiedoille, jotka muuttuvat usein. Jos joitakin riippuvaisia kenttiä on jäljellä, suunnittele sovellus niin, että se edellyttää käyttäjän vahvistavan kaikki liittyvät kentät, kun yhtä kenttää muutetaan. Muut normalisointimuodotNeljäs normaalimuoto (Boyce-Coddin normaalimuoto eli BCNF) ja viides normaalimuoto ovat olemassa, mutta niitä sovelletaan käytännön suunnittelussa vain harvoin. Näiden sääntöjen jättäminen huomiotta saattaa antaa tulokseksi muun kuin täydellisen tietokantarakenteen, mutta sen ei pitäisi vaikuttaa tietokannan toimintaan.Esimerkkitaulukon normalisoiminenNäissä vaiheissa esitellään kuvitteellisen opiskelijataulukon normalisointiprosessi.
Ominaisuudet | Artikkeleiden käännökset
 |
Palaa alkuun
