POSLOVNA INTELIGENCIJA

DOC.DR Jasmin Azemović

Predavanje 1

Potreba za poslovnom inteligencijom

Ako već postoje OLTP baze iz kojih efikasno izvlačimo podatke, zašto bi tražili BI rješenje za
istu namjenu ?

Aplikacija pored toga što služi da sistem puni podacima, služi i za izvlačenje povratne
informacije na osnovu toga šta se nalazi u tim podacima.

Problem je što se prikupljaju se ogromne količine podataka.

BI priča se odnosi na velike kompanije, enterprise class business, a vrlo je rijetko da postoji
potreba na malim bazama.

Adekvatna analiza pomaže u donošenju poslovnih odluka.

Ako ne u real-time, onda u drugim vremenskim intervalima bi trebalo biti omogućeno dobiti
izvještaje i uvide u poslovanje, na osnovu kojih se donose poslovne odluke.

Moderna ekonomije nije zamisliva bez poslovne inteligencije (Prodaja, marketing,

planiranje...)

Poslovna inteligencija postaje integralna komponenta novih i postojećih softverskih rješenja

Obuhvata širok i različit spektar uloga

-Implementatora

-Korisnika

Problem sa klasičnim sistemima

Poslovni podaci su rašireni kroz različita heterogena okruženja pa je pronalaženje informacija

vremenski zahtjevno i podložno greškama.

Kao primjer ovog možemo navesti neku firmu koja je stara više desetina godina, a koja nema
up to date softver, ne posjeduju najnovije softvere, a jednom BI analitičaru trebaju
informacije iz svih tih sistema, iz svih tih okruženja, da bi mogao na osnovu svih informacija
vršiti neke korisne analize.
Izvlačenje informacija može potrajati.

Većina baza podataka je dizajnirana kao OLTP

-Optimizovane za INSERT/UPDATE i DELETE operacije

-Nisu optimizovane za izvještavanje i analize

Ovakve baze, gdje su podaci rašireni kroz različita heterogena okruženja, baš i nisu pogodne
za izvještavanje i analizu, dok su pogodne npr za SELECT, izvlačenje podataka.

Analize su uglavnom agregacije na velikim količinama podataka

(SUM,MAX,MIN,AVERAGE,COUNT...)

Recimo, agregacija na terabajtnoj tabeli je spora, a i zahtjevni upiti vode ka usporenjima, pa

sam relacioni model nije pogodan za analize i izvještavanje.

Agregacije na velikim količinama podatka su spore, a relacioni model nije blizak poslovnim
korisnicima

U BI svijetu radi se sa velikim količinama podataka, milionima zapisa, a zastrašujuća je

činjenica da se sve tabele sa zapisima inkrementalno pune.

Uvijek putem ETL procesa dolaze novi svježi podaci za neke buduće poslovne analize, zbog
toga, klasičan SELECT je u redu, ali SELECT koji nešto analizira nije.

Ahilova peta u BI svijetu je integracija različitih legacy okruženja.

Cloud na sebe uzima veliki teret, jer treba da hostira naše podatke.

Data science-budućnost u razvoju poslovne inteligencije, gdje se sada pojavljuju timovi ljudi
koji koriste naučne metode npr. Machine learning, vision, data mining, vještačka
inteligencija, te pokušavaju iskoristiti veliku količinu informacija za AI ili druge inteligentne
sisteme.

U velikim BI projektima javlja se puno rola, timovi sa više ljudi od kojih se za svakog zna koju
funkciju obavlja.

Project Manager-rukovodi cijelom pričom, poznaje IT, tako da može da prati sve i koordinira.

Solution Architect-projektuju cijeli BI sistem, prave nacrt onoga šta se pravi.

Data Modeler-modeliraju iz postojećih sistema baze,podatke, modele, prilagođavaju

postojećim ili prave nove data i/ili poslovne modele koji će se kasnije napuniti podacima u
cilju analiza.

Database Administrator-osiguravaju da sistem radi, da je up time itd.

ETL Developer- brinu se da su sistemi koji su kreirani napune podacima iz heterogenih

okruženja
Business Users i ostali su oni koji konzumiraju BI riješenja.

Rješenja za BI i alati

Svaki IT vendor posjeduje svoje rješenje pa je teško odabrati pravo BI riješenje, a ta BI

riješenja uglavnom nisu ista, mada rade istu stvar, ali npr. terminologija, implementacije se
razlikuju.

Uglavnom se radi o sistemima koja su kompaktibilna sa drugim okruženjima

Potrebne stvari: database engine,integration services, master data services, data quality
services, analysis services, reporting services

Predavanje 2

Skladišta podataka I

Šta je skladište podataka ?

Skladište podataka je centralizovano mjesto svih poslovnih podataka u cilju izvještavanja i

različitih poslovnih analiza.

Skupljamo sve podatke iz svih data source-ova koji se nalaze u našoj korporaciji,
infrastrukturi.Skupljamo ih sve na jednu lokaciju i iz te lokacija radimo poslovne analize.Jak
obi teško bilo da radimo jedan report npr. na više heterogenih okruženja.

