Johdanto tietokannan normalisointiin

Tietokannan normalisointi on prosessi, jota käytetään tietokannan järjestämiseen taulukoiksi ja sarakkeiksi. Tärkein ajatus tässä on, että taulukon tulisi olla tietystä aiheesta ja mukana vain tukevat aiheet. Ota esimerkkinä tiedot sisältävä laskentataulukko, jossa tiedot sisältävät myyjiä ja asiakkaita, jotka palvelevat useita tarkoituksia:

• Tunnista organisaatiosi myyjät
• Luettelo kaikista asiakkaista, joihin yrityksesi kutsuu myydä tuotetta
• Tunnista, mitkä myyjät kutsuvat tiettyjä asiakkaita.

Rajoittamalla taulukkoa yhteen tarkoitukseen vähennät tietokannassasi olevien kaksoiskappaleiden määrää. Tämä eliminoi joitain tietokannan muutoksista johtuvia ongelmia.

Näiden tavoitteiden saavuttamiseksi käytämme joitain vakiintuneita sääntöjä. Kun sovellat näitä sääntöjä, muodostetaan uusia taulukoita. Eteneminen hallitsemattomasta optimoituun kulkee useiden normaalien muotojen läpi.

Useita tietokantoja noudatetaan kolmessa normaalissa muodossa. Kun taulukot täyttävät jokaisen peräkkäisen tietokannan normalisointilomakkeen, ne ovat vähemmän alttiita tietokannan muokkauspoikkeamille ja keskittyvät enemmän ainoaan tarkoitukseen tai aiheeseen. Ennen kuin jatkat, muista, että ymmärrät tietokantataulukon määritelmän.

Syitä tietokannan normalisointiin

Tietokannan normalisointiin on kolme pää syytä. Ensimmäinen on minimoida päällekkäinen data, toinen on minimoida tai välttää tietojen muuttamiseen liittyvät ongelmat, ja kolmas on yksinkertaistaa kyselyitä.

Kun käymme läpi eri normalisointitiloja, keskustelemme siitä, miten kukin lomake käsittelee näitä asioita, mutta aluksi tarkastelemme joitain tietoja, joita ei ole normalisoitu, ja keskustelemme mahdollisista karhuista.

Luulen, että kun ymmärrät ongelmat, arvostat paremmin normalisointia. Harkitse seuraavaa taulukkoa:

Ensimmäiseksi on huomioitava, että tässä taulukossa on monia tarkoituksia, mukaan lukien:

1. Organisaation myyjien tunnistaminen
2. Myynnin luettelointi toimistot ja puhelinnumerot
3. Myyjän yhdistäminen myyntitoimistoon
4. Kunkin myyjän asiakkaiden näyttäminen

DBA: na tämä nostaa punaisen lipun. Yleensä haluan nähdä taulukoita, joilla on yksi tarkoitus. Pöydän tarjoaminen moniin tarkoituksiin tuo mukanaan monia haasteita; nimittäin tietojen päällekkäisyys, tietojen päivitysongelmat ja lisääntynyt pyrkimys tietojen kyselyyn.

Tietojen päällekkäisyydet ja muokkauspoikkeamat

Huomaa, että jokaiselle SalesPersonille olemme listanneet sekä SalesOffice että OfficeNumber. Myyjän tietoja on päällekkäisiä. Päällekkäisillä tiedoilla on kaksi ongelmaa:

1. Se lisää tallennustilaa ja heikentää suorituskykyä.
2. Tietomuutosten ylläpitäminen on vaikeampi.

Esimerkiksi:

Harkitse, siirretäänkö Chicagon toimisto Evanstoniin, IL. Tämän heijastamiseksi taulukkoon meidän on päivitettävä kaikkien Chicagossa tällä hetkellä olevien myyntihenkilöiden merkinnät. Taulukomme on pieni esimerkki, mutta voit nähdä, olisiko se suurempi, että mahdollisesti tähän saattaa liittyä satoja päivityksiä.

