TEORIJSKE OSNOVE BAZA PODATAKA RAZLIKA IZMEU PLONIH I SLOENIH BAZA PODATAKA Ako elite analizirati podatke koji su strukturirani samo u jednoj tablici koja nije povezana sa drugim tablicama, Excel e biti dobar izbor za vae potrebe. Na alost realne potrebe u praksi nisu uvijek tako jednostavne. Ako su podaci strukturirani u vie tablica koje su u meusobnoj interakciji, npr. tablica kupaca, tablica narudbi, tablica rauna. tada treba razmotriti koritenje naprednijeg, sloenijeg programskog alata za analize kao to je Microsoft Access. Osnovna razlika Excela i Accessa je u nainu modeliranja, strukturiranja i manipuliranja sa podacima. Access je tzv. "relacijska" baza podataka, a tablica u Excelu predstavnik je modela tzv. "plone" baza podataka (eng. "flat database"). to su relacijske baze podataka biti e detaljno objanjeno kasnije. Relacijske baze podataka imaju mnoge prednosti u odnosu na plone baza podataka:

odravanje integriteta podataka, prevenciju redundancije, efikasne mehanizme usporeivanja, filtriranja i pretraivanja podataka.

To ne znai da Excel "naputamo" i da on "ne valja", naprotiv treba nauiti u kojim situacijama treba koristiti koji programski alat i to je jo vanije, kako ih kombinirati da bi postigli maksimalnu efikasnost i produktivnost. Spomenuti emo jo jednu mogunost Excela koja ga na neki nain moe razlikovati od "isto plonih" baza podataka. Excel moe povezati pojedine podatke izmeu vie tablica preko mehanizma formula koje referenciraju elije iz druge tablice. No treba naglasiti da je takav mehanizam povezivanja bitno drugaiji (i "primitivniji") od povezivanja tablica u relacijskoj bazi i da se na taj nain nikako ne mogu realizirati svojstva koje ima relacijska baza. Pojam redundancije Nadoveimo se na prethodnu temu razlike izmeu Excela i Accessa objanjenjem osnovne mane plonih baza podataka redundancijom mogunou zapisa istog podatka na vie mjesta. to je dakle redundancija i koje probleme moe stvoriti? Razmotrimo slijedei primjer:

U Excelovoj tablici vodimo listu izdanih rauna sa stupcima u kojima su naziv tvrtke, adresa tvrtke, grad, drava, broj rauna, datum rauna i iznos rauna. Za neko vremensko razdoblje biti e mnogo sluajeva gdje emo istoj tvrtki izdati vie razliitih rauna. To znai da e se za takve raune u tablici ponavljati svi osnovni podaci tvrtki naziv, adresa itd. to je loe u tome? Na prvi pogled ini se da to nije problem, ali razmotrimo to podrobnije. Prvo, ponavljajui podaci zauzimaju suvian prostor u memoriji, to danas nije tako vano, ali na drugi nain mogu uzrokovati ozbiljnije probleme. to ako takve podatke zapisane na puno mjesta u tablici treba u nekom trenutku promijeniti, odnosno aurirati? Na primjer tvrtka s kojom godinama suraujemo, promijenila je adresu ili naziv. Ima li garancije da emo uspjeno aurirati sva pojavljivanja tih podataka u npr. tablici od desetak tisua redaka? Moemo koristiti funkciju "replace". S druge strane ima li garancije da su kod unosa svakog novog rauna uvijek na isti nain upisani ime i adresa tvrtke ako su podaci dui ili sloeniji? Tada se moe dogoditi da "replace" funkcijom ne auriramo podatke u ba svim recima gdje je to bilo potrebno. Zamislimo da nakon takve promjene elimo filtrirati iz tablice samo raune izdane toj tvrtki. Oni rauni za koje auriranje imena tvrtke nije izvreno, nee biti prikazani! Isto e se dogoditi ako pri unosu rauna nismo uvijek upisali tono isti naziv tvrtke kao u svim prijanjim unosima u odgovarajui stupac. Ovakvih primjera mogli bi navesti jo mnogo zakljuak je da ima puno situacija kada zapis jednog podatka na vie mjesta u bazi podataka moe uzrokovati ozbiljne probleme i dovesti do krivih rezultata u provoenju sloenih analiza. Najgore je to nitko u tim situacijama nije svjestan da su rezultati analize pogreni. Stoga je osnovni cilj naprednijih modela baze podataka od plonog modela eliminirati mogunost redundancije. BAZA PODATAKA definicija: BAZA PODATAKA je skup meusobno ovisnih podataka, spremljenih bez redundancije, koji slue jednoj ili vie aplikacija na optimalan nain, gdje su podaci neovisni od programa kojima se obrauju i gdje postoji kontrolirani pristup do podataka. CILJEVI RAZVOJA BAZA PODATAKA

Fleksibilnost pristupa - doputa se korisniku slobodno "prebiranje" po podacima, dok je to u starijim sustavima baza podataka bilo ogranieno, te se je do podataka dolazilo strogo utvrenim redoslijedom.

Efikasan rad - Operacije se moraju obavljati brzo, posebno za velike baze podataka. Sigurnost - mora postojati zatita od unitenja baze, npr. zbog hardverskog kvara, ali i

