Office
Logi sisse
Andmebaasi kujunduse alused

Andmebaasi kujunduse alused

Korralikult üles ehitatud andmebaas annab teile alati juurdepääsu ajakohasele ja täpsele teabele. Kuna õige ülesehitus on andmebaasiga töötamisel eesmärkide saavutamiseks hädavajalik, tasub võtta aega hea disaini põhimõtetega tutvumiseks. Kokkuvõttes on nõnda märksa suurem võimalus saada andmebaas, mis vastab teie vajadustele ning mida on lihtne muuta.

Sellest artiklist leiate juhised töölauaandmebaasi kavandamiseks. Muu hulgas saate teada, kuidas otsustada, millist teavet teil vaja on, kuidas seda teavet asjakohasteks tabeliteks ja veergudeks jaotada ning kuidas on need tabelid omavahel seotud. Enne oma esimese töölauaandmebaasi loomist peaksite selle artikli läbi lugema.

NB!: Access annab teie käsutusse kujunduskeskkonna, mis võimaldab teil ka veebi jaoks andmebaasirakendusi luua. Andmebaaside konstrueerimisel veebi jaoks on kaalutlused sageli teistsugused. Selles artiklis ei käsitleta veebiandmebaasirakenduste konstruktsiooni. Lisateavet leiate artiklist Veebis ühiskasutatava andmebaasi koostamine.

Selle artikli teemad

Andmebaasiterminid, mida tasub teada

Milline on hea andmebaasikonstruktsioon?

Konstrueerimistoimingud

Andmebaasi otstarbe määratlemine

Vajaliku teabe leidmine ja korraldamine

Teabe jaotamine tabeliteks

Teabeüksuste teisendamine veergudeks

Primaarvõtmete määratlemine

Tabeliseoste loomine

Ülesehituse viimistlemine

Normeerimisreeglite rakendamine


Andmebaasiterminid, mida tasub teada

Access korraldab teie teabe tabelitena: ridade ja veergude loendina, mis sarnaneb raamatupidamistabeli või arvutustabeliga. Lihtne andmebaas võib sisaldada ainult ühte tabelit. Enamiku andmebaaside jaoks on vaja siiski mitut tabelit. Näiteks võib teil olla üks tabel tooteinfo, teine tabel tellimuste ja kolmas klientidega seotud teabe jaoks.

Pilt kolme tabeliga andmelehel

Andmebaasis nimetatakse rida kirjeks ja veergu väljaks. Kirje on tähenduslik ja järjepidev viis millegi kohta käivat teavet kombineerida. Väli on üks teabeüksus – üksusetüüp, mis kuvatakse igas kirjes. Näiteks tootetabelis vastab iga rida ehk kirje ühele tootele. Iga veerg ehk väli omakorda sisaldab selle toote kohta teatud tüüpi teavet, näiteks toote nime ja hinda.

Lehe algusse

Milline on hea andmebaasikonstruktsioon?

Andmebaasi konstrueerimisel tuleb juhinduda kindlatest põhimõtetest. Esimene põhimõte on, et korduv ehk liigne teave on halb, kuna raiskab ruumi ning võib suurendada vigade ja vastuolude arvu. Teine põhimõte on, et teave peab olema õige ja täielik. Kui andmebaas sisaldab valeteavet, sisaldavad seda ka kõik andmebaasi alusel koostatavad aruanded. Selle tulemusena on nende aruannete põhjal langetatud otsused ekslikud.

Seega on hea andmebaasikonstruktsiooni tundemärgid järgmised:

  • teave on liigse teab vältimiseks jaotatud teemapõhistesse tabelitesse;

  • Accessile on antud teave, mida on vaja tabelites oleva teabe ühendamiseks;

  • andmebaas aitab tagada teie teabe täpsust ja terviklust;

  • andmebaasi saab teie andmetöötlus- ja aruandevajadustega kohandada.

Lehe algusse

Konstrueerimistoimingud

Konstrueerimisprotsess koosneb järgmistest etappidest.

  • Andmebaasi otstarbe määratlemine    

    See aitab valmistuda järgmiste toimingute jaoks.

  • Vajaliku teabe leidmine ja korraldamine    

    Koguge kokku kogu teave, mida soovite andmebaasi salvestada, näiteks tootenimed ja tellimuste numbrid.

  • Teabe jaotamine tabeliteks    

    Jaotage teabeüksused suuremates rühmadeks ehk teemadeks (nt Tooted või Tellimused). Igast teemast saab seejärel omaette tabel.

  • Teabeüksuste teisendamine veergudeks    

    Otsustage, millist teavet soovite igas tabelis talletada. Igast üksusest saab väli, mis kuvatakse tabelis veeruna. Näiteks võib tabel „Töötajad“ sisaldada välju „Perekonnanimi“ ja „Tööle võetud“.

  • Primaarvõtmete määratlemine    

    Valige iga tabeli jaoks primaarvõti. Primaarvõti on veerg, mida saab kasutada iga rea kordumatuks tuvastamiseks. Näiteks võib see olla Toote ID või Tellimuse ID.

  • Tabelitevaheliste seoste määratlemine    

    Vaadake oma tabeleid ning otsustage, kuidas on ühes tabelis leiduv teave seotud teistes tabelites asuva teabega. Seoste täpsustamiseks lisage vajaduse korral tabelitesse välju või looge uusi tabeleid.

  • Konstruktsiooni viimistlemine    

    Analüüsige tabelite ülesehitust võimalike vigade leidmiseks. Looge tabelid ja lisage neisse näidisandmetega kirjed. Vaadake, kas tabelid annavad soovitud tulemeid. Vajaduse korral tehke ülesehituses muudatusi.

  • Normeerimisreeglite rakendamine    

    Kontrollimaks, kas tabelid on õigesti struktureeritud, rakendage andmetele normeerimisreeglid. Vajaduse korral tehke tabelite ülesehituses muudatusi.

