KOMUNIKIMI I SISTEMEVE TË EMERGJENCAVE DHE [602812]

KOMUNIKIMI I SISTEMEVE TË EMERGJENCAVE DHE
SINKRONIZIMI I TË DHËNAVE NË APLIKIMET
WEB MOBILE

Doktoranti :ZIJADIN KRASNIQI

Dorëzuar
Universitetit Europian t ë Tiranës
Shkollës Doktorale

Në përmbushje t ë detyrimeve të programit të Doktoratës në
Shkenca Eko nomike, me profil Menaxhim i Sistemeve të I nformacionit, për
marrjen e gradës shkencore “Doktor”

Udhëheqës shkencor : Prof.Dr.ADRIANA GJONAJ

Numri i fjalëve:36003

TIRANË , Shtator 2015

2

DEKLARATA E AUTOR ËSISË

Nën përgjegjësinë time personale, deklaroj se ky studim është punë origjinale dhe nuk
përmban plagjiaturë. Punimi është shkruar prej meje, nuk është prezantuar asnjëherë para një
institucioni tjetër për vlerësim dhe nuk është botuar i tëri ose pjesë të veçanta të tij. Punimi
nuk përmban material të shkruar nga ndonjë person tjetër përveç rasteve të cituara dhe të
referuara.

3
ABSTRAKTI

Menaxhimi i fatekeqsive natyrore eshte nje domen kompleks por dhe shume i
nevojshem.Keshtu qe nevojat e jetes normale kane shume dallim nga ato te situatave te
emergjencave natyrore.Ne kete teze fokusi do jete ne menaxhimin e fatekeqsive natyrore
,duke e eksploruar ne risite qe n a ofron teknologjia e informacionit per te lehtesuar keto
situata. Agjencionet , institutet dhe organizatat qe merren me menaxhimin e fatekeqsive
natyrore secila ne vete kontribon me gjenerimin e nje sasie te dhenave, por qe te gjitha nuk
kane nje centraliz im ne ndertimin e nje DWH .Nje sis tem i tille DWH mund te jete efikas ne
organizimin dhe analizimin e nje morie te informatave ,e qe mund te ndihmoj ne krijimin e
nje modeli efikas me qellim vendim marrje ne kohe . Në këtë punim do të paraqitet një studim
i sistemeve Data Warehouse për teknikat dhe standartet që sot për sot ekzistojnë dhe do të
përshkruhet aplikimi i tyre ne fushën e menaxhimit te fatekqesive natyrore. Duke marre per
baze problemet me te cilat po sfidohet sot Agjencioni i menaxhimit te emerg jencave –AME
,si dhe menyra si po aplikohen te dhenat operacionale te shperndara neper institute tjera,nga
kjo forme e ketyre te dhenave eshte ngritur hipoteza per ndertimin e nje datamarti ,qe bene
analizimin e rekordeve te detajuara . Në të prezantohet ha p pas hapi modelimi i këtij datamart –
i sipas modelit Kimball, që do të shërbejë për analiza të hollesishme te institutit mjeksor ,te
dhenave nga instituti hidrometrologjik,si dhe nga institute seizmik. Në grumbullimin e ketyre
te dhenave , transformimin dhe ngarkimin e të dhënave, gjejnë aplikim metodat ETL/ELT,
të cilat konsiderohen si detyrat më kritike të ndërtimit të një sistemi DWH. Perveq kesaj do
kemi edhe mundesin e sinkronizimit te te dhenave permes ndertimit qe DWH te komunikojne
ne kohe reale, se d eri me tani ka qene nje mangesi ne fushen e menaxhimit te emergjencave.

4
Se fundi ka lind nevoja, qe ne veqanti te shqyrtojme mundesin e zhvillimit te aplikacioneve
WEB mobile .Ku dihet se paisjet mobile jane nje teknologji e re. Së fundmi duke u bazuar
në studimet e literatu rave por edhe në punën konkrete me këto sisteme, prezantohen disa
elementë të rendësishëm për suksesin e sistemeve DWH , Datamart dhe zhvillimin e web
aplikacioneve mobile .
Fjalëkyçe:DWH,datamart,ETL,OLTP,OLAP,WEBMobile,sinkronizim,vendim marrje,fatek
eqsi natyrore,menaxhim i emergjencave.

5
PËRMBAJTJA E L ËNDËS
KAPITULLI I:Permbledhje e studimit
1.1 Hyrje
1.2 Permbajtja shkencore e Doktorates -pershkrimi i problemit
1.3 Caktimi i objektivave te studimit dhe hartimi i hipotezave
1.4 Metodologjia e perdorimit gjate studimit te doktorates
1.5 Permbledhje e literatures kryesore
KAPITULLI II:
2.1 Hyrje
2.2 Koncepti i Data Warehouse (DWH)
2.3 Historiku i sistemeve në mbështetje të vendimmarrjes (DSS)
2.4 Nevoja për të veçuar sistemet operacionale dhe informative
2.5 Metodologjia e Zhvillimit të Data Warehouse (DWH).
2.6 Arkitektura e sistemeve te DWH
2.7 Konkluzion
KAPITULLI III: APLIKIMI I SISTEMEVE TË DWH NE RASTIN E EMERGJENCAVE
DHE FATKEQËSIVE NATYRORE
3.1 Hyrje
3.2 Gjendja e emergjencave dhe fatkeqësive natyrore në vendin tone
3.2.1 Analizimi i te dhenave ne rastin e tërmeteve
3.2.2 Rasti i zjarreve pyjore
3.2.3 Analizimi i te dhenave tek Instituti Hidro‐meterologjike -Rasti i vërshimeve
3.2.4. Rasti i Orteku te borës
3.3 Analizimi i te dhënave ne rastin e emergjencave dhe fatkeqësive natyrore .
3.4 Burimi i të dhënave kryesore te QOAME -se
3.5 Integrimi i të dhënave dhe menaxhimi i katastrofave
3.6 Konkluzion

6
KAPITULLI IV: MODELIMET E DATAMART -ËVE PËR MENAXHIMIN E
EMERGJENCAVE DHE FATKEQËSIVE NATYRORE
4.1 Hyrje
4.1.1 Arkitektura data mart -eve
4.1.2 Arkitektura e Data -Martit të Pavarur dhe e Ruajtjes të të dhënave Operacionale
4.2 Shtrimi i problemit per QOAME
4.3 Modelimi i të dhënave te përzgjedhura
4.4 Modelimi dimensional
4.4.1 Modelimi i formës së tretë normale (3NF )
4.4.2 Tabelat e Fakteve
4.4.2 Tabelat e Dimensioneve
4.4.3 Çelësat e tabelës të dimensioneve
4.4.4 Dimensionet e konfirmuara
4.4.5 Sjellja së bashku e fakteve dhe dimensioneve
4.5 Modelimi konceptual
4.6 Modelimi logjik
4.6.1 Tipi 1 – SCD
4.6.2 Tipi 2 – SCD
4.6.3 Tipi 3 – SCD
4.7 Modelimi fizik
4.8 Përgati tja e një strategjie indeksimi.
4.8.1 Indeksimi i Data Warehouse
4.8.2 Përmbledhje e indeksimit
4.8.3 Indeksimi për tabelat e mëdha
4.8.4 Indeksimi vetem me lexim
4.9 Efektet e indekseve
4.9.1 Indeksi B -Tree
4.9.2 Indeksi Bitmap
4.9.3 Treguesit Bitmap
4.9.4 Indeksi i tabelës të fakteve
4.9.5 Inde ksimi i tabelave të dimensioneve

7
4.9.6 Rendesia e indeksimit
4.10 Konkluzion

KAPITULLI V: METODOLOGJIA ETL PER GRUMBULLIMIN E TE
DHENAVE
5.1 Hyrje
5.2 Nxjerrja e të dhënave
5.3 Transformimi
5.4 Ngarkimi i te dhenave
5.5 Mjetet e përdorura për ETL –DATA STAGE .
5.6 Konkluzion

KAPITULLI VI:SINKRONIZIMI I DHENAVE NE SISTEMET ETL NE
KOHE REALE
6.1 Hyrje
6.2 Sinkronizimi i të Dhënave
6.3 Arkitektura e data -marteve logjike dhe DWH në kohë reale
6.4 Data warehouse në kohë reale dhe teknikat ETL
6.5 Sfidat dhe mundësitë e DWH në kohë reale
6.6 Rishikim i DWH në kohë reale
6.7 Përcaktimi i ETL në kohë reale
6.8 Qasjet ETL në kohë reale
6.9 Enterprise Application Integration –EAI
6.10 Ndërtimi i particioneve në kohë reale
6.10.1Roli strategjik i menaxhimit te dimensioneve
6.10.2 Vetëm faktet apo edhe ndryshimet në dimension
6.10.3 Integrim të dhënash dhe integrimi aplikacioneve
6.11 Konkluzion

KAPITULLI VII: APLIKIMET WEB MOBILE NE RASTIN E
FATEKEQSIVE NATYRORE
Hyrje
6.1 Arkitektura e aplikimeve web mobile
KAPITULLI VIII: Konkluzione dhe Rekomandime

8
Përmbledhje
Përfundime dhe realizime

LISTA E ILUSTRIMEVE
Figura 2 .1 Vlera e informacionit si funksion i sasisë së të dhënave
Figurën 3 ‐1 Sistemi Informativ Hidro ‐meteorologjik Çek
Figura 3.1 Diagrama e kalimit te informacionit drejt DWH -QOAME
Figura 4.1. Arkitektura data -mart e pavarur për një DWH
Figura 4.2 Arkitektura trishtresore e Data -Martit të Pavarur
Figura 4.3 Skema e arkitekturës së përzgjedhur
Figura 4.4 . Proceset e modelimi t dimensional
Figura 4.5 Moster e tabeles dimensionale
Figura 4.7 .Tabela e Fakte dhe Dimensioneve ne modelin dimensional.
Figura 4.6 Ndarja e dimensioneve në skemën
Figura 4.7 Projektimi i t abeles fakt për trajtimin e matjeve në kohë të sakta
Figura 4.8 Skema e datamart -it të IMK
Figura 4.9 Tipi 2 SCD historiku perfekt i particioneve
Figura 4.10 Implementimi i Tipit 3 -SCD ne pershkrimin e nr rendor -profesioni
Figura 4.11 Struktura e nje indeksi B -Tree
Figura 5.1 Komponentët e Data stage
Figura 6.1 Data mart logjike dhe arkitektura ne kohe reale e Data Warehouse
Figura 6.2 Lidhja midis formës statike dhe skemës ylli ne kohë -reale
Figura 6 .3 Lidhja logjike per particionet e datamart -ve ne kohe -reale
Figura 6.4 Diagrami Konvencional ETL

9
Figura 6.5 Diagrami Mik ro-Batch ETL
Figura 6.6 Diagrami Konvencional EAI
Figura 6.7 Diagrami i DWH në kohë reale i EAI
Figura 6.8 Integrimi i aplikacioneve Point –to-Point
Figura 6.9 Integrimi i Aplikacioneve HUB dhe SPOKE
LISTA E TABELAVE OSE DIAGRAMEVE

TABELA:2 -1 Krahasimi i Sistemeve operacionale dhe Sistemeve informative
Tabela:2 -2 Qasja sipas Inmon -it dhe Kimball -it .
Tabela 1.3 Elementët e arkitekturave për ndërtimin e sistemeve DWH
Tabela 3.1 Sipas Institutit të Sizmologjisë në Ministrinë e Zhvillimit Ekonomik
Tabela 3.2. Instituti Seizmik i Kosoves -ISK, Buletini Mujore (Mars 2010)

Tabela 3.2. Instituti Seizmik i Kosoves -ISK, Buletini Mujore (Nentor 2013)
Tabela 3.2 Te dhenat e vitit nga Sherbimi i zjarrefikseve te Kosoves -SHZK( 2006)
Tabela 3.2 Te dhenat e Stacionit meteorologjik ne Peje
Tabela 3.3 Te dhenat e Stacionit meteorologjik ne Prishtine

Tabela 3.4 Te dhenat e Stacionit meteorologjik ne Ferizaj
Tabela 3.2 – Katastrofat natyrore në tri dekadat e fundit (1980 -2014)
Tabela 1.2 – Katastrofat natyrore – Fatkeqësitë Teknologjike
Tabela 4.1 Elementët kriter për përzgjedhjen e modelimit
Tabela 4.2 Matrica Dimension /Fakt
Grafiku 3.1 Përmbledhje e katastrofave natyrore 1980 -2014

10

LISTA E SHKURTIMEVE DHE E FJALORIT

A
AME Agjencisë për Menaxhim të Emergjencave
ARC Agjencioni i Regjistrimit Civil
B
BI Business Intelligence
C
CIF Corporate Information Factory
D
DWH Data Warehouse
DSS Decision support system
DBMS Database Management System
DML Data Manipulation Language
DBA Database Administrator
E
ETL Extract Transformation Load
ELT Extract Load Transformation
EDWH Enterprise Data warehouse
ERP Enterprise resource planning
G

11
GPRS General packet radio service
I
IMK Institutin mjeksor te Kosoves
ISK Instituti Seizmik i Kosoves
IHMK Instituti Hidrometrologjik i Kosoves
K
KPSH Kujdesit Parësor Shëndetësor
M
MZHE Ministrinë e Zhvillimit Ekonomik
O
OLTP Online transaction processing
OLAP Online analytical processing
ODS Operational Data Store
Q
QOAME Qendra Operative e Agjencionit të Menaxhimit Emergjent
QMF Qendrat e Mjekësisë Familjare
QKMF Qendrat Kryesore të Mjekësisë Familjare
QKUK Qendrën Klinike Universitare të Kosovës
S
SCD Slowly Changing Dimensi ons
SH
SHZK Sherbimi i zjarrefikseve te Kosoves

12

KAPITULLI I: Permbledhje e studimit
1.1 Hyrje
Çdo shtet duhet t’i jep prioritet fushës së emergjencave, duke pasur parasysh se parandalimi
në të shumtën e rasteve rezulton në zvogëlimin e fatkeqësive.
Jo rrallëherë, komuna të ndryshme të Kosovës, janë përballë me situata emergjente, nga të
cilat kanë humbur jetë njerëzish dhe janë dëmtuar prona e paluajtshmëri. Zinxhiri i
komunikimit në raste emergjencash, sipas strategjive dhe ligjeve në f uqi, jo rrallëherë ka
patur ndikimin e tij negativ. Ky zinxhir poshtë -lart, i komunikimit, është aq kompleks, sa
ndikon edhe në kohën e reagimit ndaj emergjencave. E kjo, sidomos kur merret parasysh se
Kosova deri tani, edhe pas planifikimit të hapjes së q endrave të operimit për emergjenca, nuk
i disponon më këto qendra, të cilat këtë komunikim megjithëse pse kompleks, do të sillnin
një lehtësim të dukshëm.
Nëse situata tejkalon edhe nivelin e përgjegjësisë dhe mundësisë për veprim të rajonit të
caktuar, a tëherë kërkesa shkon në nivel të Agjencisë për Menaxhim të Emergjencave
( Forumi për siguri ,2013) .
Kur te përballemi me fatkeqësi duhet ne mënyrë te shpejte të koordinohemi me një varg
agjencish për te siguruar informacione optimale ne lidhje me situatat e krijuara. Me këtë lind
nevoja për një sistemi integral te komunikimit për menaxhim efikas, të b esueshëm dhe siguri

13
ne shkëmbimin dhe përpunimin e informacioneve (Andreas & Thomas ,2002) .Integrimi i
këtyre sistemeve te ndryshëm është i rëndësishë m dhe kjo mund te realizohet
( Sam & Lance, 2009) .Sistemet e informacionit janë një faze e rëndësishme n ë planifikimin
dhe përgatitjen për fatkeqësitë (Sriganesh & Iyer,2005)
. Në një situatë emergjente, informacioni përkatës në lidhje me elementet e përfshira është i
nevojshëm. Për më tepër, procesi i menaxhimit të emergjencave është dinamik dhe përfshin
disa hapa të caktuar (Tanasescu & Gugliotta,2006:956)
Sistemet e komunikimi t dhe informimit duhet të jenë të dizajnuara që të kenë fleksibilitet, të
besueshme dhe të shkallëzueshme në mënyrë që të funksionojnë në çdo lloj të incidentit, pa
marrë parasysh shkakun, madhësinë, vendndo dhjen apo kompleksitetin e tij (SIME ,2010).
1.2 Permbajtja shkencore e Doktorates -pershkrimi i problemit
Nje nga problemet e shumta te dala gjate vizitave ne Agjencioni e menaxhimit te
emergjencave , menaxhimi i te dhenave te sistemit te informimit dhe komunikimit ,kjo nuk
eshte vetem ne aspektin e th jeshte te gjenerimit te raporteve standarte lidhur me fatekeqesit
natyrore te ndodhura ,por per te ardhur ne ndihme me keto te dhena ne kohe reale te gjitha
strukturave mbeshtetese kryesishte depertamenteve : Agjencioni i Regjistrimit Civil –ARC,
Institutin mjeksor te Kosoves –IMK, Instituti Seizmik i Kosoves -ISK, Sherbimi i
zjarrefikseve te Kosoves -SHZK dhe Instituti Hidrometrologjik i Kosoves -IHMK .-
Ne fakt ne Agjencioni n e menaxhimit te emergjencave nuk ka asnjë metodologji të
paracaktuar/vendosur për mbl edhjen e informatave, ruajtjen dhe përditësimin periodik të
dhënave historike që lidhen me fatkeqësitë. Megjithatë, mbledhja e të dhënave dhe ruajtja e

14
tyre është bërë në mënyrë spontane dhe prandaj modele të ndryshme të mbledhjes së të
dhënave dhe ruajtje s janë shfrytëzuar për ngjarjet e fatkeqësive. Aktualisht, nuk ka sistem
kombëtar vëzhgimi për rrezikun i cili mbledh të dhëna në një formë të centralizuar dhe
prodhon një vlerësim të rëndomtë të rreziqeve të vendit – për shfrytëzim në planifikime për
parandalim, zbutje dhe madje për masa gatishmërie. Mungesa e kapaciteteve sa i përket
identifikimit të rreziqeve gjithashtu ndikon paralajmërimin e hershëm. Nuk ka mekanizma të
paralajmërimit të hershëm për të informuar autoritetet dhe publikun për trendët në rritje të
rreziqeve – popullimi në rritje dhe ekspozimi i pasurisë ndaj rreziqeve të ndryshme natyrore
dhe mjedisore (Armenv & Hachim & George, 2011) .Perballe faktit se nuk kemi nje
databaze te centralizuar per menaxhim te te dhenave ne kuader te AME -se ,atehere mbetet
edhe vonesa te medha ne hedhjen e te dhenave te sakta dhe ne kohe reale .Nga te gjitha keto
depertamente ne kuader te AME -se kemi nje veshtirsi per informim te shpejte dhe te sakte
ne lidhje me te dhenat e tyre qe gjenerohen . Kjo ne nje menyre te domodsoshme paraqet
nevojen per nje integrim te te dhenave nga te gjitha keto burime ,duke krijua r keshtu nje
sistem komunikimi unik per vete AME -ne .
Perveq integrimit te te dhenave dhe ndertimit te sistemi t DWH ,nevoje tjeter eshte edhe
modelimi i databazeve aktuale qe jane ndertuar apo duhet ndertuar ne depa rtamentet e vete
AME -se ,kjo munde te arrihet duke marre ne studim modelin data mart , edhe gjithë proçeset
që do e bëjnë të mundur grumbullimin e informacionet nga burimet origjinale,transformimin
dhe ngarkimin e tij në destinacion. . Si pjese e trajtimit te modelimit hap pas hapi te data mart
,do jete edhe procesi i ndertimit te ETL ,qe konside rohet njera nga detyrat me kritike ne hapat
e ndertimit te sistemit DWH.

15
Me kete AME –ja mund te lehtesoje procesin e vendim marrjes ne situata kur eshte e perfshire
ne menyre dire kte ne menaxhimin e fatekeqsive natyrore ,e situata te tilla shume here du het
te monitorohen ne menyre te vazhdueshme per te pasur mundesi te paralajmerohen dhe te
mirren masa adekuate konforme menaxhimit te fatekeqesive natyrore.
Ky studim perfshin analizimin e sistemeve te informacionit sipas standarteve te ndertimit te
Baze s se te dhenave ,modelimit dhe aplikimin e ketyre te dhenave ne paisjet e vogla permes
WEB Aplikacioneve Mobile.
E tera kjo analize permbledh sistemet si:
 Sistemet DWH
 Modelimin shume dimensional te Data mart -ve
 Sinkronizimi i te dhenave ne sistemet ETL ne kohe reale
 Zhvillimi i aplikacionit ne plat eformen WEB MOBILE
1.3 Caktimi i objektivave te studimit dhe hartimi i hipotezave
Objektive (Mark,2010) e hulumtimi t është që të shqyrtojë mënyrat për të krijuar një sistem
komunikimit që do të r eferohet si qendër operative . Qendra Operative e Agjencionit të
Menaxhimit Emergjent (QOAME), është shumë institucionale e cila siguron koordinim të
përgjithshëm të reagimit qendror, për incidentet me Karakter Kombëtar dhe zbatim të
progr amit të menaxhim it emergjent (MPB ,2010) . Sot, më tepër se asnjëherë është nevoja që
të krijojmë një sistem të koordinuar institucional me të gjitha resurset dhe kapacitetet që kemi
në dispozicion për të qenë të përgatitur që të reagojmë në mënyrë të koordinuara dhe
plani fikuara me rastin e fatkeqësive natyro re dhe incidenteve tjera (SIME ,2010).

16
Pra zhvillimit te teknologjise se informacionit dhe shfrytezimi i tyre per qellime te ndryshme
ne administrimin e QOAME -se eshte nje nga fushat kry esore të kërkimit sot në botë dhe
motoja kryesore në korporata për të analizuar mundësitë për zhvillimin e mëtejshëm të
biznesit dhe përmirësimin e cilësisë së shërbimeve të tyre.
Qëllimi kryesor i këtij studimi është që të kontribuojë në fushën e implementimit të
aplikacioneve të plat formës web mobile dhe ndertimit te sistemeve te centralizuar te te
dhenave në ndihmë të Qendres Operative te AME -se (Dasho, 2014) .
Objektivi i I -re ,i shtruar per zgjidhje
Projektimi dhe ndertimi i sistemit DWH ,qe ne kuader te bashkerendimit dhe lehtesimit te
mundesohet integrimi i te dhenave ng a te gjitha burimet qe nderlidhen me QOAME.Ky
integrim i te dhenave do beje te mundur marrjen e informacioneve ne kohe reale.
a. Ndertimi i sistemit DWH
b. Modelimi i Datamart -it
c. Metoda e grumbullimit te te dhenave ETL .
Objektivi i II -re ,i shtruar per zgjidhje
Zhvillimi i teknologjisë se informacioneve do të bëjë të mundur menaxhimin me efikas te
emergjencave, fatkeqësive dhe krizave natyrore ,qe kryesisht po fokusohet drejt
komunikimeve pa tela , posaçër isht rreth pajisjeve mobile ,ku është rritur nevoja qe aplikimet
e ndryshme të jenë të pranueshme nga çdo pajisje qoftë ai kompjuter personal apo pajisje

17
mobile . Pra projektimi i aplikacioneve te plateformes web mobile , si nje plateforme standarte
e sistemit te teknologjis se informacionit.
a) Sinkronizimi i te dhenave ne sistemet ETL ne kohe reale
b).Zhvillimi i aplikacioneve web mobile
Studimin cilësor ,te thelluar teorik dhe përmbajtjësor te kësaj teze e ndihmon gjetja e
përgjigjeve në disa nga pyetjet qe mund te shtrohen ne lidhje me ecurine e punes se kesaj
teze doktorate ,duke bere permbushjen e qellimit kryesor te ketij punimi:
Pyetje 1. Cilet do ishin faktoret kyq qe kane ndikuar ne ndertimin e sistemit DWH ne
QOAME sipas kerkesave te mbledhjes se informacioneve per procesin e vendimmarrjes ne
menaxhimin e fatekeqesive natyrore ?
Pyetje 2. Cila do jete metodika me e pershtatshme per ndertimin e sistemit DWH ,do
perzgjedhet ?
 Metodika Top -down (Bill Imnon)
 Metodi ka Bottom -Up (Ralph Kimball)
Pyetje 3. Si eshte i ndertuar Datamart -i QOAME ,e qe ne fakt bene integrimin e burimeve
te te dhenave ?
Pyetje 4. Si do te ndikoje s inkronizimi i dhenave ne sistemet ETL ne kohe reale tek raste
e emergjencave dhe fatekeqsive natyrore ?

18
Pyetje 5. Sa do te rritet performanca ne procesin e vendim marrjes me rastin e
implementimit sistemit DWH dhe perdorimi i aplikacioneve te plateformes web mobile ?
Pra ngritja e pyetjeve kerkimore te shtruara me larte na japin nje kendveshtrim me te qarte
per te gjithe ecurine e tezes se doktorates d uke u bazuar ne nivelin e larte te zhvillimit te
teknologjisë se informacionit dhe komunikimeve ne distanca te largëta ,ne mundësitë qe
ofrojnë këto zhvillime dhe ne përvojën e deritani shme në këto fusha , konsideroj se ka shumë
argumente që të pretendohet se :
Zhvillimi i aplikimeve web për pajisjet qe janë ne lëvizje mund te ketë këto ndikime:
 Lehtësimin e qasjes ne informata nga vende te n dryshme dhe situata emergjente
 Qasja në faqet web dhe shërbimeve web përmes pajisjeve mobile.
 Rritja e shkalles se besueshmërisë se informacionit
1.4 Metodologjia e perdorimit gjate studimit te doktorates
Teknologjia informative është bërë një bazë për zhvillimin e shume sistemeve te
informacionit sot. Në shumicën e fushave jetësore është bërë shumë e vështirë të realizohen
komunikime ,ndërlidhje institucionale apo edhe komunikime ndërkombëtare pa përdorim të
gjerë të teknologjisë së informacionit.
Teknologjia informative merr për baze komunikimin e pajisjeve mobile që është e një
rëndësi të veçantë , duke ditur se numri i tyre është shumë më i madh se numri i kompjuterave
,është e arsyeshme që edhe përmes pajisjeve mobile të mund të sh frytëzohen resurset e
ndryshme. Si pikë e rëndësishme në Teknolo gjinë e informacionit është përdorimi, adapti mi

19
dhe ndërtimi i web aplikacionit mobil . Po ashtu edhe standardet dhe zhvillimi i teknologjive
të ndryshme në fushën e pajisjeve mobile janë pjesë e rëndësishme e studimit, shërbimet web
në hapësirat mobile po bëhen për arsye se janë duke u optimizuar protokollet dhe janë duke
u bërë adekuate për pajisje mobile.
Studimet e reja të teknologjisë së informacionit dhe komunikimit kanë hapur mundësi për
përmirësime të rëndësishme në integrimin dhe koordinimin e sh ërbimeve emergjente.
Aplikimet e teknologjive të informacionit ofrojnë mundësi të reja për integrimin dhe
përmirësimin e shkëmbimit të informacionit ndërmjet institucioneve ,qe menaxhojnë me
shërbimet emergjente dhe fatekeqesive natyrore.
Me kete raste e kzistojne nje numer metodash per qasje te ndryshem e ,si per analizim te
sistemit ,zhvillim te aplikacioneve ,implementim e tij dhe shfrytezimin ,e me pas edhe
mirembajtjen e sistemit .
Nese marrim per baze objektivin e I -re ,metodologjia m bi te cilen ndertohet sistemi DWH
eshte specifikuar sipas hapave vijues:
1.5 Permbledhje e literatures kryesore
Studimin cilësor, te thelluar teorik dhe përmbajt jesor te këtij punimi e bene te ndare ne disa
grupe kryesore te literatures :
o Sistemi Data Warehouse
o ELT,OLTP
o Sinkronizimi i te dhenave ne sistemet ETL ne kohe reale
o Aplikimet WEB Mobile
Sistemi Data Warehouse

20
Kjo pjese e punimit paraqet anen teorike te ndertimit te DWH qe eshte shume e mirepritur
per proceset vendim marrese te fushave biznesore ,telekomunikuese,shendetsore.Por ndikim
te madh ka edhe tek menaxhimi i fatekeqesive natyrore ,e qe ne fakt kjo lemi ka nevoje per
te dhena ne kohen reale .Sistemet DWH nga kendveshtrimi i zhvillimit jane shume evolutive
dhe dinamike ,nuk ndalen se transformua ri konforme kerkesave.Sistemi DWH eshte sistem
qe grumbullon informacione nga burime te ndryshme heterogjene (Kimball & Becker ,2008 )
.Megjithëse një data warehouse fillimisht mund të jetë e vogël dhe e thjeshtë, të ofrosh të dhënat
e duhura ka një rëndësi shumë të madhe në vendimmarrjet e ndryshme, te cilat do të mbështeten
në këto të dhëna dhe për këtë qëllim shpesh herë kërkohen të dhëna historike, të shtrira në kohë
dhe të regjistruara në një nivel shumë të detajuar. Një data warehouse është një sistem që merr
dhe konsolidon të dhënat në mënyrë periodike, nga sisteme të tjera në modele dimensionale
ose të normalizuara. Zakonisht mbajnë të dhëna për vite të ndryshme dhe janë të modeluar
që të le htësojnë kërkimin e informacionit për business intelligence (BI) . Analizat mund të
kërkojnë dhe një akses në kohë reale të të dhënave. Meqë një analist të dhënash përparon
vazhdimisht në përvetësimin dhe kuptueshmërinë e të dhënave, një raport i thjeshtë nuk është
kurrë i mjaftueshëm, kështu që për të rritur shkallën e vendimarrjeve të tij janë gjithmonë të
nevojshme ad hoc query -të dhe analizat e sofistikuara. Në kuadër të përparimit të vazhdueshëm,
shumica e data warehouse -ve nuk konsiderohen kurrë të pë rfunduara, ato janë gjithnjë në
zhvillim e sipër për t’iu përgjigjur sa më mire ndryshimeve që ndodhin në fushat për të cilat ato
janë ndërtuar ,e sidomos ne rrafshin menaxhimit te emegjencave qe nevojitet qdo here ndrysh ime
(Çela ,2014).
ELT,OLTP

21
Brenda n jë sipërmarrjeje ka sasi të mëdha aplikimesh të ndryshme dhe burime të dhënash të
cilat duhet të integrohen. Përpunimi i transaksionit on -line (OLTP) dhe DWH nuk mund të
bashkëekzistojnë në mënyrë të efektshme në të njëjtin mjedis databaze meqenëse databazat
OLTP mbajnë të dhëna aktuale në shumë detaje kurse DWH merren me të dhënat e
përmbledhura dhe shpesh historike të bashkërenduara globalisht. OLTP thekson e fikasitetin
e transaksioneve të përditësimit të shkurtër ku secila mbulon një pjesë të vogël të databazës,
ndërsa DWH kërkon studim të gjatë të një pjese të madhe të databazës. Procesi ETL
ekstrakton të dhënat nga sistemet burim, i transformon të dhënat si pas rregullave të biznesit
dhe i ngarkon rezultatet në DWH të synuar. Aktivitetet ETL përfshijnë (a) identifikimin e
informacioneve përkatëse në anën burim; (b) ekstraktimin e këtij informacioni; (c)
personalizimin dhe integrimin e informacionit që vjen ng a disa burime në një format të
vetëm; (d) pastrimin e setit të të dhënave që vjen si rezultat mbi bazën e rregullave të
databazës dhe biznesit; dhe (e) përhapjen e të dhënave në DWH / datamarte. Cilësia e të
dhënave dhe efektiviteti i një DWH varet direkt nga efikasiteti i procesit ETL. Prandaj, një
proces ETL cilësor sjell fuqi vendim -marrjeje cilësie. Studimi ka zbuluar se shtatëdhjetë
përqind (70%) e përpjekjeve për implementimin e softuerëve dhe mirëmbajtjes të DWH
harxhohet në sistemin ETL. Qasjet trad icionale në ETL bazohen në përhapjen e
përditësimeve të vërteta të të dhënave dhe jo në ngarkimet në rritje.
Sinkronizimi i te dhenave ne sistemet ETL ne kohe reale
Përdorimi i DWH është rritur ndjeshëm në vitet e fundit dhe luan një rol themelor në shumë
procese ve ndim -mbështetëse sidomos te AME. Me shumë AME që tani duhet të integrojnë
përditësimin e të dhënave në kohë, përditësimi midis databazave transaksionale dhe analitike
është bërë një çështje kritike. Për të arritur efikasiteti n maksimal, disa bur ime te te dhenave

22
te AME kërkojnë futjen e të dhënave transaksionale në një DWH në kohë reale ose në
periudha të rregullta më të shkurtra se ngarkimet statike tradicionale. Shumica e ndërtimeve
të DWH e trajtojnë të gjithë DWH si një ent itet të vetëm, homogjen për sa i përket
sinkronizimit.
Të gjitha të dhënat e ruajtura rifreskohen në të njëjtën kohë gjatë të njëjtave ngarkesa
periodike. Sidoqoftë, kjo qasje nuk është më e vlefshme pasi porcionet e DWH që për bëjnë
modele të ndryshme agjencio nesh te emergjencave kanë kërkesat e tyre të përditësimit të
cilat ndryshojnë me kalimin e kohës. Për të adresuar këtë problem, paraqitim një strukturë që
përdor sete parametri për të përcaktuar opsionin më të përshtatshëm të përditësimit për një
model të caktuar AME -se.Segmentet e DWH përditësohen në intervale të ndryshme në varësi
të burimit të informacionit në mjedisin e përpunimit të transaksionit online si edhe në
kërkesat e aplikimeve analitike.Shpeshtësia e procesit të ngarkimit të DWH përcakton pik at
e përditësimit midis sistemeve të transaksionit dhe DWH me aplikime analitike. Normalisht,
DWH mbështetet në përditësime statike, me procese ngarkimi në grup që ndodhin çdo ditë,
javë, muaj ose në intervale të rregullta. Sidoqo ftë, nevojat e sotme të AM E-se kërkojnë një
mjedis analitik që siguron
• integrim të vazhdueshëm të të dhënave me periudha më të shkurtra për kapjen dhe
ngarkimin nga burimet operacionale,
• një motor aktiv vendimi që bën rekomandime, dhe
• disponueshmëri e lartë.
Sinkro nizimi i DWH në kohë reale me sistemet transaksionale kërkon kështu reduktimin e
intervalit midis pikave të përditësimit. Për të arritur këtë opsion dinamik, sistemi i databazës
analitike duhet të reflektojë menjëherë përditësimet në të dhënat transaksionale. Fami ljet e

23
ndryshme të algoritmave implementojnë mirëmbajtjen e DWH në kohë reale.Megjithëse këto
algoritma dhe derivatet e tyre të shumta rritin saktësinë dhe performancën, ato nuk marrin
parasysh cili opsion i përditësimit të të dhënave është më i pë rshtatsh ëm për një model AME
të caktuar. Për shembull, kontrolli i te dhenave nga instituti seizmik i Kosoves kërkon marrje
dhe konsolidim të të dhënave në kohë reale, ndër sa kontrolli i regjistrimit civil kërkon
ngarkim të dhënash çdo muaj. Nevoja të ndryshme bashkekzi stojnë në të njëjtin ent te
Agjencionit te emergjencave , duke ndryshuar nëpër departamente të ndryshme. Për më tepër,
jo të gjitha modelet e AME -se kërkojnë sinkronizim të dhënash në kohë real e. E njëjta DWH
duhet të jetë në gjendje të mbështetë disa opsione përditësimi bazuar në një Agjencion te
menaxhimit te fatekesive natyrore ne rrethana teknike të caktuara (Cristina & Ferreira ,2006
:53).
Aplikimet Web Mobile

