Baza podataka kao podsistem marketing informacionog …apeironsrbija.edu.rs/Centar_za_izdavacku_djelatnost/Radovi/Specij... · Baza podataka kao podsistem marketing informacionog

UNIVERZITET APEIRON BANJALUKAFAKULTET INFORMACIONIH TEHNOLOGIJA

Inženjering informacionih tehnologijaSpecijalistički studij

Baza podataka kao podsistem marketinginformacionog sistema

(specijalistički rad)

Mentor: prof.dr. Zoran Avramović Kandidat: Refik Mehanović- 2008 -

Baza podataka kao podsistem marketing informacionog sistema

2

1. Uvod

U savremenim tržišnim uslovima kao vrlo važan faktor uspješnog poslovanje pokazalo se

efikasno praćenja marketing okruženja. Praćenjem marketing okruženja uprava može spoznati

želje potrošača, konkurentske akcije, promjene koje nastaju u kanalima distribucije i slično. Da bi

se vršilo praćenje svih informacija koje dolaze iz marketing okruženja preduzeće mora iznaći način

prikupljanja i praćenja ovih informacija a to se postiže upotrebom marketing informacionih

sistema.

Savremeno poslovanje je dovelo do velike potrebe prikupljanja marketing informacija iz tri

osnovna razloga:

- Prenošenje marketinga sa lokalnog na nacionalni i globalni nivo

- Prelaz iz praćenja potreba kupaca prema praćenju želja kupaca, jer kupci s povećanjem

prihoda postaju izbirljiviji pri odabiru robe.

- Prelaz sa konkurencije cijenama na necjenovnu konkurenciju

Novi informacijski zahtjevi su praćeni razvojem informacionih tehnologija (uključujući i

razvoj sistema za upravljanje bazama podataka) ali bez obzira na to mnogim kompanijama

nedostaje informaciona sofisticiranost. Neka preduzeća ne posjeduju odjeljenja za istraživanje

tržišta iako je praćenje sadašnje i prognoza buduće tražnje jedan od važnih preduslova uspješnog

poslovanja.

Podaci predstavljaju vrlo važan resurs preduzeća, te je neophodno da budu sistematizovani,i

organizovani, a to se postiže izgradnjom baze podataka korištenjem nekog od sistema za

upravljanje bazama podataka. Iako su sistemi za upravljanje bazama podataka postojali dosta

ranije efikasna upotreba ovih sistema je zabilježena tek u posljednih 20 godina.

Ovaj rad sadrži osnovne informacije o marketing inofrmacionim sistemima i bazi podataka

kao podsistemu marketing infromacionh sistema. Također je naveden praktični primjer marketing

baze podataka za preduzeće koje se bavi prodajom.


3

2. Marketing informacioni sistem

Aktivnosti koje čine marketing kao poslovnu funkciju su brojne, raznovrsne i međusobno

povezane. Marketinško odeljenje preduzeća mora utvrditi postojanje tržišta, veličinu, specifičnosti

i navike kupovine koje na njemu vladaju. Na osnovu informacija do kojih se tom prilikom dolazi,

odeljenje za istraživanje i razvoj kreira najbolji mogući proizvod za ciljno tržište. Marketing

odeljenje nakon toga mora odrediti cijenu, distribuciju i plan promocije za lansiranje datog

proizvoda. Na kraju, ono prati rezultate preduzetih aktivnosti i preduzima korektivne mjere,

ukoliko je to potrebno. Na taj način, marketing aktivnosti počinju prije pojave proizvoda i

nastavljaju se dugo nakon njegove prodaje, prateći stalno šta se događa na tržištu i neprestano

tražeći puteve za povećanje stepena zadovoljenja potreba potrošača. Da bi svaki dio marketing

mozaika ispunio svoj zadatak i bio adekvatno uklopljen u jedinstvenu celinu, potrebne su

marketing informacije i adekvatan marketing informacioni sistem.

Marketing koncepcija je koncepcija upravljanja i rukovođenja, koja poslovne odluke donosi

na bazi prethodno izraženih potreba i želja kupaca/korisnika, mogućnosti tržišta, intenziteta uticaja

okruženja, kao i utvrđenih resursnih mogućnosti za zadovoljavanje zahtjeva tržišta kompletnije od

konkurencije. Savremeni marketing informacioni sistem plod je sistemskog pristupa koncepcije

marketinga u istraživanju budućih kretanja na tržištu, integralne upotrebe instrumenata marketing

miksa, tekuće kontrole i revizije ostvarenih rezultata na tržištu i preduzeću i razvoja informacione

tehnologije.

Ako se ima u vidu domen i područje primjene marketinga, marketing informacioni sistem

se može definisati na sljedeći način:

„ Marketing informacioni sistem čini kontinuiran i interaktivan spoj ljudi, opreme i

postupaka koji primjenom određenih modela i metoda, radi prikupljanja, razvrstavanja, analize,

procjene i distribucije prikladnih i pravovremenih informacija, stvara osnovu za upravljanje i

regulisanje poslovnih odluka. ”


4

Najviše citirana definicija MIS-a je sledeća:

„ Marketing informacioni sistem je strukturiran, interaktivan kompleks osoba, mašina i

postupaka oblikovan za produkciju uređenog toka relevantnih informacija prikupljenih iz

unutrašnjih i spoljašnjih izvora kompanije, koje se koriste kao osnova za donošenje odluka u

određenim oblastima nadležnosti upravljanja marketingom”.

Razvoj marketinških istraživanja u pravcu MIS-a omogućio je :

§ da se tržišna istraživanja orijentišu na potrebe marketing menadžmenta za

informacijama

§ da se prikupljanje eksternih informacija vrši kontinuirano

§ da se organizuju ukupne informatičke aktivnosti u marketingu

Dakle, perspektiva MIS-a treba da bude takva da se jasno vidi da tražnja za informacijama i

ponuda informacija predstavljaju međusobno zavisan sistem, koji može da bude uspješan samo ako

je prikupljanje informacija orijentisano na potrebe menadžmenta za njima. Takođe, treba naglasiti

da MIS doprinosi otklanjanju situacije u kojoj se najčešće kontinuirano prikupljaju samo interne

informacije, dok se prikupljanje eksternih informacija prepušta ad-hoc marketinškom istraživanju

sa definisanim početkom i krajem, koje se tiče određenog projekta. MIS treba da bude strukturiran

tako da se procesi odlučivanja podržavaju organizovanim tokom relevantnih informacija iz izvora

koji se nalaze u preduzeću i van njega.

Može se reći da mnoga preduzeća još uvek nisu dovoljno shvatila značaj upravljanja

informacijama za djelotvoran marketing u savremenoj tržišnoj privredi. Postoje razlozi koji, sada

više nego ranije, zahtjevaju upravljanje marketinškim informacijama i razvoj marketinških

informacionih sistema Neki od najznačajnijih razloga su :

§ Informaciona eksplozija. - Ocenjeno je da je za poslednjih deset godina svjetska

akumulacija znanja udvostručena.

§ Rastuća kompleksnost poslova i okruženja preduzeća.- Diverzifikacija proizvodnje,

širenje dimenzija tržišta, suočavanje preduzeća sa sve oštrijom konkurencijom na


5

domaćem i međunarodnom tržištu i veća probirljivost kupaca zahtjevaju bolje

informacije da bi se poslovima dobro upravljalo.

§ Rast preduzeća. – Ako rast preduzeća nije praćen razvojem marketinškog

informacionog sistema, onda postoji realna opasnost da postojeće marketinške

informacije budu toliko "raspršene" da ih nije moguće praktično upotrebiti.

§ Brzina kojom treba donositi odluke se povećava. – Porast tržišne dinamike dovodi

do toga da je potrebno donositi odluke u sve kraćim vremenskim intervalima, a to

nameće potrebu sve češćeg korištenja odgovarajućih marketinških informacija.

§ Skraćivanje životnog ciklusa proizvoda (i porast smrtnosti proizvoda) zahtjeva

vješto upravljanje da bi se izvukao što veći profit u raspoloživom „redukovanom”

vremenu, a to, pak, zahtjeva bolje marketinške informacije.

§ Primjena modelskog pristupa u upravnjanju marketingom. – Primjena savremenih

kvantitativnih modela donošenja marketinških odluka o cijenama, promociji,

distribuciji i dr. zahtjeva veću količinu informacija (podataka) nego tradicionalni

pristupi upravljanju marketingom.

§ Korištenje prednosti nove informatičke tehnologije. – Mada računar nije neophodan

marketinškom informacionom sistemu, razvoj hardvera i softvera, koncepta baze

podataka i komunikacionih tehnologija omogućio je korištenje određenih metoda i

modela koji se ranije, bez računarskih resursa, nisu mogli koristiti. Jedna od

najinteresantnijih implikacija nove informatičke tehnologije jeste da baza podataka

može biti distribuirana-decentralizovana do tačaka i mjesta gdje se donose odluke.

Svako preduzeće treba organizovati tok informacija do marketing menadžera. Preduzeća

istražuju potrebe svojih menadžera za informacijama i stvaraju marketing infomaione sisteme kako

bi se te potrebe zadovoljile.

«Marketing informacioni sistem se sastoji od ljudi, opreme i postupaka potrebnih za

prikupljanje, sortiranjem analiziranje, vrednovanje i distribuciju potrebnih, pravovremenih i tačnih

informacija do onih koji donose odluke o marketingu.» (Philip Kotler)

Da bi izvršili svoje analize, planiranje, primjenu i kontrolu odgovornosti, menadžeri

marketinga trebaju informacije o događajima iz marketing okruženja. Uloga marketing


6

informacionog sistema je ispunjavanje potreba menadžera za informacijama, razvoj potrebnih

informacija i pravovremena distribucija informacija do menadžera marketinga. Potrebne

informacije se procesiraju putem internih izvještaja preduzeća, aktivnostima marketinškog

obavještavanja, istraživanje tržišta i analizu podrške marketnig odluka. Iz ovoga slijedi da su

komponente MIS-a:

1. Sistem internog izvještavanja

2. Sistem izvještavanja u marketingu

3. Sistem marketing istraživanje

4. Sistem podške za donošenje marketing odluka

1. Sistem internog izvještavanja

Sistem internog izvještavanja predstavlja osnovni sistem informacija kojim se služe manadžeri

marketinga. U njega su uključeni

- izvještaji o narudžbama

MenadžeriMarketinga

Analiza

Planiranje

Primjena

Kontrola

Okruženjemarketinga

Kanalimarketinga

Konkurenti

Javnost

Snage

Makrookruženje

Određivanjepotreba za

informacijama

Distribucijainformacija

Interniizvještaji

Analizapodatakai mark.odluke

Mark.izvještav

anje

Mark.Istraživ.

Marketinške odluke i komunikacija


7

- izvještaji o prodaji

- izvještaji o cijenama

- izvještaji o visini zaliha

- izvještaj o ulazima

- izvještaji o plaćanju

- ...

Analizom ovih izvještaja mogu se otkriti bitne mogućnosti i problemi. Pri ovoj analizi je

vrlo bitno posebno praćenje ciklusa od narudžbe do plačanja. Preduzeća trebaju aktivnosti iz ovog

ciklusa obavljati brzo i tačno jer kupci preferiraju one dobavljače koji robu ispostavljaju na

vrijeme. Mnoge kompanije danas koriste sistem razmjene elektronskih informacija (EDI –

electronic data interchange) da bi poboljšale vrzinu, tačnost i djelotvornost ovog ciklusa.

Sistem izvještaja o prodaji treba da obezbjede tačne informacije o trenutnom stanju prodaje.

Informacione tehnologije su jako doprinjele na brzini i efikasnosti ovog sistema čime marketing

menadžeri imaju sveoubuhvatne i tačne podatke o prodaji.

2. Sistem izvještavanja u marketingu

Za razliku od internog sistema podataka koji obezbjeđuje podatke o rezultatima sistem

izvještavanja u marketingu obezbjeđuje podatke o onome što se tenutno dešava. Njega čine

postupci i izvori koje koriste menadžeri kako bi dobili svakodnevne informacije o stalnim

događanjima u okruženju marketinga.

Poboljšanje kvaliteta i kvantiteta marketing uizvještavanje se provodi :

- motivacijom prodajnog osoblja da izvještavaju o novim događajima

- motivacijom distributera, trgovaca i drugih posrednika da dostavljaju važne informacija

- kupovanjem informacija od vanjskih dobavljača

- uspostavom internog centra marketing informacija za prikupljanje i prosljeđivanje

marketing informacija.

3. Sistem marketing istraživanja


8

Marketing istraživanje je sistemsko oblikovanje, prikupljanje, analiza i izvještavanje o podacim

ai nalazima bitnim za određenu marketinšku situaciju s kojom je preduzeće suočeno. Marketing

istraživanje se obično provodi unutar posebnog odjela marketinga, a rezultate dostavljaju

marketing menadžeru. Ukoliko preduzeće ne može organizovati vlastito odjeljenje za marketing

istraživanja, može kupiti usluge preduzeća specijalizovana za marketing istraživanja.

Proces marketing istraživanja se provodi u pet faza

1. Definisanje problema i ciljeva istraživanja

2. Razvoj plana istraživanja

3. Prikupljanje informacija

4. Analiziranje informacija

5. Prezentacija rezultata

Kvalitetno marketing istraživanje karakteriše

- korištenje naučnih metoda

- kreativnost istraživanja

- multiple metode

- međuzavisnost modela i podataka

- vrijednost i cijena informacija

- zdravi skepticizam

- etički marketing

4. Sistem podrške donošenju marketing odluka

Sve veći broj ogranizacija korisiti sisteme za podršku odlučivanju (DSS decision suport

system) u svim funkcijama poslovanja pa tako i u marketingu. Za potrebe marketing odlučivanja

izdvaja se posebna grupa DSS sistema a to su MDSS (marketing descision support system).

MDSS predstavlja koordinirano skupljanje podataka, sistema, alata i tehnika korištenjem


9

informacionih resursa (hardware i software) kojim kompanija prikuplja relevantne informacija iz

poslovanja i okruženja te ih pretvara u bazu marketinške akcije.

MIS kao komparativna prednost

U tržišnim uslovima privređivanja, od preduzeća se zahteva da svoju misiju ostvaruje na

zadovoljstvo korisnika njegovih proizvoda i usluga. U skladu sa tim, uspjek kompanije je u jako

određen sposobnošću da otkriva nove potrebe potrošača i iste zadovoljava bolje od svojih

konkurenata. Marketing informacioni sistem se nalazi između okruženja, u kojem su sadržane

šanse i opasnosti, i menadžera, koji na bazi podataka o stanju i uticaju faktora iz eksterne sredine i

informacija o internim mogućnostima, preduzimaju odgovarajuće marketing aktivnosti. Upravo

zahvaljujući dobro razvijenom MIS-u, koji predstavlja čvorišnu tačku u kojoj se ukrštaju

informacije iz različitih izvora, preduzeće je u mogućnosti da na anticipirane potrebe odgovori brže

i kvalitetnije od konkurencije i po tom osnovu ostvari profit.

Obzirom na kompleksnost i obuhvatnost marketing odluka, vrlo je teško predvidjeti

količinu i vrstu informacija koja je za njihovo donošenje potrebna. Marketari često raspolažu

velikom količinom nerelevantnih i malim brojem korisnih informacija. Dešava se da se podaci

gomilaju na nekom mjestu u preduzeću i ne koriste se za ono čemu su namjenjeni ili se ne

prosljeđuju tamo gdje su potrebne. Da bi se ovi problemi prevazišli, marketing menadžeri moraju

pri koncipiranju MIS-a odrediti kakve informacije žele da dobiju, prije nego što donesu odluku o

iulaznim podacima koji se uz pomoć MIS-a tranasformišu u relevantne informacije.

Uspješan MIS se ne može spontano razvijati, već mora biti planski organizovan u skladu sa

organizacionom strukturom marketing sektora i samog preduzeća. S obzirom na uobičajene otpore

zaposlenih na svaku promjenu organizacije, treba izvršiti obuku u cilju prihvatanja jednog

savremenog MIS-a i brojnih pozitivnih efekata koje on u pogledu informisanosti o svijetu

marketinga donosi. Pritom se mora imati u vidu da se on se ne postavlja jednom zauvjek, već se

mijenja sa promjenama u samoj organizaciji i njenom okruženju. Može se reći da ne postoji jedan

univerzalno primjenjiv model MIS-a, već se on mora koncipirati za svako preduzeće posebno.


10

Marketinški informacioni sistem doprinosi većoj efektivnosti i efikasnosti marketinga kao

poslovne funkcije i preduzeća u celini. Ukoliko je dobro postavljen, on obezbeđuje veću

proizvodnju informacija u jedinici vremena, kao i bržu cirkulaciju podataka kroz preduzeće. Svako

u hijerarhijskoj strukturi dobija one informacije koje su mu potrebne za odluke iz njegovog

domena. MIS omogućava da se ostvari isti nivo zadovoljenja informatičkih potreba uz manje

troškove informisanja. Velikim i decentralizovanim preduzećima pomaže da se informacije rasute

po manjim organizacionim delovima integrišu u smislenu celinu. Zahvaljujući MIS-u preduzeće

brže prepoznaje trendove u marketing okolini, potencijalne opasnosti svodi na minimum,

maksimalno koristi prilike koje mu se ukazuju, brže reaguje na zbivanja u merketing sredini i po

tom osnovu povećava svoj profit.


11

3. Upravljanje podacima

Organizacije u savremenom okruženju su primorane na uvođenje novih strategija,

utvrđivanje novih tržišta kako bi zadržale konkurentnost ili kako bi uopšte opstale na tržištu. Nije

rijedak slučaj da preduzeća nisu svjesna činjenice kako efikasno upravljanje podacima podstiče

konkurentske prednosti niti kako su ovisne o podacima kao nikada ranije.

Većina organizacija zna da su podaci vrlo bitan resurs, ali je potrebno naglasiti da podaci

predstavljaju jedini resurs koji je potpuno višestruko upotrebljiv, odnosno da predstavlja resurs koji

se „ne troši“. U proteklim godinama „napredne“ organizacije su počele razumjevati da je kvalitet

rezultata svake analize kvalitetan upravo onoliko koliko su kvalitetni ulazni podaci.

Larry English je u svojoj knjizi „Unapređenje podataka“ (Improving Data) predstavio

model „Enterprise Data Manageent Maturity Model“ koji pomaže organizacijama da uoče vlastitu

poziciju u upravljanju podacima kao i da obezbjedi najbolji momenat i akcije za unapređenje u

sljedeću fazu upravljanja podacima.

Ovaj model predstavlja mnoge karakteristike organizacije od kojih ovisi faza razvoja , a

osnovna 4 su

- Ljudi – Ko je uključen, ko doprinosi trenutnoj fazi razvoja, koje su aktivnosti koje se

moraju preduzeti za unapređenje,

- Procesi – Koje aktivnosti se provode u trenutnoj fazi kao i šta treba uraditi za

unapređenje u višu fazu razvoja,

- Tehnologija – Koje tehnološke investicije su dovele do trenutnog stanja razvoja i šta

treba uraditi za unapređenje,

- Rizik i nagrada – S kojim se rizicima suoačava organizacija u trenutnoj fazi razvoja kao

i šta se može očekivati u sljedećoj fazi.

Odlike pojedinih faza razvoja su:

Faza 1. UNWARE – Organizacija ima samo nekoliko definisanih pravila i ograničenja vezano za

upravljanje podacima. Slični ili isti podaci postoje na više mjesta ili više baza podataka.

Redudantni podaci su dostupni iz više izvora u različitim formatima.


12

Uspjeh zavisi od nekolicine talentiranih pojedinaca. Tehologija koja se koristi je najčešće MS

Excel, MS Access i slično. Nema standardizacije procesa. Rizik je vrlo visok. Gubitak podataka

vodi do gubitka kupaca...

Faza 2. REACTIVE – U ovoj fazi organizacija razumije probleme upravljanja podacima kao i

činjenicu da su podaci vrlo bitni za uspjeh. Uspjeh u ovoj fazi zavise od vještina grupe tehničkog

osoblja (DBA, IT stručnjaci ..). Podaci nisu integrisani ali se teži konsolidaciji podataka. U ovoj

fazi jačaju pravila upravljanja podacima, ali je većina procesa kratkoročnog perioda. Rizik je još

visok obzirom na „curenje“ informacija.

Faza 3. PROACTIVE – Dostizanjem ove faze razvoja kompanije su u mogućnosti izbjeći rizike

,dok uppravljanje podacima zauzima bitnu ulogu u organizaciji. Uprava kompanije uviđa da su

podaci strateški resurs. Korporativni podaci više standardizirani, konzistentni i lako mjerljivi. U

ovoj fazi cilj u upravljanju podacima se umjesto na riješavanje problema prenosi na spriječavanje

problema. Rizik je u ovoj fazi u srednje do nizak, a to je rezultat vladanja boljom informacijom

koja je dostupna donosiocima odluka.

Faza 4. PREDICTIVE – Kvalitetni podaci su dio svih poslovnih procesa koji su skoro ili potpuno

automatizovani. Čitava organizacija je uključena u upravljanje podacima. Alati su standardizirani u

čitavoj organizaciji. Rizik je jako nizak jer su podaci uniformisani i čvrsto kontolisani.


13

4. Baze podataka

Koncept baze podataka je prvobitno najavljivan kao rješenje svih dotadašnjih problema u

sistemu informatičke podrške, kako u transakcijskim sisitemima , tako i u sistemima u okviru

podrške menadžmentu i strateškom upravljanju. Ono što je izdvojilo sisteme baza podataka od

ostalih programa jeste njihova sposobnost upravljanja trajnim podacima, te pristup velikim

količinama podataka na efikasan i siguran način.

Osobine koje karakterišu sve sisteme baza podataka, definisane prema Ullman-u

[Graham,1994] uključuju podršku:

§ Apstraktni model podataka

§ Visok nivo pristupa ili upitne jezike

§ Upravljanje transakcijama u višekorisničkom okruženju

§ Kontrolu pristupa i vlasništva nad podacima

§ Validaciju podataka i provjeru konzistentnosti