Lehe algusse

Andmebaasi otstarbe määratlemine

Andmebaasi otstarbe võiksite paberile kirja panna: mis on andmebaasi eesmärk, kuidas kavatsete seda kasutada ja kes seda kasutama hakkab. Kui olete väikeettevõtja ja koostate väikest andmebaasi, võiksite kirjutada midagi lihtsat – näiteks „Kliendiandmebaas tooteteavituste ning aruannete jaoks vajaliku kliendinimekirja talletamiseks“. Kui andmebaas on keerukam või seda kasutab rohkem inimesi nagu juhtub sageli ärikasutuses, võib otstarbe kirjeldus enda alla võtta mitu lõiku ning peaks sisaldama teavet selle kohta, kes ja kuidas andmebaasi kasutama hakkab. Selle mõte on välja töötada selgelt sõnastatud eesmärk, millele saab viidata kogu konstrueerimisprotsessi käigus. Sõnastatud eesmärk aitab otsuste tegemisel sihil püsida.

Lehe algusse

Vajaliku teabe leidmine ja korraldamine

Vajaliku teabe leidmiseks ja korraldamiseks alustage olemasolevast teabest. Ehk hoiate näiteks ostutellimuste teavet pearaamatus või kliendiandmeid dokumendikaustade kapis? Koguge need dokumendid kokku ja pange kirja nende abil registreeritud teabe tüübid (nt vormil täidetavad väljad). Kui teil pole andmetega täidetud blankette, proovige ette kujutada, et peate koostama kliendiandmete talletamiseks sobiva vormi. Millised andmed te sellele vormile kannaksite? Milliseid täidetavaid välju kasutaksite? Tehke need andmed kindlaks ja pange kirja. Oletagem näiteks, et hoiate praegu kliendiandmeid kartoteegikaartidel. Nende kaartide analüüsimisel võib selguda, et igal kaardil on kliendi nimi, aadress, linn, maakond, sihtnumber ja telefoninumber. Iga taoline üksus kujutab endast võimalikku tabeliveergu.

Loendi koostamisel ärge muretsege selle üle, et see peaks kohe täiuslik saama. Pange kirja kõik, mis meelde tuleb. Kui andmebaasi hakkavad kasutama ka teised, küsige nende arvamust. Hiljem saate loendit täpsustada.

Järgmiseks võtke arvesse, milliseid aruandeid või saadetisi soovite andmebaasi põhjal luua. Näiteks on võimalik, et soovite teha väljavõtteid müügist piirkonniti või laoseisust toodete laoseisu kaupa. Samuti võite soovida koostada klientidele saatmiseks vormkirju, et teavitada neid müügipakkumistest või teha eripakkumisi. Kujundage aruanne vaimusilmas valmis. Millist teavet peaks see aruanne sisaldama? Pange kõik üksused kirja. Tehke sedasama vormkirjade ja muude aruannete jaoks, mida kavatsete luua.

Toote laoaruannet kujutav isik

Võimalike aruannete ja saadetiste läbimõtlemine aitab kindlaks teha, millised üksused on andmebaasis vajalikud. Oletagem, et soovite anda klientidele võimaluse tellida regulaarseid teabelehti (või neist lahti öelda) ning sooviksite välja printida teabelehe tellinud klientide nimekirja. Selle teabe andmebaasi salvestamiseks tuleb andmebaasi klienditabelisse lisada veerg „Saada meil“. Iga kliendi korral saate välja väärtuseks seada kas Jah või Ei.

Nõue saata klientidele meilisõnumeid tingib veel ühe registreerimist vajava üksuse lisamise: kui on teada, et klient soovib meilisõnumeid saada, on vaja teada ka meiliaadressi, kuhu need sõnumid või teabelehed saata. Seega on vaja iga kliendi jaoks registreerida ka meiliaadress.

