Upload
truongtram
View
234
Download
2
Embed Size (px)
Citation preview
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.
Baza podataka kao podsistem marketing informacionog sistema
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. ”
Baza podataka kao podsistem marketing informacionog sistema
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
Baza podataka kao podsistem marketing informacionog sistema
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
Baza podataka kao podsistem marketing informacionog sistema
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
Baza podataka kao podsistem marketing informacionog sistema
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
Baza podataka kao podsistem marketing informacionog sistema
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
Baza podataka kao podsistem marketing informacionog sistema
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.
Baza podataka kao podsistem marketing informacionog sistema
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.
Baza podataka kao podsistem marketing informacionog sistema
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.
Baza podataka kao podsistem marketing informacionog sistema
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.
Baza podataka kao podsistem marketing informacionog sistema
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.
Baza podataka kao podsistem marketing informacionog 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 .
Baza podataka kao podsistem marketing informacionog sistema
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
Baza podataka kao podsistem marketing informacionog sistema
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
Baza podataka kao podsistem marketing informacionog sistema
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.
Baza podataka kao podsistem marketing informacionog sistema
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.
Baza podataka kao podsistem marketing informacionog sistema
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.
Baza podataka kao podsistem marketing informacionog sistema
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”.
Baza podataka kao podsistem marketing informacionog sistema
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.
Baza podataka kao podsistem marketing informacionog sistema
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
Baza podataka kao podsistem marketing informacionog sistema
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.
Baza podataka kao podsistem marketing informacionog sistema
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.
Baza podataka kao podsistem marketing informacionog sistema
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
Baza podataka kao podsistem marketing informacionog sistema
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.
Baza podataka kao podsistem marketing informacionog sistema
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.
Baza podataka kao podsistem marketing informacionog sistema
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
Baza podataka kao podsistem marketing informacionog sistema
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...
Baza podataka kao podsistem marketing informacionog sistema
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.
Baza podataka kao podsistem marketing informacionog sistema
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:
Baza podataka kao podsistem marketing informacionog sistema
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.
Baza podataka kao podsistem marketing informacionog sistema
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.
Baza podataka kao podsistem marketing informacionog sistema
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.
Baza podataka kao podsistem marketing informacionog sistema
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
Baza podataka kao podsistem marketing informacionog sistema
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.
Baza podataka kao podsistem marketing informacionog sistema
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.
Baza podataka kao podsistem marketing informacionog sistema
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.
Baza podataka kao podsistem marketing informacionog sistema
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.
Baza podataka kao podsistem marketing informacionog sistema
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
Baza podataka kao podsistem marketing informacionog sistema
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.
Baza podataka kao podsistem marketing informacionog sistema
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
Baza podataka kao podsistem marketing informacionog sistema
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.
Baza podataka kao podsistem marketing informacionog sistema
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.
Baza podataka kao podsistem marketing informacionog sistema
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.
Baza podataka kao podsistem marketing informacionog sistema
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.
Baza podataka kao podsistem marketing informacionog sistema
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
Baza podataka kao podsistem marketing informacionog sistema
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.
Baza podataka kao podsistem marketing informacionog sistema
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:
Baza podataka kao podsistem marketing informacionog sistema
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
Baza podataka kao podsistem marketing informacionog sistema
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.
Baza podataka kao podsistem marketing informacionog sistema
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.
Baza podataka kao podsistem marketing informacionog sistema
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.
Baza podataka kao podsistem marketing informacionog sistema
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,
Baza podataka kao podsistem marketing informacionog sistema
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.
Baza podataka kao podsistem marketing informacionog sistema
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.
Baza podataka kao podsistem marketing informacionog sistema
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);
Baza podataka kao podsistem marketing informacionog sistema
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:
Baza podataka kao podsistem marketing informacionog sistema
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.
Baza podataka kao podsistem marketing informacionog sistema
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.
Baza podataka kao podsistem marketing informacionog sistema
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.
Baza podataka kao podsistem marketing informacionog sistema
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
Baza podataka kao podsistem marketing informacionog sistema
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
Baza podataka kao podsistem marketing informacionog sistema
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.
Baza podataka kao podsistem marketing informacionog sistema
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.
Baza podataka kao podsistem marketing informacionog sistema
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.
Baza podataka kao podsistem marketing informacionog sistema
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.
Baza podataka kao podsistem marketing informacionog sistema
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.
Baza podataka kao podsistem marketing informacionog sistema
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.
Baza podataka kao podsistem marketing informacionog sistema
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)
Baza podataka kao podsistem marketing informacionog sistema
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.
Baza podataka kao podsistem marketing informacionog sistema
72
Tipičan primjer marketing baze podataka
Baza podataka kao podsistem marketing informacionog sistema
73
5.1 Makering baza podataka – praktični primjer realizacije
Šema modela podataka (Entity Relation Diagram ERD):
Baza podataka kao podsistem marketing informacionog sistema
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
Baza podataka kao podsistem marketing informacionog sistema
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
Baza podataka kao podsistem marketing informacionog sistema
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 :
Baza podataka kao podsistem marketing informacionog sistema
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,
Baza podataka kao podsistem marketing informacionog sistema
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
Baza podataka kao podsistem marketing informacionog sistema
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
;
ALTER TABLE KUPAC_KREDITNA_KARTICA
ADD CONSTRAINT KUPAC_KREDITNA_KARTICA_FK FOREIGN KEY
(
KUPAC_KUPAC_ID
)
REFERENCES KUPAC
(
KUPAC_ID
) ENABLE
;
ALTER TABLE KUPAC_KREDITNA_KARTICA
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
;
ALTER TABLE KUPAC_DATUM
ADD CONSTRAINT KUPAC_DATUM_KUPAC_FK FOREIGN KEY
(
Baza podataka kao podsistem marketing informacionog sistema
80
KUPAC_ID
)
REFERENCES KUPAC
(
KUPAC_ID
) ENABLE
;
ALTER TABLE KUPAC_DATUM
ADD CONSTRAINT KUPAC_DATUM_TIP_DATUMA_FK FOREIGN KEY
(
TIP_DATUMA_ID
)
REFERENCES TIP_DATUMA
(
TIP_DATUMA_ID
) ENABLE
;
ALTER TABLE CLAN_DATUM
ADD CONSTRAINT CLAN_DATUM_CLAN_FK FOREIGN KEY
(
CLAN_ID
)
REFERENCES CLAN
(
CLAN_ID
) ENABLE
;
ALTER TABLE CLAN_DATUM
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
;
ALTER TABLE AKTIVNOST_FAZE
ADD CONSTRAINT AKTIVNOST_FAZE_FK FOREIGN KEY
(
TIP_DOGADJAJA_ID
)
REFERENCES TIP_DOGADJAJA
(
TIP_DOGADJAJA_ID
) ENABLE
;
ALTER TABLE AKTIVNOST_FAZE
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
(
Baza podataka kao podsistem marketing informacionog sistema
81
TIP_DOGADJAJA_ID
)
REFERENCES TIP_DOGADJAJA
(
TIP_DOGADJAJA_ID
) ENABLE
;
ALTER TABLE KANDIDAT
ADD CONSTRAINT KANDIDAT_KUPAC_FK FOREIGN KEY
(
UPAC_ID
)
REFERENCES KUPAC
(
KUPAC_ID
) ENABLE
;
ALTER TABLE KANDIDAT
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
Baza podataka kao podsistem marketing informacionog sistema
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
Baza podataka kao podsistem marketing informacionog sistema
84
Na isti način su kreirani zapisi za ostale šifarnika
Tip datuma
Tip dogadjaja
Baza podataka kao podsistem marketing informacionog sistema
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
Baza podataka kao podsistem marketing informacionog sistema
86
Korak 4 (Prethodno pripremljeni podaci u MS Excel-u)
Korak 5
Baza podataka kao podsistem marketing informacionog sistema
87
Korak 6
Provjerom podataka može s uočiti kako je triger KUPAC_T1 obezbjedio popunjavanje polja
KUPAC_ID
Baza podataka kao podsistem marketing informacionog sistema
88
Na sličan način su u ubazu upisani podazi i za ostale tabele
Baza podataka kao podsistem marketing informacionog sistema
89
5.3 Primjeri prikupljanja podataka
Lista podataka o kupcima (upit bez restrikcije)
Lista kupaca sortirana po nazivu kupca (upit bez restrikcije)
Baza podataka kao podsistem marketing informacionog sistema
90
Lista kupaca sa imenom na slovo B (upit sa restrikcijom)
Lista kupaca i datuma za kupca (upit sa relacijom)
Baza podataka kao podsistem marketing informacionog sistema
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)
Baza podataka kao podsistem marketing informacionog sistema
92
Lista kupaca i evidentiranih događaja (upit sa dvije relacije i sortiranjem)
Lista kupaca i clanova kojima je datum rodjenja u maju
Baza podataka kao podsistem marketing informacionog sistema
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)
Baza podataka kao podsistem marketing informacionog sistema
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)
Baza podataka kao podsistem marketing informacionog sistema
95
Baza podataka kao podsistem marketing informacionog sistema
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.
Baza podataka kao podsistem marketing informacionog sistema
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.
Baza podataka kao podsistem marketing informacionog sistema
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)
Baza podataka kao podsistem marketing informacionog sistema
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