Ky punim është i ndertuar të jetë i ndarë në 8 kapituj, n ë te cilën përshkruhet struktura si
më poshtë:
Kapitulli 1 paraqet nje hyrje ne problematiken e menaxhimit te emergjencave dhe
fatekeqesive natyrore ,duke paraqitur me theks te veqante komunikimin ndermjet sistemeve
te ndry shme dhe me kete raste edhe integrimin e ketyre sistemeve permes DataWarehouse –
DWH.
Kapitulli 2 jep nje pershkrim te sistemeve DWH dhe problemet qe ai zgjidhe ne mbeshtetje
te vendimmarrjes (DSS).Duke marre per baze hulumtimet shkencore dhe literaturen,esh te nje
paraqitje e sistemeve operacionale dhe informative .Poashtu edhe nje permbledhje
metodologjike dhe arkitekturore qe aplikohet sot ne ndertimin dhe projektimin e DWH.

24
Kapitulli 3 na paraqet nje pasqyre te gjendjes se emergjencave dhe fatekeqesive nat yrore ne
vendin tone dhe me gjere ne Europe ne tri dekadat e fundit .Ne kete kap itull trajtohen edhe
format e integrimit te te dhenave ,ku si rezultat i perparimeve ne teknologjine e informacionit
ka ndikuar aplikimi i sistemeve DWH ,ku edhe behet pershkri mi teorik per vlerat qe sjell
ndertimi i sistemeve te integruara.
Kapitulli 4 vijon me aplikimin e modelit shume dimensional duke ndertuar nje analize te
detajuar te regjistrave te agjencionit te emergjencave,ne te p araqitet hap pas hapi modelimi i
nje datamarti. Ne kuader te ndertimit te datamar -eve kemi edhe indeksimin Para se gjithash
me kete do krijohet nje ide me e qarte se si keto sisteme do ndikojne ne analiza me te thella
ne vendim marrjen strategjike te menaxhimit te emergjencave .
Kapitu lli 5 Me kete raste do te trajtohet edhe ndertimi i proçeseve ETL,ne fakt kjo
konsiderohet njera nga detyrat me esenciale ne ndertimin e nje sistemi DWH. Datastage eshte
në vetvete zgjidhje software -ike të cilat janë përgjegjëse për tërheqjen e të dhënave nga
burime të ndryshme, për pastrimin e tyre, përshtatjen dhe ngarkimin në databazen e
centralizuar DWH
Kapitulli 6 Ne kete kapitull trajtohen ndertimi i DWH qe sinkronizohet ne kohe reale ,qe ka
synim zvogelimin e kohes se replikimit te te dhenave ,pra jepen shpjegime teorike te bazuara
fillimishte ne arkitekturen e DWH ne kohe reale ,por dhe trajtohen ETL si pergjegjes per
terheqjen ,transformimin dhe ngarkimin e DWH
Kapitulli 7 Ne kete kapitull trajtohen zhvillimi dhe aplikimi i web mobile ,duke pas synim
zhvillimin gjuhen programuese Java ,ORACLE,HTML5 dhe CSS .M e kete synohet krijimi
i aplikacionit web mobile duke pasyruar te dhënat nga databaza ne aplikimet web mobile ,siq
eshte rasti i fatekeqsive natyrore .

25

Kapitulli 8 Përmbledh faktorët thelbësorë që ndikojnë në suksesin e këtyre sistemeve. Ne
veqanti ju jep gjitha pyetjeve kerkimore nje pergjigjje konforme pjeses teorike dhe literatures
se perdorur dhe me kete raste nxirret nje perfundim lidhur me ndertimin e DWH .

KAPITULLI II:

Hyrje
Rëndësia e analizës të dhënave është rritur ndjeshëm në vitet e fundit ndërsa organizatave në
të gjithë sektorët u kërkohet që të përmirësojnë proceset e tyre të vendimmarrjes me qëllim
që të ruajnë avantazhin e tyre konkurrues. Sistemet tradicionale të da tabazave nuk i
plotësojnë kërkesat e analizës të dhënave. Ato mbështetin operacionet ditore të një organizate
dhe shqetësimi i tyre kryesor është të sigurojnë qasje të shpejtë të të dhënave në prani të
shumë përdoruesve, e cila bën të nevojshme përpunimin e transaksioneve, kontrollin e
konkurrencës dhe teknikat e rikuperimit që garantojnë qëndrueshmërinë e të dhënave. Këto
sisteme njihen si databaza operacionale ose sisteme të përpunimit të transaksioneve online
(OLTP). Databazat tipike operacionale përmba jnë të dhëna të detajuara, nuk përfshijnë të
dhëna historike dhe meqenëse zakonisht janë shumë të normalizuara, performojnë dobët kur
ekzekutojnë kërkesa komplekse që duhet të bashkojnë shumë tabela relative së bashku ose të
përmbledhin volume të mëdha të dhënash. Për më tepër, kur përdoruesit duan të analizojnë
sjelljen e një organizate si një e tërë, duhet të integrohen të dhënat nga sisteme të ndryshme

26
operacionale. Kjo mund të jetë një detyrë e vështirë për t'u arritur për shkak të diferencave
në përkuf izimin e të dhënave dhe përmbajtjen.
Janë propozuar DWH me qëllim që t'i përgjigjen më së miri kërkesave në rritje të përdoruesve
të vendimmarrjes. Një DWH është një koleksion i të dhënave të orientuara nga subjekti, të
integruara, të pandryshueshme dhe të ndryshueshme në kohë për të m bështetur vendimet e
menaxhimit (Malinowski & Zim´anyi ,2008)
2.1 Koncepti i Data Warehouse (DWH)
Termi Data Warehouse (DWH) është shpikur nga W. H. Inmon: " Data Warehouse është një
grumbullim të dhënash i orientuar nga subjekti, i integruar, i varur nga koha, dhe i pa
ndryshueshëm në mbështetje të procesit të marrjes së mendimeve nga menaxhimi"
Në kontrast me aplikimet On -Line Transaction Processing (OLTP) (Përpunimi i
Transaksioneve -On-Line), mbështetja e vendimit bën disa kërkesa të ndryshme në
teknologjinë e databazës. Data Warehouse (DWH) sigurojnë ruajtje, funksionalitet dhe
shpejtësi për kërkesat që janë përtej kapacitetit të databazave OLTP. Ato përmbajnë të dhëna
historike, të përmbledhura dhe të konsoliduara mundësisht në periudha të gjata kohe.
Përmasat e tyre mund të jenë nga qindra gigabajt deri në qindra terabajt. Ekziston një nevojë
shumë e madhe për t'u siguruar vendimmarrësve në të gjitha nivelet e menaxhimi t
informacione në nivelin e detajeve të dëshiruar, për të ndihmuar vendimmarrjen e tyre.
Përveç kryerjes të aktiviteteve të raportimit të zakonshme të paracaktuara, një numër
përdoruesish paralel po paraqesin kërkesa 'ad hoc', komplekse. Këto kërkesa kërko jnë askes

27
në miliona regjistrime dhe shkaktojnë veprime të shumta skanimi, bashkimi dhe grumbullimi
në DWH (Stolba,2007).
2.2 Historiku i sistemeve në mbështetje të vendimmarrjes (DSS)
Deri në vitet 1980, kompanitë ruanin vetëm informacionin e sistemeve O nline Transaction
Processing (OLTP) në databazat e tyre . Për çdo kërkesë raportimi apo analize mbi të dhënat,
duhej të nxirrej informacioni nga databazat operacionale, nëpërmjet përmbledhjes së tij, nga
raportet që ndërtoheshin mbi të dhënat burim, si figura 2 .1 më poshtë. Sipas kësaj mënyre,
sa më shumë shtohej informacioni aq më të pakëta bëheshin njohuritë.
Figura 2 .1 Vlera e informacionit si funksion i sasisë së të dhënave (Golfarelli & Rizzi ,2009) .

Rritja e vazhdueshme e këtyre dat abazave kërkonte analiza që nevojiteshin për një
vendimmarrje, prandaj lindi nevoja e krijimit të sistemeve të ndërtuar për mbështetjen e
vendimmarrjeve (DSS). Sistemet e mbështetjes së vendimeve kanë ekzistuar shumë më
përpara konceptimit të DWH, shpesh t ë iniciuara nga departamentet e marketing -ut, shitjeve

28
ose dhe financave, ku secili grup i merrte të dhënat që kërkonte nga sistemet e vjetëruara dhe
i vendoste në baza të vogla të dhënash në serverat e tyre lokalë.
Këto zgjidhje zbatoheshin në mënyrë të pavarur dhe pa ndihmën e shërbimeve të
informacionit. Si rrjedhim, rezultatet kishin prirjen të ishin jokonsistente, veçanërisht kur
krahasoheshin me rezultatet e marra nga organizata simotra me sisteme të ngjashme, por
individuale në vendime.
Koncepti i sistemeve DSS përfshin dy fusha kërkimesh:
 Studime teorike të proçeseve të vendimmarrjes në një organizatë
 Studime teknike të ndërlidhjes së sistemeve IT për të ndihmuar vendimet
Nga pikëpamja e arkitekturës, një sistem DSS përfshin një siste m menaxhimi të
informacionit, të bazuar në modele që lidhet me njohuritë dhe gjithashtu shfaqet me një
ndërfaqe grafike interaktive
Sistemet DWH kanë menaxhuar sistemet DSS prej viteve 1990. Ato duhet të nxjerrin
informacionin e duhur nga gjithë ai inform acion sasior i ruajtur në disa sisteme heterogjene.
Në këtë mënyrë mund të gjenerohen shumë analiza komplekse pa ndikuar n ë performancën
e sistemeve OLTP (Juliana ,2014) .
2.3 N evoja për të veçuar sistemet operacionale dhe informative
Sistemi operacional është një sistem që përdoret për të drejtuar një biznes në kohë reale, në
bazë të të dhënave aktuale. Shembuj të sistemeve operacionale janë përpunimi i porosive të
shitjeve, sistemet e rezervimit dhe sistemet e regjistrimit të pacientë ve. Sistemet operacionale
duhet të përpunojnë volume të mëdha të leximit/shkrimit relativisht të thjeshtë të
transaksioneve dhe të sigurojnë përgjigje të shpejtë. Sistemet operacionale quhen gjithashtu

29
sisteme regjistrimi.Sistemet informative janë ndërtuar për të ndihmuar marrjen e vendimeve
në bazë të të dhënave historike dhe të parashikimit. Ato janë ndërtuar gjithashtu për kërkesa
komplekse ose aplikacionet e gërmimit të të dhënave. Shembuj të sistemeve informative janë
sistemet për analizimin e trendit të shitjeve, segmentimit të klientëve dhe planifikimin e
burimeve njerëzore.
Diferencat kyçe midis sistemeve operacionale dhe infor mative janë treguar në Tabelën 2 -1.
Këto dy lloje përpunimesh kanë karakteristika shumë të ndryshme në pothuajse çdo kategori
krahasimi. Në veçanti, vini re se ato kanë komunitete përdoruesish krejt të ndryshme.
TABELA:2 -1 Krahasimi i Sistemeve operacio nale dhe Sistemeve informative (Khan, 2012 ).

Sistemet operacionale përdoren nga shitësit, administratorët, agjentët e shitjeve dhe të tjerë
që duhet të përpunojnë transaksione biznesi. Sistemet informative përdoren nga menaxherët, Karakteristikat Sistemet Operacionale Sistemet informative
Qëllimi kryesor Drejtuar biznesit në një bazë të
tanishme Mbështetur vendimmarrjen
menaxheriale
Lloji i të dhënave Përfaqësimi i fushës së biznesit Shënime me baze te dhenave historike
Përdoruesit kryesor Nënpunësit, shitësat,
administratorët Menaxherët, ekzekutivët, analistët e
biznesit
Fushat e përdorimit Të ngushta,të planifikuara dhe të
reja Të gjerë, ad hoc, pyetje dhe analiza
komplekse
Qëllimi i projektimit Performanca: disponueshmëria Lehtësia e qasjes fleksibile në përdorim
Vëllimi Update -ime të shumta e të
vazhdueshme në rreshtat ose në
disa tabela Update -ime periodike ,që kërkojnë
shumë ose të gjitha rreshtat

30
ekzekutivët, analistët e biznesit dhe (gjithnjë e më tepër) nga klientët të cilët kërkojnë
informacione statusi ose të cilët janë marrësit e vendimeve.
Nevoja për të veçuar sistemet operacionale dhe informative bazohen në tre faktorë kryesorë:
1. Një DWH centralizon të dhënat që janë shpërndarë përmes sistemeve operacionale të
ndryshme dhe i vë ato në dispozicion për aplikacionet që ndihmojnë vendim -marrjen.
2. Një DHW e ndërtuar mirë i shton vlerë të dhënave duke përmirësuar cilësinë dhe
konsi stencën e tyre.
3. Një DWH e veçantë eliminon shumë mosmarrëveshjet për burimet që rezultojnë kur
aplikacionet informative përzihen me përpunimet operacionale (Hoffer & Ramesh.,2011).
2.4 Metodologjia e Zhvillimit të Data Warehouse (DWH).
Bill Inmon dhe Ralph Kimball janë dy liderët kryesorë të metodologjisë brenda fushës DW H
të cilët kanë nisur rritjen e shquar të zhvillimit DW në dhjetëvjeçarin e fundit. Gjatë dhjetë
deri pesëmbëdhjetë vjetëve të fundit, metodologjitë e tyre kanë krijuar një qendër soli de Data
Warehouse (DWH) të ngulitura me sukses.
Sipas Inmonit Data Warehouse (DWH) është ndërtuar në një model përsëritës, nga DWH të
ndërmarrjes në data bazat e departamenteve, duke përdorur një mjet databaze relativ të
zakonshëm për t'i shërbyer shumicës të nevojave për marrjen e vendimeve. Inmoni thekson
tre premisat bazë për ndërtimin e Data warehouse.

31
 E para është normalizimi i të dhënave dhe përkufizimi i metadatave për modelimin e
të dhënave dhe proceseve siç është e zakonshme në zhvillimin e sistemit të
menaxhimit të databazave.
 E dyta është të ndihmohen vendimet e përdoruesve finalë duke përdorur k ërkesa
arbitrare në databazë.
 E treta është pastrimi dhe unifikimi i të dhënave në fazën e përgatitjes të të dhënave
(skenimi i të dhënave) për transformimin e të dhënave operacionale në të dhëna për
qëllime 'informative'.
Zhvillimi i DWH të synuar përfshin një numër detyrash duke filluar me një analizë të
madhësisë/copëzimit, e cila përfshin tre nivele copëzimi: atomike, departamentesh dhe DW
individuale
Sipas Kimballit përdoret një metodë e nxitur nga kërkesa; kjo fillon me planifikimin e
projektit për vlerësimin e gatishmërisë, studimit dhe justifikimit.
Qasja e Kimballit është e tipit nga poshtë lart, e cila e vë analizën e kërkesave të biznesit në
krye të fazave të zhvillimit të saj. Arkitektura e Kimballit formon DWH të ndërmarrjes me
anë të ar kitekturës bus që grumbullon 'data marts' në bazë të dimensioneve dhe fakteve të
vërtetuara. Secili data mart përfaqëson një proces biznesi në organizatë me anë të modelimit
dimensional (p.sh. skema yll). Modelet e ndërtimit dimensional përfshijnë një proc es me
katër hapa:
 zgjedhja e procesit të biznesit duke filluar me procesin me ndikimin më të madh,

32
 deklarimi i njësive i cili shërben për të vendosur se çfarë niveli detajesh do të
përmbajë DWH,
 zgjedhja e dimensioneve dhe
 identifikimi i fakteve.
Pastaj zhvillohet një ndërtim fizik, duke i kushtuar vëmendje strategjive të përmbledhjes dhe
indeksimit. Për qëllime funksionaliteti, krijohet një strukturë analitike e qëndrueshme që
përmbush kërkesat analitike të përdoruesit. Tabela e cila thjeshton diferenca t kryesore midis
qasjeve të Inmonit dhe Kimballit.
Tabela:2 -2 Qasja sipas Inmon -it dhe Kimball -it .
Inmon Kimball
Qasja sipas
emrit
Waterfall,CIF,Hub and Spoke Data mart, arkitekturës bus
dhe dimensioneve
Kërkesat
biznesore Top down
Bottom Up
Modeli DW Modeli ER
Modeli Shumedimensional
Qasja e
zhvillimit Qasja operative per zhvillimin e DB te
departamenteve nga EDW
Grumbullon data marts në bazë
të dimensioneve dhe fakteve .
Pjesemarrja
kryesore Profesioniste te IT -se Perdoruesit fundor

Ndërkohë , rritja e vazhdueshme në adoptimet DWH ka rritur ndërgjegjësimin e studiuesve
dhe zhvilluesve për të propozuar dhe zhvilluar metodologji të reja që komprometohen dhe

33
shkëmbehen -midis Inmonit dhe Kimballit ose madje përshtatin teknika dhe/ose arkitektura
të reja.
2.5 Arkitektura e sistemeve te DWH
Koncepte të shumta arkitekturore janë prezantuar dhe diskutuar me kalimin e kohës, të cilat
nxjerrin një numër idesh dhe pikëpamjesh. Janë propozuar arkitektura DW H konceptuale
në mënyra të ndryshme, ato klasifi kohen zakonisht në tre grupe sipas numrit të niveleve, nëse
është arkitekturë me një nivel, dy nivele ose tre nivele.
 Në një arkitekturë me një nivel , të quajtur zakonisht si magazinë të dhënash
virtuale, çdo pjesë të dhënash ruhet njëherë, ndërsa një niv el 'i mesëm' vepron si ndër
faqe midis përdoruesve dhe databazave operacion ale pa asnjë DWH aktuale, por
stimulohet duke përdorur shikimet. Kjo lloj arkitekture karakterizohet nga zhvillimi
i shpejtë me kosto të reduktuara, dhe krijon nevojën që aktivitete t e planifikimit (p.sh.
identifikimi i të dhënave bur im, transformimi i të dhënave etj.) të bëhen për çdo
kërkesë. Gjithashtu ka një mungesë të historizimit të të dhënave dhe një kohë aksesi
mjaft të paparashikueshme për përdoruesin final.
 Nga ana tjetër , arkitekturat me dy nivele veçojnë të dhënat burim (niveli i parë)
nga të dhënat e nxjerra ose niveli i dytë i arkitekturës. Të dhënat e nxjerra mund të
jenë qoftë një kopje e thjeshtë e të dhënave burim ose të marra prej tyre nga ndonjë
proces nxjerrjeje /përmbledhjeje. Ky lloj është praktik, veçanërisht kur burimet
operacionale janë homogjene. Në kontrast me këtë, ka dyfishim të konsiderueshëm
të dhënash pasi çdo aplikim i ndihmës për vendimmarrje ka kopjen e vet të të dhënave
të nxjerra zakonisht.

34
 Arkitektura me tre nivele përbëhet nga niveli i të dhënave operacionale, niveli i të
dhënave të bashkërenduara dhe niveli që mbës htet të dhënat e vendimmarrjes (Arwa
,2011)
Arkitekturat standarte që përdoren në ndërtimin e sistemeve DWH, së bashku me shtre sat
bazë që secila arkitekturë ka në përmbajtjen e saj mund te paraqitet ne tabelen e
meposhteme

Tabela 2 .3 Elementët e arkitekturave p ër ndërtimin e sistemeve DWH (Juliana ,2014) .
Shtresa e
Burimeve Shtresa Stage e
Rakordimit Shtresa e
DWH/Datamart
Arkitektura me një
Shtresë

X

Arkitektura me dy
shtresa

X
X

Arkitektura me tre
shtresa

X
X
X

Ku nga tabela më sipër:
1- Shtresa e burimit përfaqëson burimet e informacioni, të cilat mund të jenë databaza
relacionale të kompanisë, skedare të tipeve të ndryshëm ose të dhëna të marra nga një
aplikacion i jashtëm.
2- Shtresa „Stage‟ . Të dhënat e marra nga burimet e ndryshme, duhet të
pastrohen,transformohen dhe përshtaten në mënyrë të tillë, që prej tyre të ndërtohet një skeme

35
e vetme dhe e përbashkët të dhënash. Kjo shtresë krijohet në rastin kur proçeset ETL ruajnë
informacione në da tabaza fizike.
3- Shtresa DWH/Datamart. Informacioni që mblidhet nga të gjitha burimet,ngarkohet në
një sistem të vetëm të centralizuar, apo datamart (Juliana ,2014) .
Nxjerrja e të dhënave për mbështetjen e vendimmarrjes kryhet në dy faza:
 Faza e pare int egrimi i të dhënave operacionale dhe
 Faza e dyte nxjerrja e të dhënave të mbështetjes të vendimmarrjes nga burimet e
integruara.
Sen sugjeron llojet arkitekturore DW H të zakonshme :
o Lloji i parë është data -mart i pavarur i cili sugjeron data -marte të ndryshme për
funksione të ndryshme biznesi. Megjithëse kjo qasje ndan të njëjtën ETL për burimet
e zakonshme të të dhënave, nuk jep asnjë version të së vërtetës, e cila e bën të vështirë
të analizohen të dhënat në data -marte.
o Lloji i dytë është DWH e centralizuar me data -marte të pavarura (Hub &Spoke). kjo
arkitekturë përdor shikimin e sipërmarrjes të të dhënave; zhvillohet në një mënyrë
përsëritëse ku një fushë subjekti ndjek tjetrën. Da ta-martet e pavarura zhvillohen për
qëllime departamenti, funksionale ose speciale; këto data -marte marrin të dhëna nga
magazina.
o Lloji i tretë është DWH e centralizuar pa data -mart të pavarur. Kjo arkitekturë është
e ngjashme me atë të mësipërmen por pa data-marte të pavarura.
o Lloji i katërt është arkitektura DW virtuale, e cila nuk përfshin ndërtimin DW tipik;
në vend të kësaj përdor një 'program urë' për të përdorur të dhënat operacionale. Kjo
arkitekturë rekomandohet për firmat që nuk duan të rindërto jnë.

36
o Lloji i fundit është arkitektura bus e data -marteve me data -marte dimensionale të
lidhura.
Për çdo proces të caktuar biznesi, ndërtohet një data -mart me përdorimin e dimensioneve të
konfirmuara për të siguruar data -marte të integruara në mënyrë logj ike dhe nj ë pamje
ndërmarrje e të dhënave (Arwa ,2011) .

Konkluzion
Një sistem i DWH ofron qasje të efektshëm në informacionet e përmbledhura të cilësisë të
lartë që ndihmojnë menaxhimin për vendim -marrje më të mirë. Një DWH lejon që
menaxhimi të njohë tendencat kyçe dhe të parashikojë rezultatet e pritura. Gjithashtu lejon
menaxhimin të k uptojë shkaqet dhe pasojat e asaj që ka ndodhur tashmë, e cila në këmbim i
ndihmon organizatat të jenë më konkurruese dhe të përmbushin më shpejt kërkesat e tregut.
Sipas Benmecchiche dhe Chouinard, dobia më e madhe e mundshme e një DWH ndodh kur
i jep men axhimit një botëkuptim logjik të ngjarjeve të tyre, e cila lehtëson përgjigjet e
vendim -marrësve të rindërtojnë një proces menaxhimit te emergjencave ,të një organizate
dhe të mbështetin objektivat strategjike të QOAME për dobinë e tyre.

37
KAPITULLI III: Aplikimi i sistemeve të DWH ne rastin e emergjencave dhe
fatkeqësive natyrore

3.1 Hyrje

Në ditët e sotme më shumë se kurrë shohim nevojën për të ndërtuar një sistem institucional
të koordinuar me të gjitha burimet e disponueshme dhe kapacitetet e planifikuara për një
reagim të menjëhershëm në raste të katastrofave natyrore dhe incidenteve të tjera. Është koha
që të punojmë në një mënyrë më gjithëpërfshirëse për të koordinuar përpjekjet tona në
menaxhimin e përgjigjeve kundrejt situatave të emergjencës përfshirë katastrofat natyrore,
incidentet me rrezik të lartë, terrorizmi dhe incidente të tj era të shkaktuara nga qeniet
njerëzore.
Me fjalë të tjera, ky sistem është një qasje sistematike drejt udhëheqjes dhe përgatitjes më të
mirë të gjitha agjencive dhe departamenteve përkatëse në të gjitha nivelet e qeverisjes, dhe
institucioneve të tjera joqeveritare që t'i shërbejnë qytetarëve më së miri në këto emergjenca,
pavarësisht kompleksitetit, shtrirjes, vendit apo shkakut. Incidentet dhe katastrofat natyrore
nuk njohin kufij. Implementimi i këtij sistemi ofron një zgjidhje të koordinuar komunikimi
dhe ushtrim të avancuar në fushë në nivel shtetëror. Për më tepër, ky sistem do të çojë në
bashkëpunim më t ë mirë rajonal dhe ndërkombëtar (SIME ,2010).
3.2 Gjendja e emergjencave dhe fatkeqësive natyrore në vendin tone
Tre rreziqet kryesore natyrore që Kosova u nënshtrohet janë tërmetet, vërshim et dhe zjarret
pyjore. Veç këtyre rreziqeve, rrezik i konsiderueshëm gjithashtu paraqitet nga rrëshqitjet e
tokës,thatësira, rëniet e mëdha të borës dhe plasja e pendëve të rezervuarëve të ujit. Për më

38
tepër, ekzistojnë edhe fatkeqësi mjedisore të shkaktuar a nga ish fabrika e plumbit në
Mitrovicë, në të cilën erërat e fuqishme dhe stuhitë kontribuojnë në ndotjen e ujit të pijes dhe
kontaminimin e ushqimit, me pasoja siç janë sëmundjet dhe epidemitë. Këto rreziqe përbëjnë
një kërcënim të përhershëm për qyteta rët e Kosovës.
Nisur nga kjo , për qëllim analiz e është shqyrtuar gjendja aktuale lidhur me kapacitetet e
komunave për intervenime në raste em ergjente, qoftë në kuadrin ligjor, qoftë kapacitetet
teknike dhe njerëzore , që dispono hen nga institucionet relevante dhe përgatitjen e vendit tonë
për menaxhimin e emergje ncave. Kur kësaj i shtohet edhe mungesa e analizave të kësaj
problematike qoftë nga inst itucionet, qoftë nga mekanizmat tjerë joqeveritar , ne e
konsiderojmë të nevojshme vështrimin e kapaciteteve institucionale dhe nevojave të
institucioneve relevante pë r reagime në situata emergjente ( Forumi për siguri ,2013).
3.2.1 Analizimi i te dhenave ne rastin e tërmeteve
Për këtë dëshmojnë qartë tërmetet që kanë ndodhur në të shkuarën e largët dhe të afërt, kështu
mund të përmendim. Sipas Institutit të Sizmologjisë në Ministrinë e Zhvillimit Ekonomik
(MZHE), çdo dite ndodhin tërmete, por me një intensitet shume të ulet ku rse tërmetet qe
ndodhin mbi 3.5 shkalle te Riterit siç paraqiten ne tabelën

Tabela 3.1 Te dhena historike te rastit te termeteve (Instituti Seizmik, 2012) .

Emri i Regjionit Data Magnituda
Prizren 16 Qershor 1456 6.0
Pejë 11 Nëntor 1662 6.0

39
Ferizajt 26 Shkurt 1755 6.1
Kopaonikut 18 Maj 1980 5.7
Gjilanit 24 Prill 2002 5.7
Istogut 10 Mars 2010 5.2
Ferizaj -Vitisë 10 Gusht 1921 6.1

Nga te dhenat e tabeles 3.1 kemi te dhena historike te rastit te termeteve ,por per keto
ngjarje te fatekeqsive natyrore siq jane termetet duhet te kemi te dhena ne kohen reale .
Nga Instituti i Sizmologjisë kemi te dhena kryesishte mujore “ Buletin Mujor ”,si qe
paraqiten ne tabelat e meposhteme .

Tabela 3.2 . Instituti Seizmik i Kosoves -ISK, Buletini Mujore (Mars 2010) (Instituti Seizmik,
2012) .
Data Koha Vendi M Lat Long Depth
10.03.2010 13:38:03.1
13:44:41.8
14:13:20.9
15:32:43.2 Kosovë
Kosovë
Kosovë
Kosovë 5.2
1.8
1.9
2.2 42.76
42.75
42.69
42.65 20.62
20.63
20.58
20.95 5.22km
5.00km
18.83km
Unknown
11.03.2010 04:33:54.9
08:59:19.4 Kosovë
Kosovë 1.5
3.3 42.73
42.74 20.58
20.60 16.06km
Unknown
12.03.2010 14:28 :16.1
Kosovë
1.3
42.47
20.67
Unknown

13.03.2010 01:54:00.3 Kosovë 1.8 42.72 20.57 6.28 km

40

Tabela 3.2. Instituti Seizmik i Kosoves -ISK, Bu letini Mujore (Nentor 2013) (Instituti
Seizmik, 2012) .
DATA KOHA LAT LONG DEPTH M VENDI
01.11.2013 14:11:17.8. 42.644 21.02 2 km 1.6 Kosovë
01.11.2013 14:50 :25.2. 43.085 20.89 Unknown 1.5 Kosovë
01.11.2013 18:42:07.3. 42.475 20.41 16 km 1.6 Kosovë
16.11.2013 07:42:34.4. 42.869 21.025 Unknown 2.9 Kosovë
16.11.2013 07:44:01.0. 42.871 21.005 1 km 2.4 Kosovë
17.11.2013 08:14:14.0. 42.864 21.011 10 km 3.7 Kosovë
17.11.2013 14:27:52.0. 42.102 20.656 8 km 2.3 Kosovë
17.11.2013 14:48:19.3. 42.837 20.991 Unknown 1.6 Kosovë
17.11.2013 23:58:53.2. 42.859 21.001 4 km 2.8 Kosovë
18.11.2013 11:23:39.7. 42.765 21.055 Unknown 1.5 Kosovë
18.11.2013 13:15:03.3. 42.863 21.014 4 km 4.8 Kosovë
18.11.2013 13:28:05.8. 42.901 21.023 1 km 1.5 Kosovë
18.11.2013 13:30:04.2. 42.883 21.031 2 km 1.6 Kosovë 13:53:44.5 Kosovë 1.5 42.76 20.61 15.28km
15.03.2010 21:37:40.5 Kosovë 2.1 42.44 20.90 14.04km
18.03.2010 02:48:10.9 Kosovë 1.6 42.71 20.60 9.99 km
26.03.2010 07:46:10.8
07:46:33.8 Kosovë
Kosovë 1.8
1.8 42.71
42.71 20.58
20.57 17.18km
17.10km

41
18.11.2013 13:35:50.7. 42.849 21.001 1 km 2 Kosovë
18.11.2013 13:42:25.2. 42.877 21.027 10 km 3.5 Kosovë
18.11.2013 14:42:25.2. 43.209 20.698 Unknown 1.8 Kosovë
18.11.2013 15:24:27.6. 42.905 21.064 6 km 1.8 Kosovë
18.11.2013 16:49:24.0. 42.857 21.016 Unknown 1.7 Kosovë
18.11.2013 20:31:07.5. 42.838 20.998 Unknown 1.5 Kosovë
18.11.2013 23:28:34.3. 42.386 21.561 Unknown 1.5 Kosovë
19.11.2013 01:37:14.5. 42.86 21.052 Unknown 1.6 Kosovë
19.11.2013 03:39:49.9. 42.865 21.061 5 km 2.2 Kosovë
19.11.2013 06:31:00.6. 42.879 21.062 Unknown 1.6 Kosovë
19.11.2013 16:51:09.0. 42.812 21.02 Unknown 1.9 Kosove
19.11.2013 20:35:06.5. 42.795 21.081 Unknown 1.5 Kosovë
19.11.2013 21:14:16.0. 42.853 21.054 Unknown 2 Kosovë

Keto raportime te te dhenave nga ISK behen mbi baza mujore ,e qe ne fakte nevoja per
informacione eshte e nevojshme te jene ne kohen reale . Në të njëjtën kohë duhet të
përmendim se territori i Kosovës është prekur mjaft herë me pasoja të rënda edhe nga tërmetet
e ndodhura në vendet fqinje me të, si p.sh., tërmetet e ndodhura në territorin e Shqipërisë,
Malit t ë Zi, Maqedonisë, etj.
3.2.2 Rasti i zjarreve pyjore
Pyjet mbulojnë një pjesë të konsiderueshme të Kosovës – sipas disa burimeve deri në 43 për
qind të territorit mbulohet me pyje dhe shkurre, dhe këto zona janë veçanërisht të prira nda j
zjarreve pyjore në fund të pranverës dhe gjatë muajve të thatë të verës (Faulkner,2011).

42
Zjarret në pyje dhe kullota shpesh janë ngjarje të një shkalle më të vogël, në krahasim me ato
që kanë ndikim dramatik mbi jetën dhe pronën. Përjashtim bëjnë zjarret që mbulojnë
sipërfaqe të mëdha shkurresh ose pyje ku përfshihen edhe zona të banuara, pasi këto të fundit
mund të shkaktojnë shkatërrim në një zonë të gjerë.
Si rezultat, zonat specifike të rrezikut janë lehtësisht të identifikueshme, ndërkohë që
paranda limi, lehtësimi, mbrojtja dhe parapërgatitja janë të mundura dhe mund të kenë efekte
të ndjeshme për uljen e rrezikut.Në rastet e zjarreve që përfshijnë sipërfaqe të tëra, është
shumë e vështire për t’u kontrolluar,qofshin këto zjarre të shkaktuara nga nje rëzit ose zjarre
natyrore drejtimi dhe forca e erës janë faktorë te veqante në pa parashikueshmërinë e tyre.Në
vendin tonë, rreziku më i madh i zjarreve të pyjeve është evident në fund të pranverës dhe
gjatë periudhave të verave të that a [27]
Që prej vitit 2000 ka pasur një numër në rritje të zjarreve pyjore. Zjarrfikësit dhe ekipet tjera
relevante operacionale kanë kryer në mes të 2,000 e 3,000 intervenimesh për secilin vit
pasues ,ne vijim paraqesim te dhenat e vitit 2006 nga Sherbimi i zjarrefikseve te Kosoves –
SHZK (Faulkner,2011) .
Tabela 3.2 Te dhenat e vitit nga Sherbimi i zjarrefikseve te Kosoves -SHZK( 2006)
Komun
a Data e
Aksidentit Nr.i
zjarreve Sherbime Aksidente
Rrugore Vershime Të vdekur Të
lenduar
Prishtin
a 2006 911 276 78 62 1 12
Gjilani 2006 712 213 35 41 1 0
Prizreni 2006 575 274 78 26 7 8

43

3.2.3 Analizimi i te dhenave tek Instituti Hidro‐meterologjike -Rasti i vërshimeve

Në vitin 1973 qyteti i Ferizajt ishte goditur nga një vërshim i ashpër i cili dëmtojë pjesën
jugore të qytetit 1, mirëpo vërshimet pati edhe ne komunën e Pejës gjate vitit 2013. Janë
vetëm disa nga shembujt ku vendi jonë është ballafaquar me situata emergjente te vershimeve
(Armenv & Hachim & George ,2011).
Nese marrim te dhenat e s tacioneve meteorologjik e ne Peje ,Prishtine dhe Ferizaj te vitit 2012
– vlerat mesatare mujore te elementeve dhe dukurive meteorologjike jane te paraqitura si me
poshte (Faulkner,2011).
Tabela 3.2 Te dhenat e Stacionit meteorologjik ne Peje (Instituti hidrometeorologjike ,2014).
Mitrovi
ca 2006 545 265 18 21 1 4
Peja 2006 653 148 15 22 2 2
2012 I II III IV V VI VII VIII IX X XI XII m.vjet.
Tmax . 2.7 0.2 14.1 17.2 21.1 28.9 32.1 32.6 22.6 18.1 16 6.4 17.7
Tmin. -4.9 -7.5 1.3 5.1 9.8 14.2 17.5 16.3 11.8 7.9 5.3 0.6 6.4
Tmes. -1.5 4.1 7.6 11.8 16.3 23.1 25.3 26.0 16.8 11.6 8.5 4.1 12.8
Lagësh
% 89 86 83 79 73 72 59 53 72.1 86 83 87.3 76.8
Shty.atm 943.6 948.3 940.2 946.3 951.2 956.8 961.7 963.1 958.3 955.4 952.8 953.2 952.5
Era/ms. 1.2 1.8 1.6 1.9 1.3 0.8 1.2 0.9 0.8 1.4 1.3 1.1 1.3
Reshje. 121.6 41 13.2 58.4 96.3 5.8 40.6 0.3 24.7 34.5 65.4 70.3 572.1