Mõistlik on luua iga aruande ja väljundi jaoks prototüüp ning otsustada, milliseid üksusi on selle koostamiseks vaja. Näiteks võib teile üht-teist pähe turgatada vormkirja analüüsides. Kui soovite kirja kaasata korrektse tervitusvormeli (nt tervitust alustava stringi „Hr.“, „Pr.“ või „Prl.“), peate ka selle jaoks vastava üksuse looma. Samuti võite soovida meili alustada sõnadega “Lugupeetud hr. Sepp”, aga mitte “Lugupeetud hr. Silver Sepp”. See tähendab, et perekonnanimi tuleks talletada eesnimest eraldi.

Tähtis on meeles pidada, et iga teabeüksus tuleks jagada vähimateks kasulikeks osadeks. Kui soovite näiteks, et perekonnanimi oleks alati kohe kasutatav, peate nime jagama kaheks osaks – eesnimi ja perekonnanimi. Aruande sortimiseks perekonnanime järgi on hea, kui kliendi perekonnanimi on talletatud eraldi. Üldiselt tuleks iga teabeüksus, mille järgi soovite sortida, otsida, arvutada või mille alusel aruannet koostada, paigutada omaette väljale.

Mõelge küsimustele, millele soovite andmebaasist vastust saada. Kui mitu reklaamitud toote müügitellimust näiteks eelmisel kuul lõpule viidi? Kus elavad teie parimad kliendid? Kes on enimmüüdud toote tarnija? Nende küsimuste ettenägemine aitab selgeks teha, millise teabe peaksite andmebaasis salvestama.

Pärast selle teabe kogumist olete valmis järgmiseks toiminguks.

Lehe algusse

Teabe jaotamine tabeliteks

Teabe tabeliteks jagamiseks valige peamised olemid ehk teemad. Näiteks pärast tootemüügi andmebaasi jaoks vajaliku teabe otsimist ja korraldamist võib esialgne loetelu välja näha järgmine:

Käsitsi kirjutatud teabeüksused teemadeks rühmitatuna

Siin näidatud suuremad olemid on tooted, tarnijad, kliendid ja tellimused. Mõistlik ongi alustada nende nelja tabeliga: üks tooteinfo, üks tarnijate, üks klientide ja üks tellimuste jaoks. Kuigi see pole veel täielik nimekiri, on see hea algus. Saate selle täiendamist jätkata, kuni olete loonud hästi toimiva struktuuri.

Esmakordsel loendiüksuste ülevaatamisel võib tekkida kiusatus need joonisel kujutatud nelja tabeli asemel kõik ühte tabelisse paigutada. Peagi mõistate, miks see pole hea mõte. Vaadake hetkeks seda tabelit siin:

Pilt tabeliga, milles on nii tooted kui tarnijad

Sel juhul sisaldab iga rida teavet nii toote kui ka selle tarnija kohta. Kuna ühelt tarnijalt võib olla palju tooteid, kordub tarnija nimi ja aadress sageli. See raiskab kettaruumi. Palju parem lahendus on salvestata teave tarnijate kohta eraldi tabelisse ning sellele toodete tabelist viidata.

Teine probleem tekib selle ülesehitusega siis, kui peate tarnija andmeid muutma. Oletagem, et soovite muuta tarnija aadressi. Kuna see esineb mitmes kohas, võite andmed muuta küll ühes kohas, kuid kogemata unustada seda teha teises kohas. Tarnija aadressi salvestamine ainult ühes kohas kõrvaldab selle probleemi.

Andmebaasi konstrueerimisel proovige iga teabekild salvestada ainult üks kord. Kui tabate end sama teavet mitmes kohas kordamas (nt tarnija aadressi korral), paigutage see teave omaette tabelisse.

Lõpuks oletagem, et Coho Winery tarnib ainult ühte toodet ning soovite selle toote loendist kustutada, ent säilitada tarnija nime ja aadressi. Kuidas kustutaksite toote kirje ilma tarnija kohta käiva teabe kaotamiseta? See pole võimalik. Kuna iga kirje sisaldab andmeid nii toote kui ka tarnija kohta, ei saa ühte kustutada ilma teiseta. Nende andmete eraldi hoidmiseks peate tabeli kaheks jagama: üks tabel toote ja teine tarnija andmete jaoks. Tootekirje kustutamine peab kustutama ainult toote, mitte tarnija kohta käivad andmed.

Pärast tabelina esitatava teema valimist tuleks tabeli veergudes talletada andmeid ainult selle teema kohta. Näiteks peaks tootetabel sisaldama andmeid ainult toodete kohta. Kuna tarnija aadress on tarnija, mitte toote kohta käiv teave, kuulub see tarnijate tabelisse.

Lehe algusse

Teabeüksuste teisendamine veergudeks