§ Konzistentni oporavak podataka nakon ispada ssitema ili hardverske greške.

Ukupan razvoj, ne samo baza podataka, nego i računarske podrške odlučivanju, doveo je do

pojave koncepta skladišta podataka. Da bi se bolje shvatili korijeni toga koncepta, kao i njegov

evolucijski karakter, potrebno je poznavati kako povijest, tako i trenutno stanje u području razvoja

baza podataka, te njihovu spregu s organizacijskom strukturom poslovnog sistema.


14

4.1. Organizacija baza podataka

Istorija razvoja baza podataka ukazuje na to da su osnovne pokretačke snage toga razvoja činili:

§ Ukupan razvoj informatičke tehnologije, posebno hardvera i komunikacija;

§ Shvatanje podataka kao značajnog resursa organizacije;

§ Ukupne društvene promjene, prije svega procesi informatizacije i globalizacije ljudskog

društva;

§ Promjene u upravljanju i organizacijskoj strukturi poduzeća;

§ Povećanje potreba krajnjih korisnika, posebnoe menadžera, za kvalitetnim podacima1.

Sam razvoj baza podataka išao je u smjeru ostvarenja slijedećih ključnih ciljeva:

§ Razdvajanja podataka od aplikacija koje ih koriste;

§ Prezentiranje logičkog pogleda na podatke nezavisno od fizičkih detalja njihovog čuvanja u

bazi podataka;

§ Omogućavanje različitih pogleda na istu bazu podataka, zavisno o korisničkim i

aplikativnim potrebama.

Navedeni ciljevi se ostvaruju pomoću koncepta šema baze podataka. Pod tim konceptom se

podrazumijevaju tri osnovna nivoa definisanja baze podataka

1 Kvalitetan podatak ima slijedeća osobine: točnost, kompletnost, konzistentnost,jedinstvenost i vremensku dimenziju .


15

Slika 3.1 – Konceptualni nivoi baze podataka

§ Konceptualni

§ Vanjski

§ Unutrašnji ili fizički

Konceptualni nivo ili konceptualna šema predstavlja logički pogled na čitavu bazu podataka. Sa

slike je uočljivo da se ova šema može promatrati kao preslikani model organizacije za koju se pravi

baza podataka.

Vanjski nivo ili vanjska šema predstavlja korisnički pogled na bazu podataka, a formira se u skladu

s potrebama i ograničenjima korisnika u upotrebi baze podataka. Svaki korisnik može imati

vlastiti, različit pogled na istu bazu podataka.

Unutrašnji nivo ili fizička šema opisuje implementaciju baze podataka na konkretnom hardveru.

Sistem za upravljanje bazom podataka (engl. DataBase Management System) treba omogućiti

formiranje i održavanje navedenih šema, ali i njihovo međusobno preslikavanje. Naime, treba

biti omogućeno reorganiziranje

unutrašnje ili fizičke šeme baze podataka bez mijenjanja logičke, odnosno konceptualne šeme, kao

i promjena konceptualne šeme bez mijenjanja postojeće vanjske šeme.

Na slici je uočljiv i utiecaj organizacijske strukture i hardvera na odgovarajuće šeme baze

podataka. Tako se kroz istoriju baza podataka, od hijerarhijskih, preko mrežnih, relacionih pa do


16

objektno orijentisanih, može pratiti i razvoj organizacije, od hijerarhijske, preko mrežne do

virtualne, kao i hardvera, od velikih računarskih sistema, preko računarskih mreža, personalnih

računala do Interneta i Intraneta.

4.1.1. Hijerarhijske baze podataka

Krajem šezdesetih godina 20-tog vijeka pojavile su se na tržištu prve hijerarhijske baze podataka.

U to je vrijeme hijerarhijska organizacija bila prevladavajući oblik organizacijske strukture

poduzeća, a takva organizacija je pratila i centralizirana organizacija obrade podataka bazirana na

velikim računarskim sistemima. Stoga je logično da su prvi proizvodi baza podataka počivali na

hijerarhijskoj vezi između svojih datoteka.

Osnovu razvoja činio je IBM-ov IMS2 sistem za upravljanje bazama podataka koji se na tržištu

pojavio 1968. godine. Hijerarhijske baze (pogotovo IMS) su bile izuzetno popularne i efikasne, a

zasnivale su se na slogovima sastavljenim od polja. Skup slogova je činio stablo, dok se baza

podataka sastojala od uređenog skupa stabala. Stablo se sastojalo od jednog korijenskog sloga

(engl. root record) i nula ili više slogova podstabala (slika 3.2). Odnos između tih slogova se

najčešće naziva odnos roditelj-dijete (engl. parent-child relationship). Jedan slog kao roditelj može

imati nula ili više dijete slogova, dok dijete slog ima samo jedan roditelj slog. Kako su slogovi

postavljeni u hijerarhijskom odnosu (roditelj je po hijerarhiji iznad djeteta) to je baza dobila naziv

hijerarhijska baza podataka.

2 IMS/VS (engl. Information Management System/Virtual Storage)- Informacijski upravljačkisistem/Virtualno pohranjivanje


17

Slika 3.2. Hijerarhijsko stablo podataka

Jezik za manipuliranje podacima u hijerarhijskoj bazi podataka sastoji se od skupa operatora

pomoću kojih se obrađuju podaci u stablima (operator za lociranje pojedinog stabla u bazi

podataka, operator za pomicanje s jednog stabla na stablo koje slijedi po hijerarhiji, operator za

pomicanje sa sloga na slog unutar stabla, operator za unošenje novog podatka, operator za brisanje

pojedinog podatka u stablu i sl.). Cjelovitost i konzistentnost podataka (integritet) u sklopu

hijerarhijske baze podataka uslovljena je samom koncepcijom baze. Pravila integriteta, u pravom

smislu riječi, tj. u onom smislu kako ih je definisao relacioni model podataka nisu postojala, ali su

vrijedila dva bitna pravila koja su postavljala određena ograničenja na podacima:

§ Niti jedan slog ne može postojati kao dijete slog ako za njega ne postoji roditelj slog;

§ U slučaju brisanja roditelj sloga, sistem automatski briše sve dijete slogove.

Hijerarhijske baze podataka su imale uspješnu primjenu u organizacijama koje su bile ustrojene na

hijerarhijski način jer je konceptualni model ovih baza pogodan upravo za takvu strukturu.


18

4.1.2. Mrežne baze podataka

Praktična primjena hijerarhijskih baza podataka ukazala je na činjenicu da se mnoge poslovne veze

ne mogu uklopiti u hijerarhijsku mrežu, što je dovelo do razvoja mnogo uopštijih mreža kao

produkta analize sistema. Tako su nastale mrežne baze podataka (npr. TOTAL, IDMS), a svoju su

potvrdu dobile u standardima CODASYL3 komiteta 1971. godine. CODASYL je predložio tri

različita jezika za opis baze podataka - DDL4:

§ Šema DDL – jezik za opis mrežno strukturirane baze podataka;

§ Podšema DDL – jezik za definisanje korisničkog pogleda na bazu podataka;

§ DML5– jezik za manipuliranje podacima čija je sintaksa kompatibilna sa

sintaksom programskih jezika u koje se uključuje (npr. COBOL i sl.).

Kao i kod hijerarhijskih baza podataka, osnovu strukture i u mrežnim bazama čine slogovi, s tim da

najvažnija razlika između ova dva tipa baza podataka leži u tome da mrežne baze dopuštaju da

jedan dijete slog može imati više roditelj slogova. Na taj način veze između slogova čine mrežu

(slika 3.3.), pa odatle i ime mrežne baze podataka. Mrežna baza podataka se sastoji od skupa

slogova i skupa veza između slogova, a za oba vrijede slijedeća osnovna pravila:

§ Jedna veza potieče samo od jednog sloga i ne može imati više roditelj slogova;

§ Svaka veza ima isključivo jedan dijete slog, dok jedan dijete slog može imati više veza u

kojima sudjeluje;

§ Dijete slog u jednoj hijerarhiji može biti roditelj slog u drugoj;

§ Jedan roditelj slog može biti roditelj slog u većem broju veza;

§ Jedan dijete slog može biti dijete slog u većem broju veza;

§ Između jednog roditelj i jednog dijete sloga može istovremeno postojati više veza.

3 CODASYL (engl. Conference On DAta SYstem Languages) - Konferencija o sistemu jezika zapodatke

4 DDL (engl. Database Description Language) - Jezik za opis baze podataka5 DML (engl. Data Manipulation Language) - Jezik za manipuliranje podacima.


19

Slika 3.3. Mrežne veze između podataka

Jezik za manipulisanje podacima se, kao i kod hijerarhijskih baza, sastoji od skupa operatora. Kod

mrežnih baza podataka ti operatori upravljaju kompletnim slogovima zbog čega se nazivaju

slogovno orijentisani operatori (engl. record-level operators), a najznačajniji su: operator za

lociranje određenog sloga ili vrijednosti određenog polja u tom slogu, operator za pomicanje s

roditelj sloga na prvo pojavljivanje dijete sloga, operator za pomicanje s konkretnog dijete sloga na

slijedeći dijete slog unutar iste veze, operator za pomicanje s dijete sloga na njegov roditelj slog

unutar iste veze, operator za kreiranje novog sloga, operator za brisanje postojećeg sloga i sl.

Kao i kod hijerarhijske baze, i mrežna baza podataka ima u sintaksi ugrađen integritet podataka.

Mrežne baze podataka su skoro dostigle popularnost i efikasnost kao i njihove hijerarhijske

preteče. Međutim, oba sistema baza podatka su bila zavisna o fiksnim pokazivačima (engl.

pointers), što je njihovu izmjenu ili proširenje u skladu sa reorganizacijom poslovanja činilo

složenim.

U hijerarhijskom modelu je bilo moguće predstaviti samo određene vrste strukturalnih relacija, na

primjer pojedinačno nasljeđivanje ili podtipove, dok su mrežni sistemi dopuštali konstruisanje

mnogo uopštenijih veza (mreža), ali je još uvijek promjena tih relacija, nakon što se sistem jednom

dizajnira, bila komplikovana.

I hijerarhijske i mrežne baze podataka su nastale kao odgovor na praktične potrebe i bez pokrića u

formalnoj teoriji: ne postoji razvijen mrežni model podataka ili hijerarhijski model podataka.


20

Glavne zamjerke ovim modelima svode se na:

§ Sva pretraživanja se izvode po unaprijed definisanim i točno navedenim putevima;

§ Svi odnosi između objekata se moraju unaprijed i tačno definisati;

§ Optimizacija se provodi ručno, programer sam optimizira kôd i određuje metodu koja će

biti korištena pri komunikaciji između aplikacije i baze podataka. Brzina i način te

komunikacije zavise o sposobnosti programera i njegovom razumijevanju organizacije

pokazivača i strukture baze podataka.

4.1.3. Relacione baze podataka

Daljnji razvoj baza podataka doveo je do uvođenja prvog formalnog modela podataka, E.F. Codd-

ovog relacionog modela podataka. Taj model je zasnovan na matematičkoj teoriji relacijske

algebre - FOPC6.

Osnovu relacionog modela podataka čini relacija. E.F. Codd je pod tim pojmom podrazumjevao

pravougaono područje (slika 3.4.) koje se sastoji od kolona (vrijednosti atributa) i redova koje

ispunjavaju slijedeće uslove:

§ Sve vrijednosti unutar jednog atributa su istog tipa (pri tome se misli na tip podataka), dok

kod različitih atributa to nije obvezno.

§ Svaka vrijednost za sebe unutar reda predstavlja samo određeni broj ili skup znakova i ništa

više. Ako se posmatra samo jedna vrijednost, ne može se ništa doznati o ostalim

vrijednostima atributa, niti o ostalim vrijednostima u redu.

§ Unutar jedne relacije ne smiju postojati dva reda s identičnim vrijednostima svih atributa.

§ Redoslijed redova unutar relacije je potpuno nebitan, s obzirom da je tablica zapravo

matematička relacija (skup), a kod skupova redoslijed elemenata nije bitan.

§ Svi atributi unutar relacije moraju imati različita imena, dok njihov redoslijed nije bitan.

6 FOPC (engl. First-Order Predicate Calculus) – Predikatni račun prvog reda.Osnovne postulate i strukturu relacionog modela podataka, E.F. Codd je iznio 1971. godine u knjizi “ARelational Model of Data for Large Shared Data Banks”.


21

Skup svih atributa, odnosno svih imena atributa naziva se relaciona šema, a relacija je tada relacija

nad relacijskom šemom. Šema baze podataka je skup svih relacionih šema svih relacija u bazi

podataka. Baza podataka je skup relacija. Različite relacije mogu imati ista imena atributa, ali u

bazi ne mogu postojati dvije relacije s istim imenom.

Definisana teorijska osnova otvorila je mogućnost razvoja potpuno relacionog, neproceduralnog

upitnog jezika. Današnji de facto standard za definiranje i upravljanje podacima - SQL7 čini

osnovu relacionog modela baze podataka.

U relacijskoj bazi podataka atributi se mogu dodati ili ukloniti bez potrebe za rekonstruiranjem

kompleksnog sistema pokazivača, što je omogućilo i pojednostavnilo redefinisanje poslovnih

sistema i organizacijske strukture kako bi se osiguralo postizanje poslovnih ciljeva.

Slika 3.4. Relaciona tabela

Daljnji razvoj relacionog model podataka bio je motivisan s nekoliko ciljeva, među kojima je želja

za upotrebom formalnih metoda u dizajniranju baza podataka, pretraživanju i ažuriranju, želja da se

može dokazati ispravnost programa zasnovanih na ne-proceduralnim opisima, i hitnost da se

potvrdi da bi teorija trebala biti što jednostavnija uz zadržavanje snage izražavanja. Osnovna ideja

7 SQL (engl. Structured Query Language) - Strukturni jezik za pretraživanje.Standardni SQL je relacioni potpun jer za svih pet osnovnih relacionih operatora (spajanje,razlika, množenje, restrikcija i projekcija) postoje semantički ekvivalentne SQL naredbe. SQLje postavio standarde za upite, ažuriranje i komuniciranje između baza podataka i aplikacija.


22

je da se podaci predstavljaju kao serija tablica ili ravnih datoteka (engl. flat files). Nikakve

ponavljajuće grupe ili implicitna hijerarhija nisu dozvoljene i nikakve fiksne strukturne veze ne

mogu biti dio baze podataka. Logičke veze između podataka se uspostavljaju u vrijeme izvršavanja

ili se čuvaju u posebnim tablicama. Na taj način je isti tip objekta upotrebljen za predstavljanje i

entiteta i veza. Takođe, ovakve ukrštene (engl. cross-reference) tablice se mogu ponovno napraviti

bez potrebe da se reorganiziraju podaci u bazi.

Jedna od osnovnih pretpostavki na kojoj je razvijan relacioni model baza podataka jeste da treba

osigurati brzo i jednostavno prilagođavanje strukture podataka u promjenjenim uslovima

poslovanja. Ovo je tipična tačka na kojoj dolazi do nerazumijevanja, kako kod zagovornika, tako i

kod protivnika relacionog modela. Glavni izvor nerazumijevanja leži u konfuziji između logičkog i

fizičkog modela podataka. Relacioni model jeste logički model podataka. S druge strane, ne postoji

hijerarhijski ili mrežni model podataka u logičkom smislu. Oni spadaju u fizički dizajn. U stvari,

relaciona baza podataka može biti implementirana kao mrežna baza radi poboljšanja efikasnosti.

Logički relacioni model omogućava korisnicima da vide istu strukturu podataka na mnogo

različitih načina, kroz tzv. korisničke poglede, tako da je jedna od bitnih koristi relacionih baza

podataka veći stepen prihvaćanja od strane korisnika.

Jednostavnost i striktna ograničenja formalnog relacionog modela uzrokovala su u praktičnoj

primjeni, posebno kod složenijih financijskih analiza, značajne poteškoće, kako u načinu

definisanja modela, tako i u performansama rada baze podataka. Naime, jedna od značajnijih

slabosti relacionog shvaćanja, kada dođe do poslovne primjene, jeste neprirodan način na koji radi

s relacijama koje su direktno u višedimenzionalnom obliku. Očiti primjer je područje financijskog

modeliranja. Nemogućnost relacionog modela da prihvati kao atomski bilo koji objekt višeg tipa

(lista, vektor i sl.) čini od relativno trivijalnog zadatka tabelarnog modeliranja značajan problem

unutar ovog modela. Jednostavnost upotrebe programskih paketa tipa proračunskih tablica (npr.

Excel, Lotus i sl.) proizlazi iz bogatstva struktura podataka i njihovoj dobroj usklađenosti s

načinom na koji ljudi doživljavaju probleme. U praksi, većina organizacija će čuvati sirove podatke

u relacijske tablice i agregirati ih na različite načine prije nego što ih proslijede posebnim

programskim paketima za modeliranje ili aplikacijama za podršku odlučivanju. Iz ovoga proizlazi

da relacioni model samo osigurava rad s masom nepročišćenih podataka, što i nije uvijek slučaj.

Neke aplikacije za podršku odlučivanju visokog nivoa su potpuno prilagođene relacijskoj


23

organizaciji podataka. Primjer takve aplikacije jeste Express8 – sistem za financijsko modeliranje u

potpunosti baziran na relacionom modelu podataka. Express nudi korisnički logičan model

podataka, model koji se razlikuje i od mrežnog, i od hijerarhijskog, ali i od “čistog” relacionog

pristupa. To je multidimenzijski model podataka, model koji se odnosi na varijable definisane na

više dimenzija koje se mogu posmatrati kao kocka (s tim da kocka kod multidimenzijskih modela

podrazumijeva i više od tri dimenzije). Dimenzije same po sebi ne moraju tvoriti realnu liniju, kao

što je slučaj u Kartezijskoj geometriji, već mogu i same biti skupovi. Ustvari, ovakav pogled na

podatke jeste jednostavna transformacija relacionog modela gdje su instance u dimenzijama

jednake vrijednosti atributa iz domene.

Poteškoće vezane uz relacioni model uključuju: rad s rekurzivnim upitima, probleme vezane uz

nula vrijednosti, nedostatak podrške za apstraktne tipove podataka, i možda najvažniji: nedostatak

u predstavljanju podataka i funkcionalne semantike, tj. ne postoji stvarna podrška za poslovna ili

pravila integriteta. Takođe, bitni su i problemi vezani uz normaliziranje podataka9. Naime,

normalizirane relacije rijetko, ako ikada, odgovaraju bilo kojem objektu iz stvarnog svijeta.

Normalizacija često potpuno skriva semantiku. Jedan od razloga za to jeste što normalizacija skriva

primjenjivo znanje koje je predstavljeno funkcionalnom zavisnošću između atributa.

Uz ove slabosti, relacioni sistemi imaju veliku snagu. Snaga relacionog modela je u zasnovanosti

na formalnoj teoriji. Ta teorija je osigurala razvoj relacionog neproceduralnog jezika kao što je

SQL. Logika osigurava da određene stvari vezane uz ovaj jezik mogu biti matematički dokazane.

Relacioni sistemi osiguravaju jednostavnu promjenu strukture podataka i štite korisnika od

kompleksnosti pomoću ne-proceduralnih upitnih jezika koji se mogu automatski optimizirati.

Početni problemi performansi danas su uglavnom savladani, i nakon prvobitnog otpora relacione

baze su postigle široku prihvaćenost u industriji.

Današnji relacioni sistemi za upravljanje bazama podataka u pravilu uključuju i posebne

optimizatore za poboljšanje performansi, ugrađenu inteligenciju za izvršavanje upita, distribuirane i

replikacijske opcije, a postupno se dodaju i objektne mogućnosti, tako da se trenutno može govoriti

da na tržištu prevladavaju relacijske baze s objektno orijentisanim proširenjima.

8 Express je nastao ranih 1970-tih, a program su napisala dvojica studenata (Jay Wurths iRick Karrash) MIT-a, radeći marketinšku analizu za svoje profesore

9 Pod normalizacijom podataka se podrazumijeva postupak kojim se eliminiše potreba zavišestrukim zapisivanjem istih podataka u bazu i osigurava postojanje semantičkogintegriteta tj. izbjegavaju se anomalije pri unosu, brisanju ili promjeni podataka kojemogu dovesti do njihovog gubitka.


24

4.1.4. Relacione baze s objektno orijentisanim proširenjima

Nastanak relacionih baza s objektno orijentisanim proširenjima - ORDBMS10 vezan je uz namjeru

omogućavanja postupnog prelaza s relacionih sistema za upravljanje bazama podataka -RDBMS11

na objektno orijentsane baze podata - OODB12 i olakšavanje praktične primjene i usvajanja

objektnih metoda. Naime, RDBMS su dostigle svoju potpunu zrelost, riješeni su mnogi početni

problemi, postignuta je stabilnost i pouzdanost, performanse su dostigle zadovoljavajuću razinu,

postale su u praksi prevladavajuća tehnologija čuvanja podataka, a konačno su dostignuti i

uspostavljeni standardi (SQL-92), postignuta je skalabilnost, RDBMS podržavaju najsavremeniju

serversku tehnologiju kao što je simetrično multiprocesiranje, paralelne procesore, I/O13

redukcijske tehnike, čuvanje procedure, trigera i alate za upravljanje i modeliranje performansi.

Usprkos mnogih svojih prednosti, relacioni model podataka je siromašan za prihvat različitih

tipova podataka trenutno uobičajenih unutar organizacije. Ustvari, objektne baze podataka duguju

svoje postojanje osnovnim ograničenjima relacionog modela opisanog u SQL2 standardu.

Posljednjih godina sve je više zahtijeva, posebno sa strane dizajnera i programera aplikacija, za

većom fleksibilnošću i funkcionalnošću modela podataka, kao i od strane administratora sistema

koji zahtijevaju zajedničku tehnologiju baza podataka kojom se upravlja zajedničkim skupom alata.

Rezultat svega toga jeste da je komitet za standardizaciju proširio relacioni model podataka tako da

je u SQL3 standard uključio i objektne mogućnosti.

Međutim, i najuporniji zagovarači relacionog modela moraju priznati da relacioni model nema

mogućnost modeliranja i efikasnog upravljanja složenim objektima kao što su slike, dokumenti,

