Pretraživanje čitava lokacija Office.com
 
Podrška / Access / Pomoć i članci „Kako da...“ za Access 2010 / Osnove programa Access
 
 

Osnove dizajniranja baze podataka

Primenljivo na: Microsoft Access 2010

 

Ispravno dizajnirana baza podataka vam omogućava pristup ažurnim i tačnim informacijama. Pošto je ispravan dizajn od suštinske važnosti za postizanje ciljeva u radu sa bazom podataka, ulaganje vremena u sticanje znanja o principima dobrog dizajna ima smisla. Na kraju krajeva, u tom slučaju mnogo je veća verovatnoća da ćete dobiti bazu podataka koja odgovara vašim potrebama i koja na jednostavan način može da se menja.

Ovaj članak sadrži uputstva o planiranju baze podataka na stonom računaru. Saznaćete kako da odlučite koje su vam informacije potrebne, kako da te informacije rasporedite u odgovarajuće tabele i kolone, kao i na koji način se povezuju te tabele. Ovaj članak bi trebalo da pročitate pre nego što prvi put kreirate bazu podataka na stonom računaru.

 Važno   Microsoft Access 2010 obezbeđuje novi utisak pri dizajniranju koji vam omogućava da kreirate aplikacije za baze podataka za Veb. Mnoge stavke dizajna razlikuju se kada dizajnirate za Veb. Ovaj članak ne govori o dizajnu aplikacija za Veb baze podataka. Više informacija potražite u članku Pravljenje baze podataka za deljenje na Vebu.

U ovom članku


Neki termini baze podataka koje bi trebalo da znate

Access 2010 organizuje informacije u tabele: liste redova i kolona koje podsećaju na notes računovođe ili unakrsnu tabelu. U jednostavnoj bazi podataka možete imati samo jednu tabelu. Za većinu baza podataka biće vam potrebno više od jedne tabele. Na primer, možda ćete imati jednu tabelu za skladištenje informacija o proizvodima, drugu tabelu za skladištenje informacija o porudžbinama i još jednu sa informacijama o kupcima.

Na slici su prikazane tri tabele u listovima sa podacima

Svaki red se pravilnije zove zapis, a svaka kolona polje. Zapis predstavlja kombinovanje informacija o nečemu na smislen i dosledan način. Polje je pojedinačna stavka informacije – tip stavke koji se pojavljuje u svakom zapisu. U tabeli „Proizvodi“, na primer, svaki red ili zapis sadrži informacije o jednom proizvodu. Svaka kolona ili polje ima isti tip informacija o tom proizvodu, na primer njegovo ime ili cenu.

Vrh stranice Vrh stranice

Šta se podrazumeva pod dobrim dizajnom baze podataka?

Procesom dizajniranja baze podataka upravljaju određeni principi. Prvi princip je da su duplirane informacije (koje se nazivaju i redundantni podaci) loša pojava, jer nepotrebno zauzimaju prostor i povećavaju verovatnoću pojave grešaka i nedoslednosti. Drugi princip ističe važnost ispravnosti i potpunosti informacija. Ako baza podataka sadrži neispravne informacije, izveštaji koji izvlače informacije iz baze podataka će takođe sadržati neispravne informacije. Kao posledica toga, donete odluke koje su zasnovane na tim izveštajima će u osnovi sadržati pogrešne informacije.

Dakle, pod dobrim dizajnom baze podataka podrazumeva se sledeće:

  • Informacije treba da budu raspoređene u tematski zasnovane tabele u cilju smanjivanja broja suvišnih podataka.
  • Programu Access treba da se obezbede informacije neophodne za spajanje informacija u tabelama kada je to potrebno.
  • Dizajn treba da podržava i obezbeđuje tačnost i integritet informacija.
  • Potrebno je da dizajn odgovara na vaše potrebe u vezi sa obradom podataka i izveštavanjem.

Vrh stranice Vrh stranice

Proces dizajniranja

Proces dizajniranja se sastoji iz sledećih koraka:

  • Određivanje namene baze podataka    

Ovaj korak doprinosi pripremi za preostale korake.

  • Pronalaženje i organizovanje potrebnih informacija     

Sakupite sve tipove informacija koje ćete možda želeli da zapišete u bazu podataka, poput imena proizvoda i broja porudžbine.

  • Raspoređivanje informacija u tabele    

Rasporedite stavke informacija po glavnim entitetima ili temama, kao što su „Proizvodi“ ili „Porudžbine“. Na taj način svaka tema će postati tabela.

  • Pretvaranje stavki informacija u kolone    

Odlučite koje informacije želite da uskladištite u svaku tabelu. Svaka stavka će postati polje i prikazaće se kao kolona u tabeli. Na primer, tabela „Zaposleni“ bi mogla da sadrži polja poput „Prezime“ i „Datum zapošljavanja“.

  • Određivanje primarnih ključeva    

Odaberite primarni ključ za svaku tabelu. Primarni ključ predstavlja kolonu koja se koristi da jedinstveno identifikuje svaki red, na primer „ID proizvoda“ ili „ID porudžbine“.

  • Podešavanje relacija između tabela    

