MODELIRANJE PODATAKA ZA POTREBE PROJEKTOVANJA

SKLADIŠTA PODATAKA
DATA MODELING FOR DATA WAREHOUSE DESIGN
Dragana Ćamilović
Fakultet za menadžment „Braća Karić“

Sadržaj – Tradicionalni pristupi projektovanju baza

podataka nisu pogodni za skladišta podataka. Ipak,
primena trofaznog pristupa modeliranju podataka, koji se
pokazao kao dobra praksa u ranom dobu projektovanja
relacionih baza podataka, predstavlja mudar izbor. Stoga
izrada konceptualnog, logičkog i fizičkog modela mora
biti neophodan deo dizajna i razvoja skladišta podataka.
Ovaj će se rad detaljno baviti pomenutom temom.

Abstract – Traditional approaches to database design

are not appropriate for data warehousing. Never the less,
it is wise to use a three-stage data modeling process,
which was a good practice in the old days of relational
database design. The conceptual, logical and physical
data models must be introduced as a necessary part of
data warehouse design and development. The paper will
cover this topic in detail.
1. UVOD
Ranije je za projektovanje baza podataka bilo
karakteristično da se modeliranje vršilo u tri faze: kroz
razvoj konceptualnog, logičkog i fizičkog modela [1].
Konceptualni model podataka se, u slučaju relacionih
baza, predstavlja dijagramom odnosa entiteta, odnosno
ER (entity relationship) modelom i jedna od njegovih
bitnih karakteristika je da je nezavisan od tehnologije koja
će se koristiti pri implementaciji, tj. treba da bude
primenljiv u svakom tipu baza podataka [1].
Druga faza jeste izrada logičkog modela. Logički model
se u slučaju relacionih baza podataka svodi na relacionu
šemu, tj. na određenje skupa relacija i domena iz kojih
atributi uzimaju vrednosti.
Treća faza podrazumeva izradu fizičkog modela, koji, u
slučaju relacionih baza, predstavlja niz DLL (data
definition language, jezik za definisanje podataka)
naredbi za generisanje tabela, indeksa i ograničenja. Sva
tri modela su prikazana na Slici 1.
Vremenom se ova tzv. trilogija modela sve manje
primenjivala. Obično se projektovanje baze podataka
svodilo na izradu ER modela, koji se direktno
konvertovao u skup tabela. Međutim, projektovanje
skladišta podataka se mora realizovati u tri faze, pre svega
zbog neophodnosti postojanja nezavisnog konceptualnog
modela [1].
Slika 1. Konceptualno, logičko i fizičko modeliranje
podataka [2]
Treba imati u vidu da se generalno za potrebe dizajniranja
ispostava podataka (data mart) primenjuju koncepti
dimenzionalnog modeliranja, što predstavlja bitnu razliku
u odnosu na klasične transakcione sisteme. Stoga će se
ovom temom baviti naredni odeljak rada.
2. DIMENZIONALNO MODELIRANJE
Za potrebe dimenzionalnog modeliranja se mogu koristiti
dva osnovna modela:
 Zvezdasta šema (star schema), i
 Pahuljičasta šema (snowflake schema).