44
Tabela 3.3 Te dhenat e Stacionit meteorologjik ne Prisht ine (Instituti hidrometeorologjike
,2014).

Tabela 3.4 Te dhenat e Stacion it meteorologjik ne Ferizaj (Instituti hidrometeorologjike
,2014).

Nga keto te dhena përfshihen nivelet e reshjes, sasinë e borës në malet e larta, rrjedhën e
lumenjëve, nivelet e ujërave nëntokësore dhe nivelet e mundësive akumuluese të liqeneve.
Të gjitha këto variabla duhe t të monitorohen vazhdimisht dhe të raportohen nga qendra tek
QOAME q ë ka përgjegjësi për monitorimin kombëtar të përmbytjeve.
Për këtë, ai regjistruesi automatik i të dhënave në stacionin matës duhet që të jetë i lidhur me
rrjetin telefonik (mobil) GPRS. 2012 I II III IV V VI VII VIII IX X XI XII m.vjet.
Tmax. 2.3 0.0 13.6 16.8 20.7 28.5 31.7 31.8 27.6 21.6 14.1 3.0 17.6
Tmin. -5.2 -7.9 1.1 4.9 9.4 13.7 16.6 15.0 12.1 7.5 4.7 -3.0 5.7
Tmes. -1.7 3.7 7.1 11.1 15.5 22.2 24.9 24.2 20.0 13.8 8.6 -0.6 12.4
Lagësh% 83 81 62 68 66 57 54 47 58 68 79 86 67.4
Shty.atm 945.7 945.5 950.4 939.4 944.5 947.2 946.8 948.5 947.5 945.8 947.4 943.2 945.9
Era/ms. 1.8 2.2 2.2 2.6 1.9 1.2 1.6 1.3 1.4 1.5 1.5 1.7 1.7
Reshjet. 105.7 36.1 12.8 51.5 102 6.2 53.3 3.9 13.7 60.4 29.6 65.9 541.1
2012 I II III IV V VI VII VIII IX X XI XII m.vjet.
Tmax. 1.9 0.2 12.6 16.4 20.0 27.9 31.9 31.0 26.2 20.9 12.7 2.4 17.0
Tmin. -5.7 -7.4 0.6 4.2 8.7 11.9 15.2 14.6 11.7 7.0 -4.4 -3.1 4.4
Tmes. -2.2 -3.1 6.8 10.5 14.4 21.1 24.2 23.8 18.7 13.2 7.8 -0.6 11.2
Lagësh% 87 83 66 71 75 65 60 53 68 78 87 88 73.4
Shty.astm, 946.0 945.5 951.0 939.5 944.3 947.5 947.1 48.9 942.7 945.9 947.6 943.6 870.8
Era/ms. 1.2 2.4 1.4 1.9 1.4 1.2 1.8 0.9 1.4 1.1 1.8 1.8 1.52
Reshjet. 67.4 41.7 17.1 64.5 132.5 3.8 14.1 48.2 26.6 27.9 30.7 50.8 525.3

45
E gjithë literatura mbi praktikën më të mirë së i përket menaxhimit të përmbytjeve konfirmon
dy parime thelbësore:
o Të dhënat hidro ‐meteorologjike duhet që në mënyrë konstante të monitorohen në
mënyrë që të zbulohet fillimi i një situate të thatësirës
o Duhet të ekzistojnë nivele të qarta të alarmimit (varësisht nga statusi i të dhënave
hidro‐meteorologjike) në bazë të të cilave mund të ndërmerren veprime të ndryshme
për zbutjen e kësaj situate .
Nga pikëpamja menaxhuese, ky lloj i përmbytjeve shpesh mund të jetë i parashikuar që më
parë (30‐10 ditë), duke e lejuar zbatimin e masave lehtesuese POR përmbytjet mund të
vazhdojnë për shumë ditë apo javë, e që mund të bllokoj infrastrukturën komunikuese
(energjinë, telekomunikacionin dhe transportin) dhe si pasojë e kësaj të ketë nevojë për
kërkesa të mëdha sociale në lidhje me in frastrukturëën (evakuimi, shpëtimi dhe shërbimet
mjekësore dhe strehimi i të zhvendosurve) (Faulkner,2011) .

3.2.4. Rasti i Orteku te borës , që kushtoi me jetë njerëzi sh në fshatin Restelicë ne vitin
2011 ( Forumi për siguri ,2013). Në Kosovë shumica e reshjeve dimrore bie si borë, dhe kjo
akumulohet në malet e larta. Ky akumulim përfaqëson një formë të magazinimit/akumulimit
të ujit, dhe për këtë arsye monitorimi i kësaj variable në të vërtetë është shumë i rëndësishëm
dhe është një mekanizëm parashikim i afat‐gjatë. Shtresat e borës mund të maten çdo javë me
përdorimin e një matësi shumë të thjeshtë të monitoruar nga vëzhguesi (shiko Figurën 4 ‐1).
Për shembull, një nivel i ulët i shtresës së borës gjatë muajve Dhjetor ‐Mars do të rezultojë
në:

46
a) Prurje më të ulëta se normala në Dhjetor deri Mars
b) Sasi të mëdha të borës së shkrirë gjatë Prillit dhe Majit
Prandaj thellësitë e borës më të larta se mesatarja janë një tregues i mirë i mundësisë së
zhvillimit të përmbytjeve gjatë muajve pranveror.
Institu ti Hidro‐Meteorologjik i Kosovës (IHMK) duhet të konsiderojë me seriozitet
instalimin e disa matësve të thellësisë së borës në malet e grykë derdhjeve të lumenjëve
kryesor. Këto do të duhej të lexoheshin vetëm në baza javore nga një Observues i trajnuar,
dhe zakonisht vetëm për muajt nga Shkurt ‐Prill.
Një nga shembujt më të mirë të një sistemi të tillë është ai i Institutit Hidrometeorologjik
Çek. Ky sistem on ‐line paraqet të dhëna reale nga rrjeti hidro ‐meteorologjik në faqen e
internetit të Institutit (shiko Figurën 3 ‐1). Është e mundur për të kontrolluar statusin e çdo
stacioni të vetëm duke përdorur faqen e internetit. Ky lloj i burimit të informacionit online
në kohë reale mund të përdoret nga shumë menaxherë të ujit për të marrë vendime
afatshkurtra operative .
Figurën 3 ‐1 Sistemi Informativ Hidro ‐meteorologjik Çek (Faulkner, 2011) .

47
Sistemi Informativ Çek i ujit jo vetëm që siguron informacion në kohë reale, por ofron një
arkiv të trendeve të prurjeve të cilat janë të rëndësishme në atë se tregon se si përmbytjet (ose
thatësirat) mund të zhvillohen. Analiza e trendeve është shumë e rë ndësishme në
parashikimin e periudhave të ardhshme të përmbytjeve.E rëndësishme poashtu është që
tregohet statusi i prurjeve në raport me nivele të ndryshme të emergjencës së përmbytjes (ose
thatësirës), kështu që është e lehtë për të identifikuar nëse pru rja e lumit është në një gjendje
të normalitetit, alarmimit, emergjencës etj. Pasi sistemet GPRS të llojit telemetrik të futen në
rrjetin hidro ‐meteorologjik të Kosovës, procesimi i këtyre të dhënave për të siguruar informata në
kohë reale e të sakta duhet të bëhet prior iteti i IHMK. Ne mund të përfundojmë duke thënë se paraqitja
e rregullt e të dhënave hidrometeorologjike në një mënyrë të lehtë të qasjes dhe format të lehtë për
t’u kuptuar është një komponent i rëndësishëm i gatishm ërisë së mirë ndaj përmb ytjeve.
Aktualisht, IHMK operon me një numër të paisjeve ‘automatike’ matëse të reshjeve
(përafërsisht 12). Këto paisje regjistrojnë të dhënat vetëm në një regjistrues të dhënash që
pastaj duhet të shkarkohet në terren. Ky proces nuk është i volitshëm për paralajmërim të
emergjencës së përmbytjes dhe ne kemi propozuar avancimin e pasijeve aktuale në sistemin
e ‘gjendjes telemterike’ me anë të përdorimi t të sinjalit GPRS . Transmetimet automatike të
të dhënave mbi reshjet në një qendër kontrolli patjetër që do të ofronte një mundësi të
paralajmërimit të hershëm mbi kon ditat e mundshme për përmbytje (Faulkner, 2011).

3.3 Analizimi i te dhënave ne rastin e emergjencave dhe fatkeqësive natyrore .
Katastrofat e mëdha kanë shënuar dhe formësuar historinë e njer ëzimit. Ato nuk janë ngjarje
vetëm të shekullit të fundit. Që nga kohët parahistorike e deri më sot shumë ngjarje kanë lënë
shenjë si në ndikimin fizik mbi planet ashtu edhe në kujtesën e njerëzve.

48
Një nga dallimet e rëndësishme në përcaktimin e madhësisë së një katastrofe është nëse
diskutojmë për numrin e viktimave. Shumica e studimeve mbi katastrofat janë të fokusuara
kryesisht në dy shekujt e fundit dhe sidomos në dekadat e fundit
Duke analizuar me kujdes tri dekadat e fundit ne Evrope (1980 -2014), të p araqitura në Tabela
3.2 vihet re fakti që trendi i katastrofave natyrore është ne rritje,
Tabela 3 .2 – Katastrofat natyrore në tri dekadat e fundit (1980 -2014) (http://www.emdat.be)
Vitet Fat. Natyrore Nr. rasteve Humbje te njerëzve Të prekurit
1980 -2014 Tërmetet 105 33159 3305601
1980 -2014 Vala e të ftohtit 153 5778 1386133
1980 -2014 Vala e të nxehtit 60 134397 2120
1980 -2014 Stuhitë 414 2347 8759900
1980 -2014 Përmbytjet 497 3356 13193747
1980 -2014 Thatësira 40 2 10488769
1980 -2014 Zjarret 98 502 1295600
1980 -2014 Epidemitë 45 440 189556
nëse analizojmë dëmet e shkaktuara nga katastrofat për të njëjtën periudhë, katastrofat
natyrore shkaktojnë shumë më tepër dëme se ato me natyrë njerëzore.
Tabela 1.2 paraqet humbjet nga katastrofat me natyrë njerëzore për periudhën 1980 -2014.
Tabela 1. 2 – Katastrofat natyrore – Fatkeqësitë Teknologjike
Burimi: http://www.emdat.be/
Vihet re që dëmet më të mëdha shkaktohen nga ngjarje natyrore me natyrë: meteorologjike,
hidrologjike dhe gjeofizike (Tërmetet , Vala e të ftohtit , Vala e të nxehtit, Stuhitë, Përmbytjet,
Thatësirat, Zjarret, Epidemitë etj.) (Lito ,2013) ,siç shihet ne Grafiku 3 .1
Vitet Fat. Teknologjike Nr. rasteve Humbje te njerëzve Të prekurit
1980 -2014 Fat. Teknologjike 812 26445 308533

49
Grafiku 3 .1 Përmbledhje e katastrofave natyrore 1980 -2014

Nisur nga kjo , për qëllim analiz e është shqyrtuar gjendja aktuale lidhur me kapacitetet e
komunave për intervenime në raste em ergjente, qoftë në kuadrin ligjor, qoftë kapacitetet
teknike dhe njerëzore , që dispono hen nga institucionet relevante dhe përgatitjen e vendit tonë
për menaxhimin e emergje ncave. Kur kësaj i shtohet edhe mungesa e analizave të kësaj
problematike qoftë nga institucionet, qoftë nga mekanizmat tjerë joqeveritar , ne e
konsiderojmë të nevojshme vështrimin e kapaciteteve institucionale dhe nevojave të
institucioneve relevante për reagime në situata emergjente ( Forumi për siguri ,2013). Qëllimi
i teknologjisë se informacionit është të lehtësojë shkëmbimin e informacionit dhe të
komunikimit në mesin e organizatave të shumta dhe agjencive (Kristi na, 2004).
Sistemet e informacionit janë një faze e rëndësishme në planifikimin dh e përgatitjen për
fatkeqësitë (Sriganesh &Iyer) . Në një situatë emergjente , informacioni përkatës në lidhje me 33159
5778134397
2347 33562 502 440 020000400006000080000100000120000140000160000
Tërmetet Vala e të
ftohtit Vala e të
nxehtitStuhitë Përmbytjet Thatësira Zjarret EpidemitëHumbje te njerëzve gjatë periudhës 1980 -2014

50
elementet e përfshira është i nevojshëm. Për më tepër , procesi i menaxhimit të emergjencave
është dinamik dhe p ërfshin disa hapa të caktuar (Tanasescu & Gugliotta,2006:956).
3.4 Burimi i të dhënave kryesore te QOAME -se
Qendra Operative e Agjencioni t te memaxhimit te Emergjencave disponojnë një sasi të
mëdha të dhënash. Mund të jetë njeri nga sektoret, i cili për vetë funksionet që kryen dhe
platformat që zotëron, ruan më shumë informacion s e çdo tip tjetër industrie (Juliana ,2014) .
Pra Qendra Operative e tillë ka shumë burime informacioni, por janë disa kategori të cilat ne
do të trajtojmë në zgjidhjet vijuese:
1-Te dhenat e Agjencioni i Regjistrimit Civil –ARC , qe permbajne informacione nga
regjistrimi i popullsis duke pe rfshi shenimet bazike si:
Mbiemri ,Emri ,Mbiemri i vajzërisë ,Vendi i lindjes ,Komuna e lindjes ,Shteti i
lindjes ,Data e lindjes ,Gjinia ,Gjatësia ,Grupi i gjakut ,Statusi
martesor ,Komuna ,V endi ,Rruga ,Nr i ndërteses ,Nr i apartamentit ,Fotografia e
personit ,Shenjat e gishtrinjëve ,Nenshkrimi elektronik.
2- Te dhenat qe lidhen me Institutin mjeksor te Kosoves –IMK ,jane kryesishte te dhena
qe identifikojne shenimet fillestare te nje pacienti duke perfshire pjesen historike t e
trajtimeve mjeksore ,ku shenimet fillestare do jene: Nr rendor i pacientëve ,Institucioni
shëndetësor ,Departamenti -Reparti ,Njësia ,Mbiemri ,Emri ,Mbiemri i Vajzërisë ,Emri
i Prindit ,Vendi i Lindjes ,Profesion i ,Datëlindja ,Gjinia ,Grupi i gjakut ,Rh
Faktori ,Alergjitë ,Vendbanimi ,Adresa ,Telefoni kontaktues ,e -mail ,Statusi
bashkëshortorë ,Statusi i sigurimit shëndetësor ,Medikamentet e rekomanduara ,Data

51
e fillimit te trajtimit ,Data e perfundimit e trajtimi t , Emri dhe vendi
institucionit,Gjendja gjate vizites hospitalizimit ,Emri dhe mbiemri i mjekut.
3-Te dhenat qe lidhen me Instituti Seizmik i Kosoves -ISK,jane kryesishte informacione nga
ndodhja e termeteve dhe permblidhen si shenime bazike : Nr rendor ,Emri i stacioneve
seizmike ,Data e lekundjes s eizmike ,Koha lokale e lekundjes s eizmike ,Latituda
seizmike ,Longituda s eizmike ,Magnituda e lekundjes s eizmike ,Thellesia
seizmike ,Data fillestare e lekundjes s eizmike ,Data perfundimtare e lekundjes
seizmike ,Pamja satelitore e lekundjes s eizmike.
4-Ndersa te dhenat nga Sherbimi i zjarrefikseve te Kosoves -SHZK ,jane kryesishte
informata qe permblidhen nga rastet e zjarreve dhe perfshihen : Nr raportit , Data e
Aksidentit , Vendi i Aksidentit ,Komuna, Vendndodhja ,Lloji i z jarrevenjeve ,Sinjali
alarmues ,Nr telefonit ,Intervenimet teknike ,Koha e nisjes , Koha e arritjes ,Koha
lokale ,Koha e kthimit ,Vërejtje .
5- Te dhenat qe lidhen me Instituti Hidrometrologjik i Kosoves -IHMK , qe permbajne
informaci one nga regjistrimi i paisjeve matese duke perfshi shenimet bazike si : Nr rendor
,Emri i stacionit matës ,Numeri i stacioneve matëse ,Temperatura Maximale
,Temperatura Minimale ,Temperatura Mesatare , Lageshtia e ajrit , Shtypja
atmosferike ,Shpejtesia e erë s ,Reshjet atmosferike .
Keto (Juliana, 2014) qe permendem me siper konsiderohen burime te brendshme, pasi
QOAME ka edhe burime te jashtme .sikurse mund te jene te dhenat nga sherbimet e sigurise
kombetare.

52
Nga figura e meposhtme tregohen burimet qe shfytezohen per ndertimin e DWH, nga e cila
me pastaj ndihmon ne analizimin dhe raportimin ne procesin e vendimmarrjes ne QOAME.
Figura 3.1 Diagrama e kalimit te informacionit drejt DWH -QOAME .

Duke u nisur nga keto sisteme QOAME ka interes grumbullimin dhe integrimin e
informacionit ,me kete lind nevoja per nje integrim te te dhenave te gjeneruar nga plateformat
e ARC -se ,ISK -se,IMK -se,IHMK -se dhe SHZK -se.
3.5 INTEGRIMI I TË DHËNAVE DHE MENAXHIMI I KATASTROFAVE
Integrimi i të dhënave është procesi i kombinimit të dhënave që ndodhen në burime të
ndryshme dhe sigurimi i një pamjeje të unifikuar i këtyre të dhënave për përdoruesin. Ky
proces zhytet në një sërë sit uatash qoftë bizneseve (kur dy kompani të ngjashme duhet të
bashkojnë databazat e tyre) dhe shkencore (kombinim i rezultateve të kërkimit nga ato të
DWH -QOAME
ARC
SHZK
ISK
IMK
IHMK

53
ndryshme sizmike, mjekësore, meteorologjike, të zjarrit dhe emergjencave). Problemi i
integrimit të dhënav e bëhet më kritik ndërsa sasia e të dhënave që duhet të ndahet rritet.Me
investigimin e të dhënave, nënkuptojmë procesin e futjes në një sistem të dhënash, e cila vjen
nga disa burime heterogjene.
Shkallëzimi është një çështje e rëndësishme në gëlltitjen e të dhënave, meqenëse rrjedha e
informacionit mund të jetë shumë e lartë gjatë kohë s të një ngjarjeje kritike (Hristidis &
Chen,2010 :1701). .Fusha e integrimit të dhënave ose integrimit të informacionit ka bërë
progres të madh në themelet teorike dhe në zh villimin e algorit meve dhe mjeteve (Peng
&.Zhang ,2010 : 316 –327 ) .Integrimi i të dhënave është problemi i kombinimit të dhënave,
të cilat gjenden në burime të ndryshme; si rezultat i përparimeve në teknologjinë e
informacionit ka gjithashtu DWH për t'i siguruar përdoruesit një pamje e unifikuar e këtyre
të dhënave, problemi i sistemeve të ndërtimit për integrimin e të dhënave është i rëndësishëm
në aplikimet e sotme.Duke marrë parasysh zhvillimet në Teknologjinë e Informacionit,
menaxhimi i emergjencave kërkon të dhëna modelimi nga burime të ndryshme, duke
koordinuar aktivitetet midis institucioneve dhe agjencive qeveritare .
Sot, më shumë se kurrë nevoja për të krijuar një sistem institucional për të koordinuar të
gjitha burimet dhe aftësitë që janë në di spozicion për t'u përgatitur për të reaguar në një
mënyrë të koordinuar dhe të planifikuar në rast të katastrofave natyrore dhe incidenteve të
tjera.Gjatë viteve të fundit, një zhvillim i një teknologjie të shumëllojshme informacioni dhe
komunikimi kanë pr opozuar alternativa për të menaxhuar katastrofat natyrore në nivel
kombëtar dhe rajonal.

54
Teknologjia e informacionit është bërë një bazë për zhvillimin e shumë sistemeve të
informacionit sot. Në shumicën e fushave të jetës është bërë shumë e vështirë të mb ahen
komunikimet, koordinimet ose komunikimet ndërkombëtare pa përdorimin e gjerë të
teknologjisë të informacionit (Krasniqi ,2014) .Gjate çdo faze te menaxhimit te katastrofave
,fatkeqësive mund te dëshirojnë qasjen ne te dhënat nga departamentet : Agjencio ni i
Regjistrimit Civil –ARC, Institutin mjeksor te Kosoves –IMK, Instituti Seizmik i Kosoves –
ISK, Sherbimi i zjarrefikseve te Kosoves -SHZK dhe Instituti Hidrometrologjik i Kosoves –
IHMK . Integrimi i këtyre sistemeve te ndryshme është i rëndësis hëm dhe kjo mund te
realizohet ( Sam & Lance, 2009) .
Integrimi i të dhënave përfshin kombinimin e të dhënave nga disa burime të ndryshme, të
cilat janë ruajtur duke përdorur teknologji të ndryshme dhe siguron një paraqitje të unifikuar
të dhënave. Integrimi i të dhënave bëhet gjithnjë e më i rëndësishëm në rastet e bashkimit të
sistemeve të shume agjenci apo konsolidimin e aplikacioneve brenda një agjencie që të
ofrojë një pamje të unifikuar të dhënave të aseteve të agjencive për menaxhimin e
emergjencave. Përfitimet e një depoje të dhënave mundëson një biznesi të përformojë
analizat bazuar në të dhënat në depo. Kjo nuk do të jetë e mundur të bëhet me të dhënat e
vlefshme vetëm në sistemin e burimit. Arsyeja është se sistemet e burimeve nuk mund të
përmbajë të dhënat përkatëse, edhe pse të dhënat kanë emër të njëjtë, ato mund të ref erohen
subjekteve të ndryshme (Lenzerini, 2002) .
Konkluzion
Shtetet nuk janë të sigurta nga fatekeqesit natyrore dhe nga dora e njeriut pavarësisht
përpjekjeve të jashtëzakonshme të b ëra për të zvogëluar fatekeqesit . Mënyrat tradicionale

55
shpesh nuk janë të mjaftueshme për t'u marrë me fatekeqesit natyrore. Prandaj, duhet të
eksplorohen mënyra të reja me që llim që të zvogëlohen katastrofat. Në bazë të këtyre fakteve
eshte treguar një përmbledhje gjithëpërfshirëse të shumë çështjeve, problemeve, sfidave dhe
kërcënimeve që rimodelojnë menaxhimin e fatekeqesit natyrore. Me qëllim që të adresohen
këto çështje.
 Së pari, teknologjia DW H eliminon teprinë dhe papajtueshmërinë e të dhënave duke
arritur ndarjen e të dhënave pa letër në një organizatë dhe duke rritur besimin në
cilësinë e të dhënave.
 Së dyti, një DW H përmirëson efektshmërinë e detyrave operacionale pasi ka
premtimin që t'i mundësojë organizatave të g jenerojnë raporte dhe analiza ad -hoc për
vendimmarrje më të mirë.
 Së treti, një DW H kupton dhe plotëson më mirë nevojat e klientëve, rrit në maksimum
rezultatet e fushatave, ndërton besnikërinë dhe, së f undi, përmirëson rezultatet finale.

56
KAPITULLI IV: Modelimet e datamart -ëve për menaxhimin e
emergjencave dhe fatkeqësive natyrore
4.1 Hyrje
Sikurse potencuam në kapitullin 3 , agjencitë për menaxhimin e emergjencave dhe
fatkeqësive natyrore e kanë të domosdoshme të grumbullojnë dhe analizojnë të dhëna masive
të fatkeqësive natyrore . Rekordet e tërmeteve ,vërshimeve të det ajuara, apo edhe te stuhive
dhe temperaturave ekstreme , janë fusha më e nxehtë për eksplorimin e njohurive në
menaxhimin e emergjencave dhe fatkeqësive natyrore . Analizat që duhet të gjenerohen prej
tyre, janë shumë të larmishme. Për ketë arsye modelimi i një datamart -i për këto të dhëna
është shumë interesant për tu zhvilluar. Për ndërtimin e tij, është e rëndësishme të
shfrytëzohet një model që është shumë i lehtë për tu kuptuar edhe nga një përdorues te
thjeshte , sepse këta përdorues do të luajnë një rol aktiv në gjenerimin e rezultateve.Ky
kapitull përmend të gjitha hapat, në detaje, që ndjekim për ndërtimin e një datam art-i mbi
këto të dhëna. Në të përmenden pikat dhe problemet kryesore, që duhet të zgjidhen gjatë
ndërtimit të modeleve. Për të përfituar më shumë fleksibilitet, në lidhje me analizat mbi
informacionin e ruajtur, përdoren mjetet OLAP, të teknologjisë BI.

57
4.1.1 Arkitektura data mart -eve
Arkitektura data -mart e pavarur për një DWH është treguar në Figurën 4.1 .
Figura 4.1. Arkitektura data -mart e pavarur për një DWH (Hoffer & Ramesh.,2011).

Ndërtimi i kësaj arkitekture kërkon katër hapa bazë (duke lëvizur nga e ma jta në të djathtë
në Figurën 4.1 ):
1. Të dhënat nxirren nga skedat e sistemit dhe databazat burim të ndryshme të brendshme
dhe të jashtme. Në një organizatë të madhe, ato mund të jenë me dhjetëra ose qindra skeda
dhe databaza të tilla.
2. Të dhënat nga sistemet e ndryshme te burimeve transformohen dhe integrohen para se të
ngarkohen në data -marte. Transaksionet mund të dërgohen në sistemet burim për të

58
korrigjuar gabimet e gjetura në skenimin e të dhënave. DWH konsiderohet si koleksion i
data-marteve.
3. DWH është një set databazash të ndryshme fizikisht të organizuara për ndihmë
vendimmarrjeje. Përmban të dhëna të detajuara dhe të përmbledhura së bashku.
4. Përdoruesit përdorin DWH përmes një sërë gjuhësh kërkimi dhe mjetesh analitike.
Rezu ltatet (p.sh., parashikimet, planifikimet) mund të kalohen nga një DWH dhe databaza
operacionale.
Me pas do të diskutojmë proceset më të rëndësishme të nxjerrjes, transformimit dhe
ngarkimit (ETL) të të dhënave nga sistemet burim në DWH me më shumë hollës i në kete
kapitull Do të shikojmë gjithashtu në një pjesë më poshtë mjete të ndryshme prezantimi të
përdoruesve finalë. Nxjerrja dhe ngarkimi ndodhin rregullisht – disa herë çdo ditë, javë ose
muaj. Prandaj, DWH shpesh nuk ka, ose nuk ka nevojë të ketë, t ë dhëna aktuale. Mos harroni,
DWH nuk mbështet (direkt) përpunimin operacional të transaksioneve, megjithëse mund të
përmbajë të dhëna transaksionesh (por më shpesh përmbledhje të transaksioneve dhe pamje
çasti të variablave të statusit, të tilla si bilanc et e llogarive dhe nivelet e inventarit). Për
shumicën e aplikacioneve të DWH, përdoruesit nuk kërkojnë reagim në një transaksion të
veçantë por më tepër tendencat dhe strukturat në gjendjen e organizatës nëpër një nëngrupi
të madh të DWH. Si minimum, pesë tremujorë fiskalë të dhënash mbahen në një DWH në
mënyrë që të shihen të paktën tendencat dhe strukturat vjetore. Të dhënat më të vjetra mund
të pastrohen ose të arkivohen. Do të shohim më vonë se një arkitekturë e avancuar e DWH,
DWH në kohë reale, bazohet në një supozim të ndryshëm rreth nevojës për të dhëna aktuale.
Ndryshe nga shumë parimet e diskutuara deri në këtë kapitull, qasja e data -marteve pavarura

59
nuk krijon një DWH. Por në vend të kësaj, kjo qasje krijon shumë data -marte të veçanta,
secila e bazuar në DWH, jo teknologji databaze të përpunimit të transaksioneve.
Një data -mart është një DWH e cila është e kufizuar në shtrirje, e personalizuar për
aplikacionet e vendimmarrjes të një grupi të caktuar përdoruesi final. Përmbajtet e saj merren
qoftë nga proceset ETL të pavarura, siç tregohet në Figurën 4.1 për një data -mart të
pavar ur, ose merren nga DWH, të cilën do ta diskutojmë në dy pjesët më tej. Është e mundur
që çdo data -mart të ndërtohet duke përdorur mjete të ndryshme; për shembull, një data -mart
financiar mund të ndërtohet duke përdorur një mjet multidimensional si Hyperion 's Essbase,
dhe një data -mart të shitjeve mund të ndërtohet mbi një platformë DWH me qëllim më të
përgjithshëm, si për shembull Teradata, duke përdorur MicroStrategy dhe mjete të tjera për
raportim, kërkesa, dhe shikim të dhënash. Do të tregojmë një krahas im të arkitekturave të
ndryshme të DWH më vonë, por mund të shikoni një karakteristikë të dukshme të strategjisë
data-mart të pavarur: kompleksiteti për përdoruesit finalë kur duhet të përdorin të dhënat në
data (të evidencuara nga vijat e përshkuara që li dhin gjithë data -martet me mjetet e
prezantimit të përdoruesit final).
Ky kompleksitet vjen jo vetëm nga detyrimi për të hapur të dhënat nga databaza të veçanta
data-martesh por gjithashtu nga mundësia e një gjenerate të re sistemesh të dhënash
kontradikt ore – data-martet. Nëse ka një set metadatash në gjithë data -martet, dhe nëse të
dhënat janë bërë të qëndrueshme në data -martet përmes aktiviteteve në fushën e skenimit të
të dhënave (p.sh. nga ato çka quhen "dimensione konform" në kutinë e fushës të skeni mit të
të dhënave në Figurën 4.1 ), pastaj kompleksiteti për përdoruesit reduktohet. Jo kaq i dukshëm
në Figurën 4.1 është kompleksiteti për proceset ETL, sepse transformimet dhe ngarkesat e
veçanta duhet të ndërtohen për secilin data -mart të pavarur.

60
Data -martet e të dhënave shpesh krijohen sepse një organizatë përqendrohet në një seri
objektivash biznesi të volitshme, afatshkurtra. Objektivat e kufizuara afatshkurtra mund të
jenë më të pajtueshme me koston shumë më të ulët (para dhe kapital organizate ) për të
implementuar akoma edhe një data -mart të pavarur. Sidoqoftë, projektimi i mjedisit të DWH
në grupet e ndryshme të objektivave afatshkurtër do të thotë që humbisni elasticitetin për atë
afatgjatë dhe aftësinë për të reaguar ndaj ndryshimeve të kush teve të biznesit. Dhe të qenit
në gjendje për të reaguar ndaj ndryshimit është kritik për të ndihmuar vendimmarrjen. Nga
ana organizative dhe politike mund të jetë më e lehtë të kesh DWH të veçanta, të vogla të
dhënash në vend se të mbledhësh të gjitha pal ët organizative të bien dakord për pikëpamjen
e një organizate në një DWH qendrore të dhënash. Gjithashtu, disa teknologji të DWH kanë
kufizime teknike për madhësinë e DWH që mund të mbështetin – të cilën do ta quajmë më
vonë çështje shkallëzimi. Prandaj, teknologjia, në vend se biznesi, mund të diktojnë një
arkitekturë DWH nëse e mbyllni më parë veten në një grup teknologjish të DWH para se të
të kuptoni kërkesat tuaja për DWH. Ne diskutojmë avantazhet dhe disavantazhet e
arkitekturës të data -martit të pav arur me kulmin e vet duke konkurruar arkitekturën në pjesën
vijuese.
4.1.2 Arkitektura e Data -Martit të Pavarur dhe e Ruaj tjes të të dhënave Operacionale
Arkitektura e data -martit pavarur në Figurën 4.1 ka kufizime të ndryshme të rëndësishme
1. Është zhvilluar një proces i veçantë ETL për secilin data -mart, e cila mund të japë të dhëna
të tepërta dhe mundime përpunimi të kushtueshme.
2. Data -martet mund të mos jenë të pajtueshme me njëra tjetrën për shkak se shpesh janë
zhvilluar me teknologji të ndrys hme, dhe prandaj mund të mos japin një shikim të qartë

61
mbarë -ndërmarrjesh të të dhënave në lidhje me subjektet e rëndësishme si klientët, furnitorët
dhe produktet.
3. Nuk ka asnjë aftësi për të gërmuar në më shumë detaje ose në fakte përkatëse në data –
marte të tjera ose një depozitë të dhënash të ndarë, prandaj analiza është e kufizuar, ose më e
shumta shumë e vështirë (p.sh. bërja e bashkimeve nëpër platforma të veçanta për data -marte
të ndryshme). Në thelb, lidhja e të dhënave nëpër data -marte është një d etyrë e kryer nga
përdoruesit jashtë DWH.
4. Kostot e shkallëzimit janë të tepërta pasi çdo aplikacion i ri që krijon një data -mart të
veçantë përsërit të gjithë hapat e nxjerrjes dhe ngarkimit. Zakonisht, sistemet operacionale
kanë dritare kohore të kufiz uara për nxjerrjen e të dhënave në grup, prandaj në njëfarë pike,
ngarkimi në sistemet e operacioneve mund të nënkuptojnë që teknologjia e re është e
nevojshme, me kosto të tjera.
5. Nëse ka një përpjekje për t'i bërë data -martet më të pajtueshme, kostoja për ta bërë këtë
është shumë e lartë.
Vlera e data -marteve të pavarura është debatuar mjaft. Kimball (1997) mbështet fort
zhvillimin e data -marteve të pavarura si një strategji të zbatueshme për një zhvillim në faza
të sistemeve për mbështetjen e vendimmar rjes. Armstrong (1997), Inmon (1997,2000), dhe
Marco (2003) tregojnë pesë ide të gabuara të përmendura më parë dhe shumë të tjera.
Ka dy debate në lidhje me vlerën reale të data -marteve të pavarura:
1. Një debat merret me natyrën e qasjes në faza në imple mentimin e mjedisit të DWH. Thelbi
i këtij debati është nëse çdo data -mart duhet ose nuk duhet të zhvillohet në një model poshtë –
lart nga një nëngrup të dhënash mbarë -ndërmarrjesh për mbështetjen e vendimmarrjes.

62
2. Debati tjetër merret me arkitekturën e p ërshtatshme të databazës për përpunimin analitik.
Ky debat përqendrohet në shkallën në të cilën duhet të normalizohet një databazë data -marti.
Thelbet e këtyre dy debateve adresohen më tej në këtë kapitull. Një nga qasjet më të njohura
për adresimin e kufi zimeve të data -marteve të pavarura të përmendura më sipër është
përdorimi i një qasjeje me tre nivele e përfaqësuar nga arkitektura e data -marteve të pavarura
dhe e ruajtjes të të dhënave operacionale (shiko Figurën 4.2 ).
Figura 4.2 Arkitektura trishtresore e Data -Martit të Pavarur (Hoffer & Ramesh.,2011) .

Këtu niveli i ri është dyqani i të dhënave operacionale, dhe niveli i ruajtjes të të dhënave dhe
metadatave është rikonfiguruar.
Kufizimi i parë dhe i dytë adresohen duke ngarkuar data -martet e pavarura nga DWH të
ndërmarrjes (EDW), e cila është një DWH qendrore, e integruar e cila është pika e kontrollit

63
dhe "versioni i së vërtetës" i vetëm i vënë në dispozicion për përdoruesit fin alë për
aplikacionet e mbështetjes të vendimmarrjes. Data -martet e pavarura akoma kanë një qëllim
për të siguruar një mjedis të thjeshtuar dhe me performancë të lartë i cili akordohet sipas
nevojave të vendimmarrjes të grupeve të përdoruesve. Një data -mart mund të jetë një
databazë e veçantë fizike (dhe data -martet e ndryshme mund të jenë në platforma të
ndryshme) ose mund të jetë një data -mart logjik .Një grup përdoruesi mund të hapë data –
martin e vet, dhe kur nevojiten të dhënat e tjera, përdoruesit mund të hapin EDW. Teprica
nëpër data -martet e pavarura është e planifikuar, dhe të dhënat e tepërta janë të pajtueshme
sepse çdo data -mart ngarkohet në një mënyrë të sinkronizuar nga një burim i përbashkët të
dhënash (ose është një reflektim i DWH). Integrimi i të dhënave është përgjegjësia e stafit IT
që menaxhon DWH të ndërmarrjes; nuk është përgjegjësia e përdoruesve finalë të integrojnë
të dhënat nëpër data -marte të pavarura për çdo kërkesë ose aplikim. Data -marti i të dhënave
dhe arkitektura e ruajtjes të të dhënave shpesh quhet një qasje "qendër dhe foli", në të cilën
EDW është qendra dhe sistemet e të dhënave burim dhe data -martet janë në fundet e folive
hyrëse dhe dalëse.
Kufizimi i tretë adresohet duke siguruar një burim të integruar për gjithë të dhëna t
operacionale në një dyqan të dhënash operacionale. Një dyqan të dhënash operacionale
(Operational Data Store) (ODS) është një databazë e integruar, e orientuar nga subjekti, e
përditësueshme vazhdimisht, me vlerë aktuale (me histori të fundit), mbarë -organizate, e
detajuar e ndërtuar për t'i shërbyer përdoruesve operacionalë ndërsa bëjnë përpunimin e
mbështetjes të vendimmarrjes (Imhoff, 1998; Inmon, 1998). Një ODS është zakonisht një
databazë relative dhe e normalizuar si databazat në sistemet e regjistr imit, por është e
akorduar për aplikimet e vendimmarrjes. Për shembull, indekset dhe elementët e tjerë të

64
ndërtimit të databazës relative janë akorduar për kërkesat që gjejnë grupe të mëdha të
dhënash, në vend se për përpunimin e transaksioneve ose kërkimi n individual dhe regjistrimet
e lidhura direkt (p.sh. një porosi klienti). Për shkak se është e ndryshueshme, aktuale, dhe
vetëm e dhënë e historisë të fundit, e njëjta kërkesë kundrejt një ODS -je me shumë mundësi
do të japë rezultate të ndryshme në kohë t ë ndryshme. Një ODS zakonisht nuk përmban
histori "të thellë", ndërsa një EDW H mban zakonisht një histori me shumë shtresa të pamjeve
të gjendjes së organizatës. Një ODS mund të ushqehet nga databaza e një aplikacioni ERP,
por për shkak se shumica e organi zatave nuk kanë vetëm një databazë ERP dhe nuk i bëjnë
të gjitha veprimet kundrejt një ERP -je, një databazë ODS është zakonisht e ndryshme nga
një databazë ERP.
ODS gjithashtu shërben si fushë skenimi për ngarkimin e të dhënave në EDW H. ODS mund
të marrë të dhënat menjëherë ose me njëfarë vonese nga sistemet e regjistrimit, cilado që
është më praktike dhe e pranueshme për kërkesat e vendimmarrjes që mbështet. Arkitektura
e data -marteve të pavarura dhe ruajtjes të të dhënave operacionale quhet gjithashtu një fabrikë
informacioni korporate (Corporate Information Factory) (CIF) (shiko Imhoff, 1999).
Konsiderohet të jetë një pamje gjithëpërfshirëse e të dhënave organizative në mbështetje të
të gjitha kërkesave të përdoruesve për të dhënat.
Drejtuesit e ndryshëm në këtë fushë përkrahin qasje të ndryshme për magazinimin e të
dhënave. Ata që përkrahin qasjen e data -marteve të pavarura argumentojnë se kjo qasje ka
dy dobi të mëdha:
1. Lejon që koncepti i magazinës të të dhënave të tregohet duke p unuar në një seri projektesh
të vogla.

65
2. Koha derisa fillojnë dobitë nga magazinimi i të dhënave reduktohet sepse organizata nuk
vonohet derisa të gjithë të dhënat të centralizohen.
Avokatët e CIF (Armstrong, 2000; Inmon, 1999) ngrejnë çështje serioze me qasjen e pavarur;
këto çështje përfshijnë pesë kufizime të data -marteve të pavarura të përmendura më sipër.
Inmon sugjeron se një avantazh i data -marteve fizikisht të veçanta, të pava rura është se ato
mund të akordohen sipas nevojave të secilit komunitet përdoruesish.
Në veçanti, ai sugjeron nevojën për një DWH eksplorimi , e cila është një version i veçantë i
EDW H të optimizuar për gërmimin e të dhënave dhe inteligjencën e biznesit duk e përdorur
modelime statistikore, matematikore dhe mjete vizualizimi. Armstrong (2000) dhe të tjerë
shkojnë më tej duke argumentuar se dobitë e pretenduara nga avokatët e data -marteve të
pavarura janë vërtet dobi të marrjes të një qasjeje në faza për zhvil limin e DWH.
Një qasje në faza mund të arrihet gjithashtu brenda strukturës CIF, dhe lehtësohet nga
arkitektura finale e DWH që do të shqyrtojmë në pjesën vijuese.
4.2 Shtrimi i problemit per QOAME
Që shtrimi i problemit të jetë më domethënëse, ne i ndajmë të dhënat duke e u bazuar në
periudhe kohor, si të dhëna historike, të dhëna momentale dhe të dhëna të së ardhmes. Në
fakt, të dhënat e së ardhmes janë të dhëna të kalkuluara dhe për t’i kalkuluar ato duhen bërë
analiza predikuese. Dhe kjo në fakt paraqet arsyjen kryesore të analizës së të dhënave. Të
dhënat historike që posedon QOAME janë një burim shumë i rëndësishëm dhe bazë për
analizat numerike nga ku rrjedhin indikatorët e performancës, shifrat kyçe të QOAME , ne
vijim paraqesim gjendjen e përgjithshme te Agjencioneve per menaxhim te emergjencave
(CIO.al, 2011) :

66
a) Analizat mbi te dhenat e Institutit mjeksor te Kosoves –IMK
Sistemi informativ shëndetësor është kryesisht manual, në letër dhe shumica e të dhënave për
pacientë dhe trajtim regjistrohen në formularë nga letra të cilat grumbullohen nëpër
institucione gjegjëse dhe pastaj futen në formatin elektronik nga ana operator ëve në spitale
dhe qendra kryesore të mjekësisë familjare.Në sektorin e kujdesit parësor shëndetësor
(KPSH) të dhënat nga Qendrat e Mjekësisë Familjare (QMF) dhe ambulantat, grumbullohen
në formë të letrave nga Qendrat Kryesore të Mjekësisë Familjare (QKM F) e pastaj futen në
bazën elektronike nga ana e SISH njësive dhe transferohen në depertamentin e SISH -it në
kuadër të IKSHPK. Në shumicën e rasteve ky transfer bëhet me anë të mjetit elektronik “flash
memory”. Situatë e njejtë qëndron edhe në Qendrën Klin ike Universitare të Kosovës (QKUK) ku të
dhënat nga repartet dhe klinikat e ndryshme transferohen në njësitë e SISH -it në formë të kopjeve të
letrës. Të dhënat për personelin dhe pacientët (të ashtuquajturat ”statistikat e mesnatës”), kryesisht
futen në pr ogramin Excel. Megjithatë, qysh nga viti 2002 të dhënat për aktivitetet, sëmundshmërinë,
dhe vdekshmërinë në kujdesin parësor, dytësor dhe tretësor janë duke u regjistruar gjithnjë e më tepër
në bazën kryesore të të dhënave “Access -Master databaza” . Deri më sot Access -Master databaza
implementohet në të gjitha QKMF -të , në 7 spitale (5 spitale regjionale dhe 2 spitale të qytetit) dhe
ne QKUK. Mirëpo, të dhënat raportohen me vonesë prej gjashtë muaj e më tepër, analizat e të
dhënave të njëjta japin rezult ate të ndryshme dhe jo të gjitha institucio net shëndetësore raportojnë
(MSH,2014).
b) Analizat nga Instituti Seizmik i Kosoves -ISK
Pjesa dermuese e te dhenave nga Instituti Seizmik i Kosoves -ISK ndodhen te
arkivuara ne trajten e raporteve ,tabelave ,skicave e hartave .Shfrytezimi i tyre behet