Razmotrite svaku tabelu i odlučite na koji način će podaci iz jedne tabele biti povezani sa podacima u drugoj tabeli. Dodajte polja u tabele ili kreirajte nove tabele kako biste, po potrebi, objasnili relacije.

  • Pročišćavanje dizajna    

Analizirajte dizajn radi pronalaženja grešaka. Kreirajte tabele i dodajte nekoliko zapisa sa probnim podacima. Proverite da li iz tabela možete da dobijete željene rezultate. Po potrebi podesite dizajn.

  • Primenjivanje pravila normalizacije    

Primenite pravila normalizacije podataka kako biste videli da li su tabele ispravno strukturirane. Po potrebi podesite tabele.

Vrh stranice Vrh stranice

Određivanje namene baze podataka

Preporučuje se da zapišete namenu baze podataka na papir – samu namenu, način na koji planirate da je koristite, kao i ko će je koristiti. Na primer, za malu bazu podataka za posao koji radite kod kuće mogli biste da zapišete nešto jednostavno poput „Baza podataka kupaca sadrži listu informacija o kupcima sa namenom kreiranja pošiljki i izveštaja“. Ako je baza podataka složenija ili je koristi veći broj ljudi, što se često dešava u poslovnom okruženju, opis namene bi mogao da zauzme jedan ili više pasusa, a trebalo bi takođe da sadrži vreme kada će i način na koji će svaka osoba koristiti tu bazu podataka. Potrebno je da postoji precizno definisan cilj zadatka koji ćete moći da uzmete u obzir tokom čitavog procesa dizajniranja. Postojanje tako definisanog cilja vam pomaže da se pri donošenju odluka usredsredite na ciljeve.

Vrh stranice Vrh stranice

Pronalaženje i organizovanje potrebnih informacija

Da biste pronašli i organizovali potrebne informacije, počnite od postojećih informacija. Na primer, možda izlazne porudžbine zapisujete u registrator ili informacije o kupcima čuvate na papirnim obrascima u arhivi. Sakupite te dokumente i navedite sve prikazane tipove informacija (na primer, svako polje koje popunjavate u obrascu). Ako nemate postojeće obrasce, zamislite da morate da dizajnirate obrazac kako biste zapisali informacije o kupcima. Koje informacije biste uneli u obrazac? Koja polja za popunjavanje biste kreirali? Identifikujte i navedite sve te stavke. Na primer, pretpostavite da trenutno listu kupaca čuvate na karticama za indeksiranje. Pregledanje ovih kartica bi moglo da pokaže da svaka kartica sadrži ime, adresu, grad, državu, poštanski broj i broj telefona kupca. Svaka od ovih stavki predstavlja potencijalnu kolonu u tabeli.

Dok pripremate listu, nemojte se truditi da ona odmah bude savršena, već navedite svaku stavku koje se setite. Ako će još neke osobe koristiti bazu podataka, i njih upitajte za ideje. Kasnije možete da preciznije podesite listu.

Nakon toga razmotrite tipove izveštaja i pošiljki koje ćete možda želeti da kreirate na osnovu baze podataka. Na primer, možda biste želeli da kreirate izveštaj o prodaji proizvoda koji će prodaju prikazivati po regionu ili izveštaj sa rezimeom zaliha koji prikazuje nivoe zaliha proizvoda. Možda biste želeli da generišete i tipska pisma koja ćete slati kupcima najavljujući prodajni događaj ili nudeći premiju. Dizajnirajte izveštaj u glavi i zamislite kako će izgledati. Koje informacije biste obuhvatili izveštajem? Navedite svaku stavku. To isto učinite za tipsko pismo, kao i za svaki drugi izveštaj čije kreiranje planirate.

Osoba zamišlja izveštaj o zalihama proizvoda

Razmišljanje o izveštajima i pošiljkama koje biste želeli da kreirate pomaže vam da identifikujete stavke koje će vam biti potrebne u bazi podataka. Na primer, pretpostavimo da ste kupcima omogućili da daju (ili odbiju) saglasnost za periodične ispravke koje se šalju putem e-pošte i da želite da odštampate listu onih koji su dali saglasnost. U tabelu sa kupcima dodajte kolonu „Slanje e-pošte“ da biste zapisali te informacije. Polje za svakog kupca možete da postavite na vrednost „Da“ ili „Ne“.

Potreba da se kupcima šalju e-poruke podrazumeva još jednu stavku koju je potrebno zapisati. Kada saznate da kupac želi da prima e-poruke, moraćete da znate i e-adresu na koju ćete ih poslati. Stoga je potrebno da zapišete e-adresu svakog kupca.

Ima smisla kreirati prototip svakog izveštaja ili izlazne liste i razmotriti koje stavke će biti potrebne za kreiranje izveštaja. Na primer, kada pregledate tipsko pismo, prisetićete se nekoliko stvari. Ako želite da uključite odgovarajuće oslovljavanje – na primer, nisku „g.“, „gđa“ ili „gđica“ kojom započinje pozdrav, moraćete da kreirate i stavku oslovljavanja. Osim toga, mogli biste da pismo započnete na uobičajen način sa „Poštovani g. Savić“, a ne „Poštovani g. Svetozar Savić“. Ovo bi značilo da vi, u principu, želite da prezime uskladištite odvojeno od imena.