Model treba da ima u vidu potrebe korisnika i nivo
detaljnosti podataka koji će biti neophodan za vršenje
analiza. Njime se definiše i koje će se činjenice i
dimenzije posmatrati. Mora se voditi računa da odabrano
rešenje podrţava lako odrţavanje i eventualna
unapređenja u budućnosti, shodno novim zahtevima
korisnika.
Svaki model ima u svom središtu tabelu činjenica, u
okviru koje se čuvaju numeričke vrednosti koje se ţele
analizirati tj. činjenice. Kimball u [3] ističe da svaka
činjenica predstavlja određeno merilo poslovanja. Sa
tabelom činjenica su povezane dimenzionalne tabele, a
način na koji je to učinjeno zavisi od odabrane šeme.
Najjednostavniji model povezivanja je u okviru zvezdaste
šeme. Centralno mesto u ovoj šemi ima tabela činjenica
koja poseduje sloţen ključ, koji omogućuje povezivanje
sa dimenzionalnim tabelama, ali poseduje i po jedno
numeričko polje za svaku činjenicu koja će biti uključena
u analizu. Svakoj dimenziji odgovara po jedna
dimenzionalna tabela, koja je direktno povezana sa već
pomenutom tabelom činjenica. Ovo je prikazano na Slici
2.
Slika 2. Zvezdasta šema
Ukoliko postoji dekompozicija jedne ili više dimenzija
onda je reč o pahuljičastoj šemi. Pahuljičasta šema,
zapravo, predstavlja oblik zvezdaste šeme kod koje je
izvršena normalizacija pojedinih dimenzionalnih tabela,
pa su podaci o nekoj dimenziji smešteni unutar većeg
broja tabela. Ovaj je model razumljiv i prihvatljiv
projektantima baza podataka, ali je zato poslovnim
korisnicima teţe da rade sa pahuljičastom, nego sa
zvezdastom šemom (zbog njene sloţenije strukture).
Zvezdasta šema moţe obezbediti uštedu memorijskog
prostora [4], a zbog smanjenja redudanse podataka postiţe
se i lakše odrţavanje. Ipak, treba imati u vidu da tabela
činjenica po pravilu zauzima mnogo više memorije od
dimenzionalnih tabela, pa ove uštede često nisu značajne.
Još jedan razlog zašto je pahuljičasta šema manje
“popularna” je taj što izvršavanje upita zahteva veći broj
spajanja tabela, čime se postiţu lošije performanse u
odnosu na zvezdastu šemu [5]. Primer pahuljičaste šeme
je prikazan na Slici 3.
Slika 3. Pahuljičasta šema
Kimball je veliki protivnik upotrebe pahuljičaste šeme i
smatra da dizajn ispostava podataka treba da se striktno
zasniva na zvezdastoj šemi. Pahuljičasta šema, po njemu,
bespotrebno dovodi do usloţnjavanja modela podataka, a
narušava performanse pretraţivanja tj. listanja podataka
[6].
Kimball takođe navodi da je nuţno da se unutar
dimenzionalnih tabela uvode potpuno novi ključevi, koji
će se razlikovati od prirodnih ključeva iz izvornih
sistema, a koje naziva ključevima surogatima. Ovo treba
da budu integer vrednosti, koje počinju od jedinice, a za
svaki sledeći slog se uvećavaju za jedan [7]. Svaka
dimenzionalna tabela će tako imati prost ključ. Na ovaj
način se obezbeđuje jednostavno spajanje dimenzionalnih
tabela sa tabelom činjenica.
Generalno govoreći, dimenzionalno modeliranje treba da
obezbedi uspešan pristup podacima [8]. Osnovna razlika u
odnosu na ER modele i jeste u dozvoljavanju izvesnog
stepena denormalizacije, kako bi se uvećale performanse
pristupa velikim količinama podataka. S tim u vezi
Kimball-ovo stanovište je opravdano: zvezdasta šema
sigurno obezbeđuje brţe odgovore na upite od
pahuljičaste šeme. Neke konkretne prednosti upotrebe
zvezdaste šeme su sledeće [8, 9]:
 Obezbeđuje kratko vreme odgovora na upite.
 Omogućuje optimizaciju baze podataka, jer se radi sa
mnogo jednostavnijim dizajnom.
 Omogućuje dizajniranje podataka koje je u skladu sa
viđenjem krajnjih korisnika.
 Pojednostavljuje razumevanje i korišćenje
metapodataka.
 Povećava mogućnost izbora front-end alata za pristup
(jer neki zahtevaju strogo korišćenje zvezdaste šeme).
Konceptualni model skladišta podataka mora podrţavati
ovde iznete koncepte dimenzionalnog modeliranja. O
konceptualnom modeliranju će više biti reči u odeljku koji
sledi.
3. KONCEPTUALNI MODEL
Konceptualno modeliranje treba da kombinuje dve
najznačajnije komponente razvoja skladišta podataka, a to
su poslovni zahtevi korisnika (u ovom slučaju donosioca
odluka) i struktura podataka. Sam model mora biti
nezavisan od logičkog modela i fizičke implementacije,
što pre svega znači da on ne treba da zavisi od tehnologije
i njenih čestih promena. Konceptualni model je stabilan i
nepromenljiv sve dok ne dođe do značajnih promena u
poslovnom procesu.
Pri projektovanju relacionih baza podataka, kao što je već
ranije pomenuto, konceptualni model se prikazivao ER
modelom tj. ER dijagramom. Kimball, međutim, smatra
da je pri projektovanju skladišta podataka nepodesno
koristiti ER dijagrame, jer oni ne podrţavaju
dimenzionalno modeliranje. ER modele je u slučaju
transakcionih sistema pogodno koristiti jer omogućuju
smanjenje redudanse podataka, što je jako bitno za
relacione baze. U slučaju projektovanja skladišta
podataka ovi modeli su nepodesni iz više razloga [10]:
 Krajnji korisnici obično ne razumeju ER modele.