Tabeli veergude tuvastamiseks otsustage, millist teavet tabelisse salvestatud teema kohta soovite jälgida. Klienditabelis näiteks võiksite alustuseks luua järgmised veerud: Nimi, Aadress, Linn-maakond-sihtnumber, Saada meil, Tervitus ning Meiliaadress. Kuna tabeli iga kirje sisaldab sama veerukomplekti, saate nime, aadressi, linna-maakonna-sihtnumbri, meilisõnumi saatmise, tervituse ja meiliaadressi teabe talletada iga kirje jaoks. Aadressiveerg näiteks sisaldab klientide aadresse. Iga kirje sisaldab andmeid ühe kliendi kohta ning aadressiväli sisaldab just selle kliendi aadressi.

Kui olete kindlaks määranud iga tabeli algse veerukomplekti, saate asuda veerge täpsemalt piiritlema. Näiteks on mõistlik talletada kliendi nimi kahes veerus: eesnimi ja perekonnanimi. Sel viisil saate sortida, otsida ja indekseerida ainult vastava veeru teabe põhjal. Aadress omakorda koosneb viiest erinevast osisest: aadress, linn, maakond, sihtnumber ja riik/regioon. Needki andmed on mõistlik paigutada omaette veergudesse. Kui soovite otsida, sortida või filtreerida näiteks maakonna järgi, peavad maakonna andmed olema eraldi veerus.

Peate mõtlema ka sellele, kas andmebaasis hakatakse hoidma vaid siseriiklikke või ka rahvusvahelisi andmeid. Näiteks võiks rahvusvaheliste andmete jaoks olla veeru Maakond asemel hoopis Piirkond, kuna sel juhul saate sinna salvestada nii oma riigi maakonnateavet kui ka rahvusvahelisi või teiste riikide haldusüksuste nimesid. Samamoodi tasub rahvusvaheliste andmete salvestamisele mõelda ka sihtnumbri veeru korral.

Järgmine loend pakub näpunäiteid veergude määratlemiseks.

  • Arvutuslikke andmeid ei tasu kaasata    

    Üldjuhul ei tasu tabeleisse salvestada arvutuste tulemeid. Kui soovite näha arvutuse tulemit, saate lasta Accessil arvutuse jooksvalt teha. Oletagem, et teil on aruanne „Tellitud tooted“, kus kuvatakse iga tootekategooria kohta tellitud tooteühikute vahesumma. Üheski tabelis pole aga veergu „Tellitud ühikud“. Selle asemel sisaldab tootetabel veergu, milles on kirjas iga tootekategooria tellitud tooteühikute arv. Nende andmete alusel arvutab Access vahesumma iga korda, kui te aruande prindite. Vahesummat ennast ei tohiks tabelis talletada.

  • Teave tuleb talletada väikseimate loogiliste osadena    

    Teil võib tekkida kiusatus kasutada ühtainsat välja täisnime või toote ja toote kirjelduse talletamiseks. Kui talletate ühel väljal mitut eri liiki teavet, on hiljem konkreetseid andmeid keerulisem välja tuua. Katsuge teave jagada loogilisteks osadeks, näiteks luua eraldi väljad ees- ja perekonnanime või tootenime, -kategooria või -kirjelduse jaoks.

Pilt, mis kujutab teabeüksusi kujundusprotsessi käigus

Kui olete tabeli andmeveerud täpsustanud, oletegi valmis valima iga tabeli jaoks primaarvõtme.

Lehe algusse

Primaarvõtmete määratlemine

Iga tabel peaks sisaldama veergu või veergude komplekti, mis tuvastab iga tabelis talletatava rea kordumatult. Sageli on see kordumatu identifitseerimisnumber või kood – näiteks töötaja ID või seerianumber. Andmebaasiterminoloogias nimetakse seda tabeli primaarvõtmeks. Access kasutab primaarvõtmevälju mitme tabeli andmete kiireks seostamiseks ja andmete koondamiseks.

Kui teil juba on tabelis ainuidentifikaator (näiteks tootekood, mis võimaldab üheselt tuvastada iga kataloogis oleva toote), võite seda kasutada tabeli primaarvõtmena – ent üksnes siis, kui selle veeru väärtused on kindlasti iga kirje jaoks erinevad. Primaarvõtme väärtused ei tohi korduda. Seetõttu pole mõistlik kasutada primaarvõtmena näiteks inimeste nimesid, kuna need ei pruugi olla kordumatud. Teil võib samas tabelis olla kergesti kaks sama nimega inimest.

Primaarvõtmel peab alati olema väärtus. Kui veeru väärtus võib mingil hetkel olla määratlemata või tundmatu (puuduv väärtus), ei saa seda primaarvõtmena kasutada.

Alati tuleb valida selline primaarvõti, mille väärtus ei muutu. Andmebaasis, kus on rohkem kui üks tabel, kasutatakse tabeli primaarvõtit teistes tabelites viitamiseks. Kui primaarvõti muutub, tuleb muudatus teha kõikjal, kus võtmele viidatakse. Muutumatu primaarvõtme kasutamine vähendab võimalust, et see langeb muudes tabelites, mis sellele viitavad, sünkroonist välja.

Sageli kasutakse primaarvõtmena suvalist kordumatut arvu. Näiteks võite igale tellimusele määrata kordumatu tellimusenumbri, mille ainus otstarve on tellimus tuvastada. Pärast selle numbri määramist seda enam ei muudeta.