video i audio zapisi, animacije i kompozitni objekti (vremenske serije). Ali, većina poslovnih

sistema ili ne treba te osobine ili je u mogućnosti da ih doda koristeći postojeće relacione

mehanizme. Nadalje, većina dizajnera aplikacija se slaže da objektno-orijentisani model osigurava

veću fleksibilnost i modularnost. Međutim, objektno-orijentisani model nije pogodan za paralelno

procesiranje upita, ne podržava standardni, široko rasprostranjeni upitni jezik i sl. Naime, razvoj

objektno orijentisanih baza podataka prolazi kroz sve one “dječje” bolesti koje su relacijske baze

već “preboljele”. Praktična primjena OODB-a ide relativno sporo jer se organizacije teško odlučuju

10 ORDBMS (engl. Object/Relational DataBase Management System) – Relacijske baze sobjektno orijentiranim proširenjima.

11 RDBMS (engl. Relational DataBase Management System) – Relacioni sistem za upravljanjebazom podataka.

12 OODB (engl. Object Oriented DataBase) – Objektno orijentirane baze podataka.13 I/O (engl. Input/Output) – Ulazno/Izlazne.


25

na radikalne promjene. Većina se odlučuje za postupan, evolutivni pristup što podrazumijeva da se

manje, i za poslovanje nekritične aplikacije postupno prebacuju u OODB. Na taj način se, čekajući

da OODB proizvodi dostignu određenu zrelost i stabilnost, stiču dragocjena iskustva.

Zahvaljujući takvom pristupu, ORDBMS je iz prelaznog rješenja izrastao u potpuno samostalan

proizvod. Zagovornici ujedinjenja objektnog i relacionog modela baziraju se na dvije osnovne

tvrdnje. Prvo, niti relacioni, niti objektni model nemaju sve mogućnosti potrebne za upravljanje

podacima. Smatra se da korisnici trebaju primjenjivati postojeća znanja i vještine stečene u

relacionom svijetu, uz istovremenu podršku novoj generaciji aplikacija. Drugo, relacione baze

podataka su i dalje prevladavajući repozitorij podataka za većinu razvojnih aplikativnih projekata.

Međutim posljednjih 10 godina objekti su postali najbolji način izgradnje aplikacija. Migracija na

objektni model kroz relacioni pristup s objektno orijentisanim proširenjima trebala bi riješiti

problem uvezivanja različitih modela.

Relaciona baze s objektno orijentisanim proširenjima dodaju nove mogućnosti smještanja objekata

u relacijske sisteme koji još uvijek čine osnovu informacijskih sistema. Ove nove osobine

integriraju upravljanje tradicionalnim tabelarnim podacima sa složenim objektima kao što su

vremenske serije i prostorni podaci i različitim binarnim medijima kao što su zvuk, slika i sl.

Pridružujući metode podatkovnim strukturama, ORDBMS server može uraditi složene analitičke,

kao i operacije manipuliranja podacima u cilju pretraživanja, te transformirati multimediju i druge

složene objekte.

Kao evolutivna tehnologija, relacioni pristup s objektnim proširenjima je naslijedio svu robusnost

transakcije i mogućnosti upravljanja performansama od svog relacionog pretka, ali i fleksibilnost

svojih objektno-orijentisanih rođaka. Dizajner baze podatka može i dalje raditi s poznatim

strukturama tablica i jezicima za definiranje podataka (DDLs) dok usput postupno usvaja nove

objektne mogućnosti.

ORDBMS su ustvari proširena nadogradnja svojih RDBMS prethodnika, i , za razliku od prelaza

na objektno orijentisane sisteme baza podataka, prelaz na relacione sisteme s objektno

orijentisanim proširenjima ne zahtjeva obavezno ponovno prekodiranje.

Osnovne osobine koje proširuju relacionu u relacionu bazu podataka s objektno orijentisanim

proširenjima su [Kim,1997]:

§ Automatska optimizacija upita i njihova obrada. Optimizator upita za ORDBMS mora

sadržavati sve ključne tehnike uključene u RDBMS optimizator upita, uključujući


26

generisanje planova izvršenja upita, odabir optimalnog plana baziran na procjeni

očekivanih troškova izvršenje upita, upotrebu metoda pristupa za izvršenje upita

(indeksiranje i sortiranje), spajanje preko ugniježđenih petlji ili sort algoritama, te upotrebu

statistike baze podataka u procjeni troškova. ORDBMS treba implementirati mehanizam za

pohranjivanje i pristup vrijednostima atributa sa skupom vrijednosti.

Metoda bi se trebala moći izvršiti na klijent ili server (ili obje) strani u slučaju

klijent-server arhitekture. Optimizator upita za ORDBMS mora generisati plan

izvođenja upita za minimiziranje prienosa podataka između klijenta i servera

kada izvršavanje upita uključuje metodu.

§ Indeksiranje apstraktnih tipova podataka. RDBMS daje korisnicima mogućnost

kreiranja indeksa koji pomažu procesiranju upita tako što ograničavaju prostor za

pretraživanje na minimum.

§ Kontrola istovremenog pristupa. ORDMS mora potpuno podržavati sve tehnike sadržane

u RDMBS, uključujući protokol dvofaznog potvrđivanja, postavljanje zaključavanja,

protokole za skidanje zaključavanja, hijerarhijsko zaključavanje, logičko i fizičko

zaključavanje, te modove zaključavanja. Objektno proširenje zahtijeva i neke dodatne

mogućnosti. Podrška upitima koji sadrže hijerarhiju nasljeđivanja klasa i dinamičku

evoluciju takve hijerarhije, zahtijeva proširenje mehanizma za kontrolu zaključavanja, tako

da hijerarhija nasljeđivanja s korijenom u određenoj klasi može biti zaključana kao

jedinstvena cjelina kako bi se izbjegle neželjene situacije. Dalje, činjenica da ORDBMS

korisnik može koristiti OID14 za pristup pojedinom objektu znači da pojedinačni objekt,

radije nego pojedinačna disk stranica ili klasa, treba biti najmanja jedinica zaključavanja

kod ORDBMS-a.

§ Autorizacija. ORDBMS mora osigurati podršku svim mehanizmima autorizacije koje

podržava RDBMS, uključujući autorizaciju atributa, klasa ili pogleda, rekurzivni prenos i

ukidanje autorizacije, prenos autorizacije na pojedince, grupe, autorizaciju resursa i sl.

Objektno proširenje dodaje i autorizaciju koja uključuje izvršavanje metoda, kao i

autorizaciju pojedinačnog objekta. Činjenica da ORDBMS korisnik može navesti OID kako

14 OID (engl.Object Identifier) - Identifikator objekta. Svaka instanca klase ima jedinstven i nepromjenjiv OID.


27

bi pristupio pojedinačnom objektu, ukazuje na to da bi ustvari taj pojedinačni objekt trebao

biti najmanja jedinica za autorizaciju kod ORDBMS.

§ Trigeri. Trigeri (okidači) su i kod ORDBMS-a podjednako značajni, kao i kod RDBMS-a.

Objektno proširenje uključuje samo mogućnost poziva metoda kao dijela akcija okidača.

§ Čuvanje procedure. Metode su kod ORDBMS-a pridružene određenoj klasi i prenose se

na podklase. Nadalje, metode se mogu izvršavati na klijentu, isto kao i na poslužitelju.

Sačuvane procedure mogu, ovisno o server orijentisanoj metodi, biti pridružene bazi

podataka kao cjelini, a ne nekoj određenoj klasi.

§ Dinamički razvoj šeme baze podataka. ORDBMS shema ima mnogo više djelova od

relacijske, te slijedi da se više elemenata šeme može dinamički mijenjati. Ti elementi

uključuju dodavanje i ukidanje metoda za klase, dodavanje i ukidanje nadklasa/podklasa

relacija između dvije klase, te promjene domene atributa.

§ Obavezna sigurnost. Sigurnost je kritični faktor za pojedine tipove aplikacija (npr. za

vladu, vojsku, policiju i sl.) baze podataka. Objektna ekstenzija usložnjava taj problem, a

najveće poteškoće su vezane uz upotrebu metoda i OID-a.

Relacioni model opisuje sistem pomoću informacija, koristeći relacije, atribute, domene i pravila.

Nasuprot tomu, objektno-orijentisani model opisuje sistem koristeći objekte koji definišu identitet,

stanje, ponašanje, enkapsulaciju i nasljeđivanje.

Identitet objekta odvaja jedan objekt od ostalih. Stanje definira trenutnu vrijednost objekta.

Ponašanje objekta je skup metoda i sučelja koja odgovaraju na poruke. Enkapsulacija skriva

podatke od vanjskih entiteta, prisiljavajući da se pristup podacima izvršava samo putom metoda.

Nasljeđivanje dopušta objektima da iskoriste osobine i funkcionalnost drugih objekata.

Dizajner relacijske baze podataka s objektnim proširenjima bi trebao mapirati objekte u vrijednosti

atributa pri mapiranju jednog modela u drugi, a koncept normalizacije bi trebao biti zamijenjen

eliminiranjem redundance u relacionom modelu s objektno orijentisanim proširenjima. Pogledi koji

u relacijskom modelu postoje kao atributi objekta i ograničenja relacionog integriteta, trebali bi se

mapirati u nasljeđivanje zasnovano na tipu objekta.


28

Najznačajnije, nove, osobine relacione baze s objektno orijentisanim proširenjima su:

§ Korisnički definisani tipovi (UDTs15);

§ Korisnički definisane funkcije (UDFs16);

§ Infrastruktura – nove metode indeksiranja/pristupa i proširenja optimizatora koji ih

podržavaju.

Ključna izmjena jeste u tomu što relacioni modeli s objektno orijentisanim proširenjima uključuju i

podatke i procese: kakva informacija postoji i što se namjerava s njom učiniti. Nasuprot tome,

relacijske baze podatka podržavaju samo ograničenu enkapsulaciju operacija i procesa. Jasno,

dizajn metodologije i alati moraju sada modelirati i podatke i operacije, zahtjev koji traži pristup

koji pokriva i tradicionalne baze podataka i objektno-orijentisane aplikacije i koji bi optimalno

dozvoljavao dizajnerima i enkapsulaciju funkcija s podacima i generisanje klasa ili kodne strukture

izvan baze podataka.

Trenutno postoje dva različita pristupa koje koriste proizvođači kako bi uključili i objektnu

komponentu u svoje relacijske baze podataka, a to su:

§ Federalni

§ Integrirani

Federalni pristup je konceptualno jasniji i lakši za implementiranje. Kao što se vidi sa slike 2.6., u

ovom pristupu uz RDBMS se nalazi objektna baza podataka s proširenim mogućnostima vezanim

za tipove podataka, a obje baze su prikrivene od programa zajedničkim softverskim sučeljem.

Zajedno s aplikacijskim programskim interfejsom, ovaj zajednički softver je odgovoran za ukupno

izvršavanje i upravljanje oporavkom baze podataka, kreiranje plana za izvršenje upita, te

integriranje odgovora iz sastavnih dijelova baze na (parcijalne) upite postavljene na osnovu upita

aplikacijskih programa.

15 UDTs (engl. User Defined Types) – Korisnički definirani tipovi16 UDFs (engl. User Defined Functions) – Korisnički definirane funkcije


29

Slika 2.6. Federalni pristup uključivanju objektne komponente u RDBMS

Ova arhitektura je dobra za upotrebu trenutno raspoložive ODBMS tehnologije, kao i za

distribuirane podatke. Sa slike 2.6. je očigledno da se dodatni tipovi podataka – tekst ili prostorne

baze – konceptualno mogu dodati u ovakvoj arhitekturi. Ovakva struktura predstavlja veliki izazov,

pošto promjene koje se moraju napraviti na sastavnim dijelovima baze trebaju očigledno biti

minimizirane do stepena da se svaka može napraviti nezavisno od ostalih. Na žalost, što su veće

takve izmjene, to je veći izazov za zajedničko softversko sučelje i slabiji su izgledi za optimalno

izvršenje – koje najčešće zahijeva razmjenu među-rezultata između objektne i relacijske baze

podataka.

Zajedničko softversko sučelje podrazumijeva odgovornost za upoređivanje dva skupa među-

odgovora i kreiranje skupa odgovora koji se šalje nazad odgovarajućem aplikacionom programu.

Odvajanjem objektne funkcionalnosti od relacijske, ova arhitektura onemogućava primjenu

objektne funkcionalnosti na postojeće relacijske podatke. Pozitivno je, međutim, da ostavlja visoko

optimizirani relacioni transakcijski softver gotovo neizmjenjenim, te zadržava njegove performanse

i izoliranost od objektnog procesiranja.

Integrirana relaciona arhitektura s objektno orijentisanim proširenjima, kao što i samo ime kaže,

integriše objektnu funkcionalnost zajedno s relacijskom funkcionalnošću unutar istog softvera baze

Upravljanje sesijama i upitima,optimiziranje, koordiniranje izvršenja,

integriranje rezultata

Relacijskabaza

podataka

Objektnabaza

podataka...


30

podataka. Rezultat je spajanje objektnog i relacionog pristupa, s potencijalom moćnih unapređenja

aplikacija, te integrisanom administracijom jedinstvene baze podataka. Cijena ove funkcionalnosti

je dizajn sistema koji je veoma složen za implementiranje i izlaganje aplikacija relacionih baza,

njihovih performansi i integriteta podataka riziku kojim se mora pažljivo upravljati kako tokom

implementacije, tako i u samoj produkciji.

ORDBMS poboljšavaju programersku produktivnost omogućujući objektno orijentisani prikaz

podataka, funkcionalno indeksiranje i korisnički definirane procedure (UDR17). Nadalje,

programeri mogu upotrebljavati objektne razvojne jezike kao što su C++ i Java, umjesto da ovise o

ograničenim proceduralnim jezicima čiji su vlasnici proizvođači konkretnog RDBMS-a.

Sposobnost relacijske baze podataka s objektno orijentisanim proširenjima da predstavi objektni

model unutar baze eliminiše potrebu za destrukcijom i rekonstrukcijom poslovnih objekata. Dok

relaciona baza podataka zahijeva izvršavanje višestrukih kompleksnih upita, relaciona baza s

objektno orijentisanim proširenjima omogućava da se jednom baznom operacijom izgrade

korisnički tipovi podataka, kreira tablica koja će koristit te nove tipove, kao i pohranjivanje i

pristup korisnički-definiranim objektima. Dio specifikacije novog tipa podataka sadrži dodatne

matematičke funkcije, agregiranje vrijednosti podataka i sl. Mogućnost definisanja složenih tipova

podataka kombinovana s nasljeđivanjem omogućava brzo dodavanje novih tipova podataka.

Upotreba složenih tipova podataka unutar jednog SQL iskaza eliminiše potrebu za kompleksnim

višestrukim upitima ili naknadnim procesiranjem što je bilo tako karakteristično za RDBMS.

Funkcionalno indeksiranje eliminiše značajne probleme vezane za administriranje baze podataka.

Dok RDBMS dopušta kreiranje indeksa na skupu kolona, ORDBMS ide korak dalje

omogućavajući kreiranje indeksa na vrijednost vraćenu od strane procedure, a ne na vrijednost

kolone. Korisnik može definisati vlastite indekse za rad s kritičnim podacima bez potrebe za

dodatnim aplikacijskim kodom ili izmjenom SQL-a. ORDBMS također može definisati potpuno

novi tip indeksa ili novu strukturu za pohranjivanje.

UDR mogućnost poboljšava performanse sistema. Relacijske baze podataka koriste vlastite

procedure za grupisanje više SQL izraza zajedno kako bi se izvršile kompleksne zadatke. Međutim,

te procedure se ne mogu pozivati unutar SQL iskaza. UDR su procedure napisane u C++ ili Java

jeziku i mogu biti pohranjene na serveru podataka. Mogu se pozivati bilo unutar SQL izraza, bilo

17 UDR (engl. User-Defined Routine) – Korisnički definirane procedure.


31

unutar druge UDR procedure. UDR se izvršavaju na serveru, što osigurava da se procesiranje

izvršava u neposrednoj blizini podataka, minimizirajući količinu informacija koja se treba slati

putom mreže, što u konačnici poboljšava performanse. UDR također omogućavaju programerima

enkapsulaciju podataka, štiteći aplikaciju od izmjena u shemi i reducirajući troškove održavanja.

Svoj udio na tržištu baza podataka ORDBMS pronalazi u onom dijelu gdje se čiste relacijske baze

ne preporučuju zbog njihove nemogućnosti modeliranja kompleksnih podataka (liste, vektori i sl.)

i/ili zbog složenog upravljanja multimedijalnim podacima, odnosno u dijelu gdje čiste objektne

baze nisu poželjne zbog svoje loše skalabilnosti i/ili zbog ne ispunjenja zahtjeva vezanih za brzinu

i pouzdanost baze podataka.

4.1.5. Objektno orijentisane baze podataka

Objektno orijentisani sistem baza podataka je sistem baza podataka – u smislu da ima sve osobine

baza podataka, uključujući jezike za pristup, sposobnost upravljanja ogromnim količinama

podataka, postojanost, integritet podataka i transakcija, sigurnost i oporavak – koji dodatno

podržava apstrakciju, nasljeđivanje i objektni identitet. Savremene objektno orijentisane baze

uključuju i mogućnost praćenja različitih verzija baza podataka, neophodan zbog načina rada u

mrežnom okruženju.

Dok su se relacione baze razvijale u doba samostojećih mini ili velikih računalnih sistema,

objektno orijentisane baze se razvijaju u okruženju umreženih radnih stanica. Slijedi da se novi

produkti razvijaju unutar kulturnih postavki gdje je prosljeđivanje rada kolegama na mreži radi

modifikacije, konsultacija, dovršenja i sl. česta i uobičajena pojava. Transakcije ovakvog tipa

nazivaju se duge transakcije, a najčešće se javljaju pri razvoju inženjerskog dizajna i proizvodnji

dokumentacije, ali ne i kod tipova aplikacija gdje se konvencionalno upravljanje bazama podataka

najčešće primjenjuje. Tradicionalne baze podataka upravljaju samo kratkim transakcijama.

Tri su osnovna razloga koja nameću potrebu razvoja objektno orijentisanih baza podataka:


32

§ Omogućavanje jednostavnijeg povezivanja s objektno orijentisanim programskim jezicima;

§ Razvoj aplikacija koje zahtijevaju fleksibilnost relacionih baza podataka, ali za koje su

performanse istih neadekvatne;

§ Razvoj potpuno novih vrsta aplikacija na koje se može primijeniti metafora prosljeđivanja

poruka.

Objektno orijentisane baze podataka idu dalje od semantičkih modela tako da prihvaćaju

apstrakcije koje opisuju ponašanje (metode), iz čega proizlazi da one mogu predstavljati, pa čak i

normalizirati ponašanje.

Objekti mogu sačuvati veze predstavljene kao linkove na druge objekte i metode. Ove relacije se

često posmatraju kao posebni objekti i kao takvi mogu imati atribute i metode.

Kod objektno orijentisanih sistema baza podataka, postoji izraženiji zahtjev za modeliranjem

strukturnih osobina podataka i pravljenjem eksplicitne strukture nasljeđivanja i agregacije. Postoje

različiti načini prikaza takvih struktura:

§ Objekti se mogu grupisati u klase prema zajedničkim strukturnim i osobinama ponašanja –

što se naziva klasifikacija;

§ Slična klasifikaciji je asocijacija – konkretne instance se grupišuu u klase prema nekoj

osobini koja im je zajednička;

§ Objekti se mogu grupisati kao dijelovi nekog kompozitnog objekta na dva načina: kao dio

strukture (kompozicija) ili kao skup atributa (agregacija).

Agregacija atributa i metoda je način na koji se konceptualno formiraju objekti u objektno

orijentisanom programiranju.

Drugi tip strukture, značajan za dizajniranje složenih sistema za upravljanje podacima, jeste

struktura korištenja, ili klijent-server, veza među objektima. Ova struktura predstavlja topologiju

prijenosa poruka sistema i mjeru kompleksnosti kontrolnih struktura. Relacioni sistemi nude ne-

proceduralni, tj. deklarativni jezik pristupa, baziran na logici koja je predmet optimizacije upita.

Objektno orijentisani sistemi su u osnovi proceduralni i ne-deklarativni u odnosu na način pristupa

preko eksplicitno deklarisanih veza između objekata i klasifikacijskih struktura.


33

Objektno orijentisane baze podataka uglavnom ne trebaju spajanja, najsporiju operaciju koju su

relacioni sistemi morali izvršavati. Pošto su objekti pohranjeni kao jedinstvene cjeline, poziv

objekta je jedna, jednostavna, iako možda velika, operacija. U relacijskom okruženju aplikacija

izvodi strukturu baze podataka u vrijeme izvršavanja iz nepovezanih tablica, dok su kod objektno

orijentisanih baza podatka strukture pohranjene direktno u bazi. Tako, umjesto da izvršava

spajanja, baza slijedi pokazivače od objekta do objekta. Ovo podsjeća na strukturu mrežnih baza

podataka, s tim što su objektno orijentisane baze mnogo fleksibilnije u smislu evolucije šeme.

Kod OODB, uslovi integriteta se odnose na instance, za razliku od relacionih sistema gdje se samo

entiteti (ili nivo klasa) mogu iskazati. Semantika aplikacija, kao što su funkcionalne ovisnosti, kod

OODB-a nisu skrivene u normaliziranim tablicama. Redundanca se rješava smještanjem

pokazivača uz objekte.

Relacioni sistem, u pravilu, ima ograničeni skup primitivnih tipova podataka: cjelobrojne,

numeričke, alfanumeričke, datumske i sl. Većina sistema danas podržava i proširene tipove kao što

su tekstualni ili BLOBS18, ali ne postoji interna struktura ili semantika s njima povezana. OODB

dozvoljavaju korisnički definisane tipove podataka sa semantikom pridruženom preko sistema

klasa. Ovo omogućava upotrebu objektno orijentisanih programskih jezika, ali i upitnih i DML-a.

Objektno orijentisane baze podataka dodiruju neka od ključnih pitanja primjene informacione