neovlatenog mijenjanja podataka. Podeavanje baze i kontrola - Baze podataka trae stalnu brigu: rutinsko odravanje,

praenje performansi i njihovo poboljanje radi efikasnosti, razvoj aplikacija, nadopunjavanje. Ovi se poslovi obavljaju centralizirano od osobe, administratora baze podataka. Administratoru za to slue razna pomagala (alati, programi) a jedno od njih je rjenik podataka (baza o bazi).

FUNKCIJE (zadaci) SUSTAVA ZA UPRAVLJANJE BAZOM PODATAKA Za definiranje baze podataka - jezikom (SQL, DDL) se opisuje shema baze podataka, kao i njena fizika organizacija Funkcije za manipulaciju podacima u bazi (ostvaruju se zasebnim, esto neproceduralnim jezikom) Upravljake funkcije

zatita od neovlatenog koritenja ouvanje integriteta podataka (backup i recovery)

statistiko praenja rada baze ARHITEKTURA BAZE PODATAKA Struktura veine modernih sustava za upravljanje bazama podataka ima polazite u tzv.ANSI/SPARC arhitekturi (American National Standard Institute/Standard Planning and Requirements Comitee), koja sustav dijeli na tri razine: unutranju, konceptualnu i vanjsku. Svaka razina na specifini nain prikazuje objekte u bazi, njihove odnose i operacije nad objektima. Takva hijerarhijska arhitektura omoguuje prirodnu dekompoziciju i efikasni razvoj sustava za upravljanje bazama podataka. Unutranja razina je najnia razina arhitekture, odnosno najblia fizikoj realizaciji baze podataka na odreenom hardveru - predstavlja fiziki zapis baze podataka koji je sukladan opisu na konceptualnoj razini. Konceptualna ili logika razina je model svih informacija (podataka) koje sadri baza podataka. Modelom podataka predstavlja se logika struktura svih podataka u bazi i skup operacija koje korisnik moe izvriti nad tim podacima. Na konceptualnoj razini "vidljivi su svi podaci iz "fizikog" zapisa, samo to je njihov prikaz na vioj razini apstrakcije. Ovakav prikaz moe bitno odstupati od onoga to vidi korisnik, moglo bi se rei da je to stvarno stanje stvari bez programskih ili hardverskih ogranienja. Vanjska razina ili korisniki pogled je opis dijela konceptualnog modela primjeren odreen korisniku, preslikavajui konceptualni model u formu prilagoenu uporabi, odnosno aplikaciji. Za odreenog korisnika iskljuuju se irelevantni podaci kao i podaci do kojih ne smije pristupiti. Pri razvoju sustava baza podataka unutranjom razinom bave se programeri operativnih sustava i programeri tzv. "database engine-a" odnosno sustava za upravljanje bazama podataka. Kod vrlo sloenih i vanih baza podataka (npr. bankovni sustavi) poslovima odravanja na ovoj razini arhitekture bave se tzv. administratori baze. Projektiranje odreene baze podataka zapoinje na konceptualnoj razini. Projektiranjem sloenih baza i opsenih informacijskih sustava bave se specijalisti, tzv. sistem analitiari.

Na radnom mjestu sigurno ete biti u situaciji da radite sa jednom ili vie baza podataka preko razliitih suelja odnosno u ulozi korisnika na vanjskoj razini. Steeno znanje trebati e vam za uspjenu komunikaciju sa sistem analitiarima, kao i za to efikasnije i bre snalaenje i savladavanje rada sa konkretnim informacijskim sustavom odnosno bazom podataka na buduem radnom mjestu.

MODELI BAZA PODATAKA Kroz povijest pa do danas razvijeni su sljedei modeli baza podataka: 1. Ploni model 2. Hijerarhijski 3. Mreni 4. Relacijski 5. Objektno orijentirani U plonom modelu podaci su organizirani i zapisani u obliku samo jedne tablice. To je najjednostavnija struktura od postojeih modela, pa otuda i naziv "ploni" (dvodimenzionalna

ploha reci i stupci u tablici). Kako je ve ranije objanjeno, primjer plonog modela su tablice, odnosno radni listovi u Excelu. U hijerarhijskom modelu podaci su organizirani u strukture oblika stabla, tj. podaci imaju nadreene podatke. Manipuliranje podacima stoga podrazumijeva precizno navoenje kroz hijerarhijske putanje do odreenog segmenta. Kao ilustracija primjera hijerarhijskog modela moe posluiti datoteni sustav na raunalu.

Hijerarhijski model Mreni model Mreni model je proirenje hijerarhijskog modela na nain da jedan podatak moe biti povezan sa vie drugih podataka a ne samo sa sebi nadreenim podatkom. Mreni model moe se predoiti usmjerenim grafom u kojem su vorovi podaci a lukovi meu vorovima definiraju veze meu podacima. Hijerarhijski i mreni model ne ostvaruju meusobnu nezavisnost razina predstavljanja podataka prethodno obrazloene ANSI/SPARC arhitekture. Kod ovih modela na logikoj razini postoji velika koliina informacija o fizikom zapisu i strukturiranju podataka. Nasuprot njima, relacijski model podataka na logikom razini modelira podatke i odnose meu njima relacijama, odnosno tablicama. Jezik za upravljanje podacima je neproceduralan i ne ukljuuje informacije o putanjama kojim se fiziki pristupa podacima. Relacijski model baza podataka je matematiki model temeljen na predikatnoj logici i teoriji skupova. Relacijska baza podataka moe se promatrati kao skup meusobno povezanih tablica u kojima su mehanizmi i preduvjeti povezivanja odreeni pravilima matematikog modela. Veina suvremenih baza podataka temelji se na relacijskom modelu, stoga emo ovom modelu nadalje posvetiti posebno poglavlje.