Kui te ei oska arvata, milline veerg või veerukomplekt oleks primaarvõtme jaoks sobiv, võiksite kasutada automaatnumbri tüüpi veergu. Selle andmetüübi kasutamisel määrab Access automaatselt ise väärtuse. Selline identifikaator on sisutühi; see ei sisalda rea kohta mingit faktilist kirjeldavat teavet. Sisutühjad identifikaatorid on primaarvõtme jaoks ideaalsed, kuna need ei muutu. Rea kohta andmeid (telefoninumbrit või kliendi nime) sisaldava primaarvõtme muutumine on tõenäolisem, kuna sisuline teave ise võib muutuda.

Pilt, mis näitab primaarvõtme väljaga tootetabelit.

1. Veerg, mille andmetüüp on Automaatnumber, sobib enamasti hästi primaarvõtmeks. Kahe toote koodid pole kunagi samad.

Mõnel juhul võib teil tekkida soov kasutada tabeli primaarvõtme jaoks kahe või enama välja kombinatsiooni. Näiteks tabel „Tellimuste üksikasjad“, kus talletatakse tellimuste reaüksusi, võiks primaarvõtme jaoks kasutada kahte veergu: Tellimuse ID ja Toote ID. Kui primaarvõti hõlmab rohkem kui ühte veergu, kutsutakse seda liitvõtmeks.

Tootemüügi andmebaasi jaoks võite iga tabeli jaoks luua primaarvõtmena toimiva automaatnumbri veeru: tootetabeli jaoks Toote ID, tellimuste tabeli jaoks Tellimuse ID, klienditabeli jaoks Kliendi ID ning tarnijate tabeli jaoks Tarnija ID.

Pilt, mis kujutab teabeüksusi kujundusprotsessi käigus


Lehe algusse

Tabeliseoste loomine

Nüüd, kui olete andmed tabelitesse jaganud, on vaja need taas sisulisel viisil kokku tuua. Järgmine vorm näiteks koondab mitmest tabelist pärinevaid andmeid.

Tellimuste vorm

1. Selle vormi teave pärineb tabelist Kliendid...

2. ...tabelist Töötajad...

3. ...tabelist Tellimused...

4. ...tabelist Tooted...

5. ...ja tabelist Tellimuse üksikasjad.

Access on relatsioonandmebaaside haldussüsteem. Relatsioonandmebaasis jaotatakse andmed eraldiseisvaisse temaatilistesse tabelitesse. Seejärel saate teabe vastavalt vajadusele tabeliseoste abil kokku viia.

Lehe algusse

Üks-mitmele seose loomine

Oletagem, et tootetellimuste andmebaas sisaldab tabeleid „Tarnijad“ ja „Tooted“. Tarnija võib tarnida suvalist arvu tooteid. Järelikult võib iga tabelis „Tarnijad“ märgitud tarnija kohta olla tabelis „Tooted“ palju tooteid. Tabelite „Tarnijad“ ja „Tooted“ vaheline seos on üks-mitmele.

Üks-mitmele kontseptuaalskeem

Andmebaasi ülesehitamisel võtke üks-mitmele seose esitamiseks primaarvõti poolelt „üks“ ning lisage see lisaveeruna või -veergudena andmebaasipoole „mitmele“ tabelisse. Käesoleva artikli näite korral tuleks tabeli „Tarnija“ veerg „Tarnija ID“ lisada tabelisse „Tooted“. Access saab siis tabelis „Tooted“ kasutada konkreetse toote tarnija leidmiseks veergu „Tarnija ID“.

Tabeli „Tooted“ veergu „Tarnija ID“ kutsutakse võõrvõtmeks. Võõrvõti on teise tabeli primaarvõti. Veerg „Tarnija ID“ tabelis „Tooted“ on võõrvõti, kuna see on tabeli „Tarnijad“ primaarvõti.

Pilt, mis kujutab teabeüksusi kujundusprotsessi käigus

Seotud tabelite liitmise aluseks on primaar- ja võõrvõtmete sidumine. Kui te pole kindel, millistes tabelites peaks ühine veerg olema, aitab üks-mitmele seose väljaselgitamine kindlaks teha, millised kaks tabelit nõuavad ühist veergu.

Lehe algusse

Mitu-mitmele seose loomine

Mõelge tabelite „Tooted“ ja „Tellimused“ seosele.

Üks tellimus võib sisaldada rohkem kui ühte toodet. Teisest küljest võib üks toode esineda mitmes tellimuses. Seega võib iga tabeli „Tellimused“ kirje kohta olla tabelis „Tooted“ mitu kirjet ja vastupidi – iga tabeli „Tooted“ kirjele võib tabelis „Tellimused“ samuti vastata mitu kirjet. Seda tüüpi seost kutsutakse mitu-mitmele seoseks, kuna iga toote kohta võib olla mitu tellimust ning iga tellimuse kohta mitu toodet. Võtke arvesse, et mitu-mitmele seoste märkamiseks on vaja mõelda seose mõlemale poolele.

