Andmebaasi kujunduse alused

Korralikult kujundatud andmebaas pakub ajakohast ja täpset teavet. Kuna korralik kujundus on andmebaasiga töötamisel eesmärkide saavutamiseks hädavajalik, tasub võtta aega hea kujunduse 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.

Selles artiklis tuuakse juhiseid töölaua andmebaasi planeerimiseks. Õpite otsustama, millist teavet teil vaja on, kuidas seda teavet jagada sobivateks tabeliteks ja veergudeks ning kuidas on need tabelid omavahel seotud. Enne oma esimese töölaua andmebaasi loomist peaksite selle artikli läbi lugema.

NB!: Microsoft Access 2010 pakub uut kujunduskogemust, mis võimaldab teil luua veebirakendusi. Veebi jaoks kujundust luues tuleb arvesse võtta muid asju. See artikkel ei käsitle veebiandmebaasirakenduste kujundust. Lisateavet leiate artiklist Veebis ühiskasutatava andmebaasi koostamine.

Selle artikli teemad

Andmebaasiterminid, mida tasub teada

Milline on hea andmebaasikujundus?

Kujundusprotsess

Andmebaasi otstarbe määratlemine

Vajaliku teabe leidmine ja korraldamine

Teabe tabeliteks jagamine

Teabeühikute teisendamine veergudeks

Primaarvõtmete määratlemine

Tabeli seoste loomine

Kujunduse viimistlemine

Normeerimisreeglite rakendamine


Andmebaasiterminid, mida tasub teada

Access 2010 korraldab teie teabe tabeliteks: ridade ja veergude loendiks, mis sarnaneb raamatupidamistabelile või arvutustabelile. Lihtsas andmebaasis võib olla ainult üks tabel, enamiku andmebaaside jaoks on vaja siiski mitut. Näiteks võib teil olla üks tabel tooteinfo, teine tabel tellimuste ja kolmas klientide kohta.

Pilt kolme tabeliga andmelehel

Täpsemalt kutsutakse igat rida kutsutakse kirjeks ning igat veergu väljaks. Kirje on mõistlik ja ühtlustatud viis koondada teavet millegi kohta. Väli on üks teabeühik – ühiku tüüp, mis on olemas igas kirjes. Näiteks tootetabelis vastab iga rida või kirje ühele tootele ning iga veerg või väli näitab teatud tüüpi teavet selle toote kohta, näiteks toote nime ja hinda.

Lehe algusesse

Milline on hea andmebaasikujundus?

Andmebaasi kujundamisel tuleb juhinduda kindlatest põhimõtetest. Esimeseks põhimõtteks on, et korduv teave (kutsutakse ka liigseks teabeks) on halb, kuna raiskab ruumi ning võib suurendada vigade arvu ning võimalikku mittekooskõlalisust. Teiseks põhimõtteks on, et teabe õigsus ja täielikkus on tähtis. 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 andmebaasikujunduse tundemärgid järgmised.

  • jagab teabe teemapõhistesse tabelitesse liigse teab vältimiseks,

  • pakub Accessile teavet, mida on vaja tabelites oleva teabe ühendamiseks,

  • aitab tagada teie teabe täpsust ja terviklikkust,

  • on kohandatav teie andmetöötlus- ja aruandevajadustele.

Lehe algusesse

Kujundusprotsess

Kujundusprotsess koosneb järgmistest etappidest.

  • Andmebaasi otstarbe määratlemine    

    See aitab valmistuda järgmiste juhiste jaoks.

  • Vajaliku teabe leidmine ja korraldamine     

    Koondage kogu teave, mida soovite andmebaasi salvestada, näiteks tootenimi ja -number.

  • Teabe tabeliteks jagamine    

    Jagage teabeühikud suuremates rühmadeks või teemadeks nagu Tooted või Tellimused. Igast teemast saab seejärel tabel.

  • Teabeühikute teisendamine veergudeks    

    Otsustage, millist teavet soovite igasse tabelisse talletada. Igast ühikust saab väli ning seda kuvatakse tabelis veeruna. Näiteks või tabel Töötajad sisaldada välju Perekonnanimi ja Tööleasumisaeg.

  • Primaarvõtmete määratlemine    

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

  • Tabelitevaheliste seoste määratlemine    

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

  • Kujunduse viimistlemine    

    Analüüsige oma tabeleid võimalike vigade leidmiseks. Looge tabelid ning lisage neisse näiteandmeid. Proovige tabeleist saada soovitud tulemeid. Kohandage vajadusel kujundust.

  • Rakendage normeerimisreegleid    

    Kontrollimaks, et tabelid on õigesti struktureeritud, rakendage normeerimisreegleid. Kohandage vajadusel kujundust.