Treba imati u vidu da se radi o donosiocima odluka
koji ne moraju imati značajno informatičko
obrazovanje.
 Softveri sa teškoćom izvršavaju upite nad ER
modelima.
 ER modeli onemogućuju osnovnu pretpostavku
skladišta podataka za visokim performansama
pretraţivanja podataka.
Od svih prethodno opisanih razloga moţda je
najznačajniji prvonavedeni. Treba imati u vidu da
korisnici igraju značajnu ulogu pri određenju zahteva koje
skladište podataka treba da ispuni, te im model mora biti
razumljiv. Zato se za izradu konceptualnog modela ovde
predlaţe tačkasto modeliranje. Tačkasti model je dovoljno
jednostavan da omogući poslovnim ljudima da se uključe
u njegovu izgradnju i eventualno ga menjaju. Sa druge
strane, dovoljno je snaţan da omogućuje projektantima
skladišta da pređu na narednu fazu tj. izradu logičkog
modela [1]. Konceptualni model je po pravilu rezultat
zajedničkog napora projektanata skladišta podataka i
poslovnih ljudi tj. donosilaca odluka koji će ga koristiti.
Na ovaj način se omogućuje dobro razumevanje
poslovnih zahteva, jer je to uslov da projektovanje i
implementacija skladišta budu uspešno realizovani.
Metod tačkastog modeliranja u potpunosti podrţava
osnove koncepte dimenzionalnog modeliranja. Ponašanje
se ovde predstavlja tačkama, što znači da je informacija
koju predstavlja tačka obično numerička. To moţe biti
pojedinačna, ali i sloţena vrednost (npr. količina i
novčana vrednost prodaje). Ove se informacije mogu
posmatrati po više dimenzija. Stoga se tačka crta u sredini
dijagrama, a dimenzije oko nje, kao što se moţe videti na
primeru sa Slike 4, na kojoj je prikazan tačkasti dijagram
ispostave podataka za praćenje prodaje. Ukoliko
dimenzija poseduje hijerarhijsku strukturu to je prikazano
odgovarajućim strelicama, što se takođe moţe videti na
primeru sa slike.
Slika 4. Tačkasti model
Kao što je na Slici 4 prikazano, tačkasti model ima tri
osnovne komponente, a to su:
 Tačka, kojom se predstavljaju činjenice.
 Imena dimenzija. Potrebno je imenovati sve
dimenzije u modelu.
 Usmerene spojnice, koje se postavljaju između