tehnologije. One obećavaju iskorištavanje prednosti vezanih za objektno orijentisano

programiranje, upotrebljivost i proširivost, kao i poboljšavanje sistema baza podataka. Možda je

jedno od važnijih obećanja iskorištavanje povezanosti sa semantički bogatim jezicima, na način

semantičkih baza podataka i ekspertnih sistema. Područje u kojemu bi objektno orijentisane baze

najprije mogle postići uvažavanje i prihvaćanje jeste mogućnost kombinovanja objektno

orijentisanog programiranja, semantičkih modela podataka i ekspertnih sistema u jednu jedinstvenu

cjelinu.

Prednosti objektno-orijentisanih baza podataka mogu se podijeliti u tri osnovne grupe

[Graham,1994]:

§ Prednosti koje proizlaze iz potrebe korištenja objektno orijentisanih programskih jezika ili

okruženja:

18 BLOBS (engl. Binary Large ObjectS) - Veliki binarni objekti.


34

- Objektno orijentisana baza podataka minimizira potrebu za straničenjem objekata u

memoriji kada se koristi objektno orijentisano programiranje. Ostale su prednosti

vezane uz opće odlike baze podataka kao što su dijeljenje podataka, distribuiranje,

sigurnost i slično.

- Objektno orijentisane baze podataka pomažu smanjenju semantičkog procijepa

između objekata i koncepata realnog svijeta i njihovog predstavljanja u bazi

podataka. One također nude rješenje problema dekompozicije s gubitkom

informacija (engl. impedance mismatch) između aplikacijskog programskog jezika i

DML-a, što omogućava projektantima upotrrbu uniformnijeg načina u prikazivanju

dizajna.

§ Prednosti koje proizlaze iz bogatih semantičkih mogućnosti objektno orijentisanih baza

podataka:

- Moguće je pohraniti oboje, i relacije između objekata i ograničenja vezana uz

objekte na server, radije nego na klijent aplikaciju. Ovo ima bitan utjecaj kako na

održavanje, tako i na integritet aplikacija. Promjena se izvršava samo na jednom

mjestu, te se mogućnost nekonzistentnih promjena ako ne ukida, onda sigurno

minimizira.

- Objektno orijentisani model podataka može predstaviti sve što i relacioni,

hijerarhijski i mrežni model, i još ih semantički obogatiti.

- Postoji, ako ništa potencijalna, podrška za “pravila” (aktivne objekte) kod objektno

orijentisanih baza podataka. Većina trenutnih prijedloga su ad hoc, ali je uočljiva

potreba za standardnim protokolima za enkapsuliranje pravila.

- Objektno orijentisane baze podataka nude mogućnost ranije provjere tipa ad hoc

upita u odnosu na relacijske sisteme. To se ostvaruje preko korisnički definisanih

tipova koji se mogu koristiti za odbacivanje nekorektnih tipova podataka prije

stvarnog pristupa bazi.

§ Prednosti koje proizlaze direktno iz mogućnosti samog dizajna objektno orijentisanih baza

podataka:

- Objektno orijentisane baze podataka kombinuju brzinu mrežnih baza podataka s

fleksibilnošću relacionih.


35

- Podrška za duge transakcije uz korištenje trajnog zaključavanja i za automatsku

kontrolu verzija čini ove baze osnovom za novi pristup distribuiranom dizajnu, jer je

metafora prenošenja poruka prirodna za upotrebu kod distribuiranih sistema.

- Generalno imaju bolje performanse kada su u pitanju složeni objekti i složene

relacije. To je prvenstveno stoga što nema potrebe za razbijanjem velikih objekata

kako bi se pohranili u normalizirane tablice, a zatim ponovno sastavljanje u trenutku

izvršavanja uz uporabu sporih operacija spajanja. Ovo je posebno uočljivo kod

aplikacija koje uključuju inženjerske crteže i kompleksnu grafiku.

- Objektna metafora podržava multimedijalne aplikacije na prirodan način. Objekti s

osobinama oblika, s privremenim ponašanjem (video i zvuk), tekst i drugi koncepti

mogu se modelirati i pohranjivati unutar jedinstvene konceptualne šeme.

- Objektno orijentisane baze daju općenito bolju navigacijsku kontrolu nad upitima

jer su pokazivači vezani za i smješteni uz objekte.

Međutim, ni objektno orijentisane baze nisu imune na probleme. Na čisto teoretskm nivou postoji

problem nepostojanja opće prihvaćenog objektno-orijentisanog modela podataka. Problemi nastaju

i zbog različitih verzija višestrukog nasljeđivanja podržanog od strane različitih produkata baza

podataka i programskih jezika. Čini se neizbježnim da svako ko želi koristiti ovaj aspekt objektno

orijentisane tehnologije, mora osigurati kompatibilnost programskih jezika i baza podataka u

odnosu na to.

Distribuirane objektne baze podataka trebaju riješiti još čitav niz problema. Ne samo da se

tradicionalni problemi zaključavanja i strategije potvrde zapisa javljaju u novom svjetlu, već

postoje i dodatni problemi. Jedan od njih je i kako osigurati identitet objekta na mreži. Iako je

logika protokola zaključavanja lakša za razumijevanje kod objektnih sistema, nije očigledno da se

zaključavanje može sprovesti efikasno u višekorisničkom okruženju. Postoje veoma ozbiljni

problemi zaključavanja vezani za hijerarhiju nasljeđivanja.

Razmišljanje da objektna orijentisanost u bazama podataka i komercijalnim sistemima postaje

stalna osobina softverske industrije, podržano je i pojavom samoimenovanih tijela za


36

standardizaciju koja predstavljaju utjecajne grupe na tržištu. Na jednoj strani je OMG19, a na drugoj

CADF20.

CADF je grupa utiecajnih pojedinaca iz svijeta baza podataka koja je 1990-te godine objavila jednu

vrstu naprednog manifesta baza podataka u kojemu su pobrojani principi koje bi napredni objektno

orijentisani sistem za upravljanje bazama podataka trebao ispuniti u bližoj budućnosti. Ovi principi,

analogno čuvenim 12 Codd-ovih pravila za relacijske sisteme, sadrže slijedeće [Graham,1994]:

§ Objektno orijentisane baze podataka trebale bi imati sve mogućnosti konvencionalnih

DBMS-ova, uključujući upravljanje ogromnim količinama podataka, istovremeni

višekorisnički pristup, jezike visoke razine, istovremeni pristup distribuiranim podacima,

podršku efikasnoj obradi transakcija i potpuni oporavak od grešaka, te sigurnosne

mogućnosti.

§ Objektni identitet treba biti podržan.

§ Treba postojati podrška za najmanje jedan oblik nasljeđivanja.

§ Podrška za transparentni distribuirani pristup i ažuriranje.

§ Podrška za složene objekte kroz enkapsulaciju ili apstraktne tipove podataka i klase.

§ Kreiranje semantički bogatijeg jezika od SQL-a.

§ Podrška za dinamično povezivanje.

§ Podrška za korisnički definisane funkcije.

§ Provjera unosapodtaka i sve mogućnosti korisničkog sučelja.

§ Efikasna kontrola verzija i konfiguracija.

Trenutno su objektno orijentisane baze podataka najbolje za onu vrstu aplikacija kod kojih se

relacioni sistemi ponašaju loše (rad s kompleksnim podacima, multimedijom i sl.), ili tamo gdje je

objektna metafora neophodna. Primjena uključuje distribuirane i klijent-server sisteme, radni tok i

automatizaciju grupnog rada, integriranje modeliranja unutar organizacije, multimedijalne baze

podataka, geografske informacijske sisteme i sl.

19 OMG (engl. Object Management Group) - Grupa objektnog upravljanja.20 CADF (engl. Committee for Advanced DBMS Function) - Komisija za unapređenje DBMS funkcija.


37

4.2.Oblici baza podataka

Baze podataka prema funkcionalnoj namjeni možemo razvrstati na

Operacone (transakcijske, produkcijske) baze podataka - pamte detaljne i aktuelne podatke

potrebne za podršku poslovnih procesa i operacija u e-biznis preduzecu. Primjeri su baza kupaca,

baza ljudskih resursa – personala, baza zaliha i mnoge druge baze generisane poslovnim

operacijama.

Distribuirane baze podataka - Mnoge organizacije repliciraju i distribuiraju kopije ili djelove

baze podataka na razlicite mrežne servere. Distribuirane baze se mogu nalaziti na razlicitim

serverima Web, intranet, extranet ili neke druge kompanijske mreže. Distribuirane baze mogu biti

kopije operacijskih ili analitickih, hipermedijalnih ili nekih drugih tipova baza podataka.

Replikacija i distribucija baza podataka umanjuje performanse i sigurnost baze podataka. Garancija

da ce svi podaci u organizacijskim distribuiranim bazama podataka biti konzistentno i

istovremenoo ažurirani je jedan od glavnih zadataka distribuiranih DBMS-a.

Eksterne baze podataka - Pristup informacijama iz eksternih baza podataka je moguć putem

velikog broja komercijalnih online servisa, kao i sa placanjem ili bez, iz mnogih izvora na

Internetu. Web-stranice osiguravaju putem hiperlinkovanih strana pretraživanje multimedijalnih

dokumenata u hipermedijalnim bazama podataka. Eksterni podaci su najcešce u vidu statistickih

baza podataka nastalih kao rezultat ekonomskih i demografskih istraživanja i aktivnosti. Takođe su

popularne bibliografske ili full text baze iz kojih se mogu vidjeti ili download-ovati apstrakti ili

kompletne kopije raznih casopisa, istraživackih radova i drugih publiciranih materijala.

Data Warehouse i Data Mining - Data Warehouse baza podataka čuva podatke izdvojene iz

razlčcitih operacionih, eksternih ili nekih drugih baza podataka u okviru organizacije. Ona je

središnji izvor prečišženih i transformiranih aktuelnih i historijskih podataka koje koriste

menadžeri i drugi poslovni stručnjaci za data mining, OLAP (online analytical processing) i druge

vrste poslovnih analiza, istraživanja tržišta, i podršku odlucivanju. Data warehouse može biti

podijeljen na data mart-ove koji sadrže podskupove podataka warehose-a koji su fokusirani na neki

specifični aspekt kompanije, kao što je odjel ili poslovni proces.


38

Hipermedijalne baze podataka na Web-u. Ubrzani napredak Web tehnologija je značajno

povećao primjenu baza hipermedijalnih dokumenata koje se nazivaju hipermedijalne baze

podataka. Hipermedijalna baza podataka je zapravo webstranica koja se sastoji od hiperlinkovanih

multimedijalnih strana. Dakle, sa tačke gledišta teorije baza podataka, hipermedijalna baza

podataka nije skup medusobno povezanih slogova, već skup medusobno hiperlinkovanih

multimedijalnih strana.

4.3 Distribuirana baza podataka

Distribuirana baza podataka je baza podataka koja se ne nalazi u cjelini na jednom računaru

(serveru) već je razdijeljena na više lokacija koje su povezane komunikacijskom mrežom. Svaka

lokacija, koja se zove i čvor komunikacijske mreže, ima svoj vlastiti, autonomni ssistem za

upravljanje bazama podataka (DBMS), sa vlastitom kontrolom, upravljačem transakcija i opravka

od pada, i ostalim važnim funkcijama, a ima i svoj procesor i ulazno/izlazne uređaje.

Aplikacije istovremeno pristupaju i mijenjaju podatke na više razlicitih baza podataka u mreži, gdje

mreža može biti LAN ili WAN.

Osnovne karakteristike ovog oblika baze podataka

- Skup logički povezanih djeljivih podataka

- Podaci su razdvojeni na više fragmenata

- Fragmenti se mogu replicirati

- Fragmenti/Replikacije pripadaju lokacijama

- Lokacije su povezane komunikacijskom mrežom

- Podaci na svakoj lokaciji su pod nadzorom DBMS-a

- DBMS na svakoj lokaciji može upravljati lokalnim aplikacijama autonomno

- Svaki DBMS učestvuje u najmanje jednoj globalnoj aplikaciji.


39

Slika 4.1 Prikaz sistema distrubirane baze podataka

Prednosti koje donosi distribuirani koncept baze podataka:

- Lokalna autonomija podataka, upravljanja i kontrole. Okruženje u kojem se DBP primjenjuju

je i samo distribuirano (npr. univerziteti, fakulteti, zavodi; centralna biblioteka, matični uredi,

ministarstvo, regionalni centri itd.) .Distribuiranje baza podataka kao i ssistema za upravljanje

njima, omogućava pojedinim grupama da lokalno kontrolišu vlastite podatke, uz mogucnost

pristupa podacima na drugim lokacijama kada je to potrebno.

- Veci kapacitet i postupni rast. Čest razlog za instaliranje distribuiranog sistema je nemogućnost

jednog servera da primi i obrađuje sve potrebne podatke. U slučaju da potrebe nadmaše postojeći

kapacitet, dodavanje čvora distribuiranom sistemu je znatno jednostavnije nego zamjena sistema

većim.


40

- Pouzdanost i raspoloživost. Distribuirani sistemi mogu nastaviti svoje funkcionisanje i kada

neki od čvorova izgube funkcionalnost.

- Efikasnost i fleksibilnost. Podaci su fizički blizu onome ko ih stvara i koristi, pa je znatno

smanjena potreba za udaljenom komunikacijom.

Da bi se postigla visoka efikasnost DSMDB, sve njegove komponente treba realizovati na takav

način da se smanji mrežna komunikacija. Najznačajniji problemi koje pri tome treba riješiti su:

- fragmentacija podataka

- distribuirana obrada upita

- distribuirano ažuriranje

- upravljanje katalogom

- distribuirano izvršenje skupa transakcija, što uključuje konkurentnost, integritet,

- oporavak i protokole kompletiranja transakcija

Fragmentacija podataka

Podaci u distribuiranom sistemu mogu biti particionirani ili ponovljeni u fizickoj memoriji. U

slučaju ponavljanja podataka, jedan logički objekt može imati veci broj kopija na većem broju

lokacija. Ponovljenost podataka povecava raspoloživost podataka i efikasnost pristupa podacima,

ali značajno komplicira ažuriranje podataka, koji moraju biti konzistentni u svim svojim kopijama.

Složenost koju nosi sa sobom strategija ponavljanja podataka mora biti sakrivena od korisnika, tj.

mora biti osigurana nevidljivost ponavljanja podataka.

U slucaju particioniranja podataka,logički skup podataka treba na neki nacin podijeliti, a zatim

dijelove - fragmente (može i sa ponovljenim kopijama) razdijeliti po raznim lokacijama. Logički

skup podataka u relacijskom sistemu je relacija, a prirodni fragment relacije je neki njezin podskup

definisan uslovom projekcije i restrikcije. Fragmentacija mora biti izvedena tako da se spajanjem

fragmenata dobije polazna relacija.

Distribuirana obradba upita


41

Distribuirana obradba upita podrazumijeva distribuiranu optimizaciju kao i distribuirano izvršenje

upita. Strategije optimizacije upita nad distribuiranom bazom podataka imaju za cilj

minimalizaciju cijene obradbe i vremena za koje ce korisnik dobiti odgovor.

U troškovima obradbe najveci udio imaju troškovi mrežne komunikacije, tj. Prenosa podataka kroz

mrežu, dok su troškovi komunikacije sa ulazno/izlaznim uredajima i korištenja procesora manji za

nekoliko redova velicine. Zbog toga je vrlo značajno, u zavisnosti od propusnosti mreže (količina

podataka koju može primiti u sekundi) i vremena kašnjenja, pravilno odabrati relacije i njihove

fragmente koji će biti prenošeni s jedne lokacije na drugu s ciljem obradbe upita (globalna

optimizacija). Razlog za prenošenje podataka može biti taj što su podaci na lokaciji različitoj od

one na koju se postavlja upit, ili što u upitu učestvuje veci broj relacija s različitih lokacija. Izbor

strategije za izvršenje operacija na jednoj lokaciji zove se lokalna optimizacija.

Distribuirano ažuriranje

Ponavljanje podataka podrazumijeva da jedan logički objekt (relacija ili fragment) može imati više

kopija na većem broju lokacija. Posljedica toga je da se, s obzirom na potrebu za konzistentnošcu

podataka u svim kopijama, ažuriranje jednog logičkog objekta mora prenijeti i na sve fizičke kopije

tog objekta. Međutim, trenutno prenošenje ažuriranja može onemoguciti ( ili nedopustivo dugo

odložiti) uspješno izvršavanje ažuriranja u slučaju da je bilo koja lokacija u padu; na taj način

ponavljanje podataka ne povećava, nego smanjuje raspoloživost podataka.

Jedan široko prihvaćeni pristup prijenosu ažuriranja oslanja se na koncept primarne kopije, i sastoji

se od dva dijela:

- jedna kopija svakog ponovljenog objekta proglašava se primarnom kopijom tog objekta,

pri čemu primarne kopije različitih objekata mogu biti ba različitim lokacijama

- operacija ažuriranja objekta smatra se logicki izvršenom čim se izvrši ažuriranje

primarne kopije tog objekta; ažuriranje ostalih kopija je sada u nadležnosti lokacije na

kojoj je primarna kopija, ali se mora izvršiti prije kompletiranja transakcije.

Ovaj postupak zahtjeva primjenu protokola dvofaznog kompletiranja transakcije, koji se ne može

uspješno provesti ako je bar jedna relevantna kopija u padu , što je čest slucaj. Ukoliko se dopusti

ažuriranje kopija i poslije kompletiranja transakcije, ne može se garantovati konzistentnost

podataka u svim njihovim kopijama.


42

Upravljanje katalogom

Katalog je baza podataka koja sadrži podatke o baznim relacijama, pogledima, indeksima

korisnicima itd., a u slučaju distribuiranog sistema, i o načinu i lokacijama na koje su podaci

razdijeljeni i (možda) ponovljeni. Sam katalog u distribuiranom sistemu može biti centraliziran

(samo na jednoj lokaciji), potpuno ponovljen (na svim lokacijama po jedna kopija kataloga),

particioniran (na svakoj lokaciji je dio kataloga koji se odnosi na objekte te lokacije) ili

kombinovan (katalog je particioniran ali na jednoj lokaciji postoji jedna centralna kopija cijelog

kataloga ).

S obzirom na nedostatke koje ima svaki od navedenih pristupa (zavisnost od centralne lokacije,

visoka cijena prenosa ažuriranja kataloga, skup pristup udaljenoj lokaciji) implementirani sistemi

koriste neke druge strategije.

Distribuirano upravljanje transakcijama

Pod transakcijom u distribuiranom sistemu podrazumijeva se vremenski niz uređenih radnji koji

prevodi jedno konzistentno stanje baze u drugo konzistentno stanje. Transakcija može izvršavati i

radnje svog programa na raznim lokacijama. Na taj način transakcija može izvršavati više procesa

na više lokacija. Pokretanjem jedne transakcije bira se jedan upravljač transakcija (na jednoj

lokaciji) koji služi kao koordinator procesa te transakcije. Svakoj transakciji se dodjeljuje i njezin

privatni radni prostor (koji može biti raspoređen na više lokacija), iz kojeg će transakcija čitati i u

kojeg će se upisivati vrijednosti objekata. Pri distribuiranoj obradbi transakcija, transakcija koja

čita vrijednost objekta, čita vrijednost samo jednog lokalnog primjerka tog objekta, dok ažuriranje

jednog objekta sprovodi nad svim primjercima tog objekta.

Oporavak

Da bi se dobila atomičnost transakcije u distribuiranom okruženju, u smislu da se izvrše sve njene

radnje ili nijedna, sistem za ipravljanje transakcijama mora osigurati da se svi procesi te transakcije

uspješno kompletiraju ili da se svi njihovi efekti ponište. Na primjer, da bi se izvršilo ažuriranje

logičkog objekta x, od strane neke transakcije, potrebno je uspješno izvršiti ažuriranje svih

primjeraka tog objekta. Taj zadatak zahtjeva posebno razmatranje zato što su primjerci jednog

objekta na raznim lokacijama koje, nezavisno jedna od druge, mogu biti onemogućene da izvrše tu

radnju (npr.zbog pada sistema). Da bi se osiguralo da ažuriranja svih primjeraka svih objekata od


43

strane jedne transakcije budu uspješno izvršena, ili da nijedno ne bude izvršeno, primjenjuje se

poseban protokol dvofaznog komplementiranja transakcije. Njemu se pristupa kada je koordinator

transakcije obaviješten da su svi procesi te transakcije završili sa radom(uspješno ili neuspješno),

i sastoji se od dvije faze:

- Za svaki logicki objekt x koji transakcija T ažurira, i za svaki primjerak xi objekta x,

koordinator te transakcije šalje poruku lokaciji i (njenom DBMS) da preliminarno

ažurira objekt xi . Ako je proces transakcije T na lokaciji i uspješno izvršen, lokacija i

odgovara tako što izvrši preliminarno ažuriranje, tj. prepisuje vrijednost xi iz radnog

prostora transakcije u svoju log datoteku, i obavještava o tome koordinatora; u

suprotnom slucaju, lokacija obavještava koordinatora o neuspjehu.

- Ako je koordinator obaviješten da su sve radnje preliminarnog ažuriranja svih objekata

koje transakcija T ažurira, na svim lokacijama, uspješno obavljene, on šalje poruke tim

lokacijama da izvrše operaciju konacnog ažuriranja svih svojih primjeraka svih objekata

koje T ažurira; lokacije odgovaraju tako što odgovarajuče vrijednosti iz svojih log

datoteka prepisuju u svoje lokalne baze i oslobađaju resurse koje je transakcija T držala.

Kada se obave sva ta prepisivanja i o tome obavijesti koordinator, izvršenje transakcije

T je završeno. Ako je koordinator obaviješten da bar jedna lokacija nije uspješno

obavila prvu fazu, on šalje poruku svim lokacijama o poništenju transakcije.

Ovakav protokol dvofaznog komplementiranja transakcije u implementacijama se poboljšava na

razne načine, u cilju smanjenja broja poruka koje se prenose. Npr., moguće je pretpostaviti da će

komplementiranje biti uspješno i time eliminisati slanje poruka iz prve faze. Ukoliko je