Ključna stvar koju bi trebalo da imate u vidu je da svaku informaciju treba da raščlanite na najmanje korisne delove. Kad su u pitanju imena, puno ime podelite na dva dela – ime i prezime, kako bi prezime bilo odmah dostupno. Odvojeno skladištenje prezimena kupaca može da bude korisno ako, na primer, izveštaj želite da sortirate po prezimenu. Uopšte uzev, ako želite da sortirate, pretražujete, izračunavate ili izveštavate na osnovu neke stavke sa informacijama, trebalo bi da tu stavku smestite u posebno polje.

Razmislite o pitanjima na koja možda želite da baza podataka pruži odgovor. Na primer, koliko ste prodaja preporučenog proizvoda zaključili prošlog meseca? Gde žive vaši najvažniji kupci? Ko je dobavljač vašeg najprodavanijeg proizvoda? Ukoliko predvidite ove odgovore, bićete u mogućnosti da se usredsredite na dodatne stavke koje treba da zapišete.

Posle sakupljanja ovih informacija spremni ste za sledeći korak.

Vrh stranice Vrh stranice

Raspoređivanje informacija u tabele

Odaberite glavne entitete ili teme kako biste informacije rasporedili u tabele. Na primer, pošto pronađete i organizujete informacije za bazu podataka prodaje proizvoda, preliminarna lista bi mogla da izgleda ovako:

Tematski grupisane stavke informacija pisane rukom

Glavni entiteti koje su ovde prikazani su proizvodi, dobavljači, kupci i porudžbine. Stoga, kreiranje ima smisla početi sa ove četiri tabele: jedna je za činjenice o proizvodima, druga za činjenice o dobavljačima, treća za činjenice o kupcima, a četvrta za činjenice o porudžbinama. Iako ovim lista nije dovršena, to je dobar početak. Možete da nastavite s pročišćavanjem ove liste sve dok ne dobijete dizajn koji dobro funkcioniše.

Kada prvi put budete redigovali preliminarnu listu stavki, možda ćete poželeti da ih smestite u jednu tabelu, umesto u četiri koje su prikazane na prethodnoj slici. Sada ćete saznati zašto bi to bilo loše. Nakratko razmotrite tabelu koja je ovde prikazana:

Na slici je prikazana tabela koja sadrži proizvode i dobavljače

U ovom slučaju, svaki red sadrži informacije i o proizvodima i o dobavljačima. Pošto možete imati veliki broj proizvoda od istog dobavljača, informacije o imenu dobavljača i njegovoj adresi moraju se ponoviti više puta. Na taj način se zauzima nepotreban prostor na disku. Mnogo je bolja opcija da samo jednom zapišete informacije o dobavljaču u odvojenu tabelu „Dobavljači“, a zatim je povežete sa tabelom „Proizvodi“.

Drugi problem sa dizajnom u ovom slučaju javlja se kada je potrebno da izmenite informacije o dobavljaču. Na primer, pretpostavimo da treba da promenite adresu dobavljača. Pošto se ona pojavljuje na mnogo mesta, može da se desi da slučajno promenite adresu na jednom mestu, a da zaboravite da je promenite na ostalim mestima. Zapisivanje adrese dobavljača na samo jednom mestu rešava taj problem.

Kada dizajnirate bazu podataka, uvek pokušajte da svaku činjenicu zapišete samo jednom. Ako je potrebno da istu informaciju, poput adrese određenog dobavljača, ponavljate na više mesta, smestite tu informaciju u odvojenu tabelu.

Na kraju, pretpostavimo da postoji samo jedan proizvod vinarije „Coho Winery“, a vi želite da ga izbrišete bez gubljenja informacija o imenu i adresi dobavljača. Kako ćete izbrisati zapis o proizvodu, a da pri tome ne izgubite i informacije o dobavljaču? To nije moguće. Pošto svaki zapis sadrži činjenice o proizvodu, kao i činjenice o dobavljaču, ne možete da izbrišete jedno, a da ne izbrišete i drugo. Da biste ove činjenice čuvali odvojeno, tabelu morate podeliti na dva dela: jedna tabela služi za informacije o proizvodu, a druga za informacije o dobavljačima. Brisanje zapisa o proizvodu bi trebalo da izbriše činjenice o proizvodu, a ne i činjenice o dobavljaču.

Kada odaberete temu za tabelu, kolone u toj tabeli bi trebalo da skladište samo činjenice o temi. Na primer, tabela proizvoda bi trebalo da skladišti samo činjenice o proizvodima. Pošto je adresa dobavljača činjenica o dobavljaču, a ne činjenica o proizvodu, ona pripada tabeli o dobavljačima.

Vrh stranice Vrh stranice

Pretvaranje stavki informacija u kolone