Lehe algusesse

Andmebaasi otstarbe määratlemine

Kasulik on andmebaasi otstarve paberile kirja panna: selle eesmärk, oodatavad kasutusjuhud ning kes seda kasutama hakkab. Koduäri väikese andmebaasi jaoks võib kirjutada midagi lihtsat nagu "Klientide andmebaas tooteteavituste ning aruannete jaoks vajaliku kliendinimekirja hoidmiseks". Kui andmebaas on keerukam või seda kasutab rohkem inimesi nagu juhtub sageli ärikasutuses, võib eesmärk olla lõigupikkune 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 kujundusprotsessi käigus. Sõnastatud eesmärk aitab otsuste tegemisel sihil püsida.

Lehe algusesse

Vajaliku teabe leidmine ja korraldamine

Vajaliku teabe leidmiseks ja korraldamiseks alustage olemasolevast teabest. Võib-olla hoiate ostutellimusi pearaamatus või kliendiandmeid pabervormidel kaustas. Koguge need dokumendid kokku ja loetlege neis kasutatud teave tüübi järgi (nt vormil täidetavad väljad). Kui teil pole olemasolevaid vorme, kujutage ette, et soovite kujundada kliendiandmete hoidmiseks vormid. Millise teabe te vormile kannaksite? Milliseid täitelahtreid kasutaksite? Määratlege ja loetlege kõik sellised üksused. Oletame, 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 tabeli võimalikku veergu.

Loendi loomisel ärge muretsege selle koheselt ideaalseks saamise üle. Loetlege kõik, mis meenub. Kui andmebaasi hakkavad kasutama ka teised, küsige nende arvamust. Hiljem saate loendit parandada.

Järgmiseks võtke arvesse, milliseid aruandeid või saadetisi soovite andmebaasi põhjal luua. Võite näiteks soovida teha väljavõtteid müügist piirkonniti või laoseisust toodete laoseisu kaupa. Võite soovida luua klientidele saatmiseks vormkirju, et teavitada neid müügipakkumistest või teha eripakkumisi. Kujundage aruanne vaimusilmas valmis. Millised andmed peaksid aruandel olema? Loetlege kõik üksused. Tehke sedasama vormkirjade ning kõigi teiste aruannete jaoks, mida kavatsete luua.

Toote laoaruannet kujutlev isik

Võimalike aruannete ja saadetiste läbimõtlemine aitab määratleda andmebaasis vajalikke üksusi. Oletame, et soovite anda klientidele võimaluse kas liituda või lahti öelda regulaarsetest meilisõnumitest ning te sooviksite välja printida liitunud klientide loetelu. Selle teabe andmebaasi salvestamiseks peate andmebaasi klienditabelisse lisama veeru "Saada meil", kus iga kliendi korral seatakse selle väärtuseks kas Jah või Ei.

Nõue saata klientidele meilisõnumeid tingib veel ühe salvestamist vajava üksuse lisamise. Kui on teada, et klient soovib meili saada, on vaja teada ka meiliaadressi, millele see saata. Seega on vaja iga kliendi juurde salvestada 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 kirja analüüsides midagi pähe turgatada. Kui soovite kirja kaasata korrektset tervitusvormelit, näiteks tervitust alustavat stringi "Hr.", "Pr." või "Prl.", peate looma ka selle jaoks üksuse. Samuti võite soovida meili alustada sõnadega “Lugupeetud Hr. Sepp”, aga mitte “Lugupeetud Hr. Silver Sepp”. See eeldab, et perekonnanime tuleb talletada eesnimest eraldi.

Tähtis on meeles pidada, et iga teabeühik tuleks jagada vähimateks kasulikeks osadeks. Näiteks kui soovite, et nime korral oleks perekonnanimi hõlpsalt saadaval, peate nime jagama kaheks osaks, eesnimi ja perekonnanimi. Aruande sortimiseks perekonnanime järgi on hea, kui kliendi perekonnanimi on talletatud eraldi. Üldiselt tuleks kõik teave, mille järgi soovite sortida, otsida, arvutada või mille alusel aruannet koostada, asetada eraldi väljale.

