Baza podataka – pojam. Objekti baze podataka. Planiranje i optimizacija baze podataka.

Na današnjem nivou razvijenosti, funkcionisanje privrede i informacionog društva uopše, nezamislivo je bez primene baza podataka. Baze podataka su svuda oko nas:  facebook, banke, marketi, …Kada podižete novac sa bankomata ili kada nešto plaćete karticom, koristi se baza podataka banke iz koje se proveravaju vaši podaci. U marketima, kada prodavac na kasi skenira neki proizvod, koristi se baza podataka robe. Na facebook-u se takođe podaci pamte u bazi. Tu su vaši lični podaci, podaci prijatelja, vaše objave, komentari i fotografije.  Kada se ulogujete, sve vam je dostupno.

To znači da je baza podataka u stvari organizovan skup podataka koji su međusobno povezani u jednu celinu i pogodni za dalju nadogradnju i obradu. Podatak je sam po sebi jedna prosta činjenica koja nema neku upotrebnu vrednost. Kada se logički poveže više podataka, dobija se informacija.

Osnovne cilj postojanja baze podataka nije samo prosto “punjenje” baze, već njeno korišćenje i pomoć koju može da vam pruži prilikom donošenja poslovnih odluka. Podatke možete da pretražujete na osnovu različitih kriterijuma, da ih sortirate i filtrirate,  da pravite izveštaje, upite, …

Objekti baze podataka.

Objekti baze podataka su tabele (Tables), upiti (Queries), obrasci (Forms), izveštaji (Reports), makroi (macros) i moduli (Modules). Glavni obrazac baze sa kojom će mo da radimo u okviru ovog kursa je dat na slici dole. Baza se odnosi na robno-magacinsko poslovanje a način na koji funkcioniše je obrađen u narednom vedeu. Podaci iz baze su izmišljeni i odnose se na 2012. godinu. Bazu možete preuzeti ovde.

Ideja je da učenici, pre svakog modula, u ovoj bazi urade nešto od onoga što uče. Na primer kada uče forme, treba da preko istih proknjiže par naloga, ili pre nogo što sami naprave izveštaj ovde pogledaju čemu služe i kako izgledaju podaci u gotovom izveštaju a kako su suvoparni u upitu ili tabeli.

Tabele u bazi su osnovni objekti jer se u njima čuvaju podaci. Upiti su u stvari snaga baze podataka, zavisno od toga koliko ste vešti. Pomoću upita možete da izdvajate podatke iz više tabela prema različitim kriterijumima, možete da menjate podatke u tabeli ili pak da pravite nove tabele. Takođe u  okviru upita možete da primenjujete i računske operacije, kao i još puno ugrađenih funkcija. Obrasci predstavljaju interfejs prilikom rada sa podacima, a sve u cilju da se izbegne direktan rad sa tabelama i smanji  verovatnoća pravljenja slučajnih grešaka. Izveštaji se koriste za prikazivanje podataka na ekranu ili za štampanje, a u formi koja nama odgovara.

Makroi sluše za automatizaciju nekih poslova koji se stalno ponavljaju. Moduli se pišu u programskom jeziku VBA, i kao makroi služe da povećaju funkcionalnost baze podataka.

Kako bi se upoznali sa bazom i videli neke od mogućnosti, treba uraditi naredne zadatake:

• Svaki učenik treba da u bazu unese sebe i svoju školu kao kupce preko komandnog dugmeta Unos kupaca.
• Unesite novog dobavljača “Sliv” d.o.o. Paraćin, PIB: 123456789, tel. 035/555-555, preko komandnog dugmeta Unos dobavljača.
• Proverite da li su podaci uneti preko komandnih dugmadi Kupci-podaci i Dobavljači-podaci

Proveriti još i:

• Šta je od robe stiglo od dobavljača 3 u prvoj polovini juna 2012.? (Koristite komandno dugme Ulazni nalog po izboru)
• Da li na stanju imamo proizvod sa šifrom 33465? (Koristite komandno dugme Kartica robe – izveštaj. Drugi način je komandno dugme Stanje)
• Kolika je vrednost robe u magacinima? (Koristite komandno dugme Lager – izveštaj)

U narednih par lekcija, odmah posle otvaranja nove baze i kreiranja tabela na više načina, u ovu bazu će mo dodati novu tabelu sa podacima o zaposlenima.

Planiranje i optimizacija baze podataka.

Ovo je najteži deo posla. Treba vam dosta iskustva i vremena da utrošite na planiranje baze. U zavisnosti od toga, za koga pravite bazu ( za sebe ili nekog drugog korisnika), neophodno je da znate šta su to ulazni podaci a šta izlazni. Ovo se postiže razgovorom sa klijentom. Šta se od dokumentacije unosi u bazu ( ulazne fakture, izvodi iz banaka, …) i kakvi sve izveštaji treba da se naprave. Klijenti najčešće imaju puno zahteva. Najgore je kada ste na kraju a onda dođe još jedan zahtev tipa “mogli gi da ubacimo i …”. U ovom slučaju, ako vam baza nije dobo optimizovana, nastaju “nerešivi” problemi. To znači da prilikom dizajniranja baze i tabela treba da predvidite različite mogućnosti koje vam kasnije mogu koristiti prilikom automatizacije poslova i procesa.