kompletiranje zaista uspješno, broj poruka je znatno smanjen; ukoliko je kompletiranje (a

pretpostavlja se da je to riješi slučaj), broj poruka se uvećava,a zahtjeva se i poništavanje

određenog broja radnji.


44

4.4 Data warehousing (Skladištenje podataka)

Zbog složenih uslova poslovanja, podaci koji se generišu u organizacijama se multipliciraju i

pohranjuju se u transakcione baze podataka koje dostižu terabajte podataka. Zbog veličine baza

nije ih moguće pretraživati u realnom vremenu, niti dobiti jezgrovit izvještaj na postavljene upite.

Već je ranije u tekstu naglašen značaj informacija za poslovanje organizacije, imajući prvenstveno

u vidu pravovremenost dobijanja informacija i n jihovu konciznost radi ostvarivanja konkurentskih

prednosti organizacije. Iz navedenog proizilazi da se od današnjih informacionih sistema poslovnih

organizacija očekuje da osiguraju informacije čiji sadržaj, brzina pristupa informacijama i način

prezentovanja odgovaraju konkretnim potrebama menadžera u procesu odlučivanja. Pomenute

transakcione baze su zasnovane na klasičnom principu, relacioni model koji obezbjeđuje ažurno

stanje poslovnog sistema, no u takvim bazama se određenim podacima nakon ažuriranja gubi trag,

a za donošenje pravilnih poslovnih odluka potrebno je imati uvid i u vremenski redoslijed zbivanja

poslovnih događaja, pa tako koncipirane baze ne predstavljaju zadovoljavajuće rješenje. Radi toga

je razvijen novi koncept organizovanja podataka u skladišta podataka. Skladište podataka sadrži

podatke prikupljene iz različitih izvora, istorijske podatke o poslovanju iz transakcionih baza

organizacija i podatke iz okruženja, a dizajnirano je tako da omogućava pretragu podataka, on-line

analitičku obradu, izvještavanje i podršku odlučivanju.

Od brojnih definicija skladišta podataka, definicija Williama H Inmon-a21 predstavlja cjelovit

pristup temi. Prema ovom autoru "skladište podataka predstavlja subjektno usmjeren (subject-

oriented), integrisani (integrated),vremenski uslovljen (time-variant) i sadržajno nepromjenjiv

(non-volatile) skup podataka, a krajnji cilj mu je podrška menadžmentu pri donošenju odluka."

Subjektna usmjerenost podataka znači da se oni organizuju oko predmeta poslovanja, na način

da sadrže informacije o tačno određenim predmetima u okviru funkcionalnih područja (prodaja,

nabavka...) umjesto o tekućim operacijama organizacije (narudžbe, isporuke i sl.)

Integrisanost podataka koji se prikupljaju uz različitih izvora i pohranjuju u

standardizovanom formatu, konzistentni i prezentabilni na dosljedan način.

21 Preuzeto od Višnja Ljubetić: "Upravljanje znanjem primjenom alata poslovne inteligencije", magistarski rad, Zagreb2005, str. 40.


45

Vremenski uslovljeni – svi podaci u skladištu podataka su vezani i identifikuju se uz

određeni vremenski period, što odgovara njihovom istorijskom karakteru, a ujedno odražava

koncept poslovne inteligencije da temeljito predviđanje budućih događaja nije moguće provesti bez

poznavanja prošlih događaja. Iako su podaci u skladištu podataka iz prošlosti, oni su usmjereni ka

budućnosti.

Sadržajna nepromjenjivost, znači da su podaci u skladištu nakon pohranjivanja

nepromjenjivi, što ima odraza na buduće upite, odgovori će uvijek biti isti za jedan period bez

obzira na frekvenciju i vremensku dimenziju upita.

Uloga skladišta podataka je da svim zainteresovanim ovlaštenim osobama u organizaciji

stavi na raspolaganje informacije koje su do tada bile "zaključane" u transakcionim/operativnim

bazama podataka, zajedno sa podacima iz vanjskih izvora a koje su relevanti za donošenje

upravljačkih odluka. (podaci o konkurentima, demografski podaci, trendovi i sl.) Dakle,

skladištenje podataka je kontinuiran proces koji zahvata ogromnu količinu podataka iz raznih

izvora oblikovanih na svrsishodan način, pri tome mora zainteresovanim osobama omogućiti

pouzdan, brz i jednostavan pristup u svako doba i mora posjedovati fleksibilnost da bi moglo da

služi organizaciji na njenom strateškom putu.

ETL procesi

Najobimniji posao u aktivnostima skladištenja podataka predstavljaju procesi integisanja

podataka kako iz operativnih baza podataka, tako i iz drugih izvora i organizovanje njihovog

sadržaja.tim aktivnosima se bavi skup procesa pod imenom ETL procesi (extraction,

transformation i loading). Samom ETL procesima prethode određene aktivnosti na formatiranju,

usklađivanju i čišćenju podataka, što znači da ulazne podatke treba standardizovati u jedinstveni

format. Usklađivanje je potrebno radi izbjegavanja redundancije podataka, a čišćenje

podrazumijeva uklanjanje pogrešnih podataka nastalih u ranijim procesiranjima i drugim

informacionim sistemima. (uklanjanje netačnih, nekonzistentnih i nekompletnih podataka.)

Karakeristika ETL procesa je izbor odgovarajućih alata koje koristimo u pojedinim djelovima u

zavisnosti od procjene kvaliteta ulaznih podataka. Naprimjer, ako su performanse alata bolje u

procesu čišćenja, onda su slabije u dijelu transformacije ili obratno. Radi djelotvornog izbora alata

potrebno je znati karakteristike podataka koji se skladište i prema potrebi birati ETL alate koji su

jači u jednom ili drugom procesu.


46

Ekstrakcija podataka

Ovaj proces se odvija u pozadini redovnih poslova minimalno opterećujući redovne

operativne poslove. Pristup ekstrakciji odnosno izboru alata za ekstrakciju treba da karakteriše

brzina zahvatanja podataka i djelotvornost u smislu izbjegavanja redundancije podataka. Prirodan

izbor je da se za zahvatanje izaberu samo podaci koji će se koristiti u aplikacijama poslovne

inteligencije.

Transformacija podataka

U okviru ETL procesa najveći potrošač vremena je postupka transformacije podataka, nekih

80% od ukupnog vremena za ETL procese. Razlozi za to leže u:

- nekonzistentnosti podataka koja se javlja prilikom njihovog kopiranja, pri čemu kopija

nije u potpunosti vjerna originalu.

- nepodudarnost primarnih ključeva podataka iz izvornih datoteka sa onima koje koristi

aplikacija poslovne inteligencije.

- netačne vrijednosti podataka, što se rješava u fazi čišćenja podataka postavljanjem

odgovarajuće logike čišćenja.

- različiti formati podataka naprimjer, datum sa računa ili broj računa banke nije u istom

formatu kako ga očekuje alat poslovne inteligencije te ih treba podesiti.

- problem sinonima i homonima, ponekad se isti podaci pojavljuju pod različitim nazivima

(sinonim) ili se različiti podaci pojavljuju pod istim nazivom (homonim), u oba slučaja

potrebno ih je uklanjati.

- "skrivena procesna logika", kada se koriste podaci iz tzv. Legacy aplikacija, pri čemu su

nejasni odnosi između podataka niti ima ko da ih rasvjetli, pa ih treba transformisati u

poznati tip odnosa.


47

Punjenje skladišta podataka

Govoreći o podacima potrebnim za skladište podataka organizacije, a imajući u vidu

njihovu namjenu u konceptu poslovne inteligencije, sigurno da podaci porijeklom iz transakcionih

baza organizacije nisu dovoljni za tu svrhu. Tako da je nužno pored izvornih podataka u skladišta

podataka pohranjivati i istorijski podatak iz arhiva organizacije i drugih izvora. To doprinosi da se

za punjenje baza koristi više vrsta ETL programa, kao što su programi za inicijalno punjenje, za

punjenje istorijskih podataka i programi za dopunjavanje prema utvrđenom rasporedu

(inkrementalno punjenje). Kada je bilo riječi o transformaciji podataka, rečeno je da se mora voditi

računa o određenim neusaglašenostima koje se mogu javiti u tom postupku, na ovom mjestu se

konkretizuje misao i govorimo o inicijalnim programima za čišćenje i usklađivanje živih podataka

(tekući podaci iz transakcionih baza) radi eliminisanja grešaka. Nakon toga, kao produžetak

aktivnosti, moramo koristiti drugačije programe za čišćenje i usklađivanje istorijskih podataka iz

ranije razmotrenih razloga (format, logička povezanost i sl.) Poslednji po redu su programi za

inkrementalno punjenje podataka koji se aktiviraju pošto inicijalni programi završe svoje aktivnosti

na čišćenju i usklađivanju podataka. Inkrementalni programi su aktivna komponenta koja prema

utvrđenom rasporedu vrši dopunjavanje skladišta podataka od zadnjeg zapisanog stanja tako da se

izbjegava dupliranje podataka i slične greške. Slika ispod prikazuje tok ETL procesa kao važne

spone u kreiranju skladišta podataka i preduslova za razvoj i primjenu poslovne inteligencije.

Procesi

BI Izvještaji

Skladište podataka Transakcione baze

Za arhitektura skladišta podataka može se reći da generalno prati uobičajenu arhitekturu

informacionih sistema, ali ima i svojih specifičnosti, pa tako imamo:

E T L


48

· Dvoslojnu arhitekturu sa zajedničkim centralnim skladištem podataka. Skladište

podataka je velikog obima i složene kompozicije podataka, što mora biti praćeno i

širokom lepezom aplikacionih zahtjeva. Ovakva arhitektura je troškovno zahtjevna i

traži iznad prosječan angažman ljudskih resursa.

· Dvoslojnu arhitekturu sa distribuiranim skladištima podataka. Karakteristika ovog tipa

je postojanje većeg broja nezavisnih lokalnih spremišta podataka namjenjenih ta

podršku pojedinačnim aplikacijama u organizacionim jedinicama. Ovaj model je

jednostavnije izgraditi i njegovo korištenje je jednostavnije, ali ima i nedostatke koji se

odražavaju u:

o Komunikacionim problemima između organizacionih jedinica, što mu umanjuje

vrijednost u situacijama koje zahtijevaju međusobnu komunikaciju i kolaboraciju više

organizacionih jedinica.

o Povećanje opterećenja baza transakcionih sistema (narušava se princip procesa u

pozadini koji ne ometaju primarne transakcije).

o Lokalno skladište ili data-mart podržava samo jednu aplikaciju, pa naknadno

povećanje broja aplikacija koje koriste isto skladište podataka postaje problematično.

o Autonomija koju data-mart-ovi imaju otežava uvid u pravo stanje informacija na

nivou čitave organizacije.

· Troslojnu arhitekturu. Model se sastoji od većeg broja data-mart-ova i jednog

centralnog skladišta podataka koje korespondira (dvosmjerna komunikacija) sa

lokalnim skladištima, omogućavajući tako integritet i usklađenost podataka. Troslojni

model obezbjeđuje veću tačnost informacija bez obzira na izvor. Prevazilazi

komunikacione probleme između organizacionih jedinica, smanjen angažman posebno

obučenog osoblja (informatičara), povećana skalabilnost i proširivost platforme za

skladištenje podataka i ujedno ostavlja otvorenom mogućnost korištenja vanjskih

aplikacija.


49

4.5 Data Mining (rudarenje podataka)

Pojam data mining (rudarenje podataka) je povezan sa skladištima podataka, a označava

pretraživanje podataka i otkrivanje znanja u bazama podataka, akcenat mu je na poslovni a ne na

tehničko-tehnološki aspekt.

Često se na rudarenje podataka gleda kao na finalnu manifestaciju procesa skladištenja

podataka. Rudarenje podataka predstavlja proces pronalaženja trendova, zakonitosti, modela i

odnosa među podacima, do kojih dolazimo uz pomoć alata za rudarenje podataka. Alati za

rudarenje daju odgovore na poslovna pitanja za čije rješavanje tradicionalnim metodama je

potrebno mnogo više vremena. Pretraživanje baza podataka otkriva nove matrice ponašanja

kupaca, konkurencije, što omogućuje donošenje proaktivnih odluka baziranih na znanju

(knowledge-driven decisions). Razvoj metoda koje se danas koriste u okviru pojma rudarenje

podataka počinje 70-tih i 80-tih godina prošlog vijeka, a od sredine 90-tih pojam rudarenje

podataka objedinjuje skup metoda i postupaka koje za cilj imaju otkrivanje zakonitosti u masi

podataka.

Tehnike rudarenja predstavljaju rezultat dugog procesa istraživanja i razvoja statističkih

algoritama, ovaj evolucioni proces započeo je zajedno sa kompjuterskom obradom podataka i traje

u kontinuitetu, uporedo sa razvojem informacionih tehnologija i to:

- sve moćnijom multiprocesorskom tehnologijom (Moore-ov zakon),

- tehnologijom za masovno prikupljanje podataka i

- stalno rastućim brojem algoritamskih tehnika za rudarenje podtaka.

Na putu od poslovnih podataka do informacija poslovne inteligencije, svaki novi korak je

sagrađen na prethodnom. Napredak tehnologija omogućava da se istorijski podaci u skladištima

podataka koriste za izradu modela koji osvjetljavaju kretanja sistema u prošlosti i izvlače konkretne

zaključke i na tom osnovu predviđaju buduća kretanja poslovnog sistema u određenom vremenu.

Radi se o dinamičnom pristupu istraživanja podataka (data exploration) kojim se iz velike količine

podataka dolazi do skrivenih podataka od značaja za pribavljanje novih informacija i otkrivanja

znanja temeljenog na podacima i stvaranje nove poslovne vrijednosti.

Otkrivanje znanja rudarenjem podataka se odvija kroz nekoliko faza ili koraka:


50

- selekcija podataka – u prvom koraku se odabire ciljani skup podataka na kojima će se

provesti postupak otkrivanja znanja, odnosno vrši se izbor baza podataka, varijabli i

uzoraka podataka. (demografski podaci, podaci o prodaji i sl.)

- pročišćavanje podataka – u ovoj fazi se podaci zahvataju sa raznih računara i baza,

zatim se čiste i uparuju,

- redukcija i projekcija podataka – ovdje se vrši transformacija podataka iz transakcionih

baza podataka i ostalih izvora u višedimenzione baze. Npr. na primjeru maloprodaje,

dimenziona baza se sastoji iz dimenzije vremena, dimenzije maloprodajnih objekata i

dimenzije kupaca,

- određivanje metode rudarenja – u poslednjem koraku vrši se izbor najprikladnije

metode rudarenja podataka, npr. metoda klasifikacije, klaster metoda, analiza

potrošačke korpe i sl.

Kruna niza prethodnih aktivnosti jeste pravilna interpretacija i izvođenje zaključaka kao

rezultat procesa otkrivanja znanja.

Kvalitet dobijenih izvještaja kao rezultat rudarenja podataka je u direktnoj zavisnosti od

kvaliteta podataka. Opet, kvalitet podataka zavisi od stepena razvijenosti informacionog sistema

organizacije i razvijenosti sistema skladištenja podataka koji obuhvata sve relevantne atribute koji

se planiraju koristiti u analizama. U njima su podaci već čisti, integrisani i potpuni.

U zavisnosti od potreba organizacije i odabrane strategije, koriste se i različite metode

rudarenja podataka koje nisu privilegija jednog područja društvene aktivnosti, već se koriste

svugdje gdje se raspolaže sa velikom količinom podataka na osnovu kojih se žele otkriti određene

veze, pravilnosti i zakonitosti (u medicini, mikrobiologiji, genetici, mehanici i sl.) Najčešće je u

upotrebi nekoliko metoda u procesu rudarenja:

- Regresiona metoda. Koristi se za opisivanje veza između varijabli od primarnog

interesa (prodaja, računi) i tzv. prediktorskih varijabli, odnosno kada se na osnovu

postojećih vrijednosti vrši predviđanje budućih vrijednosti. Poznate su linearna

regresija, višestruka regresija, polinomna regresija itd. No, za većinu problema se ne

može primjeniti jednostavna linearna regresiona metoda. Postoje kategorije koje je

teško predvidjeti kao što je obim prodaje, kretanja vrijednosti na berzi ili pad


51

proizvodnje, jer te vrijednosti zavise od mnogostrukih varijabli, pa se za te slučajeve

primjenjuju druge metode poput stabla odlučivanja ili neuronskih mreža.

- Metoda klasifikacije. Ovdje ubrajamo metode za svrstavanje posmatranih pojava u

jednu od prethodno definisanih klasa ili grupa. Metoda klasifikacije identifikuje

zajedničke karakteristike koje označavaju grupu kojoj pripada svaki pojedinačni slučaj.

- Metoda klastera. Za razliku od klasifikacije, klaster metoda predstavlja postupak kojim

se vrši grupisanje objekata sličnih karakteristika sa ciljem pronalaženja grupa koje se

znatno razlikuju jedna od druge, dok su članovi unutar grupa vrlo slični jedni drugima.

Ovdje nemamo prethodno definisane klase niti atribute po kojima će se podaci

svrstavati u grupe klastera. Za provođenje klaster metode postoje različiti algoritmi od

kojih ćemo navesti dva K-means i Hijerarhijsko klasterisanje i nećemo ih dalje

opisivati. Karakteristika svih algoritama je da rade samo sa numeričkim vrijednostima,

kada se u proces analize uvrste i nenumeričke varijable, prethodno treba izvršiti

transformaciju nenumeričke u numeričke vrijednosti. Metoda se koristi za početno

segmentiranje tržišta, kao i za praćenje trendova i u drugim situacijama.

- Neuronske mreže. Ili nelinearni modeli predviđanja omogućuje modeliranje velikih i

kompleksnih problema koji uključuju stotine varijabli i mnogobrojne interakcije. Treba

naglasiti da postoje biološke neuronske mreže koje su neuporedivo kompleksnije od

matematičkog modela koji se koristi u praksi prema funkcionalnoj šemi. Neuronske

mreže nije lako interpretirati, pošto zahtjevaju sveobuhvatan trening za osposobljavanje,

osim u slučajevima rješavanja "malih" problema.

- Stablo odlučivanja. Predstavlja način klasifikacije atributa u odnosu na zadatu ciljnmu

varijablu. U slučaju stabla odlučivanja interpetacija rezultata je lagana.

- Metode za analizu veza. Ovdje spada i metoda za analizu potrošačke korpe, služe za

analizu kombinacija proizvoda koji se često kupuju zajedno. Glavni cilj ove metode je

otkrivanje zakonitosti kupovine skupina proizvoda u trgovačkim centrima, a može se

iskoristiti za povećanje prodaje. Suština metode se sastoji u otkrivanju asocijativnih

pravila koja ukazuju koji se parovi proizvoda i sa kojom vjerovatnoćom kupuju

zajedno.

- Genetički algoritmi. Koriste se kao tehnike za rješavanje problema optimizacije,

naprimjer kreiranje rasporeda rada u smjenama i slično.


52

Znanja otkrivena u procesu rudarenja podataka prezentiraju se u obliku izvještaja ili se

formalizuju i pohranjuju u sisteme zasnovane na pravilima. Neki sistemi poput neuronskih mreža

su sposobni osim pravila prihvatiti dinamičke modele. Sistemi zasnovani na pravilima se mogu

podijeliti na tradicionalne ekspertne sisteme i sisteme zasnovane na neizrazitoj logici.

Na tržištu postoji veliki broj firmi koji nude softver za rudarenje podataka različitih

namjena i stepena specijalizacije. u današnjim tržišnim uslovima, poslovni procesi generišu

ogromne količine podataka, pa baze dostižu veličinu koja se mjeri terabajtima, pri čemu se jaz,

između mogućnosti prikupljanja podataka i analize podataka, stalno povećava. U tako "nakrcanoj"

bazi se skrivaju informacije od strateškog značaja za organizaciju. Uspješno rudarenje podataka je

uslovljena sa dva činioca, pravilno integrisano skladište podataka i dobro razumijevanje i

poznavanje procesa poslovanja nad kojim se želi primjeniti postupak rudarenja podataka, kao i broj

kadrova koji raspolažu sa analitičkim vještinama.

Primjena rudarenja podataka nije ograničena na uska područja poslovanja, primjenjuje se u

proizvodnji, telekomunikacijama, bankarstvo, finansije, osiguranje, maloprodaja i druga, pri čemu

je najkorisnija tamo gdje postoji prijetnja poplave podataka.


53

4.6 Poslovna inteligencija

U složenim poslovnim sistemima svijest o korisnosti prihvatanja koncepta poslovne

inteligencije raste svakim danom, a time raste i potreba za uvođenjem informacionih sistema koji

su sposobni podržati takve trendove. Pomoću alata BI organizacije efikasnije povezuju ljude sa

njihovim poslovanjem, sa kupcima, dobavljačima i partnerima, omogućavajući uvid u ogromnu

količinu kompleksnih podataka. Ističu se sljedeći tipovi alata:

- Alati za upite predstavljaju programske pakete koji omogućavaju korisnicima

postavljanje upita o matricama ili detaljima na koje se podaci odnose.

- Alati za rudarenje podataka, koji omogućavaju automatsko pretraživanje

karakterističnih matrica ili korelacija među podacima.

- Softver za multidimenzionalne analize ili pozantiji kao OLAP (Online Analytical

Processing).

Današnje poslovanje karakteriše zagušenje poslovnih sistema enormnim količinama

podataka i informacija internog i eksternog karaktera. Primjena koncepta poslovne inteligencije

omogućava organizacijama korištenje samo onih informacija koje su im u određenom vremenu

potrebne za donošenje poslovnih odluka u obliku koji im odgovara. Dalje, primjena poslovne

inteligencije smanjuje količinu podataka kojima su zaposleni izloženi uz istovremeno povećanje

kvaliteta informacija. Iz ovoga proizilazi da je glavna namjera koncepta poslovne inteligencije

generisanje što kvalitetnijih informacija potrebnih u procesu donošenja odluka.

Karakteristika poslovne inteligencije da je proaktivna, potiče iz operativnih podataka i

orijentisana na je na isporuku informacija korisnicima prema njihovim preferencijama.