Relacijski model iroka primjena tzv. objektno orijentiranih programskih jezika potakla je i razvoj objektnog modela baze podataka. Objektna baza podataka kombinira semantiku objektno orijentiranog programskog jezika i mehanizme upravljanja i pretraivanja podataka konvencionalnih sustava baza podataka. Ovdje su sami podaci vrlo sloene strukture, tzv. objekti koji nastaju

izvoenjem programske aplikacije, a uloga baze je da omogui pohranu i ponovo koritenje objekata. Ovaj model moe prikazati izuzetno sloene strukture, ali s druge strane je izuzetno teko realizirati tako efikasne metode filtriranja i pretraivanja kao to ih ima relacijski model. Stoga su razvijeni i tzv. hibridni objektno-relacijski i relacijsko-objektni modeli. RELACIJSKI MODEL BAZE PODATAKA Teorijske osnove relacijskog modela postavio je 1971. god. E.F. Codd sa slijedeim osnovnim ciljevima:

dati teorijske temelje za konzistentno semantiko postupanje s podacima i za rjeenje redundancije (to nije ostvareno mrenim i hijerarhijskim modelom)

omoguiti razvoj skupovno orijentiranih jezika za obradu podataka (relacijska algebra i neproceduralni jezici)

dati bogat model podataka za opis i obradu jednostavnih i kompleksnih podataka - ovaj cilj nije ostvaren na zadovoljavajui nain to je dalo poticaj razvoju objektnih modela baza podataka

Komercijalni proizvodi sustava za upravljanje bazama podataka koji se uvrijeeno nazivaju "relacijske baze" zapravo implementiraju model koji je samo aproksimacija matematikog modela koji je definirao E.F. Codd. Codd je postavio 12 pravila koje treba zadovoljiti da bi se u potpunosti implementirao njegov model, no niti jedna komercijalna aplikacija do danas nije uspjela ispuniti svih 12 pravila. Detaljno objanjenje ovog problema neemo navoditi jer je matematiki previe sloeno. Matematika definicija relacije: Relacija je podskup kartezijevog produkta dvaju skupova. Kartezijev produkt dva skupa je skup ureenih parova gdje je prvi element para uvijek iz prvog skupa, a drugi element uvijek iz drugog skupa.

a1

a2

a3

a4

b1 b2 b3 b4 b5

skup B

sku

p A

R AxB = { (a,b) R | a A, b B }

primjer sa slike :

{a1,a2,a3,a4} {b1,b2,b3,b4,b5} = {(a1,b1), (a1,b2), (a1,b3), (a2,b3), (a3,b2), (a3,b3), (a3,b5), (a4,b1), (a4,b4)}

Matematiki gledano, tablica u relacijskom modelu je zapravo prikaz relacije:

skup A skup B a1 b1 a1 b2 a1 b4 a2 b3 a3 b2 a3 b3 a3 b5 a4 b1 a4 b4

Tablica sa vie stupaca zapravo je viestruki prikaz relacija izmeu elemenata vie skupova. atrikl proizvoda grad Kava Franck Zagreb ips Franck Zagreb Mlijeko Dukat Zagreb Mlijeko KIM Karlovac Kava Anamarija Zagreb Mlijeko Vindija Varadin Rije "relacija", "relacijski" upotrebljava se u terminologiji baza podataka u razliitim kontekstima i treba biti oprezan da ne doe do zabune. Relacijska baza podataka je skup "povezanih" podataka (eng. "related" data). U matematikom kontekstu relacija (eng. "relation") je podskup kartezijevog produkta dvaju skupova. I s tree strane, kada se u relacijskoj bazi povezuju tablice, govorimo o "relaciji" (eng. "relationship") izmeu dvije tablice. Ovo djeluje pomalo zbunjujue, ali to je ve dugo uvrijeena terminologija preuzeta iz engleskog jezika u kojem je ovaj problem razliite uporabe istog pojma jo izraeniji. Daljnji detaljniji prikaz relacijskog modela baze podataka zahtijeva matematike osnove koje su previe sloene i izvan su okvira ovog udbenika. Dalje emo nastaviti sa osnovnim svojstvima relacijskog modela bitnim za koncipiranje i modeliranje konkretnih relacijskih baza u praktinoj primjeni, bez objanjavanja matematikih osnova. Razumijevanje koncepta relacijskog modela bitno je za uenje i uspjean rad sa programom MS Access. Premda se ne kolujete za administratore baze podataka na ovaj nain moi ete bolje komunicirati sa njima, a biti ete u stanju i sami definirati jednostavne strukture tablica i njihovih veza u relacijskoj bazi podataka MS Access. TABLICA U RELACIJSKOM MODELU PODATAKA