Odlučite koje informacije treba da pratite u vezi sa temom zapisanom u tabeli kako biste odredili kolone u tabeli. Na primer, kolone „Ime“, „Adresa“, „Grad-država-poštanski broj“, „Slanje e-pošte“, „Oslovljavanje“ i „E-adresa“ predstavljaju dobru početnu listu kolona za tabelu „Kupci“. Svaki zapis u tabeli sadrži isti skup kolona tako da za svaki zapis možete da uskladištite informacije o imenu, adresi, gradu-državi-poštanskom broju, slanju e-pošte, oslovljavanju i e-adresi. Na primer, kolona sa adresama sadrži adrese kupaca. Svaki zapis obuhvata podatke o jednom kupcu, a polje za adresu sadrži adresu tog kupca.

Nakon što odredite početni skup kolona za svaku tabelu, kolone možete dodatno da pročistite. Na primer, dobro je uskladištiti puno ime kupca u dve odvojene kolone – ime i prezime, kako biste mogli da sortirate, pretražujete i indeksirate samo prema ovim kolonama. Slično tome, adresa se u stvari sastoji od pet odvojenih komponenti – adrese, grada, države, poštanskog broja i zemlje/regiona, koje je korisno uskladištiti u odvojene kolone. Na primer, ako želite da izvršite operaciju pretraživanja, filtriranja ili sortiranja po državi, potrebna vam je informacija o državi koja je uskladištena u odvojenoj koloni.

Trebalo bi da razmotrite da li će baza podataka sadržati informacije samo domaćeg porekla ili i međunarodnog. Na primer, ako planirate da skladištite međunarodne adrese, bolje je umesto kolone „Država“ imati kolonu „Region“ jer takva kolona može da prihvati i domaće države, kao i regione drugih zemalja/regiona. Slično tome, kolona „Poštanski broj“ ima više smisla nego kolona „Poštanski broj – Srbija“ ako ćete skladištiti međunarodne adrese.

Sledeća lista sadrži nekoliko saveta za određivanje kolona.

  • Ne uključujte izračunate podatke    

U većini slučajeva, rezultat računskih operacija ne bi trebalo da skladištite u tabele. Umesto toga, Access može da izvršava računske operacije kada vi želite da vidite odgovarajući rezultat. Na primer, pretpostavimo da postoji izveštaj „Proizvodi u porudžbini“ koji prikazuje podzbir jedinica u porudžbini za svaku kategoriju proizvoda u bazi podataka. Međutim, kolona podzbira „Jedinice u porudžbini“ ne postoji ni u jednoj tabeli. Umesto toga, tabela „Proizvodi“ sadrži kolonu „Jedinice u porudžbini“ koja za svaki proizvod skladišti jedinice u porudžbini. Koristeći te podatke, Access izračunava podzbir svaki put kada odštampate izveštaj. Sam podzbir ne bi trebalo skladištiti u tabeli.

  • Informacije uskladištite u najmanje logičke jedinice    

Možda ćete poželeti da imate jedno polje za puna lična imena ili imena proizvoda sa opisima proizvoda. Ako kombinujete više vrsta informacija u jednom polju, kasnije će biti teško preuzeti pojedinačne činjenice. Potrudite se da informacije raščlanite na logičke jedinice; na primer, kreirajte odvojena polja za ime i prezime ili ime, kategoriju i opis proizvoda.

Lista stavki informacija tokom procesa dizajniranja

Kada pročistite kolone sa podacima u svim tabelama, moći ćete da odaberete primarni ključ za svaku tabelu.

Vrh stranice Vrh stranice

Preciziranje primarnih ključeva

Svaka tabela bi trebalo da sadrži kolonu ili skup kolona koji jedinstveno identifikuje svaki red uskladišten u tabeli. To je često jedinstveni identifikacioni broj, poput ID broja zaposlenog ili serijskog broja. U terminologiji baze podataka ova informacije se naziva primarni ključ tabele. Access polja primarnog ključa koristi za brzo povezivanje podataka iz više tabela, kao i sakupljanje podataka za vaše potrebe.

Ako već imate jedinstveni identifikator tabele, kao što je broj proizvoda koji jedinstveno identifikuje svaki proizvod u katalogu, taj identifikator možete da koristite kao primarni ključ tabele – ali samo ako će vrednosti za svaki zapis u ovoj koloni uvek biti različite. U primarnom ključu ne možete imati duplirane vrednosti. Na primer, imena osoba nemojte koristiti kao primarni ključ jer ona nisu jedinstvena. Lako bi moglo da se desi da dve osobe u jednoj tabeli imaju isto ime.

Primarni ključ uvek mora da ima vrednost. Ako postoji mogućnost da vrednost kolone u nekom trenutku postane nedodeljena ili nepoznata (vrednost koja nedostaje), ona ne može da se koristi kao komponenta u primarnom ključu.

Uvek bi trebalo da odaberete primarni ključ čija se vrednost neće menjati. U bazi podataka sa više tabela primarni ključ jedne tabele se može koristiti kao referenca u drugim tabelama. Ako se primarni ključ promeni, promena se mora primeniti i na sva mesta na kojima se referencira na ključ. Korišćenje primarnog ključa koji se neće menjati smanjuje verovatnoću da primarni ključ postane nesinhronizovan sa drugim tabelama koje na njega referenciraju.