Nämä tilanteet ovat muokkauspoikkeamia. Tietokannan normalisointi korjaa ne. Muunnospoikkeamia on kolme:

Lisää poikkeama

On tosiasioita, joita emme voi tallentaa, ennen kuin tiedämme koko rivin tiedot. Esimerkissämme emme voi tallentaa uutta myyntikonttoria, ennen kuin tunnemme myös myyjän. Miksi? Koska tietueen luomiseen tarvitaan ensisijainen avain. Meidän tapauksessamme tämä on EmployeeID.

Päivitä poikkeama

Tässä tapauksessa meillä on samat tiedot useilla riveillä. Esimerkiksi jos toimiston numero muuttuu, on tehtävä useita päivityksiä. Jos emme päivitä kaikkia rivejä, epäjohdonmukaisuuksia esiintyy.

Poikkeama

Rivin poistaminen aiheuttaa useamman kuin yhden tosiseikkojen poistamisen. Esimerkiksi, jos John Hunt jää eläkkeelle, kyseisen rivin poistaminen johtaa tietojen menettämiseen New Yorkin toimistosta.

Haku- ja lajitteluongelmat

Viimeinen harkitsemamme syy on helpottaa tietojen hakua ja lajittelua. Jos haluat etsiä tiettyä asiakasta, kuten Fordia, SalesStaff-taulukossa sinun on kirjoitettava kysely, kuten

SELECT SalesOfficeFROM SalesStaffWHERE Customer1 = ‘Ford’ OR Customer2 = ‘Ford’ OR Customer3 = ‘Ford’

Selkeä, jos asiakas olisi jotenkin yhdessä sarakkeessa kyselymme olisi yksinkertaisempi. Harkitse myös, haluatko suorittaa kyselyn ja lajitella sen asiakkaan mukaan.

Nykyinen taulukomme tekee tästä vaikean. Sinun olisi käytettävä kolmea erillistä UNION-kyselyä!Voit poistaa tai vähentää näitä poikkeavuuksia jakamalla tiedot eri taulukoihin. Tämä sijoittaa tiedot taulukoihin, jotka palvelevat yhtä tarkoitusta.

Taulukon uudelleensuunnittelu on tietokannan normalisointi.

Tietokannan normalisoinnin määritelmä

Tietokannan normalisointia on kolme yleistä muotoa: 1., 2. ja 3. normaali muoto. Ne on myös lyhennetty vastaavasti 1NF, 2NF ja 3NF.

On olemassa useita muita lomakkeita, kuten BCNF, mutta pidän niitä edistyneinä, eikä niitä ole liian välttämätöntä oppia alussa.

Lomakkeet ovat progressiivisia, mikä tarkoittaa, että saadakseen kolmannen normaalin muodon taulukon on ensin täytettävä toisen normaalin muodon säännöt ja toisen normaalin muodon on noudatettava ensimmäisen normaalin muodon sääntöjä. Ennen kuin keskustelemme eri muodoista ja säännöistä yksityiskohtaisesti, tehkäämme yhteenveto eri muodoista:

• Ensimmäinen normaali muoto – Tiedot tallennetaan relaatiotaulukkoon, jossa jokaisessa sarakkeessa on atomiarvoja. Ei ole toistuvia sarakeryhmiä.
• Toinen normaali muoto – Taulukko on ensimmäisessä normaalimuodossa ja kaikki sarakkeet riippuvat taulukon ensisijaisesta avaimesta.
• Kolmas normaali muoto – taulukko on toisessa normaalimuodossa ja kaikki sen sarakkeet eivät ole väliaikaisesti riippuvaisia ensisijaisesta avaimesta.

Jos säännöillä ei ole liikaa järkeä, älä huoli. Olen linkittänyt artikkeliin auttaakseni sinua ymmärtämään niitä.

Tällä hetkellä on tärkeää ymmärtää, että tietokantojen normalisointiin on kolme sääntöä. Joidenkin mielestä tietokannan normalisointi näyttää monimutkaiselta.

mutta sen ei tarvitse olla, ja kun ymmärrät sen, siitä tulee intuitiivinen.