Svaka tablica sastoji se od stupaca i redaka. Uvrijeeno je (u terminologiji podruja baza podataka) da se stupci nazivaju poljima (eng. fields), a reci slogovima (eng. records). Analogija polju u relacijskom modelu je elija u Excel-ovoj tablici. Stupci i retci tablice u relacijskom modelu imaju slijedea svojstva:

Svaki stupac (polje) tablice ima svoje ime, pri tome dva stupca u istoj tablici ne mogu imati isto ime. Imena stupaca nalaze se u zaglavlju tablice.

U jednom stupcu tablice mogu postojati samo podaci samo jedne (iste) vrste. (npr. prezime, ime, grad i sl.)

Svi podaci u jednom stupcu (polju) imaju isti, unaprijed definirani format. Uvrijeena je terminologija da se redovi (slogovi) sastoje od polja.

Svako polje moe sadravati samo jedan podatak! Redoslijed stupaca i redaka nije bitan za operacije u bazi podataka

KONCEPTUALNO MODELIRANJE PODATAKA Baze podataka osnovni su softverski elementi informacijskih sustava. Sloeni informacijski sustavi raunalno podravaju sloene transakcijske, komunikacijske, organizacijske i ostale procese i strukture iz realnog svijeta. Pri razvoju i gradnji informacijskog sustava sve pojave i odnose iz realnog svijeta moramo prikazati i modelirati na nain prilagoen raunalnoj obradi. Kako smo ve objasnili ranije time se bave tzv. sistem analitiari oni analiziraju domenu koju e raunalno podrati informacijski sustav te izrauju tzv. konceptualni model podataka to predstavlja srednju razinu ANSI/SPARC arhitekture. U pravilu konceptualni model treba biti neovisan o implementaciji na najnioj razini arhitekture. Danas se u praksi najvie upotrebljava konceptualni model "entiteti veze" (entity-relationship). Taj konceptualni model je vrlo blizak relacijskom modelu baze podataka i relativno se jednostavno preslikava u strukturu tablica i njihovih veza u relacijskoj bazi podataka. Model entiteti veze (entity-relationship)

Ovaj model definira prostor promatranja pomou entiteta, njihovih meusobnih relacija i atributa koji karakteriziraju entitete. Entitet je primarni objekt naeg interesa oko kojeg se skupljaju informacije, to je neto to moe biti posebno identificirano i moe nezavisno egzistirati - posjeduje znaajke koje ga opisuju i po kojima se razlikuje od svoje okoline. Entitet moe biti:

osoba - zaposlenik, uenik, student, ustanova, organizacija ili organizacijska cjelina realni objekt, npr.DVD, auto, stroj apstraktni pojam, npr. status narudbe, poznavanje jezika dogaaj od informacijskog interesa (situacija, stanje) -proli, sadanji ili budui, npr.

roenje, kolovanje, zaposlenje, rezervacija povezanost razliitih objekata stvarnog svijeta, npr. srodstvo

Entiteti su najee imenice. Atributi detaljiziraju entitete, predstavljaju neko obiljeje, znaajku entiteta. Pojedinane vrijednosti atributa pohranjuju se u bazu podataka Atribut je ogranien je na jednu injenicu o entitetu, dok veza moe modelirati kompleksne odnose jednostavnih entiteta. Po vrijednostima koje predstavljaju, atributi mogu biti:

jednostavni -vrijednost atributa je pojedinani podatak, primjer: Prezime, Ime sloeni, sastavljeni atributi - vrijednost je ureena n-torka ili logika grupa

jednostavnih atributa - primjer: datum = (dan, mjesec, godina) Domena atributa je skup moguih vrijednosti koje atributi mogu poprimiti. Primjeri definiranja domene:

tipom podatka, npr. integer (samo cijeli brojevi) intervalom [20-30] skupom konstanti, npr. odgovor = {A,B,C}

Tablica u relacijskom modelu podataka najee predstavlja kolekciju podataka (vrijednosti atributa) razliitih instanci jedne vrste entiteta. Imena stupaca tablice odgovaraju nazivima

atributa tog entiteta, a podaci u jednom retku tablice vrijednosti su atributa pojedinog konkretnog pojavljivanja entiteta. Veza ili relacija (eng. relationship) opisuje (pokazuje) kako su entiteti povezani. Relacija se najee imenuje glagolom ili glagolskom imenicom. Primjeri: tvrtka posjeduje raunalo; pjeva izvodi pjesmu; uenik pohaa kolu. Relacija moe izraavati ulogu entiteta koje povezuje:

Osoba STANUJE u Mjestu (entitet Osoba je STANOVNIK entiteta Mjesto). U Mjestu STANUJE Osoba (entitet Mjesto je MJESTO STANOVANJA)

Prema nainu pridruivanja pojava entiteta razlikujemo tri vste veza:

jedan prema jedan (1:1) (eng. one-to-one) Jedan podatak (atribut) prvog entiteta jednak je najvie jednom podatku (atributu)

drugog entiteta. Imamo, dakle, zapravo dva entiteta sa istim atributima. Ovakav nain zapisa veze se u koncipiranju relacijske baze izbjegava. Ako entitete preslikamo u tablice to znai da smo umjeto u dvije, podatke mogli unijeti i u samo jednu tablicu.

PRIMJER podaci o osobama

jedan-prema-vie (1:N) (eng. one-to-many)