Posjedovanje prave informacije je danas osnovni preduslov za preživljavanje organizacije

u turbulentim uslovima koji vladaju na tržištu. Ona omogućava organizacijama pravovremeno

povlačenje odgovarajućih poslovnih poteza. Prema procjenama, tipična organizacija danas

analizira samo 10% prikupljenih podataka.22 Implemetacijom sistema poslovne inteligencije

organizacija može koristiti i preostale podatke iz svih izvora transformišući ih u kvalitetne

informacije. Primjena koncepta poslovne inteligencije omogučava organizaciji i:

· Analizu ponašanja kupaca i dobavljača

22 Preuzeto od Višnja Ljubetić: "Upravljanje znanjem primjenom alata poslovne inteligencije", magistarski rad, Zagreb2005, str. 68.


54

· Određivanje ko su ključni kupci, dobavljači i troškovi

· Gdje i kod kojih kupaca nastaje poslovni rezultat

· Djelotvornije pregovaranje sa kupcima i dobavljačima

· Analizu djelotvornosti upravljanja

· Lakše predviđanje budućih trendova i

· Uvid u ponašanje pojedinih tržišnih segmenata.

Uvođenje sistema poslovne inteligencije u naprednim organizacijama se javlja kao potreba

zbog sve jače tržišne utakmice, razvijenih distribucionih kanala i ponude roba i usluga koja znatno

premašuje potražnju, prema nekim istraživanjima i 30-tak% više od stvarnih potreba. Alati

poslovne inteligencije omogućavaju organizaciji da brzo reaguje na prijetnje koje dolaze iz

okruženja. Još jedan razloga za primjenu poslovne inteligencije jeste zadržavanje postojećih i

privlačenje novih kupaca, pri čemu je pronalaženje novih kupaca višestruko skuplje od zadržavanja

postojećih. Prema rezultatima istraživanja Harvard Business Review-a, ako organizacija uspije

smanjiti odlazak kupaca konkurentima za 5%, može udvostručiti svoju zaradu. Istraživanja Gartner

Group u 2004. pokazuju da samo 20% velikih kompanija iskorištava 50% prikupljenih podataka u

cilju povećanja konkurentske prednosti, što nas navodi na to da prihvatanje koncepta poslovne

inteligencije predstavlja mogućnost koju će veliki broj poslovnih sistema što prije prihvatiti

ukoliko žele opstati na tržištu.

Sa stanovišta informatičke infrastrukture, sistem poslovne inteligencije započinje sa

izgradnjom skladišta podataka kao centralnom bazom organizacije u koju se slivaju svi podaci

internog karaktera (nastali u organizaciji) ili podaci iz vanjskih izvora. Proces punjenja skladišta je

objašnjen ranije uz korištenje ETL alata, ono što nas nakon toga zanima je mogućnost analize.

Eksploatacija i vizuelizacija podataka se vrši uz pomoć multidimenzionalne analize ili korištenje

OLAP ( On-Line Analytical Processing) alata. Skraćenica OLAP podrazumijeva kategoriju

aplikacija i tehnologije namijenjenu za skupljanje, upravljanje, obradu i prezentaciju

multidimenzionalnih podataka namjenjenih analizama za potrebe upravljanja. OLAP alati se

međusobno mogu jako razlikovati, stoga je bitno da pri akviziciji alata u njihovom vrednovanju u

cilju izbora najpovoljnijeg rješenja, učestvuju i korisnici i IT stručnjaci. Modeli OLAP su lagano

razumljivi, pa korisnici ne moraju vladati posebnim analitičkim vještinama. Takođe, ih karakteriše

velika brzina rada što ima efekta na efikasnost ukupnih napora kod donošenja odluka. Spektar

mogućnosti koje obuhvataju OLAP alati je veoma širok, kreće se od jednostavnog pretraživanja,


55

preko proračuna do visoko diferenciranih i sofisticiranih analiza kao što su vremenske serije i

kompleksno modeliranje. Time oni obuhvataju kompletan slijed koji počinje podacima, a završava

poslovnom inteligencijom.

Prednost koju pružaju mehaniznmi OLAP alata je i provođenje ad-hoc analiza, pored pored

rutinske i periodične analize i na osnovu njih produkovanih papirnih izvještaja. Ad-hoc analiza

omogućava generisanje odgovora u stvarnom vremenu koje je izraženo veoma malim vremenskim

jedinicama do nekoliko minuta i tekstualnom i grafičkom obliku koji je pogodan za upotrebu.

Na tržištu je danas moguće naći nekoliko varijanti OLAP alata:

· Relacioni OLAP alati, u njihovoj osnovi se nalaze relacione baze podataka i za razliku od

multi dimenzionalnihvjerno odražava stvarni svijet. No, u slućaju promjena koje proizvođač

alata želi uraditi, moguća je otežana primjena standardnih upitnih jezika (SQL) koji je

blizak korisnicima, kao i neke druge interakcije sa bazom podataka.

· MOLAP alati, za razliku od ROLAP-a njihova baza podataka nije izgrađena na standarnom

modelu (relacionom) već je prilagođena u n-dimenzione matrične strukture. To čini ove

alate teško prilagodljivim promjenama u veličini sistema kojeg se želi pomoću njih pratiti i

analizirati.

· Desktop OLAP alati, predstavljaju jednostavne OLAP alate, nižih cijena i prilagođeni su

skromnijim performansama desktop računara. Namjena im je da zadovolje potrebe

pojedinačnih korisnika.

· HOLAP alati, su hibridni proizvod pomoću kojeg je moguće izvoditi multidimenzionalne

analize simultano iz podataka koji se nalaze u multidimenzionalnim skladištima podataka i

relacionih baza, što predstavlja kombinaciju MOLAP i ROLAP alata.

OLAP alati su prisutni na tržištu više od deset godina, a kao najpoznatiji proizvođači

navedenih alata su kompanije: Cognos, Microsoft, Oracle, SAS, IBM, Busines Objects, Aplix,

Hyperion Solution itd.


56

4.7 SQL (Structured Query Language)

Već je ranije rečno da je današnji de facto standard za definisanje i upravljanje podacima - SQL23

koji čini osnovu relacionog modela baze podataka. Bitno je napomenuti da SQL omogućava

interakciju sa bazom putem komandi koje se kreću od reda veličine nekoliko riječi da velikih upita

od nekoliko hiljada znakova. Korisnici aplikativnih sistema obično i ne trebaju poznavati SQL

upite već putem korisničkog sučelja (user interface) zadaju unaprijed napisane i provjerene SQL

upite (ili komande).

Obzirom da se gotovo sva interakcija sa bazom podataka obavlja putem SQL-a ovdje ću opisati

osnovne pojmove kao i historijat nastanka SQL jezka.

Kratki istorijat SQL-a

U ranim vremenima razvoja sistema zasnovanim na bazama podataka, kao problem se postavio

način brzog i efikasnog pristupa podacima. Strukturni jezici 3 generacije (C, Fotran..) jednostavno

nisu najmjeni za pristup i manipulaciju podacima. Kao logičan korak se pojavila potreba za

razvojem potpuno novog „drugačijeg“ jezika za rad sa bazama podaka i podacima koji se nalaze u

njima.

Kao jedno od rješenja ponudio je IBM, razvijeno za potrebe vlastitog DBMS-a DB2. Jezik koji su

razvili su nazvali SQL (Structured Query Language).

Ubrzo su i ostali DBMS proizvođači prepoznali potencijal u SQL i implementirali ga u svojim

rješenjima. Karakteristike koje razlikuju DBMS od RDBMS je da RDBMS obezbjeđuje skupovno

orjentisan jezik baza podataka (SQL). Danas je rijetko naći DBMS sistem, a da isti nije i RDBMS.

Inače, teorija releacionih baza podataka je zasnovana na matematičkoj oblasti teoriji skupova

Sljedeći važan korak jeste bila standardizacija jezika kako bi se izbjegla šarolikost različitih verzija

i implementacija. Tako nam danas ANSI (American National Standard Institute) i ISO

23 SQL (engl. Structured Query Language) - Strukturni jezik za pretraživanje.Standardni SQL je relacioni potpun jer za svih pet osnovnih relacionih operatora (spajanje,razlika, množenje, restrikcija i projekcija) postoje semantički ekvivalentne SQL naredbe. SQLje postavio standarde za upite, ažuriranje i komuniciranje između baza podataka i aplikacija.


57

(International Standard Organization) nude SQL standard za industriju i primjenu istog. ANSI-99

je trenutno aktuelna verzija i predstavlja osnovu. Svaki RDBMS proizvođač koji želi dobiti ANSI-

99 certfikat mora ispoštovati sva pravila standarda. Izmjene su zabranjene, ali dodaci nisu. To

znaći da proizvođač smije dodati neke novine u jezik, ali njegova osnova mora biti po ANSI-92.

Tako danas imamo dvije najpoznatije varijante ovog jezika TSQL (Microsoft) i PL/SQL (Oracle).

Pregled SQL programskog jezika

SQL omogučava da programer i/ili administrator urade neke od sljedećih operacija:

· Promjeni strukturu baze podataka (manipulacija sa definicijama tabela, poljima, tipovima

podataka, referencijalnim integritetom, ograničenjima i sl.);

· Manipulisanje sa sigurnosnim elemtima (korisnici, uloge, prava pristupa pojedinim

objektima ili podacima u tabelama);

· Pregled sadržaja (dohvat željenih podataka iz baze);

· Ažuriranje podataka (dodavanje novih, izmjena postojećeh ili brisanje podataka iz tabela).

SQL nije proceduralni jezik, nego strukturni. To nas dovodi do važnog zaključka koji glasi: SQL je

jezik koji odgovara na pitanje ŠTA, a ne KAKO ! Drugim riječima SQL-om opisujete koje

podatke želite prikazati, modifikovati ili obrisati, a da pri tome nije bitno kako se to radi.

Grupe SQL komandi

Kao što smo do sada napomenuli, SQL nije striktno jezik za pregled podataka, kako bi se to dalo

naslutiti iz njegovog imena. Nego mnogo više od toga. Takođe vrlo bitno je napomenuti da SQL

ima izuzetno jednostavnu sintaksu i mali broj ključnih riječi, ali neka Vas to ne zavara u njegovom

učenju. Efikasno poznavanje i korištenje SQL u svakodnevnim poslovima je direktno

proporcionalno utrošenom vremenu za savladavanje njegove logike i načina rada.

SQL se djeli na tri glavne grupe komandi i to:

· DDL (Data Definition Language);

· DCL (Data Control Language);

· DML (Data Manipulation Language);


58

Data Definition Language (DDL)

SQL::DDL je grupa komandi koja obezbjeđuje manipulisanje se objektima baze podataka kao što

su: (tabele, pogledi, procedure, trigeri, korisnici...). Objekti baze podataka se u praksi obično

kreiraju i ažuriraju korištenjem razvojnih alata I grafičkog korisničkog sučelja koje je vrlo efikasno

često ograničeno na osnovne akcije iz ovog skupa SQL komandi. Zbog toga je potrebno da osoba

koja se bavi bazama i programer koji se bavi razvojem aplikacija za baze, mora detaljnije poznavati

DDL. Kroz DDL imamo puno više kontrole nad procesom kreiranja i manipulacije nad bilo kojim

objektom. Više nego što omogućavaju različiti dizajn alati.

Postoje samo tri komande za definisanje objekata, a to su:

· CREATE (kreiranje bilo kojeg objekta u bazi sa maksimanom kontrolom tog procesa. Npr.

tabela sa svim poljima, tipovima podataka, primarnim ključevima, stranim ključevima,

indeksima i ograničenjima)

· ALTER (promjena osobina bilo kojeg objekta u bazi. Npr. promjena veličine polja u

tabeli);

· DROP (permanetno brisanje bilo kojeg objekta u bazi)

Slijedi primjer jedne CREATE TABLE naredbe:

CREATE TABLE studenti (ID number, Ime varchar2(15), Prezime varchar2

(20), BrojDosijea number) ;

Data Control Language (DCL)

Baza podataka je sistem koji se uveliko oslanja na sigurnosne mehanizme i postavke. Sama priroda

posla, rada sa podacima, postvlja činjenicu da su tajnost i privatnost od esencijalnog značaja za bilo

koji sistem koji radi sa podacima. To nas dovodi do sljedeće grupe komandi za kontrolu prava

pristupa SQL::DCL. Kao u DDL grupi i ovdje imamo samo 3 komande i to:


59

· GRANT (davanje određenih permsija npr.SELECT, UPDATE...nad objektima u bazi

podataka. Najčešće su to tabele, međutim komanda se može koristiti nad bilo kojim drugim

objektom);

· DENY (uskraćivanje određene permsije nad objetom bazi. Npr.zabrana DELETE komande

nad određenom tabelom);

· REVOKE (uklanja prethodno datu-GRANTED ili uskraćenu-DENIED permsiju nad

objektom)

Data Manipulation Language (DML)

Najčešće korištena grupa komandi za rad sa podacima, bez obzira da li se radi o programerima ili

administratorima baza podataka, jesu SQL::DML tj.komande za pregled i modifikovanje podataka

u tabelama i/ili views (pogledima). Možda najbliži poznati pojam za poglede (views), a da ste se

susreli sa njime jeste query iz MS Access-a. Postoje samo 4 DML komande i to:

· SELECT (najpoznatija i najčešće korištena komanda. Njeno ime govori da se radi o

pregledu podataka. Definišemo ŠTA želimo da prikažemo iz tabele-a i/ili pogleda.

SELECT može da bude izuzetno jednostavan, jedna linija koda, do jako kompleksnih upita

od više stotina linija koda);

· INSERT (radi se o komandi pomoću koje dodajemo nove zapise u tabele. Programeri koji

prave aplikacije za baze podataka često koriste ovu komandu prilikom pohranjivanja

podataka iz korisničkog interfejsa);

· UPDATE (kada želimo da promjenimo određeni zapis u tabeli, tada koristimo UPDATE

komandu);

· DELETE (u slučajevima kada je potrebno obrisati određeni zapis ili više njih komanda

DELETE će uraditi taj zadatak.)

Za bilo koju grupu SQL komandi (DDL, DCL i DML) je potrebna odgovarajuća permisja za

korisnika.


60

4.8 Obrada upita u bazi podataka (Oracle 8i)

Kao što je prethodno rečeno SQL komande su predstavljene kratkim tekstom koji se putem

aplikacija ili upućuju prema DBMS-u koji u vrlo (ili relativno) kratkom vremenu izvršava zadatu

komadnu. Međutim, od momenta kada se komanda uputi prema DBMS do trenutka kada server

uzvrati rezultat koji odgovara zahtijevu u pozadini se dešava se čitav niz operacija. Jedan bezazleni

zahtijev tipa « zelim znati imena radnika zaposlenih u toku ove godine » će uzrokovati niz

interakcija razlicitih arhitekturalnih komponenti Oracle baze podataka.

Faze obrade upita u bazi podataka

Kada korisnik postavi jednu SQL instrukciju ili upit (query), korisnički proces proslijeđuje te

instrukcije ili upite server procesu. Server proces prima instrukcije i upite i pristupa njihovoj

obradi. Postoje tri glavne etape u obradi jednog upita :

1. analiziranje (parse),

2. izvršenje (execute) i

3. dobavljanje (fetch).

Analiziranje upita

U ovoj etapi server proces najprije prima upit od korisničkog procesa. Potom, server proces

provjerava sintaksu upita kako bi se uvjerio u njegovu valjanost. Server proces provjerava takođe i

sigurnosne privilegije korisnika u pogledu pristupa objektima na koje se poziva u upitu. Server

proces koristi Shared Pool memorijsku strukturu iz SGA kako bi u njoj kompilirao instrukciju i

izgradio kompiliranu verziju instrukcije (parse tree). Na kraju ove etape server proces uzvraća

korisničkom procesu informaciju o statusu. Ova informacija ukazuje na to da li je analiziranje upita

bilo uspjesno ili ne.

Izvršenje upita

U ovoj fazi server proces priprema dobavljanje zahtjevanih podataka. Ukoliko je obrađivana

instrukcija DELETE ili UPDATE server proces će zabraniti pristup (lock) svim linijama kojih se

tiče ovaj zahtjev, tako da ostali korisnici baze podataka ne mogu da im pristupe.


61

Dobavljanje

U ovoj fazi server povlači linije koji se zahjev tiče i prosliješuje ih korisniku. Zavisno o količini

memorije potrebne za prenos rezultata upita, dobavljanje će se obaviti iz jednog ili vise puta.

Shared Pool

Etapa analiziranja upita služi se Shared Pool-om, memorijskom strukturom koja je dio SGA.

Shared Pool sadrži komponente zajedničke memorije koje server proces koristi za analiziranje SQL

instrukcija. Komponente zajednicke memorije u Shared Pool-u su Library Cache i Data Dictionary

Cache.

Slika 4.8.1 prikaz komponenti Shared Pool memorijske zone

Library Cache sadrži informacije u vezi najskorije koristenim SQL instrukcijama. U njoj su

pohranjeni tekst instrukcije, kompilirana verzija instrukcije (parse tree) te plan izvrčenja instrukcije

(execution plan). Plan izvrsenja komande sadrži korake izvršenja instrukcije koje određuje

optimizator. U slucaju da je SQL instrukcija, za koju postoje informacije (kompilirana verzija i

plan izvršenja) u Library Cache-u, nanovo odaslana od strane ma kojeg korisnickog procesa prije

nego sto njen plan izvršenja zastari, njena kompilirana verzija i plan izvršenja mogu biti ponovo

koristeni.

Library Cache sadrzi i druge kontrolne strukture kao sto su zabrane pristupa (locks)i Library Cache

Handles.

Data Dictionary Cache sadrži informacije rječnika podataka u vezi objekata i struktura baze

podataka te definicija kolona. Data Dictionary Cache sadrži također i vrijedeća imena korisnika,

njihove lozinke i privilegije za bazu podataka. Data Dictionary Cache je poznat i pod imenom Row

Cache zato što su u njemu podaci sadrzani u linijama a ne u međuspremnicima (buffer) koji sadrže

cijele blokove podataka.


62

Database Buffer Cache

Prilikom obrade upita, server proces provjerava prisustvo blokova podataka neophodnih za

obradu upita u Database Buffer Cache-u, koji je memorijska struktura i dio SGA. Database Buffer

Cache sadrćava blokove podataka koji su učitani iz datoteka podataka. Ukoliko server proces ne

uspije pronaći zahtijevani blok podataka u Database Buffer Cache-u, on će taj blok podataka učitati

iz datoteke podataka i njegovu kopiju spremiti u Database Buffer Cache. Sa stanoviša efikasnosti

rada baze podataka, poželjno je da server proces pronalazi potrebne podatke u memoriji (cache hit).

Ukoliko to nije slučaj (cache miss) server proces će pristupati podacima čitajuci ih sa diska što je

znatno sporije u odnosu na pristup podacima u memoriji. Database Buffer Cache nazivamo joč i

Buffer Cache. On je korišten za pohranjivanje najskorije i često korištene blokove podataka.

Database Buffer Cache je skup međuspremnika (buffer-a) baze podataka. Veličina svakog od

međuspremnika u Database Buffer Cache-u je jednaka velicini jednog bloka podataka u bazi

podataka. Velicina memorijske zone Database Buffer Cache jednaka je proizvodu broja

međuspremnika (buffer-a) u Database Buffer Cache-u i veličine bloka podataka u bazi podataka.

Broj međuspremnika (buffer-a) u Database Buffer cache-u odrešen je vrijednošću parametra baze

DB_BLOCK_BUFFERS. S obzirom da je veličina DB_BLOCK_SIZE određena prilikom kreiranja

baze podataka, te da je DB_BLOCK_BUFFERS dinamiči parametar, da bismo izmjenili veličinu

Database Buffer-a neophodno je zaustaviti i nanovo podići instancu baze podata.

Database Buffer Cache sadrži kao izmjenjene tako i neizmjenjene blokove podataka. Da bi

napravio mjesta za nove blokove podataka u database Buffer Cache-u, Oracle koristi algoritam

Last Recently Used (LRU) da bi oslobodio prostor koji zauzimaju međuspremnici sa podacima koji

nisu skoro bili korišteni. Database Buffer je podjeljen u dvije liste: nečistu (dirty) listu i najskorije

korištenu (last recently used) LRU listu. Nečista lista sadrži kopije blokova koji su izmjenjeni u

odnosu na njihov sadrđaj na disku i koji jos uvijek nisu upisani nazad u datoteku podataka. DBWn

proces primjenjuje odgođeno upisivanje,radi efikasnijeg rada baze podataka. LRU lista sadrži

mešuspremnike koji mogu da su ili trenutačno korišteni ili slobodni za upotrebu ali isto tako i

modifikovani mešuspremnici koji jos nisu prebačeni u nečistu listu. Do njihovog premještanja u

nečistu listu će doći kada neki drugi proces bude tražio slobodne mešuspremnike u LRU listi.

Kada jedan proces nastoji da rezerviše mešuspremnike u Database Buffer-u, on će tražiti slobodne

mešuspremnike u LRU listi. Taj proces će skanirati LRU listu dok ne pronaše slobodne


63

mešuspremnike ili dok ne bude dostignut određeni prag. Prilikom ovog skaniranja svi pronađeni

izmjenjeni međuspremnici će biti prebačeni u nećistu listu. Ukoliko slobodni međuspremnici nisu

pronađeni proces će to signalirati DBWn procesu kako bi on reagovao tako što će upisati

izmjenjene međuspremnike na disk i na taj nacin osloboditi prostor u Database Buffer-u.

Database Buffer cache služi za minimiziranje I/O pristupa na disku i poboljšanje efikasnosti rada

baze podataka. U Oracle8i bazi raspolažemo sa više zona u Database Buffer Cache-u. Objekte

možemo učitati u jednu od slijedeće tri zone:

- DEFAULT zona je korištena za objekte koji nisu pridruženi određenoj zoni Database

Buffer-a ili su, što je prilično rijetko, ekplicitno pridruženi DEFAULT zoni. Veličina

ove zone nije eksplicitno određena već je za nju rezervisan prostor koji preostane u