Svojstva jednog skladišta:

-Velike količine „historijskih“ zapisa

Npr. podaci o prodaji, pacijentima u bolnici itd., konkretno historijski zapis kompletnog
posla, od početka.To bi trebali da budu read-only podaci, jer taj record oslikava stanje koji je
bio u nekom specifičnom vremenu, neki datum, pa bi bilo koja izmjena bila pogrešna i dovela
bi do polaznih osnova u nekoj analizi.

-Optimizovana za upite, a ne dodavanje i ažuriranje podataka

Tabele su uglavnom puno veće, dešava se redudancija, jer se podaci slijevaju iz više lokacija i
samim tim ovo se pravi za analizu, agregaciju a ne za dodavanje.

-Dopunjava se inkrementno sa novim poslovnim podacima u regularnim intervalima

Npr svaku noć, svakih sedam dana, ovisno kako se definiše.

-Predstavlja osnovu za BI rješenja

Bilo koja BI priča može da radi ali gubi smisamo bez pravih skladišta ili lokacija
Arhitektura skladišta podataka:

Central data warehouse

Jedna valika baza, jedan veliki DW gdje se slijevaju podaci sa svih lokacija.Svi branchevi se
„kače“ svojim BI alatima i uzimaju podatke sa jednog DW-a.Jednostavnije je za održavanje,
jeftinije itd., ali na nekim mjestima ovo gubi smisao.

Npr., imamo 10 departmenta, i bez obzira da li neki department, recimo „Human Resources“
ne želi vidjeti podatke iz department-a analize, mora proći kroz šumu svih podataka.Upravo
zbog toga dolazi departmental data marts.

Departmental data marts

Za data marts se može reći da je skladište, ali manjih proporcija.Svaki department ima svoj
nezavisni data warehouse, za poslovne akcije, za analizu itd.

Hub and spoke

Imamo centralni warehouse, imamo male hub-ove odnosno data marts koji su konstantno u
sync-u sa centralom.

Kako se podaci slijevaju u veliki DW onda se oni proslijeđuju u branchove, ili obratno.Ovaj
način je najefikasniji i najbolji, ali i najskuplji.

Komponente projekta baziranog na skladištu podataka:

Cijela poenta je da se podaci iz heterogenih okruženja preliju u jedan DW.

Jako je važan master data management.To je framework, pravila, policy koji na jedinstven
način definiše pravila za sve (kodne stranice, format, datum, kako se riješavaju referentne
lookup tabele).Sve se prije definiše, jer ako se to ne riješi u ovoj fazi, onda ćemo u fazi data
cleaning morati uraditi jako puno posla oko formatiranja i ostalog.

ETL je uvlačenje i prečišćavanje podataka prije nego što se napuni DW

It DW-a se uzimaju konkretni podaci i prave odgovarajući modeli (multidimenzionalni,

tabularni itd.) i onda se „kačimo“ report-om na te modele i radimo neke analize.
Baze podataka i pohrana

Promjena izvorne šeme baze podataka u procesu koji se naziva denormalizacija

Važno je da se izvorna OLTP šema denormalizuje, i na osnovu toga se kreira data warehouse,
odnosno jedan poslovni proces koji smo razbili na nekoliko tabela, denormalizuje, i pravimo
data warehouse koji sada odgovara nečem drugom osim insert, update i delete.

DW baze podataka se nalaze na klasičnom serveru baze podataka

Pitanje hardvera je jako važno.Potrebno je tačno izračunati specifikacije i ono šta nam treba
od hardvera.

HA-High availability

DR-Disaster recovery

HA i DR služe kao podrška kontinuiranom poslovanju

Ako stane sa radom baza za DW onda staje i poslovna analiza, BI, moguće je da se pojave
anomalije u odlukama koje trebaju biti ključne u nekim poslovnim procesima.

Sigurnost je faktor koji nije zanemariv.Mi povlačimo historijske zapise sa mnogo lokacija.U
tim podacima su lični podaci i ostali osjetljivi podaci i potrebno je prvo provjeriti da li
smijemo povlačiti te podatke, šta smijemo sa podacima itd.

Potrebno je obratiti pažnju na tip indeksa, jer indeks ubrzava pretragu.

Columnstore Indeks

Row-based indeks

-Može biti clustered i non-clustered

-Poboljšava performanse na row level upitima, insert,update i delete operacijama

Logično je da svaki insert,update i delete zahtijeva i da se indeks promijeni, iz tih razloga se

baza razbije na puno više manjih tabela te tako ažuriranje traje kraće.

-Najbolje koristiti u OLTP bazama

-Procesiraju se svi podaci u zapisu

Row-based indeks se može koristiti i u data warehouse.

Column-based indeks

Može biti clustered i non-clustered

Ovi indeksi su uglavnom memory based u cilju rapidnog ubrzanja performansi, analize i
agregacija.
Poboljšava performanse na upitima koji rade scan tabele, agregacije i analitičke operacije
(row-based indeksi su ovdje jako neefikasni)

