BAZA ZNANJA

Kurs: ECDL Access

Modul: Korišćenje aplikacije

Autor:

Naziv jedinice: Koncept baze podataka

Pojam baze podataka

Raspolaganje adekvatnim, pravovremenim i pouzdanim podacima neophodno je za uspešno poslovanje. Računovodstveni podaci, katalozi proizvoda, stanje zaliha, informacije o prodaji samo su neki primeri podataka sa kojim se često susrećemo. Podatke nije dovoljno prikupiti, nego ih moramo na pogodan način organizovati kako bi mogli da im lako i efikasno pristupimo. Tabele su uobičajen način da podatke organizujemo. Na primer, za evidenciju poslovnih partnera možemo da napravimo sledeću tabelu:

Partneri

Slika 1: Početna tabela Partneri

Gledajući podatke u ovoj tabeli možemo uočiti da se za više osoba iz iste firme ponavljaju adresni podaci (problem redundanse).  Dupliranje podataka otežava unos,  zauzima dodatni prostor i , što je još važnije, nosi rizik da uneseni podaci budu nekonzistentni. Kad je potrebno izmeniti neki podatak (npr. promena adrese preduzeća), izmenu je potrebno sprovesti na svim mestima gde se on nalazi, što često uslovljava pojave grešaka.

Takođe i jednostavna greška pri unosu (npr. Katanićeva umesto Katićeva) dovodi do neusklađenosti podataka, pa korišćenje takvih podataka postaje diskutabilno (problem integriteta podataka).

Rešenje je uvođenje još jedne tabele u kojoj bi se čuvale informacije o firmi, tako da se podaci ne dupliraju nego se unose samo jednom.  U tom slučaju za svaku osobu u tabeli Partneri bi se čuvalo polje sa nazivom firme, koji bi koristilo da jednu tabelu možemo da povežemo sa drugom.

Slika 2: Početna tabela razdvojena je na dve tabele

Na ovaj način smo rešili problem redundanse ali i dalje možemo imati problema sa neodgovarajuće unesenim podacima. Naziv preduzeća nije pogodan način identifikacije jer je dugačak i lako može doći do pogrešnih unosa. U  jednom slučaju možemo uneti ABC d.o.o. drugi put samo ABC ili D.O.O. ABC, pa je uobičajeno da se umesto naziva koriste šifre za povezivanje tabela. Mi ćemo za šifru firme uzeti redni broj. Konačno naša evidencija poslovnih partnera  bi izgledala kao na Slici 3.

Slika 3: Umesto Naziva firme za povezivanje tabela koristi se šifra firme