Kahe tabeli teemad – tellimused ja tooted – on mitu-mitmele seoses. See toob endaga kaasa probleemi. Probleemi olemuse mõistmiseks kujutlege, mis juhtub, kui prooviksite luua nende kahe tabeli vahel seose, lisades välja „Toote ID“ tabelisse „Tellimused“. Et ühes tellimuses saaks olla rohkem kui üks toode, on tabelis „Tellimused“ vaja iga tellimuse kohta rohkem kui ühte kirjet. See tähendab, et kordaksite andmeid igas reas, mis on seotud ühe tellimusega. Tulemuseks on ebaefektiivne konstruktsioon, mis võib viia andmete ebatäpsuseni. Sama probleemi otsa põrkate, kui lisate välja „Toote ID“ tabelisse „Tellimused“ – siis peaks teil olema tootetabelis iga toote kohta rohkem kui üks rida. Kuidas seda probleemi lahendada?

Tuleb luua kolmas tabel, mida sageli kutsutakse seostustabeliks ja mis tükeldab mitu-mitmele seose kaheks üks-mitmele seoseks. Kui lisate kummagi tabeli primaarvõtme kolmandasse tabelisse, talletab see kolmas tabel seose iga esinemiskorra.

Mitu-mitmele kontseptuaalskeem

Iga kirje tabelis „Tellimuse üksikasjad“ esindab ühte tellimuse reaüksust. Tabeli „Tellimuse üksikasjad“ primaarvõti koosneb kahest väljast – tabelite „Tellimused“ ja „Tooted“ võõrvõtmetest. Ainult välja „Tellimuse ID“ selle tabeli primaarvõtmena kasutada ei saa, kuna ühel tellimusel võib olla mitu reaüksust. Kuna väli „Tellimuse ID“ kordub tellimuse iga reaüksuse jaoks, ei sisalda see väli kordumatuid väärtusi. Ka ainult välja „Toote ID“ kasutamine ei õnnestu, sest üks toode võib sisalduda mitmes tellimuses. Kuid need kaks välja koos tagavad iga kirje jaoks kordumatu väärtuse.

Tootemüügi andmebaasis pole tabelid „Tellimused“ ja „Tooted“ teineteisega otseselt seotud. Selle asemel on nad teineteisega seotud kaudselt – tabeli „Tellimuse üksikasjad“ kaudu. Tellimuste ja toodete vaheline mitu-mitmele seos on andmebaasis esitatud kahe üks-mitmele seose kaudu.

  • Tabelitel „Tellimused“ ja „Tellimuse üksikasjad“ on üks-mitmele seos. Iga tellimus võib sisaldada rohkem kui ühte reaüksust, kuid iga rida on seotud vaid ühe tellimusega.

  • Tabelitel „Tooted“ ja „Tellimuse üksikasjad“ on üks-mitmele seos. Iga toode võib sisaldada rohkem kui ühte reaüksust, kuid iga rida on seotud vaid ühe tootega.

Tabelis „Tellimuse üksikasjad“ saate välja selgitada kõik konkreetsesse tellimusse kuuluvad tooted. Samuti saate leida kõik konkreetse toote tellimused.

Pärast tabeli „Tellimuse üksikasjad“ rakendamist võib tabelite ja väljade loend välja näha umbes järgmine.

Pilt, mis kujutab teabeüksusi kujundusprotsessi käigus


Lehe algusse

Üks-ühele seose loomine

Veel üks seosetüüp, millega peaksite end kurss viima, on üks-ühele seos. Oletagem näiteks, et teil on vaja salvestada erilist lisateavet, mida läheb vaja harva ja vaid üksikute toodete jaoks. Kuna seda teavet on vaja harva ja kuna selle salvestamine tabelis „Tooted“ tekitaks tühja välja iga seda mittevajava toote jaoks, tuleks see teave paigutada omaette tabelisse. Sarnaselt tabeliga „Tooted“ kasutate ka sel juhul primaarvõtmena tootenumbrit. Selle lisatabeli ja tabeli „Tooted“ vahel on üks-ühele seos. Iga tabelis „Tooted“ oleva kirje jaoks on lisatabelis ainult üks sobiv kirje. Kui tuvastate sellise seose, peab mõlemas tabelis olema üks ühine väli.

Kui märkate vajadust üks-ühele seose järele, mõelge, kas oleks võimalik andmeid neist kahest tabelist koondada ühte tabelisse. Kui te seda mingil põhjusel ei soovi (näiteks kuna selle tulemusena tekiks palju tühja ruumi), näitab järgmine loend, kuidas seost andmebaasi ülesehituses esitada.

  • Kui tabelitel on sama teema, saate seose tõenäoliselt tekitada mõlemas tabelis sama primaarvõtit kasutades.

  • Kui tabelitel on erinevad teemad ja erinevad primaarvõtmed, valige üks tabeleist (emb-kumb) ning lisage selle primaarvõti teise tabelisse võõrvõtmena.