Optimizaciju će mo objasniti na primeru baze za školsku evidenciju. Krećemo od toga šta nam je sve potrebno od podataka i kakvu evidenciju želimo (adresar, ocene, izostanci, ekskurzija, biblioteka, praksa, …).

Učenicima dajem zadatak da nacrtaju tabelu na tabli koja će sadržati sve potrebne podatke o učenicima (zadatak radimo grupno – oluja ideja). Sugerišem im da pri projektovanju baze ubace što više polja (koja mogu ostati prazna), jer kasnije, ako se javi potreba za nečim, mnogo teže je uraditi isto zbog integriteta i relacija između tabela. Pored osnovnih podataka (ime, prezime, datum rođenja, …, smer, razredni starešina), treba staviti i polja za telefon fiksni i mobilni, e-mail, hobi, …

Na samom početku se bavimo i šifrom učenika, ne u kontekstu primarnog ključa što će mo kasnije, već zbog samog shvatanja jednoznačnosti podataka. Tako, za robu, veliki marketi koriste EAN kod i skener, dok male prodavnice koriste svoje interne šifre za fiskalnu kasu. Za stanovništvo, banke i druge institucije (policija, sudovi, poreske službe,…) koriste JMBG a za male baze koristimo interne šifre koje sami smišljamo. Takve šifre treba da budu intuitivne.

Učenici sada predlažu model šifre. Broj u dnevniku? Ne može jer npr. broj 20 u dnevniku ima svako odeljenje. Ako dodamo još dve cifre ispred, za razred i odeljenje, šifra je jednoznačna. Na primer 2620 znači da je učenik iz odeljenja II/6 i broj 20 u dnevniku. Ako se baza vodi za svaku školsku godinu posebno, ovo je dovoljno. Međutim, ako se baza svake godine dopunjava sa novim učenicima, onda je potrebno dodati još dve cifre za recimo godinu upisa (slično kao u matičnoj knjizi).

Učenik, koji poslednji uđe u učionicu, ispisuje podatke na tabli za desetak učenika iz odeljenja. Dogovor je da se ne pišu skraćenice ili znak deto, jer operater koji treba da puni bazu nema takvu mogućnost (za sada ne raspravljamo o povlačenu podataka i kombo boksu). Cilj je da učenici vide problem sa dupliranjem podataka. Dobija se nešto slično kao na slici dole. Izostavili smo neka polja, tipa telefon, e-mail, … kako bi se zadatak završio u okviru ovog dvočasa.

Sledi pitanje za učenika koji je popunjavao tabelu na tabli: Koji deo posla mu je bio najdosadniji?

Odgovor je upisani smer i odeljenjski starešina tj. polja osenčena zelenom bojom. Dolazimo do zaključka da se Ekonomski tehničar ponavlja 120 puta (u jednom odeljenju 30 učenika, puta četiri razreda). Takođe Perić Pera se kao odeljenjski starešina ponavlja 30 puta. Isto važi za sve ostale smerove i odeljenja.

Rešenje ovog problema je optimizacija baze. Optimizacija baze ima za cilj da se svaki podatak upisuje samo na jednom mestu tj. da se izbegne dupliranje podataka. U našem slučaju, potrebno je da se velika tabela „razbije“ na dve manje koje se međusobno povezuju relacijama. Upravo zbog ovoga, ovo su relacione baze podataka.

Učenicima sada treba objasniti kako se tabele u Accessu prikazuju u modu za dizajniranje, odnosno da se ne vide podaci i zaglavlje tabele kao u Excelu, već samo nazivi polja u tabeli. Kada se ovo shvati, onda će i optimizacija baze, sa narednih slika biti jasnija.

Ovde smo, od velike polazne tabele, napravili dve manje tabele Smer i Učenici. Jasno je da će mo za npr. odeljenje III/1 samo jednom, u tabeli Smer, uneti Ekonomski tehničar i Perić Pera. To znači da će tabela Smer imati onoliko slogova koliko ima odeljenja u školi.

Da ništa nije idealno, pokazuje i dupliranje polja Odeljenje. Ovo polje (osenčeno plavom bojom u polaznoj tabeli) mora da se duplira zbog relacije koja je uspostavljena između ovih tabela. Jedno odeljenje ima više upisanih učenika, ali o relacijama će mo kasnije.

Kada formiramo ovakvu strukturu, u postojeću bazu možemo dodavati još tabela. Na sledećem primeru je dodata tabela za evidenciju uplata rata za ekskurziju. Jedan učenik može da ima više uplata. Zbog toga šifra učenika u tabeli Ekskurzija nema primarni ključ.

Kada je baza “napunjena”, na sličan način kao u prethodnom primeru, možete naknadno dodavati još tabela za različite vrste evidencija tipa biblioteke, izostanaka, prakse i td.