OSP

Oblikovanje skladišta podataka (Data Warehouse Design)

1

ZTE22D1

OBLIKOVANJE SKLADIŠTA PODATAKA

Nositelji: Prof.dr.sc. Zoran Skočir, dr.sc. Boris Vrdoljak SADRŽAJ

Skladište podataka: definicija i osnovni pojmovi. Značajke skladišta podataka. Proces izgradnje skladišta podataka. Konceptualni višedimenzionalni model podataka. Konceptualno oblikovanje skladišta podataka. Logički višedimenzionalni model podataka. Logičko oblikovanje skladišta podataka. Proces izvlačenja podataka iz izvora, transformacije podataka i njihovog učitavanja u skladište. Oblikovanje skladišta podataka iz XML izvora. Oblikovanje skladišta podataka

2

ZTE22D1

OBLIKOVANJE SKLADIŠTA PODATAKA

LITERATURA ♦ ♦

♦

W.H. Inmon. Building the Data Warehouse (Second Edition). John Wiley & Sons, 1996. R. Kimball, Margy Ross. The Data Warehouse Toolkit: The Complete Guide to Dimensional Modeling (Second Edition). John Wiley & Sons, 2002. S. Abiteboul, P. Buneman, and D. Suciu. Data on the Web: From Relations to Semistructured Data and XML. Morgan Kaufman Publishers, 1999.

Oblikovanje skladišta podataka

3

Teme

♦ ♦ ♦ ♦

Baze podataka - pregled Osnovni pojmovi skladišta podataka i skladištenja Značajke skladišta podataka Skladištenje podataka Procesi

skladištenja podataka Izvedba sustava skladištenja podataka


4

Teme

♦

Modeli podataka za skladište podataka Model entiteti – veze Relacijski model Dimenzionalni model činjenica (Dimensional Fact Model) Višedimenzionalni model podataka Strukturirani i polustrukturirani podaci XML – značaj i pohrana

♦

Oblikovanje skladišta podataka iz XML izvora

♦

♦


5

Baze podataka - pregled


6

Baze podataka - pregled INFORMACIJSKI SUSTAV je sustav koji prikuplja, pohranjuje, čuva, obrađuje i isporučuje informacije važne za organizaciju i društvo, tako da budu dostupne i upotrebljive za svakog tko ih želi koristiti, uključujući poslovodstvo, klijente, osoblje i ostale. Informacijski sustav aktivni je društveni sustav koji može, ali ne mora, koristiti suvremenu informacijsku tehnologiju. Baza podataka je centralno mjesto informacijskog sustava. Pohranjeni podaci u bazi podataka opisuju trenutno stanje dijela realnog svijeta za koji je i razvijen informacijski sustav, naravno na način pogodan za računalnu obradu.


7

Baze podataka - pregled

BAZA PODATAKA je skup međusobno povezanih podataka pohranjenih bez nepotrebne zalihosti s ciljem da na optimalni način posluže u raznim primjenama. Podaci se spremaju neovisno o programima koji ih koriste, zajedničkim pristupom dodaju se novi podaci te mijenjaju i premještaju postojeći.


8

Baze podataka - pregled MODEL PODATAKA je formalni sustav koji mora imati barem sljedeće tri komponente: a) Skup objekata koji su osnovni elementi baze podataka; b) Skup operacija koje možemo izvoditi nad objektima definiranim pod a) i kojima se mogu pretraživati, dobivati i modificirati podaci o tim objektima; c) Skup općih pravila integriteta podataka koja implicitno ili eksplicitno definiraju skup konzistentnih stanja podataka ili promjena stanja, ili oboje i koja su općenita u smislu da su primjenjiva na bilo koju bazu podataka koja koristi taj model. Oblikovanje skladišta podataka

9

Baze podataka - pregled SUSTAV ZA UPRAVLJANJE BAZOM PODATAKA (DBMS - Database Management System) je programski sustav koji osigurava osnovne funkcije odabranog modela podataka u postupku kreiranja i korištenja baze podataka. Sastoji se od integrirane kolekcije programske podrške koja omogućava: • • •

opis i manipulaciju podacima pomoću posebnog jezika (posebnih jezika), visoki nivo sučelja prema podacima nezavisan od strukture podataka u računalu, efikasno korištenje i razumijevanje informacija pohranjenih u bazi podataka, zahvaljujući skupu programskih alata.


10

Baze podataka - pregled U suvremenom informacijskom sustavu - dvije komponente: Transakcijski sustav - još se koriste i nazivi: operacijski sustav, operacijska baza podataka, OLTP sustav (OLTP - On-Line Transaction Processing), • velik broj transakcija od kojih svaka sadržava malu količinu podataka Sustav skladištenja podataka analiza podataka, izvješća, obrada velike količine podataka, OLAP sustav (On-Line Analytical Processing)


11

Baze podataka - pregled promjena

brisanje

brisanje

upit

unošenje

promjena

upit

periodičko učitavanje upiti

unošenje

operacijska baza podataka

skladište podataka

Da bi se što više smanjio negativan utjecaj analitičke obrade na rad transakcijskih sustava, a i zbog brojnih razlika tih dvaju sustava, nužno ih je logički i fizički odvojiti. Oblikovanje skladišta podataka

12

Osnovni pojmovi skladišta podataka i skladištenja


13


SKLADIŠTE PODATAKA je baza podataka koja sadrži povijesne nepromjenjive podatke koji se prikupljaju i obrađuju radi potpore poslovnom odlučivanju. Podaci se izvlače iz raznovrsnih izvora te se u skladu s definiranim modelom podataka učitavaju u skladište podataka i integriraju s postojećim podacima.


14

Osnovni pojmovi skladišta podataka i skladištenja Skladište podataka u logičkom smislu centralizirana baza podataka sadržaj: povijesni nepromjenjivi podaci koji se prikupljaju i obrađuju radi potpore poslovnom odlučivanju podaci se izvlače iz raznovrsnih izvora te se u skladu s definiranim modelom podataka učitavaju u skladište podataka i integriraju s postojećim podacima (podaci učitani iz različitih izvora trebaju biti konzistentni) izvor

podataka: operacijske baze podataka i datoteke te vanjski izvori periodički se osvježava Oblikovanje skladišta podataka

15


Skladištenje podataka je proces integracije podataka o poslovanju neke organizacije u jednu bazu podataka (u logičkom smislu), iz koje krajnji korisnici - analitičari, menadžeri, donositelji poslovnih odluka - mogu raditi izvješća, postavljati upite i analizirati podatke


16


Sustav skladištenja podataka - skup tehnologija i alata koji omogućavaju prikupljanje, integraciju i analizu podataka iz različitih izvora, s ciljem iskorištenja postojećih podataka za brzo dobivanje korisnih informacija.


17

Osnovni pojmovi skladišta podataka i skladištenja Područno skladište podataka (eng. data mart) je skup podataka dizajniran i konstruiran radi potpore odlučivanju pri čijem se dizajniranju slijede principi dizajna skladišta podataka s tim da taj skup podataka poslužuje potrebe homogene grupe korisnika.


18

Osnovni pojmovi skladišta podataka i skladištenja Skladište podataka se često sastoji od različitih manjih skupova podataka koje nazivamo područnim skladištima podataka ♦ ♦ ♦

samo jedno tematsko područje, odnosno jedna grupa korisnika pojedine funkcije poslovanja, male usko specijalizirane poslovne grupe, poslovanje pojedinih odjela poduzeća u poduzeću - jedno skladište podataka i više data mart skupova podataka


19

Osnovni pojmovi skladišta podataka i skladištenja Cilj skladištenja podataka ♦ iskoristiti podatke za dobivanje korisnih informacija ♦ analitičarima, menadžerima, donositeljima odluka omogućiti fleksibilan i učinkovit pristup svim relevantnim podacima ♦ omogućiti dobivanje cjelovite slike o poslovanju poduzeća ♦ analiziranje i razumijevanje poslovnih kretanja, praćenje i predviđanje situacije na tržištu, što brža reakcija na promjene ♦ kvaliteta odluka ovisna je o kvaliteti dostupnih podataka, razumijevanju tih podataka i brzini njihova dohvata Oblikovanje skladišta podataka

20

Osnovni pojmovi skladišta podataka i skladištenja Problemi ♦ često se ne može brzo i jednostavno pristupiti postojećim podacima ♦ podaci unutar jednog poduzeća pohranjeni: na raznorodnim platformama u različitim tipovima baza podataka i datoteka u različitim podatkovnim formatima s nekonzistentnim ključevima, mjernim jedinicama… ♦ ♦

za analizu su zanimljivi sumarni i povijesni podaci analitička obrada narušava učinkovitost rada operacijskih baza


21

Značajke skladišta podataka


22

Značajke skladišta podataka

♦ ♦ ♦ ♦

Skladište podataka je skup podataka kao potpora u procesu odlučivanja sa sljedećim značajkama: Tematska orijentacija Integracija i konzistentnost Podaci točni za određeni protekli trenutak ili razdoblje Postojanost Struktura (tipovi) podataka u skladištu podataka Odnos između transakcijskih baza i skladišta


23

Značajke skladišta podataka Tematska orijentacija ♦

Skladište podataka je orijentirano oko glavnih tematskih područja poslovanja neke organizacije, odnosno važne entitete iz stvarnog svijeta (korisnik, proizvod, korisnički račun, ...).


24

Značajke skladišta podataka Tematska orijentacija

♦

Tematska orijentacija kod skladišta podataka je u suprotnosti s klasičnom procesnom, odnosno funkcijskom orijentacijom aplikacija kakvu nalazimo kod operacijskih sustava baza podataka.


25

Značajke skladišta podataka Tematska orijentacija • Operacijsko okruženje automatizira specifične funkcije poslovanja. Općenito uzevši kod opisa poslovanja, operacijsko je okruženje dizajnirano oko zajmova, ušteđevina, bankovnih kartica, a okruženje skladišta podataka oko glavnih tema, odnosno važnijih entiteta iz stvarnog svijeta, kao što su: korisnik, prodavač, proizvod, korisnički račun itd.


26

Značajke skladišta podataka Integracija Najvažnija značajka skladišta podataka jest da su podaci koji se prikupljaju iz raznorodnih izvora u njemu integrirani. Integracija uključuje konzistentne: nazive podatkovnih elemenata, mjerne jedinice za varijable, strukture šifriranja, ključevi podatkovnih elemenata., ..itd.


27

Značajke skladišta podataka Integracija Operacijske podatke koji dolaze iz više baza podataka, a vjerojatno i podatke pribavljene izvan poduzeća koje izrađuje skladište podataka, treba transformirati i integrirati prije pohranjivanja u skladištu podataka. Proces transformacije i integracije podataka može biti najzahtjevniji dio izgradnje skladišta podataka.


28

Značajke skladišta podataka Integracija

Operacijsko okruženje

integracija podataka

M,F

Skladište podataka

M,F

X,Y M,Ž

Podaci se integriraju prije učitavanja u skladište podataka


29

Značajke skladišta podataka Integracija Bilo da se radi o fizičkim značajkama podataka, mjernim jedinicama ili šifriranju, podaci trebaju biti spremljeni u skladište podataka na jedinstven, općeprihvatljiv način, i onda kada operacijski sustavi spremaju podatke na različite načine.


30

Značajke skladišta podataka Podaci točni za određeni protekli trenutak ili razdoblje Skladište podataka je dugi vremenski slijed zabilježenih snimaka – to je slijed slojeva podataka na kojima su spremljeni podaci o poslovanju poduzeća za određene trenutke, odnosno vremenska razdoblja.


31

Značajke skladišta podataka Podaci točni za određeni protekli trenutak ili razdoblje Za podatke u skladištu podataka kaže se da su vremenski različiti jer je svaki podatak točan za neki protekli trenutak: podaci stari 5 do 10 godina element vremena u složenim ključevima ako je snimak napravljen ispravno, nema kasnijih izmjena Oblikovanje skladišta podataka

32

Značajke skladišta podataka Postojanost Dvije

vrste operacija: učitavanje relevantnih podataka i upiti Kad su podaci učitani, nad njima više nema promjena. Zbog toga u skladištu podataka ne postoji anomalija brisanja i mijenjanja podataka, pa su dopuštene određene slobode u pristupu podacima, pogotovo u pogledu normalizacije. Posljedica jednostavnosti operacija nad skladištem podataka je jednostavnija tehnologija. Oblikovanje skladišta podataka

33

Značajke skladišta podataka Razlike između OLTP sustava i skladišta


34

Skladištenje podataka Procesi


35

Skladištenje podataka - Procesi ♦

U postupku skladištenja podataka prisutni su sljedeći procesi: izvlačenje,

transformacija i učitavanje podataka

spremanje

podataka i upravljanje podacima

korištenje


podataka kao potpora u procesu odlučivanja

36

Skladištenje podataka - Procesi

NASLIJEĐENI SUSTAVI

RDBMS

IZVLAČENJE, TRANSFORMACIJA I UČITAVANJE PODATAKA

SPREMANJE PODATAKA

UPITI, ANALIZA, IZVJEŠĆA

VANJSKI PODACI


37

Skladištenje podataka - Procesi Izvlačenje, transformacija, učitavanje, upravljanje i korištenje Izvlačenje, transformacija, učitavanje

Procesi izvlačenja, transformacije i učitavanja podataka zapravo uključuje niz složenih zadaća koje se odnose na identificiranje odgovarajućeg skupa podataka u operacijskom sustavima i vanjskim izvorima, izvlačenje, čišćenje i transformaciju podataka, prebacivanje podataka u skladište podataka (baza podataka), te provjeru kvalitete podataka. Oblikovanje skladišta podataka

38