Tabelitevaheliste seoste määratlemine aitab tagada, et teil on õiged tabelid ja veerud. Kui on olemas üks-ühele seos või üks-mitmele seos, peab asjakohastes tabelites olema ühine veerg või veerud. Kui on olemas mitu-mitmele seos, on seose esitamiseks vaja kolmandat tabelit.

Lehe algusse

Ülesehituse viimistlemine

Kui olete vajalikud tabelid, veerud ja seosed loonud, peaksite tabelid täitma näidisandmetega ning proovima andmetega töötada: päringuid looma, kirjeid lisama jne. See aitab välja tuua võimalikke probleeme – näiteks võib selguda, et teil tuleb lisada veel mõni veerg, mis jäi konstrueerimisfaasis kahe silma vahele, või tuleks mõni tabel dubleerimise vältimiseks kaheks jagada.

Proovige, kas saate andmebaasist vajalikke vastuseid. Looge vormide ja aruannete mustandid ning vaadake, kas need kajastavad oodatud andmeid. Otsige mittevajalikke andmete kordusi ja vajadusel muutke andmebaasi ülesehitust dubleeritud andmete kõrvaldamiseks.

Algandmebaasi testimisel avastate tõenäoliselt asju, mida saaks parandada. Tähelepanu võiksite pöörata näiteks järgmisele.

  • Kas olete mõne veeru unustanud? Kui jah, siis kas need andmed kuuluvad olemasolevatesse tabelitesse? Kui andmed käivad millegi muu kohta, peate võib-olla looma uue tabeli. Looge veerg iga asja jaoks, mida teil on vaja jälgida. Kui andmeid ei saa arvutada teiste veergude põhjal, siis on teil tõenäoliselt nende jaoks tarvis eraldi veergu.

  • Kas mõni veerg on üleliigne, kuna seda on võimalik arvutada olemasolevate veergude abil? Kui andmeid on võimalik arvutada olemasolevate veergude põhjal (nt hind pärast allahindlust), on sageli parem nii tehagi ja vältida lisaveeru loomist.

  • Kas sisestate mõnda tabelisse korduvalt duplikaatandmeid? Kui jah, siis on teil tõenäoliselt vaja tabel jagada kaheks üks-mitmele seosega tabeliks.

  • Kas teil on paljude väljadega ja piiratud kirjete arvuga tabeleid või paljude tühjade väljadega kirjeid? Kui jah, siis mõelge tabeli ümbertegemisele nii, et selles oleks vähem välju ja rohkem kirjeid.

  • Kas kõik andmed on jagatud vähimateks kasulikeks üksusteks? Kui teil on tarvis andmete alusel aruannet koostada või andmeid sortida, otsida või arvutada, kandke need andmed omaette veergu.

  • Kas iga veerg sisaldab tabeli teemaga seotud andmeid? Kui mitte, siis kuulub see veerg mõne muu tabeli juurde.

  • Kas kõik tabelitevahelised seosed on esindatud kas ühiste väljade või kolmanda tabeli kaudu? Üks-ühele ja üks-mitmele seosed nõuavad ühiseid veerge, mitu-mitmele seosed nõuavad kolmandat tabelit.

Tabeli „Tooted“ täpsustamine

Oletagem, et iga toode tootemüügi andmebaasis kuulub mõne üldkategooria alla – näiteks karastusjoogid, maitseained või mereannid. Tootetabelis võiks olla väli, mis näitab iga toote kategooriat.

Oletagem, et pärast andmebaasi analüüsimist ja selle ülesehituse täpsustamist otsustate talletada kategooria kirjelduse koos nimega. Kui lisate tabelisse „Tooted“ välja „Kategooria kirjeldus“, peate iga kategooria kirjeldust kordama iga selle kategooria toote korral. See pole hea lahendus.

Parem lahendus oleks luua kategooriad andmebaasi jaoks uue teemana, omaette tabeli ja omaette primaarvõtmega. Seejärel saaksite tabeli „Kategooriad“ primaarvõtme lisada tabelisse „Tooted“ võõrvõtmena.

Tabelite „Kategooriad“ ja „Tooted“ vahel on üks-mitmele seos: kategooria võib sisaldada mitut toodet, kuid toode võib kuuluda vaid ühte kategooriasse.

Tabelistruktuuride ülevaatamisel otsige korduvaid rühmi. Kujutage näiteks ette tabelit, milles on järgmised veerud.

  • Toote ID

  • Nimi

  • Toote ID 1

  • Nimi 1

  • Toote ID 2

  • Nimi 2

  • Toote ID 3

  • Nimi 3

Siin on iga toode korduv veerurühm, mis erineb teistest üksnes veerunime lõppu lisatud numbri poolest. Kui teil on niimoodi nummerdatud veerud, peaksite kujunduse üle vaatama.

