Pravilno oblikovana zbirka podatkov vam omogoča dostop do posodobljenih in točnih informacij. Pravilen načrt je bistvenega pomena za doseganje ciljev pri delu z zbirko podatkov, zato svetujemo, da vložite nekaj časa in preberete, katera so načela dobrega načrta. Na koncu je večja verjetnost, da boste ustvarili zbirko podatkov, ki ustreza vašim potrebam in jo lahko spreminjate.
V tem članku so opisane smernice za načrtovanje namizne zbirke podatkov. Spoznali boste, kako se odločite, katere informacije potrebujete, kako te informacije razdelite v ustrezne tabele in stolpce in kako so te tabele povezane med seboj. Ta članek preberite, preden ustvarite svojo prvo namizno zbirko podatkov.
V tem članku
Nekateri izrazi zbirk podatkov, ki jih je dobro vedeti
Access organizira podatke v tabele: sezname vrstic in stolpcev, ki spominjajo na računovodsko razpredelnico ali preglednico. V preprosti zbirki podatkov imate lahko le eno tabelo. V večini zbirk podatkov pa jih boste potrebovali več. Lahko imate na primer tabelo s podatki o izdelkih, tabelo s podatki o naročilih in tabelo s podatki o strankah.
Vsako vrstico pravilno imenujemo zapis, vsak stolpec pa je polje. Zapis je smiseln in dosleden način za združevanje podatkov o nečem. Polje je en element podatkov – vrsta elementa, ki se pojavi v vsakem zapisu. V tabeli izdelkov na primer vsaka vrstica ali zapis vsebuje podatke o enem izdelku. Vsak stolpec ali polje vsebuje določeno vrsto podatkov o tem izdelku, na primer njegovo ime ali ceno.
Kakšen je dober načrt za zbirko podatkov?
Za postopek oblikovanja zbirke podatkov veljajo določena načela. Prvo načelo je, da so podvojeni podatki (imenovani tudi odvečni podatki) slabi, saj zapravlja prostor in poveča verjetnost napak in nedoslednosti. Drugo načelo je, da sta pomembni pravilnost in celovitost podatkov. Če so v zbirki podatkov nepravilni podatki, bodo te nepravilne podatke vsebovala tudi vsa poročila, ki uporabljajo podatke iz zbirke podatkov. Posledično bodo vse odločitve, ki jih sprejmete na podlagi teh poročil, nepravilne.
Dober načrt zbirke podatkov je torej tisti, ki:
-
razporedi podatke v tabele glede na zadevo in s tem zmanjša količino odvečnih podatkov;
-
Accessu zagotovi informacije, ki jih potrebuje, da lahko podatke po potrebi združi v tabele;
-
podpira in zagotavlja točnost in celovitost podatkov;
-
se sklada z vašimi potrebami za obdelavo podatkov in poročanje o podatkih.
Postopek oblikovanja
Postopek oblikovanja sestavljajo ti koraki:
-
Določite namen zbirke podatkov
Tako se bolje pripravite na naslednje korake.
-
Poiščite in organizirajte potrebne podatke
Zberite vse vrste podatkov, ki jih boste želeli dodati v zbirko podatkov, na primer ime izdelka in številka naročila.
-
Razdelite podatke v tabele
Razdelite elemente podatkov v večje celote ali zadeve, kot so izdelki ali naročila. Vsaka zadeva postane tabela.
-
Pretvorite elemente podatkov v stolpce
Določite, katere podatke želite shraniti v posamezni tabeli. Vsak element postane polje in je prikazan kot stolpec v tabeli. Na primer tabela »Zaposleni« lahko vključuje polja, kot sta priimek in datum zaposlitve.
-
Določite primarne ključe
Izberite primarni ključ za vsako tabelo. Primarni ključ je stolpec, ki enolično določa vsako vrstico. Primer je lahko ID izdelka ali ID naročila.
-
Nastavite odnose tabel
Oglejte si vsako tabelo in določite, kako so podatki iz ene tabele povezani s podatki v drugih tabelah. Po potrebi v tabele dodajte polja ali pa ustvarite nove tabele, s katerimi razložite odnose.
-
Natančneje določite načrt
Preglejte, ali so v načrtu napake. Ustvarite tabele in dodajte nekaj zapisov z vzorčnimi podatki. Oglejte si, ali ste iz tabel dobili želene rezultate. Po potrebi prilagodite načrt.
-
Uporaba pravil normaliziranja
Uporabite pravila normaliziranja in si oglejte, ali imajo tabele ustrezno strukturo. Po potrebi prilagodite tabele.
Določanje namena zbirke podatkov
Dobro je, da si namen zbirke podatkov zabeležite na papir – njen namen, kako jo nameravate uporabljati in kdo jo bo uporabljal. Če gre za manjšo zbirko podatkov v domačem podjetju, morda lahko na primer napišete nekaj takšnega: »V zbirki podatkov strank je seznam podatkov o strankah, ki jih potrebujem za pošiljanje sporočil in poročil.« Če je zbirka podatkov bolj zapletena ali jo uporablja veliko ljudi, kot se pogosto zgodi v večjem podjetju, je lahko namen dolg cel odstavek ali več. Vanj napišite, kdaj in kako bodo posamezne osebe uporabljale zbirko podatkov. Tako boste imeli boljšo predstavo o namenu in izjavo, s katero si boste pomagali skozi postopek oblikovanja. S to izjavo se boste lažje osredotočili na cilje, ko boste sprejemali odločitve.
Iskanje in organiziranje zahtevanih podatkov
Če želite poiskati in organizirati potrebne podatke, začnite z obstoječimi podatki. Morda imate na primer naročilnice shranjene v glavni knjigi ali pa podatke o strankah hranite v papirnatih obrazcih v predalniku. Zberite te dokumente in navedite vsako vrsto prikazanih podatkov (na primer vsako polje, ki ga izpolnite v obrazcu). Če nimate obstoječih obrazcev, si lahko namesto tega predstavljate, da morate oblikovati obrazec za beleženje podatkov o strankah. Katere podatke bi želeli vnesti v obrazec? Katera polja za izpolnjevanje bi želeli ustvariti? Določite in navedite vse elemente. Recimo, da seznam strank trenutno hranite na indeksnih karticah. Ko pregledate te kartice, ugotovite, da je na vsaki ime stranke, naslov, kraj, država, poštna številka in telefonska številka. Vsak od teh elementov predstavlja morebitni stolpec v tabeli.
Ko pripravljate seznam, ne skrbite, če ni popoln. Najprej zapišite vsak element, ki vam pride na misel. Če bodo zbirko podatkov uporabljali tudi drugi, tudi njih prosite za zamisli. Seznam lahko pozneje natančneje prilagodite.
Nato razmislite o vrstah poročil ali sporočil, ki jih želite ustvariti na podlagi zbirke podatkov. Morda na primer želite, da poročilo o prodaji izdelka prikazuje prodajo po regijah ali da poročilo s povzetkom zaloge prikazuje količino zaloge izdelka. Morda boste želeli oblikovati tudi pisma, ki jih boste poslali strankah in jih obvestili o razprodaji ali posebni ponudbi. Oblikujte poročilo v mislih in si predstavljajte, kako bi bilo videti. Katere podatke bi želeli vnesti v poročilo? Navedite vse elemente. Enako naredite za pisma in ostala poročila, ki jih imate namen ustvariti.
Če že prej razmislite o poročilih in sporočilih, ki jih boste želeli ustvariti, boste lažje določili elemente, ki jih boste potrebovali v zbirki podatkov. Recimo, da strankam omogočite, da se prijavijo na ali odjavijo od prejemanja rednih e-poštnih sporočil, in želite natisniti seznam strank, ki so prijavljene na ta sporočila. Če želite zabeležiti te podatke, v tabelo strank dodate stolpec »Pošlji e-pošto«. Za vsako stranko lahko to polje nastavite na »Da« ali »Ne«.
Če boste strankam morali pošiljati e-poštna sporočila, boste morali dodati še en element. Ko veste, da stranka želi prejemati e-poštna sporočila, morate poznati tudi njen e-poštni naslov, kamor jih boste poslali. Torej boste morali zabeležiti e-poštni naslov za vsako stranko.
Smiselno je izdelati prototip vsakega poročila ali seznama izhodov in razmisliti o tem, katere elemente boste potrebovali za izdelavo poročila. Ko na primer pregledate oblikovno pismo, lahko pride na misel nekaj stvari. Če želite vključiti ustrezen pozdrav , na primer »G.«, »Ga.« ali »Ms«. Niz, ki začne pozdrav, boste morali ustvariti element pozdrava. Prav tako boste morda običajno začeli pismo z "Dragi gospod Smith", namesto "Dragi. Gospod Sylvester Smith. S tem predlagate, da želite običajno shraniti priimek ločeno od imena.
Ključna točka, ki jo morate upoštevati, je, da vsak del informacije razdelite na najmanjše smiselne dele. Če gre za celotno ime in želite, da je priimek takoj razviden, morate ta element razdeliti na dva dela – Ime in Priimek. Če želite poročilo shraniti glede na priimek, je na primer tudi koristno, če je priimek stranke shranjen ločeno. Na splošno velja, da morate vsak element, po katerem želite razvrščati, iskati, računati ali ustvariti poročilo, postaviti v svoje polje.
Razmislite, na katera vprašanja naj odgovori zbirka podatkov. Na primer koliko priporočenih izdelkov ste prodali prejšnji mesec? Kje živijo vaše najboljše stranke? Kdo je dobavitelj najbolje prodajanega izdelka? Če razmislite o teh vprašanjih, se boste lažje osredotočili na dodatne elemente, ki jih morate vključiti v zbirko podatkov.
Ko zberete vse te informacije, ste pripravljeni na naslednji korak.
Razdelitev podatkov v tabele
Če želite podatke razdeliti v tabele, izberite večje celote ali teme. Ko na primer poiščete in organizirate podatke za zbirko podatkov prodaje izdelka, bo začetni seznam morda videti takšen:
Tukaj so glavne celote izdelki, dobavitelji, stranke in naročila. Zato je smiselno, da začnete s temi štirimi tabelami: ena za dejstva o izdelkih, ena za dejstva o dobaviteljih, ena za dejstva o strankah in ena za dejstva o naročilih. Čeprav s tem seznam ni popoln, je dobro izhodišče. Seznam lahko natančneje določate, dokler ne dobite ustrezne oblike.
Ko prvič pregledate začetni seznam elementov, vas bo morda mikalo, da bi vse postavili v isto tabelo namesto v štiri, kot je prikazano na prejšnji sliki. Tukaj je razloženo, zakaj je to slaba zamisel. Za trenutek si oglejte to tabelo:
V vsaki vrstici so podatki o izdelku in dobavitelju. Ker ima toliko izdelkov istega dobavitelja, morata biti njegovo ime in naslov velikokrat ponovljena. To zapravlja prostor na disku. Veliko bolje je, da podatke o dobavitelju zabeležite le enkrat v ločeni tabeli dobaviteljev, nato pa to tabelo povežete s tabelo izdelkov.
Druga težava tega načrta se pojavi, ko želite spremeniti podatke o dobavitelju. Recimo, da na primer morate spremeniti naslov dobavitelja. Ker je zapisan na številnih mestih, ga boste morda pomotoma spremenili na enem mestu in pozabili spremeniti na drugih. Če naslov dobavitelja zabeležite le na enem mestu, je ta težava rešena.
Ko oblikujete zbirko podatkov, poskusite vsak zapis zabeležiti le enkrat. Če opazite, da morate isti podatek večkrat ponoviti, na primer naslov določenega dobavitelja, postavite te podatke v ločeno tabelo.
Na koncu pa si oglejmo še primer, ko na primer dobavitelj Vinogradništvo Trta dobavlja le en in ta izdelek želite izbrisati, vendar bi radi ohranili ime in naslov dobavitelja. Kako izbrišete zapis izdelka, ne da bi izgubili tudi podatke o dobavitelju? Ne morete. Vsak zapis vsebuje dejstva izdelku in o dobavitelju, zato ne morete izbrisati enega brez drugega. Če želite ta dejstva ločiti, morate tabelo razdeliti na dva dela: ena tabela je za podatke o izdelku, druga pa za podatke o dobavitelju. Če izbrišete zapis izdelka, bi se morala izbrisati le dejstva o izdelku in ne o dobavitelju.
Ko izberete zadevo tabele, naj bodo v njej le dejstva o tej zadevi. V tabeli izdelkov naj bodo le dejstva o izdelkih. Naslov dobavitelja je dejstvo o dobavitelju in ne o izdelku, zato sodi v tabelo dobaviteljev.
Pretvorba elementov podatkov v stolpce
Če želite določiti stolpce v tabeli, se odločite, katere podatke želite vključiti o zadevi, ki ji je tabela namenjena. Na primer v tabelo strank lahko za začetek vključite stolpce Ime, Naslov, Mesto/država/poštna številka, Pošlji e-pošto, Pozdrav in E-poštni naslov. Vsak zapis v tabeli vsebuje enak nabor stolpcev, zato lahko podatke o imenu, naslovu, mestu/državi/poštni številki, pošiljanju e-pošte, pozdravu in e-poštnem naslovu shranite za vsak zapis. V stolpcu Naslov so na primer naslovi strank. Vsak zapis vsebuje podatke o eni stranki, polje z naslovom pa vsebuje naslov te stranke.
Ko določite začetni nabor stolpcev za vsako tabelo, lahko podrobneje določite stolpce. Smiselno je na primer shraniti ime stranke kot dva ločena stolpca: ime in priimek, tako da lahko razvrstite, poiščete in indeksite le v teh stolpcih. Podobno je naslov dejansko sestavljen iz petih ločenih komponent, naslova, mesta, zvezne države, poštne številke in države/regije, smiselno pa jih je tudi shraniti v ločene stolpce. Če želite na primer izvesti iskanje, filtriranje ali razvrščanje po stanju, potrebujete podatke o stanju, shranjene v ločenem stolpcu.
Razmislite tudi, ali bodo v zbirki podatkov le domači naslovi ali tudi mednarodni. Če na primer nameravate shraniti mednarodne naslove, je dobro vključiti tudi stolpec z zvezno državo ali regijo, kamor lahko vnesete regije ali zvezne države v drugih državah. Podobno je namesto poštne številke bolje vključiti stolpec poštna šifra, če bodo v tabeli tudi mednarodni naslovi.
Na spodnjem seznamu je nekaj namigov za določanje stolpcev.
-
Ne vključite izračunanih podatkov
Načeloma je bolje, da v tabele ne shranjujete rezultatov izračunov. Namesto tega lahko v Accessu nastavite, da izvede izračune, ko želite videti rezultat. Recimo, da je v poročilu »Naročeni izdelki« prikazana vmesna vsota naročenih enot za vsako kategorijo izdelka v zbirki podatkov. Vendar v nobeni tabeli ni stolpca za vmesno vsoto naročenih enot. V tabeli »Izdelki« je le stolpec »Naročene enote«, v katerem je shranjeno število naročenih enot za vsak izdelek. S temi podatki Access izračuna vmesno vsoto vsakič, ko natisnete poročilo. Sama delna vsota pa naj ne bo shranjena v tabeli.
-
Shranite informacije v najmanjše logične dele
Morda boste želeli v isto polje shraniti ime in priimek ali pa ime izdelka skupaj z opisom. Če v istem polju združite več vrst podatkov, boste pozneje težje prišli do posameznih dejstev. Poskusite podatke razdeliti v logične dele; ustvarite na primer ločena polja za ime in priimek ali za ime izdelka, kategorijo in opis.
Ko natančneje določite stolpce podatkov v vseh tabelah, lahko zanje izberete primarne ključe.
Določanje primarnega ključa
V vsaki tabeli naj bo vključen stolpec ali nabor stolpcev, ki vsebuje enolično oznako za vsako vrstico v tabeli. Pogosto gre za enolično identifikacijsko številko, kot je na primer številka ID zaposlenega ali serijska številka. V terminologiji zbirke podatkov se ta podatek imenuje primarni ključ tabele. Access s polji s primarnim ključem hitro poveže podatke iz več tabel in jih združi namesto vas.
Če že imate enolični identifikator za tabelo, na primer številko izdelka, ki enolično določa vsak izdelek v katalogu, lahko uporabite ta identifikator kot primarni ključ v tabeli; vendar le, če bodo vrednosti v tem stolpcu vedno različne za vsak zapis. V stolpcu za primarni ključ ne sme biti podvojenih vrednosti. Za primarni ključ na primer ne uporabljajte imen oseb, ker imena niso enolična. Hitro se lahko zgodi, da boste v isti tabeli imeli dve osebi z istim imenom.
Primarni ključ mora vedno imeti vrednost. Če obstaja verjetnost, da vrednost stolpca v nekem trenutku postane nedodeljena ali neznana (manjkajoča vrednost), te vrednosti ni mogoče uporabiti kot primarni ključ.
Vedno izberite primarni ključ, katerega vrednost se ne bo spremenila. V zbirki podatkov z več tabelami je lahko primarni ključ tabele uporabljen kot sklic v drugih tabelah. Če se spremeni primarni ključ, se mora njegova vrednost spremeniti povsod, kjer obstaja sklic nanj. Uporabite primarni ključ, ki se ne bo spremenil, saj s tem zmanjšate možnost, da ne bo sinhroniziran z drugimi tabelami, ki se sklicujejo nanj.
Pogosto se za primarni ključ uporablja poljubna enolična številka. Vsakemu naročilu lahko na primer dodelite enolično številko naročila. Edini namen številke naročila je, da določa naročilo. Ko je dodeljena, se nikoli spremeni.
Če ne veste, kateri stolpec ali nabor stolpcev bi lahko uporabili za primarni ključ, lahko uporabite stolpec z vrsto podatkov »Samoštevilo«. Pri vrsti podatkov »Samoštevilo« Access samodejno dodeli vrednost. Ta identifikator je brez dejstev; ne vsebuje nobenega dejanskega podatka o vrstici, ki jo predstavlja. Identifikatorji brez dejstev so najbolj primerni za primarni ključ, ker se ne spremenijo. Primarni ključ, ki vsebuje dejstva o vrstici – na primer telefonska številka ali ime stranke, se bo mogoče spremenil, ker se bodo spremenili dejanski podatki o stranki.
1. Stolpec s podatkovnim tipom »Samoštevilo« predstavlja dober primarni ključ. Vsi ID-ji izdelkov se med seboj razlikujejo.
V nekaterih primerih lahko uporabite dva ali več polj, ki skupaj predstavljajo primarni ključ tabele. Na primer tabela »Podrobnosti naročila«, v kateri so shranjeni vrstični elementi za naročilo, lahko za primarni ključ uporablja dva stolpca: ID naročila in ID izdelka. Ko primarni ključ uporablja več stolpcev, se imenuje tudi sestavljeni ključ.
V zbirki podatkov s prodajo izdelkov lahko v vsaki tabeli ustvarite stolpec s samoštevilom, ki služi kot primarni ključ: IDizdelka za tabelo z izdelki, IDnaročila za tabelo z naročili, IDstranke za tabelo s strankami in IDdobavitelja za tabelo z dobavitelji.
Ustvarjanje odnosov tabele
Ko podatke razporedite v tabele, jih morate znova združiti na smiselne načine. Na spodnjem obrazcu so na primer podatki iz več tabel.
1. Podatki v tem obrazcu so iz tabele »Stranke«,
2. iz tabele »Zaposleni«,
3. iz tabele »Naročila«,
4. iz tabele »Izdelki«
5. in iz tabele »Podrobnosti o naročilu«.
Access je sistem za upravljanje relacijskih zbirk podatkov. V relacijski zbirki podatkov te podatke razdelite v ločene tabele glede na zadevo. Nato jih z odnosi tabel znova združite, tako kot želite.
Ustvarjanje odnosa »ena proti mnogo«
Oglejte si ta primer: tabeli »Dobavitelji« in »Izdelki« v zbirki podatkov z naročili izdelkov. Dobavitelj lahko dobavi poljubno število izdelkov. Torej so za vsakega dobavitelja, ki je naveden v tabeli dobaviteljev, lahko v tabeli izdelkov navedeni številni izdelki. Odnos med tabelo »Dobavitelji« in »Izdelki« je torej »ena proti mnogo«.
Če želite v načrtu zbirke podatkov predstaviti odnos »ena proti mnogo«, vzemite primarni ključ na strani »ena« v odnosu in ga dodajte kot dodatni stolpec v tabelo na strani »mnogo« v odnosu. V tem primeru stolpec »ID dobavitelja« iz tabele »Dobavitelji« dodamo v tabelo »Izdelki«. Access lahko uporabi številko ID dobavitelja v tabeli z izdelki, da poišče ustreznega dobavitelja za vsak izdelek.
Stolpec »ID dobavitelja« v tabeli »Izdelki« imenujemo tuji ključ. Tuji ključ je primarni ključ iz druge tabele. Stolpec »ID dobavitelja« v tabeli »Izdelki« je tuji ključ, ker je hkrati primarni ključ v tabeli »Dobavitelji«.
Ko uvedete pare primarnih in tujih ključev, s tem postavite osnovo za združevanje povezanih tabel. Če niste prepričani, katere tabele naj imajo skupni stolpec, najprej poiščite odnose »ena proti mnogo«; tako ugotovite, da morata tabeli v tem odnosu imeti skupni stolpec.
Ustvarjanje odnosa »mnogo proti mnogo«
Oglejte si odnos med tabelama »Izdelki« in »Naročila«.
Eno naročilo lahko vključuje več izdelkov. Po drugi strani se lahko isti izdelek pojavi v več naročilih. Torej vsakemu zapisu v tabeli »Naročila« lahko ustreza več zapisov v tabeli »Izdelki«. In vsakemu zapisu v tabeli »Izdelki« lahko ustreza več zapisov v tabeli »Naročila«. To vrsto odnosa imenujemo odnos »mnogo proti mnogo«, ker je za vsak izdelek lahko veliko naročil; in v vsakem naročilu je lahko več izdelkov. Če želite ugotoviti, katere tabele imajo odnos »mnogo proti mnogo«, upoštevajte obe strani odnosa.
Zadeve dveh tabel – naročila in izdelki – imajo odnos »mnogo proti mnogo«. To predstavlja težavo. Če želite razumeti težavo, si predstavljajte, kaj se zgodi, če ste poskusili ustvariti relacijo med dvema tabelama tako, da ste v tabelo »Naročila« dodali polje »ID izdelka«. Če želite imeti več kot en izdelek na naročilo, potrebujete več kot en zapis v tabeli »Naročila« na naročilo. Informacije o naročilu bi ponavljali za vsako vrstico, ki se nanaša na en vrstni red, kar bi privedlo do neučinkovitega načrta, ki bi lahko privedlo do netočnih podatkov. Na isto težavo naletite, če polje »ID naročila« vstavite v tabelo »Izdelki« – za vsak izdelek bi imeli v tabeli »Izdelki« več zapisov. Kako odpravite to težavo?
Rešitev je, da ustvarite tretjo tabelo, ki jo imenujemo tudi stična imena in ki odnos »mnogo proti mnogo« razdeli v dva odnosa »ena proti mnogo«. Primarni ključ iz obeh tabel vstavite v tretjo tabelo. V tretji tabeli je tako zabeležena vsaka ponovitev ali primerek odnosa.
Vsak zapis v tabeli »Podrobnosti naročila« predstavlja en vrstični element v naročilu. Primarni ključ tabele »Podrobnosti naročila« je sestavljen iz dveh polj – tujih ključev iz tabel »Naročila« in »Izdelki«. V tej tabeli za primarni ključ ne morete uporabiti polja »ID naročila«, ker je v enem naročilu lahko več vrstičnih elementov. ID naročila se ponovi za vsak vrstični element v naročilu, zato to polje ne vsebuje enoličnih vrednosti. Tudi uporaba samega polja »ID izdelka« ne bo ustrezna, saj se lahko en izdelek pojavi v več različnih naročilih. Toda obe polji skupaj vedno ustvarita enolično vrednost za vsak zapis.
V zbirki podatkov o prodaji izdelkov tabeli »Naročila« in »Izdelki« nista neposredno povezani med seboj. Povezani sta neposredno prek tabele »Podrobnosti naročila«. Odnos »mnogo proti mnogo« med naročili in izdelki je v zbirki podatkov predstavljen z dvema odnosoma »ena proti mnogo«:
-
Tabeli »Naročila« in »Podrobnosti naročila« imata odnos »ena proti mnogo«. V vsakem naročilu je lahko več vrstičnih elementov, vendar je vsak povezan le z enim naročilom.
-
Tabeli »Izdelki« in »Podrobnosti naročila« imata odnos »ena proti mnogo«. Vsak izdelek ima lahko veliko vrstičnih elementov, ki so povezani z njim, toda vsak vrstični element se nanaša le na en izdelek.
V tabeli »Podrobnosti naročila« lahko poiščete vse izdelke v določenem naročilu. Poiščete lahko tudi vsa naročila določenega izdelka.
Ko uredite tabelo »Podrobnosti naročila«, bo seznam tabel in polj videti približno tako:
Ustvarjanje odnosa »ena proti ena«
Druga vrsta relacije je relacija »ena proti ena«. Recimo, da morate zabeležiti nekatere posebne dodatne informacije o izdelku, ki jih boste potrebovali redko ali ki veljajo le za nekatere izdelke. Ker informacij ne potrebujete pogosto in ker bi shranjevanje informacij v tabeli »Izdelki« pomenil prazen prostor za vsak izdelek, za katerega ne velja, ga postavite v ločeno tabelo. Tako kot v tabeli »Izdelki« za primarni ključ uporabite tudi IDizdelka. Relacija med to dodatno tabelo in tabelo »Izdelek« je relacija »ena proti ena«. Za vsak zapis v tabeli »Izdelek« obstaja en ujemajoči se zapis v dodatni tabeli. Ko določite takšno relacijo, morata imeti obe tabeli skupno polje.
Ko ugotovite, da v svoji zbirki podatkov potrebujete odnos »ena proti ena«, najprej razmislite, ali lahko podatke iz obeh tabel združite skupaj v eni tabeli. Če tega iz katerega koli razloga ne želite narediti (morda ker bi to povzročilo veliko praznih polj), si pomagajte s spodnjimi nasveti, kako odnos prikažete v načrtu:
-
Če se tabeli nanašata na isto zadevo, verjetno lahko odnos ustvarite z istim primarnim ključem v obeh tabelah.
-
Če se tabeli nanašata na različni zadevi z različnimi primarnimi ključi, izberite eno od tabel (katero koli) in njen primarni ključ vstavite v drugo tabelo kot tuji ključ.
Ko določate odnose med tabelami, s tem pomagate zagotoviti, da imate ustrezne tabele in stolpce. Ko obstaja odnos »ena proti ena« ali »ena proti mnogo«, morajo tabele iz teh odnosov imeti skupen stolpec ali stolpce. Pri odnosu »mnogo proti mnogo« potrebujete tretjo tabelo, ki predstavlja odnos.
Natančnejše določanje načrta
Ko imate tabele, polja in relacije, ki jih potrebujete, ustvarite in izpolnite tabele z vzorčnimi podatki ter poskusite delati z informacijami: ustvarjanje poizvedb, dodajanje novih zapisov itn. S tem boste lažje označili morebitne težave, na primer, morda boste morali dodati stolpec, ki ste ga pozabili vstaviti med fazo načrtovanja, ali pa imate tabelo, ki jo morate razdeliti v dve tabeli, da odstranite podvajanje.
Preskusite, ali lahko z zbirko podatkov dobite želene odgovore. Ustvarite osnutke obrazcev in poročil in preverite, ali so v njih prikazani pričakovani podatki. Poiščite podvojene podatke in, če jih najdete, spremenite načrt tako, da jih ne bo več.
Med preskušanjem prve različice svoje zbirke podatkov boste verjetno odkrili stvari, ki bi jih lahko izboljšali. Priporočamo vam, da preverite te stvari:
-
Ali ste pozabili kakšen stolpec? Če ste ga, ali podatki za ta stolpec sodijo v obstoječe tabele? Če gre za podatke o nečem drugem, morda morate ustvariti še eno tabelo. Ustvarite stolpec za vsak element podatkov, ki jim morate slediti. Če podatkov ni mogoče izračunati iz drugih stolpcev, zanje verjetno potrebujete nov stolpec.
-
Ali kakšnega stolpca ne potrebujete, ker lahko njegove vrednosti izračunate iz drugih polj? Če lahko element podatkov izračunate iz drugih obstoječih stolpcev, na primer ceno s popustom izračunate iz redne prodajne cene, je bolje, da to naredite in se izognete dodatnemu stolpcu.
-
Ali v eno od tabel vedno znova vnašate ponavljajoče se podatke? V tem primeru je bolje, da to tabelo razdelite na dve tabeli z odnosom »ena proti mnogo«.
-
Ali imate tabele z veliko polji, omejenim številom zapisov in številnimi praznimi polji v posameznih zapisih? V tem primeru poskusite tabelo preoblikovati tako, da je v njej manj polj in več zapisov.
-
Ali je bil vsak element podatkov razdeljen na najmanjše uporabne dele? Če morate ustvariti poročilo, razvrstiti, iskati ali izračunati na podlagi določenega elementa podatkov, postavite ta podatek v ločen stolpec.
-
Ali vsak stolpec vsebuje dejstvo o zadevi tabele? Če v stolpcu ni podatkov o zadevi tabele, ta stolpec sodi v drugo tabelo.
-
Ali so vzpostavljeni vsi odnosi med tabelami – prek skupnih polj ali prek tretje tabele? V odnosih »ena proti ena« in »ena proti mnogo« potrebujete skupne stolpce. V odnosih »mnogo proti mnogo« potrebujete tretjo tabelo.
Natančnejše določanje tabele »Izdelki«
Predstavljajte si, da vsak izdelek v zbirki podatkov o prodaji izdelkov sodi v splošno kategorijo, na primer pijače, dodatki ali morska hrana. V tabelo »Izdelki« lahko vstavite polje s kategorijo posameznega izdelka.
Recimo, da se po pregledu in natančnejšem določanju načrta zbirke podatkov odločite, da boste poleg imena kategorije shranili tudi njen opis. Če v tabelo »Izdelki« dodate polje »Opis kategorije«, boste morali ponoviti opis posamezne kategorije za vsak izdelek, ki spada v to kategorijo – to pa ni dobra rešitev.
Boljša rešitev je, da kategorije postanejo nova zadeva, ki ji sledite z zbirko podatkov, in zanje ustvarite svojo tabelo in primarni ključ. Nato lahko primarni ključ iz tabele »Kategorije« dodate v tabelo »Izdelki« kot tuji ključ.
Med tabelama »Kategorije« in »Izdelki« je odnos »ena proti mnogo«: kategorija lahko vsebuje več izdelkov, vendar vsak izdelek lahko sodi le v eno kategorijo.
Ko pregledujete strukture tabel, pazite na ponavljajoče se skupine. Za primer vzemimo tabelo s temi stolpci:
-
ID izdelka
-
Ime
-
ID izdelka1
-
Ime1
-
ID izdelka2
-
Ime2
-
ID izdelka3
-
Ime3
Vsak izdelek predstavlja ponavljajočo se skupino stolpcev, ki se od drugih razlikujejo le po številki na koncu imena. Če vidite tako oštevilčene stolpce, poskusite preoblikovati načrt.
Takšen načrt ima več napak. Za začetek vas prisili, da postavite zgornjo mejo števila izdelkov. Ko dosežete to mejo, morate v strukturo tabele dodati novo skupino stolpcev, kar je obsežno administrativno opravilo.
Druga težava je, da se bo pri dobaviteljih, ki imajo manj izdelkov od največjega števila, pojavil prazen prostor, saj bodo dodatni stolpci prazni. Največja težava takšnega načrta pa je, da je težko opravljati nekatera opravila, na primer razvrščanje ali indeksiranje tabele glede na ID izdelka ali ime.
Vedno ko vidite ponavljajoče se skupine, dobro preglejte načrt in razmislite o razdelitvi tabele na dva dela. V zgornjem primeru je bolje uporabiti dve tabeli, eno za dobavitelje in eno za izdelke, ki sta povezani z ID-jem dobavitelja.
Uporaba pravil normaliziranja
Naslednji korak v načrtu je uporaba pravil za normaliziranje podatkov (imenovana tudi kar pravila normaliziranja). S temi pravili ugotovite, ali imajo tabele ustrezno strukturo. Postopek uporabe pravil v načrtu zbirke podatkov imenujemo normaliziranje zbirke podatkov ali samo normaliziranje.
Normaliziranje je najbolj uporabno, ko že določite vse elemente podatkov in ste prišli do osnovnega načrta. S tem postopkom zagotovite, da ste elemente podatkov razdelili v ustrezne tabele. Vendar z normaliziranjem ne morete ugotoviti, ali ste določili ustrezne elemente podatkov.
Pravila uporabite po vrsti in pri vsakem koraku zagotovite, da je načrt skladen z eno od »normalnih oblik«. Na splošno je sprejetih pet normalnih oblik – od prve do pete normalne oblike. V tem članku so razložene prve tri, saj večina načrtov zbirk podatkov potrebuje le te tri.
Prva normalna oblika
Prva normalna oblika navaja, da v vsakem presečišču vrstice in stolpca v tabeli obstaja le ena vrednost in nikoli seznam vrednosti. Na primer: ne morete imeti polja »Cena«, v katerega vnesete več cen. Če si vsako presečišče vrstic in stolpcev predstavljate kot celico, je lahko v vsaki celici le ena vrednost.
Druga normalna oblika
Druga normalna oblika zahteva, da je vsak stolpec, ki ni ključ, popolnoma odvisen od celotnega primarnega ključa in ne le od dela ključa. To pravilo velja, ko je primarni ključ sestavljen iz več kot enega stolpca. Predstavljajte si na primer, da so v tabeli naslednji stolpci, pri čemer ID naročila in ID izdelka skupaj tvorita primarni ključ:
-
ID naročila (primarni ključ)
-
ID izdelka (primarni ključ)
-
Ime izdelka
Ta načrt krši drugo normalno obliko, ker je ime izdelka odvisno od ID-ja izdelka, od ID-ja naročila pa ne; torej ime ni odvisno od celotnega primarnega ključa. Iz tabele odstranite ime izdelka. Sodi v drugo tabelo (Izdelki).
Tretja normalna oblika
Tretja normalna oblika ne zahteva le, da so vsi stolpci, ki niso ključ, odvisni od celotnega primarnega ključa, temveč zahteva tudi, da so neodvisni drug od drugega.
To torej pomeni, da mora biti vsak stolpec, ki ni ključ, odvisen le od primarnega ključa in od ničesar drugega. Za primer poglejmo tabelo s temi stolpci:
-
ID izdelka (primarni ključ)
-
Ime
-
PC
-
Popust
Predpostavimo, da je popust odvisen od priporočene cene (PC). Ta tabela krši tretjo normalno obliko, ker je stolpec, ki ni ključ (Popust), odvisen od drugega stolpca, ki ni ključ (CP). Neodvisnost stolpcev pomeni, da lahko spremenite kateri koli stolpec, ki ni ključ, in to ne vpliva na noben drug stolpec. Če spremenite vrednost v polju PC, se spremeni tudi vrednost popusta, zato kršite to pravilo. V tem primeru stolpec »Popust« premaknite v drugo tabelo, ki je vezana na PC.