Najbolje koristiti u DW bazama

Procesiraju se samo potrebne kolone(row-based procesiraju sve podatke u zapisu)

Clustered columnstore indeks se može kombinovati sa klasičnim non-clustered indeksima

Izvori podataka

Tehnologije i tipovi konekcija prema izvorima podataka

Ovdje se govori o tome koji su nam libraries ili provajderi potrebni da bi izvukli podatke iz
jednog starog formata.

-ODBC,ADO.NET,JDBC

Potrebne dozvole i prava pristupa

Da li postoji neka autorizacija, autentifikacija.Security je jako važan.Pitanje je da li nam

podaci putuju u clear text-u ili ih kriptujemo jer ne znamo da li neko sa druge strane „sluša“ i
želi dohvatiti naše podatke

Format podataka

-Tipovi,konverzije, kodne stranice

Sve se ovo mora riješiti prije ETL faze

Vremenski okviri i ograničenja prilikom pristupa

-Misli se na okvire kada je najbolje da se podaci uzimaju ponovo i inkrementalno puni DW u

ETL fazi

-Posebno važno u heterogenim

ETL proces

Staging

Staging je međufaza.

Nekada nije moguće prebaciti podatke direktno sa jedne na drugu lokaciju pa se prave
međulokacije, podaci se po potrebi formatiraju, čiste i prebacuju u clean obliku u jedan
warehouse.

-Nekada i nije moguće direktno prebaciti podatke iz OLTP i DW

-Rad u fazama

-Odluka u formatu
Nekada su potrebni i staging serveri

Transformacije

-Tokom ekstrakcije ili prebacivanja(data flow)

Kad uzimamo podatke, recimo SELECT komandom, radimo funkciju CONVERT nad kolonom
DATE.Ta operacija će opteretiti server.Ako nećemo da opteretimo neki server, onda
uzimamo podatke, ne radimo transformaciju u ekstrakciji nego „u letu“ kada podaci putuju u
neki stage, u neku drugu lokaciju, a ne lokaciju servera.

Inkrementali ETL

-Prepoznavanje izmjena u podacima koje zahtijevaju ekstrakciju

-Istovremeno punjenje tokom insert i/ili update operacije

Data Quality i Master Data Management

Obično to se uradi efikasno, manje ili nikako.Iz tig razloga postoji data quality koji
omogućava da se podaci pročiste, validiraju, da se uradi de-duplikacija itd.

Kvalitet podatka

Čišćenje podataka

-Validacija vrijednosti

-Osiguranje konzistentnosti

-Identificiranje nedostajućih vrijednosti

De-dupliciranje podataka

-Npr. imamo jedan te isti zapis o jednoj te istoj poslovnoj stvari jer smo povukli
podatak iz više lokacija.Da ne bi punili DW stvarima koje su nepotrebne, prepoznajemo te
stvari i uklanjamo ih.

ETL faza nije jednostavna, jer se njom puni DW, i ako se ona ne riješi kako treba, kompletna
BI analiza je dovedena u pitanje.

Master Data Management

-Osiguranje konzistentnosti svih poslovnih pravila i definicija kroz različite sisteme

-Primjena poslovnih pravila u cilju validacije podataka

Master Data Management je set pravila koji treba da osigura konzistentnost svih poslovnih
pravila, definicija, u kompletnom okruženju tako da je što lakše uraditi ETL fazu.
Razmatrana u vezi infrastrukture skladišta podataka

Parametri od kojih zavisi procjena veličine i rasta

-Data Volume

Prije svega koliki je inicijalni dw i koliko se npr sedmično uvuče podataka.Ako se uvlači
mnogo podataka, logično je da nam treba mnogo prostora.Od količine uvlačenja podataka
zavisi i koliko ćemo uložiti u hardversku infrastrukturu.

-Analysis/Report Complexity

Koliko su nam kompleksi reporti i analiza.Ako je manje kompleksno možemo staviti neke
kompnente manje snage(npr CPU slabiji)

-Number of Users

Broj korisnika je važan, a BI operater je puno zahtjevniji od klasičnih korisnika.Npr. klasični

korisnici rade insert,update,select, dok BI operater se „kači“ na npr. multidimenzionalnu
kocku i radi neke operacije nad njoj, što je zahtjevnije.

-Availability Requirements

Scaling out-kada proširujemo u ovom slučaju BI rješenje izvan okvira(npr. Kupnja više servera
i povezivajne)-bolje rješenje

Scaling in-poboljšavamo postojeću infrastrukturu (recimo poboljšavamo postojeće servere )

Tipična topologija jednog BI rješenja

Na početku imamo dvije opcije:

-Da li ćemo krenuti sa jednim velikim serverom na kojeg instaliramo i DB engine, analysis
services, integration services za ETL i reporting service.Za neke manje BI projekte ovo je
prihvatljivo do neke faze, ali recimo za enterprise business ovo nije prihvatljivo.U jednom
trenutku će doći do zasićenja (cpu zauzet, disk pun itd.), tada se ovo skalira i razbije na svaki
server posebno, server za warehouse, za olap kocke i modele, posebno za etl itd.Potrebno je
u startu procijeniti ono šta nam treba.