Pokazalo se da je čuvanje podataka u samo jednoj tabeli skoro nikada nije dobar način organizacije i da se opisani problemi redundanse i integriteta podataka javljaju čim želimo da evidentiramo više od najjednostavnijih lista podataka. Zato je za skladištenje velikih količina podataka efikasnije i primerenije koristiti bazu podataka.

 Baza podataka predstavlja organizovanu kolekciju podatka, tako da im lako možemo pristupiti, ažurirati ih ili pronaći željeni podatak. Baza podataka sadrži skup podataka kojim se opisuje realan sistem, odnosno formalizovan model realnog sistema. Baze podataka možemo klasifikovati po načinu organizacije podataka, a danas u upotrebi preovlađuju relacione baze podataka. U relacionim bazama podataka,  podaci su smešteni unutar dvodimenzionalnih tabela, koje su međusobno povezane (u relaciji). Tako se eliminiše redundansa, ali je potreban složeniji softver koji će upravljati podacima i relacijama (Data Base Management System – DBMS). Danas se za upravljanje bazama podataka najčešće koriste MS SQL Server, Oracle (pre svega za velike poslovne sisteme) i MS Access (pre svega za manje poslovne sisteme i personalne baze podataka. U savremenom okruženju informacije su postale veoma značajne,  pa računari širom sveta troše veliki deo vremena na upravljanje i korišćenje baza podataka.

Tabele relacione baze podataka

Tabele baze podataka se sastoje iz redova, koje nazivamo slog ili zapis (record) i kolona za koje upotrebljavamo termin polje ili atribut (field). Elementi u jednom polju tabele moraju da budu istorodni, tj. da uzimaju vrednosti iz istog domena. Za svako polje definiše se tip podataka koji ono može da sadrži: numerički podatak, tekstualni podatak, datum/vreme ili drugo. Pored tipa podataka možemo definisati i druga svojstva (parametre, properties) za određeno polje tabele. Koja svojstva polja je moguće postaviti i menjati  zavisiće od izabranog tipa podataka za to polje. Za tekstualno polje možemo zadati maksimalnu  dužinu teksta, a za numeričko polje broj decimalnih mesta, dok format ispisa možemo definisati i za tekstualno i numeričko polje.

Svaki slog obavezno sadrži vrednosti za sva polja, pri čemu neka polja mogu imati vrednost ‘nedefinisano’ ( tj. NULL, što treba razlikovati od praznog teksta). Redosled po kojem se redovi sortiraju nije unapred određen.

Primarni ključ i indeks

Svaki slog sadrži jedinstvenu kombinaciju polja – ne sme biti dupliranih redova. Polje po kojem se jedan red tabele razlikuje od ostalih zove se primarni ključ (primary key). U našem primeru primarni ključ za tabelu Firme je šifra firme. Neko drugo obeležje npr. adresa, telefon, naziv može biti isto za više organizacija, pa ga ne možemo koristiti kao primarni ključ. Ako pogledamo sada tabelu Partneri, nemamo ni jedan atribut koji samostalno razlikuje jedan slog u tabeli od ostalih. U tom slučaju možemo koristiti dva (ili više) atributa da formiramo primarni ključ. Na primer mogli bi da razmotrimo korišćenje kombinacije Prezime, Ime kao primarni ključ. U realnoj situaciji kombinacija ime i prezime nije pogodna za primarni ključ, zato što mogu da se pojave dve osobe sa istim imenom i prezimenom. Zbog toga je uobičajeno da dodamo još jedno polje u tabeli Partneri  koje će služiti kao primarni ključ – npr. jedinstveni matični broj osobe.

Primarni ključ jedinstveno određuje slog u tabeli. Može se formirati od više polja. Ni jedno polje u primarnom ključu ne sme imati  vrednost NULL! Ako se vratimo na Sliku 3, vidimo da kolona Sifra_firme postoji iksljučivo iz razloga da bi mogli da izvršimo povezivanje ove tabele sa tabelom Firmi. Ovakvo  polje zovemo spoljni ključ. Strani ključ (foreign key) povezuje jedan slog  sa slogom  iz druge tabele. Kao i primarni ključ, strani ključ može biti sastavljen od više polja. Strani ključ može imati vrednost NULL ili bilo koju drugu vrednost koja je jednaka primarnom ključu iz tabele na koju je povezan.

Bez obzira na organizaciju tabele, u tabelama koje sadrže veliki broj slogova naći pojedini slog nije lako – za tabelu od 1000 ili više slogova pretraživanje red po red trajalo bi isuviše dugo. Da bi se obezbedilo brže pretraživanje i sortiranje tabele, u bazama podataka formiraju se posebne tabele indeksa. Na primer, ako često našu tabelu firmi pretražujemo po mestu možemo da formiramo indeks za polje Mesto. Analogija se može napraviti sa indeksom pojmova na kraju knjige – nađete traženu reč u indeksu pojmova i zatim brzo pristupite stranici na kojoj se nalazi.

Indeks (Index) omogućuje brzo pretraživanje i sortiranje tabela. Indeksi se mogu kreirati za jedno polje, kao i za kombinaciju polja. Pored polja za koje se očekuje često pretraživanje i sortiranje, indekse obično kreiramo i za polja koja koristimo za povezivanje sa drugim poljima u tabeli (spoljni ključevi). Primarni ključ tabele je automatski indeksiran. Indeksi koji se sastoje iz više polja koriste se u slučaju kad pretraživanje i sortiranje samo po jednom polju daje veliki broj slogova, npr. možemo formirati indeks od polja  Ime i Prezime u tabeli Partneri iz našeg primera.

Povezivanje tabela

Videli smo da se zbog problema redundanse podaci u relacionoj bazi podataka drže u razdvojenim tabelama. Da bi korisniku omogućili da podacima smeštenim u različitim tabelama pristupi istovremeno uspostavljaju se relacije između tabela. Koristeći relacije, sistem baze podataka može obaviti operaciju udruživanja tako što kombinuje povezane tabele u rezultujuću tabelu, koja sadrži uniju kolona iz povezanih tabela. U navedenom primeru, koristeći relacije između tabela Firme i Partneri može se dobiti pregled svih poslovnih partnera u vidu tabele od koje smo počeli primer (slika 1)

Relacije između tabela u bazi podataka omogućuju da podaci smešteni u različitim tabelama budu vidljivi u isto vreme.

Kod uspostavljanja relacija između tabela razlikujemo veze:

·         Jedan – prema – više – jedan slog tabele može imati više slogova u drugoj tabeli. Prva tabela se naziva tabela “roditelj”, a druga tabela “dete”. U “roditeljskoj” tabeli mora postojati primarni ključ. U tabeli “dete” mora postojati polje koje će predstavljati određeni slog iz tabele roditelj. To polje se naziva spoljni ključ.

·         Jedan-prema-jedan – slogu iz jedne tabele odgovara tačno jedan slog iz druge tabele i obrnuto. Npr. između tabele LičniPodaci u kojoj bi za neke osobe iz tabele Partneri unosili kućnu adresu i telefon, i tabele Partneri  postojala bi veza jedan-prema-jedan (ovaj odnos se zove specijalizacija). Odnos jedan prema jedan možemo imati i kad jednu tabelu sa mnoštvom kolona podelimo na dve tabele. U ovom slučaju primarni ključ iz jedne tabele povezujemo sa primarnim ključem iz druge tabele.

·         Više-prema-više - jedan slog tabela A ima više zavisnih slogova u tabeli  B i  obrnuto. Primer ovakve relacije bila bi veza između tabela Knjige – Autori: jedan autor može da ima više knjiga, a jedna knjiga može da ima više autora. Za takvu relaciju kreiramo dodatnu tabelu – tabelu veze (npr. AutorKnjiga u našem primeru) koja sadrži parove primarnih ključeva iz obe tabele. Novu tabelu povezujemo sa postojećim tabelama relacijama jedan – prema – više.

Pravila za uspostavljanje veza između tabela

Za uspostavljene veze možemo definisati i dodatna pravila kojima obezbeđuje ispravnost podataka pri unošenju i ažuriranju povezanih tabela. Ova pravila nazivaju se pravila referencijalnog  integriteta i obuhvataju sledeće:

·         Ne može se uneti slog u tabelu “dete” ako ne postoji odgovarajući slog u “roditeljskoj” tabeli.  U našem primeru ne možemo uneti osobu u tabelu Partneri dok ni smo uneli odgovarajuću firmu u tabeli firma.

·         Ne može se izvršiti brisanje sloga iz “roditeljske” tabele ako postoji povezani slog u tabeli “dete”. U našem primeru ne možemo obrisati firmu ukoliko postoje osobe u tabeli Partneri koji pripadaju toj firmi.

·         Ne može se izmeniti slog u tabeli “dete” tako da on nema odgovarajući slog u tabeli “roditelj”. U našem primeru ne možemo uneti novu firmu za postojeću osobu u tabeli Partneri, ukoliko ta firma ne postoji u tabeli Firmi.

·         Ne može se promeniti vrednost primarnog ključa u “roditeljskoj” tabeli sve dok postoji povezani slog u tabeli “dete”.