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.
Selle artikli teemad
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.
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.
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.
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.
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.
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.
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 klientidele meilisõnumeid saata soovitab mõnda muud kirjet. Kui teate, et klient soovib meilisõnumeid vastu võtta, peate teadma ka meiliaadressi, kuhu ta saata. Seetõttu peate salvestama iga kliendi meiliaadressi.
Mõistlik on koostada iga aruande või väljundikirje prototüüp ja kaaluda, milliseid üksusi aruande koostamiseks vaja läheb. Näiteks vormikirja analüüsimisel võivad mõned asjad meeles pidada. Kui soovite lisada õige tervituse – näiteks string "Hr", "Proua", "Pr", või "Ms", mis alustab tervitust, peate looma tervitusüksuse. Samuti võite tavaliselt alustada kirjaga "Lugupeetud härra Smith", mitte "Kallis." Härra Sylvester Smith". See viitab sellele, et tavaliselt soovite talletada perekonnanime 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.
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:
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:
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.
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 iga tabeli jaoks määranud algse veerukogumi, saate veerge täpsemalt piiritleda. Näiteks on mõistlik talletada kliendi nimi kahe eraldi veeruna: ees- ja perekonnanimena, et saaksite sortida, otsida ja indekseerida ainult nende veergude järgi. Samamoodi koosneb aadress tegelikult viiest eraldi komponendist, aadressist, linnast, osariigist, sihtnumbrist ja riigist/regioonist ning samuti on mõistlik need salvestada eraldi veergudesse. Kui soovite näiteks otsida, filtreerida või sortida oleku järgi, on teil vaja eraldi veergu talletatud olekuteavet.
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.
Kui olete tabeli andmeveerud täpsustanud, oletegi valmis valima iga tabeli jaoks primaarvõtme.
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 kasutatakse primaarvõtmena suvalist kordumatut numbrit. Näiteks võite igale tellimusele määrata kordumatu tellimuse numbri. Tellimuse numbri ainus otstarve on tellimuse tuvastamine. Kui see on määratud, ei muutu see kunagi.
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.
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.
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.
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.
Ü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.
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.
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.
Mitu-mitmele seose loomine
Mõelge tabelite „Tooted“ ja „Tellimused“ seosele.
Üks tellimus võib sisaldada mitut toodet. Teisest küljest võidakse üks toode kuvada ka paljudes tellimustes. Seetõttu võib tabeli Tellimused iga kirje kohta olla tabelis Tooted mitu kirjet. Tabeli Tooted iga kirje kohta võib tabelis Tellimused olla palju kirjeid. Seda tüüpi seost nimetatakse mitu-mitmele seoseks, kuna mis tahes toote puhul võib olla mitu tellimust; ja mis tahes tellimuse puhul võib olla palju tooteid. Pange tähele, et tabelitevaheliste mitu-mitmele seoste tuvastamiseks on oluline arvestada seose mõlemat poolt.
Kahe tabeli teemad – tellimused ja tooted – on seotud mitu-mitmele. See kujutab endast probleemi. Probleemi mõistmiseks kujutlege, mis juhtub, kui proovite luua kahe tabeli vahelist seost, lisades tabelisse Tellimused välja Toote ID. Kui soovite, et tellimuse kohta oleks rohkem kui üks toode, vajate tabelis Tellimused tellimuse kohta rohkem kui ühte kirjet. Korrate järjestuse teavet iga üksiku tellimusega seotud rea kohta– selle tulemuseks on ebaefektiivne kujundus, mis võib põhjustada ebatäpseid andmeid. Sama probleem tekib ka siis, kui lisate välja Tellimuse ID tabelisse Tooted – iga toote kohta on tabelis Tooted mitu kirjet. Kuidas seda probleemi lahendada?
Vastus on luua kolmas tabel, mida sageli nimetatakse sõlmtabeliks, mis jagab mitu-mitmele seose kaheks üks-mitmele seoseks. Lisage mõlema tabeli primaarvõti kolmandasse tabelisse. Selle tulemusena salvestab kolmas tabel seose iga esinemiskorra või eksemplari.
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.
Ü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.
Ü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 esitatud kas ühiste väljade või kolmanda tabelina? Ü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 kujunduse uurimist ja täpsustamist otsustate salvestada kategooria kirjelduse koos selle nimega. Kui lisate tabelisse Tooted välja Kategooria kirjeldus, tuleb korrata iga kategooria kirjeldust iga kategooria alla kuuluva toote kohta – 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.
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“.