Proširenje BI rješenja(scaling out)

Scaling in-kada se u postojeći hardver doda više memorije, više cpu-ova ako je multisocket
ploča itd., što nam govori da smo prilično ograničeni.

Scaling out-slično kao scaling in ali recimo imamo novi server.Skaliramo warehouse na više
servera, analizu na više i ostale procese na više servera.

Potrebno je omogućiti visoku dostupnost.Ovo su uglavnom sql server tehnologije.Uglavnom

je to AlwaysOn i Failover Cluster gdje se osgiurava da ako jedan primarni server ispadne,
sekundardni nastavi da radi, odnosno da rade share load balancinga tamo gdje je to
potrebno.

Polazne osnove za hardver

Osnovne reference

-Testirana i certificirana oprema

-Ovo je vrlo važno zbog kompaktibilnosti

-Dostupna od više različitih hardverskih opcija

-Podrška za skladišta podataka

-Alati za kalkulaciju zahtjeva

Određivanje zahtjeva za procesorima i memorijom

Formula za određivanje broja jezgri:

(Average query size in MB/MCR)xConcurrent users)/Target response time

Odnosno:

Koliko naš query povuče megabajta kroz MCR a MCR je propusnost po core-u, koliko MB
može da propusti core-u u sekundi, ovo se pomnoži sa brojem istodobnih korisnika pa se sve
podijeli sa response time

Određivanje količine RAM memorije:

-Minimalno 4GB po jezgri kad je u pitanju RAM

-Cilj je postići 20% RAM-a od količine podataka(ako je DW 100GB, RAM bi trebao biti 20GB)

Ovakve specifikacije predstavljaju neki minimum.

Određivanje zahtjeva za pohranom

-Koristiti više manjih diskova umjesto manje većih(smanjuje se seek time, scan time itd)

-Koristiti najbrže moguće

-SSD je najbolja opcija je je dobar u slučajnom I/O operacijama jer nema pokretnih
dijelova, sve je na principu flash memorije.

-SSD ima ograničen broj read/write po ćeliji

-Koristiti RAID 10(najoptimalnije) ili minimalno RAID 5

Razmotriti opciju za SAN(Storage Area Network)

 Skladište podataka II

Dimenzionalni model

Ono na šta je potrebno obratiti pažnju je da su klasične OLTP baze uglavnom relacione.Data
warehouse okruženja su dimenzionalna.To je model koji se razlikuje u odnosu na relacioni.

Uglavnom se radi o procesu denormalizacije, kada se npr. više tabela smanjeuje količinski na
manji broj tabela, a sve u cilju efikasnijeg izvještavanja i bržih query-a u DW-u.

U centru se nalaze činjenice i mjere, a okolo su dimenzije.U samom centru se nalazi poslovni
proces koji se sastoji od atributa nad kojim se mogu raditi određene agregacije.

Dimenzije su također tabele koje se sastoje od atributa koje se vežu preko spoljnih ključeva
sa fact tabelom ili činjenicama.Po dimenzijama se rade kalkulacije.Npr. imamo dimenziju
Customer, a unutar fact-a imamo prodaju za tog Customer-a, možemo vidjeti podatke o
prodaji, kakva je bila prodaja prije itd.

U osnovi postoje 2 modela:

-Star model gdje imamo jednu činjenicu i jedan sloj dimenzija.Dimenzija nema svoje pod-
dimenzije.

-Drugi model je snowflake šema, to je nadogradnja na star šemu, gdje se može pojaviti
potreba da odrešena dimenzija iam svoje pod dimenzije.

Preporuka je da se držimo star modela, jer je jednostavniji, i samim tim se smanjuje broj join
operatora.

U konačnici ove dimenzije postaju tabele, sa ogromnom količinom zapisa što može dovesti
do usporenja.
Proces dizajna skladišta podataka

-Šta je to izlaz u smislu analitike i reportinga ?

U principu kada se prave relacione baze i posmatramo poslovne procese i na osnovu njih
sklapamo entitete, atribute, pod atribute da bi to postalo šema baze podataka.

U DW-u se radi obrnuto, vidimo šta je izlaz, ljudi kojima se pravi BI rješenje kažu šta je izlaz
npr. primjeri report-a ili kalkulacija.

-Identifikovanje poslovne procese koji generišu potrebne podatke

Na osnovu izlaza prepoznajemo poslovne procese, koji su to procesi u njihovom okruženju

koji generišu te podatke, a ti podaci su potrebni da bi uradili analitiku i izvještavanje

-Ispitati izvore podataka

Sljedeći korak je da ispitamo same izvore podataka, ne u smislu masovnog importa, nego
quick ulaskom sa par selecta vidimo od čega se oni sastoje.

-Utvrđivanje dimenzija između poslovnih procesa