činjenica i dimenzija.
Model sa Slike 4 se oslanja na tačkasto modeliranje koje
je Todman opisao u [1], s tim što je dopunjen
predstavljanjem hijerarhija, na sličan način kao što je to
učinjeno u [4].
Atributi činjenica i dimenzija se ne prikazuju u dijagramu,
kako bi on ostao pregledan. Stoga posebno treba navesti
spisak atributa svake pojedinačne dimenzije, i utvrditi da
li je potrebno pratiti njihovu promenu u vremenu. Ovaj
spisak atributa moţe sadrţati još neke dodatne elemente,
kao što je njihov opis (metapodaci su od velikog značaja
za skladište podataka), izvor (odakle se iz izvornog
sistema ovaj atribut dobija), način transformacije
podataka (kakva se obrada vrši nad atributom da bi on
mogao da uđe u skladište), frekvencija njegovog
upisivanja u skladište, tip podatka (određuje tip i
preciznost atributa) [1]. I za tabelu činjenica je potrebno
navesti spisak atributa, tj. dati određenje činjenica koje će
se korisiti u modelu.
Nakon izrade konceptualnog modela moţe se preći na
narednu fazu, tj. na izradu logičkog modela.
4. LOGIČKI MODEL
Logičko modeliranje se svodi na transformaciju već
definisanog konceptualnog modela u logičku šemu
podataka. Logički model bi prema [11] trebalo da uključi:
 Sve entitete i relacije među njima.
 Specifikaciju atributa entiteta.
 Specifikaciju primarnih ključeva entiteta.
 Specifikaciju spoljnih ključeva (koji određuju veze
među entitetima).
Konceptualni model se u logički transformiše tako što
svaka dimenzija postaje posebna tabela. Ona će imati
prost ključ, i to će biti integer vrednost kojoj će se redom
dodeljivati vrednosti 1, 2 itd. O ključevima surogatima je
već bilo reči u ovom radu. Ostali atrubuti postaju polja
odgovarajuće tabele, pri čemu se za svaki mora definisati
tip podatka (najčešće tekstualni). Takođe treba razmotriti
način praćenja promene vrednosti atributa u vremenu: da
li se radi o nepromenljivim atributima, onima kod kojih će
se primenjivati strategija upisivanja nove vrednosti
umesto stare, unositi nov slog u okviru dimenzionalne
tabele sa tom novom vrednošću atributa, dok će vrednosti
ostalih atributa ostati nepromenjene, ili primeniti treća
Kimball-ova strategija za dimenzije koje se sporo
menjaju, koja podrazumeva kreiranje polja koje će
sadrţati novu vrednost atributa. Nekad je neophodno
generisati i posebnu tabelu koja će predstavljati tzv.
minidimenziju. Kimball u [3] koristi minidimenzije kao
način praćenja promene vrednosti atributa dimenzija koje
se brzo menjaju. Koncept je primenjiv na dimenziju
Kupac sa Slike 4. Kimball tako predlaţe da se
demografski atributi, kao što su starost, pol, broj dece (ili
članova porodice), kategorija u zavisnosti od godišnjeg
prihoda i slično čuvaju u posebnoj tabeli. U minidimenziji
će se za svaku kombinaciju vrednosti ovih atributa uneti
po jedan slog, što znači da se ne unosi slog za svakog
kupca [3]. Kompromis koji je pri ovom pristupu nuţno
napraviti je sledeći: umesto posmatranja svih mogućih
vrednosti pojedinih atributa treba formirati određene
kategorije u zavisnosti od opsega vrednosti atributa. Npr.
neće biti posmatrane sve moguće vrednosti atributa
(polja) starost, već će se posmatrati starosne kategorije.
Sličan princip se moţe primeniti i na posmatranje
kategorija na osnovu godišnjeg prihoda kupaca. Uvođenje
kategorija znatno smanjuje broj kombinacija koje se
Slika 5. Uvođenje minidimenzije [3]
Dimenzionalne tabele se sa tabelom činjenica povezuju
isključivo preko ključeva surogata. To znači da tabela
činjenica sadrţi kao spoljašnje ključeve surogate svih
dimenzija koji se javljaju u okviru zvezdaste šeme.
Primarni ključ tabele činjenica je sloţen i moţe biti
sačinjen od svih ključeva surogata, ili moţe biti njihov
podskup. Pored ključeva surogata tabela činjenica sadrţi
činjenice, koje su brojčanog tipa podataka (treba odrediti
tip i tačnost broja). Eventualno mogu sadrţati i polje tipa
datum-vreme, kao i tzv. degenerativne dimenzije (to su
npr. redni brojevi transakcija, brojevi narudţbenica,
faktura i slično). Degenerativne dimenzije su gotovo uvek
u vezi jedan-prema-jedan sa tabelom činjenica, pa je bolje
ostaviti ovu informaciju u okviru tabele činjenica, nego
kreirati ogromnu dimenzionalnu tabelu. One mogu biti i
deo ključa tabele činjenica [3].
Logički model po pravilu grade projektant skladišta
podataka i administrator baze. Pored specifikacija tabela,
njihovih ključeva i atributa potrebno je povezati tabele i
izgraditi pravila referencijalnog integriteta. Ovo je obično
zadatak administratora baze podataka.
Za razliku od relacionih baza podataka, gde se insistira na
normalizaciji podataka, ovde su podaci denormalizovani
(zvezdasta šema po pravilu podrazumeva izvesan stepen
denormalizacije). U relacionim bazama normalizacija
treba da obezbedi smanjenje redudanse i omogući veću
fleksibilnost, ali ona svakako utiče na povećanje troškova
izvođenja. Troškovi izvođenja naglo rastu kod skladišta
podataka, jer ona sadrţe znatno veće količine podataka.
Stoga bi spajanje većeg broja manjih tabela, pogotovo ako
se ima u vidu da dimenzionalne tabele mogu sadrţati jako
veliki broj slogova, narušilo performanse skladišta
podataka i zahtevalo neprihvatljivo dugo vreme
izvršavanja.
Posle izrađenog logičkog modela prelazi se na fizičko
modeliranje.
čuvaju u okviru minidimenzije. Međutim, vrlo je vaţno
dobro razmisliti na koji način će se one formirati, jer se
kasnije ne praktikuje njihova izmena. Tako se, dakle,
originalna dimenzionalna tabela sa podacima o kupcima
transformiše u dve tabele na način prikazan na Slici 5.
5. FIZIČKI MODEL
Fizički model treba da definiše fizičku realizaciju
skladišta podataka. Fizičko projektovanje zavisi od
konkretnog sistema za upravljanje bazama podataka, a
realizuje se u nekoliko koraka [12]:
 Razvoj standarda. Standardi se mogu npr. odnositi na