Jedan podatak (atribut) prvog entiteta povezan je s vie podataka drugog entiteta, odnosno svaki podatak prvog entiteta pojavljuje se vie puta u drugom entitetu. Ili gledano s druge strane, vie podataka drugog entiteta jedanko je samo jednom podatku prvog entiteta.

Ovakva veza "prirodna" je za relacijsku bazu podataka i ona se koristi kao osnovni mehanizam gradnje strukture relacijske baze podataka.

PRIMJER RAZRED UENICI u jednom razredu ima vie uenika, ali jedan uenik

pripada samo jednom razredu

vie-prema-vie (M:N) (eng. many-to-many) Jedan podatak (atribut) prvog entiteta povezan je s vie podataka drugog entiteta,

ali istovremeno svakom podatku drugog entiteta odgovara vie podataka prvog entiteta.

Preslikano na tablice koritenje takvih tablica je problematino, jer je povezivanje neodreeno (nije jednoznano). Ovaj problem rjeava se tako da se kreira "dodatna" tablica koja e definirati tono to je sa ime povezano.

PRIMJER PREDMETI NASTAVNICI jedan predmet predaje vie nastavnika, a jedan

nastavnik predaje vie predmeta

KLJU (KEY) ILI IDENTIFIKATOR Neki atributi ili skupovi atributa svojim vrijednostima jednoznano identificiraju svaki od entiteta u nekom skupu entiteta. Primjer takvog atributa je OIB osobni identifikacijski broj koji je razliit i jedinstven za svaku osobu u dravi. Svi atributi nemaju to svojstvo. Ukoliko niti jedan atribut nekog entiteta nema svojstvo jednoznane identifikacije tada dodajemo razliite ifre ili redne brojeve. Takve atribute nazivamo kljuevi. Klju mora zadovoljavati sljedee uvjete:

jednoznanost (u skupu entiteta ne smiju postojati dvije pojave s istim vrijednostima kljua)

odreenost za svaku instancu entiteta mora postojati vrijednost kljua stabilnost treba biti "otporan" na promjene tijekom vremena idealno bi bilo da se

kao podatak uope ne mijenja za sve vrijeme postojanja zapisa u bazi

raspoloivost treba biti dostupan svim korisnicima Jedan entitet moe imati jedan ili vie kljueva, ali ako nema niti jedan atribut koji ima svojstvo kljua, tada je gotovo uvijek potrebno dodati neku novu ifru ili jednostavno redni broj. Ako entitet ima samo jedan klju, (bilo jedan od atributa ili naknadno dodanu jednoznanu ifru) u najveem broju sluajeva taj klju koristiti e se kao tzv. primarni klju. Ako entitet ima vie kljueva, jedan od njih izabrati e se za primarni klju. to je to primarni klju? Primarni klju (eng. primary key) je posebna vrsta kljua koji se koristi za povezivanja tablica u relacijskom modelu podataka. U svakoj tablici se samo jedan klju moe oznaiti kao primarni klju. U popisu stupaca tablice primarni klju se obino oznaava podebljanim ili podvuenim slovima. Ako ne odredimo drugaije, u veini sustava baza podataka reci tablice se sortiraju prema primarnom kljuu. Strani klju (eng. foreign key) je atribut koji ukazuje na povezanost izmeu razliitih entiteta, odnosno skupova entiteta. Dakle to je atribut ije se vrijednosti odnose na vrijednosti kljua drugog entiteta, odnosno strani klju moe poprimiti vrijednost primarnog kljua drugog entiteta. Na taj nain ostvaruje se veza izmeu tablica u relacijskom modelu i ujedno se eliminira redundancija podataka. Vano je napomenuti da se nakon uspostavljanja veze izmeu primarnog i stranog kljua prilikom upisa podataka u stupac stranog kljua ne zapisuju ponovno vrijednosti podataka primarnog kljua nego se zapisuje "pokaziva" na redak u tablici primarnog kljua s kojim je odgovarajui redak iz tablice stranog kljua povezan. Na taj nain eliminirana je redundancija podatak u stranom kljuu ne zapisuje s ponovno "fiziki" u drugu tablicu baze, u polju podatka zapisana je zapravo "memorijska adresa" polja u primarnom kljuu na kojoj je podatak samo jedanput fiziki zapisan. Kako jedan primarni klju moe biti povezan sa vie stranih kljueva, kada jednom eventualno promijenimo podatke bilo u primarnom kljuu ili u drugim poljima tablice primarnog kljua, nema problema sa auriranjem u poljima povezanih stranih kljueva jer ona i dalje "pokazuju" na istu adresu, odnosno na isti redni broj retka u tablici primarnog kljua. Povezivanjem primarnog i stranog kljua dviju tablica realiziramo modeliranje i zapisivanje relacije "jedan prema vie" u relacijskom modelu baze podataka. RELACIJA JEDAN PREMA VIE Nakon definiranja kljueva vratimo se jo na detaljnije objanjenje relacije "jedan prema vie", osnovnom "mehanizmu funkcioniranja i strukturiranja" relacijske baze podataka. Relacijom "jedan prema vie" povezujemo stupce dviju tablica u relacijskoj bazi sa svrhom eliminiranja redundancije i osiguranja automatskog auriranja i integriteta podataka. Povezujemo jedan stupac "prve" tablice sa jednim stupcem "druge" tablice, pri tome se u odgovarajuem stupcu druge tablice nalazi vie podataka koji su jednaki jednom i samo jednom podatku u stupcu prve tablice. Pri uspostavljanju relacije vrijede pravila:

Podaci u prvoj tablici moraju biti jednoznani - stupac prve tablice mora biti primarni klju.

Primarni i vanjski klju moraju imati isti format podataka. Ovisno o sustavu baze podataka moemo uspostaviti tzv. kontrolu referencijalnog

integriteta (eng. referential integrity): Izmjenom podatka u primarnom kljuu promijeniti e se odgovarajui podaci u

stranom kljuu, brisanjem retka u tablici primarnog kljua, obrisati e se svi reci tablice stranog kljua koji imaju istu vrijednost

Prilikom upisa u polje vanjskog kljua, provjerava se da li taj podatak ve postoji u primarnom kljuu. (Novi podatak moramo prvo upisati u primarni klju, pa ga tek onda moemo upisati u vanjski klju.)

Jedna tablica moe imati vie vanjskih kljueva, ali samo jedan primarni klju. Pri viestrukom povezivanju vie tablica, jedan primarni klju moe biti povezan sa vie vanjskih kljueva drugih tablica.

INDEKSIRANJE Pomou indeksa moemo redove tablice sloiti prema podacima u odreenom stupcu. Indeks moe biti uzlazni (Ascending) ili silazni (Descending). Moe obuhvaati jedan stupac ili vie stupaca. Svaka tablica moe imati vie indeksa, a svaki indeks mora imati drugo ime. Pretraivanje podataka ubrzavamo indeksiranjem. Provjeravanjem, da li podatak koji elimo upisati ve postoji u indeksu, moemo sprijeiti ponovni upis istog podatka. Takav indeks koji dozvoljava upis podatka samo jednom nazivamo UNIQUE (jedinstveni). LOGIKO MODELIRANJE PODATAKA Konkretni konceptualni modeli pojedinih baza podataka izvedeni "entity-relatinship" metodologijom prikazuju se posebnim dijagramima koji imaju propisan izgled i znaenje simbola. Kada sistem analitiari definiraju model u obliku entiteti-veze na temelju analize stvarnog stanja i zahtjeva postavljenih za razvoj baze podataka, prelazi se na pretvorbu takvog konceptualnog modela u logiku shemu baze podataka. Logika shema ukljuuje definiranje strukture tablica u bazi i veza izmeu pojedinih polja (stupaca tablica). Logika shema se dalje dorauje ako to proizlazi iz specifinih zahtjeva za obradom podataka - npr. distribuiranje baze, poveanje brzine rada itd. KORITENJE PROGRAMA MICROSOFT ACCESS Kako je ranije reeno sustav za upravljanje bazom podataka je skup raunalnog softvera koji prua suelje izmeu korisnika i jedne ili vie baza podataka. Program Access predstavlja upravo takav raunalni softver, suelje. Kreiranje baze podataka u Accessu nije tako jednostavno kako to moda na prvi pogled izgleda. Nije dovoljno samo unositi podatke u tablice, nego je potrebno razumjeti i savladati teoretske osnove relacijskog modela baze podataka na to smo se usredotoili u prethodnom poglavlju. Ako samostalno kreirate novu bazu podataka, iznimno je vano kako ete isplanirati i izgraditi njezinu strukturu, odnosno definicije tablica i veza izmeu njih, jer to ima dalekosene posljedice na uinkovitost, produktivnost i mogunosti analize podataka u cijelom daljnjem ivotnom ciklusu nove baze podataka. Mnogi sloeni projekti razvoja informacijskih sustava u praksi propadaju zbog greaka u poetnoj fazi konceptualnog modeliranja baze podataka. U ovom ete poglavlju nauiti osnovne tehnike i postupke definiranja tablica i njihovih veza, kao i postupke kreiranja jo nekih vanih objekata u bazi podataka, poput upita, formi i izvjetaja. OBJEKTI U RELACIJSKOJ BAZI PODATAKA Za uvod navesti emo ukratko koje su to vrste objekata, a kasnije emo detaljnije objasniti svaku od njih.

Tablice (Tables) su osnovni elementi relacijske baze podataka. U tablice se unose i pohranjuju svi podaci te se auriraju. Upiti (Queries) slue za pregledavanje, pretraivanje i manipuliranje podacima. Ulazni formulari (Forms) su grafika suelja za unoenje podataka i manipuliranje njima. Izvjea (Reports) slue za formatirano, grupirano i razvrstano ispisivanje podataka. Moduli i makro naredbe (Modules, Macros) dva su naina razvoja programskih aplikacija kao nadogradnje na pojedinu bazu podataka. Stranice (Pages) su web-stranice koje slue kao suelje za unos podataka i rad s bazom podataka preko Interneta i/ili lokalne raunalne mree Tablica (Table) Tablice su osnovni elementi relacijske baze podataka. U tablice se unose, pohranjuju i auriraju svi podaci. elija tablice slui samo za pohranu podatka, procesi filtriranja, raunanja i sl. odvijaju se na drugim mjestima a ne u tablici kao to je sluaj sa Excelom. Na taj nain podaci su odvojeni od procesa njihove obrade i rezultata obrade. Podaci su uvijek pohranjeni u izvornom ("sirovom") obliku neovisno o tome na koji nain i kojim programskim alatom emo ih analizirati ili prezentirati. Bitna svojstva tablice u relacijskom modelu podataka navedena su ve ranije. Ponovo emo napomenuti da treba nastojati da jedna tablica sadri podatke o jednom entitetu npr. kola, nastavnik, uenik, itd. Ve je ranije reeno da podaci u jednom stupcu tablice moraju biti istog tipa (vrste). Kao uvod u postupak definiranja tablice, navodimo mogue vrste podataka u Accessu.