Generalno, činjenica je jedan poslovni proces koji se vrti u odnosu na neke aktore sistema
(customers, employees itd).U ovoj fazi možem oda detektujemo koje su to dimenzije u
postojećim okruženjima pomoću kojih ćemo da analiziramo poslovne procese odnosno da
kreiramo DW okruženje za te analize.

-Izrada dimenzija na osnovu utvrđenih prioriteta

Ovo znači da prvo vidio šta je najbitnije, šta je srednje bitno, a šta najmanje bitno i da
poredamo prioritete na taj način.

-Dokumentovanje u cilju definisanja logičke šeme baze podataka(DW)

Jako je važno da se sve dokumentuje, jer kad se sve dokumentuje, lahko će neko drugi
nastaviti posao, implementacija je vrlo jednostavna.Kada se sve analizira i dokumentuje,
tada se to samo proslijedi nekome ko zna da implementira i implementacija će se obaviti vrlo
jednostavno.

-Dizajniranje fizičke strukture baze podataka(DW)

Nakon svih faza koristimo neko alat i pravio DW u nekom od postojećih rješenja
Modeliranje dimenzija

Kako se modeliraju dimenzije?

Najjednostavnije je ako se koristi ovaj pristup matrice gdje imamo poslovne procese.Ova
matrica je u principu AdventureWorks baza koja oslikava prodaju.Ovdje vidimo koje su to
stvari u bazi koje zahtijevaju veliku poslovnu analitiku.Ovdje vidimo dimenzije u odnosu na
koje se izvršavaju ovi poslovni proces.Npr. prodaja ima presjek u vremenskoj dimenziji i u
proizvodima kao i u factory line.

Order Processing se sastoji od vremenske dimenzije, product-a ,customer-a, salesperson-a,

dakle koji proizvod je koji customer, od strane koje osobe, prodan u nekom vremenskom
trenutku.

Ili npr. isporuka, order fufilment, time, customer i shipment, znamo ko isporučuje, kada, i
kome.

Primjer studentske službe

Dimenzije:studenti,predmeti,edukatori,administracija

Poslovni procesi: prijava ispita, polaganje ispita, učenje itd.

Dokumentovanje dimenzionalnog modela

Primjer

Npr. imamo fact Sales Order koja se sastoji od različitih atributa (item quantity, total cost,
unit cost itd.),a okolo su dimenzije, jer Sales Order zavisi od salesperson, customer, i
vremena kada je to urađeno.Svaka dimenzija ima atribute od kojih se ona sastoji, te se tu
pojavljuju nazivi i podnazivi.
Ovdje je potrebno prepoznati hijerarhiju.U dimenziji Sales Person imamo atribut „Region“ pa
atribut „Country“ i „Territory“.U bazi Adventure Works ovo bi bile 3 tabele, a sada sve
salijevamo , pretvaramo u jednu dimenziju(tabelu) gdje je omogućeno i dozvoljava se
ponavljanje samih atributa i podataka.Bitno je znati koji atributi omogućavaju drill down
hijerarhiju.

Drill down znači da možemo , na report koji je interaktivan, kliknuti na region pa dobiti sve
države, klikom na državu dobijemo teritorije itd.

Dizajniranje dimenzionih tabela

Uglavnom se radi o preslikavanju atributa iz relacionih baza.Potrebo je obratiti pažnju prije

svega na ključeve.Pošto je i DW baza, koja se sastoji od tabela, poželjno je da te dimenzije
imaju svoje primarne ključeve.Pošto se dimenzija uglavnom sastoji od atributa iz drugih
tabela koje imaju svoje PK-ove, nije dobro da uzmemo te ključeve kao primarne.

Npr. imamo informacije o customeru u tri različite baze, gdje ne mora značiti da isti
customer u sve tri baze ima isti primarni ključ, i samim tim u nekom ETL procesu, povlačimo
tri ista customera, ali sa tri različita ID-a i samim tim to postaju 3 različite osobe u sistemu.

Potrebno je imati business ključeve, surogat ključeve koje sami definišemo koji je manje-više
neki generator brojeva.Poželjno je da ostavimo i primarni ključ iz izvorne tabele (source) a to
je obično „alt“ prefiks.To je ključ koji je povučen iz source-a.

Atributi, dimenzije i hijerarhije

Ako smo ispravno prepoznali atribut i njihove hijerarhije to je onda lahko implementirati u
konkretnoj tabeli.Npr. imamo country ima svoje states, states imaju svoje gradove, unutar
tih gradova imamo customer-e sa svojim atributima.

Npr. gender(spol) nije hijerarhija niti detalj hijerarhije, ali je dobar kao filter, kao granični
filter, i to nazivamo slicer.Dakle ako je nešto dobro za filtriranje a nije hijerarhija ili detalj to
stavim okao slicer.
Nepoznato ili ništa(unknown or none)