67
me metodat tradicionale.Mjetet e komunikimit jane manuale,mungon nje rrjedhe e
vazhdueshme dhe e perditesuar per mbledhjen ,vlersimin dhe administrimin
.Perdoruesit e kane te pamundur qe te sigurojne ne kohe reale ,info rmacion te fresket
dhe te besushem per problemet per te cilat interesohen ne fushen seizmike
c) Analiza nga Instituti Hidrometrologjik i Kosoves -IHMK
Bazuar në analizat e gjeneruara të raportimit dhe në rrethanat qe gjendet Instituti
Hidrometrologjik i Kosoves ka grumbulluar të dhëna mjedisore nga institucionet
monitoruese, kompanitë, operatorët, ndërmarrjet e ndryshme,publikimet, raportet dhe nga
burime tjera. Për t’i përmbushur kërkesat e raportit, të dhënat e grumbulluara janë përpunuar
në informata k ualitative mjedisore që me pas jane prezantuar në raport e. Këto të dhëna janë
në formë teksti, tabelash, hartash dhe paraqitjesh grafike (Agjencia,2011). Cilësia e të
dhënave dhe besueshmëria janë shumë të rëndësishme. Të dhënat e pasakta ose jo të plota të
reshjeve janë më të dëmshme se mungesa e të dhënave. Pa të dhëna asgjë nuk mund të
parashikohet, të planifikohet ose të menaxhohet (Zyra e Kryeministrit,2014) .
Nga Instituti Hidrometrologjik i Kosoves deri me tani nuk kemi nje baze te dhenave qe mund
ti referohemi ne kohe reale dhe te kemi freskim te te dhenave nga Instituti Hidrometrologjik .

4.3 Modelimi i të dhënave te përzgjedhura
Analizimi i kërkesave të mësipërme, udhëheq proçesin e modelimit të të dhënave për
ndërtimin e një zgjidhjeje. Modelimi shumë dimensional u përzgjodh për tu aplikuar në rastin
tonë, për tre arsye :

68
-Këto modele ofrojnë një thjeshtësi në përdorim edhe nga personat pa njohuri në IT
-Plotëson kërkesa komplekse me performancë të lartë
-Përshtatet shumë mirë me sasi të mëdha in formacioni, siç është rasti ynë (Juliana ,2014)
Datamart -i që do të ndërtojmë në vijim jane për të optimizuar performancën ,për përdorimet
e përcaktuara mirë dhe të parashikueshme, ndonjëherë qoftë edhe një ose pak kërkesa. Për
shembull, rasti i menaxhimit te emergjencave mund të ketë një data -mart per Institutit
mjeksor te Kosoves –IMK, një data -mart Agjencioni i Regjistrimit Civil –ARC , një data -mart
Instituti Hidrometrologjik i Kosoves -IHMK , e kështu me radhë për të ndihmuar përpunimin
analitik te raport eve (Hoffer & Ramesh.,2011) .
Sipas të njëjtës mënyrë, ndërtohen edhe për tipet e tjera të rekordeve. Gjithashtu, duke u nisur
nga përshkrimi i problemit dhe duke krahasuar elementët e dy metodikave kryesore për
ndërtimin e zgjidhjes, u përzgjodh metodika Kimball që bazohet mbi datamart -e.
Elementët kriter të përzgjedhjes janë paraqitur në tabelën e mëpos htme

Tabela 4.1 Elementët kriter për përzgjedhjen e modelimit
Elementet Kimball Inmon
Nevoja E menjëhershme E zgjatur në kohë
Fokusi Fusha specifike të biznesit Gjithë sipërmarja
Buxheti Buxhet i vogël Buxhet i madh
Perdoruesit Grupe specifike të biznesit Korporata

69
Duke u bazuar pikërish t në rekomandimet e Kimball të trajtuara në seksionin 3.4 , u
përzgjodh arkitektura me dy shtresa, për të përmbushur veçanërisht tiparin e ndarjes.Ku të
dhënat fillimisht do të ngarkohen në një zonë Stage, ku edhe do të transformohen, për tu
ngarkuar më pas në skemën e Datamart -it (Juliana ,2014)
Figura 4.3 Skema e arkitekturës së përzgjedhur (Ali, 2011:91).

Me pastaj shqyrtojme edhe njeren nga teknikat kyçe me të cilën janë ndërtuar dhe
implementuar strukturat e të dhënave brenda DWH ,e kjo ka te beje me modelimin
dimensional.
4.4 Modelimi dimensional
Modelimi dimensional është një teknik e ndërtimit logjik dhe ben strukturimin e të dhënave
për përdoruesit e biznesit me qe raste ka performancë kërkimi të shpejtë.Modelimi
dimensional pranohet gjerësisht si qasja e preferuar për pre zantimin DW/BI.Ekspertët e kanë
dalluar se të dhënat e prezantuara në mjetet e BI duhet të bazohen në thjeshtësi për t'i qëndruar
çdo mundësie suksesi. Herë pas here, organizatat IT, konsulentët, përdoruesit dhe shitësit

70
kanë zbritur në një strukturë të th jeshtë dimensionale për t'iu përshtatur nevojës njerëzore
bazë për thjeshtësi.Modelimi dimensional e ndan botën në matje dhe kontekst . Matjet kapen
nga procedurat e biznesit të organizatës dhe sistemet e tyre burim operacionale mbështetëse.
Matjet janë zak onisht vlera numerike ne i quajmë ato si fakte (Kimball & Becker ,2008 ).
Tabela e fakteve është e përbërë nga çelësat kryesorë me shumë pjesë, ku faktet numerike
dhe shtesë janë faktet më të dobishme në tabelën e fakteve. Secila tabelë faktesh tregon një
numër tabelash më të vogla të quajtura dimensione çelësi kryesor i të cil ave i përket saktësisht
një prej çelësave me shumë pjesë në tabelën e fakteve. Një përshkrim i tillë është quajtur si
modeli i skemës yll, i cili shërben fillimisht për një data -mart. Ndërsa DW H rritet, mund të
shtohen më shumë data -marte, e cila jep më sh umë mundësi për të krijuar dimensione të cilat
janë të përbashkëta për më shumë se një data -mart. Këto dimensione të përbashkëta (DP)
veprojnë si "ura të dhënash" midis tabelave të fakteve, duke lejuar kërkesa të cilat veprojnë
që të dhënat nga faktet e sh umëfishta të shkruhen. Shembuj tipikë të dimensioneve të
përbashkëta përfshijnë datën dhe vendndodhjen.
Si rrjedhojë, një hap shumë i rëndësishëm në ndërtimin e modelit multidimensional është
krijimi i një dimensioni të konformuar me qëllim që DWH të funk sionojë si një depozitë e
vetme. [13 ] Secila prej proc eseve të menaxhimit te emergjencave si ne rastin e Institutit
mjeksor te Kosoves –IMK mund të tregohet nga një model dimensional i cili përbëhet nga
një tabelë faktesh që përmban matjet numerike të rreth uara nga një sërë tabelash
dimensionesh që përmbajnë kontekstin tekstual, siç ilustrohet në

71
Figura 4.4 Proceset e modelimi t dimensional

Kjo strukturë shume here e ngjashme me yllin , një term që datohet në ditët më të hershme
të databazave relacionale.Modelet dimensionale të ruajtura në platformën e databazës
relacionale zakonisht quhen “Skema yll” ,ndersa modelet dimensionale të ruajtur a në
strukturat e përpunimit analitik online multidimensional (OLAP) quhen kuba .
4.4.1 Modelimi i formës së tretë normale (3NF )
Eshtë krejt i ndryshëm nga modelimi dimensional. Modelimi 3NF është një teknikë ndërtimi
që kërkon të eliminojë tepritë e të d hënave. Të dhënat ndahen në shumë entitete të
dallueshme, secila prej tyre bëhet një tabelë në databazën relacionale. Ky normalizim është
shumë i dobishëm për përpunimin e transaksioneve pasi e bën ngarkimin dhe përditësimin e
transaksionit thjeshtë dhe shpejtë.
Modelimi dimensional dhe modelimi 3NF rezultojnë të dy në tabela fizike të arsyetuara në
një sistem databaze relacionale. Strukturat e tabelave që vijnë si rezultat ndryshojnë, por të

72
gjitha kanë të njëjtat karakteristika databaze relacionale, pavarësisht nga teknika e modelimit.
Ja vlen të theksohet se konvertimi nga strukturat normale në modelet dimensionale është
relativisht e drejtpërdrejtë.
 Hapi i parë ë shtë të përcaktohen relacio net 'shumë -në-shumë' në modelin e
normalizuar që përmban vlera numerike dhe shtuese metrike jo-kyçe si tabela faktesh,
tabelat e fakteve zakonisht normalizohen në 3NF në një model dimensional sepse
konteksti përkatës hiqet në tabelat e dimensionit.
 Hapi i dytë është të denormalizohen tabelat e mbetura në tabela dimensioni me çelësa
me një pjesë të cilat lid hen direkt me tabelën e fakteve, tabelat e dimensionit më
shpesh i ngjajnë tabelave të formës normale të dytë me shumë për shkrues me
kardinalitet të u lët (Kimball & Becker ,2008 ).
4.4.2 Tabelat e Fakteve
Tabelat e fakteve ruajnë matjet e performancës të gjeneruara nga aktivitetet ose eventet e
biznesit të organizatës. Termi fakt i referohet çdo matjeje performance. Ju zakonisht nuk e
dini vlerën e një fakti që më përpara sepse ajo është e ndryshueshme, vlerësimi i faktit ndodh
në kohën e eventit të matjes, si për shembull kur merret një porosi, dërgohet një ngarkesë ose
regjistrohet një problem shërbimi.
Pothuajse çdo fakt është numerik. Faktet më të dobishme janë numerike dhe shtuese. Shtimi
është i rëndësi shëm sepse aplikimet BI rrallë marrin një rresht të vetëm tabele
faktesh, kërkesat zakonisht zgjedhin qindra ose mijëra rreshta faktesh njëherësh, dhe gjëja e
vetme e dobishme për t'u bërë me kaq shumë rreshta është që ato të mblidhen.

73
Tabelat e fakteve jan ë gjigante, me miliona ose miliarda rreshta, por janë efikase. Për shkak
se tabelat e fakteve shpesh ruajnë më shumë se 90 përqind të të dhënave në një model
dimensional, ne jemi të kujdesshëm të minimizojmë të dhënat e tepërta në një tabelë faktesh.
Gjith ashtu, ne përpiqemi të ruajmë matjet që dalin nga një proces biznesi në një tabelë të
vetme faktesh e cila është e ndarë në të gjithë organizatën. Për shkak se të dhënat e matjeve
janë të dhënat më voluminoze, ne e shmangim qëllimisht dyfishimin e metrikës të detajuar
në tabelat e shumëfishta të fakteve në korporatë, ndërsa përshkruajmë më tej me arkitekturën
bus të DWH të korporatës .
4.4.3 Tabelat e Dimensioneve
Tabelat e dimensioneve janë shoqërues integralë t ë një tabele faktesh. Tabelat e
dimensioneve përmbajnë për shkrues tekstualë të një rasti siq eshte QOAME tabele
dimensionale qe lidhet me te dhenat e datave , siç ilustrohet në Figura 4 .5.
Figura 4.5 Moster e tabeles dimensionale

74
Në një model dimensional të ndërtuar mirë, tabelat e dimensioneve kanë shumë kolona ose
atribute.Atributet e dimensioneve shërbejnë si burimi kryesor i kufizimeve të kërkimit,
grupimeve dhe emërtimev e të raportit. Në një kërkim ose kërkesë raporti, atributet dallohen
nga fjalët. Atributet e tabelës të dimensioneve luajnë një rol jetësor në DWH Meqenëse janë
burimi i virtualisht të gjitha kufizimeve interesante dhe emërtimeve të raporteve, ato janë
çelësi për ta bërë DWH të përdorshme dhe të kuptueshme. Në shumë mënyra, DWH vlen
vetëm aq sa atributet e dimensioneve.Atributet më të mira janë tekstuale dhe të dallueshme.
Atributet duhet të përbëhen nga fjalë të vërteta në vend se nga shkurtime kriptike. A tributet
tipike për një dimension Data do të përfshinin një përshkrim të shkurtër (10 deri 15
karaktere), një përshkrim të gjatë (30 deri 50 karaktere), Dita e lindjes , dita e fillimit te
trajtimit , dita e perfundimit te trajtimit , viti, dhe shumë karakteristika të tjera të dimension
Data . Megjithëse madhësia është me shumë mundësi numerike, përsëri është një atribut
dimensioni sepse sillet më shumë si një përshkrim tekstual sesa si një matje numerike.
Madhësia është një përshkrues i qa rtë dhe konstant i një produkti specifik.Ndonjëherë kur po
ndërtojmë një databazë është e paqartë nëse një fushë të dhënash numerike e nxjerrë nga një
burim të dhënash prodhimi është fakt apo atribut dimensionesh. Ne shpesh mund të marrim
vendimin duke pye tur nëse fusha është një matje që merr shumë vlera dhe merr pjesë në
llogaritje (duke e bërë një fakt) apo është një përshkrim me vlerë të qartë i cili është pak a
shumë konstant dhe merr pjesë në kufizime (duke e bërë një atribut dimensional). Për
shembul l,kostoja standarde për një produkt duket si një atribut konstant i produktit por mund
të ndryshohet kaq shpesh saqë ne të vendosim që ësh të më shumë si një fakt i matur .

75
4.4.3 Çelësat e tabelës të dimensioneve
Tabelat e fakteve kanë një çelës me shumë pjesë, rreshtat e dimensioneve dallohen në
mënyrë unike nga një fushë çe lësi e vetme. Meqe çelësat kryesorë të tabelave të
dimensioneve janë thjesht numra të plotë me radhë duke filluar nga 1, që do të thotë se kur
krijojmë një çelës për një regjistrim dim ensioni të ri, ne thjesht shtojmë 1 në vlerën e fundit
që kemi përdorur. Këta çelësa zëvendësues janë pa kuptim, ata thjesht shpërbejnë si fusha
bashkimi midis tabelave të fakteve dhe dimensioneve.
Meqenëse jemi përqendruar në dobitë, është e drejtë të pra nojmë se ka gjithashtu një kosto
në përdorimin e çelësave zëvendësues. Caktimi dhe menaxhimi i çelësave zëvendësuese të
tabelës të dimensioneve dhe zëvendësimi i mirë i tyre për çelësat natyralë operacionalë në
rreshtat e fakteve vendos një barrë në sistem in ETL. F atmirësisht, përpunimi është virtualisht
identik nëpër tabelat e fakteve dhe dimensioneve, prandaj mund të ndërtohet edhe njëherë
dhe pastaj të ripërdoret. Gjithashtu, shumë ofrues të ETL japin aftësi të integruara për të
lehtësuar përpunimin e çe lësave zëvendësues.

4.4.4 Dimensionet e konfirmuara
Dimensionet e konformuara të standardizuara janë synimi për çdo DWH të arkitekturuar
mirë. Ndonjëherë i referuar si dimensione master ose dimensione referencë të përbashkëta,
dimensionet e konformuara n dahen nëpër mjedisin e DWH të korporatës, duke iu bashkuar
tabelave të fakteve të shumëfishta që përfaqësojnë procese të ndryshme biznesi. Dimensionet
e konformuara vijnë në dy forma.Ne formen bazë, dy dimensionet e konformuara janë
absolutisht identike, m e të njëjtat çelësa, emra atributesh, përkufiz ime atributesh dhe vlera te
dhenash pavarësisht nga tabela e fakteve me të cilat ato bashko hen. Për shembull, dimensioni

76
Kohë nga tabela e fakteve të Institutit mjeksor te Kosoves -IMK është identike me
dimensionin e Data të bashkuar në faktet e inventareve. Kjo tabelë dimensionesh jep të
njëjtën përmbajtje, interpretim dhe prezantim pavarësisht nga procesi i biznesit që përfshihet.
Ose ndryshe, dimensionet konformohen kur një dimension është një nëngrup perfekt i një
tabele dimensionesh më të detajuar, më të copëzuar. Në këtë rast, atributet që janë të
përbashkëta për dimensionin e detajuar dhe dimensionin nëngrup të tkurrur, kanë të njëjtat
emra atributes h, përkufizime dhe vlera te dhen ash. Siç ilustrohet në Figura 4.6
Figura 4.6

Tabelat e konformuara të detajuara dhe të tkurrura të dimensioneve korrespondojnë me
tabelat e fakteve në copëzime të ndryshme .Dimensionet e konformuara janë jashtëzakonisht
të rëndësishme për natyrën AME të sistemit DW H/BI pasi ato japin dobitë e mëposhtme:
• Qëndrueshmëri. Dimensionet e konformuara sigurojnë që çdo tabelë faktesh të filtrohet në
mënyrë të qëndrueshme dhe grupet e përgjigjeve të kërkesës që vijnë si rezultat të emërtohen
vazhdimisht.
• Integrim. Përmbajtja rreptësisht me dimensionet e konformuara lejon mjedisin DW H/BI që
të operojë si një i tërë i integruar. Dimensionet e konformuara lejojnë kërkesat të gërmojnë

77
në tabelat e fakteve që për faqësojnë procese të ndryshme duke lëshuar kërkesa të veçanta të
çdo tabele të veçantë faktesh, dhe pastaj duke iu bashkuar grupeve të rezultateve në atributet
e dimensioneve të përbashkëta.
• Reduktim i kohës të zhvillimit në treg. Ndërkohë që ka një inve stim organizate që duhet
për të përcaktuar dhe menaxhuar dimensionet e konformuara, pasi janë ndërtuar, ato mund
të pakësojnë në mënyrë dramatike kohën e zhvillimit për një projekt pasi dimensionet e
përbashkëta janë në dispozicion pa rikrijuar vazhdimisht . (Kimball & Becker ,2008 ).

Më parë, ka qënë një traditë për të ndjekur të treja etapat e modelimit gjatë ndërtimit të një
databaze. Modeli i pare që duhet të ndërtohet është ai konceptual, i cili fokusohet drejt
biznesit për të përmbledhur kërkesat e e tij në nivel të lartë. Zakonish t prezantohet nga një
skeme dhe duhet të jetë e pav arur nga tipi i databazës së perdorur. Modeli vijues është ai
llogjik, i cili duhet të përshkruaj skemën e saktë të përdorur nga databaza. Së fundmi është
modeli fizik, i cili është përbërë nga një bashkësi skriptesh ,të cilat gjenerojnë dhe krijojnë
tabel at, indekset, lidhjet etj. Në kohët e sotme, shumë teknikë i bashkojnë në një fazë të vetme
të treja modelet. Ata thjesht ndërtojnë një model (ER) dhe e konvertojnë direkt në një
bashkësi objektesh të databazës.
Megjithatë një DWH është ndryshëm nga tipe t e tjera të databazave dhe për rrjedhojë
rekomandohet të përdoret triologjia konceptual/llogjik/fizik ( Lula & Kika , 2012 :230).
4.4.5 Sjellja së bashku e fakteve dhe dimensioneve
Tani që i kuptojmë tabelat e fakteve dhe dimensioneve, le të sjellim së bashku dy blloqe
ndërtimi në një model dimensional. Siç ilustrohet në Figura 4.7

78
Figura 4.7 .Tabela e Fakte dhe Dimensioneve ne modelin dimensional.

tabela e fakteve që përbëhet ng a matje numerike i bashkohet një grupi tabelash dimensionesh
të mbushura me atribute përshkruese. Kjo strukturë karakteristike ngjashëm yllit shpesh
quhet skema e bashkimit yll. Ky term datohet që në ditët e hershme të databazave relacionale.
Gjëja e parë që vëmë re rreth skemës dimensionale është thjeshtësia dhe simetria. Pa dyshim,
përdoruesit e biznesit përfitojnë nga thjeshtësia pasi të dhënat janë më të lehta për t'u kuptuar
dhe naviguar. Struktura e ndërtimit në Figura 4.7 është fakti se është shumë e dallu eshme për
përdoruesit e menaxhimit te emergjencave . Ne kemi vërejtur me qindra raste ku përdoruesit
bien dakord menjëherë se modeli dimensional është mundesi per menaxhim efektiv te
fatekeqsive natyrore . Për më tepër, numri i reduktuar i tabelave dhe përdorimi i përs hkruesve
kuptimplotë të menaxhimit e bën më pak të mundur ndodhjen e gabimeve.Thjeshtësia e një
modeli dimensional ka gjithashtu dobi performance. Optimizuesit e databazave i përpunojnë
këto skema të thjeshta në më nyrë më të efektshme me më pak bashkime. Një motor databaze
mund të bëjë supozime shumë të forta së pari rreth detyrimit të tabelave të dimensioneve të
indeksuara dhe pastaj edhe të tabelës së fakteve njëherësh me produktin Kartezian të

79
çelësave të tabel ës së dimensioneve duke plotësuar detyrimet e përdoruesit. Çuditërisht, duke
përdorur këtë qasje është e mundur të vlerësohen bashkimet n-way në një tabelë faktesh me
një kalim të vetëm përmes indeksit të tabelës së fakteve.Së fundi, modelet dimensionale j anë
shumë të zgjerueshme për të akomoduar ndryshimet. Struktura e parashikueshme e një
modeli dimensional i reziston ndryshimeve të papritura në sjelljen e përdoruesit. Çdo
dimension është ekuivalent, të gjitha dimensionet janë pika hyrjeje të njëjta simet rikisht në
tabelën e fakteve. Modeli logjik nuk ka paragjykim të integruar në lidhje me strukturat e
pritura të kërkimit. Nuk ka preferenca për pyetjet e biznesit që do të bëjmë këtë muaj kundrejt
pyetjeve që do të bëjmë muajin tjetër. Ne patjetër nuk duam të rregullojmë skemat tona nëse
përdoruesit e biznesit vijnë me mënyra të reja për të analizuar biznesin.
Me modelet dimensionale, ne mund të shtojmë dimensione krejt të reja për sa kohë
përcaktohet një vlerë e vetme e atij dimensioni për çdo rresht ekzis tues faktesh. Po kështu,
ne mund të shtojmë fakte të reja, të papritura në tabelën e fakteve, duke supozuar që niveli i
detajeve përputhet me tabelën e fakteve ekzistuese. Ne mund të shtojmë tabela dimensionesh
para-ekzistuese me atribute të reja, të papri tura. Ne gjithashtu mund t'i ndajmë rreshtat
ekzistues të dimensioneve në një nivel më të ulët copëzimi nga një pikë e caktuar në kohë.
Në çdo rast, tabelat ekzistuese mund të ndryshohen në vend qoftë thjesht duke shtuar rreshta
të reja të dhënash në tabel ë ose duke ekzekutuar një komandë SQL ALTER TABLE. Të
dhënat nuk do të kishin nevojë të ngarkoheshin përsëri. Të gjitha aplikimet ekzistuese të
aksesit të të dhënave vazhdojnë të punojnë pa nxjerrë rezultate të ndryshme (Kimball &
Ross, 2002)

4.5 Modelimi konceptual

80
Modeli konceptual është një përfaqësim i koncepteve dhe marrëdhënieve midis tyre.
Është kryesisht për të kapur kërkesat e përdoruesve të vendimmarrjes pa u shqetësuar
për detajet e implementimit. Ka modele konceptuale që ekzistojnë për databazat
relacional e dhe spaciale por ato nuk shkallëzohen mirë në DWH spaciale për shkak të
pranisë të hierarkive, përmbled hjeve, matjeve dhe dimensioneve (Garg & Mithal).
Në këtë modelim, identifikohen entitetet dhe relacionet midis tyre dhe përcaktohet niveli më
i ulët i detajimit të ruajtjes së informacionit, që plotëson kërkesat e analizimit të
informacionit. Përcaktimi i nivelit më të ulët të informacionit, lidhet ngushtë me një
përllogaritje të volumeve fizike të informacionit që nevojiten për ruajtjen e të dhënave bur im
(Juliana ,2014) .Modelet konceptuale lehtësojnë komunikimin midis përdoruesve dhe
ndërtuesve meqenëse nuk kërkojnë njohuri për veçoritë specifike të platformës së
implementimit.
Për më tepër, skemat e zhvilluara duke përdorur modelet konceptuale mund të hartohen në
modele logjike të ndryshme, si modelet relacionale, objekt -relacionale ose të orientuara nga
objekti, duke thjeshtuar kështu përgjigjet për ndryshimet në tekno logjinë e përdorur.Keshtu
qe, modelet konceptuale lehtësojnë mirëmbajtjen dhe evolucionin e databazës meqenëse
përqend rohen në kërkesat e përdoruesve, si pasojë japin mbështetje më të mirë për
ndryshim et në skemat logjike dhe fizike (Alejandro & Esteban,2014) . Bashkë me këtë
vendim u bënë parashikimet përkatëse të volumeve fizike të nevojshme për ruajtjen e
informacionit. Ruajtja në nivel shumë të detajuar të rekordeve të gjeneruar nga çdo platformë,
kërkon investim të lartë në hardware dhe gjithashtu një strategj i të mirëpërcaktuar të arkivimit
të tyre. Informacioni i shtuar çdo ditë në databazën destinacion është disa GB. Nga analiza e

81
përbashkët e kërkesave të grumbulluara u përcaktuan elementët, mbi bazë të të cilave
kërkohen matje, këto sipas modelit shumë dim ensional do të quhen dimensionet e skemës.
Gjatë modelimit konceptual, një vend të vecantë zuri analiza e elementit kohë. Dimensioni
kohë është pjesë e çdo analize të mundëshme, ai mund të jetë i nevojshëm deri në nivel
sekon de për analiza të detajuara (Juliana ,2014). Megjithëse dimensioni i datës është
dimensioni më i rëndësishëm i kohës, na duhet gjithashtu një dimension muaji kur shtrirja
kohore e tabelës së fakteve është një muaj. Në disa mjedise, mund të na duhet të ndërtojmë
dimensione javore, tremujo re ose vjetore si edhe nëse ka tabela faktesh në secilën prej këtyre
shtrirjeve (Kimball & Caserta.,2004) .Duke u bazuar në modelet shumë dimensionale,
elementi kohë u konsiderua si një dimension që ndryshon shumë shpesh dhe duhet të ndahet .
Sipas arsyetimit të mësipërm, dimensioni datë_kohë duhet të ndahet në dy tabela të skemës
tonë (Juliana ,2014).

Figura 4 .8 Ndarja e dimensioneve në skemën (Juliana ,2014).

82
Dimensioni i muajit duhet të jetë një tabelë fizike e veçantë dhe duhet të krijohet duke
eliminuar fizikisht rreshtat dhe kolonat e zgjedhura nga dimensioni i ditës kalendarike. Në
disa tabela faktesh, koha matet nën nivelin e ditës kalendarike, deri në minutën ose madje
edhe sekondën. Nuk mund të ndërtohet një dimension kohe me çdo minutë ose çdo sekondë
që ekziston. Ka më shumë se 31 milion sekonda në vit. Ne duam të ruajmë dimensionin e
fuqishëm të datës kalendarike dhe të mbështetim njëkohësisht kërkimin e saktë deri në
minutën ose sekondën. Gjithashtu mund të duam të llogarit im intervale kohore shumë të sakta
duke krahasuar kohën e saktë të dy regjistrimeve të tabelës së fakteve. Për këto arsye, ne
rekomandojmë ndërtimin e treguar në figura 4.9
Figura 4.9 Projektimi i t abeles fakt për trajtimin e matjeve në kohë të sakta (Kimball &
Caserta.,2004).
Komponent i i ditës kalendarike të kohës s ë saktë mbetet si çelësi i huaj referencë për
dimensionin tonë të njohur të ditës kalendarike. Mendojeni si një lloj të veçantë fakti, jo si
një di mension. Në këtë rast , është e dobishme të bëjmë një dimension komponentë minutash