Skladištenje podataka - Procesi Izvlačenje, transformacija, učitavanje, upravljanje i korištenje Učitavanje i upravljanje

Podaci se spremaju u bazu podataka. Posebnu pozornost treba posvetiti omogućavanju brzog i učinkovitog pristupa podacima, te upravljanju skladištem podataka. Upravljanje uključuje zadaće kao što je omogućavanje sigurnog pristupa podacima, suočavanje s problemima povećanja količine podataka u slučaju pogreške u sustavu. Oblikovanje skladišta podataka

39

Skladištenje podataka - Procesi Izvlačenje, transformacija, učitavanje, upravljanje i korištenje Korištenje

Korištenje podataka se odnosi na postavljanje upita nad podacima pohranjenih u skladištu podataka, analizu tih podataka, izradu izvješća, grafova, pronalaženja nepoznatih zakonitosti među podacima i objavljivanje dobivenih rezultata.


40

Skladištenje podataka - Procesi Izvlačenje

Izvlačenje podataka (extracting) podrazumijeva čitanje i razumijevanje izvornih podataka, odabir podataka koji su najkvalitetniji i najrelevantniji za poslovnu analizu, te preslikavanje tih podataka radi daljnje obrade.


41

Skladištenje podataka - Procesi Izvlačenje Problemi ♦

Čitanje podataka iz raspoloživih izvora koji posjeduju nejasne i nedokumentirane vrijednosti podataka, a odnosi među podacima imaju dosta nekonzistentnosti i zalihosti.


42


Za zastarjele sustave koji se koriste tekstualnim datotekama, mrežnim i hijerarhijskim bazama podataka smještenim na mainframe računalim koristi se naziv naslijeđeni sustavi. Ti postojeći sustavi izvor su povijesnih podataka i često ne podržavaju on-line režim rada.


43


Meta podaci, tj. podaci o imenu datoteka, nazivu polja, ograničenjima i tipovima podataka, mijenjaju se tokom vremena. Te promjene nisu uvijek dokumentirane, te se ne može sa sigurnošću utvrditi kada je došlo do promjena u naslijeđenoj aplikaciji. Ljudi koji su razvijali te aplikacije rijetko su još dostupni.


44


Pri ispitivanju izvora podataka problem nekonzistentnosti između više odvojenih sustava dolazi u središte pozornosti. Podaci su raspoređeni u više operacijskih baza podataka i među njima postoji znatna zalihost. Podaci koji se odnose na iste entitete razlikuju se po formi i sadržaju. Svaki izvor podataka izrađen je na temelju vlastitog skupa zahtjeva i tijekom razvojnog procesa ne vodi se briga o drugim bazama, pa nema usklađenog pogleda na podatke.


45

Skladištenje podataka - Procesi Izvlačenje Metode izvlačenja podataka iz operacijskih baza: ♦ Izvlačenje podataka iz log datoteka. ♦ Neki sustavi kreiraju posebnu datoteku promjena koja se pri izvlačenju koristi na isti način kao log datoteka. ♦ Ako izvorni podaci imaju oznake vremena, u procesu izvlačenja podataka može se odabrati samo one podatke koji su se promijenili od zadnjeg izvlačenja podataka. ♦ Metoda koja se godinama koristila je uspoređivanje datoteka.


46

Skladištenje podataka - Procesi Izvlačenje

Budući da je skladište podataka slijed snimaka stanja transakcijskih baza, podaci se trebaju izvlačiti tako da se izvlačenje podataka iz jednog izvora odnosi na isti trenutak u vremenu kao i izvlačenje iz drugih izvora podataka.


47

Skladištenje podataka - Procesi Transformacija

♦

♦

Kad se podaci izvuku iz operacijskih baza podataka i datoteka, te vanjskih izvora, treba ih pripremiti za učitavanje u skladište podataka – dakle treba ih transformirati u prikladni format. Podatke treba prilagoditi modelu podataka odredišne baze podataka, provjeriti njihovu točnost i kvalitetu, te ih integrirati.


48


Transformirani podaci moraju biti: ♦ Točni ♦ Relevantni za poslovne potrebe ♦ Konzistentni za zalihosne izvore ♦ Potpuni, tj. moraju sadržavati informacije potrebne za odgovore na poslovna pitanja


49


♦

Transformacija podataka u pripremnom spremištu podataka uključuje: Čišćenje podataka

♦ ♦ ♦ ♦

Ispravke spellinga Rješavanje sukoba domena Rad s podatkovnim elementima koji nedostaju Raščlanjivanje podataka u standardne formate

Odstranjivanje podataka nekorisnih za skladište podataka Kombiniranje izvora podataka Nametanje novih ključeva Izgradnja agregacija radi poboljšanja izvedbe čestih upita


50


Čišćenje podataka je otklanjanje nekonzistentnosti i anomalija koje bi imale nepovoljan utjecaj na daljnju obradu i korištenje podataka. Čišćenje podataka prije ubacivanja u skladište podataka od životne je važnosti za projekt skladištenja podataka budući da o kvaliteti podataka pohranjenih u skladište podataka ovisi ispravnost odluka koje se donose na temelju tih odluka.


51


♦ ♦ ♦ ♦

Čišćenjem podataka otklanjaju se pogreške nastale zbog nepažljivog upisa podataka i osigurava se da podaci budu: Konzistentni unutar sebe Konzistentni s drugim podacima u istom izvoru podataka Konzistentni s podacima u drugim izvorima Konzistentni s podacima koji su već u skladištu podataka


52

Skladištenje podataka - Procesi Transformacija Tehnike čišćenja, transformacije i integracije moraju se primjenjivati na iterativni način. Treba specificirati logiku za transformaciju podataka i automatizirati proces što više moguće (korištenjem specijaliziranih alata i programske podrške). Složenost procesa ovisi o dizajnu skladišta podataka, strukturi izvornog sustava, čistoći izvornog sustava i zahtjevima za integracijom izvornih sustava. Informacije o izvlačenju i transformaciji treba dokumentirati jer one čine važne meta podatke. Oblikovanje skladišta podataka

53

Skladištenje podataka - Procesi Učitavanje

♦ Učitavanje podataka

Dnevno, tjedno ili mjesečno Treba nametnuti referencijski integritet podataka Provjera kvalitete učitanih podataka


54

Skladištenje podataka - Procesi Izvlačenje, transformacija i učitavanje - kvaliteta podataka

Loša kvaliteta podataka, prema istraživanjima SAS Instituta, uzrok je neuspjeha u 70% projekata izgradnje skladišta podataka što je dovoljan razlog da se tom pitanju posveti dužna pažnja prilikom svih faza izgradnje sustava. U većini slučajeva pitanja kvalitete podataka su izvan utjecaja tima zaduženog za skladište podataka već ona ovisi o ispravnosti izvorišnih sustava – izvora podataka.


55


♦

♦

♦

Karakteristike kvalitetnih podataka: Ispravnost – podatak u bazi skladišta podataka odgovara podatku iz izvora, a ako ne odgovara postoji dokumentiran razlog različitosti Potpunost – podaci u bazi skladišta podataka predstavljaju cijeli skup relevantnih podataka, npr. element pod nazivom ukupan prihod treba sadržavati i podatke iz podružnice u Austriji, ako nema podataka za tu podružnicu potrebno je preimenovati naziv elementa Konzistentnost – podaci ne smiju biti kontradiktorni, npr. agregacije podataka moraju odgovarati sumi detaljnih podataka


56


♦ ♦

Karakteristike kvalitetnih podataka: Jedinstvenost – npr. u skladištu podataka smije postojati samo jedan oblik imena neke tvrtke Pravovremenost – podaci u skladištu podataka odgovaraju određenom vremenskom trenutku, npr. stanje broja korisnika u 3/2000 godine treba usporediti s jednakim takvim izvještajem iz izvora podataka. Druga komponenta pravovremenosti je sam proces prijenosa koji u pravilnim vremenskim periodima dopunjuje bazu skladišta podataka. U slučaju prekida procesa potrebno je znati vrijeme zadnjeg uspješnog prijenosa odnosno datum valjanosti baze skladišta podataka


57


♦ ♦ ♦ ♦

Da bi podaci u skladištu podataka bili točni, konzistentni i pouzdani potrebno je baviti se kvalitetom podataka tijekom čitavog procesa skladištenja podataka. To uključuje: pregled kvalitete podataka u operacijskim sustavima, razvoj i izvršenje plana djelovanja za čišćenje podataka, praćenje stanja kvalitete u procesu izvlačenja, transformacije i učitavanja, osiguravanje da podaci u odredišnom okruženju budu pouzdani, konzistentni i da odgovaraju potrebama poslovnih korisnika.


58


Kad se podaci učitaju u skladište podataka treba napraviti provjeru stanja učitanih podataka. Prebrojavanje i zbroj odgovarajućeg skupa podataka donosi jednostavnu i brzu provjeru podataka. Ako su sva prebrojavanja ispala prema očekivanjima, a zbrojevi ili prosječne vrijednosti se nalaze unutar specificirane gornje i donje granice, onda se može s određenom pouzdanošću tvrditi da je učitavanje visoke kvalitete, te da krajnji korisnici mogu vjerovati sadržaju skladišta.


59

Skladištenje podataka - Procesi Izvlačenje, transformacija i učitavanje - kvaliteta podataka Kvaliteta podataka u skladištu se može redovito provjeravati uzimanjem slučajnih uzoraka podataka. Postavi se niz standarda za kvalitetu podataka i provjerava jesu li podaci unutar granica koje imaju smisla za poslovanje, te se i nad 1% skladišta može procijeniti sveukupna kvaliteta podataka u skladištu. Provjerava se jesu li vrijednosti podataka konzistentne s vremenskim slijedom sličnih vrijednosti koje su im prethodile. Također, uspoređuju se podaci s vrijednostima u operacijskim sustavima.


60


Za osiguranje kvalitete podataka u skladištu podataka važno je da krajnji korisnici skladišta daju informatičkom osoblju informacije o kvaliteti podataka. Krajnji će korisnici bolje od informatičkog osoblja razumjeti poslovne razloge za moguću besmislenost nekih podataka u skladištu i bolje će otkrivati podatke čija vrijednost nema smisla.


61

Skladištenje podataka - Procesi Izvlačenje, transformacija i učitavanje – alat


62

Skladištenje podataka - Procesi Spremanje podataka i upravljanje ♦

Podaci se spremaju u bazu podataka odvojenu od postojećih operacijskih (OLTP) baza.

♦

Posebnu pozornost treba posvetiti omogućavanju brzog i učinkovitog pristupa podacima te upravljanju skladištem podataka.

♦

Upravljanje uključuje omogućavanje sigurnog pristupa podacima, suočavanje s problemom stalnog povećanja količine podataka te osiguravanje raspoloživosti podataka u slučaju pogreški u sustavu.


63

Skladištenje podataka - Procesi Korištenje skladišta podataka ♦ ♦ ♦ ♦ ♦

postavljanje upita nad podacima analiza podataka izrada izvješća, grafova pronalaženje nepoznatih zakonitosti među podacima objavljivanje dobivenih rezultata OLAP

(On-Line Analytical Processing)

Dubinska analiza podataka (data mining)


64

Skladištenje podataka - Procesi Korištenje skladišta podataka

OLAP analiza - analiza velikog broja podataka na brz, konzistentan i interaktivan način: ♦

♦ ♦

Podaci se organiziraju, te pomoću tablica i grafova prikazuju na način na koji krajnji korisnik razmišlja pri analizi poslovanja Prikazuju se sumarni i detaljni podaci Pogled na podatke iz različitih perspektiva


65

Skladištenje podataka - Procesi Korištenje skladišta podataka OLAP alati: ♦

♦

♦ ♦

analiza velikog broja podataka na brz, konzistentan i interaktivan način - dinamička višedimenzijska analiza podataka podaci se organiziraju, te pomoću tablica i grafova prikazuju na način koji odražava dimenzionalnost poslovanja tj. način na koji krajnji korisnik razmišlja pri analizi poslovanja sumarni podaci, detaljni podaci pogled na podatke iz različitih perspektiva


66

Skladištenje podataka - Procesi Korištenje skladišta podataka Primjeri - OLAP alati mogu dati odgovor na pitanja: ♦

♦ ♦

♦

Kolika je tjedna prodaja proizvoda A u zadnje dvije godine po županijama u Hrvatskoj, te u kojim županijama se nije postigla predviđena tjedna kvota prodaje za taj proizvod? Kolika je prodaja proizvoda B za prošli mjesec u zapadnoj Europi u odnosu na isti mjesec godinu dana ranije? Kojih 10 proizvoda je donijelo najveću zaradu u proteklom tromjesečju na području grada Zagreba? Koji su se proizvodi najslabije prodavali u istom razdoblju? Kad bi u čitavoj Hrvatskoj bio porast prodaje vrste proizvoda C jednak porastu u Zagrebu u 1998. godini, kolika bi bila prodaja u Hrvatskoj u toj godini?


67

Skladištenje podataka - Procesi Korištenje skladišta podataka Dubinska analiza podataka (DATA MINING) Analiza velikih skupova podataka s ciljem pronalaženja neočekivanih veza i uzoraka u skupovima podataka ili sumarnog prikaza skupa podataka na način da vlasniku ili korisniku podataka pruža nove, razumljive i korisne informacije.


68

Baze podataka - pregled Tehnike dubinske analize podataka se dijele na: Deskriptivno

modeliranje

Segmentacija Clustering Prediktivno

modeliranje

Klasifikacija regresija Pronalaženje

uzoraka i pravila – asocijacijska pravila (market basket analysis) Vizualizacijske i interaktivne metode


69

Skladištenje podataka - Izgradnja Analiza poslovnih zahtjeva