Kao primarni ključ se često koristi proizvoljni jedinstven broj. Na primer, svakoj porudžbini možete da dodelite jedinstveni broj porudžbine. Jedina namena broja porudžbine je identifikacija porudžbine. On se nakon dodeljivanja nikada ne menja.

Ako nemate u vidu kolonu ili skup kolona koje bi mogle da budu dobar primarni ključ, razmotrite upotrebu kolone koja sadrži tip podataka „Automatsko numerisanje“. Kada koristite tip podataka „Automatsko numerisanje“, Access će automatski dodeliti vrednost umesto vas. Takav identifikator nije zasnovan na činjenicama; oni ne sadrže činjenične informacije koje opisuju red koji predstavljaju. Ti identifikatori su idealni za korišćenje u vidu primarnih ključeva jer se ne menjaju. Verovatnije je da se primarni ključ koji sadrži činjenice o redu – npr. broj telefona ili ime kupca – promeni jer se same činjenične informacije mogu promeniti.


Na slici je prikazana tabela „Proizvodi“ sa poljem primarnog ključa.

Oblačić 1 Kolona čiji je tip podataka postavljen na „Automatsko numerisanje“ je često dobar primarni ključ. Nijedan ID proizvoda se ne ponavlja.

U nekim slučajevima, možda ćete želeti da za primarni ključ tabele koristite dva ili više polja. Na primer, tabela „Detalji porudžbine“ u kojoj su uskladištene stavke za porudžbinu bi za primarni ključ koristila dve kolone: „ID porudžbine“ i „ID proizvoda“. Kada se primarni ključ sastoji iz više kolona, naziva se i složeni ključ.

U bazama podataka prodaje proizvoda možete da kreirate kolonu „Automatsko numerisanje“ koja će u svakoj tabeli služiti kao primarni ključ: „ID proizvoda“ za tabelu „Proizvodi“, „ID porudžbine“ za tabelu „Porudžbine“, „ID kupca“ za kolonu „Kupci“ i „ID dobavljača“ za tabelu „Dobavljači“.

Na slici su prikazane stavke informacija tokom procesa dizajniranja

Vrh stranice Vrh stranice

Kreiranje relacija između tabela

Nakon raspoređivanja informacija u tabele, potreban vam je metod da ih ponovo povežete na smislen način. Na primer, sledeći obrazac sadrži informacije iz nekoliko tabela.


Obrazac „Porudžbine“

Oblačić 1 Informacije u ovom obrascu potiču iz tabele „Klijenti“…
Oblačić 2 …tabele „Zaposleni“…
Oblačić 3 …tabele „Porudžbine“…
Oblačić 4 …tabele „Proizvodi“…
Oblačić 5 …i tabele „Detalji porudžbine“.

Access je sistem za upravljanje relacionim bazama podataka. U relacionoj bazi podataka informacije se na osnovu teme dele u zasebne tabele. Nakon toga se koriste relacije između tabela kako bi se informacije po potrebi povezale.

Vrh stranice Vrh stranice

Kreiranje relacije „jedan-prema-više“

Razmotrite ovaj primer: tabele „Dobavljači“ i „Proizvodi“ u bazi podataka porudžbina proizvoda. Dobavljač može da dostavlja neograničen broj proizvoda. To znači da za svakog dobavljača koji je predstavljen u tabeli „Dobavljači“ može da postoji više proizvoda predstavljanih u tabeli „Proizvodi“. Dakle, relacija između tabele „Dobavljači“ i tabele „Proizvodi“ je relacija „jedan-prema-više“.

Koncept „jedan-prema-više“

Da biste predstavili relaciju „jedan-prema-više“ u dizajnu baze podataka, primarni ključ sa strane relacije „jedan“ dodajte u vidu jedne ili više dodatnih kolona u tabelu na strani relacije „više“. U ovom slučaju, npr. kolonu „ID dobavljača“ dodajete u tabelu „Proizvodi“. Access će nakon toga moći da koristi ID broj dobavljača u tabeli „Proizvodi“ za pronalaženje odgovarajućeg dobavljača za svaki proizvod.

Kolona „ID dobavljača“ u tabeli „Proizvodi“ naziva se sporedni ključ. Sporedni ključ je primarni ključ druge tabele. Kolona „ID Dobavljača“ je sporedni ključ u tabeli „Proizvodi“, pošto je primarni ključ u tabeli „Dobavljači“.

Lista stavki informacija tokom procesa dizajniranja

Vi obezbeđujete osnovu za spajanje srodnih tabela uparivanjem primarnih i sporednih ključeva. Ako niste sigurni koje tabele bi trebalo da dele zajedničku kolonu, identifikacija relacije „jedan-prema-više“ obezbeđuje situaciju u kojoj će dve povezane tabele zaista zahtevati deljenu kolonu.

Vrh stranice Vrh stranice

Kreiranje relacije „više-prema-više“

Razmotrite relaciju između tabele „Proizvodi“ i tabele „Porudžbine“.