83
ose sekondash të kohës të saktë, sepse llogaritja e in tervaleve kohore në rekordet e tabelës së
fakteve bëhet shumë e ngatërruar kur përpiqemi të merremi me dimensione të veçanta dite
dhe ore -të-ditës (Kimball & Caserta.,2004) .
Pjesa e kodit të proçedurës Oracle që popullon tabelën Dim_Kohe dhe Dim_Data është si më
poshtë:
CREATE OR REPLACE PROCEDURE POPULLIMI_KOHE_DIM
AS
v_koha_plote DATE;
v_sekonda NUMBER;
v_minuta NUMBER;
v_ore NUMBER;
v_key NUMBER;
v_koha_e_nisjes VARCHAR (40);
v_koha_e_arritjes VARCHAR (40);
v_koha_plote1 DATE;
BEGIN
DELETE FROM DIM_KOHE;
v_koha_plote := TO_DATE ('06 -04-15 00:00:00', 'DD -MM-YY
HH24:MI:SS');
v_koha_plote1:= TO_DATE ('28 -10-15 00:00:00', 'DD -MM-YY
HH24:MI:SS');
v_key := 1;
WHILE v_koha_plote < v_koha_plot e1
LOOP
BEGIN

v_sekonda := TO_CHAR (v_koha_plote, 'SS');
v_minuta := TO_CHAR (v_koha_plote, 'MI');
v_ore := TO_CHAR (v_koha_plote, 'HH24');
v_koha_e_nisjes:= TO_CHAR (v_koha_plote, 'HH24:MI:SS');
v_koha_e_arritjes:= TO_CHAR (v_koha_plote, 'HH24:MI:SS');

INSERT INTO DIM_KOHE
(Dim_kohe_Key,
sekonda,
minuta,

84
ore,
kohe_e_nisjes
kohe_e_arritjes)
VALUES (v_key,
v_sekonda,
v_minuta,
v_ore,
v_ kohe_e_nisjes
v_kohe_e_arritjes);
v_koha_plote := v_koha_plote + 1 / (24 * 60 * 60);
v_key := v_key + 1;
END;
END LOOP;
END;

Pjesa e kodit të proçedurës Oracle që popullon tabelën
Dim_Kohe është si më poshtë:

CREATE OR REPLACE PROCEDURE POPULLIMI _DATA_DIM
(p_data_fi llimit DATE,
p_data_mbarimit DATE)
AS
v_data_plote DATE;
v_dite_e_muajit NUMBER;
v_dite_e_vitit NUMBER;
v_dite_e_javes VARCHAR2 (30);
v_dita_e_lindjes VARCHAR2 (20);
v_dita_e_fillimit_te_trajtimit VARCHAR2 (40);
v_dita_e_perfundimit_te_trajtimit VARCHAR2
(40);
v_dita_e_lekundjes_seizmike VARCHAR2 (30);
v_nr_muaji NUMBER;
v_viti NUMBER;
v_katermujor NUMBER;
v_key NUMBER;
BEGIN
v_data_plote := p_data_fillimit;
v_key := 1;
WHILE v_data_plote < p_data_mbarimit
LOOP
BEGIN
v_dite_e_muajit := TO_CHAR (v_data_plote, 'DD');
v_dite_e_vitit := TO_CHAR (v_data_plote , 'DDD');
v_dite_e_javes := UPPER (TO_CHAR (v_data_plote, 'DAY'));
v_dita_e_lindjes:= UPPER (TO_CHAR (v_data_plote, 'DAY'));

85
v_dita_e_fillimit_te_trajtimit:= UPPER (TO_CHAR
(v_data_plote, 'DAY'));
v_dita_e_perfundimit_te_trajtimit:= UPPER
(TO_CHAR(v_data_p lote, 'DAY'));
v_dita_e_lekundjes_seizmike:= UPPER (TO_CHAR(v_data_plote,
'DAY'));
v_muaji := UPPER (TO_CHAR (v_data_plote, 'MONTH'));
v_nr_muaji:= TO_CHAR (v_data_plote, 'MM');
v_viti:= TO_CHAR (v_data_plote, 'YYYY');
v_katermujor:= TO_CHAR (v_data_plote, 'Q');
INSERT INTO Dim_Data (Dim_data_Key,

Data
Dita_ e_lindjes
Dita _e_fillimit_te_trajtimit
Dita_ e _perfun dimit_te_trajtimit
Dita_ e_lekundjes _seizmike
Dite_e_muajit
Dite_e_vitit
Dite_e_javes
Nr_muajit
Katermujor
Viti )

VALUES (v_key,
v_data_plote,
v_Dita_ e_lindjes
v_Dita _e_fillimit_te_trajtimit
v_Dita_e_perfundimit_te_trajtimit
v_Dita_e_lekundjes _seizmike
v_dite_e_muajit,
v_dite_e_vitit,
v_dite_e_j aves,
v_muaji,

86
v_nr_muaji,
v_katermujor,
v_viti);
v_data_plote := v_data_plote + 1;
v_key := v_key + 1;
END;
END LOOP;
END;
Ky dokument i përgatitur do të përbëjë thelbin e këtij datamart -i dhe do të shërbejë si një
fjalor (metadata). Mbasi perfundimit te modelit konceptual do vaz hdojme me ndertimin e
modelit logjik (Juliana ,2014).
4.6 Modelimi logjik
Modelimi logjik transformon modelin e të dhënave konceptuale në një model dimensional, i
njohur zakonisht si skema yll. Përbëhet nga një tabelë e madhe faktesh (e njohur si tabela e
fakteve), me një numër tabelash të tjera që e rrethojnë të cilat përmbajnë të dhëna
përshkruese, të quajtura dimensione. Modeli i të dhënave logjike përfshin veçoritë e
mëposhtme:
• Përfshin të gjitha entitetet dhe marrëdhëni et midis tyre.
• Të gjitha atributet për çdo entitet janë të përcaktuara.
• Çelësi kryesor për çdo entitet është i përcaktuar.
• Çelësat e huaj ‘foreign keys‘ (çelësat që përcaktojnë marrëdhënien midis entiteteve të
ndryshme) janë të përcaktuara.
Në këtë nivel, modeluesi i të dhënave përpiqet të përshkruajë të dhënat me sa më shumë
detaje të jetë e mundur, pa u shqetësuar për mënyrën se si do të implementohen fizikisht në
databazë. Secili prej emrave të dimensioneve i treguar në diagramin me pika zakonisht bëhet

87
një tabelë dimensionesh e veçantë në skemën yll. Sidoqoftë, çelësat natyralë duhet të
zëvendësohen me të ashtuquajturit çelësa zëvendësues 'surrogate key‘ . Çelësi zëvendësues
është një çelës për rreshtin e databazës që është unik për çdo rresht në n jë tabelë dimensionesh
dhe nuk nxirret nga të dhënat e rreshtit. Secili prej këtyre çelësave duhet të jetë një numër
dhjetor i thjeshtë , duke filluar me 1 dhe duke shkuar në numrin më të madh që nevojitet
(Kimball & Caserta.,2004) . Lidhjet midis tabelave dimension dhe tabelës fakt duhet të
bazohen ekskluzivisht në këto çelësa. Zakonisht një ‘primary key‘ i tabelës fakt është një
bashkim i çelësave. Ka disa arsye përse duhet të përdoren ‘surrogate keys‘ dhe një prej tyre
është nevoja për të rregjistruar të dhëna të pasigurta. Kjo situatë zakonisht njihet me termin
‘nuk e di‘ dhe mundëson të shtosh një rrjesht në tabelën e dimensioneve, që do të ketë si vlerë
të barabartë me -1. Këto mund të përfshijnë rekordet problematike, me informacione jo të
plota. Ekzist on gjithashtu një tjetër problem që lidhet me përfshirjen e kohës dhe duhet të
konsiderohet me kujdes gjatë modelimit llogjik. Në rastet kur duhet të kontrollohen
ndryshimet, është e papranueshme të ndërtohet çdo dimension si i varur nga koha.
Dimensionet e pavarura nga koha janë të njohura me emrin SCD (dimensione shumë pak të
ndryshueshme).
Analiza e problemit dhe zgjidhja e tij.
Duke pas parasyshe shumicen e teknikave per ndertimin e DWH /datamart,analizimi i
kerkesave cilesohet njera nga prioritet pare sore tek procesi i ndertimit te
DWH/datamart.Duke ndjekur modelin Kimball ,identifikimi i elementeve baze te modeleve
shume dimensionale ,mund te perkufizohet permes sistemit matrice e lidhjes
Dimension/fakt /matje ( Tabela 4.2 ).Pra ndertimi i datamart -it do bazohet mbi matricen qe
percakton qarte elementet e skemes.

88

Tabela 4 .2 Matrica Dimension /Fakt

Dimensione/Fakte

Dim_Kohe

Dim_ Grupi i gjakut

Dim_ Adresa

Dim_ Data

Dim_ Instituti Shendetsor

Tabela Fakt_IMK X X X X X

Per rastin tone dimensionet jane:
– Koha , perben informacionin kalendarik (diten ,muajin ,vitin,oren,minuten,sekonden ).Qe
vlersohet njera nga dimensionet me te detajuara.
-Grupi i gjakut , paraqet njeren nga dimensionet me te detajuar lidhur me pacientet .
-Adresa ,zakonishte eshte njera nga me te veqantat ne ndertimin e nje datamarti.
-Data ,Informacioni me i detajuar si dimension, qe ruan te dhena ne baze te dative.
-Instituti shendetsor ,paraqet institucionin qe menaxhon me nje numer te madh te pikave qe
ofrojne sherbime ne fushen shendetsore .
Ndërsa tabela Fakt eshte:

89
-TabelaFakt_IMK ,ruan informacione nga institucioni mjeksor i Kosoves ,qe ne vete perben
nje game te gjere te te dhenave .Ku perfshihen te dhenat nga shume burime te te dhenave te
fushes se perkujdesit mjeksor. Skema e datamart -it paraqitet si më poshtë:
Figura 4.10 Skema e datamart -it të IMK

Në rastin e datamart -it të IMK nje ‘dimension junk‘ do të përfshinte të dhënat bazike te
mbiemrit, emrit,gjinia ,emri i prindrit ,vendi i lindjes ,profesioni dhe adresa etj. Në
skemë do të përfaqë sojnë një dimension të veçantë. Përveç strukturimit të dimens ioneve duhet
të ndërtohen edhe tabela fakt. Zakonisht kjo tip tabele përmban të gjitha ‘foreign keys‘, si
dhe të gjitha matjet numerike të quajtuara si fakte. Në rastin e tabelës fakt të modelit do të
jetë vetëm një matje numerike që ka të bëjë me kohëzgja tjen e komunikimeve ne IMK. ( Lula
& Kika , 2012 :230).
Për çdo atribut në një tabelë dimension, duhet të përcaktohet një strategji për të ruajtur
ndryshimet. Ka gjithësej tre tipe teknikash :

90
4.6.1 Tipi 1 – SCD
Megjithëse vendosja e rekordeve të reja në një SCD Tipi 1 kërkon gjenerimin e çelësave të
rinj të dimensionit, ndryshimet e përpunimit në një SCD Tipi 1 nuk ndikon asnjëherë në
çelësat e tabelës së dimensioneve ose çelësat e tabelës së fakteve dhe në përgjithësi ka
ndikimin më të vogël në të dhënat e tre llojeve SCD. SCD Tipi 1 mund të ketë një ndikim në
ruajtjen e tabelave të fakteve agregate, nëse ndonjë agregate ndërtohet direkt në atributin që
u ndryshua.Bazuar në çelësin natyral të nxjerrë n ga sistemi burim, çdo rekord i ri i caktoh et
një çelësi zëvendësues të ri dhe i lidhur me të dhënat e dimensioneve ekzi stuese. Rekordet
ekzistuese update -ohen në vend. Performanca e kësaj teknike mund të jetë më e dobët në
krahasim me ngarkimin në një ngarkues në shumicë, por nëse tabelat janë me madhësi të
arsyeshme, impakti duhet të jetë i pranueshëm. Disa mjete ETL ofrojnë transformime të
specializuara që mund të zbulojnë nëse një duhet të futet apo të update -ohet një re kord.
Sidoqoftë, ky utilitet duhet të ngulë tabelën duke përdorur çelësin kr yesor të regjistrimit të
kandidatit për të parë nëse ekziston. Kjo qasje është proces intensiv dhe duhet të shmanget.
Për të minimizuar goditjen e performancës kur përdoret SQL për të ngarkuar një dimension
Tipi 1, procesi ETL duhet të veçojë qartë të dhën at ekzistuese q ë kërkojnë deklarata
UPDATE nga t ë dhënat që kërkojnë INSERT (Kimball & Caserta.,2004) .
Sipas kësaj teknike, atributi i vjetër do të mbivendoset nga vlera e re. Kjo është shumë e lehtë
për tu aplikuar, por nuk mirëmban asnjë historik të vlerave të hershme për këto dimensione.
Prandaj është më e përshtatshme që kjo teknikë të përdoret për të ruajtur vlera të korrigjuara
pa u shqetësuar për historikun ( Lula & Kika , 2012 :230).
4.6.2 Tipi 2 -SCD

91
Kur DWH njoftohet se një regjistrim dimensio ni ekzistues duhet të ndryshohet, në vend se
të mbishkruhet, DWH lëshon një regjistrim dimensioni të ri në momentin e ndryshimit. Këtij
regjistrimi dimensioni të ri i caktohet një çelës kryesor zëvendësues i freskët, dhe ai çelës
përdoret nga ai moment e t utje në të gjitha tabelat e fakteve që kanë atë dimension si çelës të
huaj. Për sa kohë çelësi i ri zëvendësues i caktohet menjëherë në momentin e ndryshimit,
asnjë çelës ekzistues në çdo tabelë faktesh nuk ka nevojë të përditësohet ose ndryshohet, dhe
asnjë tabelë faktesh agregate nuk ka nevojë të rillogaritet. Ne themi se SCD Tipi 2 e ndan
historinë në mënyrë perfekte sepse çdo version i detajuar i entitetit dimensional është i lidhur
saktë me shtrirjen e regjistrimeve të tabelës së fakteve për të cilin a i version është shumë i
saktë. Në Figura 4.11 , ilustrohet .
Figura 4.11 Tipi 2 SCD historiku perfekt i particioneve

Për një dimension të vogël me disa mijëra rekordesh dhe nja dhjetë fusha, si për shembull
një skedë e thjeshtë produkti, zbulimi i ndryshimeve i treguar në Figura 5.16 mund të bëhet
me forcë, duke krahasuar çdo fushë në çdo rekord në shkarkimin e sotëm me çdo fushë në
çdo rekord nga i djeshmi. Duhet të gje nden shtimet, ndryshimet dhe fshirjet. Por për një
dimension të m adh, një listë e tillë me milion a pacientë të siguruar me 100 fusha përshkruese

92
në çdo rekord , qasja e forcës të krah asimit të çdo fushe në çdo rekord është shumë joefikase
(Kimball & Caserta.,2004) .Kjo teknikë përdoret më së shumti në dimensionet SCD. Kjo
metodë mundëson krijimin e një rreshti të ri, sa herë që duhet të ndryshohet ndonjë atribut i
dimensionit. Gjithë atributet e tjera do të jenë me të njëjtat vlera. Normalisht një tjet ër
‘surrogate key‘ do të gjene rohet për këtë rresht të ri ( Lula & Kika , 2012 :230)
4.6.3 Tipi 3 -SCD
Përdoret kur ndodh një ndryshim në një dimension regjistrimi por vlera e vjetër e atributit
mbetet e vlefshme si zgjedhje e dytë. Dy situa tat më të zakon shme të IKM ku ndodh kj o janë
ndryshimet , ku caktimi i territorit të vjetër duhet të vazhdojë të jetë në dispozicion si zgjedhje
e dytë, dhe ndryshimet në caktimet Nr rendor -Profesioni , ku caktimi i Profesioni i Vjetër
duhet të vazhdojë të jetë i disponueshëm si zgjedhje e dytë. Arkitekti i DWH duhet të dallojë
fushat që kërkojnë administrimin e Tipit 3. Në SCD Tipi 3, në vend se të lëshohet një rresht
i ri kur bëhet një ndryshim, krijohet një kolonë e re (nëse nuk ekzis ton tashmë), dhe vlera e
vjetër vendoset në këtë fushë të re para se të mbishkruhet vlera primare. Për shembullin e Nr
rendor -Profesioni , ne supozojmë që fusha kryesore quhet Profesioni . Për të implementuar
SCD Tipi 3, ne ndryshojmë tabelën e dimensioneve për të shtuar fushën Profesioni i Vjetër.
Në kohën e ndryshimit, ne e marrim vlerën origjinale të Profesioni dhe e shkruajmë atë në
fushën Profesioni i Vjetër; pastaj e mbishkruajmë fushën e Profesioni sikur të ishte ndryshim
Tipi 1. Shiko Figura 4.12
Figura 4.12 Implementimi i Tipit 3 -SCD ne pershkrimin e nr rendor -profesioni

93

Nuk ka nevojë të ndryshohen çelësat në asnjë tabelë dimensionesh ose asnjë tabelë faktesh.
Njëlloj si SCD Tipi 1, nëse tabelat agregate janë ndërtuar direkt në fushën poshtë ndryshimit
Tipi 3, këto tabela agregate duhet të rillogariten.
Kur shtohet një re gjistrim i ri në një dimension që përmban fusha Tipi 3, duhe t të nxirret një
rregull IMK -se për të vendosur si të popullohet fusha e vlerës të vjetër. Vlera aktuale mund
të shkruhet në këtë fushë, ose mund të jetë NUL L, në varësi të rregullit të IMK -SE . Ne
shpesh e përshkruajmë SCD Tipi 3 si mbështetës të një realiteti alternativ. Në shembullin
tonë Nr rendor -Profesioni , përdoruesi final mund të zgjedhë midis dy versioneve të hartimit
të Nr rendor në Profesion . Qasja SCD Tipi 3 mund të zgjatet në shumë rea litete alternative
duke krijuar një numër arbitrar fushash alternativ e bazuar në atributin origjinal (Kimball &
Caserta.,2004) .Sipas kësaj teknike duhet të rregjistrohen vlerat para dhe pas ndryshimit. Kjo
realizohet me shtim të një kolone të re për vlerën e shtuar. Kjo teknikë përdoret shumë rrallë.

94
Zakonisht në praktikë kombinohen teknika e parë dhe e dytë për të njëjtin rresht informacioni,
sepse mund të ketë fusha për të cilat mund të ruhen ose jo ndryshimet ( Lula & Kika , 2012
:230) .
Një situatë tjetë r shumë e zakonshme, kur bëhet fjala për modelimin logjik, është kur ka një
nevojë për të përfshirë disa flamuj dhe tregues që janë të lidhur dukshëm me dimensionet,
por nuk përshtaten në asnjë prej tabelave të dimensioneve të konformuara. Në teori, ka kat ër
zgjidhje për këtë problem:
• Flamujt dhe treguesit jane pjese e tabelës fakteve.
• Nxirr të gjithë flamujt dhe treguesit nga ndërtimi.
• Vendos çdo flamur dhe tregues në dimensionin e tij të veçantë(perkates).
• Bashkohen të gjithë flamujt dhe treguesit në një ose më shumë’ dimensione junk’.
Në praktikë, vetëm zgjidhja e fundit eshte e pershtatshme. Një dimension shumice është një
grupim i mirë i flamujve dhe treguesve (kjo mund të bëhet gjithashtu për të dhëna të tjera jo
përkatëse të cilat do të kishin kuptim të kombinoheshin). Përfshin të gjitha kombinimet e
vlefshme të atributeve, të cilat nënkuptojnë që seti i të dhënave finale do të ishte një produkt
kartezian i të gjithë flamujve dhe treguesve individualë. Nëse të gjitha vlerat e mundshme
rezultojnë në një set të dhënash të vogël, me shumë mundësi është më mirë që rresh tat të
krijohen më përpara (Kimball & Caserta.,2004) .
4.7 Modelimi fizik
Në këtë nivel, modeluesi i të dhënave përcakton mënyrën se si do të realizohet modeli i të
dhënave logjike në skemën e databazës. Objektivat e procesit të ndërtimit fizik nuk

95
përqendrohen në struktura. Modeluesi është më i shqetësuar për mënyrën si do të p unojë
modeli në vend se në mënyrën si do të duket.
Sipas Ponniah, ka disa hapa të ndryshëm në procesin e ndërtimit f izik për një DWH :
o Zhvillimi i standardeve.
Standardet variojnë nga mënyra si të emërtohen fushat në databazë deri në bërjen e
intervistave me përdoruesit finalë për përkufizimin e kërkesave. Standardi për emërtimin e
objekteve merr domethënie të veçantë sepse përdorimi i emrave të objekteve nuk është i
kufizuar vetëm për specialistët IT. Përdoruesit i referohen gjithashtu objekteve me emra, k ur
krijojnë dhe bëjnë kërkimet e tyre. Kjo është arsyeja pse emri vetë duhet të jetë në gjendje të
përcjellë kuptimin dhe përshkrimin e objektit. Gjithashtu është e nevojshme të adoptohen
standarde efektive për emërtimin e strukturës të të dhënave në fazën e skenimit, si edhe të
gjitha llojet e skedave (jo vetëm skedat e të dhënave dhe indekseve, por gjithashtu skedat që
përmbajnë kode dhe skripte, skeda databaze dhe dokumente aplikacionesh).
o Krijimi i planeve te te dhenave te grumbulluara.
Në këtë hap, duhet të shqyrtohen mundësitë për ndërtimin e tabelave te te dhenave te
grumbulluara. Është e mundur që shumë prej te dhenave te grumbulluara do të tregohen në
sistemin OLAP. Sidoqoftë, nëse rastet OLAP nuk janë për përdorim universal nga të g jithë
përdoruesit, atëherë te dhenat e grumbulluara duhet të tregohen në DWH. Ka dy faktorë
kryesorë që duhet të merren në konsideratë kur merret një vendim per planin e të dhenave te
grumbulluara.
-Së pari, modelet e aksesit të përdoruesve të biznesit d uhet të merren parasysh – të dhënat që
ata po përmbledhin shpesh here duhet të paraqiten në DWH .

96
-Së dyti, duhet të vlerësohet shpërndarja statistikore e të dhënave (p.sh. sa raste unike
ekzisto jnë në secilin nivel hierarkie dhe cili është forma e shpernd arjes në rast të lëvizj es
nga një nivel në tjetrin) .
o Përcaktimi i skemes se ndarjes të të dhënave.
Duhet të merren parasysh mundësitë e ndarjeve për tabelat e fakteve, si edhe tabelat e
përmasave. DWH zakonisht mban tabela databaze shumë të mëdha. Tab elat e fakteve janë
në miliona rreshta, dhe shumë tabela dimensionesh (p.sh. tabelat e klientëve) përmbajnë një
numër të madh rreshtash gjithashtu. Duke pasur tabela me madhësi kaq shumë të mëdha,
hasen disa probleme të caktuara. Ngarkimi i tabelave të mëd ha dhe ndërtimi i indekseve
kërkon shumë kohë. Kërkimet gjithashtu zgjatin më shumë, rezervimi dhe rikuperimi i
tabelave të mëdha gjithashtu. Kjo është arsyeja pse ndarja në particione është e rëndësishme.
Ndarja në particione do të thotë ndarja e qëllimsh me e një tabele dhe e të dhënave të indeksit
në pjesë të menaxhueshme. Sistemi i menaxhimit të databazës (DBMS) mbështet dhe siguron
mekanizmin për këtë. Çdo particion i një tabele trajtohet si objekt më vete. Particionet mund
të shpërndahen nëpër disa dis qe për të arritur performancë optimale. Një tabelë shumë e
madhe mund të ndahet vertikalisht ose horizontalisht. Në ndarjen vertikale, njëra ndan
particionet duke i grupuar kolonat e zgjedhura së bashku. Në këtë skenar, çdo tabelë e ndarë
në particione për mban të njëjtin numër rreshtash si tabela origjinale. Zakonisht, tabelat me
dimensione të mëdha janë kandidate për ndarjen vertikale. Në rast të ndarjes horizontale,
tabela ndahet duke i grupuar rreshtat e zgjedhur së bashku. Ndarja horizontale e tabelës t ë
mëdha të fakteve të bazuara në datat kalendarike zakonisht punon mirë në një mjedis të
DWH . Skema e ndarjes në particione duhet të përfshijë të mëposhtmet: tabelat e fakteve dhe
tabelat e dimensioneve të zgjedhura për ndarjen në particione, lloji i ndarj es për çdo tabelë

97
(horizontal ose vertikal), numri i particioneve për çdo tabelë, kriteret për të ndarë çdo tabelë
dhe përshkrimi se si të bëhen kërkime që janë në dijeni të particioneve (një kërkim ka nevojë
të përdorë vetëm particionet e nevojshme). Çdo DBMS ka mënyrën e vet të caktuar të
implementimit të particioneve fizike. Një nga shumë konsideratat e rëndësishme kur zgjidhet
DBMS është mbështetja e saj për ndarjen në particione dhe indeksimi.

Create table Tabela_Fakt_IMK
(

Nr_rendor_pacienti NUMBER (8) not null,
Mbiemri VARCHAR2 (50) not null,
Emri VARCHAR2 (50) not null,
Mbiemri i vajzerise VARCHAR2 (50) not null,
Dim_Data_KEY NUMBER(4)not null,
Dim_kohe_KEY NUMBER (5) not null,
Gjinia CHAR (3) not null,
Emri Prindit VARCHAR2 (50) not null,
Vendi i lindjes VARCHAR2 (50) not null,
Grupiigjakut_Key NUMBER (5) not null,
Institu_shendetsor_Key NUMBER (5) not null,
Profesioni VARCHAR2 (25) not null,
Adresa_Key NUMBER (5) not null,
)
PARTITION BY RANGE ( Dim_Data_KEY )
SUBPARTITION BY Hash (ROUTING_CATEGORY)

(
PARTITION Qershor_2015 values less than (TO DATE (’01 -JAN-
2015’,’dd -MON-yyyy’))
TABLESPACE IMK_tbl
PCTFREE 10
INITRANS 1
MAXTRANS 255
(
SUBPARTITION p1 TABLESPACE IMK_tbl,
SUBPARTITION p2 TABLESPACE IMK_tbl,
SUBPARTITION p3 TABLESPACE IMK_tbl,
SUBPARTITION p4 TABLESPACE IMK_tbl,
SUBPARTITION p5 TABLESPACE IMK_tbl,
SUBPARTITION p6 TABLESPACE IMK_tbl,

98
SUBPARTITION p7 TABLESPACE IMK_tbl,
SUBPARTITION p8 TABLESPACE IMK_tbl,
)
…
…
ALTER TABLE Tabela_Fakt_IMK
ADD constraint trafiku_PRIM primary key
(Nr_rendor_Pacientit)
using index
tablespace trafiku_index
pctfree 10
initrans 2
maxtrans 255
storage
(
initial 64K
next 1M
minextents 1
maxextents unlimited );

o Themelimi i opsioneve të bashkimit të copave.
Bashkimi i copave përfshin vendosjen dhe menaxhimin e njësive përkatëse të të dhënave në
të njëjtin bllok fizik memorieje. Në këtë mënyrë, ato njësi mblidhen së bashku në një veprim
të vetëm. Për të krijuar mundësitë e mira për bashkimin e copave, tabelat duhet të
ekzaminohen me kujdes dhe duhet të gjenden çiftet që janë të lidhura me njëra tjetrën.
Rreshtat nga tab elat përkatëse zakonisht mblidhen së bashku për përpunim dhe është e
mençur që ato të ruhen së bashku në të njëjtën skedë në mjet.
o Caktimi i strukturave të memories.
Plani i memories duhet të përcaktojë ku do të vendosen të dhënat në mjetin e memories
fizike, skedat fizike, si edhe plani për caktimin e çdo tabele në skeda specifike, dhe mënyra
se si çdo skedë fizike duhet të ndahet në blloqe të dhënash.
o Përfundimi i modelit fizik.

99
Ky është hapi final që rishikon dhe konfirmon plotësimin e aktiviteteve dhe detyrave të
mëparshme.Triologjia konceptuale/logjike/fizike e përshkruar në këtë pjesë, sipas opinionit
të autorit, është praktika më e mirë për modelimin e DWH . DWH siguron platformën për
analizën OLAP.
o Menaxhimi i particioneve
Particionet e lejojnë një tabelë (dhe treguesit e saj) të ndahen fizikisht në mini tab ela për
qëllime administrative dhe për të përmirësuar performancën e kërkimit. Dobia finale e
copëzimit të një tabele është se një kërkim që kërkon një muaj të dhënash ng a një tabelë që
ka dhjetë vjet të dhënash mund të shkojë direkt në particionin e tabelës që përmban të dhënat
për muajin pa skanuar të dhënat e tjera. Particionet e tabelave mund të përmirësojnë në
mënyrë dramatike performancën e kërkimit në tabela të mëdh a faktesh. Particionet e një
tabele janë të mbuluara , të fshehura nga përdoruesit. Vetëm stafi DBA dhe ETL duhet të jetë
në dijeni të particioneve. Meqenëse përdoruesit zakonisht kufizohen në kolonat në
dimensionin e datës, ju duhet të ndani tabelën e fakt eve në kyçin që i bashkohet dimensionit
të datës në mënyrë që optimizuesi të njohë kufizimin. Tabelat që janë ndarë nga një interval
date zakonisht ndahen sipas vitit, tremujorit ose muajit. Faktet shumë voluminoze mund të
ndahen sipas javës ose ditës. Zak onisht, ndërtuesi i DWH punon me stafin DBA për të
përcaktuar strategjinë më të mirë të copëzimit në bazë tabelë -pas-tabele. Stafit ETL duhet t'i
tregohet për çdo particio n tabele që duhet të mirëmbahet (Kimball & Caserta.,2004) .
4.8 Përgatitja e një strat egjie indeksimi.
Plani i indeksimit duhet të tregojë indekset për çdo tabelë. Për më tepër, për çdo tabelë, duhet
të përcaktohet sekuenca në të cilin do të krijohen indekset. Gjithashtu, indekset që janë
pranuar të ndërtohen në çdo rast të parë të databazës duhet të përshk ruhen. Ofruesit e DBMS

100
ofrojnë një sërë teknikash indeksimi. Zgjedhja nuk është më e kufizuar vetëm në skedat e
indeksit në sekuencial. Të gjithë ofruesit mbështetin indekset B -tree për gjetjen efikase të të
dhënave. Një mundësi tjetër është indeksi bit -map. Tabelat e dimensioneve duhet të kenë një
indeks unik në çelësin kryesor me një kolonë. Kimball gjithashtu rekomandon një tregues B –
tree në kolonat e atributeve me kardinalitet të lartë të përdorura për kufizimet dhe vendosjen
e indekseve bit -map në të g jitha atributet me kardinalitet të mesëm dhe të lartë. Në rastin e
tabelave të fakteve, çelësi kryesor është pothuajse gjithmonë një nënset i çelësave të huaj. Në
këtë rast është e mençur të vendoset një indeks i vetëm, i përqendruar në dimensionet
kryesor e të tabelës së fakteve. Pasja e një çelësi date ndihmon gjithashtu në përmirësimin e
performancës. Meqenëse mund të përdoret më shumë se një indeks në të njëjtën kohë duke
zgjidhur një kërkim, mund të ndërtohen gjithashtu indekse të veçanta në çelësat e h uaj të
pavarur në tabelën e fakteve . Indeksimi është ndoshta mekanizmi më i efektshëm për
përmirësimin e performancës. Sidoqoftë, pasja e një numri shumë të madh indeksesh
ngadalëson ngarkimin e të dhënave në magazinë, veçanërisht gjatë ngarkimeve fillesta re. Ky
problem mund të zgjidhet duke rrëzuar indekset para se të bëhen punët e ngarkimit. Në këtë
rast, ato nuk do të krijojnë hyrje indeksi gjatë procesit të ngarkimit, por ndërtimi i skedave të
indeksit mund të bëhet pasi të përfundojë procesi i ngarkimi t. Ka edhe diçka tjetër që duhet
mbajtur në mendje, dhe ky është fakti se tabelat e mëdha (me miliona rreshta) nuk mund të
mbështetin shumë indekse. Kur një tabelë është shumë e madhe, pasja e më shumë se një
indeksi vetë mund të shkaktojë vështirësi. Nëse është i nevojshëm më shumë se një indeks,
tabela duhet të ndahet para se të përcaktohen më shumë indekse. Kolonat më të përshtatshme
për indeksimin janë ato që përdoren shpesh për të kufizuar kërkimet. Sidoqoftë, praktika më
e mirë është të fillohet me in dekset vetëm në çelësat kryesorë dhe të huaj të çdo tabele. Pastaj,

101
pas monitorimit të performancës me kujdes, mund t ë shtohen disa indekse të tjera (Kimball
& Caserta.,2004) .
4.8.1 Indeksimi i Data Warehouse
Në një sistem kërkim -qendror si mjedisi i DWH, dominon nevoja për të përpunuar kërkesat
më shpejt. Nuk ka mënyrë më të sigurt për t'i larguar përdoruesit tuaj nga DWH se kërkesat
shumë të ngadalta. Për përdoruesin në një seancë analize që kalon nëpër një s eri të shpejtë
kërkesash komplekse, ju duhet të përshtatni ritmin e rezultateve të kërkimit me shpejtësinë e
mendimit. Mes metodave të ndryshme për të përmirësuar performancën, indeksimi radhitet
shumë lart. Çfarë lloje indeksesh duhet të ndërtoni në DWH ? Ofruesit DBMS ofrojnë një
sërë mundësish. Zgjedhja nuk është më e kufizuar vetëm në skedat e indeksit në sekuencial.
Të gjithë ofruesit mbështetin indekset B -Tree për gjetjen efikase të të dhënave. Një mundësi
tjetër është indeksi bit -map. Siç do ta shohim më tej në këtë pjesë, kjo teknikë indeksimi
është shumë e përshtatshme për mjedisin e DWH. Disa ofrues po e shtojnë fuqinë e
indeksimit sipas kërkesave specifike. Këto përfshijnë indekse mbi tabela të copëzuara dhe
tabela të organizuara me indekse.
4.8.2 Përmbledhje e indeksimit
Le të marrim në konsideratë teknikën e indeksimit nga këndvështrimi i DWH . Tabelat e të
dhënave janë vetëm të lexueshme. Kjo veçori do të thotë që pothuajse asnjëherë nuk i
përditësoni regjistrimet apo t'i fshini regjistrimet. Dhe regjistrimet nuk futen në tabela pas
ngarkimeve. Kur bëni shtime, përditësime ose fshirje, ju hasni ngarkesë shtesë për
manipulimin e skedave të indeksit. Por në një DWH nuk ndodh kështu. Kështu ju mund të
krijoni një numër indeksesh për çdo tabelë. Sa ind ekse mund të krijoni për tabelë? Shumica
e indeksimit bëhet në tabelat e dimensioneve. Në përgjithësi, do të shikoni shumë më tepër

102
indekse në një DWH sesa në një sistem OLTP. Kur një tabelë rritet në volum, indekset
gjithashtu rriten në madhësi, duke kërk uar më shumë memorie. Rregulli i përgjithshëm është
se numri maksimal i indekseve ndryshon anasjelltas me madhësinë e tabelës. Numrat e
mëdhenj të indekseve ndikojnë në procesin e ngarkimit pasi indekset krijohen për regjistrimet
e reja në atë moment. Ju d uhet të balanconi faktorët e ndryshëm dhe të vendosni mbi numrin
e indekseve për tabelë. Rishikoni tabelat, një nga një. Në pjesën e mbetur të kësaj pjese, do
të studiojmë më thellë teknikat specifike të indeksimit. Para se të bëjmë këtë, ju lutem vini
re parimet e përgjithshme të mëposhtme. Indekset dhe ngarkimi
Kur keni një numër të madh indeksesh, ngarkimi i të dhënave në magazinë ngadalësohet
ndjeshëm. Kjo ndodh sepse kur shtohet çdo regjistrim në tabelën e të dhënave, duhet të
krijohet çdo indeks përkatës. Problemi është më i madh gjatë ngarkesave fillestare. Mund ta
adresoni këtë problem duke i rrëzuar indekset para se bëni punët e ngarkimit. Duke bër ë këtë,
punët e ngarkimit nuk do të krijojnë hyrje indeksi gjatë procesit të ngarkimit. Pasi të mbarojë
procesi i ngarkimit, mund të bëni punë të veçanta për të ndërtuar skedat e indeksit. Ndërtimi
i skedave të indeksit kërkon kohë të madhe, por jo aq sa k rijimi i hyrjeve të indeksit gjatë
procesit të ngarkimit .
4.8.3 Indeksimi për tabelat e mëdha
Tabelat e mëdha me miliona rreshta nuk mund të mbështetin shumë indekse. Kur një tabelë
është shumë e madhe, pasja e më shumë se një indeksi vetë mund të shkakto jë vështirësi.
Nëse ju duhet të keni shumë indekse për tabelë, merrni parasysh ta ndani tabelën para se të
përcaktoni më shumë indekse.
4.8.4 Indeksimi vetem me lexim

103
Siç e dini, në procesin e gjetjes të të dhënave, regjistrimi i indeksit më parë lexohet dhe pastaj
bëhet leximi i të dhënave përkatëse. DBMS zgjedh indeksin më të mirë mes shumë
indekseve. Le të themi se DBMS përdor një indeks të bazuar në katër kolona në një tabelë
dhe shumë përdorues në mjedisin tuaj kërkojnë të dhëna nga këto katër kolona dhe një kolonë
më shumë në tabelë. Si bëhet gjetja e të dhënave? DBMS përdor këtë indeks për të gjetur
regjistrimin përkatës të të dhënave. Ju duhen të paktën dy veprime input -output (I/O). Në
këtë rast, DBMS duhet të gjejë regjistrimin e të dhënave vetëm për një kolonë shtesë. Në
raste të tilla, merrni parasysh shtimin e asaj kolone ekstra në indeks. DBMS do të lexojë
indeksin dhe do të zbulojë se të gjitha informacionet që duhen ndodhen në vetë regjistrimin
e indeksit, prandaj nuk do të lexojë regjistrimi n e të dhënave në mënyrë të panevojshme.
4.9 Efektet e indekseve
DWH përdoret sepse është shumë më e shpejtë dhe më e besueshme se sistemi i transaksionit.
Avantazhi i shpejtësisë që ofron DWH është për shkak të një numri veçorish kyçe:
 Modeli i të dhënave dimensionale i cili lejon indeksimin e ndërtuar qëllimisht të
dimensioneve dhe fakteve
 Strategjia e indeksit agresiv
 Regjistrimet të ruajtura fizikisht
 Paralelizmi i kërkimit
Teknikat e ndërtimit dhe dobitë e të dhënave dimensionale janë treguar me hollësi në këtë
literature dhe janë në dispozicion në një gamë gjerë të tjera. Në këtë pjesë do të flasim për
një minutë rreth indekseve.Indekset janë shtylla e kohës kërkesë -përgjigje në DWH . Çdo
kërkim që godet databazën përdor të paktën një indeks. Fatk eqësisht, në aq sa indekset

104
ndihmojnë përdoruesit të kërkojnë DWH, stafi ETL është i ngarkuar me barrën për të
menaxhuar indekset ekzistuese gjatë procesit ETL.Menaxhimi i indekseve llogaritet për një
pjesë të konsiderueshme të shumicës së proceseve ETL. P ara se të zhytemi në teknikat për
menaxhimin e indekseve gjatë ngarkesës të DWH, është e rëndësishme që të shqyrtojmë
llojet e ndryshme të indekseve që janë në dispozicion në shumicën e databazave. Kryesisht,
do të gjeni dy lloje indeksesh dhe është e rënd ësishme të kuptoni dallimin midis dy llojeve
(Kimball & Caserta.,2004) .
4.9.1 Indeksi B-Tree Shumica e sistemeve të menaxhimit të databazave kanë teknikën e
indeksit B -Tree si metodë standarde të indeksimit. Kur kodoni deklarata duke përdorur
gjuhën e përkufizimit të të dhënave të softuerit të databazës për të krijuar një indeks, sistemi
krijon in deksin B -Tree. DBMS gjithashtu krijon automatikisht indekse mbi vlerat kryesore
kyçe. Teknika e indeksit B -Tree është superiore ndaj teknikave të tjera për shkak të
shpejtësisë të gjetjes të të dhënave, lehtësisë të mirëmbajtjes dhe thjeshtësisë. Figura 4.13
tregon një shembull të një indeksi B -Tree.
Figura 4.13 Struktura e nje indeksi B -Tree (Ponniah ,2010).

105

Vini re strukturën pemë me rrënjët në krye. Indeksi përbëhet nga një strukturë B -Tree (një
pemë binare e balancuar) e bazuar mbi vlerat e kolonës të indeksuar. Në shembullin, kolona
e indeksuar është Emri. Kjo B -Tree krijohet duke përdorur të gjithë emrat ekzistues të cilat
janë vlerat e kolonës të indeksuar. Vini re blloqet e sipërme që përmbajnë të dhënat e indeksit
të drejtuara në bllokon tjetër më poshtë. Mendojeni si një indeks B -Tree që përmban nivele
hierarkike të blloqeve. Blloqet në nivelin më të ulët tregojnë në rreshtat në tabelën e të
dhënave. Nëse një kolonë në një tabelë ka shumë vlera unike, atëherë selekti viteti i kolonës
thuhet të jetë e lartë. Në një tabelë dimensioni territori, kolona për Qytetin përmban shumë
vlera unike. Prandaj kjo kolonë është shumë selektiv. Indekset B -Tree janë më të
përshtatshmet për kolonat shumë selektive. Për shkak se vlerat e nyjeve do të jenë unike ato
,qe çojnë në rreshta të qarta të dhënash dhe jo në një zinxhir rreshtash. Po nëse një kolonë e

106
vetme nuk është shumë selektive? Si mund ta përdorni indeksimin B -Tree në këto raste? Për
shembull, kolona e parë e emrit në një tab elë punonjësish nuk është shumë selektive.
Ekzistojnë shumë emra të njëjtë. Por mund ta përmirësoni selektivitetin duke lidhur emrin
me mbiemrin. Kombinimi është shumë më selektiv. Krijoni një indeks B -Tree të lidhur mbi
të dyja kolonat së bashku. Indekset rriten në përpjestim të drejtë me rritjen e tabelës të
indeksuar të të dhënave. Kurdoherë që indekset përmbajnë një lidhje të disa kolonave, ato
kanë prirjen të rriten në madhësi. Ndërsa DWH merret me volume të mëdha të dhënash,
madhësia e skedave të inde ksit mund të jetë shkak për t'u shqetësuar. Çfarë mund të themi
për selektivitetin e të DWH ? A janë shumica e kolonave shumë selektive? Jo tamam. Nëse i
kontrolloni kolonat në tabelën e dimensioneve, do të vini re se një numër kolonash që
përmban indekse t ë data -Tree me selektivitet të ulët nuk punojnë mirë me të dhënat e atyre
që kanë selektivitet të ulët. Cila është alternativa? Kjo na çon në një lloj tjetër teknike
indeksimi (Ponniah ,2010) .Indekset B -tree janë optimalë për kolonat me kardinalitet shumë
të lartë. Me kardinalitet të lartë , ne nënkuptojmë numrin e vlerave të ndryshme. Strukturat
pemë të kthyera përdorin një teknikë jashtëzakonisht të efektshme ndaj dhe pushto të
analizimit të t ë dhënave për të gjetur një vlerë të caktuar (një gamë vlerash). Treguesit B -tree
janë të shkëlqyer për të optimizuar kërkimet e njohura por janë paksa joelastikë për të
mbështetur mjediset ad -hoc si për shembull DWH. Treguesit B -tree janë përcaktuar si
joelastikë sepse ju nuk mund të kombinoni kolonat e indeksuara menjëherë për të krijuar në
formë dinamike indekse të përbëra për të zgjidhur kërkime të reja, të papritura. Të gjitha
indekset duhet të bëhen më përpara. DBA duhet të përpiqet të gjejë cilat kol ona mund të
kufizohen. Për më tepër, rendi në të cilat pozicionohen kolonat përcakton nëse ato po

107
përdoren ap o jo. Rezultati është se stafi D BA duhet të bëjë shumë indekse B -tree të përbëra,
shumë prej të cilave përmbajnë të njëjtat kolona në rende të ndry shme.
4.9.2 Indeksi Bitmap
Indekset Bitmap janë idealisht të përshtatshme për të dhënat me selektivitet të ulët. Një
bitmap është një seri bitesh të radhitura, një për çdo vlerë të qartë të kolonës të indeksuar.
Supozoni që kolona për ngjyrën ka tre ngjyra të qarta, përkatësisht e b ardhë, bezhë dhe e
zezë. Ndërtoni një bitmap duke përdorur këto tre vlera të qarta. Çdo hyrje në bitmap përmban
tre bite. Le të themi që biti i parë i referohet të bardhës, i dyti bezhës dhe i treti të zezës. Nëse
një produkt ka ngjyrë të bardhë, hyrja bit map për atë produkt përbëhet nga tre bite, ku biti i
parë është vendosur në 1, biti i dytë është vendosur në 0 dhe biti i tretë është vendosur në 0.
Nëse një produkt ka ngjyrë bezhë, hyrja bitmap për atë produkt përbëhet nga tre bite, ku biti
i parë është vendosur në 0, biti i dytë është vendosur në 1 dhe biti i tretë është vendosur në 0.
Tani e kuponi idenë. Tani studioni shembullin e indeksit bitmap të treguar në Figura 18 -9.
Figura tregon një ekstrakt të tabelës të shitjeve dhe indekseve bitmap për tre k olona të
ndryshme. Vini re se si çdo hyrje në një indeks përmban bitet e radhitura për të treguar vlerat
e qarta në kolonë. Krijohet një hyrje për çdo rresht në tabelën bazë. Çdo hyrje mban adresën
e rreshtit të tabelës bazë. Si punojnë indekset bitmap për të gjetur rreshtat e kërkuar? Merrni
në konsideratë një kërkesë kundrejt tabelës së shitjeve në shembullin më sipër: Zgjidhni
rreshtat nga tabela e shitjeve ku produkti është “Rondele” dhe ngjyra është “Bezhë” dhe
ndarja është “ Lindje” ose “Jug.” Figura 1 8-10 tregon se si aplikohet logjika Booleane për të
gjetur setin e rezultateve bazuar në indekset bitmap të treguar në Figura 18 -9. Siç mund ta
vëreni, indekset bitmap mbështetin kërkimet duke përdorur kolona me selektivitet të ulët.
Pika e fortë e kësaj t eknike qëndron në efektshmërinë e saj duke përdorur kallëzuesit mbi

108
kolonat me selektivitet të ulët në kërkimet. Indekset bitmap marrin shumë më pak hapësirë
se indekset B -Tree për kolonat me selektivitet të ulët. Në një DWH , shumë aksese të dhënash
bazohe n në kolonat me selektivitet të ulët. Gjithashtu, analiza duke përdorur skenarët "po
nëse" kërkojnë kërkime që përfshijë disa kallëzues. Do të zbuloni se indekset bitmap janë më
të përshtatshëm për një mjedis DWH sesa për një sistem OLTP. Nga ana tjetër, n ëse
prezantohen vlera të reja për kolonat e indeksuara, indekset bitmap duhet të rindërtohen. Një
disavantazh tjetër lidhet me nevojën për të aksesuar tabelat e të dhënave gjithë kohës pasi
janë aksesuar indekset bitmap. Indekset B -tree nuk kërkojnë akses tabele nëse informacionet
e kërkuara janë tashmë në indeks (Ponniah ,2010).
4.9.3 Treguesit Bitmap
Funksionojnë krejt ndryshe nga treguesit B -tree. Treguesit bitmap janë të përshtatur më mirë
për kolonat me kardinalitet të ulët. Shumë tregues bitmap me një kolonë mund të bashkohen
në formë dinamike së bashku për të krijuar indekse të përbëra për të mbës htetur kërkimet ad –
hoc. Për shkak të elasticitetit të tyre, është praktikë e zakonshme të krijohen indekse bitmap
me një kolonë në çdo çelës zëvendësues në tabelat e fakteve në magazinën e të dhënave. Tani
duam të kthehemi në mënyrën se si indekset ndikojn ë në transaksionet DML. Çdo e dhënë e
një indeksi B -tree përmban një, dhe vetëm një, numër rreshti që tregon regjistrimin përkatës
në tabelën bazë. Krejt ndryshe, indekset bitmap përmbajnë një gamë numrash rreshtash për
çdo vlerë në indeks. Nëse një vlerë përditësohet, çdo regjistrim që i përket gamës të numrave
të rreshtave kyçet. Së fundi, çdo herë që përditësohet një regjistrim, vendoset një barrë shumë
e madhe në databazë për të menaxhuar të gjitha kyçjet e rreshtave që ndodhin. Fatkeqësisht,
tabelat e fakteve zakonisht përbëhen vetëm nga indekse bitmap, dhe bërja e përditësimeve

109
masive krijon dhimbje koke masive për shkak të ngarkesës të madhe dhe performancës
shumë të dobët.
4.9.4 Indeksi i tabelës të fakteve
Çelësi kryesor i tabelës së fakteve përbëh et nga çelësat kryesorë të të gjitha dimensioneve të
lidhura. Nëse keni tabela me katër dimensione të dyqanit, produktit, kohës, dhe ofertës,
atëherë çelësi i plotë kryesor i tabelës së fakteve është seria e çelësave kryesorë të tabelave
të dyqanit, produk tit, kohës, dhe ofertës . Cilat janë kolonat e tjera? Kolonat e tjera janë
metriket, të tilla si njësitë e shitjeve, dollarët e shitjeve, dollarët e kostove e kështu me radhë.
Këto janë llojet e kolonave që duhet të merren në konsideratë për indeksimin e tabelave të
fakteve , kur behet planifikimi i krijimit te indekse ve për tabelat e fakteve:
 Nëse DBMS nuk krijon një indeks mbi çelësin kryesor, krijoni qëllimisht një indeks
B-Tree në çelësin e plotë kryesor.
 Caktoni me kujdes rendin e elementëve kyçë individualë në çelësin e plotë të lidhur
për indeksim. Në rendin e lartë të çelësit të lidhur, vendosni çelësat e tabelave të
dimensioneve të referuar shpesh gjatë kërkimit.
 Rishikoni komponentët individualë të çelësit të lidhur. Krijoni indekse mbi
kombin imet bazuar në kërkesat e përpunimit të kërkimeve.
 Nëse DBMS mbështet kombinimet inteligjente të indekseve për akses, atëherë mund
të krijoni indekse mbi çdo komponent të veçantë të çelësit të lidhur.
 Mos i anashkaloni mundësitë e indeksimit të kolonave që përmbajnë metrike. Për
shembull, nëse shumë kërkime kërkojnë dollarë shitjesh brenda gamave të dhëna,
atëherë kolona “dollarë shitjesh” është një kandidat për indeksimin.

110
 Indeksimi bitmap nuk aplikohet për tabelat e fakteve. Pothuajse nuk ka kolona me
selektivitet të ulët.
4.9.5 Indeksimi i tabelave të dimensioneve
Kolonat në tabelat e dimensioneve përdoren në kallëzuesit e kërkimeve. Këtu kolonat
produkti, muaji, dhe sektori nga tre tabela të ndryshme dimensionesh janë kandidate për
indeksim. Kontrolloni kolonat e çdo tabele dimensionesh me kujdes dhe planifikoni indekset
për këto tabela. Mund të mos jeni në gjendje të arrini përmirësim të performancës duke
indeksuar kolonat në tabelat e fakteve por kolonat në tabelat e dimensioneve ofrojnë mundësi
shumë t ë mëdha për të përmirësuar performancën me anë të indeksimit.
Këtu janë disa këshilla mbi indeksimin e tabelave të dimensioneve:
 Krijoni një indeks unik B -Tree mbi çelësin kryesor me një -kolonë.
 Ekzaminoni kolonat që përdoren zakonisht për të kufizuar kër kimet. Këto janë
kandidate për indekse bitmap.
 Kërkoni kolona që përdoren shpesh së bashku në tabela dimensionesh të mëdha.
Përcaktoni se si këto kolona mund të rregullohen dhe përdoren për të krijuar indekse
me shumë kolona. Mos harroni se kolonat që përd oren më shpesh ose kolonat që në
nivele hierarkike më të larta në tabelën e dimensioneve vendosen në rendin e lartë të
indekseve me shumë kolona.
Indeksoni individualisht çdo kolonë që ka mundësi të përdoret shpesh në kushte bashkimi
(Ponniah ,2010).

111
4.9.6 Rendesia e indeksimit
Një strategji indeksimi e mirëplanifikuar lejon akses të shpejtë dhe eficent në të dhënat baze.
Indekset mund të krijohen në tabela ose views dhe idealisht lejojnë DWH të vendosë dhe
menaxhojë të dhënat në mënyrë më efektive. K ur eficensa përmirësohet, koha në dispozicion
që cdo operacion kryen reduktohet, së bashku me koston e lidhur me kryerjen e operacionit.
Dizenjimi i indeksit kryhet zakonisht gjatë zhvillimit të aplikimit të bazës së të dhënave.
Arsyeja është se aftesia për të krijuar indekse efektive është e bazuar në të kuptuarit se si
“application queries“jane koduar dhe se si e dhëna është e ruajtur (stored) në bazën e të
dhënave. Megjithatë, indekset gjithashtu kërkojnë menaxhim pasi “database
application“është vendo sur dhe se si modelet e përdorura shfaqen ose ndryshojnë.
Menaxhimi dhe optimizimi i indekseve është një proces në vazhdim lejon përmirësime të
performancës së mundshme pa kërkua r ndryshime në skemën themelore (Dasho, 2014).

112
KAPITULLI V: METODOLOGJIA ETL PER GRUMBULLIMIN E TE
DHENAVE
5.1 Hyrje
Me perfundimin e ndertimit te modelit datamart -it, duhet të zhvillohen edhe gjithë proçeset
që do të bëjnë të mundur grumbullimin e informacionet nga burimet origjinale , transformimin
dhe ngarkimin e tij në destinacion. (Juliana, 2014) .Te tri keto procese llogariten te jene
proçeset më kompleks gjatë ndërtimit të sistem eve ETL (Johnson &Jones, 2015) . Sipas
arkitekturës specifike destinacioni i të dhënave, do të jetë një datamart i ndërtuar për një proçes
te menaxhimit te emergjencave dhe fatekeqesive natyrore. Duhet të përcaktohet nëse
informacioni sapo të nxirret nga burimet do të tranformohet me mjetet e duhura dhe më pas të
ngarkohet në sktrukturën e databazës destinacion, apo fillimisht do të ng arkohet ashtu si është në
databazë në tabela Stage, për tu transformuar nga proçedura të vetë databazës destinacion. Të dyja
mundësitë janë metoda të njohura në literatura si: ETL, ELT. Për rastin tonë do të përdorim
metodat ETL. Proçeset (ETL) janë në vetv ete zgjidhje software -ike të cilat janë përgjegjëse për
tërheqjen e të dhënave nga burime të ndryshme, për pastrimin e tyre, përshtatje n dhe ngarkimin
në databaza.
5.2 Nxjerrja e të dhënave
Nxjerrja e të dhënave nga një sërë sistemesh burimesh të ndryshme shpesh është aspekti më
sfidues i ETL, pasi përcakton fazën për mënyrën si do të vazhdojnë proceset në vijim. Në
përgjithësi, synimi i fazës të ekstraktimit është të konvertojë të dhënat në një format të vetëm
i cili është i përshtatshëm për përpunim transformimi. Çdo sistem i veçantë mund të përdorë
gjithashtu një format/organizatë të ndryshme të dhënash. Formatet e burimeve të të dhënave
të përbashkëta janë databazat relacionale dhe skedat e sheshta, por mund të përfshijnë

113
struktura databazash jo -relacionale si për shembull Sistemi i Menaxhimit të Informacionit
(IMS) ose struktura të tjera të dhënash si Metoda e Aksesit të Ruajtjes Virtuale (VSAM) ose
Metoda e Aksesit Sekuencial të Indeksuar (ISAM), ose edhe marrje nga burimet e jashtme si
për shembull kapje nga uebi ose krruajtje nga ekrani ( web-spidering; screen -scraping)
(ETL,2015). Shumicën e rasteve, të dhënat në sistemin burim janë shumë komplekse, kështu
përcaktimi se cilat të dhëna jan ë përkatëse është shumë e vështirë. Ndërtimi dhe krijimi i
proceseve të ekstraktimit është përpjekje programimi që kërkon shumë kohë. Për t'i mbajtur
të dhënat të përditësuara në një DWH, të dhënat duhet të ekstraktohen disa herë në mënyrë
periodike. Ka dy metoda logjike për ekstraktimin: Ekstraktim i plotë dhe ekstraktim
progresiv.
1. Ekstraktimi i plotë: Në këtë lloj ekstraktimi, të dhënat nga sistemi burim ekstraktohen
plotësisht. Ndërsa ekstraktimi i plotë ekstrakton të gjithë të dhënat nga sistemet bur im, nuk
ka nevojë që të ndiqni ndryshimet e bëra në sistemin burim duke krahasuar me ekstraktimin
e mëparshëm.
2. Ekstraktimi progresiv: Në këtë lloj ekstraktimi, vetëm ndryshimet e bëra në sistemin burim
do të ekstraktohen në krahasim me ekstraktimin e më parshëm. Kapja e ndryshimit të të
dhënave (CDC) është një mekanizëm që përdor ekstraktimin progresiv. Shumica e mjeteve
ETL nuk e përdorin mekanizimin ETL, në vend të kësaj ekstraktojnë të gjithë tabelat nga
sistemet burim në vendin e stazhimit dhe i kraha sojnë këto tabela me të dhëna ose tabela të
ekstraktuara nga ekstraktimet e mëparshme për të dalluar ndryshimet. Ky krahasim rezulton
në një ndikim të madh të performancës në proceset ETL të DWH . Ka dy metoda fizike të
ekstraktimit: Ekstraktimi online dhe ekstraktimi offline

114
 Ekstraktimi online: Procesi i ekstraktimit të ETL lidhet me sistemin burim për të
ekstraktuar tabelat burim ose për t'i ruajtur ato në një format të konfiguruar tashmë
në sisteme ndërmjetëse, p.sh., tabela log.
 Ekstraktimi offline: Të d hënat e ekstraktuara stazhohen jashtë sistemeve burim
(Metodat e Ekstraktimit të të Dhënave ETL – Pjesa Dy).
Procesi i lëvizjes fizike të të dhënave nga një sistem në një sistem tjetër është gjithashtu pjesë
e procesit të ekstraktimit, i cili është quajtur si transport dhe përfshin:
1. Lëvizja e të dhënave nga sistemi burim në DWH
2. Lëvizja e të dhënave nga databaza e stazhimit në DWH
3. Lëvizja e të dhënave nga DWH në datamart
Transportimi mund të bëhet duke përdorur mekanizma skedash të sheshta, mekanizëm
operacionesh të shpërndara, ose duke përdorur hapësira t e tabelave të transportueshme
(Kakish.& Kraft2012 :1 -12).
5.3 Transformimi
Faza e transformimit aplikon një seri rregullash ose funksionesh në të dhënat e ekstraktuara
nga burimi për të nxjerrë të dhënat për ngarkim në vendin final. Disa burime të dhënash
kërkojnë shumë pak ose aspak manipulim të dhënash. Raste të tjera kërkojnë një ose më
shumë prej llojeve të mëposhtme të transformimit:
1. Zgjedhja e vetëm disa kolonave për të ngarkuar,
2. Përkthim i vlerave të koduara (p.sh., nëse sistemi burim ruan 1 për mashkull dhe 2 për
femër, por magazina ruan M për mashkull dhe F për fe mër);
3. Vlerat e enkodimit formë e lirë (p.sh., hartim "Mashkull" në "1");

115
4. Nxjerrja e një vlere të sapo llogaritur (p.sh., shuma e shitjes = sasia * çmimi i njësisë);
5. Renditje;
6. Bashkim i të dhënave nga disa burime (p.sh. kërkim, bashkim) dhe dyfishim i të dhënave;
7. Grumbullim;
8. Gjenerim i vlerave surrogate -kyçe;
9. Zhvendosje ose lëvizje (kthimi i disa kolonave në disa rreshta ose anasjelltas);
10. Ndarja e një kolone në disa kolona;
11. Ndarje e kolonave të përsëritura në një tabelë të veçantë të detajuar;
12. Kërkim dhe vlerësim i të dhënave përkatëse nga tabelat ose skedat referenciale për
dimensionet që ndryshojnë ngadalë; dhe
13. Aplikim i çdo forme të thjeshtë ose komplek se të verifikimit të të dhënave (ETL, 2015).

5.4 Ngarkim i i te dhenave
Kjo fazë ngarkon të dhënat në vendin final, zakonisht DWH . Në varësi të kërkesave të
organizatës, ky proces ndryshon gjer ësisht. Disa DWH mund të mbishkruajnë informacionet
ekzistue se me informacione grumbulluese update -imet e shpeshta me të dhënat e ekstraktuara
bëhen çdo orë, ditë, javë ose muaj. Koha dhe shtrirja për të zëvendësuar ose pritur
përditësimet janë zgjedhje ndërtimi strategjik që varen nga koha në dispozicion dhe nevojat
e biznesit.
Ndërsa faza e ngarkimit bas hkëvepron me databazën, kufizimet e përcaktuara në skemën e
databazës – si edhe shkrehësit e aktivizuar me ngarkimin e të dhënave (për shembull,
unikaliteti, integriteti referencial, fushat e detyrueshme), do t'i kontribuojnë perfo rmancës të
përgjithshme t ë DWH të procesit ETL.

116
Mekanizmat për të ngarkuar një DWH përshijnë:
1. SQL loader: i përdorur përgjithësisht për të ngarkuar skedat të sheshta në DWH .
2. Tabelat e jashtme: ky mekanizëm bënë të mundur që të dhënat e jashtme të përdoren si
tabelë virtuale e cila mund të kërkohet dhe bashkohet para se të ngarkohet në sistemin e
synuar.
3. Oracle Call Interface (OCI) dhe Application Programming Interface ( API) me rrugë të
drejtpërdrejtë: janë metodat e përdorura kur procesi i transformimit bëhet jashtë databazës.
4. Eksport/Import: ky mekanizëm përdoret nëse ka transformime komplekse dhe të dhënat
mund të ngarkohen në sistemin e DWH të synuar ashtu siç jan ë. DWH tipike me bazë ETL
përdor stazhimin, integrimin dhe përdor shtresa për të strehuar funksionet e saj kyçe. Shtresa
e stazhimit ose databaza e stazhimit ruan të dhënat e papërpunuara të nxjerra nga secili prej
sistemeve të ndryshme të të dhënave burim . Shtresa e integrimit integron setet e ndryshme të
të dhënave duke i transformuar të dhënat nga shtresa e stazhimit, shpesh duke i ruajtur këto
të dhëna të transformuara në një databazë dyqani të dhënash operacionale (ODS). Pastaj të
dhënat e integruara l ëvizen në një databazë tjetër, shpesh të quajtur databaza e DWH, ku të
dhënat radhiten në grupe hirerarkike të quajtura shpesh dimensione dhe në fakte dhe fakte
agregate. ETL luan një rol të rëndësishëm në arkitekturën e DWH meqenëse këto procese
ETL lëviz in të dhënat nga sistemet transaksionale ose burim në vendet e stazhimit të të
dhënave dhe nga vendet e stazhimit në DWH (Kakish.& Kraft2012 :1 -12).
5.5 Mjetet e përdorura për ETL –DATA STAGE .
Per ETL eshte perdorur mjeti Data -Stage,qe përbëhet nga komponentët e mëposhtëm:

117
Figura 5.1 Komponentët e Data stage (Ambati ,2012) .

Duke ndjekur edhe tiparin e ndarjes të sistemeve DWH, proçeset ETL duhet të bëhen mbi
një databazë të ndryshme dhe të pavarur nga burimet dhe DWH. Aplikimi i teknikave ETL,
me anë të komponentit Data -stage – Designer do të bëhet me këto hapa (Juliana ,2014) :
 Shpjegohen mundesite e terheqjes se të dhëna ve nga burimet
Identifikimi i burimeve është i qartë, pasi skedarët e gjeneruar nga platformat do të jenë
burimi i informacionit. Nëse fokusi jone eshte te skedarët që gjeneron Instituti mjeksor i
Kosoves –IMK , janë të dhëna të pastrukturuara, sepse në të përmbahen tipe të ndryshme të
dhënash që kanë lidhje me :Nr rendor i pacientëve ,Institucioni
shëndetësor ,Departamenti -Reparti ,Njësia ,Mbiemri ,Emri ,Mbiemri i Vajzërisë ,Emri
i Prindit ,Vendi i Lindjes ,Profesioni ,Datëlindja ,Gjinia ,Grupi igjakut ,Rh
Faktori ,Alergjitë ,Vendbanimi ,Adresa ,Telefoni kontaktues ,e -mail ,Statusi

118
bashkëshortorë ,Sta tusi i sigurimit shëndetësor ,Medikamentet e rekomanduara ,Data
e fillimit te trajtimit ,Data e perfundimit e trajtimit , Emri dhe vendi
institucionit,Gjendja gjate vizites hospitalizimit ,Emri dhe mbiemri i mjekut .etj. Kjo do
të thotë që çdo tip rekordi në skedarin burim, ka një numër të caktuar fusha sh të ndryshëm
nga tipet e tjera .Nevojitet të ndërtohet një pr oçes parsimi, mbi rekordet e IMK . Ky proçes do
të realizojë strukturimin e të dhënave.Ndërkohë burimet e tjera të informacionit si p.sh:
Agjencioni i Regjistrimit Civil –ARC prodhojnë informacion të strukturuar, ku çdo rekord
i skedarit të prodhuar ka të njëjtën përmbajtje. Për datamart -in tonë na intereson informaci oni
i IMK . Proçesi nxjerrjes së informacionit përfshin:
– Proçesin fillesta r të nxjerrjes së informacionit
– Proçesin rifreskimit të vazhdueshëm.
Proçesi fillestar ndodh kur nuk ka asnjë informacion në destinacion, ndërsa freskimi është ai
proçes që sigurohet se të dhënat janë të fundi t dhe nxjerr vetëm atë pjesë të informacioni që
është e shtuar apo nd ryshuar nga version paraardhës. Për përcaktimin e të dhënave të
ndryshuara ka dis a metodika, por ajo që ne do të përdorim për dimensionet tona është si më
poshtë: Mbas çdo nxjerrje informacioni nga një burim, ruhe t në zonën Stage nj ë kopje e të
dhënave të nxjera (në hash -file). Gjatë ekzekutimit pasardhës, proçesi merr gjithë tabelën
burim dhe e krahason me versionin paraar dhës të ruajtur në zonën Stage. Vetëm diferencat
do të dërgohen në DWH. Për tab elën Fakt, gjenerojmë me anë të Datastage rregullat e
përzgjedhjes të rekordeve të shtuar në skedarët burim (Juliana, 2014 ).
 Zhvillimi i hapave te s trukturimi t te informacionit.

Ne zhvillimin e strukturimit te inform acionit përfshihet ne këto hapa:

119
a- Ne këto raste, do të ndajmë infomacionin në modele të vecantë në bazë të rregullave të
secilit tip informacioni. Ndarja do të bëhet në bazë të rregullave që ndërtojmë për
diferencim in e çdo tip te burimi t te informacionit. Duke ditur strukturën e çdo tip tra fiku,
ndërtojmë modulet e vecantë me fushat përkatëse të çdo tipi.
b- Hapi i dytë është stukturimi dhe ruajtja e këtyre të dhënave në mënyrë te përshtatshme,
për të mundësuar manipulimin e tyre të metejshëm. Në rastin tonë, të dhënat do të ruhen në
tabela Stage, sipas arkitekturës së zgjedhur. Në llogjikën e transformimin do të ndërtohen
rregullat e parsimit të informacionit të pa strukturuar, për ta transformuar në një informacion
të strukturuar .
3- Specifikojmë transformimet që do të ndodhin.
Mbasi të dhënat nxirren nga burimet, ato i nënshtohen proçeseve të transformimeve.
Veprimet transformuese në rastin tone, bëhen mbi të dhënat e nxjera nga burimet apo mbi
objektet e përkohëshme nga zona Stage. Po kështu edhe vetë transformimet mund të krijojnë
rezultate të përkohëshme që ruhen në zonën Stage .
Proçeset më kryesore transformuese që do të ndodhin janë:
– Konvertimi dhe normalizimi që punon në të dy anët e informacionit për të kthyer të dhënat
uniforme.
– Proçesi i lidhjes që realizon bashkimin llogj ik të fushave ekuivalente nga burime të ndryshme
– Përzgjedhja që ul numrin e fushave dhe rekordeve të burimit.
Figura e mëposhtme demostron një shembull të thjeshtë të proçesit të transformimit.
4.7 Rezultatet e përfituara nga a nalizat
4.8 Konkluzione

120
KAPITULLI VI:SINKRONIZIMI I DHENAVE NE SISTEMET ETL NE
KOHE REALE
6.1 Hyrje
Ne ditët e sotme, Agjencionet e menaxhimit te emergjencave gjenerojnë sasi të mëdha të
dhënash, me një ritëm i cili mund të arrijë me lehtësi shumë megabyte ose gigabyte në ditë.
Prandaj, ndërsa koha kalon, një DWH e menaxhimit te emergjencave mund të rritet në disa
terabyte ose edhe petabyte. Madhësia e DWH tregon që çdo kërkim që ekzekutohet kundrejt
të dhënave të saj zakonisht hap sasi të mëdha regjistrimesh, gjithashtu bën vep rime si
bashkime, radhitje, grupime dhe llogaritje. Për të optimizuar këto aksese, DWH përdor
struktura të dhënash të brendshme të përcaktuara si për shembull indekset ose particionet , të
cilat janë gjithashtu të mëdha në sasi dhe kanë një nivel shumë të m adh kompleksiteti. Këto
fakte tregojnë se është shumë e vështirë të përditësohen në mënyrë të efektshme DWH në
kohë reale, pasi përhapja e të dhënave transaksionale në kohë reale me shumë mundësi do të
mbingarkohet serverin, duke pasur parasysh shpeshtë sinë e përditësimit dhe volumin, do të
përfshinte veprimtari jashtëzakonisht të mëdha mbi strukturat e DWH dhe do të degradonte
dramatikisht performancën.
Me pak fjalë, DWH në kohë reale synojnë uljen e kohës ne komunikimet e rasteve te
fatekeqsive natyrore d he emergjencave që ne keto raste duhet për të marrë vendime dhe për
të arritur një kohë zgjatje zero midis shkakut dhe efektit për atë vendim, duke mbyllur
hapësirën midis sistemeve reaktive inteligjente dhe proceseve të sistemeve. Synimi ynë është
transformimi i një DWH standard duke përdorur ngarkimin në grup gjatë dritareve të
përditësimit (gjatë të cilave nuk lejohet aksesi analitik) n jë mjedis analitik me kohë zgjatje
thuajse zero duke siguruar të dhëna aktuale, me qëllim që të mundësohet (thuaj se) përhapja

121
në kohë reale e informacionit të ri nëpër organizatë. Kërkesat e AME -se për këtë lloj mjedisi
analitik prezanton një set të ri me marrëveshje niveli shërbimi që shkojnë përtej asaj që është
tipike në një DW tradicionale. Problemi më i madh ësh të si të bëhet i mundur integrimi i
vazhdueshëm i të dhënave dhe të sigurohemi që minimizon impaktin negativ në veçori të
ndryshme të mëdha të sistemit, si disponueshmëria dhe koha e përgjigjes të sistemeve OLTP
dhe OLAP. Është dhënë një diskutim në thellë si i këtyre veçorive nga këndvështrimi analitik
(për të bërë të mundur analizën konsistente në kohë). Kombinimi i sistemeve shumë të
disponueshme me motorët aktivë të vendimit lejon përhapjen e informacionit në kohë reale
për DWH .E gjitha bashkë, kjo ësht ë baza për mjediset analitike me kohëzgjatje zero.
DWH në kohë reale siguron akses në një pamje të saktë, të integruar, të konsoliduar të
informacioneve të AME dhe ndihmon në dhënien e informacioneve thuajse në kohë reale për
përdoruesit e vet. Kjo kërkon t eknika ETL të efektshme që bëjnë të mundur integrimin e
vazhdueshëm të të dhënave (Santos & Bernardino ,2008 ) .
6.2 Sinkronizimi i të Dhënave
Sinkronizimi i të dhënave zakonisht kërkohet për t'i mbajtur dy ose më shumë sisteme të
sinkronizuara dhe të përdi tësuara. Një arsye e zakonshme për sinkronizimin e të dhënave
është migrimi i sistemit (si rezultat i konsolidimit të biznesit; zvogëlimit, etj…) ku kërkohet
vënia në punë e dy sistemeve në paralel për një periudhë kohe, ndonjëherë disa vjet. Gjatë
kësaj periudhe, transaksionet që kapen nga një sistem duhet të update -ohen në sistemin tjetër
gjithashtu. Një arsye tjetër e zakonshme për sinkronizimin e të dhënave është shkrirja ose
blerja (M&A) ku sisteme t e përdorura nga njëra nga institutet e menaxhimit te emergjencave
vihen sipër tjetrës, dhe të dyja duhet të jenë të update -uara. CDC bën të mundur kapjen e
ndryshimeve ndërsa ndodhin dhe i përpunon duke përdorur mjete të tilla si EAI, ETL ose

122
programet e ndërtuara vetë. Duke inkorporuar CDC, sinkronizimi i të dhënave mund të bëhet
i efektshëm dhe në kohë reale.[ 49] Një DWH siguron informacione për përpunim analitik,
vendimmarrje dhe mjete të shfrytëzimit të të dhënave. Një DW H grumbullon të dhënat nga
shumë sisteme me burim operacional heterogjen (OLTP – On-Line Transaction Processing)
dhe ruan të dhënat e përmbl edhura të integruara të AME -se në një depo qendrore të përdorur
për aplikimet analitike (OLAP – On-Line Analytical Processing) me kërkesa të ndry shme
përdoruesi. Vendi i të dhënave të një DWH zakonisht ruan historinë e plotë të një AME -se.
Procesi i zakonshëm për marrjen e një informacioni të vendimmarrjes bazohet në përdorimin
e mjeteve OLAP. Këto mjete e kanë burimin e tyre të të dhënave të bazua r në një vend të
dhënash DW, në të cilin Update regjistrimet nga mjetet ETL (Ekstraktim, Transformim dhe
Ngarkim). Proceset ETL janë përgjegjëse për identifikimin dhe ekstraktimin e të dhënave
përkatëse nga sistemet e burimit OLTP, duke i personalizuar dhe integruar këto të dhëna në
një format të përbashkët, duke i pastruar të dhënat dhe duke i konformuar në një format të
integruar të përshtatshëm për update -imin e vendit të të dhënave të DW H dhe, së fundi,
ngarkimin final të të dhënave të formatuara në dat abazën e tyre. Tradicionalisht, është
pranu ar gjerësisht se databazat e DWH përditësohen rregullisht – zakonisht në ditë, javë ose
muaj – duke treguar se të dhënat e saj nuk janë asnjëherë të update -uara, pasi rekordet OLTP
të ruajtura midis atyre update -imeve nuk janë përfshirë në vendin e të dhë nave. Kjo tregon
që rekordet operacionale më të fundit nuk janë përfshirë në vendin e të dhënave, duke u
përjashtuar kështu nga rezultatet e siguruara nga mjetet OLAP. Deri kohët e fundit, përdorimi
i të dhënave të update -ohen periodikisht nuk ishte një problem kritik. Sidoqoftë, me
sipërmarrjet si e -business, shkëmbime burse, telekomunikacione online dhe sisteme
shëndetësore, për shembull, informacionet përkatëse duhet të jepen sa më shpejt të jetë e

123
mundur për pun onjësit e njoftimeve ose sistemet e vendimeve të cilët mbështeten në një
mënyrë thuajse në kohë reale, sipas të dhënave të reja dhe më të fundit të kapura nga sistem i
i informacionit të QOAME . Kjo e bën mbështetjen DWH në kohë reale (RTDW) një çështje
kritike për këto lloj aplikimesh. Kërkesa për të dhëna të freskëta në DWH ka qenë gjithmonë
një dëshirë e fortë. Rifreskimi i DWH (integrimi i të dhënave të reja) kryhet tradicionalisht
në një me todë off -line. Kjo do të thotë që ndërsa po kryhen proceset për update -imin e të
dhënave, përdoruesit dhe aplikacionet OLAP nuk mund t'i përdorin të dhënat. Ky set
aktivitetesh zakonisht bëhet në një dritare ngarkimi me kohë të përcaktuar, për të shmangur
mbingarkimin e sistemeve të burimit OLTP operacionale me ngarkesë ekstra. Përsëri,
përdoruesit po kërkojnë nivele më të larta rifreskimi, meqenëse gjithnjë e më shumë
Agencioni i fatekeqsive natyrore operojnë në një orar 24×7. Magazinimi Aktiv i të Dhëna ve
i referohet një trendi të ri ku DW H përditësohen sa më shpesh të jetë e mundur, për shkak të
kërkesave të mëdha të përdoruesve për të dhëna të freskëta.
6.3 Arkitektura e data -marteve logjike dhe DWH në kohë reale
Arkitektura e data -marteve logjike dhe DWH në kohë reale është praktike vetëm për DWH
me përmasa mesatare ose kur përdoren teknologji DWH me performancë të lartë, si për
shembull sistemi Teradata. Siç mund të shihet në figurën 6.1 , kjo arkitekturë ka
karakteristikat e mëposhtme unike:
Figura 6.1 Data mart logjike dhe arkitektura ne kohe reale e Data Warehouse (Hoffer &
Ramesh.,2011)

124

1. Data -martet logjike nuk janë databaza fizikisht të veçanta por pamje relative të ndryshme
të një DWH relative fizike, paksa të denormalizuar.
2. Të dhë nat lëvizen në DWH në vend ose në një fushë të veçantë skenimi për të përdorur
fuqinë kompjuterike me performancë të lartë të teknologjisë të magazinës për të kryer hapat
e pastrimit dhe transformimit.
3. Data -martet e reja mund të krijohen shpejt sepse asnjë databazë fizike ose teknologji
databaze nuk ka nevojë të krijohet ose merret dhe nuk ka nevojë të shkruhen rutina ngarkimi.
4. Data -marte t janë gjithmonë të update -uara sepse të dhënat në një pamje krijohen kur pamja
është referencuar, pamjet mund të materializohen nëse një përdorues ka një seri kërkesash
dhe analizash që duhet të shlyejnë të njëjtin ilustrim të data -martit.

125
Qoftë logjike apo fizike, të data -martet dhe DWH luajnë role të ndryshme në një mjedis
DWH këto role të ndryshme janë përmbledhur në Tabelën 9 -2. Megjithëse me shtrirje të
kufizuar, një data -mart mund të mos jetë i vogël. Prandaj, teknologjia e shkallëzimit shpesh
është kritike. Një barrë dhe kosto e madhe vihet mbi përdoruesit kur ata vetë duhet të
integrojnë të dhënat nëpër data -marte të veçanta fizike (nëse kjo është e mundur). Ndërsa
shtohen data -martet, një DWH mund të ndërtohet në faza.M ënyra më e lehtë që të ndodhë
kjo është të ndiqet arkitektura e data -marteve logjike dhe e DWH në kohë reale (Hoffer &
Ramesh.,2011).
6.4 Data warehouse në kohë reale dhe teknikat ETL
Një DWH, disa vite më parë, zakonisht përditësohej çdo ditë ose çdo javë. Në dy deri tre
vitet e kaluara, ka pasur gjithnjë e më shumë kërkesë për të rritur shpeshtësinë e update –
imeve . Përdoruesit duan që të dhënat në DWH të update -ohen çdo dy minuta ose edhe në
kohë reale. Një DWH në kohë rea le është një DWH që update -ohet nga ETL në momentin
që ndodh transaksioni në sistemin burim. Për shembull, ju vendosni shkrehës në tabelën e
transaksionit të shitjeve në sistemin burim në mënyrë që kurdoherë që futet një transaksion
në databazë, shkrehësi qëllon dhe e dërgon rekordin e ri në DWH si mesazh. DWH ka një
dëgjues aktiv që kap mesazhin në momentin që vjen, e pastron, bën DQ, e transformon dhe
e fut në tabelën e fakteve menjëherë. Ketu diskutohet për një diferencë kohore prej dy
sekon dash këtu, midis momentit që ka ndodhur nje fatekeqsi natyrore ne nje zone , që të
dhënat janë në dispozicion në tabelën e fakteve.
Qasja tjetër e implementimit të një DWH në kohë reale është të modifikohet aplikimi burim
për të shkruar në vendin e skenimit të DWH, menjëherë pasi i shkruan të dhënat në databazën

126
e saj të brendshme. Në databazën e skenimit, ju vendosni shkrehës që do të qëllojnë çdo herë
që futet një regjistrim i ri, dhe këta shkrehës përditësojnë DWH.
Qasjet thuajse në kohë reale mund të implementohen duke përdorur një mini -grup me dy deri
pesë minuta shpeshtësi, e cila i nxjerr të dhënat nga vendi i skenës në vend se duke përdorur
shkrehës. Ky mini grup bën gjithash tu punën normale ETL – duke transformuar të dhënat dhe
duke i ngarkuar në databazën dimensionale të DWH. Mini -grupi mund të nxjerrë gjithashtu
të dhënat direkt nga sistemi burim, duke eliminuar nevojën e modifikimit të sistemit burim
për të përditësuar ven din e skenimit (Rainardi , 2008). DWH në kohë reale vijnë nga prirjet e
fundit të globalizimit të biznesit, veprimtarive 24/7, volumeve të të dhënave gjithnjë e në
rritje, presioneve të konkurrencës, r ritjes të kërkesave të menaxhimit te emergjencave dhe
rritjes të kërkesave nga vendimmarrësit për të dhëna në kohë reale. Këto prirje të fundit
kërkojnë që menaxhimi i emergjencave të kenë akses në të dhënat më të update -uara për
qëllime analize dhe statistike, e cila bën të nevojshme një kërkesë për nd ërtimin e DWH në
kohë reale dhe të ETL. Teknikat për të arritur qe DWH në kohë reale përshijnë teknikën
Change Data Capture (CDC) dhe integrimin e kapjes të ndryshimit të të dhënave me proceset
ETL ekzistuese për të rritur në maksimum performancën e ETL dh e për të arritur ETL në
kohë reale. Integrimi i CDC me mjetet ETL ekzistuese siguron një qasje të integruar për të
reduktuar sasinë e informacionit të transferuar duke minimizuar ndërkohë kërkesat e
burimeve dhe maksimizuar shpejtësinë dhe efikasitetin. Në kontrast, migrimi i të dhënave në
DWH duke përdorur mjetet tradici onale ETL ka një problem ne kohezgjatjen me volumet e
mëdha të seteve të të dhënave pasi proceset ETL konsumojnë burime të konsiderueshme të
CPU dhe kohe për sete të mëdha të dhënash (Kaki sh.& Kraft2012 :1 -12).

127
Një rast i zakonshëm për përdorimin e CDC përfshin procesin e lëvizjes të informacionit në
DW. Tradicionalisht, përditësimet DW përpunohen me një mjet ETL (Ekstrakt, Transformim
dhe Ngarkim). ETL është një program softueri që ekstrak ton të dhënat nga sistemi burim, i
transformon dhe pastron të dhënat, dhe pastaj i ngarkon në DW. Këto procese kërkojnë që
sistemi(et) operacionale të vihen offline për një periudhë kohe të caktuar. Kjo periudhë kohe
quhet si "Batch Window", e matur zakoni sht në orë dhe ndonjëherë në ditë, gjatë së cilës
sistemi është i zënë me lëvizjen e të dhënave dhe nuk mund të kryejë funksione operacionale
dhe funksione të tjera kritike për misionin. Duke pasur parasysh kufizimin e kësaj qasje je
"shumice", shumica e ag jencioneve te emergjencave perdorin IT qe te përditësojnë DW H-
të e tyre vetëm mbi bazë ditore, dhe shpesh javore. Duke pasur parasysh nevojën e shumë
kompanive për informacione të minutës së fundit, ata kanë filluar të kërkojnë më nyra të tjera
për të upd ate-uar DWH-të e tyre në kohë reale, duke reduktuar ndjeshëm kohezgjatjen . Mjetet
EAI merren ndonjëherë në shqyrtim për të arritur këtë synim. CDC, sidoqoftë, siguron një
qasje të re për t'i lëvizur informacionet në një DW, dhe mund të punojë njëkohësisht me
mjetet ETL ose EAI. Diagrami i mëposhtëm ilustron se si duket një zgjidhje CDC:
CDC i çon ndryshimet në një mjet ETL ose EAI në grup ose në kohë reale, duke lejuar
përmirësimin në mënyrë dramatike të efikasitetit të të gjithë procesit, reduktimin ose
eliminimin totalisht të 'batch windows', sigurimin e informacionit në kohë zgjatje të ulët, dhe
reduktimin e kostove përkatëse përfshirë ciklet e CPU, memorien, 'bandwidth' të rrjetit dhe
burimet njerëzore (Efficient and Real -time Data Integration, 2009).
Gjithnjë e më tepër ka një nevojë për të mbështetur dhe marrë vendime ne menaxhimin e
fatekeqsive natyrore thuajse në kohë reale bazuar në vetë të dhënat operacionale.
Arkitekturat tipike ETL janë të orientuara në përditësim grupi dhe shkaktojnë një boshl lëk të

128
madh në aktualitetin e informacionit në DWH . Ne vëmë në dyshim efektivitetin e
performancës të arkitekturave tipike ETL grupi dhe përditësimet me bazë thuajse në kohë
reale mbi të dhënat operacionale dhe ngremë pyetje për të adresuar studimin në koh ë të
menjëhershme me qëllim që të adresojmë procesin e vendimmarrjes ne AME . Ne ngremë
çështjen se procesi ETL aktual ka nevojë të largohet nga rifreskimet periodik e në update -ime
te vazhdueshme, sidoqoftë update -imi online i DWH ngre sfida të reja të sinkronizimit të
shikimit dhe caktimit të burimeve. "Për t'u përballur me kërkesat në kohë reale, DWH duhet
të jetë në gjendje të mundësojë integrimin e vazhdueshëm të të dhënave, me qëllim që të
merret me të dhënat më të fundit të A gencionit te menaxhimint te emergjencave -se
Problemet e sinkronizimit të shikimit lindin kur shikimet janë të përbëra nga të dhëna të
nxjerra nga disa burime të dhënash që po përditësohen pa dallim. Sfidat e burimit vijnë kur
ka kërkesa burimesh në konfli kt të kërkesave të analizave afatgjata në praninë e
përditësimeve në ecuri e sipër. Në mjetet ETL tradicionale, ngarkimi bëhet rregullisht gjatë
kohës joproduktive dhe gjatë kësaj kohe askush nuk mund të hapë të dhënat në një DWH .
Ndarja midis kë rkimit dhe përditësimit qartë thjesht eson shumë aspekte të implemen timit të
DWH , por ka disavantazh të madh sepse DWH nuk përditësohet vazhdimisht. Mjetet
tradicionale ETL nuk janë në gjendje mjaftueshëm që merren me këto futje ose update -ime
të vazhdueshme pa kohë joproduktive në DWH . Në DWH në kohë reale, ngarkimi bëhet
vazhdimisht ndryshe nga një bazë periodike në qasjet tradicionale. Një qasje në arkitekturën
e përgjithshme të një DWH në kohë reale përbëhet nga elementët e mëposhtëm:
(a) Sistemet e të dhënave që hostojnë sistemet e prodhimit të cilat popullojnë DWH ,
(b) një Zonë Përpunimi të Dhënash (DPA) e ndërmjetme ku bëhet pastrimi dhe transformimi
i të dhënave dhe

129
(c) Data Wareh ouse (Kakish.& Kraft2012 :1 -12).
Ndërtimi i një zgj idhjeje ETL DWH në kohë reale kërkon klasifikimin e disa objektivave te
AME -se shpesh të lëvizshme, kuptimin e një seti të shumëllojshëm teknologjish, pasjen e një
ndërgjegjësimi të disa qasjeve pragmatike të cilat janë përdorur me sukses nga të tjerët, dh e
zhvillimin e fleksibilitetit dhe kreativitetit inxhinierik. Kjo fushë mbetet e re, me teknologji
të reja, metodologji emergjente dhe fjalorë të rinj. Qartësisht, kjo situatë mund të jetë një
deshmi telashesh, por DWH në kohë reale u ofron gjithashtu adop tuesve të hershëm potencial
të madh për të arritur një avantazh konkurrues – një risk intrigues kundrejt shpërblimit. Ky
kapitull propozon një proces me katër hapa për të drejtuar profesionistin e DWH përmes
zgjedhjes të një arkitekture teknike dhe metodologjie ETL të përshtatshme në kohë reale:Ne
kemi treguar katër hapat kryesorë të sistemit ETL në një DWH : nxjerrje, garantim i cilësisë,
konformim dhe strukturim i të dhënave si një seri skemash dimens ionale gati për t'u
konsumuar nga përdoruesit finalë.
6.5 Sfidat dhe mundësitë e DWH në kohë reale
DWH në kohë reale përbën një numër unik sfidash dhe mundësish për inxhinierin ETL. Nga
këndvështrimi i arkitekturës teknike, ka potencialin të ndryshojë qasj en big -beng të
nevojshme gjatë grupit të natës ETL në një rrjedhë ngjashëm ETL përgjatë ditës. Kërkesat e
disponueshmërisë të sistemit mund të përshkallëzohen ndërsa biznesi mbështetet në
disponueshmërinë e ulët të transaksioneve të biznesit në DWH . Nëse AME zgjedh qasjet e
menaxhimit të dimensioneve në kohë reale të treguara në këtë kapitull, disponueshmëria
bëhet një avantazh strategjik. Nga këndvështrimi i arkitekturës të të dhënave, DWH në kohë
reale sfidon qëndrimin e DWH si sistem i matjeve periodike të veçanta – një ofrues i pamjeve
të biznesit – duke përkrahur kështu një sistem më gjithëpërfshirës dhe informacione të

130
përkohshme të vazhdueshme. Ky kalim ndodh pak nës e, për shembull, shpeshtësia e
ngarkimit të fakteve rri tet nga njëherë në ditë në çdo 15 minuta, por në mënyrë më dramatike
nëse ngarkimi i fakteve dhe regjistrimeve të dimensioneve ndodh vazhdimisht. DWH mund
të hapë pastaj një regjistrim të transaksioneve të biznesit dhe të kontekstit të tyre dimensional
në të gjitha pikat në kohë. Dimensionet që ndryshojnë ngadalë bëhen shpejt dimensione në
ndryshim, dhe qëndrimi i DHW bëhet më operacional nga funksioni . Në fakt, nëse DWH në
kohë reale mbështet gjithashtu përputhjen dhe sinkronizimin e dimensioneve në kohë reale,
atëherë ajo evoluohet në një shtrirje logjike të vetë sistemeve operative .
6.6 Rishikim i DWH në kohë reale
Qasja ne kohë reale e DWH mund të ndjekë një linjë të qartë të asaj që është quajtur fillimisht
ODS. Motivimet e ODS -ve fillestare ishin të ngjashme me magazinat moderne të të dhënave
në kohë reale, por implementimi i DWH në kohë reale pasqyron një gjeneratë të re
hadruerësh, soft uerësh dhe teknikash. Pjesët e mëposhtme i zhvillojnë këto ide më me hollësi.
Gjenerata 1 – Operational Data Store
Eshtë një ndërtim DWH i gjeneratës së parë i synuar për të mbështetur raportimin e
kohezgjatjes së ulët përmes krijimit të një konstrukti ark itekturor të qartë dhe aplikimi të
veçantë nga DWH . ODS është sistem gjysmë operacional dhe gjysmë vendim -mbështetës,
duke u përpjekur të krijojë një ekuilibër midis nevojës për të mbështetur njëkohësisht
përditësimet e shpeshta dhe kërkimet e shpeshta. Ar kitekturat më të hershme ODS e
përshkruanin si një vend ku të dhën at integroheshin dhe dergoheshin në një DWH
'downstream', duke vepruar kështu si një lloj zgjatimi i shtresës ETL të DHW . Arkitekturat
e mëvons hme e përshkruajnë si bashkues të të dhënave të integruara nga shtresa ETL e DWH
dhe e kategorizojnë si Tipi 1 deri 4 dhe ODS të brendshme ose të jashtme , në varësi të vendit

131
ku qëndron brenda arkitekturës të përgjithshme dhe urgjencës me të cilën duhe t të ngarkojë
të dhënat nga fusha operacionale.
Gjenerata 2 – Particioni mi në kohë r eale
Përdorimi i particionit logjik dhe fizik në kohë reale, siç është përshkruar fillimisht nga Ralph
Kimball, është një zgjidhje pragma tike e disponueshme për të dhënat analitike në kohë reale
nga një DWH . Duke përdoru r këtë qasje, krijohet një tabelë faktesh në kohë reale struktura
dhe dimensionaliteti i së cilës përshtatet me tabelën përkatëse të fakteve në DWH statike
(ngarkesa e natës ). Kjo tabelë faktesh në kohë reale përmban vetëm faktet e ditës aktuale
(ato që n uk janë ngarkuar akoma në tabelën e DWH statike ). Figura 6.2 tregon dy skema yll
të lidhura me tabelat e fakteve në koh ë reale dhe statike të pikës se institutit mjeksor , duke
ndarë një set të përbashkët dimensionesh.
Figura 6 .2 Lidhja midis formës statike dhe skemës ylli ne kohë -reale (Kimball &
Caserta.,2004) .

132

Çdo natë, përmbajtja e tabelës të particionit në kohë reale shkruhet në tabelën e fakteve
statike, dhe partici oni në kohë reale pastaj bartet , gati për të marrë transaksionet e ditës tjetër .
Figura 6 .3 jep një ide se si punon procesi.
Figura 6 .3 Lidhja logjike per particionet e datamart -ve ne kohe -reale (Kimball &
Caserta.,2004) .

133
Në thelb, kjo qasje sjell dobitë e raportimit të të dhënave në kohë reale të ODS -së në vetë
DWH , duke eliminuar shumë prej mbingarkesës arkitekturore ODS në proces.
Faktet rrjedhin në tabelën(at) e fakteve në kohë reale përgjatë ditës, dhe kërkimet e
përdo ruesit kundrejt tabelës në kohë reale ndalohen ose ndërpriten nga ky proces ngarkimi.
Indeksimi në tabelën e fakteve në kohë reale është minimal, ose nuk ekziston, për të
minimizuar përpjekjet e ngarkimit të të dhënave dhe ndikimin e tij në kohët e përgjig jes të
kërkimit. Performanca arrihet duke kufizuar sasinë e të dhënave në tabelë (vetëm një ditë)
dhe duke futur të gjithë tabelën e fakteve në kohë reale në memorie. Në mënyrë opsionale,
mund të krijohet një pamje që kombinon (Unione) faktet në tabelën e fakteve në kohë reale
dhe statike, duke siguruar një skemë virtuale yll për të thjeshtuar kërkimet që kërkojnë
shikime të masave historike që shtrihen deri në moment.
Nëse vetëm rekordet e fakteve rrjedhin -futen në particionin në kohë reale, nevojitet një
politikë për t'u marrë me ndryshimet në dimensionet që ndodhin midis dy ngarkesave të
mëdha natën. Për shembull, rekordet e institutit mjeksor të krijuar gjatë ditës për të cilat keni
fakte që mund të ketë nevojë të rikthehen në një seri rekordesh gjenerike te pacientit në
dimensionin e institutit shendetsor për t'u update -uar në rekordet pacientit ,më përshkruese
në mb rëmje, kur një ngarkesë e plotë e te dhenave te rekordit pacienti dhe të ndryshuar
ngarkohet në dimensionin statik të institutit m jeksor .
Ose ndryshe, DWH në kohë reale mund të zgjedhë të marrë më shumë pamje të shpeshta të
imazheve dimensionale që ndryshojnë për të braktisur konceptin pikë -në-kohë së bashku dhe
për të kapur të gjitha ndryshimet dimensionale që ndodhin. Më vonë, ky k apitull tregon disa
prej çështjeve që lidhen me zgjedhjen e një politike të përshtatshme për t'u marrë me

134
ndryshimet dimensionale, disa qasje pragmatike për të rrjedhur të dhënat në particione në
kohë reale përgjatë ditës së punës, dhe avantazhet e disavan tazhet e këtyre qasjeve.
6.7 Përcaktimi i ETL në kohë reale
Në shumë raste, ofrimi i DWH në kohë reale kërkon një qasje krejt të ndryshme nga metodat
ETL të përdorura në DWH me orientim në grup. Thjesht përdorimi i grupeve ETL të
zakonshme mbi një program më të shpeshtë përgjatë ditës mund të mos jetë praktik, qoftë
për sistemet OLTP apo për DWH. Anasjelltas, përfshirë DWH në logjikën e kryerjes të
transaksionit të sistemit OLTP nuk mund të punojnë gjithashtu. Sistemi OLTP nuk e ka luksin
e të priturit të k ryerjen e transaksionit të ngarkimit të DWH para se të vazhdojë me
transaksionin tjetër, as nuk ka ndonjë kyçje ose logjikë kryerjeje me dy faza praktike nëpër
sisteme me struktura të ndryshme dhe nivele të ndryshe granulariteti. Në vend të kësaj, ju
refer ohet thjesht të lëvizni në transaksione të reja në një particion ne kohe reale të veçantë (e
përkufizuar më tej në këtë kapitull) të DWH brenda një afati kohor të pranueshëm për
menaxhimine fatekeqsive natyrore , duke ofruar mbështetje analitike për vendime t e
veprimtarive ditë per dite. Për momentin, kjo procedurë është përkufizimi ynë praktik i ETL
në kohë reale.
6.8 Qasjet ETL në kohë r eale
Përmes njëfarë riciklimi kreativ të teknologjive dhe mjeteve ETL të themeluara, një paletë e
maturuar dhe e gjerë te knologjish është e disponueshme për të adresuar kërkesat e DWH .
Pjesët në vijim diskutojnë këto teknologji. ETL e zakonshem me qasje është jashtëzakonisht
e efektshme në adresimin e kërkesave të raportimit në grup çdo ditë, javë dhe muaj.
Transaksionet e reja ose të ndryshuara (rekordet e fakteve) lëvizen në masë, dhe dimensionet
kapen si pamje në një pikë kohore për çdo ngarkesë. Prandaj, ndryshimet në dimensionet që

135
ndodhin midis përpunimeve në grup nuk janë të disponueshme në DWH . Prandaj ETL nuk
është një teknikë e përshtatshme për integrimin e të dhënave ose aplikimit për AME -ne që
kanë nevojë për raportim me kohë zgjatje të shkurter ose për organizatat që kanë nevojë për
kapje ndryshimi dimensional më të detajuar. Por ETL i zakonshëm është n jë metodë e
thjeshtë, direkte dhe e provuar për orga nizatat të cilat kanë kërkesa ne kohezgjatje më
rastësore dhe sfida integrimi më komplekse. Figura 6.4 tregon procesin ETL tradicional.
Figura 6.4 Diagrami Konvencional ETL (Kimball & Caserta.,2004) .

ETL Mikro batch është shumë i ngjashëm me ETL tradicional, përveç se shpeshtësia e
grupeve rritet, ndoshta deri në shpeshtësin ë prej çdo ore. Këto mikro batch të shpeshta vihen
në punë përmes një procesi ETL tradicional tjetër dhe ushqejnë direkt particion et në kohë
reale të datamarteve. Njëherë në ditë, particionet në kohë reale kopjo hen në datamartet statike
dhe ba shkohen. Figura 6.5 tregon një diagram të ETL mikro -batch .

136
Figura 6.5 Diagrami Mikro -Batch ETL (Kimball & Caserta.,2004) .

Sistemet menaxhere të dimensioneve gjenerojnë imazhe dimensionale të reja në dimensionet
në ndryshim Tipi 2 ose 3, por për shkak të rritjes në shpeshtësinë e punimit, dimensionet që
ndryshojnë përgjatë ditës mund të ndryshojnë shpejt dhe të shkojnë thellë. Një alternativë
është të injorohen ndryshimet në dimensionet që ndodhin gjatë ditës dhe në vend të kësaj të
gjenerohen regjistrime dimensionesh vetëm për disa raste, duke përdorur vlerat standarde në
të gjitha kolonat. Ky kompromis mund të mjaftojë për organizatat që gjener ojnë pak
regjistrime të reja mbi një ditë të caktuar dhe janë tolerante për kohezgjatjen e kontekstit
dimensional nga mbrëmja e mëparshme, por pakëson qartë disa prej dobive të raportimit në
kohë reale. Nëse është e pashmangshme, zgjidhja e vetme praktike për t'u marrë me
dimensionet që ndryshojnë shpesh është përdorimi i matur i një mini dimensioni, ku ju krijoni
dimensione të veçanta për shumicën e atributeve që ndryshojnë shpesh të një dimensioni të

137
madh dhe duke pakësuar kështu numrin e rasteve dimensio nale të reja që kanë nevojë të
krijohen nga procesi ETL.Sistemet menaxhere të dimensioneve gjenerojnë imazhe
dimensionale të reja në dimensionet në ndryshim Tipi 2 ose 3, por për shkak të rritjes në
shpeshtësinë e punimit, dimensionet që ndryshojnë përgjat ë ditës mund të ndryshojnë shpejt
dhe të shkojnë thellë.. ETL mikro grup kërkon një kontroll pune gjithëpërfshirës, programim,
vartësi dhe metodë për minimizim të gabimeve, një që është e fortë aq sa të punojë e pavarur
për shumicën e kohës dhe në gjendje të ekzekutojë strategjitë e publikimit në DWH përballë
shumicës të çështjeve të ngarkimit të të dhënave .
6.9 Enterprise Application Integration –EAI
Në fundin e sipërm të spektrit të kompleksitetit shtrihet Enterprise Application Integration
(EAI) të quajtura ndonjëherë integrim funksional. EAI përshkruan setin e teknologjive që
mbështetin integrimin e vërtetë të aplikimit, duke lejuar sistemet operacionale individuale të
ndërveprojnë në mënyra të reja dhe të ndryshme nga ato që u caktuan fillimisht. E AI
zakonisht detyron ndërtimin e një seti kompo nentësh adaptore dhe broker që lëvizin
transaksionet e menaxhimit te fatekeqsive natyrore , në formën e mesazheve , nëpër sisteme të
ndryshme në rrjetin e integrimit, duke i izoluar të gjitha sistemet nga njohur ia ose vartësitë
në sistemet e tjera në rrjetin e integrimit. Adaptorët specifike të aplikimit janë përgjegjës për
t'u përballur të gjithë logjikën që duhet për të krijuar dhe ekze kutuar mesazhe, dhe broker -et
janë përgjegjës për përcjelljen e mesazheve në mënyrë të përshtatshme, bazuar në rregullat e
publikimit dhe regjistr imit. Adaptorët dhe broker -ët komunikojnë përmes mesazheve që
varen nga aplikacioni, shpesh të pasqyruara në XML. Kur ndodh një event i konsid erueshëm
aplikimi si updat -imi i një rekordi t klienti, lëshohet një shkrehës, dhe adaptori i aplikacionit
krijon një mesazh të ri. Adaptori është gjithashtu përgjegjës për fillimin e transaksioneve të

138
saj përkatëse kur merr një mesazh që përmban informacione që ka zgjedhur të marrë, si për
shembull një rekordi klienti i ri nga sistemi menaxh eri i dimensionit klient. Mesazhet rrugë
broker midis adaptorëve, bazuar në një set publikimesh dhe
Rregullat e re gjistrimit. Radhët e mesazheve shpesh vendosen midis aplikacioneve dhe
adaptorëve të tyre, dhe mi dis adaptorëve dhe broker -ve, për të dhënë një fushë stazhimi për
mesazhet asinkrone dhe për të mbështetur garancitë e dërgimit dhe qëndrueshmërinë e
transaksi oneve nëpër rrjetin e integrimit. Në Figura 6.6 , aplikacionet A dhe B punojnë në
mënyrë të pavarur por janë në gjendje të shkëmbejnë të dhëna dhe të ndërveprojnë përmes
mesazheve EAI.
Figura 6 .6 Diagrami Konvencional EAI (Kimball & Caserta.,2004) .

Për shembull, ndryshimet në regjistrimet e një klienti në aplikacioni A mund të lëshojnë një
shkrehës nga adaptori i aplikacionit A, i cili krijon dhe dërgon një mesazh XML të ndryshimit
të një brokeri . Nëse aplikacioni B është regjistruar në mesazhet klie nt-ndryshim nga
aplikacioni A, brokeri përcjell mesazhin në adaptorin e aplikacionit B, i cili mund të zbatojë
pastaj të gjitha ose një nënset të ndryshimit të regjistrimit të klientit në aplikacionin B.

139
Aplikacionet A dhe B nuk kanë nevojë të dinë asgjë p ër njëri -tjetrin; adaptorët e tyre përkatës
janë përgjegjës për kapjen, interpretimin dhe aplikimin e mesazheve për aplikacionin e tyre.
Ky koncept është i fuqishëm sepse lejon rrjetet EA I të shtrihen në mënyrë solide, prezantimi
i aplikacioneve të reja në rrjetin e integrimit kërkon vetëm krijimin e një adaptori të ri dhe
rregullave të reja të publik imit/regjistrimit te broker -it.
Kur themi vetëm , ne nuk implikojmë që krijimi i adaptorëve të forcës industriale të p ërforcuar
është i parëndësishëm, e vërteta është krejt e kundërta. Çdo adaptor duhet të jetë në gjendje
të ekzekutojë transaksione komplekse në sistemin e tij host dhe të merret me shumë probleme
konkurrence që mund të shfaqen kurdoherë që aplikacionet e pavarura operojnë mbi të dhëna
logjike të përbashkëta. Pavarësisht nga qasja e integrimit, duhet të merren në shqyrtim disa
çështje të caktuara diku në arkitekturë, dhe adaptorët EAI e bëjnë këtë në pozicionin optimal,
sa më pranë aplikacionit që të jetë e mundur. Teknologjitë EAI mund të jenë mjete të
fuqishme për DWH në kohë reale sepse ato mbështetin aftësinë për të sinkronizuar të dhëna
të rëndësishme si informacionet e pacientit nëpër aplikacione, dhe ato ofrojnë një mjet të
efektshëm për shpërndarjen e aseteve të informacioneve të nx jerra nga DWH , si për shembull
vlerat e segmentimit të pacientit , nëpër sipërmarrje.
Arkitektura e DWH EAI në kohë reale modularizon bllokun ETL monolitik duke tërhequr
sistemin(et) menaxhere dimensioni si komponentë arkitekturorë të veçantë, secili me
adaptorët e vet, dhe duke e vënë përgjegjësinë për shumicën e bërthamave të transformimit
dhe ngarkimit të particioneve në kohë reale të datamart -eve në shumicën e adaptorëve të
datamart -eve. Figura 6.7 është një diagram i DWH ne EAI në kohë reale.

140
Figura 6.7 Diagrami i DWH në kohë reale i EAI

Një skenar tipik real mund të përfshijë implementimin e adaptorëve për një set sistemesh
OLTP si për shembull një planifikim i burimit të sipërmarrjeve, ERP, dhe automatizimi i
forcës të shitjeve, sistemet menaxhe re të dimensionit KOHË dhe DATA (të cilat kryejnë
pastrim dhe deduplifikim në kohë reale), dhe datamarte për IMK dhe IHMK .
Çdo transaksion ndryshimi KOHË dhe DATA do të kapej nga aplikacioni OLTP nga një
adaptor, qe eshte mesazh dimensioni i pa -konformua r te brokeri , i cili pastaj e dërgon në
cilindo sistem që regjistrohet në mesazhet e dimensionit të pa -konformuar, zakonisht vetëm
sistemi menaxher i dimensionit të përshtatshëm. Sistemi menaxher i dimensionit konformon

141
regjistrimin dimensional, dhe adaptori i tij pastaj e dërgon përsëri si mesazh dimensi oni të
konformuar te brokeri , i cili pastaj e përcjell te të gjitha sistemet që regjistrohen të të dhënat
e dimensioneve të konformuara, zakonisht sistemet OLTP dhe datamartet.
Marre në shqyrtim këtë s hembull. Sistemi ERP update -on rekordet e DATA pastaj adaptori
ERP zbulon këtë ndryshim, gjeneron një mesazh XML të emërtuar Transaksion DATA i Pa-
Konformuar nga ERP , dhe e dërgon te brokeri.Me pas brokeri e përcjell këtë mesazh te
menaxheri i dimensionit DATA , zakonisht sistemi i vetëm që regjistrohet në mesazhet DATA
të pa -konformuara nga siste mi ERP. Menaxheri i dimensionit DATA merr mesazhin dhe e
vendos informacionin e pa -konformuar të DATA në radhën e punës (ose fazën e stazhim it,
nëse mikro -grup) të menaxherit dimension DATA . Menaxheri dimension DATA punon
transaksionin, dhe nëse rezulton në një ndryshim në një ose më shumë rekorde DATA të
konformuara, adaptori menaxher i dimensionit DATA zbulon këto ndryshime që kanë
ndodhur, i paketon këto re korde klienti të rishikuara në mesazhet Transaksione DATA të
Konformuara nga mesazhet Menaxher Dimension DATA dhe i dërgon ato te brokeri . Duke
supozuar që datamartet e porosive, datamartet e IMK -se, dhe sistemet SFA janë regjistruar
të gjitha në Transaksionet DATA të Konformuar a nga mesazhet Dimensioni DATA Menaxher
, brokeri i kopjon dhe shpërndan mesazhin te të katër këto sisteme.. Secili prej katër
adaptorëve është pastaj përgjegjës për aplikimin e ndryshimeve në re kordet e DATA në
aplikimet e tyre përkatëse Pranimi i regjistrimit të konformuar të DATA nga sistemet ERP
dhe SFA mund të shkaktojnë një ndryshim në regjistrimet e tyre përkatëse të DATA , duke
lëshuar kështu një set të ri transaksionesh EAI. Transaksionet e fakteve kapen gjithashtu nga
adaptorët OLTP, i dërgohen broker -it si mesazh faktesh IMK ose IHMK , dhe pastaj i
dërgohen të gjithë regjistruesve të këtyre llojeve të mesazheve, tipikis ht datamarte. Adaptori

142
datamart kryen të gjitha transformimet e nevojshme dhe e fut transaksionin e ri direkt në
datamartin particion në kohë reale. EAI është një mjet i fuqishëm i sinkronizimit të
informacioneve kyçe të biznesit, të dy për rrjedhjen -furni zimin e datamarteve dhe për
publikimin e shpërndarjen e segmentimeve të nxjerra nga magazina në sistemet OLTP
përballë klientit. Por mund të jetë komplekse dhe e shtrenjtë për t'u implementuar. EAI është
një qasje e shkëlqyer për organizatat kërkesat e të cilave kërkojnë kohëzgjatje raportimi të
ulët, të cilët janë intolerantë nga humbja e update -imeve dimensionale ndër -ditore, ose që
kërkojnë sinkronizim bidireksional të të dhënave dimensionale midis DWH dhe sistemeve
operative.
6.10 Ndërtimi i particioneve në kohë reale
Në vitet e kaluara, një kërkesë e madhe e re është shtuar në listën e ndërtuesve të DWH .
Data warehouse tani duhet të zgjatë kohën e saj historike ekzistuese deri në rastin aktual.
Nëse AME ka bërë një porosi në orën e kaluar, d uhet ta shohim këtë porosi në konteks tin e
të gjithë marrëdhënies me xxxx . Për më tepër, n e duhet të gjurmojmë statusin për çdo orë të
porosisë më të fundit pasi ndryshon gjatë ditës. Megjithëse boshllëku midis sistemeve
operacionale të përpunimit të transaksioneve dhe DWH është ngushtuar në 24 orë në
shumicën e rasteve, nevojat sistematike qe vine nga menaxhimi i fatekeqsive natyrore
kërkojnë që DWH ta mbushë këtë boshllëk me të dhëna thuajse në kohë reale.
Shumica e ndërtuesve të DWH janë skeptikë se punët ekzistuese ekstrakt -transformim –
ngarkesë (ETL) thjesht mund të përshpejtohen nga një k ohë cikli 24 -orësh në një kohë cikli
15-minutësh. Edhe nëse hapat e pastrimit të të dhënave lidhen që të ndodhin në paralel me
ngarkimin final të të dhënave, manipulimet fizike rrotull fakteve më të mëdha dhe tabelave
të dimensioneve thjesht nuk mund të bë hen çdo 15 minuta. Ndërtuesit e DWH po i përgjigjen

143
kësaj nevojes duke ndërtuar një particion në kohë reale përpara DWH të zakonshme statike
të të dhënave (Rainardi , 2008).
6.10.1 Roli strategjik i menaxhimit te dimensioneve
Mundesia që lidh në mënyrë logjike ose fizike fusha subjektesh të veçanta (datamarte) së
bashku në arkitekturën bus të DWH dimensionale është konformancë e dimensioneve dhe
fakteve, e arritur përmes përdorimit të sistemeve menaxhere dimensioni siç përshkru het me
tej. Tradicionalisht, menaxheri i dimensionit është parë si një rol puna e të cilit është
përkufizimi, mirëmbajtja dhe publikimi i një dimensioni të veçantë të konformuar i të gjitha
datamarteve që ndërveprojnë brenda arkitekturës bus të DWH .Së fund i, DWH në kohë reale
luan një rol në objektivin më të madh të sigurimit të aksesit të gatshëm për shumicën e të
dhënave aktuale dhe informative për të gjithë përdoruesit në sipërmarrje. Për më tepër, për të
dhënë shpejt regjistrime faktesh në DWH , mund të gjendet avantazh tejet konkurrues në
sigurimin e sinkronizimit në kohë reale të dimensioneve kyçe si klienti ose produkti nëpër të
gjitha sistemet operacionale në organizatë. Ky funksion informacion -sinkronizim mund të
konsiderohet një zgjatim logjik rolit të menaxherit dimension dhe është një mekanizëm i
efektshëm dhe i qëndrueshëm për mbylljen e lakut midis botës operacionale dhe asaj të
magazinës të të dhënave duke siguruar një mjet të shpërndarjes të segmentimeve të nxjerra
nga DWH dhe informacioneve të tjera të pasurimit në botën operacionale.Menaxheri i
dimensionit klient në një DWH strategjike në kohë reale mun d që jo vetëm të rrjedhë
datamarte me informacione klienti të reja të konformuara, por gjithashtu mund të
bashkëpunojë me ndonjë mekanizëm për sinkronizimin e informacioneve të klientit nëpër të
gjitha sistemet operacionale të interesuara (regjistruara). Këto informacione klienti në kohë
reale duhet të përfshijnë inteligjencë klienti të gjeneruar nga vetë DWH .

144
Qartësisht, këto objektiva ambicioze , dhe sipas këtij shkrimi, asnjë zgjidhje e paketuar apo
set mjetesh nuk mund të thjeshtojë në mënyrë dramatike procesin e ndërtimit të një integrimi
aplikacioni ndërmarrjeje bi -direksional (EAI)/zgjidhje DWH në kohë reale. Sidoqoftë, këto
sisteme janë kri juar; blloqet bazë të ndërtimit për këto sisteme ekzistojnë dhe po maturohen
më shumë. Potenciali për diferencimin e biznesit i siguruar nga një sistem i tillë është
mahnitës, prandaj ka të ngjarë që adoptuesit e hershëm të sotëm do të gëzojnë vendin në tr eg
Avantazhet që nxitin adoptimin më të gjerë të këtyre sistemeve në të ardhmen. Marr parasysh
sistemet e ndërtuara sot aspak nuk e pengojnë aftësinë e organizatës për t'u evoluar në një
EAI në kohë reale/zgjidhje DWH në të ardhmen.
6.10.2 Vetëm faktet apo edhe ndryshimet në dimension
Njerëzit e biznesit dhe arkitektët e DWH dimen sionale e përshkruajnë këtë fushe në terma
faktesh dhe dimensionesh, por sistemet OLTP nuk i bëjnë këto dallime të tilla. Sidoqoftë,
duhe t të kuptohet se kategorizimi i transaks ionve t te biznesit OLTP me interes për përdoruesit
finalë dhe t'i ndërtoni në mënyrë të përshtatshme. A janë të përqendruara kërkesat e raportimit
në kohë reale të fokusuara vetëm në fakte të freskëta, si për shembull porositë e bëra,
telefonatat e fundit, tregtimet e fundit të bursës, shitjet e fundit , e kështu me radhë, apo lidhen
gjithashtu me transaksionet e freskëta të dimensioneve, si për shembull një update -ime i
regjistri mit të një klienti ose produkti . Nëse ndryshimet dimensionale në kohë reale ja në të
nevojshme për raportim, a po ndryshojnë ato ngadalë apo shpejt? Me fjalët të tjera, a ka
nevojë AME -ja për një imazh të saktë të këtyre dimensioneve ashtu siç ishin në momentin e
transaksionit, apo a mundet që të gjitha ose disa update -ime dimensiona le të shkruhen në
formë shkatërruese kur ndodhin përditësime të reja? A duhet që raportet të jenë të
përsëritshme ? Tipi 1, dimensionet që ndryshojnë ngadalë, në të cilat ndryshimet në atributet

145
e një dimensioni mbishkruajnë në formë shkatërruese vlerat e m ëparshme, rezultojnë në një
DWH që rindërton vazhdimisht historinë, duke raportuar eventet jo ndërsa shikojnë në kohën
e transaksionit por ndërsa shikojnë në kontekstin e dimensioneve të sotme. Në këtë skenar,
raportet e vëna kundrejt të njëjtëve elementë dimensional në pika të ndryshme kohore kanë
rezultate paksa të ndryshme ose shumë të ndryshme. Tipi 1, ndryshimet janë gjithashtu të
rrezikshme sepse mund të zhvlerësojnë përmbledhje historike nëse ndryshimi i Tipit 1
zbatohet në një fushë të përdorur si bazë të një llogaritjeje përmble dhëse. Tipi 2 dhe 3,
dimensionet që ndryshojnë ngadalë ruajnë një tablo më granulare të imazheve të dimensionit
në pika të caktuara në kohë, ndoshta çdo ditë, por përsëri nuk i kapin ndryshimet në
dimensione që ndodhin midis ekstraktimeve. Rifreskimi dimen sional në kohë reale mund ta
lëvizë këtë granularitet deri në çdo disa minuta ose mund të kapë të gjitha ndryshimet e
dimensionit. Implikimet arkitekturore nuk janë të lehta. Duke adoptuar një politikë të kapjes
të imazheve të ndryshimit dimensional gjithn jë e më shpesh, DWH largohet nga qëndrimi i
saj i mëparshëm si një sistem i matjes periodike (imazheve) dhe drejt një ideali me
zerokohëzgjatje të mbështetjes së vendimit . Ndërsa DWH dhe teknologjitë e integrimit të
aplikacionit fillojnë të përzihen, DWH bëhet, në efekt, një zgjatim i vërtetë logjik i sistemeve
operative që vënë në punë sipërmarrjen. Për momentin, si çështje praktike, sistemet ETL me
shumë mundësi kanë nevojë të ndërtohen që të japin thuajse zero kohëzgjatje për faktet e
matura sipas mundësisë , por të lejojnë që disa ose të gjitha atributet dimensionale të
përditësohen në grupe, ose mikrogrupe, siç është zhvilluar në këtë kapitull.
6.10.3 Integrim i i të dhënave dhe integrimi aplikacioneve

146
Duke supozuar që k ërkesa e DWH në kohë reale detyron gji thashtu njëfarë mase të integrimit
nëpër sistemet operacionale, ju duhet të kategorizoni kërkesën tuaj qoftë si integrim të
dhënash apo integrim aplikacioni.
 Në përgjithësi, integrimi që mund të plotësohet thjesht duke lëvizur të dhënat midis
databazave q uhet integrim të dhënash . Shpesh, këto zgjidhje janë point -to-point, të
ekzekutuara përmes (për databazat heterogjene) ekstraktimin e skedave ASCII,
shkrehësve, lidhjeve të databazave, dhe portave (gateways) ose për shërbimet e
replikimit të databazave hom ogjene ose imazheve të tabelave. Në thel b, të dhënat
ndahen nëpër pjeset e pasme të aplikacioneve pjesëmarrëse, duke tejkaluar plotësisht
logjikën e aplikacionit. Disa mjete integrimi të dhënash më të sofistikuara sigurojnë
mbështetje administrimi të centr alizuar për programimin dhe lëvizjen e të dhënave,
duke mbështetur pak më shumë kontroll sipërmarrjeje dhe menaxhim për bërthamat
e integrimit të të dhënave point -to-point.
 Integrimi i aplikacionit (ndonjëherë i quajtur integrim funksional) mund të
përshkruhet si ndërtim i zgjidhjeve të reja të biznesit duke ngjitur aplikacionet së
bashku përmes përdorimit të disa 'middleware' të përbashkët. Middleware është një
kategori softueri që varet nga aplikacioni, duke siguruar një mjet për të kapur,
përcjell ë dhe ekzekutuar mesazhet transaksionale midis aplikacioneve. Në
përgjithësi, përdoren konektorët ose adaptorët për të lidhur aplikacionet pjesëmarrëse
në rrjetin e integrimit, dhe komisionerët përdoren për të përcjellë mesazhet sipas
rregullave të publiki mit dhe regjistrimit.
point -to-point kundrejt Hub -and-Spoke

147
Nëse magazina juaj e të dhënave mbështet gjithashtu njëfarë shkalle të integrimit të
aplikacionit (ose funksional), një faktor i rëndësishëm në zgjedhjen e arkitekturës është numri
i sistemeve të publikimit dhe regjistrimit që ju merrni pjesë duke mbështet ur të ardhmen e
parashikueshme. Ky numër mund t'ju ndihmojë të vendosni nëse një zgjidhje point -to-point
relativisht e thjeshtë do t'ju mjaftojë apo nëse kërkohet një arkitekturë më e fortë hub -and-
spoke.
Figura 6 .8 Integrimi i aplikacioneve Point –to-Point (Kimball & Caserta.,2004) .

Figura 11.8 tregon se, edhe me një numër aplikacionesh relativisht të vogël të aplikacioneve
që shkëmbejnë të dhënat, zgjidhjet point -to-point mund të kërkojnë një numër shumë të madh

148
ndërfaqesh të shkëmbimit të të dhënave, secila prej të cilave kërkon mirëmbajtje kurdoherë
që burimi ose aplikacionet e synuara ndryshojnë.
Shtimi i aplikacioneve në rrjetin e integrimit kërkon gjithashtu ndërfaqe të reja të shkëmbimit
të të dhënave për të gjitha aplikacionet e publikimit dhe re gjistrimit. Sidoqoftë, organizatat
që kanë një listë të shkurtër, të prerë aplikacionesh që kërkojnë integrim dimensioni të
konformuar dhe që presin që kjo listë të mbetet e qëndrueshme për të ardhmen e
parashikueshme, mund të gjejnë se qasja e integrimit point -to-point është mjaft tërheqëse.
Shmang kompleksitetin e krijimit të komponentëve middleware EAI dhe mund të mbështetet
pjesërisht përmes përdorimit të teknologjive të integrimit të të dhënave si Capture,
Transform, dhe Flow (CTF) të treguara më sipër në këtë kapitull. Në kontrast me arkitekturat
point -to-point, numri i ndërfaqeve klient dhe vartësive ndër -sistem mund të minimizohet
përmes përdorimit të një qasjeje integrimi hub -and-spoke shiko Figura 6.9
Figura 6.9 Integrimi i Aplikacioneve HUB dhe S POKE (Kimball & Caserta.,2004) .

149
Sidoqoftë, barra shtesë e ndërtimit të adaptorëve EAI dhe komponentëve broker nuk është e
parëndësishme. Çdo aplikacion që merr pjesë në rrjetin e integrimit ka nevojë për një adaptor
në gjendje të konvertojë transaksionet e përcaktuara në mesazhe gjenerike dhe të interpretojë
e ekzekutojë mesazhet gjenerike në aplikacionin lokal. Mirëmbajtja e adaptorit kërkohet
kurdoherë që një aplikacion host i lidhur ndryshon ose nëse seti i mesazheve gjenerike
ndryshon. Rregullat e vështira -dhe-shpejta mbi kufirin e vendimit midis arkitekturave point –
to-point dhe hub -and-spoke nuk ekzistojnë, p or organizatat që presin integrimin nëpër tre ose
më shumë aplikacione ose ato që presin një numër në rritje të pjesëmarrësve në integrim –
rrjeti në të ardhmen a parashikueshme, mund të marrin në konsideratë arkitekturat hub -and-
spoke EAI (Kimball & Caserta .,2004) .
Konkluzion

150
KAPITULLI VI I: APLIKIMET WEB MOBILE NE RASTIN E
FATEKEQSIVE NATYRORE
Hyrje
6.1 Arkitektura e aplikimeve web mobile

KAPITULLI VII I: Konkluzione dhe Rekomandime
Përmbledhje

Përfundime dhe realizime

Pyetjet e mëposhtëme kërkimore të shtruara për hulumt im na japin një këndvështrim të qartë
për të gjithë ecurinë e punës së kësaj teze doktorate, duke bërë të mundur përmbushjen e
qëllimit kryesor të këtij punimi:
Pyetje 1. Cilet do ishin faktoret kyq qe kane ndikuar ne ndertimin e sistemit DWH ne
QOAME sipas kerkesave te mbledhjes se informacioneve per procesin e vendimmarrjes ne
menaxhimin e fatekeqesive natyrore ?
Nga studimi i realizuar kundrejt literaturës shkencore të përzgjedhur dhe analiza e bërë te
natyres se men axhimit te fatekeqsive natyrore per rastin e QOAME ,ku mbledhja e ketyre
informacioneve kane ndikim ne ndertimin e DWH .Realizimi kyq i faktoreve ne ndertimin e
e DWH bazohet ne tre faktore kryesor:
1. Një DWH centralizon të dhënat që janë shpërndarë përme s sistemeve operacionale të
ndryshme dhe i vë ato në dispozicion për aplikacionet që ndihmojnë vendim -marrjen.

151
2. Një DHW e ndërtuar mirë i shton vlerë të dhënave duke përmirësuar cilësinë dhe
konsistencën e tyre.
3. Një DWH e veçantë eliminon shumë mosmar rëveshjet për burimet që rezultojnë kur
aplikacionet informative përzihen me përpunimet operacionale
Q endra Operative e Agjencionit te menaxhimit te emergjenncave eshte qender operative ne
kuader te AME -se ,kjo qender duhet te perballet me nivelin e infor macioneve si kordinuese
e nje numeri te madhe institutesh .Pra baze e ndertimit te DWH eshte qe te gjitha keto burime
te te dhenave te centralizohen permes sistemeve operacionale ,duke permisuar cilesine ne
vazhdimesi dhe rrite nivelin e vendim marrjen .
Pyetje 2. Cila do jete metodika me e pershtatshme per ndertimin e sistemit DWH ,do
perzgjedhet ?
 Metodika Top -down (Bill Imnon)
 Metodika Bottom -Up (Ralph Kimball)
Nder metodikat me te favorshme per ndertimin e sistemeve DWH per rastin e menaxhimit
te emergjencave do te paraqiten si :Metoda Top Down dhe Metoda Bottom -Up.
Nese marrim per baze Metoda Top Down qe eshte kushte per ndertimin e DWH ,mund te
arrihet sipas tri kushteve baze:
 E para është normalizimi i të dhënave dhe përkufizimi i metadatave pë r modelimin e
të dhënave dhe proceseve siç është e zakonshme në zhvillimin e sistemit të
menaxhimit të databazave.

152
 E dyta është të ndihmohen vendimet e përdoruesve finalë duke përdorur kërkesa
arbitrare në databazë.
 E treta është pastrimi dhe unifikimi i të dhënave në fazën e përgatitjes të të dhënave
(skenimi i të dhënave) për transformimin e të dhënave operacionale në të dhëna për
qëllime 'informative'.
Ndersa ne ne studimin tone doktorale kemi qene te fokusuar ne metodiken Bottom -Up te
Kimball -it . Arkitektura e Kimballit formon DWH të ndërmarrjes me anë të arkitekturës bus
që grumbullon 'data marts' në bazë të dimensioneve dhe fakteve të vërtetuara. Ku sipas
Kimballit përdoret një metodë e nxitur nga kërkesa,e qe kjo fillon me planifikimin e projek tit
për vlerësimin e gatishmërisë, studimit dhe justifikimit. Nga fakti se ne kemi trajtuar temen
e menaxhimit te emergjencave dhe fatekeqsive natyrore ne kuader te Agjencionit te
emergjencave ,me metoden e Kimballit kemi trajtuar formen dhe mundesin e int egrimit te te
dhenave nga shume burime te informacionit . B urimet e informacionit qe kemi arritur qe
permes ndertimit te sistem it DWH te integrojme jane :
-Agjencionin e regjistrimit civil (ARC) ,ne kete raste ne mundemi te marrim informacione te
ketij Agj encioni duke u fukosuar kryesishte ne te dhena bazike te regjistrimit te popullsise.
– Instituti seizmik i Kosoves (ISK) ,nga ky institucion ne kemi synuar te marrim informacione
lidhur me lekundjet seizmike qe ndodhin ne nivel vendi por edhe me gjere,duke marre te
dhena ne kohe reale .
-Instituti mjeksor i Kosoves (IMK),duke pas informacione adekuate nga ky institut lidhur me
shendetin e popullsis .Me keto te dhena shendetsore do arrihet nje harmonizim i gjithe

153
mbarshem ne nivel vendi dhe ne raste te fatek eqsive natyrore do kemi nje pasqyre te mire ne
raste te vendimmarrjeve menaxheriale.
-Instituti hidro -metorologjik i Kosoves (IHM K),ne rastet kur kemi vershime nga rreshjet e
medha , temperatura ekstreme te larta –ulta ,era te forta dhe ndotje te ambientit .Per te gjitha
keto raste IHMK bene mbledhje e te dhenave per keto ngjarje .Por deri me tani keto te dhena
kane qene ne nivel te raporteve dhe te pa shfytezuara nga Agjencioni i menaxhimit te
emergjencave .
-Sherbimi i zjarrefikesve te Kosoves (SHZK),ky s herbim ka nje mori aksionesh te fikjes se
zjarreve ,pjesemarrje ne rastet e menaxhimit te emergjencave mjeksore ,pjesemarrje ne raste
vershimeve .Kordinimi nderinstitucional deri me tani ka qene shume i ulet. Andaj te gjitha
keto institucione qe permendem m e larte perbejne burime te te dhenave ,te gjitha keto te
dhena jane vetem ne nivel te institucionit , p ra ndertimi i sistemit te DWH ka qene i nje
rendesie te veqante per shkak te nje numeri te madhe te burimeve dhe integrimin e ketyre te
dhenave .
Pyetje 3. Si eshte i ndertuar Datamart -i QOAME ,e qe ne fakt bene integrimin e
burimeve te te dhenave ?
Qendra Operative e Agjencise për menaxhimin e emergjencave dhe fatkeqësive natyrore e
kanë të domosdoshme të grumbullojnë dhe analizojnë të dhëna masive të fatkeqësive
natyrore . Te dhenat nga rekordet e tërmeteve ,vërshimeve të det ajuara, apo edhe te stuhive
dhe temperaturave ekstreme , janë fusha më e nxehtë për eksplorimin e njohuriv e në
menaxhimin e emergjencave dhe fatkeqësive natyrore . Analizat që duhet të gjenerohen prej

154
tyre, janë shumë të larmishme. Për ketë arsye modelimi i një datamart -i për këto të dhëna
është shumë interesant për tu zhvilluar.
Analizimi i kërkesave të mësipë rme,eshte mundesia e udhëheq jes se proçesit te modelimit
të të dhënave dhe ndërtimin e një zgjidhjeje. Keshtu qe m odelimi shumë dimensional u
përzgjodh për tu aplikuar në rastin tonë, për tre arsye :
-Këto modele ofrojnë një thjeshtësi në përdorim edhe n ga personat pa njohuri në IT
-Plotëson kërkesa komplekse me performancë të lartë
-Përshtatet shumë mirë me sasi të mëdha in formacioni, siç është rasti ynë (Juliana ,2014).
Datamart -i që do të ndërtojmë në vijim jane për të optimizuar performancën ,për përdorimet
e përcaktuara mirë dhe të parashikueshme, ndonjëherë qoftë edhe një ose pak kërkesa. Për
shembull, rasti i menaxhimit te emergjencave mund të ketë :
-Një data -mart per Institutit mjeksor te Kosoves –IMK,
-Një data -mart Agjencioni i Regjist rimit Civil –ARC , dhe
– Data-mart Instituti Hidrometrologjik i Kosoves -IHMK , e kështu me radhë për të ndihmuar
përpunimin analitik te raporteve
Per realizimin e objektivit te datamart -eve jane perdor tri forma te modelimit :
 Modelimi Konceptual
 Modelimi Logjik
 Modelimi Fizik

155
Shtese tjeter per realizimin e datamart -eve eshte pjesa e kodeve te ORACLE dhe vegla
softuerike DATASTAGE
Pyetje 4. Si do te ndikoje s inkronizimi i dhenave ne sistemet ETL ne kohe reale tek raste
e emergjencave dhe fatekeqsive natyrore?
Ne ditët e sotme ne kemi shume sisteme DWH te cilat duhet te jene te Update -ura dhe te
kemi te dhena nga keto ne kohe reale Agjencionet e menaxhimit te emergjencave gjenerojnë
sasi të mëdha të dhënash, i cili mund të arrijë me lehtësi shumë megab yte ose gigabyte në
ditë. Prandaj, ndërsa koha kalon, një DWH e menaxhimit te emergjencave mund të rritet në
disa terabyte ose edhe petabyte. Madhësia e DWH tregon që çdo kërkim që ekzekutohet
kundrejt të dhënave të saj zakonisht hap sasi të mëdha regjist rimesh, gjithashtu bën veprime
si bashkime, radhitje, grupime dhe llogaritje. Për të optimizuar këto aksese, DWH përdor
struktura të dhënash të brendshme të përcaktuara si për shembull indekset ose particionet , të
cilat janë gjithashtu të mëdha në sasi dhe kanë një nivel shumë të madh kompleksiteti. Këto
fakte tregojnë se është shumë e vështirë të përditësohen në mënyrë të efektshme ,andaj me
kete raste kemi bere perpjekje qe permes shpjegimit teorik te bazuar ne literature dhe fakte
shkencore ta aplikojme sinkronizimin e te dhenave ne kohe reale.
DWH në kohë reale përbën një numër unik sfidash dhe mundësish për inxhinierin ETL. Për
rastin tonë do të përd orim metodat ETL. Proçeset ETL perbejne në vetvete zgjidhje software –
ike të cilat janë përgjegjëse për t ërheqjen e të dhënave nga burime të ndryshme, për pastrimin
e tyre, përshtatjen dhe ngarkimin në databaza

156
Pyetje 5. Sa do te rritet performanca ne procesin e vendim marrjes me rastin e
implementimit sistemit DWH dhe perdorimi i aplikacioneve te plateformes web mobile ?

LISTA E REFERENCAVE / BIBLIOGRAFIA
Libra dhe disertacione
Alejandro .V, Esteban .Z (2014) ; Data Warehouse Systems,Design and Implementation;
Spring er-Verlag Berlin .
Andreas M, Thomas L, Thomas R, Thomas K, Holger K.(2002).Design Challenges for an
Integrated Disaster Management Communication and Information System. New York City

Armen G,Hachim B,George B (2011): Raport Vlerësimi i Kapacitetit përZvogëlim të
Rrezikut nga Fatkeqësitë Për Kosovë ,Prishtinë,Kosovë

Arwa A J (2011): Transitioning a Clinical Unit to a DataWarehouse, Guildford, England.
Çela.S (2014); Studimi i antenave inteligjente të telefonisë celulare, rrezatimi jo -jonizues në
afërsi të tyre , Tiranë, Shqipëri.

Dasho.A (2014 ); Zhvillimi i aplikimeve të platformës web një risi e re për korporatën
elektroenergjetike , Tirane, Shqiperi
Golfarelli.M, Rizzi.S (2009); Data Warehouse Design : Modern Principles and
Methodologies; McGraw -Hill, Itali.

Hoffer. J. A., Ramesh.V , Topi.H (2011) ; Modern database management – Te n t h E d i t i o
n;Pearson , New Jersey.

Kimball.R, Ross.M (2002); The Data Warehouse Toolkit – The Complete Guide to
Dimensional Modeling, John Wiley and Sons, Inc, New York .

Kimball .R, Ross .M, Thornthwaite .W, Mundy .J, Becker .B (2008);The Data Warehouse
Lifecycle Toolkit, Second Edition , John Wiley and Sons, Inc, New York .

Khan ,I (2012 ) ;Modern methodology & tools for data warehouse development ; Athabasca
University .

157

Kimball .R ,Caserta .J (2004) ;The Data Warehouse ETL Toolkit – Practical Techniques for
Extracting, Cleaning, Conforming, and Delivering Data , Wiley Publishing,USA

Lito,G (2013); Manaxhimi I riskut të katastrofave -rasti i Shqipërisë. Tiranë
Juliana L (2014): Studimi i sistemeve data warehouse dhe ndërtimi i një modeli raportimi të
bazuar në teknologjinë business intelligence,Tiranë .
Mark, K(2010):Command Center for Disaster Management Communication System Data
Warehouse., P u r d u e U n i v e r s i t y ,USA.

Malinowski E , Zim´anyi E (2008): Advanced DataW arehou se Design -Data -Centric Systems
and Applications , Springer -Verlag Berlin .

Ponniah . P (2010);Data warehousing fundamentals for IT professionals ,2nd ed;John Wiley
& Sons, Inc., New Jersey .

Rainardi.V (2008) ; Building a Data Warehouse: With Examples in SQL Server,Apress ,
United States of America .

Santos R, Bernardino .J (2008) ;Real -Time Data Warehouse Loading Methodology,ACM,
Portugal

Stolba N (2007): Towards a Sustainable Data Warehouse Approach for Evidence -Based
Healthcare ,Vien ,Austri.

Revista shkencore dhe burime nga interneti :
Ali.Sh (2011) ” A proposed model for data warehouse ETL processes ” Vol.23, f 91–104.

Camilovic, D (2009) “A Call Detail Records Dat a Mart: Data Modelling and OLAP Analysis
“,ComSIS, Vol. 6, f 87-110.

Cristina. I , Ferreira.E.J (2006)”Synchronization options for data warehouse designs”,
IEEE Computer ,Vol 39,f 53 -57.

Hristidis.V , Chen.SH, Li .T, Luis.S, Deng .Y ( 2010) “Survey of data management and analysis in
disaster situations ”, Elsevier ,f 1701 -1714.
Kakish.K , Kraft.TH (2012) “ETL Evolution for Real -Time Data Warehousing” New
Orleans Louisiana,Vol 5,f 1-12 .

158

Krasniqi.Z (2014):”Application of information technology in emergency and natural disaster
management”, Tirana,Albania.

Lenzerini, M(2002) “Data Integration: A Theoretical Perspective”,Universit `a di Roma “La
Sapienza

Lula .J, Kika .A (2012) “ Modelimi i një datamart -i për CDR, b u l e t i n i,Vol 14,f 230 -242.
Peng .Y,.Zhang.Y ,Tang.Y ,Li.Sh (2010) “An incident information management framework
based on data integration, data mining, and multi -criteria decision making ” Elsevier, Vol.
51, f 316–327

Tanasescu .V, Gugliotta, A., Domingue, J., Davies, R., Gutierrez, L., Rowlatt, M.,
Richardson, M., Stincic, S. (2006)”A Semantic Web Services GIS based Emergency
Management Application”, Springer , f 959-966.
Agjencia (2011) ”Gjendja e mjedisit në K osovë 2008 -2010 ”,Marrë nga www.ammk –
rks.net/repository/docs/Gjendja_e_Mjedisit_ne_Kosove_2008 -2010.pdf ,(Parë më
14.02.2015)

Ambati .K (2012) “ DataStage Enterprise Edition ” Marrë nga
www.scribd.com/doc/79600772/DataStage -OA#scribd,(Parë më 15.09.2015 )

CIO.al(2011) “ Teknologjia OLAP -revolucioni i parë në analizën e të dhënave ” Marrë nga
www. cio.al/teknologjia -olap-revoluc ioni-i-pare-ne-analizen -e-te
dhenave/#sthash.o5wgftdL.dpuf ,(Parë më 10 .10.2014).

ETL (2015) “ Extra ct transform load “Marrë nga
www. en.wikipedia.org/wiki/Extract,_transform,_load . (Parë më 12.05 .2015 )

Efficient and Real -time Data Integration (2009)” Efficient and Real Time Data Integ ration
With Change Data Capture” Marrë nga
www.download.101com.com/tdwi/ww29/Attunity_Efficient_and_Real -Time_DI.pdf ,
( Parë më 15.04.2015).

Faulkner .B (2011) ”Korniza Kosovare për menaxhim të rrezikut nga përmbytjet ”,Marrë nga
www.kryeministri ks.net/tfu/repository/docs/110421_Kosovo_Flood_Management_Framew
ork_Alb.pdf (Parë më 15.12. 2014).

159
Forumi për siguri (2013)”Reagimet në situata emergjente – përgatitjet dhe mundësitë” Marrë
nga www.fiq -fci.org/repository/docs/Reagimet_ne_situata_emergjente.pdf , Prishtinë.(Parë
më 01.02.2014)

Garg.N, Mithal.S ” Spatial Data warehouses ”Marrë nga www.users.cs.umn.edu/~smithal/ (Parë më
04.08.2015 )
Instituti hidrometeorologjike ( 2014) ” Instituti hidrometeorologjike i Kosoves” Marrë nga
www. ammk -rks.net/?page=1,90 ,(Parë më 17.01.2014)
Instituti Seizmik (2012) “Mikrozonimi sizmik i Gjilanit”,Marrë nga
www. mzhe -ks.net/repository/docs/MIKROZONIMI_SIZMIK_I_GJILANIT.pdf,(Parë më
02.02.2014)

Johnson.E ,Jones.J( 2015 ) “Building ETL Processes for Business Intelligence Solutions
Built on Microsoft SQL Server ” Marrë nga
www.erwin.com/content/whitepapers/ca_erwin_building_etl_processes_sql.pdf (Parë më
12.03.2015)

Kristiina, R.(2004) “The Role of Information Technology in Crisis Management”. Marrë
nga www.einiras.net/conf/conferences/ conferences_helsinki2004.cfm ,(Parë më 14 janar
2015).

MPB (2010)” Plani i Reagimit Kombëtar -Prishtinë “Marrë nga
www. mpb-ks.org/repository/docs/Plani%20Reagimit%20 Kombetar_14_01_11.pdf,
(Parë më 18.10.2014)

MSH (2014) “ Strategjia per sistemin e informimit shendetesor ne kosove 2010 -2020 ”,Marrë
nga,www.kryeministri ks.net/repository/docs/strategjia__per__sistemin_e_informimit_shend
etesor_ne_kosove_2010_ -_2020.pdf ,(Parë më 01.05.2015)

Plani i mbrojtjes (2011)” Plani i mbrojtjes nga zjarri për komunën e Prishtinës ”Marrë nga
www.kk.rksgov.net/prishtina/getattachment/Municipality/Departments/Sherb -Pub-
Mbrojtje -dhe-Shpet -/Sektori -per-mbrojtje -dhe-shpetim/plani -i-mz-prill2011 -.pdf.aspx,(Parë
më 14.07.2014).

Sam . B, Lance. M (2009) “Geospatial Web Services and Cross -Boundary Information
Sharing During Disasters” Marrë nga www.ogcnetwork.net/node/573 (Parë më 24.05.2014 )
SIME (2010) “Sistemi i Integruar i Menaxhimit të Emergjencave “Marrë nga www.mpb –
ks.org/repository/docs/Sistemi%20i%20integruar%20per%20menaxhimin%20e%20emergjencave%20ALB.pdf
,( Parë më 01.02.2014).

160
Sriganesh, V., Iyer, P. “Information Resources and Systems for Disaster
Management “Marrë nga www.qmed.org.in/wp –
content/uploads/2013/02/pi_info_sys_disastermgnt.pdf (Parë më 15 mars 2015)

Zyra e Kryeministrit (2014) “Grupi i punës për menaxhimin e thatësirës .Mësimet e nxjerra
dhe Rekomandimet, Marrë nga
www.kryeministriks.net/tfu/repository/docs/2014_Thatesiat__mesimet_e_nxjerra__rekoma
ndimet.pdf ,(Parë më 02/09/2015)