Nekada se u sistem unesu vrijednosti od strane korisnika, a opet se neke vrijednosti unesu
ako nismo unijeli u neko polje nikakvu vrijednost te ako nije riješena validacija.Neko u tom
slučaju unese „N/A“, neko unese space neko unese „null“ itd.Razne su opcije šta klijenti
mogu unijeti u njihovoj percepciji nepoznatog.To se desi kada nismo osigurali constrainte da
defaultno ako nema ništa bude NULL.Problem je kada se povlače takvi recordi u ETL fazi.Da li
je to zaista nepoznato ili je to ništa.Tu je korisna funkcija ISNULL().Trebalo bi prvo da
sempliramo te tabele i vidmo koje su sve opcije bile za prazno , da ih izvučemo te da
vrijednosti zamijenimo sa nečim što ima smisla, npr. „unknown“, tako da u DW-u znamo da
je to vrijednost koja je bila nepoznata u nekoj bazi.

Nemojte izjednačavati NULL vrijednosti na osnovu pretpostavki

Dizajniranje sporo promjenjivih dimenzija

Npr. Amy u nekom trenutku promijeni broj telefona.Mi smo importovali originalni zapis prije
7 dana,a Amy promijeni taj broj u OLTP sistemu.Na narednom importu kada se puni DW Amy
ima novi broj telefona.Ako je to ovaj oblik ovdje, onda se ti zapisi prepisuju.Prepišemo Amy i
dobijemo novi broj telefona.Ono šta se gubi ovdje je historija, gubi se stari broj telefona u
ovom slučaju.

Npr.Amy je živjela u Vancouveru, i prvi import ubaci te podatke.Amy se preseli u Toronto i na

narednom importu mi bilježimo novu lokaciju ali pamtimo staru.Tako imamo start i end
atribute kako bi obilježili od kada do kada je neki zapis vrijedio (current polje kaže da li
vrijedi).
Npr.Amy je imala 0 auta, i sada je kupila neko auto.Sada imamo ekstra atribut „Current
Cars“ i „Prior Cars“, čuvamo kumulativno šta je prije bilo i šta je trenutno, nemamo
historiju.Ovo je agregatno prikazivanje informacija.

Tabele za vremenske dimenzije

Vremenske dimenzije se generišu od strane funkcija za datum i vrijeme.Poželjno je imati sve

moguće opcije datuma koje su neophone za neke poslovne procese.Što je više granularno to
je efikasnije.

Potrebno je :

-Surogat ključ

-Granularnost

-Opseg

-Višestruki kalendari

-Nepoznate vrijednosti

Smoreferencirajuće dimenzije

Uobičajeno je da se vrši implementacija roditelj-dijete hijerarhija u obliku

samoreferencirajućih tabela.

Spoljni ključ iz tabele je referenciran sa primarnim ključem u istoj tabeli.

Ovdje imamo PK koji ide na drugi atribut u tabeli koji se posmatra kao spoljni ključ.
U ovom primjeru imamo EmployeeKey koji je primarni ključ, imamo business ključ iz OLTP
baze, imamo EmployeeName, imamo oznaku ko je toj osobi menadžer, a u principu
ManagerKey je primarni ključ odavde.ID osobe iz ove tabele se u istoj tabeli remapira da bi
znali ko je navedenim osobama menadžer.

Junk dimenzije

Kombinacija atributa koji nisu unutar postojećih dimenzija, a može se pojaviti potreba za
istim u analitici.

Umanjuje potrebu za kreiranjem više manjih dimenzionih tabela.

To su atributi koji nemaju mjesta u dimenzijama koje smo već napravili.Ako nam trebaju
takvi atributi smjestit ćemo ih u junk tabelu.

Dizajniranje činjeničnih(fact) tabela

Tipovi kolona u činjeničnim tabelama

Fact tabela se također sastoji od atributa, prije svega to su ključevi prema dimenzijama.

Prvo su tu veze prema dimenzijama, kako da vežemo fact tabelu sa dimenzijama, zatim
dolaze mjere odnosno šta se mjeri, koji su to atributi koj zahtijevaju neke agregacije,
sumiranja itd.

Degenerativna dimenzija:

-Imamo atribut koji nije ni ključ ni mjera(OrderNumber), ali je koristan iz ugla filtriranja i
reportinga

Tipovi mjera

-Additive: sve mjere koje mogu da se agregiraju po svim dimenzijama

-Semi-Additive :mjere koje se mogu agregirati samo u nekim dimenzijama, nije primjenjiva
na sve dimenzije

-Non-Additive: atribut koji se ne može sumirati ni po jednoj dimenziji, ali je koristan da

ostane kao fact u smislu nekog filtera, graničnika, a najčešće iz ugla reportinga

Tipovi činjeničnih tabela

-Transakciono činjenična tabela-kako transakcija dolazi tako se bilježi putem ETL-a u data
warehouse

-Periodično snimana tabela-uzimamo termine od-do, u nekom terminu imamo jednu

vrijednost a u drugom se ta vrijednost promijenila, snima se neki vremenski period od nekog
do nekog termina.

-Akumulirano snimana tabela-je manje više agregacija.Npr. za neki broj narudžbe uzmemo
date key, ship date key itd., bez detalja, akumuliramo maksimalno jedan poslovni proces.