Mõelge küsimustele, millele soovite, et andmebaasist vastuse saada. Näiteks kui mitu reklaamitud toote müügitellimust eelmisel kuul lõpule viidi? Kus elavad parimad kliendid? Kes on enimmüüdud toote tarnija? Nende küsimuste ettenägemine aitab keskenduda talletamist vajavatele lisaüksustele.

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

Lehe algusesse

Teabe tabeliteks jagamine

Teabe tabeliteks jagamiseks valige peamised olemid või teemad. Näiteks pärast esialgset tootemüügi andmebaasi jaoks vajaliku teabe leidmist 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 tekib hästi töötav kujundus.

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 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 kujundusega siis, kui peate tarnija andmeid muutma. Oletame, 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. Salvestades tarnija aadressi vaid ühte kohta, kõrvaldate selle probleemi.

Andmebaasi kujundamisel püüdke iga asja salvestada vaid korra. Kui tabate end sama teavet kordamas mitmes kohas, näiteks tarnija korral, asetage see teave eraldi tabelisse.

Lõpuks oletame, et Kõo veinikelder tarnib vaid ühte toodet ning soovite selle toote loendist kustutada, kuid säilitada tarnija nime ja aadressi. Kuidas kustutaksite toote kirje ilma tarnija kohta käiva teabe kaotamist? See pole võimalik. Kuna iga kirje sisaldab andmeid nii toote kui tarnija kohta, ei saa üht kustutada teiseta. Nende 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.

Kui olete valinud tabelina esitatava teema, peaksid tabeli veerud talletama andmeid ainult selle teema kohta. Näiteks peaks tootetabel sisaldama andmeid ainult toodete kohta. Kuna tarnija aadress on tarnija, aga mitte toote kohta käiv teave, kuulub see tarnijate tabelisse.

Lehe algusesse

Teabeühikute teisendamine veergudeks

Tabeli veergude tuvastamiseks otsustage, millist teavet tabelisse salvestatud asja kohta soovite jälgida. Näiteks on klientide tabelis hea alguspunkt luua veerud Nimi, Aadress, Linn-maakond-indeks, Saada meil, Tervitus ning Meiliaadress, et neid andmeid saaks salvestada iga kirje juurde. Aadressiveerg sisaldab näiteks 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 veergude komplekti, võite veerge veelgi täpsustada. Näiteks on mõistlik talletada kliendi nimi kahes veerus: eesnimi ja perekonnanimi. Siis on võimalik sortida, otsida ja indekseerida just neid veerge. Samuti koosneb aadress viiest erinevast osisest: aadress, linn, maakond, sihtnumber ja riik/piirkond ning needki on mõistlik paigutada eraldi 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 kodumaiseid või ka rahvusvahelisi andmeid. Näiteks peaks rahvusvaheliste andmete jaoks olema veeru Maakond asemel hoopis Piirkond, kuna sinna saaks salvestada nii kodumaiseid maakondi kui rahvusvahelisi või teiste riikide piirkondi. Samamoodi on rahvusvaheliste andmete salvestamisele mõeldes mõistlik teha pigem veerg sihtnumber, mitte Postiindeks.

Järgmine loend pakub vihjeid veergude väljaselgitamiseks.

  • Arvutatud andmeid ei tasu kaasata    

    Üldjuhul ei tasu arvutuste tulemusi tabeleisse salvestada. Selle asemel võib lasta Accessil arvutada siis, kui soovite näha tulemit. Oletame, et teil on aruanne Tellitud tooted, mis kuvab iga tootekategooria kohta tellitud toodete vahesumma. Sellegipoolest pole üheski tabelis veergu Tellitud tooted. Selle asemel sisaldab tootetabel veergu, milles on kirjas iga tootekategooria tellitud toodete arv. Nende andmete alusel arvutab Access vahesumma igal aruande printimiskorral. 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 ühele väljale mitut eri liiki teavet, on sellist hiljem raske välja tuua kindlaid fakte. Katsuge teave jagada loogilisteks osadeks, näiteks luua eraldi väljad ees- ja perekonnanimi või tootenime, -kategooria või -kirjelduse jaoks.

Kujundusprotsessi teabeüksuste loend