Jedna porudžbina može da sadrži više proizvoda, a jedan proizvod može da se pojavi u više porudžbina. Stoga, za svaki zapis u tabeli „Porudžbine“ može da postoji više zapisa u tabeli „Proizvodi“, dok za svaki zapis u tabeli „Proizvodi“ može da postoji više zapisa u tabeli „Porudžbine“. Ovaj tip relacije naziva se relacija „više-prema-više“ jer za svaki proizvod može da postoji više porudžbina, a za svaku porudžbinu može da postoji više proizvoda. Imajte u vidu da je za otkrivanje relacije „više-prema-više“ između tabela važno da uzmete u obzir obe strane relacije.

Teme dveju tabela – tabele porudžbina i proizvoda – imaju relaciju „više-prema-više“. To predstavlja problem. Kako biste shvatili problem, zamislite šta bi se dogodilo ako biste pokušali da kreirate relaciju između ove dve tabele dodavanjem polja „ID proizvoda“ u tabelu „Porudžbine“. Potrebno je da u tabeli „Porudžbine“ postoji više od jednog zapisa po porudžbini da biste imali više proizvoda po porudžbini. Ponavljaćete informacije o porudžbini za svaki red koji je povezan sa pojedinačnom porudžbinom – što za posledicu ima neefikasan dizajn koji bi mogao da dovede do netačnih podataka. Srešćete se sa istim problemom ako polje „ID porudžbine“ smestite u tabelu „Proizvodi“ – za svaki proizvod ćete imati više od jednog zapisa u tabeli „Proizvodi“. Kako rešiti ovakav problem?

Odgovor leži u kreiranju treće tabele koja se često naziva vezna tabela, a koja relaciju „više-prema-više“ raščlanjuje na dve relacije „jedan-prema-više“. Primarni ključ iz obe tabele umeće se u treću tabelu. Kao posledica toga, treća tabela će zapisati svako pojavljivanje ili instancu relacije.

Relacija „više-prema-više“

Svaki zapis u tabeli „Detalji porudžbine“ predstavlja jednu stavku u porudžbini. Primarni ključ tabele „Detalji porudžbine“ sastoji se iz dva polja – sporednih ključeva iz tabele „Porudžbine“ i tabele „Proizvodi“. Kao primarni ključ ove tabele ne možete koristiti samo polje „ID porudžbine“, jer jedna porudžbina može da ima više stavki. Polje „ID porudžbine“ se ponavlja za svaku stavku u porudžbini, tako da ono ne sadrži jedinstvene vrednosti. Ne možete koristiti ni samo polje „ID proizvoda“, jer jedan proizvod može da se pojavi u više porudžbina. Ali ova dva polja zajedno uvek kreiraju jedinstvenu vrednost za svaki zapis.

U bazi podataka prodaje proizvoda, tabela „Porudžbine“ i tabela „Proizvodi“ nisu direktno povezane. One su, u stvari, povezane indirektno preko tabele „Detalji porudžbine“. Relacija „više-prema-više“ između porudžbina i proizvoda predstavljena je u bazi podataka pomoću dve relacije „jedan-prema-više“:

  • Između tabela „Porudžbine“ i „Detalji porudžbine“ postoji relacija „jedan-prema-više“. Svaka porudžbina može da ima više stavki, dok je svaka stavka povezana sa samo jednom porudžbinom.
  • Između tabela „Proizvodi“ i „Detalji porudžbine“ postoji relacija „jedan-prema-više“. Svaki proizvod može da ima više pridruženih stavki, ali svaka stavka upućuje samo na jedan proizvod.

Iz tabele „Detalji porudžbine“ možete da odredite sve proizvode u određenoj porudžbini. Možete da odredite i sve porudžbine za određeni proizvod.

Posle unosa tabele „Detalji porudžbine“, lista tabela i polja bi mogla da izgleda poput ove:

Lista stavki informacija tokom procesa dizajniranja

Vrh stranice Vrh stranice

Kreiranje relacije „jedan-prema-jedan“

Drugi tip relacije jeste relacija „jedan-prema-jedan“. Na primer, pretpostavimo da treba da zapišete neke specijalne dopunske informacije o proizvodu koje će vam retko biti potrebne ili koje su primenljive na samo nekoliko proizvoda. Pošto vam te informacije nisu često potrebne i pošto bi njihovo skladištenje u tabelu „Proizvodi“ dovelo do pojave praznog prostora za svaki proizvod za koji one ne važe, smestite ih u odvojenu tabelu. Koristite „ID proizvoda“ kao primarni ključ, kao u tabeli „Proizvodi“. Relacija između ove dopunske tabele i tabele „Proizvod“ je relacija „jedan-prema-jedan“. Za svaki zapis u tabeli „Proizvod“ postoji jedan podudarni zapis u dopunskoj tabeli. Kada identifikujete takvu relaciju, obe tabele moraju da dele zajedničko polje.