imenovanje objekata, što je vaţno sa stanovišta
skladišta podataka, jer se imena objekata pojavljuju u
upitima korisnika.
 Definisanje plana agregiranja podataka. Većina upita
nad podacima iz skladišta zahteva sumarne podatke,
pa treba razmotriti mogućnost kreiranja sumarnih
tabela. U većini slučajeva agregacije će postojati u
okviru OLAP sistema, ali ako svi korisnici ne koriste
iste kocke podataka za vršenje analiza, neki
agregirani podaci mogu postojati i u okviru skladišta.
 Definisanje šeme podele tabela. Podela tabela
podrazumeva njihovo raščlanjivanje na particije. S
obzirom da su tabele činjenica jako velike (tj. sadrţe
veliki broj slogova) treba razmotriti način njihovog
raščlanjivanja, a nekada će postojati potreba i za
podelom velikih dimenzionalnih tabela (npr. tabele
koja sadrţi podatke o kupcima). Ukoliko tabele
sadrţe izrazito veliki broj slogova to dovodi do
brojnih problema: njihovo učitavanje prilično dugo
traje, kreiranje indeksa takođe, a loše su i
performanse izvršavanja upita. Pravljenje rezervnih
kopija i oporavak ovakvih tabela takođe zahteva
dosta vremena. Zbog toga se moraju razmotriti načini
njihove podele i to se mora uraditi unapred, a ne kad
skladište podataka krene da se upotrebljava. Šema
podele tabela treba da definiše koje će tabele
činjenica i dimenzionalne tabele biti podeljene na
particije, na koji način će svaka od njih biti
raščlanjena (da li će se primeniti horizontalna ili
vertikalna podela), na koliko će particija svaka tabela
biti podeljena, koji će biti kriterijum podele tabela
(npr. po godinama), kao i na koji način će se ovo
raščlanjivanje odraziti na izvršavanje upita. Tabele se
 mogu deliti tako što se određene kolone stavljaju u
okviru iste particije (verikalna podela), što se moţe
npr. primeniti na pojedine dimenzionalne tabele. Ili
se podela moţe vršiti tako što se redovi iz tabele
grupišu u okviru particija, i ova se horizontalna
podela najčešće koristi kod tabela činjenica.
 Određivanje opcija klasterovanja. Klasterovanje
podrazumeva da se srodni podaci smeštaju tako da
budu “fizički bliski” [13]. Ovo zahteva detaljnu
analizu tabela, kako bi se pronašli podaci koji su
srodni tj. oni koji se zajedno koriste u aplikacijama.
Takvi se podaci učitavaju u jednom fizičkom bloku.
 Priprema strategije indeksiranja. Indeksiranje u