Kui olete tabeli andmeveerge täpsustanud, olete valmis looma primaarvõtit.

Lehe algusesse

Primaarvõtmete määratlemine

Iga tabel peaks sisaldama veergu või veergude komplekti, mis tuvastab kordumatult iga tabeli rida. See on sageli kordumatu 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 ning andmete koondamiseks.

Kui teil juba on tabelis unikaalne identifikaator nagu näiteks tootekood, mis on iga kataloogis oleva toote jaoks kordumatu, võite kasutada tabeli primaarvõtmena seda, kuid ainult siis, kui selle veeru väärtused on iga kirjega erinevad. Primaarvõtme väärtused ei tohi korduda. Ärge kasutage primaarvõtmena inimeste nimesid kuna need pole 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 kasutada primaarvõtmena.

Alati tuleb valida primaarvõti, mille väärtus ei muutu. Andmebaasis, milles on rohkem kui üks tabel, kasutatakse tabeli primaarvõtit muudes 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 sünkroonist välja muudes tabelites, mis sellele viitavad.

Sageli kasutakse primaarvõtmena suvalist kordumatut arvu. Näiteks võite igale tellimusele kinnistada kordumatu tellimusenumbri, mille ainsaks eesmärgiks on tellimust tuvastada. Kord kinnistatud, ei muutu see kunagi.

Kui te ei oska arvata, milline veerg või veerukomplekt oleks primaarvõtme jaoks sobiv, kaaluge selleks sellise veeru kasutamist, mille andmetüüp on Automaatnumber. 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. Primaarvõtme, mis sisaldab rea kohta andmeid (telefoninumbrit või kliendi nime) muutumine on tõenäolisem, sest sisuline teave ise võib muutuda.

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

1. Veerg andmetüübiga Automaatnumber sobib primaarvõtmeks hästi. Kahe toote koodid pole kunagi samad.

Mõnel juhul võite tahta kasutada tabeli primaarvõtme jaoks kahte või rohkemat välja. Näiteks tabeli Tellimuste üksikasjad, kus talletatakse tellimuste rea üksusi, kasutaks primaarvõtme jaoks 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õtmele 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 algusesse

Tabeli seoste loomine

Nüüd, kui olete andmed tabelitesse jaganud, on vaja need taas sisulisel moel koondada. Näiteks koondab järgmine vorm andmeid mitmest tabelist.

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 relatsiooniline andmebaasihaldussüsteem. Relatsioonilises andmebaasis jagatakse andmed eraldiseisvaisse temaatilistesse tabelitesse. Seejärel kasutatakse vajadusel andmete koondamiseks tabelite seoseid.

Lehe algusesse

Üks-mitmele seose loomine

Mõelge sellele näitele: Tarnijad ja Tooted on tabelid tootetellimuste andmebaasis. Tarnija võib tarnida suvalist arvu tooteid. Järelikult võib iga tabelis Tarnijad märgitud tarnija kohta olla palju tooteid tabelis Tooted. Tabelite Tarnijad ja Tooted vaheline seos on üks-mitmele.

Üks-mitmele kontseptuaalskeem

Andmebaasikujunduses üks-mitmele suhte esitamiseks võtke seose poolelt "üks" primaarvõti ning lisage see lisaveeruna või -veergudena tabelis poolel "mitmele". Selle näitega lisate tabeli Tarnija veeru Tarnija ID tabelile Tooted. Access saab siis tootetabelis kasutada iga tootja tarnija leidmiseks veergu Tarnija ID.

Tootetabeli 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 primaarvõtmeks tabelis Tarnijad.

Kujundusprotsessi teabeüksuste loend

Seotud tabelite liitmise aluseks on primaar- ja võõrvõtmete sidumine. Kui te pole kindel, millised tabelid peaksid ühist veergu jagama, siis aitab üks-mitmele seose väljaselgitamine tuvastada tabeleid, mis tegelikult nõuavad ühist veergu.

Lehe algusesse

Mitu-mitmele seose loomine

Mõelge tabelite Tooted ja Tellimused seosele.

Üksiktellimus võib sisaldada rohkem kui ühte toodet. Teisest küljest võib üks toode esineda paljudes tellimustes. Seega võib iga tabeli Tellimused kirje kohta olla tabelis Tooted mitu kirjet. Iga kirje jaoks tabelis Tooted võib olla mitu kirjet tabelis Tellimused. Seda tüüpi seost kutsutakse mitu-mitmele seoses, kuna iga toote jaoks võib olla mitu tellimust ning iga tellimuse jaoks mitu toodet. Pange tähele, et mitu-mitmele seoste märkamiseks on vaja mõelda seose mõlemale poolele.