Kada otkrijete potrebu za relacijom „jedan-prema-jedan“, razmotrite da li informacije iz dve tabele možete da smestite u jednu tabelu. Ako to iz nekog razloga ne želite da uradite, možda zbog toga što bi to proizvelo mnogo praznog prostora, sledeća lista sadrži opis načina na koji biste tu relaciju predstavili u dizajnu:

  • Ako dve tabele imaju istu temu, verovatno možete da podesite relaciju pomoću istog primarnog ključa u obe tabele.
  • Ako dve tabele imaju različite teme sa različitim primarnim ključevima, odaberite jednu od tabela (bilo koju) i umetnite njen primarni ključ u drugu tabelu kao sporedni ključ.

Određivanje relacija između tabela vam pomaže da se uverite da imate odgovarajuće tabele ili kolone. Kada postoji relacija „jedan-prema-jedan“ ili „jedan-prema-više“, biće potrebno da tabele unutar relacije dele zajedničku kolonu ili kolone. Kada postoji relacija „više-prema-više“, za predstavljanje relacije će biti potrebna treća tabela.

Vrh stranice Vrh stranice

Pročišćavanje dizajna

Ako imate potrebne tabele, polja i relacije, trebalo bi da kreirate tabele i popunite ih probnim podacima, kao i da isprobate rad sa informacijama: kreiranje upita, dodavanje novih zapisa itd. Na taj način ćete doprineti otkrivanju potencijalnih problema – na primer, možda će biti potrebno da dodate kolonu koju ste zaboravili da umetnete tokom faze dizajniranja ili možda bi neku tabelu trebalo da podelite na dve tabele kako biste uklonili dupliranje.

Proverite da li bazu podataka možete da koristite kako biste dobili željene odgovore. Kreirajte prve radne verzije obrazaca i izveštaja i vidite da li one prikazuju očekivane rezultate. Potražite nepotrebne duplikate podataka i izmenite dizajn kako biste ih eliminisali nakon što ih pronađete.

Dok budete isprobavali početnu bazu podataka, verovatno ćete otkriti da ima mesta za poboljšanja. Evo nekoliko stvari koje bi trebalo da proverite:

  • Da li ste zaboravili neke kolone? Ako je to slučaj, da li te informacije pripadaju postojećim tabelama? Ukoliko se radi o informacijama o nečem drugom, možda će biti potrebno da kreirate još jednu tabelu. Kreirajte kolonu za svaku stavku informacija koju treba da pratite. Ako se ta informacija ne može izračunati na osnovu drugih kolona, postoji verovatnoća da će vam za nju biti potrebna nova kolona.
  • Da li su neke kolone nepotrebne jer se mogu izračunati na osnovu postojećih polja? Ako neka stavka informacija može da se izračuna na osnovu drugih postojećih kolona – npr. cena sa popustom izračunata na osnovu maloprodajne cene – često je bolje uraditi samo to i izbeći kreiranje nove kolone.
  • Da li iznova unosite duplirane informacije u neku tabelu? Ako je to slučaj, verovatno je potrebno da tabelu podelite na dve tabele između kojih će postojati relacija „jedan-prema-više“.
  • Da li imate tabele sa velikim brojem polja, ograničenim brojem zapisa i mnogo praznih polja u pojedinačnim zapisima? Ako je to slučaj, razmotrite ponovno dizajniranje tabele u kojoj će biti manje polja i više zapisa.
  • Da li ste svaku informaciju raščlanili na najmanje korisnih delova? Ako je potrebno da izveštavate, sortirate, pretražujete ili izračunavate prema nekoj stavci informacije, stavite je u zasebnu kolonu.
  • Da li svaka kolona sadrži činjenicu o temi tabele? Ako kolona ne sadrži informaciju o temi tabele, ona pripada drugoj tabeli.
  • Da li su sve relacije između tabela predstavljene, bilo pomoću zajedničkih polja, bilo pomoću treće tabele? Relacije „jedan-prema-jedan“ ili „jedan-prema-više“ zahtevaju zajedničke kolone. Relacije „više-prema-više“ zahtevaju treću tabelu.

Pročišćavanje tabele „Proizvodi“

Pretpostavimo da svaki proizvod u bazi podataka prodaje proizvoda spada u opštu kategoriju, poput alkoholnih i bezalkoholnih pića, začina ili morskih plodova. Tabela „Proizvodi“ bi mogla da sadrži polje koje prikazuje kategoriju svakog proizvoda.

Pretpostavimo da posle ispitivanja i pročišćavanja dizajna baze podataka odlučite da uskladištite opis kategorije sa njenim imenom. Ako dodate polje „Opis kategorije“ u tabelu „Proizvodi“, moraćete da ponavljate opis kategorije za svaki proizvod koji spada u određenu kategoriju – ovo nije dobro rešenje.

Bolje rešenje je da tabela „Kategorije“ postane nova tema koja će se pratiti u bazi podataka, sa sopstvenom tabelom i sopstvenim primarnim ključem. Nakon toga primarni ključ iz tabele „Kategorije“ možete dodati u tabelu „Proizvodi“ kao sporedni ključ.

Tabele „Kategorije“ i „Proizvodi“ imaju relaciju „jedan-prema-više“: kategorija može da sadrži više proizvoda, ali proizvod može da pripada samo jednoj kategoriji.