Sellisel kujundusel on mitu viga. Esiteks piiritleb see kindlalt toodete arvu. Kohe, kui selle ületate, peate tabelisse lisama uue veerurühma, mis on aeganõudev haldustoiming.

Teine probleem on, et tarnijad, kellel on vähem kui maksimaalne arv tooteid, raiskavad ruumi, kuna lisaveerud on tühjad. Säärase kujunduse kõige tõsisem viga seisneb aga selles, et see raskendab paljude toimingute (nt toote ID või nime järgi sortimine või indekseerimine) tegemist.

Kui näete korduvaid rühmi, on õigem jaotada tabel kaheks tabeliks. Eeltoodud näites on mõistlik kasutada kahte tabelit: üht tarnijate ja teist toodete jaoks, mis on omavahel seotud tarnija ID kaudu.

Lehe algusse

Normeerimisreeglite rakendamine

Järgmise sammuna saate oma struktuurile rakendada andmete normeerimisreegleid (ehk lihtsalt normeerimisreegleid). Need aitavad teil kontrollida, kas tabelid on õigesti struktureeritud. Seda reeglite rakendamise toimingut kutsutakse andmebaasi normeerimiseks või ka lihtsalt normeerimiseks.

Normeerimine on kõige kasulikum pärast kõigi teabeüksuste esitamist ja eelstruktuuri valmimist. Selle mõte on aidata teil veenduda, et olete andmed jaganud sobivatesse tabelitesse. Normeerimine ei taga, et teil on olemas kõik vajalikud õiged andmed.

Võite reegleid rakendada järgemööda, iga sammuga veendudes, et teie andmebaasi ülesehitus vastab ühele vormindusreeglitest. Üldiselt tunnistatakse viit vormindusreeglit (ehk normaalvormingut), esimesest viiendani. Selles artiklis käsitletakse kolme esimest vormindusreeglit, kuna vaid need on enamiku andmebaasikujunduste juures nõutavad.

Esimene vormindusreegel

Esimene vormindusreegel nõuab, et tabelis oleks iga rea ja veeru ristumiskohas ainult üks väärtus, mitte kunagi väärtuste loend. Näiteks ei tohi teil olla välja nimega „Hind“, kuhu kantakse rohkem kui üks hind. Kui mõelda ridade ja veergude ristumiskohtadest kui lahtritest, tohib igas lahtris olla ainult üks väärtus.

Teine vormindusreegel

Teine vormindusreegel nõuab, et iga veerg, mis pole võtmeveerg, sõltuks täielikult primaarvõtmest kui tervikust, mitte üksnes primaarvõtme mõnest osast. See reegel kehtib siis, kui primaarvõti koosneb mitmest veerust. Oletagem, et teil on tabel järgmiste veergudega, kus primaarvõtme moodustavad veerud „Tellimuse ID“ ja „Toote ID“.

  • Tellimuse ID (primaarvõti)

  • Toote ID (primaarvõti)

  • Toote nimi

Selline struktuur on teise vormindusreegliga vastuolus, kuna „Toote nimi“ on sõltuv veerust „Toote ID“, kuid mitte veerust „Tellimuse ID“ ja seega ei sõltu see tervest primaarvõtmest. Peate veeru „Toote nimi“ tabelist eemaldama. See kuulub teise tabelisse (Tooted).

Kolmas vormindusreegel

Kolmas vormindusreegel nõuab lisaks sellele, et kõik veerud, mis pole võtmeveerud, sõltuksid tervest primaarvõtmest, ka seda, et mitte-võtmeveerud oleksid üksteisest sõltumatud.

See tähendab, et iga mitte-võtmeveerg peab olema sõltuv ainult primaarvõtmest, mitte millestki muust. Oletagem näiteks, et teil on tabel järgmiste veergudega.

  • Toote ID (primaarvõti)

  • Nimi

  • SJH

  • Allahindlus

Oletagem, et allahindlus sõltub soovitatavast jaehinnast (SJH). See tabel rikub kolmandat vormindusreeglit, kuna mitte-võtmeveerg „Allahindlus“ sõltub teisest mitte-võtmeveerust „SJH“. Veerusõltumatus tähendab, et suvalist mitte-võtmeveergu peaks saama muuta muid veerge mõjutamata. Kui muudate väärtust veerus „SJH“, muutuks vastavalt ka veerg „Allahindlus“, mis seega rikub reeglit. Antud näite korral tuleks „Allahindlus“ tõsta teise tabelisse, mis on võtme kaudu seotud väljaga „SJH“.

Lehe algusse

Täiendage Office'i kasutamise oskusi
Tutvuge koolitusmaterjalidega
Kasutage uusi funktsioone enne teisi
Liituge Office Insideri programmiga

Kas sellest teabest oli abi?

Täname tagasiside eest!

Täname tagasiside eest! Tundub, et võiksime teid kokku viia ühega meie Office'i tugiagentidest, kes aitab teil probleemi lahendada.

×