Kahe tabeli teemad, tellimused ja tooted, on mitu-mitmele seoses. Sellest tekkiva probleemi mõistmiseks kujutage, mis juhtub, kui prooviksite luua nende kahe tabeli vahele seost lisades tabelile Tellimused välja Toote ID. Et ühe tellimuse kohta saaks olla rohkem kui üks toode, on tabelis Tellimused vaja rohkem kui ühte kirjet tellimuse kohta. Te kordaksite andmeid igas reas, mis viitab ühele tellimusele. Selle tulemuseks on ebaefektiivne kujundus, mis võib viia andmete ebatäpsuseni. Sama probleemi otsa põrkate, kui kannate 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 liigendab mitu-mitmele seose kaheks üks-mitmele seoseks. Lisades kummagi tabeli primaarvõtme kolmandasse tabelisse, talletab see tabel iga seose.

Mitu-mitmele seos

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

Tootemüügi andmebaasis ei ole tabelid Tellimused ja Tooted üksteisega otseselt seotud. Nad on seotud kaudselt läbi tabeli Tellimuse üksikasjad. Tellimuste ja toodete vaheline mitu-mitmele seos on andmebaasis esitatud kahe üks-mitmele seose kaudu.

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

  • Tabelid Tooted ja Tellimuse üksikasjad on üks-mitmele seoses. Iga toode võib sisaldada rohkem kui üht reaüksust, kuid iga rida on seotud vaid ühe tootega.

Tabelist Tellimuse üksikasjad saate määrata toodete kindla järjekorra. Samuti saate leida kõik konkreetse toote tellimused.

Pärast tabeli Tellimuse üksikasjad rakendamist võiks tabelite ja väljade loend välja näha umbes järgmiselt.

Kujundusprotsessi teabeüksuste loend


Lehe algusesse

Üks-ühele seose loomine

Lisaks on olemas üks-ühele seos. Oletame, et teil on vaja salvestada erilist lisateavet, mida läheb vaja harva ja vaid üksikute toodete juures. Kuna seda teavet on vaja harva ning kuna selle salvestamine tabelis Tooted tekitaks tühja välja iga seda mittevajava toote jaoks, asetate selle eraldi tabelisse. Nagu tabelis Tooted, kasutate primaarvõtmeks veergu Toote ID. Seos selle lisatabeli ja tabeli Tooted vahel on üks-ühele. Iga tabeli Tooted kirje jaoks on lisatabelis ainult üks sobiv kirje. Kui tuvastate sellise seose, peavad tabelid jagama ühte ühist välja.

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 kujunduses esitada.

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

  • Kui tabelitel on erinevad teemad erinevate primaarvõtmetega, valige üks tabeleist (emb-kumb) ning lisage selle primaarvõti teise tabeli võõrvõtmeks.

Tabelitevaheliste seoste määratlemine aitab tagada, et teil on õiged tabelid ja veerud. Kui on olemas üks-ühele seos või üks-mitmele seos, peavad kaasatud tabelid jagama ühist veergu või veerge. Kui on olemas mitu-mitmele seos, on vaja seose esitamiseks kolmandat tabelit.

Lehe algusesse

Kujunduse viimistlemine

Kui teil on olemas vajalikud tabelid, veerud ja seosed, peaksite tabelid täitma näiteandmetega ning proovima andmetega töötada: looma päringuid, lisama kirjeid jne. Nii toimimine aitab välja tuua võimalikke probleeme, näiteks võib osutuda vajalikuks veeru lisamine, mille olite kujundusfaasis unustanud, või teil on tabel, mis tuleb dubleerimise vältimiseks jagada kaheks.

Proovige, kas saate andmebaasist vajalikke vastuseid. Loote vormide ja aruannete mustandid ning vaadake, kas neis kajastuvad oodatud andmed. Otsige mittevajalikke andmete kordusi ning vajadusel muutke kujundust nende kõrvaldamiseks.