Dizajn modela podataka

Dizajn načina korištenja podataka

Analiza podataka

Analiza izvornih sustava

Analiza tehničke arhitekture

Analiza Oblikovanje skladišta podataka

Dizajn procesa izvlačenja, transformacije i učitavanja podataka

Izgradnja sustava

Određivanje tehničkog okruženja

Dizajn 70

Modeli podataka za skladište podataka

Model entiteti – veze Relacijski model Dimenzionalni model činjenica (Dimensional Fact Model Višedimenzionalni model podataka Oblikovanje skladišta podataka

71

Modeli podataka za skladište podataka ♦

Konceptualni model baze podataka u potpunosti je nezavisan o sustavu za upravljanje bazom podataka i operacijskom sustavu računala na kojem se baza podataka nalazi. On ostaje isti bez obzira upotrijebe li se hijerarhijski, mrežni ili relacijski sustav za upravljanje bazom podataka. U sklopu konceptualnog modela podataka isključivo se definiraju atributi za željene entitete i veze između entiteta. Nije definiran konkretan način na koji se veze između entiteta ostvaruju. Model entitet-veza primjer je konceptualnog modela baze podataka.


72

Modeli podataka za skladište podataka Logički model podataka je korisnikovo viđenje podataka u sustavu za upravljanje bazom podataka. Ovaj model definira način na koji su entiteti međusobno povezani, a time i mogućnosti odnosno načine pretraživanja baze podataka. Hijerarhijski, mrežni i relacijski model podataka su logički modeli baze podataka.


73

Modeli podataka za skladište podataka Model entiteti – veze Model entitet_veza (engl. entity-relationship model, MEV) je konceptualni model podataka koji je prvi opisao Chen 1976. Model entitet_veza čine entiteti, njihovi atributi i veze između entiteta. Konceptualna shema predočava se grafički dijagramom entiteti_veze. Uz najstariji Chenov, postoji veći broj drukčijih grafičkih prikaza, od kojih je najpoznatiji Martinov. Postupci konceptualnog modeliranja modelom entitet_veza općenito nisu strogo propisani. Jednako tako, ne postoji standardni grafički prikaz, iako su Chenov i Martinov najčešći.


74

Modeli podataka za skladište podataka Model entiteti – veze MEV se koristi isključivo za opis konceptualnog modela podataka. Konceptualna shema u MEV-u prikazana je u obliku DIJAGRAMA ENTITETI-VEZE (DEV).

U MODELU ENTITETI-VEZE (MEV) se dio realnog svijeta opisuje pomoću sljedećih osnovnih elemenata strukture: •

entiteta,

•

njihovih međusobnih veza

•

odgovarajućih atributa.


75

Modeli podataka za skladište podataka Model entiteti – veze Odnosi između tipova entiteta opisuju se elementom VEZA. Veza se ovisno o broju entiteta koje opisuje (povezuje) dijeli na unarnu, binarnu, ternarnu …

Ako tip entiteta promatramo kao skup entiteta, tada se matematički veza može izraziti kao matematičko pridruživanje elemenata skupova. Stoga je kod opisa veza ključno definirati kardinalnost pridruživanja dvaju tipova entiteta.


76

Modeli podataka za skladište podataka Model entiteti – veze Veza tako može biti jednoznačna, uvjetna ili višeznačna. Pridruživanje je:

♦

•

JEDNOZNAČNO ako je svakom članu jednog tipa entiteta (skupa) A pridružen jedan i samo jedan član tipa entiteta B. Kardinalnost se označava oznakom 1,1.

•

UVJETNO ako je svakom članu jednog tipa entiteta (skupa) A pridružen jedan ili nijedan član tipa entiteta B. Kardinalnost se označava oznakom 0,1.

VIŠEZNAČNO ako je svakom članu jednog tipa entiteta (skupa) A pridružen nijedan, jedan ili više članova tipa entiteta B. Kardinalnost se označava oznakom 0,M.


77

Modeli podataka za skladište podataka Model entiteti – veze

TIP_ENT._1

UREĐAJ

1,1

veza1

0,M

smještaj

1,M

TIP_ENT._2

1,1

LOKACIJA

G r a f i č k i p r im j e r v e z e p r e m a C h e n u


78

Modeli podataka za skladište podataka Model entiteti – veze Martinov grafički prikaz se razlikuje u odnosu na Chenov prikaz u sljedećem (nastavak): ♦

Donja i gornja granica kardinalnosti označava se oznakama: • kružić označava donju granicu 0, • crtica donju i/ili gornju granicu 1, • znakom otiska “pačje noge” označava se gornja granica M (više), • gornja granica označava se oznakom pisanom uz oznaku tipa entiteta.

♦

Veze ne mogu imati atribute, već se umjesto veze s atributima stvara novi tip entiteta. Taj novostvoreni tip entiteta povezuje se s tipovima entiteta koji su u vezi.


79

Modeli podataka za skladište podataka Model entiteti – veze

TIP_ENT._2

sadrži

UREĐAJ

se nalazi

veza2

veza1

TIP_ENT._1

LOKACIJA

G r a fič k i p r im je r v e z e p r e m a M a r tin u


80

Modeli podataka za skladište podataka Model entiteti – veze Osnovne karakteristike MODELA ENTITETI-VEZE (MEV): ♦ MEV s odgovarajućim DEVom se pokazao kao vrlo pogodan za konceptualni prikaz baze podataka. ♦ DEV na pregledan vizualan način, korisnicima vrlo blizak, prikazuje odnose između pojedinih objekata koji sudjeluju u definiranju strukture baze podataka. ♦ DEV se može transformirati definiranim pravilima na bilo koji klasični model baze podataka (hijerarhijski, mrežni ili relacijski). ♦ Korektno nacrtani DEV može se definiranim pravilima jednoznačno transformirati u relacijske sheme koje su barem u 3NF.


81

Modeli podataka za skladište podataka Relacijski model U RELACIJSKOM MODELU PODATAKA osnovni je element RELACIJA koja se najjednostavnije može prikazati kao tablica: ♦

Stupci predstavljaju pojedine atribute.

♦

Vrijednosti koje se mogu pojaviti u određenom stupcu tablice su vrijednosti iz domene pojedinog atributa.

♦

Pojedini redak predstavlja opis pojedinog entiteta.

♦ Postoji skup atributa (primarni ključ) čije vrijednosti

jednoznačno određuju pojedini red.


82

Modeli podataka za skladište podataka Relacijski model Svaka RELACIJA predstavljena kao tablica opisana je RELACIJSKOM SHEMOM. Pod RELACIJOM podrazumijevamo sadržaj TABLICE. SHEMA RELACIJE se odnosi na opis strukture RELACIJE, dakle atributa koji u njoj sudjeluju s posebno naznačenim primarnim ključem.


83

Modeli podataka za skladište podataka Relacijski model RELACIJSKI MODEL PODATAKA koristi istu strukturu i sintaksu za opis ENTITETA i ODNOSA (veze). RELACIJE se koriste za spremanje opisa entiteta i njihovih odnosa, ne postoji zahtjev za eksplicitan opis kojim bi se definirala veza između dva tipa entiteta kao što postoji u mrežnom modelu (tip skupa).


84

Modeli podataka za skladište podataka Relacijski model

Baza pod.

Ime tablice: tablice: ZAPOS BRZAP BRZAP 1369 1369 1499 1499 1521 1521 7566 7566

IMEZAP IMEZAP DARKO DARKO ANA ANA VEDRAN VEDRAN JOSIP JOSIP

POSAO POSAO SLUŽBENIK SLUŽBENIK PRODAVAČ PRODAVAČ PRODAVAČ PRODAVAČ UPRAVITELJ UPRAVITELJ

BRODJ BRODJ 20 20 30 30 30 30 20 20

Ime tablice: tablice: ODJEL BRODJ BRODJ 10 10 20 20 30 30 40 40

IMEODJELA IMEODJELA RAČUNOVODSTVO RAČUNOVODSTVO MARKETING MARKETING PRODAJA PRODAJA RAZVOJ RAZVOJ

LOKACIJA LOKACIJA ZAGREB ZAGREB SPLIT SPLIT ZAGREB ZAGREB OSIJEK OSIJEK


85

Relacijska baza podataka - terminologija

♦ ♦

Svaka n-torka je jednoznačno određena vrijednošću primarnog ključa. Može se logički povezati podatke iz više tablica korištenjem stranog ključa.

Tablica ZAPOS BRZAP 1369 1499 1521 7566

IMEZAP DARKO ANA VEDRAN JOSIP

Primarni Primarni ključ ljuč Oblikovanje skladišta podataka

Tablica ODJEL POSAO SLUŽBENIK PRODAVAČ PRODAVAČ UPRAVITELJ

BRODJ 20 30 30 20

Strani ključ ključ

BRODJ 10 20 30 40

IMEODJELA RAČUNOVODSTVO MARKETING PRODAJA RAZVOJ

LOKACIJA ZAGREB SPLIT ZAGREB OSIJEK

Primarni Primarni ključ ključ 86

Modeli podataka za skladište podataka Relacijski model

neključni atribut

atribut – primarni ključ BRZAP

IMEZAP

POSAO

BRODJ

----------

--------------

------------------

-----------

1369

DARKO

SLUŽBENIK

20

1499

ANA

PRODAVAČ

30

1521

VEDRAN

PRODAVAČ

30

7566

JOSIP

UPRAVITELJ

20

n-torka Oblikovanje skladišta podataka

87

Modeli podataka za skladište podataka Relacijski model Svojstva RELACIJSKOG MODELA PODATAKA: • jednostavan za korištenje, • posjeduje strogi matematički formalizam koji osigurava jednoznačnost u definiranju struktura podataka i operacija nad njima, • sadrži jednostavne strukture podataka, • općenit, • neovisan o implementacijskim detaljima i načinu pretraživanja.


88


MEV i relacijski model U MEV-u se svakom entitetu definiraju atributi, koji iskazuju njegova svojstva. Entitet uspostavlja veze s jednim ili nekoliko drugih entiteta. Ovakav konceptualni model izuzetno se lako preslikava u logički model za relacijsku bazu podataka. Entitet postaje relacijska shema, a njegovi atributi postaju atributi relacijske sheme. Binarne veze (tj. one koje uključuju samo dva entiteta) tipa 1:1 i 1:N izražene su stranim ključem na drugu relacijsku shemu.


89


Model EV i relacijski model


90


Model EV i relacijski model Veza M:N se može pretvoriti u dodatni entitet, koji s početnim entitetima ostvaruje odnos 1:M odnosno 1:N. Pri preslikavanju u relacijski model veza M:N rezultira novom relacijom čiji je primarni ključ uvijek sastavljen od primarnih ključeva relacija koje su spojene tom vezom. Ternarna veza tipa M:M:M dat će tako novu relaciju u kojoj tri strana ključa tvore jedan primarni ključ. Pravilno izrađen MEV daje relacijsku shemu baze podataka koja se nalazi barem u trećoj normalnoj formi (3NF), tj. svi neključni atributi u svakoj relaciji su međusobno funkcijski nezavisni, te potpuno funkcijski ovisni o ključu. Oblikovanje skladišta podataka

91



♦

♦ ♦ ♦

Za transakcijsku obradu podataka normalizacija (u praksi obično 3NF) donosi mnoge prednosti: Uklanjanjem zalihosti u modelu podataka dobiva se na konzistentnosti podataka budući da se uklanjaju anomalije unosa, izmjene i brisanja. Pristup zapisima je jednoznačno određen ključevima relacija što omogućava brzi indeksirani pristup. Smanjuje se vjerojatnost pojave semantičkih pogrešaka prilikom izvođenja operacije. Dodavanje novootkrivenih entiteta i veza među njima je jednostavno.


92



MEV modeliranje je, dakle, vrlo dobra tehnika za dizajniranje sustava za transakcijsko procesiranje u relacijskom okruženju. Međutim, MEV koji rezultira relacijskom shemom baze podataka u 3NF je manje prikladan za dizajn modela podataka u okruženju skladištenja podataka, pogotovo u pogledu izvedbe složenih upita.


93


MEV i relacijski model Razlozi za navedenu tvrdnju su sljedeći: ♦ ♦ ♦

♦ ♦

MEV je razvijen upravo s ciljem što boljeg zadovoljenja zahtjeva transakcijske obrade. Postojeća programska podrška ne može učinkovito obraditi zahtjevnije upite nad bazom podataka koja je dizajnirana MEVom. Spajanje relacija predstavlja vrlo tešku zadaću za postojeću programsku podršku. Problematično za izvedbu je i dobivanje sumarnih podataka, sortiranje podataka i pretraživanje veće količine podataka, a sve te operacije često treba izvoditi u sustavima za potporu odlučivanju. Krajnji korisnik skladišta teško može razumjeti i pamtiti MEV. Korisniku baze podataka modelirane po pravilima MEV modeliranja je teško zadati složeni upit koji nije prethodno planiran.


94


Skladište podataka, kao bazu podataka za poslovne analize, potrebno je izraditi u konceptualnom modelu koji će jasno postaviti "početni" element za analizu, omogućiti istodobno postavljanje nekih parametara poslovanja kao međusobno posve nezavisnih, drugima (funkcijski i tranzitivno ovisnima) naglasiti zavisnost te biti pogodan za sumiranje. Takve mogućnosti pruža višedimenzijski konceptualni model ili dimenzijski činjenični model.


95

Modeli podataka za skladište podataka Osim pojma višedimenzijski konceptualni model i dimenzijski činjenični model u literaturi se koristi i naziv dimenzijski konceptualni model, a pojam dimenzijski model se često odnosi na logički model koji opisuje realizaciju višedimenzijskog konceptualnog modela u sustavu za upravljanje relacijskom bazom podataka. Kimball opisuje dimenzijsko modeliranje kao "tehniku konceptualnog i implementacijskog oblikovanja kojom se putem standardiziranog intuitivnog koncepta omogućuje brz pristup podacima". Jednostavnim konceptualnim modelom opisuju se poslovni procesi preko dimenzija koje su često hijerarhijski organizirane. Višedimenzijski konceptualni model definira osnovne pojmove činjenice, mjere, dimenzije i hijerarhije.


96

Modeli podataka za skladište podataka Višedimenzijski pogled na podatke ♦

♦

♦

kod višedimenzijskog pogleda na podatke svaki podatkovni element smješten je na presjeku dimenzijskih članova koji ga određuju primjer: kod analiziranja narudžbi, dimenzije mogu biti: proizvod, vrijeme i kupac intuitivan koncept, lako razumljiv analitičarima i menadžerima

KUPAC

VRIJEME

PROIZVOD


97

Modeli podataka za skladište podataka Višedimenzijski pogled na podatke ♦

OLAP alati pružaju krajnjem korisniku višedimenzijski pogled na podatke.

♦

Organiziranjem i spremanjem podataka prema navedenom konceptu omogućava se sljedeće: korisnik može dobro razumijeti podatke, korisnička sučelja su jednostavna za korištenje, izvedba upita je na zadovoljavajućoj razini.

♦

Broj dimenzija je često veći od tri i tada se radi o “n_dimenzijskoj kocki” ili “hiperkocki”. Takvu strukturu nije lako vizualno predočiti, ali radi se o istom konceptu kao i za tri dimenzije.


98

Dimenzijski činjenični model ♦

Dimenzijski činjenični model je konceptualni model u kojem je skladište podataka predstavljeno skupom činjeničnih shema (eng. fact scheme).

Činjenična shema – osnovne komponente: ♦ činjenica – središte interesa u procesu donošenja odluka (npr. narudžbe, prodaja, itd.) ♦ mjere – brojčani atributi koji se koriste za izračunavanja ♦ dimenzije – atributi s konačnim skupom vrijednosti; određuju najnižu razinu detaljnosti podataka


99

Dimenzijski činjenični model PURCHASE ORDER productID

unitPrice quantity income

customerID

Jednostavna date

činjenična shema

Činjenica: purchase order Mjere: unitPrice, quantity, income Dimenzije: productID, date, customerID


100


Zbog dinamičke prirode činjenica, činjenična shema gotovo uvijek uključuje vremensku dimenziju, čija zrnatost može varirati (minuta, sat, datum, mjesec…).

♦

Primarni događaj – pojavljivanje činjenice, definirano preko n-torke čije su vrijednosti uzete iz domena n dimenzija koje opisuju činjenicu. Svaki primarni događaj ima točno jednu vrijednost za svaku mjeru. Dimenzije se koriste za identifikaciju i odabir primarnih događaja. Primjer primarnog događaja: kupac A.B. naručio je 8. prosinca 2004. godine 1 knjigu “Oblikovanje skladišta podataka”, s cijenom od 300 kuna.


101

Dimenzijski činjenični model productName

name

address

PURCHASE ORDER type

productID


customerID

city country

productDesc date

Činjenična shema dayOfWeek month ♦ ♦

činjenična shema – usmjereni graf kojem je korijen činjenica dimenzijski atributi su ili dimenzije (npr. customerID) ili drugi atributi koji opisuju dimenzije (npr. address, city, country)


102

Dimenzijski činjenični model

♦

hijerarhije – sastavljene od diskretnih dimenzijskih atributa povezanih funkcijskim ovisnostima

♦

svaka dimenzija je korijen jedne hijerarhije (npr. customerID je korijen hijerarhije u kojoj se još nalaze atributi: name, address, city i country)

♦

funkcijske ovisnosti predstavljaju veze među atributima tipa višeprema-jedan (kao što je npr. veza između atributa city i country) takve veze omogućavaju fleksibilno sumiranje podataka u upitima


103


Hijerarhije mogu također sadržavati opisne atribute koji sadrže dodatne informacije o nekom drugom dimenzijskom atributu (npr. productName i productDesc opisuju proizvod koji je jednoznačno određen atributom productID). Za razliku od ostalih dimenzijskih atributa, opisni atributi se ne mogu koristiti za sumiranje podataka. productName

address

name PURCHASE ORDER

type

productID


customerID

city country

productDesc date dayOfWeek month


Činjenična shema s označenim opisnim atributima 104


Sekundarni događaji agregiraju (sumiraju) primarne događaje. U primjeru, primarni događaji su narudžbe po danima, proizvodima i kupcima. Zarada od narudžbi može se sumirati npr. po tipovima proizvoda, po mjesecima ili po mjestu stanovanja kupaca, u različitim kombinacijama. Svaka takva kombinacija, odnosno n-torka vrijednosti dimenzijskih atributa, čini jedan sekundarni događaj.

♦

Svaka n-torka vrijednosti dimenzijskih atributa koje čine sekundarni događaj odgovara skupu n-torki vrijednosti dimenzija tj. skupu primarnih događaja.

♦

Za neki sekundarni događaj zarada će biti izražena kao zbroj zarada odgovarajućih primarnih događaja (tj. narudžbi).


105


Mjera je zbrojiva nad određenom dimenzijom ako se njene vrijednosti mogu agregirati po pripadajućoj hijerarhiji koristeći operator zbrajanja.

♦

Mjera je zbrojiva ako se njene vrijednosti mogu agregirati koristeći operator zbrajanja po svim hijerarhijama u činjeničnoj shemi (npr. zarada je zbrojiva po svim dimenzijama).

♦

Poželjno je da što veći broj mjera bude zbrojiv.

♦

Ako je činjenica nezbrojiva, poželjno je da se nad njom može provesti agregacija koristeći operatore kao što su maksimalna vrijednost, minimalna vrijednost ili srednja vrijednost (kao što je slučaj s mjerom cijena proizvoda).


106

Modeli podataka za skladište podataka Konceptualno višedimenzijsko oblikovanje ♦

Konceptualno višedimenzijsko oblikovanje podrazumijeva stvaranje skupa činjeničnih shema na temelju postojećih shema koje opisuju izvore podataka.

♦

Svaka činjenična shema se izgrađuje tako da se prvo odabere činjenica, a zatim se, počevši od te činjenice, prate funkcijske ovisnosti i dodaju novi atributi u činjeničnu shemu.

♦

Osnovni problem je identifikacija funkcijskih ovisnosti.

♦

Činjenična shema, kao konceptualna shema, ne ovisi o DBMS-u odabranom za implementaciju.


107

Modeli podataka za skladište podataka Implementacija konceptualnog činjeničnog modela Kod implementacije je bitno da krajnjim korisnicima omogućuje razumijevanje podataka, da korisnička sučelja budu jednostavna za korištenje, te da izvedba upita bude na zadovoljavajućoj razini Implementacija: ♦ relacijska baza podataka (ROLAP rješenje)

♦

osnovna struktura je tzv. zvjezdasta shema, odnosno zvijezda spoj

višedimenzionalna baza podataka (MOLAP rješenje)

podaci se spremaju u višedimenzionalna polja


108

Modeli podataka za skladište podataka Implementacija konceptualnog činjeničnog modela ROLAP (Relational OLAP) ♦ Svi podaci se pohranjuju u relacijsku bazu podataka, a pri izvedbi upita OLAP alati generiraju SQL naredbe na temelju meta podataka. OLAP alati, dakle, izravno pristupaju podacima u skladištu podataka. Međutim, od OLAP alata se zahtijeva da se analiza može izvoditi brzo i to s jednakim mogućnostima i jednakom lakoćom što se tiče svake od dimenzija. Mora se koristiti specijalizirani dizajn kojim se oponaša podatkovna struktura višedimenzijskog polja i koji je optimiziran za brzu i jednostavnu izvedbu složenih višedimenzijskih upita – spoj zvijezda. Oblikovanje skladišta podataka

109

Modeli podataka za skladište podataka Implementacija konceptualnog činjeničnog modela MOLAP (Multidimensional OLAP) ♦ U ovom načinu rada podaci se pohranjuju u bazu podataka koja nije relacijska i koja je posebno optimizirana za pohranu podataka namijenjenih za višedimenzijsku analizu. U takvoj, višedimenzijskoj bazi podataka (Multidimensional Database – MDDB) podaci se pohranjuju u višedimenzijska polja na način koji odražava konceptualni pogled u obliku kocke. Pri izvedbi upita na temelju vrijednosti dimenzija zadanih upitom izračunavaju se pozicije ćelija polja koje sadrže tražene podatke.


110

Modeli podataka za skladište podataka Implementacija konceptualnog činjeničnog modela HOLAP (Hybrid OLAP) ♦

Riječ je o kombinaciji MOLAP i ROLAP načina rada. Budući da relacijska baza ima veći kapacitet, a višedimenzijska bržu izvedbu upita, detaljni se podaci spremaju u relacijskoj bazi (tj. skladištu podataka), a oni sumarni podaci koji se u upitima često koriste spremaju se u višedimenzijsku bazu podataka.


111

Modeli podataka za skladište podataka Implementacija konceptualnog činjeničnog modela ♦ ♦

spoj zvijezda - sastoji se od središnje tablice činjenica i više dimenzijskih tablica. Svakoj dimenziji u konceptualnom modelu odgovara jedna dimenzijska tablica (engl. dimensional table) logičkog modela. Svi dimenzijski atributi nalaze se u dimenzijskoj tablici, a za njen primarni ključ se atribut uzima temeljni atribut najdetaljnije razine hijerarhije. Ključ dimenzijske tablice uvijek se sastoji od samo jednog atributa. Dimenzijska tablica je denormalizirana i u njoj postoji tranzitivna funkcijska ovisnost. Veza entiteta opisanog činjeničnom tablicom i bilo kojeg entiteta opisanog nekom od dimenzijskih tablica je uvijek jedan-prema-više.


112

Modeli podataka za skladište podataka Implementacija konceptualnog činjeničnog modela ♦

♦

U tablici činjenica (engl. fact table) nalaze se sve mjere dane činjenice. Uz mjere, činjenična tablica sadrži po jedan strani ključ na svaku od dimenzija koje opisuju činjenicu. Svi strani ključevi na dimenzijske tablice zajedno čine složeni primarni ključ tablice činjenica. To znači da je redak činjenične tablice određen kombinacijom svih primarnih ključeva dimenzijskih tablica. Za svaki zapis u činjeničnoj tablici postoji samo jedan zapis u svakoj dimenziji. Za bilo koji zapis u bilo kojoj dimenzijskoj tablici može postojati više odgovarajućih zapisa u činjeničnoj tablici. Opisani međusobni odnos zapisa omogućuje sumiranje (agregaciju) zapisa u činjeničnoj tablici.


113

Modeli podataka za skladište podataka Implementacija konceptualnog činjeničnog modela VRIJEM E

PRODAVAONICA PRODAJA

ključ_datum

k_datum

dan_u_tjed PROIZVOD dan_u_m jes šifra_proizv m jesec naziv rad_dana_m j veličina godina šifra_tip

k_prodav k_proizv cijena količina prihod

broj_prod ulica šifra_m j im e_m j pošt_br županija država

naziv_tip šifra_poslvđ šifra_kat br_poslvđ naziv_kat


114

Modeli podataka za skladište podataka Implementacija konceptualnog činjeničnog modela Zvijezda spoj ♦

“Činjenice” (ili “mjere”): brojčane kontinuirano vrednovane zbrojive

♦

Atributi u dimenzijskim tablicama: tekstualni diskretni (tj. imaju određen skup mogućih vrijednosti)


115

Modeli podataka za skladište podataka Dimenzijsko modeliranje

♦

tehnika konceptualnog i logičkog dizajna kod koje se putem standardiziranog intuitivnog koncepta omogućuje brz pristup podacima

♦

jednostavnim konceptualnim modelom opisuju se poslovni procesi preko dimenzija koje su hijerarhijski organizirane

♦

višedimenzionalni konceptualni pogled na podatke


116

Modeli podataka za skladište podataka Primjer Primjer: analiza pristupa na www.hr - katalog hrvatskih Web stranica Npr. pitanje: Koliko je bilo pristupa na web stranice u kategoriji Turizam i putovanja iz Sjeverne Amerike po mjesecima u 1998. godini? Dimenzije: ♦

Zemljopisno područje (Hrvatska ili kontinenti) gdje se nalazi računalo s kojeg se pristupa na web stranice kataloga

♦

Kategorija u kojoj se nalazi tražena stranica

♦

Vrijeme pristupa, tj. vremenska razdoblja unutar kojih je došlo do pristupa na www.hr stranice


117

Modeli podataka za skladište podataka Primjer V ri j em

e

Svaka kockica (tj. ćelija) unutar podatkovne kocke sadrži podatak o broju pristupa za određenu kombinaciju:

Z e m lj o p i s

Pristup na www.hr

♦ Kategorija na www.hr

- analiza pristupa na www.hr


♦ ♦

zemljopisnog područja odakle se pristupa kategorije na koju se pristupa vremenskog razdoblja unutar kojeg se pristupa na WWW.HR stranice

118

Modeli podataka za skladište podataka Primjer

• promjena orijentacije dimenzija (tzv. rotacija)

N

Prosinac 98. Studeni 98. Listopad 98. Rujan 98.

O V T U OS R TI SP IZA O M R K T U O LT H UR RV A A TS K O

J

Operacije tipične za OLAP alate:

• postupno kretanje po podatkovnim razinama (od sumarnih ka detaljnim i obrnuto)

HRVATSKA EUROPA SJEV. AMERIKA AUSTRALIJA AZIJA


119


N O V O EU ST I R O PA

V rij

(fact table)

1. 7. 1998.

Višedimenzionalni konceptualni pogled na podatke Oblikovanje skladišta podataka

em e

Tablica činjenica Z e m lj o p i s

EUROPA

22 N O V O S T I

1. 7. 98.

Kategorija na www.hr 120

Modeli podataka za skladište podataka Primjer Pristupi ( tablica činjenica )

Vrijeme ( dimenzijska tablica ) ključ_vrijeme dan_u_tjednu mjesec mjesec_opis tromjesečje godina ...

ključ_zemljopis ključ_vrijeme ključ_kategorija broj_pristupa

Zemljopis ( dimenzijska tablica ) ključ_zemljopis zemljopis_opis ...

Kategorija ( dimenzijska tablica ) ključ_kategorija kategorija_opis ...

Zvijezda spoj koji opisuje pristupe na WWW.HR stranice Oblikovanje skladišta podataka

121

Modeli podataka za skladište podataka Primjer ključ ključ_vrijeme (jedan stupac)

ključ ključ_kategorija (jedan stupac)

Kategorija Vrijeme

Zemljopis

Slož Složeni ključ ključ


ključ ključ_zemljopis (jedan stupac)

122



123



124

Modeli podataka za skladište podataka Dimenzijski model ♦

♦

♦

Vremenska dimenzija je gotovo uvijek nazočna u skladištu podataka, jer je zapravo svako skladište podataka vremenski niz. Da nema eksplicitne vremenske dimenzije, pri postavljanju upita mogla bi se postavljati ograničenja preko vremenskog ključa datumskog tipa u tablici činjenica i tako bismo mogli analizirati poslovanje po mjesecima i godinama. Međutim, ako želimo npr. u analizi suprotstaviti radne dane neradnim danima i praznicima ili analizirati po sezonama, tada nam treba eksplicitna dimenzija vremena.


125

Modeli podataka za skladište podataka Dimenzijski model Vremenska dimenzija može sadržavati atribute kao što su: datum dan u tjednu broj tjedna (npr. tjedan 12) mjesec tromjesečje indikator praznika radni dan / vikend specijalni događaj sezona ... Oblikovanje skladišta podataka

126

Modeli podataka za skladište podataka Dimenzijski model ♦

U dimenzijsku tablicu vremena često se na osnovnoj razini pohranjuju zapisi koji predstavljaju dane (tj. datume) i koji pokrivaju nekoliko proteklih i nekoliko idućih godina. Ako je potrebno pohranjivati podatke po satima, obično se u tim slučajevima stvara nova dimenzijska tablica za sate.

♦

Hijerarhija je vrlo važna u dimenzijskom modeliranju, budući da ona omogućuje dobivanje detaljnijeg ili sumarnijeg višedimenzijskog pogleda na podatke. Krajni korisnik će obično prvo promatrati sumarne podatke, a zatim će dio podataka gledati detaljnije.

♦

Dimenzija može paralelno imati više hijerarhija. Osim hijerarhije datum-mjesec-tromjesečje-godina, može se raditi sumiranje i po tjednima ili posebno definiranim sezonama.


127

Modeli podataka za skladište podataka Upiti Izvedba upita: ♦ ♦ ♦

U dimenzijskim tablicama se nađu sve vrijednosti ključa koje zadovoljavaju postavljena ograničenja. Od njih se spoje sve moguće kombinacije složenih ključeva koje će se tražiti u tablici činjenica. Svi nađeni podaci u tablici činjenica se zatim grupiraju i sumiraju prema specifikacijama korisnika.


128

Modeli podataka za skladište podataka Upiti SQL upit tipičan za skladište podataka: SELECT DT2.type, sum(FT.income) FROM orders FT, time DT1, product DT2, customer DT3 WHERE FT.timeKey = DT1.timeKey AND FT.productKey = DT2.productKey AND FT.customerKey = DT3.customerKey AND DT1.month = ’10-2005’ AND DT3.city = ’Zagreb’ GROUP BY DT2.type; ♦ ♦ ♦

Upit vraća sve tipove proizvoda naručene u listopadu 2005. godine iz Zagreba i pokazuje ukupnu zaradu za svaki tip proizvoda. U prva tri reda dijela definirano je spajanje tablice činjenica s dimenzijskim tablicama preko ključeva. U dijelu SELECT koriste se agregacijska funkcija SUM za sumiranje zarade za svaki tip proizvoda.


129

Modeli podataka za skladište podataka Pohranjivanje sumarnih (agregiranih) podataka ♦ ♦

♦

♦

Krajnji korisnik u svojim upitima češće traži sumarne podatke nego podatke na osnovnoj razini zrnatosti. Najjednostavniji oblik zvijezda spoja ima samo jednu tablicu činjenica i ta tablica sprema podatke na samo jednoj (osnovnoj) razini zrnatosti, a ne sadrži nikakve sumarne (agregirane) podatke. Osnovna razina zrnatosti, na kojoj su prilično detaljni podaci, može imati vrlo velik broj zapisa, pa izvlačenje podataka s te razine zrnatosti ne daje optimalnu kvalitetu rada. - Zbrajanje velikog broja podataka iz tablice činjenica osnovne razine će dugo trajati. U skladištu podataka se stoga podaci unaprijed spremaju na više razina zrnatosti.


130

Modeli podataka za skladište podataka Pohranjivanje sumarnih (agregiranih) podataka ♦

♦

♦

Agregirane činjenice, tj. činjenice koje su unaprijed sumirane i pohranjene, najčešće se dobivaju tako da se činjenice s osnovne razine zrnatosti zbrajaju, no činjenice se mogu i prebrojavati ili se može računati njihova minimalna, maksimalna ili srednja vrijednost i sl. Agregirane činjenice se najčešće spremaju u posebne tablice činjenica, odvojeno od podataka osnovne razine. Svaka agregacijska razina ima svoju tablicu činjenica. Pojedine agregacijske tablice se mogu staviti off-line i zatim opet on-line, a da to nema utjecaja na ostale podatke.


131

Modeli podataka za skladište podataka Pohranjivanje sumarnih (agregiranih) podataka Zemljopis Mjesec ključ_mjesec mjesec_opis tromjesečje godina

Pristupi_mj ključ_zemljopis ključ_mjesec ključ_kategorija broj_pristupa

ključ_zemljopis zemljopis_opis ...

Kategorija ključ_kategorija kategorija_opis ...

♦

♦

Umjesto dimenzijske tablice Vrijeme u shemu je uključena dimenzijska tablica Mjesec koja sadrži dio atributa tablice Vrijeme (uključeni samo atributi koji opisuju mjesece, tromjesečja i godine). Za dimenzijsku tablicu Mjesec treba odrediti primarni ključ.


132


♦

♦

Smanjene (izvedene) dimenzijske tablice su važne za brzinu pretraživanja pri upitima. Kad se upitom traže podaci za određeni dan u tjednu, pri izvedbi upita se vidi da u tablici Mjesec nema atributa dan_u_tjednu i tada se ide na tablicu Vrijeme koja taj atribut sadrži. U ovakvom pristupu, krajnji korisnik ne vidi agregacijske tablice činjenica, već samo tablicu činjenica na osnovnoj razini. Sve SQL naredbe se odnose samo na osnovnu tablicu činjenica i njoj pridruženim dimenzijskim tablicama.


133

Modeli podataka za skladište podataka Pohranjivanje sumarnih (agregiranih) podataka Upiti se izvode na sljedeći način: 1. Za svaku SQL naredbu nađe se najmanja tablica činjenica (tj. tablica s najmanjim brojem redaka) koja još nije ispitana, u skupu shema na koji se upit odnosi. 2. Ako se svi atributi koji su navedeni u SQL upitu mogu naći u toj tablici činjenica i pridruženim joj smanjenim dimenzijskim tablicama, tada se u originalnim SQL naredbama zamijene odredišna imena tablica stvarnim imenima tablica.

3.

Ako se bar jedan atribut iz SQL upita ne može naći u ispitivanim tablicama, traži sljedeća veća tablica činjenica. Ako upit nije riješen ranije, na kraju će se doći do osnovne tablice činjenica koja sigurno daje odgovor na upit.

Pokreću se promijenjene SQL naredbe.


134


♦

Agregacijska tablica može imati manje ključnih atributa od osnovne tablice činjenica, tj. može biti povezana s manje dimenzijskih tablica. Npr. ako sumiramo zaradu od prodaje svih proizvoda po trgovini i datumu: Proizvod Vrijeme Trgovina Agregacijska tablica


135


Primjeri agregacijskih tablica Prodaja po: kategoriji proizvoda, danu i trgovini proizvodu, mjesecu i gradu datumu i prodavaču tromjesečju i regiji ...


136


♦

Agregiranjem se uklanja potreba za ponavljanjem računanja koji bi se inače provodili svaki put kad se traži sumarna informacija i time se znatno ubrzava izvođenje upita. Međutim, agregiranje ima i svoje nedostatke: zauzima se prilično prostora na disku, kreiranjem novih tablica otežava se upravljanje skladištem, ako se agregiranje provodi svaki put kad se dodaju novi podaci u tablicu činjenica, bit će potrebno dosta vremena za učitavanje podataka u skladište. Treba obratiti pozornost na to koliko ima agregacijskih tablica i koliko je ukupno prostora na disku zauzeto agregatima.


137

Modeli podataka za skladište podataka Pohranjivanje sumarnih (agregiranih) podataka Kad se određuje koje će se agregacijske tablice napraviti, potrebno je razmotriti: za koje hijerarhijske razine po dimenzijama korisnik najviše postavlja upite, gdje se podaci koncentriraju, tj. za koje hijerarhijske elemente u dimenzijskoj tablici je prosječni broj redaka relativno velik, odnosno za koje hijerarhijske razine se sporo dobija odgovor. Ako neki element hijerarhije u dimenzijskoj tablici ima daleko više redaka nego drugi elementi u hijerarhiji, agregacija na razini tog elementa bi drastično popravila izvedbu.


138


♦

♦

Agregacijske tablice počnu se planirati već u ranim fazama oblikovanja na osnovu korisničkih zahtjeva za upitima. Ti se zahtjevi dokumentiraju, implementiraju i nadgledaju. Kad se skladište podataka da na korištenje, ispituje se na koji način su se najčešće obavljala grupiranja podataka (tj. koji su atributi najčešće bili u GROUP BY dijelu SQL naredbi). Dobivene informacije koriste se za kreiranje novih agregacijskih tablica (ili ukidanje postojećih). Dobar odabir agregacijskih tablica je jedan od ključnih faktora koji skladište podataka čine učinkovitim - korisnici mogu brzo dobiti odgovore na svoje upite.


139

Modeli podataka za skladište podataka Sporo promjenjive dimenzije Vrijednosti u dimenzijskim tablicama su prilično statične, no i one će se u određenim slučajevima mijenjati tijekom vremena. Primjeri: ♦ Kupac X je promijenio adresu. ♦ Promijenio se opis proizvoda A. ♦ Promijenila se zemljopisna podjela na regije. Skladište podataka treba ispravno pratiti promjene, a ujedno znati kakvo je stanje bilo u određenom trenutku. Dva su osnovna načina obrade promjena u dimenzijskim tablicama.


140

Modeli podataka za skladište podataka Sporo promjenjive dimenzije 1. način ♦

Stara vrijednost u dimenzijskoj tablici zamijeni se novom.

♦

Gubi se povijest promjena dimenzijskih vrijednosti. Ovaj način se koristi za ispravljanje pogrešaka pri punjenju dimenzijske tablice podacima. Može se koristiti i za dimenzije čija nas povijest ne zanima.

♦ ♦


141

Modeli podataka za skladište podataka Sporo promjenjive dimenzije 2. način ♦

Dodaje se novi redak (s novom vrijednošću primarnog ključa) u dimenzijsku tablicu.

♦

I stari i novi retci uz primarni ključ sadrže i stalni identifikator (“prirodni ključ”), za npr. identifikator određenog kupca koji je promijenio adresu ili identifikator određenog proizvoda kojem je promijenjen opis. Dimenzijska tablica može sadržavati sljedeće stupce: zastavicu za aktualni redak, vrijedi_od, vrijedi_do.

♦


142

Modeli podataka za skladište podataka Sporo promjenjive dimenzije Sifra (PK)

Mat_br

Naziv

Ulica

Kbr

Mjesto

Post_br

Vrijedi_ od

Vrijedi_ do

12311

123

AB

Teslina

3

Zagreb

10000

14.7. 1994.

23. 10. 2006.

12312

123

AB

Ilica

8

Zagreb

10000

24. 10. 2006.

Pri promjeni vrijednosti dimenzijskog atributa pronađemo u dimenzijskoj tablici trenutno važeći redak. Lociramo ga u ovom primjeru pomoću atributa Mat_br i zatim tražimo redak čiji atribut Vrijedi_do ima vrijednost NULL . Ažuriramo vrijednost Vrijedi_do i dodamo novi redak s novim primarnim ključem i novom vrijednošću atributa čiju promjenu pratimo. Oblikovanje skladišta podataka

143


Mat_br

Naziv

Ulica

Kbr

Mjesto

Post_br

Vrijedi_ od

Aktualno

12311

123

AB

Teslina

3

Zagreb

10000

14.7. 1994.

N

12312

123

AB

Ilica

8

Zagreb

10000

24. 10. 2006.

D

Umjesto stupca Vrijedi_do može se koristiti zastavica Aktualno s vrijednostima za DA i NE. Može se pamtiti i sva tri zapisa: Vrijedi_od, Vrijedi_do i Aktualno. Na taj način ubrzava se dohvaćanje podataka o vremenskom trajanju pojedine vrijednosti, odnosno nije potrebno dodatno pretraživanje po dimenziji da bismo pronašli prethodno važeći zapis u svrhu otkrivanja datuma do kojeg je određena vrijednost atributa važila. Kreiranjem indeksa nad stupcem Aktualno, ubrzano je lociranje trenutno važećeg zapisa. Oblikovanje skladišta podataka

144


Mat_br

Naziv

Ulica

Kbr

Mjesto

Post_br

Vrijedi_ od

Aktualno

12311

123

AB

Teslina

3

Zagreb

10000

14.7. 1994.

N

12312

123

AB

Ilica

8

Zagreb

10000

24. 10. 2006.

D

U tablici činjenica mogu se naći retci s vrijednošću odgovarajućeg atributa jednakoj 12311 za svaku kupnju do 14.7.1994. i retci s vrijednošću 12312 za kupnju nakon toga datuma. Ako u upitu tražimo da je naziv kupca jednak ‘AB’, obje vrijednosti šifre tog kupca (12311 i 12312) će se tražiti u tablici činjenica te će se dobiti odgovarajući skup rezultata. Oblikovanje skladišta podataka

145

Modeli podataka za skladište podataka Pretvorba ER dijagrama u zvjezdaste sheme ♦

Postupak pretvorbe normaliziranog modela podataka dobivenog ER modeliranjem u dimenzijski model (tj. skup zvjezdastih shema): 1. Razdvajanje ER dijagrama na pojedine poslovne procese ER dijagram, koji često sadrži sve poslovne procese nekog poduzeća, prevodi se u više dimenzijskih dijagrama. Zato je prvi korak u pretvorbi ER dijagrama u skup dimenzijskih dijagrama razdvajanje ER dijagrama na pojedine poslovne procese i modeliranje svakog od njih posebno.


146

Modeli podataka za skladište podataka Pretvorba ER dijagrama u zvjezdaste sheme 2. Odabir onih veza tipa više-premaviše koji sadrže brojčane i zbrojive atribute Od veza tipa više-prema-više koje sadrže brojčane i zbrojive atribute u ER dijagramu nastat će tablice činjenica.

TIP_ENT._1 1,N

veza1

1,M

TIP_ENT._2


147

Modeli podataka za skladište podataka Pretvorba ER dijagrama u zvjezdaste sheme

♦

Prema pravilima pretvorbe ER modela u relacijski model podataka, veze tipa više-prema-više iz ER modela uvijek rezultiraju relacijom tj. tablicom sa složenim ključem u relacijskom modelu podataka.

♦

Takve veze mogu se u ER dijagramu prikazati kao binarne, ternarne ili veze višeg stupnja u Chenovom prikazu ili se radi o asocijativnim entitetima u Martinovom prikazu.


148

Modeli podataka za skladište podataka Pretvorba ER dijagrama u zvjezdaste sheme ♦

Ako nema neključnih atributa u n-arnoj vezi tipa višeprema-više, odnosno odgovarajućem asocijativnom entitetu, tada će i dobivena relacija imati samo atribute koji čine složeni ključ.

♦

Tablica činjenica, međutim, uvijek ima neključne atribute koji su brojčani i po mogućnosti zbrojivi po svim dimenzijama.

♦

Pri pretvaranju ER dijagrama u dimenzijski model traže se veze tipa više-prema-više koje sadrže brojčane i zbrojive neključne atribute, te se od takvih veza dobijaju tablice činjenica.


149

Modeli podataka za skladište podataka Pretvorba ER dijagrama u zvjezdaste sheme 3. Denormalizacija svih ostalih tablica ♦ Denormaliziraju se sve ostale tablice u dimenzijske tablice s jednostavnim ključevima koji izravno povezuju te tablice s tablicama činjenica. Na taj način, pretvorbom n-arne veze tipa više-prema-više iz konceptualnog ER modela u implementacijski relacijski model dobija se shema zvijezda. Od n-arne veze nastaje zvjezdasta shema s jednom tablicom činjenica i n dimenzijskih tablica.


150

Modeli podataka za skladište podataka Različiti pristupi oblikovanju skladišta podataka ♦

Dva osnovna pristupa:

1. Inmon: U skladištu podataka prevladava normalizirani model podataka. Za pojedine teme, tj. grupe pitanja koje će krajnji korisnici često postavljati, kreiraju se manji dimenzijski modeli. 2. Kimball: Čitav model skladišta podataka se radi u dimenzijskom modelu. Pojedini dimenzijski modeli (zvijezde) povezani su zajedno inzistiranjem na uporabi zajedničkih tj. usklađenih dimenzijskih tablica. Oblikovanje skladišta podataka

151

Modeli podataka za skladište podataka Različiti pristupi oblikovanju skladišta podataka Pristup 1 – Inmon: ♦ U skladištu podataka prevladava normalizirani model podataka (obično u 3. normalnoj formi) koji se u većini slučajeva dobija postupkom ER oblikovanja. ♦ Kreira se i više manjih dimenzijskih modela za pojedine teme, tj. grupe pitanja koje će krajnji korisnici često postavljati, obično preko OLAP alata. Ti će dimenzijski modeli sadržavati sumarne podatke. ♦ Da se ne bi mijenjao normalizirani model, nekad se koriste pogledi (tj. samo logičke, a ne i fizičke definicije relacija), kojima se može pri postavljanju upita “sakriti” stvarna složenost modela. Oblikovanje skladišta podataka

152

Modeli podataka za skladište podataka Različiti pristupi oblikovanju skladišta podataka Pristup 2 – Kimball: ♦ Skup zvjezdastih shema, od kojih svaka opisuje jedan poslovni proces, povezuje se u model podataka čitavog skladišta podataka. ♦ Pojedine zvjezdaste sheme povezane su zajedno inzistiranjem na uporabi zajedničkih, odnosno usklađenih dimenzijskih tablica. Ako se dvije dimenzijske tablice koje bi trebale imati isto značenje nalaze u dvije zvijezde, to moraju biti potpuno iste dimenzijske tablice ili jedna mora biti podskup druge tablice (tj. projekcija). Usklađena dimenzijska tablica ima isto značenje bez obzira na koju je tablicu činjenica spojena. Oblikovanje skladišta podataka

153

Modeli podataka za skladište podataka Različiti pristupi oblikovanju skladišta podataka ♦

Kimball

♦

zajedničke (usklađene) dimenzijske tablice

Tablica činjenica 1 Oblikovanje skladišta podataka

Tablica činjenica 2 154

Strukturirani i polustrukturirani podaci


155

Strukturirani i polustrukturirani podaci ♦

Kod strukturiranih podataka shema je apriorna (najprije se definira shema, a potom se počinju unositi podaci koji odgovaraju shemi) i odvojena od podataka. Shemu se može nazvati određenom vrstom metapodataka (podataka o podacima). Za primjer se mogu uzeti relacijske baze podataka gdje se najprije zadaje relacijska shema, a zatim stvara relacija koja se može puniti podacima.

♦

Polustrukturirane podatke karakterizira barem jedno od sljedećih dvaju osnovnih obilježja: nepravilna struktura. implicitna struktura.


156

Strukturirani i polustrukturirani podaci Nepravilna struktura. ♦

Veliki skupovi podataka često se sastoje od manjih podatkovnih jedinica čija struktura je međusobno slična, ali ne i posve jednaka. U primjeru može se uočiti da Poe uz ime i prezime ima i srednje ime, a Jesenjin uz ime i prezime ima i očevo ime.

{autor: {prezime: "Poe"}, {ime: "Edgar"}, {srednje: "Allan"}} {autor: {prezime: "Gide"}, {ime: "Andre"}} {autor: {prezime: "Jesenjin"}, {ime: "Sergej"}, {očevo: "Aleksandrovič"}}


157

Strukturirani i polustrukturirani podaci

•

Implicitna struktura. Shema podatkovne strukture ne mora biti sadržana u posebnom dokumentu, nego integrirana zajedno s njihovim sadržajem.

Primjer:

{kompozitor: {prezime:"Verdi"}{ime="Giuseppe"} {djelo: {opera:"Traviata"}} {djelo: {opera:"Don Carlos"} } } •

Značenje riječi Verdi nije napisano u odvojenom vanjskom dokumentu nego je upravo uz sadržaj podataka (Verdi) navedeno i što oni predstavljaju (prezime).


158

Strukturirani i polustrukturirani podaci ♦

♦

Raznovrsnost podataka koji se opisuju polustrukturiranim formatom dovodi do nepravilne strukture, a time i kompliciranih shema. Kod polustrukturiranih podataka sheme su po količini memorije koju zauzima njihov zapis jednako velike, a najčešće i višestruko veće od samih podataka koje opisuju. Korištenje polustrukturiranog podatkovnog oblika naraslo je do ogromnih razmjera primjenom formata XML. XML je nastao uslijed potrebe da se sadržaj na Internetu stvara dinamički, na temelju razmjene podataka putem mreže.


159

XML – značaj i pohrana


160

eXtensible Markup Language

♦

XML je preporuka organizacije W3C (World Wide Web Consortium) osnovna namjena: razmjena podataka preko Interneta

♦

Dok HTML opisuje način prezentacije podataka, XML opisuje sadržaj.

♦

♦ ♦

XML podaci su polustrukturirani: ne moraju imati fiksnu shemu, dopuštene su varijacije u strukturi, informacije koje su u relacijskoj bazi vezane uz shemu ovdje se nalaze zajedno s podacima.


161

Struktura i sintaksa XML dokumenata

element tip elementa Mrs. sadržaj Ana elementa: Novak podelementi Ilica 54 Zagreb ... sadržaj elementa: znakovni podatak (string) Oblikovanje skladišta podataka

162

Struktura i sintaksa XML dokumenata

ime atributa vrijednost atributa Mrs. Ana ...


163

Dobro formiran i valjan XML dokument ♦

XML dokumenti mogu imati pridružene datoteke tipa Document Type Definition (DTD) ili XML Schema, koje opisuju strukturu dokumenata i postavljaju ograničenja nad podacima.

♦

XML dokument je dobro oblikovan ako zadovoljava pravila strukture i sintakse XML-a (npr. vrijednosti atributa moraju biti u navodnicima).

♦

XML dokument je valjan ako je dobro oblikovan i ima pridružen DTD ili XML Schemu te zadovoljava pravila koja su tamo definirana.


164

Document Type Definition (DTD)

♦

dio XML 1.0 specifikacije

♦

definira: koji elementi su na raspolaganju, slijed elemenata, kardinalnost pojavljivanja elemenata, dopuštene strukture ugnježđivanja elemenata, atribute koje pojedini element može imati, vrijednosti koje atribut može dobiti


165

XML Schema

♦

W3C preporuka – 2001.

♦

Napisana u XML-u

♦

Značajno proširuje mogućnosti DTD-a: podržava velik broj predefiniranih tipova podataka moguće definiranje novih tipova podataka kardinalnost se može preciznije definirati bolje riješeni ključevi i referenciranje


166

Integracija XML-a u skladište podataka

♦

Teme važne za integraciju XML-a u skladišta podataka: definiranje upitni

veza među podacima u DTD-u i XML Schemi

jezici za XML

pohrana

XML podataka


167

Veze u DTD-u i XML Schemi ♦

specificirane preko podelemenata purchaseOrder items shipTo

orderDate

billTo ?

name postCode

*

?

product

productCode key product Description

productName city country

?

item

state

street

+ ? comment

price ?

quantity currency

partNum keyref shipDate

?

? size weight

type

DTD graf / schema graf Oblikovanje skladišta podataka

168

Veze u DTD-u i XML Schemi Razlikujemo četiri tipa veza: -prema-jedan podelement ili atribut se pojavljuje točno jednom, neobavezna –prema-jedan (označena s ?) podelement ili atribut se pojavljuje jednom ili se uopće ne pojavljuje, -prema-više (označena s +) podelement se pojavljuje barem jednom, neobavezna –prema-više (označena s *) podelement se može pojaviti nula, jedan ili više puta. ♦

problem: samo jedan smjer veze se može pratiti

♦

Iako XML Schema omogućava precizniju specifikaciju strukture XML dokumenta nego DTD, kod specifikacije veza preko podelemenata DTD i XML Schema daju slična rješenja.


169

Veze u DTD-u i XML Schemi ♦

Specificirane preko ključeva i njihovih referenci

♦

ID/IDREF(S) mehanizam u DTD-u vrijednost IDREF atributa mora biti jednaka vrijednosti nekog ID atributa u dokumentu IDREFS atribut referencira više elemenata koji imaju ID atribute

Ograničenja: ID atribut je jedinstven (unique) unutar čitavog dokumenta Pri korištenju IDREF(S), za elemente koji sudjeluju ne može se specificirati da oni moraju pripadati određenom tipu elementa Elementi ne moraju imati ID, a čak i ako ga imaju, njegovo korištenje nije obavezno ID su uvijek unarni identifikatori (tj. ne mogu biti složeni) ID/IDREF(S) mehanizam je ograničen na vrijednosti atributa


170

Veze u DTD-u i XML Schemi ID/IDREF(S) mehanizam u DTD-u

♦

Primjer: analiza prometa na Webu Namjera: specificirati da svaki URL pripada u samo jednu kategoriju datoteka

♦

webTraffic ♦

+

*

fileCategory

click

host ? category

?

date

time

hostId

nation

fileCategoryId

url

+

site

fileCategoryDesc

ID

ID

urlId

ID ♦

urlCategory fileCategoryRef IDREF

Problem: fileCategoryRef može također poprimiti vrijednost koja odgovara nekoj od vrijednosti za hostId ili urlId


171

Veze u DTD-u i XML Schemi

key/keyref mehanizam u XML Schemi – bolji, fleksibilniji mehanizam od ID/IDREF

productName

. . .

. . .

item

product

price ?

quantity currency

... Oblikovanje skladišta podataka

partNum keyref shipDate

productCode key

product Description

?

? size

weight type

172

Veze u DTD-u i XML Schemi

DTD ID/IDREF(S)

XML Schema key/keyref

Složeni ključ

ne

da

Kad je ID/key specificiran, obavezan je

ne

da

Područje identifikacije elementa

cijeli dokument

identificiran XPath izrazom

sudionici

nije određen tip elementa/atributa

elementi/atributi određenog tipa

Ključ uvijek na istom mjestu u dokumentu

ne

ne

tip veze

Ne može se odrediti

-prema-jedan


173

Upitni jezici za XML Kao rezultat istraživanja u području polustrukturiranih podataka razvijeno je nekoliko upitnih jezika. Kad je XML postao široko prihvaćeni standard za polustrukturirane podatke, na temelju stečenih iskustava stvoreni su upitni jezici za XML.

♦

LOREL Razvijen na sveučilištu Stanford. Originalno namijenjen izvedbi upita nad polustrukturiranim podacima, kasnije i za XML. Da bi se jezik prilagodio XML-u, dodano je razlikovanje podelemenata i atributa, različite vrste usporedbi, sortiranje itd.


174

Upitni jezici za XML ♦

YATL Razvijen na institutu INRIA (Francuska). Originalno razvijen za polustrukturirane podatke, kasnije prilagođen za XML. Ima definiran skup funkcija za pristup, izgradnju i usporedbu dijelova XML dokumenata, a omogućava i definiciju novih funkcija.

♦

XML-QL Razvijen u AT&T Labs. Uključuje svojstva i mogućnosti više različitih upitnih jezika za polustrukturirane podatke i dodaje neke nove mehanizme.

♦

XML-GL Razvijen na Politecnico di Milano. XML dokument i DTD su prikazani grafički - jednostavan za korištenje.


175


♦

XSLT (eXtensible Stylesheet Language Transformations) Razvila ga je W3C organizacija. Čini dio jezika XSL-a kojim se specificiraju stilovi nekog XML dokumenta. Može se koristiti za definiranje načina pretvorbe jednog XML dokumenta u drugi. Najviše se, međutim, koristi za pretvorbu XML-a u HTML (čime se definira prezentacija XML dokumenta). Koristi XPath (W3C standard) za pristup određenim dijelovima XML dokumenta. XQL Razvile su ga tvrtke Texcel, webMethods i Microsoft. Proizašao iz obrade dokumenata, a ne iz područja polustrukturiranih podataka. Proširuje sintaksu XSLT-a - dodana je Boolova algebra, filteri, indeksiranje, itd.


176


Quilt

♦

Koristi svojstva nekoliko upitnih jezika (Lorel, YATL, XML-QL, XQL, itd.) Koristi XPath izraze za lociranje XML elemenata i atributa. W3C organizacija ga je prihvatila kao osnovu za razvoj jezika XQuery.

XQuery

W3C prijedlog za standardni upitni jezik za XML. Kao nasljednik jezika Quilt, naslijedio je svojstva nekoliko upitnih jezika. Još u razvoju, ali već ima potporu industrije.


177

Usporedba 4 upitna jezika za XML

LOREL

XML-QL

XQL

XQuery

grupiranje

da

da

da

da

restrukturiranje

da

da

ne

da

sortiranje

da

da

ne

da

spajanje

da

da

da

da

agregacije

da

ne

djelomično

da

promjena sadržaja

da

ne

ne

ne


178

Pohrana podataka u XML formatu

1.

Pohrana XML dokumenata u datotečni sustav

2.

Pohrana XML dokumenata u velike objekte (Large OBject – LOB) u objektno-relacijskim bazama

3.

Preslikavanje strukture XML podataka u relacijsku strukturu

4.

Korištenje izvorne (“native”) baze za pohranu XML podataka


179



180

Integracija XML-a u skladište podataka velike količine podataka zanimljivih za analizu i donošenje odluka nalaze se u XML formatu → potreba za integracijom XML podataka u skladišta podataka

♦

NASLIJEĐENI SUSTAVI

RDBMS

IZVLAČENJE, TRANSFORMACIJA I UČITAVANJE PODATAKA

SPREMANJE PODATAKA

UPITI, ANALIZA, IZVJEŠĆA, ISKOPAVANJE PODATAKA

VANJSKI PODACI

XML Oblikovanje skladišta podataka

181


♦

Razvijena je poluautomatizirana metodologija za oblikovanje skladišta podataka iz XML izvora (Zavod za telekomunikacije + profesor Stefano Rizzi, Italija)

♦

Cilj je u što većoj mjeri automatizirati postupak oblikovanja skladišta podataka iz XML izvora. Time se oblikovanje ubrzava, projektantu se olakšava posao, a smanjuje se i mogućnost pogrešaka.

♦

Neki koraci se ne mogu obaviti automatski jer uključuju razumijevanje semantičkih odnosa.

Problem: XML – polustrukturirani podaci → teško je dobiti sve tražene informacije


182

Oblikovanje skladišta podataka iz XML izvora Pri oblikovanju skladišta podataka bitno je poznavati tip veza među podacima. ♦

Postoje različiti načini specifikacije veza među podacima u DTD-u i XML Schemi:

♦

podelementi u DTD-u √ ID/IDREF(S) mehanizam u DTD-u podelementi u XML Schemi √ key/keyref u XML Schemi √

Budući da je mehanizam key/keyref u XML Schemi znatno precizniji od ID/IDREF(S) u DTD-u te zbog toga što je XML Schema sve rasprostranjenija, pri oblikovanju skladišta polazimo od XML Scheme.


183


XML Schema XML dokumenti

Konceptualno oblikovanje


Konceptualna shema

Logičko oblikovanje

Logička shema

CASE alat

184

Metodologija za oblikovanje skladišta iz XML-a ♦

Priprema za oblikovanje skladišta podataka

♦

Analiza Pohrana XML-a


Konceptualno oblikovanje Definiranje skupa najčešćih upita i procjena količine podataka Logičko oblikovanje Izvlačenje, transformacija i učitavanje podataka Fizičko oblikovanje


185

Funkcijska arhitektura (1. dio) – Priprema i konceptualno oblikovanje projektant XML DOKUMENTI

♦

Priprema: Analiza XML izvora Prikupljanje korisničkih zahtjeva Pohrana XML-a

♦

Oblikovanje skladišta: KONCEPTUALNO OBLIKOVANJE …

za

ht je vi

XML SCHEMA

korisnik

validacija

POHRANA XML-A

XQuery

konceptualno oblikovanje

KONCEPT. SHEMA


186

Analiza ♦

Prije početka oblikovanja skladišta podataka potrebno je:

Analizirati XML dokumente i predloške (XML Schema) prema kojima su ti dokumenti napravljeni, da bi se procijenila kvaliteta podataka, njihova semantika, odredio broj raspoloživih dokumenata itd.

Prikupiti i filtrirati korisničke zahtjeve kako bi se odredilo: koji će se izvori podataka koristiti što će se odabrati za činjenicu (Odabirom činjenice zapravo započinje oblikovanje skladišta podataka.)


187

Pohrana XML-a ♦

Nakon što su XML Schema i XML dokumenti prikupljeni, pohranjuju se lokalno te se provodi provjera valjanosti dokumenata – provjerava se je li XML dokument dobro oblikovan i je li usklađen s pravilima i ograničenjima opisanim u pripadajućoj XML Schemi.

♦

Pri oblikovanju skladišta, sustav za pohranu XML dokumenata treba moći:

pohranjivati čitave XML dokumente provjeravati valjanost dokumenata prema odgovarajućoj XML Schemi podržavati korištenje XQuery naredbi


188

Pohrana XML-a ♦

Zbog svoje opće namjene, već postojeće tehnike mapiranja u relacijsku bazu nisu prikladne za lokalnu pohranu XML-a pri oblikovanju skladišta podataka - zbog dvostruke pretvorbe (XML → relacijska baza, relacijska baza → skladište) povećao bi se rizik od gubitka informacije.

♦

Moguće izvedbe: izvorne XML baze podataka, datotečni sustavi, pohrana u velike objekte (LOB), ako se XQuery upiti mogu izvesti na jednostavan i učinkovit način.


189

Konceptualno oblikovanje ♦

Kao konceptualni model za skladište podataka koristimo dimenzijski činjenični model.

♦

Na temelju postojećih XML Schema i XML dokumenata, uzevši u obzir i korisničke zahtjeve, izrađuje se skup činjeničnih shema.

♦

Izrada svake činjenične sheme počinje odabirom činjenice.

♦

Počevši od odabrane činjenice prate se funkcijske ovisnosti definirane u XML Schemi te se tako u činjeničnu shemu dodaju novi atributi.


190

Funkcijska arhitektura (2. dio) - Definiranje skupa najčešćih upita i procjena količine podataka projektant

korisnik

htj za

i ev

upiti

POHRANA XML-A

XQuery

konceptualno oblikovanje ry ue XQ

provjera konceptualne sheme korištenjem tih upita

definiranje upita, količina pod.

KONCEPT: SHEMA

validacija


detaljno formuliranje skupa najčešćih i najzanimljivijih upita

XQuery se koristi da bi se ispitali izvori podataka u XML-u i utvrdila količina podataka

UPITI, KOLIČINA POD.

191

Logičko oblikovanje ♦

Činjenična shema, kao konceptualna shema, može se implementirati: u relacijskoj bazi podataka kao shema zvijezda ili slična struktura (tzv. ROLAP rješenje) u posebnoj strukturi koja se naziva višedimenzionalna baza podataka (tzv. MOLAP rješenje)

♦

Koristit ćemo ROLAP rješenje jer su relacijske baze standardizirane, imaju veći kapacitet i pružaju veću fleksibilnost kod rješavanja zahtjevnijih problema oblikovanja nego MOLAP sustavi.


192

Funkcijska arhitektura (3. dio) – Logičko oblikovanje projektant

KONCEPTUALNA SHEMA

♦

SQL DDL (Data Definition Language) naredbama se na temelju dobivene logičke sheme (zvijezda ili slične sheme) generiraju dimenzijske tablice i tablica činjenica u relacijskoj bazi podataka.

♦

Potrebno je definirati preslikavanje svakog tipa podatka u XML Schemi u odgovarajući tip podatka u relacijskoj bazi podataka.

validacija UPITI, KOLIČINA POD. logičko oblikovanje SQL-DDL

LOGIČKA SHEMA


193

ETL oblikovanje ETL (Extraction, Transformation, Loading) ♦

Nakon kreiranja dimenzijskih tablica i tablice činjenica, te se tablice pune podacima iz XML dokumenata korištenjem XQuery upita.

♦

Nakon prvog učitavanja, dodatni podaci se učitavaju u skladište podataka periodički.

♦

Mora se osigurati pravilna pretvorba formata podataka u slučajevima kad tip podatka u XML-u ne odgovara tipu podatka u relacijskoj bazi podataka.


194

Fizičko oblikovanje ♦ ♦

♦

Fizičko oblikovanje odnosi se prvenstveno na odabir indeksa, što ima važnu ulogu u optimizaciji performansi skladišta podataka. Cilj: što brže izvođenje upita. Kod skladišta podataka tipični upiti zahtijevaju spajanje tablice činjenica s nekoliko dimenzijskih tablica. Postupak je sljedeći: U dimenzijskim tablicama se nađu sve vrijednosti ključa koje zadovoljavaju postavljena ograničenja. Od tih vrijednosti se naprave kombinacije složenih ključeva koje će se zatim tražiti u tablici činjenica. Svi nađeni podaci u tablici činjenica se zatim grupiraju i sumiraju prema specifikacijama korisnika.


195

Konceptualno oblikovanje skladišta podataka iz XML izvora


196

Konceptualno oblikovanje ♦

Na temelju relevantnih XML Schema i XML dokumenata na poluautomatizirani način se stvara konceptualna višedimenzijska shema u skladu s dimenzijskim činjeničnim modelom.

♦

Osnovni zadatak pri konceptualnom oblikovanju skladišta je identifikacija funkcijskih ovisnosti.

♦

Problem: u XML Schemi je kardinalnost veze opisana samo u smjeru od nadređenog elementa prema podelementu. U slučajevima kada je potrebno ispitati kardinalnost veze u suprotnom smjeru (od podelementa prema nadređenom elementu), potrebno je postaviti odgovarajuće upite nad XML dokumentima korištenjem jezika XQuery ili tražiti od projektanta da procijeni o kakvom se tipu veze radi.


197

Algoritam za konceptualno oblikovanje ♦

Konceptualno oblikovanje se izvodi tako da se za određenu XML Schemu prvo napravi graf sheme, a zatim se, prateći funkcijske ovisnosti u XML Schemi, izgrađuje činjenična shema.

♦

Algoritam - koraci:

1. Pojednostavnjenje XML Scheme. 2. Izrada grafa sheme. 3. Odabir činjenice. 4. Za svaku činjenicu: 4.1 Izgradnja grafa ovisnosti iz grafa sheme 4.2 Preuređenje grafa ovisnosti 4.3 Određivanje dimenzija i mjera 4.4 Konačno definiranje činjenične sheme Oblikovanje skladišta podataka

198


Prva dva koraka, pojednostavnjenje XML Scheme i izrada grafa sheme, potpuno su automatizirani u prototipu alata za oblikovanje skladišta podataka iz XML izvora.

♦

Na temelju korisničkih zahtjeva i dobivenog grafa sheme projektant skladišta odabire činjenicu, tj. središnju točku interesa korisnika skladišta podataka (korak 3).

♦

Za odabranu činjenicu, na poluautomatizirani način se izgrađuje graf ovisnosti (korak 4.1). Graf ovisnosti je privremena struktura koja predstavlja osnovu za buduću činjeničnu shemu. Novi čvorovi dodaju se u graf ovisnosti prateći funkcijske ovisnosti u grafu sheme. Čvorovi grafa ovisnosti su podskup čvorova elemenata i atributa u grafu sheme. Činjenica je korijenski čvor grafa ovisnosti, a ostali čvorovi su kandidati za mjere te dimenzijske i opisne atribute u budućoj činjeničnoj shemi.


199


Nakon završetka njegove izgradnje, graf ovisnosti se može preurediti (korak 4.2). U grafu ovisnosti mogu se nalaziti čvorovi koji su nezanimljivi ili su previše detaljni za višedimenzijsku analizu te ih projektant skladišta može ukloniti. Također, u graf ovisnosti mogu biti dodani i potpuno novi čvorovi. Na primjer, uz postojeću prodajnu cijenu proizvoda i prodanu količinu, korisno je dodati i čvor koji opisuje ukupni prihod od prodaje tog proizvoda (umnožak cijene i količine).

♦

Slijedi određivanje mjera, dimenzija i hijerarhijskih razina (korak 4.3), nakon čega je jednostavno pretvoriti graf ovisnosti u činjeničnu shemu (korak 4.4).


200

Izrada grafa sheme

Primjer: narudžbe

globalni elementi purchaseOrder i comment Graf sheme sadrži i operatore kardinalnosti (npr. element item je pridružen elementu items s kardinalnošću -prema-više).


201

Izrada grafa sheme Primjer: prodaja


elementi i atributi koji predstavljaju primarni ključ imaju oznaku PK (customerId, productID), a koji oni predstavljaju strani ključ oznaku FK (productRef, customerRef).

202

Odabir činjenice

♦

Odabir činjenice predstavlja ključni korak konceptualnog oblikovanja skladišta podataka. Ne može se izvesti automatski, već ovisi o projektantovom razumijevanju semantike u XML Schemi, kao i o korisnikovom središtu interesa u procesu donošenja odluka.

♦

Činjenica je korijen grafa koji predstavlja činjeničnu shemu. Da bi se dobila činjenična shema koja ima smisla, od izuzetne je važnosti da projektant pravilno odabere činjenicu.


203

Odabir činjenice ♦

Kad bi se konceptualno oblikovanje skladišta radilo na temelju dijagrama entiteti-veze kao izvora podataka, za činjenicu bi se moglo odabrati: vezu više-prema-više ili entitet koji prema drugim entitetima ima vezu -prema-jedan, dok oni prema njemu imaju vezu -prema-više (budući da se veza tipa više-prema-više može pretvoriti u takav novi entitet).

♦

U višedimenzijskom konceptualnom modelu činjenica tvori vezu -prema-jedan sa svakom od dimenzija, dok one s njom tvore vezu -prema-više.


204


Kod konceptualnog oblikovanja skladišta iz XML izvora, programski sustav nudi projektantu skladišta za činjenicu: sve čvorove u grafu (sve atribute i sve elemente) osim tzv. kontejnera, sve veze među čvorovima.

♦

Kontejner je čvor koji ima samo jedan podelement složenog tipa; nema atributa ni podelemenata jednostavnog tipa, a kardinalnost veze od kontejnera prema podelementu je –prema-više. Kontejner nema vlastiti semantički sadržaj, u njega se ne pohranjuje nikakva podatkovna vrijednost. Osim informacije da sadrži druge elemente, ne nosi nikakvu dodatnu informaciju. Zbog toga se kontejner ne može odabrati za činjenicu, niti uključiti u dimenzijsku hijerarhiju.

♦


205


♦

♦

Programski alat pretvara sve veze u grafu sheme u dodatne čvorove grafa i nudi ih projektantu, zajedno s čvorovima koji predstavljaju elemente i atribute, kao moguće činjenice. Veza između narudžbe (purchaseOrder) i naručenog proizvoda (item) je -prema više. U suprotnom smjeru kardinalnost nije prikazana, ali budući da se jedan proizvod može naći na više narudžbi, radi se o vezi višeprema-više. Ta veza se bira za činjenicu.


206


Graf sheme za primjer prodaje

salesData

+

+

invoice

+

customer

product

invoiceNum orderDate

+

shipDate shipMethod

customerID key lineItem

quantity

price

?

postCode

customerRef keyref

city

name

productID key

address

?

size color prodName

FACT ♦

productRef keyref

čvor koji predstavlja element lineItem (tj. stavka računa) je odabran za činjenicu


207

Izgradnja grafa ovisnosti

♦

Graf ovisnosti za primjer prodaje

invoiceNum

shipMethod

orderDate

invoice customerRef

name address

city postCode

shipDate ♦

Počevši od činjenice, prateći funkcijske ovisnosti u grafu sheme, dodaju se čvorovi u graf ovisnost

price

productRef

productName color Oblikovanje skladišta podataka

quantity

lineItem

size 208


Graf ovisnosti se proširuje tako da se: prate funkcijske ovisnosti “prema dolje” (prema čvorovima koji su “nasljednici” činjenice), prate funkcijske ovisnosti “prema gore” (prema čvorovima koji su “preci” činjenice), prati mehanizam key/keyref. U slučaju da je za činjenicu izabrana veza dvaju čvorova, u graf ovisnosti najprije se dodaju dva čvora koje ta veza povezuje u grafu sheme.


209

Izgradnja grafa ovisnosti purchaseOrder

smjer “dolje”

+

? shipTo

orderDate

billTo ?

name

...

? state

product

productCode key product Description

street postCode

comment

*

city

shipTo i billTo su instance istog složenog tipa (Address) Oblikovanje skladišta podataka

country

?

? size weight

type

zbog veze -prema-više product ne ulazi u graf ovisnosti

... 210

Izgradnja grafa ovisnosti purchaseOrder

praćenje key/keyref ...

...

orderDate

*

+ ? comment ?

product ?

item

?

size productCode weight key product type Description

key productCode product Description

partNum ? keyref productName quantity price shipDate

?

?

size weight

type

currency

productCode ?

? product Description

type

size weight

transformacija primarnog ključa: čvor koji je ključ (productCode) dolazi na mjesto čvora složenog elementa (product) budući da productCode funkcijski određuje podelemente čvora product (slično prirodnom spajanju u relacijskoj bazi)


211


productName

quantity ♦

...

price

FACT

currency

item partNum product Description

size

weight

comment

Potomci primarnog ključa (productCode) ulaze u graf ovisnosti kao potomci stranog ključa (partNum).

shipDate

type

Graf ovisnosti – praćenje mehanizma key/keyref


212

Izgradnja grafa ovisnosti Smjer “gore”

♦

U ovom smjeru XML Schema ne definira kardinalnost veze pa se ona mora pokušati saznati ispitivanjem sadržaja XML dokumenta.

♦

Nadređeni element u grafu sheme će se u grafu ovisnosti nadovezati na postojeći čvor samo ako je o njemu funkcijski ovisan, odnosno ako je veza od postojećeg čvora prema nadređenom čvoru kardinalnosti -prema-jedan.

♦

Izvode se upiti nad XML dokumentima koji imaju odgovarajuću XML Schemu korištenjem jezika XQuery.


213

Izgradnja grafa ovisnosti Ispitivanje veze prema nadređenom čvoru ♦

Ispituje se da li se za isti sadržaj podređenog elementa u XML dokumentima razlikuju sadržaji nadređenih elemenata.

Ako se razlikuju, veza je tipa -prema-više, a nadređeni čvor se ne uključuje u graf ovisnosti.

Ako se ne razlikuju, to još uvijek ne znači da se ne mogu načiniti dokumenti na temelju čijeg sadržaja bi se ustanovilo da je veza tipa -prema-više te u ovom slučaju projektant mora dati procjenu kardinalnosti veze, odnosno odlučiti hoće li nadređeni čvor ući u graf ovisnosti.


214


♦

Graf ovisnosti za primjer narudžbi orderDate

productName

name street shipTo postCode

Address

quantity currency

purchaseOrder-item purchaseOrder

price item

FACT

partNum

billTo

shipDate

comment

city

comment

productDescription country

state

size

weight

type


215

Preuređenje grafa ovisnosti Projektant može preurediti neke dijelove grafa ovisnosti, ukloniti nezanimljive ili previše detaljne čvorove, a može i dodati nove čvorove ako su zanimljivi za analizu i za njih se mogu dobiti vrijednosti podataka. Preuređenja grafa ovisnosti za primjer narudžbi: ♦ ♦ ♦ ♦ ♦ ♦ ♦

čvorovi item i partNum → samo partNum ostaje purchaseOrder-item i purchaseOrder → samo purchaseOrder ostaje comment i shipDate se izbacuju jer nisu zanimljivi za analizu sve cijene su prebačene u istu valutu te se ukida čvor currency quantity i price postaju “djeca” činjenice da bi se kasnije mogli definirati kao mjere prepoznata je funkcijska ovisnost city→country Address je preimenovan u customer da bi se bolje objasnila uloga čvora


216

Preuređenje grafa ovisnosti

Preuređeni graf ovisnosti za narudžbe:

street

quantity

name shipTo

postCode city country

customer billTo

productName price

purchaseOrder product Description orderDate size

partNum

weight

type

state


217

Određivanje dimenzija i mjera ♦ ♦

Nakon što je projektant skladišta preuredio graf ovisnosti, moguće je odrediti mjere i dimenzije te definirati hijerarhijske razine. Programski sustav ne dozvoljava da se započne s određivanjem mjera i činjenica prije nego su svi čvorovi bez sadržaja uklonjeni iz grafa ovisnosti. Dimenzijom ili mjerom može postati samo čvor čiji roditelj je činjenica. Čvor koji treba postati mjera ne smije imati niti jedan potčvor.

U primjeru narudžbi: dimenzije: orderDate, product, shipToCustomer, billToCustomer ♦ mjere: uz price i quantity definira se i income (zarada kao umnožak cijene i količine) ♦ hijerarhijske razine: uz postojeće hijerarhije, vremenska dimenzija (razina datuma) se obogaćuje hijerarhijskom razinom mjeseca (month) te atributima dayOfWeek i holiday ♦


218

Konačno definiranje činjenične sheme Činjenična shema za narudžbe

street

name shipTo

postCode

quantity price income

customer

partNum

product Description

billTo

city country

productName

PURCHASE ORDER

orderDate state

dayOfWeek

size

weight

type

holiday

month


219

Logičko oblikovanje skladišta podataka iz XML izvora


220

Logičko oblikovanje ♦

Logičko oblikovanje kreće od dobivene činjenične sheme, uzevši u obzir i definirani skup najčešćih upita te procijenjenu količinu podataka.

♦

U pravilu se svaka činjenična shema s n dimenzija preslikava u jednu tablicu činjenica i n dimenzijskih tablica u relacijskoj bazi podataka.

♦

Postoje i specijalni slučajevi kao što su: konvergencija i dijeljena hijerarhija (primjer narudžbi) veza više-prema-više (primjer prodaje knjiga). U ovim slučajevima kao rezultat logičkog oblikovanja ne dobiva se klasična shema zvijezda.


221

Logičko oblikovanje TIME timeKey

♦

dijeljena hijerarhija KORISNIK (customer) je predstavljena samo jednom dimenzijskom tablicom

orderDate dateKey

PURCHASE_ORDER

CUSTOMER

dayOfWeek

customerID shipToCustomerKey

customerKey

holiday

billToCustomerKey

customer

month

orderDateKey

name

productKey

street

PRODUCT

price

productKey partNum productName

postCode

quantity

city

income

state country

productDescription size weight type


♦

u činjeničnoj tablici se stvara onoliko stranih ključeva koliko ima instanci u dijeljenoj hijerarhiji 222

Oblikovanje skladišta iz XML izvora zaključak ♦

poluautomatizirana metodologija za oblikovanje skladišta iz XML izvora

♦

kad se skladište ne radi izravno iz XML izvora, već se podaci prvo prebacuju iz XML formata u relacijsku bazu, postoji opasnost od gubitka informacija

♦

algoritam za konceptualno oblikovanje najveći izazov - zbog polustrukturirane prirode XML podataka

♦

kod konceptualnog oblikovanje prvo se na temelju XML Scheme izradi graf sheme, a zatim se prate funkcijske ovisnosti predstavljene u XML Schemi podelementima i mehanizmom key/keyref

♦

prototip alata pomaže projektantu u izradi konceptualne i logičke sheme i omogućuje nadzor različitih faza oblikovanja preko grafičkog sučelja

♦

osim korištenja XML Scheme, može biti potrebno ispitivati XML dokumente ili tražiti pomoć projektanta


223


ZAKLJUČAK


224

Oblikovanje skladišta podataka - zaključak ♦

Sustav skladištenja odvojen je od transakcijskih sustava.

♦

Podaci iz različitih izvora integriraju se u skladištu podataka, pri čemu trebaju biti odstranjene nekonzistentnosti i anomalije među podacima.

♦

Izgradnja sustava: dugoročno planiranje razvoja čitavog sustava ispravna metodologija implementacija - dio po dio, u malim koracima i na iterativan način, sa što učestalijim povratnim informacijama od krajnjeg korisnika ⇒ dijelovi sustava mogu se relativno brzo dati na korištenje, a sustav čini kompaktnu cjelinu i odgovara potrebama krajnjih korisnika


225

OSP

Recommend Documents