velikoj meri utiče na performanse skladišta podataka.
Stoga za svaku tabelu treba utvrditi za koje kolone će Slika 6. Transformacija logičkog u fizički
se kreirati indeksi, s obzirom da moţe postojati više model [12]
indeksa na nivou jedne tabele. Ako ih ima više, treba
definisati redosled njihovog kreiranja. Da bi se 6. ZAKLJUČAK
odredio optimalan broj indeksa mora se razmotriti
nekoliko problema. Prvi je usporavanje učitavanja Za razliku od relacionih baza podataka za čiji su dizajn
podataka u skladište usled postojanja većeg broja odgovorni zaposleni u IT-ju, u dizajnu skladišta podataka
indeksa. Ovo se moţe izbeći tako što se kreiranje učestvuju i krajnji korisnici. Samo oni mogu definisati
indeksa odloţi za kasnije, posle učitavanja. Treba koje su im informacije potrebne za vršenje analiza, i kako
takođe imati na umu da velike tabele, sa nekoliko će se analiza podataka iz skladišta vršiti. Stoga oni treba
miliona slogova, ne mogu podrţati kreiranje većeg da imaju aktivnu ulogu u kreiranju konceptualnog
broja indeksa. Ukoliko postoji nuţnost za njihovim modela, što je moguće u slučaju prihvatanja koncepata
kreiranjem, treba razmisliti o podeli tabele. Najbolji ovde prikazanog tačkastog modeliranja. Tačkasti model je
kandidati za indeksiranje su one kolone koje se često jednostavan i razumljiv i onima koji nisu stručnjaci iz
javljaju kao ograničenja u upitima. Kao najbolja oblasti poslovne inteligencije. Izrada logičkog i fizičkog
praksa se pokazalo da je za početak najpreporučljivije modela je već odgovornost IT-ja.
uvesti indekse za primarne i spoljnje ključeve, a
zatim pratiti performanse skladišta, te kasnije po Ovde prikazan pristup modeliranju podataka omogućuje
potrebi kreirati nove indekse. lako prevođenje iz konceptualnog u logički, a iz njega u
 Odabir memorijskih struktura. Potrebno je utvrditi fizički model podataka. Ovakva trilogija modela
gde će se tačno smeštati podaci na fizičkom predstavlja idealno rešenje pri projektovanju skladišta
memorijskom medijumu, kako će izgledati fizičke podataka.
datoteke, da li će se one deliti na blokove podataka.
Potrebno je razmotriti sve opcije memorisanja LITERATURA
podataka.
 Upotpunjavanje fizičkog modela. Ovaj korak [1] Todman C., Designing a Data Warehouse: Supporting
podrazumeva vršenje provere uspešnog završetka Customer Relationship Management, Prentice Hall, USA,
svih prethodnih koraka. Podaci sakupljeni u 2000.
prethodnim fazama se koriste za potrebe izrade
fizičke šeme na osnovu koje se generišu iskazi u [2] Varga M., Baze podataka, DRIP, Zagreb, 1994.
jeziku za definisanje podataka i kreira fizička
struktura u okviru rečnika podataka. [3] Kimball R., Ross M., The Data Warehouse Toolkit
(Second Edition)- the Complete Guide to Dimensional
Za razliku od logičkog modela koji opisuje objekte i Modeling, John Wiley & Sons, USA, 2002.
relacije među njima (tačnije tabele, atribute, primarne
ključeve i relacije), fizički model se manje bavi [4] Ballard C., Herreman D., Schau D., Bell R., Kim E.,
strukturom, a više performansama. To znači da je sa Valenic A., Data Modeling Techniques for Data
aspekta fizičkog modeliranja značajnije kako će model da Warehousing, IBM Corp., http://www.redbooks.
funkcioniše, nego kako će da izgleda [12]. Fizički model ibm.com , 1998.
treba da teţi poboljšanju performansi, ali i da omogući što
lakše odrţavanje memorisanih podataka. Logički se u [5] Han J., Kamber M., Data Mining: Concepts and
fizički model transformiše nizom aktivnosti, što je i Techniques, Morgan Kaufmann Publishers, San
prikazano na Slici 6. Francisco, 2001.

[6] Kimball R., Is ER Modeling Hazardous to DSS?,

1995, http://www.dbmsmag.com/9510d05.html
[7] Kimball R., Surrogate Keys - Data Warehouse
Architect (DBMS online), Miller Freeman, USA, 1998.
[8] Balaban N., Ristić Ţ., Poslovna inteligencija,
Ekonomski fakultet Subotica, Subotica, 2006.
[9] Poe V, Klaufer P., Brobst S., Building a Data
Warehouse for Decision Support, Prentice Hall, London,
1998.
[10] Kimball R, A Dimensional Modeling Manifesto,
Miller Freeman Inc, 1997, http://www.dbmsmag.com/
9708d15.html
[11] Conceptual, Logical, And Physical Data Models,
http://www.1keydata.com/datawarehousing/data-
modeling-levels.html
[12] Ponniah P., Data Warehousing Fundamentals: A
Comprehensive Guide for IT Professionals, John Wiley &
Sons, New York, 2001.
[13] Lazarević B., Marjanović Z., Aničić N., Babarogić
S., Baze podataka, Fakultet organizacionih nauka,
Beograd, 2003.