Esialgse andmebaasi testimisel avastate tõenäoliselt asju, mida saaks parandada. Järgmisena mõni asi, millele tähelepanu pöörata.

  • Kas unustasite mõne veeru? 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älitada. Kui andmeid ei saa arvutada muude veergude abil, siis on teil tõenäolisel 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 abil (nt hind peale 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 ümberkujundamisele nii, et selles oleks vähem välju ja rohkem kirjeid.

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

  • Kas iga veerg sisaldab andmeid tabeli teema kohta? 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 tabeliga? Üks-ühele ja üks-mitmele seosed nõuavad ühiseid veerge, mitu-mitmele seosed nõuavad kolmandat tabelit.

Tabeli Tooted viimistlemine

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

Oletame, et pärast andmebaasi analüüsimist ja viimistlemist otsustate talletada kategooria kirjelduse koos nimega. Kui lisate välja Kategooria kirjeldus tabelile Tooted, peate iga kategooria kirjeldust kordama iga selle kategooria toote korral. See pole hea lahendus.

Parem lahendus oleks luua kategooriad andmebaasi jaoks uue teemana, eraldi tabeli ja eraldi 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.

Tabelite struktuuride kontrollimisel otsige korduvaid rühmi. Näiteks kujutage ette tabelit, milles on järgmised veerud.

  • Toote ID

  • Nimi

  • Toote ID1

  • Nimi1

  • Toote ID2

  • Nimi2

  • Toote ID3

  • Nimi3

Siin kordab iga toode veergude rühma, mis erineb teistest vaid veerunimele lisandunud numbri poolest. Kui teil on niimoodi nimetatud veerud, peaksite kujunduse üle vaatama.

Sellisel kujundusel on mitu viga. Esiteks piiritleb see kindlalt toodete arvu. Niipea kui selle ületate, peate tabelisse lisama uue veerurühma, mis on mahukas 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 teeb paljude toimingute (nt Toote ID või nime järgi sortimine või indekseerimine) sooritamise raskeks.

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

Lehe algusesse

Normeerimisreeglite rakendamine

Järgmise sammuna saate oma kujundusele rakendada andmete normeerimisreegleid (vahel öeldakse lihtsalt normeerimisreeglid). Kasutage neid reeglid kontrollimaks, 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 andmete esitamist ja eelkujunduse valmimist. Selle mõte on aidata teid 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, veendudes iga toimingu juures, et teie kujundus vastab ühele normaalvormingule. Viis normaalvormingut on üldaktsepteeritud, esimesest kuni viienda normaalvorminguni. See artikkel selgitab esimest kolme, kuna vaid need on enamiku andmebaasikujunduste juures nõutavad.

Esimene normaalvorming

Esimene normaalvorming nõuab, et iga rea ja veeru ristumiskohal tabelis on vaid üks väärtus, mitte kunagi väärtuste loend. Näiteks ei tohi olla välja nimega Hind, kuhu kantakse rohkem kui üks Hind. Kui mõelda ridade ja veergude ristumiskohtadest kui lahtritest, siis peab igas lahtris olema ainult üks väärtus.

Teine normaalvorming

Teine normaalvorming nõuab, et iga mitte-võtmeveerg sõltuks täielikult kogu primaarvõtmest, mitte selle osast. See reegel on rakendatav siis, kui primaarvõti koosneb mitmest veerust. Oletagem, et teil on tabel järgmiste veergudega, milles primaarvõtmeks on väljad Tellimuse ID ja Toote ID.

  • Tellimuse ID (primaarvõti)

  • Toote ID (primaarvõti)

  • Toote nimi

Selline kujundus rikub teist normaalvormingut, kuna Toote nimi on sõltuv väljast Toote ID, kuid mitte väljast Tellimuse ID, sõltumata seega täielikust primaarvõtmest. Peate tabelist eemaldama välja Toote nimi, kuna see kuulub teise tabelisse (Tooted).

Kolmas normaalvorming

Kolmas normaalvorming nõuab, et mitte ainult iga mitte-võtmeveerg oleks sõltuv täielikust primaarvõtmest, vaid et mitte-võtmeveerud oleksid ka üksteisest sõltumatud.

Seega, et iga mitte-võtmeveerg peab olema sõltuv ainult primaarvõtmest. Oletame, et teil on tabel järgmiste veergudega.

  • Toote ID (primaarvõti)

  • Nimi

  • SJH

  • Allahindlus

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

Lehe algusesse

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.

×