Elementi fizičkog dizajna DW-a

Ovdje posebnu važnost ima administrator baza.Administartor treba znati kako funkcioniše
engine, na šta treba obratiti pažnju, razumije se u raid polja itd.

I/O aktivnosti skladišta podataka

U nekoj ETL fazi, prepoznamo da su to maksimalno neki bulk inserti, lookup-i i updatei-i, na
osnovu ovih stavki znamo kada je potrebno raditi ETL i kako ga raditi.Neke od ovih stavki
uzrokuju lockove što znači da sistem stoji i niko ne može pristupiti zapisima.

U nekom warehouse-u jako je puno tabela, milioni zapisa, pa ako su to velike fact tabele,
znamo da će upit trajati dugo pa takvi upiti trebaju biti optimizovani.

Kod reportinga su stvari manje-više statične, pa je report vrlo stabilan i teško je da se report
može oteti kontroli.

Kod I/O aktivnosti jedna od najvažnijih stvari je optimizacija, npr klijenti se mogu svojim
alatima „kačiti“ na DW pa to može dovesti do usporenja.

Opcije za fajlove baze podataka

Potrebno je obratiit pažnju na:

-Data fajlovi i grupe fajlova (izbor raid polja, lokacija itd.)

-Staging tabele (podaci ne idu odmah u destinaciju, nego se zadrže, uradi se reformatiranje
pa se onda preusmjere dalje)

-temdb (vrlo opasna, može postati mjesto zagušenja sistema)

-Transaction log fajlovi (t-log fajlovi ne bi smjeli da rastu pretjerano kao kod OLTP baza jer se
radi uglavnom o bazama koje su u simple recovery modu pa t-log fajlovi ne rastu previše
brzo)

-Backup fajlovi (analize mogu postati neupotrebljive ako DW padne)

Particioniranje tabela

Ovdje se radi o razbijanju fact tabela na više particija.Prepoznajemo koji su to podaci u našim
fact tabelama koji su stari i nepotrebni, dok nam trenutni trebaju.Podaci koji nam ne trebaju
ćemo odvojiti u zasebne particije.Na najbrže diskove stavimo particije koje nam trenutno
trebaju.Koristi se da se smanji overload cpu-a i memorije itd.

Opcije za indeksiranje

Indeksi za dimenzione tabele

-Clustered indeks nad kolonom surogatnog ključa

-Non-clustered indeks nad poslovnim ključem

-Non-clustered indeks nad kolonama koje se često pretražuju

Indeksi za činjenične tabele

-Clustered indeks nad najčešće pretraživanim datumskim ključem

-Non-clustered indeks na drugim dimenzionim ključevima

Ili

Columnstore indeks nad svim kolonama

Kompresija podataka

Opcija koja omogućava da se smanje velike tabele na disku, da se smanji fragmentacija,

pretraživanje I/O rate-a itd.

Aktivirati kompresiu stranica u data fajlu DW-a

-nad svim dimenzionim tabelama, indeksima i particijama činjeničnim tabela

U slučaju da dođe do usporenja(proces dekompresije tokom rada sa DW)

-vratiti na kompresiju zapisa(row) nad particijama koje se najviše pretražuju(defaultno se

koristi page kompresija)
ETL se generalno brine o tome kako podatke prebaciti iz izvora na destinaciju.

•Uvod u ETL

•Planiranje ekstrakcije podataka (E)

•Planiranje transformacije podataka (T)

•Planiranje procesa punjenja (L)

•Šta je SSIS?

ETL:

Extract - ekstrakcija podataka

Transform - transformacija, promjena podataka

Load - punjenje destinacije sa podacima iz source-a

ETL se ne može uvijek raditi. Podatke ne možemo povlačiti u svakom trenutku.

Važni temelji:

Monitoring i optimizacija, operacije i održavanje

Arhitektura kretanja podataka (Data Flow):

Single-Stage

Transfer podataka se vrši direktno iz izvora prema skladištu podataka. Transformacija i

validacija se vrši prilikom ekstrakcije ili kretanja.

Two-Stage

Podaci se zadržavaju u cilju bolje kontrole punjenja DW-a. Transformacija i validacija je i

kretanju ili u fazi zadržavanja. Ovo je dobro jer se može povući puno podataka iz različitih
source-ova i ne brinuti se o tome kada će biti ubačeni u data warehouse

Three-Stage

Koristi se kada imamo mnogo source-ova, koji se ekstraktuju brzo u landing zonu, a nakon
toga zadržavaju u staging-u prije punjenja. Transformacija i validacija se dešava u kretanju.

Dokumentovanje kretanja podataka

U jednome dokumentu imamo šta je source, koje su tabele u source-u, te vidimo po fazama
šta iz koje iz tabele uzimamo, odakle se radi lookup, povlačimo kategorije i podkategorije, te
u fazi flow-a uradimo generisanje ključeva i ostalo, pa se sve to povlači u dimenziju
warehouse-a.

Drugi korak dokumentovanja je mapiranje pojedinih faza. Zavisno od arhitekture, (single-

stage, two-stage, three-stage) mapiramo šta očekujemo u kojoj fazi.