Database Buffer-u nakon rezervisanja prostora za preostale dvije zone: KEEP i

RECYCLE.

- KEEP zona je korištena za objekte koje želimo zadržati u memoriji. Njena veličina je

kontrolisana BUFFER_POOL_KEEP parametrom.

- RECYCLE zona je korištena za objekte koje šelimo zadršati u memoriji tek toliko

koliko je potrebno (dok ih algoritam ne proglasi zastarijelim). Njena veličina je

kontrolisana BUFFER_POOL_RECYCLE parametrom.

Program Global Area (PGA)

Kada je startovan server proces, Oracle rezerviše Program Global Area (PGA). PGA je memorijski

međuspremnik (buffer). On sadrži podatke i kontrolne informacije za server proces ili za

pojedinaćni pozadinski proces. PGA je nazivan i Process Global Area. PGA je rezervisan kada

startuje server proces i oslobođen kada se server proces zavrsi. Jedna od karakteristika PGA jeste

da je to memorijski region u koji je moguće pisati (writeable) i da je nedjeljiv (non-sharable).

Sadrzaj PGA ovisi o konfiguraciji Oracle servera. U konfiguraciji servera posebne namjene

(dedicated server) PGA posjeduje zonu za razvrstavanje (sort area), informacije o sesiji, stanje

kursora i stack prostor. U multithreaded (MTS) konfiguraciji, pojedine informacije PGA su

spremljene u SGA.

Zona za razvrstavanje, kao što joj ime kaže, korištena je za obavljanje operacija


64

razvrstavanje (sort), koje mogu biti neophodne prije obrade linija ili prije nego što su linije

odaslane korisničkom procesu.

Informacije o sesiji preciziraju privilegije korisnika za tekuću sesiju.

Stanje kursora ukazuje na fazu u kojoj se nalazi obrada pojedinih kursora koji su trenutno korišteni

u sesiji. Kursor je pokazivač ka memorijskoj zoni pridruzenoj specificnoj SQL instrukciji. Oracle

koristi radne zone za izvrsavanje SQL instrukcija i spremanje informacija o obradi. Kursori nam

omogućuju da imenujemo ove radne zone i da pristupamo informacijama koje one sadrze.

Stack Space sadrzi varijable i matrice (tablice) sesije.

Obrada DML instrukcija

Pored instrukcije SELECT kojom pribavljamo informacije iz baze podataka na raspolaganju su

nam i instrukcije koje nam omogućuju modifikovanje sadržaja tih informacija. Pod

modifikovanjem podrazumijevamo kako izmjenu sadrzaja informacija (ažurirarnje) tako i

dodavanje novih informacija te brisanje odnosno poništavanje postojećih informacija. Tretman

ovih instrukcija koje jos nazivamo i DML (Data Manipulation Language) instrukcijama razlikuje

se od prethodno prikazanog tretmana instrukcija SELECT i uključuje i potrebu validiranja ili

poništavanja sačinjenih izmjena.

Izvršna faza DML instrukcije

Oracle raspolaže instrukcijama za manipulisanje podataka kao sto su INSERT,UPDATE i

DELETE i koje čine Data Manipulation Language (DML). Obrada DML instrukcija se obavlja u

dvije etape : analiziranje instrukcije (parse) i izvršenje instrukcije (execute). U fazi analiziranja

korisnički proces šalje instrukciju server procesu. Nakon provjere sintakse, analizirana instrukcija

je učitana u zajedičku SQL zonu (shared SQL area). Ako je faza analiziranja uspješno obavljena,

slijedeća faza u obradi instrukcije je izvršna faza. Izvršna faza se sastoji iz više etapa.

Posmatraćemo izvršenje jedne UPDATE instrukcije koje je prikazano na slici.


65

Slika 4.8.2 Šematski prikaz procesa obrade jedne DML instukcije

Najprije, server proces čita blokove podataka iz rollback blokova iz Database Buffer Cache-a.

Ukoliko zahtijevani blokovi podataka nisu pronađeni u Database Buffer Cache-u tada će server

proces povuci te blokove podataka iz datoteka podataka (1) i smjestiti ih u Database Buffer Cache

(2). Nakon što je smjestio zahtjevane blokove podataka u Database Buffer Cache, server proces će

staviti zabrane pristupa na podatke koji trebaju da su izmjenjeni (3). Potome, originalne vrijednosti

(before image) podataka će smjestiti u rollback segment. Ovo uzrokuje izmjene u buffer cache-u.

Server proces biljezi ove izmjene u Redo-Log Buffer-u (4) štiteći tako originalne vrijednosti.

Konačno, server proces bilježi promjene u Database Buffer Cache-u (5). Ove izmjene su takođe

zabilježene i u Redo-Log Buffer-u da bismo zaštitili novu (afterimage) vrijednost. Izmjenjeni

blokovi u database Buffer cache-u su obiljezeni kao “prljavi” međuspremnici (dirty bufferi).

“Prljavi” međuspremnici su oni koji nisu identični odgovarajućim blokovima na disku.


66

Obrada instrukcija DELETE i INSERT sadrži slične korake. Originalna vrijednost (before image)

DELETE instrukcije sadrži vrijednosti kolona poništene linije dok je u slučaju INSERT-a potrebno

spremiti informaciju o lokaciji linije u rollback blok.

Rollback Segmenti

Kada pozovemo neku DML instrukciju kako bismo izmjenili podatke, server proces najprije kopira

originalne, stare, vrijednosti u rollback segment. Rollback segment je korišten za poništavanje

promjena u slučaju anuliranja transakcije (rollback) i da bi se osiguralo da ostale transakcije ne

vide nepotvrđene (uncommited) izmjene. Korisnici Oracle baze ne mogu eksplicitno čitati u

rollback segmentu. Jedino Oracle može pristupati rollback segmentima. Svaka baza podataka

sadrži jedan ili vise rollback segmenata. Oracle automatski pridružuje transakciju slijedećem

raspoloživom rollback segmentu. Do ovog pridruživanja transakcije rollback segmlentu dolazi u

momentu kada pozovete prvu DML instrukciju u vašoj transakciji. Oracle neće nikada pridružiti

transakciju koja samo čita iz baze (read-only) jednom rollback segmentu. Transakcije koje samo

čitaju iz baze ne sadrže samo upite i nijednu DML instrukciju.

Broj transakcija kojima moze raspolagati jedan rollback segment ovisi o operativnom sistemu.

Upotreba rollback segmenata

- Ako je potrebno, rollback segment je korišten prilikom anuliranja transakcije za

poniptavanje izmjena načinjenih nad podacima.

- Informacije spremljene u rollback segmentima su korištene i za osiguranje dosljednosti

čitanja (read consistency). Dosljednost čitanja osigurava da ostale transakcije ne

pristupaju vrijednostima koje su izmjenjene nepotvrđenim (uncommited) DML

instrukcijama.

- Rollback segmenti su takodjer korišteni prilikom oporavka baze nakon kvara u cilju

njenog dovođenja u dosljedno (consistent) stanje.

Rollback segmenti se nalaze u datotekama podataka jednako kao i tabele i indeksi. Dijelovi ovih

segmenata su po potrebi ucitavani u Database Buffer Cache.


67

Redo-Log Buffer

Redo-Log Buffer bilježi sve promjene načinjene nad podacima prilikom obrade DML instrukcije.

Redo-Log Buffer je memorijska struktura koja cini dio SGA. Njegova velicina izražena u bajtima

je odredjena vrijednoscu parametra LOG_BUFFER. U Redo-Log Bufferu su spremljeni redo zapisi

ili ulazi (entries). Redo zapis bilježi izmjenjeni blok, lokaciju izmjene i novu vrijednost. Redo zapis

ne pravi nikakvu razliku u pogledu tipa bloka u kome je izvršena izmjena. Ovo znači da redo zapis

ne pravi razliku između bloka podataka, indeks bloka ili rollback segment bloka. Redo-Log Buffer

je korišten sekvencijalno (u nizu) te se izmjene sačinjene u jednoj transakciji nalaze pomiješane sa

izmjenama drugih transakcija. Redo-Log Buffer je kružni međuspremnik (buffer) čiji prostor je

oslobođen za ponovnu upotrebu nakon što je popunjen. Međutim, do ovoga oslobađanja prostora

dolazi jedino nakon što su svi postojeci redo zapisi upisani u online redolog datoteke. Veličina

Redo-Log Buffera je fiksna i ona je kreirana prilikom podizanja instance.

Database Writer (DBWn)

DBWn pozadinski proces upisuje podatke iz Database Buffer Cache-a u datoteke podataka nadisku. Do ovog upisivanja podataka na disk dolazi jedino kada se dese određeni dogadjaji.

Slike 4.8.3. Šematski prikaz upisivanja podataka u datoteke podataka koje obavlja DBWn proces

Jedan od dogadjaja koji dovode do toga da DBWn proces pocne pisati u datoteke podatake je kada

broj “prljavih” međuspremnika (dirty buffers) dostigne vrijednost praga (treshold). “Prljav”

međuspremnik je izmjenjeni međuspremnik u Database Buffer Cache-u. Kako broj “prljavih”

međuspremnika raste tako i broj slobodnih međuspremnika u Database Buffer Cache-u opada.


68

Jedan od zadataka DBWn procesa je da održava dovoljno slobodnih međuspremnika kako bi

mogao prihvatiti učitane blokove podataka iz datoteka podataka.

DBWn ce poceti pisanje u datoteke podataka i kada server proces ne uspije pronaći slobodne

upotrebljive međuspremnike nakon skaniranja odredjenog broja međuspremnika.

Ako istekne određeno vrijeme timeout-a, DBWn će odpočeti pisanje u datoteke podataka. Timeout

ističe ako je DBWn neaktivan tokom određenog vremenskog perioda, npr. tokom tri sekunde. Kada

timeout istekne DBWn trazi u Last Recently Used (LRU) listi odredjeni broj međuspremnika i

upisuje “prljave” međuspremnike na disk. Ukoliko je baza podataka nezaposlena, DBWn ce

eventualno upisati na disk kompletan sadrzaj Database Buffer Cache-a.

DBWn pise na disk i kada se desi checkpoint. Checkpoint mogu izazvati različiti događaji kao npr.

kada administrator baze podataka zaustavlja bazu podataka. DBWn checkpoint je sredstvo za

sinhroniziranje Database Buffer Cache-a sa datotekama podataka.


69

Log Writer (LGWR)

LGWR pozadinski proces upisuje redo zapise iz Redo-Log Buffera u online redolog datoteke

tekuće redo-log grupe. LGWR proces započinje ovo pisanje kada se desi jedan od navedenih

dogadjaja :

Slika 4.8.4 Šematski prikaz upisivanja podataka u redo-log datoteke koje obavlja LGWR proces

- LGWR počinje pisanje kada je Redo-Log Buffer popunjen do trećine.

- LGWR počinje pisanje i kada istekne timeout. Standardna vrijednost timeout-a je tri sekunde.

- LGWR će upisati redo zapise u online redo-log datoteke prije nego što DBWn upiše bilo koji od

izmjenjenih blokova podataka iz Database Buffer Cache-a u datoteke podataka.

- Kada korisnicki proces potvrdi (commit) transakciju, LGWR upisuje Redo-Log Buffer u online

redo-log datoteke. U pojedinim situacijama kada potrebno više prostora u Redo-Log Bufferu nego

što ga ima raspoloživog, LGWR ce upisati redo zapise prije nego sto je transakcija potvrdjena.

Međutim, ovi zapisi će postati trajni jedino nakon što transakcija bude potvrdjena.

- Kada je više od 1 MB informacija upisano u Redo-Log Buffer.

LGWR proces je znacajan radi toga što potvrda transakcije nije izdana sve dok ona nije upisana u

redo-log datoteku.


70

4.9 Pregled vodećih proizvođača sistema za upraljvanje bazama podataka

Proizvođač2006

Tržišni udio2006 (%)

2005

Tržišni udio2005 (%)

2005-2006Rast

Oracle 7,168.0 47.1 6,238.2 46.8 14.9IBM 3,204.1 21.1 2,945.7 22.1 8.8Microsoft 2,654.4 17.4 2,073.2 15.6 28.0Teradata 494.2 3.2 467.6 3.5 5.7Sybase 486.7 3.2 449.9 3.4 8.2Ostali 1,206.3 7.9 1,149.0 8.6 5.0Ukupno 15,213.7 100.013,323.5 100.0 14.2

Izvor: Gartner Dataquest (Juni 2007)


71

5. Marketing zasnovan na bazi podataka

Marketing baziran na bazi podataka predstavlja tehniku prikupljanja svih dostupnih

informacija o kupcima, događajima i katalozima i spremanju podataka u centralnu bazu podataka

kao i korištenje ovih podataka u marketing akcijama. Informacije su pohranjene u marketing bazu

podataka i mogu biti korištene kako u svrhu donošenja strateškiha tako i taktičkih odluka za pri

marketing aktivnostima.

Kompanije koje koriste marketing bazu podataka konstanto rade na prikupljanju,

prečiščavanju i analizi podataka o vlastitim kupcima. Pri tome se prate historijati kupovina, dostave

kataloga, demografske informacije itd. Analizom podatke pretvaraju infromacije koje podržavanju

vlastite marketing programe. Napredne marketing kompanije prikupljaju informacije na vlastitim

web stranicama kako bi imali i detaljnije informacije o interesovanjima pojedinih kupaca.

Današnje najuspješnij ekompanije su u pravilu i korisnici marketing baza podataka. Ove

kompanije su u stanju da:

- ciljano dostavljaju kataloge bilo kojem segmentu svojih kupaca

- mjere vrijednost vlastitih kupaca

- prate efekte promocije , mjere količinu odgovora na ponude, narudžbe …

Direktni marketing opisuje grupu taktika i komunikacijskih kanala (pošta, email, telefonski

marketing itd) , a svi zajedno dijele osobinu da se rezultati mogu mjeriti (1000 dostavljenih pisama,

10 odgovora od to 2 uspješne prodaje). Uobičajeni naziv za ovu vrstu marketinga je “marketing sa

mjerljivim rezultatima”.

Marketing baziran na bazi podatakauvodi organizaciju kupaca i kataloških podataka tako su

efikasnije iskorišteni u akcijama direktnog marketinga. Na taj način se organizuje kompletan

marketing process. Ovaj pristup omogućava da se bira šta ponuditi pojedinačnom kupcu i u kojem

momentu, a sve na bazi znanja koje je pohranjeno u marketing bazu podataka. Ukupan rezultat

ovakve organizacije marketing aktivnosti je povećanje povrata sredstavainvestiranih u marketing

aktivnosti.


72

Tipičan primjer marketing baze podataka


73

5.1 Makering baza podataka – praktični primjer realizacije

Šema modela podataka (Entity Relation Diagram ERD):


74

Bazu podataka čine sljedeći objekti:

1. Tabele:

a.) šifarnici

- kategorija (šifarnik kategorija kupaca)

- mjesto (šifarnik mjesta – adrese)

- tip_datuma (šifarnik vrsta datuma koji se bilježe)

- tip_dogadjaja (tipovi dogadjaja o kojima se prikupljaju informacije)

b.) ostale

- kupac (matični podaci o kupcu)

- kreditna_kartica (vrste kreditnih kartica)

- kupac_kreditna_kartica (podaci o karticama za određenog kupca)

- kupac_datum (podaci o datumima po tipu, za određenog kupca)

- clan (podaci o clanovima porodice određenog kupca)

- clan_datum (podaci o datumima po tipu za određenog člana porodice)

- proizvod (podaci o proizvodu koji se prodaje)

- racun (podaci o izdatom racunu)

- racun_stavke (stavke racuna)

- aktivnost (podaci o marketing aktivnosima)

- aktivnost_faze (faze izvođenja marketing aktivnosti)

- kandidat (izdvojena skupina kupaca prema kojima se izvodi marketing

aktivnost)

- kupac_dogadjaj (informacija o događajima vezanim za određenog kupca)

2. Objekti referencijalnog integriteta (u modelu su koišteni surogatni ključevi) baze podataka

a.) Primarni ključevi :

- kupac – primarni ključ tabele kupac

- kategorija_pk – primarni ključ tabele kategorija

- kreditna_kartica_pk – primarni ključ tabele kreditna_kartica

- kupac_kreditna_kartica_pk – primarni ključ tabele kupac_kreditna_kartica

- clan_pk – primarni ključ tabele član


75

- kupac_datum_pk – primarni ključ tabele kupac_datum

- clan_datum_pk – primarni ključ table clan_datum

- tip_datuma_pk – primarni ključ tabele tip_datuma

- racun_pk – primarni ključ tabele racun

- proizvod_pk – primarni ključ tabele proizvod

- aktivnost_pk – primarni ključ tabele aktivnost

- tip_dogadjaja_pk – primarni ključ tabele tip_dogadjaja

- aktivnost_faze_pk - primarni ključ tabele aktivnost_faze

- kandidat_pk - primarni ključ tabele kandidat

- mjesto_pk – primarni ključ tabele mjesto

b) Strani ključevi

- KUPAC_KATEGORIJA_FK – relacija 1:M – kategorija : kupac

- KUPAC_MJESTO_FK – relacija 1:M – mjesto :kupac

- KUPAC_KREDITNA_KARTICA_FK – relacija 1:M - kupac

:kupac_kreditna_kartica

- KUPAC_KREDITNA_KARTICA_FK1 – relacija 1:M - kreditna_kartica

:kupac_kreditna_kartica

- CLAN_KUPAC_FK – relacija 1:M – kupac : clan

- KUPAC_DATUM_KUPAC_FK – relacija 1:M – kupac : kupac_datum

- KUPAC_DATUM_TIP_DATUMA_FK – relacija 1:M – tip_datuma :

kupac_datum

- CLAN_DATUM_CLAN_FK – relacija 1:M – clan : clan_datum

- CLAN_DATUM_TIP_DATUMA_FK relacija 1:M – tip_datuma : clan_datum

- RACUN_KUPAC_FK – relacija 1:M – kupac : racun

- RACUN_STAVKE_RACUN_FK – relacije 1:M – racun : racun_stavke

- ACUN_STAVKE_PROIZVOD_FK – relacija 1:M – proizvod : racun_stavke

- AKTIVNOST_FAZE_FK – relacija 1:M – tip_dogadjaja : aktivnosti_faze

- AKTIVNOST_FAZE_AKTIVNOST_FK – relacija 1:M – aktivnost :

aktivnost_faze

- KUPAC_DOGADJAJ_KUPAC_FK – relacija 1:M – kupac : kupac_dogadjaj

- KUPAC_DOGADJAJ_FK - relacija 1:M – tip_dogadjaja : kupac_dogadjaj


76

- KANDIDAT_KUPAC_FK – relacija 1:M – kupac : kandidat

- KANDIDAT_AKTIVNOST_FK – relacija 1:M – aktivnost : kandidat

3 Sekvence (za kreiranje surogatnih ljučeva)

- KUPAC_ID–redni broj kupca (šifra kupca)

- KUPAC_KREDITNA_KARTICA_ID - redni broj kupac_kreditna_kartica zapisa

- CLAN_ID redni broj člana

- KUPAC_DATUM_ID redni broj kupac_datum zapisa

- CLAN_DATUM_ID redni broj clan_datum_zapisa

- RACUN_ID redni broj racuna

- RACUN_STAVKE_ID redni broj racun_stavke zapisa

- PROIZVOD_ID - redni broj proizvoda šifra proizvoda,

- KANDIDAT_ID – redni broj zapisa kandidat

- AKTIVNOSTI_FAZE_ID – redni broj aktivnosti_faze zapisa

- AKTIVNOSTI redni broj zapisa aktivnosti

4 Trigeri – korišteni samo za generisanje surogatnih ključeva

- Kupac_T1

- Kupac_kreditna_kartica_T1

- CLAN_T1

- KUPAC_DATUM_T1

- CLAN_DATUM_T1

- RACUN_T1

- RACUN_STAVKE_T1

- PROIZVOD_T1

- AKTIVNOST_T1

- AKTIVNOST_FAZE_T1

DDL skripta za kreiranja objekata baze :


77

CREATE TABLE KUPAC

(

KUPAC_ID INTEGER NOT NULL,

NAZIV VARCHAR2(50),

ADRESA VARCHAR2(50),

KATEGORIJA_ID INTEGER NOT NULL,

MJESTO_ID INTEGER

)

;

CREATE TABLE KATEGORIJA

(

KATEGORIJA_ID INTEGER NOT NULL,

NAZIV VARCHAR2(50)

)

;

CREATE TABLE KREDITNA_KARTICA

(

KARTICA_ID INTEGER NOT NULL,

NAZIV VARCHAR2(100),

KRATKI_NAZIV VARCHAR2(10),

BANKA VARCHAR2(100),

TRANS_RACUN VARCHAR2(30)

)

;

CREATE TABLE KUPAC_KREDITNA_KARTICA

(

KUPAC_KREDITN_AKARTICA_ID INTEGER NOT NULL,

KUPAC_KUPAC_ID INTEGER NOT NULL,

KREDITNA_KARTICA_KARTICA_ID INTEGER

)

;

CREATE TABLE CLAN

(

CLAN_ID INTEGER NOT NULL,

IME VARCHAR2(40),

RELACIJA VARCHAR2(40),

UPAC_ID INTEGER NOT NULL

)

;

CREATE TABLE KUPAC_DATUM

(

KUPAC_DATUM_ID INTEGER NOT NULL,

KUPAC_ID INTEGER,

TIP_DATUMA_ID INTEGER¸

Datum date

)

;

CREATE TABLE CLAN_DATUM

(

CLAN_DATUM_ID INTEGER NOT NULL,

CLAN_ID INTEGER,

TIP_DATUMA_ID INTEGER,

Datum date

)

;

CREATE TABLE TIP_DATUMA

(

TIP_DATUMA_ID INTEGER NOT NULL,

NAZIV VARCHAR2(4000)

)

;

CREATE TABLE RACUN

(

RACUN_ID INTEGER NOT NULL,

KUPAC_ID INTEGER,

DATUM_RACUNA DATE,

DATUM_PLACANJA DATE,

NACIN_PLACANJA VARCHAR2(20)

)