Kada redigujete strukture tabela, obratite pažnju na grupe koje se ponavljaju. Na primer, razmotrite tabelu koja sadrži sledeće kolone:

  • ID proizvoda
  • Ime
  • ID1 proizvoda
  • Ime1
  • ID2 proizvoda
  • Ime2
  • ID3 proizvoda
  • Ime3

Ovde svaki proizvod predstavlja grupu kolona koja se ponavlja i razlikuje od drugih samo po broju koji se dodaje na kraj imena kolone. Kada vidite ovako numerisane kolone, trebalo bi da ponovo razmotrite dizajn.

Takav dizajn ima nekoliko nedostataka. Za početak, primorava vas da postavite gornju granicu broja proizvoda. Čim prekoračite tu granicu, moraćete da dodate novu grupu kolona u strukturu tabele što predstavlja osnovni administrativni zadatak.

Problem je i u tome što će ti dobavljači koji imaju manji broj proizvoda od maksimalnog nepotrebno zauzeti prostor, pošto će dodatne kolone biti prazne. Najozbiljniji nedostatak takvog dizajna je u tome što otežava izvršavanje mnogih zadataka, kao što je sortiranje ili indeksiranje tabele prema ID-u proizvoda ili imenu.

Svaki put kada vidite grupe koje se ponavljaju, pažljivo redigujte dizajn obrativši pažnju na deljenje jedne tabele na dve. U prethodnom primeru je bolje koristiti dve tabele, jednu za dobavljače, a drugu za proizvode, pri čemu bi one bile međusobno povezane ID-om dobavljača.

Vrh stranice Vrh stranice

Primenjivanje pravila normalizacije

Pravila normalizacije podataka (ponekad se nazivaju samo pravila normalizacije) možete da primenite kao sledeći korak u dizajnu. Koristite ova pravila da biste proverili da li su tabele ispravno strukturirane. Proces primenjivanja pravila na dizajn baze podataka naziva se normalizacija baze podataka ili samo normalizacija.

Normalizacija je najkorisnije pošto predstavite sve stavke informacija i dođete do preliminarnog dizajna. Cilj je da se uverite da ste informacije podelili u odgovarajuće tabele. Putem normalizacije ne možete da proverite da li imate sve ispravne stavke podataka potrebne za početak rada.

Pravila primenjujete redom, pri čemu se tokom svakog koraka morate uveriti da je vaš dizajn postigao takozvanu „normalnu formu“. Opšteprihvaćeno je pet takvih formi – od prve do pete normalne forme. Ovaj članak sadrži objašnjenja o prve tri, jer su one dovoljne za većinu slučajeva dizajna baze podataka.

Prva normalna forma

Prva normalna forma podrazumeva da u svakom preseku reda i kolone u tabeli postoji jedna vrednost, a nikada lista vrednosti. Na primer, ne možete imati polje pod nazivom „Cena“ u koje ćete smestiti više cena. Ako svaki presek redova i kolona zamislite kao ćeliju, svaka ćelija može da sadrži jednu vrednost.

Druga normalna forma

Druga normalna forma zahteva da svaka kolona bez ključa potpuno zavisi od celog primarnog ključa, a ne samo nekog njegovog dela. Ovo pravilo se primenjuje kada imate primarni ključ koji se sastoji od više kolona. Na primer, pretpostavimo da imate tabelu koja sadrži sledeće kolone, pri čemu polja „ID porudžbine“ i „ID proizvoda“ formiraju primarni ključ:

  • ID porudžbine (primarni ključ)
  • ID proizvoda (primarni ključ)
  • Ime proizvoda

Ovakav dizajn krši pravilo druge normalne forme, jer kolona „Ime proizvoda“ zavisi od polja „ID proizvoda“, a ne od polja „ID porudžbine“, tako da ne zavisi od celog primarnog ključa. Potrebno je da iz tabele uklonite kolonu „Ime proizvoda“. Ona pripada dugoj tabeli (tabeli „Proizvodi“).

Treća normalna forma

Treća normalna forma ne zahteva samo da svaka kolona bez ključa bude zavisna od celog primarnog ključa, već i da kolone bez ključa zavise jedna od druge.

Drugim rečima, svaka tabela bez ključa mora da zavisi od primarnog ključa i ni od čega drugog. Na primer, pretpostavimo da imate tabelu koja sadrži sledeće kolone:

  • ID proizvoda (primarni ključ)
  • Ime
  • PMC
  • Popust

Pretpostavimo da kolona „Popust“ zavisi od preporučene maloprodajne cene (PMC). Ova tabela narušava treću normalnu formu jer kolona bez ključa „Popust“ zavisi od kolone bez ključa „PMC“. Nezavisnost kolone znači da bi trebalo da budete u mogućnosti da promenite svaku kolonu koja ne sadrži ključ ne utičući na druge kolone. Ako promenite vrednost u polju „PMC“, kolona „Popust“ će se promeniti u skladu sa tim i na taj način prekršiti to pravilo. U ovom slučaju, kolonu „Popust“ bi trebalo premestiti u drugu tabelu sa ključem u polju „PMC“.

Vrh stranice Vrh stranice