Pravljenje baza podataka: Uobičajene greške koje treba izbegavati

Bez obzira na to da li radite u bazi podataka koja sadrži stotine ili milione zapisa, uvek je izuzetno važno napraviti odgovarajuću koncepciju baze podataka. Osim toga što će vam u tom slučaju preuzimanje podataka biti mnogo jednostavnije, olakšaće vam i moguće buduće proširenje baze podataka. Nažalost, sasvim je lako da se uhvatite u nekoliko zamki koje će vam kasnije otežati život.

Mnogobrojne knjige na tržištu bave se temom normalizacije baza podataka, ali ako budete jednostavno izbegavali greške koje ćemo ovde spomenuti, bićete na pravom putu da uspostavite dobru koncepciju baze podataka.

Prva greška: Ponavljanje polja u tabeli

Osnovno pravilo koje treba poštovati pri stvaranju baza podataka je prepoznavanje ponovljenih podataka i premeštanje kolona koje se ponavljaju u posebnu tabelu. Ponavljanje kolona u tabeli karakteristično je za ljude koji su se uglavnom bavili tabelarnim proračunima, koji su dvodimenzionalni. S druge strane, baze podataka treba da budu relacione, što znači da se iz dvodimenzionalnog prostora prebacujete u trodimenzionalni.

Srećom, lako je uočiti kolone koje se ponavljaju. Pogledajte sledeću tabelu:

 

OrderID Product1 Product2 Product3
1 Teddy Bears Jelly Beans  
2 Jelly Beans    

Šta se dešava kad narudžbina sadrži četiri proizvoda? U tom slučaju potrebno je dodati još jednu kolonu tabeli da bi mogla da obuhvati više od tri proizvoda. Ako bismo za tabelu napravili klijent aplikaciju koja bi nam pomogla pri unosu podataka, možda bismo morali da je izmenimo dodajući novu kolonu za proizvod. Kako pronalazimo sve narudžbine Jellybeans-a u celoj narudžbini? Morali bismo da pravimo upit za svaku kolonu za proizvod u tabeli pomoću SQL-ove naredbe koja bi mogla da izgleda ovako: SELECT * FROM Products WHERE Product1=’Jelly Beans’ OR Product2=’Jelly Beans’ OR Product3=’Jelly Beans’.

Umesto pravljenja samo jedne tabele u koju ćemo natrpati sve informacije, trebalo bi da napravimo tri tabele. U tom slučaju, svaka će sadržati određenu vrstu informacija. U ovom primeru, trebalo bi da napravimo tabelu Orders (porudžbine) u kojoj će se nalaziti podaci o porudžbinama, zatim tabelu Product (proizvod) za sve naše proizvode i konačno, tabelu ProductOrders (naručivanje proizvoda) koja će povezati proizvod sa porudžbinom.

 

OrderID CustomerID Order Date Total
1 7 1/24/17 19.99
2 9 1/25/17 24.99

 

ProductID Product Count
1 Teddy Bears 1
2 Jelly Beans 100

 

ProductOrderID ProductID OrderID
101 1 1
102 2 1

 

Obratite pažnju na to da svaka tabela ima svoje jedinstvenu kolonu identiteta (ID). To je primarni ključ. Tabele povezujemo koristeći vrednost primarnog ključa kao stranog ključa u drugoj tabeli.

Druga greška: Umetanje tabele u tabelu

Ovo je druga uobičajena greška, ali ne pojavljuje se toliko često koliko se pojavljuju ponovljene kolone. Kad pravite bazu podataka, želite da budete sigurni da svi podaci u tabeli pripadaju jednoj vrsti. To liči na onu dečiju igru u kojoj treba da uočite razlike. Ako imate bananu, jagodu, breskvu i televizor, verovatno je da televizor pripada nekoj drugoj grupi.

Slično tome, ako imate tabelu u kojoj se nalaze prodavci, sve informacije u toj tabeli treba da se odnose na određenog prodavca. Svaka dodatna informacija koja nije jedinstvena za tog prodavca verovatno pripada nekom drugom mestu u vašoj bazi podataka.

 

SalesID First Last Address PhoneNumber Office OfficeNumber
1 Sam Elliot 118 Main St, Austin, TX (215) 555-5858 Austin Downtown (212) 421-2412
2 Alice Smith 504 2nd Street, New York, NY (211) 122-1821 New York (East) (211) 855-4541
3 Joe Parish 428 Aker St, Austin, TX (215) 545-5545 Austin Downtown (212) 421-2412

 

Iako vam se možda čini da se ova tabela odnosi na pojedinačnog prodavca, ona, ipak ima umetnutu tabelu. Obratite pažnju na ponavljanje u kolonama Office i OfficeNumber zajedno sa „Austin Downtown“. Šta bi se dogodilo ako bi se promenio broj telefona u kancelariji? Morali biste da ažurirate ceo skup podataka zbog promene samo jedne informacije, što nikada nije lak posao. Ta polja bi trebalo premestiti u posebnu tabelu.

 

SalesID First Last Address PhoneNumber OfficeID
1 Sam Elliot 118 Main St, Austin, TX (215) 555-5858 1
2 Alice Smith 504 2nd Street, New York, NY (211) 122-1821 2
3 Joe Parish 428 Aker St, Austin, TX (215) 545-5545 1

 

OfficeID Office OfficeNumber
1 Austin Downtown (212) 421-2412
2 New York (East) (211) 855-4541

 