Tekst (Text) tekstom se smatra bilo koja kombinacija slova, brojki i ostalih znakova. Veliki dio podataka tekstualnog je tipa. Broj se moe zapisati i kao tekst, ali s takvim se podatkom ne mogu izvoditi aritmetike operacije. Duina zapisa moe se odrediti za svaki tekstualni podatak pojedinano, no treba imati na umu da je maksimalna duina zapisa tekstualnog podatka 255 znakova.

Dopis (Memo) je takoer podatak tekstualnog tipa, ali maksimalne duine 64 KB. Slui za pohranu objanjenja, komentara i slinih duih tekstova.

Broj (Number) slui za sve numerike vrijednosti koje e trebati razvrstati i nad kojima e se provoditi aritmetike operacije. Izuzetak je brojani tip podatka valuta (engl. currency), koji se tretira na poseban nain. Numeriki tip podatka ima sljedee podvrste: Byte, Integer, Long Integer, Single, Double, Replication ID i Decimal. Integer i Long Integer upotrebljavaju se ako se oekuje da e svi podaci tog tipa imati samo cjelobrojne vrijednosti, a Single i Double za realne (decimalne brojeve). Za decimalne se brojeve moe dodatno definirati format zapisa i broj decimala.

Datum / Vrijeme (Date / Time) i ovaj se tip podataka esto upotrebljava pri kalkulacijama i razvrstavanju. Manipulacija s podacima tipa datum/vrijeme omoguava razne komparacije i analize po tjednima, mjesecima, godinje itd. Pri upisu ove vrste podatka treba se pridravati definiranog formata s obzirom na redoslijed - dan, mjesec, godina, sat, minuta te s obzirom na broj znakova za svaki dio zapisa i simbol koji odvaja pojedine dijelove zapisa datuma.

Valuta (Currency) je brojani tip podatka koji sadri i oznaku valute. Upotrebljava se iskljuivo za raunske operacije s novanim iznosima.

Samonumeriranje (AutoNumber) je cijeli broj koji se automatski poveava za jedan pri dodavanju novog retka u tablicu. Korisnik ne moe unositi podatke u ovo polje, jer to program radi automatski. Na taj se nain osigurava da svaki redak dobije jedinstveni broj to se koristi u sluajevima kada niti jedan od atributa nekog entiteta nema svojstva kljua. Ako pri kreiranju nove tablice ne odaberete niti jedan stupac kao primarni klju, Access e prilikom spremanja tablice sam ponuditi definiranje novog

stupca (polja), tipa AutoNumber, i pitati elite li postaviti takvo polje kao primarni klju.

Logiki podaci - Da/Ne (Yes/No) - podaci ovog tipa mogu poprimiti samo jedno od dva mogua stanja: ili Da ili Ne, odnosno istina ili la. Ovaj podatak analogan je logikoj varijabli u programskim jezicima.

Objekt (OLE Object) upotrebljava se kada u bazu treba spremiti binarni zapis datoteke - gotovi grafiki, video ili audiozapis preuzet iz neke druge aplikacije. To mogu biti i Word, Excel ili PowerPoint dokumenti. Treba paziti da nemamo previe ovakvih objekata spremljenih u bazi jer e se veliina datoteke koja sadri bazu podataka znatno poveati.

Hiperveza (Hyperlink) URL adrese web-stranica ili stranica na lokalnom raunalu ili lokalnoj mrei. Klikom na njega otvorit e se stranica na koju pokazuje.

arobnjak za traenje (Lookup Wizard) daje mogunost unosa podatka iz liste zadanih vrijednosti. Vrijednosti u listi upisuju se posebno ili uzimaju iz odabranog polja neke druge tablice.

Upit (Query) slui za pregledavanje, pretraivanje i manipuliranje s podacima. To je zapravo pitanje koje postavljamo prema podacima u bazi npr. kolika je bila prodaja jedne vrste artikla na odreenom podruju o odreenom vremenskom razdoblju. Pokretanjem upita uvijek se kreira nova tablica koja prikazuje rezultate. Takve tablice stvaraju se dinamiki, tj. one se ne spremaju trajno u bazu podataka. U bazu podataka kao novi objekt trajno se sprema samo definicija upita. Treba naglasiti da u definiciji upita moemo kombinirati podatke iz vie povezanih tablica. U Accessu upit se jednostavno definira preko grafikog suelja ime se zapravo formira naredba programskog jezika SQL o emu e biti vie rijei kasnije. Jednom spremljena definicija upita moe se kasnije mijenjati i doraivati. Stanje podataka u tablicama baze stalno se mijenja dodaju se novi podaci i eventualno mijenjaju postojei. Spremljeni upiti mogu se pokrenuti u svakom trenutku kada elimo dobiti rezultate neke analize nakon promjene podataka u bazi kroz odreeni vremenski period. Ovakvom koncepcijom permanentno su odvojeni zapisi podataka od sredstava za njihovu analizu. Razliiti kriteriji u upitu mogu se postavljati uporabom operatora navedenih u slijedeoj tablici:

Svi navedeni operatori osim like i not mogu se primjeniti na podatke brojanog tipa, a neki od njih na podatke tekstualnog tipa i na podatke tipa datum/vrijeme. Aritmetiki operatori (prvih est u tablici) na podatak tekstualnog tipa primjenjuju se u smislu sortiranja po abecedi npr. >Ivica znai svi koji su po abacedi iza Ivice. Operator between znai uzmi sve izmeu zadanih granica npr. between 10 and 50, between Osijek and Split - svi gradovi po abecedi

izmeu Osijeka i Splita. Operator not znai svi osim navedenog npr. not Zagreb - svi gradovi osim Zagreba. Operator like upotrebljava se za tekst npr. Like P* znai svi podaci koji poinju sa slovom P. Posebna vrsta kriterija je Is Null i Is Not Null - pomou njih pitamo da li podatak postoji ili ne: Da li je polje prazno? - Is Null - znai izdvoji sva prazna polja. Da li je podatak upisan? - Is Not Null - znai izdvoji sva polja u kojima postoji podatak. Ulazni formular (Form) je grafiko suelje za unoenje podataka i za manipuliranje sa podacima. esto je nepregledno unositi nove podatke u tablicu koristei jednostavni pogled na tablicu u obliku redaka i stupaca. U relacijskoj bazi sve bi tablice trebale biti meusobno povezane preko primarnih i stranih kljueva. To znai da su este situacije kada pri unosu novih podataka u polje stranog kljua trebamo unijeti podatke koji ve postoje kao primarni klju u drugoj tablici. Da bi olakali unos tada moemo takve podatke prikazati u obliku "padajuih" listi na formi. Forme je uputno koristiti pogotovo kada trebamo podatke unositi u vie tablica baze istovremeno. Pored olakavanja unosa podataka na formama koristimo i grafike elemente s kojima moemo pokrenuti dijelove programskog koda koji e u bazi obaviti sloenije transakcije. Na slici je prikazan primjer jedne forme iz baze podataka Northwind.mdb. Ova datoteka moe se "downloadati" sa Microsoft-ovih slubenih stranica, a bila je i sastavni dio instalacije ranijih verzija Access-a. Datoteka je primjer baze podataka koja podrava poslovanje trgovakog drutva za opskrbu restorana. Za one koji ele znati vie korisno je prouiti ovu bazu i pokuati raditi s njom.

PRIMJER FORME

Izvjee (Report) slui za formatirano, grupirano i sortirano ispisivanje podataka. Temelj svakog izvjea je ili neka od tablica iz baze ili rezultat upita (koji je opet u obliku tablice). Tablini prikaz podataka esto je nepregledan pogotovo kod veih tablica, esto postoji potreba da podatke grupiramo po odreenim kategorijama pa unutar kategorija sortiramo. Razliite razine prikaza potrebno je istaknuti, dodati naslove, staviti razliite fontove i veliinu slova, itd. Sve se to moe napraviti u izvjeima, dakle izvjea su alat za oblikovanje preglednih filtriranih, grupiranih i sortiranih ispisa podataka iz baze. Filtriranje podataka rjeava se upitima rezultat upita je tablica u kojoj su samo oni podaci koji nas trenutno zanimaju. Ve smo ranije rekli da se u upitu mogu kombinirati podaci iz vie tablica. Da zakljuimo, izvjea su zapravo konani rezultat rada s bazom podataka, ono to kao

dokument izlazi "van" za potrebe krajnjih korisnika baze podataka. Primjer izvjea s kojim ste se svi susreli je mjeseni izvod transakcija po tekuem raunu u banci. Podaci su izdvojeni samo za jedan tekui raun, sa ispisom svih podataka o korisniku rauna u zaglavlju. Sve transakcije su ispisane sortirane po datumu, ali pri tome su iz cjelokupne baze podataka u banci filtrirane samo transakcije za jedan raun i za period od jednog mjeseca.

PRIMJER IZVJEA

Moduli i makro-i (modules, macros) dva su naina razvoja programskih aplikacija kao nadogradnje na pojedinu bazu podataka. Iako Access ima mnogo funkcija i "arobnjaka " koji olakavaju i pojednostavljuju rad, kod razvoja sloenih baza podataka potrebno je dodatno programiranje da bi se realizirali svi zahtjevi i zadae koje sustav baze podataka treba ispuniti. Makro-i slue za automatiziranje postupaka koje treba esto ponavljati ili koje neki od korisnika baze ne znaju samostalno napraviti. Moduli su dijelovi programskih aplikacija koje se razvijaju u Visual Basic-u. U kombinaciji s grafikim elementima na formama, koritenjem makro-a i dodatnih aplikacija napisanih u Visual Basic-u moe se postii visoka razina zatite od nehotinih greaka kao i visoka razina automatizacije u svakodnevnom radu s bazom onih korisnika koji preteno unose podatke i pokreu transakcije. Stranice (pages) to su web stranice koje slue kao suelje za unos podataka i rad s bazom podatka preko Interneta i/ili lokalne raunalne mree.