Planiranje ekstrakcije podataka (E)

Profiliranje izvora podataka

Prije same ekstrakcije profilira se izvor podataka, tj. koji izvori podataka su u pitanju i kako će
se ETL komponente konektovati, koji tipovi podataka i formati se nalaze u svakom od izvora,
koja pravila integriteta su implementirana i da li postoje problemi sa validacijom podataka.

Identifikovanje novih i modifikovanih zapisa

Data warehouse se dopunjava novim i modifikovanim zapisima. Takve zapise identifikujemo

putem vremenskih atributa u tabelama preko audit mehanizama, change data capture
mehanizama (tabelama se dodaju CDC tabela koje prate izmjene nad podacima) i
temporalnih tabela (kroz par dodatnih atributa detektujemo od kad do kad je neki zapis bio
validan).

Planiranje vremenskog okvira

Vremenski okvir planiramo na osnovu:

- koliko često se generišu i zadržavaju (retention period) podaci na izvoru

-period latencije između promjena u sistemu i reporting komponente BI-a (koliko dugo se
podaci o nekom poslovnom procesu smiju čuvati u sistemu, npr. podaci o nekoj narudžbi)

-koliko dugo traje ekstrakcija podataka?

-kada je izvorni sistem najviše korišten od strane korisnika?

Planiranje transformacije podataka (T)

Uzimamo u obzir

- gdje izvršiti transformaciju?

- vrste transformacija

- da li koristiti SQL ili transformaciju kroz „Data Flow“ komponente

- optimizacija
- upravljanje sa zapisima koji uzrokuju greške

Gdje izvršiti transormaciju:

- Prilikom ekstrakcije

-Sa izvora

- Iz „landing“ zone

- Iz „stage“ baze

- U protoku između:

- Izvora i „landing“ zone

- „Landing“ zone i „staging“ baze

- Staging baze i DW-a

- U fazi mirovanja Unutar „landing“ zone Unutar „staging“ baze

Vrste transformacija:

• Tranformacije na nivou zapisa:

Character Map, Copy Column, data Conversion, Derived Column, Export Column, Import
Column, OLE DB Command

• Tranformacije na nivou skupa zapisa (Rowsets):

Aggregate, Sort, Percentage Sampling, Row Sampling, Pivot, Unpivot

• Split i Join tranformacije:

Conditional Split, Multicast, Union All, Merge, Merge Join, Lookup, Cache, CDC Splitter

• Auditing transformacije:

Audit, Rowcount

• BI tranformacije:

Slowly Changing Dimension, Fuzzy Grouping, Fuzzy Lookup, Term Extraction, Term Lookup,
Data Mining Query, Data Cleansing
• Custom transformacije:

Script, Custom Component

Optimizacija

- Optimizacija upita - odabrati samo one kolone i zapise koji su nam potrebni - Izbjegavati
nepotrebna sortiranja

- Koristiti već sortirane podatke, ako je moguće

- Oprezno sa binarnim podacima

- Provjeriti tempdb postavke

- Koristiti skripte ako govorimo o SQL pristupu, a ne front-end komponente

Upravljanje sa zapisima koji uzrokuju greške

- Odabrati odgovarajuće tipove transakcija u cilju minimiziranja „rollback“ operacija

- Logirati okolnosti pod koji se desila greška

- Logirati zapise koji su uzrokovali problem

- Kolone

- Tip podatka

- Podatak

- Audit korisnika

Planiranje procesa punjenja (L)

Minimiziranje procesa logiranja:

- Aktiviranje simple ili bulk-logged opcije nad DW okruženjima

- Razmisliti o aktiviranje opcije „trace flag 610“ nad SQL Server (destinacijom)

- Koristiti bulk load opracije za brži rad (Bcp, BULK INSERT, INSERT..SELECT, SELECT INTO,
MERGE)
Punjenje indeksiranih tabela:

- Razmisliti o brisanju indeksa prije punjenja tabela i ponovnim rekreiranjem nakon operacije

- Sortiranje podataka preko clustering ključa

Punjenje particioniranih činjenjičnih tabela

- Nakon punjenja činjeničnih tabela iste prebaciti u particije (odnosno ako se radi o
dopunjavanju uraditi dodavanje novih particija prema kriterijima koji su definisani)

- Koristiti indekse za particije kako bi se minimizirao broj DROP/CREATE INDEX operacija

- Raditi u satima minimalnog opterećenja DW sistema od ostatka BI arhitekture

SSIS

SSIS (SQL Server Integration Services) je set klijentske i serverske strane. Omogućava ETL
fazu i maksimalnu kontrolu nad njom.

Sastoji se od Control Flow Engine-a i Data Flow Engine-a.

Control Flow Engine se brine kako povući podatke i kako ih proslijedi dalje.

Data Flow Engine se brine kako podatke proslijediti do zadane destinacije.

SSIS paket može sadržati jedan ili više zadataka.

SSIS projekat sadrži više paketa.