Ovakav koncept vam omogućava da dodate naknadne informacije tabeli Office, a da pri tom ne stvorite haos pretrpavajući tabelu prodavaca (sales person). Zamislite samo koliko bi naporno trebalo da radite kad bi stalno pratili podatke o adresi, gradu, državi i poštanskom broju ako bi sve te informacije bile u tabeli u kojoj se nalaze prodavci!

Treća greška: Unošenje dve ili više informacija u jednu kolonu

Umetanje podataka o kancelariji u tabelu za prodavce predstavlja problem ne samo u toj bazi podataka. Kolona za adresu sadrži tri informacije: naziv ulice, grada i države. Svaka kolona u bazi podataka treba da sadrži samo jednu informaciju. Kad imate više informacija u jednoj koloni, mnogo je teže postaviti upit za podatak u bazi podataka.

Šta će se dogoditi ako, na primer, postavite upit za sve prodavce iz Ostina? Trebalo bi da pretražujete u koloni adresa, što nije samo neefikasno, već vam može dati pogrešne rezultate. Konačno, neko bi mogao da živi u Ulici Ostin u Portlandu u državi Oregon.

Ovako bi trebalo da izgleda tabela:

 

SalesID First Last Address1 Address2 City State Zip Phone
1 Sam Elliot 118 Main St   Austin TX 78720 2155555858
2 Alice Smith 504 2nd St   New York NY 10022 2111221821
3 Joe Parish 428 Aker St Apt 304 Austin TX 78716 2155455545

 

Ovde bi trebalo obratiti pažnju na to da kolone „Address1 i „Address2“ izgleda pripadaju već pomenutom ponavljanju kolona.

Međutim, u ovom slučaju one se odnose na različite informacije koje se direktno odnose na prodavce, a ne na ponovljene grupe podataka koje bi trebalo smestiti u posebnu tabelu.

Navešćemo još jednu grešku koju treba izbegavati u ovom slučaju. Obratite pažnju kako je napisan broj telefona. Trebalo bi da izbegavate skladištenje broja telefona napisanog u različitim oblicima kad god je to moguće. U slučaju brojeva telefona, ljudi koriste različite metode zapisivanja: 215-555-5858 ili (215) 555-5858, što bi otežalo pretraživanje prodavaca prema njihovom broju telefona ili prema istom pozivnom broju.

Četvrta greška: Korišćenje pogrešnog primarnog ključa

U većini slučajeva, želećete da koristite automatski brojčani priraštaj ili neki drugi generisani broj ili alfanumerički karakter za svoj primarni ključ. Ne bi trebalo da koristite neke konkretne informacije kao primarni ključ iako možda to zvuči kao odličan identifikator.

Na primer, svako od nas ima svoj jedinstveni matični broj i izgleda nam da bi bio odličan primarni ključ u bazi podataka zaposlenih. Iako se retko kad dešava, ipak, matični broj bi mogao da se promeni, a mi smo čvrsto odlučili da ne želimo da menjamo primarni ključ.

U stvari, želimo samo da napomenemo da pravu informaciju ne možemo da koristimo kao primarni ključ jer ona podleže promenama.

Peta greška: Izbegavanje konvencije imenovanja

Možda vam ovo ne izgleda kao ozbiljan problem pri samom stvaranju baze podataka, ali kad počnete da pravite upite za bazu podataka da biste prikupili informacije, konvencija imenovanja vam može pomoći da zapamtite nazive kolona.

Zamislite samo koliko bi ceo proces bio otežan kad biste u jednoj tabeli skladištili podatke kao FirstName, LastName, a u drugoj kao fisrt_name, last_name.

Dve najčešće korišćene konvencije imenovanja su pisanje velikog početnog slova u svakoj reči ili odvajanje reči donjom crtom. Neki programeri koriste drugačije načine imenovanja, recimo, sve reči počinju velikim slovom osim prve: firstName, lastName.

Sami odlučujete i o tome da li ćete koristiti jedninu ili množinu pri imenovanju tabele. Da li ćete napisati Order table ili Orders table pri imenovanju tabele je odluka koju donosite sami kao i u slučaju Customer table or Customers table. Ponovo vas podsećamo da ne napravite grešku i zaglavite se u tabelama koje se zovu Order table i Customers table, dakle da jednom koristite jedninu, a u drugom slučaju množinu.

Nije mnogo važno koju ćete konvenciju imenovanja izabrati, ali izuzetno je važno da se pridržavate konvencije koju ste izabrali.

Šesta greška: Neodgovarajuće indeksiranje

Indeksiranje je jedan od najtežih postupaka, naročito za one koji su prilično neiskusni u stvaranju i radu u bazama podataka. Svi primarni i strani ključevi moraju biti indeksirani jer se njima povezuju tabele. Dakle, bez indeksa, vaša baza podataka će veoma teško i jadno funkcionisati.

Međutim, obično se zaborave ostale kolone, a najčešće kolona „WHERE“. Ako ćete često sužavati pretragu koristeći kolonu u naredbi „WHERE“, onda bi trebalo da indeksirate i tu kolonu. Ne bi trebalo uvoditi mnogo indeksa jer će i to usporiti rad vaše baze podataka.

Koliko je dovoljno? Indeksiranje je deo umetnosti stvaranja baza podataka. Ne postoje stroga ograničenja u broju indeksa koje treba uvesti u tabelu. Prvenstveno treba indeksirati one kolone koje se često koriste u naredbi „WHERE“.