;

CREATE TABLE RACUN_STAVKE

(

RACUN_STAVKE_ID INTEGER,

RACUN_ID INTEGER,

PROIZVOD_ID INTEGER,

KOLICINA NUMBER(12, 2),

CIJENA NUMBER(12, 2),

IZNOS NUMBER(12, 2)

)

;

CREATE TABLE PROIZVOD

(

PROIZVOD_ID INTEGER NOT NULL,

CIJENA NUMBER(12, 2),

KOLCINA_NA_STANJU NUMBER(12, 2),

NAZIV VARCHAR2(40)

)

;

CREATE TABLE AKTIVNOST

(

AKTIVNOST_ID INTEGER NOT NULL,

NAZIV VARCHAR2(50),

STATUS INTEGER

)

;

CREATE TABLE TIP_DOGADJAJA

(

TIP_DOGADJAJA_ID INTEGER NOT NULL,


78

NAZIV VARCHAR2(40)

)

;

CREATE TABLE AKTIVNOST_FAZE

(

AKTIVNOST_FAZE_ID INTEGER NOT NULL,

DATUM DATE,

TIP_DOGADJAJA_ID INTEGER,

AKTIVNOST_ID INTEGER

)

;

CREATE TABLE KUPAC_DOGADJAJ

(

KUPAC_DOGADJAJ_ID INTEGER,

DATUM DATE,

NAPOMENA VARCHAR2(200),

KUPAC_ID INTEGER,

TIP_DOGADJAJA_ID INTEGER

)

;

CREATE TABLE KANDIDAT

(

KANDIDAT_ID INTEGER NOT NULL,

UPAC_ID INTEGER,

AKTIVNOST_ID INTEGER

)

;

CREATE TABLE MJESTO

(

MJESTO_ID INTEGER NOT NULL,

NAZIV VARCHAR2(40)

)

;

ALTER TABLE KUPAC

ADD CONSTRAINT KUPAC PRIMARY KEY

(

KUPAC_ID

)

ENABLE

;

ALTER TABLE KATEGORIJA

ADD CONSTRAINT KATEGORIJA_PK PRIMARY KEY

(

KATEGORIJA_ID

)

ENABLE

;

ALTER TABLE KREDITNA_KARTICA

ADD CONSTRAINT KREDITNA_KARTICA_PK PRIMARY KEY

(

KARTICA_ID

)

ENABLE

;

ALTER TABLE KUPAC_KREDITNA_KARTICA

ADD CONSTRAINT KUPAC_KREDITNA_KARTICA_PK PRIMARY KEY

(

KUPAC_KREDITN_AKARTICA_ID

)

ENABLE

;

ALTER TABLE CLAN

ADD CONSTRAINT CLAN_PK PRIMARY KEY

(

CLAN_ID

)

ENABLE

;

ALTER TABLE KUPAC_DATUM

ADD CONSTRAINT KUPAC_DATUM_PK PRIMARY KEY

(

KUPAC_DATUM_ID

)

ENABLE

;

ALTER TABLE CLAN_DATUM

ADD CONSTRAINT CLAN_DATUM_PK PRIMARY KEY

(

CLAN_DATUM_ID

)

ENABLE

;

ALTER TABLE TIP_DATUMA

ADD CONSTRAINT TIP_DATUMA_PK PRIMARY KEY

(

TIP_DATUMA_ID

)

ENABLE

;

ALTER TABLE RACUN

ADD CONSTRAINT RACUN_PK PRIMARY KEY

(

RACUN_ID


79

)

ENABLE

;

ALTER TABLE PROIZVOD

ADD CONSTRAINT PROIZVOD_PK PRIMARY KEY

(

PROIZVOD_ID

)

ENABLE

;

ALTER TABLE AKTIVNOST

ADD CONSTRAINT AKTIVNOST_PK PRIMARY KEY

(

AKTIVNOST_ID

)

ENABLE

;

ALTER TABLE TIP_DOGADJAJA

ADD CONSTRAINT TIP_DOGADJAJA_PK PRIMARY KEY

(

TIP_DOGADJAJA_ID

)

ENABLE

;

ALTER TABLE AKTIVNOST_FAZE

ADD CONSTRAINT AKTIVNOST_FAZE_PK PRIMARY KEY

(

AKTIVNOST_FAZE_ID

)

ENABLE

;

ALTER TABLE KANDIDAT

ADD CONSTRAINT KANDIDAT_PK PRIMARY KEY

(

KANDIDAT_ID

)

ENABLE

;

ALTER TABLE MJESTO

ADD CONSTRAINT MJESTO_PK PRIMARY KEY

(

MJESTO_ID

)

ENABLE

;

ALTER TABLE KUPAC

ADD CONSTRAINT KUPAC_KATEGORIJA_FK FOREIGN KEY

(

KATEGORIJA_ID

)

REFERENCES KATEGORIJA

(

KATEGORIJA_ID

) ENABLE

;

ALTER TABLE KUPAC

ADD CONSTRAINT KUPAC_MJESTO_FK FOREIGN KEY

(

MJESTO_ID

)

REFERENCES MJESTO

(

MJESTO_ID

) ENABLE

;


ADD CONSTRAINT KUPAC_KREDITNA_KARTICA_FK FOREIGN KEY

(

KUPAC_KUPAC_ID

)

REFERENCES KUPAC

(

KUPAC_ID

) ENABLE

;


ADD CONSTRAINT KUPAC_KREDITNA_KARTICA_FK1 FOREIGN KEY

(

KREDITNA_KARTICA_KARTICA_ID

)

REFERENCES KREDITNA_KARTICA

(

KARTICA_ID

) ENABLE

;

ALTER TABLE CLAN

ADD CONSTRAINT CLAN_KUPAC_FK FOREIGN KEY

(

UPAC_ID

)

REFERENCES KUPAC

(

KUPAC_ID

) ENABLE

;


ADD CONSTRAINT KUPAC_DATUM_KUPAC_FK FOREIGN KEY

(


80

KUPAC_ID

)

REFERENCES KUPAC

(

KUPAC_ID

) ENABLE

;


ADD CONSTRAINT KUPAC_DATUM_TIP_DATUMA_FK FOREIGN KEY

(

TIP_DATUMA_ID

)

REFERENCES TIP_DATUMA

(

TIP_DATUMA_ID

) ENABLE

;


ADD CONSTRAINT CLAN_DATUM_CLAN_FK FOREIGN KEY

(

CLAN_ID

)

REFERENCES CLAN

(

CLAN_ID

) ENABLE

;


ADD CONSTRAINT CLAN_DATUM_TIP_DATUMA_FK FOREIGN KEY

(

TIP_DATUMA_ID

)

REFERENCES TIP_DATUMA

(

TIP_DATUMA_ID

) ENABLE

;

ALTER TABLE RACUN

ADD CONSTRAINT RACUN_KUPAC_FK FOREIGN KEY

(

KUPAC_ID

)

REFERENCES KUPAC

(

KUPAC_ID

) ENABLE

;

ALTER TABLE RACUN_STAVKE

ADD CONSTRAINT RACUN_STAVKE_RACUN_FK FOREIGN KEY

(

RACUN_ID

)

REFERENCES RACUN

(

RACUN_ID

) ENABLE

;

ALTER TABLE RACUN_STAVKE

ADD CONSTRAINT RACUN_STAVKE_PROIZVOD_FK FOREIGN KEY

(

PROIZVOD_ID

)

REFERENCES PROIZVOD

(

PROIZVOD_ID

) ENABLE

;


ADD CONSTRAINT AKTIVNOST_FAZE_FK FOREIGN KEY

(

TIP_DOGADJAJA_ID

)

REFERENCES TIP_DOGADJAJA

(

TIP_DOGADJAJA_ID

) ENABLE

;


ADD CONSTRAINT AKTIVNOST_FAZE_AKTIVNOST_FK FOREIGN KEY

(

AKTIVNOST_ID

)

REFERENCES AKTIVNOST

(

AKTIVNOST_ID

) ENABLE

;

ALTER TABLE KUPAC_DOGADJAJ

ADD CONSTRAINT KUPAC_DOGADJAJ_KUPAC_FK FOREIGN KEY

(

KUPAC_ID

)

REFERENCES KUPAC

(

KUPAC_ID

) ENABLE

;

ALTER TABLE KUPAC_DOGADJAJ

ADD CONSTRAINT KUPAC_DOGADJAJ_FK FOREIGN KEY

(


81

TIP_DOGADJAJA_ID

)

REFERENCES TIP_DOGADJAJA

(

TIP_DOGADJAJA_ID

) ENABLE

;


ADD CONSTRAINT KANDIDAT_KUPAC_FK FOREIGN KEY

(

UPAC_ID

)

REFERENCES KUPAC

(

KUPAC_ID

) ENABLE

;


ADD CONSTRAINT KANDIDAT_AKTIVNOST_FK FOREIGN KEY

(

AKTIVNOST_ID

)

REFERENCES AKTIVNOST

(

AKTIVNOST_ID

) ENABLE

;

CREATE SEQUENCE KUPAC_ID INCREMENT BY 1 START WITH 1 ;

CREATE SEQUENCE KUPAC_KREDITNA_KARTICA_ID INCREMENT BY 1 START WITH 1 ;

CREATE SEQUENCE CLAN_ID INCREMENT BY 1 START WITH 1 ;

CREATE SEQUENCE KUPAC_DATUM_ID INCREMENT BY 1 START WITH 1 ;

CREATE SEQUENCE CLAN_DATUM_ID INCREMENT BY 1 START WITH 1 ;

CREATE SEQUENCE RACUN_ID INCREMENT BY 1 START WITH 1 ;

CREATE SEQUENCE RACUN_STAVKE_ID INCREMENT BY 1 START WITH 1 ;

CREATE SEQUENCE PROIZVOD_ID INCREMENT BY 1 START WITH 1 ;

CREATE SEQUENCE KANDIDAT_ID INCREMENT BY 1 START WITH 1 ;

CREATE SEQUENCE AKTIVNOSTI_FAZE_ID INCREMENT BY 1 START WITH 1 ;

CREATE SEQUENCE AKTIVNOSTI INCREMENT BY 1 START WITH 1 ;

CREATE OR REPLACE TRIGGER "RACUN_T1"

BEFORE

insert on "RACUN"

for each row

begin

if :new.racun_id is null then

select racun_id.nextval into :new.racun_id from dual;

end if;

end;

/

ALTER TRIGGER "RACUN_T1" ENABLE

/

CREATE OR REPLACE TRIGGER "RACUN_STAVKE_T1"

BEFORE

insert on "RACUN_STAVKE"

for each row

begin

if :new.racun_stavke_id is null then

select racun_stavke_id.nextval into

:new.racun_Stavke_id from dual;

end if;

end;

/

ALTER TRIGGER "RACUN_STAVKE_T1" ENABLE

/

CREATE OR REPLACE TRIGGER "PROIZVOD_T1"

BEFORE

insert on "PROIZVOD"

for each row

begin


82

if :new.proizvod_id is null then

select proizvod_id.nextval into :new.proizvod_id

from dual;

end if;

end;

/

ALTER TRIGGER "PROIZVOD_T1" ENABLE

/

CREATE OR REPLACE TRIGGER "KUPAC_T1"

BEFORE

insert on "KUPAC"

for each row

begin

if :new.kupac_id is null then

select kupac_id.nextval into :new.kupac_id from

dual;

end if;

end;

/

ALTER TRIGGER "KUPAC_T1" ENABLE

/

CREATE OR REPLACE TRIGGER "KUPAC_KREDITNA_KARTICA_T1"

BEFORE

insert on "KUPAC_KREDITNA_KARTICA"

for each row

begin

if :new.kupac_kreditn_akartica_id is null then

select kupac_kreditna_kartica_id.nextval into

:new.kupac_kreditn_akartica_id from dual;

end if;

end;

/

ALTER TRIGGER "KUPAC_KREDITNA_KARTICA_T1" ENABLE

/

CREATE OR REPLACE TRIGGER "KUPAC_DATUM_T1"

BEFORE

insert on "KUPAC_DATUM"

for each row

begin

if :new.kupac_datum_id is null then

select kupac_datum_id.nextval into

:new.kupac_datum_id from dual;

end if;

end;

/

ALTER TRIGGER "KUPAC_DATUM_T1" ENABLE

/

CREATE OR REPLACE TRIGGER "CLAN_T1"

BEFORE

insert or update or delete on "CLAN"

for each row

begin

if :new.clan_id is null then

select clan_id.nextval into :new.clan_id from dual;

end if;

end;

/

ALTER TRIGGER "CLAN_T1" ENABLE

/

CREATE OR REPLACE TRIGGER "CLAN_DATUM_T1"

BEFORE

insert on "CLAN_DATUM"

for each row

begin

if :new.clan_datum_id is null then

select clan_datum_id.nextval into

:new.clan_datum_id from dual;

end if;

end;

/

ALTER TRIGGER "CLAN_DATUM_T1" ENABLE

/

CREATE OR REPLACE TRIGGER "AKTIVNOST_T1"

BEFORE

insert on "AKTIVNOST"

for each row

begin

if :new.aktivnost_id is null then

select aktivnosti.nextval into :new.aktivnost_id

from dual;

end if;

end;

/

ALTER TRIGGER "AKTIVNOST_T1" ENABLE

/

CREATE OR REPLACE TRIGGER "AKTIVNOST_FAZE_T1"

BEFORE

insert on "AKTIVNOST_FAZE"

for each row

begin

if :new.aktivnost_faze_id is null then

select aktivnosti_faze_id.nextval into

:new.aktivnost_faze_id from dual;

end if;

end;

/

ALTER TRIGGER "AKTIVNOST_FAZE_T1" ENABLE

5.2 Unos podataka u bazu

5.2.1 Kreiranje zapisa u tabelama šifarnika

kategorija

-- primjer korištenja insert komande sa navođenjem imena polja u koja se

-- upisuju podaci

insert into kategorija (kategorija_id,naziv) values (1,'Fizička lica');1 row(s) inserted.

-- primjer korištenja insert komande bez navođenjem imena polja u koja se

-- upisuju podaci. Korištenjem ovog naina moraju biti nevedeni podaci za sva

-- polja tabele.

insert into kategorija values (2,'Pravna lica');1 row(s) inserted.

Mjesta

-- primjer unosa podataka korištenjem Oracle 10G (XE edition) korisničkog interfejsa za

administraciju baze podataka


84

Na isti način su kreirani zapisi za ostale šifarnika

Tip datuma

Tip dogadjaja


85

5.2.2 Kreiranje zapisa za ostale table

Kupac

Primjer korištenja «load data» korisničkog interfejsa za administraciji baze podataka

Korak 1.

Korak 2.

Korak 3


86

Korak 4 (Prethodno pripremljeni podaci u MS Excel-u)

Korak 5


87

Korak 6

Provjerom podataka može s uočiti kako je triger KUPAC_T1 obezbjedio popunjavanje polja

KUPAC_ID


88

Na sličan način su u ubazu upisani podazi i za ostale tabele


89

5.3 Primjeri prikupljanja podataka

Lista podataka o kupcima (upit bez restrikcije)

Lista kupaca sortirana po nazivu kupca (upit bez restrikcije)


90

Lista kupaca sa imenom na slovo B (upit sa restrikcijom)

Lista kupaca i datuma za kupca (upit sa relacijom)


91

Lista kupaca i datuma za kupca (upit sa relacijom drugi način povezivanja)

Lista kupaca i datuma za kupca uz opis tipa datuma (upis sa dvije relacije)


92

Lista kupaca i evidentiranih događaja (upit sa dvije relacije i sortiranjem)

Lista kupaca i clanova kojima je datum rodjenja u maju


93

Lista računa korisnika koji su izvršili narudžbu u roku od 7 dana po dostavi kataloga

Lista računa sa ukupnim iznosom sortirano po iznosu računa (primjer korištenja SQL tabele)


94

Analiza ukupne prodaje sortirano grupisano po danima , prkaz samo dana čiji je iznos prodaje preko

1000 (korštenje agregacijskih funkcija)

Analiza ukupne prodaje po proizvodima sortirano po količini prodatih proizvoda (korištenje

agregacijskih funkcija)


95


96

6. Zaključak

Marketing koncepcija je koncepcija upravljanja i rukovođenja, koja poslovne odluke donosi na

bazi prethodno izraženih potreba i želja kupaca/korisnika, mogućnosti tržišta, intenziteta uticaja

okruženja, kao i utvrđenih resursnih mogućnosti za zadovoljavanje zahtjeva tržišta kompletnije od

konkurencije. Savremeni marketing informacioni sistem plod je sistemskog pristupa koncepcije

marketinga u istraživanju budućih kretanja na tržištu, integralne upotrebe instrumenata marketing

miksa, tekuće kontrole i revizije ostvarenih rezultata na tržištu i preduzeću i razvoja informacione

tehnologije

Koncept baze podataka je prvobitno najavljivan kao rješenje svih nagomilanih problema u

sistemu informatičke podrške, kako u transakcijskim sisitemima , tako i u sistemima u okviru podrške

menadžmentu i strateškom upravljanju. Ono što je izdvojilo sisteme baza podataka od ostalih

programa jeste njihova sposobnost upravljanja trajnim podacima, te pristup velikim količinama

podataka na efikasan i siguran način.

Marketing baziran na bazi podataka predstavlja tehniku prikupljanja svih dostupnih

informacija o kupcima, događajima i katalozima i spremanju podataka u centralnu bazu podataka kao i

korištenje ovih podataka u marketing akcijama. Informacije su pohranjene u marketing bazu podataka

i mogu biti korištene kako u svrhu donošenja strateškiha tako i taktičkih odluka pri marketing

aktivnostima.

Kompanije koje koriste marketing bazu podataka konstanto rade na prikupljanju, prečiščavanju

i analizi podataka o vlastitim kupcima. Pri tome se prate historijati kupovina, dostave kataloga,

demografske informacije itd., te analizom podatke pretvaraju infromacije koje podržavanju vlastite

marketing programe. Napredne marketing kompanije prikupljaju informacije i na vlastitim web

stranicama kako bi imali i detaljnije informacije o interesovanjima pojedinih kupaca.

Marketing baza podatka je jako moćno sredstvo koje na vrlo efikasan način obavlja poslove

prikupljanja, sortiranja, analize i distribucije marketing informacija. Ulaganja u marketing bazu

podataka se višestruko isplate ukoliko se baza podataka pravlino dizajnira kao i koristi nakon

uvođenja.


97

Obzirom da na našem tržištu još uvijek preovladava intuitivni način upravljanja marketing

baze podataka nisu našle veliku primjenu. Ukoliko želimo imati pozitivne poslovne rezultate ovo

stanje je potrebno mijenjati, jer konkurentost u poslovnom djelovanju uveliko zavisi od pravovremene

i tačne informacije koja će rezultirati ispravnim menadžerskim odlučivanjem.


98

7. Literatura

[1] Filipović, V., Kostić, M., Marketing menadžment – teorija i praksa, FON, Beograd,2005.

[2] Milenković, I., Pavković, M., Primena OLAP poslovne analize na primeru bazepodataka Megatrend univerziteta, Zbornik radova SYM-OP-IS , Banja Koviljača, 2006.

[3] Deepak Pareek; Business Inteligence for Telecomunications; Auerbach Publications2007.

[4] Panian Ž. , Klepac G.; Poslovna inteligencija; Masmedia, Zagreb 2003.[5] Alempije V. Veljović, Menadžment informacioni sistemi; Kompjuter biblioteka 2002 .[6] Keith Fletcher (Prevod Pusić Milena ...); Upravljanje marketingom i informaciona

tehnologija; Clio 2003.[7] Darko Hrenić; Oracle, principi i praksa programiranja; Znak 1995[8] Oracle8i DBA arhitektura i administriranje – Oracle 1Z0-023[9] Višnja Ljubetić; Upravljanje znanjem primjenom alata poslovne inteligencije;

Magistarski rad.[10] Philip Kotler, Upravljanje marketingom; Northwestern University.[11] http://www.gartner.com/it/page.jsp?id=507466&format=print (10.8.2008)[12] www.ideasoft.co.yu[13] http://www.management-hub.com/database-management-mis.html (29.08.2008)

http://www.gartner.com/it/page.jsp?id=507466&format=print

http://www.ideasoft.co.yu/

http://www.management-hub.com/database-management-mis.html


99

8. Sadržaj

1. Uvod............................................................................................................................................... 22. Marketing informacioni sistem........................................................................................................ 3

MIS kao komparativna prednost...................................................................................................... 93. Upravljanje podacima ................................................................................................................... 114. Baze podataka............................................................................................................................... 13

4.1. Organizacija baza podataka .................................................................................................... 144.1.1. Hijerarhijske baze podataka................................................................................................. 164.1.2. Mrežne baze podataka ......................................................................................................... 184.1.3. Relacione baze podataka...................................................................................................... 204.1.4. Relacione baze s objektno orijentisanim proširenjima .......................................................... 244.1.5. Objektno orijentisane baze podataka.................................................................................... 314.2.Oblici baza podataka ............................................................................................................... 374.3 Distribuirana baza podataka..................................................................................................... 384.4 Data warehousing (Skladištenje podataka)............................................................................... 444.5 Data Mining (rudarenje podataka) ........................................................................................... 494.6 Poslovna inteligencija.............................................................................................................. 534.7 SQL (Structured Query Language) .......................................................................................... 564.8 Obrada upita u bazi podataka (Oracle 8i) ................................................................................. 604.9 Pregled vodećih proizvođača sistema za upraljvanje bazama podataka .................................... 70

5. Marketing zasnovan na bazi podataka ........................................................................................... 715.1 Makering baza podataka – praktični primjer realizacije ........................................................... 735.2 Unos podataka u bazu.............................................................................................................. 835.3 Primjeri prikupljanja podataka................................................................................................. 89

6. Zaključak ...................................................................................................................................... 967. Literatura ...................................................................................................................................... 988. Sadržaj.......................................................................................................................................... 99

Documents

Baza podataka kao podsistem marketing informacionog …apeironsrbija.edu.rs/Centar_za_izdavacku_djelatnost/Radovi/Specij... · Baza podataka kao podsistem marketing informacionog